Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Mon, 10 June 2013 12:48 UTC

Return-Path: <thomas.stach@siemens-enterprise.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF1B21F86D3 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 05:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrkCcnE9sMUr for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 05:48:47 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 423BE21F84F5 for <mmusic@ietf.org>; Mon, 10 Jun 2013 05:47:08 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B78D11EB8513; Mon, 10 Jun 2013 14:40:45 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 10 Jun 2013 14:40:42 +0200
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE?
Thread-Index: AQHOY52wb18zsuOxAkCqqvPaFYXQyJkqulsAgAAGtQCAAsljgIAARsqAgAEU25A=
Date: Mon, 10 Jun 2013 12:40:41 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE121144B94F@MCHP04MSX.global-ad.net>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, <CD0D36C1-25C5-4222-B37E-D02AE2331E8B@iii.ca>, <51B20CD1.5090002@alum.mit.edu> <BLU169-W683BD404A78C1DD8E2B0D593990@phx.gbl>, <51B26996.1090006@alum.mit.edu> <BLU169-W64FD0D8AFD754835DD196C939B0@phx.gbl> <51B4FB67.7000600@alum.mit.edu>
In-Reply-To: <51B4FB67.7000600@alum.mit.edu>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 12:48:53 -0000

> -----Ursprüngliche Nachricht-----
> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Montag, 10. Juni 2013 00:02
> An: Bernard Aboba
> Cc: mmusic@ietf.org
> Betreff: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
> 
> On 6/9/13 1:48 PM, Bernard Aboba wrote:
> > Paul said:
> >
> >  > There is a big difference between clipping for one 
> second until the 183
> >  > is received, and clipping until the phone is answered 
> and a 200 received.
> >
> > [BA] So you're saying it is sufficient to enable media once a 183 is
> > received, but not before?  I believe that is consistent 
> with the current
> > WebRTC API.   The use case document isn't clear that this is the bar
> > that is being set, though.
> 
> I'm suggesting that in the case of BUNDLE, there be a 
> requirement that 
> media not be sent until an answer is known to have been 
> received by the 
> other end. Sending a reliable 183 and awaiting the PRACK 
> before sending 
> media would satisfy that. Presumably something similar can serve in a 
> pure WebRTC environment.
> 
> That will ensure no clipping.
> 
> The objection I hear to this is that some don't implement PRACK. I'm 
> just saying that we could require support for PRACK with support for 
> BUNDLE. Then that argument becomes bogus.
Just as well, we could require ICE together with BUNDLE and 
re-use how ICE deals with reliability of provisional reponses.
In the RTCWEB this would be a non-issue. 
Environments that don't support ICE could still require PRACK.

Regards
Thomas

> 
> Then we can say that it is ok if something in the answer is 
> needed for 
> the offerer to demux incoming media.
> 
> > One issue is what the WebRTC gateway will do if it gets 
> media before the
> > 183.    If it just forwards it on, then it will be dropped by the
> > browser until the 183 shows up and setRemoteDescription is called.
> > Should it buffer it until the 183 arrives?
> 
> My proposal is that it should not transmit media until it knows the 
> answer has been received. I don't care how it achieves that, but I 
> imagine dropping it would be a good choice.
> 
> Or, if people prefer, we could allow it to be sent, but allow 
> the other 
> end to drop it. But still expect the early answer so that the period 
> when media is lost is brief.
> 
> >  > But I was suggesting that we couple a requirement for 
> PRACK with BUNDLE,
> >  > and say that media should not be sent until the PRACK is 
> received. So
> >  > then there won't be clipping at all.
> >
> > [BA] Personally, I don't see PRACK as being required for BUNDLE, at
> > least in WebRTC uses. However, a WebRTC/SIP gateway probably should
> > support PRACK.
> 
> PRACK wouldn't be required in JSEP. But the equivalent would 
> be expected 
> - a quick ANSWER, before media is sent.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>