Subject: [Sipping] comments on draft-hilt-sipping-policy-package-01

From: "Bob Penfield" <[email-masked]>
Date: Wed, 22 Mar 2006 11:46:24 -0500

My main concern with session-dependant policies is the number of messages required to set up a session, and its affect on so-called "post-dial delay".

The spec allows the UA to cache the policy server URI. Could the policy server URI be learned as a part of session-independant policy configuration rather than first INVITE failure?

The document explicity forbids transmitting policy decisions in the signaling path. However, the number of messages could be reduced if the policy decision could be passed back in the 488 response, at least when the proxy is authoritaive for the domain of the UAC. Of course, we would need a mechanism to assure that an authorized proxy provided the policy decision. 

I am also concerned that the policy server may require more information to make a policy decision. For example, the target domain of the request may impact the policy decision. If the proxy and/or policy server can determine that a media relay will be required based on the target of the request, that impacts whether or not the policy decision needs to include the media relay address and port(s). The policy server in the terminating domain might use the Via headers to determine whether or not a media relay is required. I suggest that portions of the SIP message that proxies might use (e.g. method, Request-URI, From, To, Via, Contact, Route, Record-Route) also be included in the data sent to the policy server.
 
cheers,
(-:bob
_______________________________________________
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: Volker Hilt <[email-masked]>
Date: Thu, 23 Mar 2006 00:41:50 -0600

Bob Penfield wrote:
> My main concern with session-dependant policies is the number of 
> messages required to set up a session, and its affect on so-called 
> "post-dial delay".
>  
Assuming that the policy server URI is cached in the UA, the additional 
round trip time is really one subscribe/notify cycle to a (typically) 
local policy server. So the actual delay added for this seems relatively 
small. In particular, since this cycle can be done in parallel with 
other operations for an INVITE (e.g. a DNS lookup). This parallelization 
is not possible if the policy decision is returned in a 488.

> The spec allows the UA to cache the policy server URI. Could the policy 
> server URI be learned as a part of session-independant policy 
> configuration rather than first INVITE failure?
>  
That's a good point. Yes. Once the policy server URI is in the cache (no 
matter how it got there) it will be used.

This possibility should probably be spelled out explicitly in the draft.

> The document explicity forbids transmitting policy decisions in the 
> signaling path. However, the number of messages could be reduced if the 
> policy decision could be passed back in the 488 response, at least when 
> the proxy is authoritaive for the domain of the UAC. Of course, we would 
> need a mechanism to assure that an authorized proxy provided the policy 
> decision.
>  
The problem with the 488 approach is that it only works in the case of 
outbound INVITEs that carry an offer. It does not work if the offer is 
in a response (i.e. not in the INVITE) and for policies that apply to 
the answer. In addition, 488 doesn't work well for incoming INVITEs 
either since the proxy can't pass the policy decision to the local UA. 
The proxy could pass the policy decision to the remote UA in a 488 but 
that would mean policies are sent across the entire network and the 
remote UA may not accept a policy decision from an unauthorized proxy at 
the far end. Another issue is that 488 requires the proxy to examine the 
session description. I.e. the session description can't be encrypted or 
use something else than SDP. Finally, 488 doesn't support policy 
decision updates. With 488 everything is set when the session is 
established.

Regarding the additional messages, 488 also adds an additional 
INVITE/488 cycle in case it kicks in. Even though a subscribe based 
mechanism requires more messages, the overall delay added is probably 
rather small.

> I am also concerned that the policy server may require more information 
> to make a policy decision. For example, the target domain of the request 
> may impact the policy decision. If the proxy and/or policy server can 
> determine that a media relay will be required based on the target of the 
> request, that impacts whether or not the policy decision needs to 
> include the media relay address and port(s). The policy server in the 
> terminating domain might use the Via headers to determine whether or not 
> a media relay is required. I suggest that portions of the SIP message 
> that proxies might use (e.g. method, Request-URI, From, To, Via, 
> Contact, Route, Record-Route) also be included in the data sent to the 
> policy server.
>  
I can see that the request URI might be relevant for a policy decision. 
This could probably be conveyed to the policy server in an event 
parameter in the SUBSCRIBE. I'm not so convinced that the subscribe 
should contain a fragment of the INVITE message.

Thanks,

Volker