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

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

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