Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //some points

From: [email-masked]
Date: Sat, 9 Oct 2010 19:13:25 +0800

I find some time to list some of the points *might* need clarification.

1. As we know if the INVITE with Join's streams are less than the original 
session, only the requested streams should be mixxed(if they are suitable 
for mixxing, such as audio, instant message). But how about the Join party 
then send a Re-INVITE to add streams, while the original session has such 
added streams? 
//Personal viewpoint: The UAS should do mix for the added streams. 

2. And how about the added streams(considering the Re-INVITE can be sent 
from the Join party, or between the original two parties) are not in the 
original session? 
//Personal viewpoint: The UAS should not do mix for such streams.
One new question: Then, how would be the signalling of the request for the 
mix for such new media type streams?

3. If the stream types between the Join part and UAS is more, Re-INVITE 
between the origanl two party should also trigger mixxing for the added 
streams, if the added streams are in the stream types between the Join 
part and UAS.

4. How about the streams(such as video) which are not proper for mixxing, 
if the INVITE with Join has such streams? 

5. Further, is the behavior for UAS related to such streams's 
bidirectional or unidirectional attributes? 
//It seams that we have agreed this point for video. But point 4&5 should 
be media type specific.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================
----- 转发人 高扬140197/user/zte_ltd 时间 2010-10-09 18:36 -----

高扬140197/user/zte_ltd
2010-10-07 00:14

收件人
"Worley, Dale R (Dale)" <[email-masked]>
抄送
Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [sipcore] About RFC3911(Join header)'s potential error:

I'd like to emphasize that I also think there should be no 
conference/mixing resources for the showed use case, as I said in the 
previous mail.

But I think what we said was not defined clearly in the RFC3911. And I 
also think it is hardly to do any deduction to get the rules we discussed.

So, it is not a question like "how should it be?", but a question like 
"where is it defined".

Thanks,

Gao

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

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

收件人
Paul Kyzivat <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [sipcore] About RFC3911(Join header)'s potential error:

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

I think the works you are concerned about already are consistent with
the scenario you raise. Specifically,

> and assign any mixing or conferencing resources necessary to complete 
the join

includes the case where no mixing or conferencing resources are necessary.
_______________________________________________

I think that Paul is correct here.  If two dialogs go to a server and are 
joined at the server, and both dialogs are sendonly at the server, then 
"mixing" is very simple: the one source (generated by the server) is 
duplicated as RTP to each dialog's remote end.

In practice, one might say that this "does not allocate mixing resources". 
 OTOH, for some implementations, this duplication of the media stream may 
require the allocation of a mixing resource, if no other component of the 
server can perform the duplication.

I do not see this as a problem that needs to be solved.

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: Paul Kyzivat <[email-masked]>
Date: Sat, 09 Oct 2010 12:05:49 -0400

IMO all the things you mention *are* and *should be* out of scope for
sip, at least in general.

They all seem to be in the category of defining services and features on
top of sip. If you want that then there should be some additional
negotiation of such services/features.

	Thanks,
	Paul

On 10/9/2010 7:13 AM, [email-masked] wrote:
> 1. As we know if the INVITE with Join's streams are less than the 
> original session, only the requested streams should be mixxed(if they 
> are suitable for mixxing, such as audio, instant message). But how about 
> the Join party then send a Re-INVITE to add streams, while the original 
> session has such added streams?
> One new question: Then, how would be the signalling of the request for 
> the mix for such new media type streams?
> 
> 4. How about the streams(such as video) which are not proper for 
> mixxing, if the INVITE with Join has such streams?
> 
> //It seams that we have agreed this point for video. But point 4&5 
> should be media type specific.
> 
> Thanks,
> 
> Gao
> 
> *高扬140197/user/zte_ltd*
> 	Re: [sipcore] About RFC3911(Join header)'s potential error:链接 
> <Notes://NJMAIL01/48257169002DF8EE/DABA975B9FB113EB852564B5001283EA/B79995A849150874482577AE007046AD>
> 
> 
> 	
> 
> 
> 
> 
> 
> *"Worley, Dale R (Dale)" <[email-masked]>*
> In practice, one might say that this "does not allocate mixing 
> resources". OTOH, for some implementations, this duplication of the 
> media stream may require the allocation of a mixing resource, if no 
> other component of the server can perform the duplication.
>

---

From: [email-masked]
Date: Mon, 11 Oct 2010 08:53:40 +0800

Paul,

> negotiation of such services/features.

That's ture. It is services and features on top of the sip.
But Join header itself is this kind of services and features on top of the 
sip. While it had not been clearly defined then, I guess there unclear 
points should be clarified.

Meanwhile, which WG is the proper one for this kind of work? As Join 
header is not demanded for all SIP UA, so it seams that it is not proper 
to be defined in SIPCore. Could you give me some suggestion, Dispatch?

Thanks,

Gao

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 11 Oct 2010 16:17:26 -0400

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

4. How about the streams(such as video) which are not proper for mixxing, if the INVITE with Join has such streams?
________________________________________

It is not clear that video is not proper for mixing.  For example, if UA A is the join-point, and it is receiving 3 video streams (one generated by UA A, one incoming from UA B, and one incoming from UA C), it can "mix" the streams from A and B by embedding their frames in a larger frame, and send the combined video frames to UA C.  Many videoconferencing systems work this way - each participant sees a single video stream containing small images of each other participants.

Dale

---

From: [email-masked]
Date: Tue, 12 Oct 2010 09:01:24 +0800

> It is not clear that video is not proper for mixing.  For example, 
> if UA A is the join-point, and it is receiving 3 video streams (one 
> generated by UA A, one incoming from UA B, and one incoming from UA 
> C), it can "mix" the streams from A and B by embedding their frames 
> in a larger frame, and send the combined video frames to UA C.  Many
> videoconferencing systems work this way - each participant sees a 
> single video stream containing small images of each other participants.
> 

I guess you are talking about the layout features for video conference 
systems. But it's control semantics is  more complex than the "Join 
header"(such as how layout, the size, which one is the main window？). If 
we want to use "Join header" as the triggering for the layout of video 
conference, the "Join header" itself need extension for layout features. 
Do you think so?

Thanks,

Gao