Introduce CNAM

[GoogleCodeExporter]

As posted by Red Leatherman:

@EasternPA:
Things have been working smoothly for several months now and I see  that
you and Mike Telis are keeping the dial plans updated on your Google Code site.

Recently I had some time and I got CNAM working (with a little help from
Mike Telis) for my G5 account and it also worked with my Sipgate.
The CNAM uses a "phone book" in the dial plan for number recognition and
can use white pages look-ups if you sign up for a white pages api (which I
did). http://developer.whitepages.com/

It's described over on the sipsorcery forum under use cases and there is a
dial plan that a forum member posted there (doesn't work with G5 without a
tweak) but I was wondering if you and Mike would be interested in adding
the setup information and some accompanying cleaned up dial plans with
integrated CNAM on your Google Code page.

Original issue reported on code.google.com by easter...@gmail.com on 15 May 2010 at 1:35

[GoogleCodeExporter]

CNAM or Caller's Name lookup is what we know as Caller ID. 
the sipsorcery thread I learned about CNAM is 
http://forum.sipsorcery.com/viewtopic.php?f=15&t=2007

Caller ID got really popular in the 90's but with cell phones we don't pay it 
much
attention anymore. if our friend is in our phone book on the cell we get a name 
if
not we still have a number and decide whether or not to answer.

Integrating CNAM will enhance a VOIP line with a caller ID enabled phone 
plugged into
a ata and other than that it's not much help.
Well I use a ata almost exclusively so it's a deal to me and I got it going and 
maybe
it will be a function you want with your ata as well .. so long as your using a
caller ID enabled phone too.
You can use it with a phone book in your dial plan and the function will be 
like a
cell phone, ie if you have a match with a name and number.
You can also sign up for a white pages api account at
http://developer.whitepages.com/ and enter the number your assigned in the
appropriate place in the dial plan and you get a call from a registered number 
you
will get a name and number, if it isn't registered I've been getting a city 
state and
number so that's still more helpful than just a number.
I'll attach the dial plan that I copied from the sipsorcery forum and Mike 
Telis gave
me a code modification to allow it to work with Gizmo5. if you use the dial 
plan from
the CNAM thread over there it will work with sipgate but needs a line modified 
to
work with G5.
I Tried integrating CNAM in my existing dial plans but I suck at that so I'm 
just
doing copy and paste.

The CNAM phone book and the line to paste in the White pages api is in the 
**status**
section.
And so you know, you can use it without the white pages api and just use the 
phone
book like a cell phone does.

Original comment by Red.Leat...@gmail.com on 15 May 2010 at 2:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Okay I have hosted the file as is. Click here on r132 and then click on the path
above "Add". The raw file doesn't seem to be available at this moment, but it 
should
be shortly. Next we can clean it up, document the update, and if its small 
enough,
included into the Simple or Complex Dialplan.

Original comment by easter...@gmail.com on 15 May 2010 at 3:18

• Changed state: Started

[GoogleCodeExporter]

Is the tweak required for use with G5 included in this drop? Can someone 
describe the
tweak required?

Original comment by easter...@gmail.com on 15 May 2010 at 3:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The tweak is included. The dial plan as I uploaded here works with Gizmo and 
Sipgate.
the tweak had to do with Gizmo5 putting a + before the number and Mike made a 
fix
that replaced a line in the plan I was using.

Original comment by Red.Leat...@gmail.com on 15 May 2010 at 4:24

[GoogleCodeExporter]

What I'm thinking for "cleanup" is getting the entry for the white pages api 
user
number up to the top of the plan like the entries for user email and passwords 
and such.

Original comment by Red.Leat...@gmail.com on 15 May 2010 at 4:30

[GoogleCodeExporter]

Here is the line of code, old and the new
old = name.sub!(/^011/,'')
new = name.sub!(/^(011|\+)/,'')

Original comment by Red.Leat...@gmail.com on 15 May 2010 at 6:17

[GoogleCodeExporter]

I have written a dialplan combining CNAM lookup with existing complex dialplan 
as well 
as some other enhancements like multiple callback numbers, multiple GV 
accounts, ENUM 
lookup in all databases out there.

EasternPA is working on some kind of "User's manual". Once it's ready, we'll 
publish 
the plan.

Original comment by mte...@gmail.com on 16 May 2010 at 8:17

