Subject: [Sipping] RE: streaming media without sending 18x containing sdp

From: "Brett Tate" <[email-masked]>
Date: Fri, 12 Jan 2007 17:31:22 -0500

Thanks for the response.  My replies are inline.

> We have been trying to have the offeranswer draft explain 
> things that are specified in standards and/or generally 
> agreed to have been implied by the standards.
> 
> IMO what you are asking doesn't, yet, fall into that 
> category. I think we at least need some further list 
> discussion leading to consensus about what correct 
> behavior is in this case. 

Sounds fair.  Maybe those sending media without sending an answer SDP or
"preview" answer SDP will reply.  

I think it violates the spirit of rfc3264; however depending upon
interpretation of section 6.1, it might not actually violate rfc3264.

RFC 3264 section 5.1 lists some of the restrictions concerning receiving
media prior to receiving the answer SDP.  It cannot send media.  It
cannot send RTCP receiver reports.

RFC 3959 and RFC 3960 discuss the forking related limitations; however I
don't recall if all are discussed.  The receiver might not be able to
handle media being streamed from multiple locations.  Clipping might
occur upon answer if not currently presenting the media associated with
the dialog which answered (INVITE 200).  The user might not like the
sound of media being mixed to avoid the clipping problem.

And John Elwell mentioned problems with:
"
- use of security descriptions - the SDP answer is necessary before
sending SRTP;
- certain NAT environments, e.g., when using ICE or when forward RTP is
needed to open the NAT binding for backward RTP.
"

> What you are looking for may be:
> - an explicit statement that the behavior you have seen is
>    in fact legal, or
> - a tightening of the specifications, declaring the kind of
>    behavior you are concerned with to in fact be illegal, or
> - a BCP specifying this behavior.
>
> Once there is a clear sense of the way to go on this, I 
> think it *might* be appropriate for the offeranswer draft.

Thanks for the potential willingness to provide clarification 
within draft-ietf-sipping-sip-offeranswer.

> I don't know if there are any important use cases where 
> sending media before the answer is necessary. I'd be 
> interested to hear if there are.

As far as I know, there are two reasons.  However the importance level
is debatable since I really think it is just a lack of desire to comply
with the spirit of rfc3264.

1) Simplification: avoid the restrictions and complication caused by the
only 1 answer rules.  Thus violate the spirit of rfc3264 and act as
answerer without actually sending the SDP. :)

2) Optimization: avoid the extra dialogs, UPDATEs, or re-INVITEs which
would have been required by sending different SDPs when early-session
(rfc3959) not used or adequate.  For instance if not using
early-session, extra messaging would be required if first wanted return
SDP containing sendonly and subsequently send SDP containing sendrecv.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 13 Jan 2007 14:36:46 +0100

Hi, 

>is debatable since I really think it is just a lack of desire 
>to comply with the spirit of rfc3264.
> 
>1) Simplification: avoid the restrictions and complication 
>caused by the only 1 answer rules.  Thus violate the spirit of rfc3264
and act as
>SDP containing sendonly and subsequently send SDP containing sendrecv.

Both cases can be solved with a very simple trick: changing of the To
tag. If the UAS wants to change the answer, it simply changes the To tag
in the response (18x or 200) where the new answer is sent. No need for
any UPDATE or re-INVITE, and no violation of any RFC.

Regards,

Christer