[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



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