Summary: | ASTERISK-03558: [patch] Incorrect parsing of calling party ID when it is withheld | ||
Reporter: | buzzydex (buzzydex) | Labels: | |
Date Opened: | 2005-02-22 05:54:33.000-0600 | Date Closed: | 2008-01-15 15:41:59.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) sip_debug.txt ( 1) sip_from_parsing_rev3.diff.txt | |
Description: | This is a follow on from the previously closed bugnote ID 0002910. Calling party ID works fine if its available but when the ID has been withheld it shows the IP address of the SIP gateway. | ||
Comments: | By: Clod Patry (junky) 2005-02-22 06:25:00.000-0600 Please attach your sip.conf and a sip debug. Thanks By: buzzydex (buzzydex) 2005-02-22 07:10:21.000-0600 sip.conf [sip-in] type=peer host=somehost.net disallow=all allow=alaw allow=g729 insecure=yes context=incoming_number dtmfmode=inband Sip debug -- Executing Answer("SIP/123.123.123.123-4093fbb8", "") in new stack We're at 321.321.321.321 port 19652 Answering with preferred capability 0x8 (alaw) Answering with capability 0x100 (g729) Reliably Transmitting (no NAT): SIP/2.0 200 OK Via: SIP/2.0/UDP 123.123.123.123;branch=z9hG4bK5494.051e64b5.0 Via: SIP/2.0/UDP 123.123.123.123:5060 Record-Route: <sip:123.123.123.123;ftag=869F5CB4-219E;lr=on> From: "anonymous" <sip:123.123.123.123>;tag=869F5CB4-219E To: <sip:09978450043965@somesipgateway.net>;tag=as31f2eeb4 Call-ID: F1B68B92-840711D9-A542B54A-A9B6819A@123.123.123.123 CSeq: 101 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:08450043965@321.321.321.321> Content-Type: application/sdp Content-Length: 192 v=0 o=root 12310 12310 IN IP4 321.321.321.321 s=session c=IN IP4 321.321.321.321 t=0 0 m=audio 19652 RTP/AVP 8 18 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=silenceSupp:off We're at 321.321.321.321 port 19856 Answering with preferred capability 0x400 (ilbc) Answering with non-codec capability 0x1 (telephone-event) 12 headers, 10 linesg no Reliably Transmitting:no INVITE sip:user-1@192.1.1.1 SIP/2.0 Via: SIP/2.0/UDP 321.321.321.321:5060;branch=z9hG4bK507f82a0;rport From: "anonymous" <sip:123123123123@321.321.321.321>;tag=as0120d408 To: <sip:user-1@192.1.1.1> Contact: <sip:123123123123@321.321.321.321> Call-ID: 30c9b8e77df5191664e29e64333fe554@321.321.321.321 CSeq: 102 INVITE User-Agent: Asterisk PBX Date: Tue, 22 Feb 2005 12:56:12 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 224 edited on: 02-22-05 09:23 By: Kevin P. Fleming (kpfleming) 2005-02-22 09:07:00.000-0600 Your sip.conf does not have "trustrpid" set to "yes", so Asterisk should not even be looking for Remote-Party-ID headers. However, I think you mean "remote party ID" (generically), not that specific header. Your debug does not really show the results of this SIP traffic, it only shows a portion of the traffic. At what point are you seeing the IP address appear as the CLID? By: buzzydex (buzzydex) 2005-02-22 09:21:00.000-0600 I see the IP for a CLID on the phone as whenever the call comes through, maybe the following will help its from the other end. U 123.123.123.123:5060 -> 321.321.321.321:5060 INVITE sip:08450043965@321.321.321.321 SIP/2.0 Record-Route: <sip:123.123.123.123;ftag=864C1CF0-1C7E;lr=on> Via: SIP/2.0/UDP 123.123.123.123;branch=z9hG4bK3c25.7a0f6db7.0.. Via: SIP/2.0/UDP 123.123.123.123:5060.. From: "anonymous" <sip:123.123.123.123>;tag=864C1CF0-1C7E To: <sip:09978450043965@somehost.net> Date: Tue, 22 Feb 2005 11:25:08 gmt Call-ID: 3DC7F157-83FB11D9-8E2EB54A-A9B6819A@123.123.123.123 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 5 Remote-Party-ID: <sip:123.123.123.123>;party=calling;screen=yes;privacy=full Timestamp: 1109071508 Contact: <sip:123.123.123.123:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 347 edited on: 02-22-05 09:21 By: Kevin P. Fleming (kpfleming) 2005-02-22 10:02:58.000-0600 OK, I see what you are talking about, and yes, the From parsing in chan_sip is broken. Please try the attached patch to see if it solves your problem; it makes chan_sip not set the cid_num at all if it does not see an @ in the URI presented in the From header (which makes this parser RFC 3261 compliant). (and as usual, my disclaimer is on file) edited on: 02-22-05 10:03 By: Kevin P. Fleming (kpfleming) 2005-02-22 10:08:05.000-0600 In addition, I am nearly ready to post a patch that adds full Remote-Party-ID support to Asterisk (sending as well as receiving), and this will be most useful with people who are using Cisco gateways (since I know they support it fully as well). If you are interested, watch for the patch to appear here in Mantis in a few days and help out with the testing :-) By: Kevin P. Fleming (kpfleming) 2005-02-22 15:39:48.000-0600 rev2 uploaded, intended for HEAD only (rev1 can apply to stable as well) This is a much more aggressive patch, that actually creates structures and functions to do _complete_ RFC compliant parsing of the SIP URI and From/Remote-Party-ID headers (and all headers formatted the same way). Currently the new functions are only used in check_user_full, but if they are found to work properly they should be used everywhere in chan_sip, rather than having incomplete and/or inconsistent parsing as we have now. I have tested this with four different brands of SIP phones without trouble; none of them send Remote-Party-ID, though, so that part is untested. Someone with a Cisco gateway would be a perfect candidate to test this :-) By: Kevin P. Fleming (kpfleming) 2005-02-22 15:41:30.000-0600 Corrected summary and description, as this problem is not related to the Remote-Party-ID header. By: buzzydex (buzzydex) 2005-02-23 02:27:11.000-0600 Applying the patch gives me the following error patching file chan_sip.c Hunk #2 succeeded at 638 (offset -1 lines). Hunk #3 succeeded at 5728 (offset 5 lines). patch: **** malformed patch at line 282: *sin, int ignore, char *mailbox, int mailboxlen) I am not sure whether this means its changed chan_sip.c or not, I'm assuming it checks first before making any changes but can someone confirm this. By: Kevin P. Fleming (kpfleming) 2005-02-24 11:12:08.000-0600 Can someone with a working valgrind installation run the rev2 patch through it, please? I'm getting segfaults after only a few SIP calls, but valgrind doesn't work correctly on my test box and it will require a complete Linux reinstall to fix... Thanks. By: Kevin P. Fleming (kpfleming) 2005-03-11 10:11:31.000-0600 rev3 uploaded to match current CVS, and call for testers sent out to asterisk-dev list. By: drmac (drmac) 2005-03-15 14:38:12.000-0600 patch works fine here using Cisco 7960. By: Jon BrĂ¼el (jb) 2005-03-22 13:34:54.000-0600 May this bug also result fact that I get the clid asterisk@serveripaddress, when a call is transferred and in the fact that I cannot get the clid from Flash Operators Panel? By: Kevin P. Fleming (kpfleming) 2005-03-22 14:04:26.000-0600 Yes, it could be the cause of those problems. By: Michael Jerris (mikej) 2005-05-23 21:02:53 Kevin- Do you want to commit the original patch to this that solves the immediate issue of setting to the IP address if no @ is found in the from so we can close out this issue, and leave the full parsing to another patch and another day? By: savag3 (savag3) 2005-06-08 09:18:49 Is there any chance someone could commit the original patch to cvs or attach it to the bug because this bug is an issue for me and the current rev3 patch dosen't apply to current cvs head and also causes segfaults. By: darkskiez (darkskiez) 2005-07-19 03:15:07 The latest Cisco SIP firmware 7.5 (I believe) has Sending/Receiving Remote Party ID support to support updating the display with the ID of the connected party. By: hawk (hawk) 2005-07-19 08:15:29 Anyone has a patch for asterisk that makes use of the new functionality on the new cisco firmware you talk about? The 7960 is very widely used, so i guess a lot of people would like this ;-) By: Kevin P. Fleming (kpfleming) 2005-07-19 19:48:43 The original simple fix has been committed; the more extensive work will have to wait. By: Digium Subversion (svnbot) 2008-01-15 15:41:59.000-0600 Repository: asterisk Revision: 6169 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r6169 | kpfleming | 2008-01-15 15:41:59 -0600 (Tue, 15 Jan 2008) | 2 lines simple fix for bug ASTERISK-3558 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6169 |