RE: SIPit 21 : Topics that attendees argued about

See inline comments. 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com] 
> Sent: Thursday, November 22, 2007 3:11 PM
> To: Horvath, Ernst; ravishankar.shiroorwipro.com; 
> rjsparksnostrum.com; sipietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees
argued about
> 
> 
> Hi, 
> 
> >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."
> 
> The question is not what the offerer is supposed to
send, but what he
> should be able to receive.
> 

So what's the problem? The text talks about what the
answerer is
supposed to send, not the offerer.  Initially the offerer
must expect
any format that he included in the offer. But once the
answer has
arrived, an answerer that conforms to RFC 3264 WILL send
only formats
included in the answer, so the offerer CAN stop listening
for all other
formats.

> 
> >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."
> 
> Yes. The problem with the "MAY" is that the
other party doesn't know
> whether the offerer will listen or not, so therefor I
think it's more
> saft to only use codecs which BOTH entities include in
the SDP.

No, the MAY gives a conformant offerer the permission to
stop listening
immediately on arrival of the answer. That means for the
conformant
answerer that he MUST NOT assume that the offerer is still
listening for
formats that were not in the answer. I know, auxiliary verbs
can be
tricky, but the two cited excerpts from RFC 3264 are
entirely
consistent.

Regards,
Ernst

> 
> >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)
> 
> In many cases the offerer will not - due to different
kind of 
> reasons -
> accept anything before he receives the answer (yes,
yes, I know what
> RFC3261 says...).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> > > -----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