Hello, Could somebody please explain the rationale for the "One of N Codecs" section of the SDP offer/answer draft? (draft-ietf-mmusic-offer-answer-02)
Firstly, to mark an initial offer as "inactive" seems rather pessimistic, and requires further round trips to set up the call. As the draft notes, there is a danger of glare here (though it's hard to see how this could happen at the SDP level: why would the *answerer* need to immediately make an updated offer?). It does require a SIP UAS core to deal with an ACK and a re-INVITE together, possibly arriving out-of-order (which is allowed, I suppose? Or might the UAS have to return 491?). Secondly, to simultaneously offer codecs which cannot simultaneously be supported (even in an inactive sense) seems an inelegant oddity in the protocol. The same goes for multiple codecs in a SIP OPTIONS response. I seem to remember there were suggestions made in which an offer could contain a default/preferred set of codecs in the "m=" line, plus a set of alternative capabilities as attributes. This would have solved the glare and slow-start problems, and still been reasonably backwards compatible. I wonder why that approach was not taken? (I'm sure there were good reasons, I'm just curious to know them!) A related concern: Putting a SIP call "on hold" is now indistinguishable from changing its streams from sendrecv to sendonly. One would normally consider these events to be semantically different. This has implications for the user interface at the "holdee" end, to advise them that they have been put on hold. For instance, how can one determine if local "hold music" should be played? Regards, Nick -- Nick Hollinghurst [EMAIL PROTECTED] Research Engineer Phone: +44 1223 343364 AT&T Laboratories, Cambridge, England Fax: +44 1223 313542 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
