Summary: | ASTERISK-24569: user=phone is not added to From, Contact and Diversion header | ||
Reporter: | Mark Petersen (asterisk.org@zombie.dk) | Labels: | |
Date Opened: | 2014-12-01 03:46:57.000-0600 | Date Closed: | |
Priority: | Major | Regression? | |
Status: | Open/New | Components: | Channels/chan_sip/General |
Versions: | 11.14.1 13.18.4 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | cento 6.5 | Attachments: | ( 0) chan_sip.24569.2.patch |
Description: | the problem is that user=phone is not added to the From, Contact and Diversion header, but is correctly added to the INVITE and To header
This is a major problem as our Provider is switching to a new platform where they require these header, in order for os to set the outgoing CALLERID on our trunk {noformat} [general] usereqphone=yes {noformat} {noformat} Set(CALLERID(name)=77777777); Set(CALLERID(num)=88888888); Set(CALLERID(ANI-num)=99999999); Set(CALLERID(rdnis)=66666666); Dial(SIP/55555555@192.168.0.2); {noformat} {noformat} INVITE sip:55555555@192.168.0.1;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9hG4bK1b298676;rport From: "77777777" <sip:88888888@192.168.0.1>;tag=as14ad576b To: <sip:55555555@192.168.0.2;user=phone> Contact: <sip:88888888@192.168.0.1:5060> Call-ID: 566480180a198f053ee9ba1016c0aef8@192.168.0.1 CSeq: 102 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Diversion: <sip:66666666@192.168.0.1>;reason=unknown {noformat} | ||
Comments: | By: Matt Jordan (mjordan) 2014-12-02 13:43:42.613-0600 I don't think this is a bug. Asterisk is not a telephone. Hence, it placing the {{user=phone}} specifier in the SIP URI for the mentioned fields would be incorrect. The fact that your provider wants to pretend like Asterisk is a telephone is a limitation of your provider. Someone may want to add this functionality as an improvement (and it would have to be configurable, as - again - Asterisk is not necessarily providing telephone numbers here in the mentioned headers). That being said, without a patch, I don't think this issue will remain open. By: Rusty Newton (rnewton) 2014-12-03 17:40:04.933-0600 Yup I don't see how this is a bug. Closing out as "Not a Bug". If someone decides to write a feature for this then they should open a new issue. By: Mark Petersen (asterisk.org@zombie.dk) 2014-12-04 02:47:02.452-0600 Hmm I do not agree as asterisk already has an option to add the user=phone it is just not doing it on all the required headers ;usereqphone = no ; If yes, ";user=phone" is added to uri that contains a valid phone number just because my provide require it, and they are annoying, do not mean that it is not a bug user=phone is well described in RFC3261 & RFC3666 for how to interact with the PSTN world witch asterisk has implement with the sip setting usereqphone that you are not going to fix it without someone providing a patch, is a different thing, and I'm working on getting that done but the first step is to report the bug, so others know that it exist http://tools.ietf.org/html/rfc3261 http://tools.ietf.org/html/rfc3666 http://tools.ietf.org/html/rfc4967 By: Matt Jordan (mjordan) 2014-12-04 09:26:11.374-0600 The RFCs aren't super explicit about the usage of {{user=phone}}, and certainly don't mandate its usage. The fact that your provider is requiring it is ... odd. That being said, after talking with a few other folks, if the user portion of a SIP URI is *known* to map to a PSTN DID, then you can certainly include {{user=phone}}. I'm not sure how you're going to be able to make this determination for all of the fields you mention, but if you have a patch in mind, we can certainly entertain it. Re-opening. By: Mark Petersen (asterisk.org@zombie.dk) 2014-12-04 16:15:21.111-0600 Thanks yes I'm working with the provider to remove that requirement but as they are switching to a new huawei platform for their transition to VoLTE, where the new platform require that we send this option they are not very forthcoming in recognizing that what they do is not optimal my plan is to add a regx that will validate if it is a number {noformat} ^\+?[0-9a-dA-D*#]{1,15}$ {noformat} this will match the following * optional first special character + * the digits 0-9 * the special characters # and * * the DTMF digits A-D * number must be between 1 and 15 digits/char long, not including + I'm not sure where I should allow "-" and space in the number all the examples in the RFC's the SIP header newer uses them they are only used in the description like this: the phone number +1-415-767-6791 {noformat} <sip:+14157676791@example.com;user=phone> {noformat} By: Fazil (fas143) 2015-01-20 02:07:53.687-0600 Mark peterson: Am facing this same issue. Need user=phone in From header in invite. This is hardly requested by provider By: Mark Petersen (asterisk.org@zombie.dk) 2015-05-19 04:05:38.168-0500 patch that add missing urioptions to from headder By: Mark Petersen (asterisk.org@zombie.dk) 2015-05-19 04:25:55.408-0500 ups fixed a small bug, we will now generate the from header like this <sip:+14157676791@example.com;user=phone>;tag=23325dasd By: Fazil (fas143) 2015-05-19 11:13:42.386-0500 Thanks you Mark Petersen. I will try it on tomorrow and will update. By: Mark Petersen (asterisk.org@zombie.dk) 2015-05-20 06:10:05.646-0500 Patch is for Asterisk 11 By: Fazil (fas143) 2015-05-20 07:31:29.315-0500 Noted By: Fazil (fas143) 2015-05-21 03:02:41.511-0500 Excellent its working fine That provider also request for with Media Connection information These are sip debugs from their end server {noformat} ----------------------------------------------------------------------------Sip debugs from their end by an out going call from our asterisk server----------------------- === Session Description Protocol === Protocol Version : v=0 Session Owner/Creator and session identi : o=root 377537064 377537064 IN IP4 10.100.20.10 Session Name : s=Asterisk PBX 1.8.20.0 Session Connection Information : c=IN IP4 10.100.20.10 Time the session is active : t=0 0 Media Name : m=audio 14830 RTP/AVP 8 101 Media : audio Port : 14830 Protocol type : RTP/AVP Media Format : 8 = PCMA Media Format : 101 = dynamic Media Attribute : a=rtpmap:8 PCMA/8000 Media Attribute : a=rtpmap:101 telephone-event/8000 Media Attribute : a=fmtp:101 0-16 Media Attribute : a=ptime:20 Media Attribute : a=sendrecv ---------------------------------------------------Sip debugs from their end by an out going call from an server what they exepect----------------------- Protocol Version : v=0 Session Owner/Creator and session identi : o=CiscoSystemsSIP-GW-UserAgent 6070 8175 IN IP4 178.16.8.7 Session Name : s=SIP Call Session Connection Information : c=IN IP4 178.16.8.7 Time the session is active : t=0 0 Media Name : m=audio 32706 RTP/AVP 8 101 Media : audio Port : 32706 Protocol type : RTP/AVP Media Format : 8 = PCMA Media Format : 101 = dynamic Media Connection information : c=IN IP4 178.16.8.7 <- with Media Connection information Media Attribute : a=rtpmap:8 PCMA/8000 Media Attribute : a=rtpmap:101 telephone-event/8000 Media Attribute : a=fmtp:101 0-15 Media Attribute : a=ptime:20 ------------------------------------------------------------------------------------------------------------ {noformat} Sip debug from our server as follows {noformat} NVITE sip:0553625772@172.16.84.6;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.100.20.10:5060;branch=z9hG4bK3b61bdfd Max-Forwards: 70 From: <sip:576981000@10.100.20.10;user=phone>;tag=as2f333a3c To: <sip:0553625772@172.16.84.6;user=phone> Contact: <sip:576981000@10.100.20.10:5060> Call-ID: 65161339488954b43193f8562f8ac7d4@10.100.20.10:5060 CSeq: 102 INVITE User-Agent: FPBX-2.8.1(1.8.20.0) Date: Wed, 21 Jan 2015 09:32:12 GMT Session-Expires: 1800 Min-SE: 1800 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Allow-Events: telephone-event Content-Disposition: session;handling=required P-Asserted-Identity: <sip:576981000@10.100.20.10;user=phone> Content-Type: application/sdp Content-Length: 235 v=0 o=root 576210786 576210786 IN IP4 10.100.20.10 s=Asterisk PBX 1.8.20.0 c=IN IP4 10.100.20.10 t=0 0 m=audio 15996 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv {noformat} |