Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ?

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 17 Jan 2011 14:17:25 +0530

Paul/John,

IMO, the metadata shall contain rejected or non-recorded m-line
information and recording session SDP have to carry non-recorded m-line
information.

I have another alternative approach in mind to solve this issue in
Metadata. In case of media stream is not active in CS, Recording session
has to carry non-active m-line (port 0 or a=inactive) information with
label attribute (RFC 4574) then the external document shall refer to
m-line using label attribute. SRS shall understand about non-active
stream by the analysis of SDP metadata. Here, the external document has
no need to aware of the stream state.

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat (pkyzivat)
Sent: Tuesday, December 21, 2010 8:47 PM
To: [email-masked]
Subject: Re: [siprec] SIPREC Metadata model: Is it required to model
streams that are not recorded ?

On 12/21/2010 8:47 AM, Elwell, John wrote:
> If additional media streams are offered to the SRS but declined,
clearly the SRS knows of the existence of those streams. So I think the
point behind the question is whether the SRS needs to know the
subsequent fate of those additional streams in the CS, e.g., if they are
held, resumed, disabled, etc..

One possibility is for the SRC to continue offering them even though
they have been previously declined. However there is some cost to doing
this, in maintaining media ports, possibly using ICE, etc.

An alternative might be to send metadata about these hypothetical
streams without any cross reference to the SDP. But that will require
being careful that sufficient info is in the metadata without the SDP in
the RS.

	Thanks,
	Paul

> John
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
>> Sent: 21 December 2010 13:29
>> To: [email-masked]
>> Subject: [siprec] SIPREC Metadata model: Is it required to model 
>> streams that are not recorded ?
>>
>> Hi all,
>>
>>
>>
>> During the SIPREC IETF dec 16th 2010 virtual interim we discussed in 
>> brief about the need to model stream that are not recorded ( there 
>> were people like Leon who have suggested on having this in the 
>> model).
>>
>>
>>
>> e.g. SRC offered certain media types (like audio, video) but SRS 
>> choose to accept only subset of them ( say only audio).
>>
>> The other possibility could be a CS might have multiple media 
>> types(audio, video) but an SRC may record only one type (say
>> audio) due to its limitations. However an SRS might want to know all 
>> the streams of CS.
>>
>>
>>
>> If its required  to  model these information in metadata, how do we 
>> do them ?
>>
>>
>>
>> I would like to get some thoughts/ inputs from interested people in 
>> the mailing list on whether there is a value add / need  in storing 
>> information about streams that are not recorded.
>>
>>
>>
>> Regards,
>>
>> Ram
>>
>>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jan 2011 11:05:33 -0500

> no need to aware of the stream state.

This approach seems workable to me.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 17 Jan 2011 08:16:02 -0800

I think using port 0 would be a better choice than a=inactive since both
sides will not need to reserve a port number if it is set to zero, and
zero clearly indicates that the stream is no longer used.

Regards,
Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Monday, January 17, 2011 11:06 AM
> To: Parthasarathi R (partr)
> Cc: [email-masked]
> > being careful that sufficient info is in the metadata without the
SDP
> in

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Jan 2011 17:33:01 +0100

Partha,

Just to be clear what you are proposing. I imagine that in the RS SDP at the start of the CS, the SRC supplies an RFC 4574 label for each offered medium. Then, even if a particular medium is rejected by the SRS, updates to metadata can reference that label to indicate future changes to the corresponding medium on the CS. Correct?

John

> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 17 January 2011 08:47
> To: Paul Kyzivat (pkyzivat); [email-masked]
> Subject: Re: [siprec] SIPREC Metadata model: Is it required 
> to model streams that are not recorded ?
> 
> Paul/John,
> 
> [mailto:[email-masked]] On Behalf

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jan 2011 13:31:06 -0500

> Just to be clear what you are proposing. I imagine that in the RS SDP at the start of the CS, the SRC supplies an RFC 4574 label for each offered medium. Then, even if a particular medium is reject…

More than that I think. I'm thinking that as the media stream changes in 
the CS, that there will need to be another offer on the RS, updating the 
(rejected) media stream, communicating information such as codec, etc.

Maybe that isn't necessary - maybe once the label has been associated 
with the stream everything else of interest can be communicated as 
metadata. I guess that remains to determine. It would probably be better 
if it worked this way. If there is need to offer the stream again, even 
if it isn't to be recorded, then it requires assigning a port just in 
case it *might* be accepted.

Or maybe we are talking about offering a media stream in the RS with 
port zero from the start, just so we can attach a label to it.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Tue, 18 Jan 2011 08:46:15 +0200

Paul, Partha

I like the idea to have port=0 and media inactive for rejected media streams in order to be able for SRS mid-call start to record these streams as well.

Regarding rejected/not recorded media events, I agree that we need to keep an option for reporting it via metadata events. It will provide most robust mechanism

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, January 17, 2011 8:31 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ?

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 18 Jan 2011 19:08:35 +0530

John/ Paul,

Please see inline for some comments 

> Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Tuesday, January 18, 2011 12:01 AM
> To: Elwell, John
> Cc: [email-masked]
> > Just to be clear what you are proposing. I imagine that in the RS
SDP
> at the start of the CS, the SRC supplies an RFC 4574 label for each
> offered medium. Then, even if a particular medium is rejected by the
> SRS, updates to metadata can reference that label to indicate future
> changes to the corresponding medium on the CS. Correct?
> 

My thought for this case is to have a SRC offer a stream (that it can
record) at the start of RS ( with a valid port) and continue to keep
sending updates for that media stream even if the SRS has rejected the
stream at the beginning. From the discussions I had in the last interim
and before, it is my understanding that SRS would like to know the
changes to a media stream even if they are not being recorded after
being offered by SRC. My preference would be send the further updates of
that media stream ( rejected) through m-line instead of metadata and
just having reference to the label in metadata document.
The negative side to it would be the cost in keeping the port open [ for
the rejected media stream].

> port zero from the start, just so we can attach a label to it.

There was another requirement too here if I remember which is for the
SRS to know the streams that are part of CS but which are not offered by
SRC to SRS. This could be possible if SRC does not have the capability
to fork certain media types. In those cases I think we could follow the
above approach you mentioned where in SRC can offer a media stream with
port zero at the start of CS.
After that SRC can keep sending the  updates of the same media stream
through metadata.

Thanks,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jan 2011 09:36:31 -0500

We have to be careful about attaching much significance to m-lines with 
the port set to zero. Often there is an expectation that once the port 
is set to zero, none of the other information has meaning. This is 
especially true when media streams are refused by an answerer that 
doesn't understand. (This has also come up in 
draft-ietf-mmusic-image-attributes, but only tangentially.)

The situation here in the RS is quite controlled - its between a pair of 
UAs that will both be bound by the siprec spec, so we may be able to 
spell out more meaning to rejected streams. But it is something to keep 
in mind and seek some help from mmusic on.

	Thanks,
	Paul