Summary:	ASTERISK-01387: SIP with videosupport _allways_ adds video to SDP
Reporter:	zond (zond)	Labels:
Date Opened:	2004-04-09 21:14:02	Date Closed:	2004-09-25 02:49:42
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ethereal_dumps.zip ( 1) sdp-offer-answer-video.txt
Description:	When connecting to an asterisk having videosupport=yes in the sip.conf with a UA without videosupport (like a Cisco IP PHONE for example), the Asterisk erroneously adds a videostream to the transaction in the 200 OK replies. This is not according to the RFC, as far as I know, and it breaks some mediaproxies that have a hard time connecting a different number of streams together (for example SERMediaProxy) ****** ADDITIONAL INFORMATION ****** Added are two ethereal-dumps, one with the traffic between the Asterisk gw and the SER with the mediaproxy, and the other between the SER and the UA.
Comments:	By: Mark Spencer (markster) 2004-04-09 22:20:57 Why not just turn off video support? By: Olle Johansson (oej) 2004-04-10 03:55:44 Can you solve this by adding disallow/allow commands that doesn't include video? By: zond (zond) 2004-04-10 06:29:53 Yes, we could turn off videosupport. But we sometimes want videosupport. I haven't tried using disallow/allow-commands - this would be painful, since we dont allways know what client a customer will be using (and we dont want to change the config every time they change). And honestly I feel that this is one part of the RFC (if I understand correctly and it is indeed non-RFC behaviour) that Asterisk should follow. By: Mark Spencer (markster) 2004-04-10 11:25:42 So far, nobody has been able to find where in any appropriate RFC text which supports that you cannot respond with codecs which were not in the original invite.  If you like, you can provide an RFC and a section number to support your theory and I'll be happy to look at it.  In any case, this won't help you in the case of Asterisk placing a call to your buggy UA's which are allegedly unable to handle the multiple media lines or us adding codecs which they do not support.  You might start with RFC3264 which is the "An Offer/Answer Model with the Session Description protocol".  Section 6.1, Unicast Streams says, among other things: "... the "m=" line MUST contain at least one media format the answerer is willing to rece from amongst those listed in there offer.  The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to receive." So unless you have something else, I think my intepretation holds water. By: Olle Johansson (oej) 2004-04-10 16:15:24 Zond, could you please tell me how this breaks stuff? If this means major products out there can't handle it, regardless if the RFC, we might have to have an optional config option for these. So, please add more info on which clients/media proxies, how they problem you have breaks them - is it impossible to set up a session or what happens? By: Mark Spencer (markster) 2004-04-10 19:50:08 We do have such an option, it's called "videosupport=no" or "videosupport=yes".  One thing that *is* mentioned specifically in RFC3264 is that we MUST have exactly the same number of "m=" lines in the answer as in the original offer, so if they do not give us an "m=" line for video then we MUST NOT give them an "m=" line for video in our offer, presumably.  I *believe* we do not send one if we receive an offer with no "m=" line, but it would be nice to know for sure.  Anybody should be able to test that and look at the dump, and if we do, I'd take a patch that makes us not do it. By: zond (zond) 2004-04-10 23:10:16 markster: As for you challenge for me to "provide an RFC and a section number", I am afraid you misunderstood me. I wasnt talking about * adding codecs, but about * adding a stream (an "m="-line) as you talk about in your latest post. Yes, * does indeed give the caller an "m="-line even if the caller does not give one in the INVITE. Look at my dumps if you please. oej: It used to break SERMediaProxy when a caller got a 200 OK with an extra stream, and the proxy couldnt connect 1 stream with 2 streams. I have now patched my own SERMediaProxy to survive this behaviour, and I believe that the people at ag-projects will add something similar after my having made them aware of the problem. I just thought it prudent to make the *-community aware of the problem, too. What happens is that SER doesnt use the proxy in those cases, which would break the traffic if both parts were behind fw. By: Olle Johansson (oej) 2004-04-23 14:19:30 Mark: In this trace, we do really add a video stream without being offered one, which breaks the RFC. Additionally, we're not adding a rtpmap for the video stream. We need a patch, I guess. By: Olle Johansson (oej) 2004-04-23 14:20:04 I added a text file with the two relevant SDP's from the packet trace provided by zond. By: Olle Johansson (oej) 2004-04-23 14:35:39 zond: I tried to repeat this, but couldn't. There's something I do not understand here... Please help me. Is this the picture: 1. A phone sends invite to asterisk - one media stream (cisco) 2. Asterisk calls to ???? 3. Asterisk gets reply from ??? 4. Asterisk sends 200 OK with two media streams back Or is this a call that Asterisk terminates into PSTN via PRI, meaning that there's no other SIP device on the other end. Do you still have this problem with latest CVS head? By: zond (zond) 2004-04-23 19:21:13 The call terminated via PRI into PSTN, yes. The only SIP-device was on the other end of SER. I do not know if the problem exists with CVS HEAD... I can try it out after the weekend if you want (we had this problem on our lab server, so I am uncommonly free to experiment with versions :) By: zond (zond) 2004-04-23 19:24:57 Clarification: 1. A phone (Cisco IP PHONE 7960) sends INVITE to SER 2. SER record-route's and statefully forwards it to * after having rewritten the SDP-header to use the SERMediaProxy 3. * replies with SIP-messages containing SDP-headers including an RTP-stream not mentioned in the initial INVITE 4. SER tries to rewrite the SDP-header to use the SERMediaProxy before forwarding back to the phone, but fails as there are to few RTP-streams registered in SERMediaProxy 5. SER forwards the reply to the phone without having rewritten the headers, and SERMediaProxy goes unused. By: Olle Johansson (oej) 2004-04-24 03:31:27 Thank you for your fast reply! Let's keep this on hold until you've been able to test. If there's an oppurtunity to test over the weekend, it would be very much appreciated since we're moving fast to clean out all the possible bugs. Ha en trevlig helg :-) /Olle By: zond (zond) 2004-04-24 05:52:23 Ok, I tried it with CVS HEAD now, and the problem doesnt exist! :D Sorry about all the fuzz, I should have tried this earlier :/ Very well, I guess we can consider this bug closed :D Detsamma, Olle! //Martin By: Mark Spencer (markster) 2004-04-24 11:54:27 I'm upgrading this to major since it's a significant SIP protocol violation. By: Mark Spencer (markster) 2004-04-24 12:00:28 Doh!  Well i didn't read far enough to see that it was a significant protocol violation that doesn't exist anymore.