Subject: [siprec] metadata model for participant that is not part of CS

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 26 Jan 2011 10:55:58 -0800

This is to follow up on some questions I raised regarding the metadata
model during the interim meeting Tuesday.
My initial concern was that I thought we were allowing media streams to
be defined without any participant. I now understand that is not the
case; rather, a media stream is always associated with at least one
participant, but that participant need not necessary be associated with
the CS.
Now I have some concern about participants that are not part of the CS.
My concern is that the level of metadata we have for such participants
will be inconsistent at best. If the metadata for a non-CS participant
is incomplete, what do we plan to do? 
Also, I believe there was reference to a document that contains the
model and some use cases. Which document is that?

Thanks,
Charles

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 26 Jan 2011 13:27:58 -0800

Trying to come up with an instance diagram for what a conference mixer
looks like:

   +-------------------------------+
   | Recording Session (RS)        |
   +-------------------------------+
              |
              |
   +-------------------------------+
   |   Communication Session (CS)  |
   |      Group(CSG)               |
   +-------------------------------+
   |   Unique-id1                  |
   +-------------------------------+
              |
              |        
   +----------------+  
   | Communication  |  
   | Session (CS)1  |  
   +----------------+  
   |                |  
   +----------------+  
              |        
              |-------------------+
              |                   |
   +---------------+     +---------------+
   | ParticipantA  |--+--| ParticipantB  |
   +---------------+  |  +---------------+
           |          |          |
         sends     receives     sends
           |          |          |
   +---------------+  |  +---------------+
   |Media Stream A |  |  |Media Stream B |
   +---------------+  |  +---------------+
                      |
               +---------------+
               |Media Stream C |
               | (mixed stream)|
               +---------------+
                      |
                     sends
                      |
               +---------------+ 
               | ParticipantC  | 
               | (automated    | 
               |  announcement)| 
               +---------------+

Media Stream C is the one that we are interested in and that is the
recorded stream in the RS.

It looks to me that we need some form of an automated participant that
produces the mixed media as well as acting as an automated participant
that produces any announcements to the conference mix. This way we can
tell who generated the announcements as well as the mix itself, however,
I have a the same question as Charles where it is unclear to me whether
this automated participant should belong to any CS.

Regards,
Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: Wednesday, January 26, 2011 1:56 PM
> To: [email-masked]
> Subject: [siprec] metadata model for participant that is not part of
CS
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 27 Jan 2011 08:39:01 +0100

I am starting to see Charles's point. For a participant behind a bridge, you don't really know what media he is contributing or what media he is receiving. All you know for certain is that the bridge is a participant. Perhaps we could assign multiple user identities to a bridge participant, thereby reflecting users behind the bridge that may or may not be contributing to the media the bridge sends and may or may not be recipients of media the bridge receives.

Note that the model when the SRC is at the bridge, rather than outside the bridge, is quite different. Also the model where the bridge is switching, rather than mixing, might be different.

John (as individual) 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: 26 January 2011 18:56
> To: [email-masked]
> Subject: [siprec] metadata model for participant that is not 
> part of CS
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 27 Jan 2011 18:05:07 +0530

Hi Charles/John,

In the current model, a media stream is always associated with at least
one participant. Here is the snippet of the associations between CS and
Participant and Participant and Media Streams taken from the draft
https://datatracker.ietf.org/doc/draft-ram-siprec-metadata

Section 4.3.2 has the associations between CS and Participant
Section 4.4.2 has the associations between media stream and participant

The current model allows participants who are not part of CS to be part
of the model. 
A example of such a case is:
- participants in a premixed media stream.  The SRC may have knowledge
of such Participants, yet not have any signaling relationship with them.
This might arise if one participant in CS is a conf focus.

In those case, if the metadata for non-CS participants is incomplete,
the SRC can use other mechanisms like subscribing to conference event
package to retrieve the information about non-CS participants.

To summarize the model allows representing of non-CS participants who
contribute media to CS.

Charles, 
The use case section is at the end of this document
https://datatracker.ietf.org/doc/draft-ram-siprec-metadata

Please note the case where Focus is acting as SRC is simpler as all
participants of conference which are connected to focus will in turn
become participants of CS too.

