[Sipping] RE: Continuing review of draft-ejzak-sipping-p-em-auth now -01

["Ejzak, Richard P (Richard)" <ejzak at lucent.com>]

Hi Paul,
I see no reason to single out this header to describe an issue that already exists in SIP today.  When parallel forking occurs the UAC can at most render one randomly chosen stream.  IMS already has the option of implementing static early media gating policies near the UAC and/or UAS.  Even the rendering of media in preference to local ringing is a matter of local policy according to RFC 3960, even though only one policy is described in detail in the RFC.  My draft does not change any of this.

We have different opinions on how networks should manage this issue.  This header provides a network more information to make potentially less restrictive gating decisions than it otherwise would need to make to ensure local policies.  Other networks have local policies that don't require any gating - or this header.  You would prohibit networks with more restrictive policies from doing any gating.  Unfortunately for you, you don't control the gates - they do.  So let's help make those networks as friendly as possible.

Richard

Paul Kyzivat wrote:
> Richard,
> 
> As best I can tell, there are only a few reasons for this 
> draft and header:
> 
> - to provide a new mechanism for a UA to use when deciding whether
>    to render early media it receives
> 
> - to provide a mechanism for a UA to indicate it intends to send
>    early media
> 
> - to provide a mechanism for middle boxes to indicate that early
>    media is being denied
> 
> Without this, there is already a mechanism for a UA to use to 
> decide to 
> render early media: It should just render what it receives. 
> Introducing 
> another mechanism for this seems certain to present interop problems.
> 
> Without this there is no expectation that a UA needs to explicitly 
> indicate its intent to use early media. Introducing a 
> mechanism for this 
> seems certain to present interop problems.
> 
> The use by middleboxes is a second order issue, because if 
> the middlebox 
> is blocking early media then it will cause interop problems 
> whether this 
> new mechanism is used or not. But the mechanism is a surrogate for 
> approving of this blocking.
> 
> The interop issues are the same regardless of what policy is used, 
> (except for a policy that says not to use the header). So I think the 
> interop scenarios can be worked out in a policy independent 
> manner, and 
> without regard for what middleboxes do to the header. I think 
> the cases 
> are simply based one end (UAC or UAS) using / expecting use of the 
> header together with the value used, and the other end not 
> understanding 
> or using the header.
> 
> For instance, if the UAC will only render early media if the 
> header is 
> present, while the UAS sends early media without including 
> the header, 
> then there will be an interop problem. IMO this is the kind of result 
> that is not supposed to happen with P-headers. (But that is a complex 
> subject and don't pretend to be the authority for making that call.)
> 
> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP