Subject: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

From: "Sandipkumar Shah (sandshah)" <[email-masked]>
Date: Wed, 31 Aug 2011 12:27:04 -0700

Section 6.3.2 SIP REC Metadata :  
 
[Draft] CS to have at least two or more participants.
 
[Sandip] It should say - "CS to have at least one or more participants."
Let's take a use case. A company executive wants to record all hands
kind of meeting from recording studio or any telepresence room. In such
case CS will have only one participant.

Thread http://www.ietf.org/mail-archive/web/siprec/current/msg02367.html
discussed the same. Just wanted to make sure this will be incorporated
in next draft.

General comment on metadata :
 
Telepresence based (audio/video/presentation) meetings/recordings has
needs to convey much more richer metadata so that recorded video becomes
more searchable and hence increase consumption. Here are few examples.
 
1)  As meeting is schedule (e.g. Microsoft outlook) Organizer can
specifies lot of information 
a.  Specify Meeting subject.
b.  May specify tags associated with meeting topic. E.g. Once video is
uploaded on youtube.com user can specify tags for searching videos.
<ceo/> <allhands/> <Q4Result> <cfo/> <hiring/> <offshore/>

c.  Recording system can be communicating with speech recognition system
for mining more data. Organizer can provide grammar that can be sent to
speech
Recognition system. Similar to what VoiceXML allows.
 
UA may not be able to provide above mentioned information to SRC using
SIP however SRC can access the information (via its custom mechanism)
and provide to SRS so that it can associate these richer metadata with
recording.
 
Looking at present metadata, it is providing few additional information
such as AOR, Displayname, start/endtime, additional participants etc. to
SRS.
While this is useful metadata, implementations can derive these
information from SIP headers when possible and probably that is what
today's recording implementation
in market may be doing. We need to be able to specify more rich metadata
without using <extensiondata> to increase great adoption.
 
Suggestion on section 7.1 :
In order to understand it better and correlate with SIP signaling, I
suggest to put SIP signaling with SDP also in place. Additionally put
comments in the 
Example metadata xml so one can understand the example better.
 
Best,
Sandip Shah

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 5 Sep 2011 20:56:35 +0530

Hi Sandip,

Sorry for delay in response as I was busy publishing the new version of
the metadata draft. Please see inline <Ram> for answers

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sandipkumar Shah (sandshah)
Sent: Thursday, September 01, 2011 12:57 AM
To: [email-masked]
Subject: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

 

<Ram>Ver-04 does not include this as from the last discussion we had
there was no concrete consensus in the WG to add this.  The last mail on
this thread is here -
http://www.ietf.org/mail-archive/web/siprec/current/msg02451.html.  I
will re-start the discussion on this and ask for a consensus on which
way to go. 

 

 
 
Looking at present metadata, it is providing few additional information
such as AOR, Displayname, start/endtime, additional participants etc. to
SRS.
While this is useful metadata, implementations can derive these
information from SIP headers when possible and probably that is what
today's recording implementation
in market may be doing. We need to be able to specify more rich metadata
without using <extensiondata> to increase great adoption.
<Ram> This is a new use-case which has not been discussed so far. The
current approach that is followed in the draft is  metadata has mostly
attributes that can be derived from CS SIP session (both from SIP/SDP).
I think what you are asking for is information that can be learnt from
outside SIP to be carried in metadata. The initial proposal of metadata
had several such attributes but after subsequent discussions in mailer,
several folks in WG where not in favor of having element that are not
learned from SIP / SDP in the XML. Can you please start a new thread for
this use-case to get the WG opinion on the new attributes you are
suggesting ?

<Ram> In version -04 of metadata I have included some XML examples in
Appendix. I have included SDP snippets at some places along with XML to
make it clear. Please review and let me know if you need more clarity.
Note we initially had complete examples but later removed them as we
received comments to  have the SIP things moved to protocol document.
 
Regards,
Ram
 
Best,
Sandip Shah

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 5 Sep 2011 23:14:18 +0530

Hi Sandip,

Please read inline.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ram Mohan R (rmohanr)
Sent: Monday, September 05, 2011 8:57 PM
To: Sandipkumar Shah (sandshah); [email-masked]
Subject: Re: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

Hi Sandip,

 

[Partha] I have really tough time in understanding CS with single
participant. I could not figure out how Voice mail or studio recording
falls within SIPREC architecture with different CS and RS. Let us
discuss in the interim meeting for the closure.

 

 
Looking at present metadata, it is providing few additional information
such as AOR, Displayname, start/endtime, additional participants etc. to
SRS.
While this is useful metadata, implementations can derive these
information from SIP headers when possible and probably that is what
today's recording implementation
in market may be doing.
[Partha] There are "n" number of SIP header based mechanism exist in the
market. It is one of the main motivation for this work to be
standardized.
Recording Metadata in SIP headers has "n" number of issues like how to
group participant to media stream, how to group multiple CS, how to
represent the single participant is not receiving the stream whereas
others are receiving, defining the unique-id mechanism to identify the
individual CS. The authors of metadata explored the mechanism to pass
the metadata in SDP and again it has other pitfalls. So, we decided to
go with message body approach. JSON, XML, ASN.1 notation are considered
for message body and then XML was chosen as a data representation for
metadata. Hope this clarifies.
 
 We need to be able to specify more rich metadata without using
<extensiondata> to increase great adoption.
[Partha] we have done a long exercise in the metadata model between
IETF78 to IETF-80 about the number of attributes for each metadata
block. Lot of call centre specific attributes, application extensions
are discussed in couple of meeting. Even it was apparent that there was
need for  some call center specific metadata which lot of folks are
interested but those attributes are not generic enough to mention within
SIPREC metadata. Please look into old SIPREC archive for more details.
Currently, we are having open items for attributes like contact params,
CSRC.
 
 Generic attribute MUST apply for all kind of SRC like UA, B2BUA, focus.
In case you have any specific generic attribute in mind, Please let us
know.

 
 
Regards,
Ram
 
