Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP

From: Alan Johnston <[email-masked]>
Date: Tue, 03 Nov 2009 15:09:10 -0600

All,

Here is some updated charter text for CCUS.  Comments are most welcome.

Thanks,
Alan

- - - - -

The Call Control UUI for SIP  (CCUS) working group is chartered to 
define a SIP mechanism for transporting call control related 
user-to-user (UUI) information between User Agents.

The mechanism developed in this working group is generally appropriate 
in the following situations:
1. The information is generated and consumed by an application using SIP 
during session setup but the application is 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. Multi-vendor interoperability is important.

This mechanism is not appropriate in the following situations:
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.

User data of the mechanism will be clearly marked with the application, 
encoding, semantics, and contents of the data, allowing policy to be 
applied by UAs.  The working group will define the information which 
each application must specify in a standards-track document to utilize 
the mechanism.

One important application of this mechanism is interworking with the 
ISDN User to User Information Service.  This application defined by 
ITU-T Q.931, is extensively deployed in the PSTN today, supporting such 
applications as contact centers, call centers, and automatic call 
distributors (ACDs).  A major barrier to the movement of these 
applications to SIP is the lack of a standard mechanism to transport 
this information in SIP.   For interworking with ISDN, minimal 
information about the content of the UUI is available.  In this case 
only, the content will just indicate ISDN UUI Service 1 interworking 
rather than the actual content.

Call control UUI is user information conveyed between user agents during 
call control operations.  As a result, the information must be conveyed 
with the INVITE transaction, and must survive proxy retargeting, 
redirection, and transfers.  The mechanism must utilize a minimum of SIP 
extensions as it will need to be supported by many simple SIP user 
agents such as PSTN gateways.  The mechanism must interwork with the 
existing ISDN service but should also be extensible for use by other 
applications and non-ISDN protocols.

While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI 
can be generated by a number of protocols that are not ISUP, and as such 
it is architecturally unreasonable to interwork these protocols at the 
SIP / ISUP gateway. That is, existing SIP-T approaches defined in 
RFC3372 do not meet the requirements.

Mechanisms based on the SIP INFO method, RFC2976, will not be considered 
by the working group since the UUI contents carry information that must 
be conveyed during session setup at the user agent - the information 
must be conveyed with the INVITE transaction.  The information must be 
passed with the session setup request (INVITE), responses to that 
INVITE, or session termination requests.  As a result, it is not 
possible to use INFO in these cases.

The group will produce:

- A problem statement and requirements document for implementing a SIP 
call control UUI mechanism

- A specification of the SIP extension to best meet those requirements.

Goals and Milestones
====================

Mar 10 - Problem statement and requirements document to IESG 
(Informational)
Aug 10 - SIP call control UUI specification to IESG (PS)

---

From: Leon Portman <[email-masked]>
Date: Wed, 4 Nov 2009 09:58:56 +0200

Only one comment, does it also supposed to support re-invite (for SRTP re-keying or media updates) scenarios as well?

Thanks

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Tuesday, November 03, 2009 11:09 PM
To: [email-masked]
Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP

All,

Thanks,
Alan

- - - - -

The group will produce:

Goals and Milestones
====================

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

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Nov 2009 03:18:29 -0600

I think UUI is carried during session setup and teardown, and hence
re-Invite scenario may not be applicable here.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Leon Portman
Sent: Wednesday, November 04, 2009 1:29 PM
To: Alan Johnston; [email-masked]
Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for
SIP

Only one comment, does it also supposed to support re-invite (for SRTP
re-keying or media updates) scenarios as well?

Thanks

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan Johnston
Sent: Tuesday, November 03, 2009 11:09 PM
To: [email-masked]
Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP

All,

Thanks,
Alan

- - - - -

during session setup but the application is not necessarily even SIP
aware.

information.

The group will produce:

Goals and Milestones
====================

---

From: Leon Portman <[email-masked]>
Date: Wed, 4 Nov 2009 11:31:45 +0200

