Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML

From: Leon Portman <[email-masked]>
Date: Sun, 3 Jul 2011 13:43:16 +0300

I do prefer that metadata XML will be as self-contained as possible and not rely on conveying some data via RS SDP. RS SDP should only be used to recording establishment and negotiation and not as a mechanism for metadata reporting.

Otherwise we will not be able to reuse same format for reporting metadata via web services or as dedicated SIP session.

As for examples, the basic information as media type, labels, volume etc. Any application level data can be relevant. Even indication of encryption (for a case where RS is not encrypted)

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Wednesday, June 29, 2011 7:17 PM
To: Elwell, John; Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML

I think it is sufficient, especially since we can assign new values if necessary.
Are there any examples of what people think they might want to capture in the SDP and/or metadata field?

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Tuesday, June 28, 2011 3:11 AM
> To: Parthasarathi R (partr); [email-masked]
> Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML
> 
> I would like other opinions on whether the SDP a=content attribute in
the RS SDP has the correct
> semantics for representing the content type of the recorded CS media
stream.
> 
> John
> 
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > Sent: 28 June 2011 10:45
> > To: Elwell, John; [email-masked]
> > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> > Subject: RE: Content (RFC 4796) attribute in SDP or XML
> >
> > John,
> >
> > In case if it is the argument of whether CS MS content type or RS MS 
> > content type in the metadata, it is better for us to re-open ticket 
> > #71 
> > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html).
> > Please let me know your opinion here.
> >
> > The basic idea in metadata format is to re-use as much as SDP 
> > attribute (like direction, content) in media level for RS dialog 
> > (using SDP label attribute as a pointer) until otherwise there is a 
> > restriction in using in such manner. As per RFC 4796, there is no 
> > such restriction and so, I prefer to reuse as content SDP attribute 
> > rather than introducing the new <content-type> element for this 
> > purpose.
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]]
> > Sent: Monday, June 27, 2011 1:18 PM
> > To: Parthasarathi R (partr); [email-masked]
> > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> > Subject: RE: Content (RFC 4796) attribute in SDP or XML
> >
> >
> >
> > > -----Original Message-----
> > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > Sent: 27 June 2011 08:08
> > > To: [email-masked]; Elwell, John
> > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> > > Subject: Content (RFC 4796) attribute in SDP or XML
> > >
> > > Hi all,
> > >
> > > As per the last interim SIPREC meeting, there is a consensus to 
> > > describe the content of an MS using RFC 4796 & its
> > extension. As per
> > > RFC 4796, the multiple instance of content attribute is possible
to
> > > exist in SDP which shall be used in RS SDP. SRS shall group
> > the same
> > > media content types by "content" attribute in RS SDP. We are 
> > > interested in knowing any specfic reason for this attribute to be 
> > > duplicated in Metadata XML.
> > [JRE] I don't have a reason for **duplication**. However, I think 
> > there is a valid question to be asked whether the content type of an 
> > MS should be represented:
> > A) in XML; or
> > B) in RS SDP as a=content.
> >
> > The content type we are talking about is an MS content type, i.e., 
> > relating to the CS. One could argue that the corresponding RS stream 
> > is NOT the same content type. For example:
> > - CS MS content type is "slides".
> > - RS media stream content type is "recording of slides".
> >
> > On this basis, I think the correct option for conveying the MS
content
> > type "slides" is A) (in the XML).
> >
> > Note that this would not involve duplication. The SDP a=content 
> > attribute is optional, so we need not use it for the RS.
> >
> > Perhaps my distinction is too theoretical, but I do feel a little
more
> > comfortable using the XML rather than the RS SDP.
> >
> > John (as individual)
> >
> >
> > >
> > > Thanks
> > >
> > > Partha
> > >
> > > last Interim SIPREC meeting Note:
> > >
> > > Slide 7: On the question of how to describe the content of an MS, 
> > > there was no objection to basing this on the types in the RFC 4796 
> > > registry (new values could be specified via the appropriate
> > means if
> > > needed). Paul had a slight concern that you might be mixing
> > multiple
> > > CS MSs into a single RS media stream and whether this might
> > result in
> > > cases not describable in this way, but in the end accepted the 
> > > consensus. It needs to be discussed on the list whether this is 
> > > conveyed in XML or in the RS SDP a=content attribute.
> > >
> > >
> >
> _______________________________________________
> 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: "Parthasarathi R (partr)" <[email-masked]>
Date: Sun, 3 Jul 2011 22:19:35 +0530

Leon,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Sunday, July 03, 2011 4:13 PM
To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr);
[email-masked]
Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML

I do prefer that metadata XML will be as self-contained as possible and
not rely on conveying some data via RS SDP. RS SDP should only be used
to recording establishment and negotiation and not as a mechanism for
metadata reporting.

<partha> In case Metadata XML has to be self-contained, the complete SDP
has to be converted into XML format or else XML has to have <content>
sort of XML attribute which carries SDP. Creating mapping for each SDP
attribute with metadata XML element does not  seems to be feasible
</partha>

Otherwise we will not be able to reuse same format for reporting
metadata via web services 
<partha> As per IETF-80 and last interim meeting, there is no intent of
reusing this metadata XML in other protocol. In case reusing same format
for webservice or XMPP is the intent, the current metadata XML mechanism
is not the appropriate. This was discussed in
http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html,
http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st
point in format slide). In case you have difference of opinion even
after this multiple discussion, let us again discuss at IETF-81.
</partha> 

or as dedicated SIP session.
<partha> In case Metadata is separate session from RS, RS attribute like
RS-id MUST be included within XML. This was discussed at
http://www.ietf.org/mail-archive/web/siprec/current/msg02013.html. Could
you please explain reason for the dedicated SIP session for metadata.
</partha>

As for examples, the basic information as media type, labels, volume
etc. Any application level data can be relevant. Even indication of
encryption (for a case where RS is not encrypted)

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Charles Eckel (eckelcu)
Sent: Wednesday, June 29, 2011 7:17 PM
To: Elwell, John; Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML

I think it is sufficient, especially since we can assign new values if
necessary.
Are there any examples of what people think they might want to capture
in the SDP and/or metadata field?

Cheers,
Charles

Behalf Of Elwell, John
stream.

to

content
more

---

From: Leon Portman <[email-masked]>
Date: Mon, 4 Jul 2011 09:40:50 +0300

Partha Hi

Please see below.

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: Sunday, July 03, 2011 7:50 PM
To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; [email-masked]
Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML

Leon,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: Sunday, July 03, 2011 4:13 PM
To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML

<partha> In case Metadata XML has to be self-contained, the complete SDP has to be converted into XML format or else XML has to have <content> sort of XML attribute which carries SDP. Creating mapping for each SDP attribute with metadata XML element does not  seems to be feasible </partha>

