Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension

From: [email-masked]
Date: Thu, 7 Oct 2010 00:29:51 +0800

Sure, the type of the media streams is decided by the Offer, usually is 
the user of the UA sending the INVITE/Replaces, as you said.

But I said in my example is some different. Please see the flows(I copied 
them from Paul's mail, and I add some new notes):

X -------------------- Y
       voice/video

//Y send voice/video session to X. As Y does not know X support HD video, 
so he send the call from a normal UE.

moving to (2):

   X -------------------- Y
   |       voice
   |
   +--------------------- Z
         HD video

//Then, X tell Y that his UE support HD video and want to establish the HD 
video stream. Please note that, X tell Y by voice, while not by any 
signalling.

//Then, Y use a new equipment(Z) to transfer the video stream from the 
orignal session. The voice stream is still between X and Y.

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

"Worley, Dale R (Dale)" <[email-masked]> 
发件人:  [email-masked]
2010-10-01 04:08

收件人
"[email-masked]" <[email-masked]>, Paul Kyzivat 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [sipcore] About Join and Replaces Headers: //Replaces header's 
extension

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of 
[email-masked] [[email-masked]]

Nowadays, I am considering requirements about media streams tranfering 
between user's UEs, such as transfering active video stream from one 
normal UE to one HD(High Definitive) device.

This function is similar to 3GPP's IUT(Inter UE Transfer). But I'd like to 
seek a end to end solution, with out SCC_AS's 3pcc call control.

I think we could do one potential extension for Replaces header, as:

The Replaces header could be added with a indication.
For examle, transfer video to HD device, while save the audio at the 
orignal device:
The new party(new device) send a INVITE(the Offer with video stream) with 
Replaces header, with the indication. Then the UAS of this INVITE can just 
transfer the media streams(video) to the new session, and save the other 
streams in the origianl session (by a new Re-INVITE to just mute the 
transfered media streams).
________________________________________

However, you must beware that in SIP which rendering devices of a UA are 
used to render particular media streams is under the control of the user 
of the UA, not of the remote UAs that it communicates with.  Therefore, 
while an incoming INVITE/Replaces may provide HD video, it is not the 
choice of the sender of the INVITE/Replaces that the HD video stream be 
rendered on the HD video device.  (Indeed, the sender of the 
INVITE/Replaces has no certain knowledge that the recipient UA possesses 
an HD video device.)  It is the choice of the user of the recipient UA (or 
more likely, his configuration of the UA) that determines that the offered 
HD video stream is to be rendered on a particular rendering device.

Within that architecture, there can be no use for such an indication on 
the Replaces header.

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 6 Oct 2010 15:37:11 -0400

________________________________________
From: [email-masked] [[email-masked]]

X -------------------- Y
      voice/video

//Y send voice/video session to X. As Y does not know X support HD video, so he send the call from a normal UE.

moving to (2):

  X -------------------- Y
  |       voice
  |
  +--------------------- Z
        HD video

//Then, X tell Y that his UE support HD video and want to establish the HD video stream. Please note that, X tell Y by voice, while not by any signalling.

//Then, Y use a new equipment(Z) to transfer the video stream from the orignal session. The voice stream is still between X and Y.
________________________________________

(BTW, you are using the same symbols for the *users* and the *UAs* here, and that creates confusion.)

If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the original dialog (between UAs X and Y) *must* be terminated by X when it accepts the INVITE-with-Replaces.

What UA Z should do is send an INVITE-with-Join to X (offering only video), and then UA Y should do a re-INVITE to remove its video stream from its dialog with X (leaving the audio stream).  At that point, X is "mixing" two dialogs, but each media stream (audio and video) is used by only one leg of the conference, so X doesn't need to do any actual mixing processing.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Oct 2010 17:37:30 -0400

Why is Y inflicting issues with this equipment on X? This is better 
resolved by Y working with Z, while doing only ordinary things with X.

Specifically, Y can invite Z, and then eventually do a reinvite to X 
with the mixture of streams from Y and Z that it prefers.

Or if Z is smart enough, and Y isn't, I guess Z could do invite/Replaces 
to both X and Y, and fix things up.

It really depends on where the devices with intelligence are located. 
But counting on X to help, when you don't control X, seems like a bad 
idea to me.

	Thanks,
	Paul

---

From: [email-masked]
Date: Thu, 7 Oct 2010 16:01:11 +0800

> If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the 
> original dialog (between UAs X and Y) *must* be terminated by X when
> it accepts the INVITE-with-Replaces.

I knew it. But my proposal here is to do extension for the Replaces 
header. And you may refer to the first mail of this thread for details. 
 
> What UA Z should do is send an INVITE-with-Join to X 

I MUST point out that Join header's semantics is not proper for this use 
case.

> (offering only video), 

By my experience, INVITE-with-Join(only downlink video) *could* be treated 
as a video duplication request. But how about INVITE-with-Join(only 
bidirectional video)? 
In fact, no like audio stream, there's no physical meaning for video 
streams' mixing. So, if UA Z send an INVITE-with-Join, with only 
bidirectional video, UA X may not know how to handle it.(So, I feel that 
RFC3911 need clarification!)

> and then UA Y should do a re-INVITE to remove its video 
> stream from its dialog with X (leaving the audio stream). 

Let's analyse what would happen after UA Y sending a re-INVITE to remove 
it's video stream from it's dialog. As the use case of 
"INVITE-with-Join(only bidirectional video)" is meaning, as I showed in 
the previous section, we may analyse a similar one: "INVITE-with-Join(only 
downlink video)" .