[GoogleCodeExporter]

Uploaded the dialplan, check it out:

http://code.google.com/p/google-voice-sipsorcery-
dialplans/source/browse/trunk/SIP+Sorcery+Dial+Plans/#SIP Sorcery Dial 
Plans/Contrib/Complex Dial Plan with CNAM lookup

Original comment by mte...@gmail.com on 18 May 2010 at 12:18

[GoogleCodeExporter]

@Mike:
 I got a copy of the dial plan and I saw you put number formatting in too!
Since the mess last night I can't get the "in dial plan" to work, so I guess 
the dust
is going to have to settle a bit.  I cant log into the console to see what is
happening but soon as it does I'll be trying it out and will let you know.
Thank you.

Original comment by Red.Leat...@gmail.com on 18 May 2010 at 12:59

[GoogleCodeExporter]

Yea, Aaron's goofed up with IP addresses:

http://forum.sipsorcery.com/viewtopic.php?f=2&t=2440

and all development and debugging must be postponed for another 12 hours, I 
guess.

Original comment by mte...@gmail.com on 18 May 2010 at 4:39

[GoogleCodeExporter]

Oh my god i HAVE A EMERGENCY, tell Aaron to hurry up i GOTTA ORDER A PIZZA!
Anyhow, I don't know much but I could sorta see that something wasn't linking up
right and knew it was going to take some time to get things going again.
From the time stamps it looks like Aaron just won't sleep until he's done 
fixing it.
I used to be that dedicated but then one day I watched a documentary that said 
how it
took some umpteen billions of years for us to get to this point in time and I 
figure
when things aren't going right, most anything I'm doing can wait one more day. 

Original comment by Red.Leat...@gmail.com on 18 May 2010 at 5:53

[GoogleCodeExporter]

Funny! :-)

Anyway, the things @ sipsorcery are back to normal now.

Original comment by mte...@gmail.com on 19 May 2010 at 1:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@Mike:
I tested your CNAM dial plan (r135) with Gizmo5.
I replaced the Domains  =  line with
['sipsorcery.com','sip1.sipsorcery.com','sip2.sipsorcery.com','184.73.243.48','1
84.73.168.14']

The whitepages look up works and the phone-book hash works.
The Number Format does not work. My phone does support xxx-yyy-zzzz formatting. 
I'm
OK without number formatting but if you want to work on it what can I do to 
help?
paste console ect.., ?
and.. thanks for making these dial plans. :)

Here is what I think I see so far, with sipsorcery the number is posted as 
1xxxyyyzzzz
when I get a formatted number (using sipgate without sipsorcery while it was 
down) I
get xxx-yyy-zzzz  the difference I see is that the 1 doesnt show up when 
formatted
through sipgate.
Now that I read this, I'll test with my sipgate through sipsorcery in about a 
hour or
so and see what happens.

Original comment by Red.Leat...@gmail.com on 19 May 2010 at 12:57

[GoogleCodeExporter]

I think that number formatting conflicts with your phone. Just to make sure, 
could you 
show me Console log for incoming call?

Original comment by mte...@gmail.com on 19 May 2010 at 3:13

[GoogleCodeExporter]

