Aman Arora wrote:
> hi Paul,
>
> As per the following sections of the RFC 3264, dated June 2002,
>
> Section 8: Modifying a Media Session
> If an SDP is offered, which is different from the previous SDP, the
> new SDP MUST have a matching media stream for each media stream in
> the previous SDP. In other words, if the previous SDP had N "m="
> lines, the new SDP MUST have at least N "m=" lines. The i-th media
> stream in the previous SDP, counting from the top, matches the i-th
> media stream in the new SDP, counting from the top. This matching is
> necessary in order for the answerer to determine which stream in the
> new SDP corresponds to a stream in the previous SDP.
The matching is just correspondence. There must be at least as many
m-lines in the new offer as in the old one. And they correspond in the
sense that the new m-line in the same ordinal position replaces the
previous one in the same position.
This does not say that the *content* of the m-line must match the
content of the prior one.
E.g. If you has one m-line with m=message that had established an MSRP
session, you could reinvite and offer one m=audio line instead if you
wanted to talk instead of IM.
> and Section 8.1, Adding a Media Stream
> New media streams are created by new additional media descriptions
> below the existing ones, or by reusing the "slot" used by an old
> media stream which had been disabled by setting its port to zero.
> Reusing its slot means that the new media description replaces the
> old one, but retains its positioning relative to other media
> descriptions in the SDP. New media descriptions MUST appear below
> any existing media sections.
>
> As per my understanding of these sections in the RFC, the restrictions
> seem to be in place. Can you please let me
> know another draft or RFC revision's where these restrictions seem to have
> been relaxed?
Its been that way for a long time. I think we have to look back to 2543
to find the more restrictive rules, that say you can't reuse an m-line
with a port of zero, and that you can't change the media field in an m-line.
Paul
> thanks
> aman
>
>
>
> Paul Kyzivat <[EMAIL PROTECTED]>
> 07/07/2006 12:57 AM
>
>
> To
> Rajnish Jain <[EMAIL PROTECTED]>
> cc
> Aman Arora/[EMAIL PROTECTED], [email protected], Amit
> Mahajan/[EMAIL PROTECTED], Pankaj Negi/[EMAIL PROTECTED], Amit Sharma/[EMAIL
> PROTECTED], Umang
> Singh/[EMAIL PROTECTED], Puneet Sharma/[EMAIL PROTECTED]
> Subject
> Re: [Sip-implementors] What should the new SDP be following
> arejectedoffer.
>
>
>
>
>
>
>
>
> Rajnish Jain wrote:
>> Aman,
>>
>> I can't find any restrictions in RFC 3264 where a new media stream (m4)
> has
>> to be of the same type in order to reuse a slot created by a previously
>> rejected media stream (m3).
>
> There is no such restriction. Once upon a time a rejected m-line could
> not be reused at all. And also once upon a time you were not permitted
> to change the media type in an m-line in a subsequent offer. Both of
> those restrictions were relaxed.
>
> Paul
>
>> I think it makes sense that RFC 3264 hasn't placed such a restriction.
>> Because this is simply about relative ordering of the m= lines not about
>> what media type they depict. This also makes sense from an efficiency
> and
>> message size point of view i.e. why carry empty slots back and forth if
> they
>> can be reused.
>>
>> Rajnish
>>
>> ________________________________
>>
>> From: Aman Arora
> [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, July 06, 2006 12:33 AM
>> To: Rajnish Jain
>> Cc: Amit Mahajan; Amit Sharma; Pankaj Negi; Puneet
> Sharma; Umang
>> Singh
>> Subject: Re: [Sip-implementors] What should the new SDP
> be following
>> arejectedoffer.
>>
>>
>>
>> hi Rajnish,
>>
>> Thanks for the answer. But I just wanted to know, will it
> be ok to
>> replace m4 with m3 even if the media types of the
>> two m lines are different? If this is the case then it
> would
>> contradict the RFC's requirement where it mentions that
>> the position of a m line in the SDP needs to be fixed.
>>
>> rgds
>> aman
>>
>>
>>
>> "Rajnish Jain" <[EMAIL PROTECTED]>
>> Sent by: [EMAIL PROTECTED]
>>
>> 07/05/2006 06:27 PM
>>
>>
>>
>> To
>> Aman Arora/[EMAIL PROTECTED],
> <[email protected]>
>> cc
>> Amit Mahajan/[EMAIL PROTECTED], Pankaj
> Negi/[EMAIL PROTECTED], Amit
>> Sharma/[EMAIL PROTECTED], Umang Singh/[EMAIL PROTECTED], Puneet
>> Sharma/[EMAIL PROTECTED]
>> Subject
>> Re: [Sip-implementors] What should the
> new SDP be following
>> arejectedoffer.
>>
>>
>>
>>
>>
>>
>> Aman,
>>
>> RFC 3264 states that SDP offer/answer exchange is atomic.
> It has a
>> binary
>> outcome. It either succeeds or fails. However, I think
> the answer to
>> your
>> question depends on how the modified offer is rejected.
> An offer can
>> be
>> rejected in two ways:
>>
>> 1. Answerer sends a 488
>> 2. Answerer sends a 200 but puts m3's port number as 0
>>
>> If it's a 488 and going by the atomic nature of the
> offer/answer
>> outcome, it
>> would seem like m3 need not be remembered by either
> parties. In that
>> case,
>> new offers in either direction can be m1, m2, m4.
>>
>> On the other hand, if it's a 200 with m3's port equal to
> 0, then m3
>> has
>> occupied a slot. In this case, new offers in either
> direction will
>> need to
>> be m1, m2, m3, m4. However, you also have the option of
> reusing m3's
>> slot
>> for m4, in which case it'll become m1, m2, m4.
>>
>> Therefore, m1, m2, m4 seems to be a safe bet in both
> cases of
>> rejection in
>> either direction.
>>
>>
>> Rajnish
>>
>>
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED]
>> > [mailto:[EMAIL PROTECTED] On
> Behalf
>> > Of Aman Arora
>> > Sent: Wednesday, July 05, 2006 7:34 AM
>> > To: [email protected]
>> > Cc: Amit Mahajan; Puneet Sharma; Aman Arora; Umang
> Singh;
>> > Pankaj Negi; Amit Sharma
>> > Subject: [Sip-implementors] What should the new SDP be
>> > following a rejectedoffer.
>> >
>> > hi,
>> >
>> > I have an established call, with the following m lines
> m1, m2
>> > between two users A and B.
>> > The call was initiated by A, i.e., the first offer in
> the
>> > request was sent by A and B sent the answer to this
> offer.
>> >
>> > Now mid-call a Re-Invite is received from B (new
> offer). The
>> > SDP in the new offer has the the following m lines m1,
> m2 and
>> > m3 (a new m line). A rejects this offer.
>> > Now if B sends
>> > another Re-Invite to A, what should the new offer
> contain m1,
>> > m2, m3 and
>> > m4 or
>> > m1, m2, m4 (since m3 was rejected).
>> >
>> > Also if B was to sent the second re-invite (instead of
> B),
>> > then what should the offer from A contain m1, m2, m3
> and m4
>> > or m1, m2, m4.
>> >
>> > Would appreciate any clarifications on this.
>> >
>> > rgds
>> > aman
>> >
>> > *********************** FSS- Confidential
>> ***********************
>> > _______________________________________________
>> > Sip-implementors mailing list
>> > [email protected]
>> >
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>> >
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>> *********************** FSS- Confidential
> ***********************
>> *********************** FSS- Confidential
> ***********************
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
>
> *********************** FSS- Confidential ***********************
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
