Multpile phone number incoming on one provider SIP account?


#1

Hi Folks,

Having a little trouble that I haven’t been able to figure out… I have a SIP account with a local provider here in .au, engin… On that SIP account I have two phone numbers - one is 02xxxxxx, one ix 03xxxxxx. I can’t seem to get asterisk to recognise that there are two different numbers coming in on the one account… Now with both TCPdump, and SIP debugging, it shows different TO: addresses, but I’m guessing it’s just a limitation of asterisk?

i.e. I get:

On the ‘secondary number’, I see:
INVITE sip:s@202.128.109.6 /2.0
To: sip:03901308xx@voice.mibroadband.com.au
From:.sip:0417xxxxxx@voice.mibroadband.com.au

On the ‘main number’, I see:
INVITE sip:s@202.128.109.6 /2.0
To: sip:02611286xx@voice.mibroadband.com.au
From:.sip:0417xxxxxx@voice.mibroadband.com.au

However asterisk just points everything at the s extension, and I can’t find any way of differentiating between calls to the 02611286xx and 03901308xx numbers… is there a way of doing this on one SIP account? Or am I going to need to get a second SIP account with my provider?

Thanks,

Damien


#2

sure,

you need to have matching extension for each account and direct it what to do. (Btw - you can do sip debug at the CLI to see the same SIP messages in the log, a bit easier than the whole tcpdump/ehtereal route - although the latter being extremely useful for those harder problems).

Anyhow, in the context where you are sending incoming calls for that provider (from-trunk or what ever):

[from-trunk]
exten => 03901208XX,1,DO_SOMETHING()
exten => 03901208XX,n,KEEP DOING WHATEVER()
exten => 02611286XX,1,DO_SOMETHING()
exten => 03901208XX,n,KEEP DOING WHATEVER()
exten => s,1,DO_SOMETHING_FOR_THE_REST()

in other words, trap the incoming DID which is the TO: field and go off into your dial plan doing what ever you want to do with it. (You can also use _02XXXXXX type pattern matching if appropriate for what you are doing.)

p


#3

Hi P,

Thanks for your reply… Is this something that was only implemented in a recent version of asterisk? I’m currently running 1.2.4…

Here’s what I’m seeing in a sip debug:

<-- SIP read from 202.61.13.40:5060:
INVITE sip:s@202.128.109.6 SIP/2.0
To: <sip:0390130863@voice.mibroadband.com.au>
From: <sip:0417055052@202.61.13.52>;tag=251b2c2b
Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-d4a6326e2b4d5132ff46-1-cHAxNmZkMTY3MGY0ZmM4ZDY0ZTQ5Mw..-d87543-
Call-ID: 32d2b16c25a2f77634973c69b03fad53
CSeq: 485836882 INVITE
Contact: <sip:2nCvrO0hlpBnLAEazI4Rc5somneKml6QQ..@202.61.13.40:5060>
Expires: 180
Max-Forwards: 68
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Content-Disposition: session;handling=required
Content-Type: application/sdp
Date: Mon, 17 Apr 2006 07:24:36 GMT
Supported: timer, resource-priority, replaces
Timestamp: 1145258676
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow-Events: telephone-event
Content-Length: 425
Remote-Party-ID: <sip:0417055052@202.61.13.52>;party=calling;screen=yes;privacy=off
Min-SE: 1800
Cisco-Guid: 1669093951-3467383258-2212823043-3128418427

v=0
o=CiscoSystemsSIP-GW-UserAgent 7430 974753469 IN IP4 202.61.13.40
s=SIP Call
c=IN IP4 202.61.13.40
t=0 0
m=audio 16588 RTP/AVP 18 8 0 98 99 102 101 19
c=IN IP4 202.61.13.40
a=fmtp:18 annexb=yes
a=fmtp:101 0-16
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:19 CN/8000

