Subject: [siprec] Review Request for draft-ram-siprec-metadata-format-01

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 8 Mar 2011 19:53:51 +0530

Hi all,

As per the mailing list comments and interim meeting discussion, I
updated -01 draft of draft-ram-siprec-metadata-format and send it for
review. The draft is available at
http://www.ietf.org/id/draft-ram-siprec-metadata-format-01.txt. The
following update are done as part of -01 draft:

1) URN UUID (RFC 4122) mechanism is used as the unique id mechanism for
relevant XML elements like group, session, stream, participant. 

2) Partial XML passing in RS is supported by having unique URN UUID for
group, session, stream, participant, recording, extension data which are
directly under recording-metadata container/namespace. 

3) Include recording-metadata element as a container element instead of
recording element. This helps in avoiding duplicate data of recording
elements during the partial update

4) Updated elements in XML document as per draft-ram-siprec-metadata-04
elements & associations

5) Changed appdata element name as extensiondata

6) Removed container element like sessions, participants, streams from
XML document as  parent reference exists in each element

7) Added Partial Update example & SIP usage XML+SDP example

8) Portion of security considerations section is added.

Could you please review and provide your expert comments on the draft.

Thanks
Partha 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Tuesday, March 08, 2011 7:31 PM
To: Parthasarathi R (partr)
Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Subject: New Version Notification for
draft-ram-siprec-metadata-format-01 

A new version of I-D, draft-ram-siprec-metadata-format-01.txt has been
successfully submitted by Parthasarathi R and posted to the IETF
repository.

Filename:	 draft-ram-siprec-metadata-format
Revision:	 01
Title:		 Session Initiation Protocol (SIP) Recording Metadata
Format
Creation_date:	 2011-03-08
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
Session recording is a critical requirement in many communications
environments such as call centers and financial trading.  In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons.  Recording of a session is
typically performed by sending a copy of a media stream to a recording
device.  The requirements for which are described in
[I-D.ietf-siprec-req], the architecture for which is described in
[I-D.ietf-siprec-architecture], and the metadata model viewed by Session
Recording Server is described in [I-D.ram-siprec-metadata].
This document focuses on the Recording metadata format which describes
the communication session.

The IETF Secretariat.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Mar 2011 15:49:14 +0100

Partha,

I read -01 and have the following comments:

1. In section 3:
"The media related details of metadata SHALL be passed across using
   session description protocol (SDP) [RFC4566].  SDP attributes
   describes about different media formats like audio, video."
I wonder whether it is really appropriate to describe SDP attributes as part of the metadata. If I look at the metadata model, I don't see any attributes of a Media Stream object that could be satisfied using RS SDP. For example, the "codec parameters" attribute relates to the CS, not the RS - the two sessions could use different codecs or different codec parameters. I think it would be far simpler to regard all metadata as being sent in XML. Note that the SDP label attribute can still be used as the linkage between a Media Stream object in the metadata and the corresponding RS media stream that captures the CS media stream concerned.

2. We perhaps need to think about mixed RS media streams, i.e., where several CS media streams have been mixed to produce a single RS media stream. In this case, the several Media Stream objects would all point to the same SDP label, I guess. This then brings into question the mode element (type streamMode) - why is this needed? The fact that several Media Stream objects (stream elements) point to the same label would imply there has been mixing, so the mode element seems to be redundant.

3. Section 4.2.4:
"Each group MAY have initiator entity attribute which contains SIP/
   SIPS URI to identify the device which acts as Session Recording
   Client (SRC).  The entity attribute SIP/SIPS URI FQDN or IP address
   represents the device and may not have user part."
It is unclear to me why a URI identifying the SRC should be an attribute of a group element. I cannot find a corresponding attribute in the CS Group object in the metadata model draft.

4. The example (section 5.1) seems rather odd, in that the recording-metadata element appears to comprise a sequence of elements (recording, group, session, etc.) alternating with extensiondata elements, i.e., there is an extensiondata element after each of the other elements. This probably complies with the schema, but what is the meaning of several extensiondata elements all within the same recording-metadata element? Why not just a single extensiondata element? Is any significance to be drawn from the fact that there is an extensiondata element following the recording element, another following the group element, etc.?

5. On the other hand, elements group, session, etc. seem to lack extensiondata elements - would it not be sensible to allow each of these to be extensible?

6. The method of sending partial metadata seems to imply that when a session, participant, stream etc. comes to an end, we send partial metadata indicating that the element concerned now has an end time. This seems implicitly to mean that the element ceases to exist - correct? So if the SRS were to request a snapshot of complete metadata, it would not receive any elements for which a stop time has previously been sent - correct? I don't think I have an issue with this - I just wanted to confirm my understanding.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 08 March 2011 14:24
> To: [email-masked]
> Subject: [siprec] Review Request for 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Mar 2011 13:23:20 -0500

> I wonder whether it is really appropriate to describe SDP attributes as part of the metadata. If I look at the metadata model, I don't see any attributes of a Media Stream object that could be sati…

I think I agree with you here.
The label reference in the xml, and the label in the sdp provide a 
linkage between the *meta*data and the *data*. Originally I was thinking 
that there would be some things in the sdp that were metadata, but so 
far that seems not to be true.

> 2. We perhaps need to think about mixed RS media streams, i.e., where several CS media streams have been mixed to produce a single RS media stream. In this case, the several Media Stream objects wo…

My thinking is that situation is modeled as a single media stream with 
multiple participants.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 12 Mar 2011 23:20:09 +0530

John/Paul,
 
Please read inline.
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
Sent: Fri 3/11/2011 11:53 PM
To: [email-masked]
Subject: Re: [siprec] Review Request for draft-ram-siprec-metadata-format-01

<Partha> I agree with the linkage part and CS codec parameters information in the model.  IMO, some of the information shall be retrieved from RS SDP 

1) Media Type (Audio/Video)

2) In a unmixed stream, grouping of direction attribute in RS helps to understand that CS is in hold during the given time.  

BTW, these information is possible to be passed in stream extension data but I thought that reusing the existing SDP framework may be preferred. I'm not very sure at this moment whether removing this text is appropriate. In case everyone feels that it is *data* and not *metadata*, I'll remove this sentence in the next revision. </Partha>

        Thanks,
        Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 12 Mar 2011 23:54:01 +0530

John,
 
Thanks for the detailed comments. Please read inline.
 
Thanks
Partha

From: Elwell, John [mailto:[email-masked]]
Sent: Fri 3/11/2011 8:19 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Review Request for draft-ram-siprec-metadata-format-01

Partha,

1. In section 3:

3. Section 4.2.4:

<Partha> It is a good point. I missed to remove after our last interim meeting discussion. I'll remove in the next revision as there is no strong request for initiator of the session </Partha> 

4. The example (section 5.1) seems rather odd, in that the recording-metadata element appears to comprise a sequence of elements (recording, group, session, etc.) alternating with extensiondata elements, i.e., there is an extensiondata element after each of the other elements. This probably complies with the schema, but what is the meaning of several extensiondata elements all within the same recording-metadata element? 

<Partha> Each extensiondata has its own id and different parent id. Parent id shall be of recording, group, session etc., It is possible for each extension data to have different extended namespace which is specific to its parent.  But it is possible to uniquely identify within recording-metadata as it has its own unique id. </Partha>

Why not just a single extensiondata element? 

<Partha> It may not be preferred because it is tough to arrange extension data for a particular stream within the extension data of group. The individual extension data also provides flexibility to pass the specific extension-data during partial update in case other extension data is not modified. </Partha>

Is any significance to be drawn from the fact that there is an extensiondata element following the recording element, another following the group element, etc.?

<Partha> As mentioned earlier, group mechanism may passed in group extensiondata  whereas retention policy of a specific session will be passed in session, recording extension data will have common attribute like os login shall be passed. It provides more flexibility and it is optional element, so it is required to pass whenever applicable only </Partha>

<Partha> Parent-id in extension data helps to link group, session to specific extension data </partha>

6. The method of sending partial metadata seems to imply that when a session, participant, stream etc. comes to an end, we send partial metadata indicating that the element concerned now has an end time. This seems implicitly to mean that the element ceases to exist - correct? So if the SRS were to request a snapshot of complete metadata, it would not receive any elements for which a stop time has previously been sent - correct?

<Partha> Your understanding is correct, end-time will not passed across in case of SRS request for complete metadata as SRC may have lost the state</Partha>

 I don't think I have an issue with this - I just wanted to confirm my understanding.

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Mar 2011 14:53:47 -0500

On 3/12/2011 1:24 PM, Parthasarathi R (partr) wrote:

> 6. The method of sending partial metadata seems to imply that when a
> session, participant, stream etc. comes to an end, we send partial
> metadata indicating that the element concerned now has an end time. This
> seems implicitly to mean that the element ceases to exist - correct? So
> if the SRS were to request a snapshot of complete metadata, it would not
> receive any elements for which a stop time has previously been sent -
> correct?
>
> <Partha> Your understanding is correct, end-time will not passed across
> in case of SRS request for complete metadata as SRC may have lost the
> state</Partha>

The element doesn't cease to exist. None of the elements ever cease to 
exist. They are simply historic. But its likely that the SRC ceases to 
remember it, and hence won't mention it if a snapshot is subsequently 
requested.