Best,
Sandip Shah

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 6 Sep 2011 10:29:33 +0200

This thread is getting impossible to follow because folks are not putting line breaks in their text.
At least on my client it means scrolling left and right all the time to read it. Please exercise some discipline.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: 05 September 2011 18:44
To: Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah); [email-masked]
Subject: Re: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

Hi Sandip,

Please read inline.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Monday, September 05, 2011 8:57 PM
To: Sandipkumar Shah (sandshah); [email-masked]
Subject: Re: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

Hi Sandip,

Sorry for delay in response as I was busy publishing the new version of the metadata draft. Please see inline <Ram> for answers

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sandipkumar Shah (sandshah)
Sent: Thursday, September 01, 2011 12:57 AM
To: [email-masked]
Subject: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

Let's take a use case. A company executive wants to record all hands kind of meeting from recording studio or any telepresence room. In such case CS will have only one participant.

Thread http://www.ietf.org/mail-archive/web/siprec/current/msg02367.html discussed the same. Just wanted to make sure this will be incorporated in next draft.
<Ram>Ver-04 does not include this as from the last discussion we had there was no concrete consensus in the WG to add this.  The last mail on this thread is here - http://www.ietf.org/mail-archive/web/siprec/current/msg02451.html.  I will re-start the discussion on this and ask for a consensus on which way to go.

[Partha] I have really tough time in understanding CS with single participant. I could not figure out how Voice mail or studio recording falls within SIPREC architecture with different CS and RS. Let us discuss in the interim meeting for the closure.

Telepresence based (audio/video/presentation) meetings/recordings has needs to convey much more richer metadata so that recorded video becomes more searchable and hence increase consumption. Here are few examples.

1)  As meeting is schedule (e.g. Microsoft outlook) Organizer can specifies lot of information

b.  May specify tags associated with meeting topic. E.g. Once video is uploaded on youtube.com user can specify tags for searching videos.

c.  Recording system can be communicating with speech recognition system for mining more data. Organizer can provide grammar that can be sent to speech

UA may not be able to provide above mentioned information to SRC using SIP however SRC can access the information (via its custom mechanism) and provide to SRS so that it can associate these richer metadata with recording.

Looking at present metadata, it is providing few additional information such as AOR, Displayname, start/endtime, additional participants etc. to SRS.

While this is useful metadata, implementations can derive these information from SIP headers when possible and probably that is what today's recording implementation

in market may be doing.

[Partha] There are "n" number of SIP header based mechanism exist in the market. It is one of the main motivation for this work to be standardized.

Recording Metadata in SIP headers has "n" number of issues like how to group participant to media stream, how to group multiple CS, how to represent the single participant is not receiving the stream whereas others are receiving, defining the unique-id mechanism to identify the individual CS. The authors of metadata explored the mechanism to pass the metadata in SDP and again it has other pitfalls. So, we decided to go with message body approach. JSON, XML, ASN.1 notation are considered for message body and then XML was chosen as a data representation for metadata. Hope this clarifies.

 We need to be able to specify more rich metadata without using <extensiondata> to increase great adoption.

[Partha] we have done a long exercise in the metadata model between IETF78 to IETF-80 about the number of attributes for each metadata block. Lot of call centre specific attributes, application extensions are discussed in couple of meeting. Even it was apparent that there was need for  some call center specific metadata which lot of folks are interested but those attributes are not generic enough to mention within SIPREC metadata. Please look into old SIPREC archive for more details. Currently, we are having open items for attributes like contact params, CSRC.

 Generic attribute MUST apply for all kind of SRC like UA, B2BUA, focus. In case you have any specific generic attribute in mind, Please let us know.

<Ram> This is a new use-case which has not been discussed so far. The current approach that is followed in the draft is  metadata has mostly attributes that can be derived from CS SIP session (both from SIP/SDP).  I think what you are asking for is information that can be learnt from outside SIP to be carried in metadata. The initial proposal of metadata had several such attributes but after subsequent discussions in mailer, several folks in WG where not in favor of having element that are not learned from SIP / SDP in the XML. Can you please start a new thread for this use-case to get the WG opinion on the new attributes you are suggesting ?

In order to understand it better and correlate with SIP signaling, I suggest to put SIP signaling with SDP also in place. Additionally put comments in the

<Ram> In version -04 of metadata I have included some XML examples in Appendix. I have included SDP snippets at some places along with XML to make it clear. Please review and let me know if you need more clarity. Note we initially had complete examples but later removed them as we received comments to  have the SIP things moved to protocol document.

Regards,

Ram

Best,

Sandip Shah

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 6 Sep 2011 19:59:40 +0530

[re-stating the issue discussed in the below thread raised by Sandip  ]

Sandip has raised this issue on the CS having a restriction of minimum two participants in the current model. 
The restriction two was choosen based on the use-cases we discussed in the past.

He cites the use-cases of recording studio which was discussed in the past as an example of use-case having one participant, however majority of folks see this use-case as having two participants from the earlier discussions.

The open item that is not yet closed in the earlier discussions is in case an SRS receives a metadata XML with a session element having only one participant should SRS reject the metadata or still accept ?
(was discussed here earlier - http://www.ietf.org/mail-archive/web/siprec/current/msg02429.html but no consensus was reached)

IMO SRS should be liberal and accept the metadata if that is all what an SRC can provide. It is better to have some information(metadata) rather than having nothing at all.

There was also a question earlier on what the definition of a participant really is ? None of the documents defines this even though every SIPREC document uses it.

Comments ?

Regards,
Ram

From: Ravindran Parthasarathi [mailto:[email-masked]] 
Sent: Monday, September 05, 2011 11:14 PM
To: Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah); [email-masked]
Subject: RE: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

Hi Sandip,

Please read inline.

Thanks
Partha

Hi Sandip,

Regards,
Ram

Best,
Sandip Shah

---

From: Leon Portman <[email-masked]>
Date: Tue, 6 Sep 2011 19:26:17 +0300

I agree that SRS should not assume 2 or more participants.

