Subject: RE: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00

From: "Dusan Mudric" <[email-masked]>
Date: Mon, 14 Jul 2003 09:21:01 -0400

User preferences related to service negotiation between subscriber and service/internet provider, like SLA, are good candidates for out-of-a-call negotiation. These policies, like type of services, quality of services, pricing for QoS and so on, would be negotiated very infrequently and would be applied on every subsequent call.

Regards,
Dusan Mudric.

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]] 
Sent:	Monday, July 14, 2003 5:14 AM
To:	Volker Hilt
Cc:	Miguel A. Garcia; [email-masked]
Subject:	Re: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00

inline.

Volker Hilt wrote:

> Jonathan, Miguel,
> 
> Miguel A. Garcia wrote:
> 
>> First, I am missing a general requirement that describes the general
>> mechanism that we want. If you consider the General Requirements,
>> there are  many of them explaining different aspects of the solution,
>> but none that describes generally what is needed. I would expect
>> something on these lines:
>>
>> "A mechanism that provides SIP proxies with the ability to convey
>> session related policies to SIP User Agents".
> 
> 
> The goals of the policy draft have been motivated quite nicely with a
> number of very convincing examples. The requirements for these examples
> are reflected in some of the Policy Requirements (examples are
> REQ-POL-4, REQ-POL-5 and REQ-POL-7 to REQ-POL-13).
> 
> I was wondering if it is possible to separate the requirements specific
> to these examples (e.g. requesting the use of a different codec,
> different media addresses, firewalls, QoS) from requirements of the
> general policy mechanism (the mechanism needed to exchange policy
> information between UAC, proxies and UAS). This mechanism could be
> defined independent of a certain use. It could enable a proxy to request
> the modification of any aspect of a session description.
> 
> The requirements for certain use cases of the session policy mechanism
> could then be defined in a separate section/document. This separation
> seems to be more extendible than combining the requirements of the
> policy exchange mechanism and use cases.

I think that makes sense. I'll restructure the document so that there 
are some general mechanism requirements, indpendent of the particular 
policy type, and then some requirements for specific policies (codec 
policy, intermediary policy, etc.).

> 
>> The thing is that I don't foresee dynamic changes in policies,
>> depending on the traffic in the network. One could do it, of course,
>> but requires some extra administration or having some sort of monitor
>> that acts upon thresholds.
> 
> 
> How do you envision the proxy to change policies within an active call?
> This sounds a little like re-INVITEs send out by the proxy (something a
> proxy can't do!).

I think what Miguel is saying is that they wouldnt need to change in 
the middle of a call. In fact, the policies would be fairly static and 
would change infrequently. When they do change, they don't need to do 
so synchronous with any particular call attempt. In that case, you can 
use mechanisms totally outside of a call. It becomes more of a 
provisioning problem, and things like xcap would be more applicable.

> 
>> Instead I foresee another scenario where the administrator has
>> certain fixed policies that do not change often. For instance, an 
>> administrator could permanently disallow the G.711 codec because of
>> the high bandwidth. I think this is an important issue to discuss,
>> because the solution may go in one or another direction depending on
>> the rate of the changes in policy. I would suggest to add a
>> requirement regarding the expected changes in the policies.
> 
> 
> The session policies will probably not depend on highly dynamic factors
> such a load (congestion control comes to mind here) but more on things
> like network configuration and user preferences. These issues can easily
> be considered by a proxy on a call to call basis.

The point Miguel is making, and its important one, is it wouldn't even 
be on a call-by-call basis.

This is really the first major issue we need to tackle (we'll discuss 
during the sipping meeting today). Do we think session policies need 
to be specified on a call-by-call basis? Certain policies tend to need 
to be call-by-call. For example, using an intermediary for relaying 
media. That needs to be call-by-call since the port to send to will be 
computed on a call-by-call basis. Other policies, such as codecs to 
use, arguably don't change much at all, and may not need to be 
computed on a call-by-call basis.

So, the question is whether we think there are two mechanisms - one 
outside of a call, and one inside, or just one. One point to be made 
is that, if you have a single in-call mechanism, that could be used to 
cover both static and dynamic requirements. Thus, you would have just 
one mechanism (thats good). But, it might be inefficient for wireless, 
sending the same policeis to the UA over and over again (thats bad). 
Then again, sigcomp might fix it (thats good).

So, its not obvious to me what the right direction is.

Thoughts?

-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

_______________________________________________
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

_______________________________________________
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