Thanks,
Ram

> Behalf Of Elwell, John
> Sent: Thursday, January 27, 2011 1:09 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [siprec] metadata model for participant that is not part
> of CS
> 
> I am starting to see Charles's point. For a participant behind a
> bridge, you don't really know what media he is contributing or what
> media he is receiving. All you know for certain is that the bridge is
a
> participant. Perhaps we could assign multiple user identities to a
> bridge participant, thereby reflecting users behind the bridge that
may
> or may not be contributing to the media the bridge sends and may or
may
> not be recipients of media the bridge receives.
> 
> Note that the model when the SRC is at the bridge, rather than outside
> the bridge, is quite different. Also the model where the bridge is
> switching, rather than mixing, might be different.
> 
> John (as individual)
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 27 Jan 2011 18:19:30 +0530

Please see inline for comments:

> Behalf Of Henry Lum
> Sent: Thursday, January 27, 2011 2:58 AM

>From your instance diagram, there are two participant A and B who are
part of a CS and sending media streams A and B and they are receiving a
media stream from another source [ C which could be MOH or mixed stream
in this case].

As per the current model we could have Participants in media streams who
are not participants in the CS. Now that depends on what we mean by
participation in a CS. Our notion(used in the model) is:
- A participant is part of CS if it is contributing in the signaling for
the CS.

So as per the current model Participant C is non-CS participant ( as it
is not contributing to signaling) but contributing with only media to
CS. 

Thanks,
Ram

> > model and some use cases. Which document is that?
-----------------------------------------------------------------------
> --------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is
> authorized. Any liability arising from any party acting, or refraining
> from acting, on any information contained in this e-mail is hereby
> excluded. If you are not the intended recipient, please notify the
> sender immediately, destroy the original transmission and its
> attachments and do not disclose the contents to any other person, use
> it for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
> and/or its affiliated entities.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 07:59:59 -0500

> Note that the model when the SRC is at the bridge, rather than outside the bridge, is quite different. Also the model where the bridge is switching, rather than mixing, might be different.

I've been trying to ensure that there is enough flexibility in the model 
to describe all of these configurations. How the SRC *uses* that 
flexibility will be up to it. For instance, the SRC can choose to always 
include the UA that the media stream comes from as a sending 
participant, even if it is not contributing any of its own bits to the mix.

The aspect of the model that has multiple senders to a single stream has 
the intrinsic limitation that you don't know, from the model, what parts 
of the stream were sent by which participant. You may be able to improve 
on that with data in the RTP/RTCP if the mixer does a good job. Perhaps 
there should be more info in the metadata to tie all that together. My 
knowledge of the details of RTP is scant, so somebody else will have to 
suggest something if they see a way to do that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 08:47:54 -0500

I think I already commented on this, but in case...

(I presume you omitted the receivers of streams A and B because it isn't 
interesting.)

What you describe is certainly one way that this scenario could be 
reported by the SRC. It is equally possible for the SRC to report the UA 
that provides the automated announcement as another CS participant. And 
there are multiple ways that might be accomplished:

- it could be another participant in CS1. (But if there is no sip 
signaling, then that seems problematic.)

- there could be another CS2 in same CSG with CS1, having the media 
player as a participant. (But then its not clear who the other 
participant in CS2 would be.)

- we could expand the definition of participation in a CS to encompass 
signaling other than sip signaling. I'm open to that, but I think 
defining that might be difficult.

- or we could leave it as you have shown it. From a model perspective 
participant C provided MS C "by magic". Its that way because it is by 
means that we have not standardized. But the participant info still has 
the potential to have all the same info as a CS participant. (Exactly 
what is there depends on what info the SRC has available to it.) "Extra" 
information about participant C can also be provided as AppData.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 09:04:16 -0500

> model and some use cases. Which document is that?

The bottom line is that we will have to live with metadata describing 
what the SRC knows about the situation. What it doesn't know it can't 
report.

Beyond that, there may be things the SRC knows that can't be represented 
with the metamodel format we adopt. So, if there is something that you 
think the SRC might know, that we can define in a standard, that is not 
currently in the model, then speak up.