Regarding participant definition, can we just relay on 3261 RFC that defines SIP transaction users (UAC and UAS)?

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Tuesday, September 06, 2011 5:30 PM
To: Ravindran Parthasarathi; Sandipkumar Shah (sandshah); [email-masked]
Subject: [siprec] Should we allow minimum number of participants in a CS to be 1 ? ( was RE: Comments/Suggestions on - draft-ietf-siprec-metadata-03)

Comments ?

Regards,
Ram

Hi Sandip,

Please read inline.

Thanks
Partha

Hi Sandip,

1) As meeting is schedule (e.g. Microsoft outlook) Organizer can specifies lot of information a. Specify Meeting subject.
b. May specify tags associated with meeting topic. E.g. Once video is uploaded on youtube.com user can specify tags for searching videos.
<ceo/> <allhands/> <Q4Result> <cfo/> <hiring/> <offshore/>

Regards,
Ram

Best,
Sandip Shah

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 6 Sep 2011 19:06:24 +0200

I would observe that some recent decisions have ended up on the side of flexibility, rather than constraining things too much, even if at present we only see corner cases requiring this flexibility.  Removing the minimum number of participants would seem to be consistent with this principle.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: 06 September 2011 17:26
> To: Ram Mohan R (rmohanr); Ravindran Parthasarathi; 
> Sandipkumar Shah (sandshah); [email-masked]
> Subject: Re: [siprec] Should we allow minimum number of 
> participants in a CS to be 1 ? ( was RE: Comments/Suggestions 
> on - draft-ietf-siprec-metadata-03)
> 
> Regarding participant definition, can we just relay on 3261 
> RFC that defines SIP transaction users (UAC and UAS)?
> 
> Leon
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Subject: [siprec] Should we allow minimum number of 
> participants in a CS to be 1 ? ( was RE: Comments/Suggestions 
> on - draft-ietf-siprec-metadata-03)
> 
> Sandip has raised this issue on the CS having a restriction 
> of minimum two participants in the current model. 
> He cites the use-cases of recording studio which was 
> discussed in the past as an example of use-case having one 
> participant, however majority of folks see this use-case as 
> having two participants from the earlier discussions.
> 
> The open item that is not yet closed in the earlier 
> discussions is in case an SRS receives a metadata XML with a 
> session element having only one participant should SRS reject 
> the metadata or still accept ?
> (was discussed here earlier - 
> http://www.ietf.org/mail-archive/web/siprec/current/msg02429.h
tml but no consensus was reached)

Comments ?

Regards,
Ram

Hi Sandip,

Please read inline.

Thanks
Partha

Hi Sandip,

Regards,
Ram

Best,
Sandip Shah

---

From: "Sandipkumar Shah (sandshah)" <[email-masked]>
Date: Tue, 6 Sep 2011 10:51:43 -0700

Thanks Ram and Partha. Please see my comments below.

Best,

Sandip Shah

From: Ravindran Parthasarathi [mailto:[email-masked]] 
Sent: Monday, September 05, 2011 10:44 AM
To: Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah); [email-masked]
Subject: RE: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

Hi Sandip,

Please read inline.

Thanks

Partha

Hi Sandip,

 

[Sandip Shah] 
 
Hopefully following diagram clarifies above usecase.

  	

 

   

SIPREC aware  UA

    

   

  

    

SIPREC 

SRC

(B2BUA)

   

  

    

SIPREC SRS

   

 

                                                       SIP(audio/video)
SIP(audio/video)

  	

  	

  	

 

 

 

 
[Sandip Shah] 
Thanks. Makes sense.
 
 We need to be able to specify more rich metadata without using
<extensiondata> to increase great adoption.
[Partha] we have done a long exercise in the metadata model between
IETF78 to IETF-80 about the number of attributes for each metadata
block. Lot of call centre specific attributes, application extensions
are discussed in couple of meeting. Even it was apparent that there was
need for  some call center specific metadata which lot of folks are
interested but those attributes are not generic enough to mention within
SIPREC metadata. Please look into old SIPREC archive for more details.
Currently, we are having open items for attributes like contact params,
CSRC.
[Sandip Shah] 
I also feel there is a need to define more metadata related to specific
segment - contact center, video meetings etc. Probably this group can
define SIP REC metadata extension for industry specific segments. 
 
[Sandip Shah] 

 
 
Regards,
Ram
 
Best,
Sandip Shah

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 6 Sep 2011 23:46:21 +0530

Hi Sandip,

Please read inline.

Thanks

Partha

From: Sandipkumar Shah (sandshah) [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 11:22 PM
To: Ravindran Parthasarathi; Ram Mohan R (rmohanr); [email-masked]
Subject: RE: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

Best,

Sandip Shah

Hi Sandip,

Please read inline.

Thanks

Partha

Hi Sandip,

 

 

  	

 

   

SIPREC aware  UA

    

   

  

    

SIPREC 

SRC

(B2BUA)

   

  

    

SIPREC SRS

   

 

                                                       SIP(audio/video)
SIP(audio/video)

  	

  	

  	

 

[Partha] Please note that SIPREC aware UA is one participant (user),
SIPREC SRC is the second participant (automata device) and CS is
established between these two devices. SIPREC metadata has contact param
in participant which helps to differentiate whether the communicating
participant is user or automata.  Hope this clarifies this doubt.

 
 
1)As meeting is schedule (e.g. Microsoft outlook) Organizer can

 
 
[Partha] I agree with you that it is good to be standardized but it may
not within IETF. In case lot of interest and appropriate standard place
is found, we will work on it. I'm also interested as much you are.

 

Regards,
Ram
 
Best,
Sandip Shah

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 6 Sep 2011 23:55:47 +0530

Hi John,

I guess that your e-mail client is not doing wrap text automatically. I
discussed with Ram to understand whether he is able to read in his
e-mail client and he has no issues in reading this mail. I have other
problem in case I do the line breaking myself because the wrap text
happens automatically and also include my own statement break. So, each
line will be seen as 2 lines in some views (reading-pane view).