However, if it *did* happen to remember it, it *could* subsequently send 
some additional data to associate with it. (But in this case that seems 
unlikely.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 13 Mar 2011 11:41:07 +0100

So let's see if I understand correctly. Element extensionData occurs in recording-metadata, as part of the sequence that also contains things like session, participant, stream. The element has attributes 'id' and 'parent' for linking the extension data to other elements.

Is this correct? I am not sure I understand the reasons for doing it this way, but it seems it should work.

Some specific comments:

1. The schema shows 'id' and 'session' as the attributes of extensionData - I assume 'session' should be 'parent'.

2. Element extensionData also occurs in element participant for some reason, according to the scheme. Is this also an error?

3. In 4.2.2:
"recording-metadata element has recording, group, session, stream
   elements."
Participant seems to be missing (present in the example and in the scheme).

4. The group element is missing from the schema (present in the 4.2.2 and in the example).

John (as individual)

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 12 March 2011 18:24
> To: Elwell, John; [email-masked]
> I wonder whether it is really appropriate to describe SDP 
> attributes as part of the metadata. If I look at the metadata 
> model, I don't see any attributes of a Media Stream object 
> that could be satisfied using RS SDP. For example, the "codec 
> parameters" attribute relates to the CS, not the RS - the two 
> sessions could use different codecs or different codec 
> parameters. I think it would be far simpler to regard all 
> metadata as being sent in XML. Note that the SDP label 
> attribute can still be used as the linkage between a Media 
> Stream object in the metadata and the corresponding RS media 
> stream that captures the CS media stream concerned.
> 
> 2. We perhaps need to think about mixed RS media streams, 
> i.e., where several CS media streams have been mixed to 
> produce a single RS media stream. In this case, the several 
> Media Stream objects would all point to the same SDP label, I 
> guess. This then brings into question the mode element (type 
> streamMode) - why is this needed? The fact that several Media 
> Stream objects (stream elements) point to the same label 
> would imply there has been mixing, so the mode element seems 
> to be redundant.
> 
> 3. Section 4.2.4:
> It is unclear to me why a URI identifying the SRC should be 
> an attribute of a group element. I cannot find a 
> corresponding attribute in the CS Group object in the 
> metadata model draft.
> 
> <Partha> It is a good point. I missed to remove after our 
> last interim meeting discussion. I'll remove in the next 
> revision as there is no strong request for initiator of the 
> session </Partha> 
> 
> 4. The example (section 5.1) seems rather odd, in that the 
> recording-metadata element appears to comprise a sequence of 
> elements (recording, group, session, etc.) alternating with 
> extensiondata elements, i.e., there is an extensiondata 
> element after each of the other elements. This probably 
> complies with the schema, but what is the meaning of several 
> extensiondata elements all within the same recording-metadata 
> element? 
> 
> <Partha> Each extensiondata has its own id and different 
> parent id. Parent id shall be of recording, group, session 
> etc., It is possible for each extension data to have 
> different extended namespace which is specific to its parent. 
>  But it is possible to uniquely identify within 
> recording-metadata as it has its own unique id. </Partha>
> 
> <Partha> It may not be preferred because it is tough to 
> arrange extension data for a particular stream within the 
> extension data of group. The individual extension data also 
> provides flexibility to pass the specific extension-data 
> during partial update in case other extension data is not 
> modified. </Partha>
> 
> Is any significance to be drawn from the fact that there is 
> an extensiondata element following the recording element, 
> another following the group element, etc.?
> 
> <Partha> As mentioned earlier, group mechanism may passed in 
> group extensiondata  whereas retention policy of a specific 
> session will be passed in session, recording extension data 
> will have common attribute like os login shall be passed. It 
> provides more flexibility and it is optional element, so it 
> is required to pass whenever applicable only </Partha>
> 
> 5. On the other hand, elements group, session, etc. seem to 
> lack extensiondata elements - would it not be sensible to 
> allow each of these to be extensible?
> 
> <Partha> Parent-id in extension data helps to link group, 
> session to specific extension data </partha>
> 
> 6. The method of sending partial metadata seems to imply that 
> when a session, participant, stream etc. comes to an end, we 
> send partial metadata indicating that the element concerned 
> now has an end time. This seems implicitly to mean that the 
> element ceases to exist - correct? So if the SRS were to 
> request a snapshot of complete metadata, it would not receive 
> any elements for which a stop time has previously been sent - correct?
> 
> <Partha> Your understanding is correct, end-time will not 
> passed across in case of SRS request for complete metadata as 
> SRC may have lost the state</Partha>
> 
> > A new version of I-D, 
> draft-ram-siprec-metadata-format-01.txt has been

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sun, 13 Mar 2011 19:45:21 +0530

John,
 
Thanks for  further review of the draft and specific comments on XML. Please read inline.
 
Thanks
Partha

From: Elwell, John [mailto:[email-masked]]
Sent: Sun 3/13/2011 4:11 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Review Request for draft-ram-siprec-metadata-format-01

Is this correct?

<Partha> Yeah, it is correct </partha>

 I am not sure I understand the reasons for doing it this way, but it seems it should work.

<Partha> Recording metadata is the main container of rs-metadata+xml and it is the only one element which MUST be passed in both Complete/Partial Metadata XML document. All other metadata block (like stream, session, participant, extension data) in the model shall be passed independently from SRC and then, SRS will be able to correlate based on the "id". The linkage is done so that the hierarchical blocks of metadata model will be represented using the "id" relationship in XML document which avoids extra namespace during partial XML update. This design logic is applied in the following elements:  group, session, stream, participant, extensiondata as well. This proposed mechanism allows to update only extensiondata alone as well if required. The relationship of element & parent element in metadata XML document is as follows:

    Element                           -             parent id name

----------------------------------------------------------------

   group                                -             recording

   session                           -              group

   participant                       -              session

   stream                             -              session

   extensiondata                -              parent

</Partha>
Some specific comments:

<Partha> Thanks for pointing these error. I'll update the text in the next revision </Partha>

<Partha> Group element is present in Sec 6 of schema.

</xs:complexType>
   <xs:complexType name="group">
       <xs:sequence>
           <xs:element name="initiator" type="xs:anyURI"
            minOccurs="0" maxOccurs="1"/>  ====> Will be removed in the next revision as per below mail discussion 
         <xs:element name="start-time" type="xs:dateTime"
                minOccurs="0"/>
         <xs:element name="stop-time" type="xs:dateTime"
                minOccurs="0"/>
       </xs:sequence>
       <xs:attribute name="id" type="xs:urnuuid"
            use"required"/>
       <xs:attribute name="recording" type="xs:urnuuid"
            use"required"/>
   </xs:complexType> 

Please let me know in case any other change has to be done in the group element schema 

</Partha>
John (as individual)

> From: Parthasarathi R (partr) [mailto:[email-masked] <mailto:[email-masked]> ]
> From: Elwell, John [mailto:[email-masked] <mailto:[email-masked]> ]
> > [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Parthasarathi
> R (partr)
> > http://www.ietf.org/id/draft-ram-siprec-metadata-format-01.txt <http://www.ietf.org/id/draft-ram-siprec-metadata-format-01.txt> . The
> > From: IETF I-D Submission Tool [mailto:[email-masked] <mailto:[email-masked]> ]
> > https://www.ietf.org/mailman/listinfo/siprec <https://www.ietf.org/mailman/listinfo/siprec> 
> >
>
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 14 Mar 2011 08:39:12 +0100

> Sent: 13 March 2011 14:15
> So let's see if I understand correctly. Element extensionData
> occurs in recording-metadata, as part of the sequence that
> also contains things like session, participant, stream. The
> element has attributes 'id' and 'parent' for linking the
> extension data to other elements.
>
> Is this correct?
>
> <Partha> Recording metadata is the main container of
> rs-metadata+xml and it is the only one element which MUST be
> passed in both Complete/Partial Metadata XML document. All
> other metadata block (like stream, session, participant,
> extension data) in the model shall be passed independently
> from SRC and then, SRS will be able to correlate based on the
> "id".
[JRE] I see. So this allows entities other than the SRC to send metadata in this same format to the SRS, and furthermore those entities could send new or revised metadata for an object (group, session etc.) without repeating the object itself. I am not sure this is a requirement of the work, but it is certainly a property of the chosen solution.

> The linkage is done so that the hierarchical blocks of
> metadata model will be represented using the "id"
> relationship in XML document which avoids extra namespace
> during partial XML update. This design logic is applied in
> the following elements:  group, session, stream, participant,
> extensiondata as well. This proposed mechanism allows to
> update only extensiondata alone as well if required. The
> relationship of element & parent element in metadata XML
> document is as follows:
[JRE] So it has the benefit that the SRS can send new or revised metadata for an object (group, session, etc.) without repeating the object itself. I am not sure whether this is a significant benefit - in such circumstances it might save a bit of XML, but it has the cost of transmitting an object's identifier every time that object is sent, so I am not convinced there is overall gain.

> 1. The schema shows 'id' and 'session' as the attributes of
> extensionData - I assume 'session' should be 'parent'.
> 2. Element extensionData also occurs in element participant
> for some reason, according to the scheme. Is this also an error?
> 3. In 4.2.2:
[JRE] Yes, I don't know how I missed it.

John

>             minOccurs="0" maxOccurs="1"/>  ====> Will be
> removed in the next revision as per below mail discussion
> > From: Elwell, John
> [mailto:[email-masked]
> <mailto:[email-masked]> ]
> > > [mailto:[email-masked]
> <mailto:[email-masked]> ] On Behalf Of Parthasarathi
> > R (partr)
> http://www.ietf.org/id/draft-ram-siprec-metadata-format-01.txt
>
> <http://www.ietf.org/id/draft-ram-siprec-metadata-format-01.txt> . The
> > > From: IETF I-D Submission Tool
> [mailto:[email-masked] <mailto:[email-masked]> ]
> <https://www.ietf.org/mailman/listinfo/siprec>
> > >
> >
> >
> >
>
>
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 14 Mar 2011 18:04:11 +0530

John & all,

I complete agree with you that overhead of id inclusion in each Metadata
block element in case partial metadata XML document has to be supported,
there is no explicit requirement in SIPREC to solve this issue and -00
version metadata format draft addresses for complete snapsnot of XML
every time within single RS session. But I noticed in mailing alias and
last SIPREC interim meeting comment that partial metadata support as an
major open item (elephant) for metadata format draft. I'm including
Leon, Henry, and Paul as they provided comments on partial metadata. 

I'm convinced for partial metadata XML document support because of the
following reason: 

1) The usage will be more beneficial for Persistent recording mechanism
2) In Call Center scenarios, Hold & Resume, transfer sort of mid-dialog
service exist during most of the calls. Partial metadata update helps in
these scenarios.
3) Universally Unique id is anyway required for group, session, stream
element in XML which shall be used for partial XML passing as well.

Also, We analyzed multiple partial metadata XML format:

1) Current mechanism of Metadata block level id and single container
2) RFC 5261 - An Extensible Markup Language (XML) Patch Operations
Framework Utilizing XML  Path Language (XPath) Selectors
3) REST architecture for Metadata XML

With above all mechanism, the current partial XML mechanism is the
simplest mechanism which well fit for SIPREC. Including Peter in the
mail thread to find any other simpler or less overhead mechanism exists
in XML.

Please let me know everyone opinion which way to go because this is a
crucial decision point for metadata XML format.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, March 14, 2011 1:09 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Review Request for

