All incoming calls go to extension 's'

Asterisk 1.8.3
It used to be working fine until we switched to a new SIP truck service provider. So I guess it probably is a configuration issue.Anyway, outgoing calls work fine, all incoming calls go direction fall to extension ‘s’.
Here’s the log from CLI:

<— SIP read from UDP:69.94.224.2:5060 —>
[color=#800000]INVITE sip:s@192.168.3.2:5060 SIP/2.0[/color]
To: sip:71349142##@65.217.40.205:5060;user=phone
From: sip:71329182##@199.173.101.144:5060;user=phone;tag=036c055c
Via: SIP/2.0/UDP 69.94.224.2:5060;branch=z9hG4bK-d87543-a8049a7e05a17368cbb1-1-cHBmM2Q1NGYyMDg3MGRhMDM5MzYzNQ…-d87543-
Call-ID: 8f41fbaa11f8dddc7fa311c1e1df1237
CSeq: 446242311 INVITE
Contact: sip:EHRJh_--IbP0Wyc-tU_OMD39CyUSPKjC7LZKDeFwUYnxdh8x0Rj0niTAD_pFgo@69.94.224.2:5060
Max-Forwards: 13
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, INFO, SUBSCRIBE, REFER, NOTIFY, PRACK
Content-Type: application/sdp
Supported: 100rel, replaces
Content-Length: 207
P-Asserted-Identity: sip:71329182xx@65.217.40.205;user=phone
Privacy: none

That’s what you registered as.

Thanks for your reply. Could you explain to me in more detail? Do you mean the register clause in sip.conf?

Yes, although that isn’t the only way of doing it. The optional last parameter is what you want to appear in the INVITE. It defaults to “s”.

I’ve never tried, but I suspect that the To header will be presented as ${CALLERID(dnid)}.

[quote=“david55”]Yes, although that isn’t the only way of doing it. The optional last parameter is what you want to appear in the INVITE. It defaults to “s”.

I’ve never tried, but I suspect that the To header will be presented as ${CALLERID(dnid)}.[/quote]

I tried adding /desired_ext to register, but the invite message still shows as
INVITE sip:s@192.168.3.2:5060 SIP/2.0

Also, this is a SIP trunk connection, there will be a bunch of DIDs associated with it. With previous provider, I didn’t add anything to the register clause.

To be sure of the problem, I’d need a SIP trace of the REGISTER, and to check the RFC (I don’t have time for the latter now). However, I suspect both providers are violating the RFC in different ways.

Have you tried CALLERID(dnid)?

[quote=“david55”]To be sure of the problem, I’d need a SIP trace of the REGISTER, and to check the RFC (I don’t have time for the latter now). However, I suspect both providers are violating the RFC in different ways.

Howeve you tried CALLERID(dnid)?[/quote]

unfortunately, CALLERID(dnid) returns nothing.
I am not getting any useful support from the provider, it’s really frustrating.

What register string are you using? If you have purchased multiple DIDs from one provider then you may have to create multiple registration strings having"/DID Number" at last of the registration string. That may solve the issue.

I tried that, but it is not making any difference.
Could somebody verify the INVITE message is supposed to contain valid extension?
My only has an ‘s’ in it:
INVITE sip:s@192.168.3.2:5060 SIP/2.0

I did see the dialed number in this line: To: sip:71349142xx@65.217.40.205:5060;user=phone
But I don’t know how I can use it. CALLERID(DNID) is not returning anything.

I found some registration errors for the DIDs, not sure if this is related:

REGISTER sip:dblhorn-platformsvcs.net SIP/2.0
Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK5d984ae9
Max-Forwards: 70
From: sip:71389570xx@dblhorn-platformsvcs.net;tag=as478c54fe
To: sip:71389570xx@dblhorn-platformsvcs.net
Call-ID: 04e1d576371673202897306c468b24ce@127.0.1.1
CSeq: 168 REGISTER
User-Agent: Asterisk PBX 1.8.4.4
Authorization: Digest username=“71389570xx”, realm=“dblhorn-platformsvcs.net”, algorithm=MD5, uri=“sip:dblhorn-platformsvcs.net”, nonce=“4e15d8dad71c463ad9b6e0e1aab3640e40b74b98”, response=“e0decd188f014d6e6e846529b7f5c2c7”, qop=auth, cnonce=“2e0ba63b”, nc=00000010
Expires: 120
Contact: sip:71349142xx@192.168.3.2:5060
Content-Length: 0

<— SIP read from UDP:69.94.224.2:5060 —>
SIP/2.0 503 Service Unavailable
To: sip:71389570xx@dblhorn-platformsvcs.net;tag=d667b8817a564b9ebeed01aff1da290b.2e70
From: sip:71389570xx@dblhorn-platformsvcs.net;tag=as478c54fe
Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK5d984ae9
Call-ID: 04e1d576371673202897306c468b24ce@127.0.1.1
CSeq: 168 REGISTER
Contact: sip:71389570xx@192.168.3.2:5060;expires=105
Retry-After: 300
Server: DHPS-P900 v1.3.4-005
Content-Length: 0
[color=#800000]P-Registrar-Error: Too many registered contacts[/color]

I hate to do it this way, but the provider doesn’t help at all.
So I hacked chan_sip.c, when incoming call has extension ‘s’, I just overwrite it with the number in “To” field.
Ugly, but it’s working for now.

[quote=“hongfeng”]I hate to do it this way, but the provider doesn’t help at all.
So I hacked chan_sip.c, when incoming call has extension ‘s’, I just overwrite it with the number in “To” field.
Ugly, but it’s working for now.[/quote]

I have the same problem…

What you have done in that chan_sip.c file…

I want to test that…

‘To’ means what…

Criz…

It should be easier to do this in the dialplan. Handle everything as s, initially, then get the To header and extract the user part. Sorry, you have to work out the details for yourself.

You are so right, David.
Life could be much easier if I knew dialplan has such a header() function.
Thanks for the tip.

exten => _.,1,Set(DNID=${SIP_HEADER(TO):5})
exten => _.,2,Set(DNID=${CUT(DNID,@,1})
exten => _.,n,Goto(inbound,${DNID},1)