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, [EMAIL PROTECTED] wrote:
From: Robert Sparks <[EMAIL PROTECTED]>
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://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