Not like audio mixing, the session can be downgraded from three-party to 
two-party, when one leave the session. If the vedio between X and Y is 
over, I think the duplicated one between X and Z would lose it's vedio 
source.

Gao

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 7 Oct 2010 12:28:45 -0400

> it accepts the INVITE-with-Replaces.

I knew it. But my proposal here is to do extension for the Replaces header. And you may refer to the first mail of this thread for details.
________________________________________

You are focusing on the fact that you want to replace the user's connection to a particular media stream.  But the Replaces header specifies whether or not a *dialog* is replaced by another *dialog*, not whether a particular media rendering is replaced by another.  The only way that you can associate two dialogs while keeping them both in existence is with Join.

I think your usage would be helped by adding extension attributes to SDP so that which media stream was to replace/be mixed with which other media streams (in a Join) could be specified.

Dale

---

From: [email-masked]
Date: Fri, 8 Oct 2010 00:39:05 +0800

Paul,

Currently, I have more than ways to solve this problem(the Replaces 
header's extension is just one choice). But no matter how to arrange the 
signalling flows, the key issue here is show the "replace" semantics and 
relationship between the replacing vedio stream(the new one) and the 
replaced vedio stream(the original one).

And IMO, this "replace" semantics is not exist in any current defined SIP 
features, even the Replaces header. I think we might talk about this 
background first. That is, no matter how we solve it, whether we need any 
kind of *new features* to solve this use case.

Thanks,

Gao

> > //Y send voice/video session to X. As Y does not know X support HD
> video, so he send the call from a normal UE.
> >
> > moving to (2):
> >
> >    X -------------------- Y
> >    |       voice
> >    |
> >    +--------------------- Z
> >          HD video
> >
> > //Then, X tell Y that his UE support HD video and want to 
> establish the HD video stream. Please note that, X tell Y by voice, 
> while not by any signalling.
> >
> > //Then, Y use a new equipment(Z) to transfer the video stream from
> the orignal session. The voice stream is still between X and Y.
> > If user Y (using UA Z) sends an INVITE-with-Replaces to X, then 
> the original dialog (between UAs X and Y) *must* be terminated by X 
> when it accepts the INVITE-with-Replaces.
> >
> > What UA Z should do is send an INVITE-with-Join to X (offering 
> only video), and then UA Y should do a re-INVITE to remove its video
> stream from its dialog with X (leaving the audio stream).  At that 
> point, X is "mixing" two dialogs, but each media stream (audio and 
> video) is used by only one leg of the conference, so X doesn't need 
> to do any actual mixing processing.
> >
> > Dale

---

From: [email-masked]
Date: Fri, 8 Oct 2010 00:51:48 +0800

> You are focusing on the fact that you want to replace the user's 
> connection to a particular media stream.  But the Replaces header 
> specifies whether or not a *dialog* is replaced by another *dialog*,
> not whether a particular media rendering is replaced by another. 
> The only way that you can associate two dialogs while keeping them 
> both in existence is with Join.

Yes. This is the current defintion for Replaces header and Join header.

> 
> I think your usage would be helped by adding extension attributes to
> SDP so that which media stream was to replace/be mixed with which 
> other media streams (in a Join) could be specified.
> 

I once evaluated SDP extension. But the controlling semantics for the use 
case is about session control, while not session/streams attributes. So, I 
think the extension should be signalling control oriented, while not 
SDP(description) oriented.

So, I think the potential extension should be located in SIP headers, 
while not SDP.

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Oct 2010 14:04:20 -0400

Gao,

Sometimes there is value in strategic vagueness/ambiguity.
To date that has been the case with sip around what media are used and 
what it means when they are used. And its especially the case with 
Replaces and Join.

There is nothing in SIP that says where or how media are rendered. If a 
device has more than one potential device sip says nothing about which 
one. (E.g. using the handset or speaker on a speaker phone.)

In the case of join, as Dale has said, it is really only about joining 
the *dialogs*. There is a presumption that this will result in something 
reasonable happening with the media streams, but its not specified. (An 
exception to this is, I think, conferencing, which does talk about this 
to some extent.)

Going beyond just letting the UAs do what they think is right is a *big* 
step. (The conferencing stuff was a lot of work, and I don't know too 
much about it.)

You might consider whether you could use conferencing controls to get 
the kind of result you want. Otherwise, I think you have a big task and 
had better investigate if anybody else wants to work on it.

	Thanks,
	Paul

On 10/7/2010 12:51 PM, [email-masked] wrote:
> I once evaluated SDP extension. But the controlling semantics for the
> use case is about session control, while not session/streams attributes.
> So, I think the extension should be signalling control oriented, while
> not SDP(description) oriented.
>

---

From: [email-masked]
Date: Fri, 8 Oct 2010 09:03:48 +0800

Paul,

> had better investigate if anybody else wants to work on it. 

Yes. I agree that it would be a *big* step, if we want to do such feature 
enhancement for SIP.

To be honest, we have accomplished the conferencing controls way for this 
use case. But this is a little complex, as there should be a control 
focus(usually is the conference AS) and the media server. So, I try to 
find an end to end lightweight solution.

As we found out, such e2e feature is not exist now. So, I'd like to know 
are there other people also interested in this work?

Thanks,

Gao

---

From: [email-masked]
Date: Fri, 8 Oct 2010 09:13:43 +0800

Paul and Dale,

In fact, some of our new designed call flows for the IUT(inter-UEs 
transfering) use the Join header frequently. But I think the semantics of 
the Join header in a lot of use case is not clear now, as showed in the 
previous mails.

Then, what about my comments on the "RFC3911's potential clarification"? 
And I think this work is relative urgent for me.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Oct 2010 22:38:14 -0400

Gao,

I still don't understand one aspect here:

Is this a case of
- a smart device with a limited display wanting to bring in
   a dumb device with a good display into an existing call?

- a smart device with a good diplay wanting to inject its
   capabilities into an existing call preempting a dumb
   device with limited capabilities?

- something else?

If its a smart device with limited display capabilities, I think it can 
just use 3pcc to control the device with the good display, as a slave 
media server to itself. In that case I think there are no unsolved issues.

	Thanks,
	Paul

On 10/7/2010 9:03 PM, [email-masked] wrote:
> Yes. I agree that it would be a *big* step, if we want to do such
> feature enhancement for SIP.
>
> To be honest, we have accomplished the conferencing controls way for
> this use case. But this is a little complex, as there should be a
> control focus(usually is the conference AS) and the media server. So, I
> try to find an end to end lightweight solution.
>

---

From: [email-masked]
Date: Fri, 8 Oct 2010 13:55:17 +0800

Paul,
 
>    device with limited capabilities?

Both of the two ways are working for its specific case.

While, my intention is to find a more general solution, not depending on 
the capability of the UA(especially which UA).

> media server to itself. In that case I think there are no unsolved 
issues.

Yes, there's no need for extension using this way. But the way itself is 
not general enough.
I'll evaluate do I really need a general way or just a way as you 
suggested.

Thanks,

Gao