Re: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]

[Leon Portman <[e-mail]>]

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:[e-mail]]
Sent: Thursday, March 17, 2011 4:03 PM
To: Parthasarathi R (partr); Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [e-mail]
Subject: RE: [siprec] CS Codec Parameter in stream XML element [was RE: Review Request for draft-ram-siprec-metadata-format-01]



> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[e-mail]]
> Sent: 17 March 2011 12:30
> To: Elwell, John; Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat
> (pkyzivat)
> Cc: [e-mail]
> Subject: RE: [siprec] CS Codec Parameter in stream XML element [was
> RE: Review Request for draft-ram-siprec-metadata-format-01]
>
> John,
>
> Please read inline.
>
> Thanks
> Partha
>
> -----Original Message-----
> From: Elwell, John [mailto:[e-mail]]
> Sent: Thursday, March 17, 2011 5:08 PM
> To: Parthasarathi R (partr); Leon Portman; Ram Mohan R (rmohanr); Paul
> Kyzivat (pkyzivat)
> Cc: [e-mail]
> 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>
[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.

>
> 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
[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..

>
> 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
[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).

>
> 7)bandwidth - To find the exact bandwidth used in Video scenario. Some
> QOS parameter may be used.
[JRE] Again I don't see the relevance.

>
> 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)
>
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[e-mail]]
> > Sent: 17 March 2011 11:13
> > To: Elwell, John; Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat
> > (pkyzivat)
> > Cc: [e-mail]
> > Subject: RE: [siprec] CS Codec Parameter in stream XML element [was
> > RE: Review Request for draft-ram-siprec-metadata-format-01]
> >
> > 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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Elwell, John
> > Sent: Thursday, March 17, 2011 3:44 PM
> > To: Leon Portman; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> > Cc: [e-mail]
> > 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)
> >
> > > -----Original Message-----
> > > From: Leon Portman [mailto:[e-mail]]
> > > Sent: 17 March 2011 07:36
> > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
> > > Cc: [e-mail]
> > > Subject: RE: [siprec] CS Codec Parameter in stream XML
> element [was
> > > RE: Review Request for draft-ram-siprec-metadata-format-01]
> > >
> > > 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>
> > >
> > > 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?
> > >
> > <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>
> >
> > > Leon
> > >
> > > -----Original Message-----
> > > From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
> > > Sent: Thursday, March 17, 2011 9:26 AM
> > > To: Leon Portman; Paul Kyzivat (pkyzivat); Elwell, John
> > > Cc: [e-mail]
> > > Subject: RE: [siprec] CS Codec Parameter in stream XML
> element [was
> > > RE: Review Request for draft-ram-siprec-metadata-format-01]
> > >
> > > Inline
> > >
> > > > -----Original Message-----
> > > > From: Leon Portman [mailto:[e-mail]]
> > > > Sent: Thursday, March 17, 2011 12:43 PM
> > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
> > > > Cc: [e-mail]
> > > > Subject: RE: [siprec] CS Codec Parameter in stream XML
> > element [was
> > > RE:
> > > > Review Request for draft-ram-siprec-metadata-format-01]
> > > >
> > > > 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.
> > >
> > > 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
> > >
> > > >
> > > > Leon
> > > >
> > > > -----Original Message-----
> > > > From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
> > > > Sent: Thursday, March 17, 2011 9:06 AM
> > > > To: Leon Portman; Paul Kyzivat (pkyzivat); Elwell, John
> > > > Cc: [e-mail]
> > > > Subject: RE: [siprec] CS Codec Parameter in stream XML
> > element [was
> > > RE:
> > > > Review Request for draft-ram-siprec-metadata-format-01]
> > > >
> > > > Hi Leon / All,
> > > >
> > > > See inline for my comments
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]] On
> > > > > Behalf Of Leon Portman
> > > > > Sent: Wednesday, March 16, 2011 9:16 PM
> > > > > To: Paul Kyzivat (pkyzivat); Elwell, John
> > > > > Cc: [e-mail]
> > > > > 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.
> > > >
> > > > 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
> > > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > [mailto:[e-mail]] On
> > > > > Behalf Of Paul Kyzivat
> > > > > Sent: Wednesday, March 16, 2011 3:33 PM
> > > > > To: Elwell, John
> > > > > Cc: [e-mail]
> > > > > 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.
> > > > >
> > > > > If nobody feels they are necessary, then by all means
> > remove them.
> > > > >
> > > > >         Thanks,
> > > > >         Paul
> > > > >
> > > > > On 3/16/2011 3:34 AM, Elwell, John wrote:
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Parthasarathi R (partr) [mailto:[e-mail]]
> > > > > >> Sent: 16 March 2011 01:25
> > > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat)
> > > > > >> Cc: [e-mail]
> > > > > >> Subject: 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 ?
> > > > > >>
> > > > > >> 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] 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)
> > > > > _______________________________________________
> > > > > siprec mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > > _______________________________________________
> > > > > siprec mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/siprec
> > >
> > _______________________________________________
> > siprec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/siprec
> >
>