On 5/10/12 11:50 PM, Aman Aggarwal wrote:
> 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.
I guess this depends on what you mean by "new stream".
From perspective of transport it is a new stream.
In some conceptual sense it may be the same stream.
IMO this is largely in the eye of the beholder, and it may not be
possible in all cases to know whether this is intended to be a change to
a stream or a new one.
For instance, a new o/a that merely changes the address or port of a
media stream might be a simple modification (e.g. due to address
expiration and replacement), or it might be due to a transfer of the the
other end of the call to another party (via 3pcc), which might be viewed
as a new stream.
Because you can't really tell the intent, you also had better not expect
to take differing actions depending on the intent.
Thanks,
Paul
> 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
