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

["Elwell, John" <[e-mail]>]

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)

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