[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sipping] Re: Continuing review of draft-ejzak-sipping-p-em-auth now -01
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
Ejzak, Richard P (Richard) wrote:
Hi Paul,
Thanks for your review.
There are any number of different policies that a network may implement with the header, so I don't see the value in including an interop section. The behavior at an endpoint will depend completely on the policy chosen and there is no desire to mandate any particular policy in the draft. That's why there are so many MAYs in it. If you want the draft to say that depending on the local policy chosen there may be cases where early media will not be available to an endpoint - well that's pretty redundant, isn't it?
Gonzalo has also requested that I limit discussion of particular policies, which I have tried to do.
Certainly one possible policy is to authorize all early media from a particular peer network, regardless of the presence of the header in messages from that network (note that a boundary proxy can add the header). A good example of this is when the peer network is a SIP-I network that always uses early media. So the answer to your question is "yes" and an informational RFC should be adequate.
Richard
Paul Kyzivat wrote:
I just got to looking at the new version. It has cleaned up a
number of
things, and I find it improved because it is more up front
about early
media gating.
I still think there are major interoperability problems with
implementations that don't understand this header. I would
like to see
an interop section in the document that investigates cases where only
the calling side, or only the called side understands the
header and is
within the trust domain. I think that will bring to light issues that
should be confronted.
The basic issue here is whether there can ever be an expectation that
early media works in the absence of an extension like this. If the
answer is "no" then this should probably be standards track
rather than
a P-header.
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