[LeonP] But if CS SDP is different from RS SDP, anyway you will need to encapsulate the original RS SDP, so why not in XML?

Otherwise we will not be able to reuse same format for reporting metadata via web services <partha> As per IETF-80 and last interim meeting, there is no intent of reusing this metadata XML in other protocol. In case reusing same format for webservice or XMPP is the intent, the current metadata XML mechanism is not the appropriate. This was discussed in http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html,
http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st
point in format slide). In case you have difference of opinion even after this multiple discussion, let us again discuss at IETF-81.
</partha> 

[LeonP] I was not proposing replacing SIP with another transport layer, just wanted to keep other options open. I am very big supporter for metadata over SIP reporting

or as dedicated SIP session.
<partha> In case Metadata is separate session from RS, RS attribute like RS-id MUST be included within XML. This was discussed at http://www.ietf.org/mail-archive/web/siprec/current/msg02013.html. Could you please explain reason for the dedicated SIP session for metadata.
</partha>

[LeonP] The main use case is Recording on Demand, that is triggered by SRS. In such case it will be very useful to have just one SIP session and send all metadata over it (like CTI link) and then only trigger recording (via external SRC interface) only for specific call segments.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Wednesday, June 29, 2011 7:17 PM
To: Elwell, John; Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML

Cheers,
Charles

Behalf Of Elwell, John
stream.

to

content
more

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 4 Jul 2011 12:37:45 +0530

Leon,

Please read inline.

Thanks
Partha

> Sent: Monday, July 04, 2011 12:11 PM
> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, 
> John; [email-masked]
> I do prefer that metadata XML will be as self-contained as 
> possible and not rely on conveying some data via RS SDP. RS 
> SDP should only be used to recording establishment and 
> negotiation and not as a mechanism for metadata reporting.
> 
> <Partha> In case Metadata XML has to be self-contained, the 
> complete SDP has to be converted into XML format or else XML 
> has to have <content> sort of XML attribute which carries 
> SDP. Creating mapping for each SDP attribute with metadata 
> XML element does not  seems to be feasible </Partha>
> 
> [LeonP] But if CS SDP is different from RS SDP, anyway you 
> will need to encapsulate the original RS SDP, so why not in XML?

<Partha> I guess that the confusion is here. In the current format, RS
SDP is only carried towards SRS and CS SDP is not forwarded. This design
is closed as part of ticket #71
(http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html).
Please bring up with the usecase for CS SDP if required </Partha>

> 
> Otherwise we will not be able to reuse same format for 
> reporting metadata via web services <Partha> As per IETF-80 
> and last interim meeting, there is no intent of reusing this 
> metadata XML in other protocol. In case reusing same format 
> for webservice or XMPP is the intent, the current metadata 
> XML mechanism is not the appropriate. This was discussed in 
> point in format slide). In case you have difference of 
> opinion even after this multiple discussion, let us again 
> discuss at IETF-81.
> </Partha> 
> 
> [LeonP] I was not proposing replacing SIP with another 
> transport layer, just wanted to keep other options open.

<Partha> Current metadata format is customized for SIP transport. In
case we need to keep the options open, the format has to be revisited
from the scratch. In our analysis, we notice that REST architecture with
Metadata XML is best fit for HTTP, XMPP </Partha>

 I am 
> very big supporter for metadata over SIP reporting
> 
<Partha> Thanks, Me too.. </Partha>

> <Partha> In case Metadata is separate session from RS, RS 
> attribute like RS-id MUST be included within XML. This was 
> discussed at 
> http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h
tml. Could you please explain reason for the dedicated SIP > session for
metadata.
> </Partha>
> 
> [LeonP] The main use case is Recording on Demand, that is 
> triggered by SRS. In such case it will be very useful to have 
> just one SIP session and send all metadata over it (like CTI 
> link) and then only trigger recording (via external SRC 
> interface) only for specific call segments.
> 
<Partha> I understand the current implementation wherein few of the
metadata like CDR records is passed through non-sip interface. It is
outside the scope of SIPREC. The global-id in format shall be used to
correlate. Please let me know in case any current SIPREC metadata
attribute MUST be passed through this CTS link. </Partha>

> As for examples, the basic information as media type, labels, 
> volume etc. Any application level data can be relevant. Even 
> indication of encryption (for a case where RS is not encrypted)
> 
> Leon
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Are there any examples of what people think they might want 
> to capture in the SDP and/or metadata field?
> 
> Cheers,
> Charles
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jul 2011 16:44:07 +0200

(as chair)
We should try to avoid opening up old issues. I think we had agreed that:
- RS SDP describes the RS, and therefore just describes how recordable media is delivered to the SRS. It does not describe how media is delivered between CS endpoints as part of the CS.
- Therefore anything to do with the CS (i.e., the session being recorded) needs to be delivered to the SRS as metadata (i.e., in XML).
- We don't see a need to standardize delivery of things like CS codecs in the metadata, but that could be done using the extension mechanism.

Focusing now on the content attribute, I don't think there is any disagreement that the SRS needs to know the content type (e.g., presentation) of a media stream. The SRC can obtain this from the a=content attribute of the CS SDP. The discussion is about whether this content attribute should be conveyed to the SRS:
A) as an a=content attribute of the RS SDP, or
B) within the metadata XML.

(as individual)
According to past decisions, there is perhaps an argument for B). If, for example, we wanted to convey the fact that a CS media stream was subject to 256-bit encryption, this information would go in the XML (it can't go in the RS SDP, because the RS might not use 256-bit encryption. Similarly, one could argue that the content type of a CS media stream should go in the XML, not in the RS SDP.

I could even imagine cases where the content type of a CS media stream does not equal the content type of an RS media stream, e.g., where the SRC combines the current speaker video and the room video into two videos side-by-side in the same RS media stream. In the metadata these would be two media streams, each with its own content type, but both would refer to the same RS media stream.

John

> Sent: 04 July 2011 08:08

---

From: Leon Portman <[email-masked]>
Date: Tue, 5 Jul 2011 18:42:26 +0300

I completely agree with the below.

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, July 05, 2011 5:44 PM
To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); [email-masked]
Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML

(as chair)

(as individual)

John

> > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, John; 
> > [email-masked]
> > I do prefer that metadata XML will be as self-contained as possible 
> > and not rely on conveying some data via RS SDP. RS SDP should only 
> > be used to recording establishment and negotiation and not as a 
> > mechanism for metadata reporting.
> > 
> > <Partha> In case Metadata XML has to be self-contained, the complete 
> > SDP has to be converted into XML format or else XML has to have 
> > <content> sort of XML attribute which carries SDP. Creating mapping 
> > for each SDP attribute with metadata XML element does not  seems to 
> > be feasible </Partha>
> > 
> > [LeonP] But if CS SDP is different from RS SDP, anyway you will need 
> > to encapsulate the original RS SDP, so why not in XML?
> 
> > metadata via web services <Partha> As per IETF-80 and last interim 
> > meeting, there is no intent of reusing this metadata XML in other 
> > protocol. In case reusing same format for webservice or XMPP is the 
> > intent, the current metadata XML mechanism is not the appropriate. 
> > This was discussed in 
> > [LeonP] I was not proposing replacing SIP with another transport 
> > layer, just wanted to keep other options open.
> 
> from the scratch. In our analysis, we notice that REST architecture 
> with Metadata XML is best fit for HTTP, XMPP </Partha>
> 
>  I am
> > <Partha> In case Metadata is separate session from RS, RS attribute 
> > like RS-id MUST be included within XML. This was discussed at 
> tml. Could you please explain reason for the dedicated SIP > session 
> for metadata.
> > </Partha>
> > 
> > [LeonP] The main use case is Recording on Demand, that is triggered 
> > by SRS. In such case it will be very useful to have just one SIP 
> > session and send all metadata over it (like CTI
> > Are there any examples of what people think they might want to 
> > capture in the SDP and/or metadata field?
> > 
> > Cheers,
> > Charles
> >

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 5 Jul 2011 10:14:13 -0700

Okay by me.

Cheers,
Charles

> Sent: Tuesday, July 05, 2011 8:42 AM
> To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu);
[email-masked]
> - RS SDP describes the RS, and therefore just describes how recordable
media is delivered to the SRS.
> It does not describe how media is delivered between CS endpoints as
part of the CS.
> - Therefore anything to do with the CS (i.e., the session being
recorded) needs to be delivered to the
> SRS as metadata (i.e., in XML).
> - We don't see a need to standardize delivery of things like CS codecs
in the metadata, but that could
> be done using the extension mechanism.
> 
> Focusing now on the content attribute, I don't think there is any
disagreement that the SRS needs to
> know the content type (e.g., presentation) of a media stream. The SRC
can obtain this from the
> a=content attribute of the CS SDP. The discussion is about whether
this content attribute should be
> conveyed to the SRS:
> According to past decisions, there is perhaps an argument for B). If,
for example, we wanted to convey
> the fact that a CS media stream was subject to 256-bit encryption,
this information would go in the
> XML (it can't go in the RS SDP, because the RS might not use 256-bit
encryption. Similarly, one could
> argue that the content type of a CS media stream should go in the XML,
not in the RS SDP.
> 
> I could even imagine cases where the content type of a CS media stream
does not equal the content type
> of an RS media stream, e.g., where the SRC combines the current
speaker video and the room video into
> two videos side-by-side in the same RS media stream. In the metadata
these would be two media streams,
> each with its own content type, but both would refer to the same RS
media stream.
> > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell,
John;
> > > I do prefer that metadata XML will be as self-contained as
possible
> > > <Partha> In case Metadata XML has to be self-contained, the
complete
> > > <Partha> In case Metadata is separate session from RS, RS
attribute
> > > [LeonP] The main use case is Recording on Demand, that is
triggered
> > > As for examples, the basic information as media type, labels,
volume
> > > I think it is sufficient, especially since we can assign new
values
> > > if necessary.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 5 Jul 2011 23:35:55 +0530

John,

Please read inline.

Thanks
Partha

> From: Charles Eckel (eckelcu) 
> Sent: Tuesday, July 05, 2011 10:44 PM
> To: Leon Portman; Elwell, John; Parthasarathi R (partr); 
> [email-masked]
> > - RS SDP describes the RS, and therefore just describes how 
> recordable media is delivered to the SRS.
> > It does not describe how media is delivered between CS 
> endpoints as part of the CS.
> > recorded) needs to be delivered to the SRS as metadata 
> (i.e., in XML).
> > in the metadata, but that could be done using the extension 
> mechanism.
> > 
<partha> Hope everyone agree here that CS SDP information could be
passed as extension-data. <content> attribute within <extension-data>
may help to achieve this requirement. </partha>

> > disagreement that the SRS needs to know the content type (e.g., 
> > presentation) of a media stream. The SRC can obtain this from the 
> > a=content attribute of the CS SDP. The discussion is about 
> whether this content attribute should be conveyed to the SRS:
> > for example, we wanted to convey the fact that a CS media 
> stream was 
> > subject to 256-bit encryption, this information would go in the XML 

<partha> Here I have the doubt. In case 256-bit encryption is not used
by RS SDP, Please let me know the reason for passing the key information
to SRS because RS SDP is not encrypted in that fashion. </partha>

