Summary: | ASTERISK-23791: PJSIP use UUID in Contact header when Dial | ||||
Reporter: | Dmitry Kamovsky (dkamovsky) | Labels: | |||
Date Opened: | 2014-05-27 00:45:41 | Date Closed: | 2014-07-08 18:43:47 | ||
Priority: | Major | Regression? | |||
Status: | Closed/Complete | Components: | Channels/chan_pjsip | ||
Versions: | 12.2.0 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | CentOS 6.5 | Attachments: | ( 0) ASTERISK-23791_full_log ( 1) ASTERISK-23791_full_log.txt ( 2) ps_endpoint_id_ips.txt ( 3) ps_endpoint_id_ips.txt ( 4) view_ps_aors.txt ( 5) view_ps_aors.txt ( 6) view_ps_endpoints.txt ( 7) view_ps_endpoints.txt | ||
Description: | pjsip use UUID in contact header of INVITE message. This leads to core crashing when I try to redirect call, because softphone sfl-phone doesn't understand contact header like {{<sip:uuid@server>}}. Could you tell me how can I transform Contact header to {{<sip:number@server>}} instead {{<sip:uuid@server>}}?
{code} INVITE sip:2302033@172.16.99.2 SIP/2.0 Record-Route: <sip:172.16.99.2;lr;ftag=2394a326f2575a8co0;did=2b3.3238d645> Via: SIP/2.0/UDP 172.16.99.2:5060;branch=z9hG4bK282f.b2f7cb54.0 Via: SIP/2.0/UDP 172.16.99.101:5064;branch=z9hG4bK-9113c249 From: "sip123456" <sip:sip123456@172.16.99.2>;tag=2394a326f2575a8co0 To: <sip:2302033@172.16.99.2> Call-ID: a8a2baae-de70e8a4@172.16.99.101 CSeq: 102 INVITE Max-Forwards: 69 *Contact: "sip123456" <sip:sip123456@172.16.99.101:5064>* Expires: 240 User-Agent: Linksys/SPA921-5.1.8 Content-Length: 399 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1958139 1958139 IN IP4 172.16.99.101 s=- c=IN IP4 172.16.99.101 t=0 0 m=audio 16450 RTP/AVP 8 0 2 4 18 96 97 98 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv <--- Transmitting SIP response (458 bytes) to UDP:172.16.99.2:5060 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP 172.16.99.2:5060;rport;received=172.16.99.2;branch=z9hG4bK282f.b2f7cb54.0 Via: SIP/2.0/UDP 172.16.99.101:5064;branch=z9hG4bK-9113c249 Record-Route: <sip:172.16.99.2;lr;ftag=2394a326f2575a8co0;did=2b3.3238d645> Call-ID: a8a2baae-de70e8a4@172.16.99.101 From: "sip123456" <sip:sip123456@172.16.99.2>;tag=2394a326f2575a8co0 To: <sip:2302033@172.16.99.2> CSeq: 102 INVITE Server: Asterisk PBX 12 Content-Length: 0 .......... -- Executing [2302033@outgoing:7] Set("PJSIP/sip123456-00000008", "CALLERID(num)=4232050001") in new stack -- Executing [2302033@outgoing:14] Dial("PJSIP/sip123456-00000008", "PJSIP/4232302033@opensips,60,TM(utm5^start^sip123456^7ca2bee8-a884-4cb1-a8ca-66a7c4136b3f^4232050001^4232302033)") in new stack <--- Transmitting SIP request (965 bytes) to UDP:172.16.99.2:5060 ---> INVITE sip:4232302033@172.16.99.2:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.99.9:5060;rport;branch=z9hG4bKPj65c4ed8a-35cd-4ee5-a9d2-ca5f6f7bf6eb From: "sip123456" <sip:4232050001@172.16.99.9>;tag=e8843033-1e78-44e9-bd3a-ec97c7a4dd25 To: <sip:4232302033@172.16.99.2> *Contact: <sip:310fc49d-b1a9-448b-b8bc-92530f07dd26@172.16.99.9:5060>* Call-ID: 012a4451-d3ba-45a7-96a1-5aa17c7cb89c CSeq: 9163 INVITE Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 70 User-Agent: Asterisk PBX 12 Content-Type: application/sdp Content-Length: 267 v=0 o=- 1570975488 1570975488 IN IP4 localhost.localdomain s=Asterisk c=IN IP4 172.16.99.9 t=0 0 m=audio 17522 RTP/AVP 8 101 c=IN IP4 172.16.99.9 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv {code} | ||||
Comments: | By: Matt Jordan (mjordan) 2014-05-27 09:03:29.938-0500 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information I'd like to make sure we have a complete understanding of the generation of the Contact header in this case. Please make sure you have {{pjsip set logger on}} in the log file. Please also attach your {{pjsip.conf}}. Thanks! By: Dmitry Kamovsky (dkamovsky) 2014-05-28 00:19:44.828-0500 I use realtime for pjsip. Current tables in attachments. Call flow: from external provider (via e1) to Softswitch Eltex SMG1016m - (via siptrunk) to OpenSIPS - (via siptrunk) to Asterisk (Asterisk change CallerID(num) from 423205XXX(city numbe) to internal username sipXXXXXX) - user sip phone. For branch smg1016m - Asterisk is set Contract header like <sip:ip-adress:5060>, for branch Asterisk - user is set Contact header like <sip:uuid@ip-adress:5060>. When I use chan_sip instad chan_pjsip Contact header is set correctly: <sip:username or number@ipadress:5060>. Hope you understand what I mean and sorry for my English. Thank you. By: Rusty Newton (rnewton) 2014-06-23 12:20:21.135-0500 Re-attaching reporters attachments, as they are not showing up on the issue. I'm not sure why. They do show up under history. By: Rusty Newton (rnewton) 2014-06-23 12:39:58.070-0500 [~dkamovsky] Can you attach the output of "pjsip show endpoint <name>" for the endpoints involved in the call flow? By: Rusty Newton (rnewton) 2014-06-23 13:19:53.966-0500 {quote} This leads to core crashing when I try to redirect call, because softphone sfl-phone doesn't understand contact header {quote} To make sure we understand you correctly. Are you saying that sfl-phone is crashing upon receiving the INVITE? Unless Asterisk is crashing, this looks like a feature request. As after talking with a few developers it appears that sending the UUID out in the user portion of the contact header is acceptable and expected behavior. By: Rusty Newton (rnewton) 2014-07-08 18:44:20.371-0500 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines Also, this doesn't appear to be a bug. |