Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream

From: <[email-masked]>
Date: Thu, 1 Mar 2012 08:53:03 +0000

Partha,

I cant see how using CSG will help with the describing of the streams.  
Also I'm not convinced this would be the correct usage of a CSG, as while the calls are associated as they are made by the same person, in terms of sip they are completely unrelated.
I think draft-ietf-metadata could do with an explanation of what relationships a CSG implies.

Rgds
John Stafford | Solution Architect 1 | BT Global Services 
________________________________________
From: Ravindran, Parthasarathi [[email-masked]]
Sent: 01 March 2012 01:31
To: Stafford,J,John,JRJ3X C; [email-masked]; [email-masked]
Subject: RE: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream

John,

I guess that you are looking for group (CSG) element usage. Person AC sessions has to be grouped under single group. CS AC-B has to be mentioned as one of the session in group and CS AC-D has to be mentioned as another session of the group. Here, user AC is available in both sessions wherein participant (device) A is in session1 and participant (device) C is in session2, it is possible to pass participant name as AC in both sessions and it is perfectly fine. Please let me know whether this approach solves your problem.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of [email-masked]
>Sent: Wednesday, February 29, 2012 11:36 PM
>To: [email-masked]; [email-masked]
>Subject: Re: [siprec] How to specify in metadata that multiple CS's are
>being recorded in a single mixed RS m line stream
>
>Paul,
>
>Its one person AC with two handsets both in use at same time, probably
>one to each ear.
>
>Rgds
>John Stafford | Solution Architect 1 | BT Global Services
>________________________________________
>From: [email-masked] [[email-masked]] On Behalf Of
>Paul Kyzivat [[email-masked]]
>Sent: 29 February 2012 15:27
>To: [email-masked]
>Subject: Re: [siprec] How to specify in metadata that multiple CS's are
>being recorded in a single mixed RS m line stream
>
>On 2/29/12 9:29 AM, [email-masked] wrote:
>> A converse of the "How to specify in metadata that a participants
>stream is being recorded in multiple m line streams" thread:
>>
>> Another of our record configurations is when  a turret's handset 1 and
>> handset 2 calls are recorded as a single mixed recorder stream
>>
>> once again a persistent RS will be set up at registration time, in
>this case there will be a single m line.
>>
>> So if<stream>  represents a record stream, how would the following be
>described in metadata:
>>
>> There are 2 calls, A-B  and C-D, both are recorded via a single
>stream.
>> participants A and C are the same person, making two calls on handset
>1 and handset 2 of their turret.
>
>Just to clarify:
>
>There is one person, call him AC, that has two handsets A and C.
>AC has established one call with B (CS-A-B) and another call with D (CS-
>C-D).
>
>I gather these calls go on in parallel. (Maybe AC is switching back and
>forth taking into one handset of the other. In principal he could put
>one to each ear and use both at the same time.)
>
>Or is this more like a two line phone, with radio buttons to switch
>between the two lines, so that at any given time one is active and the
>other is "on hold"?
>
>I won't even try to respond to the stuff below until I get clarity on
>the above.
>
>        Thanks,
>        Paul
>
>> The problems I have in describing this in metadata are:
>> 1. I dont know how to show what the participants<recv>, as they dont
>recv the 2 call mixed stream.
>> 2. I only have a single stream being recorded which includes 2 CS's,
>> but the<stream>  element can only have a single session attriibute
>>
>> I can only describe this using<ParticipantStreamAssociation>
>and<ParticipantCSAssociation>.  I have not been following the list too
>closely for the past couple of months, is it still the intention to use
>these elements, as I see there is not yet a draft-ietf-metadata-06.txt
>that includes these elements in xml schema and examples.
>>
>> Also I dont know what happens to<send>  <recv>  when using
>associations.
>>
>> Anyway, heres my stab at it,
>>
>>   <?xml version="1.0" encoding="UTF-8"?>
>>            <recording xmlns='urn:ietf:params:xml:ns:recording'>
>>               <dataMode>complete</dataMode>
>>               <session id="====SESSION_ONE=====">
>>               </session>
>>               <participant
>>                  id="==PARTICIPANT_A=="
>>                  <nameID aor=sip:[email-masked]>
>>                                <name xml:lang="it">RamMohan R</name>
>>                  </nameID>
>>               </participant>
>>               <participantSessionAssoc
>>                  participant="==PARTICIPANT_A=="
>>                  session="====SESSION_ONE=====">
>>                     <associate-time>2010-12-16T23:41:07Z</associate-
>time>
>>                     <capabilities>  TBD</capabilties>
>>               </participantSessionAssoc>
>>               <participantStreamAssoc
>>                  participant="==PARTICIPANT_A=="
>>                  stream ="i1Pz3to5hGk8fuXl+PbwCw==">
>>                    <associate-time>2010-12-16T23:41:07Z</associate-
>time>
>>               </participantStreamAssoc>
>>
>>               <participant
>>                   id="==PARTICIPANT_B=="
>>                   <nameID aor=sip:[email-masked]>
>>                                <name xml:lang="it">Paul Kyzivat</name>
>>                   </nameID>
>>               </participant>
>>               <participantSessionAssoc
>>                  participant="==PARTICIPANT_B=="
>>                  session="====SESSION_ONE=====">
>>                     <associate-time>2010-12-16T23:41:07Z</associate-
>time>
>>                     <capabilities>  TBD</capabilties>
>>               </participantSessionAssoc>
>>               <participantStreamAssoc
>>                  participant="==PARTICIPANT_B=="
>>                  stream ="i1Pz3to5hGk8fuXl+PbwCw==">
>>                    <associate-time>2010-12-16T23:41:07Z</associate-
>time>
>>               </participantStreamAssoc>
>>
>>
>>               <session id="====SESSION_TWO=====">
>>               </session>
>>               <participant
>>                  id="==PARTICIPANT_C=="
>>                  <nameID aor=sip:[email-masked]>
>>                                <name xml:lang="it">RamMohan R</name>
>>                  </nameID>
>>               </participant>
>>               <participantSessionAssoc
>>                  participant="==PARTICIPANT_C=="
>>                  session="====SESSION_TWO=====">
>>                     <associate-time>2010-12-16T22:02:04Z</associate-
>time>
>>                     <capabilities>  TBD</capabilties>
>>               </participantSessionAssoc>
>>               <participantStreamAssoc
>>                  participant="==PARTICIPANT_C=="
>>                  stream ="i1Pz3to5hGk8fuXl+PbwCw==">
>>                    <associate-time>2010-12-16T22:02:04Z</associate-
>time>
>>               </participantStreamAssoc>
>>
>>               <participant
>>                   id="==PARTICIPANT_D=="
>>                   <nameID aor=sip:[email-masked]>
>>                                <name xml:lang="it">Andrew
>Hutton</name>
>>                   </nameID>
>>               </participant>
>>               <participantSessionAssoc
>>                  participant="==PARTICIPANT_D=="
>>                  session="====SESSION_TWO=====">
>>                     <associate-time>2010-12-16T22:02:04Z</associate-
>time>
>>                     <capabilities>  TBD</capabilties>
>>               </participantSessionAssoc>
>>               <participantStreamAssoc
>>                  participant="==PARTICIPANT_D=="
>>                  stream ="i1Pz3to5hGk8fuXl+PbwCw==">
>>                    <associate-time>2010-12-16T22:02:04Z</associate-
>time>
>>               </participantStreamAssoc>
>>
>>               <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
>>                   <label>HS1_HS2_mixed_stream</label>
>>               </stream>
>>          </recording>
>>
>>
>> Rgds
>> John Stafford | Solution Architect 1 | BT Global Services
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 12:50:34 -0500

