IETF Logo Mail Archive

Re: [MMUSIC] Application to Network Communication

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 27 June 2013 09:42 UTC

Return-Path: <christer.holmberg@ericsson.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 1A2AA21F9AFA for <mmusic@ietfa.amsl.com>; Thu, 27 Jun 2013 02:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Level:
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 Y2bBeEK2NTYB for <mmusic@ietfa.amsl.com>; Thu, 27 Jun 2013 02:42:32 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19721F9AF3 for <mmusic@ietf.org>; Thu, 27 Jun 2013 02:42:31 -0700 (PDT)
X-AuditID: c1b4fb25-b7f1e6d00000274b-89-51cc0906dd58
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 43.71.10059.6090CC15; Thu, 27 Jun 2013 11:42:30 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 11:42:30 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Pal Martinsen (palmarti)" <palmarti@cisco.com>, mmusic <mmusic@ietf.org>
Thread-Topic: Application to Network Communication
Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRA
Date: Thu, 27 Jun 2013 09:42:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se>
References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com>
In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvrS4b55lAg3t3lS2mLn/MYvH++koW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjz6/zTAWPBCqWb/jI2MB4h7eLkYNDQsBE YtVkiy5GTiBTTOLCvfVsILaQwGFGif3TZboYuYDsRYwS35rmsYHUswlYSHT/0wapERHwlfhx oo8RJCwsYCjx4KEvRNhIYurfXhaQMIh9ZxErSJhFQFXi45wvLCA2L1DnwumvWCA2+Uhc/fka zOYEir/Z+oIdxGYEuub7qTVMIDazgLjErSfzmSCuFJBYsuc8M4QtKvHy8T9WCFtRov1pAyNE vZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtt YgTGwMEtv1V3MN45J3KIUZqDRUmc9+OpXYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKNn MeVtaPzSsurf4zMqXnffCHdtru5jF1bfw7NtneSkyJ7v0/T+7PC1/vlhayvP3YNRZpfZX5yL XWu67snCPMkZZhuuPZEOnx5kYjK11l027/2uo/FBGs7d6rMnKS+SLs8N+Z3oO3HCqvXBk46G SyxtT5n94MVtjZnaV1/YzikolCor0pTd2K3EUpyRaKjFXFScCACcXDBZTwIAAA==
Subject: Re: [MMUSIC] Application to Network Communication
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: Thu, 27 Jun 2013 09:42:37 -0000

Hi,

I am not really sure what you mean by "how network should treat different streams".

What kind of network entities are you referring to, and what kind of treatment?

Regards,

Christer


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Pal Martinsen (palmarti)
Sent: 27. kesäkuuta 2013 11:36
To: mmusic
Subject: [MMUSIC] Application to Network Communication

Hi All,

We see a need for better application to network communication to convey how the network should/could treat the different streams described in the medalines of the SDP. This is especially important as video codecs have become very elastic regarding network bandwidth. It would be useful for the network to know the nature regarding the usage of the video stream. The network could treat the stream very differently whatever it is realtime video requiring low latency and high bandwidth or is it a more static presentation flow carrying a slideshow. Getting information from the network to the application can also prove to be useful.

Todays existing solutions can be difficult to implement on some devices as the information is carried in the IP header or the markings in the packets is ignored across administrative domains. Other solution treats the network as a black box and tries to fix problems when they are discovered. Both the network and the application would benefit if information regarding things that is about to happen as opposed to just happened could be conveyed.

We are considering extending ICE connectivity checks and keepalives (STUN) to provide this communication from the endpoint to the network and from the network to the endpoint.

Are other folks seeing this problem as well, or are existing techniques and throwing bandwidth at the problem sufficient today and sufficient tomorrow?

Any comments, feedback and ideas are very welcome.

Regards
Pål-Erik Martinsen
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email