Hi, Section 8.3.3 talks change in media types. What about the other parameters of m-line such as port, transport or media-format. IMO, this fax stream is a new stream and must replace existing audio stream or must be below existing audio stream as per section 8.1 of RFC 3264.
regards, Aman Aggarwal Aricent -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat Sent: Friday, May 11, 2012 1:24 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] M line ordering in Re-invite SDP for Inter domain fax call On 5/10/12 2:52 PM, Worley, Dale R (Dale) wrote: >> From: kumar.ramad...@wipro.com [kumar.ramad...@wipro.com] >> >> v=0 >> o=- 200804293 1328781680 IN IP4 192.168.13.235 >> s=SDP Data >> c=IN IP4 192.168.13.235 >> t=0 0 >> m=image 51846 udptl t38 >> a=T38FaxRateManagement:transferredTCF >> a=T38FaxUdpEC:t38UDPRedundancy >> a=ecan:fb on - >> m=audio 49846 RTP/AVP 8 >> a=ptime:10 >> a=ecan:fb on - >> >> To my understanding of RFC 3264, the above SDP is not in-line with >> Section 8& 8.1, if the previously offered or answered SDP (exchanged >> during the basic call setup) contains only "audio" media type with >> same port number. Or is it still OK to send the "image" media line >> before the "audio" media line for the fax call scenarios? > > My belief was that such a change in a new SDP offer was not allowed. > But I looked at RFC 3264 section 8.3.3, and it says: > > The media type (audio, video, etc.) for a stream MAY be changed. It > is RECOMMENDED that the media type be changed (as opposed to adding a > new stream), when the same logical data is being conveyed, but just > in a different media format. This is particularly useful for > changing between voiceband fax and fax in a single stream, which are > both separate media types. To do this, the offerer creates a new > media description, with a new media type, in place of the description > in the previous SDP which is to be changed. > > So it is allowed to change a media stream in any way, it seems. > Within that rule, what is being done in your example is that the first > media stream is being changes from "audio" to "image" (fax), and a new > "audio" stream is being added. That is probably not the best way to > express what is desired, but it appears to be *valid*. > > About a week ago, I was examining the operation of a popular PSTN/SIP > gateway device, and it changes the one media stream from "audio" to > "image" when fax is detected. I thought that its behavior was > incorrect, but now I see that it is correct. I agree with what Dale says. Note that there is no semantic difference between - using one o/a to set the port in an m-line to zero, and then a second one to reuse the m-line for something else - using a single o/a to reuse an m-line for something else The latter is just an optimization. Its also far from clear that you can infer any particular relationship between the stream established by an m-line and the one established when the m-line is reused. The quote from 3264 doesn't help much because it only *recommends* reuse. As a result, the semantics of these cases are underspecified. Clearly the end doing the offer has something in mind. But it may be a faint hope that the other end will understand it the same way. If the first o/a established only a voice stream, and the second o/a establishes only a T.38 stream then there seems to be little alternative but to assume the intent is to use T.38 and hence fax. That's true whether the 2nd o/a has another m-line with port=0 or not, and regardless of whether the T.38 m-line is first or 2nd or something else. OTOH if the first o/a established only a voice stream, and the second o/a establishes both voice stream and a T.38 stream (both active), then it is far from clear what the answerer should assume. Probably best to avoid this case. Thanks, Paul _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