Actually I was thinking that if UUI was presented during the original INVITE, if it is going to be required to be presented during RE_INVITES as well, especially if it represents some client state information

Leon

-----Original Message-----

Thanks

Leon

-----Original Message-----

All,

Thanks,
Alan

- - - - -

information.

The group will produce:

Goals and Milestones
====================

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 4 Nov 2009 12:43:41 +0100

Alan,

Do we need to make any statement about applicability of the mechanism to 3PCC situations? For example, UA A has exchanged UUI with UA B, but then is 3PCC-transferred to UA C - does UA A need to exchange UUI with UA C? From UA A's perspective it would be mid-call.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan Johnston
> Sent: 03 November 2009 21:09
> To: [email-masked]

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Nov 2009 05:44:33 -0600

Do you mean same IE that was present in initial INVITE needs to be
presented in Re-Invite as well? 

If the information does not change, then I do not see any value in
carrying the same payload in re-Invite. But if there is a new IE, then
yeah it can be presented in re-Invite.
I am not sure if there can be a new UU IE after the call is setup and
before call termination.

Sanjay

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2009 3:02 PM
To: Sanjay Sinha (sanjsinh); Alan Johnston; [email-masked]
Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for
SIP

Actually I was thinking that if UUI was presented during the original
INVITE, if it is going to be required to be presented during RE_INVITES
as well, especially if it represents some client state information

Leon

-----Original Message-----
From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2009 11:18 AM
To: Leon Portman; Alan Johnston; [email-masked]
Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for
SIP

-----Original Message-----

Thanks

Leon

-----Original Message-----

All,

Thanks,
Alan

- - - - -

information.

The group will produce:

Goals and Milestones
====================

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Nov 2009 08:56:50 -0500

> Actually I was thinking that if UUI was presented during the original INVITE, if it is going to be required to be presented during RE_INVITES as well, especially if it represents some client state…

Can you explain more about this?

The charter seems to spend its time explaining that this is governed by 
the needs for session setup. If this is a mechanism that is also 
intended for use after the session is established, then I think more 
explanation is required.

As described, this is just plain tunneling, pure and simple.
And INFO (expecially with the new Info-Package work) is yet another 
mechanism for tunneling. The rationale for not using INFO for UUI is 
that it is needed during session establishment. Clearly that doesn't 
apply after the session is established.

Of course its a mess to have two mechanisms with overlapping purposes. 
It would be silly to use two mechanisms to transport the same 
information, depending on when in the lifetime of the session the info 
was being transported. But I'm having difficulty drawing a clear 
distinction between the applicability of the two mechanisms.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Nov 2009 09:01:16 -0500

I always use 3pcc as a test case, because it presents problems almost 
every time.

Of course the problem with 3pcc is that one "side" may remain the same, 
while the other "side" is replaced. The replacement typically has no 
knowledge of the history of what went on before it joined. So there 
usually needs to be some mechanism for it to be clued in about that.

I don't know if the same is true here or not. It depends on whether the 
UUI information is viewed as transient, or as state of the session.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 4 Nov 2009 16:08:28 +0200

I will try to explain my case.

The use case for example is a customer is calling to an organization via SIP trunk with some UUI info from the hosted IVR session (business data). He is connected to an agent and then was put on hold, triggering REINVITE with updated SDP. And then transferred to another agent. Under assumption that UUI represents some kind business data state of the call (IVR selection, customer ID etc), this information has to be preserved during all session changes. It is not transient state that is delivered via INFO.
Or even more complex, the call is transferred via SIP trunk to completely another PBX as another SIP session (B2BUA scenario).

Thanks

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2009 3:57 PM
To: Leon Portman
Cc: Sanjay Sinha (sanjsinh); Alan Johnston; [email-masked]
Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 4 Nov 2009 09:47:12 -0600

This is an interesting question.  On first blush, it seems that due to  
3pcc type applications, the mechanism will need to be used in re- 
INVITEs. However, we will need to be very careful to define the  
semantics for true mid-call uses.

