Subject: [dispatch] Call Control UUI for SIP Issue

From: Alan Johnston <[email-masked]>
Date: Wed, 02 Sep 2009 16:51:50 -0500

Based on feedback during my presentation in Stockholm, I think I  have a 
good idea how to modify the proposed charter text.

One issue perhaps needs a little more discussion so I'd like to kick 
that off here.

The question is, for some kind of information, when should a new SIP 
header field be used, when should this UUI transport mechanism be used, 
and when should a proprietary header field be used.  It seemed like we  
had some differing opinions on this with respect to UUI.  I think which 
approach depends on the information being transported.  Here's my take 
on this:

New SIP header field to transport user information.  I think a new SIP 
header field is needed when:
1. SIP behavior is changed
2. The information is generated and consumed at the SIP layer by SIP 
elements
3. SIP elements besides the UAC and UAS might be interested and consume 
the information
4. There are specific privacy or cross-RAI issues involved with the 
information being transported
5. Interoperability is important

UUI Transport mechanism.  I think this mechanism is suitable when:
1. The information is generated and consumed by an application using SIP 
during session setup but not necessarily even SIP aware.
2. SIP behavior is unchanged
3. Generally only the UAC and UAS are interested in the information
4. The information is expected to survive retargeting, redirection, and 
retargeting
5. SIP elements may need to apply policy about passing and screening the 
information
6. Multivendor interop is important

Proprietary header field (the old P-header)
1. The information is only of interest to UAC and UAS
2. No SIP elements need apply policy to the information
3. Single vendor or closed system application

If we disagree strongly on these points, lets have that discussion now, 
and this may help us formulate charter text about the mechanism itself.

Thanks,
Alan

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Sep 2009 11:41:56 -0400

Alan,

I agree it is a good idea to partition the use cases in this way.

I'm a little confused about the criteria you give for UUI below, because
- I thought one of the reasons originally given for the proposed
   mechanism was that it was needed before call establishment for
   purpose of making routing decisions. If so, that means that it
   impacts sip behavior.

- Also, isn't the applying of policy by sip elements also a change
   to sip behavior?

	Thanks,
	Paul

Alan Johnston wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 03 Sep 2009 14:27:30 -0500

Paul,

Thanks for your comments - see mine below.

Thanks,
Alan

>   purpose of making routing decisions. If so, that means that it

The information does need to be rendered and parsed at the time of call 
establishment - that is why it is carried in an INVITE.  But it is not 
really used for SIP routing decisions.  I suppose it could be used in 
deciding whether to answer a call or reject it, but again I'd say that 
is not SIP behavior.

> - Also, isn't the applying of policy by sip elements also a change

No, the policy is just whether to pass the information element up the 
protocol stack or whether to block its  transport within a domain.  The 
policy isn't, because this type of UUI is present, do some special SIP 
operation or invoke a special SIP feature.

So, here's an example of what I mean by "changing SIP behavior".  Lets 
say we had this UUI mechanism but we didn't have the Refer-Sub: no 
header field.  One could argue that suppressing the REFER implicit 
subscription is just a piece of user information, which is generated by 
the UAC and consumed by the UAS, so why not transport it using the UUI 
mechanism.  Well, this information changes SIP behavior in that no 
NOTIFY is sent.  Hence, this would not be a suitable usage for this UUI 
mechanism.  

>
>     Thanks,
>     Paul
>
> Alan Johnston wrote:
>> Based on feedback during my presentation in Stockholm, I think I  
>> have a good idea how to modify the proposed charter text.
>>
>> header field be used, when should this UUI transport mechanism be 
>> used, and when should a proprietary header field be used.  It seemed 
>> like we  had some differing opinions on this with respect to UUI.  I 
>> think which approach depends on the information being transported.  
>> Here's my take on this:
>>
>> New SIP header field to transport user information.  I think a new 
>> SIP header field is needed when:
>> 3. SIP elements besides the UAC and UAS might be interested and 
>> consume the information
>> 1. The information is generated and consumed by an application using 
>> SIP during session setup but not necessarily even SIP aware.
>> 4. The information is expected to survive retargeting, redirection, 
>> and retargeting
>> 5. SIP elements may need to apply policy about passing and screening 
>> the information
>> If we disagree strongly on these points, lets have that discussion 
>> now, and this may help us formulate charter text about the mechanism 
>> itself.
>>
>> Thanks,
>> Alan
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Sep 2009 10:55:09 -0400

Alan,

Based on your answers, I'm ok with your categorization of cases.

	Thanks,
	Paul