I'll break the statement for you in future in case the statement is
going too lengthy.

Thanks

Partha

From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 2:00 PM
To: Ravindran Parthasarathi; Ram Mohan R (rmohanr); Sandipkumar Shah
(sandshah); [email-masked]
Subject: RE: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

This thread is getting impossible to follow because folks are not
putting line breaks in their text.

At least on my client it means scrolling left and right all the time to
read it. Please exercise some discipline.

John

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ravindran Parthasarathi
	Sent: 05 September 2011 18:44
	To: Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah);
[email-masked]
	Subject: Re: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

	Hi Sandip,

	Please read inline.

	Thanks

	Partha

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ram Mohan R (rmohanr)
	Sent: Monday, September 05, 2011 8:57 PM
	To: Sandipkumar Shah (sandshah); [email-masked]
	Subject: Re: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

	Hi Sandip,

	Sorry for delay in response as I was busy publishing the new
version of the metadata draft. Please see inline <Ram> for answers

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sandipkumar Shah (sandshah)
	Sent: Thursday, September 01, 2011 12:57 AM
	To: [email-masked]
	Subject: [siprec] Comments/Suggestions on -
draft-ietf-siprec-metadata-03

	 
	[Sandip] It should say - "CS to have at least one or more
participants."
	Let's take a use case. A company executive wants to record all
hands kind of meeting from recording studio or any telepresence room. In
such case CS will have only one participant.

	Thread
http://www.ietf.org/mail-archive/web/siprec/current/msg02367.html
discussed the same. Just wanted to make sure this will be incorporated
in next draft.

	<Ram>Ver-04 does not include this as from the last discussion we
had there was no concrete consensus in the WG to add this.  The last
mail on this thread is here -
http://www.ietf.org/mail-archive/web/siprec/current/msg02451.html.  I
will re-start the discussion on this and ask for a consensus on which
way to go. 

	[Partha] I have really tough time in understanding CS with
single participant. I could not figure out how Voice mail or studio
recording falls within SIPREC architecture with different CS and RS. Let
us discuss in the interim meeting for the closure.

	Telepresence based (audio/video/presentation)
meetings/recordings has needs to convey much more richer metadata so
that recorded video becomes more searchable and hence increase
consumption. Here are few examples.
	 
	1)  As meeting is schedule (e.g. Microsoft outlook) Organizer
can specifies lot of information 
	a.  Specify Meeting subject.
	b.  May specify tags associated with meeting topic. E.g. Once
video is uploaded on youtube.com user can specify tags for searching
videos.
	<ceo/> <allhands/> <Q4Result> <cfo/> <hiring/> <offshore/>

	c.  Recording system can be communicating with speech
recognition system for mining more data. Organizer can provide grammar
that can be sent to speech
	Recognition system. Similar to what VoiceXML allows.
	 
	UA may not be able to provide above mentioned information to SRC
using SIP however SRC can access the information (via its custom
mechanism) and provide to SRS so that it can associate these richer
metadata with recording.
	 
	Looking at present metadata, it is providing few additional
information such as AOR, Displayname, start/endtime, additional
participants etc. to SRS.
	While this is useful metadata, implementations can derive these
information from SIP headers when possible and probably that is what
today's recording implementation
	in market may be doing.
	[Partha] There are "n" number of SIP header based mechanism
exist in the market. It is one of the main motivation for this work to
be standardized.
	Recording Metadata in SIP headers has "n" number of issues like
how to group participant to media stream, how to group multiple CS, how
to represent the single participant is not receiving the stream whereas
others are receiving, defining the unique-id mechanism to identify the
individual CS. The authors of metadata explored the mechanism to pass
the metadata in SDP and again it has other pitfalls. So, we decided to
go with message body approach. JSON, XML, ASN.1 notation are considered
for message body and then XML was chosen as a data representation for
metadata. Hope this clarifies.
	 
	 We need to be able to specify more rich metadata without using
<extensiondata> to increase great adoption.
	[Partha] we have done a long exercise in the metadata model
between IETF78 to IETF-80 about the number of attributes for each
metadata block. Lot of call centre specific attributes, application
extensions are discussed in couple of meeting. Even it was apparent that
there was need for  some call center specific metadata which lot of
folks are interested but those attributes are not generic enough to
mention within SIPREC metadata. Please look into old SIPREC archive for
more details. Currently, we are having open items for attributes like
contact params, CSRC.
	 
	 Generic attribute MUST apply for all kind of SRC like UA,
B2BUA, focus. In case you have any specific generic attribute in mind,
Please let us know.
	 
	<Ram> This is a new use-case which has not been discussed so
far. The current approach that is followed in the draft is  metadata has
mostly attributes that can be derived from CS SIP session (both from
SIP/SDP).  I think what you are asking for is information that can be
learnt from outside SIP to be carried in metadata. The initial proposal
of metadata had several such attributes but after subsequent discussions
in mailer, several folks in WG where not in favor of having element that
are not learned from SIP / SDP in the XML. Can you please start a new
thread for this use-case to get the WG opinion on the new attributes you
are suggesting ?
	 
	Suggestion on section 7.1 :
	In order to understand it better and correlate with SIP
signaling, I suggest to put SIP signaling with SDP also in place.
Additionally put comments in the 
	Example metadata xml so one can understand the example better.
	 
	<Ram> In version -04 of metadata I have included some XML
examples in Appendix. I have included SDP snippets at some places along
with XML to make it clear. Please review and let me know if you need
more clarity. Note we initially had complete examples but later removed
them as we received comments to  have the SIP things moved to protocol
document.
	 
	Regards,
	Ram
	 
	Best,
	Sandip Shah

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 6 Sep 2011 21:20:49 +0200

If I am the only one, don't worry - but I had heard others complaining about similar messages on other lists in the past.

John

________________________________
From: Ravindran Parthasarathi [mailto:[email-masked]]
Sent: 06 September 2011 19:26
To: Elwell, John; Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah); [email-masked]
Subject: RE: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

Hi John,