--- (21 headers 17 lines)---
Using INVITE request as basis request - 32d2b16c25a2f77634973c69b03fad53
Sending to 202.61.13.40 : 5060 (non-NAT)
Found peer 'engin'
Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 98
Found RTP audio format 99
Found RTP audio format 102
Found RTP audio format 101
Found RTP audio format 19
Peer audio RTP is at port 202.61.13.40:16588
Found description format G729
Found description format PCMA
Found description format PCMU
Found description format G726-16
Found description format G726-24
Found description format G726-32
Found description format telephone-event
Found description format CN
Capabilities: us - 0x50e (gsm|ulaw|alaw|g729|ilbc), peer - audio=0x11c (ulaw|alaw|g726|g729)/video=0x0 (nothing), combined - 0x10c (ulaw|alaw|g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x3 (telephone-event|CN), combined - 0x1 (telephone-event)
Looking for s in from-engin (domain 202.128.109.6)
list_route: hop: <sip:2nCvrO0hlpBnLAEazI4Rc5somneKml6QQ..@202.61.13.40:5060>
Transmitting (no NAT) to 202.61.13.40:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-d4a6326e2b4d5132ff46-1-cHAxNmZkMTY3MGY0ZmM4ZDY0ZTQ5Mw..-d87543-;received=202.61.13.40
From: <sip:0417055052@202.61.13.52>;tag=251b2c2b
To: <sip:0390130863@voice.mibroadband.com.au>
Call-ID: 32d2b16c25a2f77634973c69b03fad53
CSeq: 485836882 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:s@202.128.109.6>
Content-Length: 0


---
    -- Executing Dial("SIP/0261128626-d929", "SIP/damien") in new stack

So it’s going straight to the s extension, rather than the phone numbe rin the To.

Here’s what my from-engin context (which is the context that incoming calls from the provider are pointed at…) looks like:

[from-engin]
exten => 0261128626,1,Dial(SIP/damienwork)
exten => 0261128626,2,HANGUP
exten => 0390130863,1,Dial(SIP/damien)
exten => 0390130863,2,HANGUP
exten => s,1,DIAL(SIP/damien)
exten => s,2,HANGUP

My register line in my sip.conf doesn’t specifically specify the s extension, but if I don’t have the s extension in extensions.conf, calls don’t come into asterisk at all - they end up with the provider’s voicemail…

Is there something else I should be doing?

Thanks muchly for you help :smile:

Regards,

Damien


#4

are you sure it is coming in to that context, can you post your sip.conf config? I also have never had incoming with leading 0, don’t know if that could make a difference. You can put _XXXXX as your extensions and try that. Also, do a dump (NooP) of all the channel variables at the s extension to see what everything is set to (including the ${EXTEN}) to help see what is going on.

p


#5

Hi P,

Sip config looks like the following:

in the register section:
register => 0261128626:xxxxxxxx@byo.engin.com.au
(note: i tried using a second login with the second phone number on the account, but it was bounced back..)

in the peer section:
[engin]
callerid="Framed" <0261128626>
type=friend
host=byo.engin.com.au
fromdomain=voice.mibroadband.com.au
username=0261128626
secret=xxxxxxxx
fromuser=0261128626
nat=no
auth=0261128626:xxxxxxx@byo.engin.com.au
disallow=all
allow=ulaw
allow=g729
allow=ilbc
allow=alaw
allow=gsm
context=from-engin
musiconhold=framed
dtmfmode=rfc2833
reinvite=no
canreinvinte=no
qualify=no
port=5060
realm=mobileinnovations.com.au
insecure=very

Re the Variable dump (i was calling the 03 number, btw), it looks like:

    -- Executing NoOp("SIP/0261128626-3119", "") in new stack # ACCOUNTCODE
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #ANSWEREDTIME
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #BLINDTRANSFER
    -- Executing NoOp("SIP/0261128626-3119", "0261128626") in new stack #CALLERID
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #CALLERIDNAME
    -- Executing NoOp("SIP/0261128626-3119", "0261128626") in new stack #CALLERIDNUM
    -- Executing NoOp("SIP/0261128626-3119", "0") in new stack #CALLINGPRES
    -- Executing NoOp("SIP/0261128626-3119", "SIP/0261128626-3119") in new stack #CHANNEL
    -- Executing NoOp("SIP/0261128626-3119", "from-engin") in new stack #CONTEXT
    -- Executing NoOp("SIP/0261128626-3119", "18042006-14:05:29") in new stack #DATETIME
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #DIALLEDPEERNAME
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #DIALLEDPEERNUMBER
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #DIALSTATUS
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #DNID
    -- Executing NoOp("SIP/0261128626-3119", "1145333129") in new stack #EPOCH
    -- Executing NoOp("SIP/0261128626-3119", "s") in new stack #EXTEN
    -- Executing NoOp("SIP/0261128626-3119", "0") in new stack #HANGUPCAUSE
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #INVALID_EXTEN
    -- Executing NoOp("SIP/0261128626-3119", "en") in new stack #LANGUAGE
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #MEETMESECS
    -- Executing NoOp("SIP/0261128626-3119", "21") in new stack #PRIORITY
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #RDNIS
    -- Executing NoOp("SIP/0261128626-3119", "202.128.109.6") in new stack #SIPDOMAIN
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #SIP_CODEC
    -- Executing NoOp("SIP/0261128626-3119", "d11670a1f9a2f68c9232ad0bee2b5e98") in new stack #SIPCALLID
    -- Executing NoOp("SIP/0261128626-3119", "Cisco-SIPGateway/IOS-12.x") in new stack #SIPUSERAGENT
    -- Executing NoOp("SIP/0261128626-3119", "20060418-140529") in new stack #TIMESTAMP
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #TXTCIDNAME
    -- Executing NoOp("SIP/0261128626-3119", "1145333129.24") in new stack #UNIQUEID
    -- Executing NoOp("SIP/0261128626-3119", "") in new stack #TOUCH_MONITOR

Thanks for your help,

Damien


#6

were all of the settings in your sip.conf file specified by your provider? (There are even keywords like renivite=no that I don’t think are valid (but would need to go back and check). Usually asterisk is forgiving, but do make sure they are all correct and needed (although I don’t suspect that is the issue).

anyhow - can you do turn on sip debug and try another call. You want to see if you provider is sending the did in the sip message. (CLI: sip debug). (you can turn it on for a specific provider or ip address to help minimize the messages which makes it easier to track. (e.g. sip debug ip xx.xx.xx.xx)

p


#7

Hi P,

Al the settings in the SIP.conf were copied to me by the provider (they’re not entirely ‘up’ with asterisk, that was just ‘what worked’ for them with other clients…)

Ok, here’s the full SIP debug output:

<-- SIP read from 202.61.13.40:5060:
INVITE sip:s@202.128.109.6 SIP/2.0
To: <sip:0390130863@voice.mibroadband.com.au>
From: <sip:0417055052@202.61.13.52>;tag=ce0e5e7d
Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-c63d142ce87de2796bf8-1-cHBhZWE4NWIxNTc2NGU1MjUwM2MzZg..-d87543-
Call-ID: 6e2ffa14150222c50126debcc87120f4
CSeq: 240278331 INVITE
Contact: <sip:2nCvrO0hlpBnLAEazI4Rc5somneKml6QQ..@202.61.13.40:5060>
Expires: 180
Max-Forwards: 68
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Content-Disposition: session;handling=required
Content-Type: application/sdp
Date: Tue, 18 Apr 2006 14:54:55 GMT
Supported: timer, resource-priority, replaces
Timestamp: 1145372095
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow-Events: telephone-event
Content-Length: 426
Remote-Party-ID: <sip:0417055052@202.61.13.52>;party=calling;screen=yes;privacy=off
Min-SE: 1800
Cisco-Guid: 1993281523-3484684762-2284322819-3128418427

v=0
o=CiscoSystemsSIP-GW-UserAgent 9710 1096284119 IN IP4 202.61.13.40
s=SIP Call
c=IN IP4 202.61.13.40
t=0 0
m=audio 16684 RTP/AVP 18 8 0 98 99 102 101 19
c=IN IP4 202.61.13.40
a=fmtp:18 annexb=yes
a=fmtp:101 0-16
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:19 CN/8000

--- (21 headers 17 lines)---
Using INVITE request as basis request - 6e2ffa14150222c50126debcc87120f4
Sending to 202.61.13.40 : 5060 (non-NAT)
Found no matching peer or user for '202.61.13.40:5060'
Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 98
Found RTP audio format 99
Found RTP audio format 102
Found RTP audio format 101
Found RTP audio format 19
Peer audio RTP is at port 202.61.13.40:16684
Found description format G729
Found description format PCMA
Found description format PCMU
Found description format G726-16
Found description format G726-24
Found description format G726-32
Found description format telephone-event
Found description format CN
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x11c (ulaw|alaw|g726|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x3 (telephone-event|CN), combined - 0x1 (telephone-event)
Looking for s in default (domain 202.128.109.6)
list_route: hop: <sip:2nCvrO0hlpBnLAEazI4Rc5somneKml6QQ..@202.61.13.40:5060>

Transmitting (no NAT) to 202.61.13.40:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-c63d142ce87de2796bf8-1-cHBhZWE4NWIxNTc2NGU1MjUwM2MzZg..-d87543-;received=202.61.13.40
From: <sip:0417055052@202.61.13.52>;tag=ce0e5e7d
To: <sip:0390130863@voice.mibroadband.com.au>
Call-ID: 6e2ffa14150222c50126debcc87120f4
CSeq: 240278331 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:s@202.128.109.6>
Content-Length: 0


---
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "0417055052") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "0417055052") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "0") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "SIP/202.61.13.52-081bb460") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "default") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "19042006-00:54:55") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "1145372095") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "s") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "0") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "en") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "21") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "202.128.109.6") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "6e2ffa14150222c50126debcc87120f4") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "Cisco-SIPGateway/IOS-12.x") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "20060419-005455") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "1145372095.70") in new stack
    -- Executing NoOp("SIP/202.61.13.52-081bb460", "") in new stack
    -- Executing Dial("SIP/202.61.13.52-081bb460", "SIP/damien") in new stack
    -- Called damien
Using INVITE request as basis request - 6e2ffa14150222c50126debcc87120f4
    -- SIP/damien-9043 is ringing

Looking at that, I’m guessing it’s something to do with the bit that says "Found no matching peer or user for ‘202.61.13.40:5060’ " (even though that’s one of the two peers that it maps against the engin registration)?, and then goes on to look for s in default context?

Thanks,

Damien


#8

Just FYI, ended up getting this sorted out - you have to do a GotoIf on ${SIP_HEADER(TO)}, and cut it up to suit your country’s style of phone numbers :smile:

Cheers,

Damien