Subject: [Sipping] draft-ejzak-sipping-p-em-auth: P-Early-Media added by proxy

From: "Brett Tate" <[email-masked]>
Date: Tue, 5 Sep 2006 19:33:44 -0400

Richard,

Can P-Early-Media added by proxy within requests (INVITE, UPDATE,
PRACK?) toward UAS (INVITE perspective) contain em-param parameters to
indicate that the proxy/SBC plans to block early media?  And if UAS
receives the header containing such knowledge, SHOULD/MAY/MUST (or
SHOULD NOT, MAY NOT, MUST NOT) the UAS act upon such knowledge?

And table 1 currently does not indicate support of P-Early-Media for
PRACK, PRACK 2xx, or UPDATE 2xx.  Should the header be expected within
these responses and request?

Thanks,
Brett

_______________________________________________
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: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 8 Sep 2006 16:42:16 -0500

Brett Tate wrote:
.
.
> 
> The main reason for allowing inclusion of the header within 
> PRACK, PRACK
> 2xx, and UPDATE 2xx is to deal with issues related to a device adding
> additional media lines within PRACK (rare if ever) or UPDATE.  If I
> understand the draft correctly without allowing header within these
> cases, the device would apply the mapping used for the prior 
> media line
> to additional media lines added within PRACK or UPDATE (from caller).
> 

The idea was that it was only necessary for the UAS to be able to include changes in authorization requests when it initiated media changes.  But I see that authorization requests may also be needed for UAC-initiated media changes.  I will add the PRACK 2xx and UPDATE 2xx cases.  The header is only needed in PRACK if we add UAS notification per your other comments.

> The following text from section 6 was one reason that I was uncertain
> concerning the header potentially containing em-param entries.  The
> "modify" text is a little misleading if you did not intend a proxy to
> manipulate the contents of the header.
> 
> "As members of the Trust Domain, each proxy receiving an 
> INVITE request
> must decide whether to insert or modify the P-Early-Media 
> header before
> forwarding."

I agree that this wording is potentially misleading.  I meant to cover the case of header deletion and to leave open the possibility of defining parameters for use in this case.

> 
> Another reason was the lack of specificity related to the 
> header solely
> indicating support of draft as it progresses towards and arrives at
> called party.

When forwarding the INVITE request, a proxy does not necessarily know what early media policy it may need to enforce.  It won't decide until it gets authorization requests, collects relevant data (such as identity of transit networks) and applies local policy.  Any information about actual early media blocking would have to be sent in some other message towards the UAS.  Unfortunately, there doesn't always exist a message we can use to piggy-back such an indication.  That's one of the reasons I didn't want to add this feature to begin with.  The other reason is that lack of blocking is not a guarantee that the media will get rendered.  As I discussed in my presentation to sipping in Montreal, there are other possible reasons for this that are unrelated to blocking.

> 
> Some of the limitations I currently see with the solution (without UAS
> aware of what is occurring) are the following:
> 
> 1) The UAS returns a 183 with SDP.  The early media reflects ringing.
> The UAC/user hears nothing because it is being blocked by the 
> SBC/proxy.
> 
> 2) The UAS returns a 183 with SDP.  The early media reflects a failure
> treatment.  The UAC hears nothing because it is being blocked by the
> SBC/proxy.  The UAS finally returns the failure code; the UAC finally
> plays local treatment.
> 
> 3) The UAS is attempting and failing to do something within 
> early media
> which it would have been willing to do upon answer if it knew early
> media was likely being blocked.

I understand these potential problems.  That was part of the idea behind Brian's draft on early media coping.  I have trouble believing that there are many UAS that would be willing to answer in case 3, btw.  Service providers need to decide their blocking and charging policies taking all of this into account.  I never intended to attempt to solve the entire set of problems with early media with this draft.
> Thanks for the response.
> -brett
Thank you for some good input for the draft.
Regards,
Richard