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

Paul Kyzivat <pkyzivat@cisco.com> Tue, 18 January 2011 14:33 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: siprec@core3.amsl.com
Delivered-To: siprec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D15F28C119 for <siprec@core3.amsl.com>; Tue, 18 Jan 2011 06:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.489
X-Spam-Level:
X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWY22FYQVUoZ for <siprec@core3.amsl.com>; Tue, 18 Jan 2011 06:33:54 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5FB9928C117 for <siprec@ietf.org>; Tue, 18 Jan 2011 06:33:54 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2011 14:36:31 +0000
Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IEaVgl004590; Tue, 18 Jan 2011 14:36:31 GMT
Message-ID: <4D35A56F.6030500@cisco.com>
Date: Tue, 18 Jan 2011 09:36:31 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com><A444A0F8084434499206E78C106220CA03C59D2F66@MCHP058A.global-ad.net> <4D10C503.9010105@cisco.com><A11921905DA1564D9BCF64A6430A6239042FB87E@XMB-BGL-411.cisco.com><A444A0F8084434499206E78C106220CA05FC70316E@MCHP058A.global-ad.net> <4D348AEA.7040405@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD050247CD@XMB-BGL-417.cisco.com>
In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD050247CD@XMB-BGL-417.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: siprec@ietf.org
Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ?
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jan 2011 14:33:56 -0000

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

On 1/18/2011 8:38 AM, Ram Mohan R (rmohanr) wrote:
> John/ Paul,
>
> Please see inline for some comments
>
>> -----Original Message-----
>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
>> Behalf Of Paul Kyzivat (pkyzivat)
>> Sent: Tuesday, January 18, 2011 12:01 AM
>> To: Elwell, John
>> Cc: siprec@ietf.org
>> Subject: Re: [siprec] SIPREC Metadata model: Is it required to model
>> streams that are not recorded ?
>>
>>
>>
>> On 1/17/2011 11:33 AM, Elwell, John wrote:
>>> 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?
>>
>> 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.
>
> 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].
>
>>
>> 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.
>
> 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
>
>>
>> 	Thanks,
>> 	Paul
>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: siprec-bounces@ietf.org
>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R
>> (partr)
>>>> Sent: 17 January 2011 08:47
>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org
>>>> Subject: Re: [siprec] SIPREC Metadata model: Is it required
>>>> to model streams that are not recorded ?
>>>>
>>>> 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: siprec-bounces@ietf.org
>>>> [mailto:siprec-bounces@ietf.org] On Behalf
>>>> Of Paul Kyzivat (pkyzivat)
>>>> Sent: Tuesday, December 21, 2010 8:47 PM
>>>> To: siprec@ietf.org
>>>> 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: siprec-bounces@ietf.org
>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R
>> (rmohanr)
>>>>>> Sent: 21 December 2010 13:29
>>>>>> To: siprec@ietf.org
>>>>>> 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
>>>>> siprec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>