> So let's see if I understand correctly. Element extensionData occurs 
> in recording-metadata, as part of the sequence that also contains 
> things like session, participant, stream. The element has attributes 
> 'id' and 'parent' for linking the extension data to other elements.
>
> Is this correct?
>
> passed in both Complete/Partial Metadata XML document. All other 
> metadata block (like stream, session, participant, extension data) in 
> the model shall be passed independently from SRC and then, SRS will be

> able to correlate based on the "id".
[JRE] I see. So this allows entities other than the SRC to send metadata
in this same format to the SRS, and furthermore those entities could
send new or revised metadata for an object (group, session etc.) without
repeating the object itself. I am not sure this is a requirement of the
work, but it is certainly a property of the chosen solution.

> The linkage is done so that the hierarchical blocks of metadata model 
> will be represented using the "id"
> relationship in XML document which avoids extra namespace during 
> partial XML update. This design logic is applied in the following 
> elements:  group, session, stream, participant, extensiondata as well.

> This proposed mechanism allows to update only extensiondata alone as 
> well if required. The relationship of element & parent element in 
> metadata XML document is as follows:
[JRE] So it has the benefit that the SRS can send new or revised
metadata for an object (group, session, etc.) without repeating the
object itself. I am not sure whether this is a significant benefit - in
such circumstances it might save a bit of XML, but it has the cost of
transmitting an object's identifier every time that object is sent, so I
am not convinced there is overall gain.

> 2. Element extensionData also occurs in element participant for some 
> reason, according to the scheme. Is this also an error?
> 3. In 4.2.2:

John

>             minOccurs="0" maxOccurs="1"/>  ====> Will be removed in 
> the next revision as per below mail discussion
> > I wonder whether it is really appropriate to describe SDP attributes

> > as part of the metadata. If I look at the metadata model, I don't 
> > see any attributes of a Media Stream object that could be satisfied 
> > using RS SDP. For example, the "codec parameters" attribute relates 
> > to the CS, not the RS - the two sessions could use different codecs 
> > or different codec parameters. I think it would be far simpler to 
> > regard all metadata as being sent in XML. Note that the SDP label 
> > attribute can still be used as the linkage between a Media Stream 
> > object in the metadata and the corresponding RS media stream that 
> > captures the CS media stream concerned.
> >
> > 2. We perhaps need to think about mixed RS media streams, i.e., 
> > where several CS media streams have been mixed to produce a single 
> > RS media stream. In this case, the several Media Stream objects 
> > would all point to the same SDP label, I guess. This then brings 
> > into question the mode element (type
> > streamMode) - why is this needed? The fact that several Media Stream

> > objects (stream elements) point to the same label would imply there 
> > has been mixing, so the mode element seems to be redundant.
> >
> > 3. Section 4.2.4:
> > It is unclear to me why a URI identifying the SRC should be an 
> > attribute of a group element. I cannot find a corresponding 
> > attribute in the CS Group object in the metadata model draft.
> >
> > <Partha> It is a good point. I missed to remove after our last 
> > interim meeting discussion. I'll remove in the next revision as 
> > there is no strong request for initiator of the session </Partha>
> >
> > extensiondata elements, i.e., there is an extensiondata element 
> > after each of the other elements. This probably complies with the 
> > schema, but what is the meaning of several extensiondata elements 
> > all within the same recording-metadata element?
> >
> > <Partha> Each extensiondata has its own id and different parent id. 
> > Parent id shall be of recording, group, session etc., It is possible

> > for each extension data to have different extended namespace which 
> > is specific to its parent.
> >  But it is possible to uniquely identify within recording-metadata 
> > as it has its own unique id. </Partha>
> >
> > <Partha> It may not be preferred because it is tough to arrange 
> > extension data for a particular stream within the extension data of 
> > group. The individual extension data also provides flexibility to 
> > pass the specific extension-data during partial update in case other

> > extension data is not modified. </Partha>
> >
> > Is any significance to be drawn from the fact that there is an 
> > extensiondata element following the recording element, another 
> > following the group element, etc.?
> >
> > <Partha> As mentioned earlier, group mechanism may passed in group 
> > extensiondata  whereas retention policy of a specific session will 
> > be passed in session, recording extension data will have common 
> > attribute like os login shall be passed. It provides more 
> > flexibility and it is optional element, so it is required to pass 
> > whenever applicable only </Partha>
> >
> > 5. On the other hand, elements group, session, etc. seem to lack 
> > extensiondata elements - would it not be sensible to allow each of 
> > these to be extensible?
> >
> > <Partha> Parent-id in extension data helps to link group, session to

> > specific extension data </partha>
> >

> > metadata indicating that the element concerned now has an end time. 
> > This seems implicitly to mean that the element ceases to exist - 
> > correct? So if the SRS were to request a snapshot of complete 
> > metadata, it would not receive any elements for which a stop time 
> > has previously been sent
> - correct?
> >
> > <Partha> Your understanding is correct, end-time will not passed 
> > across in case of SRS request for complete metadata as SRC may have 
> > lost the state</Partha>
> >

> > > 1) URN UUID (RFC 4122) mechanism is used as the unique id 
> > > mechanism for relevant XML elements like group, session, stream, 
> > > participant.
> > >
> > > 2) Partial XML passing in RS is supported by having unique URN 
> > > UUID for group, session, stream, participant, recording, extension

> > > data which are directly under recording-metadata 
> > > container/namespace.
> > >
> > > 3) Include recording-metadata element as a container element 
> > > instead of recording element. This helps in avoiding duplicate 
> > > data of
> > recording

> > > compliance, and consumer protection reasons.  Recording of a 
> > > session is typically performed by sending a copy of a media stream

> > > to
> > a recording
> > > [I-D.ietf-siprec-architecture], and the metadata model viewed by 
> > > Session Recording Server is described in 
> > > [I-D.ram-siprec-metadata].

---

From: Leon Portman <[email-masked]>
Date: Mon, 14 Mar 2011 14:39:58 +0200

Sorry, I was not following this thread from the beginning.  I completely agree with Partha. Support for delta updates of metadata is mandatory from my point of view.

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Monday, March 14, 2011 2:34 PM
To: Elwell, John; [email-masked]
Cc: Leon Portman; Henry Lum; Paul Kyzivat (pkyzivat); Peter Saint-Andre (psaintan)
Subject: Partial Metadata XML document usage in SIPREC [was RE: [siprec] Review Request for draft-ram-siprec-metadata-format-01]

John & all,

I complete agree with you that overhead of id inclusion in each Metadata block element in case partial metadata XML document has to be supported, there is no explicit requirement in SIPREC to solve this issue and -00 version metadata format draft addresses for complete snapsnot of XML every time within single RS session. But I noticed in mailing alias and last SIPREC interim meeting comment that partial metadata support as an major open item (elephant) for metadata format draft. I'm including Leon, Henry, and Paul as they provided comments on partial metadata.

I'm convinced for partial metadata XML document support because of the following reason:

1) The usage will be more beneficial for Persistent recording mechanism
2) In Call Center scenarios, Hold & Resume, transfer sort of mid-dialog service exist during most of the calls. Partial metadata update helps in these scenarios.
3) Universally Unique id is anyway required for group, session, stream element in XML which shall be used for partial XML passing as well.

1) Current mechanism of Metadata block level id and single container
2) RFC 5261 - An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML  Path Language (XPath) Selectors
3) REST architecture for Metadata XML

With above all mechanism, the current partial XML mechanism is the simplest mechanism which well fit for SIPREC. Including Peter in the mail thread to find any other simpler or less overhead mechanism exists in XML.

Please let me know everyone opinion which way to go because this is a crucial decision point for metadata XML format.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Monday, March 14, 2011 1:09 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Review Request for

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 14 Mar 2011 18:25:54 +0530

+1. 
As per my understanding, in the last interim meeting there was a general
agreement from most folks on the need to have partial updates for
metadata.
If we feel there is an overhead with the current proposed mechanism in
draft-ram-siprec-metadata-format-01 we could brainstorm on that to see
if there is any better approach.

Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Monday, March 14, 2011 6:10 PM
> To: Parthasarathi R (partr); Elwell, John; [email-masked]
> Cc: Henry Lum; Peter Saint-Andre (psaintan)
> Subject: Re: [siprec] Partial Metadata XML document usage in SIPREC
> [was RE: Review Request for draft-ram-siprec-metadata-format-01]
> 
> Sorry, I was not following this thread from the beginning.  I
> completely agree with Partha. Support for delta updates of metadata is
> mandatory from my point of view.
> 
> Leon
> 
> Cc: Leon Portman; Henry Lum; Paul Kyzivat (pkyzivat); Peter
Saint-Andre
> (psaintan)
> Subject: Partial Metadata XML document usage in SIPREC [was RE:
> [siprec] Review Request for draft-ram-siprec-metadata-format-01]
> 
> John & all,
> 
> I complete agree with you that overhead of id inclusion in each
> Metadata block element in case partial metadata XML document has to be
> supported, there is no explicit requirement in SIPREC to solve this
> issue and -00 version metadata format draft addresses for complete
> snapsnot of XML every time within single RS session. But I noticed in
> mailing alias and last SIPREC interim meeting comment that partial
> metadata support as an major open item (elephant) for metadata format
> draft. I'm including Leon, Henry, and Paul as they provided comments
on
> partial metadata.
> service exist during most of the calls. Partial metadata update helps
> in these scenarios.
> > Thanks for  further review of the draft and specific comments on
XML.
> >  I am not sure I understand the reasons for doing it this way, but
it
> > seems it should work.
> > <Partha> Thanks for pointing these error. I'll update the text in
the
> > next revision </Partha>
> >
> > 4. The group element is missing from the schema (present in the
4.2.2
> > and in the example).
> attributes
> Stream
> > >  I don't think I have an issue with this - I just wanted to
confirm
> > > my understanding.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Mar 2011 09:10:25 -0400

John,

We have been bouncing around different ways of accomplishing the task, 
and this is where we have gotten to. We may not have it quite right yet. 
Its a matter of factoring the model into objects with a suitable 
granularity wrt the way they are used and change. (Things look a bit 
different when you are concentrating on the encoding as xml than they do 
when viewed as an abstract model.)

Right now we are seeing an early step - coming up with an encoding and 
then seeing how it works out in practice. Then we can "stand back and 
look at it", and decide if we like what we see. So I expect that as we 
refine this there may be quite a bit of "fine tuning" - whether things 
are encoded as optional attributes of one object, or as separate objects.

	Thanks,
	Paul