> I think draft-ietf-metadata could do with an explanation of what relationships a CSG implies.

Its your call whether these calls are related in a way that you want to 
track as a CSG.

Clearly there are a number of different reasons you might want to group 
CSs, and we currently don't provide any attributes to distinguish one 
reason from another. That is mostly because we didn't want to get into 
the business of enumerating the possible uses. The solution to that is 
to add proprietary extension data to the CSG and/or the CSs to identify 
why they are grouped.

Alternatively I would simply treat these as two separate CSs, each with 
a separate media stream.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 5 Mar 2012 16:45:46 +0000

Ok, CSG is not a concern.

What I wanted clarified was how metadata <stream>s and would look when you have two simultaneous calls on an endpoint and both calls are mixed into a single recorder stream.

If <stream> represents the mixed stream of two calls going to the recorder, then how can a participant have a <recv> that references that stream, 
as a participant  does NOT recv the  mixed  stream.

Rgds
John Stafford | Solution Architect 1 | BT Global Services 
________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: 01 March 2012 17:50
To: Stafford,J,John,JRJ3X C
Cc: [email-masked]; [email-masked]
Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2012 17:33:00 -0500

On 3/5/12 11:45 AM, [email-masked] wrote:
> What I wanted clarified was how metadata<stream>s and would look when you have two simultaneous calls on an endpoint and both calls are mixed into a single recorder stream.
>
> If<stream>  represents the mixed stream of two calls going to the recorder, then how can a participant have a<recv>  that references that stream,