I don't think the charter needs to specify this much detail - the  
requirements document produced by the working group should include this.

Any comments on the charter text? I know I am looking forward to  
getting back to the mechanism discussion...

Thanks
Alan

On Nov 4, 2009, at 8:01 AM, Paul Kyzivat <[email-masked]> wrote:

> I always use 3pcc as a test case, because it presents problems  
> almost every time.
>
> Of course the problem with 3pcc is that one "side" may remain the  
> same, while the other "side" is replaced. The replacement typically  
> has no knowledge of the history of what went on before it joined. So  
> there usually needs to be some mechanism for it to be clued in about  
> that.
>
> I don't know if the same is true here or not. It depends on whether  
> the UUI information is viewed as transient, or as state of the  
> session.
>
>    Thanks,
>    Paul
>
>> presented in Re-Invite as well? If the information does not change,  
>> then I do not see any value in
>> From: Leon Portman [mailto:[email-masked]] Sent: Wednesday,  
>> November 04, 2009 3:02 PM
>> From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] Sent:  
>> Wednesday, November 04, 2009 11:18 AM
>> define a SIP mechanism for transporting call control related user- 
>> to-user (UUI) information between User Agents.
>> The mechanism developed in this working group is generally  
>> appropriate in the following situations:
>> 4. The information is expected to survive retargeting, redirection,  
>> and retargeting.
>> 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.
>> User data of the mechanism will be clearly marked with the  
>> application, encoding, semantics, and contents of the data,  
>> allowing policy to be applied by UAs.  The working group will  
>> define the information which each application must specify in a  
>> standards-track document to utilize the mechanism.
>> One important application of this mechanism is interworking with  
>> the ISDN User to User Information Service.  This application  
>> defined by ITU-T Q.931, is extensively deployed in the PSTN today,  
>> supporting such applications as contact centers, call centers, and  
>> automatic call distributors (ACDs).  A major barrier to the  
>> movement of these applications to SIP is the lack of a standard  
>> mechanism to transport this information in SIP.   For interworking  
>> with ISDN, minimal information about the content of the UUI is  
>> available.  In this case only, the content will just indicate ISDN  
>> UUI Service 1 interworking rather than the actual content.
>> call control operations.  As a result, the information must be  
>> conveyed with the INVITE transaction, and must survive proxy  
>> retargeting, redirection, and transfers.  The mechanism must  
>> utilize a minimum of SIP
>> agents such as PSTN gateways.  The mechanism must interwork with  
>> the existing ISDN service but should also be extensible for use by  
>> other applications and non-ISDN protocols.
>> it is architecturally unreasonable to interwork these protocols at  
>> the SIP / ISUP gateway. That is, existing SIP-T approaches defined  
>> in RFC3372 do not meet the requirements.
>> by the working group since the UUI contents carry information that  
>> must be conveyed during session setup at the user agent - the  
>> information must be conveyed with the INVITE transaction.  The  
>> information must be passed with the session setup request (INVITE),  
>> responses to that INVITE, or session termination requests.  As a  
>> result, it is not possible to use INFO in these cases.
>> The group will produce:
>> - A problem statement and requirements document for implementing a  
>> SIP call control UUI mechanism

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Nov 2009 10:07:23 -0600

Yeah this is a good case and for it we need re-Invite to carry it.

If it is session related data, then for transfers should it be carried
in REFER also, esp. for REFER with Replaces?

Sanjay

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Wednesday, November 04, 2009 7:31 PM
To: Sanjay Sinha (sanjsinh)
Cc: Leon Portman; Alan Johnston; [email-masked]
Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for
SIP

	Thanks,
	Paul

> 4. The information is expected to survive retargeting, redirection,
and 
> 3. SIP elements besides the UAC and UAS might be interested and
consume 
> User data of the mechanism will be clearly marked with the
application, 

> call control operations.  As a result, the information must be
conveyed 

> by the working group since the UUI contents carry information that
must

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Nov 2009 19:10:54 -0500

