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

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

On 10/6/2010 3:37 PM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn]
>
> 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
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>