asterisk users - May 2004 - Caller-ID for alphanumeric SIP uris

My first post here, so a brief intro:

I'm somewhat new to Asterisk, but have been working with SIP
in depth for about 3 years.  I studied Asterisk for about a year 
and have been experimenting with it hands-on for the past 
month or so.  I've done 6 Asterisk installs in wildly different
roles/applications, some of them test systems, others in 
semi-production, so I know a little bit about it.  I've setup
voicemail, meetme, ENUM, and other Asterisk features, and I've 
written some AGI scripts and done some other semi-interesting 
tweaks.

That said, I'm curious about how others might solve the following
problem.  In a pure-SIP environment, if a user has an alphanumeric
SIP uri, say sip:joe@sipservice1.com, when that user calls another 
SIP phone, (a real IP phone, as opposed to an ATA), via a SIP proxy,
that phone can log the full URI, and 'call return' works because the
SIP phone calls that URI.  With Asterisk, such a call would come in 
with the SIP From: header (thus Caller-ID in Asterisk parlance) as
something like:

  From: "joe" <sip:asterisk@204.16.112.70>;tag=as54f3792a

In this case, Asterisk doesn't know how to return the call, nor
does the SIP phone, because even if the SIP phone can dial full
alphanumeric URI's with some kind of a 'call return' feature, 
the sip:asterisk@204.16.112.70 (where 204.16.112.70 would be the
IP address of the Asterisk server), isn't a valid URI and doesn't
route a call to the original SIP URI: sip:joe@sipservice1.com.

I've thought of some tricks for handling this, and I've looked
around the archives and Google searches, but haven't seen much
discussion of this issue.

TIA,

David

At 3:02 PM -0700 on 5/11/04, David Beckemeyer wrote:
>My first post here, so a brief intro:
>
>I'm somewhat new to Asterisk, but have been working with SIP
>in depth for about 3 years.  I studied Asterisk for about a year
>and have been experimenting with it hands-on for the past
>month or so.  I've done 6 Asterisk installs in wildly different
>roles/applications, some of them test systems, others in
>semi-production, so I know a little bit about it.  I've setup
>voicemail, meetme, ENUM, and other Asterisk features, and I've
>written some AGI scripts and done some other semi-interesting
>tweaks.
>
>That said, I'm curious about how others might solve the following
>problem.  In a pure-SIP environment, if a user has an alphanumeric
>SIP uri, say sip:joe@sipservice1.com, when that user calls another
>SIP phone, (a real IP phone, as opposed to an ATA), via a SIP proxy,
>that phone can log the full URI, and 'call return' works because the
>SIP phone calls that URI.  With Asterisk, such a call would come in
>with the SIP From: header (thus Caller-ID in Asterisk parlance) as
>something like:
>
>   From: "joe" <sip:asterisk@204.16.112.70>;tag=as54f3792a
>
>In this case, Asterisk doesn't know how to return the call, nor
>does the SIP phone, because even if the SIP phone can dial full
>alphanumeric URI's with some kind of a 'call return' feature,
>the sip:asterisk@204.16.112.70 (where 204.16.112.70 would be the
>IP address of the Asterisk server), isn't a valid URI and doesn't
>route a call to the original SIP URI: sip:joe@sipservice1.com.
>
>I've thought of some tricks for handling this, and I've looked
>around the archives and Google searches, but haven't seen much
>discussion of this issue.
>
>TIA,
>
>David
David -
   You're correct.  This is an unfortunate side effect of Asterisk not 
really being a SIP proxy.  It's a PBX replacement.  Now, I understand 
that Olle's chan_sip2 has some of this type of feature functionality 
built into it, and you may want to take a look at that.

   In the interim, there are some really awful, terrible, horrendous 
tricks you can do that might work around this problem.  It involves 
snagging the SIP URI on the inbound call, pushing it into a database, 
assigning a pseudo-random number to that entry, and then keeping that 
mapping... forever.  If a user hit the "redial" button, then the 
inverse would happen: your Asterisk server would dig through the 
database looking for the key, find the 'real' SIP URI, and re-route 
the call to the appropriate correct endpoint.  Uuuuugly.

JT