Subject: Re: [Sipping] Session-independent Policy Draft

From: Volker Hilt <[email-masked]>
Date: Tue, 22 Feb 2005 09:03:15 -0500

Walter,

thanks much for your comments!

Here are some more thoughts on policy documents (maybe I should have 
included this in my initial mail - sorry). One way for structuring a 
policy format could be to actually have two schemas:
1. a basic schema (BSPF): the goal for this schema is to enable 
interoperability by providing a minimal set of policy elements that are 
commonly needed.
2. an extension to this basic schema (something along the lines of a 
"Rich Session Policy Format"): this extension can provide more session 
policy elements that are generally useful but may be specific to certain 
environments or user agents.

Of course other (and proprietary) extensions can be defined too.

First of all I would like to know if this is a reasonable approach. The 
follow up question would then be to determine what should be part of the 
basic schema and what could go into an extension? Which of the items 
below could go into the basic format and which into an extension?

Thanks,

Volker

Goix Walter wrote:
> Volker,
> 
> Out of your list of open issues, there are some of them that we as an
> operator consider to be relevant, such as:
> 
>    o  maximum number of sessions: it is pretty difficult for an operator
> to control the max number of sessions allowed by an endpoint, which is
> usually user-agent dependent. From the provider point of view, it is
> appreciable to configure the handling of a "call waiting"-like service,
> so that a user - no matter his user agent - could be enabled or not to
> receive a second call while in a session
> 
>    o  outbound proxy: there are various techniques to provide a user
> agent with an outbound proxy, but certainly a SIP way of doing it would
> avoid dependency on access technology or local network configuration,
> improving nomadicity scenarios.
> 
>    o  SIP methods
>    o  SIP option tags
>    o  body format
> For these issues, a provider may be interested, based on user profile,
> in restricting the use of SIP messages. 
> 
>    o  SIP transport protocol: it may be essential in some cases to force
> the user agent to connect through some transport protocol based on the
> network infrastructure. Without such a parameter and DNS techniques that
> may default to a specific transport, providing such configuration will
> certainly give major flexibility for the provider to handle its pool of
> user agents.
> 
> For most of the remaining issues, such parameters can be more easily
> controlled by the provider either through the SIP or transport
> infrastructure.
> 
> As for SIP-related issues, event package configuration (wether one EP is
> allowed or not) may also be considered for a service provider.
> Optionally, max body size may be interesting as well, especially when
> TCP or TLS are used as a transport protocol, to avoid huge payloads to
> be carried over the signaling link.
> 
> Walter
> 
> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Volker Hilt
>>Sent: Monday, February 21, 2005 5:30 PM
>>To: sipping
>>Cc: gonzalo Camarillo
>>Subject: [Sipping] Session-independent Policy Draft
>>
>>
>>Folks,
>>
>>the updated session-independent policy draft 
>>(http://www.ietf.org/internet-drafts/draft-ietf-sipping-sessio
> 
> n-indep-policy-02.txt) 
>   defines a completely revised and simplified XML schema for session 
> policies. This new format only covers very few policy elements, which 
> all concern media aspects.
> 
> Do we want to restrict the basic policy format to these elements? Are 
> there other elements that should be part of the basic format (e.g. max 
> no streams, max no sessions)? Elements that have been proposed are 
> listed in Section 5.3.16 of the draft. Do we want to add elements that 
> cover aspects besides media issues (e.g. allowed SIP methods, SIP option
> 
> tags).
> 
> Comments and feedback are greatly appreciated.
> 
> Thanks,
> 
> Volker
> 
> 
> _______________________________________________
> 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
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.
> 
> ====================================================================
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please send an e_mail to
> [email-masked]. Thank you
> ====================================================================
> 

-- 
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: Goix Walter <[email-masked]>
Date: Tue, 22 Feb 2005 12:40:19 +0100

Volker,

   o  SIP methods
   o  SIP option tags
   o  body format

Walter

n-indep-policy-02.txt) 

tags).

Thanks,

Volker