Brett Tate wrote:
> I think this has been discussed in the past; however I couldn't find the
> threads...
>
> 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.
Nor am I aware of any more recent drafts or RFCs that try to impose any
stronger rules, at least not normatively.
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 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.
Paul
> Thanks in advance for a response,
> Brett
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
