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