DialPlan 15:35:06:888 sip1: Using dialplan CNAM MTelis G5 for In call to
sip:lklewis@sipsorcery.com;rinstance=427749.
NewCall 15:35:06:966 sip1: Executing script dial plan for call to lklewis.
DialPlan 15:35:07:169 sip1: ** Call from
<sip:+1682xxxyyyy@74.125.240.93>;tag=2052159311 to lklewis **
DialPlan 15:35:07:169 sip1: Local time: 05/19/2010 10:35
DialPlan 15:35:07:169 sip1: Caller's number: '1682xxxyyyy'
DialPlan 15:35:07:169 sip1: Caller's name:   'Karl Cell'
DialPlan 15:35:07:184 sip1: URI dialing: lklewis@local[fu=1682xxxyyyy]
DialPlan 15:35:07:184 sip1: Commencing Dial with: lklewis@local[fu=1682xxxyyyy].
DialPlan 15:35:07:231 sip1: Call leg is for local domain looking up bindings for
lklewis@sipsorcery.com for call leg lklewis@local.
DialPlan 15:35:07:325 sip1: 1 found for lklewis@sipsorcery.com.
DialPlan 15:35:07:325 sip1: ForkCall commencing call leg to
sip:lklewis@71.11.233.201:5060.
DialPlan 15:35:08:856 sip1: SIPClientUserAgent Call using alternate outbound 
proxy of
udp:10.249.142.143:5060.
DialPlan 15:35:08:856 sip1: Switching to sip:lklewis@71.11.233.201:5060 via
udp:10.249.142.143:5060.
DialPlan 15:35:08:856 sip1: SDP on UAC call had public IP not mangled, RTP 
socket
74.125.240.93:23628.
DialPlan 15:35:08:935 sip1: Information response 100 Trying for
sip:lklewis@71.11.233.201:5060.
DialPlan 15:35:09:091 sip1: Information response 180 Ringing for
sip:lklewis@71.11.233.201:5060.
DialPlan 15:35:09:091 sip1: UAS call progressing with Ringing.
DialPlan 15:35:20:123 sip1: Response 200 OK for sip:lklewis@71.11.233.201:5060.
DialPlan 15:35:20:123 sip1: SDP on UAC response had public IP not mangled, RTP 
socket
71.11.233.201:8004.
DialPlan 15:35:20:138 sip1: Cancelling all call legs for ForkCall app.
DialPlan 15:35:20:138 sip1: Answering client call with a response status of 200.
DialPlan 15:35:20:435 sip1: Dial command was successfully answered in 13.11s.
DialPlan 15:35:20:576 sip1: Dial plan execution completed with normal clearing.
DialPlan 15:35:29:201 sip1: Matching dialogue found for BYE to 
sip:184.73.243.48:5060
from udp:10.249.142.143:5060.

Original comment by Red.Leat...@gmail.com on 19 May 2010 at 3:46

[GoogleCodeExporter]

Oh, ir was a misunderstanding on my part; I thought you were talking about this 
line:

sys.SetFromHeader(formatNum(cname || name), nil, nil)  # Set FromName for 
sys.Dial

formatNum works if (and only if) caller's number wasn't found in your local 
CNAM 
table and White Pages know nothing about it, too. This is a rare case... the 
only one 
I can think of is a 800 number used by some telemarketers.

So... yes, I'm prepending the "User" field in URI with '1' (country code) if 
the 
number looks like US caller ID. Reason: without this '1', Bria wouldn't find 
caller's 
name in it's phone book if you store the number in ENUM format (such as +1 212 
555-
1212). Normally  SIP telephones and softphones gladly accept ENUM format; if 
this is 
a problem for your softphone just remove [fu=#{name}] from the dial string.

One more remark: take a look at SIP URI you get from Gizmo5. Not only it has 
'1', it 
also contains plus sign in front of the name:

<sip:+1682xxxyyyy@74.125.240.93>

It makes me wondering what would your phone display if it got such a weird User 
field. Ever tried to register the phone to Gizmo5 directly and receive a call?

Original comment by mte...@gmail.com on 19 May 2010 at 5:07

[GoogleCodeExporter]

@Mike:
Thanks for taking a look. 
The console printout for sipgate is similar but without the '+'
<sip:6825xxxyyy@sipgate.com>

I don't have a paid Gizmo5 number so I can only receive calls on Gizmo5 via 
Google or
Gizmo to Gizmo so that may be a issue as well.

I used to use the ata with Gizmo registered directly. I made the switch just 
now and
the number shows up 1682xxxyyyy on the phone's cid. so that is the same and the 
'+'
must be being taken care of at the Google end before it's forwarded.

Funny thing, if I register sipgate direct to the ata, the first line shows my 
sipgate
number 415xxxyyy and the bottom line shows my google number with proper 
formatting
xxx-yyy-zzzz dashes and all without the 1. but not showing my mobile number at 
all.

I see it as a lot of jumps from one place to another and lots of possibilities 
for
conflicting code.

Original comment by Red.Leat...@gmail.com on 19 May 2010 at 6:23

[GoogleCodeExporter]

I'd like to reiterate that CNAM IS working properly, I just saw the num format 
thing
and wanted to mess with it and see if it would work for me. 

Original comment by Red.Leat...@gmail.com on 19 May 2010 at 6:27

[GoogleCodeExporter]

Okay, let me give you some tips:

1. Do not mess with name and cname variables (do not alter them) unless you 
notice 
something inappropriate in:

DialPlan 15:35:07:169 sip1: Caller's number: '1682xxxyyyy'
DialPlan 15:35:07:169 sip1: Caller's name:   'Karl Cell'

Callet's number should always be in ENUM format (country code + area code + 
number). 
If you do find something wrong in these lines, you'd better open a trouble 
ticket.

