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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 7 Sep 2006 08:58:51 -0500

Hi Brett,
It sounds like you are proposing an extension to the header that was not originally intended.  If we added such an extension, its use would also be subject to local policy, both in the network and at the UA.  So I don't see any answer other than "MAY" to your question.  My initial reaction was that this extension would not be useful in a private network with known early media policies, but there may be some applications when used under bilateral agreement between private networks.  There might also be value in having a proxy indication of blocking signaled towards the UAC to avoid blocking at multiple places in the network.  I have to think about these ideas further - in particular whether it matters given other impediments to early media.  I am planning an update to the draft very soon and I will provide my reasons for inclusion/exclusion of these extensions then.  Are you actively encouraging this addition?

Regards,
Richard

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2006 6:34 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-ejzak-sipping-p-em-auth: P-Early-Media added by proxy
> 
> 
> 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: "Brett Tate" <[email-masked]>
Date: Thu, 7 Sep 2006 11:57:36 -0400

> It sounds like you are proposing an extension to the 
> header that was not originally intended.  If we added 
> such an extension, its use would also be subject to 
> local policy, both in the network and at the UA.  So 
> I don't see any answer other than "MAY" to your question.  

<snip>

> I am planning an update to the draft very soon and 
> I will provide my reasons for inclusion/exclusion of 
> these extensions then.  Are you actively encouraging 
> this addition?

No.  I'm mainly just trying to understand the draft and the
limitations/benefits of the solution.

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 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."

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.

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.

Thanks for the response.

-brett