Subject: RE: [Sipping] Re: psychic early media behavior

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 30 Jun 2006 09:52:41 -0400

Paul,

As usual very thorough work on uncovering relevant RFCs and drafts.
That said, I get the impression that while a lot of MAY send media might
occur, there is not any hard reliance on getting media.  In most cases,
the expectation of early media came from the backward compatibility with
legacy PSTN systems.

Dale,

I like your formulation of the problem and solution.  However, what I
don't see is the case where it is the UAS that is the one that requires
the sending of early media vice the requestor needing it.  It would be
good to cover that case, as I suspect that might occur more often.
Thus, discussion of inserting/modifying headers/parameters in responses
would be useful.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, June 29, 2006 9:55 PM
> To: [email-masked]
> Subject: Re: [Sipping] Re: psychic early media behavior
> 
>    From: Paul Kyzivat <[email-masked]>
> 
>    I wish I was hearing more opinions here.
> 
> Be careful what you wish for!
> 
> Let me first say that I'm sure that a bar BOF is called for, 
> as I don't think that we yet have a consensus on what the 
> questions really are.
> 
> Secondly, I think we're finally enunciating clearly that the 
> fundamental question is whether a plain-vanilla RFC 3261 
> system (UAs *and*
> network) is required to pass early media.  If that is 
> answered in the affirmative, almost any system for regulating 
> or reporting regulation of early media is 
> non-upward-compatible, and cannot be handled by a P-header alone.
> 
> Finally, if we really have to, we can cobble together a 
> solution that is strictly RFC 3261 compliant, allows all the 
> controls that TISPAN could possibly want, and is sufficiently 
> isolated from all current SIP implementations that we do not 
> have to vet it microscopically before approving it as an RFC.  Viz.:
> 
>     Introduce an option tag, e.g., "controlled-early-media".  If a UA
>     specifies "Supported: controlled-early-media", that UA 
> will generate
>     extension headers to control early media, and is prepared 
> to interpret
>     such headers that are received.
> 
>     If UA1 desires to use these headers, it will send
>     requests/responses with "Supported: controlled-early-media" and
>     extension headers.  If UA2 does not understand the extension, it
>     will ignore the headers, and not send "Supported:
>     controlled-early-media", which will allow UA1 to know that there
>     is no early media control.  If UA2 understands the extension, it
>     will send "Supported: controlled-early-media" and extension
>     headers, and the UAs can negotiate early media usage.
> 
>     If UA1 *requires* these headers, it will send requests 
> with "Require:
>     controlled-early-media" (and "Supported:  
> controlled-early-media").
>     If UA2 does not understand the extension, it will reject 
> the request
>     with 420 (Extension Not Understood).  If UA2 understands the
>     extension, continue as above.
> 
>     If UA1 requires these headers, if it receives a request without
>     "Supported: controlled-early-media", it will reject the 
> request with
>     421 (Extension Required).  If UA1 receives a request with 
> "Supported:
>     controlled-early-media", continue as above.
> 
>     [The above rules can be restricted to particular subsets 
> of requests
>     (e.g., INVITE), if those are all that need to be restricted.]
> 
>     If the network and/or proxies through which a request passes
>     require these headers, 1) any entering requests that do not
>     contain "Supported: controlled-early-media" are rejected with 421,
>     and 2) any requests passed that do not contain "Require:
>     controlled-early-media" have it added.
> 
>     (RFC 3261 permits a proxy to add headers (except those listed in
>     section 19.1.5) to a request en route:  The proxy 
> forwards the request
>     to an integral UA, which responds with a 302 whose Contact is
>     <...original-destination...?Require=controlled-early-media>.)
> 
> If two UAs wish to communicate, and at least one of them does 
> not understand controlled early media, and the 
> network/proxies do not require controlled early media, this 
> mechanism allows them to communicate just as before, and 
> either UA that does understand controlled early media knows 
> that it cannot use that mechanism.
> 
> If a UA does not understand controlled early media, and the 
> other UA and/or the network/proxies require it, a connection 
> attempt will fail with 420 or 421, specifying that the 
> lacking extension is "controlled-early-media".  This is 
> inherently ugly, but is unavoidable if we are going to 
> satisfy TISPAN's requirement at all, but not have RFC 
> 3261-only UAs experience early media failures that they are 
> not notified of.
> 
> The extension headers only have to be understood by UAs that 
> support controlled early media, and networks/proxies that 
> desire to understand them.  So implementors of all other SIP 
> agents can safely ignore their definitions, regardless of how 
> perverse they are.  This should allow advancement of any 
> proposal that TISPAN wants to an RFC relatively quickly.
> 
> Dale
> 
> _______________________________________________
> 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: [email-masked]
Date: Fri, 30 Jun 2006 12:10:39 -0400

From: "Michael Hammer \(mhammer\)" <[email-masked]>

   However, what I don't see is the case where it is the UAS that is
   the one that requires the sending of early media vice the requestor
   needing it.  It would be good to cover that case, as I suspect that
   might occur more often.  Thus, discussion of inserting/modifying
   headers/parameters in responses would be useful.

The situation where the UAS requires early media breaks into several
cases --

1) The UAS does not understand this mechanism.

1a) If the UAC is prepared to deal with such a UAS in an RFC 3261
manner (that is, accept early media without further negotiation), then
it does not add "Require:  controlled-early-media", and the UAS
accepts the request, and operation proceeds as in RFC 3261.

1b) If the UAC requires further negotiation, it adds "Require:
controlled-early-media", and the UAS rejects the request, thus
ensuring both UAs are aware of the failure.

1c) If the network requires further negotiation, it ensured that
"Require:  controlled-early-media" was present in the request, and the
UAS rejects the request.

2) The UAS does understand this mechanism.

2a)  The UAC and the network do not require further negotiation to
pass early media.  In that case, the request is accepted, and early
media proceed as in RFC 3261.

2b) The UAC and/or the network require further negotiation.  When the
request reaches the UAS, "Require: controlled-early-media" is present.
The UAS accepts the request and invokes early media negotiation.

The whole point of the mechanism is that a UA that does not understand
the extension cannot establish a dialog unless the other UA and the
network between are prepared to pass early media on an RFC 3261 basis.

Dale