So far the only thing I suspect is if the SRC knows of a non-sip 
signaling relationship to some media participant. But unless we can get 
more specific that "non-sip signaling" its going to be hard to encode it.

I do think we may need to broaden the optional attributes of a 
Participant. Using a sip URI works for those in a signaling 
relationship, but for those that are not this may not work. The "name" 
has a lot of latitude, but doesn't lend itself to automated processing. 
E.g. we may need ability to include IDs from RTP. Of course this can 
also be covered by AppData until we get it right.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 27 Jan 2011 06:54:12 -0800

Inline.

> Behalf Of Paul Kyzivat
> Sent: Thursday, January 27, 2011 8:48 AM
> To: [email-masked]
[[hlum]] Right, the automated participant should have a line to receive
media stream A and media stream B. Technically, I should create a
separate mixer participant from the announcement participant so that it
is clear who is generating the announcement. 

> participant in CS2 would be.)

[[hlum]] The model only supports 2 participants in a CS, so it won't
work if we use a separate CS to contain the mixer participant. If the
mixer participant is handled through a mediactrl server, then
technically the mixer participant is part of the signaling via 3pcc and
the mixer is indeed part of CS1.

> information about participant C can also be provided as AppData.

[[hlum]] The problem I have with a participant that is not part of any
CS is that it can also mean the participant is a non-SIP participant. If
our intention is to only support SIP participants only then non-CS
participant becomes invalid.

> >> My initial concern was that I thought we were allowing media
streams
> > to
---------------------------------------------------------------------
> ----------------------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may
> contain confidential and proprietary information of Alcatel-Lucent
> and/or its affiliated entities. Access by the intended recipient only
> is authorized. Any liability arising from any party acting, or
> refraining from acting, on any information contained in this e-mail is
> hereby excluded. If you are not the intended recipient, please notify
> the sender immediately, destroy the original transmission and its

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 27 Jan 2011 10:07:46 -0800

Hi Ram,

If all CS participants are required to support the conference event
package and provide sufficient info about each non-CS participant in
order to be allowed to bring them in, then I am ok with it. My concern
is that the SRS will not be able to get sufficient info about non-CS
participant in all cases. In such cases, it seems to me the media
streams should be associated with the CS participant responsible for the
non-CS participant, rather than allowing media from incompletely
described non-CS participants to exist on its own.
You mention the case of the conference focus, in which everything may be
fine, but there are other cases, as mentioned by Jon, for which this may
not be the case.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Thursday, January 27, 2011 4:35 AM
> To: Elwell, John; Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [siprec] metadata model for participant that is not part
of CS
> 
> Hi Charles/John,
> 
> In the current model, a media stream is always associated with at
least one participant. Here is the
> snippet of the associations between CS and Participant and Participant
and Media Streams taken from
> the draft
> The current model allows participants who are not part of CS to be
part of the model.
> - participants in a premixed media stream.  The SRC may have knowledge
of such Participants, yet not
> have any signaling relationship with them.  This might arise if one
participant in CS is a conf focus.
> In those case, if the metadata for non-CS participants is incomplete,
the SRC can use other mechanisms
> like subscribing to conference event package to retrieve the
information about non-CS participants.
contribute media to CS.
> Please note the case where Focus is acting as SRC is simpler as all
participants of conference which
> are connected to focus will in turn become participants of CS too.
> 
> Thanks,
> Ram
> 
> > media he is receiving. All you know for certain is that the bridge
is a
may
may
> > > streams to

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 13:57:32 -0500

Charles,

I don't think we will be able (or should try) to design this so that 
everything the SRC specifies is guaranteed to be as complete as you wish 
it to be. At the end of the day, the SRC will have to do what it can, 
and some will be better at it than others. If the SRC you have chosen 
isn't supplying the information it could have and wish it had, then you 
can complain and request upgrades, or you can choose a different product.

As long as we have sufficient expressiveness to describe things as you 
wish for any given case then I think we are good. Lets ensure we can at 
least do that.

BTW, this is exactly the sort of discussion I have been hoping we would 
have over the model. I expected it would happen quite some time ago. But 
better now than never.

	Thanks,
	Paul