>
> You can always lock down a codec by updating the
initial offer. Take a
> look
> at section 10.2 of RFC 3264.
That would be when you have to lock down to a subset of what
has been
supported in the answer. Lets say if the offer contained
A,B,C and the
answer contained only B, what would be the need to lockdown
specifically
by another offer answer?
I am trying to understand if there is any particular reason
why it has
been kept as it has been kept, considering that one more
offer answer
would mean one more round of signaling overhead.
Regards,
Ravi.
>
> Raj
>
>
> > -----Original Message-----
> > From: Christer Holmberg
[mailto:christer.holmberg ericsson.com]
> > Sent: Thursday, November 22, 2007 5:34 AM
> > To: ravishankar.shiroorwipro.com; rjsparksnostrum.com;
sipietf.org
> > Subject: RE: [Sip] SIPit 21 : Topics that
attendees argued about
> >
> >
> > Hi,
> >
> > I agree with Ravi.
> >
> > Eventhough you in theory is supposed to be able to
receive
> > what you offer - no matter what you get in the
answer - I
> > think that in real life the only codecs that
participants
> > will be prepared to send/receive are the ones sent
both in
> > the offer and the answer. That is also the reason
why the
> > answer normally doesn't contain additional codecs
- it mostly
> > contains a subset of the codecs in the offer.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> > >I was surprised to find
> > >
> > >>* There were implementations that offered
an m-line with
> > codecs A, B,
> > >>and C, got an answer with C, then got
upset when they got
> > RTP with A
> > >>(which is quite legal).
> > >
> > >On the list (like others who argued about it I
think).
> > >
> > >I had some offline discussions with some of
the members on this.
> > >While I agree this seems legal, this seems
very
> > counter-intuitive and
> > >may result in wasted resources, would it not?
> > >
> > >For example, if the offerer is a conference
bridge or a
> > transcoder, and
> > >has a limited number of codecs of each type he
offers, why should
it
> > >hold on to one codec of each type for the
duration of the
> > session, even
> > >though the answerer has not supported it?
> > >
> > >Any particular reason why this should be
continued as a
> > legal scenario?
> > >Would it not be possible change it to say that
the Offerer needs to
> > >expect only those codecs which answerer has
explicitly
> > supported in the
> > >answer?
> > >
> > >Regards,
> > >Ravi.
> > >
> > > --
> > >
> > > Ravishankar. G. Shiroor
> > > Wipro Technologies, Bangalore.
> > >
> > > ravishankar.shiroorwipro.com
> > > --
> > >
> > > > -----Original Message-----
> > > > From: Robert Sparks [mailto:rjsparksnostrum.com]
> > > > Sent: Tuesday, November 20, 2007 2:38
AM
> > > > To: sip List
> > > > Subject: [Sip] SIPit 21 : Topics that
attendees argued about
> > > >
> > > > Digging through my notes:
> > > >
> > > > Here are some of the topics where people
were arguing. I'm
> > > capturing
> > > > the smaller topics here. Larger
arguments will get their
> > > own message.
> > > >
> > > > * There were arguments about the dynamic
payload map from
> > > numbers to
> > > > codecs (identified in the SDP and sent
in the RTP) being
> > > the same in
> > > > the offer and the answer . The spec says
they SHOULD. Some
> > > > implementations were insisting they
MUST.
> > > > * There were arguments around preserving
the relative order
> > > of codecs
> > > > on an m-line between the offer and the
answer. The specs
> > say SHOULD.
> > > > * There were implementations that
offered an m-line with
> > > codecs A, B,
> > > > and C, got an answer with C, then got
upset when they got
> > > RTP with A
> > > > (which is quite legal).
> > > > * There were arguments about deleting
rejected m-lines on
> > > re-invites
> > > > (which you cannot do), and on reusing
the slot they occupy in
re-
> > > > invites (which you can do).
> > > > * There were implementations that didn't
add the
> > refresher tag in a
> > > > session-refresh message when they were
the refresher and
> > there were
> > > > arguments about whether that meant the
other side could
> > > take the role.
> > > > * Several implementations handled
a=sendonly as a session
> > > attribute,
> > > > but not a media attribute - it can
appear in either place.
> > > >
> > > >
> > > >
> > > >
_______________________________________________
> > > > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the
core SIP Protocol Use
> > > > sip-implementorscs.columbia.edu for
questions on current sip
Use
> > > > sippingietf.org for new
developments on the application of sip
> > >
> > >
> > >
_______________________________________________
> > > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core
SIP Protocol Use
> > > sip-implementorscs.columbia.edu for
questions on current sip Use
> > > sippingietf.org for new developments on the
application of sip
> > >
> >
> >
> > _______________________________________________
> > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol Use
> > sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new developments on the
application of sip
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
