Subject: RE: [Sipping] profile data for SIP policies

From: Simonetti Gabrielle <[email-masked]>
Date: Wed, 06 Oct 2004 15:23:41 +0200

Volker,
In response to your mail, here are some items that I think should be considered in the I-D:

1. Concerning the policies:

- It should be specified how to solve the "superposition" of the same piece of profile information. For example, if both the local profile and the user profile specify the transport protocol to be used, the UA should know which information to set in priority. In most cases, the policy applied to a specific user might restrict the policy applied to the whole domain.

- It could be useful to combine some configuration settings to form a specific configuration set. The UA could thus be provided with several configuration sets, each with different values, with the configuration sets ordered by priority. Then, depending on which configuration set the UA was able to apply, the UA would be provided with a specific behavior. This involves the specification of conditions within the profile data policies, for example to force some codec to be used in concordance to an outbound proxy (acting as RTP proxy/transcoder), or when trying to set a codec from a list, some codecs may require the device to point toward such a proxy while others may use a different one.

- In the case where the UA, for some reason, is not able to set any of the settings provided, the profile data should include a default behaviour, for example to perform some UI alert or send a network alert.

2. Concerning the different aspects of profile information:

- The following data sets would be useful:

  . An "outbound_proxy" data set, for both the local profile and the user profile

  . A "NAT_address" data set, for the local profile (in the case calls are made through a NAT)

  . A "credential" data set including the user's realm/userID/passToken, for the user profile 

- Extensibility for new features within each piece of profile information should be provided, e.g. the "media" element could be extended with a child element to specify the number of voice frame packets to be transmitted.

Thanks,
Gabrielle

> -----Original Message-----
> From: Volker Hilt [mailto:[email-masked]]
> Sent: venerdì 1 ottobre 2004 23.56
> To: Simonetti Gabrielle
> Cc: [email-masked]
> Subject: Re: [Sipping] profile data for SIP policies
> 
> 
> Simonetti Gabrielle wrote:
> > Hi,
> > Some questions on draft-ietf-sipping-session-indep-policy-00:
> > - Has the XML schema already been defined for the
> >   application/session-policy+xml type (section 4.2 of the draft)?
> 
> We are currently revising the draft (including the schema) 
> and plan to 
> submit a new version for the upcoming meeting. Please let me 
> know if you 
> have any requirements or items you would like to see in the draft.
> 
> > - How does the policy document relate to the Profile Delivery
> >   Framework: how should it be included in the device 
> configuration data?
> >   Should it be part of the Local Profile, of the User 
> Profile? Or should
> >   it be an independent document?
> 
> The two drafts clearly need to be aligned (which is what we are 
> currently doing). The goal is that policies and device 
> configuration can 
> co-exist in the same document.
> 
> The separation of the profile types (user, device, local, 
> application) 
> enables multiple entities to manage profile data. It does not 
> determine 
> the profile content or the XML schema used. Thus, an XML 
> schema could be 
> used for local profiles and for user profiles.
> 
> > - How does the policy document relate to the general configuration
> >   parameters?
> 
> Policies are part of the configuration information.
> 
> > - Actually, are the Local Profile data and User Profile data being
> >   standardized? Will a draft come out with schemas for this data?
> > 
> Again, I don't think there will be a schema for local or user profile 
> data. There will be schemas for different aspects of profile 
> information 
> (e.g. media, SIP protocol, address books) which can be used in local, 
> user, device, etc. profile types. Of course, not all schemas 
> will make 
> sense for every profile type.
> 
> -- Volker
> 
> 

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
====================================================================

_______________________________________________
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: Thu, 07 Oct 2004 19:07:24 -0400

Simonetti Gabrielle wrote:

> Volker, In response to your mail, here are some items that I think
> should be considered in the I-D:
> 
> - It should be specified how to solve the "superposition" of the same
> piece of profile information. For example, if both the local profile
> and the user profile specify the transport protocol to be used, the
> UA should know which information to set in priority. In most cases,
> the policy applied to a specific user might restrict the policy
> applied to the whole domain.

I really think this is a second order problem. Right now, we have no 
means to configure a phone in any kind of standard way. I don't see a 
need for our first stab at this to allow reconciliation of conflicting 
configuration data across multiple providers.

> . A "NAT_address" data set, for the local profile (in the case calls

How does the provider know this? THis is a very brittle configuration 
assumption. ICE makes the determination of connectivity dynamic, and 
thus there is no need for this to be included as configuration data.

-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