I don't understand how it makes sense to mix the media for two distinct 
calls.

Or do you mean that you want to send them both over a single RTP 
session, distinguished by SSRC or CSRC?

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 9 Mar 2012 15:40:43 +0100

Hi John,

I am also struggling to understand this use case.

If you mean that you want to have the SRC act as an RTP Mixer and mix the streams from different CS's in to a single RTP Session using the CSRC to demultiplex at the SRS then I think this is not supported by the current metadata model.

Could our metadata experts please confirm?

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 05 March 2012 22:33
> To: [email-masked]
> Cc: [email-masked]
> > What I wanted clarified was how metadata<stream>s and would look when
> you have two simultaneous calls on an endpoint and both calls are mixed
> into a single recorder stream.
> >
> > If<stream>  represents the mixed stream of two calls going to the
> recorder, then how can a participant have a<recv>  that references that
> stream,
> > Subject: Re: [siprec] How to specify in metadata that multiple CS's
> are being recorded in a single mixed RS m line stream
> >
> >> Also I'm not convinced this would be the correct usage of a CSG, as
> while the calls are associated as they are made by the same person, in
> terms of sip they are completely unrelated.
> >> Subject: RE: [siprec] How to specify in metadata that multiple CS's
> are being recorded in a single mixed RS m line stream
> >>
> >> John,
> >>
> >> I guess that you are looking for group (CSG) element usage. Person
> AC sessions has to be grouped under single group. CS AC-B has to be
> mentioned as one of the session in group and CS AC-D has to be
> mentioned as another session of the group. Here, user AC is available
> in both sessions wherein participant (device) A is in session1 and
> participant (device) C is in session2, it is possible to pass
> participant name as AC in both sessions and it is perfectly fine.
> Please let me know whether this approach solves your problem.
> >>
> >> Thanks
> >> Partha
> >>

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 13:11:59 +0000

Andrew

As a bit of background to this Trading turrets can have between 1 and 28 audio streams coming into them all of them require recording.

To reduce recording costs trading companies have mixed devices to reduce VR license costs, network bandwidth, Storage Typically there would be two handsets and 8 speakers mixed 2 :1 and 2 x 4:1 respectively.

So in SIPREC we have one RS for a Turret which in the example above can have 10 active CS these are being sent as 3 RTP streams or 3 m-lines to the recoding capture devices.

The compliance officers in the bank have accepted the mixing so there is no requirement for the voice recorder to unmix the received streams they are stored and tagged. Normally the recorder is also taking a CTI feed and it just matches the tag normally a timestamp to the audio file in a many to one arrangement.

I hope this makes things a bit clearer

Finlay

________________________________________
From: Hutton, Andrew [[email-masked]]
Sent: 09 March 2012 14:40
To: Stafford,J,John,JRJ3X C
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream

Hi John,

Regards
Andy

