Subject: RE: [Sipping] Conference speaker control

From: "Even, Roni" <[email-masked]>
Date: Mon, 29 Nov 2004 17:26:16 +0200

Magnus,
I am not saying that RTP using SSRC does not have a mechanism to
identify the source of the streams. What I am trying to say is that we
are not talking about a pure RTP mixer but we are talking about a SIP
based conferencing server and in XCON the scope is even wider, it may be
a PSTN bridge bellow. 
So first of all there is no requirement defined that the mixer in SIP
conferencing or XCON should be a RTP mixer per RFC3550. Even if we do it
for SIPPING then we will have a problem for PSTN Bridge (example of
usage if for audio-graphic conference) and it will break for XCON.
Roni Even

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, November 29, 2004 5:11 PM
To: Even, Roni
Cc: sipping
Subject: Re: [Sipping] Conference speaker control

Hi Roni,

Sorry if I do not have a full picture of the architecture of the 
conferencing. Please enlighten me if I overstep any previous agreements.

Even, Roni wrote:

> Brian,
> I am sorry to continue to argument. I thought the view in my reply was
> clear. I think that since SIP has a dialog between two endpoint and
not
> just an RTP session, and since the meaningful information that needs
to
> be displayed to the user is who is speaking and not what is the ssrc
of
> the stream that it received, it will make more sense to have this
> information coming from a SIP conference bridge as the speaker
> indication.

RTP with RTCP does have the mechanism to provide a receiver with the 
name or at least the CNAME for all SSRCs that are used in all media 
streams. That way one can identify the actual media senders. It might be

beneficial depending on the conferencing side functions to bind the 
CNAME to some RTP/RTCP external user identification. Thus including 
CNAME in the state package may be beneficial, instead of needing to 
provide SSRC for all participants in all media streams. It would reduce 
the data  points with a factor equal to the number of media.

Is the issue that you don't think media reception from a specific SSRC a

good indication that the source is active? Otherwise I don't see the 
reason to not utilize the functionality present in RTP/RTCP.

In regards to RTP mixer I would like to point out that the conference 
bridge must not necessarily be a mixer, it could be a relay. If the 
bridge simply forwards all packets from all participants RTP and RTCP to

  everybody, no mixing is necessary. The downside is that the media 
amount gets increased every time more than one transmits data. This of 
course has its issue with users that has a limited bandwidth. The higher

the bit-rate of the media the more sensible it seems to do mixing. But 
mixing T.140 conference text seems rather unnecessary.

cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Sipping mailing list  https://www1.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: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Nov 2004 16:44:48 +0100

Hi Roni,

Lets see if I understand this correctly. You are worried about PSTN or 
other gateways that are receiving more than one source over the same 
circuit and in which cases the gateway can't separate the different 
sources within the CS to IP gateway. As long as the PSTN gateway 
receives the different circuit switched sources in the same conference 
on different circuits, it is able to assign them different SSRCs and IDs.

If the above is the case, how would adding any other mechanism help? The 
gateway can still not identify the original sources, or am I 
misunderstanding something about the setup?

My understanding of the setup you are concern is:

CS1 --\
        -> CS Bridge -> Gateway ->  IP Conf Bridge -> Client 3
CS2 --/                  ^               ^
                          |               |
                         CS5           Client 4

In this case Client 3 and 4 would not be able to determine that what is 
beyond the gateway is in fact three client. CS1 and CS2 will be bunched 
together under one source identifier? While CS5 can be identified as it 
connects directly with the gateway and uses a separate CS line into the 
gateway, thus allowing the gateway to give them separate IDs.

It should also not be a problem if the protocol used on the CS side 
provides identities, then the gateway can provide different identifiers 
for the different CS side users.

Cheers

Magnus

-- 

Magnus Westerlund