> > (it can't go in the RS SDP, because the RS might not use 
> 256-bit encryption. Similarly, one could argue that the 
> content type of a CS media stream should go in the XML, not 
> in the RS SDP.
<partha> I'm seeing content-type attribute as one of the extension of
SDP a= attribute. In general, it is possible to convert CS mediastream
content type to RS media stream content type because SRC RS media stream
is formed based on CS media stream except for the mixing scenarios
</partha>

> > does not equal the content type of an RS media stream, 
> e.g., where the 
> > SRC combines the current speaker video and the room video into two 
> > videos side-by-side in the same RS media stream. 

<partha> RS media stream is a mixed content type stream of "current
speaker video" and "room video" and the resultant shall be named as
"mixed current speaker video & room video" which shall be passed as new
content type extension to SRS </partha>

In the 
> metadata these would be two media streams, each with its own 
> content type, but both would refer to the same RS media stream.
> > 
<partha> It will be problematic approach because the actual media and
metadata are not related explicitly. As per the current description,
there are two <stream> element with different unique-id uses same label
in SDP with different XML element ("content-type") within them. The
issue is whether media has stream1 behavior or stream2 behavior or
mixed. We will able to extent XML element for having single
interpretation but it is not fully clarified in the draft now. The
bottom-up matching like stream1 & stream2 has same label element and it
has to be grouped together is not explicit in this scenario. We need
more investigation both information is required but not the actual
media. Please correct me in I'm missing something </partha>

> > > > possible and not rely on conveying some data via RS SDP. RS SDP 
> > > > should only be used to recording establishment and 
> negotiation and 
> > > > not as a mechanism for metadata reporting.
> > > >
> > > > complete SDP has to be converted into XML format or 
> else XML has 
> > > > to have <content> sort of XML attribute which carries SDP. 
> > > > Creating mapping for each SDP attribute with metadata 
> XML element 
> > > > [LeonP] But if CS SDP is different from RS SDP, anyway you will 
> > > > need to encapsulate the original RS SDP, so why not in XML?
> > >
> > > <Partha> I guess that the confusion is here. In the 
> current format, 
> > > RS SDP is only carried towards SRS and CS SDP is not forwarded.
> > > This design
> reporting 
> > > > protocol. In case reusing same format for webservice or XMPP is 
> > > > the intent, the current metadata XML mechanism is not 
> the appropriate.
> > > > This was discussed in
> > > > 
> > > > point in format slide). In case you have difference of opinion 
> > > > even after this multiple discussion, let us again 
> discuss at IETF-81.
> > > > </Partha>
> > > >
> transport 
> > > case we need to keep the options open, the format has to be 
> > > revisited from the scratch. In our analysis, we notice that REST 
> > > architecture with Metadata XML is best fit for HTTP, XMPP 
> </Partha>
> > >
> > >  I am
> > > > triggered by SRS. In such case it will be very useful 
> to have just 
> > > > one SIP session and send all metadata over it (like CTI
> > > outside the scope of SIPREC. The global-id in format 
> shall be used 
> > > to correlate. Please let me know in case any current 
> SIPREC metadata 
> > > > values if necessary.
> [mailto:[email-masked]] 
> > > > > On
> > > > Behalf Of Elwell, John
> > > > > > rather than introducing the new <content-type> element for 
> > > > > > this purpose.
> > > > > >
> > > > > > Thanks
> > > > > > Partha
> > > > > >
> > > > > > From: Elwell, John 
> [mailto:[email-masked]]
> > > > > > Note that this would not involve duplication. The SDP 
> > > > > > a=content attribute is optional, so we need not use 
> it for the RS.
> > > > > >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Jul 2011 08:35:19 +0200

> Sent: 05 July 2011 19:06
> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John;
> [email-masked]
> > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel
> (eckelcu);
> > > [email-masked]
[JRE] Or even as the standardized part of an MS element if we wish.

> to SRS because RS SDP is not encrypted in that fashion. </partha>
[JRE] I did not suggest passing the CS keying material to the SRS. I just suggested passing the information that the CS media stream used 256 bit encryption. Perhaps this was a bad example - it was just meant to illustrate the general principle that information about the CS should be passed in metadata XML.

> content type extension to SRS </partha>
[JRE] Right, so you agree this can't be passed in the RS SDP. I would challenge the need to define (and register) a new RFC 4796 value "mixed current speaker video & room video". We have two MS elements (representing the two CS video streams for current speaker and room. Why can't we just place the respective RFC 4796 content types in the respective MS elements? And why does it need to be as extension data - why can't it be standardized from day one?

John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 6 Jul 2011 13:03:11 +0530

Just on this one

> "mixed current speaker video & room video" which shall be passed as 
> new content type extension to SRS </partha>
[JRE] Right, so you agree this can't be passed in the RS SDP. I would
challenge the need to define (and register) a new RFC 4796 value "mixed
current speaker video & room video". We have two MS elements
(representing the two CS video streams for current speaker and room. Why
can't we just place the respective RFC 4796 content types in the
respective MS elements? And why does it need to be as extension data -
why can't it be standardized from day one?

My thought here is since we have new content types "mixed current
speaker video & room video" we need to register/extend RFC 4796 for the
same and send in RS SDP. I would prefer this approach instead of sending
it through recording metadata XML. Of course we need to discuss this in
AVT to get their opinion.

Regards,
Ram

> Sent: Wednesday, July 06, 2011 12:05 PM
> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Leon Portman;
> [email-masked]
> [JRE] I did not suggest passing the CS keying material to the SRS. I
> just suggested passing the information that the CS media stream used
> 256 bit encryption. Perhaps this was a bad example - it was just meant
> to illustrate the general principle that information about the CS
> should be passed in metadata XML.
> 
> >
> [JRE] Right, so you agree this can't be passed in the RS SDP. I would
> challenge the need to define (and register) a new RFC 4796 value
"mixed
> current speaker video & room video". We have two MS elements
> (representing the two CS video streams for current speaker and room.
> Why can't we just place the respective RFC 4796 content types in the
> respective MS elements? And why does it need to be as extension data -
> why can't it be standardized from day one?
> 
> John (as individual)
> 
> >
> > In the
> > > (http://www.ietf.org/mail-
> archive/web/siprec/current/msg02106.html).
> > > http://www.ietf.org/mail-
> archive/web/siprec/current/msg02155.html(1s
> > > > > t
> > > (http://www.ietf.org/mail-
> archive/web/siprec/current/msg02106.html).
> > > > > > > > such restriction and so, I prefer to reuse as content
SDP
> > > > > > > > there is a valid question to be asked whether the
content
> > > > > > type of an
> > > > > > > > > Slide 7: On the question of how to describe the
content
> > > > > > of an MS,

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 6 Jul 2011 13:05:05 -0700

RFC 4796 has registered the following values:

   slides                       RFC 4796  Presentation slides
   speaker                      RFC 4796  Image from the speaker
   sl                           RFC 4796  Sign language
   main                         RFC 4796  Main media stream
   alt                          RFC 4796  Alternative media stream

Suppose we register the following new values:

   siprec1                      RFC xxxx  SIPREC value 1
   siprec2                      RFC xxxx  SIPREC value 2
   siprec3                      RFC xxxx  SIPREC value 3

If the CS has a media lines with the following content attributes

CS MS1 - slides
CS MS2 - main
CS MS3 - siprec1
CS MS4 - siprec2

SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS MS2
is some composition of CS MS2, CS MS3 and CS MS4.
This could be represented using the content attribute as:

RS MS1 - slides
RS MS2 - main, siprec1, siprec2

If this is all we think is required, using the content attribute does
seem sufficient. However, my understanding is people want to be able to
convey something other than the simple concatenation of content
attribute values, and for that reason, prefer to use XML. In this case,
the desired set of values is not bound by anything we will define in
SIPREC. That is my understanding as to why XML is preferred over the RFC
4796 content attribute.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Wednesday, July 06, 2011 12:33 AM
Leon Portman; [email-masked]
> [JRE] Right, so you agree this can't be passed in the RS SDP. I would
challenge the need to define
> (and register) a new RFC 4796 value "mixed current speaker video &
room video". We have two MS
> elements (representing the two CS video streams for current speaker
and room. Why can't we just place
> the respective RFC 4796 content types in the respective MS elements?
And why does it need to be as
> extension data - why can't it be standardized from day one?
> 
speaker video & room video" we need
> to register/extend RFC 4796 for the same and send in RS SDP. I would
prefer this approach instead of
> sending it through recording metadata XML. Of course we need to
discuss this in AVT to get their
> opinion.
"mixed
> > archive/web/siprec/current/msg02013.h
> > > > > > > [mailto:[email-masked]] On Behalf Of Charles
Eckel
> > > > > > (eckelcu)
> > > > > > > > > (using SDP label attribute as a pointer) until
otherwise
> > > > > > > there is a
SDP
content
content
> > > > > > > of an MS,
> > > > > > > > > > there was no objection to basing this on the types
in
> > > > > > > the RFC 4796

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Jul 2011 17:26:57 -0400

>     siprec3                      RFC xxxx  SIPREC value 3

I don't get it. What is the purpose of siprecN?

I can perhaps see using a new value to indicate: this stream contains 
some content from a stream that failed to indicate what sort of content 
it contained. But you only need one value for that.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 7 Jul 2011 10:35:28 +0530

Hi all,

Please read inline

Thanks
Partha 

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, July 07, 2011 2:57 AM
> To: [email-masked]
<partha> I guess that new values for the different mixed stream like
side-by-side video & active user video, speaker + Slides, etc...
</partha>

> 
> I can perhaps see using a new value to indicate: this stream 
> contains some content from a stream that failed to indicate 
> what sort of content it contained. But you only need one 
> value for that.
> 
> 	Thanks,
> 	Paul
> 
> > SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS 
> > MS2 is some composition of CS MS2, CS MS3 and CS MS4.
> > seem sufficient.

<Partha> I agree with Charles till here and my understanding is same
</partha>

 However, my understanding is people want 
> to be able 
> > to convey something other than the simple concatenation of content 
> > attribute values, and for that reason, prefer to use XML. 

<partha> I'm interested in knowing the intent apart from the above
mentioned because I could not visualize. </partha>

In this 
> > case, the desired set of values is not bound by anything we will 
> > define in SIPREC. That is my understanding as to why XML is 
> preferred 
> > over the RFC
> > 4796 content attribute.
> >
> > Cheers,
> > Charles

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 Jul 2011 10:46:40 +0530

Inline

> Sent: Thursday, July 07, 2011 1:35 AM
> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr);
> 'Leon Portman'; [email-masked]'
MS2
> SIPREC. That is my understanding as to why XML is preferred over the
> RFC 4796 content attribute.

Yes that's my thought too. Extending content attribute ( by registering
new values if required) may be sufficient for SIPREC and we may be able
to use content attribute in RS SDP to indicate the content-type. I would
like to hear on what other things we wish to convey using content for
which we need XML.

Regards,
Ram

> > > > > > Focusing now on the content attribute, I don't think there
is
> any
> > > > > > presentation) of a media stream. The SRC can obtain this
from
> the
> > > > <partha> Here I have the doubt. In case 256-bit encryption is
not
> > > used
> > > > <partha> It will be problematic approach because the actual
media
> and
> > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP
> or
> > > XML
> > > > > > >
> > > > > > > Leon,
> > > > > > >
> > > > > > > Please read inline.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Partha
> > > > > > >
> > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi
> R
> > > > > > > > (partr); [email-masked]
> archive/web/siprec/current/msg02151.html,
> > > > > > > >
> > > > > > >
> > > > > > > > > I would like other opinions on whether the SDP
> a=content
> > > > > > > > attribute in
> > > > > > > > > > In case if it is the argument of whether CS MS
> content
> > > > > > > > type or RS MS
> > > > > > > >
> > > > > > > > > > attribute (like direction, content) in media level
> for
> > > > > > > RS dialog
> > > > > > > > > > restriction in using in such manner. As per RFC
4796,
> > > > > > > there is no
> > > > > > > > > > > RFC 4796, the multiple instance of content
> attribute
> > > > > > > is possible
> > > > > > > > to
> > > > > > > > > > The content type we are talking about is an MS
> content
> > > > > > > > type, i.e.,

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jul 2011 09:06:04 +0200

Charles,

I see how it COULD be done in the way you describe. I just feel it is architecturally wrong to describe the CS MS as part of the RS MS description (i.e., the RS SDP).

However, I can also give a more specific reason. Suppose CS MS1 is slides and CS MS2 is speaker video. But the XML does not tell me that CS MS1 is slides and CS MS1 is speaker video. Both CS MS1 and CS MS2 are combined into RS MS1 (slides + speaker). The XML metadata tells me that at a given time Participant P1 contributed to CS MS1 and P2 contributed to CS MS2. How can I tell that P1 contributed to slides and P2 contributed to speaker?

See also below:

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 06 July 2011 21:05
> To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R
> (partr); Leon Portman; [email-masked]
[JRE] That was not my motivation, but perhaps others had that in mind.

John (as individual)

> > > > > > Focusing now on the content attribute, I don't
> think there is
> any
> > > > > > presentation) of a media stream. The SRC can obtain
> this from
> the
> > > > <partha> Here I have the doubt. In case 256-bit
> encryption is not
> > > used
> > > > <partha> I'm seeing content-type attribute as one of
> the extension
> of
> > > respective MS elements? And why does it need to be as
> extension data
> -
> > > > <partha> It will be problematic approach because the
> actual media
> and
> > > > > > > Subject: RE: [siprec] Content (RFC 4796)
> attribute in SDP or
> > > XML
> > > > > > >
> > > > > > > Leon,
> > > > > > >
> > > > > > > Please read inline.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Partha
> > > > > > >
> > > > > > > > To: Charles Eckel (eckelcu); Elwell, John;
> Parthasarathi R
> > > > > > > > (partr); [email-masked]
> > > > > > > > > I would like other opinions on whether the
> SDP a=content
> > > > > > > > attribute in
> > > > > > > > > > In case if it is the argument of whether CS
> MS content
> > > > > > > > type or RS MS
> > > > > > > >
> > > > > > > > > > attribute (like direction, content) in
> media level for
> > > > > > > RS dialog
> > > > > > > > > > restriction in using in such manner. As per
> RFC 4796,
> > > > > > > there is no
> > > > > > > > > > > RFC 4796, the multiple instance of
> content attribute
> > > > > > > is possible
> > > > > > > > to
> > > > > > > > > > The content type we are talking about is an
> MS content
> > > > > > > > type, i.e.,

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 7 Jul 2011 17:32:04 +0530

John,

I understand your mixed video scenario. In case of mixed audio or video,
it is not possible to retrieve the complete information in SRS as it is
pre-mixed at SRC. It is one of the motivation for having two m-line with
non-mixed stream to SRS. The similar issue is raised by Charles earlier
for mixed audio stream wherein current speaker (participant) has to be
noticed using metadata XML. Even in case of mixed audio stream, the loss
of some information is unavoidable. Hope you agree here. In case the
intent is to create the infrastructure wherein the mixed stream should
not loose the information, then we need the separate discussion.

I will write the separate mail thread for the architecture clarification
in SRC wherein CS is handling by one SIP UA instance and RS is handled
as separate SIP UA instance.  

SDP is reused for RS media description, in case it is not possible for
SDP to express about specific media description then it is better to
generically develop the extension like IANA registration for RFC 4796
which helps for other similar mixing applications as well. 

>From the metadata perspective,  Stream in XML is pointing to m-line of
SDP using label attributes. SDP points to raw media. XML is used to
create association which is not possible in SDP. Participant, session to
Stream grouping is not possible to achieve in SDP which forces us to
look for XML representation.  But in case of content-type scenario, it
is possible to make it happen. 

Please read inline

Thanks
Partha    

> Sent: Thursday, July 07, 2011 12:36 PM
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); 
> Parthasarathi R (partr); Leon Portman; [email-masked]
> I see how it COULD be done in the way you describe. I just 
> feel it is architecturally wrong to describe the CS MS as 
> part of the RS MS description (i.e., the RS SDP).