On 3/14/2011 3:39 AM, Elwell, John wrote:
>> <Partha>  Yeah, it is correct</partha>
>>
>> relationship of element&  parent element in metadata XML
>> document is as follows:
>> <Partha>  Thanks for pointing these error. I'll update the
>> text in the next revision</Partha>
>>
>>> session</Partha>
>>> recording-metadata as it has its own unique id.</Partha>
>>>
>>> modified.</Partha>
>>> is required to pass whenever applicable only</Partha>
>>>
>>> session to specific extension data</partha>
>>>
>>> confirm my understanding.
>>>
>>> John (as individual)
>>>
>>>
>>>> mechanism for
>>>> instead of
>>>> elements&  associations
>>>> 7) Added Partial Update example&  SIP usage XML+SDP example
>>>>
>> [mailto:[email-masked]<mailto:[email-masked]>  ]
>>>> session is

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 14 Mar 2011 15:29:03 +0100

OK, what I failed to appreciate was that the overhead of the identifier in each entity (group, session, etc.) is present independently of whether extensionData can be updated separately or only as part of the entity concerned. So given that we need partial updates, the identifier is needed anyway, regardless of how we treat extensionData. Sorry for the confusion.

John (as individual)

> Sent: 14 March 2011 12:34
> Saint-Andre (psaintan)
> Subject: Partial Metadata XML document usage in SIPREC [was
> RE: [siprec] Review Request for draft-ram-siprec-metadata-format-01]
>
> John & all,
>
> > Thanks for  further review of the draft and specific
> comments on XML.
> > Please read inline.
> >
> > Thanks
> > Partha
> >
> >  I am not sure I understand the reasons for doing it this
> way, but it
> > seems it should work.
> >
> for some
> text in the
> > 4. The group element is missing from the schema (present in
> the 4.2.2
> > and in the example).
> >
> parent id.
> session to
> > >  I don't think I have an issue with this - I just wanted
> to confirm
> > > my understanding.
> > >
> > > John (as individual)
> > >
> > >

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 14 Mar 2011 21:21:48 +0530

John,
 
Thanks for accepting the partial metadata mechanism in the draft. 
 
Thanks
Partha

From: Elwell, John [mailto:[email-masked]]
Sent: Mon 3/14/2011 7:59 PM
To: Parthasarathi R (partr); [email-masked]
Cc: Leon Portman; Henry Lum; Paul Kyzivat (pkyzivat); Peter Saint-Andre (psaintan)
Subject: RE: Partial Metadata XML document usage in SIPREC [was RE: [siprec] Review Request for draft-ram-siprec-metadata-format-01]

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Mar 2011 12:22:13 +0100

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 11 March 2011 18:23
> To: [email-masked]
[JRE] I was confused by section 4.5 of the metadata model draft. It does indeed seem to say that it represents an RS media stream:
"A Media Stream block shall have properties of media as seen by SRC and sent to SRS."
And hence your interpretation above would seem reasonable. On the other hand, in 4.5.2 it says:
"A Media Stream SHALL be associated with Participant and CS."
This misled me. Also in 4.5.1:
"Codec params - represents codec parameters of the CS media"
This also seemed to imply the Media Stream object relates to a CS media stream.
Perhaps some clarification is needed in the Metadata draft.
Anyway, assuming we go with your interpretation, I suppose what we end up with is that if streams are mixed (whether this be at an MCU, say, or just part of the SRC in order to send the streams to the SRS), the net result will be modelling as a single stream in the metadata. Is this a common understanding?

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Mar 2011 12:27:38 +0100

> Sent: 12 March 2011 17:50
> To: Paul Kyzivat (pkyzivat); [email-masked]
> <Partha> I agree with the linkage part and CS codec 
> parameters information in the model.  IMO, some of the 
> information shall be retrieved from RS SDP 
> 
[JRE] Yes, I agree this needs to form part of the metadata, which unfortunately breaks my proposed simplification (unless we duplicate the information in the XML metadata).

> 
> 2) In a unmixed stream, grouping of direction attribute in RS 
> helps to understand that CS is in hold during the given time.  
[JRE] I don't understand this. In the RS, I would only ever expect to see sendonly (from SSRC to SRS) or inactive. Inactive means recording is paused, sendonly means recording is in progress. It says nothing about the held state of the CS, which would still need to be captured in XML metadata.

John (as individual)

> 
> BTW, these information is possible to be passed in stream 
> extension data but I thought that reusing the existing SDP 
> framework may be preferred. I'm not very sure at this moment 
> whether removing this text is appropriate. In case everyone 
> feels that it is *data* and not *metadata*, I'll remove this 
> sentence in the next revision. </Partha>
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Mar 2011 17:20:41 +0530

John,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 4:58 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); [email-masked]
Subject: RE: [siprec] Review Request for

> attributes as part of the metadata. If I look at the metadata model, I

> don't see any attributes of a Media Stream object that could be 
> satisfied using RS SDP. For example, the "codec parameters" attribute 
> relates to the CS, not the RS - the two sessions could use different 
> codecs or different codec parameters. I think it would be far simpler 
> to regard all metadata as being sent in XML. Note that the SDP label 
> linkage between the *meta*data and the *data*. Originally I was 
> thinking that there would be some things in the sdp that were 
> metadata, but so far that seems not to be true.
> 
> <Partha> I agree with the linkage part and CS codec parameters 
> information in the model.  IMO, some of the information shall be 
> retrieved from RS SDP
> 
[JRE] Yes, I agree this needs to form part of the metadata, which
unfortunately breaks my proposed simplification (unless we duplicate the
information in the XML metadata).

> 
> 2) In a unmixed stream, grouping of direction attribute in RS helps to

> understand that CS is in hold during the given time.
[JRE] I don't understand this. In the RS, I would only ever expect to
see sendonly (from SSRC to SRS) or inactive. Inactive means recording is
paused, sendonly means recording is in progress. It says nothing about
the held state of the CS, which would still need to be captured in XML
metadata.

<partha> I agree by looking at the single m-line, it will only evident
whether the recording is paused or not. In case of unmixed audio stream,
there are two m-lines, each m-line is associated with one participant
and SRS shall interpret the information from 2 m-line as follows:

1) Two m-lines have "sendonly" then the recording is in progress
2) Two m-lines have "inactive" then the recording is paused or call hold
3) One m-line have "sendonly", other m-line have "inactive" indicates
the service like music on hold.
</partha>

John (as individual)

> 
> BTW, these information is possible to be passed in stream extension 
> data but I thought that reusing the existing SDP framework may be 
> preferred. I'm not very sure at this moment whether removing this text

> is appropriate. In case everyone feels that it is *data* and not 
> *metadata*, I'll remove this sentence in the next revision. </Partha>
> 
> i.e., where several CS media streams have been mixed to produce a 
> single RS media stream. In this case, the several Media Stream objects

> would all point to the same SDP label, I guess. This then brings into 
> question the mode element (type

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Mar 2011 09:02:39 -0400

> Anyway, assuming we go with your interpretation, I suppose what we end up with is that if streams are mixed (whether this be at an MCU, say, or just part of the SRC in order to send the streams to…

You may have a point here - that things are somewhat ambiguous.

If we have two distinct media streams in the CS, and they are mixed 
together by the SRC before sending to the SRS, then they could be 
treated different ways:

- The SRC could report this as a single media stream with multiple 
participants. But then it would have to report its metadata as if it 
were a single stream from a mixer.

- The SRC could report it as multiple media streams from a metadata 
perspective, but map them all onto the same RS media stream. (This is a 
possibility I had never considered/recognized.)

Is there a desire to support both? If so, the metamodel and mechanism 
will probably need some tweaking.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Mar 2011 14:56:17 +0100

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 15 March 2011 13:03
> To: Elwell, John
> Cc: [email-masked]
> > [JRE] I was confused by section 4.5 of the metadata model 
> draft. It does indeed seem to say that it represents an RS 
> media stream:
> > Anyway, assuming we go with your interpretation, I suppose 
> what we end up with is that if streams are mixed (whether 
> this be at an MCU, say, or just part of the SRC in order to 
> send the streams to the SRS), the net result will be 
> modelling as a single stream in the metadata. Is this a 
> common understanding?
> 
[JRE] Consider:
"REQ-009: The mechanism MUST support the ability for an SRC to
   deliver mixed audio streams from different parties of a given
   Communication Session to an SRS."
One particular case I believe this covers is the simple 2-party call, where there are two media streams, one from A to B and the other from B to A. The SRC could mix the two together into a single stream to the SRS. Certainly useful for bandwidth constrained environments, but not so friendly towards speech analytics.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 16 Mar 2011 06:54:49 +0530

John,
 
Please read inline.
 
Thanks
Partha

From: [email-masked] on behalf of Elwell, John
Sent: Tue 3/15/2011 7:26 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Review Request for draft-ram-siprec-metadata-format-01

> seen by SRC and sent to SRS."

<Partha> Metadata model support this mechanism.  </Partha>
> > This also seemed to imply the Media Stream object relates

<Partha> It is the assumption done during metadata format that RS SDP may be used as Codec params for stream. Please note that format draft does not have codec param in stream metadata element. But the assumption does not seems to be working for all scenarios. So we need to find the way to represent CS Media stream in metadata format.

Even before going into approach, I'm interested in knowing whether it is required for SRS to understand the exact codec or SDP parameter used in CS? RS may be transcoded/transrated and lost the actual media information when it reaches SRS but the question is whether it is required to maintain the metadata in SRS even though media (RTP) is changed to new format ? 

In case we decide to pass CS codec parameter to SRS. Two approaches exist to solve this issue:

1) Tunnel complete each participant SDP inside stream element using some new optional XML element. This approach is straightforward and scale for any CS as we are sending the complete set. The overhead will be increased in SRS to parse and store appropriately.

2) Identify the list of codec parameters *MUST*  be passed from SRC to SRS and create the new XML element for them. This is simple to implement as only portion of the SDP is passed across but *may* have scalability issue.

I prefer 1st approach because it covers all scenarios. I'm interested in hearing from you which way to go.

</partha>

[JRE] Consider:

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Mar 2011 08:34:10 +0100

