Subject: [Sipping] Encoding of User-to-User Information

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 14 Feb 2008 14:48:52 +0100

Hi

Current version of the draft-johnston-sipping-cc-uui-03.txt is not very
clear about the encoding of the uui-data content. The ETSI TISPAN
specification on User-to-User signalling has clarified the content
encoding rule as follow:

------

The content of the uui-data field of the User-to-User header shall start
with the first octet being the protocol discriminator and followed by
the user information octets. 

The format of the uui-data field shall be the hexadecimal representation
of binary data coded in ascii alphanumeric characters. For example, the
8- bit binary value 0011- 1111 is 3F in hexadecimal. To code this in
ascii, one 8- bit byte containing the ascii code for the character '3'
(0011- 0011 or 033H) and one 8-bit byte containing the ascii code for
the character 'F' (0100- 0110 or 046H) are required. For each byte
value, the high-order hexadecimal digit is always the first digit of the
pair of hexadecimal digits. The ascii letters used for the hex digits
shall always be capital form.

For example:

User-to-User:
05C81031313232333334343535363637373838FA08303900064630E9E0;encoding=hex
------

Are there any comments on the quoted encoding rule? 

Can this encoding rule be included in the draft?

Greetings,
Denis Alexeitsev
_______________________________________________
Sipping mailing list  http://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: "Alexeitsev, D" <[email-masked]>
Date: Thu, 14 Feb 2008 15:21:20 +0100

Hi
 
It is an option, but I don't think, that the SIP elements between the
UUI-source and UUI-target would be very interested in accessing the
protocol discriminator information. Only in this case a separate
parameter really makes sense to me.
 
The end points would have no problems interpreting the uui-data with the
protocol discriminator included.
 
Greetings,
Denis Alexeitsev

  _____  

Von: Nachum Frid [mailto:[email-masked]] 
Gesendet: Donnerstag, 14. Februar 2008 15:08
An: Alexeitsev, Denis; [email-masked]
Betreff: RE: Encoding of User-to-User Information

Another option is to provide the User-to-User  Protocol discriminator as
a parameter, such as:

User-to-User:
05C81031313232333334343535363637373838FA08303900064630E9E0;pd=4     for
IA5 characters

See below the User-user IE  from Q.931

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexeitsev, D
Sent: Thursday, February 14, 2008 15:49
To: [email-masked]
Subject: [Sipping] Encoding of User-to-User Information

Hi 

------ 

For example: 

User-to-User:

Greetings, 
Denis Alexeitsev 

  _____  

This email and any files transmitted with it are confidential material.
They are intended solely for the use of the designated individual or
entity to whom they are addressed. If the reader of this message is not
the intended recipient, you are hereby notified that any dissemination,
use, distribution or copying of this communication is strictly
prohibited and may be unlawful.

If you have received this email in error please immediately notify the
sender and delete or destroy any copy of this message

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 14 Feb 2008 15:29:41 +0100

You seem to be working from the assumption that UUI is only used from
PSTN gateway and carries information that was in the PSTN (including the
protocol discriminator).

I do not remember that restriction being in the original draft.

If a SIP entity generates this header, how does it identify and
distinguish its particular brand of UUI from another other particular
brand of UUI.

Regards

Keith

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexeitsev, D
	Sent: Thursday, February 14, 2008 2:21 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [Sipping] Encoding of User-to-User Information

	Hi
	 
	It is an option, but I don't think, that the SIP elements
between the UUI-source and UUI-target would be very interested in
accessing the protocol discriminator information. Only in this case a
separate parameter really makes sense to me.
	 
	The end points would have no problems interpreting the uui-data
with the protocol discriminator included.
	 
	Greetings,
	Denis Alexeitsev

________________________________

	Another option is to provide the User-to-User  Protocol
discriminator as a parameter, such as:

	User-to-User:

	

	________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alexeitsev, D
	Sent: Thursday, February 14, 2008 15:49
	To: [email-masked]
	Subject: [Sipping] Encoding of User-to-User Information

	Hi 

	Current version of the draft-johnston-sipping-cc-uui-03.txt is
not very clear about the encoding of the uui-data content. The ETSI
TISPAN specification on User-to-User signalling has clarified the
content encoding rule as follow:

	------ 

	The content of the uui-data field of the User-to-User header
shall start with the first octet being the protocol discriminator and
followed by the user information octets. 

	The format of the uui-data field shall be the hexadecimal
representation of binary data coded in ascii alphanumeric characters.
For example, the 8- bit binary value 0011- 1111 is 3F in hexadecimal. To
code this in ascii, one 8- bit byte containing the ascii code for the
character '3' (0011- 0011 or 033H) and one 8-bit byte containing the
ascii code for the character 'F' (0100- 0110 or 046H) are required. For
each byte value, the high-order hexadecimal digit is always the first
digit of the pair of hexadecimal digits. The ascii letters used for the
hex digits shall always be capital form.

	For example: 

	User-to-User:

	Greetings, 
	Denis Alexeitsev 

________________________________

	This email and any files transmitted with it are confidential
material. They are intended solely for the use of the designated
individual or entity to whom they are addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
dissemination, use, distribution or copying of this communication is
strictly prohibited and may be unlawful.
	
	If you have received this email in error please immediately
notify the sender and delete or destroy any copy of this message

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 14 Feb 2008 15:37:38 +0100

Hi

No, I don't have this assumption. The encoding rules as proposed are
clear on how to encode and what to include in to the uui-data parameter.
The encoding=hex indicates that data encoded according to this rules.
The protocol discriminator is preserved, what else is missing?

Greetings,
Denis Alexeitsev

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 14 Feb 2008 19:36:57 +0100

Having now looked at the recent -03 version

http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-uui-03.txt

Instead of the -02 I reviewed previously, I see we do now have an
encoding parameter. 

My concern is that usages are known between endpoints. This current text
which you are modifying specifies that the encoding is in hex digits as
per ISDN. 

In my reading it fails to require that the first octet is the ISDN
protocol discriminator, no matter where it came from. It merely says if
the message contains a protocol discriminator how it is encoded. I
suspect that it needs a statement that the protocol discriminator for
this encoding is the one defined in ITU-T Recommendation Q.931.

Does the encoding parameter need an IANA registry? How are other value
allocated?

Regards

Keith

> -----Original Message-----
> From: Alexeitsev, D [mailto:[email-masked]] 
> Sent: Thursday, February 14, 2008 2:38 PM
> To: [email-masked]
> Cc: DRAGE, Keith (Keith)
> Subject: AW: [Sipping] Encoding of User-to-User Information
> 
> Hi
> 
> No, I don't have this assumption. The encoding rules as 
> proposed are clear on how to encode and what to include in to 
> the uui-data parameter.

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 15 Feb 2008 15:14:38 +0100

Hi

>this encoding is the one defined in ITU-T Recommendation Q.931.

Here is the quote from the current draft version. It clearly states,
although in brackets, that the protocol discriminator is included in the
hex string. The text I proposed makes the encoding description more
normative. Implementers will not have to search for an ISDN spec to
realise UUI in SIP.  

"The only defined parameter for the User-to-User header field is the
encoding parameter. "encoding=hex" is used to indicate that the UUI
information is encoded as hex digits per the ISDN specification
(including the protocol discriminator).  Other encoding methods of
encoding may also be standardized."

allocated?

I want to avoid registering ISDN UUI protocol discriminators in IANA. 

Who needs a UUI protocol discriminator as a uui-param anyway? Please
make a usage example .

Greetings,
Denis Alexeitsev

---

From: Bernd Lamparter <[email-masked]>
Date: Fri, 15 Feb 2008 16:26:57 +0100

Dear all,

some time ago we filed the following draft. We hope it is interesting
for the sipping group. Any feedback is welcome.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Duplicate a SIP session
	Author(s)       : P. Imai, et al.
	Filename        : draft-lamparter-sipping-session-duplication-00.txt
	Pages           : 16
	Date            : 2007-12-19

Session duplication copies media of an ongoing communication session
from one device to another.  After duplication the two devices have
independent control over this media.  This is in particular useful
for one-way media like broadcast IPTV or Video-on-Demand.  This
document describes the general methods and specifies the signaling
and media flows for providing this service using the Session
Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lamparter-sipping-session-duplication-00.txt