<partha> In case the intent is to pass CS MS description, I agree with
you. IIRC, charles proposed to use the explicit mixed content-type which
is more appropriate to be passed in RS SDP to provide the description
about that specific media.  </partha>

> 
> However, I can also give a more specific reason. Suppose CS 
> MS1 is slides and CS MS2 is speaker video. But the XML does 
> not tell me that CS MS1 is slides and CS MS1 is speaker 
> video. Both CS MS1 and CS MS2 are combined into RS MS1 
> (slides + speaker). 

<partha> The question here is how it is possible for any UA to represent
(slides+speaker) in SDP? In case it is not well defined, let us work for
it </partha>

The XML metadata tells me that at a given 
> time Participant P1 contributed to CS MS1 and P2 contributed 
> to CS MS2. How can I tell that P1 contributed to slides and 
> P2 contributed to speaker?

<partha> In the mixed stream, we lose the data in SRC because actual
media is mixed. The system shall be designed to send the media stream
separately or we have to find the generic way to group the stream
together </partha> 

> > seem sufficient. However, my understanding is people want 
> to be able 
> > attribute values, and for that reason, prefer to use XML. In this 
> [mailto:[email-masked]] On 
> > > > Behalf Of Elwell, John
> > > > > by RS SDP, Please let me know the reason for passing the key 
> > > > > information to SRS because RS SDP is not encrypted in that 
> > > > > fashion.
> > </partha>
> > > > > > content type of a CS media stream should go in the 
> XML, not in 
> > > > > > the RS SDP.
> > > > > content type to RS media stream content type because SRC RS 
> > > > > media stream is formed based on CS media stream except for the
> > mixing scenarios
> > > > > </partha>
> > > > >
> > > > > > >
> > > > > speaker video" and "room video" and the resultant 
> shall be named
> > as
> > > > > "mixed current speaker video & room video" which 
> shall be passed 
> > > > > as new content type extension to SRS </partha>
> > > > > there are two <stream> element with different unique-id uses 
> > > > > same label in SDP with different XML element ("content-type") 
> > > > > within them.
> > The
> > > > > bottom-up matching like stream1 & stream2 has same 
> label element 
> > > > > and it has to be grouped together is not explicit in this 
> > > > > scenario. We
> > need
> > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); 
> Elwell, John; 
> > > > > > > > [email-masked]
> > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); 
> Elwell, John; 
> > > > > > > > > [email-masked]
> > > > > > > > > <Partha> In case Metadata XML has to be 
> self-contained,
> > the
> > > > > > > > > volume etc. Any application level data can be 
> relevant.
> > Even
> > > > > > > > > I think it is sufficient, especially since we 
> can assign
> > new
> > > > > > > > > values if necessary.
> > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) 
> attribute in
> > > > > > SDP or XML
> > > > > > > > > >
> > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute 
> in SDP or
> > XML
> > > > > > > > > > >
> > > > > > > > > > > John,
> > > > > > > > > > >
> > > > > > > > > > > content type in the metadata, it is 
> better for us to
> > > > > > > > > re-open ticket
> > > > > > > > > > > #71
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute 
> in SDP or
> > XML
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > As per the last interim SIPREC meeting, 
> there is a
> > > > > > > > consensus to
> > > > > > > > > > > > interested in knowing any specfic 
> reason for this
> > > > > > > > > attribute to be
> > > > > > > > > > > Perhaps my distinction is too 
> theoretical, but I do
> > > > > > > > feel a little
> > > > > > > > > more
> > > > > > > > > > > > needed). Paul had a slight concern that 
> you might
> > > > > > be mixing
> > > > > > > > > > > multiple
> > > > > > > > > > > > cases not describable in this way, but 
> in the end
> > > > > > > > accepted the

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jul 2011 15:34:34 +0200

