From: Robert Sparks <[EMAIL PROTECTED]> What you quoted talks about what the offer can _send_. It doesn't talk about what the offerer must be willing to receive (nor does it constrain what the answerer can send).
Perhaps I'm misunderstanding you, but in regard to what the offerer must be willing to receive, this seems unambiguous: > Here's section 7 of RFC 3264 (found by Ernst Horvath): > [...] > The offerer MAY immediately cease listening for media formats that > were listed in the initial offer, but not present in the answer. In regard to what the answerer can send, RFC 3264 section 6.1 is clear: The answerer MUST send using a media format in the offer that is also listed in the answer [...]. From: Robert Sparks <[EMAIL PROTECTED]> 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. I don't want to sound snarky, but isn't "Read RFC 3264." implicit in regard to SIP implementation? I'm willing to have it pointed out to me that it's easier to overlook this information than I'm allowing for, but it seems to me that the answers to these questions are both what one would naively expect, and also are documented in the sections of the document that one would expect to find them in. The only gotcha that I can see is the consequences of forking, if the offer is contained in a dialog-forming request, in that until the transaction of the dialog-forming request is terminated, the UAC must behave as if there are unknown un-answered offers in flight. But that is implicit in the RFC 3264 model once one thinks about it. 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
