We’re connecting to Tata Telecom SIP Trunk with our Asterisk Server. Their system requires a specific formatting for To Header, how can I manipulate this header?
Current Header,
To: "7316834350"sip:7316834350@10.54.28.114:5060;transport=UDP
It should be,
To: "6834350"sip:6834350@10.53.179.34:5060;transport=UDP
I could not find a function to manipulate To Header, can someone suggest how can I get this done on chan_sip?
You have provided examples, but there is no context as to what these numbers actually mean.
There is a third-party patch that I wrote for a client that allows setting parameters in the header, but it doesn’t seem like that’s quite what you’re trying to do here. In that case, you’ll likely have to pay someone to add the capability to do this.
Also note that chan_sip is deprecated and being removed from Asterisk within the next year. You should migrate to chan_pjsip soon if possible.
Hi InterLinked,
Sorry for the missing context, the touser value should be the last 7 digits of the DID and the todomain should be a constant value (SBC IP that my ISP has shared). Here’s a dialplan that I tried out,
same => n,Set(TATADID=${EXTEN:-7})
same => n,Noop(Call To header ${TATADID})
same => n,SipAddHeader(To: ${TATADID}@10.53.179.34:5060)
This did not change the value of To: header. I’m trying to setup a SIP Proxy that registers with the SIP Trunk and forwards all calls to my PBX.
I guess that if Asterisk does not currently allow this then I’d have to switch to a different software.
Setting a To header is something one only ever does on outbound calls.
Agree with the point that chan_sip is a lame duck. However, as far as I know, chan_sip is needed to cope with this sort of abuse of the To header, and even seems to be able to set the domain part.
Asterisk sets the To header as per RFC 3261, i.e. it sets the same as request URI.
Assuming what you are currently seeing is the same as the request URI, there are two changes. One is the truncation of the user part, and the other in the change in the domain part.
I’m wondering if the requirement for the user part is bogus, and what they are really telling you to do is to use 10.53… as the actual target domain, and 10.54… as an outbound proxy. In that case try setting the outbound proxy. chan_pjsip has more flexible outbound proxy options, and I think it would allow you to set the user part differently.
If that is not what they are really asking for, you need to get a technically detailed statement of what they require, not just an example.
If they fail to give a good explanation, point out that the To URI should be set to the initial request URI, and that is what you are doing.
People do claim to have succeeded with Asterisk and Tata, without mangling To headers. I do note that they set the request URI to the SBC domain. Why are you not doing that?
Note that their sip.conf contains many common bad usages, and even if using chan_sip, you should configure from first principles, as most published ones are poor, and their real inbound handling is complicated by using the Vicidial GUI.
Looking further, chan_sip does allow you to set the To user and the To domain:
I went back to the messages from Tata’s Customer Support and realised that they had highlighted the modifications in the SIP Invite that is coming from their SBC. I’ve now pointed this out to them.
My current setup is able to handle inbound and outbound calls just fine sometimes. I noticed that most calls are not answered for the callee even though they are handled correctly by my Asterisk. I raised a support ticket for this and their team seems to be unable to diagnose the problem.
Pasting here an example inbound call where the callee heard “This number is not available” – a variant of 503.
No. Time Source Destination Protocol Length Info
1 0.000000 10.53.179.34 10.54.28.114 SIP/SDP 1031 Request: INVITE sip:XX34300@10.54.28.114:5060;transport=UDP |
Frame 1: 1031 bytes on wire (8248 bits), 1031 bytes captured (8248 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.53.179.34, Dst: 10.54.28.114
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:XX34300@10.54.28.114:5060;transport=UDP SIP/2.0
Message Header
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.54.28.114:5060;transport=UDP>
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 INVITE
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-1f4dea1e-aa88-29a258a-7f6d3c334cc0
Route: <sip:10.54.28.114:5060;transport=UDP;lr>
X-SessionId: -1441910912
User-Agent: BN4000-3.8.3-042
Supported: timer,100rel
Max-Forwards: 68
Contact: <sip:91894959XXXX@10.53.179.34:5060;transport=UDP>
Allow: INVITE,CANCEL,ACK,BYE,OPTIONS,INFO,PRACK,UPDATE,REFER,NOTIFY,SUBSCRIBE,PUBLISH,MESSAGE,REGISTER
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 176
Message Body
No. Time Source Destination Protocol Length Info
2 0.501176 10.53.179.34 10.54.28.114 SIP/SDP 1031 Request: INVITE sip:XX34300@10.54.28.114:5060;transport=UDP |
Frame 2: 1031 bytes on wire (8248 bits), 1031 bytes captured (8248 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.53.179.34, Dst: 10.54.28.114
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:XX34300@10.54.28.114:5060;transport=UDP SIP/2.0
Message Header
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.54.28.114:5060;transport=UDP>
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 INVITE
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-1f4dea1e-aa88-29a258a-7f6d3c334cc0
Route: <sip:10.54.28.114:5060;transport=UDP;lr>
X-SessionId: -1441910912
User-Agent: BN4000-3.8.3-042
Supported: timer,100rel
Max-Forwards: 68
Contact: <sip:91894959XXXX@10.53.179.34:5060;transport=UDP>
Allow: INVITE,CANCEL,ACK,BYE,OPTIONS,INFO,PRACK,UPDATE,REFER,NOTIFY,SUBSCRIBE,PUBLISH,MESSAGE,REGISTER
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 176
Message Body
No. Time Source Destination Protocol Length Info
3 0.661854 10.54.28.114 10.53.179.34 SIP 685 Status: 100 Trying |
Frame 3: 685 bytes on wire (5480 bits), 685 bytes captured (5480 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.54.28.114, Dst: 10.53.179.34
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (100)
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-1f4dea1e-aa88-29a258a-7f6d3c334cc0;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.54.28.114:5060;transport=UDP>
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:XX34300@10.54.28.114:5060>
Content-Length: 0
No. Time Source Destination Protocol Length Info
4 0.661995 10.54.28.114 10.53.179.34 SIP 685 Status: 100 Trying |
Frame 4: 685 bytes on wire (5480 bits), 685 bytes captured (5480 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.54.28.114, Dst: 10.53.179.34
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (100)
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-1f4dea1e-aa88-29a258a-7f6d3c334cc0;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.54.28.114:5060;transport=UDP>
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:XX34300@10.54.28.114:5060>
Content-Length: 0
No. Time Source Destination Protocol Length Info
5 0.662163 10.54.28.114 10.53.179.34 SIP 701 Status: 180 Ringing |
Frame 5: 701 bytes on wire (5608 bits), 701 bytes captured (5608 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.54.28.114, Dst: 10.53.179.34
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (180)
Status-Line: SIP/2.0 180 Ringing
Message Header
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-1f4dea1e-aa88-29a258a-7f6d3c334cc0;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.54.28.114:5060;transport=UDP>;tag=as0544149f
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:XX34300@10.54.28.114:5060>
Content-Length: 0
No. Time Source Destination Protocol Length Info
6 2.663542 10.54.28.114 10.53.179.34 SIP/SDP 1053 Status: 200 OK (INVITE) |
Frame 6: 1053 bytes on wire (8424 bits), 1053 bytes captured (8424 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.54.28.114, Dst: 10.53.179.34
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-1f4dea1e-aa88-29a258a-7f6d3c334cc0;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.54.28.114:5060;transport=UDP>;tag=as0544149f
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:XX34300@10.54.28.114:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 308
Message Body
No. Time Source Destination Protocol Length Info
7 2.723185 10.53.179.34 10.54.28.114 SIP 550 Request: ACK sip:XX34300@10.54.28.114:5060 |
Frame 7: 550 bytes on wire (4400 bits), 550 bytes captured (4400 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.53.179.34, Dst: 10.54.28.114
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (ACK)
Request-Line: ACK sip:XX34300@10.54.28.114:5060 SIP/2.0
Message Header
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.162.202.206:5060;transport=UDP>;tag=as0544149f
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3383 ACK
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-15908f03-aa8b-29a3030-7f6d387e8a80
Max-Forwards: 70
Contact: <sip:91894959XXXX@10.53.179.34:5060;transport=UDP>
Content-Length: 0
No. Time Source Destination Protocol Length Info
8 34.728820 10.53.179.34 10.54.28.114 SIP 602 Request: BYE sip:XX34300@10.54.28.114:5060 |
Frame 8: 602 bytes on wire (4816 bits), 602 bytes captured (4816 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.53.179.34, Dst: 10.54.28.114
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (BYE)
Request-Line: BYE sip:XX34300@10.54.28.114:5060 SIP/2.0
Message Header
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.162.202.206:5060;transport=UDP>;tag=as0544149f
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3384 BYE
Route: <sip:10.54.28.114:5060;lr>
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-46801cb9-aaab-29aad34-7f6d38653040
Max-Forwards: 69
Reason: SIP;cause=503;text="Subsystem Id: PE Cause Code: PENoTreatmentFound"
Content-Length: 0
No. Time Source Destination Protocol Length Info
9 34.728975 10.54.28.114 10.53.179.34 SIP 616 Status: 200 OK (BYE) |
Frame 9: 616 bytes on wire (4928 bits), 616 bytes captured (4928 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.54.28.114, Dst: 10.53.179.34
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-46801cb9-aaab-29aad34-7f6d38653040;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1441910912-1-1671210138-2122592896
To: "731XX34370"<sip:731XX34370@10.162.202.206:5060;transport=UDP>;tag=as0544149f
Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759
[Generated Call-ID: 17fe9f73-13b75480-aa88-7f6d1284e4e8-ea04600e-13c4-759]
CSeq: 3384 BYE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
Note the Reason: SIP;cause=503;text="Subsystem Id: PE Cause Code: PENoTreatmentFound" Content-Length: 0 in the end.
This is an incoming call to Asterisk, so the To header is irrelevant, unless you explicitly look at it in the dialplan.
You haven’t provided the dialplan, or logs of its execution, but it looks like it prematurely answers the call (some people seem to have the misunderstanding that dialplans should start by answering the call!).
The call then fails after 32 seconds, which is typical of a SIP call that times out in the call setup, but there is no logging of such a SIP call. I assume that you missed that out.
Generally we prefer to have protocol logs from Asterisk, as we know the format, and can be sure that Asterisk was actually involved.
Strings from the free text part of the message to not appear to be present in the Asterisk, or PJProject source code, so may be passed through from the far side. Google returns no hits on penotreatmentfound and no good hits on “pe cause code”, so they seem to be poorly documented proprietary messages.
I’m wondering if your strange use of incoming in the title means you think the To header is passed through to the outgoing side. It isn’t. There may not even be a To header on the incoming side.
That’s odd! I’m sharing the dialplan and execution logs here too. The logs I had earlier shared was from PCAP trace from sngrep utility. I had converted the PCAP to plaintext with Wireshark and shared the plaintext
; EXTEN is always 6834300
; this hack gets the DID from SIP Header and uses it for routing
[Tata-Incoming]
exten => _68343XX,1,Ringing
same => n,Wait(5)
same => n,Set(ACTUALDID=${SIP_HEADER(To)})
same => n,Set(ACTUALDID=${CUT(ACTUALDID,@,1)})
same => n,Set(PDID=${CUT(ACTUALDID,:,2)})
same => n,Noop(Call received at PDID:${PDID} and Exten:${EXTEN} and ActualDid:${ACTUALDID})
same => n,Set(TATADID=${PDID:-7})
same => n,Noop(Call To header ${TATADID})
same => n,SipAddHeader(To: ${TATADID}@10.53.179.34:5060)
same => n,Goto(tata,${PDID},1)
[tata]
exten => _731683437X,1,Goto(hello-world,s,1)
exten => _731683438X,1,Goto(hello-world,s,1)
[hello-world]
exten => s,1,Answer()
same => n,Wait(1)
same => n,Playback(demo-congrats)
same => n,Playback(tt-weasels)
same => n,Hangup()
Here’s the execution logs from Asterisk with the packets as well,
<--- SIP read from UDP:10.53.179.34:5060 --->
INVITE sip:6834300@10.54.28.114:5060;transport=UDP SIP/2.0
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.54.28.114:5060;transport=UDP>
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11467 INVITE
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-54a7b477-27995-9aaefc8-7f6d2c031480
Route: <sip:10.54.28.114:5060;transport=UDP;lr>
X-SessionId: -1437835167
User-Agent: BN4000-3.8.3-042
Supported: timer,100rel
Max-Forwards: 68
Contact: <sip:91894959XXXX@10.53.179.34:5060;transport=UDP>
Allow: INVITE,CANCEL,ACK,BYE,OPTIONS,INFO,PRACK,UPDATE,REFER,NOTIFY,SUBSCRIBE,PUBLISH,MESSAGE,REGISTER
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 176
v=0
o=BN4000 1528 23208 IN IP4 10.53.179.34
s=-
c=IN IP4 10.53.179.34
t=0 0
m=audio 64688 RTP/AVP 8 0 18 97
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=ptime:20
<------------->
--- (17 headers 9 lines) ---
Sending to 10.53.179.34:5060 (no NAT)
Sending to 10.53.179.34:5060 (no NAT)
Using INVITE request as basis request - 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
Found peer 'tatatel' for '91894959XXXX' from 10.53.179.34:5060
== Using SIP RTP CoS mark 5
Got SDP version 23208 and unique parts [BN4000 1528 IN IP4 10.53.179.34]
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 18
Found RTP audio format 97
Found audio description format telephone-event for ID 97
Capabilities: us - (ulaw|alaw|g729), peer - audio=(ulaw|alaw|g729)/video=(nothing)/text=(nothing), combined - (ulaw|alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.53.179.34:64688
Looking for 6834300 in Tata-Incoming (domain 10.54.28.114)
sip_route_dump: route/path hop: <sip:91894959XXXX@10.53.179.34:5060;transport=UDP>
<--- Transmitting (no NAT) to 10.53.179.34:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-54a7b477-27995-9aaefc8-7f6d2c031480;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.54.28.114:5060;transport=UDP>
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11467 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:6834300@10.54.28.114:5060>
Content-Length: 0
<------------>
-- Executing [6834300@Tata-Incoming:1] Ringing("SIP/tatatel-0000004b", "") in new stack
<--- Transmitting (no NAT) to 10.53.179.34:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-54a7b477-27995-9aaefc8-7f6d2c031480;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.54.28.114:5060;transport=UDP>;tag=as0a9aff8f
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11467 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:6834300@10.54.28.114:5060>
Content-Length: 0
<------------>
-- Executing [6834300@Tata-Incoming:2] Wait("SIP/tatatel-0000004b", "5") in new stack
-- Executing [6834300@Tata-Incoming:3] Set("SIP/tatatel-0000004b", "ACTUALDID="7316834370"<sip:7316834370@10.54.28.114:5060;transport=UDP>") in new stack
-- Executing [6834300@Tata-Incoming:4] Set("SIP/tatatel-0000004b", "ACTUALDID="7316834370"<sip:7316834370") in new stack
-- Executing [6834300@Tata-Incoming:5] Set("SIP/tatatel-0000004b", "PDID=7316834370") in new stack
-- Executing [6834300@Tata-Incoming:6] NoOp("SIP/tatatel-0000004b", "Call received at PDID:7316834370 and Exten:6834300 and ActualDid:"7316834370"<sip:7316834370") in new stack
-- Executing [6834300@Tata-Incoming:7] Set("SIP/tatatel-0000004b", "TATADID=6834370") in new stack
-- Executing [6834300@Tata-Incoming:8] NoOp("SIP/tatatel-0000004b", "Call To header 6834370") in new stack
-- Executing [6834300@Tata-Incoming:9] SIPAddHeader("SIP/tatatel-0000004b", "To: 6834370@10.53.179.34:5060") in new stack
-- Executing [6834300@Tata-Incoming:10] Goto("SIP/tatatel-0000004b", "tata,7316834370,1") in new stack
-- Goto (tata,7316834370,1)
-- Executing [7316834370@tata:1] Goto("SIP/tatatel-0000004b", "hello-world,s,1") in new stack
-- Goto (hello-world,s,1)
-- Executing [s@hello-world:1] Answer("SIP/tatatel-0000004b", "") in new stack
Audio is at 11004
Adding codec ulaw to SDP
Adding codec alaw to SDP
Adding codec g729 to SDP
Adding non-codec 0x1 (telephone-event) to SDP
<--- Reliably Transmitting (no NAT) to 10.53.179.34:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-54a7b477-27995-9aaefc8-7f6d2c031480;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.54.28.114:5060;transport=UDP>;tag=as0a9aff8f
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11467 INVITE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:6834300@10.54.28.114:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 308
v=0
o=root 1316820684 1316820684 IN IP4 10.54.28.114
s=Asterisk PBX 16.29.1
c=IN IP4 10.54.28.114
t=0 0
m=audio 11004 RTP/AVP 0 8 18 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-16
a=maxptime:150
a=sendrecv
<------------>
<--- SIP read from UDP:10.53.179.34:5060 --->
ACK sip:6834300@10.54.28.114:5060 SIP/2.0
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.162.202.206:5060;transport=UDP>;tag=as0a9aff8f
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11467 ACK
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-74a6093-2799a-9ab03ae-7f6d346e8740
Max-Forwards: 70
Contact: <sip:91894959XXXX@10.53.179.34:5060;transport=UDP>
Content-Length: 0
<------------->
--- (9 headers 0 lines) ---
-- Executing [s@hello-world:2] Wait("SIP/tatatel-0000004b", "1") in new stack
-- Executing [s@hello-world:3] Playback("SIP/tatatel-0000004b", "demo-congrats") in new stack
-- <SIP/tatatel-0000004b> Playing 'demo-congrats.gsm' (language 'en')
Really destroying SIP dialog '496986c364e54afa2c05927a2af0891d@10.53.179.34' Method: INVITE
Really destroying SIP dialog '75a5688d-4839b95b-27979-7f6d1b03c418-ea04600e-13c4-759' Method: ACK
-- Executing [s@hello-world:4] Playback("SIP/tatatel-0000004b", "tt-weasels") in new stack
-- <SIP/tatatel-0000004b> Playing 'tt-weasels.gsm' (language 'en')
<--- SIP read from UDP:10.53.179.34:5060 --->
BYE sip:6834300@10.54.28.114:5060 SIP/2.0
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.162.202.206:5060;transport=UDP>;tag=as0a9aff8f
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11468 BYE
Route: <sip:10.54.28.114:5060;lr>
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-56f28031-279ba-9ab80b3-7f6d2c361700
Max-Forwards: 69
Reason: SIP;cause=503;text="Subsystem Id: PE Cause Code: PENoTreatmentFound"
Content-Length: 0
<------------->
--- (10 headers 0 lines) ---
Sending to 10.53.179.34:5060 (no NAT)
Scheduling destruction of SIP dialog '2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759' in 32000 ms (Method: BYE)
<--- Transmitting (no NAT) to 10.53.179.34:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.53.179.34:5060;branch=z9hG4bK-56f28031-279ba-9ab80b3-7f6d2c361700;received=10.53.179.34
From: "91894959XXXX"<sip:91894959XXXX@10.53.179.34:5060;transport=UDP>;tag=BN-1437835167-1-1671328679-1574808082
To: "7316834370"<sip:7316834370@10.162.202.206:5060;transport=UDP>;tag=as0a9aff8f
Call-ID: 2d76b74b-774a2441-27995-7f6d11ba1240-ea04600e-13c4-759
CSeq: 11468 BYE
Server: Asterisk PBX 16.29.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
<------------>
I’m wondering if your strange use of incoming in the title means you think the To header is passed through to the outgoing side. It isn’t. There may not even be a To header on the incoming side.
That was a misunderstanding from my communication with that support team. They asked me to modify the To Header for specific requests – I didn’t realize they had highlighted this in the INVITE request which Tata is sending me!
The core problem I’m having is that all calls are not answered for Callee even when they’re handled by Asterisk. It is a sporadic issue and some calls also work perfectly fine beyond ~30s I assumed that the call setup should also be ok.
I was not aware of this. Can you please point out how did you arrive at this conclusion? I read the Answer() documentation on Asterisk Wiki and it simply mentions that its a good idea to answer a call before Playback()
As for chan_sip that some of you have pointed out is at its end of life. I’m forced to use it currently because I plan to also connect to a SIP Trunk Provider who uses tel URIs. Although tel URIs are not officially supported in either chan_sip or PJSIP, but it still manages to work in chan_sip. Link to a previous discussion about this.
I didn’t realise there was no outgoing leg, and got mixed up as to who sent the BYE.
This is nothing at all to do with To headers.
It may be something to do with the lack of media. You should look to see what you have configured as a timing source for Asterisk, as, as a last resort Asterisk will rely on the incoming media, although I thought the current defaults avoided this problem.
Their diagnostic message is not helpful, as google doesn’t recognize any of the text.
It could even be a policy thing at Tata; maybe they cut off the call if there is no incoming media.
You do need to answer here but the Playback does that. The Answer may still be useful because of the delay for things to set up.
Current versions of Asterisk do support TEL: to the level needed for typical providers. This was added in the last few months.
Another thought is that the weasels recording may have spoofed a signalling tone.
I found that my server was set to a different timezone and I have now changed the system timezone to Asia/Calcutta. Here’s my rtp.conf, I had to disable strict RTP for some reason because I couldn’t hear the audio on the call when it was enabled.
[general]
rtpstart=10000
rtpend=20000
strictrtp=no
[ice_host_candidates]
The IPtables looks like this – double checked to make sure I’m not dropping any packets on RTP ports,
-A INPUT -p udp -m udp --dport 6060 -j ACCEPT
-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5060 -j ACCEPT
I just looked at the complete tcpdump trace of successful (callee can hear audio) and unsuccessful (not answered for callee and they can’t hear audio) calls and noticed the following,
sip reload have a high chance of being successfulsip:7316834370@10.162.202.206:5060;transport=UDP that IP is neither Tata SBC or my IP address.Here’s the link to the PCAP traces for both calls: Asterisk-Dec2022 - Google Drive
Whilst only the tag really matters, that doesn’t sound at all right.
I can’t think of any reason, under the control of Asterisk, why you are sometimes not receiving media, but note that Asterisk is taking far too long to respond with Trying ,which makes me think you have a problem with your DNS,
Wouldn’t my usage of IP Addresses here skip the DNS lookup? My server is connected to the Tata SBC over a private network. I’ve setup the following routes for the private network,
default via 10.54.28.113 dev enp4s0 proto static metric 101
10.53.179.34 via 10.54.28.113 dev enp4s0
10.54.28.112/30 dev enp4s0 proto kernel scope link src 10.54.28.114 metric 101
I think Asterisk will still try to reverse resolve the addresses, so you would want, at least, /etc/hosts entries.
Hi David, thank you so much for your help here. My asterisk settings seem to be alright, it was Tata’s SBC that was misconfigured. The issues have now been resolved – no header manipulation was needed
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.