> you have two simultaneous calls on an endpoint and both calls are 
> mixed into a single recorder stream.
> >
> recorder, then how can a participant have a<recv>  that references 
> that stream,
> I don't understand how it makes sense to mix the media for two 
> distinct calls.
>
> > CSs, and we currently don't provide any attributes to distinguish 
> > one reason from another. That is mostly because we didn't want to 
> > get
> into
> Behalf
> are
> are
> >>>> Another of our record configurations is when  a turret's handset 
> >>>> 1
> and
> >>> AC has established one call with B (CS-A-B) and another call with 
> >>> D
> (CS-
> >>> C-D).
> >>>
> >>> I gather these calls go on in parallel. (Maybe AC is switching 
> >>> back
> and
> >>> Or is this more like a two line phone, with radio buttons to 
> >>> switch between the two lines, so that at any given time one is 
> >>> active and
> the
> >>> other is "on hold"?
> >>>
> >>> closely for the past couple of months, is it still the intention 
> >>> to
> use

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 10:29:18 -0400

> I hope this makes things a bit clearer

It *helps*, but I'm still confused as to the resulting streams contain.

Can I assume that there is *one* Trader (T) participant be Turret?
And then there could be 10 other participants, each in an independent CS 
with the Trader? (E.g. T:P0, ... T:P9). Is that right?
And these are independent CS sessions in that T:Pi contains an exchange 
of media between T and Pi.

Then you say these are then being mixed into some fewer number media 
sessions to the recorder. Is that done in a way that can be unraveled 
after the fact? (Say by SSRC or CSRC.)

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 16:40:17 +0000

Guys

To reduce recording costs trading companies have mixed devices to reduce VR license costs, network bandwidth, Storage

Typically there would be two handsets and 8 speakers as follows:-

Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX)
Mix 2 - (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX and TX + Speaker 4 RX and TX)
Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX and TX + Speaker 8 RX and TX)

So in SIPREC we have one RS for a Turret which in the example above can have 10 active CS these are being sent as 3 RTP streams
or 3 m-lines to the recoding capture devices.

The compliance officers in the bank have accepted the mixing so there is no requirement for the voice recorder to unmix the received streams they are stored
and tagged. Normally the recorder is also taking a CTI feed and it just matches the tag normally a timestamp to the audio file in a many to one arrangement.

Finlay
From: [email-masked] [[email-masked]] On Behalf Of Hutton, Andrew [[email-masked]]

Hi John,

Regards
Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 13:00:50 -0400

> Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX and TX + Speaker 8 RX and TX)

First, can we clarify the terminology?
I guess Handset 1 and 2 refer to handsets used by the Trader?
And "Speaker" doesn't mean "loudspeaker", but rather designates a 
participant connected to the Trader?
So there are 8 CSs, each involving the Trader and one of the Speakers?
And each Speaker can hear only the Trader, not any of the other 
Speakers? (Ignoring unintended crosstalk.)

Is each CS connected uniquely to one of the handsets?
Or can either handset be connected to any of the Speakers?

Do Mix 2 and Mix 3 assume that only one of the speakers in the mix is 
active at any one time?

> and tagged. Normally the recorder is also taking a CTI feed and it just matches the tag normally a timestamp to the audio file in a many to one arrangement.

Is there sufficient info in these mixes that the audio for each end of 
any one CS can be accurately reconstructed? (Even though there is no 
requirement that this be done?

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 13 Mar 2012 11:23:10 +0000

Paul,

Ok let me have a go at explaining Finlay;s clarification!

Handset 1 and Handset 2 are phone handsets, both work independantly like having 2 phones, but are both integrated into one turret.

Speaker does mean loudspeaker, a trader can have many channels of audio he is listening to simultaneously via loudspeakers, these channels need to be recorded.
However these are not receive only channels, the turret has a single stalk microphone for talking back on the speaker channels. The trader can set the microphone to be connected to one, or multiple speaker channels simultaneously, and the mic can be always on or press to talk.

So each handset and each of the speakers channels is a separate CS. The trader will be a participant in each CS.

The recorded mixes do not have to be de-multiplexed, they rely on the human ears ability to hear distinquish participants on replay,
There is not sufficient information recorded to be able to de-multiplex the audio mix for replay.

In Finlays example where there are 8 speaker channels, they are as he shows typically mixed 4:1 .
They could also be mixed 2:1, in which case there would be 4 recorder streams for the speakers,
or even 8:1 giving just 1 record channel.

The mix ratio is determined by how busy the channels are, ie  if they are  stock prices which  may be shouted on a channel maybe only one a minute then you could mix 8 channsla nd still expect on replay to be able to hear what was being said. But if the channels have continuous commentary then you may only be able to mix 2:1.
It's a trade off of recorded/network bandwidth/cost against replay intelligibility.

I think allowing a stream to have multiple session's (would have to be elements not an attribute) would allow the recorded to find a mixed recorded CS,
but I am at a loss of what to do about the paticipants <recv>  lement, as a participant clearly does not recv the mixed stream.

Hope that helps.

Rgds
John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932 773504   | E: [email-masked]  |  www.bt.com/globalservices
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: 12 March 2012 17:00
To: [email-masked]
Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2012 11:50:55 -0400

John,

Thanks for the explanation. I think I now know more than I want to. :-)
This is clearly a very specialized situation. One we certainly didn't 
contemplate in our definitions. Without further study and discussion I 
don't really know what the best way to map this is, or if there is a 
best way.