> Sent: 16 March 2011 01:25
> To: Elwell, John; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: CS Codec Parameter in stream XML element [was RE: 
<snip/>
> <Partha> It is the assumption done during metadata format 
> that RS SDP may be used as Codec params for stream. Please 
> note that format draft does not have codec param in stream 
> metadata element. But the assumption does not seems to be 
> working for all scenarios. So we need to find the way to 
> represent CS Media stream in metadata format.
> 
> Even before going into approach, I'm interested in knowing 
> whether it is required for SRS to understand the exact codec 
> or SDP parameter used in CS? RS may be transcoded/transrated 
> and lost the actual media information when it reaches SRS but 
> the question is whether it is required to maintain the 
> metadata in SRS even though media (RTP) is changed to new format ? 
> 
> 1) Tunnel complete each participant SDP inside stream element 
> using some new optional XML element. This approach is 
> straightforward and scale for any CS as we are sending the 
> complete set. The overhead will be increased in SRS to parse 
> and store appropriately.
> 
> 2) Identify the list of codec parameters *MUST*  be passed 
> from SRC to SRS and create the new XML element for them. This 
> is simple to implement as only portion of the SDP is passed 
> across but *may* have scalability issue.
> 
> I prefer 1st approach because it covers all scenarios. I'm 
> interested in hearing from you which way to go.
> 
> </partha>
[JRE] I was basing my earlier comment on the fact that the metadata model seems to indicate that the Media Stream object has CS codec parameters as an attribute. This is indeed questionable. I seem to remember somebody wanting this at some stage in the past. From my point of view, I don't think this information is needed by the SRS - it is historic information, nothing to do with the media actually sent to the SRS, and of no use to the SRS, in my opinion.

If people do think there is a reason for providing this information to the SRS, I don't think I would favour approach 1) above. The SDP could potentially contain all sorts of information other than codecs (codecs are only a small part, and the SDP will contain information like IP addresses, ports, security keys!!!, transport, non-recorded media descriptions (e.g., MSRP channel, BFCP channel), format parameters, SDP capability negotiation attributes, etc..

Moreover, the offerer and answerer might have agreed several codecs in the SDP, so you need to look at RTP to see which codec is actually used. This can change on the fly.

Finally, although the SRS's SIP/SDP stack will surely have and SDP parser, the XML metadata is intended for passing to an application. Requiring that application to contain an SDP parser is, I think, unreasonable.

So I have doubts as to whether it is really feasible to provide CS codec information in metadata to the SRS in a meaningful way, whether this be using approach 1) or approach 2), but I particularly dislike approach 1).

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 16 Mar 2011 14:49:41 +0530

Hi John,

Please read inline.

Including Leon in this mail thread as he provided the comment in the
same area.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2011 1:04 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: CS Codec Parameter in stream XML element [was RE: [siprec]
Review Request for draft-ram-siprec-metadata-format-01]

<snip/>
> <Partha> It is the assumption done during metadata format that RS SDP 
> may be used as Codec params for stream. Please note that format draft 
> does not have codec param in stream metadata element. But the 
> assumption does not seems to be working for all scenarios. So we need 
> to find the way to represent CS Media stream in metadata format.
> 
> Even before going into approach, I'm interested in knowing whether it 
> is required for SRS to understand the exact codec or SDP parameter 
> used in CS? RS may be transcoded/transrated and lost the actual media 
> information when it reaches SRS but the question is whether it is 
> required to maintain the metadata in SRS even though media (RTP) is 
> changed to new format ?
> 
> 1) Tunnel complete each participant SDP inside stream element using 
> some new optional XML element. This approach is straightforward and 
> scale for any CS as we are sending the complete set. The overhead will

> be increased in SRS to parse and store appropriately.
> 
> 2) Identify the list of codec parameters *MUST*  be passed from SRC to

> SRS and create the new XML element for them. This is simple to 
> implement as only portion of the SDP is passed across but *may* have 
> scalability issue.
> 
[JRE] I was basing my earlier comment on the fact that the metadata
model seems to indicate that the Media Stream object has CS codec
parameters as an attribute. This is indeed questionable. I seem to
remember somebody wanting this at some stage in the past. From my point
of view, I don't think this information is needed by the SRS - it is
historic information, nothing to do with the media actually sent to the
SRS, and of no use to the SRS, in my opinion.

<Partha> I'm of the same opinion as yours as I really didn't get the
exact requirement to keep CS metadata only and not CS original
data(media). Some of my guessed requirements are

1) CS with High Density (HD) video/audio but recording with Low
density(LD) video/audio codec for saving the bandwidth/storage. During
retrieval, somebody may be interested in knowing whether the original
communication is HD or LD

2) SRS may not support the codec which CS is using but during retrieval
process, it may required for weird reason to understand the original CS
codec. This may extended for packetization time of the codec. (Simple
Transcoding & transrating scenario). 

Let us get more clarity/reason for passing information before proceeding
to the approach. IMO, this parameter shall be removed in case there is
no strong requirement to pass across </Partha>

If people do think there is a reason for providing this information to
the SRS, I don't think I would favour approach 1) above. The SDP could
potentially contain all sorts of information other than codecs (codecs
are only a small part, and the SDP will contain information like IP
addresses, ports, security keys!!!, transport, non-recorded media
descriptions (e.g., MSRP channel, BFCP channel), format parameters, SDP
capability negotiation attributes, etc..

Moreover, the offerer and answerer might have agreed several codecs in
the SDP, so you need to look at RTP to see which codec is actually used.
This can change on the fly.

Finally, although the SRS's SIP/SDP stack will surely have and SDP
parser, the XML metadata is intended for passing to an application.
Requiring that application to contain an SDP parser is, I think,
unreasonable.

So I have doubts as to whether it is really feasible to provide CS codec
information in metadata to the SRS in a meaningful way, whether this be
using approach 1) or approach 2), but I particularly dislike approach
1).

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Mar 2011 09:33:05 -0400

I believe the codec parameters on the MS have been there since my first 
cut at the metadata model. Putting them there was just speculation on my 
part, and doesn't imply any actual need known to me.

If nobody feels they are necessary, then by all means remove them.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Mar 2011 17:45:35 +0200

I agree with points below that passing actual CS SDP to SRS is a not good idea from security and layers separation point of view.
Today's SRS implementations(at least that I know about) do not keep original codec information in the database for later retrieval. I am trying to think about use cases why SRS can be interested in one, and except troubleshooting it is not very relevant. 
The main assumption is that SRC inspected CS SDP and extracted all relevant information like ip addresses, media line labels and infos and reported it to SRS via metadata.

The main reason as I see if we want to be able to report CS SDP via metadata is for the case where SRS wants to sniff RS RTP packets directly and not by forking from SRC but it is out of scope.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, March 16, 2011 3:33 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

I believe the codec parameters on the MS have been there since my first cut at the metadata model. Putting them there was just speculation on my part, and doesn't imply any actual need known to me.

	Thanks,
	Paul

On 3/16/2011 3:34 AM, Elwell, John wrote:
>> <Partha>  It is the assumption done during metadata format that RS 
>> SDP may be used as Codec params for stream. Please note that format 
>> draft does not have codec param in stream metadata element. But the 
>> scale for any CS as we are sending the complete set. The overhead 
>> will be increased in SRS to parse and store appropriately.
>>
>> 2) Identify the list of codec parameters *MUST*  be passed from SRC 
>> to SRS and create the new XML element for them. This is simple to

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Mar 2011 18:28:31 +0100

Leon,

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 16 March 2011 15:46
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] CS Codec Parameter in stream XML 
> element [was RE: Review Request for 
> draft-ram-siprec-metadata-format-01]
> 
> I agree with points below that passing actual CS SDP to SRS 
> is a not good idea from security and layers separation point of view.
> Today's SRS implementations(at least that I know about) do 
> not keep original codec information in the database for later 
> retrieval. I am trying to think about use cases why SRS can 
> be interested in one, and except troubleshooting it is not 
> very relevant. 
> The main assumption is that SRC inspected CS SDP and 
> extracted all relevant information like ip addresses, media 
> line labels and infos and reported it to SRS via metadata.
[JRE] Why would the SRS need to know anything about CS IP addresses?

> 
> The main reason as I see if we want to be able to report CS 
> SDP via metadata is for the case where SRS wants to sniff RS 
> RTP packets directly and not by forking from SRC but it is 
> out of scope.
[JRE] So I assume you agree that there is no need for metadata to include CS codecs (or, for that matter CS IP addresses, ports, etc.).

John (as individual)

> Subject: Re: [siprec] CS Codec Parameter in stream XML 
> element [was RE: Review Request for 
> draft-ram-siprec-metadata-format-01]
> 
> I believe the codec parameters on the MS have been there 
> since my first cut at the metadata model. Putting them there 
> was just speculation on my part, and doesn't imply any actual 
> need known to me.
> 
> whether it 
> >> In case we decide to pass CS codec parameter to SRS. Two 
> approaches 
> >> exist to solve this issue:
> >>
> from SRC 
> > [JRE] I was basing my earlier comment on the fact that the 
> metadata model seems to indicate that the Media Stream object 
> has CS codec parameters as an attribute. This is indeed 
> questionable. I seem to remember somebody wanting this at 
> some stage in the past. From my point of view, I don't think 
> this information is needed by the SRS - it is historic 
> information, nothing to do with the media actually sent to 
> the SRS, and of no use to the SRS, in my opinion.
> >
> > If people do think there is a reason for providing this 
> information to the SRS, I don't think I would favour approach 
> 1) above. The SDP could potentially contain all sorts of 
> information other than codecs (codecs are only a small part, 
> and the SDP will contain information like IP addresses, 
> ports, security keys!!!, transport, non-recorded media 
> descriptions (e.g., MSRP channel, BFCP channel), format 
> parameters, SDP capability negotiation attributes, etc..
> >
> > Moreover, the offerer and answerer might have agreed 
> several codecs in the SDP, so you need to look at RTP to see 
> which codec is actually used. This can change on the fly.
> >
> > Finally, although the SRS's SIP/SDP stack will surely have 
> and SDP parser, the XML metadata is intended for passing to 
> an application. Requiring that application to contain an SDP 
> parser is, I think, unreasonable.
> >
> > So I have doubts as to whether it is really feasible to 
> provide CS codec information in metadata to the SRS in a 
> meaningful way, whether this be using approach 1) or approach 
> 2), but I particularly dislike approach 1).
> >
> > John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 17 Mar 2011 12:36:21 +0530

Hi Leon / All,

See inline for my comments

