Re: [rtcweb] Multiplexing using the same port number for multiple media descritions

Harald Alvestrand <harald@alvestrand.no> Tue, 30 August 2011 15:14 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83021F8CAA for <rtcweb@ietfa.amsl.com>; Tue, 30 Aug 2011 08:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.989
X-Spam-Level:
X-Spam-Status: No, score=-105.989 tagged_above=-999 required=5 tests=[AWL=3.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 NN9hd-Z5pyqC for <rtcweb@ietfa.amsl.com>; Tue, 30 Aug 2011 08:14:15 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9DA21F8CA5 for <rtcweb@ietf.org>; Tue, 30 Aug 2011 08:14:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A854B39E12B; Tue, 30 Aug 2011 17:14:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GBvvE0K02+M; Tue, 30 Aug 2011 17:14:17 +0200 (CEST)
Received: from [172.16.40.245] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 712FC39E072; Tue, 30 Aug 2011 17:14:17 +0200 (CEST)
Message-ID: <4E5CFE94.6010608@alvestrand.no>
Date: Tue, 30 Aug 2011 17:15:32 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233D64F47@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D64F47@ESESSCMS0356.eemea.ericsson.se>
Content-Type: multipart/alternative; boundary="------------080504000607090606040508"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Multiplexing using the same port number for multiple media descritions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Aug 2011 15:14:16 -0000

On 08/30/11 13:21, Christer Holmberg wrote:
> Hi,
> One possible alternative solution for SDP multiplex negotiation could 
> be based on the assumption of using the same port number in multiple 
> SDP m- lines (yes, I know SDP does not allow it, and I will come back 
> to that).
> Something like:
> SDP offer:
> m=audio 10000 ...
> a=rtpmap ...
> a=rtpmap ...
> m=video 10000 ...
> a=rtpmap ...
> a=rtpmap ...
> SDP answer (multiplex supported/accepted):
> m=audio 20000 ...
> a=rtpmap ...
> a=rtpmap ...
> m=video 20000 ...
> a=rtpmap ...
> a=rtpmap ...
In this case, packets flow from/to port 10000 to port 20000 for both 
media types.
> SDP answer (multiplex not-supported/rejected):
> m=audio 20000 ...
> a=rtpmap ...
> a=rtpmap ...
> m=video 30000 ...
> a=rtpmap ...
> a=rtpmap ...
In this case, packets would presumably flow between port 10000 and port 
20000 for audio, and port 10000 and port 30000 for video.
Is that a correct interpretation of how you think this would work?

In that case, we have an RTP spec problem, not just an SDP problem: RTP 
"straight" claims to identify sessions by destination address + port 
(RFC 3550 section 5.2, for instance). In normal unicast / point-to-point 
usage, we expect all packets to come from the same address + port too, 
but RFC 3550 doesn't say that.

I don't know if this is an issue. If it is an issue, sender might have 
to start over.