Re: [AVTCORE] BUNDLE and same payload type in different "bundled" m= lines

Iñaki Baz Castillo <ibc@aliax.net> Fri, 11 March 2016 20:28 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D27212D8A9 for <avt@ietfa.amsl.com>; Fri, 11 Mar 2016 12:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
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 80At-POmDc8R for <avt@ietfa.amsl.com>; Fri, 11 Mar 2016 12:28:42 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F44812DB40 for <avt@ietf.org>; Fri, 11 Mar 2016 12:28:42 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id g127so103694373ywf.2 for <avt@ietf.org>; Fri, 11 Mar 2016 12:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tn8+KR1KmoLn9Nf8T1A76JmThOJ5jWUedWD3VbLvPaU=; b=UB7J/3ixfgdn5yxN+RXWfz4CD/NVXOENTFtWFEAToUR+0/1O/SXujKjkK0/gm9MYdj FY2orLDEMF3UhP71hAHPwk/ilbMzkZOFGhueA+wyzlUSAZEoN5t9akzjXgaVZ1uEtBwO bzegGVm0AO/Ntb+XJknsDgo5ozSU4axlBaHZ225mHMfWNQG7REyKSqZmOdum8mHiDH1A tqxvWZ6VaXEPXIYxAX5gF/r9dNXmwvqmkh3Ee3BUzWqTOf+E5FzmuO7gDi00uq+k+U9s WmweIOStbmJljlxctMuFtXd7d7EQgjjFcbAP0NTOkmynjGPgyhrSYgIdpkWOt2cwvnqf 0vrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tn8+KR1KmoLn9Nf8T1A76JmThOJ5jWUedWD3VbLvPaU=; b=JLkopJ4PjpWTRwYzPM4Cjkt4iIOFkM7yYhhL0kchy7JSQJEYCLy0mHnw1ljIPJY6nP VhxhMMdWLVk6uItj+9XD+7kKvCOg7N6YyU+yB5kMKtHvGT8XJZShMWF5nDNT1+N3VM3h HfgKEfFNB5x+1s7c+VQmUIQbCCz68xwEK+V1N+/ahhg3Lwj0m2U7Mm9jeuGeN83L1Qtq mi3nDac9WhGiYLbq5O7zK3S9h6drkhderRPcEfSSIuMlAWwmGNrf2TF3JYRukrFJfzN+ wtr2tB//D9fVQPORdNV7Co7sC+9xxGaXW3gsOSSdUN4Q0T3cdiy9Bf3maMZgZpxXQvKn a76A==
X-Gm-Message-State: AD7BkJJhN6VaX3FalD9XPefhpj4Cu5TEQIbyf2sihv4TsZMdfMW1P79mHXYug3ElhL1d47lWRBtThAo2KYU3bA==
X-Received: by 10.13.214.77 with SMTP id y74mr6272005ywd.217.1457728121472; Fri, 11 Mar 2016 12:28:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Fri, 11 Mar 2016 12:28:22 -0800 (PST)
In-Reply-To: <56E286F2.7070002@ericsson.com>
References: <CALiegf=ipwHpMVo2H12-FspsEx2EP8dBkabLHmDta-WWoor_zg@mail.gmail.com> <61AB25C3-A41F-44B4-B2C4-8A2F8E202B8E@gmail.com> <CALiegfmc=mrX9tYW8WJXQvV2fA8Q2+LddDYqQQTorFyeNQgNCg@mail.gmail.com> <56E286F2.7070002@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Fri, 11 Mar 2016 21:28:22 +0100
Message-ID: <CALiegfnCr7nvmU6O2iguEGTUAhkbAN=QW3swjOg7W3S=xp1kXw@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/n4fj9PK0vo_Swkpxb4dfzPYrMgc>
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] BUNDLE and same payload type in different "bundled" m= lines
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 11 Mar 2016 20:28:45 -0000

2016-03-11 9:50 GMT+01:00 Magnus Westerlund <magnus.westerlund@ericsson.com>om>:
> I don't really agree to this characterization of Bundle. Bundle is SDP
> solution for how one adds media source level information around the RTP
> streams that all are sent within a single RTP session.
>
> In non offer/answer usage of SDP, like in SAP and RTSP the m= lines
> represents a RTP session, not a media source. In these cases you don't
> have any information about the specific RTP streams, there is an
> assumption that there will be sent one or more per direction in these
> usages.

Not sure if I get it. At the end, in WebRTC each m= line means a
MediaStreamTrack to be sent and/or a MediaStreamTrack to be received.