My first reaction is to suggest that you map what you have onto our 
model the best you can - making this an application issue. (E.g. simply 
consider each of your mixes to be a CS with multiple participants.)

If that doesn't work, and you feel that changes to the model would make 
it easier for you to map to, then certainly feel free to propose changes 
to the model. But if you do so, please propose something that makes 
sense in its own right, independent of your specialized application.

	Thanks,
	Paul

On 3/13/12 7:23 AM, [email-masked] wrote:
> but I am at a loss of what to do about the paticipants<recv>   lement, as a participant clearly does not recv the mixed stream.
>
> Hope that helps.
>
> Rgds

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 13 Mar 2012 17:49:28 +0100

Hi John,

I agree with Paul's conclusions below.

If the current metadata model does not fit your requirements then I would encourage you to make a proposal for changes to the metadata model and we can then discuss the proposal in the working group.

Will you be in the Paris meeting?

Regards
Andy

> Sent: 13 March 2012 15:51
> > Handset 1 and Handset 2 are phone handsets, both work independantly
> like having 2 phones, but are both integrated into one turret.
> >
> > Speaker does mean loudspeaker, a trader can have many channels of
> audio he is listening to simultaneously via loudspeakers, these
> channels need to be recorded.
> > However these are not receive only channels, the turret has a single
> stalk microphone for talking back on the speaker channels. The trader
> can set the microphone to be connected to one, or multiple speaker
> channels simultaneously, and the mic can be always on or press to talk.
> >
> > So each handset and each of the speakers channels is a separate CS.
> The trader will be a participant in each CS.
> >
> > The recorded mixes do not have to be de-multiplexed, they rely on the
> human ears ability to hear distinquish participants on replay,
> > The mix ratio is determined by how busy the channels are, ie  if they
> are  stock prices which  may be shouted on a channel maybe only one a
> minute then you could mix 8 channsla nd still expect on replay to be
> able to hear what was being said. But if the channels have continuous
> commentary then you may only be able to mix 2:1.
> > I think allowing a stream to have multiple session's (would have to
> be elements not an attribute) would allow the recorded to find a mixed
> recorded CS,
> > but I am at a loss of what to do about the paticipants<recv>
> lement, as a participant clearly does not recv the mixed stream.
> >
> > Hope that helps.
> >
> > Rgds
> > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44
> (0)1932 773504   | E: [email-masked]  |
> www.bt.com/globalservices
> >> As a bit of background to this Trading turrets can have between 1
> and 28 audio streams coming into them all of them require recording.
> >>
> >> To reduce recording costs trading companies have mixed devices to
> reduce VR license costs, network bandwidth, Storage
> >>
> >> So in SIPREC we have one RS for a Turret which in the example above
> can have 10 active CS these are being sent as 3 RTP streams
> >> The compliance officers in the bank have accepted the mixing so
> there is no requirement for the voice recorder to unmix the received
> streams they are stored
> >> and tagged. Normally the recorder is also taking a CTI feed and it
> just matches the tag normally a timestamp to the audio file in a many
> to one arrangement.
> >
> Hutton, Andrew [[email-masked]]
> >> If you mean that you want to have the SRC act as an RTP Mixer and
> mix the streams from different CS's in to a single RTP Session using
> the CSRC to demultiplex at the SRS then I think this is not supported
> by the current metadata model.
> >>
> distinct
> >>>> Its your call whether these calls are related in a way that you
> want
> >>> to
> >>>> track as a CSG.
> >>>>
> one
> >>>> the business of enumerating the possible uses. The solution to
> that
> >>> is
> >>>>>> From: [email-masked] [[email-masked]] On
> Behalf
> >>> Of
> >>>>>>> Another of our record configurations is when  a turret's
> handset 1
> >>> and
> >>>>>> AC has established one call with B (CS-A-B) and another call
> with D
> >>> (CS-
> >>>>>> C-D).
> >>>>>>
> >>>>>> forth taking into one handset of the other. In principal he
> could
> >>> put
> switch
> >>>>>> between the two lines, so that at any given time one is active
> and
> >>> the
> >>>>>> other is "on hold"?
> >>>>>>
> >>>>>> I won't even try to respond to the stuff below until I get
> clarity
> >>> on
> >>>>>> the above.
> >>>>>>
> >>>>>>            Thanks,
> >>>>>>            Paul
> >>>>>>
> >>>>>> and<ParticipantCSAssociation>.  I have not been following the
> list
> >>> too
> >>>>>>>                <recording
> xmlns='urn:ietf:params:xml:ns:recording'>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 25 Mar 2012 07:59:52 +0000

