Subject: [Sipping] Static and dynamic policies requirement

From: Volker Hilt <[email-masked]>
Date: Mon, 28 Jul 2003 17:31:22 -0400

Jonathan,

would it make sense to include requirements for the support of static 
and dynamic policies in the policy requirements draft? These 
requirements could look like the following:

REQ-POL-14: The solution should allow the specification of dynamic 
policies on a call-by-call basis.

REQ-POL-15: The solution should allow the specification of static 
policies, which are applicable to certain calls for a given time.

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 12:07:44 -0400

Yes, I think it makes sense.

To back this up a little, we have applications that clearly require 
dynamic policies, and ones where static is far preferable. For 
policies where the information doesn't change, dynamic policies are 
expensive - causing continuous transmission of the information during 
call setup, and possible adding to call setup latencies.

Take, for example, whether or not to use a media intermediary. In many 
cases, the desire for this is constant. For example, where an 
enterprise has a NAT which needs to be traversed. In that case, it can 
be done with a static policy. This policy would inform the UA of the 
TURN relay its supposed to contact in advance of the call. In other 
cases, its dynamic. For example, in a roaming scenario, whether a 
local relay is used or not varies on a call by call basis depending 
where the user is. ALso, if there are multiple operators on the call 
path, and each has a policy for a media relay (though I think this is 
an awful thing to do in general), thats not known till the call is made.

So, for the case of media relays, we have cases where static is what 
we want, and where dynamic is what we want. One of the issues I had 
been struggling with for a bit was the apparent overlap between 
ICE/TURN and session policy (assuming dynamic only, which is how the 
current document is structured). Both seemed to be ways for media to 
flow through an intermediary. The difference is exactly static vs. 
dynamic. WHen static policies are used, the user is informed about the 
relay (i.e., TURN server) through provisioning. When dynamic policies 
are used, the user is informed about the relay through the dynamic 
session policy mechanism. In this case TURN isn't needed to provision 
the relay; the proxy does it directly (though I suppose session policy 
could give out a turn relay address - need to think about that).

Allowed codecs are another example where a static session policy is 
probably better, since the information is not likely to change on a 
call by call basis.

So, the question then, is what additional requirements do we have for 
supporting static policies? I would say:

* The mechanism must provide the ability to inform the UA about the 
set of session policies when the device starts up

* The mechanism must allow the provider to change the static policies 
at least a few times a day

* The mechanism must allow the static policies to vary on a user by 
user basis

* The mechanism must provide a way to inform the client about changes 
in session policies when they occur

An interesting question is what we mean by "provider". Is this the 
home provider (i.e., owner of the namespace in which the UAs AOR 
resides) or visiting one or both?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Volker Hilt <[email-masked]>
Date: Wed, 30 Jul 2003 18:00:53 -0400

Jonathan Rosenberg wrote:

> cases, the desire for this is constant. For example, where an enterprise 
> has a NAT which needs to be traversed. In that case, it can be done with 
> a static policy. This policy would inform the UA of the TURN relay its 
> supposed to contact in advance of the call. In other cases, its dynamic. 
> For example, in a roaming scenario, whether a local relay is used or not 
> varies on a call by call basis depending where the user is. ALso, if 
> there are multiple operators on the call path, and each has a policy for 
> a media relay (though I think this is an awful thing to do in general), 
> thats not known till the call is made.
> 
Yes, true.

> probably better, since the information is not likely to change on a call 
> by call basis.
> 
An interesting question (admittedly more relevant for a solution than 
for the requirements) is: how does the UA actually apply static 
policies? Are these policies worked into the SDP announcement before it 
is send out, i.e. the SDP announcement contains the changes requested by 
the policy? Or does the UA create its regular SDP announcement and adds 
a separate policy object (i.e. an MFO), so that the original 
announcement and the static policies remain separate?

The first option seems makes sense since it is a little simpler and 
saves a couple of bits. Furthermore, I'm not sure what the benefits of 
exposing the static policies to proxies along the call path are. 
However, letting the UA send out the SDP announcement and the policy in 
separate objects seems to be a more transparent approach.

A related issue is: how are the static policies of the UA receiving an 
SDP offer handled? A simple solution to this would be that the UA just 
applies its static policies to the SDP answer (or would add a 
corresponding MFO object to the answer). An interesting issue is that 
the static policies of the caller and callee are now covered without the 
need for additional policy negotiation during call set up (assuming that 
there are no dynamic policies). Only transit networks would not have the 
chance to specify static policies in this case.

