asterisk users - Jan 2007 - Incoming SIP line does not display CallerID correctly

Hi all,

I've just setup a sip line with Telasip and when they route the calls to 
my asterisk box, they include an extension along with the context that 
is defined in sip.conf for that DID.

At first, I couldn't figure why they were getting 404 error from my 
asterisk box, but then figured out that they are sending the call to an 
extension that matches my number with them, in the context defined in 
sip.conf.  So instead of transferring the call to say, "incoming" they
are sending the call to incoming/5555555555 where "5555555555" is the 
sip phone number I have with them.

So, I have to account for that extension with something like this:

[incoming]
exten=>5555555555,Goto(incoming,s,1)

Thus transferring the call to the context that I want it to come in on. 
  The problem that I have is the caller ID ${CALLERID(num)} always shows 
the actual number provided by Telasip and not the actual caller id 
information.

I also have axVoice and they do not do it this way.  They simply send it 
to the context without specifying an extension.

Below is a sip packet.  The Caller ID comes through correctly on the sip 
packet by for some reason as I mentioned, Asterisk is reporting it as 
the number I have with the sip provider.

Below is the sip packet.  The "3333333333" represents my cell phone I 
was using to call into the system, which was correct.

localhost*CLI> exit
<-- SIP read from 4.79.19.56:5060:
ACK sip:myaccount@12.224.173.123 SIP/2.0
Record-Route: <sip:4.79.19.56;ftag=as5bfea671;lr=on>
Via: SIP/2.0/UDP 4.79.19.56:5060;branch=0
Via: SIP/2.0/UDP 
4.79.19.58:5060;received=192.168.3.5;branch=z9hG4bK3f2e414e;rport=5060
From: "3333333333" <sip:3333333333@4.79.19.58>;tag=as5bfea671
To: <sip:rjenkins@proxy-in.telasip.com>;tag=as12b47a8d
Contact: <sip:3333333333@4.79.19.58>
Call-ID: 71642b1e05c56b3318e7dae651f7f987@4.79.19.58
CSeq: 102 ACK
User-Agent: Telasip GW3
Max-Forwards: 69
Remote-Party-ID: "3333333333" 
<sip:3333333333@4.79.19.58>;privacy=off;screen=no
Content-Length: 0
P-hint: proxy loose route



-- 

Warm Regards,

Lee

Lee Jenkins wrote:
> 
> 
> Hi all,
> 
> I've just setup a sip line with Telasip and when they route the calls
to
> my asterisk box, they include an extension along with the context that 
> is defined in sip.conf for that DID.
> 
> At first, I couldn't figure why they were getting 404 error from my 
> asterisk box, but then figured out that they are sending the call to an 
> extension that matches my number with them, in the context defined in 
> sip.conf.  So instead of transferring the call to say, "incoming"
they
> are sending the call to incoming/5555555555 where "5555555555" is
the
> sip phone number I have with them.
> 
> So, I have to account for that extension with something like this:
> 
> [incoming]
> exten=>5555555555,Goto(incoming,s,1)
> 
> Thus transferring the call to the context that I want it to come in on. 
>  The problem that I have is the caller ID ${CALLERID(num)} always shows 
> the actual number provided by Telasip and not the actual caller id 
> information.
> 
> I also have axVoice and they do not do it this way.  They simply send it 
> to the context without specifying an extension.
> 
> Below is a sip packet.  The Caller ID comes through correctly on the sip 
> packet by for some reason as I mentioned, Asterisk is reporting it as 
> the number I have with the sip provider.
> 
> Below is the sip packet.  The "3333333333" represents my cell
phone I
> was using to call into the system, which was correct.
> 
> localhost*CLI> exit
> <-- SIP read from 4.79.19.56:5060:
> ACK sip:myaccount@12.224.173.123 SIP/2.0
> Record-Route: <sip:4.79.19.56;ftag=as5bfea671;lr=on>
> Via: SIP/2.0/UDP 4.79.19.56:5060;branch=0
> Via: SIP/2.0/UDP 
> 4.79.19.58:5060;received=192.168.3.5;branch=z9hG4bK3f2e414e;rport=5060
> From: "3333333333"
<sip:3333333333@4.79.19.58>;tag=as5bfea671
> To: <sip:rjenkins@proxy-in.telasip.com>;tag=as12b47a8d
> Contact: <sip:3333333333@4.79.19.58>
> Call-ID: 71642b1e05c56b3318e7dae651f7f987@4.79.19.58
> CSeq: 102 ACK
> User-Agent: Telasip GW3
> Max-Forwards: 69
> Remote-Party-ID: "3333333333" 
> <sip:3333333333@4.79.19.58>;privacy=off;screen=no
> Content-Length: 0
> P-hint: proxy loose route
> 
Just a bit more information on this in hopes that someone more 
knowledgeable than I will chime in.

This problem still persists, of course and I'm having a pickle trying to 
figure out what the problem would be.

Summary:

I have two SIP accounts.  One with axVoice who forwards the call to my 
asterisk box at the "s" extension of my incoming context.  The other 
with Telasip who forwards the calls to "5555555555" extension of my 
incoming context where "5555555555" represents the provisioned
telephone
number for that line.

The problem is that with calls coming in from the Telasip account, 
Asterisk ${CALLERID(num)} always returns "5555555555", the Telasip 
provisioned phone number instead of the caller's real CID.

My incoming extension.conf:

; -- Before adding Telasip account
[incoming]
exten=>s,1,Answer()
exten=>s,2,Ringing()
exten=>s,3,SetMusicOnHold(default)
exten=>s,4,Wait(1)
exten=>s,5,Goto(check_time,s,1)

... check_time does a quick GoToIfTime and into the dialplan we go.

When I got my Telasip account, I had to change it to match the extension 
they were pointing to

[incoming]
exten=>s,1,Answer()
exten=>s,2,Ringing()
exten=>s,3,SetMusicOnHold(default)
exten=>s,4,Wait(5)
exten=>s,5,Goto(check_time,s,1)
exten=>5555555555,1,Answer()
exten=>5555555555,2,Ringing()
exten=>5555555555,3,SetMusicOnHold(default)
exten=>5555555555,4,Wait(5)
exten=>5555555555,5,Goto(check_time,s,1)
; exten=>5555555555,1,Goto(incoming,s,1 <= Tried this too.

I've tried it a couple of different ways and while the calls do get 
routed correctly and everything works fine otherwise, any reference to 
${CALLERID(num)} returns the SIP number called and not the caller's 
correct CID.  For instance, inserting a Noop() such as ;

exten=>5555555555,2,Noop(caller id: ${CALLERID(num)})

results in "caller id: 5555555555" in the CLI when the call comes in. 
Notice from the priority that I tried it after a call to Answer().

I'm a little stumped so any suggestions or observations would be 
appreciated as always.

-- 

Warm Regards,

Lee