Hi,
I also think it would be useful to add some text about the
importance of
providing an answer as soon as possible, since some
implementations will
not accept any media before they have received an answer
(or, at least a
preview of an answer).
Regards,
Christer
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks nostrum.com]
> Sent: 26. marraskuuta 2007 22:17
> To: Paul Kyzivat
> Cc: sipietf.org
> Subject: Summary of "what answerer can send"
thread (was Re:
> [Sip] SIPit 21 :Topics that attendees argued about)
>
> Ok - I think we've found the necessary chunks of text
needed
> to put this part of the thread down.
>
> My introduction of the thread had a wrong conclusion in
it
> (per 3254 6.1).
>
> To re-summarize:
>
> If an m-line in the offer offers codecs A, B, and C
then
> until all possible answers are received (think
forking), the
> offerer must be prepared to receive RTP containing A,
B, or C.
> After each answer (again remember forking), that
answerer
> MUST only send RTP packets using the codecs that are in
the
> intersection of the offer and the answer for that
m-line. So,
> for instance, if that m-line in the answer contained
only B,
> the answerer can only send B. Once it's received the
answer,
> the offerer can decide to only render B, but due to
race
> conditions it should anticipate seeing some A or C
coded
> packets, but nobody should expect it to do anything
useful with them.
>
> Now we need to find where to put pointers to this so
that it
> isn't so hard for implementers in the future to find.
>
> RjS
>
> On Nov 26, 2007, at 11:34 AM, Paul Kyzivat wrote:
>
> >
> >
> > Robert Sparks wrote:
> >> Dale -
> >> What you quoted talks about what the offer can
_send_.
> >
> > The second sentence says what format the offerer
MUST use when
> > sending. A corollary of that is that it MUST NOT
use some other
> > format. And a corollary of *that* is that the
answerer MUST be
> > prepared to receive any of the formats listed in
the
> answer, and MAY
> > NOT be prepared to receive any other format.
> >
> > Note that this apparently includes formats listed
in the answer but
> > not in the offer! So if the offerer is capable of
using any of the
> > "extra" formats listed in the answer
(which the answerer
> has no way of
> > knowing) then it may go ahead and use those.
> >
> >> It doesn't talk about what the offerer must be
willing to receive
> >> (nor does it constrain what the answerer can
send).
> >
> > Yes, you are right - it doesn't.
> >
> > Section 5.1 says:
> >
> > ... If multiple formats are listed, it
> > means that the offerer is capable of making use
of any of those
> > formats during the session. In other words,
the answerer MAY
> > change
> > formats in the middle of the session, making
use of any of the
> > formats listed, without sending a new offer.
...
> >
> > That certainly at least *implies* that the offerer
MUST
> initially be
> > capable of receiving any format listed in the
offer.
> >
> > Then Section 6.1 says:
> >
> > Once the answerer has sent the answer, it MUST
be prepared to
> > receive
> > media for any recvonly streams described by
that answer.
> It MUST
> > be
> > prepared to send and receive media for any
sendrecv
> streams in the
> > answer, and it MAY send media immediately. The
answerer MUST be
> > prepared to receive media for recvonly or
sendrecv streams using
> > any
> > media formats listed for those streams in the
answer, and it MAY
> > send
> > media immediately. When sending media, it
SHOULD use a
> > packetization
> > interval equal to the value of the ptime
attribute in
> the offer, if
> > any was present. It SHOULD send media using a
bandwidth
> no higher
> > than the value of the bandwidth attribute in
the offer,
> if any was
> > present. 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. In the case of RTP, it MUST use the
payload type numbers
> > from the offer, even if they differ from those
in the answer.
> >
> > *This* says that the answerer is constrained to
send on a format in
> > the intersection of the offer and the answer. So
the
> offerer must be
> > prepared to receive everything it offers
initially, and then it can
> > *reduce* what it expects and is capable of
receiving once
> it receives
> > the answer.
> >
> > Thanks,
> > Paul
> >
> >
> >> RjS
> >> On Nov 23, 2007, at 11:31 AM, Dale.Worleycomcast.net wrote:
> >>> From: Robert Sparks <rjsparksnostrum.com>
> >>>
> >>> On Nov 23, 2007, at 5:12 AM, Christer
Holmberg wrote:
> >>>> AFTER he has received the answer he
may accept only what both
> >>>> parties have indicated support for.
> >>>
> >>> I don't think that's right. Can you
show me the text that
> >>> supports
> >>> that claim?
> >>>
> >>> Here's section 7 of RFC 3264 (found by
Ernst Horvath):
> >>>
> >>> 7 Offerer Processing of the Answer
> >>>
> >>> When the offerer receives the answer,
it MAY send media on the
> >>> accepted stream(s) (assuming it is
listed as sendrecv
> or recvonly
> >>> in
> >>> the answer). It MUST send using a
media format listed in the
> >>> answer,
> >>> and it SHOULD use the first media
format listed in the answer
> >>> when it
> >>> does send.
> >>>
> >>> The reason this is a SHOULD, and not
a MUST (its also a
> >>> SHOULD,
> >>> and not a MUST, for the answerer),
is because there will
> >>> oftentimes be a need to change
codecs on the fly. For
> >>> example,
> >>> during silence periods, an agent
might like to switch to a
> >>> comfort
> >>> noise codec. Or, if the user
presses a number on
> the keypad,
> >>> the
> >>> agent might like to send that using
RFC 2833 [9].
> Congestion
> >>> control might necessitate changing
to a lower rate
> codec based
> >>> on
> >>> feedback.
> >>>
> >>> The offerer SHOULD send media according
to the value
> of any ptime
> >>> and
> >>> bandwidth attribute in the answer.
> >>>
> >>> The offerer MAY immediately cease
listening for media formats
> >>> that
> >>> were listed in the initial offer, but
not present in
> the answer.
> >>>
> >>> I skimmed
draft-ietf-sipping-sip-offeranswer-04 and I see
> nothing in
> >>> it that would alter the interpretation of
this section.
> >>>
> >>> Dale
> >>>
> >>>
> >>>
_______________________________________________
> >>> 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
|
