Hi Paul, Thanks for the response. My replies are inline.
> > Some vendors are currently choosing to stream > > early media without including an SDP within > > the 18x response. Is such behavior explicitly > > discouraged within an existing RFC? And if not, > > should text discussing/discouraging it be added > > to draft-ietf-sipping-sip-offeranswer? > > AFAIK there is nothing in 3261 to suggest that this is > improper behavior. 3261 (or maybe it is 3264) explicitly says > that the offerer should be prepared to receive media as soon > as the offer is sent. Yes; the "MUST be prepared to receive" is discussed at the end of rfc3264 section 5.1. And my understanding is that this text is to avoid clipping instead of giving the answerer approval to avoid sending an answer SDP or "preview" answer SDP. Section 6.1 discusses that the answerer may send media immediately after sending answer. However I haven't found any text discussing the validity (valid or invalid) of sending media without also sending an answer SDP. > Nor am I aware of any more recent drafts or RFCs that try to > impose any stronger rules, at least not normatively. My understanding is that it isn't discussed because nobody expected vendors to stream media without attempting to deliver an answer SDP or "preview" answer SDP. Wouldn't draft-ietf-sipping-sip-offeranswer be a good place to discuss the validity and if it is encouraged or discouraged? (I will likely post a follow up to the sipping list.) RFC 3960 indirectly discusses it by discussing the problems of forking and early media. However it doesn't specifically discuss the situation I'm asking about. > I know there are deployed operating environments that make > tighter assumptions, but I think these must be viewed as > added requirements for those particular environments. You can > perhaps find fault for a particular device not following such > added rules, but I don't think it is currently an ietf issue. I'm not looking to find fault. I'm looking for clarification and if this it is encouraged or discouraged as a way to bypass the offer/answer rules. > > I assume the vendors are attempting to bypass the > > various rules and complexities of offer/answer by > > trying to take advantage of products willing to render > > the media (to avoid clipping) under the pretence > > that the related 18x/200 containing the SDP is slow > > to arrive. > > > > Some of the reasons to discourage such behavior is > > discussed within rfc3960. However I have not found > > any text explicitly discussing devices acting like > > answer SDP or "preview" answer SDP has been sent > > without intention of actually sending it. > > If there is consensus that such behavior is to be mandated > then it will take some new draft to do it. I'm not asking for a mandate. I'm asking for a sip related IETF document to discuss it. If people think it is a good way to bypass the offer/answer model; it should be encouraged. If people think it is a bad thing, it should be discouraged. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
