Subject: [Sip] Re: RFC 3264 An Offer/Answer Model Session Description Protocol

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2002 19:22:27 -0400

I have a question of interpretation regarding section 8.3.2 (Changing the Set of Media Formats).

When describing how an offer is to be constructed for a change (a reINVITE), this section says:
   
"However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session.  For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session."

What I question is the "or answers" at the end of this section. This seems to be inconsistent with section 6.1, which says that the payload type numbers for answers may be different than those for offers.

These aren't necessarily inconsistent if another constraint is added to 6.1, saying that when the answer changes the payload number from what was in the offer, it must be a number that doesn't already have an association with a particular payload type in the current session. But I don't think that is what was intended. (My impression is that the intent is to permit the two sides to have totally independent numberings for codecs.)

The alternative interpretation is that section 8.3.2 is a bit overzealous, and that the mapping between payload type numbers and codecs only needs to be consistent for a particular endpoint of a session. 

This is probably not a big deal, because the suggestion that this applies to both directions rather than each direction independently only appears in an example.

I realize it would have been better to ask about this before or during last call. But I just didn't get around to it. Sorry!

	Paul
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip