Subject: [Sipping] draft-johnston-sipping-cc-uui-03.txt

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 15 May 2008 17:50:14 +0200

Hi,

The UUI draft was recently added to the 3GPP dependency list. In order
to boost the progress of the work I'd like to start the discussion on
the still open issues and understand what is needed to be done to push
the draft to the RFC status

Last mail thread about the draft
http://www.ietf.org/mail-archive/web/sipping/current/msg15115.html was
finished with no conclusion on the encoding details.

To have this clarified - is the encoding clarification made in the
http://www.ietf.org/mail-archive/web/sipping/current/msg15091.html
acceptable? If not, what are the counter proposals?

Greetings,
Denis Alexietsev

_______________________________________________
Sipping mailing list  https://www.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: "Mary Barnes" <[email-masked]>
Date: Fri, 16 May 2008 12:36:11 -0500

Hi Denis,
 
From a WG perspective, there are currently no plans to progress the
document. Per the SIPPING WG charter, we need to first understand and
agree the requirements before we agree a solution. And, if the solution
requires a new header, as currently suggested in the document, that work
must be agreed and completed in the SIP WG.   
 
IMHO, with my chair hat off, the requirements are not clear to me and
given that this is for the support of ISDN "services", is this not
something that should be considered in the BLISS WG?  I'd like to see
more use cases for this header and consider whether we need to be
emulating the ISDN service or if there isn't an alternative more SIP
friendly way to support the services for which this new header is
proposed. 
 
Regards,
Mary. 

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexeitsev, D
Sent: Thursday, May 15, 2008 10:50 AM
To: [email-masked]
Subject: [Sipping] draft-johnston-sipping-cc-uui-03.txt

Hi, 

Last mail thread about the draft
http://www.ietf.org/mail-archive/web/sipping/current/msg15115.html
<http://www.ietf.org/mail-archive/web/sipping/current/msg15115.html>
was finished with no conclusion on the encoding details.

To have this clarified - is the encoding clarification made in the
http://www.ietf.org/mail-archive/web/sipping/current/msg15091.html
<http://www.ietf.org/mail-archive/web/sipping/current/msg15091.html>
acceptable? If not, what are the counter proposals?

Greetings, 
Denis Alexietsev

---

From: Alan Johnston <[email-masked]>
Date: Fri, 16 May 2008 13:56:51 -0500

Mary Barnes wrote:
> agree the requirements before we agree a solution. And, if the 
> solution requires a new header, as currently suggested in the 
> document, that work must be agreed and completed in the SIP WG.   
>  
Hi Mary,

Thanks for the comments on the draft.  We have tried to have a 
discussion of the requirements and usages in the draft - perhaps we need 
to add a bit more.

I do not think it belongs in BLISS - the interop problem is that the 
transport for the information does not exist - it is not as if there are 
multiple ways of doing this.  The way this is done today is that contact 
centers are not migrating to SIP as they should - not a good place to be.

We have given a lot of thought about more SIP friendly ways to do this.  
However, this is the conclusion we came to:  user to user information is 
so broad that many SIP header fields have various types of information.  
However, the user to user information in this case is from another 
protocol, ISDN, and hence does not map in terms of content and 
semantics.  And, whenever we come  up with a new case of some 
information with clear content and semantics, we just create a new SIP 
header field with an appropriate name.  I think it would be silly for 
SIP to try to transport all manner of interesting information into a 
generic header field.

This is why we have taken the approach - there is a very clear need in 
the industry for this ISDN user to user transport at call setup, and 
there is not a need for a generic SIP header field for non-ISDN information.

Thanks,
Alan

>  
> Regards,
> Mary.
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Alexeitsev, D
> *Sent:* Thursday, May 15, 2008 10:50 AM
> *To:* [email-masked]
> *Subject:* [Sipping] draft-johnston-sipping-cc-uui-03.txt
>
> Hi,
>
> _http://www.ietf.org/mail-archive/web/sipping/current/msg15115.html_ 
> _http://www.ietf.org/mail-archive/web/sipping/current/msg15091.html_ 
> ------------------------------------------------------------------------
>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 16 May 2008 14:14:59 -0500

Hi Alan,

(Chair hat totally off)

On your last point (I've snipped the rest), how is this different than
the Application Invocation in the User agent concept in the the service
identification document?:
http://tools.ietf.org/html/draft-ietf-sipping-service-identification-01 

And how is the ISDN specific case different that the P-Asserted-Service
header?  I know your documents suggests that URI won't work, but that
had to do with retargetting, whereas the P-Asserted-Service header
should be preserved during retargetting.

My questions may well be because I haven't looked at Q.931 specs in over
15 years. Can you tell us which pages/section to look at in the 345 page
referenced spec to better understand the function of the UUI? 

Thanks,
Mary.   

----snipped by Mary----

This is why we have taken the approach - there is a very clear need in
the industry for this ISDN user to user transport at call setup, and
there is not a need for a generic SIP header field for non-ISDN
information.

Thanks,
Alan

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 19 May 2008 10:51:27 +0200

Hi Marry,
the description of the User to User information element is in Q.931 clause 4.5.30

Here the copy of the clause without the tables.

4.5.30	User-user
The purpose of the User-user information element is to convey information between ISDN users. This information is not interpreted by the network, but rather is carried transparently and delivered to the remote user(s).
The User-user information element is coded as shown in Figure 4-36 and Table 4 26. There are no restrictions on content of the user information field.
In SETUP, ALERTING, CONNECT, DISCONNECT, RELEASE and RELEASE COMPLETE messages, the User-user information element has a network dependent maximum size of 35 or 131 octets. The evolution to a single maximum value is the long term objective; the exact maximum value is the subject of further study.
In USER INFORMATION messages sent in association with a circuit-mode connection, the User-user information element has a network dependent maximum size of 35 or 131 octets. For USER INFORMATION messages sent in a temporary or permanent user-user signalling connection, the user information field contained inside this information element has a maximum size equal to the maximum size of messages defined in clause 3, that is 260 octets.
NOTE - The User-user information element is transported transparently by an ISDN between a call originating entity, e.g. a calling user and the addressed entity, e.g. a remote user or a high layer function network node addressed by the call originating entity. 

The Element is buit off:

1. Octet = element name
2. Octet = Length of user-user contents
3. Octet = Protocol discriminator
4. Octet and following = User information

Within Q.763 ISUP we have additional Parameter fields in clause 3.60 and 3.61 
A User-to-user indicators Protocolelement (indicating which service is used) and the User-to-user information (containing the DSS1 information).

The User to User Servic itself is described within Q.737.1, User-to-user signalling (UUS) for Network Signalling and in Q.957.1, User-to-User Signalling (UUS) for DSS1/ISDN.

There are also some requirements documents ITU-T Recommendation 
I.257.1 (1995), Additional information transfer supplementary services: User-User Signalling.
ITU-T Recommendation Q.87.1 (1993), Functions and information flows for services in the ISDN; Stage 2 description for additional information transfer supplementary services: User to-User Signalling (UUS).

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Mary Barnes
> Gesendet: Freitag, 16. Mai 2008 21:15
> An: Alan Johnston
> Cc: [email-masked]; Alexeitsev, Denis
> Betreff: Re: [Sipping] draft-johnston-sipping-cc-uui-03.txt
> 
> Hi Alan,
> 
> (Chair hat totally off)
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 19 May 2008 13:15:17 -0500

My comments on this draft.

While Q.931 UUI is terribly un-sexy and boring, it is probably one of those things
that we ought to support.

I find the proposed solution (i.e., to use a new header) to be the best choice. I find
the MIME body to be the least desireable. The URI *could* work, if the loose-route
thing ever gets solved.

In any case, what I find somewhat strange and disconcerting with this document, is that
instead of explaining what UUI is (with a reference to Q.931 for example), and explain the
generic need, it picks a very arcane ACD application with redirection as the example.

I would suggest that you modify the draft to "start from the beginning" and explain UUI.
Show an example with no redirection (e.g., two PSTN gateways). After that, you can explain 
the special consideration with redirection, which in my mind, is slighlty orthogonal (but
your suggestion on implementation are quite useful).

Cheers

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 20 May 2008 16:05:56 +0200

Hello Francois

Your comments reflect exactly my position, except for aesthetics, that
are subjective anyway. 

Would SIPPING be the right group to progress the draft, or should it be
SIP or even BLISS?

Greeting,
Denis Alexeitsev

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 20 May 2008 09:10:25 -0500

As I said before, the SIPPING WG must first agree on the requirements
for the solution. As Francois suggests, the requirements (and the
objective of the documented solution) are not yet clear in the current
document. Once SIPPING WG agrees the requirements, the solution work
would be completed in the SIP WG (if meeting the requirements requires
normative SIP changes).  

Regards,
Mary
SIPPING WG co-chair 

-----Original Message-----
From: Alexeitsev, D [mailto:[email-masked]] 
Sent: Tuesday, May 20, 2008 9:06 AM
To: Audet, Francois (SC100:3055); [email-masked]; Barnes, Mary
(RICH2:AR00)
Cc: [email-masked]
Subject: AW: [Sipping] draft-johnston-sipping-cc-uui-03.txt

Hello Francois

Greeting,
Denis Alexeitsev