2. You can use formatNum method to format number nicely. The code within this 
method 
is pretty simple and straighforward, you can modify it to your taste. Formatted 
number should always go to the "Name" field of SIP URI. BTW, here is SIP URI 
format, 
to avoid any confusion in terminology:

Name <sip:User@Host>

Avoid special symbols in the "User" field.

3. sys.SetFromHeader method changes Name, User and Host fields "globally". fd, 
fu, fh  
keys in sys.Dial strings can be used to change fields for individual call legs.

4. If you have several clients (ATA, IP Phone, Softphone) and they all behave 
differently, you can have them registered to different SIP accounts and use 
multi-
forward, like this:

callswitch("lklewis@local&lklewis1@local[fu=#{name}]&lklewis2@local[fu=#{name[1.
.-
1]}]")

Original comment by mte...@gmail.com on 19 May 2010 at 7:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@Mike:
I couldn't let it rest, and I got it working on G5.
so far with the CNAM hash table.
I remember the line you fixed to take the '+' out
name.sub!(/^(\+|00|011)/,'')
I edited it to take the '1' out as well
name.sub!(/^(\+1|00|011)/,'')
So far so good, I had to edit my CNAM hash table to take all the 1's out but so 
far
so good
I may have broke whitepages but I can test that tomorrow when I can get a call 
in
from a landline to test the whitepages

Original comment by Red.Leat...@gmail.com on 20 May 2010 at 4:03

[GoogleCodeExporter]

Removing country code from the "name" is not an option, it will certainly bite 
you 
back. For example, suppose you get a call from Budapest, Hungary. Country code 
is 36, 
area code - 1 and then it's followed by 7-digit number. If you change the code 
as you 
described, the number will be treated as if the call came from the US, area 
code 361.

I don't think formatNum has something to do with your issue, because it 
receives 
"Karl Cell" as the argument and, since it's not a phone number it doesn't 
reformat 
it.

So, most certainly the problem is related to [fu=...] option in the dial 
string. 
Start from removing first char:

callswitch("#{sys.Username}@local[fu=#{name[1..-1]}]",45) unless (30..745) === 
@t.hour*100 + @t.min # forward straight to VM from 0:30a to 7:45a

and check whether it fixes the problem (of course, you have to revert to my 
original 
code first).

Original comment by mte...@gmail.com on 20 May 2010 at 4:30

[GoogleCodeExporter]

I've become unstuck in time again and I'll have to wait a few days before I can 
get
back to messing with it. 

Original comment by Red.Leat...@gmail.com on 20 May 2010 at 12:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi, I deleted your last comment because you forgot to remove private 
information.

Original comment by mte...@gmail.com on 21 May 2010 at 3:26

[GoogleCodeExporter]

Along with being able to receive CNAM when using a whitepages API with a 
developer account, you can sign into whitepages and update or create your 
account and enter your GV number so it will broadcast to caller ID enabled 
lines.
If you have a listed landline you will find your already there.
http://www.whitepages.com/

Original comment by Red.Leat...@gmail.com on 12 May 2011 at 2:32

[GoogleCodeExporter]

Hey, Red. Long time no see. I'm cleaning up shop around here and was wondering 
if I can close this due to inactivity. Do you still need this open, or has Mike 
incorporated the feature you were requesting?

Thanks!

Original comment by easter...@gmail.com on 1 Mar 2012 at 11:05

[GoogleCodeExporter]

Sure, it was just supposed to be a tutorial on integrating CNAM into the dial 
plan. 
It's been working great.

Original comment by Red.Leat...@gmail.com on 22 Mar 2012 at 11:31

[GoogleCodeExporter]

Thanks for your update, Red. Much appreciated. Was this meant to be a tutorial 
for Mike, or for the users? I also wanted to make sure that the wiki page 
describing the next generation dialplan covers this to your liking. I need to 
remove the bit about area code 747, and see if Mike needs to do the same for 
the actual script.

