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

From: "Elwell, John" <[email-masked]>
Date: Fri, 12 Jan 2007 08:30:59 +0000

Brett,

I am not aware of anything to prevent it in straightforward circumstances,
but be aware that in some situations it simply will not work:
- 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.

So any clarification in the sip-offeranswer draft should mention these
points.

John 

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]] 
> Sent: 11 January 2007 19:36
> To: [email-masked]; [email-masked]; Paul Kyzivat
> Subject: [Sipping] streaming media without sending 18x containing sdp
> 
> Paul, Takuya:
> 
> In order to request modification to 
> draft-ietf-sipping-sip-offeranswer,
> this email is the follow-up to my sip-implementors posting:
> 
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-
> January/01
> 5236.html
> 
> 
> As a means to bypass the offer/answer rules, some vendors are 
> currently
> choosing to stream early media without placing an sdp within the 18x
> response.
> 
> Since I have not noticed any draft/rfc explicitly discussing such
> behavior, I prefer it be discussed (valid/invalid
> encouraged/discouraged) within draft-ietf-sipping-sip-offeranswer.
> 
> The following snapshot of the above link presents why I think such
> behavior should be clarified.  Even if some find rfc3264 clear
> concerning the topic, it seems like it would still be beneficial to
> discuss it within draft-ietf-sipping-sip-offeranswer.
> 
> Thanks,
> Brett
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Brett
> Tate
> Sent: Thursday, January 11, 2007 12:55 PM
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip-implementors] streaming media without sending
> 18xcontaining sdp
> 
> 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.
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Mon, 15 Jan 2007 12:01:02 -0500

> > 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.
> 
> 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.

Thanks for the response.

I agree that the solution can be used; this solution was what I was
implying by the "extra dialogs".

The "no violation of any RFC" aspects of your comment is one of things
I'm attempting to get clarified within
draft-ietf-sipping-sip-offeranswer.  Some are interpreting the RFCs to
indicate that there is no violation.

If anyone has an opinion on the matter, please reply to the list even if
you think no clarity should be provided within
draft-ietf-sipping-sip-offeranswer.

Thanks,
Brett

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 15 Jan 2007 14:43:53 -0500

> IMHO, what is defined in RFCs is just to prepare 
> to receive media when sending SDP, and it may 
> be enough in most cases.

The last paragraph of rfc3264 section 6.1 also places restrictions upon
the answerer concerning sending media.

> I do not know whether it is perfectly good 
> thing to recommend not to send any media packets 
> until it send out SDP answer. But possibly it can 
> reduce the potential problems.

Because there can be delays in actually streaming the answer SDP or
"preview" answer SDP (like reopening a TCP connection), I'm not
necessarily advocating waiting until the answer SDP actually gets sent.
I'm more trying to clarify if it is considered appropriate to act as
answerer without sending or attempting to send a 18x containing an
answer SDP or "preview" answer SDP.

If it is appropriate, I guess that the 6.1 answerer restrictions don't
apply until the answer SDP is sent.

Within an offer/answer model, it seems a little strange to not define as
"answerers" those sending media in response to offer (or those acting
answerer upon their behalf).  However I guess that it is all a matter of
definition.

Thanks for the response,
Brett

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 15 Jan 2007 18:46:49 -0500

> The only reason I can see for waiting until the 
> answer has been sent before sending media is if 
> the answer is needed by the offerer or something 
> along the path between them for the media to reach 
> its intended destination and be properly understood.

<snip>

> These are all special sub-cases of offer/answer, 
> rather than being general. I think it might be 
> better to formalize this kind of special behavior, 
> and identify those cases where it does and does 
> not apply. Key to this is that IMO there should 
> be something explicit in the offer that indicates 
> to the answerer that the answer will be required 
> before media can be received.

The "special sub-cases" that you mention are reasons to ensure answer
delivery before uselessly streaming media within the time between answer
sent and answer received.

Within the offer/answer model, the answerer may stream immediately upon
sending the answer (rfc3264 section 6.1 last paragraph).  Within the
offer/answer model, I have seen no indication that media may be streamed
prior to sending the answer.  Otherwise SIP is only using an
offer/answer model when the answer is sent instead of also following it
prior to sending the answer SDP or "preview" answer SDP.  However of
course, I might be misinterpreting rfc3264. :)  

If something is needed to avoid uselessly streaming media during the
time between offer received and answer received, RFC 3959 and RFC 3960
provide a decent solution.  The solution follows the offer/answer model
and provides a decent forking solution.

Because of forking concerns and clipping concerns (and delay of new
offer until answer), I am unaware of a solution which could solely rely
upon offerer including something within the INVITE.  However of course,
that doesn't mean someone couldn't define an enhancement to offer/answer
or something to only solve a portion of the problem.

Thanks for the response,
Brett