I guess that your e-mail client is not doing wrap text automatically. I discussed with Ram to understand whether he is able to read in his e-mail client and he has no issues in reading this mail. I have other problem in case I do the line breaking myself because the wrap text happens automatically and also include my own statement break. So, each line will be seen as 2 lines in some views (reading-pane view).

I'll break the statement for you in future in case the statement is going too lengthy.

Thanks
Partha

From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, September 06, 2011 2:00 PM
To: Ravindran Parthasarathi; Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah); [email-masked]
Subject: RE: [siprec] Comments/Suggestions on - draft-ietf-siprec-metadata-03

John

Please read inline.

Thanks
Partha

Hi Sandip,

in market may be doing.

Regards,

Ram

Best,

Sandip Shah

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 6 Sep 2011 13:58:20 -0700

I find it much easier to follow long threads when text formatting is
used. Once rich text/html is used, it becomes very difficult to follow
and the rendering becomes mail client specific. That is why I use text
only whenever possible.
Just my 2 cents.

Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Tuesday, September 06, 2011 12:21 PM
> 
> If I am the only one, don't worry - but I had heard others complaining
about similar messages on other
> lists in the past.
> 
> 
> 
> 	Hi John,
> 
> 
> 
> 	I guess that your e-mail client is not doing wrap text
automatically. I discussed with Ram to
> understand whether he is able to read in his e-mail client and he has
no issues in reading this mail.
> I have other problem in case I do the line breaking myself because the
wrap text happens automatically
> and also include my own statement break. So, each line will be seen as
2 lines in some views (reading-
> pane view).
> 
> 
> 
> 	This thread is getting impossible to follow because folks are
not putting line breaks in their
> text.
> 
> 	At least on my client it means scrolling left and right all the
time to read it. Please exercise
> some discipline.
[mailto:[email-masked]] On Behalf Of Ravindran
> Parthasarathi
[email-masked]
> 		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ram Mohan R
> (rmohanr)
> 
> 
> 
> 		Hi Sandip,
> 
> 
> 
> 		Sorry for delay in response as I was busy publishing the
new version of the metadata
> draft. Please see inline <Ram> for answers
> 
> 
> 
[mailto:[email-masked]] On Behalf Of Sandipkumar
> Shah (sandshah)
> 		Let's take a use case. A company executive wants to
record all hands kind of meeting from
> recording studio or any telepresence room. In such case CS will have
only one participant.
discussed the
> same. Just wanted to make sure this will be incorporated in next
draft.
> 
> 		<Ram>Ver-04 does not include this as from the last
discussion we had there was no concrete
> consensus in the WG to add this.  The last mail on this thread is here
- http://www.ietf.org/mail-
> archive/web/siprec/current/msg02451.html.  I will re-start the
discussion on this and ask for a
> consensus on which way to go.
> 
> 
> 		[Partha] I have really tough time in understanding CS
with single participant. I could not
> figure out how Voice mail or studio recording falls within SIPREC
architecture with different CS and
> RS. Let us discuss in the interim meeting for the closure.
> 
meetings/recordings has needs to convey much
> more richer metadata so that recorded video becomes more searchable
and hence increase consumption.
> Here are few examples.
> 
> 		1)  As meeting is schedule (e.g. Microsoft outlook)
Organizer can specifies lot of
> information
> 		b.  May specify tags associated with meeting topic. E.g.
Once video is uploaded on
> youtube.com user can specify tags for searching videos.
recognition system for mining more
> data. Organizer can provide grammar that can be sent to speech
> 		UA may not be able to provide above mentioned
information to SRC using SIP however SRC can
> access the information (via its custom mechanism) and provide to SRS
so that it can associate these
> richer metadata with recording.
> 
> 		Looking at present metadata, it is providing few
additional information such as AOR,
> Displayname, start/endtime, additional participants etc. to SRS.
> 		While this is useful metadata, implementations can
derive these information from SIP
> headers when possible and probably that is what today's recording
implementation
> 		in market may be doing.
> 		[Partha] There are "n" number of SIP header based
mechanism exist in the market. It is one
> of the main motivation for this work to be standardized.
> 		Recording Metadata in SIP headers has "n" number of
issues like how to group participant
> to media stream, how to group multiple CS, how to represent the single
participant is not receiving
> the stream whereas others are receiving, defining the unique-id
mechanism to identify the individual
> CS. The authors of metadata explored the mechanism to pass the
metadata in SDP and again it has other
> pitfalls. So, we decided to go with message body approach. JSON, XML,
ASN.1 notation are considered
> 
> 		 We need to be able to specify more rich metadata
without using <extensiondata> to
> increase great adoption.
> 		[Partha] we have done a long exercise in the metadata
model between IETF78 to IETF-80
> about the number of attributes for each metadata block. Lot of call
centre specific attributes,
> application extensions are discussed in couple of meeting. Even it was
apparent that there was need
> for  some call center specific metadata which lot of folks are
interested but those attributes are not
> generic enough to mention within SIPREC metadata. Please look into old
SIPREC archive for more
> details. Currently, we are having open items for attributes like
contact params, CSRC.
> 
> 		 Generic attribute MUST apply for all kind of SRC like
UA, B2BUA, focus. In case you have
> any specific generic attribute in mind, Please let us know.
> 
> 		<Ram> This is a new use-case which has not been
discussed so far. The current approach
> that is followed in the draft is  metadata has mostly attributes that
can be derived from CS SIP
> session (both from SIP/SDP).  I think what you are asking for is
information that can be learnt from
> outside SIP to be carried in metadata. The initial proposal of
metadata had several such attributes
> but after subsequent discussions in mailer, several folks in WG where
not in favor of having element
> that are not learned from SIP / SDP in the XML. Can you please start a
new thread for this use-case to
> get the WG opinion on the new attributes you are suggesting ?
> 
signaling, I suggest to put SIP
> signaling with SDP also in place. Additionally put comments in the
> 		<Ram> In version -04 of metadata I have included some
XML examples in Appendix. I have
> included SDP snippets at some places along with XML to make it clear.
Please review and let me know if
> you need more clarity. Note we initially had complete examples but
later removed them as we received
> comments to  have the SIP things moved to protocol document.
> 
> 		Regards,
> 		Ram
> 
> 		Best,
> 		Sandip Shah
> 
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 6 Sep 2011 15:10:06 -0700

