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-0600Date Closed:2008-01-15 15:41:59.000-0600
Versions:Frequency of
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.

By: buzzydex (buzzydex) 2005-02-22 07:10:21.000-0600



Sip debug
   -- Executing Answer("SIP/", "") 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;branch=z9hG4bK5494.051e64b5.0
Via: SIP/2.0/UDP
Record-Route: <sip:;ftag=869F5CB4-219E;lr=on>
From: "anonymous" <sip:>;tag=869F5CB4-219E
To: <sip:09978450043965@somesipgateway.net>;tag=as31f2eeb4
Call-ID: F1B68B92-840711D9-A542B54A-A9B6819A@
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Contact: <sip:08450043965@321.321.321.321>
Content-Type: application/sdp
Content-Length: 192

o=root 12310 12310 IN IP4 321.321.321.321
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

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@ 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@>
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
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 -> 321.321.321.321:5060
INVITE sip:08450043965@321.321.321.321 SIP/2.0
Record-Route: <sip:;ftag=864C1CF0-1C7E;lr=on>
Via: SIP/2.0/UDP;branch=z9hG4bK3c25.7a0f6db7.0..
Via: SIP/2.0/UDP
From: "anonymous" <sip:>;tag=864C1CF0-1C7E
To: <sip:09978450043965@somehost.net>
Date: Tue, 22 Feb 2005 11:25:08 gmt
Call-ID: 3DC7F157-83FB11D9-8E2EB54A-A9B6819A@
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 5
Remote-Party-ID: <sip:>;party=calling;screen=yes;privacy=full
Timestamp: 1109071508
Contact: <sip:>
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