Thanks again!

Original comment by easter...@gmail.com on 22 Mar 2012 at 1:13

[GoogleCodeExporter]

Mike T actually did all the work from some scraps someone had started some time 
before on the sipsorcery forum, I got curious and started messing with it and 
then he then made the CNAM dialplans that are somewhere over in the "source" 
section under "Contrib" a simple and complex. it allows use of a "phonebook" 
too and using the whitepages api and works very well. it's just my early 
attempt at a tutorial really sucked.
You touched on it in the "next generation dialplans" but finding the CNAM dial 
plan is a little tricky and I don't think too many people care that much about 
it.
As a side note, have you noticed that dialing your own GV number from your ATA 
or sip dialer on a smartphone gets to VM with no problems nowadays? I found out 
by accident a month or two ago.

Original comment by Red.Leat...@gmail.com on 22 Mar 2012 at 2:16

[GoogleCodeExporter]

That's great news about the self-dialed voicemail! Not only have I not needed 
to use GV in several months, I came back to find the rnr_se key issue we talked 
about in the forum yesterday. What do you think I should do about covering CNAM 
in the wiki? Is there enough new content In this issue to enable writing a new 
wiki page or beefing up the current next generation page? Or do you thnk it can 
wait to see if more interest develops?

Original comment by easter...@gmail.com on 22 Mar 2012 at 2:26

[GoogleCodeExporter]

I hate to say it but I think the interest is minimal. 
On the GV forum I've seen a few comments about CNAM but it always turns out 
they are looking to push their ID not about reading incoming ID. Other issues 
with caller ID have to do with sprint integration and none related to CNAM when 
using Sipsorcery scripting.
Personally I think the CNAM dialplan with the phone book and whitepages api is 
the best thing since toilet paper but then I'm probably just easily amused.
My incoming calls from most businesses are identified as are landlines. and the 
phonebook allows me to enter names for family and friends so it shows up on my 
Handset connected to the ATA and my mobile.
After you mentioned the rnr se key issue yesterday I looked in my account 
settings to see what was set or not set and then suddenly I had the rnr se key 
issue only with that account. I logged out of everything (not just closing the 
page) waited a few then tried calling again and it started working again. so 
damifino but seems like it was related to me logging into my account settings 
at Google then after I logged out of everything Google and waited a bit the 
phone started working again.

Original comment by Red.Leat...@gmail.com on 22 Mar 2012 at 2:56

[GoogleCodeExporter]

CNAM on my mobile = smart phone sip app registered to sipsorcery not the mobile 
service

Original comment by Red.Leat...@gmail.com on 22 Mar 2012 at 3:07

[GoogleCodeExporter]

This really is an elusive problem. I signed out of everything, shut down my 
Android phones and tablet and the iPad, then started the process of turning on 
2-factor authentication. When I saw that they wanted me to create a password 
for each device I own, I backed out and cancelled the setup. I then powered 
everything back up, but the rnr se key issue was happily awaiting my return. I 
have everything so tightly integrated into what began as just a GMail account, 
that I really have no interest in creating a new account just to get GV working 
again -- especially now that I have grown used to dialing from the mobile web 
page. 

Thanks again for all your feedback with this issue. I'm going to close it out 
without making any changes to the wiki at this point. If interest suddenly 
explodes, we can revisit and figure out what to do. I have a whole new Eclipse 
setup now so I need to reconnect to the source code repository anyway if I'm 
going to extract the Gizmo-specific area code 747 handling.

Original comment by easter...@gmail.com on 22 Mar 2012 at 3:30

• Changed state: Verified

[GoogleCodeExporter]

I believe that the interest in CNAM is proportional to rate of successful 
WhitePages hits. If your incoming calls mostly come from landlines then this 
feature is quite useful; for most mobile phones you get just city/state which 
is not very helpful.

Re rnr_key issue: try to PM Aaron on Sipsorcery forum with your GV details. He 
can try logging in to your GVoice from Sipsorcery server, it should verify SS 
server's IP and clear out the problem.

Re 747 area code (ex-Gizmo): I probably should remove it from the dialplans but 
this wouldn't change anything (747 is not in use, you don't have any issues 
except for a few extra nanoseconds of the server's time).

> Mike

Original comment by mte...@gmail.com on 23 Mar 2012 at 1:12