Thanks Dale, this explains a lot. Do you think it is worth mentioning about the RFC 4917 on SIP Connected Identity as the media-session is re-negotiated in mid-dialog? On Wed, Sep 24, 2008 at 1:07 AM, <[EMAIL PROTECTED]> wrote:
> From: "Vikram Chhibber" <[EMAIL PROTECTED]> > > I think I have missed something here. Why do we need to maintain codec > numbers relationship with the previous offer/answer (Between Alice and > Bob)? > My understanding is that offer/answer model does not have any state > dependency with previous one except for "o" line and maintaining media > description ordering. > > I will say preserving m line ordering is definitely the > reason. Codec number for dynamic payload can change within same > session. > > RFC 3264 section 8.3.2: > > 8.3.2 Changing the Set of Media Formats > > The list of media formats used in the session MAY be changed. To do > this, the offerer creates a new media description, with the list of > media formats in the "m=" line different from the corresponding media > stream in the previous SDP. This list MAY include new formats, and > > MAY remove formats present from the previous SDP. 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. However, it is > acceptable for multiple payload type numbers to be mapped to the same > codec, so that an updated offer could also use payload type number 72 > for G.711. > > The mappings need to remain fixed for the duration of the session > because of the loose synchronization between signaling exchanges > of SDP and the media stream. > > Dale > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