> Or even more complex, the call is transferred via SIP trunk to completely another PBX as another SIP session (B2BUA scenario).

So you are making the case that this is *state* that must remain 
synchronized over time, not just transient information for call 
establishment.

But that supports my argument that this is generalized 
application-application tunneling over sip.
As such it overlaps greatly with the charter for INFO.
We then end up with two mechanisms, one using headers and the other 
using bodies.
- INFO can build on the rich structure of MIME definitions
   but it can't be used until at least an early dialog is established

- The proposed UUI mechanism has to be embedded in headers,
   and has a much more limited representation mechanism built up.
   (But could you embed arbitrarily complex MIME bodies into a
   UUI header value?) It can be used earlier, and in contexts
   where INFO can't.

As best I can tell, in practice, the UUI stuff will only be used where 
the data formats are already established for use in legacy PSTN 
equipment. As that stuff gets cut over to SIP infrastructure we will be 
left with applications having to use encodings that are no longer at all 
natural. (E.g. need to find something that can encode/decode ASN.1 stuff 
in an application that uses it for nothing else.)

And this is all in spite of long resistance to using SIP for tunneling 
in general.

	Just grumbling,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Nov 2009 14:16:09 +0100

1)	"4. The information is expected to survive retargeting, redirection, and retargeting." 

"retargeting" appears twice.

2)	"For interworking with ISDN, minimal 
information about the content of the UUI is available.  In this case only, the content will just indicate ISDN UUI Service 1 interworking rather than the actual content."

This could imply that the existing protocol discriminator, which does carry information about the content, is lost. I hope that is not true.

3)	I am somewhat concerned that the focus now appears to be on SIP UA to SIP UA, rather than interworking with other signalling systems that also carry such information. Where we have a SIP UA talking to a SIP UA, For at least some of the usages where a SIP UA is talking to a SIP UA, we may well already have SIP mechanisms in place to support this. In general, we should be focussing on those existing usages transported in other protocols, and any new pure SIP usage should go through the normal SIP extension considerations. With the focus as it currently appears, we could end up spending years defining a fully proper solution, whereas I believe we need something quicker and potentially less than perfect for the SIP UA to SIP UA scenarios. Note that by SIP UA I am talking about a real SIP endpoint here, not the UA that may form part of an interworking gateway.

regards

Keith

> Sent: Tuesday, November 03, 2009 9:09 PM
> To: [email-masked]
> The Call Control UUI for SIP  (CCUS) working group is 
> chartered to define a SIP mechanism for transporting call 
> control related user-to-user (UUI) information between User Agents.
> 
> 1. The information is generated and consumed by an 
> application using SIP during session setup but the 
> application is 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.
> 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.
> 
> define the information which each application must specify in 
> a standards-track document to utilize the mechanism.
> 
> One important application of this mechanism is interworking 
> with the ISDN User to User Information Service.  This 
> application defined by ITU-T Q.931, is extensively deployed 
> in the PSTN today, supporting such applications as contact 
> centers, call centers, and automatic call distributors 
> (ACDs).  A major barrier to the movement of these 
> information about the content of the UUI is available.  In 
> this case only, the content will just indicate ISDN UUI 
> Service 1 interworking rather than the actual content.
> 
> Call control UUI is user information conveyed between user 
> agents during call control operations.  As a result, the 
> information must be conveyed with the INVITE transaction, and 
> must survive proxy retargeting, redirection, and transfers.  
> The mechanism must utilize a minimum of SIP extensions as it 
> will need to be supported by many simple SIP user agents such 
> as PSTN gateways.  The mechanism must interwork with the 
> existing ISDN service but should also be extensible for use 
> by other applications and non-ISDN protocols.
> 
> While PSTN UUI is carried in ISUP (ISDN User Part), SIP call 
> control UUI can be generated by a number of protocols that 
> are not ISUP, and as such it is architecturally unreasonable 
> to interwork these protocols at the SIP / ISUP gateway. That 
> is, existing SIP-T approaches defined in
> Mechanisms based on the SIP INFO method, RFC2976, will not be 
> considered by the working group since the UUI contents carry 
> information that must be conveyed during session setup at the 
> user agent - the information must be conveyed with the INVITE 
> transaction.  The information must be passed with the session 
> setup request (INVITE), responses to that INVITE, or session 
> termination requests.  As a result, it is not possible to use 
> INFO in these cases.
> 
> The group will produce:
> 
> - A problem statement and requirements document for 
> implementing a SIP call control UUI mechanism
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Nov 2009 14:17:29 +0100

