From bgreeven@huawei.com Thu Mar 3 01:00:49 2011 Return-Path: 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 94DC23A6964 for ; Thu, 3 Mar 2011 01:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 vuyVFIAz2qAq for ; Thu, 3 Mar 2011 01:00:48 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4C1273A6995 for ; Thu, 3 Mar 2011 01:00:47 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH00D3V50OPG@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 03 Mar 2011 17:00:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH00M5250OJ4@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 03 Mar 2011 17:00:24 +0800 (CST) Received: from z00127286a ([10.70.109.54]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHH00DQZ50JLM@szxml04-in.huawei.com> for mmusic@ietf.org; Thu, 03 Mar 2011 17:00:24 +0800 (CST) Date: Thu, 03 Mar 2011 17:00:19 +0800 From: Bert Greevenbosch To: mmusic@ietf.org Message-id: <000001cbd981$6c3d0ce0$44b726a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_i0zQF8GyVUiGK3uK/g6Kvg)" Content-language: en-gb Thread-index: AcvZgWwLF6HsBt67TlyTKhi9bV4hMQ== Subject: [MMUSIC] Upload of draft-greevenbosch-mmusic-signal-3d-format 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: , X-List-Received-Date: Thu, 03 Mar 2011 09:00:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_i0zQF8GyVUiGK3uK/g6Kvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, I have uploaded an individual draft "draft-greevenbosch-mmusic-signal-3d-format". The draft concerns streaming in 3D. More precisely, it defines a new 3dFormat attribute in SDP, which is used to signal the format of streamed stereoscopic 3D video. It includes signalling for various frame packing styles, multicast of left and right views, and 2D + auxiliary data. The draft can be accessed under the following link: https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ I look forward to your comments. Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bgreeven@huawei.com telephone: +86-755-28978088 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian Longgang Shenzhen 518129 P.R. China **************************************************************************** *** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ** --Boundary_(ID_i0zQF8GyVUiGK3uK/g6Kvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

I have uploaded an individual draft "draft-greevenbosch-mmusic-signal-3d-format".

 

The draft concerns streaming in 3D. More precisely, it defines a new 3dFormat attribute in SDP, which is used to signal the format of streamed stereoscopic 3D video. It includes signalling for various frame packing styles, multicast of left and right views, and 2D + auxiliary data.

 

The draft can be accessed under the following link:

https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/

 

I look forward to your comments.

 

Best regards,

Bert

 

---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bgreeven@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian Longgang

Shenzhen  518129

P.R. China

 

*******************************************************************************

This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!

******************************************************************************

 

--Boundary_(ID_i0zQF8GyVUiGK3uK/g6Kvg)-- From tom111.taylor@bell.net Thu Mar 3 05:40:50 2011 Return-Path: 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 B48A03A67DB for ; Thu, 3 Mar 2011 05:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] 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 ymbwRr7PlV+G for ; Thu, 3 Mar 2011 05:40:50 -0800 (PST) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 07EA13A67BD for ; Thu, 3 Mar 2011 05:40:49 -0800 (PST) Received: from BLU0-SMTP33 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 05:41:57 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP33.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 05:41:57 -0800 Date: Thu, 3 Mar 2011 08:42:00 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2011 13:41:57.0058 (UTC) FILETIME=[C3A95A20:01CBD9A8] Cc: Flemming Andreasen Subject: [MMUSIC] Stepping down as Chair 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: , X-List-Received-Date: Thu, 03 Mar 2011 13:40:50 -0000 In the last few months I have found myself swamped and unable to perform the duties of MMUSIC Chair. I am sorry I have let down the Working Group at large as well as my co-Chair Flemming. I am pleased to say that a replacement Chair has been found. Please welcome Miguel Angel Garcia as your new MMUSIC co-Chair. Tom Taylor From fandreas@cisco.com Thu Mar 3 08:59:49 2011 Return-Path: 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 52EDA3A69FF for ; Thu, 3 Mar 2011 08:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vHlwLdjGJSUH for ; Thu, 3 Mar 2011 08:59:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 26AC83A67F1 for ; Thu, 3 Mar 2011 08:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=2579; q=dns/txt; s=iport; t=1299171656; x=1300381256; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Iul8wYo2vSH7HRiYqfF4z4J5xBpcBjca8Mnltn67aq8=; b=jAKOuxx5Xb4Kfzk0ZNBmUmqW0mA9srF+83sqbJxDYbq2mmW67DqKN4IM ko+u5JA+MoGFtD/0TxCCnx6LRGohYm+lAb35ddo273cYB0za1+Ubd6u5m 8ixtXHHAfTmfLAC5HrtymBKLUkYnc/qboVDtVW74ATfxIyaYMwMZDeL9X o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKJXb01AZnwN/2dsb2JhbACiBIRgdKJrnCCFYQSFGocS X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208,217";a="222289175" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2011 17:00:53 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p23H0riE009300; Thu, 3 Mar 2011 17:00:53 GMT Message-ID: <4D6FC9F5.4070502@cisco.com> Date: Thu, 03 Mar 2011 12:03:49 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Tom Taylor References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030405020005080406080702" Cc: mmusic Subject: Re: [MMUSIC] Stepping down as Chair 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: , X-List-Received-Date: Thu, 03 Mar 2011 16:59:49 -0000 This is a multi-part message in MIME format. --------------030405020005080406080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/3/11 8:42 AM, Tom Taylor wrote: > > In the last few months I have found myself swamped and unable to perform > the duties of MMUSIC Chair. I am sorry I have let down the Working Group > at large as well as my co-Chair Flemming. > Not at all Tom - you are a long time IETF contributor and have provided very helpful guidance to me as a co-chair, so I would like to take the opportunity to thank you for that. > I am pleased to say that a replacement Chair has been found. Please > welcome Miguel Angel Garcia as your new MMUSIC co-Chair. > Welcome Miguel - glad to have you on board. Thanks -- Flemming > Tom Taylor > --------------030405020005080406080702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/3/11 8:42 AM, Tom Taylor wrote:
Stepping down as Chair

In the last few months I have found myself swamped and unable to perform
the duties of MMUSIC Chair. I am sorry I have let down the Working Group
at large as well as my co-Chair Flemming.

Not at all Tom - you are a long time IETF contributor and have provided very helpful guidance to me as a co-chair, so I would like to take the opportunity to thank you for that.

I am pleased to say that a replacement Chair has been found. Please
welcome Miguel Angel Garcia as your new MMUSIC co-Chair.

Welcome Miguel - glad to have you on board.

Thanks

-- Flemming

Tom Taylor

--------------030405020005080406080702-- From miguel.a.garcia@ericsson.com Thu Mar 3 09:05:38 2011 Return-Path: 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 E67093A6A14 for ; Thu, 3 Mar 2011 09:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fDKaVELU3onK for ; Thu, 3 Mar 2011 09:05:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B61523A6A0C for ; Thu, 3 Mar 2011 09:05:37 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-17-4d6fcaa42f48 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 23.D1.21265.4AACF6D4; Thu, 3 Mar 2011 18:06:45 +0100 (CET) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.1.168]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 3 Mar 2011 18:06:44 +0100 From: Miguel Garcia A To: Flemming Andreasen , Tom Taylor Date: Thu, 3 Mar 2011 18:04:55 +0100 Thread-Topic: [MMUSIC] Stepping down as Chair Thread-Index: AcvZxJOlr20UlJBLRDG2CJZ0LjNVpgAAIpkl Message-ID: References: , <4D6FC9F5.4070502@cisco.com> In-Reply-To: <4D6FC9F5.4070502@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: Re: [MMUSIC] Stepping down as Chair 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: , X-List-Received-Date: Thu, 03 Mar 2011 17:05:39 -0000 Thank you guys. I want to thank Tom for the work done in the past. I hope I will do it as w= ell as you. /Miguel ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Flemmi= ng Andreasen [fandreas@cisco.com] Sent: Thursday, March 03, 2011 6:03 PM To: Tom Taylor Cc: mmusic Subject: Re: [MMUSIC] Stepping down as Chair On 3/3/11 8:42 AM, Tom Taylor wrote: In the last few months I have found myself swamped and unable to perform the duties of MMUSIC Chair. I am sorry I have let down the Working Group at large as well as my co-Chair Flemming. Not at all Tom - you are a long time IETF contributor and have provided ver= y helpful guidance to me as a co-chair, so I would like to take the opportu= nity to thank you for that. I am pleased to say that a replacement Chair has been found. Please welcome Miguel Angel Garcia as your new MMUSIC co-Chair. Welcome Miguel - glad to have you on board. Thanks -- Flemming Tom Taylor From abegen@cisco.com Mon Mar 7 12:44:41 2011 Return-Path: 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 59ECE3A67A1 for ; Mon, 7 Mar 2011 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.547 X-Spam-Level: X-Spam-Status: No, score=-10.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 LwVRetUVn1Ws for ; Mon, 7 Mar 2011 12:44:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 99B673A659C for ; Mon, 7 Mar 2011 12:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=390; q=dns/txt; s=iport; t=1299530752; x=1300740352; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=nAuLa0FxgVx9qZwb+IoD2oQ4BSvP5iBHndzNAvuuAeA=; b=ggMLq2KCbcd37qcnBCxCiC1/7wVYmHoyR0eDzsRQLL7tt+cSB6SSj6Lq Ec5KChDMh+pkO+HzO6J0VlDqAOTFORLtltAElSsPBltOvZ4J88pQ+C4EK QaUM3Jsq3CBEbWXw8p4+EnLdRZWVszqh1W7RWs2Jd5rJBSR5NqYiWlDlH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUIAOHSdE2rRN+K/2dsb2JhbACYT44IdKJAm3qFYgSFHIpd X-IronPort-AV: E=Sophos;i="4.62,278,1297036800"; d="scan'208";a="341827887" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2011 20:45:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p27KjVHU023238 for ; Mon, 7 Mar 2011 20:45:31 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 12:45:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 12:45:24 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E7616A5@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two new drafts on redundant media streams Thread-Index: AcvdCFV4SdefuVX9QCum97sIXr7IBA== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 07 Mar 2011 20:45:31.0120 (UTC) FILETIME=[99467700:01CBDD08] Cc: "Heidi Ou \(hou\)" , "Yiqun Cai \(ycai\)" Subject: [MMUSIC] Two new drafts on redundant media streams 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: , X-List-Received-Date: Mon, 07 Mar 2011 20:44:41 -0000 We have submitted two new drafts for describing redundant media streams = in SDP. https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= /=20 https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ = Comments and feedback are welcome. We will request a presentation slot = for these two drafts in the upcoming meeting. Thanks. -acbegen From Internet-Drafts@ietf.org Wed Mar 9 04:30:03 2011 Return-Path: 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 432393A699F; Wed, 9 Mar 2011 04:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VEBhXZDgvs6R; Wed, 9 Mar 2011 04:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CC33A695F; Wed, 9 Mar 2011 04:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110309123002.22817.6385.idtracker@localhost> Date: Wed, 09 Mar 2011 04:30:02 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-27.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: , X-List-Received-Date: Wed, 09 Mar 2011 12:30:03 -0000 --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 : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-mmusic-rfc2326bis-27.txt Pages : 296 Date : 2011-03-09 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-27.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-rfc2326bis-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09042927.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Wed Mar 9 04:37:09 2011 Return-Path: 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 474B93A695E for ; Wed, 9 Mar 2011 04:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hshuACill7mr for ; Wed, 9 Mar 2011 04:37:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D93C53A6813 for ; Wed, 9 Mar 2011 04:37:07 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-4f-4d7774bf4395 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AF.A3.09202.FB4777D4; Wed, 9 Mar 2011 13:38:23 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Wed, 9 Mar 2011 13:38:22 +0100 Message-ID: <4D7774BF.4000607@ericsson.com> Date: Wed, 9 Mar 2011 13:38:23 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20110309123002.22817.6385.idtracker@localhost> In-Reply-To: <20110309123002.22817.6385.idtracker@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-27.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: , X-List-Received-Date: Wed, 09 Mar 2011 12:37:09 -0000 Hi, As the diff will show: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-27 this is a very minor update. It does two things. 1. Fixed the bug Ross Finnlayson pointed out. 2. Resolved some bad formating around some references. Cheers Magnus Internet-Drafts@ietf.org skrev 2011-03-09 13:30: > 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 : Real Time Streaming Protocol 2.0 (RTSP) > Author(s) : H. Schulzrinne, et al. > Filename : draft-ietf-mmusic-rfc2326bis-27.txt > Pages : 296 > Date : 2011-03-09 > > This memorandum defines RTSP version 2.0 which obsoletes RTSP version > 1.0 which is defined in RFC 2326. > > The Real Time Streaming Protocol, or RTSP, is an application-level > protocol for setup and control of the delivery of data with real-time > properties. RTSP provides an extensible framework to enable > controlled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 3550). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-27.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. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F鋜鰃atan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Simo.Veikkolainen@nokia.com Thu Mar 10 02:38:25 2011 Return-Path: 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 E37353A68D7 for ; Thu, 10 Mar 2011 02:38:25 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 EELjW5TDllXJ for ; Thu, 10 Mar 2011 02:38:25 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id A4B2B3A67A7 for ; Thu, 10 Mar 2011 02:38:24 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2AAdWeQ005585; Thu, 10 Mar 2011 12:39:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 12:38:34 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Mar 2011 11:38:34 +0100 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Thu, 10 Mar 2011 11:38:33 +0100 From: To: Thread-Topic: I-D Action:draft-mmusic-sdp-icap-bcap-01.txt Thread-Index: AQHL3jzUETn0jbsj9UOvKxExnNUCRZQmYT+g Date: Thu, 10 Mar 2011 10:38:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.162.58.206] Content-Type: multipart/mixed; boundary="_003_F9E2FDAF48D4544F874A56A3A8BD68B1010AE6BF008AM1MPN1002mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2011 10:38:34.0744 (UTC) FILETIME=[4EA9B780:01CBDF0F] X-Nokia-AV: Clean Subject: [MMUSIC] FW: I-D Action:draft-mmusic-sdp-icap-bcap-01.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: , X-List-Received-Date: Thu, 10 Mar 2011 10:38:26 -0000 --_003_F9E2FDAF48D4544F874A56A3A8BD68B1010AE6BF008AM1MPN1002mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, A new version of the SDP capability neg extensions for "b=3D" and "i=3D" li= nes is now available at: http://www.ietf.org/internet-drafts/draft-mmusic-sdp-icap-bcap-01.txt Changes in this version are: - clarified the usage of bcap and icap attributes when declared at session = level vs. at media level (they now result in session level, and media level= b/i-lines, respectively) - added an Offer/answer section - added some text to security considerations - editorial cleanup Regards, Simo -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of ext Internet-Drafts@ietf.org Sent: 09 March, 2011 11:30 To: i-d-announce@ietf.org Subject: I-D Action:draft-mmusic-sdp-icap-bcap-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Title and Bandwidth Capabilities Negotiation in the Sess= ion Description Protocol (SDP) Author(s) : M. Garcia, et al. Filename : draft-mmusic-sdp-icap-bcap-01.txt Pages : 16 Date : 2011-03-09 SDP has been extended with a capability negotiation mechanism framework tha= t allows the endpoints to negotiate transport protocols and attributes. Th= is framework has been extended with a media capabilities negotiation mechan= ism that allows endpoints to negotiate additional media-related capabilitie= s. This negotiation is embedded into the widely-used SDP offer/answer proc= edures. This memo extends the SDP capability negotiation framework to allow endpoin= ts to negotiate two additional SDP capabilities. In particular, this memo = provides a mechanism to negotiate titles ("i=3D" line for each session or media) and bandwidth ("b=3D" line). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mmusic-sdp-icap-bcap-01.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. --_003_F9E2FDAF48D4544F874A56A3A8BD68B1010AE6BF008AM1MPN1002mg_ Content-Type: message/external-body; name="draft-mmusic-sdp-icap-bcap-01.url" Content-Description: draft-mmusic-sdp-icap-bcap-01.url Content-Disposition: attachment; filename="draft-mmusic-sdp-icap-bcap-01.url"; size=94; creation-date="Wed, 09 Mar 2011 09:31:56 GMT"; modification-date="Wed, 09 Mar 2011 09:31:56 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tbXVzaWMtc2RwLWljYXAtYmNhcC0wMS50eHQNCg== --_003_F9E2FDAF48D4544F874A56A3A8BD68B1010AE6BF008AM1MPN1002mg_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Wed, 09 Mar 2011 09:31:56 GMT"; modification-date="Wed, 09 Mar 2011 09:31:56 GMT" Content-ID: <60594C980FBA044B9CFE87A2B187E4AA@nokia.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_F9E2FDAF48D4544F874A56A3A8BD68B1010AE6BF008AM1MPN1002mg_-- From jf.mule@cablelabs.com Thu Mar 10 06:58:23 2011 Return-Path: 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 618D03A69F2 for ; Thu, 10 Mar 2011 06:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] 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 6R-ljedoQLWn for ; Thu, 10 Mar 2011 06:58:22 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id AAC0D3A69E0 for ; Thu, 10 Mar 2011 06:58:22 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p2AExZ7v017025; Thu, 10 Mar 2011 07:59:35 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 10 Mar 2011 07:59:35 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 10 Mar 2011 07:59:36 -0700 From: Jean-Francois Mule To: Tom Taylor , Miguel Garcia A Date: Thu, 10 Mar 2011 07:59:33 -0700 Thread-Topic: [MMUSIC] Stepping down as Chair Thread-Index: AcvfM8VNfM46hCVqSHOCsuojfsNUkA== Message-ID: <22437F05-7372-44A8-9AAD-334CB6FD66AE@cablelabs.com> References: , <4D6FC9F5.4070502@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-121--660573575"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Approved: ondar Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Stepping down as Chair 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: , X-List-Received-Date: Thu, 10 Mar 2011 14:58:23 -0000 --Apple-Mail-121--660573575 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you for your service Tom and I'd echo Flemming: you did not let = the wg done, certainly not when we worked together. Miguel - glad to see you in this new role, terrific. Jean-Francois. jfm@cablelabs.com On Mar3 2011, at 18:04, Miguel Garcia A wrote: > Thank you guys. >=20 > I want to thank Tom for the work done in the past. I hope I will do it = as well as you. >=20 > /Miguel --Apple-Mail-121--660573575 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILGzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY2MIIFHqAD AgECAhA9HnQKdVj5xlxonWZwaMawMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEwMDkyMzAwMDAw MFoXDTExMDkyMzIzNTk1OVowgeMxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0gUEVS U09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1c2U6 IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAzIENvbW9k byBMaW1pdGVkMRswGQYDVQQDExJKZWFuLUZyYW5jb2lzIE11bGUxJDAiBgkqhkiG9w0BCQEWFWpm Lm11bGVAY2FibGVsYWJzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKclKDkU DonymiJaORTjw7A6FNj40PB6grEezK2fOlqPFXCHPdhqGwSdnXmxxr6jNd5XiDSCpbh2AvkJM5hh 5REA0SIwY7A3w8IyW0eI57glJHk9sWAVLs3ZqWyqCPaeBYB7Q3XUkpY64zQAY12bBwmkP0i6XYmk QUKKpAxLPjHu62llk2fNTP3jwk15mzVXqE83xhsqQ3KnCM2xwOoaRotc6CyAp/AYTG+ZVmWfvJke EkiMzD/uFyRm+gov3KPstes4xNOl4SXxqSgKBzOZd/0eGI435EENlbgoSFyK20oWEoaAZIUP7gxu RHUqYvJbkriZ4513YqG8Xa/CxadgkacCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZw AEu0UEh83j2uBG59MB0GA1UdDgQWBBQnZKzclKfFGsX1xRQSd+YsA0Jh4zAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFp bC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0 cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVamYubXVsZUBjYWJsZWxhYnMuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQCttz0iAYDzPiRMsnFraght0i71vyRrGX8u4rtqprHlrMf3YNDdUakH qPVWp3k/vbIUM+zH3R8D8cWVuch+MpkY/KUxd+Ah3SAApOaSi23+wpEL2n67pHz7/DYGDVnYzqZY luBot3SvbQeKY/UUp1cX9/cV7YMNn1IzzMQnw+Yjcbmt1F/ZamQHhRXcNtrP4l9/ucXHcuzC+klz TzLUj5bfSxDk7vSF8zAQunKIfoDmzev/kgs7Rs4R1FzWjdoKr03gYSSiAg6wRpf1rUdZXwsMkPB/ GbWrhNbCr0IDEfk/ZDI4r+/RuV2Q0+OuEvJ9+UdJuOs7ygGCon5+iI9kuLXXMYID/DCCA/gCAQEw gcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2Vy dHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgRW1haWwCED0edAp1WPnGXGidZnBoxrAwCQYFKw4DAhoFAKCCAg0wGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMzEwMTQ1OTMzWjAjBgkqhkiG9w0BCQQxFgQU vhmlwWHlf2SRwGUhHsqiVaIreTUwgdQGCSsGAQQBgjcQBDGBxjCBwzCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQPR50CnVY+cZc aJ1mcGjGsDCB1gYLKoZIhvcNAQkQAgsxgcaggcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCED0edAp1WPnGXGidZnBoxrAwDQYJ KoZIhvcNAQEBBQAEggEAO0AIs0U3Mkow0QHO97SOlcM9PmDjqfhBldGpe4rs+0r65BXykxe6giI2 NWV/aKVlQ57p8TzDK966AXCIPqxJbQEi2lO/xBEZ6iPDsZBbf6IsMTnzC9r97wh5G8I0S21DGtWO D0TirSE5LSnj/vUrXOiBHzoX5E18fyX+m3laRSWlFJrhncRQNMNc1KqdaOtTu2O/HnJapoH1pMSL vrNkadftVRRt9+E1R0sEaBncST/bDhvCxAfDa2db0kX734hC8CZ/kT5CRMlQAM5KIaiedFkMmO/s 1mknUH0HWKRBfLYTHN6hefFRebwn0BsY8NwXnE12MvM4AO1z5mouxmmhXgAAAAAAAA== --Apple-Mail-121--660573575-- From fluffy@cisco.com Thu Mar 10 07:47:12 2011 Return-Path: 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 A264A3A69E6 for ; Thu, 10 Mar 2011 07:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.383 X-Spam-Level: X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 4XBfG5NRrSvc for ; Thu, 10 Mar 2011 07:47:11 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B5AB83A69CC for ; Thu, 10 Mar 2011 07:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=110; q=dns/txt; s=iport; t=1299772109; x=1300981709; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5nesZHrmIGCRPjWQ0jvEC3VlZhZGw9Z+qF8OwLicLAQ=; b=bqmhoxAb8lcbb3g5oZFq36JsEeE2YAmdE/zWFRTQZxZogqHVxvUSAsQq O//TOq63QLUxdXo0dXkeuNzPzmYZoICNV7p1tYP3TNCaMpySx+m6ZnTvs GSc2s6XKAfcasetyOKE9U8Zls5Wjdh8CDZkas+Ih0zFRVgXZfuAGATrO9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH6BeE2rR7Ht/2dsb2JhbACmKHeIQQGcDpw7hWIEhSSHH4NK X-IronPort-AV: E=Sophos;i="4.62,296,1297036800"; d="scan'208";a="413398834" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2011 15:48:29 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p2AFmSEA020980; Thu, 10 Mar 2011 15:48:29 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 Mar 2011 08:51:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FCF8246-110E-44BD-B308-E7913DAEAF4B@cisco.com> References: To: Tom Taylor X-Mailer: Apple Mail (2.1082) Cc: MMUSIC WG Subject: Re: [MMUSIC] Stepping down as Chair 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: , X-List-Received-Date: Thu, 10 Mar 2011 15:47:12 -0000 Tom,=20 I wanted to thank you for all the work you have done over the years as a = Chair.=20 Cullen From fandreas@cisco.com Thu Mar 10 18:10:25 2011 Return-Path: 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 1FF7F3A6820 for ; Thu, 10 Mar 2011 18:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FFrGSf+ahOgx for ; Thu, 10 Mar 2011 18:10:24 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 479303A6B18 for ; Thu, 10 Mar 2011 18:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=642; q=dns/txt; s=iport; t=1299809497; x=1301019097; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=H7ityogI9MjeIr1C+fcE+s4yov/a6eDnQHxYxMearaM=; b=QfTNFnwEvDMh5ZbVybviOZITYqBsUq14xOUWGmpG/IwtRKJaC6s59DTG sOGdVjSVdroP+r1c8gvzsKyRnMHyQIM1XbvePX+1GD7ueCTfQrdWtMSfI ee54gtqAq9M3WPBDT4C/zSwIWYpae9qdAAnpxUIkUnWHbbRM/NZWnxc97 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMkTeU2tJXG9/2dsb2JhbACmNXelMZw2hWIEhSSHHw X-IronPort-AV: E=Sophos;i="4.62,300,1297036800"; d="scan'208";a="344098845" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2011 02:11:36 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2B2BZHs002187 for ; Fri, 11 Mar 2011 02:11:36 GMT Message-ID: <4D798594.4000406@cisco.com> Date: Thu, 10 Mar 2011 21:14:44 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Fri, 11 Mar 2011 02:10:25 -0000 We currently have a MMUSIC milestone for "considerations for using SDP offer/answer with middleboxes". The latest draft for this WG item is draft-ietf-mmusic-media-path-middleboxes-03.txt which expired in January 2011. There hasn't been much discussion on this topic for a while, and the current draft authors are not planning continued work on the draft, so we need new authors if we are to continue with this WG item. Please let us know if 1) You are still interested in this deliverable 2) You are willing to actively contribute to and/or author this document. Thanks Flemming & Miguel [MMUSIC chairs] From fandreas@cisco.com Thu Mar 10 19:24:54 2011 Return-Path: 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 2EEF03A6B5D for ; Thu, 10 Mar 2011 19:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 82fMaNvbUuIU for ; Thu, 10 Mar 2011 19:24:52 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2BB833A6B16 for ; Thu, 10 Mar 2011 19:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=1449; q=dns/txt; s=iport; t=1299813971; x=1301023571; h=message-id:date:from:mime-version:to:cc:subject; bh=GLbYrRG29/3EYUmJf3x1daYjQPtShToP/wH4FPyBpkY=; b=Uf61iwADp2Esx5IdmwJ3FK/30623zgrImHwVPvYYpNFEk3ua4j2JjeNM cEuEsu7J6m4NGkMSmw0VEbwRT48CnMp1JPixoQZEY7PICAu+LmcYXR4I2 xeaVujfm7ICQ+QYT+28T4vP9rXhRnr0eHMuwN8du6ycsPpyUU4L/vmHAl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFMleU2tJXHB/2dsb2JhbACCW58OhEx3pQOcLoViBIUkhx8 X-IronPort-AV: E=Sophos;i="4.62,300,1297036800"; d="scan'208,217";a="344130080" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2011 03:26:09 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2B3Q9xJ029963; Fri, 11 Mar 2011 03:26:09 GMT Message-ID: <4D79970D.5000708@cisco.com> Date: Thu, 10 Mar 2011 22:29:17 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------050306080300090506080206" Subject: [MMUSIC] Looking for new author for Revised SDP specification (rfc4566bis) 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: , X-List-Received-Date: Fri, 11 Mar 2011 03:24:54 -0000 This is a multi-part message in MIME format. --------------050306080300090506080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings We have a MMUSIC milestone for a revised SDP specification (RFC 4566 Errata and other clarifications and bug fixes), however the author is no longer working on it, and hence we are looking for a new author. If you are well versed in SDP and would like to volunteer for this, please let the chairs know. Thanks Flemming & Miguel [MMUSIC chairs] --------------050306080300090506080206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

We have a MMUSIC milestone for a revised SDP specification (RFC 4566 Errata and other clarifications and bug fixes), however the author is no longer working on it, and hence we are looking for a new author. If you are well versed in SDP and would like to volunteer for this, please let the chairs know.

Thanks

    Flemming & Miguel [MMUSIC chairs]


--------------050306080300090506080206-- From tianlinyi@huawei.com Fri Mar 11 00:53:32 2011 Return-Path: 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 7677F3A6BAE for ; Fri, 11 Mar 2011 00:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 JEHYnWhITjzq for ; Fri, 11 Mar 2011 00:53:31 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B32F43A6BAD for ; Fri, 11 Mar 2011 00:53:30 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHV005XBY2YBQ@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 11 Mar 2011 16:54:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHV00CX8Y2YOX@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 11 Mar 2011 16:54:34 +0800 (CST) Received: from T34932F ([10.70.109.73]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHV00HP0Y2Y3B@szxml06-in.huawei.com> for mmusic@ietf.org; Fri, 11 Mar 2011 16:54:34 +0800 (CST) Date: Fri, 11 Mar 2011 16:54:34 +0800 From: Linyi Tian In-reply-to: <000001cbd981$6c3d0ce0$44b726a0$@com> To: 'Bert Greevenbosch' , mmusic@ietf.org Message-id: <000901cbdfc9$f1c8a470$d559ed50$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XCbcxM0gcb8AmttzxWRIuw)" Content-language: zh-cn Thread-index: AcvZgWwLF6HsBt67TlyTKhi9bV4hMQGSFYdw References: <000001cbd981$6c3d0ce0$44b726a0$@com> Subject: [MMUSIC] Did anybody read these drafts related to 3D signaling? RE: Upload of draft-greevenbosch-mmusic-signal-3d-format 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: , X-List-Received-Date: Fri, 11 Mar 2011 08:53:32 -0000 这是一封 MIME 格式的多部分邮件。 --Boundary_(ID_XCbcxM0gcb8AmttzxWRIuw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, All I think the topic is interesting and the MMusic Folks could help to improve. Cheers, Linyi From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bert Greevenbosch Sent: Thursday, March 03, 2011 5:00 PM To: mmusic@ietf.org Subject: [MMUSIC] Upload of draft-greevenbosch-mmusic-signal-3d-format Hello all, I have uploaded an individual draft "draft-greevenbosch-mmusic-signal-3d-format". The draft concerns streaming in 3D. More precisely, it defines a new 3dFormat attribute in SDP, which is used to signal the format of streamed stereoscopic 3D video. It includes signalling for various frame packing styles, multicast of left and right views, and 2D + auxiliary data. The draft can be accessed under the following link: https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ I look forward to your comments. Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bgreeven@huawei.com telephone: +86-755-28978088 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian Longgang Shenzhen 518129 P.R. China **************************************************************************** *** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ** --Boundary_(ID_XCbcxM0gcb8AmttzxWRIuw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, All

 

I think the topic is interesting and the MMusic Folks could help to improve.

 

Cheers,

Linyi

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bert Greevenbosch
Sent: Thursday, March 03, 2011 5:00 PM
To: mmusic@ietf.org
Subject: [MMUSIC] Upload of draft-greevenbosch-mmusic-signal-3d-format

 

Hello all,

 

I have uploaded an individual draft "draft-greevenbosch-mmusic-signal-3d-format".

 

The draft concerns streaming in 3D. More precisely, it defines a new 3dFormat attribute in SDP, which is used to signal the format of streamed stereoscopic 3D video. It includes signalling for various frame packing styles, multicast of left and right views, and 2D + auxiliary data.

 

The draft can be accessed under the following link:

https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/

 

I look forward to your comments.

 

Best regards,

Bert

 

---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bgreeven@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian Longgang

Shenzhen  518129

P.R. China

 

*******************************************************************************

This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!

******************************************************************************

 

--Boundary_(ID_XCbcxM0gcb8AmttzxWRIuw)-- From john.elwell@siemens-enterprise.com Fri Mar 11 02:17:00 2011 Return-Path: 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 BD2C63A6817 for ; Fri, 11 Mar 2011 02:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 lXZQ134NJIxI for ; Fri, 11 Mar 2011 02:17:00 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A74C03A67B0 for ; Fri, 11 Mar 2011 02:16:59 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3706377; Fri, 11 Mar 2011 11:18:06 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 706DA23F0278; Fri, 11 Mar 2011 11:18:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 11 Mar 2011 11:18:06 +0100 From: "Elwell, John" To: Flemming Andreasen , mmusic Date: Fri, 11 Mar 2011 11:18:04 +0100 Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? Thread-Index: Acvfka1kUPmSmXYmTCmx7wyfNYtPBwAQ5plg Message-ID: References: <4D798594.4000406@cisco.com> In-Reply-To: <4D798594.4000406@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Fri, 11 Mar 2011 10:17:00 -0000 Flemming, According to my records, this went through WGLC a couple of years ago, so p= erhaps the silence is due to the fact the WG believes the document is finis= hed. What exactly is the situation - were there unresolved comments from WG= LC? I am not offering to contribute actively on this - just curious. John =20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer=20 > with middleboxes ? >=20 > We currently have a MMUSIC milestone for "considerations for=20 > using SDP=20 > offer/answer with middleboxes". The latest draft for this WG item is >=20 > draft-ietf-mmusic-media-path-middleboxes-03.txt >=20 > which expired in January 2011. There hasn't been much=20 > discussion on this=20 > topic for a while, and the current draft authors are not planning=20 > continued work on the draft, so we need new authors if we are to=20 > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author=20 > this document. >=20 > Thanks >=20 > Flemming & Miguel [MMUSIC chairs] >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From fandreas@cisco.com Fri Mar 11 08:42:16 2011 Return-Path: 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 3C0543A6A38 for ; Fri, 11 Mar 2011 08:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 eX6Ie8vwseY2 for ; Fri, 11 Mar 2011 08:42:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 385823A6A32 for ; Fri, 11 Mar 2011 08:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=6654; q=dns/txt; s=iport; t=1299861814; x=1301071414; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=F1AvEb4BjnHBKwZeymGsCPxTDNKHyG89oVQ4ZqVi4qs=; b=QrQ5xLZQmVQXjZB9JxYzdNnqTps204VzGf3JN8oHvNWioeUqrzDCcY5s 5NLrDG8TFqbrq2Li2VjXILw5JTzgiLh8ENkjVDhh/IrTyr9C1W2N/DRU+ FrpFxC1AsUKcfoQ2ZRynyL6F079qc5+poUNW0XySQHpzCYQqq4DkXjy5u U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKffeU2tJV2b/2dsb2JhbAChZoRLd6V/nDGFYgSFKYcm X-IronPort-AV: E=Sophos;i="4.62,304,1297036800"; d="scan'208,217";a="344602527" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2011 16:43:34 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2BGhXvB004621; Fri, 11 Mar 2011 16:43:33 GMT Message-ID: <4D7A51F3.8010503@cisco.com> Date: Fri, 11 Mar 2011 11:46:43 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "Elwell, John" References: <4D798594.4000406@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000607080905050700080703" Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Fri, 11 Mar 2011 16:42:16 -0000 This is a multi-part message in MIME format. --------------000607080905050700080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line. Thanks -- Flemming On 3/11/11 5:18 AM, Elwell, John wrote: > > Flemming, > > According to my records, this went through WGLC a couple of years ago, > so perhaps the silence is due to the fact the WG believes the document > is finished. What exactly is the situation - were there unresolved > comments from WGLC? I am not offering to contribute actively on this - > just curious. > > John > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > > Sent: 11 March 2011 02:15 > > To: mmusic > > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > > with middleboxes ? > > > > We currently have a MMUSIC milestone for "considerations for > > using SDP > > offer/answer with middleboxes". The latest draft for this WG item is > > > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > > > which expired in January 2011. There hasn't been much > > discussion on this > > topic for a while, and the current draft authors are not planning > > continued work on the draft, so we need new authors if we are to > > continue with this WG item. Please let us know if > > 1) You are still interested in this deliverable > > 2) You are willing to actively contribute to and/or author > > this document. > > > > Thanks > > > > Flemming & Miguel [MMUSIC chairs] > > > > > > _______________________________________________ > > 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 > --------------000607080905050700080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line.

Thanks

-- Flemming



On 3/11/11 5:18 AM, Elwell, John wrote:
Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ?

Flemming,

According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious.

John


> -----Original Message-----
> From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: mmusic
> Subject: [MMUSIC] Continued WG interest in SDP offer/answer
> with middleboxes ?
>
> We currently have a MMUSIC milestone for "considerations for
> using SDP
> offer/answer with middleboxes". The latest draft for this WG item is
>
>      draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> which expired in January 2011. There hasn't been much
> discussion on this
> topic for a while, and the current draft authors are not planning
> continued work on the draft, so we need new authors if we are to
> continue with this WG item. Please let us know if
> 1) You are still interested in this deliverable
> 2) You are willing to actively contribute to and/or author
> this document.
>
> Thanks
>
>          Flemming & Miguel [MMUSIC chairs]
>
>
> _______________________________________________
> 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

--------------000607080905050700080703-- From peter.musgrave@magorcorp.com Fri Mar 11 08:46:08 2011 Return-Path: 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 DA3DB3A6B0B for ; Fri, 11 Mar 2011 08:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 PeVJOh+SvmHD for ; Fri, 11 Mar 2011 08:46:07 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 6C3113A6A38 for ; Fri, 11 Mar 2011 08:46:07 -0800 (PST) Received: by yic13 with SMTP id 13so1580886yic.31 for ; Fri, 11 Mar 2011 08:47:26 -0800 (PST) Received: by 10.236.9.36 with SMTP id 24mr3254746yhs.184.1299862046580; Fri, 11 Mar 2011 08:47:26 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id 50sm3034224yhl.29.2011.03.11.08.47.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2011 08:47:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-22--567702368 From: Peter Musgrave In-Reply-To: <4D7A51F3.8010503@cisco.com> Date: Fri, 11 Mar 2011 11:47:24 -0500 Message-Id: <0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com> References: <4D798594.4000406@cisco.com> <4D7A51F3.8010503@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1082) Cc: "Elwell, John" , mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Fri, 11 Mar 2011 16:46:09 -0000 --Apple-Mail-22--567702368 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am willing to be a reviewer - since I have worked on middle-boxes in a = past life. Peter Musgrave On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote: > Good question John. A WGLC was issued back in May 2009, and a few = minor comments were received on the list. A new version was issued = subsequently, however I don't know if that resolved all comments. In any = case, given this was almost two years ago, I think we will need to go = through this again to move the document forward, and we need a new = author to drive that as well since the current authors are no longer = working on the draft, hence the question to the list. My impression is = that the document is pretty close to being done, so I'm not expecting = this to be a lot of work or taking a long time, however we need WG = interest and a few active participants (author + reviewers) to get to = the finish line.=20 >=20 > Thanks=20 >=20 > -- Flemming=20 >=20 >=20 >=20 > On 3/11/11 5:18 AM, Elwell, John wrote: >>=20 >> Flemming, >>=20 >> According to my records, this went through WGLC a couple of years = ago, so perhaps the silence is due to the fact the WG believes the = document is finished. What exactly is the situation - were there = unresolved comments from WGLC? I am not offering to contribute actively = on this - just curious. >>=20 >> John >>=20 >>=20 >> > -----Original Message----- >> > From: mmusic-bounces@ietf.org >> > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen >> > Sent: 11 March 2011 02:15 >> > To: mmusic >> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer >> > with middleboxes ? >> > >> > We currently have a MMUSIC milestone for "considerations for >> > using SDP >> > offer/answer with middleboxes". The latest draft for this WG item = is >> > >> > draft-ietf-mmusic-media-path-middleboxes-03.txt >> > >> > which expired in January 2011. There hasn't been much >> > discussion on this >> > topic for a while, and the current draft authors are not planning >> > continued work on the draft, so we need new authors if we are to >> > continue with this WG item. Please let us know if >> > 1) You are still interested in this deliverable >> > 2) You are willing to actively contribute to and/or author >> > this document. >> > >> > Thanks >> > >> > Flemming & Miguel [MMUSIC chairs] >> > >> > >> > _______________________________________________ >> > 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 >>=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-22--567702368 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I am willing to be a reviewer - since I have worked on middle-boxes in a past life.

Peter Musgrave

On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote:

Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line.

Thanks

-- Flemming



On 3/11/11 5:18 AM, Elwell, John wrote:

Flemming,

According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious.

John


> -----Original Message-----
> From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: mmusic
> Subject: [MMUSIC] Continued WG interest in SDP offer/answer
> with middleboxes ?
>
> We currently have a MMUSIC milestone for "considerations for
> using SDP
> offer/answer with middleboxes". The latest draft for this WG item is
>
>      draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> which expired in January 2011. There hasn't been much
> discussion on this
> topic for a while, and the current draft authors are not planning
> continued work on the draft, so we need new authors if we are to
> continue with this WG item. Please let us know if
> 1) You are still interested in this deliverable
> 2) You are willing to actively contribute to and/or author
> this document.
>
> Thanks
>
>          Flemming & Miguel [MMUSIC chairs]
>
>
> _______________________________________________
> 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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--Apple-Mail-22--567702368-- From gsalguei@cisco.com Fri Mar 11 09:09:27 2011 Return-Path: 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 0A92E3A6A3C for ; Fri, 11 Mar 2011 09:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 W53g33fCdiGt for ; Fri, 11 Mar 2011 09:09:25 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id A26983A6916 for ; Fri, 11 Mar 2011 09:09:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2BHAiQu007520; Fri, 11 Mar 2011 12:10:44 -0500 (EST) Received: from dhcp-64-102-154-216.cisco.com (dhcp-64-102-154-216.cisco.com [64.102.154.216]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2BHAhll016938; Fri, 11 Mar 2011 12:10:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-60--566303832 From: Gonzalo Salgueiro In-Reply-To: <0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com> Date: Fri, 11 Mar 2011 12:10:43 -0500 Message-Id: <8218F8D9-567F-4BB3-B0F4-BD5BE85AD2C1@cisco.com> References: <4D798594.4000406@cisco.com> <4D7A51F3.8010503@cisco.com> <0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com> To: Peter Musgrave X-Mailer: Apple Mail (2.1082) Cc: Flemming Andreasen , John Elwell , mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Fri, 11 Mar 2011 17:09:27 -0000 --Apple-Mail-60--566303832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Now that I know Peter is reviewing, I'd be willing to author and get it = across the finish line. ;-) Gonzalo =20 On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote: > I am willing to be a reviewer - since I have worked on middle-boxes in = a past life. >=20 > Peter Musgrave >=20 > On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote: >=20 >> Good question John. A WGLC was issued back in May 2009, and a few = minor comments were received on the list. A new version was issued = subsequently, however I don't know if that resolved all comments. In any = case, given this was almost two years ago, I think we will need to go = through this again to move the document forward, and we need a new = author to drive that as well since the current authors are no longer = working on the draft, hence the question to the list. My impression is = that the document is pretty close to being done, so I'm not expecting = this to be a lot of work or taking a long time, however we need WG = interest and a few active participants (author + reviewers) to get to = the finish line.=20 >>=20 >> Thanks=20 >>=20 >> -- Flemming=20 >>=20 >>=20 >>=20 >> On 3/11/11 5:18 AM, Elwell, John wrote: >>>=20 >>> Flemming, >>>=20 >>> According to my records, this went through WGLC a couple of years = ago, so perhaps the silence is due to the fact the WG believes the = document is finished. What exactly is the situation - were there = unresolved comments from WGLC? I am not offering to contribute actively = on this - just curious. >>>=20 >>> John >>>=20 >>>=20 >>> > -----Original Message----- >>> > From: mmusic-bounces@ietf.org >>> > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen >>> > Sent: 11 March 2011 02:15 >>> > To: mmusic >>> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer >>> > with middleboxes ? >>> > >>> > We currently have a MMUSIC milestone for "considerations for >>> > using SDP >>> > offer/answer with middleboxes". The latest draft for this WG item = is >>> > >>> > draft-ietf-mmusic-media-path-middleboxes-03.txt >>> > >>> > which expired in January 2011. There hasn't been much >>> > discussion on this >>> > topic for a while, and the current draft authors are not planning >>> > continued work on the draft, so we need new authors if we are to >>> > continue with this WG item. Please let us know if >>> > 1) You are still interested in this deliverable >>> > 2) You are willing to actively contribute to and/or author >>> > this document. >>> > >>> > Thanks >>> > >>> > Flemming & Miguel [MMUSIC chairs] >>> > >>> > >>> > _______________________________________________ >>> > 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 >>>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-60--566303832 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Now that I know Peter is reviewing, I'd be willing to author and get it across the finish line.  ;-)

Gonzalo
 

On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote:

I am willing to be a reviewer - since I have worked on middle-boxes in a past life.

Peter Musgrave

On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote:

Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line.

Thanks

-- Flemming



On 3/11/11 5:18 AM, Elwell, John wrote:

Flemming,

According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious.

John


> -----Original Message-----
> From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: mmusic
> Subject: [MMUSIC] Continued WG interest in SDP offer/answer
> with middleboxes ?
>
> We currently have a MMUSIC milestone for "considerations for
> using SDP
> offer/answer with middleboxes". The latest draft for this WG item is
>
>      draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> which expired in January 2011. There hasn't been much
> discussion on this
> topic for a while, and the current draft authors are not planning
> continued work on the draft, so we need new authors if we are to
> continue with this WG item. Please let us know if
> 1) You are still interested in this deliverable
> 2) You are willing to actively contribute to and/or author
> this document.
>
> Thanks
>
>          Flemming & Miguel [MMUSIC chairs]
>
>
> _______________________________________________
> 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

_______________________________________________
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

--Apple-Mail-60--566303832-- From christer.holmberg@ericsson.com Fri Mar 11 23:39:49 2011 Return-Path: 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 0C3EE3A68C7 for ; Fri, 11 Mar 2011 23:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, 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 Ms0IwJh1Wffg for ; Fri, 11 Mar 2011 23:39:48 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9DDB63A6862 for ; Fri, 11 Mar 2011 23:39:47 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-f0-4d7b23928f7c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.CF.09202.2932B7D4; Sat, 12 Mar 2011 08:41:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 12 Mar 2011 08:41:05 +0100 From: Christer Holmberg To: Flemming Andreasen , "Elwell, John" Date: Sat, 12 Mar 2011 08:40:39 +0100 Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? Thread-Index: AcvgC3tA2JY9oJBwQlysmtNs3HEU6gAfUzvc Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948D7E05E@ESESSCMS0356.eemea.ericsson.se> References: <4D798594.4000406@cisco.com> , <4D7A51F3.8010503@cisco.com> In-Reply-To: <4D7A51F3.8010503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Sat, 12 Mar 2011 07:39:49 -0000 Hi, I am willing to review. Regards, Christer ________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Flemmi= ng Andreasen [fandreas@cisco.com] Sent: Friday, March 11, 2011 6:46 PM To: Elwell, John Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middle= boxes ? Good question John. A WGLC was issued back in May 2009, and a few minor com= ments were received on the list. A new version was issued subsequently, how= ever I don't know if that resolved all comments. In any case, given this wa= s almost two years ago, I think we will need to go through this again to mo= ve the document forward, and we need a new author to drive that as well sin= ce the current authors are no longer working on the draft, hence the questi= on to the list. My impression is that the document is pretty close to being= done, so I'm not expecting this to be a lot of work or taking a long time,= however we need WG interest and a few active participants (author + review= ers) to get to the finish line. Thanks -- Flemming On 3/11/11 5:18 AM, Elwell, John wrote: Flemming, According to my records, this went through WGLC a couple of years ago, so p= erhaps the silence is due to the fact the WG believes the document is finis= hed. What exactly is the situation - were there unresolved comments from WG= LC? I am not offering to contribute actively on this - just curious. John > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > with middleboxes ? > > We currently have a MMUSIC milestone for "considerations for > using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much > discussion on this > topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author > this document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > 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 partr@cisco.com Sun Mar 13 23:42:12 2011 Return-Path: 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 981113A6B07 for ; Sun, 13 Mar 2011 23:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 oV8QlwHpKUSx for ; Sun, 13 Mar 2011 23:42:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 869FB3A6AF3 for ; Sun, 13 Mar 2011 23:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=10680; q=dns/txt; s=iport; t=1300085014; x=1301294614; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=s3/xNZLyI3/JYTGaa2oPj95OqBnLKSl9dr+aIfsS75M=; b=cVUhwtwgoak4pF7y7uJHQa59c8iz28sIkR6kykXYE0g/gVSc0bL2V4M2 54sMbNHr7NyjL/rczEzonpmU6VrZzLJ+ngElp9d72HgnHKKVFQbTTZ61I qAN0OB9HzUEvgN9yS/93cqMfg2WYPHCiUJR8kectUJqyUNeiDrRJuqWL9 w=; X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208,217";a="21541090" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 06:43:33 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2E6hNQa013194; Mon, 14 Mar 2011 06:43:32 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 12:13:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE213.223F3942" Date: Mon, 14 Mar 2011 12:13:38 +0530 Message-ID: In-Reply-To: <8218F8D9-567F-4BB3-B0F4-BD5BE85AD2C1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Thread-Index: AcvgD0zmZl0smup9SRKVuLPmXXbTkwCA5dHg References: <4D798594.4000406@cisco.com><4D7A51F3.8010503@cisco.com><0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com> <8218F8D9-567F-4BB3-B0F4-BD5BE85AD2C1@cisco.com> From: "Parthasarathi R (partr)" To: "Gonzalo Salgueiro (gsalguei)" , "Peter Musgrave" X-OriginalArrivalTime: 14 Mar 2011 06:43:32.0125 (UTC) FILETIME=[227FD4D0:01CBE213] Cc: "Flemming Andreasen \(fandreas\)" , John Elwell , mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? 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: , X-List-Received-Date: Mon, 14 Mar 2011 06:42:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE213.223F3942 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm willing to be reviewer of this draft as I'm working in one such middle-box =20 Thanks Partha ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei) Sent: Friday, March 11, 2011 10:41 PM To: Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Now that I know Peter is reviewing, I'd be willing to author and get it across the finish line. ;-)=20 Gonzalo =20 On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote: I am willing to be a reviewer - since I have worked on middle-boxes in a past life.=20 Peter Musgrave =09 On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote: Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line.=20 =09 Thanks=20 =09 -- Flemming=20 =09 =09 =09 On 3/11/11 5:18 AM, Elwell, John wrote:=20 Flemming, =09 According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious. =09 John =09 =09 > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > with middleboxes ? > > We currently have a MMUSIC milestone for "considerations for > using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much > discussion on this > topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author > this document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > 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 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =09 ------_=_NextPart_001_01CBE213.223F3942 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm willing to be reviewer of this draft=20 as I'm working in one such=20 middle-box
 
Thanks
Partha

From: mmusic-bounces@ietf.org=20 [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro=20 (gsalguei)
Sent: Friday, March 11, 2011 10:41 PM
To: = Peter=20 Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell;=20 mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP = offer/answer=20 withmiddleboxes ?

Now that I know Peter is reviewing, I'd be willing to author = and get=20 it across the finish line.  ;-)

Gonzalo
 

On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote:
I=20 am willing to be a reviewer - since I have worked on middle-boxes in a = past=20 life.

Peter Musgrave

On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote:
Good question John. A WGLC = was issued=20 back in May 2009, and a few minor comments were received on the = list. A new=20 version was issued subsequently, however I don't know if that = resolved all=20 comments. In any case, given this was almost two years ago, I think = we will=20 need to go through this again to move the document forward, and we = need a=20 new author to drive that as well since the current authors are no = longer=20 working on the draft, hence the question to the list. My impression = is that=20 the document is pretty close to being done, so I'm not expecting = this to be=20 a lot of work or taking a long time, however we need WG interest and = a few=20 active participants (author + reviewers) to get to the finish line.=20

Thanks

-- Flemming



On 3/11/11 5:18 = AM,=20 Elwell, John wrote:=20

Flemming,

According to my records, this = went=20 through WGLC a couple of years ago, so perhaps the silence is due = to the=20 fact the WG believes the document is finished. What exactly is the = situation - were there unresolved comments from WGLC? I am not = offering to=20 contribute actively on this - just = curious.

John


>=20 -----Original Message-----
> From: mmusic-bounces@ietf.org
&g= t;=20 [mailto:mmusic-bounces@ietf.org] On = Behalf Of=20 Flemming Andreasen
> Sent: 11 March 2011 02:15
> To:=20 mmusic
> Subject: [MMUSIC] Continued WG interest in SDP=20 offer/answer
> with middleboxes ?
>
> We = currently have=20 a MMUSIC milestone for "considerations for
> using = SDP
>=20 offer/answer with middleboxes". The latest draft for this WG item=20 is
>
>     =20 draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> = which=20 expired in January 2011. There hasn't been much
> discussion = on=20 this
> topic for a while, and the current draft authors are = not=20 planning
> continued work on the draft, so we need new = authors if we=20 are to
> continue with this WG item. Please let us know = if
>=20 1) You are still interested in this deliverable
> 2) You are = willing=20 to actively contribute to and/or author
> this=20 document.
>
>=20 = Thanks
>
>        &nb= sp;=20 Flemming & Miguel [MMUSIC chairs]
>
>
>=20 _______________________________________________
> mmusic = mailing=20 list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic=
>
_______________________________________________
mmusic=20 mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic=

_______________________________________= ________
mmusic=20 mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

_______________________________________________
mmusic=20 mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

<= /HTML> ------_=_NextPart_001_01CBE213.223F3942-- From mperumal@cisco.com Sun Mar 13 23:54:14 2011 Return-Path: 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 302723A6BA9 for ; Sun, 13 Mar 2011 23:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6GLrhyqWx5tW for ; Sun, 13 Mar 2011 23:54:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 10C033A6A4C for ; Sun, 13 Mar 2011 23:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=38378; q=dns/txt; s=iport; t=1300085734; x=1301295334; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=CzQzSVWjfs+XsVbki1pTKuxRO9a6GPDifiwnTc9336s=; b=YFIf7F/2qdxXw5aogmeRN9jLrP+ZgV7DjjsogKHpl+DHK2UxaYZ/oX0e 70z/AK0CZREgvBkDe5P7xeMF79n7Ffdp2xTz6437OLwOKaHlwZmUza6tB sBoOvTaSxQNfOMBiRmrnkvMDtKAhmi9TCBQmKQYPbGZcyPIt7mHHjOom1 I=; X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208,217";a="21542475" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 06:55:33 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2E6tV60000317; Mon, 14 Mar 2011 06:55:33 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 12:25:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE214.CF788333" Date: Mon, 14 Mar 2011 12:25:28 +0530 Message-ID: <1D062974A4845E4D8A343C653804920204F6851B@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Thread-Index: AcvgD0zmZl0smup9SRKVuLPmXXbTkwCA5dHgAAAjTCA= References: <4D798594.4000406@cisco.com><4D7A51F3.8010503@cisco.com><0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com> <8218F8D9-567F-4BB3-B0F4-BD5BE85AD2C1@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Parthasarathi R (partr)" , "Gonzalo Salgueiro (gsalguei)" , "Peter Musgrave" X-OriginalArrivalTime: 14 Mar 2011 06:55:32.0230 (UTC) FILETIME=[CFB72260:01CBE214] Cc: "Flemming Andreasen \(fandreas\)" , John Elwell , mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? 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: , X-List-Received-Date: Mon, 14 Mar 2011 06:54:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE214.CF788333 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am interested in seeing this draft cross the finish line as well and willing to be a reviewer. If Gonzalo needs any additional help, I'll be glad to provide. =20 Muthu =20 From: Parthasarathi R (partr)=20 Sent: Monday, March 14, 2011 12:14 PM To: Gonzalo Salgueiro (gsalguei); Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic; Muthu ArulMozhi Perumal (mperumal) Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? =20 I'm willing to be reviewer of this draft as I'm working in one such middle-box =20 Thanks Partha =20 ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei) Sent: Friday, March 11, 2011 10:41 PM To: Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Now that I know Peter is reviewing, I'd be willing to author and get it across the finish line. ;-)=20 =20 Gonzalo =20 =20 On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote: I am willing to be a reviewer - since I have worked on middle-boxes in a past life.=20 =20 Peter Musgrave =20 On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote: Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line.=20 Thanks=20 -- Flemming=20 On 3/11/11 5:18 AM, Elwell, John wrote:=20 Flemming, According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious. John > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > with middleboxes ? > > We currently have a MMUSIC milestone for "considerations for > using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much > discussion on this > topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author > this document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 ------_=_NextPart_001_01CBE214.CF788333 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am interested in seeing this draft cross the finish line as well and = willing to be a reviewer. If Gonzalo needs any additional help, I'll be glad to = provide.

 

Muthu

 

From: Parthasarathi R (partr)
Sent: Monday, March 14, 2011 12:14 PM
To: Gonzalo Salgueiro (gsalguei); Peter Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell; mmusic; Muthu = ArulMozhi Perumal (mperumal)
Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ?

 

I'm willing to be reviewer of = this draft as I'm working in one such middle-box

 

Thanks

Partha

 

From: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Friday, March 11, 2011 10:41 PM
To: Peter Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell; mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ?

Now that I know Peter is reviewing, I'd be willing to author and get it = across the finish line.  ;-)

 

Gonzalo

 

 

On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote:



I am willing to be a reviewer - since I have worked on middle-boxes in a past = life.

 

Peter Musgrave

 

On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote:



Good question John. A WGLC was issued back in May 2009, and a few minor = comments were received on the list. A new version was issued subsequently, = however I don't know if that resolved all comments. In any case, given this was = almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since = the current authors are no longer working on the draft, hence the question = to the list. My impression is that the document is pretty close to being done, = so I'm not expecting this to be a lot of work or taking a long time, however we = need WG interest and a few active participants (author + reviewers) to get to = the finish line.

Thanks

-- Flemming



On 3/11/11 5:18 AM, Elwell, John wrote:

Flemming,

According to my records, this went through WGLC a couple of years ago, = so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments = from WGLC? I am not offering to contribute actively on this - just = curious.

John


> -----Original Message-----
> From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: mmusic
> Subject: [MMUSIC] Continued WG interest in SDP offer/answer
> with middleboxes ?
>
> We currently have a MMUSIC milestone for "considerations = for
> using SDP
> offer/answer with middleboxes". The latest draft for this WG = item is
>
>      draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> which expired in January 2011. There hasn't been much
> discussion on this
> topic for a while, and the current draft authors are not = planning
> continued work on the draft, so we need new authors if we are = to
> continue with this WG item. Please let us know if
> 1) You are still interested in this deliverable
> 2) You are willing to actively contribute to and/or author
> this document.
>
> Thanks
>
>          Flemming = & Miguel [MMUSIC chairs]
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.or= g/mailman/listinfo/mmusic
>
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 

------_=_NextPart_001_01CBE214.CF788333-- From Internet-Drafts@ietf.org Mon Mar 14 06:00:08 2011 Return-Path: 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 665793A6D35; Mon, 14 Mar 2011 06:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Q1fgv5VZXohH; Mon, 14 Mar 2011 06:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153D93A6D26; Mon, 14 Mar 2011 06:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314130002.4193.48464.idtracker@localhost> Date: Mon, 14 Mar 2011 06:00:02 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-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: , X-List-Received-Date: Mon, 14 Mar 2011 13:00:08 -0000 --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 Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : J. Goldberg, et al. Filename : draft-ietf-mmusic-rtsp-nat-10.txt Pages : 29 Date : 2011-03-14 This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-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-rtsp-nat-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14055237.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 06:00:08 2011 Return-Path: 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 475A33A6D37; Mon, 14 Mar 2011 06:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 KgFCt4fOxSep; Mon, 14 Mar 2011 06:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FFF3A6D2D; Mon, 14 Mar 2011 06:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314130002.4193.51570.idtracker@localhost> Date: Mon, 14 Mar 2011 06:00:02 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-evaluation-03.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: , X-List-Received-Date: Mon, 14 Mar 2011 13:00:09 -0000 --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 Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Author(s) : M. Westerlund, T. Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-03.txt Pages : 38 Date : 2011-03-14 This document describes several Network Address Translator (NAT) traversal techniques that was considered to be used by Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0 standardized in the MMUSIC WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-03.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-rtsp-nat-evaluation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14055247.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Mon Mar 14 06:05:41 2011 Return-Path: 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 06FBF3A6D17 for ; Mon, 14 Mar 2011 06:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xmbabJ+GvziZ for ; Mon, 14 Mar 2011 06:05:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DBC5A3A6928 for ; Mon, 14 Mar 2011 06:05:39 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-b9-4d7e12f608e2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.F1.09202.6F21E7D4; Mon, 14 Mar 2011 14:07:02 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Mon, 14 Mar 2011 14:07:01 +0100 Message-ID: <4D7E12F6.9060801@ericsson.com> Date: Mon, 14 Mar 2011 14:07:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mmusic@ietf.org References: <20110314130002.4193.48464.idtracker@localhost> In-Reply-To: <20110314130002.4193.48464.idtracker@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-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: , X-List-Received-Date: Mon, 14 Mar 2011 13:05:41 -0000 Hi, A diff from previous version are here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-10 The changes in this version are mostly in the category, small fixes editorial or content to make the document ready for a WG last call. So updated references, checked that it followed procedure for the mechanisms reference etc. There is one significant change in this version compared to the previous one, namely section 8: Fallback. This is new but I realized in my review that we appears to need to discuss this topic and the default destination candidate in ICE. So please provide feedback on this. Cheers Magnus Internet-Drafts@ietf.org skrev 2011-03-14 14:00: > 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 Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) > Author(s) : J. Goldberg, et al. > Filename : draft-ietf-mmusic-rtsp-nat-10.txt > Pages : 29 > Date : 2011-03-14 > > This document defines a solution for Network Address Translation > (NAT) traversal for datagram based media streams setup and controlled > with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses > Interactive Connectivity Establishment (ICE) adapted to use RTSP as a > signalling channel, defining the necessary extra RTSP extensions and > procedures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-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. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F鋜鰃atan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Mar 14 06:09:04 2011 Return-Path: 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 6F3563A6D18 for ; Mon, 14 Mar 2011 06:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2rE+y7kdTeRC for ; Mon, 14 Mar 2011 06:09:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5DC193A6D13 for ; Mon, 14 Mar 2011 06:09:03 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-c4-4d7e13c2ac75 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.72.09202.2C31E7D4; Mon, 14 Mar 2011 14:10:26 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 14 Mar 2011 14:10:25 +0100 Message-ID: <4D7E13C1.9030601@ericsson.com> Date: Mon, 14 Mar 2011 14:10:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20110314130002.4193.51570.idtracker@localhost> In-Reply-To: <20110314130002.4193.51570.idtracker@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-evaluation-03.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: , X-List-Received-Date: Mon, 14 Mar 2011 13:09:04 -0000 Hi, This update is of editorial nature. In a read through I found some text that needed correction, or fixing editorial issues like usage of references and ensuring that they are current. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-03 I think it is in descent enough shape that it can go to WG last call. It is after all only an informational document looking at aspects of NAT traversal mechanisms. Cheers Magnus Internet-Drafts@ietf.org skrev 2011-03-14 14:00: > 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 Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) > Author(s) : M. Westerlund, T. Zeng > Filename : draft-ietf-mmusic-rtsp-nat-evaluation-03.txt > Pages : 38 > Date : 2011-03-14 > > This document describes several Network Address Translator (NAT) > traversal techniques that was considered to be used by Real-time > Streaming Protocol (RTSP). Each technique includes a description on > how it would be used, the security implications of using it and any > other deployment considerations it has. There are also disussions on > how NAT traversal techniques relates to firewalls and how each > technique can be applied in different use cases. These findings > where used when selecting the NAT traversal for RTSP 2.0 standardized > in the MMUSIC WG. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-03.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. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F鋜鰃atan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rmohanr@cisco.com Mon Mar 14 06:46:26 2011 Return-Path: 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 5D86C3A6D18 for ; Mon, 14 Mar 2011 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 P6EiFfeeyaDb for ; Mon, 14 Mar 2011 06:46:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F3A2E3A6958 for ; Mon, 14 Mar 2011 06:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=18924; q=dns/txt; s=iport; t=1300110467; x=1301320067; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=sC6HpyMXvhN+b9zeo8q82rjYvutREEAZTDtJyFkKj5k=; b=XdBPy8mo1lBhzFnsxfjt/rS9K2zrIj6P6Q9j6YfzoCvZZK9eOTEo5Unu 6+MzoHtcWtJUe4cDaqK11UIqAqMhNKkblHbtrjTN9j7xUbG1jAZA/dAzb EgS9A221vFdMncnryU+5Vrn1LmWdeATb2XSr/kHtLl6ANkisLapcelhsx s=; X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="21624709" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 13:47:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2EDlkcX023562; Mon, 14 Mar 2011 13:47:46 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 19:17:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE24E.65D4BFEE" Date: Mon, 14 Mar 2011 19:17:43 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05A7E7B5@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Thread-Index: AcviTUkR+BPwwoAtQKCFHZPGLp6AYwAAAPPQ References: <4D798594.4000406@cisco.com><4D7A51F3.8010503@cisco.com><0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com><8218F8D9-567F-4BB3-B0F4-BD5BE85AD2C1@cisco.com><1D062974A4845E4D8A343C653804920204F6851B@XMB-BGL-414.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Flemming Andreasen (fandreas)" , "mmusic" , "Gonzalo Salgueiro (gsalguei)" X-OriginalArrivalTime: 14 Mar 2011 13:47:45.0708 (UTC) FILETIME=[66045EC0:01CBE24E] Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? 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: , X-List-Received-Date: Mon, 14 Mar 2011 13:46:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE24E.65D4BFEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would be interested too in reviewing this draft and providing any help in taking this draft across the finish line. =20 Regards, Ram =20 =20 ---------- Forwarded message ---------- From: Muthu ArulMozhi Perumal (mperumal) Date: 14 March 2011 12:25 Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? To: "Parthasarathi R (partr)" , "Gonzalo Salgueiro (gsalguei)" , Peter Musgrave Cc: "Flemming Andreasen (fandreas)" , John Elwell , mmusic I am interested in seeing this draft cross the finish line as well and willing to be a reviewer. If Gonzalo needs any additional help, I'll be glad to provide. =20 Muthu =20 From: Parthasarathi R (partr)=20 Sent: Monday, March 14, 2011 12:14 PM To: Gonzalo Salgueiro (gsalguei); Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic; Muthu ArulMozhi Perumal (mperumal) Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? =20 I'm willing to be reviewer of this draft as I'm working in one such middle-box =20 Thanks Partha =20 ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei) Sent: Friday, March 11, 2011 10:41 PM To: Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Now that I know Peter is reviewing, I'd be willing to author and get it across the finish line. ;-)=20 =20 Gonzalo =20 =20 On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote: =20 I am willing to be a reviewer - since I have worked on middle-boxes in a past life.=20 =20 Peter Musgrave =20 On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote: =20 Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line.=20 Thanks=20 -- Flemming=20 On 3/11/11 5:18 AM, Elwell, John wrote:=20 Flemming, According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious. John > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > with middleboxes ? > > We currently have a MMUSIC milestone for "considerations for > using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much > discussion on this > topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author > this document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 ------_=_NextPart_001_01CBE24E.65D4BFEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would be interested too in reviewing this draft and providing any = help in taking this draft across the finish = line.

 

Regards,

Ram

 

 

---------- Forwarded = message ----------
From: Muthu ArulMozhi Perumal (mperumal) = <mperumal@cisco.com>
Date: = 14 March 2011 12:25
Subject: Re: [MMUSIC] Continued WG interest in = SDP offer/answer withmiddleboxes ?
To: "Parthasarathi R = (partr)" <partr@cisco.com>, "Gonzalo = Salgueiro (gsalguei)" <gsalguei@cisco.com>, Peter = Musgrave <peter.musgrave@magorcorp.com= >
Cc: "Flemming Andreasen (fandreas)" <fandreas@cisco.com>, John = Elwell <john.elwell@siemens-en= terprise.com>, mmusic <mmusic@ietf.org>

I am interested in = seeing this draft cross the finish line as well and willing to be a = reviewer. If Gonzalo needs any additional help, I'll be glad to = provide.

 

Muthu

 

From: Parthasarathi R (partr)
Sent: = Monday, March 14, 2011 12:14 PM
To: Gonzalo Salgueiro = (gsalguei); Peter Musgrave
Cc: Flemming Andreasen (fandreas); = John Elwell; mmusic; Muthu ArulMozhi Perumal = (mperumal)
Subject: RE: [MMUSIC] Continued WG interest in SDP = offer/answer withmiddleboxes = ?

 <= /o:p>

I'm willing to be reviewer of this draft = as I'm working in one such middle-box

 <= /o:p>

Thanks

Partha

 <= /o:p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Gonzalo Salgueiro (gsalguei)
Sent: Friday, March 11, 2011 = 10:41 PM
To: Peter Musgrave
Cc: Flemming Andreasen = (fandreas); John Elwell; mmusic
Subject: Re: [MMUSIC] = Continued WG interest in SDP offer/answer withmiddleboxes = ?

Now that I = know Peter is reviewing, I'd be willing to author and get it across the = finish line.  ;-)

 <= /o:p>

Gonzalo=

 <= /o:p>

 <= /o:p>

On Mar 11, = 2011, at 11:47 AM, Peter Musgrave wrote:

 <= /p>

I am = willing to be a reviewer - since I have worked on middle-boxes in a past = life.

 <= /o:p>

Peter = Musgrave

 <= /o:p>

On = 2011-03-11, at 11:46 AM, Flemming Andreasen = wrote:

 <= /p>

Good = question John. A WGLC was issued back in May 2009, and a few minor = comments were received on the list. A new version was issued = subsequently, however I don't know if that resolved all comments. In any = case, given this was almost two years ago, I think we will need to go = through this again to move the document forward, and we need a new = author to drive that as well since the current authors are no longer = working on the draft, hence the question to the list. My impression is = that the document is pretty close to being done, so I'm not expecting = this to be a lot of work or taking a long time, however we need WG = interest and a few active participants (author + reviewers) to get to = the finish line.

Thanks

-- Flemming



On = 3/11/11 5:18 AM, Elwell, John wrote:

Flemming,

According to my records, = this went through WGLC a couple of years ago, so perhaps the silence is = due to the fact the WG believes the document is finished. What exactly = is the situation - were there unresolved comments from WGLC? I am not = offering to contribute actively on this - just = curious.

John


> -----Original Message-----
> = From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of = Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: = mmusic
> Subject: [MMUSIC] Continued WG interest in SDP = offer/answer
> with middleboxes ?
>
> We currently = have a MMUSIC milestone for "considerations for
> using = SDP
> offer/answer with middleboxes". The latest draft for = this WG item is
>
>      = draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> which = expired in January 2011. There hasn't been much
> discussion on = this
> topic for a while, and the current draft authors are not = planning
> continued work on the draft, so we need new authors if = we are to
> continue with this WG item. Please let us know = if
> 1) You are still interested in this deliverable
> 2) = You are willing to actively contribute to and/or author
> this = document.
>
> = Thanks
>
>        &nb= sp; Flemming & Miguel [MMUSIC chairs]
>
>
> = _______________________________________________
> 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=

____________= ___________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 <= /o:p>

____________= ___________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 <= /o:p>


______________________________________= _________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 

------_=_NextPart_001_01CBE24E.65D4BFEE-- From Internet-Drafts@ietf.org Mon Mar 14 14:45:15 2011 Return-Path: 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 2BF7D3A6FA4; Mon, 14 Mar 2011 14:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XO6nj09acofm; Mon, 14 Mar 2011 14:45:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568F03A6F92; Mon, 14 Mar 2011 14:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314214509.28151.72807.idtracker@localhost> Date: Mon, 14 Mar 2011 14:45:09 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-15.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: , X-List-Received-Date: Mon, 14 Mar 2011 21:45:15 -0000 --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 : An Extension to the Session Description Protocol (SDP) for Media Loopback Author(s) : C. Sivachelvan, et al Filename : draft-ietf-mmusic-media-loopback-15.txt Pages : 41 Date : 2011-03-14 The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.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-media-loopback-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14143949.I-D@ietf.org> --NextPart-- From partr@cisco.com Mon Mar 14 19:21:07 2011 Return-Path: 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 03ED43A697D for ; Mon, 14 Mar 2011 19:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.031 X-Spam-Level: X-Spam-Status: No, score=-9.031 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 oeEyr2W2CYox for ; Mon, 14 Mar 2011 19:21:05 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D092C3A69AA for ; Mon, 14 Mar 2011 19:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=21481; q=dns/txt; s=iport; t=1300155748; x=1301365348; h=mime-version:subject:date:message-id:references:from:to; bh=xdYxQ7les/ZCq4JjQgXvF+93op/WcihDN8iBidVIYic=; b=Mk5kHaPgv+1oZeEls7mhAM3pXdNjULCpWa26OvxpZmf8p/6teT6/i5b+ ZtvPyWssWCjxtOZhdP/sLznsGaVJehKCXtheQnH/84HOoOekPgj7AXMxc S58sbwDZ0XP2hd+mAqcDmaI9AZRSe7Tvt8LqSA7FRLSmzmOt+9lVK0ZRk Q=; X-IronPort-AV: E=Sophos;i="4.62,320,1297036800"; d="scan'208,217";a="21694919" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2011 02:22:27 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2F2MP5A032530; Tue, 15 Mar 2011 02:22:27 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 07:52:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE2B7.D3349DDD" Date: Tue, 15 Mar 2011 07:52:26 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments in SDP offer/answerwith middleboxes draft Thread-Index: AcviTUkR+BPwwoAtQKCFHZPGLp6AYwAAAPPQABo9nmY= References: <4D798594.4000406@cisco.com><4D7A51F3.8010503@cisco.com><0011FD93-1A71-45EF-85FC-D9DE2AEADF31@magorcorp.com><8218F8D9-567F-4BB3-B0F4-BD5BE85AD2C1@cisco.com><1D062974A4845E4D8A343C653804920204F6851B@XMB-BGL-414.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05A7E7B5@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Ram Mohan R (rmohanr)" , "Flemming Andreasen (fandreas)" , "mmusic" , "Gonzalo Salgueiro (gsalguei)" X-OriginalArrivalTime: 15 Mar 2011 02:22:26.0633 (UTC) FILETIME=[D38D3390:01CBE2B7] Subject: [MMUSIC] Review comments in SDP offer/answerwith middleboxes draft 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: , X-List-Received-Date: Tue, 15 Mar 2011 02:21:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE2B7.D3349DDD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The draft has lot of good recommendation which helps middlebox = implementer to implement without impacting other feature interactions. = Some of my initial comments are as follows:=20 1) Introduction: Para 3 last line: STUN shall be added explicitly. = Middlebox may drop STUN packet itself. 2) Sec 4.1.1: single-stage commit shall be done irrespective whether it = is offer&answer on 18x/200. 3) Sec 4.1.2: explicit resource reservation parameter is preferred to = shown in SDP. In case I understand correctly,this callflow is mentioned = related to RFC 3312. 4) Sec 4.1.2: step 5 & step 6 does not seems to be preferred approach = because MIDCOM agent is different from basic offer/answer model. whether = it is expected that UAS will not send any media till 200 OK is received. 5) Sec 5: The text shall be added to make more clarity- "These middle = boxes are termed as Session Border controller by some vendors". =20 6) General comment: signaling forking handling by middle-boxes shall be = highlighted. Because it is the one another complex activity in = offer/answer during the dialog establishment. 7) Sec 8: There is need of more analysis and description on security = consideration as most of the middle box like firewall drop packets (even = STUN packet) in the defensive mode. It is better to provide more details = which give confidence for middle-box implementers 9) Lot of text is based on IMS/ETSI implementation. It may be preferred = to include the issues involved in basic SIP/SDP based middle boxes as = well. Thanks Partha ________________________________ From: mmusic-bounces@ietf.org on behalf of Ram Mohan R (rmohanr) Sent: Mon 3/14/2011 7:17 PM To: Flemming Andreasen (fandreas); mmusic; Gonzalo Salgueiro (gsalguei) Subject: Re: [MMUSIC] Continued WG interest in SDP = offer/answerwithmiddleboxes ? I would be interested too in reviewing this draft and providing any help = in taking this draft across the finish line. =20 Regards, Ram =20 =20 ---------- Forwarded message ---------- From: Muthu ArulMozhi Perumal (mperumal) Date: 14 March 2011 12:25 Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer = withmiddleboxes ? To: "Parthasarathi R (partr)" , "Gonzalo Salgueiro = (gsalguei)" , Peter Musgrave = Cc: "Flemming Andreasen (fandreas)" , John Elwell = , mmusic I am interested in seeing this draft cross the finish line as well and = willing to be a reviewer. If Gonzalo needs any additional help, I'll be = glad to provide. =20 Muthu =20 From: Parthasarathi R (partr)=20 Sent: Monday, March 14, 2011 12:14 PM To: Gonzalo Salgueiro (gsalguei); Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic; Muthu ArulMozhi = Perumal (mperumal) Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer = withmiddleboxes ? =20 I'm willing to be reviewer of this draft as I'm working in one such = middle-box =20 Thanks Partha =20 ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Gonzalo Salgueiro (gsalguei) Sent: Friday, March 11, 2011 10:41 PM To: Peter Musgrave Cc: Flemming Andreasen (fandreas); John Elwell; mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer = withmiddleboxes ? Now that I know Peter is reviewing, I'd be willing to author and get it = across the finish line. ;-)=20 =20 Gonzalo =20 =20 On Mar 11, 2011, at 11:47 AM, Peter Musgrave wrote: =20 I am willing to be a reviewer - since I have worked on middle-boxes in a = past life.=20 =20 Peter Musgrave =20 On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote: =20 Good question John. A WGLC was issued back in May 2009, and a few minor = comments were received on the list. A new version was issued = subsequently, however I don't know if that resolved all comments. In any = case, given this was almost two years ago, I think we will need to go = through this again to move the document forward, and we need a new = author to drive that as well since the current authors are no longer = working on the draft, hence the question to the list. My impression is = that the document is pretty close to being done, so I'm not expecting = this to be a lot of work or taking a long time, however we need WG = interest and a few active participants (author + reviewers) to get to = the finish line.=20 Thanks=20 -- Flemming=20 On 3/11/11 5:18 AM, Elwell, John wrote:=20 Flemming, According to my records, this went through WGLC a couple of years ago, = so perhaps the silence is due to the fact the WG believes the document = is finished. What exactly is the situation - were there unresolved = comments from WGLC? I am not offering to contribute actively on this - = just curious. John > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > with middleboxes ? > > We currently have a MMUSIC milestone for "considerations for > using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much > discussion on this > topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author > this document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 ------_=_NextPart_001_01CBE2B7.D3349DDD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
The draft has lot of good recommendation which helps = middlebox implementer to implement without impacting other feature = interactions. Some of my initial comments are as = follows:=0A=
=0A=
=0A=

1) Introduction: Para 3 = last line: STUN shall be added explicitly. Middlebox may drop STUN packet itself.
2) = Sec 4.1.1: single-stage commit shall be done irrespective whether it is = offer&answer on = 18x/200.
3) Sec 4.1.2: explicit resource reservation parameter is = preferred to shown in SDP. In case I understand correctly,this callflow is = mentioned related to RFC 3312.
4) Sec 4.1.2: step 5 & step 6 does not seems = to be preferred approach because MIDCOM agent is different from basic offer/answer model. = whether it is expected that UAS will not send any media till 200 OK is = received.
5) Sec 5: The text  shall be added to make more = clarity- "These middle boxes are termed as Session Border controller by some vendors".  =
6) General comment: signaling forking handling by middle-boxes shall = be highlighted. = Because it is the one another complex activity in offer/answer = during the dialog = establishment.
7) Sec 8: There is need of more analysis and = description on security consideration as most of the middle box like = firewall drop packets (even STUN packet) in the defensive mode. It is = better to provide more details which give confidence for middle-box = implementers
9) Lot of text is based on IMS/ETSI implementation. It = may be preferred to include the issues involved in basic SIP/SDP based = middle boxes as well.

=0A=

Thanks

=0A=

Partha

=0A=

=0A=
=0A= From: mmusic-bounces@ietf.org on = behalf of Ram Mohan R (rmohanr)
Sent: Mon 3/14/2011 7:17 = PM
To: Flemming Andreasen (fandreas); mmusic; Gonzalo = Salgueiro (gsalguei)
Subject: Re: [MMUSIC] Continued WG = interest in SDP offer/answerwithmiddleboxes ?

=0A=
=0A=
=0A=

I would be interested too in reviewing = this draft and providing any help in taking this draft across the finish = line.

=0A=

 

=0A=

Regards,

=0A=

Ram

=0A=
=0A=

 

=0A=

 

=0A=
=0A=

---------- Forwarded = message ----------
From: Muthu ArulMozhi Perumal (mperumal) = <mperumal@cisco.com>
Date: = 14 March 2011 12:25
Subject: Re: [MMUSIC] Continued WG interest in = SDP offer/answer withmiddleboxes ?
To: "Parthasarathi R (partr)" = <partr@cisco.com>, "Gonzalo = Salgueiro (gsalguei)" <gsalguei@cisco.com>, Peter = Musgrave <peter.musgrave@magorcorp.com= >
Cc: "Flemming Andreasen (fandreas)" <fandreas@cisco.com>, John = Elwell <john.elwell@siemens-en= terprise.com>, mmusic <mmusic@ietf.org>

=0A=
=0A=
=0A=

I am interested in seeing this draft cross the finish = line as well and willing to be a reviewer. If Gonzalo needs any = additional help, I'll be glad to provide.

=0A=

 

=0A=

Muthu

=0A=

 

=0A=
=0A=
=0A=
=0A=

From: Parthasarathi R = (partr)
Sent: Monday, March 14, 2011 12:14 PM
To: = Gonzalo Salgueiro (gsalguei); Peter Musgrave
Cc: Flemming = Andreasen (fandreas); John Elwell; mmusic; Muthu ArulMozhi Perumal = (mperumal)
Subject: RE: [MMUSIC] Continued WG interest in SDP = offer/answer withmiddleboxes ?

=0A=
=0A=
=0A=

 

=0A=

I'm willing to be = reviewer of this draft as I'm working in one such = middle-box

=0A=

 

=0A=

Thanks

=0A=

Partha

=0A=

 

=0A=
=0A=
=0A=
=0A=

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo = Salgueiro (gsalguei)
Sent: Friday, March 11, 2011 10:41 = PM
To: Peter Musgrave
Cc: Flemming Andreasen = (fandreas); John Elwell; mmusic
Subject: Re: [MMUSIC] = Continued WG interest in SDP offer/answer withmiddleboxes ?

=0A=

Now that I know Peter is reviewing, I'd be willing = to author and get it across the finish line.  ;-)

=0A=
=0A=
=0A=

 

=0A=
=0A=

Gonzalo

=0A=
=0A=

 

=0A=
=0A=

 

=0A=
=0A=
=0A=

On Mar 11, 2011, at 11:47 AM, Peter Musgrave = wrote:

=0A=

 

=0A=
=0A=

I am willing to be a reviewer - since I have worked = on middle-boxes in a past life.

=0A=
=0A=

 

=0A=
=0A=

Peter Musgrave

=0A=
=0A=

 

=0A=
=0A=
=0A=

On 2011-03-11, at 11:46 AM, Flemming Andreasen = wrote:

=0A=

 

=0A=
=0A=

Good question John. A WGLC was issued back in May = 2009, and a few minor comments were received on the list. A new version = was issued subsequently, however I don't know if that resolved all = comments. In any case, given this was almost two years ago, I think we = will need to go through this again to move the document forward, and we = need a new author to drive that as well since the current authors are no = longer working on the draft, hence the question to the list. My = impression is that the document is pretty close to being done, so I'm = not expecting this to be a lot of work or taking a long time, however we = need WG interest and a few active participants (author + reviewers) to = get to the finish line.

Thanks

-- Flemming =



On 3/11/11 5:18 AM, Elwell, John wrote:

=0A=

Flemming,

According to my = records, this went through WGLC a couple of years ago, so perhaps the = silence is due to the fact the WG believes the document is finished. = What exactly is the situation - were there unresolved comments from = WGLC? I am not offering to contribute actively on this - just = curious.

John


> -----Original Message-----
> = From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of = Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: = mmusic
> Subject: [MMUSIC] Continued WG interest in SDP = offer/answer
> with middleboxes ?
>
> We currently = have a MMUSIC milestone for "considerations for
> using = SDP
> offer/answer with middleboxes". The latest draft for this WG = item is
>
>      = draft-ietf-mmusic-media-path-middleboxes-03.txt
>
> which = expired in January 2011. There hasn't been much
> discussion on = this
> topic for a while, and the current draft authors are not = planning
> continued work on the draft, so we need new authors if = we are to
> continue with this WG item. Please let us know = if
> 1) You are still interested in this deliverable
> 2) = You are willing to actively contribute to and/or author
> this = document.
>
> = Thanks
>
>        &nb= sp; Flemming & Miguel [MMUSIC chairs]
>
>
> = _______________________________________________
> mmusic mailing = list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
><= BR>_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

=0A=

_______________________________________________
mmus= ic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

=0A=

 

=0A=

_______________________________________________
mmus= ic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

=0A=

 

=0A=


_______________________________________________
= mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

=0A=

 

------_=_NextPart_001_01CBE2B7.D3349DDD-- From dwing@cisco.com Mon Mar 14 19:37:31 2011 Return-Path: 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 EC9D03A6973 for ; Mon, 14 Mar 2011 19:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ox1Z76o6Ftu7 for ; Mon, 14 Mar 2011 19:37:30 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 389AA3A6B15 for ; Mon, 14 Mar 2011 19:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2037; q=dns/txt; s=iport; t=1300156735; x=1301366335; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=sEnGD9NkSFkhjjZuGPd0jU/uxrvMCAyEjh63vgWjdME=; b=LEDLTbxDDhJm0x2HFPOSaWlGR95if4aTE3ar+yOtfGIxMQBwR2OOYzhK DSi9aZtMuyNDjFVtk6vNHKoKTcHx2pEnTZjJoMna8Uw5mWnnhKK/AbgmF E29oWHt3Llywsl86nbTp+ve5YHWJM4gbXL/BasAvVnIIJZtpAW5KhESZY M=; X-IronPort-AV: E=Sophos;i="4.62,320,1297036800"; d="scan'208";a="225624444" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2011 02:38:47 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2F2ckHJ020014; Tue, 15 Mar 2011 02:38:46 GMT From: "Dan Wing" To: "'Flemming Andreasen'" , "'mmusic'" References: <4D798594.4000406@cisco.com> In-Reply-To: <4D798594.4000406@cisco.com> Date: Mon, 14 Mar 2011 19:38:46 -0700 Message-ID: <0ed601cbe2ba$1bdfd740$539f85c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tg Content-language: en-us Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Tue, 15 Mar 2011 02:37:32 -0000 The draft uses the term "SIP ALG", which at least does not fit my definition of an ALG. An ALG doesn't have packets sent directly to its IP address; it does its job stealthily without awareness of one (or both) of the sessoin endpoints. In contrast, the function described in draft-ietf-mmusic-media-path-middleboxes is different -- packets are always sent to the IP address of the SIP "ALG", and packets are sent from the IP address of the SIP "ALG". This functionality is most often called a "server" or a "proxy" -- not an ALG. This distinction is important because this draft is closely related to functions common in NATs, which _do_ sometimes have SIP ALGs implemented in them. So ... can we change "SIP ALG" to something like "SIP proxy" or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a B2BUA, at least as best I understand the definition of a B2BUA, so B2BUA seems best. d > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Flemming Andreasen > Sent: Thursday, March 10, 2011 6:15 PM > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with > middleboxes ? > > We currently have a MMUSIC milestone for "considerations for using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much discussion on > this > topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author this > document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From gsalguei@cisco.com Mon Mar 14 20:35:50 2011 Return-Path: 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 3B5C83A6B80 for ; Mon, 14 Mar 2011 20:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9jVM0tJRssxL for ; Mon, 14 Mar 2011 20:35:49 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id ED8A53A6B59 for ; Mon, 14 Mar 2011 20:35:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2F3bCB7021284 for ; Mon, 14 Mar 2011 23:37:12 -0400 (EDT) Received: from rtp-gsalguei-8714.cisco.com (rtp-gsalguei-8714.cisco.com [10.116.61.53]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2F3b7S8016853; Mon, 14 Mar 2011 23:37:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1--269519247 From: Gonzalo Salgueiro In-Reply-To: <0ed601cbe2ba$1bdfd740$539f85c0$@com> Date: Mon, 14 Mar 2011 23:37:07 -0400 Message-Id: <2FDDC00D-1935-4633-8CA1-5D84FBB15876@cisco.com> References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1082) Cc: 'Flemming Andreasen' , 'mmusic' Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Tue, 15 Mar 2011 03:35:50 -0000 --Apple-Mail-1--269519247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Dan. I'd like others to weigh in but your comments regarding use = of SIP B2BUA instead of SIP ALG seems reasonable to me. BTW - As we jumpstart efforts to resurrect this draft, I'd like to try = and get some group feedback. The intent is coming to a consensus on what = we think is left to do with this draft in order to progress it. Regards, Gonzalo On Mar 14, 2011, at 10:38 PM, Dan Wing wrote: > The draft uses the term "SIP ALG", which at least does not fit my > definition of an ALG. An ALG doesn't have packets sent directly > to its IP address; it does its job stealthily without awareness > of one (or both) of the sessoin endpoints. In contrast, the=20 > function described in draft-ietf-mmusic-media-path-middleboxes > is different -- packets are always sent to the IP address of=20 > the SIP "ALG", and packets are sent from the IP address of the > SIP "ALG". This functionality is most often called a "server"=20 > or a "proxy" -- not an ALG. =20 >=20 > This distinction is important because this draft is closely > related to functions common in NATs, which _do_ sometimes > have SIP ALGs implemented in them. >=20 > So ... can we change "SIP ALG" to something like "SIP proxy" > or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, > it is a B2BUA, at least as best I understand the definition > of a B2BUA, so B2BUA seems best. >=20 > d >=20 >=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Flemming Andreasen >> Sent: Thursday, March 10, 2011 6:15 PM >> To: mmusic >> Subject: [MMUSIC] Continued WG interest in SDP offer/answer with >> middleboxes ? >>=20 >> We currently have a MMUSIC milestone for "considerations for using = SDP >> offer/answer with middleboxes". The latest draft for this WG item is >>=20 >> draft-ietf-mmusic-media-path-middleboxes-03.txt >>=20 >> which expired in January 2011. There hasn't been much discussion on >> this >> topic for a while, and the current draft authors are not planning >> continued work on the draft, so we need new authors if we are to >> continue with this WG item. Please let us know if >> 1) You are still interested in this deliverable >> 2) You are willing to actively contribute to and/or author this >> document. >>=20 >> Thanks >>=20 >> Flemming & Miguel [MMUSIC chairs] >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-1--269519247 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The draft uses the term "SIP ALG", which at least = does not fit my
definition of an ALG.  An ALG doesn't have = packets sent directly
to its IP address; it does its job stealthily = without awareness
of one (or both) of the sessoin endpoints.  In = contrast, the
function described in = draft-ietf-mmusic-media-path-middleboxes
is different -- packets are = always sent to the IP address of
the SIP "ALG", and packets are sent = from the IP address of the
SIP "ALG".  This functionality is = most often called a "server"
or a "proxy" -- not an ALG. =  

This distinction is important because this draft is = closely
related to functions common in NATs, which _do_ = sometimes
have SIP ALGs implemented in them.

So ... can we = change "SIP ALG" to something like "SIP proxy"
or "SIP user agent" or = "SIP Back-to-Back User Agent"?  Really,
it is a B2BUA, at least = as best I understand the definition
of a B2BUA, so B2BUA seems = best.

d


-----Original = Message-----
From: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On
Behalf Of Flemming Andreasen
Sent: Thursday, March 10, 2011 6:15 = PM
To: = mmusic
Subject: [MMUSIC] = Continued WG interest in SDP offer/answer = with
middleboxes = ?

We currently have a MMUSIC milestone for "considerations = for using SDP
offer/answer = with middleboxes". The latest draft for this WG item = is

=     draft-ietf-mmusic-media-path-middleboxes-03.txt

which expired in January 2011. There hasn't been much = discussion on
this
topic for a = while, and the current draft authors are not = planning
continued work on the = draft, so we need new authors if we are to
continue with this WG item. Please let us know = if
1) You are still interested = in this deliverable
2) You are = willing to actively contribute to and/or author = this
document.

Thanks

=         Flemming & Miguel = [MMUSIC chairs]


_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.org= /mailman/listinfo/mmusic

_________________________= ______________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

= --Apple-Mail-1--269519247-- From partr@cisco.com Mon Mar 14 23:19:46 2011 Return-Path: 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 EEBF53A6AAB for ; Mon, 14 Mar 2011 23:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.013 X-Spam-Level: X-Spam-Status: No, score=-10.013 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 RSm-cxetHezX for ; Mon, 14 Mar 2011 23:19:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 39FD33A697C for ; Mon, 14 Mar 2011 23:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=10823; q=dns/txt; s=iport; t=1300170062; x=1301379662; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=hbCX8tmd9UkStXC11rpTxlC5nj0oTaMOOg3r0uwlLwo=; b=E8VSQL5GuViMnwG3sG6CNZWI/W1hq0pTl+1BfxNghzwO5Nh3wEX3G9lF m2nrYa+jmJKExSLPBLJtaVVfi7IUEjZfJguMg5geXjlab0tM+qM3Y7eFD coJ8wy9touadvihNlX8f2Ix9ZdaXZJ/gIDLctNTUQdCUeBWLH4uN8fHp+ Q=; X-IronPort-AV: E=Sophos;i="4.62,321,1297036800"; d="scan'208,217";a="79187577" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Mar 2011 06:21:01 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2F6KpN9020667; Tue, 15 Mar 2011 06:21:00 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 11:50:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE2D9.25FE29C8" Date: Tue, 15 Mar 2011 11:50:58 +0530 Message-ID: In-Reply-To: <2FDDC00D-1935-4633-8CA1-5D84FBB15876@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Thread-Index: AcviwlIZ5SkXP2iRR8e1Hp14oTB59gAFRfrQ References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> <2FDDC00D-1935-4633-8CA1-5D84FBB15876@cisco.com> From: "Parthasarathi R (partr)" To: "Gonzalo Salgueiro (gsalguei)" , "Dan Wing (dwing)" X-OriginalArrivalTime: 15 Mar 2011 06:20:58.0760 (UTC) FILETIME=[263E7880:01CBE2D9] Cc: "Flemming Andreasen \(fandreas\)" , mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? 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: , X-List-Received-Date: Tue, 15 Mar 2011 06:19:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE2D9.25FE29C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SIP B2BUA is better than SIP ALG. All the functionality mentioned in the draft comes under SIP B2BUA in the generic term.I'm fine with the terminology. =20 But SIP B2BUA has other functionality like 3PCC handling as well. I'm not very sure whether B2BUA will be acceptable to everybody or will the usage of B2BUA increase the scope of this draft...=20 =20 Thanks Partha ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei) Sent: Tuesday, March 15, 2011 9:07 AM To: Dan Wing (dwing) Cc: Flemming Andreasen (fandreas); 'mmusic' Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? Thanks Dan. I'd like others to weigh in but your comments regarding use of SIP B2BUA instead of SIP ALG seems reasonable to me.=20 BTW - As we jumpstart efforts to resurrect this draft, I'd like to try and get some group feedback. The intent is coming to a consensus on what we think is left to do with this draft in order to progress it. Regards, Gonzalo On Mar 14, 2011, at 10:38 PM, Dan Wing wrote: The draft uses the term "SIP ALG", which at least does not fit my definition of an ALG. An ALG doesn't have packets sent directly to its IP address; it does its job stealthily without awareness of one (or both) of the sessoin endpoints. In contrast, the=20 function described in draft-ietf-mmusic-media-path-middleboxes is different -- packets are always sent to the IP address of=20 the SIP "ALG", and packets are sent from the IP address of the SIP "ALG". This functionality is most often called a "server"=20 or a "proxy" -- not an ALG. =20 =09 This distinction is important because this draft is closely related to functions common in NATs, which _do_ sometimes have SIP ALGs implemented in them. =09 So ... can we change "SIP ALG" to something like "SIP proxy" or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a B2BUA, at least as best I understand the definition of a B2BUA, so B2BUA seems best. =09 d =09 =09 =09 -----Original Message----- =09 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On =09 Behalf Of Flemming Andreasen =09 Sent: Thursday, March 10, 2011 6:15 PM =09 To: mmusic =09 Subject: [MMUSIC] Continued WG interest in SDP offer/answer with =09 middleboxes ? =09 We currently have a MMUSIC milestone for "considerations for using SDP =09 offer/answer with middleboxes". The latest draft for this WG item is =09 draft-ietf-mmusic-media-path-middleboxes-03.txt =09 which expired in January 2011. There hasn't been much discussion on =09 this =09 topic for a while, and the current draft authors are not planning =09 continued work on the draft, so we need new authors if we are to =09 continue with this WG item. Please let us know if =09 1) You are still interested in this deliverable =09 2) You are willing to actively contribute to and/or author this =09 document. =09 Thanks =09 Flemming & Miguel [MMUSIC chairs] =09 _______________________________________________ =09 mmusic mailing list =09 mmusic@ietf.org =09 https://www.ietf.org/mailman/listinfo/mmusic =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =09 ------_=_NextPart_001_01CBE2D9.25FE29C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
SIP B2BUA is better than SIP ALG. All the = functionality=20 mentioned in the draft comes under SIP B2BUA in the generic = term.I'm=20 fine with the terminology.
 
But SIP B2BUA has other functionality like=20 3PCC handling as well. I'm not very sure whether B2BUA will be = acceptable=20 to everybody or will the usage of B2BUA increase the scope of this=20 draft... 
 
Thanks
Partha

From: mmusic-bounces@ietf.org=20 [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro=20 (gsalguei)
Sent: Tuesday, March 15, 2011 9:07 AM
To: = Dan=20 Wing (dwing)
Cc: Flemming Andreasen (fandreas);=20 'mmusic'
Subject: Re: [MMUSIC] Continued WG interest in SDP=20 offer/answer withmiddleboxes ?

Thanks Dan. I'd like others to weigh in but your = comments=20 regarding use of SIP B2BUA instead of SIP ALG seems reasonable to me.

BTW - As we jumpstart efforts to resurrect this draft, I'd like to = try and=20 get some group feedback. The intent is coming to a consensus on what we = think is=20 left to do with this draft in order to progress it.

Regards,

Gonzalo

On Mar 14, 2011, at 10:38 PM, Dan Wing wrote:
The draft uses the term "SIP ALG", which at least does not fit=20 my
definition of an ALG.  An ALG doesn't have packets sent=20 directly
to its IP address; it does its job stealthily without=20 awareness
of one (or both) of the sessoin endpoints.  In = contrast, the=20
function described in = draft-ietf-mmusic-media-path-middleboxes
is=20 different -- packets are always sent to the IP address of
the SIP = "ALG",=20 and packets are sent from the IP address of the
SIP "ALG". =  This=20 functionality is most often called a "server"
or a "proxy" -- not = an ALG.=20  

This distinction is important because this draft is=20 closely
related to functions common in NATs, which _do_ = sometimes
have=20 SIP ALGs implemented in them.

So ... can we change "SIP ALG" to = something like "SIP proxy"
or "SIP user agent" or "SIP Back-to-Back = User=20 Agent"?  Really,
it is a B2BUA, at least as best I understand = the=20 definition
of a B2BUA, so B2BUA seems best.

d


-----Original Message-----
From: mmusic-bounces@ietf.org=20 [mailto:mmusic-bounces@ietf.org] On
Behalf Of Flemming = Andreasen
Sent: Thursday, March 10, 2011 6:15=20 PM
To: mmusic
Subject: [MMUSIC] Continued WG interest in = SDP=20 offer/answer with
middleboxes ?

We currently have a MMUSIC milestone for=20 "considerations for using SDP
offer/answer with middleboxes". The latest = draft for=20 this WG item is

    draft-ietf-mmusic-media-path-middle= boxes-03.txt

which expired in January 2011. There hasn't = been=20 much discussion on
this
topic for a while, and the current draft = authors are=20 not planning
continued work on the draft, so we need new = authors=20 if we are to
continue with this WG item. Please let us = know=20 if
1) You are still interested in this=20 deliverable
2) You are willing to actively contribute to = and/or=20 author this
document.

Thanks

        Flemming = &=20 Miguel [MMUSIC chairs]


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

_______________________= ________________________
mmusic=20 mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

<= /HTML> ------_=_NextPart_001_01CBE2D9.25FE29C8-- From gsalguei@cisco.com Mon Mar 14 23:32:01 2011 Return-Path: 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 9C0A23A6BA9 for ; Mon, 14 Mar 2011 23:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 JjFewtCiJeeA for ; Mon, 14 Mar 2011 23:31:59 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by core3.amsl.com (Postfix) with ESMTP id E2F6B3A6B88 for ; Mon, 14 Mar 2011 23:31:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2F6XMv6011509 for ; Mon, 14 Mar 2011 23:33:23 -0700 (PDT) Received: from rtp-gsalguei-8714.cisco.com (rtp-gsalguei-8714.cisco.com [10.116.61.53]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2F6XEP5009438; Tue, 15 Mar 2011 02:33:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--258952966 From: Gonzalo Salgueiro In-Reply-To: Date: Tue, 15 Mar 2011 02:33:14 -0400 Message-Id: References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> <2FDDC00D-1935-4633-8CA1-5D84FBB15876@cisco.com> To: Parthasarathi R (partr) X-Mailer: Apple Mail (2.1082) Cc: "Flemming Andreasen \(fandreas\)" , "Dan Wing \(dwing\)" , mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ? 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: , X-List-Received-Date: Tue, 15 Mar 2011 06:32:02 -0000 --Apple-Mail-4--258952966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Partha -=20 While I agree with you on the precision and scope of the term, B2BUA is = a closer shade of gray than ALG. Gonzalo On Mar 15, 2011, at 2:20 AM, Parthasarathi R (partr) wrote: > SIP B2BUA is better than SIP ALG. All the functionality mentioned in = the draft comes under SIP B2BUA in the generic term.I'm fine with the = terminology. > =20 > But SIP B2BUA has other functionality like 3PCC handling as well. I'm = not very sure whether B2BUA will be acceptable to everybody or will the = usage of B2BUA increase the scope of this draft...=20 > =20 > Thanks > Partha >=20 > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Gonzalo Salgueiro (gsalguei) > Sent: Tuesday, March 15, 2011 9:07 AM > To: Dan Wing (dwing) > Cc: Flemming Andreasen (fandreas); 'mmusic' > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer = withmiddleboxes ? >=20 > Thanks Dan. I'd like others to weigh in but your comments regarding = use of SIP B2BUA instead of SIP ALG seems reasonable to me. >=20 > BTW - As we jumpstart efforts to resurrect this draft, I'd like to try = and get some group feedback. The intent is coming to a consensus on what = we think is left to do with this draft in order to progress it. >=20 > Regards, >=20 > Gonzalo >=20 > On Mar 14, 2011, at 10:38 PM, Dan Wing wrote: >=20 >> The draft uses the term "SIP ALG", which at least does not fit my >> definition of an ALG. An ALG doesn't have packets sent directly >> to its IP address; it does its job stealthily without awareness >> of one (or both) of the sessoin endpoints. In contrast, the=20 >> function described in draft-ietf-mmusic-media-path-middleboxes >> is different -- packets are always sent to the IP address of=20 >> the SIP "ALG", and packets are sent from the IP address of the >> SIP "ALG". This functionality is most often called a "server"=20 >> or a "proxy" -- not an ALG. =20 >>=20 >> This distinction is important because this draft is closely >> related to functions common in NATs, which _do_ sometimes >> have SIP ALGs implemented in them. >>=20 >> So ... can we change "SIP ALG" to something like "SIP proxy" >> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, >> it is a B2BUA, at least as best I understand the definition >> of a B2BUA, so B2BUA seems best. >>=20 >> d >>=20 >>=20 >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Flemming Andreasen >>> Sent: Thursday, March 10, 2011 6:15 PM >>> To: mmusic >>> Subject: [MMUSIC] Continued WG interest in SDP offer/answer with >>> middleboxes ? >>>=20 >>> We currently have a MMUSIC milestone for "considerations for using = SDP >>> offer/answer with middleboxes". The latest draft for this WG item is >>>=20 >>> draft-ietf-mmusic-media-path-middleboxes-03.txt >>>=20 >>> which expired in January 2011. There hasn't been much discussion on >>> this >>> topic for a while, and the current draft authors are not planning >>> continued work on the draft, so we need new authors if we are to >>> continue with this WG item. Please let us know if >>> 1) You are still interested in this deliverable >>> 2) You are willing to actively contribute to and/or author this >>> document. >>>=20 >>> Thanks >>>=20 >>> Flemming & Miguel [MMUSIC chairs] >>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 --Apple-Mail-4--258952966 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Partha - 

While I agree with you on the precision and scope of the term, B2BUA is a closer shade of gray than ALG.

Gonzalo

On Mar 15, 2011, at 2:20 AM, Parthasarathi R (partr) wrote:

SIP B2BUA is better than SIP ALG. All the functionality mentioned in the draft comes under SIP B2BUA in the generic term.I'm fine with the terminology.
 
But SIP B2BUA has other functionality like 3PCC handling as well. I'm not very sure whether B2BUA will be acceptable to everybody or will the usage of B2BUA increase the scope of this draft... 
 
Thanks
Partha

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Tuesday, March 15, 2011 9:07 AM
To: Dan Wing (dwing)
Cc: Flemming Andreasen (fandreas); 'mmusic'
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ?

Thanks Dan. I'd like others to weigh in but your comments regarding use of SIP B2BUA instead of SIP ALG seems reasonable to me.

BTW - As we jumpstart efforts to resurrect this draft, I'd like to try and get some group feedback. The intent is coming to a consensus on what we think is left to do with this draft in order to progress it.

Regards,

Gonzalo

On Mar 14, 2011, at 10:38 PM, Dan Wing wrote:

The draft uses the term "SIP ALG", which at least does not fit my
definition of an ALG.  An ALG doesn't have packets sent directly
to its IP address; it does its job stealthily without awareness
of one (or both) of the sessoin endpoints.  In contrast, the
function described in draft-ietf-mmusic-media-path-middleboxes
is different -- packets are always sent to the IP address of
the SIP "ALG", and packets are sent from the IP address of the
SIP "ALG".  This functionality is most often called a "server"
or a "proxy" -- not an ALG.  

This distinction is important because this draft is closely
related to functions common in NATs, which _do_ sometimes
have SIP ALGs implemented in them.

So ... can we change "SIP ALG" to something like "SIP proxy"
or "SIP user agent" or "SIP Back-to-Back User Agent"?  Really,
it is a B2BUA, at least as best I understand the definition
of a B2BUA, so B2BUA seems best.

d


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
Behalf Of Flemming Andreasen
Sent: Thursday, March 10, 2011 6:15 PM
To: mmusic
Subject: [MMUSIC] Continued WG interest in SDP offer/answer with
middleboxes ?

We currently have a MMUSIC milestone for "considerations for using SDP
offer/answer with middleboxes". The latest draft for this WG item is

    draft-ietf-mmusic-media-path-middleboxes-03.txt

which expired in January 2011. There hasn't been much discussion on
this
topic for a while, and the current draft authors are not planning
continued work on the draft, so we need new authors if we are to
continue with this WG item. Please let us know if
1) You are still interested in this deliverable
2) You are willing to actively contribute to and/or author this
document.

Thanks

        Flemming & Miguel [MMUSIC chairs]


_______________________________________________
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


--Apple-Mail-4--258952966-- From christer.holmberg@ericsson.com Mon Mar 14 23:42:21 2011 Return-Path: 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 AC5B13A6BA7 for ; Mon, 14 Mar 2011 23:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, 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 Dbc5iIAtmJeA for ; Mon, 14 Mar 2011 23:42:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 67DF63A6AEA for ; Mon, 14 Mar 2011 23:42:19 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-29-4d7f0a9e1679 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.66.09202.E9A0F7D4; Tue, 15 Mar 2011 07:43:42 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 15 Mar 2011 07:43:41 +0100 From: Christer Holmberg To: 'Dan Wing' , 'Flemming Andreasen' , 'mmusic' Date: Tue, 15 Mar 2011 07:43:41 +0100 Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> In-Reply-To: <0ed601cbe2ba$1bdfd740$539f85c0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? 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: , X-List-Received-Date: Tue, 15 Mar 2011 06:42:21 -0000 Hi Dan, In my definition of an ALG packets can be sent directly to its IP address. In my opinion, SIP B2BUA only focuses on SIP, while an ALG also focuses on = other things, like media. A SIP ALG contains a SIP B2BUA. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Dan Wing Sent: 15. maaliskuuta 2011 4:39 To: 'Flemming Andreasen'; 'mmusic' Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middle= boxes ? The draft uses the term "SIP ALG", which at least does not fit my definitio= n of an ALG. An ALG doesn't have packets sent directly to its IP address; = it does its job stealthily without awareness of one (or both) of the sessoi= n endpoints. In contrast, the function described in draft-ietf-mmusic-medi= a-path-middleboxes is different -- packets are always sent to the IP address of the SIP "ALG",= and packets are sent from the IP address of the SIP "ALG". This functiona= lity is most often called a "server"=20 or a "proxy" -- not an ALG. =20 This distinction is important because this draft is closely related to func= tions common in NATs, which _do_ sometimes have SIP ALGs implemented in the= m. So ... can we change "SIP ALG" to something like "SIP proxy" or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a B2BU= A, at least as best I understand the definition of a B2BUA, so B2BUA seems = best. d > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Flemming Andreasen > Sent: Thursday, March 10, 2011 6:15 PM > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > middleboxes ? >=20 > We currently have a MMUSIC milestone for "considerations for using SDP=20 > offer/answer with middleboxes". The latest draft for this WG item is >=20 > draft-ietf-mmusic-media-path-middleboxes-03.txt >=20 > which expired in January 2011. There hasn't been much discussion on=20 > this topic for a while, and the current draft authors are not planning=20 > continued work on the draft, so we need new authors if we are to=20 > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author this=20 > document. >=20 > Thanks >=20 > Flemming & Miguel [MMUSIC chairs] >=20 >=20 > _______________________________________________ > 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 partr@cisco.com Tue Mar 15 02:52:43 2011 Return-Path: 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 58B8A3A6C66 for ; Tue, 15 Mar 2011 02:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 4RXwPATmwJ1a for ; Tue, 15 Mar 2011 02:52:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 32DCA3A69E3 for ; Tue, 15 Mar 2011 02:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=3987; q=dns/txt; s=iport; t=1300182846; x=1301392446; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=H8NYDerLiFTpjWzhLQBVyyhabFPIPaI75ukfurdB1z0=; b=NobEYbFU/6WJwipjdkxzz8wjlPLD4Bx22bK+kTq1R13/ac6IOTopEGHz 1N+S+0Lg/AwxwcIOQ+S5fcRxJWzgioi4YZczsGW2UMZx+PWZ0ob2rNAfI TKkcAAX8ExCmC4tqNrL/BEPvU6EGmo5urJCp9ihW/SKKIB0iYActdQj1l o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAJ7Tfk2Q/khLgWdsb2JhbACYSY1FFAEBFiYlpWudAIViBIUuiwQ X-IronPort-AV: E=Sophos;i="4.62,321,1297036800"; d="scan'208";a="21751335" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2011 09:54:05 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2F9s4Km014690; Tue, 15 Mar 2011 09:54:04 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 15:24:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 15:24:01 +0530 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEA== References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> From: "Parthasarathi R (partr)" To: "Christer Holmberg" , "Dan Wing (dwing)" , "Flemming Andreasen (fandreas)" , "mmusic" X-OriginalArrivalTime: 15 Mar 2011 09:54:04.0012 (UTC) FILETIME=[EAD91AC0:01CBE2F6] Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? 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: , X-List-Received-Date: Tue, 15 Mar 2011 09:52:43 -0000 Christer, AFAIK, There is no restriction in terms of SIP B2BUA to handle signaling only and it is upto the implementation to decide. Also, this draft does not have restriction that SIP B2BUA and media server has to be co-exist in the same device. The draft talks about the scenario wherein SIP B2BUA communicates with media server using Megaco (H.248).=20 As I mentioned in other mail thread, ALG does not look appropriate and the draft is talking only about the specific type of B2BUA. In real deployment, Few vendors named these sort of B2BUA as "Session Border Controller or SBC" as well. SBC may not accepted in IETF as SBC does lot more. In case there is a need to have different name for these kind of SIP B2BUA entity to avoid the confusion, Let us work it out.=20 Thanks Partha =20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, March 15, 2011 12:14 PM To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? Hi Dan, In my definition of an ALG packets can be sent directly to its IP address. In my opinion, SIP B2BUA only focuses on SIP, while an ALG also focuses on other things, like media. A SIP ALG contains a SIP B2BUA. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Dan Wing Sent: 15. maaliskuuta 2011 4:39 To: 'Flemming Andreasen'; 'mmusic' Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? The draft uses the term "SIP ALG", which at least does not fit my definition of an ALG. An ALG doesn't have packets sent directly to its IP address; it does its job stealthily without awareness of one (or both) of the sessoin endpoints. In contrast, the function described in draft-ietf-mmusic-media-path-middleboxes is different -- packets are always sent to the IP address of the SIP "ALG", and packets are sent from the IP address of the SIP "ALG". This functionality is most often called a "server"=20 or a "proxy" -- not an ALG. =20 This distinction is important because this draft is closely related to functions common in NATs, which _do_ sometimes have SIP ALGs implemented in them. So ... can we change "SIP ALG" to something like "SIP proxy" or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a B2BUA, at least as best I understand the definition of a B2BUA, so B2BUA seems best. d > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Flemming Andreasen > Sent: Thursday, March 10, 2011 6:15 PM > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > middleboxes ? >=20 > We currently have a MMUSIC milestone for "considerations for using SDP > offer/answer with middleboxes". The latest draft for this WG item is >=20 > draft-ietf-mmusic-media-path-middleboxes-03.txt >=20 > which expired in January 2011. There hasn't been much discussion on=20 > this topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to=20 > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author this=20 > document. >=20 > Thanks >=20 > Flemming & Miguel [MMUSIC chairs] >=20 >=20 > _______________________________________________ > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From dwing@cisco.com Tue Mar 15 09:52:12 2011 Return-Path: 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 2FEA13A6E1C for ; Tue, 15 Mar 2011 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.317 X-Spam-Level: X-Spam-Status: No, score=-105.317 tagged_above=-999 required=5 tests=[AWL=-4.915, BAYES_00=-2.599, FRT_POSSIBLE=2.697, J_CHICKENPOX_31=0.6, MANGLED_FROM=2.3, MANGLED_LOOK=2.3, MANGLED_WORKS=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 QadshIW0E84u for ; Tue, 15 Mar 2011 09:52:06 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4C7D83A6C5B for ; Tue, 15 Mar 2011 09:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=48119; q=dns/txt; s=iport; t=1300208011; x=1301417611; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=YtJTrkkfFIXlCL7C+ud8abfOAVIhzr7oN4WD8EsH/w8=; b=nBRaF5zjpUs/ph16Jbg7IZu8qTDXXFJrYkvWG/xSOYXOgNALj04teYc9 crBjiGkpAxmYlD34VkGRgJVtdMRySXvSMXK3i4A3Py6ioF0zY8axvthFb BiDK/s40p7LP5YBPbXKVUe38Rn22BCXDcmDMlvmUwQHTTYYNg90oPLnhi 8=; X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="347139568" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 16:53:26 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2FGrNXs020007; Tue, 15 Mar 2011 16:53:23 GMT From: "Dan Wing" To: "'Christer Holmberg'" , "'Flemming Andreasen'" , "'mmusic'" References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 15 Mar 2011 09:53:22 -0700 Message-ID: <11cc01cbe331$7f2d29c0$7d877d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAAFTL8AA== Content-language: en-us Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? 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: , X-List-Received-Date: Tue, 15 Mar 2011 16:52:12 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Monday, March 14, 2011 11:44 PM > To: 'Dan Wing'; 'Flemming Andreasen'; 'mmusic' > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > middleboxes? > > > Hi Dan, > > In my definition of an ALG packets can be sent directly to its IP > address. See below, where I searched for "ALG" in existing RFCs. It seems that "ALG" is pretty well entrenched to describe the operation in a NAT or firewall, which does not have packets sent directly to the IP address of the NAT or firewall. RFC2101 is the first strong definition, and used the term 'pure ALG' and 'transparent ALG'. (I have not seen 'pure'/'transparent' used before I did this grep through the RFCs, so I am not suggesting that this MMUSIC draft adopt that terminology.) > In my opinion, SIP B2BUA only focuses on SIP, while an ALG also focuses > on other things, like media. A SIP ALG contains a SIP B2BUA. But the draft already separates the two. The draft currently says the SIP ALG only pertains to SIP, and a separate function ("middlebox") pertains to media. See Figure 1 of draft-ietf-mmusic-media-path-middleboxes-03 which shows: SIP +-----------------+ SIP +-----+ Signaling | SIP ALG | Signaling +-----+ | UAC |<----------->+-----------------+<----------->| UAS | +-----+ | MIDCOM Agent | +-----+ ^ +-----------------+ ^ | ^ | | Policy rule(s) | and NAT bindings | | v | | Media +-------------+ Media | +----------------->| Middlebox |<-----------------+ +-------------+ Changing "SIP ALG" in that diagram to "SIP B2BUA" would still fit your definition. -d ----- grep "\bALG\b" rfc*.txt rfc0759.txt: 14 ENCRYPT CODE(1),COUNT(3),ALG-ID(1), rfc1410.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423* rfc1500.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1540.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1600.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1610.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1720.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1780.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1800.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1880.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1920.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc1991.txt: 0 2 RND(n bytes) 0 ALG(1 byte) DEK(k bytes) CSUM(2 by tes) rfc1991.txt: ALG refers to the algorithm byte for the secret key algorithm use d to rfc1991.txt: ALG. For the IDEA encryption algorithm, type byte 1, the DEK is 16 rfc2000.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc2025.txt:2.1 Integrity Algorithm (I-ALG): rfc2025.txt:2.2 Confidentiality Algorithm (C-ALG): rfc2025.txt:2.3 Key Establishment Algorithm (K-ALG): rfc2025.txt: context. The keys used for C-ALG and any keyed I-ALGs (for rfc2025.txt: K-ALG cannot be used with unilateral authentication in rfc2025.txt:2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm: rfc2025.txt: Having established a context key using the negotiated K-ALG , rfc2025.txt: the longest key needed by any agreed C-ALG or keyed I-ALG, and rfc2025.txt: within the K-ALG parameters). rfc2025.txt: long. If 512-bit RSAEncryption is the K-ALG in use then th e rfc2025.txt: the K-ALG in use then the context key is the result of the rfc2025.txt: allowing negotiation of the O-ALG OWF during the context rfc2025.txt: C-ALG over the established context, and the integrity algorithms rfc2025.txt: selected by the target become ones that may be used for I-ALG ove r rfc2025.txt: list that it supports). Note that any C-ALG and I-ALG may be use d rfc2025.txt: algorithm). If this K-ALG is unacceptable to the target then the rfc2025.txt: chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator wil l rfc2025.txt: offers a set of possible O-ALGs (only a single O-ALG if no respon se rfc2025.txt: is expected). The (single) O-ALG chosen by the target becomes th e rfc2025.txt: or all of I-ALG, C-ALG, K-ALG, and O-ALG. rfc2025.txt: unilateral authentication no negotiation of K-ALG can be done (th e rfc2025.txt: target either accepts the K-ALG and context key given by the rfc2025.txt: two-pass K-ALG offered by the initiator and, again, can be reques ted rfc2025.txt: -- key estb. parameter corresponding to first K-ALG in set rfc2025.txt: -- unilateral authen. if the K-ALG in use does not pro vide rfc2025.txt: -- mandatory hashing procedure MD5 (in MANDATORY I-ALG ; rfc2025.txt: } -- for C-ALG (see Section 5.2 for discussion of QOP) rfc2025.txt: -- for I-ALG (see Section 5.2 for discussion of QOP) rfc2025.txt: -- to allow negotiation of K-ALG rfc2025.txt: -- key-estb-req (if init. used a 2-pass K-ALG), or (2) the rfc2025.txt: -- key-estb-req corresponding to the K-ALG supplied in rfc2025.txt: -- to the first K-ALG supplied in initiator's key-estb- id, rfc2025.txt: -- (if target selected a 2-pass K-ALG) rfc2025.txt: -- unilateral authen. if the K-ALG in use does not pro vide rfc2025.txt: -- mandatory hashing procedure (in MANDATORY I-ALG; rfc2101.txt: (ALG). Such a device acts as a termination point for the rfc2101.txt: to explicitly establish communication with the ALG that rfc2101.txt: ALG. rfc2101.txt: Another form of ALG makes communication through the ALG rfc2101.txt: "transparent" ALG, Ua would not be required to establish expli cit rfc2101.txt: connectivity to the ALG first, before starting to communicate with rfc2101.txt: communicating via an ALG involves changes to the network heade r. rfc2101.txt: An ALG could be used only at the beginning of a session for th e rfc2101.txt: purpose of authentication, after which the ALG goes away and rfc2101.txt: described in RFC1631 is a device that has both the NAT and ALG rfc2101.txt: a transparent ALG. rfc2101.txt: This is in contrast with an ALG that can support only the rfc2101.txt: applications coded into the ALG. rfc2101.txt: and ALG functionality in a single device could be used to over come rfc2101.txt: addresses, and would resort to the ALG functionality when deal ing rfc2101.txt: connection, but would use the ALG functionality to deal with t he rfc2101.txt: the device does not support the application via the ALG rfc2101.txt: communicating through either an ALG or a NAT. Since IP Securit y, rfc2101.txt: end-to-end, it is not clear how an ALG or NAT could modify rfc2101.txt: running a NAT or ALG probably needs to run two DNS servers, on e rfc2101.txt: inside and one outside the NAT or ALG, giving different answer s to rfc2101.txt: presumably not be valid across a NAT/ALG boundary, so we must rfc2154.txt: SIG ALG The signature algorithm for the Router Public Key . rfc2182.txt: an Application Layer Gateway (ALG). Such a device would understa nd rfc2182.txt: of the firewall. A server implemented in an ALG will usually be such rfc2196.txt: only subsections of the protocol. For example, an ALG for FTP ca n rfc2200.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc2300.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc2400.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1 423 rfc2500.txt:PEM-ALG PEM - Algorithms, Modes, and Identifiers 1 423 rfc2600.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail 14 23 rfc2663.txt: across realms, even with an ALG (defined below in section 2.9) rfc2663.txt:2.9. Application Level gateway (ALG) rfc2663.txt: different realm transparently. An ALG may interact with NAT to se t up rfc2663.txt: address resolution. A DNS-ALG must be employed in conjunction wit h rfc2663.txt: Specifically, the DNS-ALG must be capable of translating private rfc2663.txt: to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts the rfc2663.txt: DNS query, and in the response returned to Host-A the DNS-ALG rfc2663.txt: ALG modifies addresses (e.g., as in the case of Twice-NAT), rfc2663.txt: devoted to describing how FTP is supported on NAT devices. FTP A LG rfc2663.txt: response are an IP address and a TCP port in ASCII. An FTP ALG is rfc2663.txt: The ALG must also update NAT with appropriate data session tuples and rfc2663.txt: used by the ALG to correct the TCP sequence and acknowledge numbe rs. rfc2663.txt: not uncommon for an SNMP specific ALG to reside on a NAT router t o rfc2663.txt: to find NAT, ALG and firewall functions co-exist to provide secur ity rfc2694.txt: or indirectly (through the internal name servers). Using DNS-ALG rfc2694.txt: headers of the DNS packet and notify DNS-ALG to perform DNS paylo ad rfc2694.txt: changes. DNS-ALG would interact with NAT and use NAT state rfc2694.txt: Figure 2: NAT & DNS-ALG in the translation path of DNS packets rfc2694.txt: ALG implementations. Note, it is possible for a committed address rfc2694.txt: is 198.76.29.1. DNS-ALG would use this temporary binding to modif y rfc2694.txt:4. DNS payload modifications by DNS-ALG rfc2694.txt: headers of a DNS packet, DNS-ALG is responsible for updating the DNS rfc2694.txt: response. No changes are required to be made by DNS-ALG to the He ader rfc2694.txt: within the zone without intervention from NAT and DNS-ALG, so lon g as rfc2694.txt: hence will not be subject to consideration by DNS-ALG. rfc2694.txt: of scope for DNS-ALG (as described in section 7). rfc2694.txt: the DNS-ALG to be 0. rfc2694.txt: Figure 3: DNS-ALG operation in Bi-Directional NAT setup rfc2694.txt: Figure 4: DNS-ALG operation in Twice-NAT setup rfc2694.txt:7. DNS-ALG limitations and Future Work rfc2694.txt: DNS-ALG. At best, DNS-ALG would be able to transform secure dnsse c rfc2694.txt: ALG, NAT and IPsec gateway (providing secure tunneling service) a re rfc2694.txt: resident on the same device, DNS-ALG will have access to the IPse c rfc2694.txt: security association keys. The preceding section, "DNS-ALG rfc2694.txt: Further, with DNS-ALG, there is a possibility of denial of servic e rfc2700.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail 1 423 rfc2709.txt: application level gateway (ALG) to make the payload meaningful in rfc2709.txt: both realms. However, applications that require assistance of an ALG rfc2709.txt: they require assistance of an ALG or not, can benefit from IPsec rfc2709.txt: policies administered based on private realm addressing. An ALG w ill rfc2709.txt: subject to any NAT processing. IKE-ALG simply translates select rfc2709.txt: match. The following diagram illustrates how an IKE-ALG process rfc2709.txt: IKE-ALG may need to request NAT to set up address bindings and/or rfc2709.txt: sessions are negotiated. In the case the ALG is unable to setup t he rfc2709.txt: necessary address bindings or transport bindings, IKE-ALG will no t be rfc2709.txt: | (IPsec | IPC-NAT MAPs | IKE-ALG | rfc2709.txt: Figure 5. IKE-ALG translates Security policies, using NAT Maps. rfc2765.txt: boundary of the cloud, or to use Application Layer Gateways (A LG) rfc2765.txt: on dual nodes at the cloud's boundary. The ALG solution is le ss rfc2765.txt: also less robust since an ALG box is likely to be a single poi nt rfc2766.txt: 2.4 Application Level Gateway (ALG)........................... 5 rfc2766.txt: 4. Use of DNS-ALG for Address assignment......................... 8 rfc2766.txt: 6. FTP Application Level Gateway (FTP-ALG) Support............... 14 rfc2766.txt: hosts by using DNS for address resolution. A DNS-ALG [DNS-ALG] mu st rfc2766.txt: name to address mapping. Specifically, the DNS-ALG must be capab le rfc2766.txt:2.4 Application Level Gateway (ALG) rfc2766.txt: Application Level Gateway (ALG) [NAT-TERM] is an application spec ific rfc2766.txt: is application unaware and does not snoop the payload. ALG could work rfc2766.txt:4. Use of DNS-ALG for Address Assignment rfc2766.txt: In any case, the DNS-ALG's principle of operation described in th is rfc2766.txt: more than one query - reply pairs. The DNS-ALG SHOULD, in that ca se, rfc2766.txt: traverse through the NAT-PT router. The DNS-ALG on the NAT-PT dev ice rfc2766.txt: server on the V6 network to the V4 node, the DNS-ALG once again rfc2766.txt: DNS-ALG intercepts and translates the "A" query to "AAAA" or "A6" rfc2766.txt: translated by the DNS-ALG to: rfc2766.txt: The DNS-ALG also holds the mapping between FEDC:BA98::7654:3210 a nd rfc2766.txt: queries for nodes residing in the V6 network causing the DNS-ALG to rfc2766.txt: for DNS-ALG intervention. Otherwise, the queries will cross the V 6 rfc2766.txt: domain and are subject to DNS-ALG intervention. We recommend rfc2766.txt: Since Node-C may have IPv6 and/or IPv4 addresses, the DNS-ALG on the rfc2766.txt: NAT-PT. The DNS-ALG then, translates the reply adding the appropr iate rfc2766.txt: section on FTP-ALG describes the changes FTP-ALG would make to FT P rfc2766.txt:6. FTP Application Level Gateway (FTP-ALG) Support rfc2766.txt: address and TCP port information for the data session, an FTP-ALG is rfc2766.txt: node. FTP-ALG, facilitating transparent FTP between V4 and V6 nod es, rfc2766.txt: session and uses PORT or PASV command, the FTP-ALG will translate rfc2766.txt: commands, the FTP-ALG will simply translate the parameters to the se rfc2766.txt: If a V6 host originates the FTP session, however, the FTP-ALG has two rfc2766.txt: approaches to pursue. In the first approach, the FTP-ALG will lea ve rfc2766.txt: In the second approach, the FTP-ALG will translate the command rfc2766.txt: forwarding to the target V6 nodes. However, the FTP-ALG would be rfc2766.txt: reflect the new payload size. A table is used by the FTP-ALG to rfc2766.txt: Application Layer Gateways (ALG) need to be incorporated to provi de rfc2766.txt: NAT-PT, in its simplest form, without the support of DNS-ALG, rfc2766.txt: NAT-PT combined with a DNS-ALG provides bi-directional connecti vity rfc2766.txt: Section 7.5 of this document states that the DNS-ALG can not be rfc2766.txt: [DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. rfc2767.txt: NOTE: This action is similar to that of the DNS ALG (Application rfc2775.txt: gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be rfc2800.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 rfc2845.txt: Algorithm Name SAMPLE-ALG.EXAMPLE. rfc2845.txt: initial value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm na mes rfc2845.txt: defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT rfc2847.txt: 2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7 rfc2847.txt: md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG), rfc2847.txt: Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O- ALG) rfc2847.txt: * Integrity algorithms (I-ALG) rfc2847.txt: ALG that returns a zero length bit string regardless of t he rfc2847.txt: The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG M AC rfc2847.txt: * Confidentiality algorithm (C-ALG). rfc2847.txt: ALG because it is much slower than cast5CBC. One set of rfc2847.txt: * Key Establishment Algorithm (K-ALG) rfc2847.txt: * One-Way Function for Subkey Derivation Algorithm (O-ALG) rfc2847.txt: sha1 is a MANDATORY O-ALG in SPKM-3: rfc2847.txt:2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) rfc2847.txt: the lack of a target certificate, it MUST use the NULL-MAC I-ALG rfc2847.txt: Because RFC 2025 requires that the RSAEncryption K-ALG be present , rfc2847.txt: the RSAEncryption K-ALG algorithm. It is also free to use an algI D rfc2847.txt: to 1 if the only K-ALG in the key-estb-set field of Req-contents is rfc2847.txt: The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a rfc2847.txt: will use the first C-ALG (privacy), and I-ALG (integrity) algorit hms rfc2847.txt: choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable . rfc2900.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 rfc2956.txt: NAT even with an ALG. rfc2956.txt: limited deployability, and/or require ALG support in NATs. rfc2962.txt: This document describes an SNMP application layer gateway (ALG), rfc2962.txt: SNMP ALG. Specifically, when using SNMPv3's authentication and rfc2962.txt: ALG. rfc2962.txt: This document describes the ALG (Application Level Gateway) for t he rfc2962.txt: mapped from one group to another. The SNMP ALG is a specific cas e of rfc2962.txt: An SNMP ALG allows network management stations to manage multiple rfc2962.txt: or SNMP ALG, is a technique in which the payload of SNMP packets rfc2962.txt: needed. In this context, an SNMP ALG can be an additional compon ent rfc2962.txt: assumed to have a fixed IP address. Thus, SNMP ALG should only b e rfc2962.txt: A typical scenario where SNMP ALG is deployed as part of NAT is rfc2962.txt: |Regional Router|-----------------|Stub Router w/NAT and SNMP ALG | rfc2962.txt: Figure 1: SNMP ALG in a NAT configuration rfc2962.txt: | SNMP ALG |-----|Management device| rfc2962.txt: Figure 2: Using external SNMP ALG to manage two private network s rfc2962.txt: An SNMP ALG is required to scan all the payload of SNMP packets, to rfc2962.txt: In many cases the router may be unable to handle SNMP ALG and ret ain rfc2962.txt: SNMP ALG outside the router, as described in Figure 2. rfc2962.txt: A basic SNMP ALG is an SNMP ALG implementation in which only IP rfc2962.txt: SNMP ALG therefore does not need to be MIB aware. rfc2962.txt: An advanced SNMP ALG is an SNMP ALG implementation which is capab le rfc2962.txt: types. This implies that an advanced SNMP ALG is MIB aware. rfc2962.txt: network (i.e. the addressing realm). The SNMP ALG described in t his rfc2962.txt: sufficient information that an advanced SNMP ALG which understand s rfc2962.txt: A NAT unfriendly textual convention requires that an SNMP ALG, wh ich rfc2962.txt: An SNMP ALG should provide transparent IP address translation to rfc2962.txt: management applications. An SNMP ALG must be compatible with the rfc2962.txt: provided by the SNMP protocol. A fully transparent SNMP ALG must be rfc2962.txt: The SNMP ALG requires bi-directional NAT devices enroute, that rfc2962.txt: a single SNMP ALG, the external addresses assumed by each of the NAT rfc2962.txt: A general SNMP ALG must be capable to translate IP addresses in rfc2962.txt: SNMP ALG must reassemble IP packets which contain SNMP messages. The rfc2962.txt: A basic SNMP ALG is an SNMP ALG implementation in which only IP rfc2962.txt: basic SNMP ALG implementation parses an ASN.1/BER encoded SNMP pa cket rfc2962.txt: Once an IpAddress has been detected, the SNMP ALG checks the rfc2962.txt: The basic SNMP ALG does not require knowledge of any MIBs since i t rfc2962.txt: easy to implement. A basic SNMP ALG does not change the overall rfc2962.txt: However, a basic SNMP ALG is only able to translate IPv4 addresse s in rfc2962.txt: ALG is not capable to translate IP addresses in objects that are rfc2962.txt: basic SNMP ALG is restricted to the first out of the four possibl e rfc2962.txt: An advanced SNMP ALG is an SNMP ALG implementation which is capab le rfc2962.txt: types. Hence, an advanced SNMP ALG may be able to transparently map rfc2962.txt: This implies that an advanced SNMP ALG must be MIB aware. rfc2962.txt: An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID) rfc2962.txt: conceptual table is a required feature of an advanced SNMP ALG. IP rfc2962.txt: example shows that an advanced SNMP ALG may change the overall pa cket rfc2962.txt: Another effect of an advanced SNMP ALG is that it changes the rfc2962.txt: incorrectly report agents behind an advanced SNMP ALG as broken S NMP rfc2962.txt: size of the SNMP packet. A basic SNMP ALG does therefore never rfc2962.txt: An advanced SNMP ALG may change the size of an SNMP packet since a rfc2962.txt: receiver can handle. An SNMP ALG which increases the size of an SNMP rfc2962.txt: anymore. Thus, an advanced SNMP ALG may cause some SNMPv3 rfc2962.txt: applications is not an achievable task. The basic SNMP ALG descr ibed rfc2962.txt: base type. Such an SNMP ALG achieves only very limited transpare ncy rfc2962.txt: SNMP ALG in place. rfc2962.txt: An advanced SNMP ALG described in Section 4.2 achieves better rfc2962.txt: transparency. However, an advanced SNMP ALG can only claim to be rfc2962.txt: understood by the advanced SNMP ALG implementation and for a give n rfc2962.txt: against unauthorized access. Thus, an SNMP ALG must have access to rfc2962.txt: invalidating them. Furthermore, the SNMP ALG must track any key rfc2962.txt: Finally, an SNMP ALG only deals with SNMP traffic and does not mo dify rfc2962.txt: is occurring, even in the presence of an SNMP ALG. rfc2962.txt: (Just replace the box SNMP ALG with a box labeled SNMP PROXY in rfc2962.txt: Furthermore, an SNMP ALG does not need to have knowledge of the rfc2962.txt: However, the usage of SNMP ALG introduces new problems when SNMPv 3 rfc2962.txt: and auth/priv) can only be processed by an SNMP ALG which support s rfc2962.txt: the keys in use. Furthermore, as keys may be updated, the SNMP A LG rfc2962.txt: SNMP ALG which maintains the keys for a set of SNMP engines is a rfc2962.txt: An SNMP ALG implementation which maintains lists of (localized) k eys rfc2962.txt: use these keys. An SNMP ALG implementation which maintains passw ords rfc2962.txt: SNMP ALG implementation must be properly secured so that people w ho rfc2962.txt: limited transparency provided by a basic SNMP ALG. Basic SNM P rfc2962.txt: advanced SNMP ALG is much more complex and less efficiency th an a rfc2962.txt: basic SNMP ALG. An advanced SNMP ALG may break the lexicograp hic rfc2962.txt: A basic SNMP ALG as described in Section 4.1 was implemented for rfc2962.txt: described in Figure 2, where SNMP ALG was combined with the NAT rfc2962.txt: an internal contradiction caused by a basic SNMP ALG since the rfc2993.txt: 7.2. ALG complexity............................................ . 14 rfc2993.txt: configured application specific gateways (ALG's), endpoints can w ork rfc2993.txt: ALG - Application Layer Gateway: inserted between application pee rs rfc2993.txt: NAT/ALG - combines ALG functions with simple NAT. Generally more rfc2993.txt: DNS/ALG - a special case of the NAT/ALG, where an ALG for the DN S rfc2993.txt: Firewall - access control point that may be a special case of an ALG, rfc2993.txt: arbitrarily inserted. Unlike an ALG, the application on at least one rfc2993.txt: pair of hosts communicating through either an ALG or a NAT. rfc2993.txt: machines, the processing and I/O capabilities of the NAT/ALG devi ce rfc2993.txt: While RSIP addresses the transparency and ALG issues, for the rfc2993.txt: OSPF ALG it would actually be possible to route across a NAT rfc2993.txt: 7.2. ALG complexity rfc2993.txt: NAT/ALG was to be one or more devices at each physical location, and rfc2993.txt: the data stream carries an IP address; the central collector or A LG rfc2993.txt: As noted in the RFC-2694 [15], the DNS/ALG cannot support secure DNS rfc2993.txt: It is also the case that DNS/ALG will break any modified, signed rfc2993.txt: modified by the DNS/ALG if it had access to the source authentica tion rfc2993.txt: this key, to maintain source authenticity. So NATs that use DNS/ ALG rfc2993.txt: Embedding the DNS server, or a DNS ALG in the NAT device will rfc2993.txt: appropriate ALG or establish a VPN to isolate the application f rom rfc2993.txt: - If the environment uses secure DNS records, the DNS/ALG will rfc2993.txt: justifications to registries or DNS/ALG rfc2993.txt: DNS/ALG breaks DNSsec replies rfc2993.txt: these technologies, NAT and the DNS/ALG work-around, hinder rfc2993.txt: effects from all applications. While this solves the ALG issues, it rfc2999.txt:This document describes the ALG (Application Level Gateway) for the SNMP rfc3000.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 rfc3022.txt: and alterations. FTP is the most popular ALG resident on NAT rfc3022.txt: devices. Applications requiring ALG intervention must not have t heir rfc3022.txt: payload encoded, as doing that would effectively disables the ALG , rfc3022.txt: unless the ALG has the key to decrypt the payload. rfc3022.txt: "TU Ports", "ALG" and others, used throughout the document, may b e rfc3022.txt: ALG to monitor the control session payload to determine the ensui ng rfc3022.txt: data session parameters. FTP ALG is an integral part of most NAT rfc3022.txt: The FTP ALG would require a special table to correct the TCP sequ ence rfc3022.txt: outbound from a private domain, DNS ALG may be obviated from use in rfc3027.txt: 4.0 Protocols that can work with the aid of an ALG ............ 8 rfc3027.txt: transparency. Unlike NAT, the function of ALG is application rfc3027.txt: ALG may be able to provide work around in some cases. But, if th e rfc3027.txt: with a DNS-ALG might be able to offer the necessary application l evel rfc3027.txt: payload is not encrypted, an ALG may in some cases be able to pro vide rfc3027.txt: across realms. The complexity of ALG depends on the application rfc3027.txt: NAT device supports DNS-ALG. Examples of Peer-to-peer applicatio ns rfc3027.txt: Alternately, an ALG may be required to interact with NAT to keep the rfc3027.txt: Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be rfc3027.txt: not to let NAT drop the address binding. Alternately, an ALG wil l rfc3027.txt: Therefore, an ALG cannot be written. rfc3027.txt: because they can easily be spoofed. NAT and DNS-ALG cannot wo rk rfc3027.txt: NAT device might solicit the help of an ALG to replace the IP add ress rfc3027.txt: without requiring an ALG. But, this approach increases the secur ity rfc3027.txt: available. As the ALG tampers with the IP addresses it will also not rfc3027.txt:4.0 Protocols that can work with the aid of an ALG rfc3027.txt: Say, an FTP client is in a NAT supported private network. An FTP ALG rfc3027.txt: impossible for an ALG to update the IP addresses in the command rfc3027.txt: FTP protocol, eliminating further processing through ALG, if the rfc3027.txt: an RSVP-ALG must be able to replace the IP addresses based upon t he rfc3027.txt: an RSVP-ALG will not work when RSVP Integrity Object is used. rfc3027.txt: resolutions. A DNS-ALG would be required to perform address to n ame rfc3027.txt: conversions on DNS queries and responses. [DNS-ALG] describes DN S- rfc3027.txt: ALG rfc3027.txt: application specific session. As a result, DNS-ALG will be requi red rfc3027.txt: server for external name lookup. No ALG is required when the nam e rfc3027.txt: cryptographic keys, an SMTP-ALG may be used to translate the IP rfc3027.txt: NAT alone, without the ALG. This can cause problems when debuggi ng rfc3027.txt: would require a SIP-ALG. rfc3027.txt: significance when traversing a NAT. Thus a SIP-ALG would need th e rfc3027.txt: As an alternative to an SIP-ALG, SIP supports a proxy server whic h rfc3027.txt: device. A work around for this would be for the ALG to examine t he rfc3027.txt: control session. Alternately, the ALG could simply redirect all rfc3027.txt: For bi-Directional NAT, you will not need an ALG. Bi-directional NAT rfc3027.txt: (This makes it particularly difficult for the ALG, which will be rfc3027.txt: encrypted, it is impossible for the ALG to decipher the data stre am, rfc3027.txt: through a NAT device, an H.323-ALG will be required to examine th e rfc3027.txt: ALG would have to be cognizant of the various gateway discovery rfc3027.txt: cases, as described in [SNMP-ALG], an SNMP ALG may be used to rfc3027.txt: addresses. Such an ALG assumes static address mapping and bi- rfc3027.txt: conventions) understood by the SNMP-ALG implementation and for a rfc3027.txt: optionally privacy) is enabled, unless the ALG has access to secu rity rfc3027.txt: require an ALG for the games to work transparently through rfc3027.txt: [SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP rfc3027.txt: [DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. rfc3102.txt: requires the presence of an application layer gateway (ALG) withi n rfc3102.txt: with an ALG for FTP, which transmits IP addresses and port number s on rfc3102.txt: if an RSIP ALG is installed. The RSIP data flow, however, will h ave rfc3103.txt: will require an application layer gateway (ALG) for any protocol that rfc3234.txt: accompanied by an ALG (Application Level Gateway - see below). I t rfc3234.txt: In practice, SIIT and NAT-PT will both need an associated ALG and rfc3234.txt: ALG; another (less common) name for them is a TLG. As with ALGs, rfc3234.txt: may be distinct, this is in practice very similar to a NAT plus A LG. rfc3235.txt: an Application Level Gateway (ALG) may still permit operation of the rfc3235.txt: protocol. Depending on the encoding used in a protocol, an ALG m ay rfc3235.txt: that the ALG design may be simple and automated. ALGs typically rfc3235.txt: the ALG should be simple and not require excessive computation or rfc3235.txt: NAT (and thus can require ALG support) are also issues for firewa lls. rfc3235.txt: new application or service, the requirement for an ALG will limit rfc3235.txt: same host IP address may not function without an ALG. rfc3235.txt: any other simple TCP connection, and so an ALG is not required. rfc3235.txt: private realm. Through use of a DNS-ALG [RFC2694], lookups are rfc3235.txt: devices, Bi-directional NAT devices (in conjunction with DNS-ALG) are rfc3257.txt: Application Layer Gateway (ALG) which will intelligently translat e rfc3278.txt: ALG]. rfc3278.txt: [PKI-ALG] Bassham, L., Housley R. and W. Polk, "Algorithms and rfc3300.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 rfc3303.txt:2.6. ALG rfc3303.txt: middlebox function. An ALG examines application traffic in trans it rfc3303.txt: An ALG may be a co-resident with a middlebox or reside externally , rfc3303.txt: MIDCOM agents are entities performing ALG functions, logically rfc3303.txt: ALG. rfc3303.txt: session tuples for which the agent is authorized to act as ALG), rfc3303.txt: session tuples for which the agent is authorized to act as ALG), rfc3338.txt: there isn't a DNS ALG as in NAT-PT, so there is no interference w ith rfc3424.txt: be dropped by the NAT anyway, because there's no ALG.) rfc3489.txt: an ALG, or MIDCOM. rfc3600.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 rfc3654.txt: MAY support other high touch functions (e.g., NAT, ALG). rfc3665.txt: 3.5. Session Through a SIP ALG. . . . . . . . . . . . . . . . 46 rfc3665.txt: ALG alg1.atlanta.example.com 192.0.2. 128 rfc3665.txt:3.5. Session Through a SIP ALG rfc3665.txt: Alice ALG Proxy 2 Bob rfc3665.txt: Alice completes a call to Bob through a ALG (Application Layer rfc3665.txt: Gateway) and a SIP Proxy. The routing through the ALG is rfc3665.txt: that the media stream setup is not end-to-end - the ALG terminate s rfc3665.txt: both media streams and bridges them. This is done by the ALG rfc3665.txt: F1 INVITE Alice -> SIP ALG rfc3665.txt: F2 INVITE SIP ALG -> Proxy 2 rfc3665.txt: F3 100 Trying SIP ALG -> Alice rfc3665.txt: /* SIP ALG prepares to proxy data from port 192.0.2.128/2000 to rfc3665.txt: F5 100 Trying Proxy 2 -> SIP ALG rfc3665.txt: F7 180 Ringing Proxy 2 -> SIP ALG rfc3665.txt: F8 180 Ringing SIP ALG -> Alice rfc3665.txt: F10 200 OK Proxy 2 -> SIP ALG rfc3665.txt: F11 200 OK SIP ALG -> Alice rfc3665.txt: /* The ALG prepares to proxy packets from 192.0.2.128/ rfc3665.txt: F12 ACK Alice -> SIP ALG rfc3665.txt: F13 ACK SIP ALG -> Bob rfc3665.txt: /* RTP streams are established between Alice and the ALG and rfc3665.txt: between the ALG and B*/ rfc3665.txt: F14 BYE Alice -> SIP ALG rfc3665.txt: F15 BYE SIP ALG -> Bob rfc3665.txt: F16 200 OK Bob -> SIP ALG rfc3665.txt: F17 200 OK SIP ALG -> Alice rfc3700.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 rfc3890.txt: ALG - Application Level Gateway. rfc3890.txt: 2. The SDP has been changed by an Application Level Gateway (ALG) . rfc3923.txt: o The SHA-1 message digest as specified in [CMS-ALG] section 2.1 . rfc3923.txt: specified in [CMS-ALG] section 3.2. rfc3923.txt: o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG ] rfc3923.txt: [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) rfc4028.txt: SIP Network Address Translator (NAT) Application Level Gateway (A LG) rfc4028.txt: [6]. The ALG embedded in a NAT will need to maintain state for t he rfc4038.txt: translated by NAT-PT DNS-ALG. In some cases, one might be tempte d to rfc4162.txt: [SEED-ALG]. The SEED homepage, rfc4162.txt: [SEED-ALG] Park, J., Lee, S., Kim, J., and J. Lee, "The SEED rfc4215.txt: ALG Application Level Gateway rfc4215.txt: 1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to rfc4226.txt: IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the purpos e of rfc4226.txt: K for ALG. Both maintain a counter C, initially zero, and the us er rfc4226.txt: authenticates itself by sending ALG(K,C) to the server. The latt er rfc4226.txt: ALG(K,i) for some i in the range C,...,C + s-1, where s is the rfc4226.txt: algorithm ALG is being used, knowing the system design, and knowi ng rfc4226.txt: ALG: K x {0,1}^c --> R. rfc4226.txt: A = ALG(K,C) rfc4226.txt: If A == ALG(K,i) then Win = TRUE; C = i + 1 rfc4472.txt: 8.1. NAT-PT with DNS-ALG ..................................... ..18 rfc4472.txt:8.1. NAT-PT with DNS-ALG rfc4472.txt: The DNS-ALG component of NAT-PT [RFC2766] mangles A records to lo ok rfc4635.txt: HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC rfc4635.txt: ALG.REG.INT, based on MD5 [RFC1321]. rfc4635.txt: The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are rfc4635.txt: Mandatory HMAC-MD5.SIG-ALG.REG.INT rfc4787.txt: the NAT administrator to enable or disable each ALG separat ely. rfc4787.txt: standards track specifications that define an ALG can update t his rfc4787.txt: the NAT administrator to enable or disable each ALG separat ely. rfc4852.txt: Application Layer Gateway (ALG) between the incompatible hosts. rfc4852.txt: diverse transition mechanisms. For example, an ALG collocated wi th rfc4924.txt: proxies. Furthermore, the ALG or proxy must be updated whenev er a rfc4924.txt: implementations. No matter how well an ALG is implemented, barri ers rfc4924.txt: "transparent ALG" is a contradiction in terms. rfc4961.txt: Gateway (ALG) functionality. Such NATs require that endpoints us e rfc4966.txt: 2. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . . 7 rfc4966.txt: 3. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13 rfc4966.txt: 4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16 rfc4966.txt: 4.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . . . 19 rfc4966.txt: o Issues with NAT-PT DNS ALG (Application Layer Gateway) in RFC 2766 rfc4966.txt: [DNS-ALG-ISSUES] rfc4966.txt: o NAT-PT DNS ALG Solutions [DNS-ALG-SOL] rfc4966.txt: Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this docum ent) rfc4966.txt: NAT-PT could avoid the use of the DNS-ALG. rfc4966.txt: passed to the hosts in the absence of the DNS-ALG. Therefore, th is rfc4966.txt: document assumes that the DNS-ALG is an integral part of NAT-PT; rfc4966.txt: accordingly, issues with the DNS-ALG must be considered as issues for rfc4966.txt: Note that issues not specifically related to the use of the DNS-A LG rfc4966.txt: o Issues that are independent of the use of a DNS-ALG and are, rfc4966.txt: o Issues that are exacerbated by the use of a DNS-ALG and are, rfc4966.txt: ALG to create address mappings with limited lifetimes means rfc4966.txt: o Issues that result from the use of a DNS-ALG and are, therefor e, rfc4966.txt: * Address selection issues and resource consumption in a DNS- ALG rfc4966.txt: * Limitations on DNS security capabilities when using a DNS-A LG. rfc4966.txt:2. Issues Unrelated to an DNS-ALG rfc4966.txt: the consequences as part of the description of the FTP ALG. Simi lar rfc4966.txt: Assuming that the NAT-PT contains a colocated ALG for one of the rfc4966.txt: relevant protocols, the ALG could replace the embedded IP address es rfc4966.txt: SCTP will need an associated "ALG" -- actually a Transport Layer rfc4966.txt: naively implemented DNS-ALG could create such bindings from spoof ed rfc4966.txt:3. Issues Exacerbated by the Use of DNS-ALG rfc4966.txt: DNS-ALG in the NAT-PT to provide the mapped address needed to rfc4966.txt: IPv6 router for the site so that the DNS-ALG is able to examine a ll rfc4966.txt: These constraints are described in more detail in [DNS-ALG-ISSUES ]. rfc4966.txt: [DNS-ALG-SOL] proposes a solution for flows initiated from the IP v6 rfc4966.txt: addresses would also use the NAT-PT DNS-ALG. rfc4966.txt: point of failure in the network. The addition of the DNS-ALG in rfc4966.txt: Using the DNS-ALG to create address bindings requires that the rfc4966.txt: Additionally, the DNS-ALG needs to determine the initial lifetime of rfc4966.txt: be determined heuristically. The DNS-ALG does not know which rfc4966.txt: an extended ALG (which has all the issues discussed in Section 2. 1) rfc4966.txt: The use of the DNS-ALG in NAT-PT introduces another vulnerability rfc4966.txt: [DNS-ALG-ISSUES] exploits the use of DNS queries traversing NAT-P T to rfc4966.txt: [DNS-ALG-SOL] proposes to mitigate the DoS attack by using Access rfc4966.txt:4. Issues Directly Related to Use of DNS-ALG rfc4966.txt: [DNS-ALG-ISSUES] discusses NAT-PT DNS-ALG issues with regard to rfc4966.txt: address selection. As specified in [RFC2766], the DNS-ALG return s rfc4966.txt: [DNS-ALG-SOL] proposes a solution that involves modification to t he rfc4966.txt: o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT rfc4966.txt: it returns them. The DNS-ALG then forwards this response t o rfc4966.txt: The NAT-PT DNS-ALG will intercept the error or empty return and rfc4966.txt: IPv4 address, the ALG creates a binding and synthesizes a rfc4966.txt: passing through a DNS ALG because the NAT-PT may have to make two rfc4966.txt: selection that is identified in [DNS-ALG-ISSUES]. Applications h ave rfc4966.txt: no way of knowing that the IPv6 address returned from the DNS-ALG is rfc4966.txt: through the NAT-PT DNS-ALG, the DNS-ALG will translate the respon se rfc4966.txt: happens because the DNS-ALG specified in [RFC2766] operates rfc4966.txt: state about queries passed through the DNS-ALG, and hence to resp ond rfc4966.txt:4.4. DNS-ALG and Multi-Addressed Nodes rfc4966.txt: these addresses. Since the DNS-ALG in the NAT-PT has no knowledg e rfc4966.txt: to authenticate DNS responses. The DNS-ALG modifies DNS query rfc4966.txt: Workarounds have been proposed, such as making the DNS-ALG behave rfc4966.txt: [DNS-ALG-ISSUES] Durand, A., "Issues with NAT-PT DNS ALG in rfc4966.txt: [DNS-ALG-SOL] Hallingby, P. and S. Satapati, "NAT-PT DNS ALG rfc4973.txt: BIT CSPF - A CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG rfc4973.txt: TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 rfc5055.txt: The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It rfc5055.txt: defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algori thms rfc5055.txt: certificate [PKIX-1]. Supported algorithms are defined in [PKIX- ALG] rfc5055.txt: specified in [PKIX-ALG]. SCVP servers that support serverPublicK eys rfc5055.txt: [PKIX-ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and rfc5245.txt: If an ALG is SIP aware but not ICE aware, ICE will work through i t as rfc5245.txt: long as the ALG correctly modifies the SDP. A correct ALG rfc5245.txt: o The ALG does not modify the m and c lines or the rtcp attribut e if rfc5245.txt: depends on the state of the ALG: rfc5245.txt: If the ALG already has a binding established that maps an rfc5245.txt: values in the m and c lines or rtcp attribute, the ALG uses rfc5245.txt: If the ALG does not already have a binding, it creates a ne w rfc5245.txt: prevents the ALG from manipulating the SDP messages and interferi ng rfc5245.txt: to provide "generic" ALG functionality. These generic ALGs hunt for rfc5274.txt: SignedData (see [CMS-ALG]). Entities MAY verify other signature rfc5274.txt: SignedData (see [CMS-ALG]). Other signatures algorithms MAY be u sed rfc5274.txt: EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-O AEP rfc5274.txt: [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CM S) rfc5382.txt: Gateway (ALG) behavior that may interfere with NAT traversal. rfc5382.txt: ALG is left unspecified because of legacy concerns: as of writ ing rfc5382.txt: passive (PASV) mode by default and require an ALG to traverse rfc5382.txt: privacy reasons or for ALG support) must ensure that TCP packets with rfc5389.txt: but misguided attempt at providing a generic ALG function. Such rfc5480.txt: (ECC). It updates RFC 3279 [PKI-ALG]. This document specifies t he rfc5480.txt: [PKI-ALG] and [PKI-ADALG], even though the associated text is rfc5480.txt: unaffected. By updating all of the ASN.1 from [PKI-ALG] in this rfc5480.txt: -- Note that in [PKI-ALG] the secp192r1 curve was referred to a s rfc5480.txt: The security considerations in [PKI-ALG] apply. rfc5480.txt: As noted in [PKI-ALG], the use of MD2 and MD5 for new application s is rfc5480.txt: Value [PKI-ALG]. If an implementation needs to use these options , rfc5480.txt: [PKI-ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms a nd rfc5480.txt: -- Note that in [PKI-ALG] the secp192r1 curve was referred to as rfc5597.txt: needed for an Application Level Gateway (ALG) to function properl y. rfc5753.txt: static-static DH, which is specified in [CMS-ALG]. Ephemeral-sta tic rfc5753.txt: specified jointly in the documents [CMS-ALG] and [CMS-DH]. rfc5753.txt: [PKI-ALG]. rfc5753.txt: in [CMS-ALG] and [CMS-SHA2]. rfc5753.txt: in [PKI-ALG]. rfc5753.txt: [CMS-ALG] and [CMS-AES]. rfc5753.txt: algorithms are found in [CMS-ALG] and [CMS-AES]. The content rfc5753.txt: algorithms are found in [CMS-ALG] and [HMAC-SHA2]. rfc5753.txt: ECDSA-Sig-Value is specified in [PKI-ALG]. Within CMS, ECDSA-Sig - rfc5753.txt: the elliptic curve domain parameters specified by [PKI-ALG]. rfc5753.txt: [CMS-ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], rfc5753.txt: lists curves [PKI-ALG] for the key sizes. rfc5753.txt: sizes and message digest algorithms. It also lists curves [PKI-A LG] rfc5753.txt: [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) rfc5753.txt: [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T . rfc5753.txt: -- From [PKI-ALG] rfc5753.txt: -- From [CMS-ALG] rfc5753.txt: -- Message Digest Algorithms: Imported from [PKI-ALG] and [RSAOAE P] rfc5753.txt: -- Signature Algorithms: Imported from [PKI-ALG] rfc5753.txt: -- Key Wrap Algorithms: Imported from [CMS-ALG] and [CMS-AES] rfc5753.txt: -- Content Encryption Algorithms: Imported from [CMS-ALG] rfc5753.txt: -- Originator Public Key Algorithms: Imported from [PKI-ALG] rfc5753.txt: -- [PKI-ALG] rfc5753.txt: -- commented out in [PKI-ALG] implicitCurve NULL rfc5753.txt: -- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomai n rfc5753.txt: -- commented out in [PKI-ALG] ... rfc5753.txt:-- ECDSA Signature Value: Imported from [PKI-ALG] rfc5753.txt:-- [PKI-ALG] rfc5753.txt:-- commented out in [PKI-ALG] implicitCurve NULL rfc5753.txt:-- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain rfc5753.txt:-- commented out in [PKI-ALG] ... rfc5780.txt: 3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11 rfc5780.txt:3.6. Detecting a Generic Application Level Gateway (ALG) rfc5780.txt: to provide "generic" ALG functionality. These generic ALGs hunt for rfc5780.txt: not match, there is a NAT with a generic ALG in the path. This t est rfc5857.txt: [CRYPTO-ALG] (or its successor). rfc5857.txt: [CRYPTO-ALG] Manral, V., "Cryptographic Algorithm Implementation rfc5858.txt: [CRYPTO-ALG] (or its successor). rfc5858.txt: [CRYPTO-ALG] Manral, V., "Cryptographic Algorithm Implementation rfc5912.txt: -- Note that in [PKI-ALG] the secp192r1 curve was referred to as rfc6071.txt: IKE-ALG (Application Level Gateway) that translates policies from rfc759.txt: 14 ENCRYPT CODE(1),COUNT(3),ALG-ID(1), rfcxx00.txt:PEM-ALG Privacy Enhancement for Internet Electronic Mail: 1 423 From keith.drage@alcatel-lucent.com Wed Mar 16 05:01:37 2011 Return-Path: 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 B85BC3A6920 for ; Wed, 16 Mar 2011 05:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.754 X-Spam-Level: X-Spam-Status: No, score=-105.754 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 nadouJLpaGnv for ; Wed, 16 Mar 2011 05:01:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 5915D3A687A for ; Wed, 16 Mar 2011 05:01:36 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2GC2Iqq010919 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Mar 2011 13:02:56 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 16 Mar 2011 13:02:47 +0100 From: "DRAGE, Keith (Keith)" To: "Parthasarathi R (partr)" , Christer Holmberg , "Dan Wing (dwing)" , "Flemming Andreasen (fandreas)" , mmusic Date: Wed, 16 Mar 2011 13:02:46 +0100 Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8g Message-ID: References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes? 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: , X-List-Received-Date: Wed, 16 Mar 2011 12:01:37 -0000 The only definition of B2BUA that I know of comes in RFC 3261 (sort of) whe= re the scope is limited to SIP. So a UA acts in one or more directions as a= SIP UA. Whatever else it does is outside the definition. That I believe ma= tches with what Christer is saying. If you want something that defines what it does with media, then you need s= omething that defines that, but using the term B2BUA to do that is probably= not the best choice. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Parthasarathi R (partr) > Sent: 15 March 2011 09:54 > To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen (fandreas); > mmusic > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > middleboxes? >=20 > Christer, >=20 > AFAIK, There is no restriction in terms of SIP B2BUA to handle signaling > only and it is upto the implementation to decide. Also, this draft does > not have restriction that SIP B2BUA and media server has to be co-exist > in the same device. The draft talks about the scenario wherein SIP B2BUA > communicates with media server using Megaco (H.248). >=20 > As I mentioned in other mail thread, ALG does not look appropriate and > the draft is talking only about the specific type of B2BUA. In real > deployment, Few vendors named these sort of B2BUA as "Session Border > Controller or SBC" as well. SBC may not accepted in IETF as SBC does lot > more. In case there is a need to have different name for these kind of > SIP B2BUA entity to avoid the confusion, Let us work it out. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Tuesday, March 15, 2011 12:14 PM > To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > middleboxes? >=20 >=20 > Hi Dan, >=20 > In my definition of an ALG packets can be sent directly to its IP > address. >=20 > In my opinion, SIP B2BUA only focuses on SIP, while an ALG also focuses > on other things, like media. A SIP ALG contains a SIP B2BUA. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Dan Wing > Sent: 15. maaliskuuta 2011 4:39 > To: 'Flemming Andreasen'; 'mmusic' > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > middleboxes ? >=20 > The draft uses the term "SIP ALG", which at least does not fit my > definition of an ALG. An ALG doesn't have packets sent directly to its > IP address; it does its job stealthily without awareness of one (or > both) of the sessoin endpoints. In contrast, the function described in > draft-ietf-mmusic-media-path-middleboxes > is different -- packets are always sent to the IP address of the SIP > "ALG", and packets are sent from the IP address of the SIP "ALG". This > functionality is most often called a "server" > or a "proxy" -- not an ALG. >=20 > This distinction is important because this draft is closely related to > functions common in NATs, which _do_ sometimes have SIP ALGs implemented > in them. >=20 > So ... can we change "SIP ALG" to something like "SIP proxy" > or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a > B2BUA, at least as best I understand the definition of a B2BUA, so B2BUA > seems best. >=20 > d >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Flemming Andreasen > > Sent: Thursday, March 10, 2011 6:15 PM > > To: mmusic > > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with > > middleboxes ? > > > > We currently have a MMUSIC milestone for "considerations for using SDP >=20 > > offer/answer with middleboxes". The latest draft for this WG item is > > > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > > > which expired in January 2011. There hasn't been much discussion on > > this topic for a while, and the current draft authors are not planning >=20 > > continued work on the draft, so we need new authors if we are to > > continue with this WG item. Please let us know if > > 1) You are still interested in this deliverable > > 2) You are willing to actively contribute to and/or author this > > document. > > > > Thanks > > > > Flemming & Miguel [MMUSIC chairs] > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > 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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partr@cisco.com Wed Mar 16 05:44:00 2011 Return-Path: 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 CE3C03A68EA for ; Wed, 16 Mar 2011 05:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.044 X-Spam-Level: X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 rs0ge8LegKPA for ; Wed, 16 Mar 2011 05:43:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E5E3E3A67F1 for ; Wed, 16 Mar 2011 05:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6391; q=dns/txt; s=iport; t=1300279525; x=1301489125; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ZnRWj3euzxYZUP+GrUhM+f4gTNHIzMCr0nCH44X6gRg=; b=V5H1Cgo5duLSB0F3tSw1E+y00lexcveBV4U8SlGaBBmAgiHyh44XDQh2 HtMXQXbcQQURSpppOY4miMQgOCDES+2UUoR8425eFTh4uGTd74HaXpuob ADn2CtLrcGfDnbMtbinVUZnO9Vqv3yA0L+C/HD0F3UEf/QlDC2myxbpEq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAG5NgE2Q/khLgWdsb2JhbACYUY03FAEBFiYlpGqcVIViBIUtiwQ X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="79442964" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2011 12:45:21 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GCjK0P011371; Wed, 16 Mar 2011 12:45:21 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 18:15:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 18:15:19 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8gAAFBYCA= References: <4D798594.4000406@cisco.com> <0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> From: "Parthasarathi R (partr)" To: "DRAGE, Keith (Keith)" , "Christer Holmberg" , "Dan Wing (dwing)" , "Flemming Andreasen (fandreas)" , "mmusic" X-OriginalArrivalTime: 16 Mar 2011 12:45:20.0300 (UTC) FILETIME=[0267F6C0:01CBE3D8] Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes? 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: , X-List-Received-Date: Wed, 16 Mar 2011 12:44:00 -0000 Keith, Sorry in case "media" word in my mail mislead you. Dan explains in another mail thread (http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) why SIP ALG is not appropriate and B2BUA is more appropriate for this draft. Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly fits your definition of B2BUA as it involves only SIP & SDP and media is defined as middlebox.=20 I have mentioned as kind of B2BUA because the draft concentrates on callflow where one side of B2BUA acts as UAC and other side always acts as UAS. IMO, the draft currently does not address B2BUA 3PCC callflows specific issues. In the current scope of draft is continued for the draft, the new definition may be required or draft text has to clarify the scope. Thanks Partha -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Wednesday, March 16, 2011 5:33 PM To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes? The only definition of B2BUA that I know of comes in RFC 3261 (sort of) where the scope is limited to SIP. So a UA acts in one or more directions as a SIP UA. Whatever else it does is outside the definition. That I believe matches with what Christer is saying. If you want something that defines what it does with media, then you need something that defines that, but using the term B2BUA to do that is probably not the best choice. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Parthasarathi R (partr) > Sent: 15 March 2011 09:54 > To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen=20 > (fandreas); mmusic > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > middleboxes? >=20 > Christer, >=20 > AFAIK, There is no restriction in terms of SIP B2BUA to handle=20 > signaling only and it is upto the implementation to decide. Also, this > draft does not have restriction that SIP B2BUA and media server has to > be co-exist in the same device. The draft talks about the scenario=20 > wherein SIP B2BUA communicates with media server using Megaco (H.248). >=20 > As I mentioned in other mail thread, ALG does not look appropriate and > the draft is talking only about the specific type of B2BUA. In real=20 > deployment, Few vendors named these sort of B2BUA as "Session Border=20 > Controller or SBC" as well. SBC may not accepted in IETF as SBC does=20 > lot more. In case there is a need to have different name for these=20 > kind of SIP B2BUA entity to avoid the confusion, Let us work it out. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: Tuesday, March 15, 2011 12:14 PM > To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > middleboxes? >=20 >=20 > Hi Dan, >=20 > In my definition of an ALG packets can be sent directly to its IP=20 > address. >=20 > In my opinion, SIP B2BUA only focuses on SIP, while an ALG also=20 > focuses on other things, like media. A SIP ALG contains a SIP B2BUA. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Dan Wing > Sent: 15. maaliskuuta 2011 4:39 > To: 'Flemming Andreasen'; 'mmusic' > Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > middleboxes ? >=20 > The draft uses the term "SIP ALG", which at least does not fit my=20 > definition of an ALG. An ALG doesn't have packets sent directly to=20 > its IP address; it does its job stealthily without awareness of one=20 > (or > both) of the sessoin endpoints. In contrast, the function described=20 > in draft-ietf-mmusic-media-path-middleboxes > is different -- packets are always sent to the IP address of the SIP=20 > "ALG", and packets are sent from the IP address of the SIP "ALG". =20 > This functionality is most often called a "server" > or a "proxy" -- not an ALG. >=20 > This distinction is important because this draft is closely related to > functions common in NATs, which _do_ sometimes have SIP ALGs=20 > implemented in them. >=20 > So ... can we change "SIP ALG" to something like "SIP proxy" > or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a > B2BUA, at least as best I understand the definition of a B2BUA, so=20 > B2BUA seems best. >=20 > d >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > Behalf Of Flemming Andreasen > > Sent: Thursday, March 10, 2011 6:15 PM > > To: mmusic > > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > > middleboxes ? > > > > We currently have a MMUSIC milestone for "considerations for using=20 > > SDP >=20 > > offer/answer with middleboxes". The latest draft for this WG item is > > > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > > > which expired in January 2011. There hasn't been much discussion on=20 > > this topic for a while, and the current draft authors are not=20 > > planning >=20 > > continued work on the draft, so we need new authors if we are to=20 > > continue with this WG item. Please let us know if > > 1) You are still interested in this deliverable > > 2) You are willing to actively contribute to and/or author this=20 > > document. > > > > Thanks > > > > Flemming & Miguel [MMUSIC chairs] > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > 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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.belling@nsn.com Wed Mar 16 05:48:06 2011 Return-Path: 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 9A43A3A68AD for ; Wed, 16 Mar 2011 05:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 EsyRRos4zyA6 for ; Wed, 16 Mar 2011 05:48:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 632A93A6977 for ; Wed, 16 Mar 2011 05:48:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2GCnRhF010538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2011 13:49:27 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2GCnRTI028486; Wed, 16 Mar 2011 13:49:27 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 13:49:27 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 13:49:25 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72203959A04@DEMUEXC014.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948D7E05E@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? Thread-Index: AcvgC3tA2JY9oJBwQlysmtNs3HEU6gAfUzvcANOxvFA= References: <4D798594.4000406@cisco.com>, <4D7A51F3.8010503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851948D7E05E@ESESSCMS0356.eemea.ericsson.se> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Christer Holmberg" , "Flemming Andreasen" , "Elwell, John" X-OriginalArrivalTime: 16 Mar 2011 12:49:27.0529 (UTC) FILETIME=[95C41D90:01CBE3D8] Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? 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: , X-List-Received-Date: Wed, 16 Mar 2011 12:48:06 -0000 Hi Christer, I can also help with a review. After a quick check, it appears that references to IETF drafts need to be updated. 3GPP has standardised protocols for the Ix and Iq reference points in the mean time, and references to the related stage 2 and stage 3 specs should also be added (Ix: TS 29.162, TS 29.238; Iq: TS 23.334, TS 29.234) Thomas -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Christer Holmberg Sent: Saturday, March 12, 2011 8:41 AM To: Flemming Andreasen; Elwell, John Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? Hi, I am willing to review. Regards, Christer ________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen [fandreas@cisco.com] Sent: Friday, March 11, 2011 6:46 PM To: Elwell, John Cc: mmusic Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ? Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line. Thanks -- Flemming On 3/11/11 5:18 AM, Elwell, John wrote: Flemming, According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious. John > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 11 March 2011 02:15 > To: mmusic > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with=20 > middleboxes ? > > We currently have a MMUSIC milestone for "considerations for using SDP > offer/answer with middleboxes". The latest draft for this WG item is > > draft-ietf-mmusic-media-path-middleboxes-03.txt > > which expired in January 2011. There hasn't been much discussion on=20 > this topic for a while, and the current draft authors are not planning > continued work on the draft, so we need new authors if we are to=20 > continue with this WG item. Please let us know if > 1) You are still interested in this deliverable > 2) You are willing to actively contribute to and/or author this=20 > document. > > Thanks > > Flemming & Miguel [MMUSIC chairs] > > > _______________________________________________ > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Wed Mar 16 15:12:36 2011 Return-Path: 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 90E213A6A75 for ; Wed, 16 Mar 2011 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 R45gT7zXXMcF for ; Wed, 16 Mar 2011 15:12:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B72E53A6A37 for ; Wed, 16 Mar 2011 15:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=20664; q=dns/txt; s=iport; t=1300313637; x=1301523237; h=message-id:date:from:mime-version:to:subject; bh=rIen6Cb3FOySURQEDpOxRDjGzBhUbB3pUDjYoRe5vDI=; b=aQoZh/yAeGVXJYe3klVuwD0ac3zgWKBG0G/GIjAxLTBFW7epPCv7Duls mig3UYrnUZvvt0O7tNxUKShjejWf04HgMz0lwxO8LcAuGT0WzGPocydGQ 5v1J/XjZRGj9qwTg+dqSMZMYPgQ87iQRm71n9bCMkg+v0TpohIoHMQjDp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANjSgE2tJV2a/2dsb2JhbACCW6MPd6YJnFKFYwSMXg X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208,217";a="347942797" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2011 22:13:52 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2GMDqwc025689 for ; Wed, 16 Mar 2011 22:13:52 GMT Message-ID: <4D8136E7.3060508@cisco.com> Date: Wed, 16 Mar 2011 18:17:11 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------050607030002030901020101" Subject: [MMUSIC] MMUSIC Draft Agenda for Prague (IETF-80) 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: , X-List-Received-Date: Wed, 16 Mar 2011 22:12:36 -0000 This is a multi-part message in MIME format. --------------050607030002030901020101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings We have just uploaded the *draft* MMUSIC agenda for IETF-80 in Prague, which you can see at http://www.ietf.org/proceedings/80/agenda/mmusic.htm as well as below. Please take a look and let us know if you have any questions or comments. Thanks Flemming & Miguel IETF-80, Prague Multiparty Multimedia Session Control (MMUSIC) WG ================================================== *** DRAFT AGENDA *** Chairs: Miguel Garcia (miguel.a.garcia@ericsson.com ) Flemming Andreasen (fandreas@cisco.com ) FRIDAY, April 1, 2011, 9:00--11:30 (Barcelona/Berlin) ----------------------------------------------------- 9:00--9:15 Introduction and Status Update (Chairs, 15) 9:15--9:20 Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) (Veikkolainen, 5) draft-ietf-mmusic-sdp-cs-06 9:20--9:30 Title and Bandwidth Capabilities Negotiation in the Session Description (Veikkolainen, 10) draft-mmusic-sdp-icap-bcap-01 9:30--9:45 TCP Candidates with Interactive Connectivity Establishment (ICE) (Keranen, 15) draft-ietf-mmusic-ice-tcp-12 9:45--10:00 ICE Updated Offer Problematic (Elwell, 15) draft-elwell-mmusic-ice-updated-offer-00 10:00-10:10 Media level ice-options SDP attribute (Petit-Huguenin, 10) draft-petithuguenin-mmusic-ice-attributes-level-00 10:10-10:25 Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) (Fairhurst, 15) draft-ietf-dccp-udpencap-07 10:25-10:35 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) (Loreto, 10) draft-loreto-mmusic-sctp-sdp-07 10:35-10:45 Grouping of Adjacent Media in the Session Description Protocol (Begen, 10) draft-jennings-mmusic-adjacent-grouping-03 10:45-10:55 The Session Description Protocol (SDP) 'trafficclass' Attribute (Polk, 10) draft-polk-mmusic-traffic-class-for-sdp-01 10:55-11:10 SDP attribute to signal parallax (Greevenbosch, 15) Signal 3D format (Greevenbosh) draft-greevenbosch-mmusic-parallax-attribute-00 draft-greevenbosch-mmusic-signal-3d-format-00 11:10-11:25 Temporal Interleaving Attribute in the Session Description Protocol (Begen, 15) Redundancy Grouping Semantics in the Session Description Protocol (Begen) draft-begen-mmusic-temporal-interleaving-01 draft-begen-mmusic-redundancy-grouping-00 --------------050607030002030901020101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

We have just uploaded the *draft* MMUSIC agenda for IETF-80 in Prague, which you can see at

    http://www.ietf.org/proceedings/80/agenda/mmusic.htm

as well as below. Please take a look and let us know if you have any questions or comments.

Thanks

        Flemming & Miguel   




IETF-80, Prague

 

Multiparty Multimedia Session Control (MMUSIC) WG

==================================================

** DRAFT AGENDA **

 

Chairs: Miguel Garcia (miguel.a.garcia@ericsson.com)

        Flemming Andreasen (fandreas@cisco.com)      

 

 

FRIDAY, April 1, 2011, 9:00–11:30 (Barcelona/Berlin)

-----------------------------------------------------

 

9:00–9:15   Introduction and Status Update (Chairs, 15)

 

9:15–9:20   Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) (Veikkolainen, 5)

 

            draft-ietf-mmusic-sdp-cs-06

 

9:20–9:30   Title and Bandwidth Capabilities Negotiation in the Session Description (Veikkolainen, 10)

 

            draft-mmusic-sdp-icap-bcap-01

 

9:30–9:45   TCP Candidates with Interactive Connectivity Establishment (ICE) (Keranen, 15)

 

            draft-ietf-mmusic-ice-tcp-12

 

9:45–10:00  ICE Updated Offer Problematic (Elwell, 15)

 

draft-elwell-mmusic-ice-updated-offer-00

 

10:00-10:10 Media level ice-options SDP attribute (Petit-Huguenin, 10)

 

draft-petithuguenin-mmusic-ice-attributes-level-00

 

10:10-10:25 Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) (Fairhurst, 15)

 

draft-ietf-dccp-udpencap-07

 

10:25-10:35 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) (Loreto, 10)

 

            draft-loreto-mmusic-sctp-sdp-07

 

10:35-10:45 Grouping of Adjacent Media in the Session Description Protocol (Begen, 10)

 

draft-jennings-mmusic-adjacent-grouping-03

 

10:45-10:55 The Session Description Protocol (SDP) 'trafficclass' Attribute (Polk, 10)

 

            draft-polk-mmusic-traffic-class-for-sdp-01

 

10:55-11:10 SDP attribute to signal parallax (Greevenbosch, 15)

            Signal 3D format  (Greevenbosh)

           

            draft-greevenbosch-mmusic-parallax-attribute-00

            draft-greevenbosch-mmusic-signal-3d-format-00

 

11:10-11:25 Temporal Interleaving Attribute in the Session Description Protocol (Begen, 15)

            Redundancy Grouping Semantics in the Session Description Protocol (Begen)

 

            draft-begen-mmusic-temporal-interleaving-01

            draft-begen-mmusic-redundancy-grouping-00






--------------050607030002030901020101-- From john.elwell@siemens-enterprise.com Thu Mar 17 06:28:34 2011 Return-Path: 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 7ABC43A67FA for ; Thu, 17 Mar 2011 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VeJ9s4gdAzRQ for ; Thu, 17 Mar 2011 06:28:33 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E68A63A695F for ; Thu, 17 Mar 2011 06:28:32 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3787286 for mmusic@ietf.org; Thu, 17 Mar 2011 14:29:59 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6BFD123F028E for ; Thu, 17 Mar 2011 14:29:56 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 17 Mar 2011 14:29:56 +0100 From: "Elwell, John" To: mmusic Date: Thu, 17 Mar 2011 14:29:55 +0100 Thread-Topic: Draft-elwell-ice-updated-offer Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AB3PW6kA= Message-ID: References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com> <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com> <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> Keywords: ICE,IPv6,MMUSIC Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Thu, 17 Mar 2011 13:28:34 -0000 It seems the esteemed chairs have awarded me some time in Prague to discuss= this - if we are going to have a meaningful discussion there, let's get th= e discussion going on the list first. So far I heard only from Christer. John > -----Original Message----- > From: Elwell, John=20 > Sent: 07 February 2011 15:02 > To: mmusic > Subject: Draft-elwell-ice-updated-offer (was RE: [MMUSIC] Yet=20 > another alternative to ICE) >=20 > In response to Gonzalo's request for a better understanding =20 > of the issues that keep ICE from being widely deployed, I=20 > have submitted a new I-D on problems arising from the updated=20 > SDP offer that ICE requires under some circumstances: > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updated-offer/ >=20 > Comments welcome. >=20 > John >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org=20 > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > Sent: 04 December 2010 20:33 > > To: Flemming Andreasen > > Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20 > > draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic > > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20 > > draft-ietf-mmusic-media-loopback-14 review and comments) > >=20 > > Hi, > >=20 > > >> - NAT Traversal and usage of ICE > > >> > > >> [Authors] As Hadriel mentioned, if you have ICE you=20 > don't need the > > >> loopback primer. As he also clarified, the loopback situation is > > >> different from standard calls because the mirror will=20 > never send a > > >> packet until it receives something from the source. This=20 > > is certainly > > >> possible for a regular call and calls may fail for that=20 > reason, but > > >> the loopback draft is dead without a solution for this problem. > > >> Remember that the primary use case for this draft is=20 > > service providers > > >> wanting to test to subscriber devices that are almost=20 > always behind > > >> NATs. The proposed solution meets the requirements for=20 > the dominant > > >> use case and while standard solutions are certainly usable=20 > > when they > > >> are available, the unfortunate reality is that most of=20 > them are not > > >> implemented. We can add clarification text that if available ICE > > >> should be used instead of the loopback primer method. > > >> > > > Thanks. The draft will also need to clearly explain how=20 > the loopback > > > primer would work, and in particular what the underlying=20 > > assumptions are > > > (e.g. latching) as well as when it will not work (e.g. when=20 > > both source > > > and mirror are behind a NAT, when you have overlapping=20 > > IP-addresses and > > > ports, etc). In short, the limitations of this approach=20 > > must be clearly > > > documented. > > >=20 > > > I will also check with our AD as to whether there are any=20 > additional > > > concerns with specifying such a solution when we already=20 > > have ICE as the > > > Standard. > >=20 > > as you all know, there have been a number of proposals to=20 > standardize > > simpler-than-ICE NAT traversal solutions that would only work=20 > > in certain > > scenarios or circumstances. There have been a lot of=20 > > discussions around > > them. A couple of IETFs ago there was even a bar BOF where=20 > > people tried > > to understand the issues that kept folks from deploying ICE in some > > scenarios. I know there have been off-list follow ups on those > > discussions but no draft have been submitted yet, AFAIK. > >=20 > > So, we need to frame this discussion taking into account the=20 > > big picture > > of NAT traversal and ICE. In this case, we need to understand=20 > > the issues > > that keep ICE from being widely deployed and, if needed, specify a > > general solution to address those issues. Coming up with several > > different NAT traversal mechanisms that only work in specific=20 > > conditions > > does not seem like the best outcome we can wish for. > >=20 > > I encourage people who are working on those ICE-related issues to > > participate in this discussion because this is an important area. > >=20 > > Thanks, > >=20 > > Gonzalo > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > = From peter.musgrave@magorcorp.com Thu Mar 17 06:59:39 2011 Return-Path: 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 02D7E3A699D for ; Thu, 17 Mar 2011 06:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 2DFtjZzf4oWv for ; Thu, 17 Mar 2011 06:59:37 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9E0B43A68AD for ; Thu, 17 Mar 2011 06:59:37 -0700 (PDT) Received: by gyf3 with SMTP id 3so1334371gyf.31 for ; Thu, 17 Mar 2011 07:01:05 -0700 (PDT) Received: by 10.90.37.38 with SMTP id k38mr1465199agk.59.1300370465114; Thu, 17 Mar 2011 07:01:05 -0700 (PDT) Received: from [192.168.1.119] (cpe-173-170-70-85.tampabay.res.rr.com [173.170.70.85]) by mx.google.com with ESMTPS id 37sm2682684anr.4.2011.03.17.07.01.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 07:01:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Thu, 17 Mar 2011 10:01:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com> <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com> <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1082) Cc: mmusic Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Thu, 17 Mar 2011 13:59:39 -0000 Hi John,=20 Is the real issue that any updated offer is bad for faxes? I wonder if = the scope needs to be extended to include: - reINVITE at the end of a SDPcap neg. offer/answer (although IIRC the = spec says the reINVITE is a SHOULD) - what I term a "defensive" reINVITE (e.g. UA offers a long list of = CODECs and after seeing the answer sends a new offer with only one CODEC = so that it does not need to support on the fly CODEC changes) Of the two remedies you propose, I favour the delay the fax updated = offer - but I agree it is not fool-proof.=20 Cheers,=20 Peter Musgrave On 2011-03-17, at 9:29 AM, Elwell, John wrote: > It seems the esteemed chairs have awarded me some time in Prague to = discuss this - if we are going to have a meaningful discussion there, = let's get the discussion going on the list first. So far I heard only = from Christer. >=20 > John >=20 >> -----Original Message----- >> From: Elwell, John=20 >> Sent: 07 February 2011 15:02 >> To: mmusic >> Subject: Draft-elwell-ice-updated-offer (was RE: [MMUSIC] Yet=20 >> another alternative to ICE) >>=20 >> In response to Gonzalo's request for a better understanding =20 >> of the issues that keep ICE from being widely deployed, I=20 >> have submitted a new I-D on problems arising from the updated=20 >> SDP offer that ICE requires under some circumstances: >> = https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updated-offer/ >>=20 >> Comments welcome. >>=20 >> John >>=20 >>=20 >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org=20 >>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>> Sent: 04 December 2010 20:33 >>> To: Flemming Andreasen >>> Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20 >>> draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic >>> Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20 >>> draft-ietf-mmusic-media-loopback-14 review and comments) >>>=20 >>> Hi, >>>=20 >>>>> - NAT Traversal and usage of ICE >>>>>=20 >>>>> [Authors] As Hadriel mentioned, if you have ICE you=20 >> don't need the >>>>> loopback primer. As he also clarified, the loopback situation is >>>>> different from standard calls because the mirror will=20 >> never send a >>>>> packet until it receives something from the source. This=20 >>> is certainly >>>>> possible for a regular call and calls may fail for that=20 >> reason, but >>>>> the loopback draft is dead without a solution for this problem. >>>>> Remember that the primary use case for this draft is=20 >>> service providers >>>>> wanting to test to subscriber devices that are almost=20 >> always behind >>>>> NATs. The proposed solution meets the requirements for=20 >> the dominant >>>>> use case and while standard solutions are certainly usable=20 >>> when they >>>>> are available, the unfortunate reality is that most of=20 >> them are not >>>>> implemented. We can add clarification text that if available ICE >>>>> should be used instead of the loopback primer method. >>>>>=20 >>>> Thanks. The draft will also need to clearly explain how=20 >> the loopback >>>> primer would work, and in particular what the underlying=20 >>> assumptions are >>>> (e.g. latching) as well as when it will not work (e.g. when=20 >>> both source >>>> and mirror are behind a NAT, when you have overlapping=20 >>> IP-addresses and >>>> ports, etc). In short, the limitations of this approach=20 >>> must be clearly >>>> documented. >>>>=20 >>>> I will also check with our AD as to whether there are any=20 >> additional >>>> concerns with specifying such a solution when we already=20 >>> have ICE as the >>>> Standard. >>>=20 >>> as you all know, there have been a number of proposals to=20 >> standardize >>> simpler-than-ICE NAT traversal solutions that would only work=20 >>> in certain >>> scenarios or circumstances. There have been a lot of=20 >>> discussions around >>> them. A couple of IETFs ago there was even a bar BOF where=20 >>> people tried >>> to understand the issues that kept folks from deploying ICE in some >>> scenarios. I know there have been off-list follow ups on those >>> discussions but no draft have been submitted yet, AFAIK. >>>=20 >>> So, we need to frame this discussion taking into account the=20 >>> big picture >>> of NAT traversal and ICE. In this case, we need to understand=20 >>> the issues >>> that keep ICE from being widely deployed and, if needed, specify a >>> general solution to address those issues. Coming up with several >>> different NAT traversal mechanisms that only work in specific=20 >>> conditions >>> does not seem like the best outcome we can wish for. >>>=20 >>> I encourage people who are working on those ICE-related issues to >>> participate in this discussion because this is an important area. >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From john.elwell@siemens-enterprise.com Thu Mar 17 07:48:04 2011 Return-Path: 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 BB9B93A694E for ; Thu, 17 Mar 2011 07:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Vx7A6EaaoHCC for ; Thu, 17 Mar 2011 07:48:03 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3B9AC3A693F for ; Thu, 17 Mar 2011 07:48:02 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3783716; Thu, 17 Mar 2011 15:49:25 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 90A8A1EB82AB; Thu, 17 Mar 2011 15:49:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Mar 2011 15:49:25 +0100 From: "Elwell, John" To: Peter Musgrave Date: Thu, 17 Mar 2011 15:49:24 +0100 Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer Thread-Index: Acvkq8LYJiD0ONywTEmAGKUQpZOOHQABD4GQ Message-ID: References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com> <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com> <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Thu, 17 Mar 2011 14:48:04 -0000 Peter, Yes, since the draft was written it was brought to my attention that SDP ca= p-neg has a similar unfortunate interaction with fax (although it is only a= SHOULD - ICE is a MUST), and I guess also your "defensive" re-INVITE. And = likewise these can interact with 3PCC. Delaying the fax updated offer might address ICE, but would be somewhat mor= e difficult with the SDP cap-neg and "defensive" cases because you don't kn= ow for sure an updated offer will arrive. It would require some practical m= easurements with different delay values to see how effective it would be. Rather than keep adding to the cases where an updated offer needs to be sen= t (we originally had fax and "defensive", now we have added ICE and cap-neg= ) it would be better if we could avoid the need. It seems the need arises o= nly from certain classes of SIP/SDP-aware middleboxes, and I wonder in how = many circumstances the updated offer will make the difference between the s= ession not working and working. It strikes me that endpoints implementing t= hese new capabilities are required to do too much to get through SIP-aware = middleboxes that should be transparent but are not. John > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 > Sent: 17 March 2011 14:01 > To: Elwell, John > Cc: mmusic > Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer >=20 > Hi John,=20 >=20 > Is the real issue that any updated offer is bad for faxes? I=20 > wonder if the scope needs to be extended to include: > - reINVITE at the end of a SDPcap neg. offer/answer (although=20 > IIRC the spec says the reINVITE is a SHOULD) > - what I term a "defensive" reINVITE (e.g. UA offers a long=20 > list of CODECs and after seeing the answer sends a new offer=20 > with only one CODEC so that it does not need to support on=20 > the fly CODEC changes) >=20 > Of the two remedies you propose, I favour the delay the fax=20 > updated offer - but I agree it is not fool-proof.=20 >=20 > Cheers,=20 >=20 > Peter Musgrave >=20 >=20 > On 2011-03-17, at 9:29 AM, Elwell, John wrote: >=20 > > It seems the esteemed chairs have awarded me some time in=20 > Prague to discuss this - if we are going to have a meaningful=20 > discussion there, let's get the discussion going on the list=20 > first. So far I heard only from Christer. > >=20 > > John > >=20 > >> -----Original Message----- > >> From: Elwell, John=20 > >> Sent: 07 February 2011 15:02 > >> To: mmusic > >> Subject: Draft-elwell-ice-updated-offer (was RE: [MMUSIC] Yet=20 > >> another alternative to ICE) > >>=20 > >> In response to Gonzalo's request for a better understanding =20 > >> of the issues that keep ICE from being widely deployed, I=20 > >> have submitted a new I-D on problems arising from the updated=20 > >> SDP offer that ICE requires under some circumstances: > >>=20 > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat > ed-offer/ > >>=20 > >> Comments welcome. > >>=20 > >> John > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: mmusic-bounces@ietf.org=20 > >>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >>> Sent: 04 December 2010 20:33 > >>> To: Flemming Andreasen > >>> Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20 > >>> draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic > >>> Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20 > >>> draft-ietf-mmusic-media-loopback-14 review and comments) > >>>=20 > >>> Hi, > >>>=20 > >>>>> - NAT Traversal and usage of ICE > >>>>>=20 > >>>>> [Authors] As Hadriel mentioned, if you have ICE you=20 > >> don't need the > >>>>> loopback primer. As he also clarified, the loopback situation is > >>>>> different from standard calls because the mirror will=20 > >> never send a > >>>>> packet until it receives something from the source. This=20 > >>> is certainly > >>>>> possible for a regular call and calls may fail for that=20 > >> reason, but > >>>>> the loopback draft is dead without a solution for this problem. > >>>>> Remember that the primary use case for this draft is=20 > >>> service providers > >>>>> wanting to test to subscriber devices that are almost=20 > >> always behind > >>>>> NATs. The proposed solution meets the requirements for=20 > >> the dominant > >>>>> use case and while standard solutions are certainly usable=20 > >>> when they > >>>>> are available, the unfortunate reality is that most of=20 > >> them are not > >>>>> implemented. We can add clarification text that if available ICE > >>>>> should be used instead of the loopback primer method. > >>>>>=20 > >>>> Thanks. The draft will also need to clearly explain how=20 > >> the loopback > >>>> primer would work, and in particular what the underlying=20 > >>> assumptions are > >>>> (e.g. latching) as well as when it will not work (e.g. when=20 > >>> both source > >>>> and mirror are behind a NAT, when you have overlapping=20 > >>> IP-addresses and > >>>> ports, etc). In short, the limitations of this approach=20 > >>> must be clearly > >>>> documented. > >>>>=20 > >>>> I will also check with our AD as to whether there are any=20 > >> additional > >>>> concerns with specifying such a solution when we already=20 > >>> have ICE as the > >>>> Standard. > >>>=20 > >>> as you all know, there have been a number of proposals to=20 > >> standardize > >>> simpler-than-ICE NAT traversal solutions that would only work=20 > >>> in certain > >>> scenarios or circumstances. There have been a lot of=20 > >>> discussions around > >>> them. A couple of IETFs ago there was even a bar BOF where=20 > >>> people tried > >>> to understand the issues that kept folks from deploying=20 > ICE in some > >>> scenarios. I know there have been off-list follow ups on those > >>> discussions but no draft have been submitted yet, AFAIK. > >>>=20 > >>> So, we need to frame this discussion taking into account the=20 > >>> big picture > >>> of NAT traversal and ICE. In this case, we need to understand=20 > >>> the issues > >>> that keep ICE from being widely deployed and, if needed, specify a > >>> general solution to address those issues. Coming up with several > >>> different NAT traversal mechanisms that only work in specific=20 > >>> conditions > >>> does not seem like the best outcome we can wish for. > >>>=20 > >>> I encourage people who are working on those ICE-related issues to > >>> participate in this discussion because this is an important area. > >>>=20 > >>> Thanks, > >>>=20 > >>> Gonzalo > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>>=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > = From bgreeven@huawei.com Thu Mar 17 19:36:52 2011 Return-Path: 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 18A3A3A6A05 for ; Thu, 17 Mar 2011 19:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 Jq2qmGMvyEif for ; Thu, 17 Mar 2011 19:36:51 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C77353A696C for ; Thu, 17 Mar 2011 19:36:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI8000WBFB6AY@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 18 Mar 2011 10:37:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI8007P7FB6FQ@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 18 Mar 2011 10:37:54 +0800 (CST) Received: from z00127286a ([10.70.109.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI800JFVFB3ZU@szxml06-in.huawei.com> for mmusic@ietf.org; Fri, 18 Mar 2011 10:37:53 +0800 (CST) Date: Fri, 18 Mar 2011 10:37:51 +0800 From: Bert Greevenbosch To: mmusic@ietf.org Message-id: <000d01cbe515$79e64880$6db2d980$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_j9U2AzUYrf6BS2nqggoJtg)" Content-language: en-gb Thread-index: AcvlFXnX/Spr2uUEQICIo7PtEVKSAQ== Cc: ietf_as@huawei.com Subject: [MMUSIC] Stereoscopic 3D format negotiation 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: , X-List-Received-Date: Fri, 18 Mar 2011 02:36:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_j9U2AzUYrf6BS2nqggoJtg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, As announced earlier, I have uploaded a draft that extends SDP for streaming stereoscopic 3D video (hereafter shortly referred to as "3D video"). For 3D video, two views need to be submitted, which are projected to the left and right eyes respectively. The L- and R-views can be transmitted separately or synthesised from a 2D view and auxiliary data. Also, they can be frame packed in a single video stream, where each video frame contains an arrangement of the left and right views. For these different transmission technologies, signalling is needed. This is what my draft proposes. It is available under the following link: https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ Also, there might be clients that support only some of the 3D formats. Then I think it might make sense to negotiate the format between the server and the client. I think this can be done using the SDP offer/answer model, as that allows the client to pick from several attributes. This I didn't write down in the draft yet; I wanted like to ask for opinions on it first. What do the SDP offer/answer experts think of this? Any other comments and proposals for improvement of the draft are welcome too! Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bgreeven@huawei.com telephone: +86-755-28978088 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian Longgang Shenzhen 518129 P.R. China **************************************************************************** *** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ** --Boundary_(ID_j9U2AzUYrf6BS2nqggoJtg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

As announced earlier, I have uploaded a draft that extends SDP for streaming stereoscopic 3D video (hereafter shortly referred to as "3D video").

 

For 3D video, two views need to be submitted, which are projected to the left and right eyes respectively. The L- and R-views can be transmitted separately or synthesised from a 2D view and auxiliary data. Also, they can be frame packed in a single video stream, where each video frame contains an arrangement of the left and right views.

 

For these different transmission technologies, signalling is needed. This is what my draft proposes. It is available under the following link:

https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/

 

Also, there might be clients that support only some of the 3D formats. Then I think it might make sense to negotiate the format between the server and the client. I think this can be done using the SDP offer/answer model, as that allows the client to pick from several attributes.

 

This I didn't write down in the draft yet; I wanted like to ask for opinions on it first. What do the SDP offer/answer experts think of this?

 

Any other comments and proposals for improvement of the draft are welcome too!

 

Best regards,

Bert

 

---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bgreeven@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian Longgang

Shenzhen  518129

P.R. China

 

*******************************************************************************

This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!

******************************************************************************

 

--Boundary_(ID_j9U2AzUYrf6BS2nqggoJtg)-- From christer.holmberg@ericsson.com Fri Mar 18 05:44:49 2011 Return-Path: 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 DE3603A68F2 for ; Fri, 18 Mar 2011 05:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, 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 4ZW1jlaBTe5F for ; Fri, 18 Mar 2011 05:44:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A9AB53A68D3 for ; Fri, 18 Mar 2011 05:44:48 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-14-4d835418b32d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 20.2D.09202.814538D4; Fri, 18 Mar 2011 13:46:17 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 18 Mar 2011 13:46:16 +0100 From: Christer Holmberg To: mmusic Date: Fri, 18 Mar 2011 13:46:15 +0100 Thread-Topic: Comment on draft-jennings-mmusic-adjacent-grouping-03 Thread-Index: Acvlangn5Qkpf9TQRJGv64ydqgt7ag== Message-ID: <224F5CB1ECAB2C45BC64065AFD0339650406B5FD57@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings Subject: [MMUSIC] Comment on draft-jennings-mmusic-adjacent-grouping-03 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: , X-List-Received-Date: Fri, 18 Mar 2011 12:44:50 -0000 Hi Cullen/Ali, There were some comments given on this draft in Beijing, but I am not sure = they have been addressed in the new version. Q1: Declaration vs negotiation ------------------------------ In Beijing it was commented that the usage is not for negotation, but rathe= r for *declaration*. Based on the minutes from Beijing, the authors verifie= d that the intended usage if for declaration. "Cullen Jennings replied that there are people w= ho need this capability. The big difference from telepresence=20 would be its declarative nature, in contrast to the negotiation cap= ability intended for telepresence." So, IF this is about declaration, I think that should be clear in the draft= , and everything about telepresence, SDP offer/answer etc should be removed= . Q2: SDP offer/answer ---------------------- (Assuming this is intended to be used also for negotiation) When used with SDP offer/answer, when an entity sends an SDP offer, it indi= cates what it is willing to *receive*. So, if I use this mechanism, I would= *not* say "please show media received on this stream on your left display"= , but "please SEND media for MY left display on this stream*. The declarati= ve nature makes it difficult to understand what the intended usage (if any)= with SDP offer/answer is. Q3: Audio/video association ----------------------------- The draft does not provide a mechanism to e.g. associate audio and video st= reams. I GUESS that could be done by using the same mid value for two strea= ms (e.g. an audio and a video stream). IF that's the case, I think it needs= to be described. Q4: Telepresence ------------------ (Assuming this is intended to be used also for negotiation) The draft also talks about telepresence, where I agree this kind of feature= very likely will be needed. But, my suggestion would be for CLUE to agree = on requirements before taking on this draft, to make sure that it can be us= ed to meet those requirements. This was also mentioned in Beijing. "Magnus Westerlund would like to s= ee where the telepresence work goes, but was concerned that we not have two solutions to the same problem. Peter Musgrave supported him,..." "Mary Barnes asked if anyone else supp= orted the work. Why not wait for telepresence?" So, again, it needs to be clarified what the scope of the propsed mechanism= is. Q5: Editorial ------------- The SDP example shows audio streams (m=3Daudio), but I assume it's meant to= be video (m=3Dvideo)? If these issues have been discussed and solved on the list between Beijing = and new, I appologize for having missed it. Regards, Christer= From pkyzivat@cisco.com Wed Mar 23 19:59:38 2011 Return-Path: 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 8F8B33A67DF for ; Wed, 23 Mar 2011 19:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 qIpz-aPcMwrB for ; Wed, 23 Mar 2011 19:59:37 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 315EB3A67DB for ; Wed, 23 Mar 2011 19:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=832; q=dns/txt; s=iport; t=1300935671; x=1302145271; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=qsHgs5/fIBGwtn7a69zxRU3ZzmqPZKgAUigP6pNtG3E=; b=GpZG2fdMHjFGRSnLaAb99ENkUtKVyhzLKGrGl7I+80M9jxxJrpFtaKwJ 5m3LSNTMdsN/v88DLz5tzjgetdhDV5eTT8bbxyaz+c2CsIuNBbrc05yiz MbI3ers6OqHmpNFpFOVNPVfCAGIiSuvWS7Lkqrr/F0wkeLeVgkbzbnvAO 4=; X-IronPort-AV: E=Sophos;i="4.63,235,1299456000"; d="scan'208";a="22944946" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 24 Mar 2011 03:01:10 +0000 Received: from [10.86.248.14] (bxb-vpn3-14.cisco.com [10.86.248.14]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2O31AhZ027390; Thu, 24 Mar 2011 03:01:10 GMT Message-ID: <4D8AB3F5.7090902@cisco.com> Date: Wed, 23 Mar 2011 23:01:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Cullen Jennings , "Ali C. Begen" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping 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: , X-List-Received-Date: Thu, 24 Mar 2011 02:59:39 -0000 (Just catching up on my reading...) One observation about this draft: The grouping framework permits multiple groups to be formed with the same semantics. (E.g. you could define two audio/video groups, each to be lip synchronized.) Analogously, one could presumably use the ADJ grouping semantic to form two independent groups of video streams. OTOH, you might want to form two different groupings of m-lines that both map onto the same grid of devices. (For instance, a grouping of video m-lines and a corresponding grouping of audio m-lines.) But the a=media-grid-dims attribute doesn't provide any way to identify which group it applies to if there is more than one. At the very least, the issue of what to do when there are multiple adjacency groupings ought to be discussed. Thanks, Paul From abegen@cisco.com Thu Mar 24 04:16:27 2011 Return-Path: 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 EA2773A680C for ; Thu, 24 Mar 2011 04:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BeZLWQvb67fF for ; Thu, 24 Mar 2011 04:16:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1B25C3A67FA for ; Thu, 24 Mar 2011 04:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3899; q=dns/txt; s=iport; t=1300965479; x=1302175079; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1XTk6NkMDacGzGRvPFJCpW+artMHsGzkta2rGnNhaKA=; b=VC90kboUwVPZl9+5RE4f4Jhx6QfxFVQC9649OGYDsBBxPin50Icw1quI GSTRdaqOU5Se3oVcCIDVAuGINttRrh8kXcOVf6dS4wfnzkZyVcjlC4jMw 53zR3E0vkImlbg1Fu7BVnEofJVZITniZ/lGN8JOmEDU7GcMBwELkVYWxx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAANnEik2rRDoG/2dsb2JhbACYCo05d4hNnRycQ4VpBIU3ixCDIw X-IronPort-AV: E=Sophos;i="4.63,236,1299456000"; d="scan'208";a="281960715" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2011 11:17:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2OBHxxv000339; Thu, 24 Mar 2011 11:17:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Mar 2011 04:17:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Mar 2011 04:17:04 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EA02ED3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <224F5CB1ECAB2C45BC64065AFD0339650406B5FD57@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on draft-jennings-mmusic-adjacent-grouping-03 Thread-Index: Acvlangn5Qkpf9TQRJGv64ydqgt7agEqZm8w References: <224F5CB1ECAB2C45BC64065AFD0339650406B5FD57@ESESSCMS0356.eemea.ericsson.se> From: "Ali C. Begen (abegen)" To: "Christer Holmberg" , "mmusic" X-OriginalArrivalTime: 24 Mar 2011 11:17:59.0596 (UTC) FILETIME=[2201FEC0:01CBEA15] Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [MMUSIC] Comment on draft-jennings-mmusic-adjacent-grouping-03 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: , X-List-Received-Date: Thu, 24 Mar 2011 11:16:28 -0000 Hi Christer, Thanks for your review. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, March 18, 2011 1:46 PM > To: mmusic > Cc: Cullen Jennings (fluffy); Ali C. Begen (abegen) > Subject: Comment on draft-jennings-mmusic-adjacent-grouping-03 >=20 >=20 > Hi Cullen/Ali, >=20 > There were some comments given on this draft in Beijing, but I am not = sure they have been addressed in the new version. >=20 > Q1: Declaration vs negotiation > ------------------------------ >=20 > In Beijing it was commented that the usage is not for negotation, but = rather for *declaration*. Based on the minutes from > Beijing, the authors verified that the intended usage if for = declaration. >=20 > "Cullen Jennings replied that there are = people who need this capability. The big difference from > telepresence > would be its declarative nature, in contrast to the = negotiation capability intended for telepresence." >=20 > So, IF this is about declaration, I think that should be clear in the = draft, and everything about telepresence, SDP offer/answer > etc should be removed. We can reduce the draft to declaration only, however, the 5888 already = provides o/a model support. Is that a concern? =20 > Q2: SDP offer/answer > ---------------------- >=20 > (Assuming this is intended to be used also for negotiation) >=20 > When used with SDP offer/answer, when an entity sends an SDP offer, it = indicates what it is willing to *receive*. So, if I use > this mechanism, I would *not* say "please show media received on this = stream on your left display", but "please SEND media > for MY left display on this stream*. The declarative nature makes it = difficult to understand what the intended usage (if any) > with SDP offer/answer is. You are right. Depending on how we move on the first issue, this should = be either removed or fixed. =20 > Q3: Audio/video association > ----------------------------- >=20 > The draft does not provide a mechanism to e.g. associate audio and = video streams. I GUESS that could be done by using the > same mid value for two streams (e.g. an audio and a video stream). IF = that's the case, I think it needs to be described. (Yes, this is an open issue that we realized after the revision). Is that a legal use of mid values? It probably needs more thought on = this, but I suspect this method won't cover all the scenarios that this = draft could be used for. =20 > Q4: Telepresence > ------------------ >=20 > (Assuming this is intended to be used also for negotiation) >=20 > The draft also talks about telepresence, where I agree this kind of = feature very likely will be needed. But, my suggestion > would be for CLUE to agree on requirements before taking on this = draft, to make sure that it can be used to meet those > requirements. >=20 >=20 > This was also mentioned in Beijing. >=20 > "Magnus Westerlund would like = to see where the telepresence work goes, but was > concerned that > we not have two solutions to the same problem. Peter Musgrave = supported him,..." >=20 > "Mary Barnes asked if anyone else = supported the work. Why not wait for telepresence?" >=20 > So, again, it needs to be clarified what the scope of the propsed = mechanism is. Agreed. =20 >=20 > Q5: Editorial > ------------- >=20 > The SDP example shows audio streams (m=3Daudio), but I assume it's = meant to be video (m=3Dvideo)? >=20 >=20 > If these issues have been discussed and solved on the list between = Beijing and new, I appologize for having missed it. :) yeah sorry about that. Cheers, -acbegen =20 >=20 > Regards, >=20 > Christer From abegen@cisco.com Thu Mar 24 04:22:21 2011 Return-Path: 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 36CAE3A6806 for ; Thu, 24 Mar 2011 04:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bsV0hA9cxTRQ for ; Thu, 24 Mar 2011 04:22:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1EA743A67FA for ; Thu, 24 Mar 2011 04:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1550; q=dns/txt; s=iport; t=1300965834; x=1302175434; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Gbp7uvd9TryC8K5FqxOBbn7jo1PLSnxb6He0eY2nARA=; b=jiy5nPOtcg19eOMgUB58hNF3ucZc1FswmbBDrIz2sCPU3yu2O6x3Pa2f LzxZk7FmFvN68b/H9RGePPZjZUeqlYwuHRf9ndieDXVYikz2GUE59n0LG jRjzS1DlYnOLRhIeg+St7pk6TeJpnTcSySBHYuqZ1PI50imFfZ7GQm99D w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAK/Gik2rRDoJ/2dsb2JhbACYCo05d4hNnSmcQ4J8gm0EhTeLEA X-IronPort-AV: E=Sophos;i="4.63,236,1299456000"; d="scan'208";a="351666978" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2011 11:23:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2OBNrjH030884 for ; Thu, 24 Mar 2011 11:23:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Mar 2011 04:23:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Mar 2011 04:22:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EA02ED4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D8AB3F5.7090902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-jennings-mmusic-adjacent-grouping Thread-Index: Acvpz72lUL7ryId0QD++ffxk36rVcAARUr5A References: <4D8AB3F5.7090902@cisco.com> From: "Ali C. Begen (abegen)" To: "Paul Kyzivat (pkyzivat)" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 24 Mar 2011 11:23:53.0513 (UTC) FILETIME=[F4F57190:01CBEA15] Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping 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: , X-List-Received-Date: Thu, 24 Mar 2011 11:22:21 -0000 > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Thursday, March 24, 2011 4:01 AM > To: Cullen Jennings (fluffy); Ali C. Begen (abegen) > Cc: IETF MMUSIC WG > Subject: Re: draft-jennings-mmusic-adjacent-grouping >=20 > (Just catching up on my reading...) >=20 > One observation about this draft: >=20 > The grouping framework permits multiple groups to be formed with the > same semantics. (E.g. you could define two audio/video groups, each to > be lip synchronized.) >=20 > Analogously, one could presumably use the ADJ grouping semantic to = form > two independent groups of video streams. >=20 > OTOH, you might want to form two different groupings of m-lines that > both map onto the same grid of devices. (For instance, a grouping of > video m-lines and a corresponding grouping of audio m-lines.) Yes. I just replied to Christer's email, he brought up the same thing. = We realized this open issue after the revision. =20 > But the a=3Dmedia-grid-dims attribute doesn't provide any way to = identify > which group it applies to if there is more than one. So it is a session-level attribute but this still does not solve the = audio-video overlay problem (suppose I have 3x2 screens - 6 video = streams and 6x2 audio (stereo) streams). If such an overlay is a desired feature, a general solution needs to be = identified. =20 > At the very least, the issue of what to do when there are multiple > adjacency groupings ought to be discussed. -acbegen =20 > Thanks, > Paul From petithug@acm.org Thu Mar 24 07:09:35 2011 Return-Path: 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 406F028C102 for ; Thu, 24 Mar 2011 07:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] 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 sOyyr3iD+vAt for ; Thu, 24 Mar 2011 07:09:34 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 748EE3A68C4 for ; Thu, 24 Mar 2011 07:09:34 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 36EC2DBCC046; Thu, 24 Mar 2011 14:11:08 +0000 (UTC) Received: from [192.168.2.225] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 7DB6DDBCC044 for ; Thu, 24 Mar 2011 14:11:07 +0000 (UTC) Message-ID: <4D8B50FB.4030500@acm.org> Date: Thu, 24 Mar 2011 07:11:07 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Media level ice-options attribute 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: , X-List-Received-Date: Thu, 24 Mar 2011 14:09:35 -0000 At the suggestions of the chairs, I'll explain here the problem that I will be presenting in Prague, so we can discuss it beforehand and make the best of the 10 minutes allocated to the presentation. This problem was discovered when implementing an endpoint supporting disaggregated media. draft-loreto-dispatch-disaggregated-media gives a good presentation of what disaggregated media is, but to simplify it is when the SIP stack is physically separated from the RTP stack, or stacks in this case, each with its own ICE implementation. In my case I had audio on one device, with my own ICE/RTP stack, and video on a separate device with a proprietary stack. I wanted to add ECN support in my RTP stack but I could not signal it in the SDP resulting of the merge of the SDP coming from the two RTP stacks because the ice-options attribute is supposed to carry this piece of information in a session-level only attribute, where in my case only one media was supporting ECN. If I added an ice-options at the media level it will be ignored by the stack on the other side, if I added it at the session level the other side will think that both medias supports ECN. So this proposal is to change the level from session-only to session *and* media. But doing only this creates problems when a stack implementing this proposal is used with a legacy stack on the other side. This is why the proposal also mandates to define how different ice-options at the media level are combined into the session level ice-options. For rtp+ecn, the rules would be that the session level attribute is set only if all the medias use the rtp+ecn option. A similar problem exist for the ice-lite option, which is also defined only at the session level, when different implementations want to use different values. Here my proposal is to not change anything, mostly because I do not see how media level values can be combined to a media level value that makes sense. On the other hand I do not care much about ICE-lite, so there is probably perhaps something that I missed. The slides for the presentation are available here: http://www.ietf.org/proceedings/80/slides/mmusic-1.pdf The I-D is available here: https://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level/ -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From pkyzivat@cisco.com Thu Mar 24 08:11:36 2011 Return-Path: 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 2271828C120 for ; Thu, 24 Mar 2011 08:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 A0h71fbn6g0N for ; Thu, 24 Mar 2011 08:11:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3DB0328C11E for ; Thu, 24 Mar 2011 08:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=774; q=dns/txt; s=iport; t=1300979585; x=1302189185; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=RprfVNMLfn6MPsYjCl2tfxSNIOt6pJk+6RLPNl1cNIU=; b=Sw0JTMa/B9bBeFR/tEjZe30PvBdYHJ02bsp0Q7d/4RI3ERFhnSND3gZf hqimERWQxXS+8SU2PJPe8Is89EEAFlkI9wtbXai0jDOVHy1XJ4RAk+FxJ LAf2oucw+UJYU+OJwTl/SdNmdKaaw1znsoEJp+adBS98CO+vsOHF61GSb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGb8ik2tJXHB/2dsb2JhbAClSXemD5xRhWkEjG+DUg X-IronPort-AV: E=Sophos;i="4.63,237,1299456000"; d="scan'208";a="417824554" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2011 15:13:03 +0000 Received: from [10.86.248.14] (bxb-vpn3-14.cisco.com [10.86.248.14]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2OFD2Hw019289; Thu, 24 Mar 2011 15:13:03 GMT Message-ID: <4D8B5F7E.5070204@cisco.com> Date: Thu, 24 Mar 2011 11:13:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Miguel A. Garcia" , "Simo.Veikkolainen@nokia.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 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: , X-List-Received-Date: Thu, 24 Mar 2011 15:11:36 -0000 I have a couple of comments on this draft: There is still work to do to extend the o/a rules to handle '-' as a media format. Specifically, if the offer contains '-', what may the answer contain? And if the offer does not contain '-', may the answer? When using uuie correlation, the uuie-value is defined as 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a discriminator byte that can be any one of 256 values. The draft doesn't mention if the uuie-value contains the discriminator byte, or if that byte is assumed to have some well known value. If it is to include the discriminator byte, then some important discriminator byte values are neither alpha nor digit. IMO the draft at least needs to explain what is intended. Thanks, Paul From Bert.Greevenbosch@huawei.com Thu Mar 24 17:22:08 2011 Return-Path: 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 997F028C134 for ; Thu, 24 Mar 2011 17:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 aFheR5a7DA7E for ; Thu, 24 Mar 2011 17:22:07 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4474228C11A for ; Thu, 24 Mar 2011 17:22:07 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIL00A8K7R7JL@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 25 Mar 2011 08:23:31 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIL00C4P7R73I@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 25 Mar 2011 08:23:31 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 25 Mar 2011 08:21:59 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.3]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 25 Mar 2011 08:23:28 +0800 Date: Fri, 25 Mar 2011 00:23:27 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.54] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012ACA56@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nw+0z1fi9WMPGj++JPlT7A)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: 3D drafts presentation for Prague Thread-index: AcvqgtxIshLQ8r/sSo6tZtN+K204yQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailman-Approved-At: Thu, 24 Mar 2011 18:53:16 -0700 Subject: [MMUSIC] 3D drafts presentation for Prague 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: , X-List-Received-Date: Fri, 25 Mar 2011 00:38:23 -0000 --Boundary_(ID_nw+0z1fi9WMPGj++JPlT7A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I have created a presentation that introduces the two 3D drafts. The presentation is scheduled to be shown in Prague. The presentation is available on the meeting materials website under the following link: http://www.ietf.org/proceedings/80/slides/mmusic-0.ppt I look forward to meet you all in Prague! Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bert.greevenbosch@huawei.com telephone: +86-755-28978088 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China ******************************************************************************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ****************************************************************************** --Boundary_(ID_nw+0z1fi9WMPGj++JPlT7A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

I have created a presentation that introduces the two 3D drafts. The presentation is scheduled to be shown in Prague.

 

The presentation is available on the meeting materials website under the following link:

http://www.ietf.org/proceedings/80/slides/mmusic-0.ppt

 

I look forward to meet you all in Prague!

 

Best regards,

Bert

 

---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bert.greevenbosch@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian, Longgang District

Shenzhen  518129

P.R. China

 

*******************************************************************************

This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!

******************************************************************************

 

--Boundary_(ID_nw+0z1fi9WMPGj++JPlT7A)-- From miguel.a.garcia@ericsson.com Fri Mar 25 04:26:52 2011 Return-Path: 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 5D65B3A6875 for ; Fri, 25 Mar 2011 04:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wIrfGI2EEv9d for ; Fri, 25 Mar 2011 04:26:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 37A453A682A for ; Fri, 25 Mar 2011 04:26:51 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-6f-4d8c7c5907c3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.97.09202.95C7C8D4; Fri, 25 Mar 2011 12:28:25 +0100 (CET) Received: from [159.107.43.228] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 25 Mar 2011 12:28:25 +0100 Message-ID: <4D8C7C58.4090306@ericsson.com> Date: Fri, 25 Mar 2011 12:28:24 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Kyzivat References: <4D8B5F7E.5070204@cisco.com> In-Reply-To: <4D8B5F7E.5070204@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 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: , X-List-Received-Date: Fri, 25 Mar 2011 11:26:52 -0000 Hi Paul, Thanks for your comments. See inline answers. On 24/03/2011 16:13, Paul Kyzivat wrote: > I have a couple of comments on this draft: > > There is still work to do to extend the o/a rules to handle '-' as a > media format. Specifically, if the offer contains '-', what may the > answer contain? And if the offer does not contain '-', may the answer? For sure, I agree. I think the information must be hidden or implicitly described, but this should be explicitly specified. At the moment the draft has O/A procedures for negotiating the correlation mechanism (Section 5.3). I think we should just have a more generic O/A procedures that discuss the whole draft, not only the correlation mechanism. > > When using uuie correlation, the uuie-value is defined as > 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a discriminator > byte that can be any one of 256 values. The draft doesn't mention if the > uuie-value contains the discriminator byte, or if that byte is assumed > to have some well known value. If it is to include the discriminator > byte, then some important discriminator byte values are neither alpha > nor digit. IMO the draft at least needs to explain what is intended. Problem acknowledged. We need to take a look at it and provide a solution. BR, Miguel > > Thanks, > Paul -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ari.keranen@nomadiclab.com Fri Mar 25 04:59:56 2011 Return-Path: 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 5EF0D3A69A9 for ; Fri, 25 Mar 2011 04:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 SlFeaHEl3uyj for ; Fri, 25 Mar 2011 04:59:55 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 7B3323A685D for ; Fri, 25 Mar 2011 04:59:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 96C474E6D8 for ; Fri, 25 Mar 2011 14:01:26 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUsgPaS3INXs for ; Fri, 25 Mar 2011 14:01:26 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 147CC4E6D3 for ; Fri, 25 Mar 2011 14:01:26 +0200 (EET) Message-ID: <4D8C8419.7050800@nomadiclab.com> Date: Fri, 25 Mar 2011 14:01:29 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE TCP open issues (if any) 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: , X-List-Received-Date: Fri, 25 Mar 2011 11:59:56 -0000 Hi all, I asked for a slot at the WG meeting to discuss open issues on the ICE TCP draft, but (luckily) there aren't any left and no new ones have showed up so far. I know some of you are still reviewing the document, so it would be great to know before Monday if you have found any issues worth discussing. If there aren't any, we can probably skip the presentation slot and start a WGLC soon. If there are issues, we can use the slot for those and get this draft finally done. Cheers, Ari From thomas.stach@siemens-enterprise.com Fri Mar 25 06:11:32 2011 Return-Path: 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 6064B3A69AD for ; Fri, 25 Mar 2011 06:11:32 -0700 (PDT) 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 70FUlnCz3zOn for ; Fri, 25 Mar 2011 06:11:25 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AAD3E3A69B2 for ; Fri, 25 Mar 2011 06:11:23 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3893488 for mmusic@ietf.org; Fri, 25 Mar 2011 14:12:54 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id DDC1823F0298 for ; Fri, 25 Mar 2011 14:12:54 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 25 Mar 2011 14:12:54 +0100 From: "Stach, Thomas" To: "mmusic@ietf.org" Date: Fri, 25 Mar 2011 14:12:53 +0100 Thread-Topic: Presentation of Draft-elwell-ice-updated-offer Thread-Index: Acvq7lk3jWwobQfsSh2hqd4nXeSTZg== Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Fri, 25 Mar 2011 13:11:32 -0000 Hi all, please find the slides we want to present at the MMUSIC session at http://www.ietf.org/proceedings/80/slides/mmusic-2.ppt The draft mentions two cases of bad interactions caused by the ICE updated = offer http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-00 We want to get input on the following topics: Any other suggestions in addition to the already proposed work-arounds? Do we really need the ICE updated offer - How many middleboxes work well with the updated offer but would not work = without it? - Or putting it another way, how many middleboxes would still fail with the= updated offer (e.g., rejecting it)? - updated offer is only SHOULD for cap-neg, so why MUST for ICE? Christer Holmberg and Peter Musgrave have already shared some thoughts. Are there further opinions in the group? Thanks and Kind Regards Thomas From dwing@cisco.com Fri Mar 25 11:01:29 2011 Return-Path: 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 751293A6814 for ; Fri, 25 Mar 2011 11:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 aTkFGZzVIYu3 for ; Fri, 25 Mar 2011 11:01:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0A9223A6813 for ; Fri, 25 Mar 2011 11:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1725; q=dns/txt; s=iport; t=1301076183; x=1302285783; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=8deQy2eBQuKs2gx+xvzDCREehKAEvk79kuOm3xOae/o=; b=muEsZL7CskdT8Covo+3jV0dqvUuyzK8TEcWPADsyL0cBJompS+R6xzRx PU499BlRhvuhqHAtHT6afwwQ6WDx0eJq1Im6DL+AbwD0qkcAfoCCEiQoN f5YD+cIrqlOFuTAh2DjHElrtvDHANIcitza3d9qPG9G73vXOaVnL/i1bk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAMnXjE2rRDoG/2dsb2JhbACYIIFki1t3iE2fDpxWhWkEhTo X-IronPort-AV: E=Sophos;i="4.63,244,1299456000"; d="scan'208";a="324638491" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2011 18:03:03 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2PI335h029963; Fri, 25 Mar 2011 18:03:03 GMT From: "Dan Wing" To: "'Stach, Thomas'" , References: In-Reply-To: Date: Fri, 25 Mar 2011 11:03:02 -0700 Message-ID: <23b101cbeb16$e271d570$a7558050$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvq7lk3jWwobQfsSh2hqd4nXeSTZgAKFmmQ Content-language: en-us Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Fri, 25 Mar 2011 18:01:29 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Stach, Thomas > Sent: Friday, March 25, 2011 6:13 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer > > Hi all, > > please find the slides we want to present at the MMUSIC session at > http://www.ietf.org/proceedings/80/slides/mmusic-2.ppt > > The draft mentions two cases of bad interactions caused by the ICE > updated offer > http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-00 > > We want to get input on the following topics: > Any other suggestions in addition to the already proposed work-arounds? > Do we really need the ICE updated offer > - How many middleboxes work well with the updated offer but would not > work without it? > - Or putting it another way, how many middleboxes would still fail with > the updated offer (e.g., rejecting it)? > - updated offer is only SHOULD for cap-neg, so why MUST for ICE? > > Christer Holmberg and Peter Musgrave have already shared some thoughts. > Are there further opinions in the group? Sorry if this idea has been discussed already, but ... ... Could we ask the middlebox to add a "Please-send-updated-offer:" header to the SIP message, if it wants to see an updated offer?? That means it doesn't need to understand ICE, but rather just needs to add that header. It's still "a change to the middlebox", true, but it's a really minor change compared to understanding ICE. -d > Thanks and Kind Regards > Thomas > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From jmpolk@cisco.com Sun Mar 27 04:52:17 2011 Return-Path: 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 E3B0C3A67EE for ; Sun, 27 Mar 2011 04:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 lSQf+X3OQ3GA for ; Sun, 27 Mar 2011 04:52:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BFB603A67E4 for ; Sun, 27 Mar 2011 04:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1792; q=dns/txt; s=iport; t=1301226833; x=1302436433; h=message-id:date:to:from:subject:mime-version; bh=PKUzGND2r2T+cr0aarY41so/ZRqJvxMEYdXwRjZZwLI=; b=eUjqrHMkISZ3EKzNQDMDVtF+Zt9h9DqIWKqFPpD9wCefrWcS+GPoSsCa qY67R4DFfpU2/XkoJPhtY8uroS9woBFxHwn5Un17Rkgm+FmDfBPTALahm bZszVTcT1BXg+5AbTAdaSDAEd2uED1sW04QHYCE9BTox5VQyTh4SHM8uP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkHAJMkj02rRDoH/2dsb2JhbACYYYx+d6VBmn2CfIJtBIU6 X-IronPort-AV: E=Sophos;i="4.63,250,1299456000"; d="scan'208";a="418962467" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 27 Mar 2011 11:53:53 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-vpn-client-10-89-7-9.cisco.com [10.89.7.9]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RBrq7X011056 for ; Sun, 27 Mar 2011 11:53:52 GMT Message-Id: <201103271153.p2RBrq7X011056@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Mar 2011 06:53:47 -0500 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] New rev of SDP Traffic Classes ID 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: , X-List-Received-Date: Sun, 27 Mar 2011 11:52:18 -0000 MMUSIC This note is to let everyone know that we have updated the traffic classes ID http://www.ietf.org/internet-drafts/draft-polk-mmusic-traffic-class-for-sdp-01.txt This draft's main purpose is to identify the type of traffic is in a session. In other words, more granular than 'video' or 'audio', but give meaningful application identification. The intent is to aid in the assignment of which DSCP a session (or flow) is to be assigned without binding the network to a fixed value. In the case of video traffic, some believe that they want to handle or treat telepresence handled or treated differently than desktop video or mobile/handheld video or webex session within certain environments. Video is the emphasis to this effort, but audio can be equally identified. What's changed in this version is that instead of relying on RFC 4594's (table 3) as the assignment template for labels, we're exploring a multilayered approach (that's in this version of the doc), including the ability to indicate proprietary strings and whether or not Call Admission Control is being or has been applied to a traffic type session or flow. What we lack in this version is a clear set of definitions for each application label and sub-application label - i.e., being able to clearly identify a traffic type fits into a single traffic class (therefore app label and/or sub-app label). If this approach is acceptable by the WG, we're going to actively reach out for input between now and Quebec City so that the next version will some or a lot of agreement within this WG (we hope). We know this isn't an easy topic (when do I ever choose an easy topic, right ;-) This is what I will focus on during my presentation time on Friday. James From thomas.stach@siemens-enterprise.com Sun Mar 27 06:09:16 2011 Return-Path: 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 DC8263A6845 for ; Sun, 27 Mar 2011 06:09:16 -0700 (PDT) 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 mk-kZV+wp3Sx for ; Sun, 27 Mar 2011 06:09:16 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AD18F3A67EE for ; Sun, 27 Mar 2011 06:09:15 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3899095; Sun, 27 Mar 2011 15:10:49 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C146E23F028E; Sun, 27 Mar 2011 15:10:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Sun, 27 Mar 2011 15:10:49 +0200 From: "Stach, Thomas" To: Dan Wing , "mmusic@ietf.org" Date: Sun, 27 Mar 2011 15:10:48 +0200 Thread-Topic: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer Thread-Index: Acvq7lk3jWwobQfsSh2hqd4nXeSTZgAKFmmQAFbrmtA= Message-ID: References: <23b101cbeb16$e271d570$a7558050$@com> In-Reply-To: <23b101cbeb16$e271d570$a7558050$@com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Sun, 27 Mar 2011 13:09:17 -0000 See inline > -----Urspr=FCngliche Nachricht----- > Von: Dan Wing [mailto:dwing@cisco.com]=20 > Gesendet: Freitag, 25. M=E4rz 2011 19:03 > An: Stach, Thomas; mmusic@ietf.org > Betreff: RE: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Stach, Thomas > > Sent: Friday, March 25, 2011 6:13 AM > > To: mmusic@ietf.org > > Subject: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer > >=20 > > Hi all, > >=20 > > please find the slides we want to present at the MMUSIC session at > > http://www.ietf.org/proceedings/80/slides/mmusic-2.ppt > >=20 > > The draft mentions two cases of bad interactions caused by the ICE > > updated offer > > http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-00 > >=20 > > We want to get input on the following topics: > > Any other suggestions in addition to the already proposed=20 > work-arounds? > > Do we really need the ICE updated offer > > - How many middleboxes work well with the updated offer but=20 > would not > > work without it? > > - Or putting it another way, how many middleboxes would=20 > still fail with > > the updated offer (e.g., rejecting it)? > > - updated offer is only SHOULD for cap-neg, so why MUST for ICE? > >=20 > > Christer Holmberg and Peter Musgrave have already shared=20 > some thoughts. > > Are there further opinions in the group? >=20 > Sorry if this idea has been discussed already, but ... >=20 > ... Could we ask the middlebox to add a "Please-send-updated-offer:"=20 > header to the SIP message, if it wants to see an updated=20 > offer?? That means > it doesn't need to understand ICE, but rather just needs to add that > header. It's still "a change to the middlebox", true, but=20 > it's a really > minor change compared to understanding ICE. This is certainly an option if we want to do something. However, I don't think we're there yet. At this point in time, we try to focus on collecting knowledge how middlebo= xes react in real life. Do they really break without the updated offer?=20 - E.g, they should have already passed onwards STUN checks before a non-de= fault candidate could be selected. Or did somebody see a failure because of the updated offer? Any input in that directions would be very valuable in finding out if there= 's interest/need for more work. Regards Thomas >=20 > -d >=20 >=20 > > Thanks and Kind Regards > > Thomas > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > = From abegen@cisco.com Sun Mar 27 14:48:22 2011 Return-Path: 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 84BFA28C0E0 for ; Sun, 27 Mar 2011 14:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aPhf-kxO2KiA for ; Sun, 27 Mar 2011 14:48:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8DE0D3A6957 for ; Sun, 27 Mar 2011 14:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1708; q=dns/txt; s=iport; t=1301262598; x=1302472198; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=uwUujDX+7R63IrMJ07q4vXZtJ/4NolO8mOtiFC70ej0=; b=d6xT/B6FL4d+ZC13NWVWgr9y6YkvUGBv5ul/BSvXzJHBPMGSxBhgnx2f dDtKTpw4Zc8H504API4mpuf5x0PPn39Gkk6Ytrd7xddhOwLLD6xmkapoi Dnm1LOnNuFsuJLEe9zO54LBIIvoo/cJTw2r7H+nkn3Dgrz5zNrXlLYUa3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAPqvj02rRDoJ/2dsb2JhbACYEz+Mf3elJpp2hWkEhTqLFw X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="419080965" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 27 Mar 2011 21:49:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2RLnwbN008049 for ; Sun, 27 Mar 2011 21:49:58 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 14:49:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Mar 2011 14:49:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EA03744@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two new drafts on redundant media streams Thread-Index: AcvdCFV4SdefuVX9QCum97sIXr7IBAPv3C8g From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 27 Mar 2011 21:49:58.0167 (UTC) FILETIME=[EA7A0270:01CBECC8] Subject: Re: [MMUSIC] Two new drafts on redundant media streams 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: , X-List-Received-Date: Sun, 27 Mar 2011 21:48:22 -0000 Some folks noted (offline) that these (redundancy) methods already = existed in practice.=20 Well, they certainly exist and are deployed in various networks out = there. What we are addressing here is the required semantics for them. = Currently, different ad hoc methods for signaling are used in different = deployments. Our goal is to make a formal definition to be used in the = SDP. We have one open issue that we would like to get feedback on. It is = about RTCP reporting for the redundant streams. The sender could be both = interested in the individual performance of each stream as well as the = performance of the merged stream. We are considering a new type of XR = report for this but are also open to other ideas. Comments/questions would be welcome and useful before the session on = Friday. -acbegen=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Ali C. Begen (abegen) > Sent: Monday, March 07, 2011 9:45 PM > To: mmusic@ietf.org > Cc: Heidi Ou (hou); Yiqun Cai (ycai) > Subject: [MMUSIC] Two new drafts on redundant media streams >=20 > We have submitted two new drafts for describing redundant media = streams in SDP. >=20 > = https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= /=20 > = https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ = >=20 > Comments and feedback are welcome. We will request a presentation slot = for these two drafts in the upcoming meeting. >=20 > Thanks. > -acbegen > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Simo.Veikkolainen@nokia.com Mon Mar 28 02:22:55 2011 Return-Path: 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 E3F063A69A9 for ; Mon, 28 Mar 2011 02:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=-0.591, 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 JvUGJqnjMY2f for ; Mon, 28 Mar 2011 02:22:55 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id AB9493A6965 for ; Mon, 28 Mar 2011 02:22:54 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2S9ONsn020063; Mon, 28 Mar 2011 12:24:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 12:24:25 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Mar 2011 11:24:24 +0200 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 11:24:24 +0200 From: To: Thread-Topic: draft-ietf-mmusic-sdp-cs-06 Thread-Index: AQHL6jYAzdzkv+kSJEq7hvaWKJy7xJQ92lEAgAShgpA= Date: Mon, 28 Mar 2011 09:24:23 +0000 Message-ID: References: <4D8B5F7E.5070204@cisco.com> <4D8C7C58.4090306@ericsson.com> In-Reply-To: <4D8C7C58.4090306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 09:24:25.0159 (UTC) FILETIME=[EDF06D70:01CBED29] X-Nokia-AV: Clean Cc: pkyzivat@cisco.com Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 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: , X-List-Received-Date: Mon, 28 Mar 2011 09:22:56 -0000 Hello, These are pretty much the only open issues we know of for this document. If= others have any concerns, it would be great if you could post them on the = list before Friday. Thanks Simo > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 25 March, 2011 13:28 > To: Paul Kyzivat > Cc: Veikkolainen Simo (Nokia-MS/Helsinki); IETF MMUSIC WG > Subject: Re: draft-ietf-mmusic-sdp-cs-06 >=20 > Hi Paul, >=20 > Thanks for your comments. See inline answers. >=20 > On 24/03/2011 16:13, Paul Kyzivat wrote: > > I have a couple of comments on this draft: > > > > There is still work to do to extend the o/a rules to handle '-' as a > > media format. Specifically, if the offer contains '-', what may the > > answer contain? And if the offer does not contain '-', may the > answer? >=20 > For sure, I agree. I think the information must be hidden or implicitly > described, but this should be explicitly specified. At the moment the > draft has O/A procedures for negotiating the correlation mechanism > (Section 5.3). I think we should just have a more generic O/A > procedures > that discuss the whole draft, not only the correlation mechanism. >=20 >=20 > > > > When using uuie correlation, the uuie-value is defined as > > 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a > discriminator > > byte that can be any one of 256 values. The draft doesn't mention if > the > > uuie-value contains the discriminator byte, or if that byte is > assumed > > to have some well known value. If it is to include the discriminator > > byte, then some important discriminator byte values are neither alpha > > nor digit. IMO the draft at least needs to explain what is intended. >=20 > Problem acknowledged. We need to take a look at it and provide a > solution. >=20 > BR, >=20 > Miguel >=20 >=20 > > > > Thanks, > > Paul >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From dwing@cisco.com Mon Mar 28 02:32:45 2011 Return-Path: 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 422883A6A2A for ; Mon, 28 Mar 2011 02:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 z+nTphvXzwt1 for ; Mon, 28 Mar 2011 02:32:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 514733A68B0 for ; Mon, 28 Mar 2011 02:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3333; q=dns/txt; s=iport; t=1301304861; x=1302514461; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=d3li7SOl2EfA4iEIw+tcAIh4seL0or7KuwN/rNooC1s=; b=LukdcMrYn90Eh43EzlOJBXtcwSLICQrsr1g4JxH799I8+srF1Cwq6XbO vZvU/M+9EQXa3agvpSRNwa1Aik0ZdzKwdyOIIVTYMELTVta/iW1IpB4yi HRStDlMWCMmYrJY3/ZiP4T0+uX0lTP4UxjJC+TwOyh1CPaoansohCyvpJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAKhVkE2rRDoJ/2dsb2JhbACYC4Fki1p3piWbQYVpBA X-IronPort-AV: E=Sophos;i="4.63,253,1299456000"; d="scan'208";a="671614975" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 28 Mar 2011 09:34:21 +0000 Received: from dwingWS (sjc-vpn5-1185.cisco.com [10.21.92.161]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2S9YKmO011562; Mon, 28 Mar 2011 09:34:21 GMT From: "Dan Wing" To: "'Stach, Thomas'" , References: <23b101cbeb16$e271d570$a7558050$@com> In-Reply-To: Date: Mon, 28 Mar 2011 11:34:18 +0200 Message-ID: <02bb01cbed2b$50946430$f1bd2c90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvq7lk3jWwobQfsSh2hqd4nXeSTZgAKFmmQAFbrmtAAK7olYA== Content-Language: en-us Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Mon, 28 Mar 2011 09:32:45 -0000 > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@siemens-enterprise.com] > Sent: Sunday, March 27, 2011 3:11 PM > To: Dan Wing; mmusic@ietf.org > Subject: AW: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer >=20 > See inline >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Dan Wing [mailto:dwing@cisco.com] > > Gesendet: Freitag, 25. M=E4rz 2011 19:03 > > An: Stach, Thomas; mmusic@ietf.org > > Betreff: RE: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > > Behalf Of Stach, Thomas > > > Sent: Friday, March 25, 2011 6:13 AM > > > To: mmusic@ietf.org > > > Subject: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer > > > > > > Hi all, > > > > > > please find the slides we want to present at the MMUSIC session at > > > http://www.ietf.org/proceedings/80/slides/mmusic-2.ppt > > > > > > The draft mentions two cases of bad interactions caused by the ICE > > > updated offer > > > = http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-00 > > > > > > We want to get input on the following topics: > > > Any other suggestions in addition to the already proposed > > work-arounds? > > > Do we really need the ICE updated offer > > > - How many middleboxes work well with the updated offer but > > would not > > > work without it? > > > - Or putting it another way, how many middleboxes would > > still fail with > > > the updated offer (e.g., rejecting it)? > > > - updated offer is only SHOULD for cap-neg, so why MUST for ICE? > > > > > > Christer Holmberg and Peter Musgrave have already shared > > some thoughts. > > > Are there further opinions in the group? > > > > Sorry if this idea has been discussed already, but ... > > > > ... Could we ask the middlebox to add a "Please-send-updated-offer:" > > header to the SIP message, if it wants to see an updated > > offer?? That means > > it doesn't need to understand ICE, but rather just needs to add that > > header. It's still "a change to the middlebox", true, but > > it's a really > > minor change compared to understanding ICE. > This is certainly an option if we want to do something. > However, I don't think we're there yet. > At this point in time, we try to focus on collecting knowledge how > middleboxes react in real life. > Do they really break without the updated offer? The ones that are believed to break are in PacketCable. In=20 Packetcable's architecture (and deployments) additional=20 timeslots are provided to a user's cablemodem for RTP flow associated with a phone call, and those timeslots are removed at the end of the phone call. -d > - E.g, they should have already passed onwards STUN checks before a > non-default candidate could be selected. > Or did somebody see a failure because of the updated offer? >=20 > Any input in that directions would be very valuable in finding out if > there's interest/need for more work. >=20 > Regards > Thomas > > > > -d > > > > > > > Thanks and Kind Regards > > > Thomas > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > =3D From Internet-Drafts@ietf.org Mon Mar 28 09:00:03 2011 Return-Path: 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 556963A6A2F; Mon, 28 Mar 2011 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XdUNTgGz1RUx; Mon, 28 Mar 2011 09:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEA93A6A5D; Mon, 28 Mar 2011 09:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328160002.22669.43826.idtracker@localhost> Date: Mon, 28 Mar 2011 09:00:02 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-options-registry-01.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: , X-List-Received-Date: Mon, 28 Mar 2011 16:00:03 -0000 --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 : IANA Registry for Interactive Connectivity Establishment (ICE) Options Author(s) : M. Westerlund, C. Perkins Filename : draft-ietf-mmusic-ice-options-registry-01.txt Pages : 5 Date : 2011-03-28 It has been identified that Interactive Connectivity Establishment (ICE) RFC5245 is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC5245. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-01.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-ice-options-registry-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28085109.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Mon Mar 28 09:02:57 2011 Return-Path: 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 79AF63A6A2F for ; Mon, 28 Mar 2011 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 RGpWx8YQPA-g for ; Mon, 28 Mar 2011 09:02:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3B72928C0CE for ; Mon, 28 Mar 2011 09:02:56 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-67-4d90b1900ed9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 12.02.09202.091B09D4; Mon, 28 Mar 2011 18:04:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 28 Mar 2011 18:04:32 +0200 From: Christer Holmberg To: "Ali C. Begen (abegen)" , "Paul Kyzivat (pkyzivat)" , "Cullen Jennings (fluffy)" Date: Mon, 28 Mar 2011 18:04:30 +0200 Thread-Topic: draft-jennings-mmusic-adjacent-grouping Thread-Index: Acvpz72lUL7ryId0QD++ffxk36rVcAARUr5AANLipKA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519490FD403@ESESSCMS0356.eemea.ericsson.se> References: <4D8AB3F5.7090902@cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540EA02ED4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EA02ED4@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping 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: , X-List-Received-Date: Mon, 28 Mar 2011 16:02:57 -0000 Hi,=20 >>The grouping framework permits multiple groups to be formed=20 >>with the same semantics. (E.g. you could define two audio/video=20 >>groups, each to be lip synchronized.) >>=20 >>Analogously, one could presumably use the ADJ grouping semantic to=20 >>form two independent groups of video streams. >>=20 >>OTOH, you might want to form two different groupings of m-lines that=20 >>both map onto the same grid of devices. (For instance, a=20 >>grouping of video m-lines and a corresponding grouping of audio m-lines.) >=20 >Yes. I just replied to Christer's email, he brought up the=20 >same thing. We realized this open issue after the revision. >=20 >>But the a=3Dmedia-grid-dims attribute doesn't provide any way to=20 >>identify which group it applies to if there is more than one. >=20 >So it is a session-level attribute but this still does not=20 >solve the audio-video overlay problem (suppose I have 3x2=20 >screens - 6 video streams and 6x2 audio (stereo) streams). >=20 >If such an overlay is a desired feature, a general solution=20 >needs to be identified. It is also important to remember that there might not always be a 1-to-1 ma= pping between audio and video. For example, you might have 3 displays, with one video stream for each disp= lay, but only 2 microphones, with one audio stream for each microphone. Regards, Christer From magnus.westerlund@ericsson.com Mon Mar 28 09:03:36 2011 Return-Path: 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 07B4228C0D9 for ; Mon, 28 Mar 2011 09:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZIyf211HFr13 for ; Mon, 28 Mar 2011 09:03:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8A28F28C0E4 for ; Mon, 28 Mar 2011 09:03:33 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-c9-4d90b1b620d6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 42.12.09202.6B1B09D4; Mon, 28 Mar 2011 18:05:10 +0200 (CEST) Received: from [153.88.19.49] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 28 Mar 2011 18:05:09 +0200 Message-ID: <4D90B1B5.9080903@ericsson.com> Date: Mon, 28 Mar 2011 18:05:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20110328160002.22669.43826.idtracker@localhost> In-Reply-To: <20110328160002.22669.43826.idtracker@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-options-registry-01.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: , X-List-Received-Date: Mon, 28 Mar 2011 16:03:36 -0000 Hi, This is a very minor update that address a few nits that our chairs found during their write-up for the publication request. Cheers Magnus Internet-Drafts@ietf.org skrev 2011-03-28 18:00: > 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 : IANA Registry for Interactive Connectivity Establishment (ICE) Options > Author(s) : M. Westerlund, C. Perkins > Filename : draft-ietf-mmusic-ice-options-registry-01.txt > Pages : 5 > Date : 2011-03-28 > > It has been identified that Interactive Connectivity Establishment > (ICE) RFC5245 is missing a registry for ICE options. This document > defines this missing IANA registry and updates RFC5245. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-01.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. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F鋜鰃atan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Simo.Veikkolainen@nokia.com Tue Mar 29 05:03:48 2011 Return-Path: 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 C81883A67B0 for ; Tue, 29 Mar 2011 05:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, 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 6yhu6nSxlPXZ for ; Tue, 29 Mar 2011 05:03:45 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 383413A6784 for ; Tue, 29 Mar 2011 05:03:45 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2TC5GHS003643; Tue, 29 Mar 2011 15:05:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 15:04:16 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 29 Mar 2011 14:04:15 +0200 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Tue, 29 Mar 2011 14:04:14 +0200 From: To: Thread-Topic: Open issues on draft-mmusic-sdp-icap-bcap Thread-Index: AcvuCWsMXNVOUmyDSfWVX01kKFMVMg== Date: Tue, 29 Mar 2011 12:04:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.229] Content-Type: multipart/alternative; boundary="_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BB988008AM1MPN1002mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2011 12:04:16.0004 (UTC) FILETIME=[6CF0FC40:01CBEE09] X-Nokia-AV: Clean Subject: [MMUSIC] Open issues on draft-mmusic-sdp-icap-bcap 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: , X-List-Received-Date: Tue, 29 Mar 2011 12:03:48 -0000 --_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BB988008AM1MPN1002mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, In order to prepare for the MMUSIC session on WG, the chairs have asked to = send a list of open issues to list to allow discussion before the session. Regarding http://tools.ietf.org/html/draft-mmusic-sdp-icap-bcap-01 we have = one issue which might be considered "open", which is the definition of sess= ion level vs media level capabilities. The current text says that "icap" and "bcap" capability attributes are to b= e interpreted as - Media level attributes in the final SDP, if the capability attri= bute was declared on media level, and - Session level attributes in the final SDP, if the capability att= ribute was declared on session level. If anyone has another opinion, please let us know. Otherwise we hope we have covered all the comments made by Flemming in his = review (thanks Flemming) http://www.ietf.org/mail-archive/web/mmusic/curren= t/msg08501.html Regards, Simo --_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BB988008AM1MPN1002mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

In order to prepare for the MMUSIC session on WG, th= e chairs have asked to send a list of open issues to list to allow discussi= on before the session.

 

Regarding http://tools.ietf.org/html/draft-mmusic-sdp-icap-bcap-01 we have one is= sue which might be considered “open”, which is the definition o= f session level vs media level capabilities.

 

The current text says that “icap” and &#= 8220;bcap” capability attributes are to be interpreted as<= /p>

-     &= nbsp;    Media level attributes in the final SDP, if the cap= ability attribute was declared on media level, and

-     &= nbsp;    Session level attributes in the final SDP, if the c= apability attribute was declared on session level.

 

If anyone has another opinion, please let us know.

 

Otherwise we hope we have covered all the comments m= ade by Flemming in his review (thanks Flemming) http://www.ietf.org/mail-archive/web/mmusic/current/msg08501.html

 

Regards,

Simo

--_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BB988008AM1MPN1002mg_-- From mperumal@cisco.com Tue Mar 29 06:19:55 2011 Return-Path: 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 70D583A6824 for ; Tue, 29 Mar 2011 06:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 EctvrJt3Q1Rb for ; Tue, 29 Mar 2011 06:19:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 980E43A6784 for ; Tue, 29 Mar 2011 06:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=35138; q=dns/txt; s=iport; t=1301404891; x=1302614491; h=mime-version:subject:date:message-id:from:to:cc; bh=0XVKYanXmcU41CPIFmn9Ew4ojjM+WOZjp2ReISt5CxI=; b=jqxQOTnfDSncm4mK1nU1b4qWp0lkcDGFCH+4s13+PJZ/U8QynNwkx8gU x5hXPIKXugkqyst4sNTzqnFMFP7iVJiIhCJO+lCkmwkQyTSzk3jveHia+ /APUqL7g6pnUnMo7hpSHRRxTH4js+WoQhfPNi5jMRjI12ubndKQaYHIaz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsEAC/ckU2Q/khMgWdsb2JhbACCYaJsFAEBFiYlqD2ORY15hWoEhTqLIg X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208,217";a="81300473" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2011 13:21:30 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TDLRFp013378 for ; Tue, 29 Mar 2011 13:21:29 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 18:51:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEE14.3642E585" Date: Tue, 29 Mar 2011 18:51:29 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513F329@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mmusic-media-path-middleboxes-03 Thread-Index: AcvuFDaIyxWMTKvGTVq4+s6cJ5eaUw== From: "Muthu ArulMozhi Perumal (mperumal)" To: "mmusic" X-OriginalArrivalTime: 29 Mar 2011 13:21:28.0961 (UTC) FILETIME=[36661F10:01CBEE14] Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-path-middleboxes-03 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: , X-List-Received-Date: Tue, 29 Mar 2011 13:19:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEE14.3642E585 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overall this draft looks to be in a good shape.=20 =20 I've one major comment. Similar to REC #2 in section 7, it would be desirable to have a recommendation that the middlebox present on the media path allow at least a nominal amount of traffic to be exchanged between endpoints for a small duration of time (say, one RTT) after the middlebox receives a message from the MIDCOM agent that indicates the media session being terminated. This will ensure that any transit signaling packets on the media path exchanged during the session termination, like RTCP Bye packets, pass through the middle box. =20 A few minor comments: 1) Section 7 (Preliminary Recommendations) =20 "REC #3: It is recommended that failure to complete signaling on the media path not automatically cause the session establishment to fail unless explicitly specified by one or more endpoints. A fallback scenario where endpoints retry signaling on the media path is recommended. A scenario where endpoints retry signaling on the media path is recommended." =20 The use of the word 'fallback' in the above sentence looks awkward, since it doesn't refer to an to any fallback mechanism when there is a failure to complete signaling on the media path. Suggest to remove 'fallback'. =20 2) Section 6.1 (Packet Filtering) =20 Replace: "For SIP [RFC3261] the typically milestone that must be reached is offer/answer exchange [RFC3264] accompanied by an acknowledgement that the dialog has been accepted by the UAS (i.e., 200 OK to the INVITE)." With: "For SIP [RFC3261] the typical milestone that must be reached is offer/answer exchange [RFC3264] accompanied by an acknowledgement that the dialog has been accepted by the UAS (i.e., 200 OK to the INVITE)." =20 3) Section 4.1.2 (Two-Stage Commit) =20 Replace: "such as Quality of Service signaling that may require resources to reserved early on in the call establishment process" With: "such as Quality of Service signaling that may require resources to be reserved early on in the call establishment process" =20 4) Section 5 (NAT Traversal) =20 Replace: " As shown in Figure 1 the MIDCOM agent that is being co- located with" With: " As shown in Figure 1 the MIDCOM agent that is being co-located with" =20 Muthu ------_=_NextPart_001_01CBEE14.3642E585 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Overall this draft looks to be in a good shape.

 

I've = one major comment. Similar to REC #2 in section = 7, it would be desirable to have a recommendation that the middlebox present on the media path allow at least a nominal amount of traffic to = be exchanged between endpoints for a small duration of time (say, one RTT) after the middlebox receives a message from the MIDCOM agent that = indicates the media session being terminated. This will ensure that any transit signaling = packets on the media path exchanged during the session termination, like RTCP Bye packets, pass through the middle = box.

 

A few = minor comments:

1) = Section 7 (Preliminary Recommendations)

 

"REC #3: It is recommended that failure to complete signaling on the media path not automatically cause the session = establishment to fail unless explicitly specified by one or more endpoints.  A fallback scenario where = endpoints retry signaling on the media path is recommended. A scenario where = endpoints retry signaling on the media path is = recommended."

 

The = use of the word 'fallback' in the above sentence looks awkward, since it doesn't = refer to an to any fallback mechanism when there is a failure to complete = signaling on the media path. Suggest to remove 'fallback'.

 

2) = Section 6.1 (Packet Filtering)

 

Replace:

"For SIP [RFC3261] the typically milestone that must = be reached is offer/answer exchange [RFC3264] accompanied by an acknowledgement that the dialog has been accepted by = the UAS (i.e., 200 OK to the = INVITE)."

With:

"For SIP [RFC3261] the typical milestone that must be = reached is offer/answer exchange [RFC3264] = accompanied by an acknowledgement that the dialog has been accepted by the UAS (i.e., 200 OK to the INVITE)."

 

3) = Section 4.1.2 (Two-Stage Commit)

 

Replace:

"such as Quality of Service signaling that may require resources to reserved = early on in the call establishment process"

With:

"such as Quality of Service signaling that may require resources to be reserved = early on in the call establishment process"

 

4) = Section 5  (NAT = Traversal)

 

Replace:

" As shown in Figure 1 the MIDCOM agent that is being co- located = with"

With:

" As shown in Figure 1 the MIDCOM agent that is being co-located = with"

 

Muthu

------_=_NextPart_001_01CBEE14.3642E585-- From mperumal@cisco.com Tue Mar 29 06:56:24 2011 Return-Path: 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 C44893A6A2D for ; Tue, 29 Mar 2011 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RcOnKzKRvYP0 for ; Tue, 29 Mar 2011 06:56:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 80A7A3A68FC for ; Tue, 29 Mar 2011 06:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=8467; q=dns/txt; s=iport; t=1301407081; x=1302616681; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6XrR2iWjGxwbpvi4mHxOV5T/LxmDwi+kJTU00EuhCL4=; b=GcYZ8cQKn8bp4QNEg5rjvonUK1ukZ5Z9uFc4C35RC95zfIEwEq+3qitz 77xuexn38XAyksN60PZ75rj+SJ2uZ0U3EMo10Th2kvdfNR/clxGe8lcuB ozdWMk/W+zpg0Dsace+lawNNSYsf7WhQtcgontYGEShExrbeEinbEwC3a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAFjkkU2Q/khNgWdsb2JhbACYEI09FAEBFiYlqHCcQoVqBIU6iyI X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="81306957" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2011 13:58:00 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TDvuEZ005627; Tue, 29 Mar 2011 13:57:59 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 19:27:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 19:27:38 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8gAAFBYCACkKF/oA== References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Parthasarathi R (partr)" , "DRAGE, Keith (Keith)" , "Christer Holmberg" , "Dan Wing (dwing)" , "Flemming Andreasen (fandreas)" , "mmusic" X-OriginalArrivalTime: 29 Mar 2011 13:57:39.0231 (UTC) FILETIME=[43FB0AF0:01CBEE19] Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Tue, 29 Mar 2011 13:56:24 -0000 It looks to me that draft-ietf-mmusic-media-path-middleboxes is just an extension of RFC 3303 -- while the later describes the middlebox communication architecture and framework, the former describes some of the desirable behaviors of these middleboxes and protocols that operate on the media path unspecified in the later. RFC 3303 defines what an ALG is and it doesn't forbid packets being addressed to the ALG at the IP layer. 2.6. ALG Application Level Gateways (ALGs) are entities that possess the application specific intelligence and knowledge of an associated middlebox function. An ALG examines application traffic in transit and assists the middlebox in carrying out its function. ALGs are different from proxies. ALGs are not visible to end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts. ALGs do not terminate sessions with either end-host. Instead, ALGs examine, and optionally modify, application payload content to facilitate the flow of application traffic through a middlebox. 2.8. MIDCOM Agents MIDCOM agents are entities performing ALG functions, logically external to a middlebox. The packets may be addressed to the agent node at the IP layer. Alternatively they may not be addressed to the agent node, but may be constrained by other factors to flow through it. So, I don't see anything wrong in the use of ALG in draft-ietf-mmusic-media-path-middleboxes, unless we plan to make changes to how RFC 3303 describes it. Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) |Sent: Wednesday, March 16, 2011 6:15 PM |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic |Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? | |Keith, | |Sorry in case "media" word in my mail mislead you. Dan explains in |another mail thread |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) why |SIP ALG is not appropriate and B2BUA is more appropriate for this draft. | | |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly fits |your definition of B2BUA as it involves only SIP & SDP and media is |defined as middlebox. | |I have mentioned as kind of B2BUA because the draft concentrates on |callflow where one side of B2BUA acts as UAC and other side always acts |as UAS. IMO, the draft currently does not address B2BUA 3PCC callflows |specific issues. In the current scope of draft is continued for the |draft, the new definition may be required or draft text has to clarify |the scope. | |Thanks |Partha | |-----Original Message----- |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] |Sent: Wednesday, March 16, 2011 5:33 PM |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); |Flemming Andreasen (fandreas); mmusic |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer |withmiddleboxes? | |The only definition of B2BUA that I know of comes in RFC 3261 (sort of) |where the scope is limited to SIP. So a UA acts in one or more |directions as a SIP UA. Whatever else it does is outside the definition. |That I believe matches with what Christer is saying. | |If you want something that defines what it does with media, then you |need something that defines that, but using the term B2BUA to do that is |probably not the best choice. | |Regards | |Keith | |> -----Original Message----- |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> Behalf Of Parthasarathi R (partr) |> Sent: 15 March 2011 09:54 |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen |> (fandreas); mmusic |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with |> middleboxes? |> |> Christer, |> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle |> signaling only and it is upto the implementation to decide. Also, this | |> draft does not have restriction that SIP B2BUA and media server has to | |> be co-exist in the same device. The draft talks about the scenario |> wherein SIP B2BUA communicates with media server using Megaco (H.248). |> |> As I mentioned in other mail thread, ALG does not look appropriate and | |> the draft is talking only about the specific type of B2BUA. In real |> deployment, Few vendors named these sort of B2BUA as "Session Border |> Controller or SBC" as well. SBC may not accepted in IETF as SBC does |> lot more. In case there is a need to have different name for these |> kind of SIP B2BUA entity to avoid the confusion, Let us work it out. |> |> Thanks |> Partha |> |> -----Original Message----- |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> Behalf Of Christer Holmberg |> Sent: Tuesday, March 15, 2011 12:14 PM |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with |> middleboxes? |> |> |> Hi Dan, |> |> In my definition of an ALG packets can be sent directly to its IP |> address. |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also |> focuses on other things, like media. A SIP ALG contains a SIP B2BUA. |> |> Regards, |> |> Christer |> |> -----Original Message----- |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> Behalf Of Dan Wing |> Sent: 15. maaliskuuta 2011 4:39 |> To: 'Flemming Andreasen'; 'mmusic' |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with |> middleboxes ? |> |> The draft uses the term "SIP ALG", which at least does not fit my |> definition of an ALG. An ALG doesn't have packets sent directly to |> its IP address; it does its job stealthily without awareness of one |> (or |> both) of the sessoin endpoints. In contrast, the function described |> in draft-ietf-mmusic-media-path-middleboxes |> is different -- packets are always sent to the IP address of the SIP |> "ALG", and packets are sent from the IP address of the SIP "ALG". |> This functionality is most often called a "server" |> or a "proxy" -- not an ALG. |> |> This distinction is important because this draft is closely related to | |> functions common in NATs, which _do_ sometimes have SIP ALGs |> implemented in them. |> |> So ... can we change "SIP ALG" to something like "SIP proxy" |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is a | |> B2BUA, at least as best I understand the definition of a B2BUA, so |> B2BUA seems best. |> |> d |> |> |> > -----Original Message----- |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> > Behalf Of Flemming Andreasen |> > Sent: Thursday, March 10, 2011 6:15 PM |> > To: mmusic |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with |> > middleboxes ? |> > |> > We currently have a MMUSIC milestone for "considerations for using |> > SDP |> |> > offer/answer with middleboxes". The latest draft for this WG item is |> > |> > draft-ietf-mmusic-media-path-middleboxes-03.txt |> > |> > which expired in January 2011. There hasn't been much discussion on |> > this topic for a while, and the current draft authors are not |> > planning |> |> > continued work on the draft, so we need new authors if we are to |> > continue with this WG item. Please let us know if |> > 1) You are still interested in this deliverable |> > 2) You are willing to actively contribute to and/or author this |> > document. |> > |> > Thanks |> > |> > Flemming & Miguel [MMUSIC chairs] |> > |> > |> > _______________________________________________ |> > 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 |> _______________________________________________ |> 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 |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From Bert.Greevenbosch@huawei.com Tue Mar 29 07:16:58 2011 Return-Path: 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 4162828C0D0 for ; Tue, 29 Mar 2011 07:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 QhZHkkJ1YAoo for ; Tue, 29 Mar 2011 07:16:57 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C5D7D3A6A36 for ; Tue, 29 Mar 2011 07:16:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT00JD8P2KKL@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 29 Mar 2011 22:18:20 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT00DXJP2KTY@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 29 Mar 2011 22:18:20 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 29 Mar 2011 22:18:17 +0800 Received: from SZXEML501-MBX.china.huawei.com ([169.254.5.242]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 29 Mar 2011 22:18:20 +0800 Date: Tue, 29 Mar 2011 14:18:19 +0000 From: Bert Greevenbosch In-reply-to: <46A1DF3F04371240B504290A071B4DB6012ACA56@SZXEML501-MBS.china.huawei.com> X-Originating-IP: [172.24.2.40] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012B0D1E@szxeml501-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bYHWrBp+dcmpPJOXhOnOyg)" Content-language: en-GB Accept-Language: en-GB, zh-CN, en-US Thread-topic: 3D drafts presentation for Prague Thread-index: AcvqgtxIshLQ8r/sSo6tZtN+K204yQDmScki X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012ACA56@SZXEML501-MBS.china.huawei.com> Subject: [MMUSIC] 3D drafts presentation for Prague 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: , X-List-Received-Date: Tue, 29 Mar 2011 14:16:58 -0000 --Boundary_(ID_bYHWrBp+dcmpPJOXhOnOyg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, I have created a presentation that introduces the two 3D drafts. The presentation is scheduled to be shown in Prague. The presentation is available on the meeting materials website under the following link: http://www.ietf.org/proceedings/80/slides/mmusic-0.ppt I look forward to discuss this on Friday! Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bert.greevenbosch@huawei.com telephone: +86-755-28978088 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China ******************************************************************************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ****************************************************************************** --Boundary_(ID_bYHWrBp+dcmpPJOXhOnOyg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,

 

I have created a presentation that introduces the two 3D drafts. The presentation is scheduled to be shown in Prague.

 

The presentation is available on the meeting materials website under the following link:

http://www.ietf.org/proceedings/80/slides/mmusic-0.ppt

 

I look forward to discuss this on Friday!

 

Best regards,

Bert

 

---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bert.greevenbosch@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian, Longgang District

Shenzhen  518129

P.R. China

 

*******************************************************************************

This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!

******************************************************************************

 

--Boundary_(ID_bYHWrBp+dcmpPJOXhOnOyg)-- From fandreas@cisco.com Tue Mar 29 14:57:50 2011 Return-Path: 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 C4E7628C0CF for ; Tue, 29 Mar 2011 14:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 3MKRMt9m4WRO for ; Tue, 29 Mar 2011 14:57:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 00D633A6ACB for ; Tue, 29 Mar 2011 14:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=12065; q=dns/txt; s=iport; t=1301435966; x=1302645566; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Dz9ki71CkSW+4vkNNZgkCYkgVSHEpJNx0ls9l/3l+Mk=; b=F3hzCCc6OtZzcmsxyaCyvFspNMUug1k7fD/YQ+QshScVHWYOeCOZbdQO lMBRtvtR7LJc3/NQLYWYqvIbhd4xRRnYzocmqplAnJM5bJxh95oxIaOTp mB8pi/1zndl4vifaxzmKIjcApfUXuSlNkW1Y57veysRHkk+ltfInPEjEB M=; X-IronPort-AV: E=Sophos;i="4.63,265,1299456000"; d="scan'208,217";a="81366445" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2011 21:59:25 +0000 Received: from fandreas-mac.local (dhcp-10-61-102-213.cisco.com [10.61.102.213]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TLxP42017455; Tue, 29 Mar 2011 21:59:25 GMT Message-ID: <4D92563C.100@cisco.com> Date: Tue, 29 Mar 2011 23:59:24 +0200 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <4D8B5F7E.5070204@cisco.com> <4D8C7C58.4090306@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040102090308010509070105" Cc: Flemming Andreasen , "Paul Kyzivat \(pkyzivat\)" , mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 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: , X-List-Received-Date: Tue, 29 Mar 2011 21:57:50 -0000 This is a multi-part message in MIME format. --------------040102090308010509070105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Simo and Miguel I have taken a closer look at the document and have some comments: Section 5.2.1 - How are dynamic payload types handled ? - How will "-" work with offer/answer (as Paul noted as well) Section 5.2.3 - s/should not/MUST NOT Section 5.2.3.1 - What's the specification policy for providing new correlation mechanisms and do we need an IANA registry ? - Informal grammer here suggests you can specify only one of the mechanisms. It is claried later that multiple can be specified (confusing here) Section 5.2.3.2 (and other places) - Why not simply require the E.164 numbers always be specified in their full International form (i.e. with country code). While that makes the "+" redundant, it's still good to include it per E.164/E.123 - The "callerid" subfield is specified as being that of the party inserting it. That raises some security concerns that need to be discussed. It would also seem to prevent use of the mechanism with 3PCC, which I don't believe is intended. Section 5.3 - As Paul noted, the O/A section overall needs to be expanded to describe the entire Offer generation, Answer generation, Offer processing of initial answer, and Modifying the Session (one section for each ala RFC 3264 preferably). The "setup", "connection", "c=", and "m=" lines, etc all need to be described - Lots of SHOULDs that seem like they should be MUSTs. If keeping them as SHOULDs, then we should be clear on why that is (including in the document). - I am confused on how the cs-correlation mechanism works. I would have thought the "calling" (active) party would send correlation info to the called (passive) party, but the O/A section seems to suggest that the calling (active) party gets the called (passive) party's correlation info and sends that to the called (passive) party somehow (spoofed caller-id ?). Did I misread this ? Section 5.5 - Would suggest making "+" mandatory in all telephone numbers and stick to International E.164 format. - Should restrict caller-id-value to 15 digits I believe. Section 6 - Example should be complete and show the answer SDP and resulting PSTN exchange (correlation part). The correlation info text seems counter to what the O/A section says, but again, I'm confused on the text in this area in general. Section 7 - Should move IANA Considerations to after Security Considerations Section 8 - Additional security considerations include risks associating with using unverified information as caller-id. More importantly, you are introducing a mechanism that causes your peer to initiate a call to a phone number of your choosing, and the security risks associated with that needs to be called out. Thanks -- Flemming On 3/28/11 11:24 AM, Simo.Veikkolainen@nokia.com wrote: > > Hello, > These are pretty much the only open issues we know of for this > document. If others have any concerns, it would be great if you could > post them on the list before Friday. > > Thanks > Simo > > > > -----Original Message----- > > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > Sent: 25 March, 2011 13:28 > > To: Paul Kyzivat > > Cc: Veikkolainen Simo (Nokia-MS/Helsinki); IETF MMUSIC WG > > Subject: Re: draft-ietf-mmusic-sdp-cs-06 > > > > Hi Paul, > > > > Thanks for your comments. See inline answers. > > > > On 24/03/2011 16:13, Paul Kyzivat wrote: > > > I have a couple of comments on this draft: > > > > > > There is still work to do to extend the o/a rules to handle '-' as a > > > media format. Specifically, if the offer contains '-', what may the > > > answer contain? And if the offer does not contain '-', may the > > answer? > > > > For sure, I agree. I think the information must be hidden or implicitly > > described, but this should be explicitly specified. At the moment the > > draft has O/A procedures for negotiating the correlation mechanism > > (Section 5.3). I think we should just have a more generic O/A > > procedures > > that discuss the whole draft, not only the correlation mechanism. > > > > > > > > > > When using uuie correlation, the uuie-value is defined as > > > 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a > > discriminator > > > byte that can be any one of 256 values. The draft doesn't mention if > > the > > > uuie-value contains the discriminator byte, or if that byte is > > assumed > > > to have some well known value. If it is to include the discriminator > > > byte, then some important discriminator byte values are neither alpha > > > nor digit. IMO the draft at least needs to explain what is intended. > > > > Problem acknowledged. We need to take a look at it and provide a > > solution. > > > > BR, > > > > Miguel > > > > > > > > > > Thanks, > > > Paul > > > > -- > > Miguel A. Garcia > > +34-91-339-3608 > > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------040102090308010509070105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Simo and Miguel

I have taken a closer look at the document and have some comments:

Section 5.2.1
- How are dynamic payload types handled ?
- How will "-" work with offer/answer (as Paul noted as well)

Section 5.2.3
- s/should not/MUST NOT

Section 5.2.3.1
- What's the specification policy for providing new correlation mechanisms and do we need an IANA registry ?
- Informal grammer here suggests you can specify only one of the mechanisms. It is claried later that multiple can be specified (confusing here)

Section 5.2.3.2 (and other places)
- Why not simply require the E.164 numbers always be specified in their full International form (i.e. with country code). While that makes the "+" redundant, it's still good to include it per E.164/E.123
- The "callerid" subfield is specified as being that of the party inserting it. That raises some security concerns that need to be discussed. It would also seem to prevent use of the mechanism with 3PCC, which I don't believe is intended.

Section 5.3
- As Paul noted, the O/A section overall needs to be expanded to describe the entire Offer generation, Answer generation, Offer processing of initial answer, and Modifying the Session (one section for each ala RFC 3264 preferably). The "setup", "connection", "c=", and "m=" lines, etc all need to be described
- Lots of SHOULDs that seem like they should be MUSTs. If keeping them as SHOULDs, then we should be clear on why that is (including in the document).
- I am confused on how the cs-correlation mechanism works. I would have thought the "calling" (active) party would send correlation info to the called (passive) party, but the O/A section seems to suggest that the calling (active) party gets the called (passive) party's correlation info and sends that to the called (passive) party somehow (spoofed caller-id ?). Did I misread this ?

Section 5.5
- Would suggest making "+" mandatory in all telephone numbers and stick to International E.164 format.
- Should restrict caller-id-value to 15 digits I believe.

Section 6
- Example should be complete and show the answer SDP and resulting PSTN exchange (correlation part). The correlation info text seems counter to what the O/A section says, but again, I'm confused on the text in this area in general.

Section 7
- Should move IANA Considerations to after Security Considerations

Section 8
- Additional security considerations include risks associating with using unverified information as caller-id. More importantly, you are introducing a mechanism that causes your peer to initiate a call to a phone number of your choosing, and the security risks associated with that needs to be called out.

Thanks

-- Flemming



On 3/28/11 11:24 AM, Simo.Veikkolainen@nokia.com wrote:
Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06

Hello,
These are pretty much the only open issues we know of for this document. If others have any concerns, it would be great if you could post them on the list before Friday.

Thanks
Simo


> -----Original Message-----
> From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: 25 March, 2011 13:28
> To: Paul Kyzivat
> Cc: Veikkolainen Simo (Nokia-MS/Helsinki); IETF MMUSIC WG
> Subject: Re: draft-ietf-mmusic-sdp-cs-06
>
> Hi Paul,
>
> Thanks for your comments. See inline answers.
>
> On 24/03/2011 16:13, Paul Kyzivat wrote:
> > I have a couple of comments on this draft:
> >
> > There is still work to do to extend the o/a rules to handle '-' as a
> > media format. Specifically, if the offer contains '-', what may the
> > answer contain? And if the offer does not contain '-', may the
> answer?
>
> For sure, I agree. I think the information must be hidden or implicitly
> described, but this should be explicitly specified. At the moment the
> draft has O/A procedures for negotiating the correlation mechanism
> (Section 5.3). I think we should just have a more generic O/A
> procedures
> that discuss the whole draft, not only the correlation mechanism.
>
>
> >
> > When using uuie correlation, the uuie-value is defined as
> > 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a
> discriminator
> > byte that can be any one of 256 values. The draft doesn't mention if
> the
> > uuie-value contains the discriminator byte, or if that byte is
> assumed
> > to have some well known value. If it is to include the discriminator
> > byte, then some important discriminator byte values are neither alpha
> > nor digit. IMO the draft at least needs to explain what is intended.
>
> Problem acknowledged. We need to take a look at it and provide a
> solution.
>
> BR,
>
>       Miguel
>
>
> >
> >     Thanks,
> >     Paul
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------040102090308010509070105-- From HKaplan@acmepacket.com Tue Mar 29 16:48:29 2011 Return-Path: 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 CE6543A6A96 for ; Tue, 29 Mar 2011 16:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 ov6evcCHOmTJ for ; Tue, 29 Mar 2011 16:48:29 -0700 (PDT) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id DB02C3A6A8F for ; Tue, 29 Mar 2011 16:48:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 29 Mar 2011 19:50:05 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 29 Mar 2011 19:50:05 -0400 From: Hadriel Kaplan To: Dan Wing Date: Tue, 29 Mar 2011 19:50:03 -0400 Thread-Topic: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer Thread-Index: AcvubAbqN5FYT4EuTAKZguGmxprbCA== Message-ID: References: <23b101cbeb16$e271d570$a7558050$@com> In-Reply-To: <23b101cbeb16$e271d570$a7558050$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Tue, 29 Mar 2011 23:48:30 -0000 On Mar 25, 2011, at 2:03 PM, Dan Wing wrote: > Sorry if this idea has been discussed already, but ... >=20 > ... Could we ask the middlebox to add a "Please-send-updated-offer:"=20 > header to the SIP message, if it wants to see an updated offer?? That me= ans > it doesn't need to understand ICE, but rather just needs to add that > header. It's still "a change to the middlebox", true, but it's a really > minor change compared to understanding ICE. I assume by "middlebox", we're talking about the 3PCC-style B2BUA scenario = in the slides? (which looks like a click-to-call app) In that scenario, t= he B2BUA is *not* a media-relaying middlebox, right? [set_worldview=3D"utopian"] Regardless, istm the 3PCC B2BUA needs to do the right thing, which is to be= a SIP B2BUA. As the UAS, it should either queue or answer the UPDATE from= UA1, and internally save the SDP and generate its own UPDATE as a UAC to U= A2. This problem isn't specific to ICE - UA1 could send an UPDATE anytime (or r= e-INVITE at any time after the ACK), and the 3PCC system needs to be able t= o handle it somehow. And if it can't, then it shouldn't indicate it can su= pport UPDATE in its Allow header. Also, I believe Flow-I of rfc3725, which is what the slide references, woul= d not have the B2BUA sending that ACK until it gets the 200 from UA2 (with = nasty repercussions for delaying the ACK, of course). [set_worldview=3D"normal"] -hadriel From HKaplan@acmepacket.com Tue Mar 29 18:55:22 2011 Return-Path: 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 0CCC63A6830 for ; Tue, 29 Mar 2011 18:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 0Kssh0gy5CO9 for ; Tue, 29 Mar 2011 18:55:21 -0700 (PDT) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id BF3C13A6834 for ; Tue, 29 Mar 2011 18:55:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 29 Mar 2011 21:56:57 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 29 Mar 2011 21:56:57 -0400 From: Hadriel Kaplan To: Gonzalo Camarillo Date: Tue, 29 Mar 2011 21:56:54 -0400 Thread-Topic: [MMUSIC] Yet another alternative to ICE WAS (Re: draft-ietf-mmusic-media-loopback-14 review and comments) Thread-Index: Acvufb9r0rA/WRovSoO0zFOInRcwkQ== Message-ID: <750D9AB2-32C2-48F4-9E11-1AC7D7CF807B@acmepacket.com> References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com> <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com> <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> In-Reply-To: <4CFAA584.8080507@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFT Cc: Flemming Andreasen , "vnagarjuna@gmail.com" , Kaynam Hedayat , "draft-ietf-mmusic-media-loopback@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Yet another alternative to ICE WAS (Re: draft-ietf-mmusic-media-loopback-14 review and comments) 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: , X-List-Received-Date: Wed, 30 Mar 2011 01:55:22 -0000 Sorry I hadn't noticed this email response before (you changed the subject = :) Comments inline... On Dec 4, 2010, at 3:33 PM, Gonzalo Camarillo wrote: > Hi, >=20 >>> - NAT Traversal and usage of ICE >>>=20 >>> [Authors] As Hadriel mentioned, if you have ICE you don=92t need the >>> loopback primer. As he also clarified, the loopback situation is >>> different from standard calls because the mirror will never send a >>> packet until it receives something from the source. This is certainly >>> possible for a regular call and calls may fail for that reason, but >>> the loopback draft is dead without a solution for this problem. >>> Remember that the primary use case for this draft is service providers >>> wanting to test to subscriber devices that are almost always behind >>> NATs. The proposed solution meets the requirements for the dominant >>> use case and while standard solutions are certainly usable when they >>> are available, the unfortunate reality is that most of them are not >>> implemented. We can add clarification text that if available ICE >>> should be used instead of the loopback primer method. >>>=20 >> Thanks. The draft will also need to clearly explain how the loopback >> primer would work, and in particular what the underlying assumptions are >> (e.g. latching) as well as when it will not work (e.g. when both source >> and mirror are behind a NAT, when you have overlapping IP-addresses and >> ports, etc). In short, the limitations of this approach must be clearly >> documented. >>=20 >> I will also check with our AD as to whether there are any additional >> concerns with specifying such a solution when we already have ICE as the >> Standard. >=20 > as you all know, there have been a number of proposals to standardize > simpler-than-ICE NAT traversal solutions that would only work in certain > scenarios or circumstances. There have been a lot of discussions around > them. A couple of IETFs ago there was even a bar BOF where people tried > to understand the issues that kept folks from deploying ICE in some > scenarios. I know there have been off-list follow ups on those > discussions but no draft have been submitted yet, AFAIK. >=20 > So, we need to frame this discussion taking into account the big picture > of NAT traversal and ICE. In this case, we need to understand the issues > that keep ICE from being widely deployed and, if needed, specify a > general solution to address those issues. Coming up with several > different NAT traversal mechanisms that only work in specific conditions > does not seem like the best outcome we can wish for. 1) While it's always nice to have general solutions to problems, I think it= 's unfair to make media-loopback go back the drawing board and wait for som= e new ICE-ish mechanism that hasn't even been proposed yet. The first loop= back draft was submitted in December 2004!! (wow) 2) I know this isn't an IAB-approved argument, but protocol history consist= ently shows that a simple incremental solution to fixing the problem at han= d invariably beats out a more complicated holistic solution to fix all poss= ible problems people don't yet have. By "beats out" I mean succeeds in get= ting adopted/implemented/used. =20 3) Let's suppose we come up with a new NAT traversal solution alternative t= o ICE, or some form of ICE-Lite which is actually/truly Lite, which I'll ca= ll "NICE" for now. Since lots of people don't have a problem with NAT trav= ersal today for normal calls because they've solved it some other way, they= won't need or even want NICE - their deployment ain't broken, so they won'= t want to fix it. But they'll still want loopback. Are we saying that in = order to loopback test their SIP calls, they have to change their network t= o NICE even for normal calls that aren't broken today? =20 4) One of the goals of loopback type testing is to make it as similar to a = normal call as possible. If the loopback call uses some NICE algorithm and= connectivity checking to choose from multiple paths or go through a TURN s= erver, and normal calls don't, the loopback test results are misleading. A= nd before anyone says "then make all calls use NICE"... that's the tail wag= ging the dog - people don't change their whole network for loopback testing= , loopback testing has to fit itself in deployed networks. My 4 cents, fwiw. -hadriel From framefritti@gmail.com Wed Mar 30 02:15:51 2011 Return-Path: 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 957153A6912 for ; Wed, 30 Mar 2011 02:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sj6L0ZKFsY4c for ; Wed, 30 Mar 2011 02:15:50 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9EDCF3A6875 for ; Wed, 30 Mar 2011 02:15:50 -0700 (PDT) Received: by qyk29 with SMTP id 29so2465858qyk.10 for ; Wed, 30 Mar 2011 02:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fJmAKG2c5jRUR4gKWjQefd60wn/zqTGwMz+SwdJ3Wto=; b=Ro4GxO+l8W6e1fqM64cpDoXvLhX8sJYApCkYmtnnNaw/q4oFBiLhJJmzVPKH/ul0Ol I007EwYJibI4y7cs5xUslu5Cbv6Be4D1bA8iPqHpQBidO3OtwCxmRTVOUVgg+K9YN/QS tAQG1sn8Ok1/rVuUexGzdldG23EtfC1I4p/cY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rumVJKGRTFCYgHQPf20zi8zFWE5RhiCxHjtB3CXk2XmTHfx47eRA7WL6wTUCiXiFTg ctLAkIOfkpn8cop3eQGpBzlpJKEd0N5cBcFKOWqQiUq4bZkUG686EXBRF+jsTO4lsK7O QsHIZuPm+zu0c9/I2DXOVY3ATnSxzYPo5DGuU= MIME-Version: 1.0 Received: by 10.229.52.34 with SMTP id f34mr737413qcg.275.1301476649067; Wed, 30 Mar 2011 02:17:29 -0700 (PDT) Received: by 10.229.187.6 with HTTP; Wed, 30 Mar 2011 02:17:28 -0700 (PDT) In-Reply-To: <4CFAA584.8080507@gmail.com> References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com> <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com> <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> Date: Wed, 30 Mar 2011 11:17:28 +0200 Message-ID: From: Riccardo Bernardini To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=0016367d530059e526049fafa52c Cc: mmusic Subject: Re: [MMUSIC] Yet another alternative to ICE WAS (Re: draft-ietf-mmusic-media-loopback-14 review and comments) 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: , X-List-Received-Date: Wed, 30 Mar 2011 09:15:51 -0000 --0016367d530059e526049fafa52c Content-Type: text/plain; charset=ISO-8859-1 2010/12/4 Gonzalo Camarillo > So, we need to frame this discussion taking into account the big picture > of NAT traversal and ICE. In this case, we need to understand the issues > that keep ICE from being widely deployed and, if needed, specify a > general solution to address those issues. Coming up with several > different NAT traversal mechanisms that only work in specific conditions > does not seem like the best outcome we can wish for. > > I encourage people who are working on those ICE-related issues to > participate in this discussion because this is an important area. > Hi, a question somehow related with this point: does someone know the order of magnitude of the time required to complete an ICE procedure? (possibly partitioned in the two components : time for candidate collection + time for checks). I am asking because NAT traversal is of some interest also in P2P streaming and long times could be a problem in high churn situations. Could long times be an obstacle to ICE deployment even in other contexts? > > Thanks, > > Gonzalo > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --0016367d530059e526049fafa52c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2010/12/4 Gonzalo Camarillo <gcamaril@gmail.com><= /span>
So, we need to frame this discussion taking into account the big picture of NAT traversal and ICE. In this case, we need to understand the issues that keep ICE from being widely deployed and, if needed, specify a
general solution to address those issues. Coming up with several
different NAT traversal mechanisms that only work in specific conditions does not seem like the best outcome we can wish for.

I encourage people who are working on those ICE-related issues to
participate in this discussion because this is an important area.

Hi,=A0
a question somehow related with= this point: does someone know the order of magnitude of the time required = to complete an ICE procedure? (possibly partitioned in the two components := time for candidate collection + time for checks). =A0I am asking because N= AT traversal is of some interest also in P2P streaming and long times could= be a problem in high churn situations. =A0Could long times be an obstacle = to ICE deployment even in other contexts?
=A0

Thanks,

Gonzalo
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--0016367d530059e526049fafa52c-- From dwing@cisco.com Wed Mar 30 02:20:38 2011 Return-Path: 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 14E913A6B24 for ; Wed, 30 Mar 2011 02:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.501 X-Spam-Level: X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 9gEdI8Rhn5dc for ; Wed, 30 Mar 2011 02:20:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 60A313A697A for ; Wed, 30 Mar 2011 02:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9720; q=dns/txt; s=iport; t=1301476935; x=1302686535; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=+7b7/PWoDtv7/Y8jO7K5HVKPOLgfRSltGAA0UOF2Lcc=; b=MvXeIebGDPFPXzPxqNteE9FkGJAFGD+6UwsHwPmDF6Z4gsC92oX9HwWE gF4IZyDUbUe8vGdPsiHogJhCx59S2Th2FKVlowPEKQAMpX8iKYk5HsSa5 7vngRC98m1Kmld0W6Q+5As6oM67rPHVZZn2MwU+6L8FF5w8xXf+XSbY4v M=; X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208";a="420796622" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2011 09:22:15 +0000 Received: from dwingWS (sjc-vpn2-813.cisco.com [10.21.115.45]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2U9MD2i013900; Wed, 30 Mar 2011 09:22:13 GMT From: "Dan Wing" To: "'Muthu ArulMozhi Perumal \(mperumal\)'" , "'Parthasarathi R \(partr\)'" , "'DRAGE, Keith \(Keith\)'" , "'Christer Holmberg'" , "'Flemming Andreasen \(fandreas\)'" , "'mmusic'" References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com> Date: Wed, 30 Mar 2011 11:22:12 +0200 Message-ID: <0e4201cbeebb$f527ea80$df77bf80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8gAAFBYCACkKF/oAApGcGA Content-Language: en-us Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Wed, 30 Mar 2011 09:20:38 -0000 > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Tuesday, March 29, 2011 3:58 PM > To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer Holmberg; > Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic > Subject: RE: [MMUSIC] Continued WG interest in SDP > offer/answerwithmiddleboxes? > > It looks to me that draft-ietf-mmusic-media-path-middleboxes is just an > extension of RFC 3303 -- while the later describes the middlebox > communication architecture and framework, the former describes some of > the desirable behaviors of these middleboxes and protocols that operate > on the media path unspecified in the later. RFC 3303 defines what an > ALG is and it doesn't forbid packets being addressed to the ALG at the > IP layer. > > > 2.6. ALG > Application Level Gateways (ALGs) are entities that possess the > application specific intelligence and knowledge of an associated > middlebox function. An ALG examines application traffic in transit > and assists the middlebox in carrying out its function. > > ALGs are different from proxies. ALGs are not visible to end-hosts, > unlike the proxies which are relay agents terminating sessions with > both end-hosts. ALGs do not terminate sessions with either end-host. > Instead, ALGs examine, and optionally modify, application payload > content to facilitate the flow of application traffic through a > middlebox. > > 2.8. MIDCOM Agents > MIDCOM agents are entities performing ALG functions, logically > external to a middlebox. > > The packets may be addressed to the agent node at the IP layer. > Alternatively they may not be addressed to the agent node, but may be > constrained by other factors to flow through it. > > > So, I don't see anything wrong in the use of ALG in > draft-ietf-mmusic-media-path-middleboxes, unless we plan to make > changes > to how RFC 3303 describes it. 3303 is quite clear, in exactly the text you quoted in the paragraph starting with "ALGs are different from proxies", that ALGs aren't visible to hosts and ALGs don't terminate sessions. An SBC is certainly visible to the end host, for both the SIP signaling and the RTP media -- the end host is sending packets to the SBC's IP address and receiving packets from the SBC's IP address. -d > Muthu > > |-----Original Message----- > |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) > |Sent: Wednesday, March 16, 2011 6:15 PM > |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); > Flemming > Andreasen (fandreas); mmusic > |Subject: Re: [MMUSIC] Continued WG interest in SDP > offer/answerwithmiddleboxes? > | > |Keith, > | > |Sorry in case "media" word in my mail mislead you. Dan explains in > |another mail thread > |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) > why > |SIP ALG is not appropriate and B2BUA is more appropriate for this > draft. > | > | > |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly fits > |your definition of B2BUA as it involves only SIP & SDP and media is > |defined as middlebox. > | > |I have mentioned as kind of B2BUA because the draft concentrates on > |callflow where one side of B2BUA acts as UAC and other side always > acts > |as UAS. IMO, the draft currently does not address B2BUA 3PCC callflows > |specific issues. In the current scope of draft is continued for the > |draft, the new definition may be required or draft text has to clarify > |the scope. > | > |Thanks > |Partha > | > |-----Original Message----- > |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > |Sent: Wednesday, March 16, 2011 5:33 PM > |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); > |Flemming Andreasen (fandreas); mmusic > |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer > |withmiddleboxes? > | > |The only definition of B2BUA that I know of comes in RFC 3261 (sort > of) > |where the scope is limited to SIP. So a UA acts in one or more > |directions as a SIP UA. Whatever else it does is outside the > definition. > |That I believe matches with what Christer is saying. > | > |If you want something that defines what it does with media, then you > |need something that defines that, but using the term B2BUA to do that > is > |probably not the best choice. > | > |Regards > | > |Keith > | > |> -----Original Message----- > |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> Behalf Of Parthasarathi R (partr) > |> Sent: 15 March 2011 09:54 > |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen > |> (fandreas); mmusic > |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > |> middleboxes? > |> > |> Christer, > |> > |> AFAIK, There is no restriction in terms of SIP B2BUA to handle > |> signaling only and it is upto the implementation to decide. Also, > this > | > |> draft does not have restriction that SIP B2BUA and media server has > to > | > |> be co-exist in the same device. The draft talks about the scenario > |> wherein SIP B2BUA communicates with media server using Megaco > (H.248). > |> > |> As I mentioned in other mail thread, ALG does not look appropriate > and > | > |> the draft is talking only about the specific type of B2BUA. In real > |> deployment, Few vendors named these sort of B2BUA as "Session Border > |> Controller or SBC" as well. SBC may not accepted in IETF as SBC does > |> lot more. In case there is a need to have different name for these > |> kind of SIP B2BUA entity to avoid the confusion, Let us work it out. > |> > |> Thanks > |> Partha > |> > |> -----Original Message----- > |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> Behalf Of Christer Holmberg > |> Sent: Tuesday, March 15, 2011 12:14 PM > |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' > |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > |> middleboxes? > |> > |> > |> Hi Dan, > |> > |> In my definition of an ALG packets can be sent directly to its IP > |> address. > |> > |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also > |> focuses on other things, like media. A SIP ALG contains a SIP B2BUA. > |> > |> Regards, > |> > |> Christer > |> > |> -----Original Message----- > |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> Behalf Of Dan Wing > |> Sent: 15. maaliskuuta 2011 4:39 > |> To: 'Flemming Andreasen'; 'mmusic' > |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with > |> middleboxes ? > |> > |> The draft uses the term "SIP ALG", which at least does not fit my > |> definition of an ALG. An ALG doesn't have packets sent directly to > |> its IP address; it does its job stealthily without awareness of one > |> (or > |> both) of the sessoin endpoints. In contrast, the function described > |> in draft-ietf-mmusic-media-path-middleboxes > |> is different -- packets are always sent to the IP address of the SIP > |> "ALG", and packets are sent from the IP address of the SIP "ALG". > |> This functionality is most often called a "server" > |> or a "proxy" -- not an ALG. > |> > |> This distinction is important because this draft is closely related > to > | > |> functions common in NATs, which _do_ sometimes have SIP ALGs > |> implemented in them. > |> > |> So ... can we change "SIP ALG" to something like "SIP proxy" > |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is > a > | > |> B2BUA, at least as best I understand the definition of a B2BUA, so > |> B2BUA seems best. > |> > |> d > |> > |> > |> > -----Original Message----- > |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> > Behalf Of Flemming Andreasen > |> > Sent: Thursday, March 10, 2011 6:15 PM > |> > To: mmusic > |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with > |> > middleboxes ? > |> > > |> > We currently have a MMUSIC milestone for "considerations for using > |> > SDP > |> > |> > offer/answer with middleboxes". The latest draft for this WG item > is > |> > > |> > draft-ietf-mmusic-media-path-middleboxes-03.txt > |> > > |> > which expired in January 2011. There hasn't been much discussion > on > |> > this topic for a while, and the current draft authors are not > |> > planning > |> > |> > continued work on the draft, so we need new authors if we are to > |> > continue with this WG item. Please let us know if > |> > 1) You are still interested in this deliverable > |> > 2) You are willing to actively contribute to and/or author this > |> > document. > |> > > |> > Thanks > |> > > |> > Flemming & Miguel [MMUSIC chairs] > |> > > |> > > |> > _______________________________________________ > |> > 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 > |> _______________________________________________ > |> 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 > |_______________________________________________ > |mmusic mailing list > |mmusic@ietf.org > |https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Wed Mar 30 02:21:05 2011 Return-Path: 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 28A083A6B41 for ; Wed, 30 Mar 2011 02:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 4npXP0-AM1CL for ; Wed, 30 Mar 2011 02:21:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 75DD83A6B36 for ; Wed, 30 Mar 2011 02:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=8170; q=dns/txt; s=iport; t=1301476961; x=1302686561; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=JtWrrAByNBCUuU45+6NAPdGvSiv5qC57789FfFI2Ksw=; b=OhYUvG37AlkLzR6DjU96rHT+sm5UblOsJKWQmzVNK9P+3/OJG0o+oWyW WhvcULnfjhUOsax1qwdhGb+iuBHrGvhHlTLColTi14rFvIUZScBvdo+YG /fUvU0iQ9+E6i43XDoDomnyHnyZzGDjWsq0WBhwLLJ1ohZw9P+JWeoZj1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgDAFj1kk2Q/khNgWdsb2JhbAClTBQBARYmJaE6nEyFagSNBg X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208,217";a="81439590" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2011 09:22:40 +0000 Received: from dhcp-4489.meeting.ietf.org (ams3-vpn-dhcp5530.cisco.com [10.61.85.153]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2U9MeNb010085; Wed, 30 Mar 2011 09:22:40 GMT Message-ID: <4D92F660.9050907@cisco.com> Date: Wed, 30 Mar 2011 11:22:40 +0200 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4D8B50FB.4030500@acm.org> In-Reply-To: <4D8B50FB.4030500@acm.org> Content-Type: multipart/alternative; boundary="------------020408050300000401050008" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media level ice-options attribute 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: , X-List-Received-Date: Wed, 30 Mar 2011 09:21:05 -0000 This is a multi-part message in MIME format. --------------020408050300000401050008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Marc Is there any particular reason why you want to redefine the existing ice-options attribute rather than defining a new media-level attribute, e.g. "ice-m-options" that has the semantics you are looking for here ? My main concern is backwards compatibility and possible semantic confusion, especially once we start considering interaction with other SDP extensions. Thanks -- Flemming On 3/24/11 3:11 PM, Marc Petit-Huguenin wrote: > > At the suggestions of the chairs, I'll explain here the problem that I > will be > presenting in Prague, so we can discuss it beforehand and make the > best of the > 10 minutes allocated to the presentation. > > This problem was discovered when implementing an endpoint supporting > disaggregated media. draft-loreto-dispatch-disaggregated-media gives > a good > presentation of what disaggregated media is, but to simplify it is > when the SIP > stack is physically separated from the RTP stack, or stacks in this > case, each > with its own ICE implementation. In my case I had audio on one > device, with my > own ICE/RTP stack, and video on a separate device with a proprietary > stack. I > wanted to add ECN support in my RTP stack but I could not signal it in > the SDP > resulting of the merge of the SDP coming from the two RTP stacks > because the > ice-options attribute is supposed to carry this piece of information in a > session-level only attribute, where in my case only one media was > supporting > ECN. If I added an ice-options at the media level it will be ignored > by the > stack on the other side, if I added it at the session level the other > side will > think that both medias supports ECN. > > So this proposal is to change the level from session-only to session *and* > media. But doing only this creates problems when a stack implementing > this > proposal is used with a legacy stack on the other side. This is why the > proposal also mandates to define how different ice-options at the > media level > are combined into the session level ice-options. For rtp+ecn, the > rules would > be that the session level attribute is set only if all the medias use the > rtp+ecn option. > > A similar problem exist for the ice-lite option, which is also defined > only at > the session level, when different implementations want to use > different values. > > Here my proposal is to not change anything, mostly because I do not > see how > media level values can be combined to a media level value that makes > sense. On > the other hand I do not care much about ICE-lite, so there is probably > perhaps > something that I missed. > > The slides for the presentation are available here: > > http://www.ietf.org/proceedings/80/slides/mmusic-1.pdf > > The I-D is available here: > > https://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level/ > > -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------020408050300000401050008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Marc

Is there any particular reason why you want to redefine the existing ice-options attribute rather than defining a new media-level attribute, e.g. "ice-m-options" that has the semantics you are looking for here ? My main concern is backwards compatibility and possible semantic confusion, especially once we start considering interaction with other SDP extensions.

Thanks

-- Flemming

On 3/24/11 3:11 PM, Marc Petit-Huguenin wrote:
[MMUSIC] Media level ice-options attribute

At the suggestions of the chairs, I'll explain here the problem that I will be
presenting in Prague, so we can discuss it beforehand and make the best of the
10 minutes allocated to the presentation.

This problem was discovered when implementing an endpoint supporting
disaggregated media.  draft-loreto-dispatch-disaggregated-media gives a good
presentation of what disaggregated media is, but to simplify it is when the SIP
stack is physically separated from the RTP stack, or stacks in this case, each
with its own ICE implementation.  In my case I had audio on one device, with my
own ICE/RTP stack, and video on a separate device with a proprietary stack.  I
wanted to add ECN support in my RTP stack but I could not signal it in the SDP
resulting of the merge of the SDP coming from the two RTP stacks because the
ice-options attribute is supposed to carry this piece of information in a
session-level only attribute, where in my case only one media was supporting
ECN.  If I added an ice-options at the media level it will be ignored by the
stack on the other side, if I added it at the session level the other side will
think that both medias supports ECN.

So this proposal is to change the level from session-only to session *and*
media.  But doing only this creates problems when a stack implementing this
proposal is used with a legacy stack on the other side.  This is why the
proposal also mandates to define how different ice-options at the media level
are combined into the session level ice-options.  For rtp+ecn, the rules would
be that the session level attribute is set only if all the medias use the
rtp+ecn option.

A similar problem exist for the ice-lite option, which is also defined only at
the session level, when different implementations want to use different values.

Here my proposal is to not change anything, mostly because I do not see how
media level values can be combined to a media level value that makes sense.  On
the other hand I do not care much about ICE-lite, so there is probably perhaps
something that I missed.

The slides for the presentation are available here:

http://www.ietf.org/proceedings/80/slides/mmusic-1.pdf

The I-D is available here:

https://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level/

--
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------020408050300000401050008-- From ag@ag-projects.com Wed Mar 30 02:52:45 2011 Return-Path: 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 0041D3A6B41 for ; Wed, 30 Mar 2011 02:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, 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 rc-AmXDiTDPq for ; Wed, 30 Mar 2011 02:52:44 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by core3.amsl.com (Postfix) with ESMTP id C384D3A6B42 for ; Wed, 30 Mar 2011 02:52:43 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 30903B01B1; Wed, 30 Mar 2011 11:54:20 +0200 (CEST) Received: from [192.168.0.110] (unknown [193.86.76.179]) by mail.sipthor.net (Postfix) with ESMTPSA id ADED8B019B; Wed, 30 Mar 2011 11:54:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1049098764 From: Adrian Georgescu In-Reply-To: Date: Wed, 30 Mar 2011 11:54:05 +0200 Message-Id: <4B369DF4-2778-494D-8D73-67A1901C2FBD@ag-projects.com> References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com> <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com> <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> To: Riccardo Bernardini X-Mailer: Apple Mail (2.1082) Cc: mmusic , Gonzalo Camarillo Subject: Re: [MMUSIC] Yet another alternative to ICE WAS (Re: draft-ietf-mmusic-media-loopback-14 review and comments) 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: , X-List-Received-Date: Wed, 30 Mar 2011 09:52:45 -0000 --Apple-Mail-1-1049098764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, What we learned when deploying Blink with ICE enabled by default: - Some SIP ALG implementations caused broken call flows, some NAT = routers even reset ! when an ICE proposal was detected=20 - The SIP packet size was to large when using UDP for some NAT routers, = because of fragmentation issues - For PSTN calls, media always go through operator servers, commercial = SIP service providers do not care much about ICE ICE itself works fine, is the fact that most SIP deployments are using = UDP transport that makes things behave unreliable. If UDP transport = would be deprecated and TLS made mandatory all these problems would not = exit as no SIP ALG will temper with the SIP packets and the packet size = would not matter. So we turned ICE off by default to avoid complaints. Regards, Adrian On Mar 30, 2011, at 11:17 AM, Riccardo Bernardini wrote: >=20 >=20 > 2010/12/4 Gonzalo Camarillo > So, we need to frame this discussion taking into account the big = picture > of NAT traversal and ICE. In this case, we need to understand the = issues > that keep ICE from being widely deployed and, if needed, specify a > general solution to address those issues. Coming up with several > different NAT traversal mechanisms that only work in specific = conditions > does not seem like the best outcome we can wish for. >=20 > I encourage people who are working on those ICE-related issues to > participate in this discussion because this is an important area. >=20 > Hi,=20 > a question somehow related with this point: does someone know the = order of magnitude of the time required to complete an ICE procedure? = (possibly partitioned in the two components : time for candidate = collection + time for checks). I am asking because NAT traversal is of = some interest also in P2P streaming and long times could be a problem in = high churn situations. Could long times be an obstacle to ICE = deployment even in other contexts? > =20 >=20 > Thanks, >=20 > Gonzalo > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-1-1049098764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

2010/12/4 Gonzalo = Camarillo <gcamaril@gmail.com>
So, we need to frame this discussion taking into account the big = picture
of NAT traversal and ICE. In this case, we need to understand the = issues
that keep ICE from being widely deployed and, if needed, specify a
general solution to address those issues. Coming up with several
different NAT traversal mechanisms that only work in specific = conditions
does not seem like the best outcome we can wish for.

I encourage people who are working on those ICE-related issues to
participate in this discussion because this is an important = area.

Hi, 
a question = somehow related with this point: does someone know the order of = magnitude of the time required to complete an ICE procedure? (possibly = partitioned in the two components : time for candidate collection + time = for checks).  I am asking because NAT traversal is of some interest = also in P2P streaming and long times could be a problem in high churn = situations.  Could long times be an obstacle to ICE deployment even = in other contexts?
 

Thanks,

Gonzalo
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

= --Apple-Mail-1-1049098764-- From thomas.stach@siemens-enterprise.com Wed Mar 30 03:49:30 2011 Return-Path: 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 B79B028C0F0 for ; Wed, 30 Mar 2011 03:49:30 -0700 (PDT) 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=[AWL=0.000, 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 Y46XpPh2Ckfm for ; Wed, 30 Mar 2011 03:49:29 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8744828C0DB for ; Wed, 30 Mar 2011 03:49:29 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3939152; Wed, 30 Mar 2011 12:51:07 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8C21A1EB82B5; Wed, 30 Mar 2011 12:51:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 30 Mar 2011 12:51:07 +0200 From: "Stach, Thomas" To: Hadriel Kaplan , Dan Wing Date: Wed, 30 Mar 2011 12:51:05 +0200 Thread-Topic: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer Thread-Index: AcvubAbqN5FYT4EuTAKZguGmxprbCAAW32Lg Message-ID: References: <23b101cbeb16$e271d570$a7558050$@com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Wed, 30 Mar 2011 10:49:30 -0000 Hadriel, see inline > -----Urspr=FCngliche Nachricht----- > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Gesendet: Mittwoch, 30. M=E4rz 2011 01:50 > An: Dan Wing > Cc: Stach, Thomas; mmusic@ietf.org > Betreff: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer >=20 >=20 > On Mar 25, 2011, at 2:03 PM, Dan Wing wrote: >=20 > > Sorry if this idea has been discussed already, but ... > >=20 > > ... Could we ask the middlebox to add a=20 > "Please-send-updated-offer:"=20 > > header to the SIP message, if it wants to see an updated=20 > offer?? That means > > it doesn't need to understand ICE, but rather just needs to add that > > header. It's still "a change to the middlebox", true, but=20 > it's a really > > minor change compared to understanding ICE. >=20 > I assume by "middlebox", we're talking about the 3PCC-style=20 > B2BUA scenario in the slides? (which looks like a=20 > click-to-call app) In that scenario, the B2BUA is *not* a=20 > media-relaying middlebox, right? >=20 > [set_worldview=3D"utopian"] >=20 > Regardless, istm the 3PCC B2BUA needs to do the right thing,=20 > which is to be a SIP B2BUA. As the UAS, it should either=20 > queue or answer the UPDATE from UA1, and internally save the=20 > SDP and generate its own UPDATE as a UAC to UA2. >=20 > This problem isn't specific to ICE - UA1 could send an UPDATE=20 > anytime (or re-INVITE at any time after the ACK), and the=20 > 3PCC system needs to be able to handle it somehow. =20 Well, this problem is specific to ICE since ICE wants us to provide the ans= wer early in order to get the STUN checks going. > And if it=20 > can't, then it shouldn't indicate it can support UPDATE in=20 > its Allow header. Just replace the UPDATE with a re-INVITE and you're in the same mess. >=20 > Also, I believe Flow-I of rfc3725, which is what the slide=20 > references, would not have the B2BUA sending that ACK until=20 > it gets the 200 from UA2 (with nasty repercussions for=20 > delaying the ACK, of course). Yes, but again ICE wants to have the answer early Regards Thomas >=20 > [set_worldview=3D"normal"] >=20 > -hadriel >=20 > = From HKaplan@acmepacket.com Wed Mar 30 04:35:35 2011 Return-Path: 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 C97C128C11F for ; Wed, 30 Mar 2011 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 fN2Dw+C4WP0d for ; Wed, 30 Mar 2011 04:35:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 592F428C0DB for ; Wed, 30 Mar 2011 04:35:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Mar 2011 07:37:12 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 30 Mar 2011 07:37:11 -0400 From: Hadriel Kaplan To: "Stach, Thomas" Date: Wed, 30 Mar 2011 07:37:09 -0400 Thread-Topic: AW: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer Thread-Index: Acvuzs7WHcIALOXjT26R+rPdel4oEw== Message-ID: <2DA73A94-C2EA-4725-9EF9-E5637B25F653@acmepacket.com> References: <23b101cbeb16$e271d570$a7558050$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "mmusic@ietf.org" , Dan Wing Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Wed, 30 Mar 2011 11:35:35 -0000 On Mar 30, 2011, at 6:51 AM, Stach, Thomas wrote: >> This problem isn't specific to ICE - UA1 could send an UPDATE=20 >> anytime (or re-INVITE at any time after the ACK), and the=20 >> 3PCC system needs to be able to handle it somehow. =20 > Well, this problem is specific to ICE since ICE wants us to provide the a= nswer early in order to get the STUN checks going. Sorry, I wasn't clear - I don't mean it's not a problem that needs to be so= lved - but rather the problem and thus solution are not ICE-specific. ICE = may happen to exacerbate it, but 3PCC systems need to handle these cases re= gardless of ICE. No? >> And if it=20 >> can't, then it shouldn't indicate it can support UPDATE in=20 >> its Allow header. > Just replace the UPDATE with a re-INVITE and you're in the same mess. Not technically - the Flow-I case in rfc3725 does not send the ACK back unt= il UA2 returns 200, so there is no opportunity for a re-INVITE SDP overlap.= (I realize that in the slides the ACK is not being delayed, but the slide = says it's Flow-I of rfc3725) =20 But anyway that wasn't my point - my point was if you're a 3PCC B2BUA doing= click-to-call, it does not absolve you of needing to be a SIP B2BUA. If y= ou say it's a problem of UPDATE handling, then the B2BUA should not indicat= e it can handle UPDATEs. If you say it's still a problem for re-INVITE, th= en the B2BUA should not claim it supports RFC 3261. BTW, I realize the real world may be different, which is why I wrapped my c= omments in worldview=3D"utopian" tags. ;) Is it the case that the 3PCC B2BUA cannot reasonably handle this as the log= ical concatenation of UAS+UAC in the real world? If so, why not? -hadriel From thomas.stach@siemens-enterprise.com Wed Mar 30 05:20:47 2011 Return-Path: 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 4E43228C197 for ; Wed, 30 Mar 2011 05:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 SNg2IiDJDLsG for ; Wed, 30 Mar 2011 05:20:46 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0A66928C190 for ; Wed, 30 Mar 2011 05:20:43 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3948112; Wed, 30 Mar 2011 14:22:21 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8FD0623F0294; Wed, 30 Mar 2011 14:22:21 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 30 Mar 2011 14:22:21 +0200 From: "Stach, Thomas" To: Hadriel Kaplan Date: Wed, 30 Mar 2011 14:22:20 +0200 Thread-Topic: AW: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer Thread-Index: Acvuzs7WHcIALOXjT26R+rPdel4oEwAADzJw Message-ID: References: <23b101cbeb16$e271d570$a7558050$@com> <2DA73A94-C2EA-4725-9EF9-E5637B25F653@acmepacket.com> In-Reply-To: <2DA73A94-C2EA-4725-9EF9-E5637B25F653@acmepacket.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Wed, 30 Mar 2011 12:20:47 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Gesendet: Mittwoch, 30. M=E4rz 2011 13:37 > An: Stach, Thomas > Cc: Dan Wing; mmusic@ietf.org > Betreff: Re: AW: [MMUSIC] Presentation of=20 > Draft-elwell-ice-updated-offer >=20 >=20 > On Mar 30, 2011, at 6:51 AM, Stach, Thomas wrote: >=20 > >> This problem isn't specific to ICE - UA1 could send an UPDATE=20 > >> anytime (or re-INVITE at any time after the ACK), and the=20 > >> 3PCC system needs to be able to handle it somehow. =20 > > Well, this problem is specific to ICE since ICE wants us to=20 > provide the answer early in order to get the STUN checks going. >=20 > Sorry, I wasn't clear - I don't mean it's not a problem that=20 > needs to be solved - but rather the problem and thus solution=20 > are not ICE-specific. ICE may happen to exacerbate it, but=20 > 3PCC systems need to handle these cases regardless of ICE. No? Sure, I think we are on the same page.=20 Of course this 3PCC problem can be solved.=20 Slide 6 mention 100rel and UPDATE, but they raise the bar for deployment of= ICE, especially=20 if you want ICE just for IPv4/IPv6 transition. The discussed draft just explores 2 problems that arise during ICE deployme= nt and asks if there is interest to do something about it without yet proposin= g solutions. Regards Thomas >=20 >=20 > >> And if it=20 > >> can't, then it shouldn't indicate it can support UPDATE in=20 > >> its Allow header. > > Just replace the UPDATE with a re-INVITE and you're in the=20 > same mess. >=20 > Not technically - the Flow-I case in rfc3725 does not send=20 > the ACK back until UA2 returns 200, so there is no=20 > opportunity for a re-INVITE SDP overlap. (I realize that in=20 > the slides the ACK is not being delayed, but the slide says=20 > it's Flow-I of rfc3725) =20 >=20 > But anyway that wasn't my point - my point was if you're a=20 > 3PCC B2BUA doing click-to-call, it does not absolve you of=20 > needing to be a SIP B2BUA. If you say it's a problem of=20 > UPDATE handling, then the B2BUA should not indicate it can=20 > handle UPDATEs. If you say it's still a problem for=20 > re-INVITE, then the B2BUA should not claim it supports RFC 3261. >=20 > BTW, I realize the real world may be different, which is why=20 > I wrapped my comments in worldview=3D"utopian" tags. ;) > Is it the case that the 3PCC B2BUA cannot reasonably handle=20 > this as the logical concatenation of UAS+UAC in the real=20 > world? If so, why not? >=20 > -hadriel >=20 > = From thomas.stach@siemens-enterprise.com Wed Mar 30 05:52:17 2011 Return-Path: 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 EF22F3A6A1C for ; Wed, 30 Mar 2011 05:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 1Az6NNMbqbPq for ; Wed, 30 Mar 2011 05:52:16 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9456B3A6816 for ; Wed, 30 Mar 2011 05:52:14 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3932723; Wed, 30 Mar 2011 14:53:53 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0E85F23F0294; Wed, 30 Mar 2011 14:53:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 30 Mar 2011 14:53:53 +0200 From: "Stach, Thomas" To: "Stach, Thomas" , Hadriel Kaplan Date: Wed, 30 Mar 2011 14:53:51 +0200 Thread-Topic: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer Thread-Index: Acvuzs7WHcIALOXjT26R+rPdel4oEwAADzJwAAKFWvA= Message-ID: References: <23b101cbeb16$e271d570$a7558050$@com> <2DA73A94-C2EA-4725-9EF9-E5637B25F653@acmepacket.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer 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: , X-List-Received-Date: Wed, 30 Mar 2011 12:52:17 -0000 replying to myself inline=20 > -----Urspr=FCngliche Nachricht----- > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > Im Auftrag von Stach, Thomas > Gesendet: Mittwoch, 30. M=E4rz 2011 14:22 > An: Hadriel Kaplan > Cc: mmusic@ietf.org > Betreff: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > > Gesendet: Mittwoch, 30. M=E4rz 2011 13:37 > > An: Stach, Thomas > > Cc: Dan Wing; mmusic@ietf.org > > Betreff: Re: AW: [MMUSIC] Presentation of=20 > > Draft-elwell-ice-updated-offer > >=20 > >=20 > > On Mar 30, 2011, at 6:51 AM, Stach, Thomas wrote: > >=20 > > >> This problem isn't specific to ICE - UA1 could send an UPDATE=20 > > >> anytime (or re-INVITE at any time after the ACK), and the=20 > > >> 3PCC system needs to be able to handle it somehow. =20 > > > Well, this problem is specific to ICE since ICE wants us to=20 > > provide the answer early in order to get the STUN checks going. > >=20 > > Sorry, I wasn't clear - I don't mean it's not a problem that=20 > > needs to be solved - but rather the problem and thus solution=20 > > are not ICE-specific. ICE may happen to exacerbate it, but=20 > > 3PCC systems need to handle these cases regardless of ICE. No? > Sure, I think we are on the same page.=20 > Of course this 3PCC problem can be solved.=20 > Slide 6 mention 100rel and UPDATE, but they raise the bar for=20 > deployment of ICE, especially=20 > if you want ICE just for IPv4/IPv6 transition. > The discussed draft just explores 2 problems that arise=20 > during ICE deployment > and asks if there is interest to do something about it=20 > without yet proposing solutions. Well,=20 "...eliminating the need for the updated offer-answer cycle" mentions a possible solution. Thomas >=20 >=20 > Regards > Thomas >=20 > >=20 > >=20 > > >> And if it=20 > > >> can't, then it shouldn't indicate it can support UPDATE in=20 > > >> its Allow header. > > > Just replace the UPDATE with a re-INVITE and you're in the=20 > > same mess. > >=20 > > Not technically - the Flow-I case in rfc3725 does not send=20 > > the ACK back until UA2 returns 200, so there is no=20 > > opportunity for a re-INVITE SDP overlap. (I realize that in=20 > > the slides the ACK is not being delayed, but the slide says=20 > > it's Flow-I of rfc3725) =20 > >=20 > > But anyway that wasn't my point - my point was if you're a=20 > > 3PCC B2BUA doing click-to-call, it does not absolve you of=20 > > needing to be a SIP B2BUA. If you say it's a problem of=20 > > UPDATE handling, then the B2BUA should not indicate it can=20 > > handle UPDATEs. If you say it's still a problem for=20 > > re-INVITE, then the B2BUA should not claim it supports RFC 3261. > >=20 > > BTW, I realize the real world may be different, which is why=20 > > I wrapped my comments in worldview=3D"utopian" tags. ;) > > Is it the case that the 3PCC B2BUA cannot reasonably handle=20 > > this as the logical concatenation of UAS+UAC in the real=20 > > world? If so, why not? > >=20 > > -hadriel > >=20 > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From gorry@erg.abdn.ac.uk Wed Mar 30 06:33:32 2011 Return-Path: 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 C9C9C3A6A1C for ; Wed, 30 Mar 2011 06:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.841 X-Spam-Level: X-Spam-Status: No, score=-101.841 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 UsRMamxQ08iV for ; Wed, 30 Mar 2011 06:33:32 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 418C03A6B50 for ; Wed, 30 Mar 2011 06:33:30 -0700 (PDT) Received: from dhcp-1773.meeting.ietf.org ([IPv6:2001:df8:0:16:5ab0:35ff:fe7b:b828]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p2UDZ2dC002607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Mar 2011 14:35:02 +0100 (BST) Message-ID: <4D933186.2030804@erg.abdn.ac.uk> Date: Wed, 30 Mar 2011 15:35:02 +0200 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Wed, 30 Mar 2011 06:47:21 -0700 Cc: gorry@erg.abdn.ac.uk, Pasi Sarolahti Subject: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.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: , X-List-Received-Date: Wed, 30 Mar 2011 13:33:32 -0000 draft-ietf-dccp-udpencap-07.txt We have a short presentation for the MMUSIC meeting on Friday on the above draft. The draft defines support for a UDP Encapsulation for NAPT traversal. This draft has completed DCCP WGLC, and had one hanging issue that needed to be resolved, concerning the way it updates SDP for DCCP [RFC5762]. The basic questions are: Is there an "easy" way to define SDP that would also allow it to be used on a UDP host that doesn't allow native DCCP? - How do you signal a server that supports both native and UDP-encapsulated DCCP? - In the build-up to Friday's meeting, we'd really welcome discussion to help progress this. The options described in the slides are illustrated by two examples: Signalling that uses a new proto in SDP m= line to indicate DCCP, plus the SDP connection-oriented media extensions [RFC 4145], as per current draft. v=0 o=alice 1129377363 1 IN IP4 192.0.2.47 s=- c=IN IP4 192.0.2.47 t=0 0 m=video 5004 DCCP/RTP/AVP 99 a=rtcp-mux a=rtpmap:99 h261/90000 a=dccp-service-code:SC=x5254505 a=dccp-in-udp:9999 a=setup:passive a=connection:new or a new m= proto value. v=0 o=alice 1129377363 1 IN IP4 192.0.2.47 s=- c=IN IP4 192.0.2.47 t=0 0 m=video 5004 DCCP-UDP/RTP/AVP 99 a=rtcp-mux a=rtpmap:99 h261/90000 a=dccp-service-code:SC=x52545056 a=setup:passive a=connection:new a=dccp-udp-port:9999 Please see the slides/draft for details: http://www.ietf.org/proceedings/80/slides/mmusic-8.pdf Best wishes, Gorry & Colin From fandreas@cisco.com Wed Mar 30 09:06:01 2011 Return-Path: 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 21AF23A6B7A for ; Wed, 30 Mar 2011 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 0K3IRvssBrf5 for ; Wed, 30 Mar 2011 09:05:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6742E3A6A48 for ; Wed, 30 Mar 2011 09:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=22501; q=dns/txt; s=iport; t=1301501253; x=1302710853; h=message-id:date:from:mime-version:to:subject; bh=sVvcIcE0LYjMFA6ZaK5/JSjBfqZvlGEJORlR2QosBH8=; b=NVrOnM+bFqIA32yMzAbWCY7zixFJGI0QgMRs/tsTemiSxKVR9pbwQHHg vYbipDconvDMwxzaF32zwFp+KEEtwVs4VvkABnPVBBbxOeZ61tj4+llkB T6PcJ/Ieuq9Trc/rNnhERh6Ces6wXKAbcXbPiGxyjVZNRhw+gcSHqaC+h s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8DAMRUk02Q/khLgWdsb2JhbACCXqJ0FAEBFiYloQ6cYYVqBI0G X-IronPort-AV: E=Sophos;i="4.63,269,1299456000"; d="scan'208,217";a="23823630" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2011 16:07:32 +0000 Received: from dhcp-13d9.meeting.ietf.org (dhcp-10-61-106-154.cisco.com [10.61.106.154]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2UG7Wc9000381 for ; Wed, 30 Mar 2011 16:07:32 GMT Message-ID: <4D935544.8050204@cisco.com> Date: Wed, 30 Mar 2011 18:07:32 +0200 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------020501080402000805070602" Subject: [MMUSIC] Updated MMUSIC Agenda 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: , X-List-Received-Date: Wed, 30 Mar 2011 16:06:01 -0000 This is a multi-part message in MIME format. --------------020501080402000805070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings We have shuffled a few agenda items around and uploaded a new MMUSIC agenda at http://www.ietf.org/proceedings/80/agenda/mmusic.htm See below as well. Regards Miguel & Flemming IETF-80, Prague Multiparty Multimedia Session Control (MMUSIC) WG ================================================== *** AGENDA *** Chairs: Miguel Garcia (miguel.a.garcia@ericsson.com ) Flemming Andreasen (fandreas@cisco.com ) FRIDAY, April 1, 2011, 9:00--11:30 (Barcelona/Berlin) ----------------------------------------------------- 9:00--9:15 Introduction and Status Update (Chairs, 15) 9:15--9:30 Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) (Veikkolainen, 15) Title and Bandwidth Capabilities Negotiation in the Session Description (Veikkolainen) draft-ietf-mmusic-sdp-cs-06 draft-mmusic-sdp-icap-bcap-01 9:30--09:45 ICE Updated Offer Problematic (Stach, 15) draft-elwell-mmusic-ice-updated-offer-00 09:45-09:55 Media level ice-options SDP attribute (Petit-Huguenin, 10) draft-petithuguenin-mmusic-ice-attributes-level-00 09:55-10:10 Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) (Fairhurst, Perkins, 15) draft-ietf-dccp-udpencap-07 10:10-10:20 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) (Loreto, 10) draft-loreto-mmusic-sctp-sdp-07 10:20-10:30 Grouping of Adjacent Media in the Session Description Protocol (Jennings, 10) draft-jennings-mmusic-adjacent-grouping-03 10:30-10:40 The Session Description Protocol (SDP) 'trafficclass' Attribute (Polk, 10) draft-polk-mmusic-traffic-class-for-sdp-01 10:40-10:55 SDP attribute to signal parallax (Greevenbosch, 15) Signal 3D format (Greevenbosh) draft-greevenbosch-mmusic-parallax-attribute-00 draft-greevenbosch-mmusic-signal-3d-format-00 10:55-11:10 Temporal Interleaving Attribute in the Session Description Protocol (Begen, 15) Redundancy Grouping Semantics in the Session Description Protocol (Begen) draft-begen-mmusic-temporal-interleaving-01 draft-begen-mmusic-redundancy-grouping-00 11:10--11:20 TCP Candidates with Interactive Connectivity Establishment (ICE) (Keranen, 10) draft-ietf-mmusic-ice-tcp-12 11:20--11:30 Wrap-up --------------020501080402000805070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

We have shuffled a few agenda items around and uploaded a new MMUSIC agenda at

     http://www.ietf.org/proceedings/80/agenda/mmusic.htm  

See below as well.

Regards

    Miguel & Flemming



IETF-80, Prague

 

Multiparty Multimedia Session Control (MMUSIC) WG

==================================================

** AGENDA **

 

Chairs: Miguel Garcia (miguel.a.garcia@ericsson.com)

        Flemming Andreasen (fandreas@cisco.com)      

 

 

FRIDAY, April 1, 2011, 9:00–11:30 (Barcelona/Berlin)

-----------------------------------------------------

 

9:00–9:15   Introduction and Status Update (Chairs, 15)

 

9:15–9:30   Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) (Veikkolainen, 15)

            Title and Bandwidth Capabilities Negotiation in the Session Description (Veikkolainen)

 

            draft-ietf-mmusic-sdp-cs-06

            draft-mmusic-sdp-icap-bcap-01

 

 

9:30–09:45  ICE Updated Offer Problematic (Stach, 15)

 

draft-elwell-mmusic-ice-updated-offer-00

 

 

09:45-09:55 Media level ice-options SDP attribute (Petit-Huguenin, 10)

 

draft-petithuguenin-mmusic-ice-attributes-level-00

 

 

09:55-10:10 Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) (Fairhurst, Perkins, 15)

 

draft-ietf-dccp-udpencap-07

 

 

10:10-10:20 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) (Loreto, 10)

 

            draft-loreto-mmusic-sctp-sdp-07

 

 

10:20-10:30 Grouping of Adjacent Media in the Session Description Protocol (Jennings, 10)

 

draft-jennings-mmusic-adjacent-grouping-03

 

 

10:30-10:40 The Session Description Protocol (SDP) 'trafficclass' Attribute (Polk, 10)

 

            draft-polk-mmusic-traffic-class-for-sdp-01

 

 

10:40-10:55 SDP attribute to signal parallax (Greevenbosch, 15)

            Signal 3D format  (Greevenbosh)

           

            draft-greevenbosch-mmusic-parallax-attribute-00

            draft-greevenbosch-mmusic-signal-3d-format-00

 

 

10:55-11:10 Temporal Interleaving Attribute in the Session Description Protocol (Begen, 15)

            Redundancy Grouping Semantics in the Session Description Protocol (Begen)

 

            draft-begen-mmusic-temporal-interleaving-01

            draft-begen-mmusic-redundancy-grouping-00

 

 

11:10–11:20 TCP Candidates with Interactive Connectivity Establishment (ICE) (Keranen, 10)

 

            draft-ietf-mmusic-ice-tcp-12

 

 

11:20–11:30 Wrap-up



--------------020501080402000805070602-- From skillzero@gmail.com Wed Mar 30 11:27:27 2011 Return-Path: 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 037BE28C18B for ; Wed, 30 Mar 2011 11:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 jLsvipQqghrf for ; Wed, 30 Mar 2011 11:27:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E126728C161 for ; Wed, 30 Mar 2011 11:27:25 -0700 (PDT) Received: by wyb29 with SMTP id 29so1503649wyb.31 for ; Wed, 30 Mar 2011 11:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=fJdlogRmQX0OCj7vyfuYOqHRm4DWltu77q73VIic8z8=; b=mis08OEA9hxubrzLSYS4wsJki1UIRiHEcCyCYJnNWNlNHz4bTEuV2w5nxRv3ctdpWv Dp5H5RVx0AccrnCDFMN4PvdLNZNSQWDvsq6L0vdoOptKtt7DG4zK3A1xkzL9fukvh3os Uie5ois1G4rRIGAmRy3CZ81l3YJgqwEVqKTWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u1a9ZPePCjJpglQXDE2TWi5zbKu3TJb2yHSXUS9+tYzjlvauWSokIqFe1fGuY1AZMD xKpTAdM2ViOExx5fRh0B+Nt4gi4VAqL3NcBFF4RUwmK5omwJoJ23mrxR7giJdhrLRrr2 xDEqEVrCTIylUCCDfWk7nHydR4Ivbrrfmt6bA= MIME-Version: 1.0 Received: by 10.216.239.200 with SMTP id c50mr1610902wer.8.1301509744434; Wed, 30 Mar 2011 11:29:04 -0700 (PDT) Received: by 10.216.17.138 with HTTP; Wed, 30 Mar 2011 11:29:04 -0700 (PDT) Date: Wed, 30 Mar 2011 11:29:04 -0700 Message-ID: From: skillzero@gmail.com To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] Synchronization source for synchronizing stream changes? 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: , X-List-Received-Date: Wed, 30 Mar 2011 18:27:27 -0000 Is it acceptable, from an RTP protocol perspective, to use the synchronization source ID in the RTP header to synchronize changes in the RTP stream, such as encoding, display characteristics (e.g. rotation, scaling), etc.? Or are there better ways to handle this? When I'm sending video frames via RTP, changes that happen on the source, such as the encoder config, transforms for display, etc. may change on a frame-by-frame basis, such as when the user rotates a source camera or the quality is reduced based on network conditions. Normally, this is sent via static SDP during session setup, but here it changes in the middle of a session. When it happens, I send the new data via a separate channel (e.g. RTCP/RTSP), but this also means it's possible for RTP video frames to arrive before the updated configuration info arrives. I need to know to defer trying to decode or display the frame until the new configuration comes in via the other channel. It seemed reasonable to use the synchronization source ID in the RTP header to indicate this. Whenever something changes, the ssrc could be incremented so the receiver knows it needs to wait until out-of-band information about the new ssrc arrives before it processes the RTP packet. Packets may also be lost so I didn't want to rely on a one-time thing like the marker bit. Payload type has a pretty small usable range and I can see it wrapping too quickly for this usage. Does this break any rules of RTP? Or is there a recommended way to handle these situations? From miguel.a.garcia@ericsson.com Thu Mar 31 02:03:39 2011 Return-Path: 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 C75F428C15E for ; Thu, 31 Mar 2011 02:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, 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 JRWdfwFBbtxm for ; Thu, 31 Mar 2011 02:03:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 449FC28C0E1 for ; Thu, 31 Mar 2011 02:03:38 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-5c-4d9443ccf51c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.E7.09202.CC3449D4; Thu, 31 Mar 2011 11:05:16 +0200 (CEST) Received: from [159.107.105.228] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 31 Mar 2011 11:05:16 +0200 Message-ID: <4D9443CB.7080705@ericsson.com> Date: Thu, 31 Mar 2011 11:05:15 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] IANA registration of the "image" media type in SDP 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: , X-List-Received-Date: Thu, 31 Mar 2011 09:03:39 -0000 As a chair It has been made aware to the chairs that SDP has not registered an 'image' media type, meaning that we should not be able to use "m=image..." in SDP. RFC 4566 intends to create an IANA registry of media types (See Section 8.2.1 in RFC 4566), but while it registers "audio", "video", and others, it does not register "image". This "image" mime type is widely used, for example, for signaling T38 fax, or in the examples in comedia (RFC 4145). To add a bit more complication, this registry has never been created, even when RFC 4566 creates the registry. See http://www.iana.org/assignments/sdp-parameters Both things (lack of registration of "image" media type and lack of the registry itself) seem to be an oversight, and should be fixed. In order to solve these issues, the chairs propose the following two actions: - First, let's contact IANA and to find out if they can create the registry that RFC 4566 mandates. Note that, as per RFC 4566 this would not register the "image" media type, but all the others indicated in RFC 4566. - Second, we can open a bug and roll down this registration in a 4566bis draft, that we should be working on to fix other found bugs. There is an alternative to this second aspect: write a one-page Internet-Draft that registers the "image" media type. We think this might be an overkill, considering that we have a bug-fixing revision of 4566 in the pipeline, which could be done as fast as this alternative. And, we have still include the "image" media type in 4566bis. Your comments are highly appreciated. Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From keith.drage@alcatel-lucent.com Thu Mar 31 02:13:36 2011 Return-Path: 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 A859A28C1FB for ; Thu, 31 Mar 2011 02:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.715 X-Spam-Level: X-Spam-Status: No, score=-103.715 tagged_above=-999 required=5 tests=[AWL=-2.066, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 YXlORk1vEGFf for ; Thu, 31 Mar 2011 02:13:35 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id E8E173A699C for ; Thu, 31 Mar 2011 02:13:34 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2V9EuNB002706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 11:15:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 31 Mar 2011 11:14:54 +0200 From: "DRAGE, Keith (Keith)" To: "Miguel A. Garcia" , mmusic Date: Thu, 31 Mar 2011 11:14:52 +0200 Thread-Topic: [MMUSIC] IANA registration of the "image" media type in SDP Thread-Index: AcvvgtBReFlWUczhSO6PC7mPARcBLwAAJwiw Message-ID: References: <4D9443CB.7080705@ericsson.com> In-Reply-To: <4D9443CB.7080705@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP 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: , X-List-Received-Date: Thu, 31 Mar 2011 09:13:36 -0000 I remain to be convinced that there is enough new material on the table to = spin a new version of 4566. I am also unaware of anything major in interope= rability terms that needs to be fixed. In any case, generation of that vers= ion would take well over 12 months, and the IANA registration does not occu= r until IESG approval. So I would suggest creating a new i-d that defines and registers the m=3Dim= age. This is no different to what has occurred with many attribute values. You can either use this new draft to also create the IANA table, or follow = your proposed path of talking to IANA directly - both should be possible. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 31 March 2011 10:05 > To: mmusic > Subject: [MMUSIC] IANA registration of the "image" media type in SDP >=20 > As a chair >=20 > It has been made aware to the chairs that SDP has not registered an > 'image' media type, meaning that we should not be able to use > "m=3Dimage..." in SDP. >=20 > RFC 4566 intends to create an IANA registry of media types (See Section > 8.2.1 in RFC 4566), but while it registers "audio", "video", and others, > it does not register "image". This "image" mime type is widely used, for > example, for signaling T38 fax, or in the examples in comedia (RFC 4145). >=20 > To add a bit more complication, this registry has never been created, > even when RFC 4566 creates the registry. See > http://www.iana.org/assignments/sdp-parameters >=20 > Both things (lack of registration of "image" media type and lack of the > registry itself) seem to be an oversight, and should be fixed. >=20 > In order to solve these issues, the chairs propose the following two > actions: >=20 > - First, let's contact IANA and to find out if they can create the > registry that RFC 4566 mandates. Note that, as per RFC 4566 this would > not register the "image" media type, but all the others indicated in RFC > 4566. >=20 > - Second, we can open a bug and roll down this registration in a 4566bis > draft, that we should be working on to fix other found bugs. >=20 > There is an alternative to this second aspect: write a one-page > Internet-Draft that registers the "image" media type. We think this might > be an overkill, considering that we have a bug-fixing revision of 4566 in > the pipeline, which could be done as fast as this alternative. And, we > have still include the "image" media type in 4566bis. >=20 > Your comments are highly appreciated. >=20 > Miguel and Flemming >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Thu Mar 31 02:37:05 2011 Return-Path: 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 2B67D28C0DD for ; Thu, 31 Mar 2011 02:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 GPyoKvET61uC for ; Thu, 31 Mar 2011 02:37:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 231AE28C0F1 for ; Thu, 31 Mar 2011 02:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=6217; q=dns/txt; s=iport; t=1301564318; x=1302773918; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=FePpYNjLhAcvkjm8NjhVq8Mj9mWAeQE7VtB71IviHAU=; b=lOFGHFq6Deeqo7wRg3Jq+A1LmGq1V0FeMKEZeaIbwYWSvZbamjQRSyvD J4XHLZAYZEfVdcqmitN2WxT2BXrpgMfGVvFL/SYwOJVqeQPROjqzUfHmG VpZ0X45rl+gpZCYkcbQpCoHCz2whbJyid9CjTTViHCD2/DAauf+oNqw+p w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoDAGtKlE2Q/khLgWdsb2JhbAClTxQBARYmJaI/nBCFawSNEYcE X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208,217";a="81610947" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2011 09:38:36 +0000 Received: from dhcp-13d9.meeting.ietf.org (dhcp-10-55-92-118.cisco.com [10.55.92.118]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2V9caIe001305; Thu, 31 Mar 2011 09:38:36 GMT Message-ID: <4D944B9D.8010404@cisco.com> Date: Thu, 31 Mar 2011 11:38:37 +0200 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: skillzero@gmail.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070305010000050707040100" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Synchronization source for synchronizing stream changes? 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: , X-List-Received-Date: Thu, 31 Mar 2011 09:37:05 -0000 This is a multi-part message in MIME format. --------------070305010000050707040100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is probably more of an AVT list question, so you may want to redirect your question there. In any case, from an RTP point of view, there is in theory nothing that prevents you from changing SSRC at any point during a session, however do note that mechanisms have appeared that signal SSRC values as part of the application signaling and hence there may be some interaction issues to consider there. Similarly, you are describing behavior that is not normally associated with an SSRC change, so you would want to make sure that your application protocol negotiates support for such semantics. Thanks -- Flemming On 3/30/11 8:29 PM, skillzero@gmail.com wrote: > > Is it acceptable, from an RTP protocol perspective, to use the > synchronization source ID in the RTP header to synchronize changes in > the RTP stream, such as encoding, display characteristics (e.g. > rotation, scaling), etc.? Or are there better ways to handle this? > > When I'm sending video frames via RTP, changes that happen on the > source, such as the encoder config, transforms for display, etc. may > change on a frame-by-frame basis, such as when the user rotates a > source camera or the quality is reduced based on network conditions. > Normally, this is sent via static SDP during session setup, but here > it changes in the middle of a session. When it happens, I send the new > data via a separate channel (e.g. RTCP/RTSP), but this also means it's > possible for RTP video frames to arrive before the updated > configuration info arrives. I need to know to defer trying to decode > or display the frame until the new configuration comes in via the > other channel. > > It seemed reasonable to use the synchronization source ID in the RTP > header to indicate this. Whenever something changes, the ssrc could be > incremented so the receiver knows it needs to wait until out-of-band > information about the new ssrc arrives before it processes the RTP > packet. Packets may also be lost so I didn't want to rely on a > one-time thing like the marker bit. Payload type has a pretty small > usable range and I can see it wrapping too quickly for this usage. > > Does this break any rules of RTP? Or is there a recommended way to > handle these situations? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------070305010000050707040100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is probably more of an AVT list question, so you may want to redirect your question there.

In any case, from an RTP point of view, there is in theory nothing that prevents you from changing SSRC at any point during a session, however do note that mechanisms have appeared that signal SSRC values as part of the application signaling and hence there may be some interaction issues to consider there. Similarly, you are describing behavior that is not normally associated with an SSRC change, so you would want to make sure that your application protocol negotiates support for such semantics.

Thanks

-- Flemming

On 3/30/11 8:29 PM, skillzero@gmail.com wrote:
[MMUSIC] Synchronization source for synchronizing stream changes?

Is it acceptable, from an RTP protocol perspective, to use the
synchronization source ID in the RTP header to synchronize changes in
the RTP stream, such as encoding, display characteristics (e.g.
rotation, scaling), etc.? Or are there better ways to handle this?

When I'm sending video frames via RTP, changes that happen on the
source, such as the encoder config, transforms for display, etc. may
change on a frame-by-frame basis, such as when the user rotates a
source camera or the quality is reduced based on network conditions.
Normally, this is sent via static SDP during session setup, but here
it changes in the middle of a session. When it happens, I send the new
data via a separate channel (e.g. RTCP/RTSP), but this also means it's
possible for RTP video frames to arrive before the updated
configuration info arrives. I need to know to defer trying to decode
or display the frame until the new configuration comes in via the
other channel.

It seemed reasonable to use the synchronization source ID in the RTP
header to indicate this. Whenever something changes, the ssrc could be
incremented so the receiver knows it needs to wait until out-of-band
information about the new ssrc arrives before it processes the RTP
packet. Packets may also be lost so I didn't want to rely on a
one-time thing like the marker bit. Payload type has a pretty small
usable range and I can see it wrapping too quickly for this usage.

Does this break any rules of RTP? Or is there a recommended way to
handle these situations?
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------070305010000050707040100-- From mperumal@cisco.com Thu Mar 31 02:59:32 2011 Return-Path: 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 757A73A6AFA for ; Thu, 31 Mar 2011 02:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 BLXwVR5eG1fk for ; Thu, 31 Mar 2011 02:59:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 44D503A6A3D for ; Thu, 31 Mar 2011 02:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=35199; q=dns/txt; s=iport; t=1301565668; x=1302775268; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ngFo7P+HvsIqRpaWuSjb+1MhUlKG5nhLoQfGqKxstik=; b=dc0PKONZ+eGV7CzIy1zNJjgPi5vkEz1T4M5R7q97/bfvibCQ84GA4ujg M2JdVjRcmcIEkJqHpD2W6Q0Dag23Z3vOSMAuaCmHxTynxhPn/gaCssorr 70TKWeqqHUfCYgPBUAwGBHzFyeaKBsQ3zVcsajai3v/DSUcneibJTyP+b s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0AAEJQlE2Q/khLgWdsb2JhbACCXpUvjUEUAQEWJiWiRJwPhWsEhT+LLYMp X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208,217";a="81615104" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2011 10:01:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2VA0XlA008302; Thu, 31 Mar 2011 10:01:06 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 15:31:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEF8A.8CBCE83C" Date: Thu, 31 Mar 2011 15:31:04 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513F870@XMB-BGL-414.cisco.com> In-Reply-To: <4D944B9D.8010404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Synchronization source for synchronizing streamchanges? Thread-Index: Acvvh8c5+XMCH/VJQDa+KCRDDc5bxgAAc9zw References: <4D944B9D.8010404@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Flemming Andreasen (fandreas)" , X-OriginalArrivalTime: 31 Mar 2011 10:01:05.0886 (UTC) FILETIME=[8CE9F7E0:01CBEF8A] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Synchronization source for synchronizing streamchanges? 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: , X-List-Received-Date: Thu, 31 Mar 2011 09:59:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEF8A.8CBCE83C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To add to Flemming, here are other reasons that can cause SSRC changes that the application needs to eliminate if it wants to associate a change in SSRC with a particular cause: http://www.ietf.org/mail-archive/web/avt/current/msg13669.html =20 =20 Muthu =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen (fandreas) Sent: Thursday, March 31, 2011 3:09 PM To: skillzero@gmail.com Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Synchronization source for synchronizing streamchanges? =20 This is probably more of an AVT list question, so you may want to redirect your question there.=20 In any case, from an RTP point of view, there is in theory nothing that prevents you from changing SSRC at any point during a session, however do note that mechanisms have appeared that signal SSRC values as part of the application signaling and hence there may be some interaction issues to consider there. Similarly, you are describing behavior that is not normally associated with an SSRC change, so you would want to make sure that your application protocol negotiates support for such semantics.=20 Thanks=20 -- Flemming=20 On 3/30/11 8:29 PM, skillzero@gmail.com wrote:=20 Is it acceptable, from an RTP protocol perspective, to use the synchronization source ID in the RTP header to synchronize changes in the RTP stream, such as encoding, display characteristics (e.g. rotation, scaling), etc.? Or are there better ways to handle this? When I'm sending video frames via RTP, changes that happen on the source, such as the encoder config, transforms for display, etc. may change on a frame-by-frame basis, such as when the user rotates a source camera or the quality is reduced based on network conditions. Normally, this is sent via static SDP during session setup, but here it changes in the middle of a session. When it happens, I send the new data via a separate channel (e.g. RTCP/RTSP), but this also means it's possible for RTP video frames to arrive before the updated configuration info arrives. I need to know to defer trying to decode or display the frame until the new configuration comes in via the other channel. It seemed reasonable to use the synchronization source ID in the RTP header to indicate this. Whenever something changes, the ssrc could be incremented so the receiver knows it needs to wait until out-of-band information about the new ssrc arrives before it processes the RTP packet. Packets may also be lost so I didn't want to rely on a one-time thing like the marker bit. Payload type has a pretty small usable range and I can see it wrapping too quickly for this usage. Does this break any rules of RTP? Or is there a recommended way to handle these situations? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01CBEF8A.8CBCE83C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MMUSIC] Synchronization source for synchronizing stream = changes?

To add to Flemming, here are other reasons that can cause SSRC changes that the application needs to eliminate if it wants to associate = a change in SSRC with a particular = cause:

h= ttp://www.ietf.org/mail-archive/web/avt/current/msg13669.html

 

 

Muthu

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen (fandreas)
Sent: Thursday, March 31, 2011 3:09 PM
To: skillzero@gmail.com
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Synchronization source for synchronizing streamchanges?

 

This is probably more of an AVT list question, so you may want to redirect = your question there.

In any case, from an RTP point of view, there is in theory nothing that prevents you from changing SSRC at any point during a session, however = do note that mechanisms have appeared that signal SSRC values as part of the application signaling and hence there may be some interaction issues to consider there. Similarly, you are describing behavior that is not = normally associated with an SSRC change, so you would want to make sure that your application protocol negotiates support for such semantics.

Thanks

-- Flemming

On 3/30/11 8:29 PM, skillzero@gmail.com wrote:

Is it acceptable, from an RTP = protocol perspective, to use the
synchronization source ID in the RTP header to synchronize changes = in
the RTP stream, such as encoding, display characteristics (e.g.
rotation, scaling), etc.? Or are there better ways to handle this?

When I'm sending video frames via RTP, changes that happen on the
source, such as the encoder config, transforms for display, etc. may
change on a frame-by-frame basis, such as when the user rotates a
source camera or the quality is reduced based on network conditions.
Normally, this is sent via static SDP during session setup, but here
it changes in the middle of a session. When it happens, I send the = new
data via a separate channel (e.g. RTCP/RTSP), but this also means = it's
possible for RTP video frames to arrive before the updated
configuration info arrives. I need to know to defer trying to decode
or display the frame until the new configuration comes in via the
other channel.

It seemed reasonable to use the synchronization source ID in the RTP
header to indicate this. Whenever something changes, the ssrc could = be
incremented so the receiver knows it needs to wait until out-of-band
information about the new ssrc arrives before it processes the RTP
packet. Packets may also be lost so I didn't want to rely on a
one-time thing like the marker bit. Payload type has a pretty small
usable range and I can see it wrapping too quickly for this usage.

Does this break any rules of RTP? Or is there a recommended way to
handle these situations?
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

------_=_NextPart_001_01CBEF8A.8CBCE83C-- From mperumal@cisco.com Thu Mar 31 03:59:26 2011 Return-Path: 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 7299E28C125 for ; Thu, 31 Mar 2011 03:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 V4NEvVSw80I6 for ; Thu, 31 Mar 2011 03:59:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5C7EF28C11E for ; Thu, 31 Mar 2011 03:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=11050; q=dns/txt; s=iport; t=1301569264; x=1302778864; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/4BtBJTPoPUv5cCHCllI0cgq+ehfOAkyw+z+qhDbcDo=; b=mtJSauHIRHaz00rQ1iroQQ2tLUiNBHF9l1+nHhB2tWXw4G7uC2nvvDJK aSyB6JEg4Miuyu/CDRwiMGmgMTtk2fCXFonYFUbZF0aV5S/WZ2fiT60mE VrQXM4hsuBT7eGm8u3/XjpIHb5X64OmTRSajRwQBNgCS8EPk3skEUn3LY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwAAKVdlE2Q/khNgWdsb2JhbACYDY1AFAEBFiYlokacDoVrBIU/iy0 X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="23932623" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 31 Mar 2011 11:00:59 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2VAxdBA019560; Thu, 31 Mar 2011 11:00:59 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 16:30:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 16:30:55 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com> In-Reply-To: <0e4201cbeebb$f527ea80$df77bf80$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8gAAFBYCACkKF/oAApGcGAAAXja7A= References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com> <0e4201cbeebb$f527ea80$df77bf80$@com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Dan Wing (dwing)" , "Parthasarathi R (partr)" , "DRAGE, Keith (Keith)" , "Christer Holmberg" , "Flemming Andreasen (fandreas)" , "mmusic" X-OriginalArrivalTime: 31 Mar 2011 11:00:57.0680 (UTC) FILETIME=[E9CA3D00:01CBEF92] Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Thu, 31 Mar 2011 10:59:26 -0000 I agree with your interpretation of what an SBC is. However, the reason why I don't find anything wrong in the use of ALG in draft-ietf-mmusic-media-path-middleboxes is because it describes firewall and NAT traversal functions that are typically implemented as ALGs, except that these functions are decoupled into a MIDCOM agent and a middle box. In addition RFC 3303 goes on to say (section 2.8) that MIDCOM agents are entities performing ALG functions, logically external to a middlebox. It even says these agents can reside on a proxy. Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the ALG in Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the draft I think. Muthu |-----Original Message----- |From: Dan Wing (dwing) |Sent: Wednesday, March 30, 2011 2:52 PM |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); 'DRAGE, Keith (Keith)'; 'Christer |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Tuesday, March 29, 2011 3:58 PM |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer Holmberg; |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic |> Subject: RE: [MMUSIC] Continued WG interest in SDP |> offer/answerwithmiddleboxes? |> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is just an |> extension of RFC 3303 -- while the later describes the middlebox |> communication architecture and framework, the former describes some of |> the desirable behaviors of these middleboxes and protocols that operate |> on the media path unspecified in the later. RFC 3303 defines what an |> ALG is and it doesn't forbid packets being addressed to the ALG at the |> IP layer. |> |> |> 2.6. ALG |> Application Level Gateways (ALGs) are entities that possess the |> application specific intelligence and knowledge of an associated |> middlebox function. An ALG examines application traffic in transit |> and assists the middlebox in carrying out its function. |> |> ALGs are different from proxies. ALGs are not visible to end-hosts, |> unlike the proxies which are relay agents terminating sessions with |> both end-hosts. ALGs do not terminate sessions with either end-host. |> Instead, ALGs examine, and optionally modify, application payload |> content to facilitate the flow of application traffic through a |> middlebox. |> |> 2.8. MIDCOM Agents |> MIDCOM agents are entities performing ALG functions, logically |> external to a middlebox. |> |> The packets may be addressed to the agent node at the IP layer. |> Alternatively they may not be addressed to the agent node, but may be |> constrained by other factors to flow through it. |> |> |> So, I don't see anything wrong in the use of ALG in |> draft-ietf-mmusic-media-path-middleboxes, unless we plan to make |> changes |> to how RFC 3303 describes it. | |3303 is quite clear, in exactly the text you quoted in the paragraph |starting with "ALGs are different from proxies", that ALGs aren't |visible to hosts and ALGs don't terminate sessions. | |An SBC is certainly visible to the end host, for both the SIP |signaling and the RTP media -- the end host is sending packets |to the SBC's IP address and receiving packets from the SBC's |IP address. | |-d | | |> Muthu |> |> |-----Original Message----- |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> Behalf Of Parthasarathi R (partr) |> |Sent: Wednesday, March 16, 2011 6:15 PM |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); |> Flemming |> Andreasen (fandreas); mmusic |> |Subject: Re: [MMUSIC] Continued WG interest in SDP |> offer/answerwithmiddleboxes? |> | |> |Keith, |> | |> |Sorry in case "media" word in my mail mislead you. Dan explains in |> |another mail thread |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) |> why |> |SIP ALG is not appropriate and B2BUA is more appropriate for this |> draft. |> | |> | |> |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly fits |> |your definition of B2BUA as it involves only SIP & SDP and media is |> |defined as middlebox. |> | |> |I have mentioned as kind of B2BUA because the draft concentrates on |> |callflow where one side of B2BUA acts as UAC and other side always |> acts |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC callflows |> |specific issues. In the current scope of draft is continued for the |> |draft, the new definition may be required or draft text has to clarify |> |the scope. |> | |> |Thanks |> |Partha |> | |> |-----Original Message----- |> |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] |> |Sent: Wednesday, March 16, 2011 5:33 PM |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); |> |Flemming Andreasen (fandreas); mmusic |> |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer |> |withmiddleboxes? |> | |> |The only definition of B2BUA that I know of comes in RFC 3261 (sort |> of) |> |where the scope is limited to SIP. So a UA acts in one or more |> |directions as a SIP UA. Whatever else it does is outside the |> definition. |> |That I believe matches with what Christer is saying. |> | |> |If you want something that defines what it does with media, then you |> |need something that defines that, but using the term B2BUA to do that |> is |> |probably not the best choice. |> | |> |Regards |> | |> |Keith |> | |> |> -----Original Message----- |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> |> Behalf Of Parthasarathi R (partr) |> |> Sent: 15 March 2011 09:54 |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen |> |> (fandreas); mmusic |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with |> |> middleboxes? |> |> |> |> Christer, |> |> |> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle |> |> signaling only and it is upto the implementation to decide. Also, |> this |> | |> |> draft does not have restriction that SIP B2BUA and media server has |> to |> | |> |> be co-exist in the same device. The draft talks about the scenario |> |> wherein SIP B2BUA communicates with media server using Megaco |> (H.248). |> |> |> |> As I mentioned in other mail thread, ALG does not look appropriate |> and |> | |> |> the draft is talking only about the specific type of B2BUA. In real |> |> deployment, Few vendors named these sort of B2BUA as "Session Border |> |> Controller or SBC" as well. SBC may not accepted in IETF as SBC does |> |> lot more. In case there is a need to have different name for these |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work it out. |> |> |> |> Thanks |> |> Partha |> |> |> |> -----Original Message----- |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> |> Behalf Of Christer Holmberg |> |> Sent: Tuesday, March 15, 2011 12:14 PM |> |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with |> |> middleboxes? |> |> |> |> |> |> Hi Dan, |> |> |> |> In my definition of an ALG packets can be sent directly to its IP |> |> address. |> |> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also |> |> focuses on other things, like media. A SIP ALG contains a SIP B2BUA. |> |> |> |> Regards, |> |> |> |> Christer |> |> |> |> -----Original Message----- |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> |> Behalf Of Dan Wing |> |> Sent: 15. maaliskuuta 2011 4:39 |> |> To: 'Flemming Andreasen'; 'mmusic' |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with |> |> middleboxes ? |> |> |> |> The draft uses the term "SIP ALG", which at least does not fit my |> |> definition of an ALG. An ALG doesn't have packets sent directly to |> |> its IP address; it does its job stealthily without awareness of one |> |> (or |> |> both) of the sessoin endpoints. In contrast, the function described |> |> in draft-ietf-mmusic-media-path-middleboxes |> |> is different -- packets are always sent to the IP address of the SIP |> |> "ALG", and packets are sent from the IP address of the SIP "ALG". |> |> This functionality is most often called a "server" |> |> or a "proxy" -- not an ALG. |> |> |> |> This distinction is important because this draft is closely related |> to |> | |> |> functions common in NATs, which _do_ sometimes have SIP ALGs |> |> implemented in them. |> |> |> |> So ... can we change "SIP ALG" to something like "SIP proxy" |> |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it is |> a |> | |> |> B2BUA, at least as best I understand the definition of a B2BUA, so |> |> B2BUA seems best. |> |> |> |> d |> |> |> |> |> |> > -----Original Message----- |> |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |> |> > Behalf Of Flemming Andreasen |> |> > Sent: Thursday, March 10, 2011 6:15 PM |> |> > To: mmusic |> |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with |> |> > middleboxes ? |> |> > |> |> > We currently have a MMUSIC milestone for "considerations for using |> |> > SDP |> |> |> |> > offer/answer with middleboxes". The latest draft for this WG item |> is |> |> > |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt |> |> > |> |> > which expired in January 2011. There hasn't been much discussion |> on |> |> > this topic for a while, and the current draft authors are not |> |> > planning |> |> |> |> > continued work on the draft, so we need new authors if we are to |> |> > continue with this WG item. Please let us know if |> |> > 1) You are still interested in this deliverable |> |> > 2) You are willing to actively contribute to and/or author this |> |> > document. |> |> > |> |> > Thanks |> |> > |> |> > Flemming & Miguel [MMUSIC chairs] |> |> > |> |> > |> |> > _______________________________________________ |> |> > 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 |> |> _______________________________________________ |> |> 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 |> |_______________________________________________ |> |mmusic mailing list |> |mmusic@ietf.org |> |https://www.ietf.org/mailman/listinfo/mmusic From mperumal@cisco.com Thu Mar 31 04:02:38 2011 Return-Path: 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 658E128C122 for ; Thu, 31 Mar 2011 04:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mZj2XqOjOwv1 for ; Thu, 31 Mar 2011 04:02:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BBE0F28C10C for ; Thu, 31 Mar 2011 04:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=12037; q=dns/txt; s=iport; t=1301569455; x=1302779055; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=liG7F28fcTmbEN3hSvYin/0VYewD9xYPJJ26AEeUW4o=; b=BZeYtIcXQrVC3XOn+8inKtMEjp09+IrECBlYykxx9lXc0X///XXc/bIA Xe1Vi67TZcPk9qsUMMGQ2PLTAXsjPeWb+FC+vunWLLUhNBrmrGBE9AYdD VkDe125nBdy8UizgnBn17NsLKQptFWMQr+siI0uhyJu/jZC330pCQgedb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwAAExelE2Q/khMgWdsb2JhbACYDY1AFAEBFiYlokOcDoVrBIU/iy0 X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="81625825" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2011 11:04:14 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2VB4DT9026812; Thu, 31 Mar 2011 11:04:13 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 16:34:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 16:34:11 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513F8B3@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest in SDPoffer/answerwithmiddleboxes? Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8gAAFBYCACkKF/oAApGcGAAAXja7AAMAtiwA== References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com> <1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Dan Wing (dwing)" , "Parthasarathi R (partr)" , "DRAGE, Keith (Keith)" , "Christer Holmberg" , "Flemming Andreasen (fandreas)" , "mmusic" X-OriginalArrivalTime: 31 Mar 2011 11:04:13.0327 (UTC) FILETIME=[5E6799F0:01CBEF93] Subject: Re: [MMUSIC] Continued WG interest in SDPoffer/answerwithmiddleboxes? 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: , X-List-Received-Date: Thu, 31 Mar 2011 11:02:38 -0000 |should cause any issues for the draft I think. Meant shouldn't cause any issues for the draft I think -:) Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal |(mperumal) |Sent: Thursday, March 31, 2011 4:31 PM |To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith); Christer Holmberg; Flemming |Andreasen (fandreas); mmusic |Subject: Re: [MMUSIC] Continued WG interest in SDPoffer/answerwithmiddleboxes? | |I agree with your interpretation of what an SBC is. However, the reason |why I don't find anything wrong in the use of ALG in |draft-ietf-mmusic-media-path-middleboxes is because it describes |firewall and NAT traversal functions that are typically implemented as |ALGs, except that these functions are decoupled into a MIDCOM agent and |a middle box. In addition RFC 3303 goes on to say (section 2.8) that |MIDCOM agents are entities performing ALG functions, logically external |to a middlebox. It even says these agents can reside on a proxy. |Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the ALG in |Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the draft I |think. | |Muthu | ||-----Original Message----- ||From: Dan Wing (dwing) ||Sent: Wednesday, March 30, 2011 2:52 PM ||To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); |'DRAGE, Keith (Keith)'; 'Christer ||Holmberg'; Flemming Andreasen (fandreas); 'mmusic' ||Subject: RE: [MMUSIC] Continued WG interest in SDP |offer/answerwithmiddleboxes? || ||> -----Original Message----- ||> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||> Sent: Tuesday, March 29, 2011 3:58 PM ||> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer Holmberg; ||> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic ||> Subject: RE: [MMUSIC] Continued WG interest in SDP ||> offer/answerwithmiddleboxes? ||> ||> It looks to me that draft-ietf-mmusic-media-path-middleboxes is just |an ||> extension of RFC 3303 -- while the later describes the middlebox ||> communication architecture and framework, the former describes some |of ||> the desirable behaviors of these middleboxes and protocols that |operate ||> on the media path unspecified in the later. RFC 3303 defines what an ||> ALG is and it doesn't forbid packets being addressed to the ALG at |the ||> IP layer. ||> ||> ||> 2.6. ALG ||> Application Level Gateways (ALGs) are entities that possess the ||> application specific intelligence and knowledge of an associated ||> middlebox function. An ALG examines application traffic in transit ||> and assists the middlebox in carrying out its function. ||> ||> ALGs are different from proxies. ALGs are not visible to end-hosts, ||> unlike the proxies which are relay agents terminating sessions with ||> both end-hosts. ALGs do not terminate sessions with either end-host. ||> Instead, ALGs examine, and optionally modify, application payload ||> content to facilitate the flow of application traffic through a ||> middlebox. ||> ||> 2.8. MIDCOM Agents ||> MIDCOM agents are entities performing ALG functions, logically ||> external to a middlebox. ||> ||> The packets may be addressed to the agent node at the IP layer. ||> Alternatively they may not be addressed to the agent node, but may be ||> constrained by other factors to flow through it. ||> ||> ||> So, I don't see anything wrong in the use of ALG in ||> draft-ietf-mmusic-media-path-middleboxes, unless we plan to make ||> changes ||> to how RFC 3303 describes it. || ||3303 is quite clear, in exactly the text you quoted in the paragraph ||starting with "ALGs are different from proxies", that ALGs aren't ||visible to hosts and ALGs don't terminate sessions. || ||An SBC is certainly visible to the end host, for both the SIP ||signaling and the RTP media -- the end host is sending packets ||to the SBC's IP address and receiving packets from the SBC's ||IP address. || ||-d || || ||> Muthu ||> ||> |-----Original Message----- ||> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On ||> Behalf Of Parthasarathi R (partr) ||> |Sent: Wednesday, March 16, 2011 6:15 PM ||> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); ||> Flemming ||> Andreasen (fandreas); mmusic ||> |Subject: Re: [MMUSIC] Continued WG interest in SDP ||> offer/answerwithmiddleboxes? ||> | ||> |Keith, ||> | ||> |Sorry in case "media" word in my mail mislead you. Dan explains in ||> |another mail thread ||> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) ||> why ||> |SIP ALG is not appropriate and B2BUA is more appropriate for this ||> draft. ||> | ||> | ||> |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly |fits ||> |your definition of B2BUA as it involves only SIP & SDP and media is ||> |defined as middlebox. ||> | ||> |I have mentioned as kind of B2BUA because the draft concentrates on ||> |callflow where one side of B2BUA acts as UAC and other side always ||> acts ||> |as UAS. IMO, the draft currently does not address B2BUA 3PCC |callflows ||> |specific issues. In the current scope of draft is continued for the ||> |draft, the new definition may be required or draft text has to |clarify ||> |the scope. ||> | ||> |Thanks ||> |Partha ||> | ||> |-----Original Message----- ||> |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] ||> |Sent: Wednesday, March 16, 2011 5:33 PM ||> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); ||> |Flemming Andreasen (fandreas); mmusic ||> |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer ||> |withmiddleboxes? ||> | ||> |The only definition of B2BUA that I know of comes in RFC 3261 (sort ||> of) ||> |where the scope is limited to SIP. So a UA acts in one or more ||> |directions as a SIP UA. Whatever else it does is outside the ||> definition. ||> |That I believe matches with what Christer is saying. ||> | ||> |If you want something that defines what it does with media, then you ||> |need something that defines that, but using the term B2BUA to do |that ||> is ||> |probably not the best choice. ||> | ||> |Regards ||> | ||> |Keith ||> | ||> |> -----Original Message----- ||> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On ||> |> Behalf Of Parthasarathi R (partr) ||> |> Sent: 15 March 2011 09:54 ||> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen ||> |> (fandreas); mmusic ||> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer |with ||> |> middleboxes? ||> |> ||> |> Christer, ||> |> ||> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle ||> |> signaling only and it is upto the implementation to decide. Also, ||> this ||> | ||> |> draft does not have restriction that SIP B2BUA and media server |has ||> to ||> | ||> |> be co-exist in the same device. The draft talks about the scenario ||> |> wherein SIP B2BUA communicates with media server using Megaco ||> (H.248). ||> |> ||> |> As I mentioned in other mail thread, ALG does not look appropriate ||> and ||> | ||> |> the draft is talking only about the specific type of B2BUA. In |real ||> |> deployment, Few vendors named these sort of B2BUA as "Session |Border ||> |> Controller or SBC" as well. SBC may not accepted in IETF as SBC |does ||> |> lot more. In case there is a need to have different name for these ||> |> kind of SIP B2BUA entity to avoid the confusion, Let us work it |out. ||> |> ||> |> Thanks ||> |> Partha ||> |> ||> |> -----Original Message----- ||> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On ||> |> Behalf Of Christer Holmberg ||> |> Sent: Tuesday, March 15, 2011 12:14 PM ||> |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' ||> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer |with ||> |> middleboxes? ||> |> ||> |> ||> |> Hi Dan, ||> |> ||> |> In my definition of an ALG packets can be sent directly to its IP ||> |> address. ||> |> ||> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also ||> |> focuses on other things, like media. A SIP ALG contains a SIP |B2BUA. ||> |> ||> |> Regards, ||> |> ||> |> Christer ||> |> ||> |> -----Original Message----- ||> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On ||> |> Behalf Of Dan Wing ||> |> Sent: 15. maaliskuuta 2011 4:39 ||> |> To: 'Flemming Andreasen'; 'mmusic' ||> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer |with ||> |> middleboxes ? ||> |> ||> |> The draft uses the term "SIP ALG", which at least does not fit my ||> |> definition of an ALG. An ALG doesn't have packets sent directly |to ||> |> its IP address; it does its job stealthily without awareness of |one ||> |> (or ||> |> both) of the sessoin endpoints. In contrast, the function |described ||> |> in draft-ietf-mmusic-media-path-middleboxes ||> |> is different -- packets are always sent to the IP address of the |SIP ||> |> "ALG", and packets are sent from the IP address of the SIP "ALG". ||> |> This functionality is most often called a "server" ||> |> or a "proxy" -- not an ALG. ||> |> ||> |> This distinction is important because this draft is closely |related ||> to ||> | ||> |> functions common in NATs, which _do_ sometimes have SIP ALGs ||> |> implemented in them. ||> |> ||> |> So ... can we change "SIP ALG" to something like "SIP proxy" ||> |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it |is ||> a ||> | ||> |> B2BUA, at least as best I understand the definition of a B2BUA, so ||> |> B2BUA seems best. ||> |> ||> |> d ||> |> ||> |> ||> |> > -----Original Message----- ||> |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] |On ||> |> > Behalf Of Flemming Andreasen ||> |> > Sent: Thursday, March 10, 2011 6:15 PM ||> |> > To: mmusic ||> |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer with ||> |> > middleboxes ? ||> |> > ||> |> > We currently have a MMUSIC milestone for "considerations for |using ||> |> > SDP ||> |> ||> |> > offer/answer with middleboxes". The latest draft for this WG |item ||> is ||> |> > ||> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt ||> |> > ||> |> > which expired in January 2011. There hasn't been much discussion ||> on ||> |> > this topic for a while, and the current draft authors are not ||> |> > planning ||> |> ||> |> > continued work on the draft, so we need new authors if we are to ||> |> > continue with this WG item. Please let us know if ||> |> > 1) You are still interested in this deliverable ||> |> > 2) You are willing to actively contribute to and/or author this ||> |> > document. ||> |> > ||> |> > Thanks ||> |> > ||> |> > Flemming & Miguel [MMUSIC chairs] ||> |> > ||> |> > ||> |> > _______________________________________________ ||> |> > 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 ||> |> _______________________________________________ ||> |> 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 ||> |_______________________________________________ ||> |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 petithug@acm.org Thu Mar 31 06:32:12 2011 Return-Path: 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 6A1B428C16A for ; Thu, 31 Mar 2011 06:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.852 X-Spam-Level: X-Spam-Status: No, score=-101.852 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] 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 Od4pvl+ZNXh5 for ; Thu, 31 Mar 2011 06:32:11 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4EFDC3A6AB2 for ; Thu, 31 Mar 2011 06:32:11 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 8801BDBCC04A; Thu, 31 Mar 2011 13:33:50 +0000 (UTC) Received: from [130.129.66.32] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 60645DBCC048; Thu, 31 Mar 2011 13:33:49 +0000 (UTC) Message-ID: <4D9482BB.2020404@acm.org> Date: Thu, 31 Mar 2011 15:33:47 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1 MIME-Version: 1.0 To: Flemming Andreasen References: <4D8B50FB.4030500@acm.org> <4D92F660.9050907@cisco.com> In-Reply-To: <4D92F660.9050907@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media level ice-options attribute 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: , X-List-Received-Date: Thu, 31 Mar 2011 13:32:12 -0000 On 03/30/2011 11:22 AM, Flemming Andreasen wrote: > Hi Marc > > Is there any particular reason why you want to redefine the existing ice-options > attribute rather than defining a new media-level attribute, e.g. "ice-m-options" > that has the semantics you are looking for here ? My main concern is backwards > compatibility and possible semantic confusion, especially once we start > considering interaction with other SDP extensions. That's a possibility, but you still want to require all future new session-level a=ice-options attribute definitions to provide an algorithm to aggregate the media-level a=ice-m-options attributes. Using the same name could help future reviewers. > > Thanks > > -- Flemming > > On 3/24/11 3:11 PM, Marc Petit-Huguenin wrote: >> >> At the suggestions of the chairs, I'll explain here the problem that I will be >> presenting in Prague, so we can discuss it beforehand and make the best of the >> 10 minutes allocated to the presentation. >> >> This problem was discovered when implementing an endpoint supporting >> disaggregated media. draft-loreto-dispatch-disaggregated-media gives a good >> presentation of what disaggregated media is, but to simplify it is when the SIP >> stack is physically separated from the RTP stack, or stacks in this case, each >> with its own ICE implementation. In my case I had audio on one device, with my >> own ICE/RTP stack, and video on a separate device with a proprietary stack. I >> wanted to add ECN support in my RTP stack but I could not signal it in the SDP >> resulting of the merge of the SDP coming from the two RTP stacks because the >> ice-options attribute is supposed to carry this piece of information in a >> session-level only attribute, where in my case only one media was supporting >> ECN. If I added an ice-options at the media level it will be ignored by the >> stack on the other side, if I added it at the session level the other side will >> think that both medias supports ECN. >> >> So this proposal is to change the level from session-only to session *and* >> media. But doing only this creates problems when a stack implementing this >> proposal is used with a legacy stack on the other side. This is why the >> proposal also mandates to define how different ice-options at the media level >> are combined into the session level ice-options. For rtp+ecn, the rules would >> be that the session level attribute is set only if all the medias use the >> rtp+ecn option. >> >> A similar problem exist for the ice-lite option, which is also defined only at >> the session level, when different implementations want to use different values. >> >> Here my proposal is to not change anything, mostly because I do not see how >> media level values can be combined to a media level value that makes sense. On >> the other hand I do not care much about ICE-lite, so there is probably perhaps >> something that I missed. >> >> The slides for the presentation are available here: >> >> http://www.ietf.org/proceedings/80/slides/mmusic-1.pdf >> >> The I-D is available here: >> >> https://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level/ >> -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From gsalguei@cisco.com Thu Mar 31 06:50:28 2011 Return-Path: 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 D769428C175 for ; Thu, 31 Mar 2011 06:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.094 X-Spam-Level: X-Spam-Status: No, score=-10.094 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] 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 m9qCAb3LMVcl for ; Thu, 31 Mar 2011 06:50:27 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id D5B7F28C141 for ; Thu, 31 Mar 2011 06:50:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2VDq3WQ002471; Thu, 31 Mar 2011 09:52:03 -0400 (EDT) Received: from rtp-gsalguei-8719.cisco.com (rtp-gsalguei-8719.cisco.com [10.116.61.58]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2VDq2Ts025847; Thu, 31 Mar 2011 09:52:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-106--997709086 From: Gonzalo Salgueiro In-Reply-To: Date: Thu, 31 Mar 2011 09:52:01 -0400 Message-Id: References: <4D9443CB.7080705@ericsson.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: mmusic Subject: Re: [MMUSIC] IANA registration of the "image" media type in SDP 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: , X-List-Received-Date: Thu, 31 Mar 2011 13:50:29 -0000 --Apple-Mail-106--997709086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Almost a year ago Kevin Fleming and I had this discussion. We ran into = this issue in the course of working with the ITU-T on a SIP Forum FoIP = TG initiated contribution to T.38. When updating references from RFC = 2327 to RFC 4566, we came across the fact that in RFC 2327 the possible = values for the 'media' type are documented as sharing the name space = with the top-level media content types in the MIME (RFC 2048) registry, = whereas in RFC 4566 this statement does not appear. RFC 4566 does = contain language that would appear to include such top-level media = content types as valid 'media' types in SDP, but also establishes a new = SDP-specific 'media' type registry. The MIME top-level media content = registry *does* have a registration for 'image'. As you correctly note, = IANA does not appear to have actually created an SDP media type registry (and populated it with the = values from RFC 4566). As a result of this we intended to write the I-D = for consideration by MMUSIC to register the 'image' media type for SDP. = We'll happily submit this if the group agrees. Regards, Gonzalo On Mar 31, 2011, at 5:14 AM, DRAGE, Keith (Keith) wrote: > I remain to be convinced that there is enough new material on the = table to spin a new version of 4566. I am also unaware of anything major = in interoperability terms that needs to be fixed. In any case, = generation of that version would take well over 12 months, and the IANA = registration does not occur until IESG approval. >=20 > So I would suggest creating a new i-d that defines and registers the = m=3Dimage. This is no different to what has occurred with many attribute = values. >=20 > You can either use this new draft to also create the IANA table, or = follow your proposed path of talking to IANA directly - both should be = possible. >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf >> Of Miguel A. Garcia >> Sent: 31 March 2011 10:05 >> To: mmusic >> Subject: [MMUSIC] IANA registration of the "image" media type in SDP >>=20 >> As a chair >>=20 >> It has been made aware to the chairs that SDP has not registered an >> 'image' media type, meaning that we should not be able to use >> "m=3Dimage..." in SDP. >>=20 >> RFC 4566 intends to create an IANA registry of media types (See = Section >> 8.2.1 in RFC 4566), but while it registers "audio", "video", and = others, >> it does not register "image". This "image" mime type is widely used, = for >> example, for signaling T38 fax, or in the examples in comedia (RFC = 4145). >>=20 >> To add a bit more complication, this registry has never been created, >> even when RFC 4566 creates the registry. See >> http://www.iana.org/assignments/sdp-parameters >>=20 >> Both things (lack of registration of "image" media type and lack of = the >> registry itself) seem to be an oversight, and should be fixed. >>=20 >> In order to solve these issues, the chairs propose the following two >> actions: >>=20 >> - First, let's contact IANA and to find out if they can create the >> registry that RFC 4566 mandates. Note that, as per RFC 4566 this = would >> not register the "image" media type, but all the others indicated in = RFC >> 4566. >>=20 >> - Second, we can open a bug and roll down this registration in a = 4566bis >> draft, that we should be working on to fix other found bugs. >>=20 >> There is an alternative to this second aspect: write a one-page >> Internet-Draft that registers the "image" media type. We think this = might >> be an overkill, considering that we have a bug-fixing revision of = 4566 in >> the pipeline, which could be done as fast as this alternative. And, = we >> have still include the "image" media type in 4566bis. >>=20 >> Your comments are highly appreciated. >>=20 >> Miguel and Flemming >>=20 >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> 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 --Apple-Mail-106--997709086 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I remain to be convinced that there is enough new = material on the table to spin a new version of 4566. I am also unaware = of anything major in interoperability terms that needs to be fixed. In = any case, generation of that version would take well over 12 months, and = the IANA registration does not occur until IESG approval.

So I = would suggest creating a new i-d that defines and registers the m=3Dimage.= This is no different to what has occurred with many attribute = values.

You can either use this new draft to also create the IANA = table, or follow your proposed path of talking to IANA directly - both = should be possible.

Regards

Keith

-----Original Message-----
From: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On Behalf
Of Miguel A. Garcia
Sent: 31 March 2011 10:05
To: mmusic
Subject: [MMUSIC] IANA registration of the "image" media = type in SDP

As a = chair

It has been = made aware to the chairs that SDP has not registered = an
'image' media type, meaning = that we should not be able to use
"m=3Dimage..." in SDP.

RFC 4566 = intends to create an IANA registry of media types (See = Section
8.2.1 in RFC 4566), = but while it registers "audio", "video", and = others,
it does not register = "image". This "image" mime type is widely used, = for
example, for signaling T38 = fax, or in the examples in comedia (RFC = 4145).

To add a bit = more complication, this registry has never been = created,
even when RFC 4566 = creates the registry. See
http://www.iana.or= g/assignments/sdp-parameters

Both things = (lack of registration of "image" media type and lack of = the
registry itself) seem to = be an oversight, and should be fixed.

In order to = solve these issues, the chairs propose the following = two
actions:

- First, let's = contact IANA and to find out if they can create = the
registry that RFC 4566 = mandates. Note that, as per RFC 4566 this = would
not register the "image" = media type, but all the others indicated in = RFC
4566.

- Second, we = can open a bug and roll down this registration in a = 4566bis
draft, that we should = be working on to fix other found bugs.

There is an = alternative to this second aspect: write a = one-page
Internet-Draft that = registers the "image" media type. We think this = might
be an overkill, = considering that we have a bug-fixing revision of 4566 = in
the pipeline, which could = be done as fast as this alternative. And, we
have still include the "image" media type in = 4566bis.

Your comments = are highly appreciated.

=           Miguel and = Flemming

--
Miguel A. = Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.org= /mailman/listinfo/mmusic
_____________________________= __________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

= --Apple-Mail-106--997709086-- From dwing@cisco.com Thu Mar 31 07:11:37 2011 Return-Path: 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 71C803A6B13 for ; Thu, 31 Mar 2011 07:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.367 X-Spam-Level: X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 dv271R9wpywy for ; Thu, 31 Mar 2011 07:11:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 89FA53A6B4A for ; Thu, 31 Mar 2011 07:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=12336; q=dns/txt; s=iport; t=1301580789; x=1302790389; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=zjDVKOP8JwBNCMNsrXwJsl4v5KrLjmoZQ0fI/axqkoc=; b=FfubdrDKLjwsKnjGcoRTFvODmAVRdHmns0RBCCvQROkRQAiX42PMUzcS j9KSZVv2KufOWm3BCQ5XGBCsmWNxHV/OcwHVpVioEiBWL9x4GeqPbnz0q LouFEC6uQZsTDIpl3vn3xxsUEjXtckrvRwG9PoHWmcB1PXutopLVyDVvf 4=; X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208";a="673790079" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2011 14:13:08 +0000 Received: from dwingWS (rtp-vpn6-995.cisco.com [10.82.251.230]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2VED5PL031909; Thu, 31 Mar 2011 14:13:06 GMT From: "Dan Wing" To: "'Muthu ArulMozhi Perumal \(mperumal\)'" , "'Parthasarathi R \(partr\)'" , "'DRAGE, Keith \(Keith\)'" , "'Christer Holmberg'" , "'Flemming Andreasen \(fandreas\)'" , "'mmusic'" References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com> <0e4201cbeebb$f527ea80$df77bf80$@com> <1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com> Date: Thu, 31 Mar 2011 16:13:05 +0200 Message-ID: <00e001cbefad$c21e2fd0$465a8f70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvfka8IjyVdSV50SF6vU/ruI/PbtgDJ16tgAAiwCIAABkTIEAA2qv8gAAFBYCACkKF/oAApGcGAAAXja7AANovukA== Content-Language: en-us Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Thu, 31 Mar 2011 14:11:37 -0000 > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Thursday, March 31, 2011 1:01 PM > To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith); > Christer Holmberg; Flemming Andreasen (fandreas); mmusic > Subject: RE: [MMUSIC] Continued WG interest in SDP > offer/answerwithmiddleboxes? > > I agree with your interpretation of what an SBC is. However, the reason > why I don't find anything wrong in the use of ALG in > draft-ietf-mmusic-media-path-middleboxes is because it describes > firewall and NAT traversal functions that are typically implemented as > ALGs, except that these functions are decoupled into a MIDCOM agent and > a middle box. In addition RFC 3303 goes on to say (section 2.8) that > MIDCOM agents are entities performing ALG functions, logically external > to a middlebox. It even says these agents can reside on a proxy. > Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the ALG > in > Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the draft > I think. If Figure 1 was modified to show a NAT or firewall, it could reasonably use the term ALG with those devices. But when showing an SBC, which is smack in the middle of Figure 1, it cannot accurately call the SBC a "SIP ALG", as it does right now. -d > Muthu > > |-----Original Message----- > |From: Dan Wing (dwing) > |Sent: Wednesday, March 30, 2011 2:52 PM > |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); > 'DRAGE, Keith (Keith)'; 'Christer > |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' > |Subject: RE: [MMUSIC] Continued WG interest in SDP > offer/answerwithmiddleboxes? > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > |> Sent: Tuesday, March 29, 2011 3:58 PM > |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer > Holmberg; > |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic > |> Subject: RE: [MMUSIC] Continued WG interest in SDP > |> offer/answerwithmiddleboxes? > |> > |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is just > an > |> extension of RFC 3303 -- while the later describes the middlebox > |> communication architecture and framework, the former describes some > of > |> the desirable behaviors of these middleboxes and protocols that > operate > |> on the media path unspecified in the later. RFC 3303 defines what > an > |> ALG is and it doesn't forbid packets being addressed to the ALG at > the > |> IP layer. > |> > |> > |> 2.6. ALG > |> Application Level Gateways (ALGs) are entities that possess the > |> application specific intelligence and knowledge of an associated > |> middlebox function. An ALG examines application traffic in transit > |> and assists the middlebox in carrying out its function. > |> > |> ALGs are different from proxies. ALGs are not visible to end-hosts, > |> unlike the proxies which are relay agents terminating sessions with > |> both end-hosts. ALGs do not terminate sessions with either end- > host. > |> Instead, ALGs examine, and optionally modify, application payload > |> content to facilitate the flow of application traffic through a > |> middlebox. > |> > |> 2.8. MIDCOM Agents > |> MIDCOM agents are entities performing ALG functions, logically > |> external to a middlebox. > |> > |> The packets may be addressed to the agent node at the IP layer. > |> Alternatively they may not be addressed to the agent node, but may > be > |> constrained by other factors to flow through it. > |> > |> > |> So, I don't see anything wrong in the use of ALG in > |> draft-ietf-mmusic-media-path-middleboxes, unless we plan to make > |> changes > |> to how RFC 3303 describes it. > | > |3303 is quite clear, in exactly the text you quoted in the paragraph > |starting with "ALGs are different from proxies", that ALGs aren't > |visible to hosts and ALGs don't terminate sessions. > | > |An SBC is certainly visible to the end host, for both the SIP > |signaling and the RTP media -- the end host is sending packets > |to the SBC's IP address and receiving packets from the SBC's > |IP address. > | > |-d > | > | > |> Muthu > |> > |> |-----Original Message----- > |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> Behalf Of Parthasarathi R (partr) > |> |Sent: Wednesday, March 16, 2011 6:15 PM > |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); > |> Flemming > |> Andreasen (fandreas); mmusic > |> |Subject: Re: [MMUSIC] Continued WG interest in SDP > |> offer/answerwithmiddleboxes? > |> | > |> |Keith, > |> | > |> |Sorry in case "media" word in my mail mislead you. Dan explains in > |> |another mail thread > |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) > |> why > |> |SIP ALG is not appropriate and B2BUA is more appropriate for this > |> draft. > |> | > |> | > |> |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly > fits > |> |your definition of B2BUA as it involves only SIP & SDP and media is > |> |defined as middlebox. > |> | > |> |I have mentioned as kind of B2BUA because the draft concentrates on > |> |callflow where one side of B2BUA acts as UAC and other side always > |> acts > |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC > callflows > |> |specific issues. In the current scope of draft is continued for the > |> |draft, the new definition may be required or draft text has to > clarify > |> |the scope. > |> | > |> |Thanks > |> |Partha > |> | > |> |-----Original Message----- > |> |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > |> |Sent: Wednesday, March 16, 2011 5:33 PM > |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); > |> |Flemming Andreasen (fandreas); mmusic > |> |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer > |> |withmiddleboxes? > |> | > |> |The only definition of B2BUA that I know of comes in RFC 3261 (sort > |> of) > |> |where the scope is limited to SIP. So a UA acts in one or more > |> |directions as a SIP UA. Whatever else it does is outside the > |> definition. > |> |That I believe matches with what Christer is saying. > |> | > |> |If you want something that defines what it does with media, then > you > |> |need something that defines that, but using the term B2BUA to do > that > |> is > |> |probably not the best choice. > |> | > |> |Regards > |> | > |> |Keith > |> | > |> |> -----Original Message----- > |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> |> Behalf Of Parthasarathi R (partr) > |> |> Sent: 15 March 2011 09:54 > |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen > |> |> (fandreas); mmusic > |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer > with > |> |> middleboxes? > |> |> > |> |> Christer, > |> |> > |> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle > |> |> signaling only and it is upto the implementation to decide. Also, > |> this > |> | > |> |> draft does not have restriction that SIP B2BUA and media server > has > |> to > |> | > |> |> be co-exist in the same device. The draft talks about the > scenario > |> |> wherein SIP B2BUA communicates with media server using Megaco > |> (H.248). > |> |> > |> |> As I mentioned in other mail thread, ALG does not look > appropriate > |> and > |> | > |> |> the draft is talking only about the specific type of B2BUA. In > real > |> |> deployment, Few vendors named these sort of B2BUA as "Session > Border > |> |> Controller or SBC" as well. SBC may not accepted in IETF as SBC > does > |> |> lot more. In case there is a need to have different name for > these > |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work it > out. > |> |> > |> |> Thanks > |> |> Partha > |> |> > |> |> -----Original Message----- > |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> |> Behalf Of Christer Holmberg > |> |> Sent: Tuesday, March 15, 2011 12:14 PM > |> |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' > |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer > with > |> |> middleboxes? > |> |> > |> |> > |> |> Hi Dan, > |> |> > |> |> In my definition of an ALG packets can be sent directly to its IP > |> |> address. > |> |> > |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also > |> |> focuses on other things, like media. A SIP ALG contains a SIP > B2BUA. > |> |> > |> |> Regards, > |> |> > |> |> Christer > |> |> > |> |> -----Original Message----- > |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > |> |> Behalf Of Dan Wing > |> |> Sent: 15. maaliskuuta 2011 4:39 > |> |> To: 'Flemming Andreasen'; 'mmusic' > |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer > with > |> |> middleboxes ? > |> |> > |> |> The draft uses the term "SIP ALG", which at least does not fit my > |> |> definition of an ALG. An ALG doesn't have packets sent directly > to > |> |> its IP address; it does its job stealthily without awareness of > one > |> |> (or > |> |> both) of the sessoin endpoints. In contrast, the function > described > |> |> in draft-ietf-mmusic-media-path-middleboxes > |> |> is different -- packets are always sent to the IP address of the > SIP > |> |> "ALG", and packets are sent from the IP address of the SIP "ALG". > |> |> This functionality is most often called a "server" > |> |> or a "proxy" -- not an ALG. > |> |> > |> |> This distinction is important because this draft is closely > related > |> to > |> | > |> |> functions common in NATs, which _do_ sometimes have SIP ALGs > |> |> implemented in them. > |> |> > |> |> So ... can we change "SIP ALG" to something like "SIP proxy" > |> |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it > is > |> a > |> | > |> |> B2BUA, at least as best I understand the definition of a B2BUA, > so > |> |> B2BUA seems best. > |> |> > |> |> d > |> |> > |> |> > |> |> > -----Original Message----- > |> |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > On > |> |> > Behalf Of Flemming Andreasen > |> |> > Sent: Thursday, March 10, 2011 6:15 PM > |> |> > To: mmusic > |> |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer > with > |> |> > middleboxes ? > |> |> > > |> |> > We currently have a MMUSIC milestone for "considerations for > using > |> |> > SDP > |> |> > |> |> > offer/answer with middleboxes". The latest draft for this WG > item > |> is > |> |> > > |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt > |> |> > > |> |> > which expired in January 2011. There hasn't been much > discussion > |> on > |> |> > this topic for a while, and the current draft authors are not > |> |> > planning > |> |> > |> |> > continued work on the draft, so we need new authors if we are > to > |> |> > continue with this WG item. Please let us know if > |> |> > 1) You are still interested in this deliverable > |> |> > 2) You are willing to actively contribute to and/or author this > |> |> > document. > |> |> > > |> |> > Thanks > |> |> > > |> |> > Flemming & Miguel [MMUSIC chairs] > |> |> > > |> |> > > |> |> > _______________________________________________ > |> |> > 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 > |> |> _______________________________________________ > |> |> 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 > |> |_______________________________________________ > |> |mmusic mailing list > |> |mmusic@ietf.org > |> |https://www.ietf.org/mailman/listinfo/mmusic From Simo.Veikkolainen@nokia.com Thu Mar 31 09:03:18 2011 Return-Path: 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 BABF53A6A63 for ; Thu, 31 Mar 2011 09:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yhvLLe9Bq5PQ for ; Thu, 31 Mar 2011 09:03:08 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 0AAA23A6B10 for ; Thu, 31 Mar 2011 09:03:07 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2VG4Qe5002949; Thu, 31 Mar 2011 19:04:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 19:04:33 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 31 Mar 2011 18:04:32 +0200 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Thu, 31 Mar 2011 18:04:21 +0200 From: To: Thread-Topic: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 Thread-Index: AQHL6jYAzdzkv+kSJEq7hvaWKJy7xJQ92lEAgAShgpCAAkdbAIAC3Xnw Date: Thu, 31 Mar 2011 16:04:21 +0000 Message-ID: References: <4D8B5F7E.5070204@cisco.com> <4D8C7C58.4090306@ericsson.com> <4D92563C.100@cisco.com> In-Reply-To: <4D92563C.100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.181.160.186] Content-Type: multipart/alternative; boundary="_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BE3BD008AM1MPN1002mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2011 16:04:33.0415 (UTC) FILETIME=[5336D170:01CBEFBD] X-Nokia-AV: Clean Cc: pkyzivat@cisco.com, mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 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: , X-List-Received-Date: Thu, 31 Mar 2011 16:03:18 -0000 --_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BE3BD008AM1MPN1002mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Flemming, and thank you again for your review. See below. From: ext Flemming Andreasen [mailto:fandreas@cisco.com] Sent: 30 March, 2011 00:59 To: Veikkolainen Simo (Nokia-MS/Helsinki) Cc: mmusic@ietf.org; Paul Kyzivat (pkyzivat); Flemming Andreasen Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06 Hi Simo and Miguel I have taken a closer look at the document and have some comments: Section 5.2.1 - How are dynamic payload types handled ? - How will "-" work with offer/answer (as Paul noted as well) [SV] I think we need to think of the media types (including the "-" from a = broader perspective. In most cases, it is enough to just exchange the E.164= numbers without any media related information. Section 5.2.3 - s/should not/MUST NOT Section 5.2.3.1 - What's the specification policy for providing new correlation mechanisms = and do we need an IANA registry ? - Informal grammer here suggests you can specify only one of the mechanisms= . It is claried later that multiple can be specified (confusing here) [SV] We need to explicitly say what the mechanism for providing new correla= tion mechanisms will be. IANA registration is definitely one option, even t= hough the current draft does not propose to register the correlation mechan= isms at IANA. [SV] Multiple mechanisms are allowed. We need to change the information gra= mmar. Section 5.2.3.2 (and other places) - Why not simply require the E.164 numbers always be specified in their ful= l International form (i.e. with country code). While that makes the "+" red= undant, it's still good to include it per E.164/E.123 [SV] That could be done, if the endpoints just are always aware of their in= ternational E.164 representation. - The "callerid" subfield is specified as being that of the party inserting= it. That raises some security concerns that need to be discussed. It would= also seem to prevent use of the mechanism with 3PCC, which I don't believe= is intended. [SV] We need to address this in the security considerations section. Section 5.3 - As Paul noted, the O/A section overall needs to be expanded to describe t= he entire Offer generation, Answer generation, Offer processing of initial = answer, and Modifying the Session (one section for each ala RFC 3264 prefer= ably). The "setup", "connection", "c=3D", and "m=3D" lines, etc all need to= be described [SV] Right, this is what we intend to do. - Lots of SHOULDs that seem like they should be MUSTs. If keeping them as S= HOULDs, then we should be clear on why that is (including in the document). [SV] Ok, we'll go these through. - I am confused on how the cs-correlation mechanism works. I would have tho= ught the "calling" (active) party would send correlation info to the called= (passive) party, but the O/A section seems to suggest that the calling (ac= tive) party gets the called (passive) party's correlation info and sends th= at to the called (passive) party somehow (spoofed caller-id ?). Did I misre= ad this ? [SV] Cs-correlation is the name of the attribute carrying the actual correl= ation mechanisms used. The relationship between the O/A and active/passive = party is a bit complicated and requires probably some clarification. In the= case of caller-id correlation mechanism, for example, the calling (active)= party needs to know the E.164 number of the called (passive) party. Theref= ore, the called party needs to return the E.164 number in the Answer (typic= ally). Section 5.5 - Would suggest making "+" mandatory in all telephone numbers and stick to = International E.164 format. - Should restrict caller-id-value to 15 digits I believe. [SV] Ok. Section 6 - Example should be complete and show the answer SDP and resulting PSTN exc= hange (correlation part). The correlation info text seems counter to what t= he O/A section says, but again, I'm confused on the text in this area in ge= neral. [SV] We'll need to clarify this. Section 7 - Should move IANA Considerations to after Security Considerations [SV] Ok. Section 8 - Additional security considerations include risks associating with using u= nverified information as caller-id. More importantly, you are introducing a= mechanism that causes your peer to initiate a call to a phone number of yo= ur choosing, and the security risks associated with that needs to be called= out. [SV] Ok, will expand the security considerations section on these. Thanks Simo Thanks -- Flemming On 3/28/11 11:24 AM, Simo.Veikkolainen@nokia.com wrote: Hello, These are pretty much the only open issues we know of for this document. If= others have any concerns, it would be great if you could post them on the = list before Friday. Thanks Simo > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 25 March, 2011 13:28 > To: Paul Kyzivat > Cc: Veikkolainen Simo (Nokia-MS/Helsinki); IETF MMUSIC WG > Subject: Re: draft-ietf-mmusic-sdp-cs-06 > > Hi Paul, > > Thanks for your comments. See inline answers. > > On 24/03/2011 16:13, Paul Kyzivat wrote: > > I have a couple of comments on this draft: > > > > There is still work to do to extend the o/a rules to handle '-' as a > > media format. Specifically, if the offer contains '-', what may the > > answer contain? And if the offer does not contain '-', may the > answer? > > For sure, I agree. I think the information must be hidden or implicitly > described, but this should be explicitly specified. At the moment the > draft has O/A procedures for negotiating the correlation mechanism > (Section 5.3). I think we should just have a more generic O/A > procedures > that discuss the whole draft, not only the correlation mechanism. > > > > > > When using uuie correlation, the uuie-value is defined as > > 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a > discriminator > > byte that can be any one of 256 values. The draft doesn't mention if > the > > uuie-value contains the discriminator byte, or if that byte is > assumed > > to have some well known value. If it is to include the discriminator > > byte, then some important discriminator byte values are neither alpha > > nor digit. IMO the draft at least needs to explain what is intended. > > Problem acknowledged. We need to take a look at it and provide a > solution. > > BR, > > Miguel > > > > > > Thanks, > > Paul > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BE3BD008AM1MPN1002mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06

Hi Flemming, and thank yo= u again for your review.

 <= /p>

See below.

 <= /p>

 <= /p>

From: ext Flemming Andreasen [mailto:fandreas@cisco.com= ]
Sent: 30 March, 2011 00:59
To: Veikkolainen Simo (Nokia-MS/Helsinki)
Cc: mmusic@ietf.org; Paul Kyzivat (pkyzivat); Flemming Andreasen
Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06<= /p>

 

Hi Simo and Miguel

I have taken a closer look at the document and have some comments:

Section 5.2.1
- How are dynamic payload types handled ?
- How will "-" work with offer/answer (as Paul noted as well)

[SV] I think we need to t= hink of the media types (including the “-“ from a broader persp= ective. In most cases, it is enough to just exchange the E.164 numbers without any media related information.

 <= /p>


Section 5.2.3
- s/should not/MUST NOT

Section 5.2.3.1
- What's the specification policy for providing new correlation mechanisms = and do we need an IANA registry ?
- Informal grammer here suggests you can specify only one of the mechanisms= . It is claried later that multiple can be specified (confusing here)

 <= /p>

[SV] We need to explicitl= y say what the mechanism for providing new correlation mechanisms will be. = IANA registration is definitely one option, even though the current draft does not propose to register the correlation mechanisms = at IANA.

 <= /p>

[SV] Multiple mechanisms = are allowed. We need to change the information grammar.



Section 5.2.3.2 (and other places)
- Why not simply require the E.164 numbers always be specified in their ful= l International form (i.e. with country code). While that makes the "&= #43;" redundant, it's still good to include it per E.164/E.123

 <= /p>

[SV] That could be done, = if the endpoints just are always aware of their international E.164 represe= ntation.


- The "callerid" subfield is specified as being that of the party= inserting it. That raises some security concerns that need to be discussed= . It would also seem to prevent use of the mechanism with 3PCC, which I don= 't believe is intended.

 <= /p>

[SV] We need to address t= his in the security considerations section.


Section 5.3
- As Paul noted, the O/A section overall needs to be expanded to describe t= he entire Offer generation, Answer generation, Offer processing of initial = answer, and Modifying the Session (one section for each ala RFC 3264 prefer= ably). The "setup", "connection", "c=3D", and "m=3D" lines, etc all need to be described=

 <= /p>

[SV] Right, this is what = we intend to do.


- Lots of SHOULDs that seem like they should be MUSTs. If keeping them as S= HOULDs, then we should be clear on why that is (including in the document).

 <= /p>

[SV] Ok, we’ll go t= hese through.


- I am confused on how the cs-correlation mechanism works. I would have tho= ught the "calling" (active) party would send correlation info to = the called (passive) party, but the O/A section seems to suggest that the c= alling (active) party gets the called (passive) party's correlation info and sends that to the called (passive) party some= how (spoofed caller-id ?). Did I misread this ?

[SV] Cs-correlation is th= e name of the attribute carrying the actual correlation mechanisms used. Th= e relationship between the O/A and active/passive party is a bit complicated and requires probably some clarification. In the case= of caller-id correlation mechanism, for example, the calling (active) part= y needs to know the E.164 number of the called (passive) party. Therefore, = the called party needs to return the E.164 number in the Answer (typically).


Section 5.5
- Would suggest making "+" mandatory in all telephone numbers= and stick to International E.164 format.
- Should restrict caller-id-value to 15 digits I believe.

[SV] Ok.


Section 6
- Example should be complete and show the answer SDP and resulting PSTN exc= hange (correlation part). The correlation info text seems counter to what t= he O/A section says, but again, I'm confused on the text in this area in ge= neral.

 <= /p>

[SV] We’ll need to = clarify this.

 <= /p>


Section 7
- Should move IANA Considerations to after Security Considerations

[SV] Ok.


Section 8
- Additional security considerations include risks associating with using u= nverified information as caller-id. More importantly, you are introducing a= mechanism that causes your peer to initiate a call to a phone number of yo= ur choosing, and the security risks associated with that needs to be called out.

[SV] Ok, will expand the = security considerations section on these.

 <= /p>

Thanks<= /p>

Simo


Thanks

-- Flemming



On 3/28/11 11:24 AM, Simo.Ve= ikkolainen@nokia.com wrote:

Hello,
These are pretty much the only open issues we know of for this document. If= others have any concerns, it would be great if you could post them on the = list before Friday.

Thanks
Simo


> -----Original Message-----
> From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: 25 March, 2011 13:28
> To: Paul Kyzivat
> Cc: Veikkolainen Simo (Nokia-MS/Helsinki); IETF MMUSIC WG
> Subject: Re: draft-ietf-mmusic-sdp-cs-06
>
> Hi Paul,
>
> Thanks for your comments. See inline answers.
>
> On 24/03/2011 16:13, Paul Kyzivat wrote:
> > I have a couple of comments on this draft:
> >
> > There is still work to do to extend the o/a rules to handle '-' a= s a
> > media format. Specifically, if the offer contains '-', what may t= he
> > answer contain? And if the offer does not contain '-', may the > answer?
>
> For sure, I agree. I think the information must be hidden or implicitl= y
> described, but this should be explicitly specified. At the moment the<= br> > draft has O/A procedures for negotiating the correlation mechanism
> (Section 5.3). I think we should just have a more generic O/A
> procedures
> that discuss the whole draft, not only the correlation mechanism.
>
>
> >
> > When using uuie correlation, the uuie-value is defined as
> > 1*32(ALPHA/DIGIT). The PSTN user-user data starts with a
> discriminator
> > byte that can be any one of 256 values. The draft doesn't mention= if
> the
> > uuie-value contains the discriminator byte, or if that byte is > assumed
> > to have some well known value. If it is to include the discrimina= tor
> > byte, then some important discriminator byte values are neither a= lpha
> > nor digit. IMO the draft at least needs to explain what is intend= ed.
>
> Problem acknowledged. We need to take a look at it and provide a
> solution.
>
> BR,
>
>       Miguel
>
>
> >
> >     Thanks,
> >     Paul
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

--_000_F9E2FDAF48D4544F874A56A3A8BD68B1010BE3BD008AM1MPN1002mg_-- From jonathan@vidyo.com Thu Mar 31 11:05:17 2011 Return-Path: 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 C358C3A6AA0 for ; Thu, 31 Mar 2011 11:05:17 -0700 (PDT) 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 HZbLfr43wyJu for ; Thu, 31 Mar 2011 11:05:13 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 9670C3A69FC for ; Thu, 31 Mar 2011 11:05:13 -0700 (PDT) Received: from st21.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id BD3D5553B68 for ; Thu, 31 Mar 2011 14:06:52 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id DA2B7553B22 for ; Thu, 31 Mar 2011 14:06:51 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 31 Mar 2011 14:05:56 -0400 From: Jonathan Lennox To: "mmusic@ietf.org" Date: Thu, 31 Mar 2011 14:06:49 -0400 Thread-Topic: Review of ice-tcp-10 Thread-Index: AcvvzlAlLwilAxudQAOHSpnkrqbpqA== Message-ID: <7B899E65-EFF9-4259-88DF-B926D8BDF5A6@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Review of ice-tcp-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: , X-List-Received-Date: Thu, 31 Mar 2011 18:05:17 -0000 I've reveiwed ice-tcp-10 -- better late than never, I suppose. In general, this document seems very solid, and in my opinion is ready for = WGLC; I have only a few minor technical quibbles and suggestions, plus a fe= w editorial comments. Section 10.1: Next, the sender checks to see if the resulting set of bytes would be viewed as a STUN packet based on the rules in Sections 6 and 8 of [RFC5389]. This includes a check on the most significant two bits, the magic cookie, the length, and the fingerprint. If, based on those rules, the bytes would be viewed as a STUN message, the sender SHOULD utilize a different number of bytes so that the length checks will fail. I think this needs to be MUST -- under what circumstances would a sender wa= nt to insert false-positive STUN packets in the stream? (Of course, depending on the content, it's possible that the sender knows a= priori that there can be no false positives, for instance if it's sending = a 7-bit-ASCII protocol.) I'd also suggest adding a suggestion: "One possible adjustment is to split = the payload in two after its sixth byte. The seventh byte of a STUN packet,= the hexadecimal A4 from the magic cookie, begins with the bits 1 0, so nei= ther the first split payload (which is too short) nor the second one (which= begins with the wrong bits) could falsely appear to be a STUN packet." Wo= rdsmithing, or alternate simple suggestions, welcome. I'd also suggest that a sender MAY pre-emptively adjust any payload that ma= tches a subset of these checks, e.g. just the significant bits, length, and= magic cookie, if it wishes to avoid calculating fingerprints over the data= it's sending. For section 5.2, Server Reflexive Candidates (and also the prioritization f= ormulas): Unless I'm missing something, Server Reflexive Candidates are only possible= and useful for Simultaneous-Open connections, not Active or Passive? Eith= er this should be pointed out, or there should be an explanation of how you= 'd create, and how you'd make use of, Server-Reflexive Active or Passive ca= ndidates. For section 5.3, UDP-Tunneled Candidates: When UDP tunneling is done by your operating system (as is the case with Te= redo on Microsoft Windows), it may not be obvious based on the system APIs = that a given candidate is in fact a UDP-tunneled candidate and not a host c= andidate. If there is a need to give UDP-tunneled candidates a lower type-= preference, it should be pointed out that implementations will need to dete= ct local pseudo-interfaces that are actually UDP tunnels. There's also the complexity that Teredo candidates may, in fact, end up bei= ng Relayed candidates, when matched up with non-Teredo IPv6 addresses. Han= dling this (and de-prioritizing the pairs) based on the normal rules of ICE= would be very difficult, however, other than by unilateral action of the c= ontrolling endpoint. Neither of these issues are specific to ICE-TCP, other than the fact that U= DP-Tunneled candidates weren't mentioned in the original ICE. Editorial: Section 10.1: For media streams that are not RTP-based and do not normally use RFC 4571, the agent treats the media stream as a byte stream, and assumes that it has its own framing of some sort. =20 This is an extreme quibble, but conceivably you could have a higher-level b= yte stream with no framing whatsoever (e.g. dumb file transfer over SIP: op= en a media stream, dump a file, close the stream). It doesn't change anyth= ing about this protocol, though. Section 4.5: Since an ICE ICE offerer always uses an active candidate as default, an ICE ICE answerer will always use a passive candidate as default and include the a=3Dsetup:passive attribute in the answer. "ICE" is repeated, twice. -- Jonathan Lennox jonathan@vidyo.com From jonathan@vidyo.com Thu Mar 31 11:57:24 2011 Return-Path: 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 532CB3A6B7C for ; Thu, 31 Mar 2011 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 S9GdPYvcjQ9m for ; Thu, 31 Mar 2011 11:57:23 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 5F79B3A6B84 for ; Thu, 31 Mar 2011 11:57:23 -0700 (PDT) Received: from st20.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 15AF58BD247; Thu, 31 Mar 2011 14:59:03 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.myoutlookonline.com (Postfix) with ESMTPS id 8A3C28BDA8E; Thu, 31 Mar 2011 14:59:02 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Thu, 31 Mar 2011 14:58:12 -0400 From: Jonathan Lennox To: Gorry Fairhurst Date: Thu, 31 Mar 2011 14:58:42 -0400 Thread-Topic: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.txt Thread-Index: Acvv1ZqCxP6x/cBrSoKNWD2g3vkluA== Message-ID: <4BFFA86F-D5E8-477A-BE11-8A4A6E88389B@vidyo.com> References: <4D933186.2030804@erg.abdn.ac.uk> In-Reply-To: <4D933186.2030804@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pasi Sarolahti , "mmusic@ietf.org" Subject: Re: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.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: , X-List-Received-Date: Thu, 31 Mar 2011 18:57:24 -0000 On Mar 30, 2011, at 3:35 PM, Gorry Fairhurst wrote: > draft-ietf-dccp-udpencap-07.txt >=20 > We have a short presentation for the MMUSIC meeting on Friday on the=20 > above draft. The draft defines support for a UDP Encapsulation for NAPT=20 > traversal. >=20 > This draft has completed DCCP WGLC, and had one hanging issue that=20 > needed to be resolved, concerning the way it updates SDP for DCCP [RFC576= 2]. >=20 > The basic questions are: >=20 > Is there an "easy" way to define SDP that would also allow it to be used= =20 > on a UDP host that doesn't allow native DCCP? >=20 > - How do you signal a server that supports both native and=20 > UDP-encapsulated DCCP? Unfortunately, I think the answer to both these questions is probably ICE, = with new ICE candidate types both for IP-layer DCCP and for DCCP-in-UDP. On the plus side, this would also allow an alternative RTP-in-DCCP/RTP-in-U= DP offer, which seems like it would greatly improve the possibility of an e= volutionary transition to using DCCP. Supporting ICE for DCCP-UDP would also allow it to use ICE's full suite of = connectivity establishment, thus allowing DCCP connections where both peers= are behind NATs (for reasonably friendly NATs, or using TURN). > The options described in the slides are illustrated by two examples: >=20 > Signalling that uses a new proto in SDP m=3D line to indicate DCCP, plus > the SDP connection-oriented media extensions [RFC 4145], as per current > draft. >=20 > m=3Dvideo 5004 DCCP/RTP/AVP 99 [omitted...] > a=3Ddccp-in-udp:9999 This will fail for any existing systems that support RFC5762 DCCP/RTP/AVP, = since in SDP unknown parameters are ignored. > or a new m=3D proto value. > m=3Dvideo 5004 DCCP-UDP/RTP/AVP 99 > a=3Ddccp-udp-port:9999 This seems better, though I'd name it UDP/DCCP/RTP/AVP following existing p= roto stacking practice. -- Jonathan Lennox jonathan@vidyo.com From fandreas@cisco.com Thu Mar 31 13:35:44 2011 Return-Path: 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 70A7B3A6BA1 for ; Thu, 31 Mar 2011 13:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] 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 BOKz925turJ8 for ; Thu, 31 Mar 2011 13:35:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D32A23A6AA4 for ; Thu, 31 Mar 2011 13:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=9151; q=dns/txt; s=iport; t=1301603843; x=1302813443; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=PNqV7Wr/81NpCnVFXg8obk1fadk9dCEShOFMpiyGZ/E=; b=Oc3B5fNmEj4Xd9SjPO+2KEUOuMlAIQmsleJ2BSwlEfCXqX82prNrIS4t 5RFWsVRHwEHqFIHy7CVpDYrtuA4CYJ8bDp3oAJR9BQcRCt/Z8zlQ0X+Qo K1Pr722CDuuy+T2pa62Yw0LD9bHp2vXW1vxw570y/rYAbQq80AEIJKGwT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIzllE2rRDoH/2dsb2JhbAClVneIeZsInDmFawSNEYxf X-IronPort-AV: E=Sophos;i="4.63,278,1299456000"; d="scan'208,217";a="421906445" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2011 20:37:12 +0000 Received: from dhcp-42c5.meeting.ietf.org ([10.21.168.8]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2VKb9BX028206; Thu, 31 Mar 2011 20:37:09 GMT Message-ID: <4D94E5F6.90004@cisco.com> Date: Thu, 31 Mar 2011 22:37:10 +0200 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Gorry Fairhurst References: <4D933186.2030804@erg.abdn.ac.uk> In-Reply-To: <4D933186.2030804@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------050803070902090804030500" Cc: Pasi Sarolahti , mmusic@ietf.org Subject: Re: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.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: , X-List-Received-Date: Thu, 31 Mar 2011 20:35:44 -0000 This is a multi-part message in MIME format. --------------050803070902090804030500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I have taken a look at the draft and have some general comments, and then answers to your questions below subsequently: - Having ICE left for further work when the mechanism is intended to allow for NAT traversal does not seem like a good idea. As the draft itself notes, the current solution only works for some NAT scenarios. Furthermore, the current proposal will most likely lead to problems (inconsistencies at the very least) if you were to add ICE support later on. I think we need to tackle the ICE issue now to ensure a complete and consistent design and solution. - The "m=" line is what provides the transport protocol in SDP, and we should stick with that. This would enable us to use SDP Capability Negotiation (RFC 5939) to negotiate between different transports (like DCCP-STD and DCCP-UDP). It will also avoid some NAT traversal/ICE issues by keeping the port number to the "m=" line (and hence allow us to use normal ICE procedures). DTLS-SRTP (RFC 5764) for example is illustrative here and would suggest we use something like UDP/DCCP/.... for DCCP-UDP and simply stick with DCCP/... for DCCP-STD. - We should stick with standard comedia operation (RFC 4145). The offending part here is the current semantics for the proposed "dccp-in-udp" attribute which says that its presence indicates that the offerer is listening for DCCP-UDP connections. This issue goes away if we follow the above proposal, and hence get rid of the "dccp-in-udp" attribute. More below On 3/30/11 3:35 PM, Gorry Fairhurst wrote: > > draft-ietf-dccp-udpencap-07.txt > > We have a short presentation for the MMUSIC meeting on Friday on the > above draft. The draft defines support for a UDP Encapsulation for NAPT > traversal. > > This draft has completed DCCP WGLC, and had one hanging issue that > needed to be resolved, concerning the way it updates SDP for DCCP > [RFC5762]. > > The basic questions are: > > Is there an "easy" way to define SDP that would also allow it to be used > on a UDP host that doesn't allow native DCCP? > Yes - define a "UDP/DCCP/...." transport. > > - How do you signal a server that supports both native and > UDP-encapsulated DCCP? > Use SDP Capability Negotiation (RFC 5939) > > > - In the build-up to Friday's meeting, we'd really welcome discussion to > help progress this. > > The options described in the slides are illustrated by two examples: > > Signalling that uses a new proto in SDP m= line to indicate DCCP, plus > the SDP connection-oriented media extensions [RFC 4145], as per current > draft. > > v=0 > o=alice 1129377363 1 IN IP4 192.0.2.47 > s=- > c=IN IP4 192.0.2.47 > t=0 0 > m=video 5004 DCCP/RTP/AVP 99 > a=rtcp-mux > a=rtpmap:99 h261/90000 > a=dccp-service-code:SC=x5254505 > a=dccp-in-udp:9999 > a=setup:passive > a=connection:new > > or a new m= proto value. > > v=0 > o=alice 1129377363 1 IN IP4 192.0.2.47 > s=- > c=IN IP4 192.0.2.47 > t=0 0 > m=video 5004 DCCP-UDP/RTP/AVP 99 > a=rtcp-mux > a=rtpmap:99 h261/90000 > a=dccp-service-code:SC=x52545056 > a=setup:passive > a=connection:new > a=dccp-udp-port:9999 > I'd suggest a new proto value and use "UDP/DCCP/..." for consistency with other transports. Thanks -- Flemming > > > Please see the slides/draft for details: > http://www.ietf.org/proceedings/80/slides/mmusic-8.pdf > > > Best wishes, > > Gorry & Colin > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------050803070902090804030500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

I have taken a look at the draft and have some general comments, and then answers to your questions below subsequently:

- Having ICE left for further work when the mechanism is intended to allow for NAT traversal does not seem like a good idea. As the draft itself notes, the current solution only works for some NAT scenarios. Furthermore, the current proposal will most likely lead to problems (inconsistencies at the very least) if you were to add ICE support later on. I think we need to tackle the ICE issue now to ensure a complete and consistent design and solution.

- The "m=" line is what provides the transport protocol in SDP, and we should stick with that. This would enable us to use SDP Capability Negotiation (RFC 5939) to negotiate between different transports (like DCCP-STD and DCCP-UDP). It will also avoid some NAT traversal/ICE issues by keeping the port number to the "m=" line (and hence allow us to use normal ICE procedures). DTLS-SRTP (RFC 5764) for example is illustrative here and would suggest we use something like UDP/DCCP/.... for DCCP-UDP and simply stick with DCCP/... for DCCP-STD.

- We should stick with standard comedia operation (RFC 4145). The offending part here is the current semantics for the proposed "dccp-in-udp" attribute which says that its presence indicates that the offerer is listening for DCCP-UDP connections. This issue goes away if we follow the above proposal, and hence get rid of the "dccp-in-udp" attribute.

More below


On 3/30/11 3:35 PM, Gorry Fairhurst wrote:
[MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.txt

draft-ietf-dccp-udpencap-07.txt

We have a short presentation for the MMUSIC meeting on Friday on the
above draft. The draft defines support for a UDP Encapsulation for NAPT
traversal.

This draft has completed DCCP WGLC, and had one hanging issue that
needed to be resolved, concerning the way it updates SDP for DCCP [RFC5762].

The basic questions are:

Is there an "easy" way to define SDP that would also allow it to be used
on a UDP host that doesn't allow native DCCP?

Yes - define a "UDP/DCCP/...." transport.


- How do you signal a server that supports both native and
UDP-encapsulated DCCP?

Use SDP Capability Negotiation (RFC 5939)


- In the build-up to Friday's meeting, we'd really welcome discussion to
help  progress this.

The options described in the slides are illustrated by two examples:

Signalling that uses a new proto in SDP m= line to indicate DCCP, plus
the SDP connection-oriented media extensions [RFC 4145], as per current
draft.

v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x5254505
a=dccp-in-udp:9999
a=setup:passive
a=connection:new


or a new m= proto value.

v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP-UDP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:new
a=dccp-udp-port:9999

I'd suggest a new proto value and use "UDP/DCCP/..." for consistency with other transports.

Thanks

-- Flemming


Please see the slides/draft for details:
http://www.ietf.org/proceedings/80/slides/mmusic-8.pdf


Best wishes,

Gorry & Colin
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------050803070902090804030500-- From jonathan@vidyo.com Thu Mar 31 13:59:37 2011 Return-Path: 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 1E0DA28C0DE for ; Thu, 31 Mar 2011 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 PtyoAY9Pnp64 for ; Thu, 31 Mar 2011 13:59:36 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 8B45A3A69AB for ; Thu, 31 Mar 2011 13:59:36 -0700 (PDT) Received: from st20.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 1F6C38BE8F4; Thu, 31 Mar 2011 17:01:16 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.myoutlookonline.com (Postfix) with ESMTPS id 856888BE8D7; Thu, 31 Mar 2011 17:01:15 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Thu, 31 Mar 2011 17:00:34 -0400 From: Jonathan Lennox To: Gorry Fairhurst Date: Thu, 31 Mar 2011 17:01:12 -0400 Thread-Topic: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.txt Thread-Index: Acvv5qzjNJlO/BUUQVylz3fm3sd0tQ== Message-ID: <5D5E1DE2-69C9-4652-BA2F-64883D86AFFF@vidyo.com> References: <4D933186.2030804@erg.abdn.ac.uk> In-Reply-To: <4D933186.2030804@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pasi Sarolahti , "mmusic@ietf.org" Subject: Re: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.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: , X-List-Received-Date: Thu, 31 Mar 2011 20:59:37 -0000 (I had this composed before I saw Fleming's e-mail; I mostly agree with him= .) On Mar 30, 2011, at 3:35 PM, Gorry Fairhurst wrote: > draft-ietf-dccp-udpencap-07.txt >=20 > The basic questions are: >=20 > Is there an "easy" way to define SDP that would also allow it to be used= =20 > on a UDP host that doesn't allow native DCCP? >=20 > - How do you signal a server that supports both native and=20 > UDP-encapsulated DCCP? Unfortunately, I think the answer to both these questions is probably ICE, = with new ICE candidate types both for IP-layer DCCP and for DCCP-in-UDP. On the plus side, this would also allow an alternative RTP-in-DCCP/RTP-in-U= DP offer, which seems like it would greatly improve the possibility of an e= volutionary transition to using DCCP. Supporting ICE for DCCP-UDP would also allow it to use ICE's full suite of = connectivity establishment, thus allowing DCCP connections where both peers= are behind NATs (for reasonably friendly NATs, or using TURN). > The options described in the slides are illustrated by two examples: >=20 > Signalling that uses a new proto in SDP m=3D line to indicate DCCP, plus > the SDP connection-oriented media extensions [RFC 4145], as per current > draft. >=20 > m=3Dvideo 5004 DCCP/RTP/AVP 99 [omitted...] > a=3Ddccp-in-udp:9999 This will fail for any existing systems that support the RFC5762 DCCP/RTP/A= VP, since in SDP unknown parameters are ignored. > or a new m=3D proto value. > m=3Dvideo 5004 DCCP-UDP/RTP/AVP 99 > a=3Ddccp-udp-port:9999 This seems better, though I'd name it UDP/DCCP/RTP/AVP following existing p= roto stacking practice. -- Jonathan Lennox jonathan@vidyo.com From jonathan@vidyo.com Thu Mar 31 14:08:40 2011 Return-Path: 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 775273A6AAD for ; Thu, 31 Mar 2011 14:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, 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 8mNDMD6fjZVB for ; Thu, 31 Mar 2011 14:08:39 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id B921C3A6A88 for ; Thu, 31 Mar 2011 14:08:39 -0700 (PDT) Received: from st22.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 2093378C0AD; Thu, 31 Mar 2011 17:10:22 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 9B94478D06C; Thu, 31 Mar 2011 17:10:21 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Thu, 31 Mar 2011 17:09:28 -0400 From: Jonathan Lennox To: Flemming Andreasen Date: Thu, 31 Mar 2011 17:10:16 -0400 Thread-Topic: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.txt Thread-Index: Acvv5/D1ZxLwFqZESySF3qcBl3cZlA== Message-ID: References: <4D933186.2030804@erg.abdn.ac.uk> <4D94E5F6.90004@cisco.com> In-Reply-To: <4D94E5F6.90004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF8E4B8C52EB44A691994E8FF7D7FE8Evidyocom_" MIME-Version: 1.0 Cc: Gorry Fairhurst , Pasi Sarolahti , "mmusic@ietf.org" Subject: Re: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.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: , X-List-Received-Date: Thu, 31 Mar 2011 21:08:40 -0000 --_000_BF8E4B8C52EB44A691994E8FF7D7FE8Evidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 31, 2011, at 10:37 PM, Flemming Andreasen wrote: On 3/30/11 3:35 PM, Gorry Fairhurst wrote: - How do you signal a server that supports both native and UDP-encapsulated DCCP? Use SDP Capability Negotiation (RFC 5939) This is the one point on which I disagree -- this is a choice of alternate = transports, so it's more like ICE than CapNeg, it seems to me. To be sure, in choosing between alternate proto values for the m=3D line th= ere's an overlap here, since proto is overloaded with both transport and pr= ofile. -- Jonathan Lennox jonathan@vidyo.com --_000_BF8E4B8C52EB44A691994E8FF7D7FE8Evidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Mar 31, 2= 011, at 10:37 PM, Flemming Andreasen wrote:
=

On 3/30/11 3:35 PM, Gorry Fairhurst wrote:

- How do you signal a server that supports both native and
UDP-encapsulated DCCP?

Use SDP Capability Negotiation (RFC 5939)

This is the one point on which I dis= agree -- this is a choice of alternate transports, so it's more like ICE th= an CapNeg, it seems to me.

To be sure, in choosing= between alternate proto values for the m=3D line there's an overlap here, = since proto is overloaded with both transport and profile.

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_BF8E4B8C52EB44A691994E8FF7D7FE8Evidyocom_-- From ari.keranen@nomadiclab.com Thu Mar 31 14:55:56 2011 Return-Path: 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 D40D128C10D for ; Thu, 31 Mar 2011 14:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 j38Qflk7eAqI for ; Thu, 31 Mar 2011 14:55:55 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 7679028C0EC for ; Thu, 31 Mar 2011 14:55:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 05C094E6D8; Fri, 1 Apr 2011 00:57:28 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZjaBPzFQGn2; Fri, 1 Apr 2011 00:57:27 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 044EA4E6D1; Fri, 1 Apr 2011 00:57:26 +0300 (EEST) Message-ID: <4D94F8CF.7010109@nomadiclab.com> Date: Thu, 31 Mar 2011 23:57:35 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jonathan Lennox References: <7B899E65-EFF9-4259-88DF-B926D8BDF5A6@vidyo.com> In-Reply-To: <7B899E65-EFF9-4259-88DF-B926D8BDF5A6@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of ice-tcp-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: , X-List-Received-Date: Thu, 31 Mar 2011 21:55:57 -0000 Hi Jonathan, On 31.3.2011 20:06, Jonathan Lennox wrote: > I've reveiwed ice-tcp-10 -- better late than never, I suppose. Definitely. Thanks! > In general, this document seems very solid, and in my opinion is > ready for WGLC; I have only a few minor technical quibbles and > suggestions, plus a few editorial comments. > > Section 10.1: > > Next, the sender checks to see if the resulting set of bytes would be > viewed as a STUN packet based on the rules in Sections 6 and 8 of > [RFC5389]. This includes a check on the most significant two bits, > the magic cookie, the length, and the fingerprint. If, based on > those rules, the bytes would be viewed as a STUN message, the sender > SHOULD utilize a different number of bytes so that the length checks > will fail. > > I think this needs to be MUST -- under what circumstances would a > sender want to insert false-positive STUN packets in the stream? > > (Of course, depending on the content, it's possible that the sender > knows a priori that there can be no false positives, for instance if > it's sending a 7-bit-ASCII protocol.) While a bit of a corner case, I think this proves SHOULD is an appropriate one here :) > I'd also suggest adding a suggestion: "One possible adjustment is to > split the payload in two after its sixth byte. The seventh byte of a > STUN packet, the hexadecimal A4 from the magic cookie, begins with > the bits 1 0, so neither the first split payload (which is too short) > nor the second one (which begins with the wrong bits) could falsely > appear to be a STUN packet." Wordsmithing, or alternate simple > suggestions, welcome. > > I'd also suggest that a sender MAY pre-emptively adjust any payload > that matches a subset of these checks, e.g. just the significant > bits, length, and magic cookie, if it wishes to avoid calculating > fingerprints over the data it's sending. Thanks a lot for the text suggestions, but since *any* way for splitting the payload is sufficient (the length will not match), I think we are better of without additional text on this. Especially considering how corner case this is to begin with.. > For section 5.2, Server Reflexive Candidates (and also the > prioritization formulas): > > Unless I'm missing something, Server Reflexive Candidates are only > possible and useful for Simultaneous-Open connections, not Active or > Passive? Either this should be pointed out, or there should be an > explanation of how you'd create, and how you'd make use of, > Server-Reflexive Active or Passive candidates. AFAIK, server reflexive should be OK also for passive candidates (once you do the tricks described in Appendix B). Also, server reflexive active candidates are useful with relays since with TURN one needs to give the TURN server the address of the peer (set permissions) for incoming connections. I could add to the server reflexive candidate section something along the lines of: Obtaining server reflexive passive candidates may require sending requests from the passive candidate; see Appendix B for implementation details. Server reflexive active candidates can be derived from the passive or S-O candidates by using the same IP address as the passive or S-O server reflexive candidate has. > For section 5.3, UDP-Tunneled Candidates: > > When UDP tunneling is done by your operating system (as is the case > with Teredo on Microsoft Windows), it may not be obvious based on the > system APIs that a given candidate is in fact a UDP-tunneled > candidate and not a host candidate. If there is a need to give > UDP-tunneled candidates a lower type-preference, it should be pointed > out that implementations will need to detect local pseudo-interfaces > that are actually UDP tunnels. OK. This is a bit of an implementation detail, but I can try to add something along those lines to the section 5.4. > There's also the complexity that Teredo candidates may, in fact, end > up being Relayed candidates, when matched up with non-Teredo IPv6 > addresses. Handling this (and de-prioritizing the pairs) based on > the normal rules of ICE would be very difficult, however, other than > by unilateral action of the controlling endpoint. Yes. But given how complex this goes, I think we're better of without trying to define something for this. > Neither of these issues are specific to ICE-TCP, other than the fact > that UDP-Tunneled candidates weren't mentioned in the original ICE. > > > Editorial: > > Section 10.1: > > For media streams that are not RTP-based and do not normally use RFC > 4571, the agent treats the media stream as a byte stream, and > assumes that it has its own framing of some sort. > > This is an extreme quibble, but conceivably you could have a > higher-level byte stream with no framing whatsoever (e.g. dumb file > transfer over SIP: open a media stream, dump a file, close the > stream). It doesn't change anything about this protocol, though. True. Maybe we can make that " [...] of some sort, if needed". > Section 4.5: > > Since an ICE ICE offerer always uses an active candidate as default, > an ICE ICE answerer will always use a passive candidate as default > and include the a=setup:passive attribute in the answer. > > "ICE" is repeated, twice. Good catch! That should say "ICE TCP". Thanks, Ari From fandreas@cisco.com Thu Mar 31 14:56:52 2011 Return-Path: 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 076F928C0EC for ; Thu, 31 Mar 2011 14:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qi00+LQ8lNDz for ; Thu, 31 Mar 2011 14:56:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1055728C10D for ; Thu, 31 Mar 2011 14:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=4279; q=dns/txt; s=iport; t=1301608711; x=1302818311; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=oVkTJwmzUnqFhqtat0o2oOHRMrk1dilDuKF8FTwAR58=; b=hBrcWlE3U2jW27OxEaWSE01HhsI84nxoLCqkXytk0PU7+cKhkT3q5J+T Y8md2YCKyQOSQaOeccGz+tPZS4sSOApIRAN7WNlbkZHQmsnir95lo+A5K W89RsV8ftttyWboiGd9ty6bpv4wz36lL7eHDlCx5//N07KpRw+wZuJPfE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE74lE2rRDoH/2dsb2JhbAClWneIeZs2nDqFawSNEQ X-IronPort-AV: E=Sophos;i="4.63,278,1299456000"; d="scan'208,217";a="421953777" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2011 21:58:30 +0000 Received: from dhcp-42c5.meeting.ietf.org ([10.21.168.8]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2VLwSMd000542; Thu, 31 Mar 2011 21:58:29 GMT Message-ID: <4D94F905.4070307@cisco.com> Date: Thu, 31 Mar 2011 23:58:29 +0200 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Jonathan Lennox References: <4D933186.2030804@erg.abdn.ac.uk> <4D94E5F6.90004@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040604010508090708000001" Cc: Gorry Fairhurst , Pasi Sarolahti , mmusic@ietf.org Subject: Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.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: , X-List-Received-Date: Thu, 31 Mar 2011 21:56:52 -0000 This is a multi-part message in MIME format. --------------040604010508090708000001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/31/11 11:10 PM, Jonathan Lennox wrote: > > On Mar 31, 2011, at 10:37 PM, Flemming Andreasen wrote: >> >> On 3/30/11 3:35 PM, Gorry Fairhurst wrote: >>> >>> - How do you signal a server that supports both native and >>> UDP-encapsulated DCCP? >>> >> Use SDP Capability Negotiation (RFC 5939) > > This is the one point on which I disagree -- this is a choice of > alternate transports, so it's more like ICE than CapNeg, it seems to me. > I think it depends on what you are trying to do: Negotiate use of a mechanism that both sides support or find a mechanism that can establish connectivity as verified by ICE. It's probably quite reasonable to support both scenarios. RFC 5939 Section 3.7 has a bit more text around this btw. More discussion/opinions on this point would be useful. Thanks -- Flemming > To be sure, in choosing between alternate proto values for the m= line > there's an overlap here, since proto is overloaded with both transport > and profile. > > -- > Jonathan Lennox > jonathan@vidyo.com > > --------------040604010508090708000001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 3/31/11 11:10 PM, Jonathan Lennox wrote:

On Mar 31, 2011, at 10:37 PM, Flemming Andreasen wrote:

On 3/30/11 3:35 PM, Gorry Fairhurst wrote:

- How do you signal a server that supports both native and
UDP-encapsulated DCCP?

Use SDP Capability Negotiation (RFC 5939)

This is the one point on which I disagree -- this is a choice of alternate transports, so it's more like ICE than CapNeg, it seems to me.

I think it depends on what you are trying to do: Negotiate use of a mechanism that both sides support or find a mechanism that can establish connectivity as verified by ICE. It's probably quite reasonable to support both scenarios. RFC 5939 Section 3.7 has a bit more text around this btw.

More discussion/opinions on this point would be useful.

Thanks

-- Flemming

To be sure, in choosing between alternate proto values for the m= line there's an overlap here, since proto is overloaded with both transport and profile.

--
Jonathan Lennox
jonathan@vidyo.com


--------------040604010508090708000001-- From HKaplan@acmepacket.com Thu Mar 31 17:10:17 2011 Return-Path: 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 949193A6B80 for ; Thu, 31 Mar 2011 17:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, 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 nm8M-AzvDyUa for ; Thu, 31 Mar 2011 17:10:16 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A44BB3A69C9 for ; Thu, 31 Mar 2011 17:10:15 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 31 Mar 2011 20:11:53 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 31 Mar 2011 20:11:53 -0400 From: Hadriel Kaplan To: mmusic Date: Thu, 31 Mar 2011 20:11:50 -0400 Thread-Topic: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? Thread-Index: AcvwAWdtQ+oOgn1/QH+21l+JdJh8dA== Message-ID: <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com> <0e4201cbeebb$f527ea80$df77bf80$@com> <1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com> <00e001cbefad$c21e2fd0$465a8f70$@com> In-Reply-To: <00e001cbefad$c21e2fd0$465a8f70$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Fri, 01 Apr 2011 00:10:17 -0000 Howdy, I read the draft, and also found the use of the term "ALG" to be confusing = and annoying. It's not just rfc3303 which defines an ALG as being in a inl= ine/NAT type device - lots of the user market uses the term ALG for inline = type as well. (it's basically a derogatory term) One "SBC" vendor I know o= f arguably had a real SIP ALG, but they went defunct years ago. Then again, the drawings actually show the SIP-ALG+middlebox not changing t= he SDP at all, so maybe they do mean ALG. But anyway... I don't mean to sound negative, but what's the purpose of thi= s document? What do we think it's going to achieve if it's published as an= RFC? The only "output" of this document are four "preliminary recommendations". = Of those four, I'd argue three of them are now wrong or misleading, and th= e remaining one is unlikely to occur/help. It also claims to describe the = impact on ICE, but doesn't; claims to propose mechanisms to mitigate latchi= ng, but doesn't; doesn't describe the issues with middleboxes and forked or= moved calls on early in-band media signaling; and uses terminology from an= cient history (ie, RFC 3303). So what's the point of this doc again? -hadriel On Mar 31, 2011, at 10:13 AM, Dan Wing wrote: >> -----Original Message----- >> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> Sent: Thursday, March 31, 2011 1:01 PM >> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith); >> Christer Holmberg; Flemming Andreasen (fandreas); mmusic >> Subject: RE: [MMUSIC] Continued WG interest in SDP >> offer/answerwithmiddleboxes? >> >> I agree with your interpretation of what an SBC is. However, the reason >> why I don't find anything wrong in the use of ALG in >> draft-ietf-mmusic-media-path-middleboxes is because it describes >> firewall and NAT traversal functions that are typically implemented as >> ALGs, except that these functions are decoupled into a MIDCOM agent and >> a middle box. In addition RFC 3303 goes on to say (section 2.8) that >> MIDCOM agents are entities performing ALG functions, logically external >> to a middlebox. It even says these agents can reside on a proxy. >> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the ALG >> in >> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the draft >> I think. > > If Figure 1 was modified to show a NAT or firewall, it could reasonably > use the term ALG with those devices. > > But when showing an SBC, which is smack in the middle of Figure 1, > it cannot accurately call the SBC a "SIP ALG", as it does right now. > > -d > > >> Muthu >> >> |-----Original Message----- >> |From: Dan Wing (dwing) >> |Sent: Wednesday, March 30, 2011 2:52 PM >> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); >> 'DRAGE, Keith (Keith)'; 'Christer >> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' >> |Subject: RE: [MMUSIC] Continued WG interest in SDP >> offer/answerwithmiddleboxes? >> | >> |> -----Original Message----- >> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> |> Sent: Tuesday, March 29, 2011 3:58 PM >> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer >> Holmberg; >> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic >> |> Subject: RE: [MMUSIC] Continued WG interest in SDP >> |> offer/answerwithmiddleboxes? >> |> >> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is just >> an >> |> extension of RFC 3303 -- while the later describes the middlebox >> |> communication architecture and framework, the former describes some >> of >> |> the desirable behaviors of these middleboxes and protocols that >> operate >> |> on the media path unspecified in the later. RFC 3303 defines what >> an >> |> ALG is and it doesn't forbid packets being addressed to the ALG at >> the >> |> IP layer. >> |> >> |> >> |> 2.6. ALG >> |> Application Level Gateways (ALGs) are entities that possess the >> |> application specific intelligence and knowledge of an associated >> |> middlebox function. An ALG examines application traffic in transit >> |> and assists the middlebox in carrying out its function. >> |> >> |> ALGs are different from proxies. ALGs are not visible to end-hosts, >> |> unlike the proxies which are relay agents terminating sessions with >> |> both end-hosts. ALGs do not terminate sessions with either end- >> host. >> |> Instead, ALGs examine, and optionally modify, application payload >> |> content to facilitate the flow of application traffic through a >> |> middlebox. >> |> >> |> 2.8. MIDCOM Agents >> |> MIDCOM agents are entities performing ALG functions, logically >> |> external to a middlebox. >> |> >> |> The packets may be addressed to the agent node at the IP layer. >> |> Alternatively they may not be addressed to the agent node, but may >> be >> |> constrained by other factors to flow through it. >> |> >> |> >> |> So, I don't see anything wrong in the use of ALG in >> |> draft-ietf-mmusic-media-path-middleboxes, unless we plan to make >> |> changes >> |> to how RFC 3303 describes it. >> | >> |3303 is quite clear, in exactly the text you quoted in the paragraph >> |starting with "ALGs are different from proxies", that ALGs aren't >> |visible to hosts and ALGs don't terminate sessions. >> | >> |An SBC is certainly visible to the end host, for both the SIP >> |signaling and the RTP media -- the end host is sending packets >> |to the SBC's IP address and receiving packets from the SBC's >> |IP address. >> | >> |-d >> | >> | >> |> Muthu >> |> >> |> |-----Original Message----- >> |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> |> Behalf Of Parthasarathi R (partr) >> |> |Sent: Wednesday, March 16, 2011 6:15 PM >> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); >> |> Flemming >> |> Andreasen (fandreas); mmusic >> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP >> |> offer/answerwithmiddleboxes? >> |> | >> |> |Keith, >> |> | >> |> |Sorry in case "media" word in my mail mislead you. Dan explains in >> |> |another mail thread >> |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) >> |> why >> |> |SIP ALG is not appropriate and B2BUA is more appropriate for this >> |> draft. >> |> | >> |> | >> |> |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly >> fits >> |> |your definition of B2BUA as it involves only SIP & SDP and media is >> |> |defined as middlebox. >> |> | >> |> |I have mentioned as kind of B2BUA because the draft concentrates on >> |> |callflow where one side of B2BUA acts as UAC and other side always >> |> acts >> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC >> callflows >> |> |specific issues. In the current scope of draft is continued for the >> |> |draft, the new definition may be required or draft text has to >> clarify >> |> |the scope. >> |> | >> |> |Thanks >> |> |Partha >> |> | >> |> |-----Original Message----- >> |> |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] >> |> |Sent: Wednesday, March 16, 2011 5:33 PM >> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); >> |> |Flemming Andreasen (fandreas); mmusic >> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer >> |> |withmiddleboxes? >> |> | >> |> |The only definition of B2BUA that I know of comes in RFC 3261 (sort >> |> of) >> |> |where the scope is limited to SIP. So a UA acts in one or more >> |> |directions as a SIP UA. Whatever else it does is outside the >> |> definition. >> |> |That I believe matches with what Christer is saying. >> |> | >> |> |If you want something that defines what it does with media, then >> you >> |> |need something that defines that, but using the term B2BUA to do >> that >> |> is >> |> |probably not the best choice. >> |> | >> |> |Regards >> |> | >> |> |Keith >> |> | >> |> |> -----Original Message----- >> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> |> |> Behalf Of Parthasarathi R (partr) >> |> |> Sent: 15 March 2011 09:54 >> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen >> |> |> (fandreas); mmusic >> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer >> with >> |> |> middleboxes? >> |> |> >> |> |> Christer, >> |> |> >> |> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle >> |> |> signaling only and it is upto the implementation to decide. Also, >> |> this >> |> | >> |> |> draft does not have restriction that SIP B2BUA and media server >> has >> |> to >> |> | >> |> |> be co-exist in the same device. The draft talks about the >> scenario >> |> |> wherein SIP B2BUA communicates with media server using Megaco >> |> (H.248). >> |> |> >> |> |> As I mentioned in other mail thread, ALG does not look >> appropriate >> |> and >> |> | >> |> |> the draft is talking only about the specific type of B2BUA. In >> real >> |> |> deployment, Few vendors named these sort of B2BUA as "Session >> Border >> |> |> Controller or SBC" as well. SBC may not accepted in IETF as SBC >> does >> |> |> lot more. In case there is a need to have different name for >> these >> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work it >> out. >> |> |> >> |> |> Thanks >> |> |> Partha >> |> |> >> |> |> -----Original Message----- >> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> |> |> Behalf Of Christer Holmberg >> |> |> Sent: Tuesday, March 15, 2011 12:14 PM >> |> |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' >> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer >> with >> |> |> middleboxes? >> |> |> >> |> |> >> |> |> Hi Dan, >> |> |> >> |> |> In my definition of an ALG packets can be sent directly to its IP >> |> |> address. >> |> |> >> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also >> |> |> focuses on other things, like media. A SIP ALG contains a SIP >> B2BUA. >> |> |> >> |> |> Regards, >> |> |> >> |> |> Christer >> |> |> >> |> |> -----Original Message----- >> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> |> |> Behalf Of Dan Wing >> |> |> Sent: 15. maaliskuuta 2011 4:39 >> |> |> To: 'Flemming Andreasen'; 'mmusic' >> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer >> with >> |> |> middleboxes ? >> |> |> >> |> |> The draft uses the term "SIP ALG", which at least does not fit my >> |> |> definition of an ALG. An ALG doesn't have packets sent directly >> to >> |> |> its IP address; it does its job stealthily without awareness of >> one >> |> |> (or >> |> |> both) of the sessoin endpoints. In contrast, the function >> described >> |> |> in draft-ietf-mmusic-media-path-middleboxes >> |> |> is different -- packets are always sent to the IP address of the >> SIP >> |> |> "ALG", and packets are sent from the IP address of the SIP "ALG". >> |> |> This functionality is most often called a "server" >> |> |> or a "proxy" -- not an ALG. >> |> |> >> |> |> This distinction is important because this draft is closely >> related >> |> to >> |> | >> |> |> functions common in NATs, which _do_ sometimes have SIP ALGs >> |> |> implemented in them. >> |> |> >> |> |> So ... can we change "SIP ALG" to something like "SIP proxy" >> |> |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it >> is >> |> a >> |> | >> |> |> B2BUA, at least as best I understand the definition of a B2BUA, >> so >> |> |> B2BUA seems best. >> |> |> >> |> |> d >> |> |> >> |> |> >> |> |> > -----Original Message----- >> |> |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> On >> |> |> > Behalf Of Flemming Andreasen >> |> |> > Sent: Thursday, March 10, 2011 6:15 PM >> |> |> > To: mmusic >> |> |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer >> with >> |> |> > middleboxes ? >> |> |> > >> |> |> > We currently have a MMUSIC milestone for "considerations for >> using >> |> |> > SDP >> |> |> >> |> |> > offer/answer with middleboxes". The latest draft for this WG >> item >> |> is >> |> |> > >> |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt >> |> |> > >> |> |> > which expired in January 2011. There hasn't been much >> discussion >> |> on >> |> |> > this topic for a while, and the current draft authors are not >> |> |> > planning >> |> |> >> |> |> > continued work on the draft, so we need new authors if we are >> to >> |> |> > continue with this WG item. Please let us know if >> |> |> > 1) You are still interested in this deliverable >> |> |> > 2) You are willing to actively contribute to and/or author this >> |> |> > document. >> |> |> > >> |> |> > Thanks >> |> |> > >> |> |> > Flemming & Miguel [MMUSIC chairs] >> |> |> > >> |> |> > >> |> |> > _______________________________________________ >> |> |> > 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 >> |> |> _______________________________________________ >> |> |> 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 >> |> |_______________________________________________ >> |> |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 mperumal@cisco.com Thu Mar 31 19:46:58 2011 Return-Path: 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 BB72C3A6ADE for ; Thu, 31 Mar 2011 19:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3khQVspdexwI for ; Thu, 31 Mar 2011 19:46:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id AD5873A6B74 for ; Thu, 31 Mar 2011 19:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=15587; q=dns/txt; s=iport; t=1301626116; x=1302835716; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=TkMmlhWRO9WGYnAW5cZxSyPq439vbGmhopXTEn57kYk=; b=UtAe4yj2o/LYoD5B2mmuM5T8z3ZL/gRNVGUXkVqYR08w3GrUlRdfUrP/ 2urCX4ibuv+v31mzJ0PL6sgbnSbdrs6cBlofsjwz1+fRiaAuE9BsIb6zf 2hPNmuQXTypwjdPHekPeubs2RxgyRTAWPb0jFFLgjFVX9UEr8LsACtn7l I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUAAEs8lU2Q/khNgWdsb2JhbACYHI0+FAEBFiYlpC+cOIVrBIVAizQ X-IronPort-AV: E=Sophos;i="4.63,280,1299456000"; d="scan'208";a="24033818" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 02:48:34 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p312mWbv028244; Fri, 1 Apr 2011 02:48:33 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 08:18:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 08:18:29 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> In-Reply-To: <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? Thread-Index: AcvwAWdtQ+oOgn1/QH+21l+JdJh8dAAERjjQ References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com> <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "mmusic" X-OriginalArrivalTime: 01 Apr 2011 02:48:32.0214 (UTC) FILETIME=[49BBA760:01CBF017] Subject: Re: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Fri, 01 Apr 2011 02:46:58 -0000 The main goal of the draft as it seems to claim is to describe the desirable behaviors of middleboxes and signaling protocols that operate on the media path, to aid in firewall/NAT traversal. It looks like an extension of RFC 3303 whose focus is also firewall and NAT traversal use-cases. The draft claims that the architecture/functions it describes is used in IMS and specified in 3GPP, TISPAN and PacketCable specs -- if it true, then this is where the recommendations in the draft would be useful I think. However, it doesn't look it would be useful for all B2BUA/SBC use-cases/deployments -- if we want to make it, then I think it would be a scope creep. Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Friday, April 01, 2011 5:42 AM |To: mmusic |Subject: Re: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? | | |Howdy, |I read the draft, and also found the use of the term "ALG" to be confusing and annoying. It's not |just rfc3303 which defines an ALG as being in a inline/NAT type device - lots of the user market uses |the term ALG for inline type as well. (it's basically a derogatory term) One "SBC" vendor I know of |arguably had a real SIP ALG, but they went defunct years ago. | |Then again, the drawings actually show the SIP-ALG+middlebox not changing the SDP at all, so maybe |they do mean ALG. | |But anyway... I don't mean to sound negative, but what's the purpose of this document? What do we |think it's going to achieve if it's published as an RFC? |The only "output" of this document are four "preliminary recommendations". Of those four, I'd argue |three of them are now wrong or misleading, and the remaining one is unlikely to occur/help. It also |claims to describe the impact on ICE, but doesn't; claims to propose mechanisms to mitigate latching, |but doesn't; doesn't describe the issues with middleboxes and forked or moved calls on early in-band |media signaling; and uses terminology from ancient history (ie, RFC 3303). | |So what's the point of this doc again? | |-hadriel | | | |On Mar 31, 2011, at 10:13 AM, Dan Wing wrote: | |>> -----Original Message----- |>> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |>> Sent: Thursday, March 31, 2011 1:01 PM |>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith); |>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic |>> Subject: RE: [MMUSIC] Continued WG interest in SDP |>> offer/answerwithmiddleboxes? |>> |>> I agree with your interpretation of what an SBC is. However, the reason |>> why I don't find anything wrong in the use of ALG in |>> draft-ietf-mmusic-media-path-middleboxes is because it describes |>> firewall and NAT traversal functions that are typically implemented as |>> ALGs, except that these functions are decoupled into a MIDCOM agent and |>> a middle box. In addition RFC 3303 goes on to say (section 2.8) that |>> MIDCOM agents are entities performing ALG functions, logically external |>> to a middlebox. It even says these agents can reside on a proxy. |>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the ALG |>> in |>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the draft |>> I think. |> |> If Figure 1 was modified to show a NAT or firewall, it could reasonably |> use the term ALG with those devices. |> |> But when showing an SBC, which is smack in the middle of Figure 1, |> it cannot accurately call the SBC a "SIP ALG", as it does right now. |> |> -d |> |> |>> Muthu |>> |>> |-----Original Message----- |>> |From: Dan Wing (dwing) |>> |Sent: Wednesday, March 30, 2011 2:52 PM |>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); |>> 'DRAGE, Keith (Keith)'; 'Christer |>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' |>> |Subject: RE: [MMUSIC] Continued WG interest in SDP |>> offer/answerwithmiddleboxes? |>> | |>> |> -----Original Message----- |>> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |>> |> Sent: Tuesday, March 29, 2011 3:58 PM |>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer |>> Holmberg; |>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic |>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP |>> |> offer/answerwithmiddleboxes? |>> |> |>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is just |>> an |>> |> extension of RFC 3303 -- while the later describes the middlebox |>> |> communication architecture and framework, the former describes some |>> of |>> |> the desirable behaviors of these middleboxes and protocols that |>> operate |>> |> on the media path unspecified in the later. RFC 3303 defines what |>> an |>> |> ALG is and it doesn't forbid packets being addressed to the ALG at |>> the |>> |> IP layer. |>> |> |>> |> |>> |> 2.6. ALG |>> |> Application Level Gateways (ALGs) are entities that possess the |>> |> application specific intelligence and knowledge of an associated |>> |> middlebox function. An ALG examines application traffic in transit |>> |> and assists the middlebox in carrying out its function. |>> |> |>> |> ALGs are different from proxies. ALGs are not visible to end-hosts, |>> |> unlike the proxies which are relay agents terminating sessions with |>> |> both end-hosts. ALGs do not terminate sessions with either end- |>> host. |>> |> Instead, ALGs examine, and optionally modify, application payload |>> |> content to facilitate the flow of application traffic through a |>> |> middlebox. |>> |> |>> |> 2.8. MIDCOM Agents |>> |> MIDCOM agents are entities performing ALG functions, logically |>> |> external to a middlebox. |>> |> |>> |> The packets may be addressed to the agent node at the IP layer. |>> |> Alternatively they may not be addressed to the agent node, but may |>> be |>> |> constrained by other factors to flow through it. |>> |> |>> |> |>> |> So, I don't see anything wrong in the use of ALG in |>> |> draft-ietf-mmusic-media-path-middleboxes, unless we plan to make |>> |> changes |>> |> to how RFC 3303 describes it. |>> | |>> |3303 is quite clear, in exactly the text you quoted in the paragraph |>> |starting with "ALGs are different from proxies", that ALGs aren't |>> |visible to hosts and ALGs don't terminate sessions. |>> | |>> |An SBC is certainly visible to the end host, for both the SIP |>> |signaling and the RTP media -- the end host is sending packets |>> |to the SBC's IP address and receiving packets from the SBC's |>> |IP address. |>> | |>> |-d |>> | |>> | |>> |> Muthu |>> |> |>> |> |-----Original Message----- |>> |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |>> |> Behalf Of Parthasarathi R (partr) |>> |> |Sent: Wednesday, March 16, 2011 6:15 PM |>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); |>> |> Flemming |>> |> Andreasen (fandreas); mmusic |>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP |>> |> offer/answerwithmiddleboxes? |>> |> | |>> |> |Keith, |>> |> | |>> |> |Sorry in case "media" word in my mail mislead you. Dan explains in |>> |> |another mail thread |>> |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) |>> |> why |>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for this |>> |> draft. |>> |> | |>> |> | |>> |> |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly |>> fits |>> |> |your definition of B2BUA as it involves only SIP & SDP and media is |>> |> |defined as middlebox. |>> |> | |>> |> |I have mentioned as kind of B2BUA because the draft concentrates on |>> |> |callflow where one side of B2BUA acts as UAC and other side always |>> |> acts |>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC |>> callflows |>> |> |specific issues. In the current scope of draft is continued for the |>> |> |draft, the new definition may be required or draft text has to |>> clarify |>> |> |the scope. |>> |> | |>> |> |Thanks |>> |> |Partha |>> |> | |>> |> |-----Original Message----- |>> |> |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] |>> |> |Sent: Wednesday, March 16, 2011 5:33 PM |>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing); |>> |> |Flemming Andreasen (fandreas); mmusic |>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer |>> |> |withmiddleboxes? |>> |> | |>> |> |The only definition of B2BUA that I know of comes in RFC 3261 (sort |>> |> of) |>> |> |where the scope is limited to SIP. So a UA acts in one or more |>> |> |directions as a SIP UA. Whatever else it does is outside the |>> |> definition. |>> |> |That I believe matches with what Christer is saying. |>> |> | |>> |> |If you want something that defines what it does with media, then |>> you |>> |> |need something that defines that, but using the term B2BUA to do |>> that |>> |> is |>> |> |probably not the best choice. |>> |> | |>> |> |Regards |>> |> | |>> |> |Keith |>> |> | |>> |> |> -----Original Message----- |>> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |>> |> |> Behalf Of Parthasarathi R (partr) |>> |> |> Sent: 15 March 2011 09:54 |>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen |>> |> |> (fandreas); mmusic |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer |>> with |>> |> |> middleboxes? |>> |> |> |>> |> |> Christer, |>> |> |> |>> |> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle |>> |> |> signaling only and it is upto the implementation to decide. Also, |>> |> this |>> |> | |>> |> |> draft does not have restriction that SIP B2BUA and media server |>> has |>> |> to |>> |> | |>> |> |> be co-exist in the same device. The draft talks about the |>> scenario |>> |> |> wherein SIP B2BUA communicates with media server using Megaco |>> |> (H.248). |>> |> |> |>> |> |> As I mentioned in other mail thread, ALG does not look |>> appropriate |>> |> and |>> |> | |>> |> |> the draft is talking only about the specific type of B2BUA. In |>> real |>> |> |> deployment, Few vendors named these sort of B2BUA as "Session |>> Border |>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as SBC |>> does |>> |> |> lot more. In case there is a need to have different name for |>> these |>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work it |>> out. |>> |> |> |>> |> |> Thanks |>> |> |> Partha |>> |> |> |>> |> |> -----Original Message----- |>> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |>> |> |> Behalf Of Christer Holmberg |>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM |>> |> |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic' |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer |>> with |>> |> |> middleboxes? |>> |> |> |>> |> |> |>> |> |> Hi Dan, |>> |> |> |>> |> |> In my definition of an ALG packets can be sent directly to its IP |>> |> |> address. |>> |> |> |>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also |>> |> |> focuses on other things, like media. A SIP ALG contains a SIP |>> B2BUA. |>> |> |> |>> |> |> Regards, |>> |> |> |>> |> |> Christer |>> |> |> |>> |> |> -----Original Message----- |>> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On |>> |> |> Behalf Of Dan Wing |>> |> |> Sent: 15. maaliskuuta 2011 4:39 |>> |> |> To: 'Flemming Andreasen'; 'mmusic' |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer |>> with |>> |> |> middleboxes ? |>> |> |> |>> |> |> The draft uses the term "SIP ALG", which at least does not fit my |>> |> |> definition of an ALG. An ALG doesn't have packets sent directly |>> to |>> |> |> its IP address; it does its job stealthily without awareness of |>> one |>> |> |> (or |>> |> |> both) of the sessoin endpoints. In contrast, the function |>> described |>> |> |> in draft-ietf-mmusic-media-path-middleboxes |>> |> |> is different -- packets are always sent to the IP address of the |>> SIP |>> |> |> "ALG", and packets are sent from the IP address of the SIP "ALG". |>> |> |> This functionality is most often called a "server" |>> |> |> or a "proxy" -- not an ALG. |>> |> |> |>> |> |> This distinction is important because this draft is closely |>> related |>> |> to |>> |> | |>> |> |> functions common in NATs, which _do_ sometimes have SIP ALGs |>> |> |> implemented in them. |>> |> |> |>> |> |> So ... can we change "SIP ALG" to something like "SIP proxy" |>> |> |> or "SIP user agent" or "SIP Back-to-Back User Agent"? Really, it |>> is |>> |> a |>> |> | |>> |> |> B2BUA, at least as best I understand the definition of a B2BUA, |>> so |>> |> |> B2BUA seems best. |>> |> |> |>> |> |> d |>> |> |> |>> |> |> |>> |> |> > -----Original Message----- |>> |> |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] |>> On |>> |> |> > Behalf Of Flemming Andreasen |>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM |>> |> |> > To: mmusic |>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer |>> with |>> |> |> > middleboxes ? |>> |> |> > |>> |> |> > We currently have a MMUSIC milestone for "considerations for |>> using |>> |> |> > SDP |>> |> |> |>> |> |> > offer/answer with middleboxes". The latest draft for this WG |>> item |>> |> is |>> |> |> > |>> |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt |>> |> |> > |>> |> |> > which expired in January 2011. There hasn't been much |>> discussion |>> |> on |>> |> |> > this topic for a while, and the current draft authors are not |>> |> |> > planning |>> |> |> |>> |> |> > continued work on the draft, so we need new authors if we are |>> to |>> |> |> > continue with this WG item. Please let us know if |>> |> |> > 1) You are still interested in this deliverable |>> |> |> > 2) You are willing to actively contribute to and/or author this |>> |> |> > document. |>> |> |> > |>> |> |> > Thanks |>> |> |> > |>> |> |> > Flemming & Miguel [MMUSIC chairs] |>> |> |> > |>> |> |> > |>> |> |> > _______________________________________________ |>> |> |> > 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 |>> |> |> _______________________________________________ |>> |> |> 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 |>> |> |_______________________________________________ |>> |> |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 | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From jonathan@vidyo.com Thu Mar 31 23:08:06 2011 Return-Path: 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 3C2653A6BEB for ; Thu, 31 Mar 2011 23:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 dolpQPz3BYFI for ; Thu, 31 Mar 2011 23:08:04 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 4DAD33A6BEA for ; Thu, 31 Mar 2011 23:08:04 -0700 (PDT) Received: from st23.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id B01B3417085; Fri, 1 Apr 2011 02:09:43 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 09D6D417089; Fri, 1 Apr 2011 02:09:43 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Fri, 1 Apr 2011 02:09:01 -0400 From: Jonathan Lennox To: Ari Keranen Date: Fri, 1 Apr 2011 02:09:41 -0400 Thread-Topic: [MMUSIC] Review of ice-tcp-10 Thread-Index: AcvwM0uHmCylB8iaQKa9SQmAbZ9PAg== Message-ID: <9991D5E3-27CC-4484-83B2-65FFEEF24043@vidyo.com> References: <7B899E65-EFF9-4259-88DF-B926D8BDF5A6@vidyo.com> <4D94F8CF.7010109@nomadiclab.com> In-Reply-To: <4D94F8CF.7010109@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of ice-tcp-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: , X-List-Received-Date: Fri, 01 Apr 2011 06:08:06 -0000 On Mar 31, 2011, at 11:57 PM, Ari Keranen wrote: > Hi Jonathan, >=20 > On 31.3.2011 20:06, Jonathan Lennox wrote: >>=20 >> I think this needs to be MUST -- under what circumstances would a >> sender want to insert false-positive STUN packets in the stream? >>=20 >> (Of course, depending on the content, it's possible that the sender >> knows a priori that there can be no false positives, for instance if >> it's sending a 7-bit-ASCII protocol.) >=20 > While a bit of a corner case, I think this proves SHOULD is an=20 > appropriate one here :) I think the sender MUST ensure there are no false-positive STUN packets in = the stream, but as discussed here and the subsequent discussion, there are = a number of ways to accomplish this. Whether to give implementation guidan= ce as to how best to do it is a separate matter, and I see your point about= not wanting to go on too much about it. >> For section 5.2, Server Reflexive Candidates (and also the >> prioritization formulas): >>=20 >> Unless I'm missing something, Server Reflexive Candidates are only >> possible and useful for Simultaneous-Open connections, not Active or >> Passive? Either this should be pointed out, or there should be an >> explanation of how you'd create, and how you'd make use of, >> Server-Reflexive Active or Passive candidates. >=20 > AFAIK, server reflexive should be OK also for passive candidates (once=20 > you do the tricks described in Appendix B). Ah, I see -- so you're recommending doing the "send from your receive port"= trick to STUN your passive candidate, in hopes the NAT has Endpoint-Indepe= ndent Filtering. I don't know how likely that policy is going to be in pra= ctice (for pure server-reflexive, as opposed to NAT-assisted, candidates), = but I guess it couldn't hurt to try it, so long as your OS supports the App= endix B tricks. > I could add to the server reflexive candidate section something along=20 > the lines of: >=20 > Obtaining server reflexive passive candidates may require sending=20 > requests from the passive candidate; see Appendix B for implementation=20 > details. Server reflexive active candidates can be derived from the=20 > passive or S-O candidates by using the same IP address as the passive or= =20 > S-O server reflexive candidate has. That makes sense. It's probably worth having some language describing why they're useful, too= (i.e. the TURN permissions issue) -- I probably won't be the only person t= o miss that. >> For section 5.3, UDP-Tunneled Candidates: >>=20 >> When UDP tunneling is done by your operating system (as is the case >> with Teredo on Microsoft Windows), it may not be obvious based on the >> system APIs that a given candidate is in fact a UDP-tunneled >> candidate and not a host candidate. If there is a need to give >> UDP-tunneled candidates a lower type-preference, it should be pointed >> out that implementations will need to detect local pseudo-interfaces >> that are actually UDP tunnels. >=20 > OK. This is a bit of an implementation detail, but I can try to add=20 > something along those lines to the section 5.4. As you wish. (It's not just Teredo on Windows; most OS-provided tunnel add= resses will look like an additional interface address, I think.) >> There's also the complexity that Teredo candidates may, in fact, end >> up being Relayed candidates, when matched up with non-Teredo IPv6 >> addresses. Handling this (and de-prioritizing the pairs) based on >> the normal rules of ICE would be very difficult, however, other than >> by unilateral action of the controlling endpoint. >=20 > Yes. But given how complex this goes, I think we're better of without=20 > trying to define something for this. I agree we can't standardize this in any useful way, yes; but it could be a= consideration for the controlling endpoint's choice of which pair to nomin= ate, so it might be worth pointing out. On the other hand, it's not TCP-specific, and it's an implementation detail= ; I know you're trying to stop the document from getting too long. So as y= ou wish. -- Jonathan Lennox jonathan@vidyo.com From peter.musgrave@magorcorp.com Thu Mar 31 23:41:16 2011 Return-Path: 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 98BDC3A6AC3 for ; Thu, 31 Mar 2011 23:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NDHIUzBR3z9R for ; Thu, 31 Mar 2011 23:41:16 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AA4A83A6A86 for ; Thu, 31 Mar 2011 23:41:15 -0700 (PDT) Received: by bwz13 with SMTP id 13so2487922bwz.31 for ; Thu, 31 Mar 2011 23:42:55 -0700 (PDT) Received: by 10.204.82.224 with SMTP id c32mr3226553bkl.161.1301640175040; Thu, 31 Mar 2011 23:42:55 -0700 (PDT) Received: from dhcp-1357.meeting.ietf.org (dhcp-1357.meeting.ietf.org [130.129.19.87]) by mx.google.com with ESMTPS id k5sm1168535bku.4.2011.03.31.23.42.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 23:42:53 -0700 (PDT) From: Peter Musgrave Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 08:42:50 +0200 References: <4919E001-92CF-4546-B759-8E4118CEB73E@magorcorp.com> To: mmusic Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 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: , X-List-Received-Date: Fri, 01 Apr 2011 06:41:16 -0000 Hi Cullen/Ali,=20 Overall, I think this is clean and usable. It solves enough useful cases = without trying to "solve world hunger".=20 Is it worth having an example in which the video is SSRC muxed as = described in section 3.2? Also, I believe your example in 4.2 wants to have all the m lines be = video (they are audio in the sample).=20 Thanks,=20 Peter Musgrave From christer.holmberg@ericsson.com Thu Mar 31 23:56:12 2011 Return-Path: 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 9D8F53A6B04 for ; Thu, 31 Mar 2011 23:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 x++2HZJKvJ6o for ; Thu, 31 Mar 2011 23:56:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2723B3A6A46 for ; Thu, 31 Mar 2011 23:56:09 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-4e-4d95776d1f60 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BF.58.21265.D67759D4; Fri, 1 Apr 2011 08:57:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 1 Apr 2011 08:57:48 +0200 From: Christer Holmberg To: "Muthu ArulMozhi Perumal (mperumal)" , Hadriel Kaplan , mmusic Date: Fri, 1 Apr 2011 08:57:46 +0200 Thread-Topic: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? Thread-Index: AcvwAWdtQ+oOgn1/QH+21l+JdJh8dAAERjjQAAnZsoA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519491729BD@ESESSCMS0356.eemea.ericsson.se> References: <4D798594.4000406@cisco.com><0ed601cbe2ba$1bdfd740$539f85c0$@com><7F2072F1E0DE894DA4B517B93C6A05851948F0B315@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C65380492020513F33C@XMB-BGL-414.cisco.com><0e4201cbeebb$f527ea80$df77bf80$@com><1D062974A4845E4D8A343C65380492020513F8B0@XMB-BGL-414.cisco.com><00e001cbefad$c21e2fd0$465a8f70$@com> <0DE1F6C1-D2B1-4F6A-A0EF-B66281AF2BB0@acmepacket.com> <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020513FA08@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes? 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: , X-List-Received-Date: Fri, 01 Apr 2011 06:56:12 -0000 Hi, >The main goal of the draft as it seems to claim is to >describe the desirable behaviors of middleboxes and signaling >protocols that operate on the media path, to aid in >firewall/NAT traversal. It looks like an extension of RFC >3303 whose focus is also firewall and NAT traversal >use-cases. The draft claims that the architecture/functions >it describes is used in IMS and specified in 3GPP, TISPAN and >PacketCable specs -- if it true, then this is where the >recommendations in the draft would be useful I think. 3GPP already specifies NAT traversal etc behavior for their "SBCs". Regards, Christer > However, it doesn't look it would be useful for all B2BUA/SBC > use-cases/deployments -- if we want to make it, then I think > it would be a scope creep. > > Muthu > > |-----Original Message----- > |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > |Sent: Friday, April 01, 2011 5:42 AM > |To: mmusic > |Subject: Re: [MMUSIC] Continued WG interest inSDP > offer/answerwithmiddleboxes? > | > | > |Howdy, > |I read the draft, and also found the use of the term "ALG" to be > confusing and annoying. It's not > |just rfc3303 which defines an ALG as being in a inline/NAT > type device > - lots of the user market uses > |the term ALG for inline type as well. (it's basically a derogatory > term) One "SBC" vendor I know of > |arguably had a real SIP ALG, but they went defunct years ago. > | > |Then again, the drawings actually show the SIP-ALG+middlebox not > changing the SDP at all, so maybe > |they do mean ALG. > | > |But anyway... I don't mean to sound negative, but what's the > purpose of > this document? What do we > |think it's going to achieve if it's published as an RFC? > |The only "output" of this document are four "preliminary > recommendations". Of those four, I'd argue > |three of them are now wrong or misleading, and the remaining one is > unlikely to occur/help. It also > |claims to describe the impact on ICE, but doesn't; claims to propose > mechanisms to mitigate latching, > |but doesn't; doesn't describe the issues with middleboxes > and forked or > moved calls on early in-band > |media signaling; and uses terminology from ancient history (ie, RFC > 3303). > | > |So what's the point of this doc again? > | > |-hadriel > | > | > | > |On Mar 31, 2011, at 10:13 AM, Dan Wing wrote: > | > |>> -----Original Message----- > |>> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > |>> Sent: Thursday, March 31, 2011 1:01 PM > |>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, > Keith (Keith); > |>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic > |>> Subject: RE: [MMUSIC] Continued WG interest in SDP > |>> offer/answerwithmiddleboxes? > |>> > |>> I agree with your interpretation of what an SBC is. However, the > reason > |>> why I don't find anything wrong in the use of ALG in > |>> draft-ietf-mmusic-media-path-middleboxes is because it describes > |>> firewall and NAT traversal functions that are typically > implemented > as > |>> ALGs, except that these functions are decoupled into a > MIDCOM agent > and > |>> a middle box. In addition RFC 3303 goes on to say > (section 2.8) that > |>> MIDCOM agents are entities performing ALG functions, logically > external > |>> to a middlebox. It even says these agents can reside on a proxy. > |>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the > ALG > |>> in > |>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the > draft > |>> I think. > |> > |> If Figure 1 was modified to show a NAT or firewall, it could > reasonably > |> use the term ALG with those devices. > |> > |> But when showing an SBC, which is smack in the middle of > Figure 1, it > |> cannot accurately call the SBC a "SIP ALG", as it does right now. > |> > |> -d > |> > |> > |>> Muthu > |>> > |>> |-----Original Message----- > |>> |From: Dan Wing (dwing) > |>> |Sent: Wednesday, March 30, 2011 2:52 PM > |>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); > |>> 'DRAGE, Keith (Keith)'; 'Christer > |>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic' > |>> |Subject: RE: [MMUSIC] Continued WG interest in SDP > |>> offer/answerwithmiddleboxes? > |>> | > |>> |> -----Original Message----- > |>> |> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > |>> |> Sent: Tuesday, March 29, 2011 3:58 PM > |>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer > |>> Holmberg; > |>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic > |>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP > |>> |> offer/answerwithmiddleboxes? > |>> |> > |>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is > just > |>> an > |>> |> extension of RFC 3303 -- while the later describes the > middlebox > |>> |> communication architecture and framework, the former describes > some > |>> of > |>> |> the desirable behaviors of these middleboxes and protocols that > |>> operate > |>> |> on the media path unspecified in the later. RFC 3303 defines > what > |>> an > |>> |> ALG is and it doesn't forbid packets being addressed to the ALG > at > |>> the > |>> |> IP layer. > |>> |> > |>> |> > |>> |> 2.6. ALG > |>> |> Application Level Gateways (ALGs) are entities that > possess the > |>> |> application specific intelligence and knowledge of an > associated > |>> |> middlebox function. An ALG examines application traffic in > transit > |>> |> and assists the middlebox in carrying out its function. > |>> |> > |>> |> ALGs are different from proxies. ALGs are not visible to > end-hosts, > |>> |> unlike the proxies which are relay agents terminating sessions > with > |>> |> both end-hosts. ALGs do not terminate sessions with > either end- > |>> host. > |>> |> Instead, ALGs examine, and optionally modify, > application payload > |>> |> content to facilitate the flow of application traffic > through a > |>> |> middlebox. > |>> |> > |>> |> 2.8. MIDCOM Agents > |>> |> MIDCOM agents are entities performing ALG functions, logically > |>> |> external to a middlebox. > |>> |> > |>> |> The packets may be addressed to the agent node at the IP layer. > |>> |> Alternatively they may not be addressed to the agent node, but > may > |>> be > |>> |> constrained by other factors to flow through it. > |>> |> > |>> |> > |>> |> So, I don't see anything wrong in the use of ALG in > |>> |> draft-ietf-mmusic-media-path-middleboxes, unless we > plan to make > |>> |> changes to how RFC 3303 describes it. > |>> | > |>> |3303 is quite clear, in exactly the text you quoted in the > paragraph > |>> |starting with "ALGs are different from proxies", that > ALGs aren't > |>> |visible to hosts and ALGs don't terminate sessions. > |>> | > |>> |An SBC is certainly visible to the end host, for both the SIP > |>> |signaling and the RTP media -- the end host is sending > packets to > |>> |the SBC's IP address and receiving packets from the SBC's IP > |>> |address. > |>> | > |>> |-d > |>> | > |>> | > |>> |> Muthu > |>> |> > |>> |> |-----Original Message----- > |>> |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > On > |>> |> Behalf Of Parthasarathi R (partr) > |>> |> |Sent: Wednesday, March 16, 2011 6:15 PM > |>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing); > |>> |> Flemming > |>> |> Andreasen (fandreas); mmusic > |>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP > |>> |> offer/answerwithmiddleboxes? > |>> |> | > |>> |> |Keith, > |>> |> | > |>> |> |Sorry in case "media" word in my mail mislead you. > Dan explains > in > |>> |> |another mail thread > |>> |> > |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html) > |>> |> why > |>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for > this > |>> |> draft. > |>> |> | > |>> |> | > |>> |> |Fig 1 of > draft-ietf-mmusic-media-path-middleboxes-03.txt exactly > |>> fits > |>> |> |your definition of B2BUA as it involves only SIP & > SDP and media > is > |>> |> |defined as middlebox. > |>> |> | > |>> |> |I have mentioned as kind of B2BUA because the draft > concentrates > on > |>> |> |callflow where one side of B2BUA acts as UAC and other side > always > |>> |> acts > |>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC > |>> callflows > |>> |> |specific issues. In the current scope of draft is > continued for > the > |>> |> |draft, the new definition may be required or draft text has to > |>> clarify > |>> |> |the scope. > |>> |> | > |>> |> |Thanks > |>> |> |Partha > |>> |> | > |>> |> |-----Original Message----- > |>> |> |From: DRAGE, Keith (Keith) > [mailto:keith.drage@alcatel-lucent.com] > |>> |> |Sent: Wednesday, March 16, 2011 5:33 PM > |>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing > (dwing); > |>> |> |Flemming Andreasen (fandreas); mmusic > |>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP > offer/answer > |>> |> |withmiddleboxes? > |>> |> | > |>> |> |The only definition of B2BUA that I know of comes in RFC 3261 > (sort > |>> |> of) > |>> |> |where the scope is limited to SIP. So a UA acts in > one or more > |>> |> |directions as a SIP UA. Whatever else it does is outside the > |>> |> definition. > |>> |> |That I believe matches with what Christer is saying. > |>> |> | > |>> |> |If you want something that defines what it does with > media, then > |>> you > |>> |> |need something that defines that, but using the term > B2BUA to do > |>> that > |>> |> is > |>> |> |probably not the best choice. > |>> |> | > |>> |> |Regards > |>> |> | > |>> |> |Keith > |>> |> | > |>> |> |> -----Original Message----- > |>> |> |> From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] > On > |>> |> |> Behalf Of Parthasarathi R (partr) > |>> |> |> Sent: 15 March 2011 09:54 > |>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen > |>> |> |> (fandreas); mmusic > |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP > offer/answer > |>> with > |>> |> |> middleboxes? > |>> |> |> > |>> |> |> Christer, > |>> |> |> > |>> |> |> AFAIK, There is no restriction in terms of SIP > B2BUA to handle > |>> |> |> signaling only and it is upto the implementation to decide. > Also, > |>> |> this > |>> |> | > |>> |> |> draft does not have restriction that SIP B2BUA and media > server > |>> has > |>> |> to > |>> |> | > |>> |> |> be co-exist in the same device. The draft talks about the > |>> scenario > |>> |> |> wherein SIP B2BUA communicates with media server > using Megaco > |>> |> (H.248). > |>> |> |> > |>> |> |> As I mentioned in other mail thread, ALG does not look > |>> appropriate > |>> |> and > |>> |> | > |>> |> |> the draft is talking only about the specific type > of B2BUA. In > |>> real > |>> |> |> deployment, Few vendors named these sort of B2BUA > as "Session > |>> Border > |>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as > SBC > |>> does > |>> |> |> lot more. In case there is a need to have different name for > |>> these > |>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work > it > |>> out. > |>> |> |> > |>> |> |> Thanks > |>> |> |> Partha > |>> |> |> > |>> |> |> -----Original Message----- > |>> |> |> From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] > On > |>> |> |> Behalf Of Christer Holmberg > |>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM > |>> |> |> To: Dan Wing (dwing); Flemming Andreasen > (fandreas); 'mmusic' > |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP > offer/answer > |>> with > |>> |> |> middleboxes? > |>> |> |> > |>> |> |> > |>> |> |> Hi Dan, > |>> |> |> > |>> |> |> In my definition of an ALG packets can be sent > directly to its > IP > |>> |> |> address. > |>> |> |> > |>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG > also > |>> |> |> focuses on other things, like media. A SIP ALG > contains a SIP > |>> B2BUA. > |>> |> |> > |>> |> |> Regards, > |>> |> |> > |>> |> |> Christer > |>> |> |> > |>> |> |> -----Original Message----- > |>> |> |> From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] > On > |>> |> |> Behalf Of Dan Wing > |>> |> |> Sent: 15. maaliskuuta 2011 4:39 > |>> |> |> To: 'Flemming Andreasen'; 'mmusic' > |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP > offer/answer > |>> with > |>> |> |> middleboxes ? > |>> |> |> > |>> |> |> The draft uses the term "SIP ALG", which at least > does not fit > my > |>> |> |> definition of an ALG. An ALG doesn't have packets sent > directly > |>> to > |>> |> |> its IP address; it does its job stealthily without awareness > of > |>> one > |>> |> |> (or > |>> |> |> both) of the sessoin endpoints. In contrast, the function > |>> described > |>> |> |> in draft-ietf-mmusic-media-path-middleboxes > |>> |> |> is different -- packets are always sent to the IP address of > the > |>> SIP > |>> |> |> "ALG", and packets are sent from the IP address of the SIP > "ALG". > |>> |> |> This functionality is most often called a "server" > |>> |> |> or a "proxy" -- not an ALG. > |>> |> |> > |>> |> |> This distinction is important because this draft is closely > |>> related > |>> |> to > |>> |> | > |>> |> |> functions common in NATs, which _do_ sometimes have > SIP ALGs > |>> |> |> implemented in them. > |>> |> |> > |>> |> |> So ... can we change "SIP ALG" to something like "SIP proxy" > |>> |> |> or "SIP user agent" or "SIP Back-to-Back User > Agent"? Really, > it > |>> is > |>> |> a > |>> |> | > |>> |> |> B2BUA, at least as best I understand the definition of a > B2BUA, > |>> so > |>> |> |> B2BUA seems best. > |>> |> |> > |>> |> |> d > |>> |> |> > |>> |> |> > |>> |> |> > -----Original Message----- > |>> |> |> > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] > |>> On > |>> |> |> > Behalf Of Flemming Andreasen > |>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM > |>> |> |> > To: mmusic > |>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP > offer/answer > |>> with > |>> |> |> > middleboxes ? > |>> |> |> > > |>> |> |> > We currently have a MMUSIC milestone for > "considerations for > |>> using > |>> |> |> > SDP > |>> |> |> > |>> |> |> > offer/answer with middleboxes". The latest draft > for this WG > |>> item > |>> |> is > |>> |> |> > > |>> |> |> > draft-ietf-mmusic-media-path-middleboxes-03.txt > |>> |> |> > > |>> |> |> > which expired in January 2011. There hasn't been much > |>> discussion > |>> |> on > |>> |> |> > this topic for a while, and the current draft authors are > not > |>> |> |> > planning > |>> |> |> > |>> |> |> > continued work on the draft, so we need new authors if we > are > |>> to > |>> |> |> > continue with this WG item. Please let us know if > |>> |> |> > 1) You are still interested in this deliverable > |>> |> |> > 2) You are willing to actively contribute to and/or author > this > |>> |> |> > document. > |>> |> |> > > |>> |> |> > Thanks > |>> |> |> > > |>> |> |> > Flemming & Miguel [MMUSIC chairs] > |>> |> |> > > |>> |> |> > > |>> |> |> > _______________________________________________ > |>> |> |> > 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 > |>> |> |> _______________________________________________ > |>> |> |> 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 > |>> |> |_______________________________________________ > |>> |> |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 > | > |_______________________________________________ > |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 >