> Sent: Wednesday, March 16, 2011 9:16 PM
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: [email-masked]
> Subject: Re: [siprec] CS Codec Parameter in stream XML element [was
RE:
> I agree with points below that passing actual CS SDP to SRS is a not
> good idea from security and layers separation point of view.
> Today's SRS implementations(at least that I know about) do not keep
> original codec information in the database for later retrieval. I am
> trying to think about use cases why SRS can be interested in one, and
> except troubleshooting it is not very relevant.
> 
> The main assumption is that SRC inspected CS SDP and extracted all
> relevant information like ip addresses, media line labels and infos
and
> reported it to SRS via metadata.

Are you still suggesting here that we pass across some of the parameters
of CS SDP that you mentioned above to SRS via metadata ? Are there any
applications at SRS which may require this information ?

I vaguely remember during IETF 79 presentation that some folks (mainly
from video perspective) were asking for part of information related to
CS SDP to be passed in metadata. But not too sure about the use cases
for the same. 
I would request people on the mailer list to speak up if there are any
use cases.

IMO if there is only some specific SRS applications that need this, it's
better to pass it as extension data rather than having it as attribute
of MS block in the metadata.

Regards,
Ram

> 
> The main reason as I see if we want to be able to report CS SDP via
> metadata is for the case where SRS wants to sniff RS RTP packets
> directly and not by forking from SRC but it is out of scope.
> 
> Leon
> 
> Behalf Of Paul Kyzivat
> Subject: Re: [siprec] CS Codec Parameter in stream XML element [was
RE:
> cut at the metadata model. Putting them there was just speculation on
> my part, and doesn't imply any actual need known to me.
> 
> > If people do think there is a reason for providing this information
> to the SRS, I don't think I would favour approach 1) above. The SDP
> could potentially contain all sorts of information other than codecs
> (codecs are only a small part, and the SDP will contain information
> like IP addresses, ports, security keys!!!, transport, non-recorded
> media descriptions (e.g., MSRP channel, BFCP channel), format
> > Moreover, the offerer and answerer might have agreed several codecs
> in the SDP, so you need to look at RTP to see which codec is actually
> used. This can change on the fly.
> >
> > So I have doubts as to whether it is really feasible to provide CS
> codec information in metadata to the SRS in a meaningful way, whether
> this be using approach 1) or approach 2), but I particularly dislike
> approach 1).
> >
> > John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Thu, 17 Mar 2011 09:12:31 +0200

Hi

I agree that if SRS need something from SDP it will be better to pass it via metadata extensions. I did some additional checks and currently there is no such requirement from SRS point of view.
Regarding video, there was requirement to report video session even if it is not recorded.  And if it is recorded then all relevant information will be reported via RS SDP such as positions, sizes etc.

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 9:06 AM
To: Leon Portman; Paul Kyzivat (pkyzivat); Elwell, John
Cc: [email-masked]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

Hi Leon / All,

and
> reported it to SRS via metadata.

Are you still suggesting here that we pass across some of the parameters of CS SDP that you mentioned above to SRS via metadata ? Are there any applications at SRS which may require this information ?

I vaguely remember during IETF 79 presentation that some folks (mainly from video perspective) were asking for part of information related to CS SDP to be passed in metadata. But not too sure about the use cases for the same. 
I would request people on the mailer list to speak up if there are any use cases.

IMO if there is only some specific SRS applications that need this, it's better to pass it as extension data rather than having it as attribute of MS block in the metadata.

Regards,
Ram

---

From: Leon Portman <[email-masked]>
Date: Thu, 17 Mar 2011 09:12:48 +0200

Yes, I think we don't need it

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2011 7:29 PM
To: Leon Portman; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

Leon,

> Subject: RE: [siprec] CS Codec Parameter in stream XML element [was 
> RE: Review Request for draft-ram-siprec-metadata-format-01]
> 
> and reported it to SRS via metadata.

John (as individual)

> RE: Review Request for draft-ram-siprec-metadata-format-01]
> 
> I believe the codec parameters on the MS have been there since my 
> first cut at the metadata model. Putting them there was just 
> speculation on my part, and doesn't imply any actual need known to me.
> 
> metadata model seems to indicate that the Media Stream object has CS 
> codec parameters as an attribute. This is indeed questionable. I seem 
> to remember somebody wanting this at some stage in the past. From my 
> point of view, I don't think this information is needed by the SRS - 
> it is historic information, nothing to do with the media actually sent 
> to the SRS, and of no use to the SRS, in my opinion.
> >
> 1) above. The SDP could potentially contain all sorts of information 
> other than codecs (codecs are only a small part, and the SDP will 
> contain information like IP addresses, ports, security keys!!!, 
> transport, non-recorded media descriptions (e.g., MSRP channel, BFCP 
> channel), format parameters, SDP capability negotiation attributes, 
> etc..
> >
> several codecs in the SDP, so you need to look at RTP to see which 
> codec is actually used. This can change on the fly.
> >
> and SDP parser, the XML metadata is intended for passing to an 
> application. Requiring that application to contain an SDP parser is, I 
> think, unreasonable.
> >
> provide CS codec information in metadata to the SRS in a meaningful 
> way, whether this be using approach 1) or approach 2), but I 
> particularly dislike approach 1).
> >
> > John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 17 Mar 2011 12:55:44 +0530

Inline 

> Sent: Thursday, March 17, 2011 12:43 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
> Cc: [email-masked]
RE:
> I agree that if SRS need something from SDP it will be better to pass
> it via metadata extensions. I did some additional checks and currently
> there is no such requirement from SRS point of view.
> Regarding video, there was requirement to report video session even if
> it is not recorded.  And if it is recorded then all relevant
> information will be reported via RS SDP such as positions, sizes etc.

For cases where Video is not recorded, there are two possibilities:
1) Video is offered by SRC in RS SDP to SRS but SRS choose to reject
video. In this case SRC can still continue to send updates via RS SDP to
SRS. 

2) SRC may not have capability to record video and may not offer video
to SRS in RS SDP.  In this case also we can send a offer (m=0) from SRC
to SRS having video information.

 My question here is - what information do we see a need to report ? Is
it just the information that video is part of CS or more than that ?

Ram

RE:
> Are you still suggesting here that we pass across some of the
> parameters of CS SDP that you mentioned above to SRS via metadata ?
Are
> there any applications at SRS which may require this information ?
> 
> IMO if there is only some specific SRS applications that need this,
> it's better to pass it as extension data rather than having it as
> attribute of MS block in the metadata.
> 
> 
> Regards,
> Ram
> 
> >
> first
whether
> using
metadata
> > > If people do think there is a reason for providing this
information

---

From: Leon Portman <[email-masked]>
Date: Thu, 17 Mar 2011 09:36:23 +0200

Regarding information, most basic one is when video started and ended.

What about the configuration where SRC knows about video (because it is inside CS SIP session) but is not able to fork video. Is it still should offer video m-line?

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 9:26 AM
To: Leon Portman; Paul Kyzivat (pkyzivat); Elwell, John
Cc: [email-masked]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

Inline 

For cases where Video is not recorded, there are two possibilities:
1) Video is offered by SRC in RS SDP to SRS but SRS choose to reject video. In this case SRC can still continue to send updates via RS SDP to SRS. 

2) SRC may not have capability to record video and may not offer video to SRS in RS SDP.  In this case also we can send a offer (m=0) from SRC to SRS having video information.

 My question here is - what information do we see a need to report ? Is it just the information that video is part of CS or more than that ?

Ram

Are
whether
metadata
information

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 17 Mar 2011 13:10:27 +0530

Inline

> Sent: Thursday, March 17, 2011 1:06 PM
RE:
> What about the configuration where SRC knows about video (because it
is
> inside CS SIP session) but is not able to fork video. Is it still
> should offer video m-line?

As I mentioned in  point 2 below I think SRC can still offer a
m-line(for video in RS SDP) with m=0 and have video information. 
Do you see any issues with this approach ?

The other option could be to carry in metadata.
Ram

RE:
> video. In this case SRC can still continue to send updates via RS SDP
> to SRS.
> 
> > > >> assumption does not seems to be working for all scenarios. So
we
> > > need
> > > >> required to maintain the metadata in SRS even though media
(RTP)
> > is
> > > historic information, nothing to do with the media actually sent
to

---

From: Leon Portman <[email-masked]>
Date: Thu, 17 Mar 2011 09:45:09 +0200

Sorry, I missed the m=0 part.

The question is then what if as in mixed voice session, where SRC need to describe in metadata what is actually mixed in RS voice media line, we will have something similar for video, where multiple video streams are mixed together (like grid for example)?
So we still will have metadata describing these sessions, correct?

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 9:40 AM
To: Leon Portman; Paul Kyzivat (pkyzivat); Elwell, John; [email-masked]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

Inline

is
> should offer video m-line?

As I mentioned in  point 2 below I think SRC can still offer a m-line(for video in RS SDP) with m=0 and have video information. 
Do you see any issues with this approach ?

we
(RTP)
to

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 17 Mar 2011 14:08:40 +0530

> Sent: Thursday, March 17, 2011 1:15 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John;
> [email-masked]
RE:
> The question is then what if as in mixed voice session, where SRC need
> to describe in metadata what is actually mixed in RS voice media line,
> we will have something similar for video, where multiple video streams
> are mixed together (like grid for example)?

Yes Leon. The metadata will have information about participants and will
also point to the video m-line of RS SDP (through label attribute). We
will add use cases for this (audio+video in CS and only audio recorded
in RS) in the next revision of the format document.

Ram

RE:
> As I mentioned in  point 2 below I think SRC can still offer a m-
> line(for video in RS SDP) with m=0 and have video information.
> > > Regarding video, there was requirement to report video session
even
> > if
> > > > original codec information in the database for later retrieval.
I
> > am
> > > > trying to think about use cases why SRS can be interested in
one,
> > > from video perspective) were asking for part of information
related
> > > > cut at the metadata model. Putting them there was just
> speculation
> > on
> that
> > RS
> > > > >> draft does not have codec param in stream metadata element.
> But
> > > the
> > > > >> used in CS? RS may be transcoded/transrated and lost the
> actual
> > > > media
> > > > >> information when it reaches SRS but the question is whether
it
> > > > >> some new optional XML element. This approach is
> straightforward
> > > and
> from
> > > SRC
> > > > >> to SRS and create the new XML element for them. This is
simple
> > to
> > > > >> implement as only portion of the SDP is passed across but
> *may*
> > > have
> > > > >> scalability issue.
> > > > >>
> > > > remember somebody wanting this at some stage in the past. From
my
> > > point
> > > > of view, I don't think this information is needed by the SRS -
it
> > > > > So I have doubts as to whether it is really feasible to
provide
> > CS

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Mar 2011 11:13:40 +0100