> * The mechanism must provide the ability to inform the UA about the set 
> of session policies when the device starts up
> 
> * The mechanism must allow the provider to change the static policies at 
> least a few times a day
> 
> * The mechanism must allow the static policies to vary on a user by user 
> basis

The mechanism should certainly allow a provider to specify different 
static policies for different (local) users. The policies might for 
example depend on the services a specific user has subscribed to.

Maybe it would also make sense to specify different static policies for 
different call destinations (i.e. remote users). For example, it would 
make sense to apply a static policy for NAT traversal only to those 
calls that actually need to cross the NAT (i.e. are not staying inside 
the local network).

> * The mechanism must provide a way to inform the client about changes in 
> session policies when they occur

I'm not sure if we need this requirement. Static policies could have a 
timeout after which they need to be renewed. If a static policy is 
changed, all UAs will learn the new policy at the time they renew their 
policies. During the transition period, some UAs will use the old policy 
and some will use the new policy. If this is not acceptable, a proxy can 
still request the use of new policy via the dynamic mechanism. This of 
course assumes that dynamic policies can override static policies (which 
seems to be reasonable in general).

> An interesting question is what we mean by "provider". Is this the home 
> provider (i.e., owner of the namespace in which the UAs AOR resides) or 
> visiting one or both?
> 
Hmmm, I guess both could have policies that are of interest to the user. 
The home provider could have policies needed for a certain service (e.g. 
always route the media stream to the call recording service I have 
subscribed to) whereas the visiting provider might have policies 
relevant for the access network (e.g. a restricted set of codecs).

-- Volker

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 31 Jul 2003 09:03:14 -0500

> * The mechanism must provide the ability to inform the UA 
> about the set of session policies when the device starts up

> * The mechanism must provide a way to inform the client about 
> changes in session policies when they occur

Would these lead to requirements for SIP telephony devices? Plus countelss
other..

Maybe it makes sense after all to have the I-D elevated to a SIPPING WG item
:-)

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, July 30, 2003 11:08 AM
> To: Volker Hilt
> Cc: sipping
> Subject: [Sipping] Re: Static and dynamic policies requirement
> 
> To back this up a little, we have applications that clearly 
> require dynamic policies, and ones where static is far 
> preferable. For policies where the information doesn't 
> change, dynamic policies are expensive - causing continuous 
> transmission of the information during call setup, and 
> possible adding to call setup latencies.
> 
> Take, for example, whether or not to use a media 
> intermediary. In many cases, the desire for this is constant. 
> For example, where an enterprise has a NAT which needs to be 
> traversed. In that case, it can be done with a static policy. 
> This policy would inform the UA of the TURN relay its 
> supposed to contact in advance of the call. In other cases, 
> its dynamic. For example, in a roaming scenario, whether a 
> local relay is used or not varies on a call by call basis 
> depending where the user is. ALso, if there are multiple 
> operators on the call path, and each has a policy for a media 
> relay (though I think this is an awful thing to do in 
> general), thats not known till the call is made.
> 
> So, for the case of media relays, we have cases where static 
> is what we want, and where dynamic is what we want. One of 
> the issues I had been struggling with for a bit was the 
> apparent overlap between ICE/TURN and session policy 
> (assuming dynamic only, which is how the current document is 
> structured). Both seemed to be ways for media to flow through 
> an intermediary. The difference is exactly static vs. 
> dynamic. WHen static policies are used, the user is informed 
> about the relay (i.e., TURN server) through provisioning. 
> When dynamic policies are used, the user is informed about 
> the relay through the dynamic session policy mechanism. In 
> this case TURN isn't needed to provision the relay; the proxy 
> does it directly (though I suppose session policy could give 
> out a turn relay address - need to think about that).
> 
> Allowed codecs are another example where a static session 
> policy is probably better, since the information is not 
> likely to change on a call by call basis.
> 
> So, the question then, is what additional requirements do we 
> have for supporting static policies? I would say:
> 
> * The mechanism must provide the ability to inform the UA 
> about the set of session policies when the device starts up
> 
> * The mechanism must allow the provider to change the static 
> policies at least a few times a day
> 
> * The mechanism must allow the static policies to vary on a 
> user by user basis
> 
> * The mechanism must provide a way to inform the client about 
> changes in session policies when they occur
> 
> An interesting question is what we mean by "provider". Is 
> this the home provider (i.e., owner of the namespace in which 
> the UAs AOR
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>