Re: [MMUSIC] Is bundle just a port override?

Emil Ivov <emcho@jitsi.org> Tue, 19 March 2013 17:03 UTC

Return-Path: <emil@sip-communicator.org>
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 C4C4621F8D68 for <mmusic@ietfa.amsl.com>; Tue, 19 Mar 2013 10:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level:
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RDNS_DYNAMIC=0.1]
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 sLVtg-0xT3CN for <mmusic@ietfa.amsl.com>; Tue, 19 Mar 2013 10:03:03 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC121F8C7D for <mmusic@ietf.org>; Tue, 19 Mar 2013 10:03:03 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm11so4630823wib.5 for <mmusic@ietf.org>; Tue, 19 Mar 2013 10:03:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=/IjoHxcIkPskjykT1I+mN3lBj1oldEna3mZF6c9WJ7s=; b=GVVULYqUWI0+F+ooW3wA6dUDHqg4EgaUAZS622X9t64Au560SxgkW8XJ17+4QjNP4V jhWwDn8xvevPAVLP3VKq8y2XDLN7XajjqnKhObu9Hbys1MbbdKnuIPEVzwtIiraSZ37P suUgm3+hSDApIcYtC9fUxNa3SM7w89sQ5RtuKFPoNysUkXR7t+UosAvYa/7WhxtvPYas hnfmYcd0u+TBh2zfBcIRT1/oHCzlphik7wuBLnpxKxlj+nkyeZpk3GXApq0uM6zRmM/o gTJWsuKin/DUAjkEY5lb5oczHyrWyD/xCc/KwIi+7n0C7anBERtcs5TrJyUiAX+A6FZY PQ3w==
X-Received: by 10.180.12.48 with SMTP id v16mr4410656wib.1.1363712582382; Tue, 19 Mar 2013 10:03:02 -0700 (PDT)
Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id t7sm1850024wij.2.2013.03.19.10.03.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 10:03:01 -0700 (PDT)
Message-ID: <51489A43.3030109@jitsi.org>
Date: Tue, 19 Mar 2013 18:02:59 +0100
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmA8Bsn5F75RncitLzdgv4FNuOtkQBzQ8+3FEj0lG4Go+CR8JC8zUNxozlV40rwY10nffmY
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Is bundle just a port override?
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: Tue, 19 Mar 2013 17:03:05 -0000

Hey Mo,

On 19.03.13, 16:28, Mo Zanaty (mzanaty) wrote:
> I understand the RTP session rules, but they are a matter for AVTCORE,
> and several drafts already detail the RTP considerations for
> multiplexing streams, of potentially different media types, over the
> same port (using plain RTP not SHIM). Bundle does not need to solve that
> (solved) problem, it just needs to signal which port(s) to use. If we
> feel we should signal some sort of human-level warning about RTP mux
> rules when signaling ports, the attribute can be named a=rtp-mux:<port>
> instead of a=port <port>.
> 
>  
> 
> I don’t see how any grouping semantics help with any of the rules.
> Actually, I think grouping semantics hurt, not just due to complexity,
> but also due to ambiguity about which attributes are inherited or
> overridden from other m-blocks. Keeping all the m-block attributes
> independent seems simpler and clearer. If an attribute needs to be
> consistent across m-blocks, repeating it seems simpler and clearer than
> inheritance/override rules across m-blocks. (Of course, if all m-blocks
> need the same attribute, it can be defined at session level instead of
> repeating in all media levels.)
> 
>  
> 
> In my simple (perhaps too simple) mind, all we’re trying to do in bundle
> is temporarily lie on the m-line port to avoid confusing
> peers/intermediaries. In the process, I think we have confused ourselves
> about what is truly needed to accomplish this deception. Or maybe I’m
> the only one confused…

In your original mail you seemed to be suggesting something similar to:

http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-00

(Sometimes referred to Cundle for Cullen's Bundle)

or this

http://tools.ietf.org/html/draft-alvestrand-one-rtp-01

(Also known as One RTP)

Both would start by offering multiple ports and fall back to a single
port if bundling is supported.

The concern that has been expressed with them is that in case of
bundling, non-use of the discarded RTP ports would cause some SBCs to
believe that there's a problem with the session which may lead to the
SBC tearing down the call.

Hope this helps,
Emil

> 
>  
> 
> Mo
> 
>  
> 
> *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Tuesday, March 19, 2013 5:03 AM
> *To:* Mo Zanaty (mzanaty)
> *Cc:* mmusic@ietf.org; rtcweb@ietf.org
> *Subject:* Re: [MMUSIC] Is bundle just a port override?
> 
>  
> 
> On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
> 
>     Does bundle imply anything beyond a simple port override of the
>     m-line port? If not, then why not just directly signal the port
>     override in an attribute without any grouping semantics?
> 
> 
> No, it's not just a port override.
> 
> BUNDLE shoves things into the same RTP session, which means that one has
> to obey the rules for being in the same RTP session:
> - Security done consistently
> - RTCP-mux done consistently
> - No SSRC collision
> - No payload type collision
> So it's a good deal more than just a port override.
> 
> Magnus argued in favour of a solution that inserted a multiplex layer,
> so that one could use the same ports but still have stuff in different
> RTP sessions, but that did not appeal to many.
> 
> 
>  
> 
> Offer to mux audio and video on the same port:
> 
> m=audio 10000 RTP/AVP 0
> 
> m=video 10002 RTP/AVP 31
> 
> a=port 10000
> 
> i=I really want 10000, but lied on the m-line for fear of confusing you.
> Confused yet?
> 
>  
> 
> Answer supports the port override attribute and agrees to mux audio and
> video:
> 
> m=audio 40000 RTP/AVP 0
> 
> m=video 40000 RTP/AVP 31
> 
> a=port 40000
> 
> …so audio and video ports are 10000<->40000.
> 
>  
> 
> Answer supports the port override attribute but doesn’t want to demux on
> his end:
> 
> m=audio 40000 RTP/AVP 0
> 
> m=video 40002 RTP/AVP 31
> 
> a=port 40002
> 
> …so audio ports are 10000<->40000 and video ports are 10000<->40002.
> 
>  
> 
> Answer doesn’t support the port override attribute, or doesn’t want
> either end to mux:
> 
> m=audio 40000 RTP/AVP 0
> 
> m=video 40002 RTP/AVP 31
> 
> …so audio ports are 10000<->40000 and video ports are 10002<->40002.
> 
>  
> 
> Either end can re-offer without lies about ports on the m-line after
> confirming the peer is not confused by muxing, if they want to avoid
> confusing intermediaries.
> 
>  
> 
> Has this approach been tried yet? Dismissed?
> 
>  
> 
> Mo
> 
>  
> 
> 
> 
> 
> _______________________________________________
> 
> mmusic mailing list
> 
> mmusic@ietf.org <mailto:mmusic@ietf.org>
> 
> https://www.ietf.org/mailman/listinfo/mmusic
> 
>  
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org