From mmusic-bounces@ietf.org Thu Jan 8 00:12:25 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821DE3A6A9F; Thu, 8 Jan 2009 00:12:25 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96723A6A9F for ; Thu, 8 Jan 2009 00:12:23 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvUxYfSAdZqn for ; Thu, 8 Jan 2009 00:12:21 -0800 (PST) Received: from mail1.astri.org (mail1.hkjcicm.org [218.188.84.5]) by core3.amsl.com (Postfix) with ESMTP id 7295F3A6A94 for ; Thu, 8 Jan 2009 00:12:20 -0800 (PST) Received: (qmail 4140 invoked from network); 8 Jan 2009 08:12:06 -0000 X-NetworkBox-HamSign: 0101;OUT;astrihk1;62ca9e6d7b46050433e4ec8483e495d1; Received: from unknown (HELO ASPROEXG.astri.local) (10.6.2.21) by 172.16.1.240 with SMTP; 8 Jan 2009 08:12:06 -0000 Received: from [192.1.1.100] ([10.6.104.75]) by ASPROEXG.astri.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 16:12:26 +0800 Message-ID: <4965B56A.6060203@astri.org> Date: Thu, 08 Jan 2009 16:12:26 +0800 From: Richard Wu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmusic@ietf.org X-OriginalArrivalTime: 08 Jan 2009 08:12:26.0799 (UTC) FILETIME=[D7CF3BF0:01C97168] X-NetworkBox-BounceSign-astri: 0101;14252;91394650 X-Scanned-By-astrihk1: Virus scan performed by network-box X-Scanned-By-astrihk1: Scanner file id is astrihk1-1231402326.638-4133-000 X-Scanned-By-astrihk1: No known viruses found in message (received+scanned in 0.03/0.04 secs) X-Scanned-By-astrihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 Cc: Fu Siu Ming Claudio Subject: [MMUSIC] Popularity of supporting RTCP extended report (RFC3611) in voip phone/video phone X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hi All, I would like to know the popularity of supporting RFC3611 in current voip phone/video phone. Thanks in advance. Regards, Richard Senior Engineer ASTRI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 8 00:18:21 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529F13A6AB2; Thu, 8 Jan 2009 00:18:21 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473563A6AAC; Thu, 8 Jan 2009 00:18:20 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bueZ+py4I1h0; Thu, 8 Jan 2009 00:18:19 -0800 (PST) Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by core3.amsl.com (Postfix) with ESMTP id 4B6D43A6AAA; Thu, 8 Jan 2009 00:18:18 -0800 (PST) Received: from pc89.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 87DF2C50F8; Thu, 8 Jan 2009 10:18:03 +0200 (EET) Message-ID: <4965B6C2.9060709@netlab.tkk.fi> Date: Thu, 08 Jan 2009 10:18:10 +0200 From: Joerg Ott User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Richard Wu References: <4965B56A.6060203@astri.org> In-Reply-To: <4965B56A.6060203@astri.org> Cc: Fu Siu Ming Claudio , mmusic@ietf.org, avt@ietf.org Subject: Re: [MMUSIC] Popularity of supporting RTCP extended report (RFC3611) in voip phone/video phone X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hi, you should address this question to the AVT group. (CC'ed). Joerg Richard Wu wrote: > Hi All, > I would like to know the popularity of supporting RFC3611 in current > voip phone/video phone. Thanks in advance. > > Regards, > Richard > > Senior Engineer > ASTRI > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > This message (including any attachments) is for the named > addressee(s)'s use only. It may contain sensitive, confidential, > private proprietary or legally privileged information intended for a > specific individual and purpose, and is protected by law. If you are > not the intended recipient, please immediately delete it and all copies > of it from your system, destroy any hard copies of it > and notify the sender. Any use, disclosure, copying, or distribution of > this message and/or any attachments is strictly prohibited. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 8 00:33:48 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDD128C125; Thu, 8 Jan 2009 00:33:48 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFAF28C125 for ; Thu, 8 Jan 2009 00:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F26GYDePxoUh for ; Thu, 8 Jan 2009 00:33:41 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CCB7028C102 for ; Thu, 8 Jan 2009 00:33:40 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7C7C1218ED for ; Thu, 8 Jan 2009 09:33:26 +0100 (CET) X-AuditID: c1b4fb3e-ae86fbb00000429e-9b-4965ba5669b5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59BE0203D1 for ; Thu, 8 Jan 2009 09:33:26 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 09:33:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 09:33:25 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTSP From header issue Thread-Index: Aclxa8XSzWW9oNfTQ8GRDmBoHovHHA== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 08 Jan 2009 08:33:26.0090 (UTC) FILETIME=[C667CAA0:01C9716B] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S Subject: [MMUSIC] RTSP From header issue X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hi Going through the syntax of the parts that handles URI's I found a possible= issue with the syntax of the From header. = 1) In section 16.23 in RTSP 2.0 there is only a reference section 14.22 in = RFC2616 which contains a rather simple definition. From =3D "From" ":" mailbox Section 20.2.3 in RTSP 2.0 however contains a much more elaborate definitio= n with extensions (from-param). = Isn't it better to specify something in section 16.23 like "The From header= is defined in in [H14.22] but is extended in this specification" ? 2) Looking at the syntax I see a risk that occasional ";" in the URI can cl= ash with URI's that precedes each optional from-param, making parsing compl= icated. The ABNF for the From header is From =3D "From" HCOLON from-spec from-spec =3D ( name-addr / addr-spec ) *( SEMI from-param ) name-addr =3D [ display-name ] LAQUOT addr-spec RAQUOT addr-spec =3D RTSP-URI / absolute-URI absolute-URI =3D < As defined in RFC 3986> display-name =3D *(token LWS) / quoted-string from-param =3D tag-param / generic-param tag-param =3D "tag" EQUAL token Here I would suggest to change the addr-spec definition to = addr-spec =3D DQ ( RTSP-URI / absolute-URI ) DQ As a comparision, Accept-Credentials, which has some similarities with the = >From header, use DQ around the URI. 3) In general. The idea to use DQ around URI's in some cases and in some ca= ses not may cause some headache for the implementor. Sure, one should read = the ABNF but I would say that it would be more consistent to always use DQ = around URI's in headers regardless if they are needed or not. /Ingemar = ******************************************* = Ingemar Johansson = Senior Research Engineer, IETF "nethead" = EAB/TVP - Multimedia Technologies = Ericsson Research Ericsson AB = Box 920 S-971 28 Lule=E5, Sweden = Tel: +46 (0)10 7143042 = ECN: 852-43042 = ECC: 852-19042 Mobile: +46 (0)730 783289 = Visit http://labs.ericsson.com ! ******************************************* = _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 8 00:38:20 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B440B3A6963; Thu, 8 Jan 2009 00:38:20 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB24328C0F6 for ; Thu, 8 Jan 2009 00:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbRaUuDRjAZt for ; Thu, 8 Jan 2009 00:38:17 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9E2593A6827 for ; Thu, 8 Jan 2009 00:38:16 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n088bk9h025374; Thu, 8 Jan 2009 10:38:00 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 10:37:15 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 10:37:10 +0200 Received: from esdhcp041160.research.nokia.com (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n088b8Lk026473; Thu, 8 Jan 2009 10:37:08 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: mmusic@ietf.org Date: Thu, 8 Jan 2009 10:37:40 +0200 User-Agent: KMail/1.9.10 References: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050916F0B1@esealmw109.eemea.ericsson.se> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901081037.40509.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 08 Jan 2009 08:37:10.0091 (UTC) FILETIME=[4BEBA1B0:01C9716C] X-Nokia-AV: Clean Cc: ext Ingemar Johansson S Subject: Re: [MMUSIC] RTSP From header issue X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org On Thursday 08 January 2009 10:33:25 ext Ingemar Johansson S, you wrote: > Hi > > Going through the syntax of the parts that handles URI's I found a possib= le > issue with the syntax of the From header. 1) In section 16.23 in RTSP 2.0 > there is only a reference section 14.22 in RFC2616 which contains a rather > simple definition. From =3D "From" ":" mailbox > Section 20.2.3 in RTSP 2.0 however contains a much more elaborate > definition with extensions (from-param). Isn't it better to specify > something in section 16.23 like "The From header is defined in in [H14.22] > but is extended in this specification" ? Is anyone using the From: in HTTP or RTSP anyhow? I guess not. -- = R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 8 08:25:27 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E7428C0E7; Thu, 8 Jan 2009 08:25:27 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856463A6ACE; Thu, 8 Jan 2009 08:25:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB+0dUMsTI98; Thu, 8 Jan 2009 08:25:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [209.139.209.61]) by core3.amsl.com (Postfix) with ESMTP id 4A8293A6AEB; Thu, 8 Jan 2009 08:25:17 -0800 (PST) Received: from berlin.arid.us (cpe-075-182-105-058.nc.res.rr.com [75.182.105.58]) (authenticated bits=0) by dublin.packetizer.com (8.13.8/8.13.8) with ESMTP id n08GOkJm011586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2009 11:24:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1231431893; bh=XYLvHTzpGIxJdkfh/3CAUY7rwLl5A81rq8VBsScs V7Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WpBbKP1X+da RDjJeDJnRhA0swjlZ5lfBDO7SEjzB6NxcOH+WjiT/+B67XphKhqwi+on9uSE7FzzTFK YReg2xayuVXnKYm83d6K6dL7I+4RhW4uDrKhumbE74UyBIgw61n+zbvtB/BZUtmiHj6 PsaMODVYXQHrXGJd5Qqqcq0fXs= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id n08GOi9b028718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Jan 2009 11:24:44 -0500 From: "Paul E. Jones" To: "'Joerg Ott'" , "'Richard Wu'" References: <4965B56A.6060203@astri.org> <4965B6C2.9060709@netlab.tkk.fi> In-Reply-To: <4965B6C2.9060709@netlab.tkk.fi> Date: Thu, 8 Jan 2009 11:24:20 -0500 Message-ID: <005e01c971ad$90290ca0$b07b25e0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclxaam8IkbUvRHzQfunMqMCTGF1HQAQvU1A Content-Language: en-us Cc: 'Fu Siu Ming Claudio' , mmusic@ietf.org, avt@ietf.org Subject: Re: [MMUSIC] [AVT] Popularity of supporting RTCP extended report (RFC3611) in voip phone/video phone X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Richard, You might be asking the wrong question. I personally do not care how widely implemented it is: it ought to be implemented more widely. Heck, even RTCP is not as widely implemented (or at least used) as it ought to be. RCTP XR can help to provide important statistics that can be used to improve call quality and diagnosing network issues. For example, H.323 has the wherewithal to report the RTCP XR data to the Gatekeeper at the end of the call. The Gatekeeper can then feed that to back-end call processing systems that can alert operators to network issues and to routing engines that use that information to route calls to avoid problematic network links or devices. Paul > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Joerg Ott > Sent: Thursday, January 08, 2009 3:18 AM > To: Richard Wu > Cc: Fu Siu Ming Claudio; mmusic@ietf.org; avt@ietf.org > Subject: Re: [AVT] [MMUSIC] Popularity of supporting RTCP extended > report (RFC3611) in voip phone/video phone > > Hi, > > you should address this question to the AVT group. > (CC'ed). > > Joerg > > Richard Wu wrote: > > Hi All, > > I would like to know the popularity of supporting RFC3611 in > current > > voip phone/video phone. Thanks in advance. > > > > Regards, > > Richard > > > > Senior Engineer > > ASTRI > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This message (including any attachments) is for the named > > addressee(s)'s use only. It may contain sensitive, confidential, > > private proprietary or legally privileged information intended for a > > specific individual and purpose, and is protected by law. If you are > > not the intended recipient, please immediately delete it and all > copies > > of it from your system, destroy any hard copies of it > > and notify the sender. Any use, disclosure, copying, or distribution > of > > this message and/or any attachments is strictly prohibited. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 8 17:29:45 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E2028C114; Thu, 8 Jan 2009 17:29:45 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4B428C10B; Thu, 8 Jan 2009 17:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=1.842, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeVpCmosecGh; Thu, 8 Jan 2009 17:29:43 -0800 (PST) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id 6812B28C0FA; Thu, 8 Jan 2009 17:29:42 -0800 (PST) MIME-Version: 1.0 Date: Fri, 9 Jan 2009 10:28:01 +0900 Message-ID: In-Reply-To: <005e01c971ad$90290ca0$b07b25e0$@com> References: <4965B56A.6060203@astri.org> <4965B6C2.9060709@netlab.tkk.fi> <005e01c971ad$90290ca0$b07b25e0$@com> From: "Jaehwan Kim" To: "Paul E. Jones" , "Joerg Ott" , "Richard Wu" Cc: Fu Siu Ming Claudio , mmusic@ietf.org, avt@ietf.org Subject: Re: [MMUSIC] [AVT] Popularity of supporting RTCP extended report(RFC3611) in voip phone/video phone X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hi, If video phone means 3GPP compliant streaming solution... RTCP XR is a part of 3GPP PSS specification. I know one phone manufacturer supports it and some streaming servers support it as well. Cheers, Jaehwan -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Friday, January 09, 2009 1:24 AM To: 'Joerg Ott'; 'Richard Wu' Cc: 'Fu Siu Ming Claudio'; mmusic@ietf.org; avt@ietf.org Subject: Re: [AVT] [MMUSIC] Popularity of supporting RTCP extended report(RFC3611) in voip phone/video phone Richard, You might be asking the wrong question. I personally do not care how widely implemented it is: it ought to be implemented more widely. Heck, even RTCP is not as widely implemented (or at least used) as it ought to be. RCTP XR can help to provide important statistics that can be used to improve call quality and diagnosing network issues. For example, H.323 has the wherewithal to report the RTCP XR data to the Gatekeeper at the end of the call. The Gatekeeper can then feed that to back-end call processing systems that can alert operators to network issues and to routing engines that use that information to route calls to avoid problematic network links or devices. Paul > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Joerg Ott > Sent: Thursday, January 08, 2009 3:18 AM > To: Richard Wu > Cc: Fu Siu Ming Claudio; mmusic@ietf.org; avt@ietf.org > Subject: Re: [AVT] [MMUSIC] Popularity of supporting RTCP extended > report (RFC3611) in voip phone/video phone > > Hi, > > you should address this question to the AVT group. > (CC'ed). > > Joerg > > Richard Wu wrote: > > Hi All, > > I would like to know the popularity of supporting RFC3611 in > current > > voip phone/video phone. Thanks in advance. > > > > Regards, > > Richard > > > > Senior Engineer > > ASTRI > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This message (including any attachments) is for the named > > addressee(s)'s use only. It may contain sensitive, confidential, > > private proprietary or legally privileged information intended for a > > specific individual and purpose, and is protected by law. If you are > > not the intended recipient, please immediately delete it and all > copies > > of it from your system, destroy any hard copies of it > > and notify the sender. Any use, disclosure, copying, or distribution > of > > this message and/or any attachments is strictly prohibited. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 9 06:30:02 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4578E28C156; Fri, 9 Jan 2009 06:30:02 -0800 (PST) X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2B15A28C156; Fri, 9 Jan 2009 06:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090109143001.2B15A28C156@core3.amsl.com> Date: Fri, 9 Jan 2009 06:30:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-sdp-media-capabilities-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP media capabilities Negotiation Author(s) : R. Gilman, et al. Filename : draft-ietf-mmusic-sdp-media-capabilities-06.txt Pages : 45 Date : 2009-01-09 Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This extension is designed to map easily to existing and future SDP media attributes, but not encodings or formatting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-media-capabilities-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-09062948.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Jan 13 06:30:04 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5B528C11E; Tue, 13 Jan 2009 06:30:04 -0800 (PST) X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2311D3A6AA7; Tue, 13 Jan 2009 06:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090113143002.2311D3A6AA7@core3.amsl.com> Date: Tue, 13 Jan 2009 06:30:02 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc3388bis-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : The SDP (Session Description Protocol) Grouping Framework Author(s) : G. Camarillo Filename : draft-ietf-mmusic-rfc3388bis-02.txt Pages : 20 Date : 2009-01-13 In this specification, we define a framework to group "m" lines in SDP (Session Description Protocol) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc3388bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc3388bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-13061647.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Jan 13 09:43:09 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0B43A69FF; Tue, 13 Jan 2009 09:43:09 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F483A6A1E for ; Tue, 13 Jan 2009 09:43:07 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-qjoOK2P-ca for ; Tue, 13 Jan 2009 09:43:07 -0800 (PST) Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by core3.amsl.com (Postfix) with ESMTP id 158D13A69FF for ; Tue, 13 Jan 2009 09:43:06 -0800 (PST) Received: from 80-186-253-165.elisa-mobile.fi (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 29F69C50EE for ; Tue, 13 Jan 2009 19:42:48 +0200 (EET) Message-ID: <496CD2A0.7030205@netlab.tkk.fi> Date: Tue, 13 Jan 2009 19:42:56 +0200 From: Joerg Ott User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: mmusic@ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-rfc3388bis-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Folks, we are issuing Working Group Last Call for draft-ietf-mmusic-rfc3388bis-02.txt for Proposed Standard. Please review the document and send comments to the MMUSIC mailing list and/or the authors. The WGLC is to expire on 31 January 2009. Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 14 01:12:47 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17553A6B3B; Wed, 14 Jan 2009 01:12:46 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2BC3A681C for ; Wed, 14 Jan 2009 01:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eqeTMevOLaQ for ; Wed, 14 Jan 2009 01:12:44 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EA91B3A6B3B for ; Wed, 14 Jan 2009 01:12:43 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 419B32140E for ; Wed, 14 Jan 2009 10:12:28 +0100 (CET) X-AuditID: c1b4fb3e-ae06ebb00000429e-a4-496dac7c5d8b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C86B20261 for ; Wed, 14 Jan 2009 10:12:28 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jan 2009 10:12:28 +0100 Received: from [147.214.183.23] ([147.214.183.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jan 2009 10:12:27 +0100 Message-ID: <496DAC7B.6090807@ericsson.com> Date: Wed, 14 Jan 2009 10:12:27 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 14 Jan 2009 09:12:27.0938 (UTC) FILETIME=[38BBF020:01C97628] X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] RTSP 2.0 status X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hi, We authors had the goal to provide a new draft version before new year. This has not happened due to one major reason, namely RFC 5378. If you missed the intensive discussion on this subject on ietf@ietf.org list, the issue is that you as author when submitting a document using the new IPR rules needs to grand additional rights to the IETF trust. However, for documents that has text contributions from people beyond they authors, the author needs to ensure that these rights are provided from these contributors also. This can be problematic as the copyright of ones work commonly belong to our employers. We have been working on obtaining these rights for all that has directly contributed text to RTSP. This has been quite successful and are to my knowledge currently missing only the rights from Real Networks. However, the sad story is that this will not be sufficient to submit the draft. RTSP 2.0 contains numerous paragraphs of text that is copied from HTTP (RFC 2068 or RFC 2616) and then adapted for RTSP. The problem with HTTP is that is has a very long list of contributors and the chance of success to acquire those rights in a timely manor are slim. Martin and I have discussed the alternatives and we need this text in the document for RTSP 2.0 to be understandable. Fortunately there are some hope, the trust are working on providing a work around until an updated version of RFC 5378 can be written. Hopefully this workaround will be available before draft submission cut-off for San Francisco. Thus allowing us to submit the draft for your review and discussion in San Francisco. We where also slightly behind on closing the open issues and we are continuing to work on these to ensure that we have a draft in good shape when we can submit it. Best Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 15 06:42:32 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46A328C1BA; Thu, 15 Jan 2009 06:42:32 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE1C3A69F2; Fri, 9 Jan 2009 07:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeYPK-Bfvo2M; Fri, 9 Jan 2009 07:36:07 -0800 (PST) Received: from mx.cbeyond.com (mx.cbeyond.com [66.180.96.58]) by core3.amsl.com (Postfix) with ESMTP id B38123A6869; Fri, 9 Jan 2009 07:36:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAL79ZklCtGAJmWdsb2JhbACBbJIlAQEBAQEICwoHEbwDhW8 X-IronPort-AV: E=Sophos;i="4.37,239,1231131600"; d="scan'208";a="174789707" Received: from slbnat.dal.cbeyond.com (HELO mms02.dal0.cbeyond.net) ([66.180.96.9]) by mx.cbeyond.com with ESMTP; 09 Jan 2009 10:35:44 -0500 Received: (from mms02.dal0.cbeyond.net [10.50.1.45]) by mms02.dal0.cbeyond.net (MOS 3.8.4-GA) with HTTP/1.1 id GBL16819 (AUTH alan_d_clark@telchemy.com); Fri, 9 Jan 2009 10:35:43 -0500 (EST) From: Alan Clark To: Jaehwan Kim , "Paul E. Jones" , Joerg Ott , Richard Wu X-Mailer: Mirapoint Webmail Direct 3.8.4-GA MIME-Version: 1.0 Message-Id: <20090109103543.GBL16819@mms02.dal0.cbeyond.net> Date: Fri, 9 Jan 2009 10:35:43 -0500 (EST) X-Mailman-Approved-At: Thu, 15 Jan 2009 06:42:30 -0800 Cc: Fu Siu Ming Claudio , mmusic@ietf.org, avt@ietf.org Subject: Re: [MMUSIC] [AVT] Popularity of supporting RTCP extended report(RFC3611) in voip phone/video phone X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Independently of any mobile phone applications, there are known to be at least 50 million devices (in reality closer to 200 million) and over 100 equipment vendors that have the capability of reporting RTCP XR, and a fair number that also use the SIP RTCP Summary Reporting draft. These include IP phones from two tier 1 telecom equipment providers, softphones, residential and trunking gateways, and MTA's (cable industry). Also Texas Instruments incorporated support for RTCP XR into all of their VoIP solutions. In addition to the RTCP XR VoIP metrics being adopted as part of H.323, they were also incorporated into H.248 (Megaco) and into PacketCable 1.5. Regards Alan Clark Telchemy ---- Original message ---- >Date: Fri, 9 Jan 2009 10:28:01 +0900 >From: "Jaehwan Kim" >Subject: Re: [AVT] [MMUSIC] Popularity of supporting RTCP extended report(RFC3611) in voip phone/video phone >To: "Paul E. Jones" , "Joerg Ott" , "Richard Wu" >Cc: Fu Siu Ming Claudio , mmusic@ietf.org, avt@ietf.org > >Hi, >If video phone means 3GPP compliant streaming solution... >RTCP XR is a part of 3GPP PSS specification. >I know one phone manufacturer supports it and some streaming servers >support it as well. > >Cheers, >Jaehwan > >-----Original Message----- >From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >Paul E. Jones >Sent: Friday, January 09, 2009 1:24 AM >To: 'Joerg Ott'; 'Richard Wu' >Cc: 'Fu Siu Ming Claudio'; mmusic@ietf.org; avt@ietf.org >Subject: Re: [AVT] [MMUSIC] Popularity of supporting RTCP extended >report(RFC3611) in voip phone/video phone > >Richard, > >You might be asking the wrong question. I personally do not care how >widely >implemented it is: it ought to be implemented more widely. Heck, even >RTCP >is not as widely implemented (or at least used) as it ought to be. > >RCTP XR can help to provide important statistics that can be used to >improve >call quality and diagnosing network issues. For example, H.323 has the >wherewithal to report the RTCP XR data to the Gatekeeper at the end of >the >call. The Gatekeeper can then feed that to back-end call processing >systems >that can alert operators to network issues and to routing engines that >use >that information to route calls to avoid problematic network links or >devices. > >Paul > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Joerg Ott >> Sent: Thursday, January 08, 2009 3:18 AM >> To: Richard Wu >> Cc: Fu Siu Ming Claudio; mmusic@ietf.org; avt@ietf.org >> Subject: Re: [AVT] [MMUSIC] Popularity of supporting RTCP extended >> report (RFC3611) in voip phone/video phone >> >> Hi, >> >> you should address this question to the AVT group. >> (CC'ed). >> >> Joerg >> >> Richard Wu wrote: >> > Hi All, >> > I would like to know the popularity of supporting RFC3611 in >> current >> > voip phone/video phone. Thanks in advance. >> > >> > Regards, >> > Richard >> > >> > Senior Engineer >> > ASTRI >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > This message (including any attachments) is for the named >> > addressee(s)'s use only. It may contain sensitive, confidential, >> > private proprietary or legally privileged information intended for a >> > specific individual and purpose, and is protected by law. If you are >> > not the intended recipient, please immediately delete it and all >> copies >> > of it from your system, destroy any hard copies of it >> > and notify the sender. Any use, disclosure, copying, or distribution >> of >> > this message and/or any attachments is strictly prohibited. >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmusic >> > >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 21 14:15:02 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E060828C0FB; Wed, 21 Jan 2009 14:15:02 -0800 (PST) X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 36A3228C0E1; Wed, 21 Jan 2009 14:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090121221501.36A3228C0E1@core3.amsl.com> Date: Wed, 21 Jan 2009 14:15:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc4756bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Forward Error Correction Grouping Semantics in Session Description Protocol Author(s) : A. Begen Filename : draft-ietf-mmusic-rfc4756bis-00.txt Pages : 10 Date : 2009-01-21 The Session Description Protocol (SDP) supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the semantics that were defined in RFC 4756 generally fail to provide the specific grouping relationships between the source and repair flows when there are more than one source and/or repair flows in the same group. Furthermore, the existing semantics also do not support additive repair flows. This document addresses these issues by introducing new FEC grouping semantics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc4756bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-21140531.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Jan 22 02:26:10 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0639C3A6B64; Thu, 22 Jan 2009 02:26:10 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9BB3A6B64 for ; Thu, 22 Jan 2009 02:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAhzo-eb7iaq for ; Thu, 22 Jan 2009 02:26:08 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0732A3A6A4A for ; Thu, 22 Jan 2009 02:26:07 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E909F21607; Thu, 22 Jan 2009 11:24:31 +0100 (CET) X-AuditID: c1b4fb3e-ad06cbb00000429e-90-4978495fb964 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CCF6A22258; Thu, 22 Jan 2009 11:24:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 11:24:31 +0100 Received: from [159.107.24.250] ([159.107.24.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 11:24:31 +0100 Message-ID: <4978495E.2030303@ericsson.com> Date: Thu, 22 Jan 2009 11:24:30 +0100 From: "Miguel A. Garcia" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 22 Jan 2009 10:24:31.0303 (UTC) FILETIME=[9CF71570:01C97C7B] X-Brightmail-Tracker: AAAAAA== Cc: Salvatore.Loreto@ericsson.com, pkyzivat@cisco.com, Gonzalo.Camarillo@ericsson.com, markus.isomaki@nokia.com Subject: [MMUSIC] New Version Notification for draft-ietf-mmusic-file-transfer-mech-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org We have just submitted a new version of the file transfer document. This version includes a few new paragraphs to satisfy Richard Barnes' comments during the security directorate review. This paragraphs provide recommendations that verify that the properties of a received file match the properties declared in the SDP. Also some reference to authentication and authorization in SIP and MSRP are included. If you are interested in a more detail level of changes, you can ran the diff with version -09 when this new version shows up in tools.ietf.org. /Miguel A new version of I-D, draft-ietf-mmusic-file-transfer-mech-10.txt has been successfuly submitted by Miguel Garcia and posted to the IETF repository. Filename: draft-ietf-mmusic-file-transfer-mech Revision: 10 Title: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Creation_date: 2009-01-22 WG ID: mmusic Number_of_pages: 49 Abstract: This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. The IETF Secretariat. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 22 02:30:03 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4A328C152; Thu, 22 Jan 2009 02:30:03 -0800 (PST) X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7540D3A6A4A; Thu, 22 Jan 2009 02:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090122103001.7540D3A6A4A@core3.amsl.com> Date: Thu, 22 Jan 2009 02:30:01 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-file-transfer-mech-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Author(s) : M. Garcia, et al. Filename : draft-ietf-mmusic-file-transfer-mech-10.txt Pages : 49 Date : 2009-01-22 This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-file-transfer-mech-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22022001.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Mon Jan 26 06:57:07 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C343028C0DB; Mon, 26 Jan 2009 06:57:07 -0800 (PST) X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8015D3A6BAC; Mon, 26 Jan 2009 06:57:06 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090126145706.8015D3A6BAC@core3.amsl.com> Date: Mon, 26 Jan 2009 06:57:06 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: draft-ietf-mmusic-decoding-dependency (Signaling media decoding dependency in Session Description Protocol (SDP)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Signaling media decoding dependency in Session Description Protocol (SDP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-decoding-dependency-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16772&rfc_flag=0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 26 06:58:26 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213B83A6BC4; Mon, 26 Jan 2009 06:58:26 -0800 (PST) X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4D6FC28C20C; Mon, 26 Jan 2009 06:58:25 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090126145825.4D6FC28C20C@core3.amsl.com> Date: Mon, 26 Jan 2009 06:58:25 -0800 (PST) Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: draft-ietf-mmusic-sdp-source-attributes (Source-Specific Media Attributes in the Session Description Protocol (SDP)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Source-Specific Media Attributes in the Session Description Protocol (SDP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attributes-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16762&rfc_flag=0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 26 08:04:31 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593C128C244; Mon, 26 Jan 2009 08:04:31 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D4D28C247 for ; Mon, 26 Jan 2009 08:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.377 X-Spam-Level: X-Spam-Status: No, score=0.377 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, URI_NO_WWW_INFO_CGI=1.043, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVecVty1Y3wI for ; Mon, 26 Jan 2009 08:04:28 -0800 (PST) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 3154128C23B for ; Mon, 26 Jan 2009 08:04:27 -0800 (PST) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1LRTrC-0003xs-GR for mmusic@ietf.org; Mon, 26 Jan 2009 16:58:42 +0100 Message-Id: <9A23FB3F-9C40-4F42-BFBD-149F4A66EBAB@ag-projects.com> From: Adrian Georgescu To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 17:03:59 +0100 References: X-Mailer: Apple Mail (2.930.3) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: [MMUSIC] SIP desktop sharing with draft-garcia-mmusic-sdp-collaboration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Hello, We have successfully implemented desktop sharing application using a variation of draft-garcia-mmusic-sdp-collaboration namely using an MSRP session instead of pure TCP. Here is the relevant negotiated SDP: INVITE sip:2233361709@sip2sip.info SIP/2.0 Record-Route: Via: SIP/2.0/UDP 81.23.228.129;branch=z9hG4bK7ec3.24ae5eb1.0 Via: SIP/2.0/UDP 192.168.1.6 :51891;received=80.101.96.20;rport=51891;branch=z9hG4bKPjcZPkzRl- dkYHaxeakmQLu8i5TDxIARL6 Max-Forwards: 68 From: "Adrian G." ;tag=IjiXUJuaiN03As3HGxf0osjkibdnUtd2 To: sip:2233361709@sip2sip.info Contact: Call-ID: M64kmnwHHuWtiVQl.QaP0svHi.rhI0-N CSeq: 13415 INVITE Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE Supported: 100rel User-Agent: sip2sip-0.4.0-pjsip-1.0.1-r2427 Content-Type: application/sdp Content-Length: 281 Thor-Scope: authenticate Thor-Origin: sip:80.101.96.20:51891 v=0 o=- 3441959219 3441959219 IN IP4 192.168.1.6 s= c=IN IP4 192.168.1.6 t=0 0 m=application 12345 TCP/TLS/MSRP/RFB * a=path:msrps://192.168.1.6:12345/Oj0BcOEf4sim;tcp a=accept-types:message/cpim application/x-rfb a=accept-wrapped-types:application/x-rfb a=setup:active SIP/2.0 200 OK Via: SIP/2.0/UDP 85.17.186.7;branch=z9hG4bK4ec3.220d6d27.0 Via: SIP/2.0/UDP 81.23.228.129;branch=z9hG4bK4ec3.cb13ac42.0 Via: SIP/2.0/UDP 192.168.1.6 : 51891 ;rport=51891;received=80.101.96.20;branch=z9hG4bKPjpf7mDBJxwkWa5hlptKm- Bozt9IGYm01Y Record-Route: Record-Route: Record-Route: Call-ID: M64kmnwHHuWtiVQl.QaP0svHi.rhI0-N From: "Adrian G." ;tag=IjiXUJuaiN03As3HGxf0osjkibdnUtd2 To: ;tag=Qv2lE9YdxHGSmy1O9b534j8jhdKIoErw CSeq: 13416 INVITE Contact: Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE Supported: 100rel User-Agent: ag-projects/sipclient-0.4.0-pjsip-1.0.1-r2427 Content-Type: application/sdp Content-Length: 393 v=0 o=- 3441959219 3441959220 IN IP4 192.168.178.33 s= c=IN IP4 192.168.178.33 t=0 0 m=application 54990 TCP/TLS/MSRP/RFB * a=path:msrps://node03.dns-hosting.info:2855/6dm+f +uC6mgbryTjbHVGEDEyMzI5NzA0MjAuMDU0OjgyLjk1LjE0MS4xMjc=;tcp msrps:// 192.168.178.33:54990/WSucWUOgCOKg;tcp a=accept-types:message/cpim application/x-rfb a=accept-wrapped-types:application/x-rfb a=setup:passive The complete SIP session negotiation (click on each message to expand its content) is here: https://secure.dns-hosting.info/CDRTool/sip_trace.phtml?cdr_source=sip_trace_thor&callid=M64kmnwHHuWtiVQl.QaP0svHi.rhI0-N&fromtag=IjiXUJuaiN03As3HGxf0osjkibdnUtd2&totag=Qv2lE9YdxHGSmy1O9b534j8jhdKIoErw&proxyIP=85.17.186.7&public=1 More information and the software is available at: http://lists.ag-projects.com/mailman/listinfo/sipclient I am wondering if it makes sense to mention the MSRP/TLS transport as a valid option for negotiating/transporting in the draft. Kind regards, Adrian Georgescu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 26 14:51:25 2009 Return-Path: X-Original-To: mmusic-archive@megatron.ietf.org Delivered-To: ietfarch-mmusic-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E59E28C167; Mon, 26 Jan 2009 14:51:25 -0800 (PST) X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D768C28C167 for ; Mon, 26 Jan 2009 14:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghBYGHfVF+ST for ; Mon, 26 Jan 2009 14:51:22 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 6FF3F28C14D for ; Mon, 26 Jan 2009 14:51:22 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n0QMp3Jd018411 for ; Mon, 26 Jan 2009 16:51:03 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.4]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 16:51:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jan 2009 16:51:02 -0600 Message-ID: <077439DFC93C83439E56A4EBDA4FF794021B4317@ILEXC1U02.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on media routing with ALGs Thread-Index: AcmACJBxY7pPRizpRHC7YF9cWXGbLA== From: "Ejzak, Richard P \(Richard\)" To: X-OriginalArrivalTime: 26 Jan 2009 22:51:03.0482 (UTC) FILETIME=[90D631A0:01C98008] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [MMUSIC] new draft on media routing with ALGs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0029332911==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0029332911== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98008.90B6EE0B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98008.90B6EE0B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, Please comment on the following draft, which was submitted to improve media routing when interconnecting SIP networks using ALGs. Work on this draft was triggered by a 3GPP Release 9 work item on "optimal media routing", which is documented in 3GPP TR 23.894. =20 http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-bg-bypass-00.txt =20 This is the abstract from the draft: =20 "This document describes an extension to the Session Description Protocol (SDP) that can be used by systems of cooperating networks using Application Level Gateways (ALG) to insert border gateways performing as Network Address Port Translators (NAPT) between their IP realms to identify when border gateways can be bypassed for more efficient media flow. This extension can be used by networks based on a protocol using the SDP offer/answer model, such as the IP Multimedia Subsystem (IMS) of the Third Generation Partnership Project (3GPP), which is based on the Session Initiation Protocol (SIP). ALGs using this extension can determine within a single SDP offer/answer transaction when the insertion of a new border gateway would cause the media path to re-enter an IP realm visited elsewhere within the media path, and to bypass one or more border gateways that would otherwise be included in the media path. This extension also works with hosted NAPT traversal schemes to establish a direct media path between endpoints within the same IP realm. Optional procedures provide additional means to improve media flow." =20 BR, Richard Ejzak Alcatel-Lucent ------_=_NextPart_001_01C98008.90B6EE0B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello,
Please = comment on=20 the following draft, which was submitted to improve media routing when=20 interconnecting SIP networks using ALGs.  Work on this draft was = triggered=20 by a 3GPP Release 9 work item on "optimal media routing", which is = documented in=20 3GPP TR 23.894.
 
http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-bg-bypass-= 00.txt
 
This = is the abstract=20 from the draft:
 
"This document=20 describes an extension to the Session Description Protocol (SDP) that can be used by systems of = cooperating networks using = Application=20 Level Gateways (ALG) to insert border gateways performing as Network Address Port = Translators (NAPT)=20 between their IP realms to = identify when=20 border gateways can be bypassed for more efficient media flow.  This extension = can be used=20 by networks based on a protocol = using the=20 SDP offer/answer model, such as the IP Multimedia Subsystem (IMS) of the Third = Generation=20 Partnership Project (3GPP), = which is based=20 on the Session Initiation Protocol (SIP).  ALGs using this extension can = determine=20 within a single SDP offer/answer = transaction when the insertion of a new border gateway would cause the media path to re-enter an IP = realm=20 visited elsewhere within the media path, and to bypass one or more = border=20 gateways that would otherwise be = included=20 in the media path.  This extension also works with hosted NAPT traversal schemes = to=20 establish a direct media path = between=20 endpoints within the same IP realm.  Optional procedures provide additional means to = improve media=20 flow."
 
BR, Richard Ejzak
Alcatel-Lucent
------_=_NextPart_001_01C98008.90B6EE0B-- --===============0029332911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --===============0029332911==--