BR,
Bernd

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: David R Oran <[email-masked]>
Date: Sun, 17 Feb 2008 07:18:31 -0500

> for the sipping group. Any feedback is welcome.
I think you're going to need to explain better how this is different  
form call transfer. You explain it's different from a 3-way conference  
by saying the old participant is dropped following the operation, but  
that's exactly what transfer does.

Also, while this may deal at least in part with the SIP-level  
synchronization, your IPTV use case requires re-synchronization of the  
media sessions as well. Of particular concern/interest is if you have  
a media control session (e.g. with mrcp or mediactrl). How does the  
target of this operation learn the current state (e.g. play/pause,  
SMPTE time codes of the playout).

I for one would like to see a cogent description of the use cases and  
the requirements rather than trying to puzzle through whether this  
particular mechanism makes sense for what you're trying to do.

Cheers, DaveO.

> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
> London W3 6BL | Registered in England 2832014
>
>

---

From: Bernd Lamparter <[email-masked]>
Date: Fri, 29 Feb 2008 13:56:17 +0100

Dear David,

thanks for your feedback.

Perhaps I can clarify the scenario:
I think there are two scenarios which are similar to the session
duplication: Conference call and call transfer.
- In the conference call all parties are part of one sessions, whereas
in the duplication their are two independent sessions after the
duplication. I.e. both terminals can control their sessions on their own
(e.g. start/stop/pause).
- In the call transfer an ongoing session is transferred to the second
terminal and the old terminal is disconnected. In duplication both have
an own session after the duplication.

If the duplication can be implemented without new headers are other
changes to RFCs, I'm happy to to that. But I don't see a possibility how
the second UE could tell a server that a particular session should be
duplicated for him.

On the re-synchronisation you are right, that has to be described in a
later version of the draft.

Ciao,
Bernd

-- 
Dr. Bernd Lamparter                   [email-masked]
Senior Research Staff Member          Tel.: +49 6221 4342 150
NEC Europe Ltd.                       Fax.: +49 6221 4342 155
NEC Laboratories Europe
Network Division
Kurfürstenanlage 36
69115 Heidelberg, Germany
http://www.netlab.nec.de/

Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 15:29:38 +0200

Hello,

I agree that the purpose and functionality of the new header is quite unclear. The only description regarding what the recipient should do with the header, seems to be in the Overview section:

This can be used to enable the duplication of a video-on-demand
   session or a broadcast session from one device to another.  For
   instance Alice and Bob are watching a soccer match on the big TV-set.
   But Alice has to leave and would like to see the match on her SIP
   enabled mobile phone.  Bob instructs the SIP user agent of the TV-set
   to send a SIP REFER request with the DUPLICATION variant to Alice's
   UA providing the SIP-URI of the soccer match.  Assuming Alice's
   permission, Alice's UA then establishes a SIP session with the
   provider of the soccer match.

So from now on, if Bob e.g. pauses the stream, is it paused also in Alice's UA? The same if Bob changes the TV channel to tennis, does Alice continue with soccer? If the answer is no, as you seem to indicate in your previous response, then what purpose this new header has?

BR,
Jari  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernd Lamparter
Sent: 29 February, 2008 14:56
To: David R Oran; [email-masked]
Subject: Re: [Sipping] Session duplication draft

Dear David,

Perhaps I can clarify the scenario:
I think there are two scenarios which are similar to the session
duplication: Conference call and call transfer.
- In the conference call all parties are part of one sessions, whereas in the duplication their are two independent sessions after the duplication. I.e. both terminals can control their sessions on their own (e.g. start/stop/pause).
- In the call transfer an ongoing session is transferred to the second terminal and the old terminal is disconnected. In duplication both have an own session after the duplication.

If the duplication can be implemented without new headers are other changes to RFCs, I'm happy to to that. But I don't see a possibility how the second UE could tell a server that a particular session should be duplicated for him.

On the re-synchronisation you are right, that has to be described in a later version of the draft.

Ciao,
Bernd

David R Oran schrieb:
>> 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
>

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