> Sent: 07 July 2011 13:02
> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R
> (rmohanr); Leon Portman; [email-masked]
[JRE] Yes, I am in agreement with using the IANA registry for RFC 4796, and extending it where necessary. My only question was whether these values are most appropriately sent in SDP or in XML.

> SDP using label attributes.
[JRE] Yes, I had forgotten that. I recall an earlier misunderstanding to do with this. I don't think that is clear in the metadata draft, so I will comment separately on that. However, if this is the common understanding, I can see that using the a=content attribute in the RS SDP would be a viable solution.

John (as individual)

> SDP points to raw media. XML is used to
> > > > > > > > - Therefore anything to do with the CS (i.e.,
> the session
> > > being
> > > > > > > > According to past decisions, there is perhaps
> an argument
> > > > > > > for B). If,
> > > > > 256 bit encryption. Perhaps this was a bad example -
> it was just
> > > meant
> > > > > > > > I could even imagine cases where the content
> type of a CS
> > > > > > > media stream
> > > > > > > > SRC combines the current speaker video and the
> room video
> > > > > > into two
> > > > > [JRE] Right, so you agree this can't be passed in the
> RS SDP. I
> > > would
> > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel
> (eckelcu);
> > > Elwell,
> > > > > > > > > > John; [email-masked]
> > > > > > > > > > need to encapsulate the original RS SDP, so
> why not in
> > > XML?
> > > > > > > > >
> > > > > > > > > Please bring up with the usecase for CS SDP
> if required
> > > > > > </Partha>
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > metadata via web services <Partha> As per
> IETF-80 and
> > > > > > > last interim
> > > > > > > > > <Partha> I understand the current
> implementation wherein
> > > > > > > few of the
> > > > > > > > > > As for examples, the basic information as
> media type,
> > > labels,
> > > > > > > > > > > > The basic idea in metadata format is to
> re-use as
> > > > > > > much as SDP
> > > > > > > > > > > > > exist in SDP which shall be used in
> RS SDP. SRS
> > > > > > > shall group
> > > > > > > > > > > > the same
> > > > > > > > > > > > > media content types by "content"
> attribute in RS
> > > > > > > SDP. We are
> > > > > > > > > > > > > registry (new values could be
> specified via the
> > > > > > > appropriate
> > > > > > > > > > > > means if
> > > > > > > > > > > > > CS MSs into a single RS media stream
> and whether
> > > > > > > this might
> > > > > > > > > > > > result in
> > > > > > > > > > > > > consensus. It needs to be discussed
> on the list
> > > > > > > > > whether this is

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 7 Jul 2011 19:15:12 +0530

John,

Thanks for your agreement for Content (RFC 4796) attribute in SDP.

Thanks
Partha

> Sent: Thursday, July 07, 2011 7:05 PM
> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram 
> Mohan R (rmohanr); Leon Portman; [email-masked]
> > I understand your mixed video scenario. In case of mixed audio or 
> > video, it is not possible to retrieve the complete 
> information in SRS 
> > as it is pre-mixed at SRC. It is one of the motivation for 
> having two 
> > m-line with non-mixed stream to SRS. The similar issue is raised by 
> > Charles earlier for mixed audio stream wherein current speaker 
> > (participant) has to be noticed using metadata XML. Even in case of 
> > mixed audio stream, the loss of some information is 
> unavoidable. Hope 
> > you agree here. In case the intent is to create the infrastructure 
> > wherein the mixed stream should not loose the information, then we 
> > need the separate discussion.
> >
> > I will write the separate mail thread for the architecture 
> > clarification in SRC wherein CS is handling by one SIP UA 
> instance and 
> > RS is handled as separate SIP UA instance.
> >
> [JRE] Yes, I am in agreement with using the IANA registry for 
> RFC 4796, and extending it where necessary. My only question 
> was whether these values are most appropriately sent in SDP or in XML.
> 
> >
> [JRE] Yes, I had forgotten that. I recall an earlier 
> misunderstanding to do with this. I don't think that is clear 
> in the metadata draft, so I will comment separately on that. 
> However, if this is the common understanding, I can see that 
> using the a=content attribute in the RS SDP would be a viable 
> solution.
> 
> John (as individual)
> 
> 
> 
> > SDP points to raw media. XML is used to create association which is 
> > not possible in SDP. Participant, session to Stream grouping is not 
> > possible to achieve in SDP which forces us to look for XML 
> > representation.  But in case of content-type scenario, it 
> is possible 
> > to make it happen.
> >
> > Please read inline
> >
> > Thanks
> > Partha
> >
> > > I see how it COULD be done in the way you describe. I 
> just feel it 
> > > is architecturally wrong to describe the CS MS as part of 
> the RS MS 
> > > description (i.e., the RS SDP).
> >
> > you. IIRC, charles proposed to use the explicit mixed content-type 
> > which is more appropriate to be passed in RS SDP to provide the 
> > description about that specific media.  </partha>
> >
> > >
> > > MS1 is slides and CS MS2 is speaker video. But the XML 
> does not tell 
> > > me that CS MS1 is slides and CS MS1 is speaker video. Both CS MS1 
> > > and CS MS2 are combined into RS MS1 (slides + speaker).
> >
> > (slides+speaker) in SDP? In case it is not well defined, 
> let us work 
> > for it </partha>
> >
> > > time Participant P1 contributed to CS MS1 and P2 
> contributed to CS 
> > > MS2. How can I tell that P1 contributed to slides and
> > > > > > > > > To: Elwell, John; Parthasarathi R (partr); 
> Charles Eckel
> > > > > > > (eckelcu);
> > > > > > > > > [email-masked]
> > > > > > > > > We should try to avoid opening up old issues. 
> I think we
> > > > > > > > had agreed that:
> > > > > > > > > - We don't see a need to standardize delivery 
> of things
> > > > > > > > like CS codecs
> > > > > > > > > disagreement that the SRS needs to know the 
> content type
> > > > (e.g.,
> > > > > > > > > subject to 256-bit encryption, this 
> information would go
> > > > > > > in the XML
> > > > > > >
> > > > > > > > > > > possible and not rely on conveying some 
> data via RS
> > > > > > > SDP. RS SDP
> > > > > > > > > > > meeting, there is no intent of reusing 
> this metadata
> > > > > > > > XML in other
> > > > > > > > > > > protocol. In case reusing same format for 
> webservice
> > > > > > > or XMPP is
> > > > > > > > > > > point in format slide). In case you have 
> difference
> > > > > > > of opinion
> > > > > > > > > > <Partha> Current metadata format is 
> customized for SIP
> > > > > > > > transport. In
> > > > > > > > > > revisited from the scratch. In our 
> analysis, we notice
> > > > > > > that REST
> > > > > > > > > > tml. Could you please explain reason for 
> the dedicated
> > > > > > > > SIP > session
> > > > > > > > > > for metadata.
> > > > > > > > > > > </Partha>
> > > > > > > > > > >
> > > > > > > > > > > indication of encryption (for a case 
> where RS is not
> > > > > > > encrypted)
> > > > > > > > > > >
> > > > > > > > > > > Leon
> > > > > > > > > > >
> > > > > > > > > > > > semantics for representing the content 
> type of the
> > > > > > > > > > recorded CS media
> > > > > > > > > > > stream.
> > > > > > > > > > > >
> > > > > > > > > > > > John
> > > > > > > > > > > >
> > > > > > > > > > > > > [JRE] I don't have a reason for 
> **duplication**.
> > > > > > > > > > However, I think
> > > > > > > > > > > > > - RS media stream content type is 
> "recording of
> > > > slides".
> > > > > > > > > > > > >
> > > > > > > > > > > > siprec mailing list [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jul 2011 15:53:12 +0200

Well, my agreement was really conditional on fixing the definition of MS - see other thread.

John

> Sent: 07 July 2011 14:45
> > > > > > > > SDP a= attribute. In general, it is possible to
> convert CS
> > > > > > > mediastream
> > > > > > > > <partha> RS media stream is a mixed content
> type stream of
> > > > > "current
> > > > > > > > > > > RS SDP is only carried towards SRS and CS
> SDP is not
> > > > > forwarded.
> > > > > > > > > > > This design
> > > > > > > > > > > metadata like CDR records is passed
> through non-sip
> > > > > > > > > interface. It is
> > > > > > > > > > > > > > rather than introducing the new
> <content-type>
> > > > > > > > element for
> > > > > > > > > > > > > > this purpose.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > Partha
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On this basis, I think the correct
> option for
> > > > > > > > > conveying the MS
> > > > > > > > > > > > content

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 7 Jul 2011 19:27:20 +0530

John,

I completely agree with you and we will fix MS issue reported in the
another mail thread.

Apart from this, I'm interested in knowing whether you wish to track the
IANA extension of RFC 4796 related to mixed content attribute as part of
metadata draft or as a separate generic item. In case you wish to
discuss as part of metadata draft, we need to discuss further for having
the common understanding.

Thanks
Partha 

> Sent: Thursday, July 07, 2011 7:23 PM
> > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R 
> > > [JRE] Yes, I am in agreement with using the IANA registry for RFC 
> > > 4796, and extending it where necessary. My only question 
> was whether 
> > > these values are most appropriately sent in SDP
> > or in XML.
> > >
> > > >
> > > misunderstanding to do with this. I don't think that is 
> clear in the 
> > > metadata draft, so I will comment separately on that.
> > > However, if this is the common understanding, I can see 
> that using 
> > > the a=content attribute in the RS SDP would be a viable solution.
> > >
> > > John (as individual)
> > >
> > >
> > >
> > > > > > > > "mixed current speaker video & room video" 
> which shall be
> > > > > > passed as
> > > > > > > > [JRE] I did not suggest passing the CS keying 
> material to
> > > > > > the SRS. I
> > > > > > > > > metadata are not related explicitly. As per 
> the current
> > > > > > description,
> > > > > > > > > more investigation both information is 
> required but not
> > > > > > the actual
> > > > > > > > > > > > > [LeonP] But if CS SDP is different 
> from RS SDP,
> > > > > > > > > anyway you will
> > > > > > > > > > > > case we need to keep the options open, 
> the format
> > > > > > has to be
> > > > > > > > > > > > > Are there any examples of what people 
> think they
> > > > > > > > > might want to
> > > > > > > > > > > > > > > relating to the CS. One could 
> argue that the
> > > > > > > > > > > > > corresponding RS stream
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > conveyed in XML or in the RS 
> SDP a=content
> > > > > > attribute.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jul 2011 18:22:40 +0200

Partha,

It is not clear to me that we need to extend the RFC 4796 registry at this point. For example, it has been argued that we could handle a mixed speaker + slides RS stream just by including both values in the a=content attribute. If and when we find other types that we want adding to the RFC 4796 registry, I think that should be covered in separate draft(s).

John

> Sent: 07 July 2011 14:57
> > > > > <partha> The question here is how it is possible for
> any UA to
> > > > > represent
> type stream
> > > > > > > of "current
> > > > > > > > > speaker video" and "room video" and the
> resultant shall
> > > > > > > be named as
> > > > > > > > > > > > in the metadata, but that could be done
> using the
> > > > > > extension
> > > > > > > > > > > mechanism.
> > > > > > > > > > > >
> > > > > > > > > [JRE] Or even as the standardized part of an
> MS element
> > > > > > > if we wish.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > just suggested passing the information that
> the CS media
> > > > > > > stream used
> > > > > > > > > Why can't we just place the respective RFC
> 4796 content
> > > > > > > types in the
> > > > > > > > > > issue is whether media has stream1 behavior
> or stream2
> > > > > > > behavior or
> > > > > > > > > > > > > > to have <content> sort of XML
> attribute which
> > > > > > > carries SDP.
> > > > > > > > > > > > > > <Partha> In case Metadata is
> separate session
> > > > > > > from RS, RS
> > > > > > > > > > > > > > one SIP session and send all
> metadata over it
> > > > > > (like CTI
> > > > > > > > > > > > > attribute MUST be passed through this
> CTS link.
> > > > > > </Partha>
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > > such restriction and so, I
> prefer to reuse
> > > > > > > as content
> > > > > > > SDP
> > > > > > > > > > > > > > attribute
> > > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr);
> Paul Kyzivat
> > > > > > (pkyzivat)
> > > > > > > > > > > > > > > > > Subject: Content (RFC 4796)
> attribute in
> > > > > > > SDP or XML
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As per the last interim
> SIPREC meeting,
> > > > > > there is a
> > > > > > > > > > > > > consensus to
> > > > > > > > > > > > > > > > > describe the content of an MS
> using RFC
> > > > > > 4796 & its
> > > > > > > > > > > > > > > > extension. As per

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 7 Jul 2011 10:07:44 -0700

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
> Sent: Wednesday, July 06, 2011 2:27 PM
> To: [email-masked]

I don't have any purpose to assign or propose at this time. My
understanding from previous thread is that others felt the existing set
of values defined for the content attribute might not be sufficient. I
was merely illustrating that we could define new values, if necessary.

Cheers,
Charles

MS2
> > attribute values, and for that reason, prefer to use XML. In this
case,
> > SIPREC. That is my understanding as to why XML is preferred over the
RFC

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 7 Jul 2011 10:19:31 -0700

> Sent: Thursday, July 07, 2011 12:06 AM
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Parthasarathi R
(partr); Leon Portman;
> I see how it COULD be done in the way you describe. I just feel it is
architecturally wrong to
> describe the CS MS as part of the RS MS description (i.e., the RS
SDP).
> 
> However, I can also give a more specific reason. Suppose CS MS1 is
slides and CS MS2 is speaker video.
> But the XML does not tell me that CS MS1 is slides and CS MS1 is
speaker video. Both CS MS1 and CS MS2
> are combined into RS MS1 (slides + speaker). The XML metadata tells me
that at a given time
> Participant P1 contributed to CS MS1 and P2 contributed to CS MS2. How
can I tell that P1 contributed
> to slides and P2 contributed to speaker?

I agree, the RFC 4976 content attribute is not well suited for this. My
point is, I think we need to clearly define what we mean when we say we
want a content attribute in XML. If the XML content attribute is meant
to convey. Within the SDP we have the content attribute. Within RTP/RTCP
we have SSRC and CSRC. These can be used to describe the content and the
contributors. If we want to be able to attribute specific content, or
pieces or content within a composed/mixed stream to individual
participants, I agree that something more is needed. We could define new
SDP and/or RTP/RTCP functionality, or simply add more XML to the
metadata. I prefer the latter in this case.
In summary, I am not arguing that the RFC 4796 content attribute
mechanism is sufficient or well suited to convey a rich description of
an arbitrary media stream. I am saying merely stating the level of
information for which it is well suited, and proposing that if that
level of information is all we need to convey, we use the SDP content
attribute rather than duplicating the same information in XML.

Cheers,
Charles
  
or
or
> > > > > information
> > > > > speaker video" and "room video" and the resultant shall be
named
> > > > > same label
> > > > > in SDP with different XML element ("content-type") within
them.
> > > > > has to be grouped together is not explicit in this scenario.
We
> > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell,
John;
self-contained,
relevant.
> > > > > > > > > I think it is sufficient, especially since we can
assign
> > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute
in
> > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP
or
> > > > > > > > > > > content type in the metadata, it is better for us
to
> > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP
or
> > > > > > > > > > > > As per the last interim SIPREC meeting, there is
a
> > > > > > > > > > > > interested in knowing any specfic reason for
this
> > > > > > > > > > > Perhaps my distinction is too theoretical, but I
do
> > > > > > > > > > > > needed). Paul had a slight concern that you
might
> > > > > > > > > > > > cases not describable in this way, but in the
end

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Jul 2011 22:05:01 -0400

> was merely illustrating that we could define new values, if necessary.

My thinking was that if we needed any new values (though I'm not sure we 
do) the purpose would be to communicate something special about the RS 
media streams, and so would never be seen in the CS media streams.

	Thanks,
	Paul