Hi John,

Looking at the current problem statement, ISTM that it is possible to accommodate this scenario within the current metadata model. The point to be noted is that single stream shall be linked to multiple CS as per metadata model (n CS to 1 stream association) and also, there is no means to identify the contributor of the mixed stream using metadata. 

Please let me know in case the current metadata model does not help to fit your scenario.

Thanks
Partha

>Of Hutton, Andrew
>Sent: Tuesday, March 13, 2012 10:19 PM
>To: Paul Kyzivat; [email-masked]
>Cc: [email-masked]
>If the current metadata model does not fit your requirements then I
>would encourage you to make a proposal for changes to the metadata model
>and we can then discuss the proposal in the working group.
>
>> Thanks for the explanation. I think I now know more than I want to.
>> :-) This is clearly a very specialized situation. One we certainly
>> didn't contemplate in our definitions. Without further study and
>> discussion I don't really know what the best way to map this is, or if
>> there is a best way.
>>
>> model the best you can - making this an application issue. (E.g.
>> simply consider each of your mixes to be a CS with multiple
>> participants.)
>>
>> If that doesn't work, and you feel that changes to the model would
>> make it easier for you to map to, then certainly feel free to propose
>> changes to the model. But if you do so, please propose something that
>> makes sense in its own right, independent of your specialized
>> application.
>>
>>       Thanks,
>>       Paul
>>
>> > In Finlays example where there are 8 speaker channels, they are as
>> > he
>> shows typically mixed 4:1 .
>> > They could also be mixed 2:1, in which case there would be 4
>> > recorder
>> streams for the speakers,
>> >> Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) Mix 2 -
>> >> (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX
>> and TX + Speaker 4 RX and TX)
>> > Do Mix 2 and Mix 3 assume that only one of the speakers in the mix
>> > is active at any one time?
>> >
>> >>> while the calls are associated as they are made by the same
>> >>> person,
>> in
>> >>>> Alternatively I would simply treat these as two separate CSs,
>> >>>> each
>> >>> with
>> >>>> a separate media stream.
>> >>>>
>> >>>>            Thanks,
>> >>>>            Paul
>> >>>>
>> >>>>> Rgds
>> >>> AC sessions has to be grouped under single group. CS AC-B has to
>> >>> be mentioned as one of the session in group and CS AC-D has to be
>> >>>>>>> once again a persistent RS will be set up at registration
>> >>>>>>> time,
>> in
>> >>>>>>> 1. I dont know how to show what the participants<recv>, as
>> >>>>>>> they
>> >>> dont
>> >>>>>> these elements, as I see there is not yet a
>> >>>>>> draft-ietf-metadata-
>> >>> 06.txt
>> >>>>>>>                                    <name
>> >>>>>>> xml:lang="it">RamMohan
>> >>> R</name>
>> >>>>>>>                                    <name
>> >>>>>>> xml:lang="it">RamMohan
>> >>> R</name>