I think in these sort of situations it would be better to report the non-recorded video stream in XML metadata. If the SRC uses an m-line with port=0 to indicate start of an unrecordable video stream, I don't see how the SRC can report the end of that unrecordable video stream in SDP. XML seems a better option.

Let me make a proposal. For each Media Stream in XML, attributes should indicate:
- The type of medium (audio, video,...).
- The content type of the medium (c.f., RFC 4796) if applicable, e.g., slides, speaker...
- The SDP label for that medium (absent if the SRC does not offer it for recording).

Yes, I know the first two items would be duplication of SDP (in cases where the medium is offered for recording), but these two items would be particularly useful in cases where the medium is not offered for recording and therefore not in the SDP.

John (as individual)

> Sent: 17 March 2011 07:36
> What about the configuration where SRC knows about video 
> (because it is inside CS SIP session) but is not able to fork 
> video. Is it still should offer video m-line?
> 
> Leon
> 
> 1) Video is offered by SRC in RS SDP to SRS but SRS choose to 
> reject video. In this case SRC can still continue to send 
> updates via RS SDP to SRS. 
> 
> 2) SRC may not have capability to record video and may not 
> offer video to SRS in RS SDP.  In this case also we can send 
> a offer (m=0) from SRC to SRS having video information.
> 
>  My question here is - what information do we see a need to 
> report ? Is it just the information that video is part of CS 
> or more than that ?
> 
> Ram
> 
> > 
> > Leon
> > 
> element [was
> extracted all 
> related to 
> element [was
> > > >> assumption does not seems to be working for all 
> scenarios. So we
> > > need
> > > >> required to maintain the metadata in SRS even though 
> media (RTP)
> > is
> > > >> changed to new format ?
> > > >>
> > > historic information, nothing to do with the media 
> actually sent to
> > the
> provide CS

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 17 Mar 2011 16:42:50 +0530

John,

I agree that your proposal will work. I'm trying to find few other
alternatives without duplication of data between SDP and XML.

Approach 1: start-time and stop-time are optional XML element in stream.
In the mentioned scenario, let stream element contains only label
element and no start & stop time elements which indicates that stream is
never activated within the given session. 

XML format for start-time & stop-time:
         <xs:element name="start-time" type="xs:dateTime"
                minOccurs="0"/>
         <xs:element name="stop-time" type="xs:dateTime"
                minOccurs="0"/> 

Approach 2: Add both start-time and stop-time in the same stream which
indicates that stream is not started.

I prefer approach 1 which will solve the issue without duplication of
metadata in XML. Please let me know your opinion here.

Leon,

Please read inline.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, March 17, 2011 3:44 PM
To: Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] CS Codec Parameter in stream XML element [was RE:
Review Request for draft-ram-siprec-metadata-format-01]

I think in these sort of situations it would be better to report the
non-recorded video stream in XML metadata. If the SRC uses an m-line
with port=0 to indicate start of an unrecordable video stream, I don't
see how the SRC can report the end of that unrecordable video stream in
SDP. XML seems a better option.

Let me make a proposal. For each Media Stream in XML, attributes should
indicate:
- The type of medium (audio, video,...).
- The content type of the medium (c.f., RFC 4796) if applicable, e.g.,
slides, speaker...
- The SDP label for that medium (absent if the SRC does not offer it for
recording).

Yes, I know the first two items would be duplication of SDP (in cases
where the medium is offered for recording), but these two items would be
particularly useful in cases where the medium is not offered for
recording and therefore not in the SDP.

John (as individual)

> Regarding information, most basic one is when video started and ended.

<Partha> In the mentioned scenario, video is never started. Hope
Approach 1 serve your purpose </Partha>
> is inside CS SIP session) but is not able to fork video. Is it still 
<Partha> It is upto SRC to decide whether to indicate the m-line in RS
or not. The decision may be based on the SRC level support for video
recording, policy in the SRC to record video or not. IMO, it is
implementation specific and SIPREC solution SHOULD be flexible for all
kinds of SRC </partha>

> to SRS in RS SDP.  In this case also we can send a offer (m=0) from 
> SRC to SRS having video information.
> 
>  My question here is - what information do we see a need to report ? 
> Is it just the information that video is part of CS or more than that 
> ?
> 
> Ram
> 
> > 
> > Leon
> >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Mar 2011 12:37:58 +0100

Partha,

Approach 1 is fine, as far as representation of start/stop times is concerned.

So if I understand correctly the unrecordable / unrecorded stream appears in both XML metadata and SDP, with XML containing the start/stop times and SDP containing the media type/content. So an SDP media description would exist for:
- recorded streams;
- streams offered by the SRC for recording but rejected by the SRS;
- streams not offered by the SRC (unrecordable streams).

The first one is fine and the second one we can't really avoid. I am rather uncomfortable about the third one, where there is an SDP media description describing a stream that does not exist in the RS. It clutters the SDP unnecessarily and I feel it is worthwhile having some minimal duplication (in XML and SDP) for recorded streams to avoid this addition to SDP for unrecordable streams.

I also feel that media type and content description are logically part of the metadata and should appear in XML, because this is information the application needs. SDP, on the other hand, is something the media engine needs in order to receive media correctly and pass the received media in some form up to the application for storage.

John (as individual)

> Sent: 17 March 2011 11:13
> To: Elwell, John; Leon Portman; Ram Mohan R (rmohanr); Paul
> Kyzivat (pkyzivat)
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf
> Of Elwell, John
> element [was RE:
> (because it
> offer video
> report ?
> [mailto:[email-masked]] On
> > > > Behalf Of Leon Portman
> > > > trying to think about use cases why SRS can be
> interested in one,
> > and
> > > > >> <Partha>  It is the assumption done during metadata
> format that
> > RS
> > > > >> draft does not have codec param in stream metadata
> element. But
> > > the
> > > > >> used in CS? RS may be transcoded/transrated and lost
> the actual
> > > > media
> > > > >> 2) Identify the list of codec parameters *MUST*  be
> passed from
> > > SRC
> > > > >> implement as only portion of the SDP is passed
> across but *may*
> > > have
> > > > >> scalability issue.
> > > > >>
> > > > remember somebody wanting this at some stage in the
> past. From my
> > > point

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 17 Mar 2011 18:00:11 +0530

John,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 5:08 PM
To: Parthasarathi R (partr); Leon Portman; Ram Mohan R (rmohanr); Paul
Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE:
Review Request for draft-ram-siprec-metadata-format-01]

Partha,

Approach 1 is fine, as far as representation of start/stop times is
concerned.

So if I understand correctly the unrecordable / unrecorded stream
appears in both XML metadata and SDP, with XML containing the start/stop
times and SDP containing the media type/content. So an SDP media
description would exist for:
- recorded streams;
- streams offered by the SRC for recording but rejected by the SRS;
- streams not offered by the SRC (unrecordable streams).

The first one is fine and the second one we can't really avoid. I am
rather uncomfortable about the third one, where there is an SDP media
description describing a stream that does not exist in the RS. It
clutters the SDP unnecessarily and I feel it is worthwhile having some
minimal duplication (in XML and SDP) for recorded streams to avoid this
addition to SDP for unrecordable streams.

<Partha> I know of real audio end points (IP phones) which starts with
"m" line having port 0 during the dialog creation stage and then add the
appropriate port in the mid-dialog. Leon may be talking about one such
video phone. AFAIK, "m" line having port 0 in the offer is not violating
any of the RFC. So, those endpoint which creates CS with "m" line having
port 0 during dialog creation shall map its RS dialog creation SDP with
port 0 for "m" line  as well. 

It is upto SRS to record/store those metadata or not. Please let me know
in case I'm missing something. </Partha>

I also feel that media type and content description are logically part
of the metadata and should appear in XML, because this is information
the application needs. 

<Partha> IMO, the minimum required codec parameters for metadata in XML
will easily grow till little bit less than complete SDP. For example, it
is not required to pass crypto key or some other parameters. Some of the
possible to be passed across are:

1)Direction attribute - To find the original direction attribute of CS
(I explained the way to retrieve from RS SDP)

2)Codec - Finding CS codec in Transcoding scenario

3)ptime - Finding CS packetization time in Transrating scenario

4)content -  To find the exact content description attribute

5)media type -  Exact media type of CS.

6)fmtp - This attribute plays vital role in video endpoints CS

7)bandwidth - To find the exact bandwidth used in Video scenario. Some
QOS parameter may be used.

There should be a way to extend in case new attribute has to be added in
XML which may fall under extensiondata itself. It was the reason that I
proposed to pass SDP within XML earlier in codec parameter has to be
passed in XML. As Leon mentioned, it is possible to pass the whole SDP
through XML using content element of XML which will be seen as SIPREC
extensiondata in CS.

In case you foresee that this parameter has to be discussed in detail to
find the selective SDP attribute passing between SRC and SRS, I'll add
in the open item for metadata format draft, Let us discuss in IETF-80
meeting. 
</partha>

SDP, on the other hand, is something the media engine needs in order to
receive media correctly and pass the received media in some form up to
the application for storage.

John (as individual)

> To: Elwell, John; Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat 
> (pkyzivat)
> Cc: [email-masked]
> element and no start & stop time elements which indicates that stream 
> is never activated within the given session.
>

> [mailto:[email-masked]] On Behalf Of Elwell, John

> see how the SRC can report the end of that unrecordable video stream 
> in SDP. XML seems a better option.
>

> where the medium is offered for recording), but these two items would 
> be particularly useful in cases where the medium is not offered for

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Mar 2011 15:02:43 +0100

> Sent: 17 March 2011 12:30
[JRE] I agree it is valid SDP - I am just uncomfortable with the SRC offering something that it doesn't even intend to use in the future. Normally a port 0 m-line in the initial offer implies a medium that might be turned on later, but I may be wrong.

> 2)Codec - Finding CS codec in Transcoding scenario
[JRE] I don't see why this is relevant - I don't think we have a requirement. Also, even if CS codec information is made available to the SRS, this is only the CS codec as seen by the SRC, and perhaps other codecs were used upstream that are not visible to the SRC. For example, Remote party A transmits audio using G.723 to a mixer, and party B transmits audio using G.711 to the mixer. The mixer then transmits audio using OPUS super-wideband to party C, and the SRC is located at C's UA (or on the path between the mixer and C's UA). The SRC uses G.722, say, to send audio to the SRS and reports that the CS used OPUS super-wideband. What can the SRS learn from this? The audio quality will be constrained by the worst link, i.e., G.723 when A is talking.

