RE: SIPit 21 : Topics that attendees argued about

I am surprised that this caused any confusion. RFC 3264
seems pretty
clear to me.

Citing from section 6.1:
  "The answerer MUST send using a media format in the
offer
   that is also listed in the answer, and SHOULD send using
the most
   preferred media format in the offer that is also listed
in the
answer."

and from section 7:
  "The offerer MAY immediately cease listening for
media formats that
   were listed in the initial offer, but not present in the
answer."

So, why should the offerer be expected to deal with formats
not present
in the answer? (Of course, the offerer must be prepared to
receive ALL
offered formats BEFORE the answer arrives)

Regards,
Ernst Horvath

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com] 
> Sent: Thursday, November 22, 2007 11: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

RE: SIPit 21 : Topics that attendees argued about

Thread: RE: SIPit 21 : Topics that attendees argued about