I would argue that the 3pcc case is covered by the statement that the information must survive transfer.

Talking more generally about the 3pcc case in the charter means that we could end up discussing scenarios of information transfer during the call. 

regards

Keith

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, November 04, 2009 2:01 PM
> Cc: Leon Portman; [email-masked]
> I always use 3pcc as a test case, because it presents 
> problems almost every time.
> 
> Of course the problem with 3pcc is that one "side" may remain 
> the same, while the other "side" is replaced. The replacement 
> typically has no knowledge of the history of what went on 
> before it joined. So there usually needs to be some mechanism 
> for it to be clued in about that.
> 
> I don't know if the same is true here or not. It depends on 
> whether the UUI information is viewed as transient, or as 
> state of the session.
> 
> 	Thanks,
> 	Paul
> 
> > Subject: RE: [dispatch] Updated CCUS Charter Text - Call 
> Control UUI 
> > for SIP
> > 
> > INVITE, if it is going to be required to be presented during 
> > RE_INVITES as well, especially if it represents some client state 
> > information
> > 
> > Leon
> > 
> > Subject: RE: [dispatch] Updated CCUS Charter Text - Call 
> Control UUI 
> > for SIP
> > 
> [mailto:[email-masked]] On 
> > Behalf Of Leon Portman
> > Subject: Re: [dispatch] Updated CCUS Charter Text - Call 
> Control UUI 
> > for SIP
> > 
> > Subject: [dispatch] Updated CCUS Charter Text - Call 
> Control UUI for 
> > SIP
> > 
> > All,
> > 
> application using 
> screening 
> > the
> allowing 
> > policy to be applied by UAs.  The working group will define the 
> > information which each application must specify in a 
> standards-track 
> with the 
> > ITU-T Q.931, is extensively deployed in the PSTN today, supporting 
> > such applications as contact centers, call centers, and 
> automatic call 
> this case 
> > retargeting, redirection, and transfers.  The mechanism 
> must utilize a 
> > minimum of SIP
> > 
> > While PSTN UUI is carried in ISUP (ISDN User Part), SIP 
> call control 
> > UUI
> > 
> > considered

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Nov 2009 14:17:58 +0100

I concur with Paul here.

Keith 

> Sent: Wednesday, November 04, 2009 1:57 PM
> To: Leon Portman
> Cc: [email-masked]
> Control UUI for SIP
> The charter seems to spend its time explaining that this is 
> governed by the needs for session setup. If this is a 
> mechanism that is also intended for use after the session is 
> established, then I think more explanation is required.
> 
> And INFO (expecially with the new Info-Package work) is yet 
> another mechanism for tunneling. The rationale for not using 
> INFO for UUI is that it is needed during session 
> establishment. Clearly that doesn't apply after the session 
> is established.
> 
> information, depending on when in the lifetime of the session 
> the info was being transported. But I'm having difficulty 
> drawing a clear distinction between the applicability of the 
> two mechanisms.
> 
> 	Thanks,
> 	Paul
> 
> > Leon
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Nov 2009 14:20:35 +0100

Given that the prime purpose of SIP is to support a session description of the media, which presumably you want to do the SRTP rekeying for, I would argue that the CCU is not the appropriate mechanism to support this. I suspect your SRTP rekeying scenario would also expect to be terminated by some interworking gateways, whereas the CCU information is meant to pass through such gateways.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: Wednesday, November 04, 2009 7:59 AM
> Only one comment, does it also supposed to support re-invite 
> (for SRTP re-keying or media updates) scenarios as well?
> 
> Thanks
> 
> Leon
>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 09 Nov 2009 00:40:47 -0600

