IETF Logo Mail Archive

Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

"Roni Even" <ron.even.tlv@gmail.com> Tue, 11 November 2014 21:07 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF281ACD0F for <avt@ietfa.amsl.com>; Tue, 11 Nov 2014 13:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANPCzwdsAAI6 for <avt@ietfa.amsl.com>; Tue, 11 Nov 2014 13:06:58 -0800 (PST)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E431ACD25 for <avt@ietf.org>; Tue, 11 Nov 2014 13:06:54 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id ex7so2914261wid.4 for <avt@ietf.org>; Tue, 11 Nov 2014 13:06:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=6nnNFkq7ci52VmJDDp5yoKMbL9YHCNImO+gzwRy0boU=; b=xHJoXHmpWbq9gh0HTdaTfAyA01iw7oO/3uhak09jj4710ufdKL8r3CSdQsh+U+CaY7 DgSmBrKcBR5VCQ6Eq+mAF4Q+tzI8xuYuyU6ysH47haoG+a/lQoh+Uimvux3CeClk9H3x pogy+5AAbpeBSxZYCLvctSmn/IISyNVlDtOl1rbk9fkdmV1BpX63T6O97E0f2VKTg9WP sQ+DcNv70lvE67ycDgThBnVwmGkaQpJyI+Pbj9E8iCRWtWzbsGSdUsJnhQVQCbXbbSNa QqA49g/PYZ5T3V/9qXBYaZ3kaTP9NpPKbk8eKo5/3HNgllyiEToTpaVp4yqaHHHyvnfN /U9A==
X-Received: by 10.194.248.162 with SMTP id yn2mr57569644wjc.16.1415740012999; Tue, 11 Nov 2014 13:06:52 -0800 (PST)
Received: from RoniE (t2001067c037001609c200589080d6a41.wireless.v6.meeting.ietf.org. [2001:67c:370:160:9c20:589:80d:6a41]) by mx.google.com with ESMTPSA id u5sm4311413wjy.39.2014.11.11.13.06.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Nov 2014 13:06:52 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: "'Nermeen Ismail (nermeen)'" <nermeen@cisco.com>, avt@ietf.org
References: <00db01cffc02$d2420570$76c61050$@gmail.com> <D0879525.1FACC%nermeen@cisco.com>
In-Reply-To: <D0879525.1FACC%nermeen@cisco.com>
Date: Tue, 11 Nov 2014 23:06:44 +0200
Message-ID: <01b101cffdf3$68b66d60$3a234820$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01CFFE04.2C4000B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJjUzXM8HBHof07VTvyYjGd/o11gAHc1yqOmyZT9VA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/t8BlCr3nMkCMK86ISanlkfx2jsU
Subject: Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 21:07:03 -0000

Hi Nermeen,

My comment was that this should be discussed in the use case section
(section 5). The proposed  topology should be clear (similar to how a
topology is described in the topologies drafts in term of RTP and RTCP
behavior). Looking at PM-07 it is a very general requirement and is about
security context but what it means depends on the topology in mind.

The topology should be very clear to allow people to offer solutions and to
verify the solution against the topology.  

Roni Even

As individual.

 

 

 

 

From: Nermeen Ismail (nermeen) [mailto:nermeen@cisco.com] 
Sent: 11 November, 2014 10:35 PM
To: Roni Even; avt@ietf.org
Subject: Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

 

PM-07 attempts to capture ,among other things, the sequence number gap
requirement during a switch from one media source to another. In order to
synchronize the SRTP context either the receiver need to be aware of the
source switch and the sequence number associated with the new source need to
be updated or the server needs to shield the receiver from such sequence
number gaps. In either case the receiver will not be perceiving packet
losses during the switch. 

 

Do you think we need to explicitly mention the packet loss issue during a
media source switch or do you think that the synchronization of the SRTP
context capture it albeit in an implicit way?

 

nermeen

 

 

 

From: Roni Even <ron.even.tlv@gmail.com>
Date: Saturday, November 8, 2014 11:51 PM
To: "avt@ietf.org" <avt@ietf.org>
Subject: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

 

Hi guys,


I read the document and was wondering which of the topologies in
draft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3). Is it
the selective forward middlebox. It will be good to either use the same
terminology or if it is a different topology define it in the topology
draft.


As for the sequence number, when using example in figure 3 , each RTP stream
received (from the same SSRC) may have a gap in the sequence number or the
receiver may report a loss for a stream switched out by the midlebox? Any
requirement here?


 


Thanks


Roni Even

v2.23.0 | Report a Bug | By Email