> To be clear, from a high level it exists a possibility to define usages
> of the RTP that would define the PT value to be scoped on SSRC basis,
> rather then RTP session level. However the devil is in the details and
> such a usage would require careful review of existing specifications to
> find where there might be issues. I am especially worried about issues
> in the RTCP parts, for cases where PT information are used. Normally
> this is clearly done in the context of an SSRC. But, to be certain there
> are no issues one has to review things.  I am also expecting that more
> than one RTP stack implementation are unable to support this without
> modifications, possibly extensive ones. This as the data structures for
> the PT are associated with the RTP session rather than individual SSRCs.

Useful information. However I will start another thread (not sure in
which mailing list) with a simple question:

As BUNDLE spec states, two bundled m= lines can just share the same PT
value if it points to the same codec name and codec configuration.
Where is specified what "same configuration" means? I expect it
depends on each codec...



> So, I would like to make sure that we are on a common understanding what a
> SFU have to do with the RTP streams to make it possible to re-use the PTs.
>
> So if we start with A and B communicating across an SFU. I will continue
> this from your example when you raised this in MMUSIC:
>
> 1) mid: alice-audio,  codec: opus,  payload: 100, ssrc: 1111
> 2) mid: bob-audio,   codec: g722,  payload: 100, ssrc: 2222
>
> This would mean that Carol receives an SDP with two "m=audio"
> sections using BUNDLE:
>
>
>   m=audio [...] 100
>   a=sendonly
>   a=mid:alice-audio
>   a=rtpmap:100 opus/48000/2
>   a=ssrc:1111 cname:foo
>   [...]
>   m=audio [...] 100
>   a=sendonly
>   a=mid:bob-audio
>   a=rtpmap:100 g722/48000
>   a=ssrc:2222 cname:bar
>   [...]
>
> So from my perspective what the conference signalling server has to send
> Carol is an SDP that looks like this:
>
> This would mean that Carol receives an SDP with two "m=audio"
> sections using BUNDLE:
>
>
>   m=audio [...] 100
>   a=sendonly
>   a=mid:alice-audio
>   a=rtpmap:100 opus/48000/2
>   a=ssrc:1111 cname:foo
>   [...]
>   m=audio [...] 101
>   a=sendonly
>   a=mid:bob-audio
>   a=rtpmap:101 g722/48000
>   a=ssrc:2222 cname:bar
>   [...]
>
>
> Then the SFU will need to change all RTP packets with PT=100 from Bob to
> PT=101 when forwarding them to Carol. The packets from Alice it can leave
> unchanged from an PT perspective.
>
> If David joins the session and can do both codecs and offers like this:
>
> m=audio [...] 98 99
> a=sendrecv
> a=rtpmap:98 opus/48000/2
> a=rtpmap:99 g722/48000
> a=ssrc:4444 cname:groo
>
> Then I expect the conference server to determine that these configurations
> are identical to already existing ones and answer:
>
> m=audio [...] 98
> a=sendonly
> a=mid:alice-audio
> a=rtpmap:98 opus/48000/2
> a=ssrc:1111 cname:foo
> [...]
> m=audio [...] 99
> a=sendonly
> a=mid:bob-audio
> a=rtpmap:99 g722/48000
> a=ssrc:2222 cname:bar
> [...]
> m=audio [...] 98 99
> a=sendonly
> a=mid:carol-audio
> a=rtpmap:98 opus/48000/2
> a=rtpmap:99 g722/48000
> a=ssrc:3333 cname:skog
> [...]
> m=audio [...] 100 101
> i=M block for David's audio stream
> a=recv
> a=rtpmap:100 opus/48000/2
> a=rtpmap:101 g722/48000
>
> So the SFU will translate the PTs towards Dave, to match what Dave accepts
> receiving. The SFU request Dave's endpoint to use the PTs it has defined as
> its common reception table out of the ones the Dave support.


Thanks a lot. Very valuable information.

However I plan to do something a bit different:

When a new participant joins the SFU room and sends its SDP offer, the
room will check the offered codecs. If same codec+configuration
already exists in the room (with an assigned unique PT) the SFU will
generate a SDP answer including the PT in the room for that
codec+configuration. According to SDP O/A, the offerer is mandated to
send RTP using the PT indicated in the SDP answer.

With this, I will avoid PT mangling in the SFU.




> Yes, using RTP middleboxes and SDP offer/answer do result in that one will
> have to specific PT values in use on each leg. It is very difficult to get
> this aligned to between the legs.
>
> Your proposal is one way to avoid that translation. Which would require
> certain changes and issues. Another possibility would be to try to address
> it in the signalling system. Because having the possibility for the central
> controller to dictate the actual configuration within the capabilities of
> the endpoints would simplify certain things. Unfortunately both have issues
> to resolve and significant legacy inertia.

That's exactly what I propose above :)
However I do know that, probably, I will have to implement PT mangling
in some cases (for example when the SFU sends a re-offer to a browser
indicating its preferred PT values but the browser replies with
different values).


Thanks a lot Magnus.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>