Keith,

Thank you for your careful read and comments on the charter text.

See my comments below.  Your last point below is very important and it 
would be great to get some opinions from others.

Thanks,
Alan

> "retargeting" appears twice.

Yes, and the information must survive if the retargeting happens twice, 
too ;-)

> This could imply that the existing protocol discriminator, which does carry information about the content, is lost. I hope that is not true.

No, we will not loose the protocol discriminator.  I didn't think it 
provided that much information about the content, but whatever 
information it provides will be available.

> 3)	I am somewhat concerned that the focus now appears to be on SIP UA to SIP UA, rather than interworking with other signalling systems that also carry such information. Where we have a SIP UA talking to a SIP UA, For at least some of the usages where a SIP UA is talking to a SIP UA, we may well already have SIP mechanisms in place to support this. 

The previous charter text had an ISDN interworking focus, but the 
consensus in the DISPATCH meeting was that there was strong interest in 
UUI outside ISDN interworking.

> In general, we should be focussing on those existing usages transported in other protocols, and any new pure SIP usage should go through the normal SIP extension considerations. With the focus as it currently appears, we could end up spending years defining a fully proper solution, whereas I believe we need something quicker and potentially less than perfect for the SIP UA to SIP UA scenarios. Note that by SIP UA I am talking about a real SIP endpoint here, not the UA that may form part of an interworking gateway.
>   
This is an important scope issue for the charter.

I understand your concern.  I am hopeful that we will not end up with a 
complicated solution and that the mechanism will work for both ISDN and 
non-ISDN approaches.

I think that enough people care strongly about the ISDN interworking 
case that if the mechanism discussions bog down, that the WG could 
recharter to deliver two mechanisms - one for ISDN interworking and 
another more  general mechanism.  However, I'd prefer not to start with 
that approach until we have proven that a single mechanism is too complex.

Do others have an opinion on this?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Nov 2009 11:19:28 -0500

Comment at end

Alan Johnston wrote:

>> 3)    I am somewhat concerned that the focus now appears to be on SIP 
>> UA to SIP UA, rather than interworking with other signalling systems 
>> that also carry such information. Where we have a SIP UA talking to a 
>> SIP UA, For at least some of the usages where a SIP UA is talking to a 
>> SIP UA, we may well already have SIP mechanisms in place to support this. 
> 
>> In general, we should be focussing on those existing usages 
>> transported in other protocols, and any new pure SIP usage should go 
>> through the normal SIP extension considerations. With the focus as it 
>> currently appears, we could end up spending years defining a fully 
>> proper solution, whereas I believe we need something quicker and 
>> potentially less than perfect for the SIP UA to SIP UA scenarios. Note 
>> that by SIP UA I am talking about a real SIP endpoint here, not the UA 
>> that may form part of an interworking gateway.
>>   

My concern all along has been that if one focuses on ISDN interworking,
then what happens when the user that used to have an ISDN device decides 
to upgrade to a new SIP device, and we then have e2e sip connectivity?

The likely scenario is that *nothing* will change. The new device will 
be expected to emulate the behavior of the ISDN device including using 
the ISDN-style UUI mechanism, even though it is not "natural" in an 
all-sip environment.

OTOH, if you start with a UUI mechanism that is "sip-friendly" but can 
also be translated to the ISDN mechanisms when necessary, then the 
migration is much smoother. And you might avoid having ISDN-isms 
lingering after ISDN itself is gone.

The argument I hear against this is that the ISDN encoding itself is 
opaque - pure tunneling of bits. But the protocol discriminator is 
supposed to deal with that isn't it? The values that the discriminator 
can take on, and the encoding of the remainder for each discriminator 
value but be standardized somewhere.

I think a "natural" encoding for sip would have to consider each 
discriminator value, and what an appropriate encoding would be for that 
case.

	Thanks,
	Paul