I am in favor of relaxing this restriction to allow a CS to have 0 or more participants.
0 participants could be a conference call in which no one has joined.
1 participant could be a conference call in which one participant has joined, or it could be a studio mode recording.
If there is some automata, it is up the SRC to include that automata as a participant or not. 
I do not see much benefit in providing any restrictions in the number of participants.

Cheers,
Charles

> Sent: Tuesday, September 06, 2011 7:30 AM
> Subject: [siprec] Should we allow minimum number of participants in a CS tobe 1 ? ( was RE:
> Comments/Suggestions on -draft-ietf-siprec-metadata-03)
> 
> He cites the use-cases of recording studio which was discussed in the past as an example of use-case
> having one participant, however majority of folks see this use-case as having two participants from
> the earlier discussions.
> 
> The open item that is not yet closed in the earlier discussions is in case an SRS receives a metadata
> XML with a session element having only one participant should SRS reject the metadata or still accept
> ?
> IMO SRS should be liberal and accept the metadata if that is all what an SRC can provide. It is better
> to have some information(metadata) rather than having nothing at all.
> 
> There was also a question earlier on what the definition of a participant really is ? None of the
> documents defines this even though every SIPREC document uses it.
> 
> Comments ?
> 
> Regards,
> Ram
> 
> 
> Let's take a use case. A company executive wants to record all hands kind of meeting from recording
> studio or any telepresence room. In such case CS will have only one participant.
> 
> Thread http://www.ietf.org/mail-archive/web/siprec/current/msg02367.html discussed the same. Just
> wanted to make sure this will be incorporated in next draft.
> <Ram>Ver-04 does not include this as from the last discussion we had there was no concrete consensus
> in the WG to add this.  The last mail on this thread is here - http://www.ietf.org/mail-
> archive/web/siprec/current/msg02451.html.  I will re-start the discussion on this and ask for a
> [Partha] I have really tough time in understanding CS with single participant. I could not figure out
> how Voice mail or studio recording falls within SIPREC architecture with different CS and RS. Let us
> Telepresence based (audio/video/presentation) meetings/recordings has needs to convey much more richer
> metadata so that recorded video becomes more searchable and hence increase consumption. Here are few
> examples.
> 
> c. Recording system can be communicating with speech recognition system for mining more data.
> Organizer can provide grammar that can be sent to speech
> UA may not be able to provide above mentioned information to SRC using SIP however SRC can access the
> information (via its custom mechanism) and provide to SRS so that it can associate these richer
> metadata with recording.
> 
> Looking at present metadata, it is providing few additional information such as AOR, Displayname,
> start/endtime, additional participants etc. to SRS.
> While this is useful metadata, implementations can derive these information from SIP headers when
> possible and probably that is what today's recording implementation
> in market may be doing.
> [Partha] There are "n" number of SIP header based mechanism exist in the market. It is one of the main
> motivation for this work to be standardized.
> Recording Metadata in SIP headers has "n" number of issues like how to group participant to media
> stream, how to group multiple CS, how to represent the single participant is not receiving the stream
> whereas others are receiving, defining the unique-id mechanism to identify the individual CS. The
> authors of metadata explored the mechanism to pass the metadata in SDP and again it has other
> pitfalls. So, we decided to go with message body approach. JSON, XML, ASN.1 notation are considered
> for message body and then XML was chosen as a data representation for metadata. Hope this clarifies.
> 
> [Partha] we have done a long exercise in the metadata model between IETF78 to IETF-80 about the number
> of attributes for each metadata block. Lot of call centre specific attributes, application extensions
> are discussed in couple of meeting. Even it was apparent that there was need for  some call center
> specific metadata which lot of folks are interested but those attributes are not generic enough to
> mention within SIPREC metadata. Please look into old SIPREC archive for more details. Currently, we
> are having open items for attributes like contact params, CSRC.
> 
>  Generic attribute MUST apply for all kind of SRC like UA, B2BUA, focus. In case you have any specific
> generic attribute in mind, Please let us know.
> 
> <Ram> This is a new use-case which has not been discussed so far. The current approach that is
> followed in the draft is  metadata has mostly attributes that can be derived from CS SIP session (both
> from SIP/SDP).  I think what you are asking for is information that can be learnt from outside SIP to
> be carried in metadata. The initial proposal of metadata had several such attributes but after
> subsequent discussions in mailer, several folks in WG where not in favor of having element that are
> not learned from SIP / SDP in the XML. Can you please start a new thread for this use-case to get the
> WG opinion on the new attributes you are suggesting ?
> 
> In order to understand it better and correlate with SIP signaling, I suggest to put SIP signaling with
> SDP also in place. Additionally put comments in the
> <Ram> In version -04 of metadata I have included some XML examples in Appendix. I have included SDP
> snippets at some places along with XML to make it clear. Please review and let me know if you need
> more clarity. Note we initially had complete examples but later removed them as we received comments
> to  have the SIP things moved to protocol document.
> 
> Regards,
> Ram
> 
> Best,
> Sandip Shah
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Sep 2011 19:03:40 -0400

My mail reader (Thunderbird) also displays paragraphs with no line 
breaks as a single line. So it also annoys me, a bit.
But frankly I have considered that to be a limitation of Thunderbird, 
not the fault of the sender. Its pretty common to encode paragraphs 
without line breaks so the UI can do the breaking where it works best 
for the reader.

So I don't complain about this.

	Thanks,
	Paul