> 3)ptime - Finding CS packetization time in Transrating scenario
[JRE] I don't think CS ptime is relevant. Also pTime doesn't give actual packetization time, which can vary during the session..

> 6)fmtp - This attribute plays vital role in video endpoints CS
[JRE] Again I don't see the relevance of particular formats used on the CS. By the time media reaches the SRS, it has been reformatted in accordance with fmtp parameters for the RS (and in some cases mixed with other streams at the SRC before sending to the SRS) so I really don't see how knowledge of the fmtp parameters used on the CS can help the SRC (with analysing the media, say).

> QOS parameter may be used.
[JRE] Again I don't see the relevance.

> through XML using content element of XML which will be seen as SIPREC
[JRE] I agree with extensibility, and if there are future requirements to send any of this information in XML, we could do that. But I fail to see any motivation for defining these now. Also, as explained before, I am uncomfortable about encapsulating CS SDP within XML metadata.

John (as individual)

> > - The SDP label for that medium (absent if the SRC does not
> offer it
> > for recording).
> >
> > > > > >> SDP may be used as Codec params for stream. Please
> note that
> > > > format

---

From: Leon Portman <[email-masked]>
Date: Thu, 17 Mar 2011 16:17:27 +0200

I completely agree with John's points below. What is important is RS codec info and not CS.

Leon
-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Thursday, March 17, 2011 4:03 PM
To: Parthasarathi R (partr); Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

> appears in both XML metadata and SDP, with XML containing the
> start/stop times and SDP containing the media type/content. So an SDP
> media description would exist for:
> - recorded streams;
> minimal duplication (in XML and SDP) for recorded streams to avoid
> this addition to SDP for unrecordable streams.
>
> "m" line having port 0 during the dialog creation stage and then add
> the appropriate port in the mid-dialog. Leon may be talking about one
> such video phone. AFAIK, "m" line having port 0 in the offer is not
> violating any of the RFC. So, those endpoint which creates CS with "m"
> line having
> port 0 during dialog creation shall map its RS dialog creation SDP
> with port 0 for "m" line  as well.
>
> It is upto SRS to record/store those metadata or not. Please let me
> know in case I'm missing something. </Partha>

John (as individual)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 17 Mar 2011 13:30:56 -0700

Please see single comment inline.

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Tuesday, March 15, 2011 6:56 AM
> One particular case I believe this covers is the simple 2-party call,
where there are two media
> streams, one from A to B and the other from B to A. The SRC could mix
the two together into a single
> stream to the SRS. Certainly useful for bandwidth constrained
environments, but not so friendly
> towards speech analytics.
> 
> John (as individual)

Once the stream is mixed meaning all packets have the same SSRC and
CSRC, I think there is no point in trying to represent it as anything
other than a single stream. If the metadata can indicate all the
individual participants in the mixed stream, that would be great, but I
doubt you will get this in all cases.
If it is a single RTP stream with multiple identifiable media streams
muxed together, then it would be good to model as independent streams.
In this case the different streams could be uniquely identified by a
SSRC or CSRC. 

Cheers,
Charles

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 18 Mar 2011 12:25:03 +0530

Charles,

Please read inline 

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Charles Eckel (eckelcu)
Sent: Friday, March 18, 2011 2:01 AM
To: Elwell, John; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Review Request for
draft-ram-siprec-metadata-format-01

Behalf Of Elwell, John

> > >> single RS media stream. In this case, the several Media Stream 
> > >> objects would all point to the same SDP label, I guess. This then

> > >> brings into question the mode element (type
> > >> Stream objects (stream elements) point to the same label would 
> > >> imply there has been mixing, so the mode element seems to be 
> > >> redundant.
> > >>
> > >> My thinking is that situation is modeled as a single media stream

> > >> with multiple participants.
> > draft. It does indeed seem to say that it represents an RS media 
> > stream:
> > what we end up with is that if streams are mixed (whether this be at

> > an MCU, say, or just part of the SRC in order to send the streams to

> > the SRS), the net result will be modelling as a single stream in the

> > metadata. Is this a common understanding?
> >

Once the stream is mixed meaning all packets have the same SSRC and
CSRC, I think there is no point in trying to represent it as anything
other than a single stream. 
<Partha> I'm of the same opinion </Partha>

If the metadata can indicate all the individual participants in the
mixed stream, that would be great, but I doubt you will get this in all
cases. 
<Partha> agreed </Partha>

<Partha> I wish to get more clarity for this scenario. In the mentioned
scenario, whether RFC 5576 ssrc attribute or some other attribute is
used in CS SDP to indicate RTP muxing in m-line. If so, the same
attribute shall be extended for RS session as well. There is no need to
push the information to metadata XML. In case there is no indication of
multiple stream in CS, it is possible that SRC may not able to indicate
explicitly in RS signaling but RTP muxed passed to SRS with different
SSRC or CSRC. </Partha> 

Cheers,
Charles

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Mar 2011 09:10:15 +0100

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 17 March 2011 20:31
[JRE] Yes, that might be a valid case (although I am not sure that CSRC would be appropriate). Actually, this is something we haven't considered at all - I will start a separate thread.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 18 Mar 2011 16:51:25 +0530

Till now, we didn't hear for any use case which requires CS SDP
parameters. IMO, We will wait till 23rd Mar to identify any CS SDP
parameter is required to be passed across in metadata. Pls mention in
case more time is required to close CS SDP parameter issue. 

In case there is no use case identified till that time, we will update
Sec 4.5.1 3rd Bullet of draft-ram-siprec-metadata as "Codec params -
represents codec parameters of RS media" in the next revision. Pls
suggest in case text has to be modified.

Apart from this, there is another issue associated in this mail thread.
John mentioned about some of the RS SDP attributes has to be duplicated
in metadata XML namely Content (RFC 4796), Mediatype (audio/video). Paul
wishes to analysis more on direction attribute to passed in XML. I doubt
that Charles is looking for RTP MUX information (RFC 5576) in XML
instead of SDP based on the another mail thread "Multiplexing different
participants' streams on the same port". I'm of the opinion that it is
better to be passed in RS SDP rather than in metadata XML because of the
following reasons: 

1) It avoids duplication of data in the single message
2) All SDP extended attributes (like fmtp for video, ssrc for RTP
muxing, content for exact content type) will be reused in Recording
session without any change
3) Also provides the way to extend any new attributes comes in SDP
attribute without impact metadata general format. 
4) In case duplication of attribute is allowed, creating the proper
demarcation whether the specific attribute falls under Metadata XML or
RS SDP will not be clear.

I wish to discuss more on this front in this mail thread.

Thanks
Partha

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 7:47 PM
To: Elwell, John; Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul
Kyzivat (pkyzivat)
Cc: [email-masked]

I completely agree with John's points below. What is important is RS
codec info and not CS.

Leon
-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Thursday, March 17, 2011 4:03 PM
To: Parthasarathi R (partr); Leon Portman; Ram Mohan R (rmohanr); Paul
Kyzivat (pkyzivat)
Cc: [email-masked]

> know in case I'm missing something. </Partha>
[JRE] I agree it is valid SDP - I am just uncomfortable with the SRC
offering something that it doesn't even intend to use in the future.
Normally a port 0 m-line in the initial offer implies a medium that
might be turned on later, but I may be wrong.

> <Partha> IMO, the minimum required codec parameters for metadata in 
> XML will easily grow till little bit less than complete SDP. For 
> example, it is not required to pass crypto key or some other 
> parameters.
> Some of the

> 2)Codec - Finding CS codec in Transcoding scenario
[JRE] I don't see why this is relevant - I don't think we have a
requirement. Also, even if CS codec information is made available to the
SRS, this is only the CS codec as seen by the SRC, and perhaps other
codecs were used upstream that are not visible to the SRC. For example,
Remote party A transmits audio using G.723 to a mixer, and party B
transmits audio using G.711 to the mixer. The mixer then transmits audio
using OPUS super-wideband to party C, and the SRC is located at C's UA
(or on the path between the mixer and C's UA). The SRC uses G.722, say,
to send audio to the SRS and reports that the CS used OPUS
super-wideband. What can the SRS learn from this? The audio quality will
be constrained by the worst link, i.e., G.723 when A is talking.

> 3)ptime - Finding CS packetization time in Transrating scenario
[JRE] I don't think CS ptime is relevant. Also pTime doesn't give actual
packetization time, which can vary during the session..

> 6)fmtp - This attribute plays vital role in video endpoints CS
[JRE] Again I don't see the relevance of particular formats used on the
CS. By the time media reaches the SRS, it has been reformatted in
accordance with fmtp parameters for the RS (and in some cases mixed with
other streams at the SRC before sending to the SRS) so I really don't
see how knowledge of the fmtp parameters used on the CS can help the SRC
(with analysing the media, say).

>
> There should be a way to extend in case new attribute has to be added 
> in XML which may fall under extensiondata itself. It was the reason 
> that I proposed to pass SDP within XML earlier in codec parameter has 
> to be passed in XML. As Leon mentioned, it is possible to pass the 
> whole SDP through XML using content element of XML which will be seen 
> as SIPREC extensiondata in CS.
[JRE] I agree with extensibility, and if there are future requirements
to send any of this information in XML, we could do that. But I fail to
see any motivation for defining these now. Also, as explained before, I
am uncomfortable about encapsulating CS SDP within XML metadata.

John (as individual)

>
> In case you foresee that this parameter has to be discussed in detail 
> to find the selective SDP attribute passing between SRC and SRS, I'll 
> add in the open item for metadata format draft, Let us discuss in 
> IETF-80 meeting.
> </partha>
>
> SDP, on the other hand, is something the media engine needs in order 
> to receive media correctly and pass the received media in some form up

> to the application for storage.
>
> John (as individual)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Mar 2011 08:30:52 -0400

ISTM the issue with a mixed stream with separate SSRC values is 
correlating the SSRC values to the signaling identities (URIs) of the 
participants. AFAIK there are currently no specifications for doing that.

	Thanks,
	Paul

On 3/18/2011 2:55 AM, Parthasarathi R (partr) wrote:
> <Partha>  I'm of the same opinion</Partha>
>
> <Partha>  agreed</Partha>
> SSRC or CSRC.</Partha>