Summary:	ASTERISK-25440: Asterisk does not use owner parameter in SDP breaking RFC3264
Reporter:	Carlos Oliva (coliva)	Labels:
Date Opened:	2015-10-01 04:51:19	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Channels/chan_sip/General
Versions:	1.8.25.0 13.4.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian 7.9	Attachments:	( 0) trazaDbg1.txt
Description:	When processing an SDP Asterisk seems to ignore owner username and session ID. Only is processing the Session Version to validate the SDP. The functionality problem can be partially workarounded using the parameter in sip.conf "ignoresdpversion=yes" but is still there. This is very clear in {{chan_sip.c}} line 9947 (process_sdp_o) where you can read: {noformat}        o_copy = ast_strdupa(o);        token = strsep(&o_copy, " ");  /* Skip username   */ and        token = strsep(&o_copy, " ");  /* Skip session-id */ {noformat} This is not a problem when we have only one media source but is a problem if we have more than one media stream from different sources, as each source is identified by different owner parameters. I tested it in 1.8.25 and 13.4.0 but looking at code all asterisk versions can be affected by this issue. This breaks the RFC 3264. Not taking in consideration the owner causes a mistake in Asterisk, which do a "session modification" (section 8) when should do a "initial offer" (section 5). As you can see in section 4 of RFC it is possible to have various initial offers. Asterisk is not taking it in consideration. A practical example to reproduce the issue: We are in a call with a media negotiated  by o=src1 1 and receive an on dialog invite from o=src1 2 with a=sendonly. Asterisk activates MOH, everything OK We receive another on dialog invite with o=src2 1 and other connection information. This is really another media channel, but Asterisk really thinks that is from the same source with an incorrect version number and don't do any changes in SDP and don't deactivate the MOH, but internally updates the o value of the sip channel to o=src2 1. The user still hears the MOH, I think the user should be hearing the media coming from o=src2 After it, asterisk receives another on dialog invite from 0=src2 2 with a=inactive. Asterisk mark the channel as inactive, the user still hears the MOH (now I think is right). Asterisk mark the channel as inactive because updated the owner from previous packet, and now thinks the version number is right. Later Asterisk receive another on dialog invite from O=src1 3 (the first source) with a=senrecv. As the last O asterisk had in the channel was O=src2 2 Asterisk ignore the SDP information, but internally updates the O to value O=src1 3. Asterisk have the media source marked as inactive but the other peer thinks that the channel is in sendrecv mode As I said previously this can be partially avoided using the parameter "ignoresdpversion=yes" You will never hear the media from src2 but can deactivate the MOH in the channel and resume the call. I have a PCAP with a demonstration of the issue. If one developer want it I can provide privately, as have some private information inside (dids, ip address, etc)
Comments:	By: Asterisk Team (asteriskteam) 2015-10-01 04:51:21.035-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2015-10-01 09:45:31.807-0500 bq. I have a PCAP with a demonstration of the issue. If one developer want it I can provide privately, as have some private information inside (dids, ip address, etc) Would it be possible for you to provide an Asterisk full log with debug, along with "sip set debug on" output inline? That way you should be able to scrub out the private information. If you scrub the IPs at least make them unique rather than X.X.X.X so we know what is going where. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Be sure to include all the logger channel types describe on the wiki page , especially VERBOSE and DEBUG with both turned up to 5. Thanks! By: Carlos Oliva (coliva) 2015-10-02 05:47:09.817-0500 Hi Rusty! thanks four your response. I Attach what you asked for. we have a very complex dialplan with lot of querys, I tried to scrub all private information. Here are a interesting lines list of attached file: the call starts at line 1003 and interesting part (On hold) at lines: First invite (sendonly) line 4860, 200 OK at line 5003 Second Invite (open 2nd channel with diferent owner) line 5089, 200 OK at line 5244 third Invite (put 2nd channel inactive) line 5526, 200OK at line 5684 Four Invite (put 1st channel in sendrecv mode) line 5770, 200 OK at line 5875 Very interesting the line 5843 that says: [Oct  2 10:05:55] DEBUG[29776] chan_sip.c: Call 38628e0a1800c9e863eb2d07015f51f1@17.16.8.79:5060 responded to our reinvite without changing SDP version; ignoring SDP. Thanks for your help By: Carlos Oliva (coliva) 2015-10-02 05:49:19.691-0500 Requested full debug of the issue By: Matt Jordan (mjordan) 2015-10-16 18:50:45.816-0500 This is likely to go way beyond the SDP. Asterisk ignores the owner parameter in the SDP because it has no practical way of representing multiple media streams internally. Since the media core has no concept of streams, and only has a single pipeline of frames - AUDIO or VIDEO - I'm not sure what fixing this issue is going to help you with. What do you actually expect to happen if we do understand that a second stream is being negotiated? Asterisk will not represent two audio or two video streams correctly, and that's not a bug - that's just a limitation of the current internal architecture. By: Carlos Oliva (coliva) 2015-11-24 04:30:10.573-0600 Sorry for the huge delay answering. The main issue is not that Asterisk can not represent multiple audio media streams. The problem is that asterisk can not distinguish the second media stream is a new media stream, not is an update of the current. This can cause a problem in the call. In the case Asterisk receives a second media offer with other owner, it may accept or may reject the offer according to the RFC. Asterisk can reject the initial offer of the second media stream because can not represent more than one audio stream, but never should mix the data of two media streams thinking is the same. In the example attached (Is a real example against a Nortel SBC)  Asterisk is updating the version of the SDP with the value of the second channel opened and it shouldn't. This is because is not taking in consideration the owner. This causes that after the second audio channel is cancelled, Asterisk can not recover the first media stream because the version is "incorrect" (was updated from the version of the second media stream) and the call will stay on hold until hangup. By: Private Name (falves11) 2017-04-17 13:13:32.764-0500 I need to add a comment here. We need a setting ignoredspversion=1 for PJSIP. This setting makes the old SIP channels work with Cisco and Broadsoft endpoints, which as of today are a huge part of the SIP trunking market on the US. Namely: Verizon, Comcast, ATT, etc. PJSIP is not able to interop with those switches, if they change media source after a connect. I had to go back and rewrite my app in old SIP. If you look in JIRA, there are many old cases where this is well documented. Years ago the developers fixed it for the old SIP channel but they forgot to do the same for the new PJSIP technology.