Subject: [sipcore] About Join and Replaces Headers:

From: [email-masked]
Date: Sat, 25 Sep 2010 16:27:13 +0800

By RFC3911 and RFC3981, the handling object of Join and Replaces headers 
is dialog:

RFC3911: The Join header is used to logically join an existing SIP dialog 
with a new SIP dialog.
RFC3981: The Replaces header is used to logically replace an existing SIP 
dialog with a new SIP dialog. 

Dialog has meaning is signalling level, not for service level. So, if we 
use Join and Replaces's semantics to build call service, the real handling 
object should be session.

For normal usage, such as:
A and B has a session;
C send a INVITE with Join header to A;
A build a basic conference for the three-party.

But if we consider some more complex use case, there might be problems. A 
and B has a audio and video call, and C just want to join to the audio 
part(part of the streams). 

Abstractly, the problem is how can we express the semantics, such as Join 
part of the streams in current session or Replaces part of the streams in 
current session? 

Thanks,

Gao

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

--------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2010 09:24:53 -0400

Gao,

I don't understand the problem you are raising.
An INVITE with Join or Replaces has its own offer/answer to negotiate 
the media used. If the new party wants to use less (or more) media than 
the existing call it can just negotiate that.

	Thanks,
	Paul

On 9/25/2010 4:27 AM, [email-masked] wrote:
> RFC3911: The Join header is used to logically join an existing SIP
> RFC3981: The Replaces header is used to logically replace an existing
> SIP dialog with a new SIP dialog.
>
> use Join and Replaces's semantics to build call service, the real
> handling object should be session.
>
> But if we consider some more complex use case, there might be problems.
> A and B has a audio and video call, and C just want to join to the audio
> Abstractly, the problem is how can we express the semantics, such as
> Join part of the streams in current session or Replaces part of the
> streams in current session?
>
> Thanks,
>
> Gao
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked]
Date: Mon, 27 Sep 2010 23:44:08 +0800

Paul,

> the existing call it can just negotiate that.

Yes, the new party can put less(or more) m= lines in the SDPs. But the 
UAS's behavior for the new party's INVITE request is not clear.

Considering Join header, there's no such defintion in RFC3911.

Thanks,

Gao

---

From: [email-masked]
Date: Tue, 28 Sep 2010 00:04:41 +0800

Hi Paul,

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).

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2010 13:29:23 -0400

> Considering Join header, there's no such defintion in RFC3911.

That's not surprising, since Join is an extension to 3261.
The semantics come from the join spec.

It seems those say that when you get an invite with Join, you should 
create a conference. And then do mixing as required. If the conferencing 
of the new call doesn't require mixing, that's fine too.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2010 14:13:33 -0400

IIUC, you are talking about (1):

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

moving to (2):

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

Is that right?

And then you are looking for the signaling that will allow that to happen?

An INVITE with Join by Z to X would probably result in (3):

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

while an INVITE with Replaces by Z to X would probably result in (4):

   X -------------------- Z
          video

ISTM that (3) is pretty reasonable, after which X can drop its video stream.

I don't see that anything new is required to achieve this.

	Thanks,
	Paul

On 9/27/2010 12:04 PM, [email-masked] wrote:
> 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.
>
> 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).
>
> Thanks,
>
> Gao
>

---

From: [email-masked]
Date: Tue, 28 Sep 2010 08:46:40 +0800

Paul,

> IIUC, you are talking about (1):

Yes.

> An INVITE with Join by Z to X would probably result in (3):

The video between X and Y would be still exsit, and would not be replaced, 
after Z has the HD video.

The requirement is to transfer the video from Y to Z.

> while an INVITE with Replaces by Z to X would probably result in (4):

By current Replaces header's semantics, the dialog between X and Y would 
be teared down.

So, my intention is to do extension for it.

> ISTM that (3) is pretty reasonable, after which X can drop its video 
stream.

If Y can only afford just one video stream at the same time(there's some 
hardware based devices are so), Y can not maintain the two video 
streams(one normal and another HD) at the same time.

Thanks,

Gao

---

From: [email-masked]
Date: Tue, 28 Sep 2010 08:53:27 +0800

Hi,

> The semantics come from the join spec.

Yes, the Join's semantics should be defined in join spec(RFC3911).

> of the new call doesn't require mixing, that's fine too.

But I really didn't find the detailed defintion for Join header, about 
when to do mixing or not, in the join spec.

Maybe, some people would say thai it is intuitionistic. But there are 
people feel that it is not intuitionistic :)

Thanks,

Gao

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 30 Sep 2010 16:08:01 -0400

________________________________________
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.

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