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

From: "Brett Tate" <[email-masked]>
Date: Thu, 11 Jan 2007 14:36:27 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jan 2007 12:57:34 -0500

Brett,

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

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.

	Paul

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 15 Jan 2007 13:08:04 +0900

Brett,

Actually so far I intended the offer/answer draft to be independent 
>from the media layer, because;

1) offer/answer exchange is not limited to sending/receiving media.
  It can negotiate key management or pre-conditions, for example.
  We want it to be general where possible.
2) early-media discussion is so controversial to be fixed here.

However, if it is useful, we can add something about the issue you raised 
here. I am not sure but maybe we need to add new section or some notes
to do that. As Paul said, we need further discussion.

IMHO, what is defined in RFCs is just to prepare to receive media when 
sending SDP, and it may be enough in most cases.
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.

Regards,
Takuya

> > bad thing, it should be discouraged.

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jan 2007 11:56:27 -0500

Thinking about this further...

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.

One example is when security descriptions are being exchanged.

Another case is when the offerer is itself only willing to receive media 
from a known source. (Note that the answer only defines the source for 
received media if the answerer's receiving port is also used for 
sending. This is not required by 3261 or 3264.)

Another case is when some middlebox is going to gate the media. The 
implications of that are much the same as if the answerer gates the 
media itself.

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.

	Paul