You've quoted relevant text from RFC 3264 but you've not explained how
you're putting two and two together. You need to explain how you're reaching
to the understanding that you've developed. Perhaps, there is some confusing
text in the RFC. But clearly, there is no text in RFC 3264 that says that a
new media stream has to be of the same type in order to reuse an empty slot.
In 3264's philosophy, as it stands now, an empty slot is an empty slot
(period).
Since you've quoted the text relating to m= lines ordering, now I'm not sure
that if you are questioning that the concept of slot reuse itself is
contradictory to the basic m= line ordering mechanism?
Or, are you still questioning that a new media stream has to be of the same
type in order to reuse a slot created by a previously rejected media stream.
Rajnish
________________________________
From: Aman Arora [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006 2:59 AM
To: Paul Kyzivat
Cc: Amit Mahajan; Amit Sharma; Pankaj Negi; Puneet Sharma; Rajnish
Jain; [email protected]; Umang Singh
Subject: Re: [Sip-implementors] What should the new SDP be following
arejectedoffer.
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.
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?
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
