I’ve been knocking my head against a wall for the last 48 hours trying to figure out why my FREEPBX and PBXACT servers fail to update the 200ok it sends to the UAC with the called party number received from the UAS.
The PBX servers are functioning is simply routing a call received from (UAC) /PJSIP trunk “A” via an in-bound route to PJSIP trunk “B” to the (UAS).
call flow & call trace/capture below
Srvr A - 172.36.4.25 -> PBX Srvr B - 172.44.25.4 -> Srvr C-172.36.4.26
I changed the following characters in order to post the call trace :
< changed to ( > changed to ) and @ changed to (+)
o. Time Source Destination Protocol Length Info
27190 1270.882814 172.36.4.25 172.44.25.4 SIP/SDP 764 Request: INVITE sip:2675559999(+)172.44.25.4;user=phone |
Frame 27190: 764 bytes on wire (6112 bits), 764 bytes captured (6112 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.36.4.25, Dst: 172.44.25.4
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:2675559999(+)172.44.25.4;user=phone SIP/2.0
Method: INVITE
Request-URI: sip:2675559999(+)172.44.25.4;user=phone
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 172.36.4.25:5160;branch=z9hG4bK-17783-1-0
From: “sipp Test” (sip:8152672677(+)172.44.25.4:5160);tag=1
To: “sut” (sip:2675559999(+)172.44.25.4;user=phone)
Contact: sip:8152672677(+)172.36.4.25:5160
Call-ID: 1-17783(+)172.36.4.25
[Generated Call-ID: 1-17783(+)172.36.4.25]
CSeq: 1 INVITE
Max-Forwards: 70
Content-Type: application/sdp
Supported: replaces
User-Agent: Apex Communications 1.0
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, NOTIFY, INFO, UPDATE, REFER
Content-Length: 220
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): user1 53655765 2353687637 IN IP4 172.36.4.25
Session Name (s): -
Connection Information ©: IN IP4 172.36.4.25
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 6000 RTP/AVP 18 101
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): sendrecv
[Generated Call-ID: 1-17783(+)172.36.4.25]
No. Time Source Destination Protocol Length Info
27194 1271.112066 172.44.25.4 172.36.4.25 SIP 352 Status: 100 Trying |
Frame 27194: 352 bytes on wire (2816 bits), 352 bytes captured (2816 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.44.25.4, Dst: 172.36.4.25
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (100)
Status-Line: SIP/2.0 100 Trying
Status-Code: 100
[Resent Packet: False]
[Request Frame: 27190]
[Response Time (ms): 229]
Message Header
Via: SIP/2.0/UDP 172.36.4.25:5160;rport=5160;received=172.36.4.25;branch=z9hG4bK-17783-1-0
Call-ID: 1-17783(+)172.36.4.25
[Generated Call-ID: 1-17783(+)172.36.4.25]
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=1
To: “sut” (sip:2675559999(+)172.44.25.4;user=phone)
CSeq: 1 INVITE
Server: PBXact-15.0.17.9(16.13.0)
Content-Length: 0
No. Time Source Destination Protocol Length Info
27582 1272.866638 172.44.25.4 172.36.4.26 SIP/SDP 986 Request: INVITE sip:2675559999(+)172.36.4.26:5160 |
Frame 27582: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.44.25.4, Dst: 172.36.4.26
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:2675559999(+)172.36.4.26:5160 SIP/2.0
Method: INVITE
Request-URI: sip:2675559999(+)172.36.4.26:5160
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 172.44.25.4:5160;rport;branch=z9hG4bKPj4af25a00-c936-4791-82fd-85795a75e6c1
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=01006a2e-b109-4357-b9d2-4caf81262ef9
To: (sip:2675559999(+)172.36.4.26)
Contact: (sip:asterisk(+)172.44.25.4:5160)
Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
CSeq: 23144 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: PBXact-15.0.17.9(16.13.0)
Content-Type: application/sdp
Content-Length: 274
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 353216608 353216608 IN IP4 172.44.25.4
Session Name (s): Asterisk
Connection Information ©: IN IP4 172.44.25.4
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 15198 RTP/AVP 18 0 101
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): ptime:20
Media Attribute (a): maxptime:150
Media Attribute (a): sendrecv
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
No. Time Source Destination Protocol Length Info
27611 1272.869557 172.36.4.26 172.44.25.4 SIP 367 Status: 100 Trying |
Frame 27611: 367 bytes on wire (2936 bits), 367 bytes captured (2936 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.36.4.26, Dst: 172.44.25.4
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (100)
Status-Line: SIP/2.0 100 Trying
Status-Code: 100
[Resent Packet: False]
[Request Frame: 27582]
[Response Time (ms): 2]
Message Header
Via: SIP/2.0/UDP 172.44.25.4:5160;rport;branch=z9hG4bKPj4af25a00-c936-4791-82fd-85795a75e6c1
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=01006a2e-b109-4357-b9d2-4caf81262ef9
To: (sip:2675559999(+)172.36.4.26);tag=4
Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
CSeq: 23144 INVITE
Content-Length: 0
No. Time Source Destination Protocol Length Info
27612 1272.872600 172.36.4.26 172.44.25.4 SIP 391 Status: 180 Ringing |
Frame 27612: 391 bytes on wire (3128 bits), 391 bytes captured (3128 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.36.4.26, Dst: 172.44.25.4
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (180)
Status-Line: SIP/2.0 180 Ringing
Status-Code: 180
[Resent Packet: False]
[Request Frame: 27582]
[Response Time (ms): 5]
Message Header
Via: SIP/2.0/UDP 172.44.25.4:5160;rport;branch=z9hG4bKPj4af25a00-c936-4791-82fd-85795a75e6c1
Contact: (sip:2675559999(+)172.36.4.26:5160)
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=01006a2e-b109-4357-b9d2-4caf81262ef9
To: (sip:2675559999(+)172.36.4.26);tag=4
Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
CSeq: 23144 INVITE
No. Time Source Destination Protocol Length Info
27613 1272.872650 172.36.4.26 172.44.25.4 SIP/SDP 719 Status: 200 OK |
Frame 27613: 719 bytes on wire (5752 bits), 719 bytes captured (5752 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.36.4.26, Dst: 172.44.25.4
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 27582]
[Response Time (ms): 6]
Message Header
Via: SIP/2.0/UDP 172.44.25.4:5160;rport;branch=z9hG4bKPj4af25a00-c936-4791-82fd-85795a75e6c1
Contact: (sip:2675559999(+)172.36.4.26:5160)
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=01006a2e-b109-4357-b9d2-4caf81262ef9
To: (sip:2675559999(+)172.36.4.26);tag=4
Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
CSeq: 23144 INVITE
Content-Type: application/sdp
Supported: replaces
User-Agent: Apex Communications 1.5
Content-Length: 221
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): user2 45365576 4235368763 IN IP4 172.36.4.26
Session Name (s): -
Connection Information ©: IN IP4 172.36.4.26
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 6012 RTP/AVP 18 101
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=yes
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): sendrecv
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
No. Time Source Destination Protocol Length Info
27614 1272.876360 172.44.25.4 172.36.4.26 SIP 445 Request: ACK sip:2675559999(+)172.36.4.26:5160 |
Frame 27614: 445 bytes on wire (3560 bits), 445 bytes captured (3560 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.44.25.4, Dst: 172.36.4.26
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (ACK)
Request-Line: ACK sip:2675559999(+)172.36.4.26:5160 SIP/2.0
Method: ACK
Request-URI: sip:2675559999(+)172.36.4.26:5160
[Resent Packet: False]
[Request Frame: 27582]
[Response Time (ms): 9]
Message Header
Via: SIP/2.0/UDP 172.44.25.4:5160;rport;branch=z9hG4bKPjab34f4d8-351e-48e5-b1db-0d5d3b91bbb8
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=01006a2e-b109-4357-b9d2-4caf81262ef9
To: (sip:2675559999(+)172.36.4.26);tag=4
Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080
[Generated Call-ID: 797c3069-843a-4f2c-9c4b-4ad3ce8d6080]
CSeq: 23144 ACK
Max-Forwards: 70
User-Agent: PBXact-15.0.17.9(16.13.0)
Content-Length: 0
No. Time Source Destination Protocol Length Info
27617 1272.881314 172.44.25.4 172.36.4.25 SIP 535 Status: 180 Ringing |
Frame 27617: 535 bytes on wire (4280 bits), 535 bytes captured (4280 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.44.25.4, Dst: 172.36.4.25
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (180)
Status-Line: SIP/2.0 180 Ringing
Status-Code: 180
[Resent Packet: False]
[Request Frame: 27190]
[Response Time (ms): 1999]
Message Header
Via: SIP/2.0/UDP 172.36.4.25:5160;rport=5160;received=172.36.4.25;branch=z9hG4bK-17783-1-0
Call-ID: 1-17783(+)172.36.4.25
[Generated Call-ID: 1-17783(+)172.36.4.25]
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=1
To: “sut” (sip:2675559999(+)172.44.25.4;user=phone);tag=10f6f70a-880a-49a0-bce9-ca80293db0f9
CSeq: 1 INVITE
Server: PBXact-15.0.17.9(16.13.0)
Contact: (sip:172.44.25.4:5160)
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Content-Length: 0
No. Time Source Destination Protocol Length Info
27618 1272.882181 172.44.25.4 172.36.4.25 SIP/SDP 862 Status: 200 OK |
Frame 27618: 862 bytes on wire (6896 bits), 862 bytes captured (6896 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.44.25.4, Dst: 172.36.4.25
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 27190]
[Response Time (ms): 2000]
Message Header
Via: SIP/2.0/UDP 172.36.4.25:5160;rport=5160;received=172.36.4.25;branch=z9hG4bK-17783-1-0
Call-ID: 1-17783(+)172.36.4.25
[Generated Call-ID: 1-17783(+)172.36.4.25]
From: “sipp Test” (sip:8152672677(+)172.44.25.4);tag=1
To: “sut” (sip:2675559999(+)172.44.25.4;user=phone);tag=10f6f70a-880a-49a0-bce9-ca80293db0f9
CSeq: 1 INVITE
Server: PBXact-15.0.17.9(16.13.0)
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: (sip:172.44.25.4:5160)
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 250
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 53655765 2353687639 IN IP4 172.44.25.4
Session Name (s): Asterisk
Connection Information ©: IN IP4 172.44.25.4
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 17196 RTP/AVP 18 101
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): ptime:20
Media Attribute (a): maxptime:230
Media Attribute (a): sendrecv
[Generated Call-ID: 1-17783(+)172.36.4.25]
No. Time Source Destination Protocol Length Info
27638 1272.892034 172.36.4.25 172.44.25.4 SIP 403 Request: ACK sip:2675559999(+)172.44.25.4:5160 |
Frame 27638: 403 bytes on wire (3224 bits), 403 bytes captured (3224 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.36.4.25, Dst: 172.44.25.4
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (ACK)
Request-Line: ACK sip:2675559999(+)172.44.25.4:5160 SIP/2.0
Method: ACK
Request-URI: sip:2675559999(+)172.44.25.4:5160
[Resent Packet: False]
[Request Frame: 27190]
[Response Time (ms): 2009]
Message Header
Via: SIP/2.0/UDP 172.36.4.25:5160;branch=z9hG4bK-17783-1-5
Contact: sip:8152672677(+)172.36.4.25:5160
From: “sipp Test” (sip:8152672672(+)172.44.25.4:5160);tag=1
To: “sut” (sip:2675559999(+)172.44.25.4:5160);tag=10f6f70a-880a-49a0-bce9-ca80293db0f9
Call-ID: 1-17783(+)172.36.4.25
[Generated Call-ID: 1-17783(+)172.36.4.25]
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
No. Time Source Destination Protocol Length Info
27639 1272.892090 172.36.4.25 172.44.25.4 SIP 408 Request: BYE sip:2675559999(+)172.44.25.4:5160 |
Frame 27639: 408 bytes on wire (3264 bits), 408 bytes captured (3264 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.36.4.25, Dst: 172.44.25.4
User Datagram Protocol, Src Port: 5160, Dst Port: 5160
Session Initiation Protocol (BYE)
Request-Line: BYE sip:2675559999(+)172.44.25.4:5160 SIP/2.0
Method: BYE
Request-URI: sip:2675559999(+)172.44.25.4:5160
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 172.36.4.25:5160;branch=z9hG4bK-17783-1-6
From: “sipp Test” (sip:8152672677(+)172.36.4.25:5160);tag=1
To: “sut” (sip:2675559999(+)172.44.25.4:172.44.25.4);tag=10f6f70a-880a-49a0-bce9-ca80293db0f9
Contact: sip:8152672677(+)172.36.4.25:5160
Call-ID: 1-17783(+)172.36.4.25
[Generated Call-ID: 1-17783(+)172.36.4.25]
CSeq: 1 BYE
Max-Forwards: 70
Content-Length: 0
Can you please explain the problem in more detail? AFAICT, server C at 172.36.4.26 did not send any indication that the call was forwarded or diverted, did not alter the To header and did not add any headers (Remote-Party-ID, P-Asserted-Identity, etc.) that would indicate an alternate destination. The PBX had no reason not to believe that the call was delivered to 2675559999 (which was where server A asked to send it) so there is nothing to update.
One obvious problem is the unreplied BYEs at the end. However, the trace stops after the first one, so there is no info to help troubleshoot.
Finally, why are you using G.729? Unless your bandwidth is very limited or expensive, there is no reason to take the quality degradation that this 24 year old codec entails.
Thanks Stewart1 ,
& my apologies for not explaining my problem in more thorough detail. So my problems are merely the "BYE"s that are forwarded to the PBX, which fails to reply with a 200ok and forward the “BYE” to the remote UAS.
This is because the PBX fails to update the 200 ok with the CDPN of the UAS. I’m simply beside myself trying to figure out why. I didn’t add the remaining BYE’s because they are simply retransmissions , also, I’m using a compressed CODEC due to BW limitations.
I can’t really understand what you’re meaning or what is going on. I think you’ve overloaded the thread with lots of finer details, without really explaining. What does “update the 200 ok with the CDPN of the UAS” mean? Which 200 ok are you referring? What are you expecting to see in the message that you aren’t? Provide the “pjsip set logger on”, trying to piece together from the text pcap output is not easy.
Thanks again to everyone for the assist but this is specifically what I mean
200 OK Contact Header sent by the UAS ( server “C’s” trunk to the PBX server -“B” )
Contact: (sip:[email protected]:5160) The 2675559999 uri = CalleD Party Number)
The PBX sends (sip:@172.44.25.4:5160) in the Contact header of the 200Ok instead of (sip:[email protected]:5160) to the UAC server “A”, which I believe is my problem.
The Contact header isn’t used for that, and Asterisk doesn’t touch it once the call is created internally. It is unlikely to be the problem. We’d really need an easier to consume view of things, specifically the “pjsip set logger on” I mentioned, to understand things further.
Hmm… in my working call traces, that URI is present (sip:2675559999@PBX IP : Port) and forwarded by the PBX to the UAC . I believe it tells the UAC to send any corresponding requests or responses to that URI at it’s domain/PBX IP: port ). I will check one last thing but if you can tell me how to activate the “pjsip set logger on” I’d greatly appreciate it.
Asterisk doesn’t forward packets, it’s not a SIP proxy. Each call is between Asterisk and the endpoint. This includes the user portion.
I can’t speak for FreePBX but in Asterisk you enter the Asterisk CLI and type “pjsip set logger on”. SIP packets then go to the console.
Comparing your traces to a working system, it’s server A that is malfunctioning. It should send the BYE to the same URI as Asterisk server B sent in the Contact header of the 200 OK.
What device or system is server A?
Thanks Joshua I’ll see if I can generate that log, I’m with you and in that sense both FreePBX and Asterisk function as B2BUAs, but with that said PBX still would use that URI in the contact header although it treats the dialogue to the UAC as a separate call correct? I do have working call traces to PBXact that depicts this.
Also I’m not arguing but am new to FreePBX/PBXact & am trying to obtain a better understanding if my logic is flawed.
Thanks Stewart1.
Although the BYE reflected in the trace reflects the 2675559999 URI , what i should have also mentioned is that even when the BYE generated from Server “A” reflects (@PBXact IP:port ) using SIPp, to match the Contact header in the 200ok, I still get the same result ( BYEs unanswered by PBX). I’ll add audio files to the call flow - in theory it shouldn’t have any bearing, and I’ll get the same result, but we’ll see. Thanks again for the assist
On my system, for Contact headers in the 200 OK response to INVITE, pjsip sends no user field, while chan_sip sends the user from the URI of the original INVITE.
Every client I have works with either, sending BYE to whatever URI is in the Contact header.
If server A is broken and doesn’t send to what was received in the Contact header, you may be able to work around the problem by using chan_sip.
AFAIK, sip:@1.2.3.4:5060 is not valid SIP at all. The user field must either be non-null or absent.
Please tell us the device or software that is server A.
Thanks Stewart I’m currently using SIPp (server A + C) . I recently migrated from chanSIP to PJSIP and I’m with you with sip:@x.x.x.x:5060 not being valid, but wanted to try it just to see what the PBX would do with it since it generated it.
So what’s crazy , is after 9 retransmissions - the PBX sends the 200ok to the UAC and forwards the BYE to the UAS , which makes no sense. I’ll generate those PJSIP logs and see if Joshua , you or anyone else might be able to shed some light on this.
Joshua & Stewart -
Thanks again for the assist & my apologies for taking your time. My scripts (UAC & UAS) had to be revised. All is well.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.