On 9/6/11 3:20 PM, Elwell, John wrote:
> about similar messages on other lists in the past.
> John
>
>     ------------------------------------------------------------------------
>     *From:* Ravindran Parthasarathi [mailto:[email-masked]]
>     *Sent:* 06 September 2011 19:26
>     *To:* Elwell, John; Ram Mohan R (rmohanr); Sandipkumar Shah
>     *Subject:* RE: [siprec] Comments/Suggestions on -
>     automatically. I discussed with Ram to understand whether he is able
>     to read in his e-mail client and he has no issues in reading this
>     mail. I have other problem in case I do the line breaking myself
>     because the wrap text happens automatically and also include my own
>     statement break. So, each line will be seen as 2 lines in some views
>     (reading-pane view).
>
>     I’ll break the statement for you in future in case the statement is
>     going too lengthy.
>
>     Thanks
>
>     Partha
>
>     *From:*Elwell, John [mailto:[email-masked]]
>     *Sent:* Tuesday, September 06, 2011 2:00 PM
>     *To:* Ravindran Parthasarathi; Ram Mohan R (rmohanr); Sandipkumar
>     Shah (sandshah); [email-masked]
>     *Subject:* RE: [siprec] Comments/Suggestions on -
>     At least on my client it means scrolling left and right all the time
>     to read it. Please exercise some discipline.
>
>     John
>
>         ------------------------------------------------------------------------
>
>         *From:[email-masked] [mailto:[email-masked]]
>         *On Behalf Of *Ravindran Parthasarathi
>         *Sent:* 05 September 2011 18:44
>         *To:* Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah);
>         [email-masked]
>         *Subject:* Re: [siprec] Comments/Suggestions on -
>         *From:[email-masked] [mailto:[email-masked]]
>         *On Behalf Of *Ram Mohan R (rmohanr)
>         *Sent:* Monday, September 05, 2011 8:57 PM
>         *To:* Sandipkumar Shah (sandshah); [email-masked]
>         *Subject:* Re: [siprec] Comments/Suggestions on -
>         *From:[email-masked] [mailto:[email-masked]]
>         *On Behalf Of *Sandipkumar Shah (sandshah)
>         *Sent:* Thursday, September 01, 2011 12:57 AM
>         *To:* [email-masked]
>         *Subject:* [siprec] Comments/Suggestions on -
>         *Section 6.3.2 SIP REC Metadata :    *
>
>
>
>         [Draft] CS to have at least*two*  or more participants.
>
>
>
>         [Sandip] It should say–  “CS to have at least*one*  or more participants.”
>
>         Let’s take a use case. A company executive wants to record all hands kind of meeting from recording studio or any telepresence room. In such case CS will have only one participant.
>
>
>
>         Thread
>         http://www.ietf.org/mail-archive/web/siprec/current/msg02367.html discussed
>         the same. Just wanted to make sure this will be incorporated in
>         next draft.
>
>         had there was no concrete consensus in the WG to add this. The
>         last mail on this thread is here -
>         http://www.ietf.org/mail-archive/web/siprec/current/msg02451.html.
>         I will re-start the discussion on this and ask for a consensus
>         on which way to go.
>
>
>
>         */[Partha] I have really tough time in understanding CS with single participant. I could not figure out how Voice mail or studio recording falls within SIPREC architecture with different CS and RS. Let us discuss in the interim meeting for the closure./*
>
>
>
>         *General comment on metadata :*
>
>
>
>         While this is useful metadata, implementations can derive these information from SIP headers when possible and probably that is what today’s recording implementation
>
>         in market may be doing.
>
>         */[Partha] There are“n”  number of SIP header based mechanism exist in the market. It is one of the main motivation for this work to be standardized./*
>
>         */Recording Metadata in SIP headers has“n”  number of issues like how to group participant to media stream, how to group multiple CS, how to represent the single participant is not receiving the stream whereas others are receiving, defining the unique-id mechanism to identify the individual CS. The authors of metadata explored the mechanism to pass the metadata in SDP and again it has other pitfalls. So, we decided to go with message body approach. JSON, XML, ASN.1 notation are considered for message body and then XML was chosen as a data representation for metadata. Hope this clarifies./*
>
>         */  /*
>
>           We need to be able to specify more rich metadata without using<extensiondata>  to increase great adoption.
>
>         */[Partha] we have done a long exercise in the metadata model between IETF78 to IETF-80 about the number of attributes for each metadata block. Lot of call centre specific attributes, application extensions are discussed in couple of meeting. Even it was apparent that there was need for  some call center specific metadata which lot of folks are interested but those attributes are not generic enough to mention within SIPREC metadata. Please look into old SIPREC archive for more details. Currently, we are having open items for attributes like contact params, CSRC./*
>
>         */  /*
>
>         */  Generic attribute MUST apply for all kind of SRC like UA, B2BUA, focus. In case you have any specific generic attribute in mind, Please let us know./*
>
>
>
>         *Suggestion on section 7.1 :*
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Sep 2011 19:38:19 -0400

+1

On 9/6/11 4:58 PM, Charles Eckel (eckelcu) wrote:
>> draft. Please see inline<Ram>  for answers
>>
>>
>>
> without using<extensiondata>  to
>> increase great adoption.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 7 Sep 2011 09:07:32 +0530

I think it's better to stick to text formatting as most of the e-mail
clients support the same

Ram

> Behalf Of Paul Kyzivat
> Sent: Wednesday, September 07, 2011 4:34 AM
> To: [email-masked]
> Subject: [siprec] Email formatting
> 
-----------------------------------------------------------------
> -------
not
> time
-------------------------------------------------------------
> -----------
> >         [Sandip] It should say-  "CS to have at least*one*  or more
> participants."
> >
> >         Let's take a use case. A company executive wants to record
> all hands kind of meeting from recording studio or any telepresence
> room. In such case CS will have only one participant.
> >
> >
> >
> >         Thread
> >         http://www.ietf.org/mail-
> archive/web/siprec/current/msg02367.html discussed
discussion
> we
> >         http://www.ietf.org/mail-
> archive/web/siprec/current/msg02451.html.
> >         */[Partha] I have really tough time in understanding CS with
> recording falls within SIPREC architecture with different CS and RS.
> Let us discuss in the interim meeting for the closure./*
> >
> >
> >
> Organizer can specifies lot of information
> >
> Once video is uploaded on youtube.com user can specify tags for
> searching videos.
> >
> >         UA may not be able to provide above mentioned information to
> SRC using SIP however SRC can access the information (via its custom
> >         While this is useful metadata, implementations can derive
> these information from SIP headers when possible and probably that is
> what today's recording implementation
> >
> >         in market may be doing.
> >
> >         */[Partha] There are"n"  number of SIP header based
mechanism
> be standardized./*
> >         */Recording Metadata in SIP headers has"n"  number of issues
> like how to group participant to media stream, how to group multiple
> CS, how to represent the single participant is not receiving the
stream
> whereas others are receiving, defining the unique-id mechanism to
> identify the individual CS. The authors of metadata explored the
> mechanism to pass the metadata in SDP and again it has other pitfalls.
> So, we decided to go with message body approach. JSON, XML, ASN.1
> notation are considered for message body and then XML was chosen as a
> data representation for metadata. Hope this clarifies./*
> >
> >         */  /*
> >
> >           We need to be able to specify more rich metadata without
> using<extensiondata>  to increase great adoption.
> >
> >         */[Partha] we have done a long exercise in the metadata
model
> extensions are discussed in couple of meeting. Even it was apparent
> that there was need for  some call center specific metadata which lot
> of folks are interested but those attributes are not generic enough to
> contact params, CSRC./*
> >         */  Generic attribute MUST apply for all kind of SRC like
UA,
> Please let us know./*
> far. The current approach that is followed in the draft is  metadata
> has mostly attributes that can be derived from CS SIP session (both
> from SIP/SDP).  I think what you are asking for is information that
can
> be learnt from outside SIP to be carried in metadata. The initial
> proposal of metadata had several such attributes but after subsequent
> discussions in mailer, several folks in WG where not in favor of
having
> element that are not learned from SIP / SDP in the XML. Can you please
> start a new thread for this use-case to get the WG opinion on the new
> attributes you are suggesting ?
> >
> >
> >

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 7 Sep 2011 11:07:29 +0530

Hi Charles,

In case the intention is to have 0 to n participants in the recording session, we need to tighten our definition of CS and other stuff to make it work. I remember in the past, there was discussion for RS persistent connection with no participant and no CS but there was consensus not to allow it. If those scenario has to be re-considered, we will discuss in detail.

Thanks
Partha 

>From: Charles Eckel (eckelcu) [mailto:[email-masked]]
>Sent: Wednesday, September 07, 2011 3:40 AM
>To: Ram Mohan R (rmohanr); Ravindran Parthasarathi; Sandipkumar Shah
>Subject: RE: [siprec] Should we allow minimum number of participants in
>a CS tobe 1 ? ( was RE: Comments/Suggestions on -draft-ietf-siprec-
>metadata-03)
>
>1 participant could be a conference call in which one participant has
>joined, or it could be a studio mode recording.
>Behalf Of Ram Mohan R (rmohanr)
>> Sandip has raised this issue on the CS having a restriction of minimum
>two participants in the current
>> model.
>> (was discussed here earlier - http://www.ietf.org/mail-
>archive/web/siprec/current/msg02429.html but no
>> consensus was reached)
>>
>Behalf Of Ram Mohan R (rmohanr)
>> Sorry for delay in response as I was busy publishing the new version
>of the metadata draft. Please see
>> inline <Ram> for answers
>>
>Behalf Of Sandipkumar Shah
>> (sandshah)
>kind of meeting from recording
>> Thread http://www.ietf.org/mail-
>archive/web/siprec/current/msg02367.html discussed the same. Just
>there was no concrete consensus
>participant. I could not figure out
>needs to convey much more richer
>SIP however SRC can access the
>information such as AOR, Displayname,
>information from SIP headers when
>group participant to media
>identify the individual CS. The
>IETF78 to IETF-80 about the number
>current approach that is
>can be learnt from outside SIP to
>suggest to put SIP signaling with
>Appendix. I have included SDP

---

From: "Feenstra, Friso" <[email-masked]>
Date: Wed, 7 Sep 2011 08:14:59 +0000

Hi all,

As a new participant I would like to propose the following notion:

SIP recording is meant for the recording of media streams (MS) where a MS is always send from a media stream source (MSS) to a media stream destination (MSD). The information passed on through the MS is called the content of the MS. 

Communication between UA's consists of one or multiple MS's. MS's are initiated using SIP messaging. MSS's create the content for MS's, either by producing the new content, transparently passing content of one MS to another MS, by mixing multiple incoming MS's or by mixing multiple incoming MS's with new content.

This leads then to the following use cases:
A straight forward call between two UA's will normally have two MS's. One from UA to UB and one from UB to UA. Each UA creates its own content.

A B2BUA will have four MS's. One from UA to B2BUA, one from B2BUA to UB, one from UB to B2BUA and one from B2BUA to UA. UA and UB create the new content. The B2BUA uses to incoming content from one MS to create the content for the outgoing MS.

A conference bridge / recording studio can have zero MS's, when there is nobody there. It can also have two MS's when the first participant dials in and the participant gets information about the information about the status of the bridge ('you are the first participant, please wait etc.') and provides DMTF information on the available options. As soon as more people join then number of MS's increase, with the conference bridge mixing the MS's.

A conference bridge / recording studio can also have one MS for instance when the first participant has dialled in, the conference bridge is providing music-on-hold and is not listening to input from the first participant. Other broadcast types of communication can also have a single media stream.

This way there are always an even number of participants in the CS as each CS is made-up of multiple MS's and each MS will have a MSS participant and a MSD participant.

Regards,
Friso Feenstra (as an individual)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: woensdag 7 september 2011 7:37
To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Sandipkumar Shah (sandshah); [email-masked]
Subject: Re: [siprec] Should we allow minimum number of participants in a CS to be 1 ? ( was RE: Comments/Suggestions on -draft-ietf-siprec-metadata-03)

Hi Charles,

Thanks
Partha 

Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.