From bernard_aboba@hotmail.com Wed Jan 2 07:23:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3D321F85DA for ; Wed, 2 Jan 2013 07:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.813 X-Spam-Level: X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEg9fJxJYG94 for ; Wed, 2 Jan 2013 07:23:35 -0800 (PST) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by ietfa.amsl.com (Postfix) with ESMTP id 68EE521F85CC for ; Wed, 2 Jan 2013 07:23:35 -0800 (PST) Received: from BLU405-EAS355 ([65.55.111.71]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jan 2013 07:23:34 -0800 X-EIP: [zvvPafOJ6u6qVDoz1QWhqfmU3whbygwU] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_166aaf9b-28d6-48e2-bb0c-7dbc5441d10a_" References: From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 2 Jan 2013 07:24:27 -0800 To: Eric Rescorla X-OriginalArrivalTime: 02 Jan 2013 15:23:34.0622 (UTC) FILETIME=[214607E0:01CDE8FD] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 15:23:36 -0000 --_166aaf9b-28d6-48e2-bb0c-7dbc5441d10a_ Content-Type: multipart/alternative; boundary="Apple-Mail-A2465603-B896-410C-B025-08282D828110" Content-Transfer-Encoding: 7bit --Apple-Mail-A2465603-B896-410C-B025-08282D828110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a good agenda - for an MMUSIC WG interim (only day 3 has any RTCWEB i= tems on it). Since there is a notice requirement, can we get MMUSIC on board so the inter= im can actually take place? On Jan 2, 2013, at 7:13, "Eric Rescorla" wrote: > Chairs, >=20 > I've spent some time thinking about the agenda for the interim, and > thought it might be helpful if I sent you a strawman based on the > items that are blocking progress in terms of implementation and > interoperability. >=20 > Note: > I am assuming 4 hours each day. The times have been selected with > the objective of giving us enough time to really resolve the > open issues. Honestly, we might even add more time for > the issues on day 1. >=20 > Hope this is helpful. >=20 > Day 1 > 2:00 Bundle [Holmberg] > Objective: select an approach and work out enough > details that the editors can work to produce a > suitable draft. >=20 > Drafts: > - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiati= on > - http://tools.ietf.org/html/draft-alvestrand-one-rtp > - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiat= ion >=20 >=20 > 2:00 Multiple flow SDP representation [Jennings, Alvestrand] > Objective: decide on an architecture for large numbers > of similar streams (e.g., multiple video streams). >=20 > Drafts: > - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid > - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > - Do we have a "master" document for the single m-line case? > - Multiple m-lines doesn't have a document >=20 >=20 > Day 2 > 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] > Objective: determine requirements > =09 > =09 > 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] > =09 > - Starting checks > - Termination conditions > - Error handling > =09 > Drafts: > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle = =09 >=20 > 1:00 SDP for Datachannels open issues [Jesup, Loreto] > Objective: resolve open issues (post WGLC?) >=20 > Drafts: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 >=20 > Day 3 > 1:00 Other recommended audio codecs [Roach] > =09 > Objective: identify what other audio codecs we intend to > recommend.=09 >=20 > 1:00 Process WGLC comments on documents [authors] >=20 > 0:30 Other business >=20 > 0:30 Wrapup/next steps [Chairs] >=20 >=20 > Best, > -Ekr >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-A2465603-B896-410C-B025-08282D828110 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
This is a good agenda - for an MMUSIC WG interim (only day 3 has any RTCWEB items on it).

Since there is a notice requirement, can we get MMUSIC on board so the interim can actually take place?

On Jan 2, 2013, at 7:13, "Eric Rescorla" <ekr@rtfm.com> wrote:

Chairs,

I've spent some time thinking about the agenda for the interim, and
thought it might be helpful if I sent you a strawman based on the
items that are blocking progress in terms of implementation and
interoperability.

Note:
I am assuming 4 hours each day. The times have been selected with
the objective of giving us enough time to really resolve the
open issues. Honestly, we might even add more time for
the issues on day 1.

Hope this is helpful.

Day 1
2:00    Bundle   [Holmberg]
Objective: select an approach and work out enough
details that the editors can work to produce a
suitable draft.

Drafts:


2:00    Multiple flow SDP representation [Jennings, Alvestrand]
Objective: decide on an architecture for large numbers
of similar streams (e.g., multiple video streams).

Drafts:
- Do we have a "master" document for the single m-line case?
- Multiple m-lines doesn't have a document


Day 2
1:30    Mapping stream/track label concepts SDP identifiers [Alvestrand]
Objective: determine requirements
1:30    Trickle ICE open issues [Ivov(?), Uberti, Rescorla]
- Starting checks
- Termination conditions
- Error handling
Drafts:

1:00    SDP for Datachannels open issues [Jesup, Loreto]
Objective: resolve open issues (post WGLC?)

Drafts:

Day 3
1:00    Other recommended audio codecs [Roach]
Objective: identify what other audio codecs we intend to
recommend.

1:00    Process WGLC comments on documents [authors]

0:30    Other business

0:30    Wrapup/next steps [Chairs]


Best,
-Ekr

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-A2465603-B896-410C-B025-08282D828110-- --_166aaf9b-28d6-48e2-bb0c-7dbc5441d10a_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_166aaf9b-28d6-48e2-bb0c-7dbc5441d10a_-- From fluffy@cisco.com Wed Jan 2 10:18:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5784321F87E0; Wed, 2 Jan 2013 10:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es-KU2TqV854; Wed, 2 Jan 2013 10:18:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2316721F87D2; Wed, 2 Jan 2013 10:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3813; q=dns/txt; s=iport; t=1357150703; x=1358360303; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FMQEbzm5lpeppxQaEs3Vn1qUZzxvAP9MfcnLR+/9UDs=; b=mQaAMispodFCqwuMYUiJsyKI0tIAHQNOc/GAqAhmt2PgI1vLXRY6gBEV cKv1UG+L9Qz19ZA3XyqdpJv35xHpJVYC6QW21JmOI3OEwduXrJrcvheqR 4RR39VUHym72NJ83eOM2X9i+0AUmOeCz4t/WdPMtOboQg4Vb8PkSX/PlQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajg6AHh55FCtJV2d/2dsb2JhbAA7CoF/qHuSRxZzgh4BAQEDAQEBATc0CwULAgEIEgYKFBAnCxcOAgQOBQgTh2YDCQYMuQiLbXUGCoNHYQOUN4JxihuFEYJ0gXE1 X-IronPort-AV: E=Sophos;i="4.84,397,1355097600"; d="scan'208";a="157931308" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jan 2013 18:18:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r02IIMgH001565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 18:18:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 12:18:22 -0600 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] [rtcweb] Proposed Agenda for Interim Thread-Index: AQHN6RWLwHg6h8loV0m39uFY3MM6iQ== Date: Wed, 2 Jan 2013 18:18:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 18:18:25 -0000 I'm not really sure what to do here - given a key role of the chairs is lar= gely to facilitate the discussions and meetings that Wg participants want t= o have, guidance from participants of both MMUSIC and rtcweb is really imp= ortant here.=20 I agree that=20 1) the items in EKR's email do look like the a bunch of the high runner ite= ms that need to be resolved soon=20 2) the solutions of these problems are likely in to be mostly MMUSIC though= , as Ted has pointed out, some amount of the requirements, architecture and= other discussion can happen in rtcweb.=20 3) if we are going to have an MMUSIC face to face interim meeting, it would= need AD approval and 4 weeks notices which puts us very close do the deadl= ine so this needs to get sort out real soon.=20 Cullen On Jan 2, 2013, at 8:24 AM, Bernard Aboba wrote= : > This is a good agenda - for an MMUSIC WG interim (only day 3 has any RTCW= EB items on it). >=20 > Since there is a notice requirement, can we get MMUSIC on board so the in= terim can actually take place? >=20 > On Jan 2, 2013, at 7:13, "Eric Rescorla" wrote: >=20 >> Chairs, >>=20 >> I've spent some time thinking about the agenda for the interim, and >> thought it might be helpful if I sent you a strawman based on the >> items that are blocking progress in terms of implementation and >> interoperability. >>=20 >> Note: >> I am assuming 4 hours each day. The times have been selected with >> the objective of giving us enough time to really resolve the >> open issues. Honestly, we might even add more time for >> the issues on day 1. >>=20 >> Hope this is helpful. >>=20 >> Day 1 >> 2:00 Bundle [Holmberg] >> Objective: select an approach and work out enough >> details that the editors can work to produce a >> suitable draft. >>=20 >> Drafts: >> - http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation >> - http://tools.ietf.org/html/draft-alvestrand-one-rtp >> - http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation >>=20 >>=20 >> 2:00 Multiple flow SDP representation [Jennings, Alvestrand] >> Objective: decide on an architecture for large numbers >> of similar streams (e.g., multiple video streams). >>=20 >> Drafts: >> - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid >> - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid >> - Do we have a "master" document for the single m-line case? >> - Multiple m-lines doesn't have a document >>=20 >>=20 >> Day 2 >> 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] >> Objective: determine requirements >> =09 >> =09 >> 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] >> =09 >> - Starting checks >> - Termination conditions >> - Error handling >> =09 >> Drafts: >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle =09 >>=20 >> 1:00 SDP for Datachannels open issues [Jesup, Loreto] >> Objective: resolve open issues (post WGLC?) >>=20 >> Drafts: >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 >>=20 >> Day 3 >> 1:00 Other recommended audio codecs [Roach] >> =09 >> Objective: identify what other audio codecs we intend to >> recommend.=09 >>=20 >> 1:00 Process WGLC comments on documents [authors] >>=20 >> 0:30 Other business >>=20 >> 0:30 Wrapup/next steps [Chairs] >>=20 >>=20 >> Best, >> -Ekr >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ted.ietf@gmail.com Wed Jan 2 10:39:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9211821F842D; Wed, 2 Jan 2013 10:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acPp7YV5Db6s; Wed, 2 Jan 2013 10:39:53 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 865AB21F882C; Wed, 2 Jan 2013 10:39:53 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so12149004iad.13 for ; Wed, 02 Jan 2013 10:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9zcC0yH3yAyzhR8CR+FxtJRvB3M3PQus43EUA3qmTR8=; b=0y2xVDmm1QbEddiPQIwowav64yW11UME1AX9x5kUHmZ2n/JA6EJ1dbHfdrvZzOxakT ivyIpR9Nn6DkTsxvrkmaYDJYNWzyNKEF9hMe0Os/kzSD6FNrvurvnxcJnxZTtvimx8Uf aXAgrOUuwOPvorjA65rENEuCzcwboBN85FF+LHzokayKNezVHWv5AeR1Hi27KIxPqBZz 0+zX2f2gEhHmJ7pqnsOxX/oOrU4iqN3jIOE1gVE96WmtpY1W1gSbSTRxxveZUTqMVzQW uXebon9WB4a5u+ZNPjWi4pgQbgHujO461bwGBlN9Djpe817RsL+FB6qnjA23bFcSbN6X w+sg== MIME-Version: 1.0 Received: by 10.42.48.147 with SMTP id s19mr35287128icf.18.1357151993111; Wed, 02 Jan 2013 10:39:53 -0800 (PST) Received: by 10.43.94.5 with HTTP; Wed, 2 Jan 2013 10:39:53 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Jan 2013 10:39:53 -0800 Message-ID: From: Ted Hardie To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=90e6ba1efbc274a4e504d2529282 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 18:39:54 -0000 --90e6ba1efbc274a4e504d2529282 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 2, 2013 at 10:18 AM, Cullen Jennings (fluffy) wrote: > > 2) the solutions of these problems are likely in to be mostly MMUSIC > though, as Ted has pointed out, some amount of the requirements, > architecture and other discussion can happen in rtcweb. > > I actually believe it can go beyond requirements and architecture; I believe that if RTCWEB can come to a firm understanding of what solutions are best for its use cases, it can communicate that to MMUSIC. That doesn't mean the final decision doesn't rest with MMUSIC--it does--but it does mean that RTCWEB doesn't have to leave the technology discussion completely off the table. A good analysis can go to MMUSIC for discussion and potential resolution in/by Orlando. 3) if we are going to have an MMUSIC face to face interim meeting, it would > need AD approval and 4 weeks notices which puts us very close do the > deadline so this needs to get sort out real soon. > > There is also the option of a virtual interim, which is (somewhat) less of a logistical issue. Ted > Cullen > > > > On Jan 2, 2013, at 8:24 AM, Bernard Aboba > wrote: > > > This is a good agenda - for an MMUSIC WG interim (only day 3 has any > RTCWEB items on it). > > > > Since there is a notice requirement, can we get MMUSIC on board so the > interim can actually take place? > > > > On Jan 2, 2013, at 7:13, "Eric Rescorla" wrote: > > > >> Chairs, > >> > >> I've spent some time thinking about the agenda for the interim, and > >> thought it might be helpful if I sent you a strawman based on the > >> items that are blocking progress in terms of implementation and > >> interoperability. > >> > >> Note: > >> I am assuming 4 hours each day. The times have been selected with > >> the objective of giving us enough time to really resolve the > >> open issues. Honestly, we might even add more time for > >> the issues on day 1. > >> > >> Hope this is helpful. > >> > >> Day 1 > >> 2:00 Bundle [Holmberg] > >> Objective: select an approach and work out enough > >> details that the editors can work to produce a > >> suitable draft. > >> > >> Drafts: > >> - > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > >> - http://tools.ietf.org/html/draft-alvestrand-one-rtp > >> - > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > >> > >> > >> 2:00 Multiple flow SDP representation [Jennings, Alvestrand] > >> Objective: decide on an architecture for large numbers > >> of similar streams (e.g., multiple video streams). > >> > >> Drafts: > >> - http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid > >> - http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > >> - Do we have a "master" document for the single m-line case? > >> - Multiple m-lines doesn't have a document > >> > >> > >> Day 2 > >> 1:30 Mapping stream/track label concepts SDP identifiers [Alvestrand] > >> Objective: determine requirements > >> > >> > >> 1:30 Trickle ICE open issues [Ivov(?), Uberti, Rescorla] > >> > >> - Starting checks > >> - Termination conditions > >> - Error handling > >> > >> Drafts: > >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle > >> > >> 1:00 SDP for Datachannels open issues [Jesup, Loreto] > >> Objective: resolve open issues (post WGLC?) > >> > >> Drafts: > >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 > >> > >> Day 3 > >> 1:00 Other recommended audio codecs [Roach] > >> > >> Objective: identify what other audio codecs we intend to > >> recommend. > >> > >> 1:00 Process WGLC comments on documents [authors] > >> > >> 0:30 Other business > >> > >> 0:30 Wrapup/next steps [Chairs] > >> > >> > >> Best, > >> -Ekr > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > 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 > --90e6ba1efbc274a4e504d2529282 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 2, 2013 at 10:18 AM, Cullen Jennings (fluffy) <fluffy@cisco.com= > wrote:

2) the solutions of these problems are likely in to be mostly MMUSIC though= , as Ted has pointed out, some amount of the requirements, architecture and= other discussion can happen in rtcweb.


I actually believe it can go beyond requirements = and architecture; I believe that if RTCWEB can come to a firm understanding= of what solutions are best for its use cases, it can communicate that to M= MUSIC.=A0 That doesn't mean the final decision doesn't rest with MM= USIC--it does--but it does mean that RTCWEB doesn't have to leave the t= echnology discussion completely off the table.=A0 A good analysis can go to= MMUSIC for discussion and potential resolution in/by Orlando.

3) if we are going to have an MMUSIC face to face interim meeting, it would= need AD approval and 4 weeks notices which puts us very close do the deadl= ine so this needs to get sort out real soon.


There is also the option of a virtual interim, wh= ich is (somewhat) less of a logistical issue.

Ted

=A0
Cullen



On Jan 2, 2013, at 8:24 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> This is a good agenda - for an MMUSIC WG interim (only day 3 has any R= TCWEB items on it).
>
> Since there is a notice requirement, can we get MMUSIC on board so the= interim can actually take place?
>
> On Jan 2, 2013, at 7:13, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
>> Chairs,
>>
>> I've spent some time thinking about the agenda for the interim= , and
>> thought it might be helpful if I sent you a strawman based on the<= br> >> items that are blocking progress in terms of implementation and >> interoperability.
>>
>> Note:
>> I am assuming 4 hours each day. The times have been selected with<= br> >> the objective of giving us enough time to really resolve the
>> open issues. Honestly, we might even add more time for
>> the issues on day 1.
>>
>> Hope this is helpful.
>>
>> Day 1
>> 2:00 =A0 =A0Bundle =A0 [Holmberg]
>> =A0 =A0 =A0Objective: select an approach and work out enough
>> =A0 =A0 =A0details that the editors can work to produce a
>> =A0 =A0 =A0suitable draft.
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0- http://tools.ietf.org/html/dra= ft-ietf-mmusic-sdp-bundle-negotiation
>> =A0 =A0 =A0- http://tools.ietf.org/html/draft-alvestrand-on= e-rtp
>> =A0 =A0 =A0- http://tools.ietf.org/html/dr= aft-holmberg-mmusic-sdp-mmt-negotiation
>>
>>
>> 2:00 =A0 =A0Multiple flow SDP representation [Jennings, Alvestrand= ]
>> =A0 =A0 =A0Objective: decide on an architecture for large numbers<= br> >> =A0 =A0 =A0of similar streams (e.g., multiple video streams).
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0- http://tools.ietf.org/html/draft-alvestran= d-rtcweb-msid
>> =A0 =A0 =A0- http://tools.ietf.org/html/draft-alvestran= d-mmusic-msid
>> =A0 =A0 =A0- Do we have a "master" document for the sing= le m-line case?
>> =A0 =A0 =A0- Multiple m-lines doesn't have a document
>>
>>
>> Day 2
>> 1:30 =A0 =A0Mapping stream/track label concepts SDP identifiers [A= lvestrand]
>> =A0 =A0 =A0Objective: determine requirements
>>
>>
>> 1:30 =A0 =A0Trickle ICE open issues [Ivov(?), Uberti, Rescorla] >>
>> =A0 =A0 =A0- Starting checks
>> =A0 =A0 =A0- Termination conditions
>> =A0 =A0 =A0- Error handling
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0http://tools.ietf.org/html/draft-rescor= la-mmusic-ice-trickle
>>
>> 1:00 =A0 =A0SDP for Datachannels open issues [Jesup, Loreto]
>> =A0 =A0 =A0Objective: resolve open issues (post WGLC?)
>>
>> =A0 =A0 =A0Drafts:
>> =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-mmusi= c-sctp-sdp-02
>>
>> Day 3
>> 1:00 =A0 =A0Other recommended audio codecs [Roach]
>>
>> =A0 =A0 =A0Objective: identify what other audio codecs we intend t= o
>> =A0 =A0 =A0recommend.
>>
>> 1:00 =A0 =A0Process WGLC comments on documents [authors]
>>
>> 0:30 =A0 =A0Other business
>>
>> 0:30 =A0 =A0Wrapup/next steps [Chairs]
>>
>>
>> Best,
>> -Ekr
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> <Mail Attachment.txt>_______________________________= ________________
> 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

--90e6ba1efbc274a4e504d2529282-- From fluffy@cisco.com Wed Jan 2 11:10:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666D621F876E for ; Wed, 2 Jan 2013 11:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.884 X-Spam-Level: X-Spam-Status: No, score=-109.884 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVLeAZiLo1+Q for ; Wed, 2 Jan 2013 11:10:54 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C917D21F86F5 for ; Wed, 2 Jan 2013 11:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=152; q=dns/txt; s=iport; t=1357153855; x=1358363455; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=pOQJEeHn65VdapFRI29m6ZCVyaz4cg4Co5FFVmSQBrQ=; b=Wo4namu/LAPXM5aauBNzzEIJ6DyTGGfXneez3RSqXF6a0hTFDU5s+7IV BSSzKjFGiQT15TMl76BTdfqUzyPOfCxs5ryg/OhjyhizjtfTyPaEk6paP 8cEFTXlBLwszpeoqumPv/h7mc49thX+m+5rbtqOW+h6972ScxFRVVZamh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ahs6AIuF5FCtJV2b/2dsb2JhbABFgX+7QhZzgiABBDpRASoUQicEG4gLmV2dOYxig1dhA6ZUgnSBcTU X-IronPort-AV: E=Sophos;i="4.84,397,1355097600"; d="scan'208";a="157952970" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jan 2013 19:10:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r02JAs4s025265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jan 2013 19:10:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 13:10:54 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" Thread-Topic: Test Thread-Index: AQHN6Rzi2/m4/vFH/kmQRXF5PB1gkQ== Date: Wed, 2 Jan 2013 19:10:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Test X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 19:10:55 -0000 Please ignore this email. Sorry ( I am seeing weird errors from on AMS on stuff to mmusic email and needed= a clean message to track it down). From bernard_aboba@hotmail.com Wed Jan 2 11:44:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F3B21F8599; Wed, 2 Jan 2013 11:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXpAS1CwqfTv; Wed, 2 Jan 2013 11:44:54 -0800 (PST) Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35321F8586; Wed, 2 Jan 2013 11:44:54 -0800 (PST) Received: from BLU002-W7 ([65.55.111.136]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jan 2013 11:44:53 -0800 X-EIP: [NyO8EK/9r68p5QizMTZGDvctraal+VAi] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b4c74f88-3437-42e5-bbaf-f211f88f3d32_" From: Bernard Aboba To: "Cullen Jennings (fluffy)" Date: Wed, 2 Jan 2013 11:44:53 -0800 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jan 2013 19:44:53.0584 (UTC) FILETIME=[A2A9C500:01CDE921] Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 19:44:55 -0000 --_b4c74f88-3437-42e5-bbaf-f211f88f3d32_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said: "3) if we are going to have an MMUSIC face to face interim meeting=2C it wo= uld need AD approval and 4 weeks notices which puts us very close do the de= adline so this needs to get sort out real soon. " [BA] I see no particularly good reason why this can't happen quickly. In = fact=2C why not schedule two MMUSIC interims=2C 4-6 weeks apart from each o= ther? If travel is an issue=2C they can be virtual. EKR's=0A= issue list is a fine starting point=2C and there is an informal IESG =0A= telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. =20 Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch= =2C but really=2C MMUSIC WG has to develop a sense of urgency on this. If = things keep going as they have=2C by the time we get published RFCs out of = MMUSIC=2C implementations will have been in the field for years. =20 If MMUSIC were a Hollywood Celebrity=2C we'd be *way* past the time for "to= ugh love" and on the front page of the National Enquirer for the Nth time.= =20 = --_b4c74f88-3437-42e5-bbaf-f211f88f3d32_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said:

"3) if we ar= e going to have an MMUSIC face to face interim meeting=2C it would need AD = approval and 4 weeks notices which puts us very close do the deadline so th= is needs to get sort out real soon. "

[BA] I see no particularl= y good reason why this can't =3B happen quickly. =3B In fact=2C why= not schedule two MMUSIC interims=2C 4-6 weeks apart from each other? = =3B If travel is an issue=2C they can be virtual. =3B EKR's=0A= issue list is a fine starting point=2C and there is an informal IESG =0A= telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. =3B

Te= d's suggestion (to cover this in the RTCWEB interim) might do in a pinch=2C= but really=2C MMUSIC WG has to develop a sense of urgency on this. =3B= If things keep going as they have=2C by the time we get published RFCs out= of MMUSIC=2C =3B implementations will have been in the field for years= . =3B

If MMUSIC were a Hollywood Celebrity=2C we'd be *way* pas= t the time for "tough love" and on the front page of the National Enquirer = for the Nth time.



= --_b4c74f88-3437-42e5-bbaf-f211f88f3d32_-- From ekr@rtfm.com Wed Jan 2 14:26:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73C921F8689 for ; Wed, 2 Jan 2013 14:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYvlvpoQZTZ6 for ; Wed, 2 Jan 2013 14:26:13 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 01EF521F8682 for ; Wed, 2 Jan 2013 14:26:12 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id xn12so13343755obc.18 for ; Wed, 02 Jan 2013 14:26:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=REwDfsEi54hEVPDRga3PPXIyCZ5fHORLFfFRPcNdGpA=; b=l/PoctmY37+xOSJjEWFeTx+0tsq6OoCh4DOAUixP1OcbufYaiF0wBo1Vh9FNblS++R wM1+0eyKGrZk7LJ7xF7znq2bwi0cKF/fUhL0bV7askr3e1kBCgg0NY3IUk8u87Mj+esa p3Jw1pRHXMaYV68cMqC6mwkP5KaHavGdk+nN9/EgoPTaJuGtB3U3tlqOAIZFvQ3gcATw +U8KuWqt4UwJIYTTnH1TeGmAduHG0bKa+kISIk2mHwMmuElFlawrXOSFAHEgpp6Xh96B TbmONZej2HVkgGjSz6tBdsUuQbkGaOg+fTBzrkycpQFhmkPYPpsfbWt5srRJY9P21xso u+FQ== Received: by 10.182.164.103 with SMTP id yp7mr38041024obb.74.1357165572474; Wed, 02 Jan 2013 14:26:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.77.225 with HTTP; Wed, 2 Jan 2013 14:25:32 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 2 Jan 2013 14:25:32 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=e89a8f643556d946dd04d255bb0a X-Gm-Message-State: ALoCoQmyPLoS22jN0UXabp9MBIUvIqL1De6onUrG+0M/nrBftSAy/Yf7QSBYUOIqzzbhCsGNASX6 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 22:26:13 -0000 --e89a8f643556d946dd04d255bb0a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 2, 2013 at 11:44 AM, Bernard Aboba wrote: > Cullen said: > > "3) if we are going to have an MMUSIC face to face interim meeting, it > would need AD approval and 4 weeks notices which puts us very close do the > deadline so this needs to get sort out real soon. " > > [BA] I see no particularly good reason why this can't happen quickly. In > fact, why not schedule two MMUSIC interims, 4-6 weeks apart from each > other? If travel is an issue, they can be virtual. EKR's issue list is a > fine starting point, and there is an informal IESG telechat tomorrow > (3-Jan) as well as one on 10-Jan-2013. > I'm not in principle opposed to "virtual" interims, but my general feeling is that we should be using face-to-face time to cover the most important and intractable issues. ISTM that those are the ones that I listed in my email. Accordingly, I don't think it makes sense to have virtual MMUSIC interims to discuss the important stuff and a F2F RTCWEB interim to discuss the rest... -Ekr Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch, > but really, MMUSIC WG has to develop a sense of urgency on this. If things > keep going as they have, by the time we get published RFCs out of MMUSIC, > implementations will have been in the field for years. > > If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for > "tough love" and on the front page of the National Enquirer for the Nth > time. > > > > --e89a8f643556d946dd04d255bb0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 2, 2013 at 11:44 AM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
Cullen said:

"3) if we = are going to have an MMUSIC face to face interim meeting, it would need AD = approval and 4 weeks notices which puts us very close do the deadline so th= is needs to get sort out real soon. "

[BA] I see no particularly good reason why this can't=A0= happen quickly.=A0 In fact, why not schedule two MMUSIC interims, 4-6 week= s apart from each other?=A0 If travel is an issue, they can be virtual.=A0 = EKR's issue list is a fine starting point, and there is an informal IESG=20 telechat tomorrow (3-Jan) as well as one on 10-Jan-2013.=A0
=

I'm not in principle opposed to = "virtual" interims, but my general feeling is
that we s= hould be using face-to-face time to cover the most important and
intractable issues. ISTM that those are the ones that I listed in my e= mail.

Accordingly, I don't think it makes sens= e to have virtual MMUSIC interims
to discuss the important stuff = and a F2F RTCWEB interim to discuss the
rest...

-Ekr


Ted's sugg= estion (to cover this in the RTCWEB interim) might do in a pinch, but reall= y, MMUSIC WG has to develop a sense of urgency on this.=A0 If things keep g= oing as they have, by the time we get published RFCs out of MMUSIC,=A0 impl= ementations will have been in the field for years.=A0

If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time f= or "tough love" and on the front page of the National Enquirer fo= r the Nth time.




--e89a8f643556d946dd04d255bb0a-- From dwing@cisco.com Wed Jan 2 19:29:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C718B21F88B0 for ; Wed, 2 Jan 2013 19:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.562 X-Spam-Level: X-Spam-Status: No, score=-109.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y37f3-2pA852 for ; Wed, 2 Jan 2013 19:29:42 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BD07321F8881 for ; Wed, 2 Jan 2013 19:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8503; q=dns/txt; s=iport; t=1357183782; x=1358393382; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=2NgsLCuvqynBg75Y98ilGWu/6tGN3BiuOVjQ3J2Tfws=; b=QIx/LVXexkKJ4/OkmZSSqA6LilR62Ad/fxfxjJEC2+CZgGFbw9fFf7GK bApBpx9W5pdcUW1Y7h1Y5FboW9iabaYXpA1YxE+ZZ0aRts209UM8KPXgX SnRFNLorjuy7jScODHUxr49wVKoJkXq3eBPB1aqWxaHbmvKRXfkUfYwul M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMHABn65FCrRDoG/2dsb2JhbABFDoFxgUm5fxZzgh4BAQEDAQEBAQUCMC0EAwQHBQcBAwIJDgMEAQEBJwcZDh8JCAIEEwkCBYd9BQ23WYxXFQaEKAOIYoUciA6QSII2X4FHCRc X-IronPort-AV: E=Sophos;i="4.84,400,1355097600"; d="scan'208";a="65276418" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Jan 2013 03:29:42 +0000 Received: from DWINGWS01 (sjc-vpn1-1104.cisco.com [10.21.100.80]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r033TfGR032057; Thu, 3 Jan 2013 03:29:41 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com><50C786C8.2010403@alum.mit.edu><023f01cdd7d5$48e33c70$daa9b550$@cisco.com> <1.3e69ec2c964b01899213@alum.mit.edu> In-Reply-To: <1.3e69ec2c964b01899213@alum.mit.edu> Date: Wed, 2 Jan 2013 19:29:41 -0800 Message-ID: <01ee01cde962$91728240$b45786c0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAHHwb56AgT7b64CgjKumZf5o70A Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 03:29:43 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, December 11, 2012 12:20 PM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > Inline > > On 12/11/12 2:25 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Tuesday, December 11, 2012 11:17 AM > >> To: Dan Wing > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >> > >> Hi Dan, > >> > >> Comments inline > >> > >> On 12/11/12 1:53 PM, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Tuesday, December 11, 2012 7:43 AM > >>>> To: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >>>> > >>>> More inline. > >>>> > >>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: > >>>>> Hi Paul, > >>>>> > >>>>> see in line! > >>>>> > >>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >>>>>> Commenting on a different point > >>>>>> > >>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >>>>>> > >>>>>>> The interesting difference is that the multiplexing between > >>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP > >>>>>>> traffic is not carried in SSRCs, which means: > >>>>>>> > >>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may > >>>>>>> have multiple associations, as you state below); you can't have > >>>>>>> multiple lines with proto DTLS/SCTP in a bundle. > >>>>>> > >>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run > >>>>>> directly over IP. It has its own notion of port used to demux > >>>>>> multiple SCTP associations over the same IP address. > >>>>>> > >>>>>> I presume that that same mechanism is still there when SCTP is > >>>>>> run over DTLS over UDP. > >>>>>> > >>>>>> So, the traffic coming over DTLS must first be demuxed into RTP > >>>>>> traffic and SCTP traffic. > >>>>> based on the current stack the SCTP traffic is the only traffic > >>>>> that runs directly over the DTLS stack. > >>>> > >>>> Yes, that is what I thought. But Harald has been asking about > >>>> multiplexing this with RTP traffic. (Actually I think it would be > >>>> DTLS/SRTP traffic that it would be multiplexed with.) > >>>> > >>>>> What I am trying to do is to include the Randell Jesup (I am > >>>>> including him in CC as I am not sure he is subscribed to this > >> mailing list) > >>>>> suggestion to give the possibility to have multiple SCTP > >>>>> *associations* running on top of the same DTLS session and of > >>>>> course providing a way to signal it in SDP. > >>>> > >>>> IIUC, SCTP (having been designed as a transport layer protocol) > >>>> defines its own notion of port, and has fields in its protocol to > >>>> carry the local and remote port number. Presumably those fields are > >>>> still there when run over UDP or DTLS. So it should be possible to > >>>> support multiple SCTP associations over the same DTLS connection, > >>>> each distinguished by its own port pair. > >>> > >>> Yes, SCTP has its own notion of ports. How this works when SCTP is > >>> carried over UDP is not quite clear, especially because SCTP assumes > >>> a NAPT will not rewrite the SCTP port number (SCTP endeavors to make > >>> such port rewriting difficult). But of course a NAPT (and the MAP > >>> techniques) rewrite UDP port numbers. I believe SCTP would only be > >>> able to successfully convey its UDP port numbers for a device that > >>> is not behind a NAT (that is, a server sitting directly on the > >>> Internet, rather than a remote peer that is behind a NAT). Creative > >>> use of PCP, NAT-PMP, or UPnP IGD would improve that situation in the > future. > >> > >> I find what you say above confusing. > > > > It is confusing, because SCTP's specifications require different > > things of a NAPT than UDP, TCP, or DCCP. Specifically, SCTP's > > specifications require the NAPT to not rewrite (not change) the source > > port number of outgoing SCTP-over-IP packets. Reference > > draft-ietf-behave-sctpnat. > > > >> SCTP running naked over IP would still have its own ports. > >> If that ran over a path with a NAPT, then I could see why the NAPT > >> might want to do the same as it does with UDP and TCP, and so replace > >> addr/port pairs to minimize addr usage. (That's if the NAPT supported > >> SCTP at all - I gather most don't.) > > > > I am not aware of any shipping NAPT that supports SCTP. > > > > > >> But with SCTP over DTLS over UDP, there is a UDP port, and then > >> presumably a separate SCTP port carried in the SCTP protocol within > >> the UDP message. > > > > Right. > > > > And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some > > relationship, but I do not understand how it works. Reference > > draft-ietf-tsvwg-sctp-udp-encaps. > > 1) draft-ietf-tsvwg-sctp-udp-encaps doesn't seem to cover SCTP over DTLS > > 2) I guess that would only apply for a kernel implementation of SCTP > over UDP, accessed via the socket interface. > > So I don't think it is relevant for the immediate future plans for user > mode implementations over UDP. The SCTP_REMOTE_UDP_ENCAPS_PORT socket option exists in the user-mode implementation, per the middle of this thread, http://www.ietf.org/mail-archive/web/rtcweb/current/msg03302.html > >> An NAPT on the path would presumably be messing with the UDP port. > >> Given use of DTLS, the NAPT won't even be able to tell that SCTP is > >> being used, much less mess with the SCTP port. > > > > Right. > > > >>>> That of course depends on having a signaling mechanism to set it > up. > >>> > >>> After the initial SCTP association is created, SCTP could be allowed > >>> to do its own thing (that is, chose to find and use other ports). > >> > >> Here you are talking about finding and using other UDP addr/port > pairs? > > > > Yes, for mobility. > > > >> That is explicitly excluded in the DTLS/SCTP mapping. > > > > I am thinking about where to layer mobility and multipath for RTP > > (MPRTP) and for SCTP. Do we do that with MICE > > (draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself? If > > we do it with MICE, we need to disable or prevent SCTP from adding / > > removing interfaces itself, which is why SCTP includes its own ability > > to signal IP addresses and ports in SCTP itself. > > OK. That will require extensions here and there over what drafts > currently say. Yeah, but requires first deciding what layer is best for such mobility. -d > Thanks, > Paul > > > -d > > > > > >> Thanks, > >> Paul > >> > >>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP), > >>> but of course they are not identical. > >>> > >>>>> to be clear: at moment WebRTC allows only one SCTP association per > >>>>> PC, so this is something that would be nice to define just to be > >>>>> ready for the future. > >>>> > >>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP > >>>> mechanism shouldn't be limited by the constraints of WebRTC. It > >>>> would be very difficult to define the SDP so that it was impossible > >>>> to set up multiple SCTP associations over different 5-tuples. > >>>> > >>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP > >>>>>> traffic can be demuxed based on SCTP port. And once the traffic > >>>>>> for a single SCTP port is identified, it can be demuxed based on > >>>>>> stream > >> number. > >>>>>> > >>>>>> Representing this in SDP is a challenge. Some variant of the > >>>>>> bundle proposal might allow bundling together several RTP m-lines > >>>>>> and some DTLS/SCTP m-lines. This would require a mechanism for > >>>>>> specifying the SCTP port number - already an open issue (#3) in > >>>>>> draft-ietf-mmusic-sctp-sdp-02. > >>>>> I agree that it is a challange how then to bundle everything > >>>>> together > >>>> > >>>> But it is a challenge that needs to be tackled if we are to realize > >>>> Harald's dream. > >>> > >>> -d > >>> > >>> > >>> > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From dwing@cisco.com Wed Jan 2 19:32:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197621F8889 for ; Wed, 2 Jan 2013 19:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.451 X-Spam-Level: X-Spam-Status: No, score=-109.451 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KNCuKpfaFag for ; Wed, 2 Jan 2013 19:32:24 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBED21F8881 for ; Wed, 2 Jan 2013 19:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6363; q=dns/txt; s=iport; t=1357183944; x=1358393544; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Cp9+0jtBvMVxzFch2Zr2lQWte1T/pWcqwpdvNnBLclo=; b=C8iXUdwpE5dAlv4kimdPadj9wahgKDvDbW+wF/9/EGEbXS3OIXqGsBTe EjJ8j1ouwhMplGD4wT8BURXyShiSWLAXvQB9SZoXE1fNVl2xKyPDpOKiB Yzjq89FQ/wmjLtx4t1Reuevlw0jiu+azAgnlh2yIObG5WnXaMsG3suQQ2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMHAHf75FCrRDoH/2dsb2JhbABFDoFxgUm5fxZzgh4BAQEDAQEBAQUCMC0EAwsFBwEDAgkOAwQBAQEnBxkOHwkIAgQTCwWHfQUNt1QEjFcVhC4DiGKFHIgOkEiCNl+BRw X-IronPort-AV: E=Sophos;i="4.84,400,1355097600"; d="scan'208";a="67776763" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 03 Jan 2013 03:32:24 +0000 Received: from DWINGWS01 (sjc-vpn1-1104.cisco.com [10.21.100.80]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r033WNCe009985; Thu, 3 Jan 2013 03:32:23 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> In-Reply-To: <1.c8c3cdc026cf630fdfa4@alum.mit.edu> Date: Wed, 2 Jan 2013 19:32:23 -0800 Message-ID: <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAJlqPoImBjuxiA= Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 03:32:25 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, December 11, 2012 11:17 AM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > Hi Dan, > > Comments inline > > On 12/11/12 1:53 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Tuesday, December 11, 2012 7:43 AM > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >> > >> More inline. > >> > >> On 12/11/12 4:08 AM, Salvatore Loreto wrote: > >>> Hi Paul, > >>> > >>> see in line! > >>> > >>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >>>> Commenting on a different point > >>>> > >>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >>>> > >>>>> The interesting difference is that the multiplexing between > >>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP > >>>>> traffic is not carried in SSRCs, which means: > >>>>> > >>>>> - There can be only one DTLS/SCTP stream in a bundle (which may > >>>>> have multiple associations, as you state below); you can't have > >>>>> multiple lines with proto DTLS/SCTP in a bundle. > >>>> > >>>> I am not an SCTP expert. But IIUC, SCTP was designed to run > >>>> directly over IP. It has its own notion of port used to demux > >>>> multiple SCTP associations over the same IP address. > >>>> > >>>> I presume that that same mechanism is still there when SCTP is run > >>>> over DTLS over UDP. > >>>> > >>>> So, the traffic coming over DTLS must first be demuxed into RTP > >>>> traffic and SCTP traffic. > >>> based on the current stack the SCTP traffic is the only traffic that > >>> runs directly over the DTLS stack. > >> > >> Yes, that is what I thought. But Harald has been asking about > >> multiplexing this with RTP traffic. (Actually I think it would be > >> DTLS/SRTP traffic that it would be multiplexed with.) > >> > >>> What I am trying to do is to include the Randell Jesup (I am > >>> including him in CC as I am not sure he is subscribed to this > >>> mailing list) suggestion to give the possibility to have multiple > >>> SCTP > >>> *associations* running on top of the same DTLS session and of course > >>> providing a way to signal it in SDP. > >> > >> IIUC, SCTP (having been designed as a transport layer protocol) > >> defines its own notion of port, and has fields in its protocol to > >> carry the local and remote port number. Presumably those fields are > >> still there when run over UDP or DTLS. So it should be possible to > >> support multiple SCTP associations over the same DTLS connection, > >> each distinguished by its own port pair. > > > > Yes, SCTP has its own notion of ports. How this works when SCTP is > > carried over UDP is not quite clear, especially because SCTP assumes a > > NAPT will not rewrite the SCTP port number (SCTP endeavors to make > > such port rewriting difficult). But of course a NAPT (and the MAP > > techniques) rewrite UDP port numbers. I believe SCTP would only be > > able to successfully convey its UDP port numbers for a device that is > > not behind a NAT (that is, a server sitting directly on the Internet, > > rather than a remote peer that is behind a NAT). Creative use of PCP, > > NAT-PMP, or UPnP IGD would improve that situation in the future. > > I find what you say above confusing. > > SCTP running naked over IP would still have its own ports. > If that ran over a path with a NAPT, then I could see why the NAPT might > want to do the same as it does with UDP and TCP, and so replace > addr/port pairs to minimize addr usage. (That's if the NAPT supported > SCTP at all - I gather most don't.) As I mentioned earlier, SCTP does not allow its source port number to be changed. > But with SCTP over DTLS over UDP, there is a UDP port, and then > presumably a separate SCTP port carried in the SCTP protocol within the > UDP message. Yep, I assume that is how it works. Effectively, UDP is just used to tunnel the SCTP. > An NAPT on the path would presumably be messing with the UDP port. Given > use of DTLS, the NAPT won't even be able to tell that SCTP is being > used, much less mess with the SCTP port. > > >> That of course depends on having a signaling mechanism to set it up. > > > > After the initial SCTP association is created, SCTP could be allowed > > to do its own thing (that is, chose to find and use other ports). > > Here you are talking about finding and using other UDP addr/port pairs? No, I was referring to the SCTP ports. -d > That is explicitly excluded in the DTLS/SCTP mapping. > > Thanks, > Paul > > > SCTP's behavior in this regard is similar to MPRTP (multipath RTP), > > but of course they are not identical. > > > >>> to be clear: at moment WebRTC allows only one SCTP association per > >>> PC, so this is something that would be nice to define just to be > >>> ready for the future. > >> > >> AFAIK WebRTC is just one possible user of this mechanism. The SDP > >> mechanism shouldn't be limited by the constraints of WebRTC. It would > >> be very difficult to define the SDP so that it was impossible to set > >> up multiple SCTP associations over different 5-tuples. > >> > >>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic > >>>> can be demuxed based on SCTP port. And once the traffic for a > >>>> single SCTP port is identified, it can be demuxed based on stream > number. > >>>> > >>>> Representing this in SDP is a challenge. Some variant of the bundle > >>>> proposal might allow bundling together several RTP m-lines and some > >>>> DTLS/SCTP m-lines. This would require a mechanism for specifying > >>>> the SCTP port number - already an open issue (#3) in > >>>> draft-ietf-mmusic-sctp-sdp-02. > >>> I agree that it is a challange how then to bundle everything > >>> together > >> > >> But it is a challenge that needs to be tackled if we are to realize > >> Harald's dream. > > > > -d > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu Jan 3 11:23:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AA821F8D12 for ; Thu, 3 Jan 2013 11:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfXYbSF0I9Rr for ; Thu, 3 Jan 2013 11:23:16 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2821F86F4 for ; Thu, 3 Jan 2013 11:23:16 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id jW4F1k00616LCl058XPFlF; Thu, 03 Jan 2013 19:23:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id jXPF1k00R3ZTu2S3SXPFni; Thu, 03 Jan 2013 19:23:15 +0000 Message-ID: <50E5DAA2.9050600@alum.mit.edu> Date: Thu, 03 Jan 2013 14:23:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> In-Reply-To: <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357240995; bh=rMfE8shz9MUyZXPB8lt6M9zfwgaK5R3BFzJMottG7gE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ojPdzGTW+e84i6xw3etXSg47ch0IwMyB2TGsTez0v+C7YFU1v8KwS/SWkNJk3Ycm4 6kGvK0zlMMRZH6X4SfLYto/2DucTLi1DgBYK9jeqfJaMDOBAK5PlInGqldDeGvh/xp BeN83RNH1vci2kqfHc+9WoxgasnnixLJMktwEw8HXdEyoh5Y5+ChFjjExOWLb23mFY P1ZpMMVffUSE/nmuOmEMlsPnmeOHvnCmZUwjFEmyEHiF9da6/uuxQG9rSZSm7FtliT 80hw5L/CqxtH30lFpN0u20ZUmXYooQIDm+03P1BYQsU5+Nu16lbIBUa4ojKsEwKE04 dTyezgPf4+nQQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 19:23:18 -0000 I'm totally lost! I looked back, and count 43 messages in this thread. At this point I no longer understand the question(s), or what if anything has been answered. Can we start over? Sort out what the questions are, and then discuss whether we have answers to them? (Preferably in separate, well identified, threads.) I *think* Harald originally asserted that DTLS/SCTP *can* already be multiplexed with SRTP audio and video streams. And so he was asking *how* this could be specified in SDP. (E.g. Does "bundle" support it?) Along the way, a question came up of how many DTLS/SCTP connections could be multiplexed with each other and with SRTP media. I think Harald assumed only one (and assumed there is only a need for one.) But reasons for more have been discussed. I suggested that it appears that multiple should be supportable, each with a different SCTP port. I think Dan raised some additional issues related to multipath support. Thanks, Paul On 1/2/13 10:32 PM, Dan Wing wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, December 11, 2012 11:17 AM >> To: Dan Wing >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >> >> Hi Dan, >> >> Comments inline >> >> On 12/11/12 1:53 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Tuesday, December 11, 2012 7:43 AM >>>> To: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >>>> >>>> More inline. >>>> >>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: >>>>> Hi Paul, >>>>> >>>>> see in line! >>>>> >>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: >>>>>> Commenting on a different point >>>>>> >>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: >>>>>> >>>>>>> The interesting difference is that the multiplexing between >>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP >>>>>>> traffic is not carried in SSRCs, which means: >>>>>>> >>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may >>>>>>> have multiple associations, as you state below); you can't have >>>>>>> multiple lines with proto DTLS/SCTP in a bundle. >>>>>> >>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run >>>>>> directly over IP. It has its own notion of port used to demux >>>>>> multiple SCTP associations over the same IP address. >>>>>> >>>>>> I presume that that same mechanism is still there when SCTP is run >>>>>> over DTLS over UDP. >>>>>> >>>>>> So, the traffic coming over DTLS must first be demuxed into RTP >>>>>> traffic and SCTP traffic. >>>>> based on the current stack the SCTP traffic is the only traffic that >>>>> runs directly over the DTLS stack. >>>> >>>> Yes, that is what I thought. But Harald has been asking about >>>> multiplexing this with RTP traffic. (Actually I think it would be >>>> DTLS/SRTP traffic that it would be multiplexed with.) >>>> >>>>> What I am trying to do is to include the Randell Jesup (I am >>>>> including him in CC as I am not sure he is subscribed to this >>>>> mailing list) suggestion to give the possibility to have multiple >>>>> SCTP >>>>> *associations* running on top of the same DTLS session and of course >>>>> providing a way to signal it in SDP. >>>> >>>> IIUC, SCTP (having been designed as a transport layer protocol) >>>> defines its own notion of port, and has fields in its protocol to >>>> carry the local and remote port number. Presumably those fields are >>>> still there when run over UDP or DTLS. So it should be possible to >>>> support multiple SCTP associations over the same DTLS connection, >>>> each distinguished by its own port pair. >>> >>> Yes, SCTP has its own notion of ports. How this works when SCTP is >>> carried over UDP is not quite clear, especially because SCTP assumes a >>> NAPT will not rewrite the SCTP port number (SCTP endeavors to make >>> such port rewriting difficult). But of course a NAPT (and the MAP >>> techniques) rewrite UDP port numbers. I believe SCTP would only be >>> able to successfully convey its UDP port numbers for a device that is >>> not behind a NAT (that is, a server sitting directly on the Internet, >>> rather than a remote peer that is behind a NAT). Creative use of PCP, >>> NAT-PMP, or UPnP IGD would improve that situation in the future. >> >> I find what you say above confusing. >> >> SCTP running naked over IP would still have its own ports. >> If that ran over a path with a NAPT, then I could see why the NAPT might >> want to do the same as it does with UDP and TCP, and so replace >> addr/port pairs to minimize addr usage. (That's if the NAPT supported >> SCTP at all - I gather most don't.) > > As I mentioned earlier, SCTP does not allow its source port number to > be changed. > >> But with SCTP over DTLS over UDP, there is a UDP port, and then >> presumably a separate SCTP port carried in the SCTP protocol within the >> UDP message. > > Yep, I assume that is how it works. Effectively, UDP is just used > to tunnel the SCTP. > >> An NAPT on the path would presumably be messing with the UDP port. Given >> use of DTLS, the NAPT won't even be able to tell that SCTP is being >> used, much less mess with the SCTP port. >> >>>> That of course depends on having a signaling mechanism to set it up. >>> >>> After the initial SCTP association is created, SCTP could be allowed >>> to do its own thing (that is, chose to find and use other ports). >> >> Here you are talking about finding and using other UDP addr/port pairs? > > No, I was referring to the SCTP ports. > > -d > > >> That is explicitly excluded in the DTLS/SCTP mapping. >> >> Thanks, >> Paul >> >>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP), >>> but of course they are not identical. >>> >>>>> to be clear: at moment WebRTC allows only one SCTP association per >>>>> PC, so this is something that would be nice to define just to be >>>>> ready for the future. >>>> >>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP >>>> mechanism shouldn't be limited by the constraints of WebRTC. It would >>>> be very difficult to define the SDP so that it was impossible to set >>>> up multiple SCTP associations over different 5-tuples. >>>> >>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic >>>>>> can be demuxed based on SCTP port. And once the traffic for a >>>>>> single SCTP port is identified, it can be demuxed based on stream >> number. >>>>>> >>>>>> Representing this in SDP is a challenge. Some variant of the bundle >>>>>> proposal might allow bundling together several RTP m-lines and some >>>>>> DTLS/SCTP m-lines. This would require a mechanism for specifying >>>>>> the SCTP port number - already an open issue (#3) in >>>>>> draft-ietf-mmusic-sctp-sdp-02. >>>>> I agree that it is a challange how then to bundle everything >>>>> together >>>> >>>> But it is a challenge that needs to be tackled if we are to realize >>>> Harald's dream. >>> >>> -d >>> >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > From abegen@cisco.com Thu Jan 3 14:31:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A821F8D37 for ; Thu, 3 Jan 2013 14:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8UYuLZC2AC3 for ; Thu, 3 Jan 2013 14:31:13 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5380E21F8CF4 for ; Thu, 3 Jan 2013 14:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=814; q=dns/txt; s=iport; t=1357252273; x=1358461873; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=k+fXggxwOzX2BexOeunrMKs+Nt4F4+DWtBNqvL+gJ68=; b=fGpVASqbNVFnzpfZms8nlX1tgICkaVCK20lihzgbgwVHhnp8+ylCitzH jnI/Ovm3UgaMbGBFt34lv+cSrgr1x6/739tap2qYrQH7oEYaoezn/cjBY lDRWFkf4HQeXqUmiVuWbPNQR+wu+Ch8c9zcOYnitM6NZDjX/d30MjBi7Z 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAGQF5lCtJV2c/2dsb2JhbABFgmyDB7deFnOCIAEEOlEBKhRCJwQbiAsBC5hBnhqQOWEDlyiPLIJ0giY X-IronPort-AV: E=Sophos;i="4.84,405,1355097600"; d="scan'208";a="158440422" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jan 2013 22:31:12 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r03MVCxF001310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Jan 2013 22:31:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 16:31:11 -0600 From: "Ali C. Begen (abegen)" To: "mmusic@ietf.org" Thread-Topic: The rtp-duplication related drafts Thread-Index: AQHN6gIIZX3irh0G9UC8vBTgxKH8HA== Date: Thu, 3 Jan 2013 22:31:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.104] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E4CFE13BF46124EA2983559BEF6B32C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] The rtp-duplication related drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 22:31:14 -0000 Hi everyone, The following two drafts have been adopted by MMUSIC a while ago and the ma= in draft discussing the RTP duplication issues is being finalized in AVTEXT= (this was also adopted as a WG item a while ago). It is simply waiting for= the WG to make a decision on the srcname proposal. http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ These two mmusic drafts are essentially completed and they are needed to be= done for the avtext draft. I hope they will be WGLC'ed some time soon. In = the mean time, I would like to get any comments, feedback that you might ha= ve. Thanks. -acbegen PS Here is the AVTEXT draft. http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/ = From fandreas@cisco.com Thu Jan 3 15:01:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34C21F8AF8 for ; Thu, 3 Jan 2013 15:01:54 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ880Sc1zEBr for ; Thu, 3 Jan 2013 15:01:53 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 234FF21F8AD4 for ; Thu, 3 Jan 2013 15:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8078; q=dns/txt; s=iport; t=1357254113; x=1358463713; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=H6o2l/8nq4ywwKNo3MTowF4Rdk8yVvu48G4gF7FftZE=; b=c/KHcrkhSz3JSHw+jSmcQg3VKS6rABN+xkeoDq9nN3w2L1vLay4cWMWx HeUfmRc+eJHe8y1/GZIc+al5FD5jKqxUN3ZbpGOGvHBtS6bvsi/d6lSYr zYnX7p1p58p49Ie25JA59Ubm+CAaEMZgM/mz/8DwF7k4tQxz3Zpr2Qte2 0=; X-IronPort-AV: E=Sophos;i="4.84,405,1355097600"; d="scan'208";a="158448371" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jan 2013 23:01:52 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r03N1pT3013603; Thu, 3 Jan 2013 23:01:52 GMT Message-ID: <50E60DDF.6070204@cisco.com> Date: Thu, 03 Jan 2013 18:01:51 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:01:54 -0000 We clearly need an escape hatch as there are several examples of attributes with a given name that may occur multiple times to provide different values by use of additional qualifiers inside the attribute, and some of those attributes may appear at both the session and media level (capability negotiation for example uses this approach, as does "rtpmap", "fmtp", etc. inside a media description). In fact, I'd argue it's more than an escape hatch and probably more of a "default rule" in the absence of anything else specified for the attribute. In terms of the "choice" wording below, I think it's underspecified what that means, and I'm also not sure we really need a general rule here. Do we have other examples than the direction attributes currently ? If not (or we can't think of those), I'd rather just call those out explicitly. Thanks -- Flemming (as Individual) On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote: > I don¹t remember us reaching a consensus regarding the text proposed by > Brett. One thing certain is that we don't wanna break anything that > complies with 4566 but we should also make the text as clear as possible. > > I am OK with Brett's suggestion as I don't recall an attribute like what > Paul might have seen. But, even if such an attribute exists, the current > text would be incorrect, too (This would indicate a problem with that > particular attribute not 4566 or 4566bis). > > Brett's proposal does not make the text any worse. So, I am planning to > incorporate this change. > > Any objections? > > -acbegen > > -----Original Message----- > From: Paul Kyzivat > Date: Monday, August 27, 2012 12:03 PM > To: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: > session-level attributes > >> I've always thought this should be the way things work, for all >> attributes. But somewhere I came across an attribute (sorry, don't >> remember which one) where the attribute at session level means something >> different than the attribute at media level, and so can't be treated as >> a default for media level. (E.g. the session level is an aggregate limit >> for something, while the media level is a limit for a single m-line.) >> >> Am I just dreaming this? Or can someone identify specific attributes >> that behave this way? >> >> If there are existing attributes that behave this way, then we can't >> make a blanket statement like this. There will need to be an escape >> hatch. For example: >> >> "The connection ("c=") information in the >> session-level section applies to all the media of that session unless >> overridden by connection information >> in the media description. For instance, in the example >> below, TBD..." >> >> "The attribute ("a=") information in the >> session-level section applies to all the media of that session unless >> overridden by connection information or an attribute of the same name >> or choice in the media description, or the specification of that >> attribute calls for a different treatment. >> For instance, in the example >> below, each media behaves as if it were given a "recvonly" attribute. >> If the example had additionally contained a "sendrecv" media-level >> attribute for audio, only the video media would behave as if it were >> given a "recvonly" attribute." >> >> Even this could have some backward compatibility consequences. I think >> there are some attributes that are only defined for media level. This >> revision would mean that a session level value could override a default >> for media level. Implementations that aren't prepared for that might >> break. >> >> Thanks, >> Paul >> >> On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: >>> Brett suggested the following change in the SDP draft. Any objections? >>> >>> -acbegen >>> >>> Current text: >>> >>> "The connection ("c=") and attribute ("a=") information in the >>> session-level section applies to all the media of that session unless >>> overridden by connection information or an attribute of the same name >>> in the media description. For instance, in the example below, each >>> media behaves as if it were given a "recvonly" attribute." >>> >>> Proposed text: >>> >>> "The connection ("c=") and attribute ("a=") information in the >>> session-level section applies to all the media of that session unless >>> overridden by connection information or an attribute of the same name >>> or choice in the media description. For instance, in the example >>> below, each media behaves as if it were given a "recvonly" attribute. >>> If the example had additionally contained a "sendrecv" media-level >>> attribute for audio, only the video media would behave as if it were >>> given a "recvonly" attribute." >>> >>>> -----Original Message----- >>>> From: Brett Tate [mailto:brett@broadsoft.com] >>>> Sent: Wednesday, August 08, 2012 7:54 AM >>>> To: Ali C. Begen (abegen); mmusic@ietf.org >>>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes >>>> >>>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the >>>>>> following. >>>>>> >>>>>> "In general, session-level values are the default for all >>>>>> media unless overridden by an equivalent media-level value." >>>>>> >>>>>> "The connection ("c=") and attribute ("a=") information >>>>>> in the session-level section applies to all the media of >>>>>> that session unless overridden by connection information >>>>>> or an attribute of the same name in the media description. >>>>>> For instance, in the example below, each media behaves >>>>>> as if it were given a "recvonly" attribute." >>>>>> >>>>>> If the attributes are related but with different names >>>>>> (such as "inactive" and "sendrecv"), does the attribute >>>>>> at the media-level have precedence over the value at the >>>>>> session-level? If so, I recommend that the draft be >>>>>> updated to clarify the topic. >>>>> I believe so. at least that is my understanding from the >>>>> text. Does it really need clarification? Thoughts? >>>> I think that it should be clarified because it is unclear if "an >>>> attribute of the same name" indicates the typical situation or only >>>> situation concerning application of "unless overridden by an >>>> equivalent media-level value". For instance if I sent "a=inactive" >>>> at session-level and "a=sendrecv" at media-level, I'd be concerned >>>> that the receiver may interpret the SDP as being >>>> abnormal (such as including both values at media-level) instead of >>>> allowing "a=sendrecv" to override "a=inactive". >>>> >>>> In case it matters from an extendibility perspective, requiring the >>>> same name might make it easier to recognize the override. >>>> However since section 6 already introduces complications with >>>> defaulting to "sendrecv" if a new option is defined/used and >>>> unknown, allowing the override even when the names are not the same >>>> doesn't make things too much worse; it actually >>>> allows communication of a backup attribute (such as "a=inactive") if >>>> they don't understand the preferred new attribute (such >>>> as "a=foo"). >>>> >>>> "If none of the attributes "sendonly", "recvonly", "inactive", >>>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the >>>> default for sessions that are not of the conference type >>>> "broadcast" or "H332" (see below)." >>>> >>>> Thanks for the response, >>>> Brett >>> _______________________________________________ >>> 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 Thu Jan 3 18:03:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4099421F8D59; Thu, 3 Jan 2013 18:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.889 X-Spam-Level: X-Spam-Status: No, score=-7.889 tagged_above=-999 required=5 tests=[AWL=2.709, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGzc9zQ9VNWV; Thu, 3 Jan 2013 18:03:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01D21F8D74; Thu, 3 Jan 2013 18:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5071; q=dns/txt; s=iport; t=1357265032; x=1358474632; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qVSRLUGGndTkzfigXqbFS/Hh7ijRMs+pJh0mGaPkfeU=; b=FQ+C0Tpedurwmr+epotNy5DivhBeredBLO3pHTfVwVJNroMXNtX6S4hV yge6oNiGFvvcCsNP+ILTM8mJGAgKJddObtqvJpEaOSBWUZ2YLJ3yN1/Sr vGHpG92ahmeCVRi413cDKm1EOMiptf2emzrMI9BwAjECvyUisHVUy9z3X E=; X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208,217";a="158711080" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jan 2013 02:03:52 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0423pPf001653; Fri, 4 Jan 2013 02:03:51 GMT Message-ID: <50E63886.3020406@cisco.com> Date: Thu, 03 Jan 2013 21:03:50 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Bernard Aboba References: , , In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806000000070002020905" Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 02:03:53 -0000 This is a multi-part message in MIME format. --------------040806000000070002020905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/2/13 2:44 PM, Bernard Aboba wrote: > Cullen said: > > "3) if we are going to have an MMUSIC face to face interim meeting, it > would need AD approval and 4 weeks notices which puts us very close do > the deadline so this needs to get sort out real soon. " > > [BA] I see no particularly good reason why this can't happen > quickly. In fact, why not schedule two MMUSIC interims, 4-6 weeks > apart from each other? If travel is an issue, they can be virtual. > EKR's issue list is a fine starting point, and there is an informal > IESG telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. > > Ted's suggestion (to cover this in the RTCWEB interim) might do in a > pinch, but really, MMUSIC WG has to develop a sense of urgency on > this. If things keep going as they have, by the time we get published > RFCs out of MMUSIC, implementations will have been in the field for > years. > The MMUSIC WG is driven by the contributions, discussions, and ultimately rough consensus of its participants, just like any other WG. The active participants on the topics of interest here seem to be largely the same in the two groups, so I'm not sure exactly what you are looking for or proposing here, but constructive suggestions are always welcome. Thanks -- Flemming (MMUSIC co-chair) > If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for > "tough love" and on the front page of the National Enquirer for the > Nth time. > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------040806000000070002020905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/2/13 2:44 PM, Bernard Aboba wrote:
Cullen said:

"3) if we are going to have an MMUSIC face to face interim meeting, it would need AD approval and 4 weeks notices which puts us very close do the deadline so this needs to get sort out real soon. "

[BA] I see no particularly good reason why this can't  happen quickly.  In fact, why not schedule two MMUSIC interims, 4-6 weeks apart from each other?  If travel is an issue, they can be virtual.  EKR's issue list is a fine starting point, and there is an informal IESG telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. 

Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch, but really, MMUSIC WG has to develop a sense of urgency on this.  If things keep going as they have, by the time we get published RFCs out of MMUSIC,  implementations will have been in the field for years. 

The MMUSIC WG is driven by the contributions, discussions, and ultimately rough consensus of its participants, just like any other WG. The active participants on the topics of interest here seem to be largely the same in the two groups, so I'm not sure exactly what you are looking for or proposing here, but constructive suggestions are always welcome.

Thanks

-- Flemming (MMUSIC co-chair)


If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for "tough love" and on the front page of the National Enquirer for the Nth time. 





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

--------------040806000000070002020905-- From pkyzivat@alum.mit.edu Thu Jan 3 18:09:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF0C21F8D8E for ; Thu, 3 Jan 2013 18:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDzYhVo2aSTa for ; Thu, 3 Jan 2013 18:09:27 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 9D14921F8D8C for ; Thu, 3 Jan 2013 18:09:27 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta07.westchester.pa.mail.comcast.net with comcast id jdeN1k0051HzFnQ57e9Tjo; Fri, 04 Jan 2013 02:09:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id je9S1k00m3ZTu2S3ae9SA0; Fri, 04 Jan 2013 02:09:27 +0000 Message-ID: <50E639D6.90105@alum.mit.edu> Date: Thu, 03 Jan 2013 21:09:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Flemming Andreasen References: <50E60DDF.6070204@cisco.com> In-Reply-To: <50E60DDF.6070204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357265367; bh=wD1o57vbonOKWxYT9hri5Bb+tqu1Y4Q5QIdarjzBWoY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ju/K26IsO3ltgb5D7HeLSwbT8l3i4eqx4hH7C5NjrHJ5wv7zX45aAT0//jsEwhEUN z6iwqZMC0GSCWR4+1Z+IqjK1FuOZjjBIPiy2t/iSNOWehEFPjOWy53YLn7XH3wq9mS 9SK2FrmqYySjnx8DflRBczIenlzyC8LbArCrzPkqsY1iAqWl1a6MdzZTsnoBhBEhmG kDOgi0MVZ9bPwG/efv8289mYu0CvcK88fLvmDyYwx0EIYM8Z4Uy3LTcXnPIm5WHcQr dYL0uDa5z6Y+P1vXJgK37NHFf6pLHzMORVGzHDKPdlJoIzjk6wHvp5R+IHUIT+jJZR GdDMdvI43B83A== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 02:09:33 -0000 Once upon a time I thought that rule actually existed and worked, and that all attributes ought to have the "session is default for media level" property. But then it became apparent that there were cases that didn't fit that rule. When writing my last reply to this thread, and examining things more closely, it became apparent to me that this defaulting behavior doesn't work in many/most cases. The interesting cases that work something like that need to be described individually to cover the special cases that seem to apply almost all the time. So I agree we are probably better off just not asserting it. And at the same time we should polish up the definitions of the attributes defined in this document so that they are very clear how session and media level interact. Thanks, Paul On 1/3/13 6:01 PM, Flemming Andreasen wrote: > We clearly need an escape hatch as there are several examples of > attributes with a given name that may occur multiple times to provide > different values by use of additional qualifiers inside the attribute, > and some of those attributes may appear at both the session and media > level (capability negotiation for example uses this approach, as does > "rtpmap", "fmtp", etc. inside a media description). In fact, I'd argue > it's more than an escape hatch and probably more of a "default rule" in > the absence of anything else specified for the attribute. > > In terms of the "choice" wording below, I think it's underspecified what > that means, and I'm also not sure we really need a general rule here. Do > we have other examples than the direction attributes currently ? If not > (or we can't think of those), I'd rather just call those out explicitly. > > Thanks > > -- Flemming (as Individual) > > > > On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote: >> I don¹t remember us reaching a consensus regarding the text proposed by >> Brett. One thing certain is that we don't wanna break anything that >> complies with 4566 but we should also make the text as clear as possible. >> >> I am OK with Brett's suggestion as I don't recall an attribute like what >> Paul might have seen. But, even if such an attribute exists, the current >> text would be incorrect, too (This would indicate a problem with that >> particular attribute not 4566 or 4566bis). >> >> Brett's proposal does not make the text any worse. So, I am planning to >> incorporate this change. >> >> Any objections? >> >> -acbegen >> >> -----Original Message----- >> From: Paul Kyzivat >> Date: Monday, August 27, 2012 12:03 PM >> To: "mmusic@ietf.org" >> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: >> session-level attributes >> >>> I've always thought this should be the way things work, for all >>> attributes. But somewhere I came across an attribute (sorry, don't >>> remember which one) where the attribute at session level means something >>> different than the attribute at media level, and so can't be treated as >>> a default for media level. (E.g. the session level is an aggregate limit >>> for something, while the media level is a limit for a single m-line.) >>> >>> Am I just dreaming this? Or can someone identify specific attributes >>> that behave this way? >>> >>> If there are existing attributes that behave this way, then we can't >>> make a blanket statement like this. There will need to be an escape >>> hatch. For example: >>> >>> "The connection ("c=") information in the >>> session-level section applies to all the media of that session unless >>> overridden by connection information >>> in the media description. For instance, in the example >>> below, TBD..." >>> >>> "The attribute ("a=") information in the >>> session-level section applies to all the media of that session unless >>> overridden by connection information or an attribute of the same name >>> or choice in the media description, or the specification of that >>> attribute calls for a different treatment. >>> For instance, in the example >>> below, each media behaves as if it were given a "recvonly" attribute. >>> If the example had additionally contained a "sendrecv" media-level >>> attribute for audio, only the video media would behave as if it were >>> given a "recvonly" attribute." >>> >>> Even this could have some backward compatibility consequences. I think >>> there are some attributes that are only defined for media level. This >>> revision would mean that a session level value could override a default >>> for media level. Implementations that aren't prepared for that might >>> break. >>> >>> Thanks, >>> Paul >>> >>> On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: >>>> Brett suggested the following change in the SDP draft. Any objections? >>>> >>>> -acbegen >>>> >>>> Current text: >>>> >>>> "The connection ("c=") and attribute ("a=") information in the >>>> session-level section applies to all the media of that session >>>> unless >>>> overridden by connection information or an attribute of the same >>>> name >>>> in the media description. For instance, in the example below, each >>>> media behaves as if it were given a "recvonly" attribute." >>>> >>>> Proposed text: >>>> >>>> "The connection ("c=") and attribute ("a=") information in the >>>> session-level section applies to all the media of that session >>>> unless >>>> overridden by connection information or an attribute of the same >>>> name >>>> or choice in the media description. For instance, in the example >>>> below, each media behaves as if it were given a "recvonly" >>>> attribute. >>>> If the example had additionally contained a "sendrecv" media-level >>>> attribute for audio, only the video media would behave as if it were >>>> given a "recvonly" attribute." >>>> >>>>> -----Original Message----- >>>>> From: Brett Tate [mailto:brett@broadsoft.com] >>>>> Sent: Wednesday, August 08, 2012 7:54 AM >>>>> To: Ali C. Begen (abegen); mmusic@ietf.org >>>>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes >>>>> >>>>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the >>>>>>> following. >>>>>>> >>>>>>> "In general, session-level values are the default for all >>>>>>> media unless overridden by an equivalent media-level value." >>>>>>> >>>>>>> "The connection ("c=") and attribute ("a=") information >>>>>>> in the session-level section applies to all the media of >>>>>>> that session unless overridden by connection information >>>>>>> or an attribute of the same name in the media description. >>>>>>> For instance, in the example below, each media behaves >>>>>>> as if it were given a "recvonly" attribute." >>>>>>> >>>>>>> If the attributes are related but with different names >>>>>>> (such as "inactive" and "sendrecv"), does the attribute >>>>>>> at the media-level have precedence over the value at the >>>>>>> session-level? If so, I recommend that the draft be >>>>>>> updated to clarify the topic. >>>>>> I believe so. at least that is my understanding from the >>>>>> text. Does it really need clarification? Thoughts? >>>>> I think that it should be clarified because it is unclear if "an >>>>> attribute of the same name" indicates the typical situation or only >>>>> situation concerning application of "unless overridden by an >>>>> equivalent media-level value". For instance if I sent "a=inactive" >>>>> at session-level and "a=sendrecv" at media-level, I'd be concerned >>>>> that the receiver may interpret the SDP as being >>>>> abnormal (such as including both values at media-level) instead of >>>>> allowing "a=sendrecv" to override "a=inactive". >>>>> >>>>> In case it matters from an extendibility perspective, requiring the >>>>> same name might make it easier to recognize the override. >>>>> However since section 6 already introduces complications with >>>>> defaulting to "sendrecv" if a new option is defined/used and >>>>> unknown, allowing the override even when the names are not the same >>>>> doesn't make things too much worse; it actually >>>>> allows communication of a backup attribute (such as "a=inactive") if >>>>> they don't understand the preferred new attribute (such >>>>> as "a=foo"). >>>>> >>>>> "If none of the attributes "sendonly", "recvonly", "inactive", >>>>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the >>>>> default for sessions that are not of the conference type >>>>> "broadcast" or "H332" (see below)." >>>>> >>>>> Thanks for the response, >>>>> Brett >>>> _______________________________________________ >>>> 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 abegen@cisco.com Thu Jan 3 18:14:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047D21F8DE3 for ; Thu, 3 Jan 2013 18:14:07 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoB8KvzmcYpE for ; Thu, 3 Jan 2013 18:14:05 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 556A821F8BAB for ; Thu, 3 Jan 2013 18:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9782; q=dns/txt; s=iport; t=1357265644; x=1358475244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=j9A7fWn/+BBOLaIGTRMqfaYOvDE9M2jvnekNA/rw/kg=; b=Zk+UMu+2Ls5+TYxZzgDT7PsVn6/stQVF1v5qrY7eAe55EPVCeO0TtU9v AuXzRMFeCRaUoMr3iF7XNwnprf16Blejom0LdpfJC4QCxXvA1d3Isl29A OjkxjXwW/Q6lcWK8Pivz1A9ggaZDn/BJlxJWXdL02g7jIqkCM3qSfJE7d 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO055lCtJXG9/2dsb2JhbAA7Cg6CXrpfFnOCHgEBAQMBAQEBZQYLBQcEAgEIDgMDAQEBAQodBycLFAkIAgQOBQiIBQYBC7ZgBIxXAg8Fg0xhA4gtnieCNj6BaT0 X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208";a="158755646" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jan 2013 02:14:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r042E385030000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 02:14:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 20:14:03 -0600 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5hjLtrmzSS0hf0Omfa72mDfZ75g4pQWAgAA0aQCAAAFJAA== Date: Fri, 4 Jan 2013 02:14:02 +0000 Message-ID: References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> In-Reply-To: <50E639D6.90105@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.58] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <14F501900B5BD940AD9E7D665A303AF3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 02:14:07 -0000 Hi Paul, On Jan 3, 2013, at 9:09 PM, Paul Kyzivat wrote: > Once upon a time I thought that rule actually existed and worked, and tha= t all attributes ought to have the "session is default for media level" pro= perty. >=20 > But then it became apparent that there were cases that didn't fit that ru= le. >=20 > When writing my last reply to this thread, and examining things more clos= ely, it became apparent to me that this defaulting behavior doesn't work in= many/most cases. The interesting cases that work something like that need = to be described individually to cover the special cases that seem to apply = almost all the time. >=20 > So I agree we are probably better off just not asserting it. >=20 Are you saying we don't change the text or remove it altogether? > And at the same time we should polish up the definitions of the attribute= s defined in this document so that they are very clear how session and medi= a level interact. Could you provide an example of what you have in mind? >=20 > Thanks, > Paul >=20 > On 1/3/13 6:01 PM, Flemming Andreasen wrote: >> We clearly need an escape hatch as there are several examples of >> attributes with a given name that may occur multiple times to provide >> different values by use of additional qualifiers inside the attribute, >> and some of those attributes may appear at both the session and media >> level (capability negotiation for example uses this approach, as does >> "rtpmap", "fmtp", etc. inside a media description). In fact, I'd argue >> it's more than an escape hatch and probably more of a "default rule" in >> the absence of anything else specified for the attribute. >>=20 >> In terms of the "choice" wording below, I think it's underspecified what >> that means, and I'm also not sure we really need a general rule here. Do >> we have other examples than the direction attributes currently ? If not >> (or we can't think of those), I'd rather just call those out explicitly. >>=20 >> Thanks >>=20 >> -- Flemming (as Individual) >>=20 >>=20 >>=20 >> On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote: >>> I don=B9t remember us reaching a consensus regarding the text proposed = by >>> Brett. One thing certain is that we don't wanna break anything that >>> complies with 4566 but we should also make the text as clear as possibl= e. >>>=20 >>> I am OK with Brett's suggestion as I don't recall an attribute like wha= t >>> Paul might have seen. But, even if such an attribute exists, the curren= t >>> text would be incorrect, too (This would indicate a problem with that >>> particular attribute not 4566 or 4566bis). >>>=20 >>> Brett's proposal does not make the text any worse. So, I am planning to >>> incorporate this change. >>>=20 >>> Any objections? >>>=20 >>> -acbegen >>>=20 >>> -----Original Message----- >>> From: Paul Kyzivat >>> Date: Monday, August 27, 2012 12:03 PM >>> To: "mmusic@ietf.org" >>> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: >>> session-level attributes >>>=20 >>>> I've always thought this should be the way things work, for all >>>> attributes. But somewhere I came across an attribute (sorry, don't >>>> remember which one) where the attribute at session level means somethi= ng >>>> different than the attribute at media level, and so can't be treated a= s >>>> a default for media level. (E.g. the session level is an aggregate lim= it >>>> for something, while the media level is a limit for a single m-line.) >>>>=20 >>>> Am I just dreaming this? Or can someone identify specific attributes >>>> that behave this way? >>>>=20 >>>> If there are existing attributes that behave this way, then we can't >>>> make a blanket statement like this. There will need to be an escape >>>> hatch. For example: >>>>=20 >>>> "The connection ("c=3D") information in the >>>> session-level section applies to all the media of that session unless >>>> overridden by connection information >>>> in the media description. For instance, in the example >>>> below, TBD..." >>>>=20 >>>> "The attribute ("a=3D") information in the >>>> session-level section applies to all the media of that session unless >>>> overridden by connection information or an attribute of the same name >>>> or choice in the media description, or the specification of that >>>> attribute calls for a different treatment. >>>> For instance, in the example >>>> below, each media behaves as if it were given a "recvonly" attribute. >>>> If the example had additionally contained a "sendrecv" media-level >>>> attribute for audio, only the video media would behave as if it were >>>> given a "recvonly" attribute." >>>>=20 >>>> Even this could have some backward compatibility consequences. I think >>>> there are some attributes that are only defined for media level. This >>>> revision would mean that a session level value could override a defaul= t >>>> for media level. Implementations that aren't prepared for that might >>>> break. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: >>>>> Brett suggested the following change in the SDP draft. Any objections= ? >>>>>=20 >>>>> -acbegen >>>>>=20 >>>>> Current text: >>>>>=20 >>>>> "The connection ("c=3D") and attribute ("a=3D") information in the >>>>> session-level section applies to all the media of that session >>>>> unless >>>>> overridden by connection information or an attribute of the same >>>>> name >>>>> in the media description. For instance, in the example below, each >>>>> media behaves as if it were given a "recvonly" attribute." >>>>>=20 >>>>> Proposed text: >>>>>=20 >>>>> "The connection ("c=3D") and attribute ("a=3D") information in the >>>>> session-level section applies to all the media of that session >>>>> unless >>>>> overridden by connection information or an attribute of the same >>>>> name >>>>> or choice in the media description. For instance, in the example >>>>> below, each media behaves as if it were given a "recvonly" >>>>> attribute. >>>>> If the example had additionally contained a "sendrecv" media-level >>>>> attribute for audio, only the video media would behave as if it wer= e >>>>> given a "recvonly" attribute." >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Brett Tate [mailto:brett@broadsoft.com] >>>>>> Sent: Wednesday, August 08, 2012 7:54 AM >>>>>> To: Ali C. Begen (abegen); mmusic@ietf.org >>>>>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attribut= es >>>>>>=20 >>>>>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the >>>>>>>> following. >>>>>>>>=20 >>>>>>>> "In general, session-level values are the default for all >>>>>>>> media unless overridden by an equivalent media-level value." >>>>>>>>=20 >>>>>>>> "The connection ("c=3D") and attribute ("a=3D") information >>>>>>>> in the session-level section applies to all the media of >>>>>>>> that session unless overridden by connection information >>>>>>>> or an attribute of the same name in the media description. >>>>>>>> For instance, in the example below, each media behaves >>>>>>>> as if it were given a "recvonly" attribute." >>>>>>>>=20 >>>>>>>> If the attributes are related but with different names >>>>>>>> (such as "inactive" and "sendrecv"), does the attribute >>>>>>>> at the media-level have precedence over the value at the >>>>>>>> session-level? If so, I recommend that the draft be >>>>>>>> updated to clarify the topic. >>>>>>> I believe so. at least that is my understanding from the >>>>>>> text. Does it really need clarification? Thoughts? >>>>>> I think that it should be clarified because it is unclear if "an >>>>>> attribute of the same name" indicates the typical situation or only >>>>>> situation concerning application of "unless overridden by an >>>>>> equivalent media-level value". For instance if I sent "a=3Dinactive= " >>>>>> at session-level and "a=3Dsendrecv" at media-level, I'd be concerned >>>>>> that the receiver may interpret the SDP as being >>>>>> abnormal (such as including both values at media-level) instead of >>>>>> allowing "a=3Dsendrecv" to override "a=3Dinactive". >>>>>>=20 >>>>>> In case it matters from an extendibility perspective, requiring the >>>>>> same name might make it easier to recognize the override. >>>>>> However since section 6 already introduces complications with >>>>>> defaulting to "sendrecv" if a new option is defined/used and >>>>>> unknown, allowing the override even when the names are not the same >>>>>> doesn't make things too much worse; it actually >>>>>> allows communication of a backup attribute (such as "a=3Dinactive") = if >>>>>> they don't understand the preferred new attribute (such >>>>>> as "a=3Dfoo"). >>>>>>=20 >>>>>> "If none of the attributes "sendonly", "recvonly", "inactive", >>>>>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the >>>>>> default for sessions that are not of the conference type >>>>>> "broadcast" or "H332" (see below)." >>>>>>=20 >>>>>> Thanks for the response, >>>>>> Brett >>>>> _______________________________________________ >>>>> 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 >>> . >>>=20 >>=20 >>=20 >=20 From pkyzivat@alum.mit.edu Thu Jan 3 18:29:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FDF21F8E33 for ; Thu, 3 Jan 2013 18:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.083 X-Spam-Level: X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln6psEt+I7iZ for ; Thu, 3 Jan 2013 18:29:22 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A921F8E2E for ; Thu, 3 Jan 2013 18:29:21 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id jcnM1k0020xGWP85CeVJpo; Fri, 04 Jan 2013 02:29:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id jeVH1k00v3ZTu2S3YeVH88; Fri, 04 Jan 2013 02:29:18 +0000 Message-ID: <50E63E7D.5050707@alum.mit.edu> Date: Thu, 03 Jan 2013 21:29:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357266558; bh=SZzKv41Qiok2BMvhIo+w31CI7FzOYAtOPB4jJ5YxsmI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hF800Y5S+qAC5DXg9Q5wXJszt55Haegh4DNQOMOJSZCEA7ZgYQly/RUAdkyiw8AkH 7ta5jNG5HxmzHsgAN9hH2CPuzeyYQW36l5yNx9g9VDUllHej2cLZk/eQNa3p1LmtGG LXE3K0X95AUcl5H9VfOZsifUgpmI8xRgohduLRIupgGaRGclKDtLJSDFGdsuL9MsbS Cpz5ysx61rbJmbsdLEzQAKgWRzLysRcPUt6BGvhW0/gQxyWnNptPbplIcpdnPNGQqi o8ubapyrqCmtEpI4VfE6iazBcbIJ4CCxob35k5zw+QBgjmaqkY+0bKIalQmqaW+N9k eWpRKUyaEYRkg== Subject: Re: [MMUSIC] The rtp-duplication related drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 02:29:22 -0000 Ali, On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote: > Hi everyone, > > The following two drafts have been adopted by MMUSIC a while ago and the main draft discussing the RTP duplication issues is being finalized in AVTEXT (this was also adopted as a WG item a while ago). It is simply waiting for the WG to make a decision on the srcname proposal. > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ > http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ I have a question about these: Each example shows only one group. But couldn't there be multiple duplication groups? If so, the current proposal has no mechanism for specifying separate duplication-delay for each group. Thanks, Paul From abegen@cisco.com Thu Jan 3 18:47:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A089121F8D90 for ; Thu, 3 Jan 2013 18:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.889 X-Spam-Level: X-Spam-Status: No, score=-7.889 tagged_above=-999 required=5 tests=[AWL=2.710, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6G37zHMSe8p for ; Thu, 3 Jan 2013 18:47:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DBC8321F8CB1 for ; Thu, 3 Jan 2013 18:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1357267640; x=1358477240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3190f+3NfxWTdrh2gGUaE9odM+sJ1LPlqw8JyjpbqzQ=; b=a/s4aCP0iFPwAAkKDqnnzk2kYJbRZCBqFFv0oZs+UWq/6EXKJRZcj7fz Lr/sioUrtBjODnRz//RapkFfy/AxIwJRysVygqAUYrR/lVMcl1uyOuXR0 s5RVDc3occa7i+PGWzllpcBlh9UaHKSEMHUESU/vpaz50tV9PFZuc96qi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABRC5lCtJXG//2dsb2JhbABFDoJeumAWc4IeAQEBAwEBAQE3NAsFCwIBCA4KChQQJwslAgQOBQiIBQYBC7ZokDlhA5cojyyCNj6CJg X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208";a="158724988" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jan 2013 02:47:19 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r042lJ9q008328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 02:47:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 20:47:19 -0600 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] The rtp-duplication related drafts Thread-Index: AQHN6gIIZX3irh0G9UC8vBTgxKH8HJg41yeAgAAFCQA= Date: Fri, 4 Jan 2013 02:47:18 +0000 Message-ID: References: <50E63E7D.5050707@alum.mit.edu> In-Reply-To: <50E63E7D.5050707@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <3BD4DF3FF1254B48809040809AE3B293@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [MMUSIC] The rtp-duplication related drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 02:47:20 -0000 Thanks for the review. On Jan 3, 2013, at 9:29 PM, Paul Kyzivat wrote: > Ali, >=20 > On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote: >> Hi everyone, >>=20 >> The following two drafts have been adopted by MMUSIC a while ago and the= main draft discussing the RTP duplication issues is being finalized in AVT= EXT (this was also adopted as a WG item a while ago). It is simply waiting = for the WG to make a decision on the srcname proposal. >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ >=20 > I have a question about these: >=20 > Each example shows only one group. But couldn't there be multiple duplica= tion groups? >=20 There could be. > If so, the current proposal has no mechanism for specifying separate dupl= ication-delay for each group. >=20 a=3Dduplication-delay:X could be specified in each media session. For examp= le: a=3Drtpmap:100 MP2T/90000 a=3Dssrc:1000 cname:ch1@example.com a=3Dssrc:1010 cname:ch1@example.com a=3Dssrc-group:DUP 1000 1010 a=3Dduplication-delay:100 a=3Dmid:Group1 a=3Drtpmap:101 MP2T/90000 a=3Dssrc:2000 cname:ch2@example.com a=3Dssrc:2010 cname:ch2@example.com a=3Dssrc-group:DUP 2000 2010 a=3Dduplication-delay:150 a=3Dmid:Group2 (The SSRC need not be different as SSRC only need to be unique within each = media session) For the non-ssrc grouping, your comment holds. It does not support specifyi= ng different delay values for different groups. Do you think we should supp= ort distinct delay values for different groups (which probably means duplic= ation-delay attribute has to be media-level only)? -acbegen > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Thu Jan 3 18:51:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC70D21F8E57; Thu, 3 Jan 2013 18:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WenhmECbAJxK; Thu, 3 Jan 2013 18:51:09 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A29E321F8E07; Thu, 3 Jan 2013 18:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8311; q=dns/txt; s=iport; t=1357267869; x=1358477469; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GeDz2+H6qbuFV3nFNdvSwXknIvOAV0Y1/XUZmx/kUio=; b=FyauE838ovbu03WN88JoHxfZccuuEHY7Y+PD2AROu+mi5i17sOIVx/br 72tD/UHkVRFdO87+NwKIUnXht16MJYSWZ7DcInxa8nk3vZYygeO4wIGhb v99gjERweOi1ikWoq7zfpWqz7unfaco9RD8e7lFiIXkNWVayeJSJWuqKV s=; X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208,217";a="158506525" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jan 2013 02:51:09 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r042p8Gs001720; Fri, 4 Jan 2013 02:51:08 GMT Message-ID: <50E6439B.1050901@cisco.com> Date: Thu, 03 Jan 2013 21:51:07 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020306090106000302040102" Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda for Interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 02:51:11 -0000 This is a multi-part message in MIME format. --------------020306090106000302040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/2/13 5:25 PM, Eric Rescorla wrote: > > > On Wed, Jan 2, 2013 at 11:44 AM, Bernard Aboba > > wrote: > > Cullen said: > > "3) if we are going to have an MMUSIC face to face interim > meeting, it would need AD approval and 4 weeks notices which puts > us very close do the deadline so this needs to get sort out real > soon. " > > [BA] I see no particularly good reason why this can't happen > quickly. In fact, why not schedule two MMUSIC interims, 4-6 weeks > apart from each other? If travel is an issue, they can be > virtual. EKR's issue list is a fine starting point, and there is > an informal IESG telechat tomorrow (3-Jan) as well as one on > 10-Jan-2013. > > > I'm not in principle opposed to "virtual" interims, but my general > feeling is > that we should be using face-to-face time to cover the most important and > intractable issues. ISTM that those are the ones that I listed in my > email. > > Accordingly, I don't think it makes sense to have virtual MMUSIC interims > to discuss the important stuff and a F2F RTCWEB interim to discuss the > rest... > While I agree it would be helpful with more face-to-face time, I don't believe in relying on this as a mechanism for making continuous progress. These types of meetings are generally most productive when coupled with regular interaction among a core set of people that represent the different points of view in a particular matter and hence I would suggest formation of one or more design teams on select topics with regular conference calls (we'll need dedicated volunteers for those) - of course the output of these design teams will still need to be discussed in the WG at large. One particular area to start with on the bundle/mmt discussion for example is to look at how the different proposals handle all existing SDP parameters and attributes to see how important their different approach really is. Thanks -- Flemming (as Individual) > -Ekr > > > Ted's suggestion (to cover this in the RTCWEB interim) might do in > a pinch, but really, MMUSIC WG has to develop a sense of urgency > on this. If things keep going as they have, by the time we get > published RFCs out of MMUSIC, implementations will have been in > the field for years. > > If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time > for "tough love" and on the front page of the National Enquirer > for the Nth time. > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------020306090106000302040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 1/2/13 5:25 PM, Eric Rescorla wrote:


On Wed, Jan 2, 2013 at 11:44 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Cullen said:

"3) if we are going to have an MMUSIC face to face interim meeting, it would need AD approval and 4 weeks notices which puts us very close do the deadline so this needs to get sort out real soon. "

[BA] I see no particularly good reason why this can't  happen quickly.  In fact, why not schedule two MMUSIC interims, 4-6 weeks apart from each other?  If travel is an issue, they can be virtual.  EKR's issue list is a fine starting point, and there is an informal IESG telechat tomorrow (3-Jan) as well as one on 10-Jan-2013. 

I'm not in principle opposed to "virtual" interims, but my general feeling is
that we should be using face-to-face time to cover the most important and
intractable issues. ISTM that those are the ones that I listed in my email.

Accordingly, I don't think it makes sense to have virtual MMUSIC interims
to discuss the important stuff and a F2F RTCWEB interim to discuss the
rest...

While I agree it would be helpful with more face-to-face time, I don't believe in relying on this as a mechanism for making continuous progress. These types of meetings are generally most productive when coupled with regular interaction among a core set of people that represent the different points of view in a particular matter and hence I would suggest formation of one or more design teams on select topics with regular conference calls (we'll need dedicated volunteers for those) - of course the output of these design teams will still need to be discussed in the WG at large.

One particular area to start with on the bundle/mmt discussion for example is to look at how the different proposals handle all existing SDP parameters and attributes to see how important their different approach really is.

Thanks

-- Flemming (as Individual)

-Ekr


Ted's suggestion (to cover this in the RTCWEB interim) might do in a pinch, but really, MMUSIC WG has to develop a sense of urgency on this.  If things keep going as they have, by the time we get published RFCs out of MMUSIC,  implementations will have been in the field for years. 

If MMUSIC were a Hollywood Celebrity, we'd be *way* past the time for "tough love" and on the front page of the National Enquirer for the Nth time. 






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

--------------020306090106000302040102-- From pkyzivat@alum.mit.edu Thu Jan 3 19:31:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C3921F8CE8 for ; Thu, 3 Jan 2013 19:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hj57joxvoZY for ; Thu, 3 Jan 2013 19:31:47 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 421AE21F882E for ; Thu, 3 Jan 2013 19:31:47 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id jdEP1k00217dt5G54fXmYw; Fri, 04 Jan 2013 03:31:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id jfXm1k0043ZTu2S3ZfXmDF; Fri, 04 Jan 2013 03:31:46 +0000 Message-ID: <50E64D21.2030609@alum.mit.edu> Date: Thu, 03 Jan 2013 22:31:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357270306; bh=4yywNTlR34MNT2snKEybxOc6aa811Kgd2ButINTR92A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XffYOBfB43qY6W8NN1LhcgH7xgtsdTD9htaonvEdHxxVo4xD8/VlzcfI7iKLXfogr IInIZo3FSf8J0zFP2fNf6SBMQ9KCnt+MwVayDAXigS694/8LA2fI3lxRA01+5zJLTL 9Duynt5FT7XIl6i21j0yvXPDHr7rb6wTeKhxXd9rKfb3lYKoHnWKCwCopqGmu34aiF xMC07tMZRm78NHNhqPeXY9iKSt61l3v/eC4oScWZtsxFGQVWihvSgPtxU+L6kGlTQW syQTXQ0PHywVrFCAzVM8tWbIsAi9jrjrXSUDqIT1XbEQ2r+r5g5WLMXhL3LlOmhPpP dv/g4rYGfzHbA== Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 03:31:48 -0000 On 1/3/13 9:14 PM, Ali C. Begen (abegen) wrote: > Are you saying we don't change the text or remove it altogether? Major change. OLD: The connection ("c=") and attribute ("a=") information in the session-level section applies to all the media of that session unless overridden by connection information or an attribute of the same name in the media description. For instance, in the example below, each media behaves as if it were given a "recvonly" attribute. An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 NEW: The connection ("c=") information in the session-level section applies to all the media of that session unless overridden by connection information in the media description. For instance, in the example below, each audio media behaves as if it were given a "c=IN IP4 192.0.2.3". An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 192.0.2.3 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 c=IN IP4 233.252.0.1/127 a=rtpmap:99 h263-1998/90000 This drops all discussion of attributes and just describes the behavior for c-lines. >> And at the same time we should polish up the definitions of the attributes defined in this document so that they are very clear how session and media level interact. > > Could you provide an example of what you have in mind? I'll try. (But please review this carefully!) In section 6: OLD: a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below). a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset. NEW: a=recvonly, a=sendrecv, a=sendonly, a=inactive At most one of recvonly/sendrecv/sendonly/inactive MAY appear at session level, and at most one MAY appear in each media section. If any one of these appears in a media section then it applies for that media section. If none appear in a media section then the one from session level, if any, applies to that media section. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present at either session level or media level, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below). For instance, in the example below, each media behaves as if it were given a "recvonly" attribute. An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=recvonly a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset. a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset. Also in section 6: OLD: a=sdplang: This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media. Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. NEW: a=sdplang: This can be a session-level attribute or a media-level attribute. Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media, overriding any sdplang attributes specified at session-level. OLD: a=lang: This can be a session-level attribute or a media-level attribute. As a session-level attribute, it specifies the default language for the session being described. As a media- level attribute, it specifies the language for that media, overriding any session-level language specified. Multiple lang attributes can be provided either at session or media level if the session or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important. NEW: a=lang: This can be a session-level attribute or a media-level attribute. Multiple lang attributes can be provided either at session or media level if the session or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important. As a session-level attribute, it specifies the default language for the session being described. As a media-level attribute, it specifies the language for that media, overriding any session-level languages specified. That's all. Thanks, Paul From pkyzivat@alum.mit.edu Thu Jan 3 19:41:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2C21F8EAA for ; Thu, 3 Jan 2013 19:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd-5HyxCNQBb for ; Thu, 3 Jan 2013 19:41:33 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD821F8EA8 for ; Thu, 3 Jan 2013 19:41:33 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id jfhY1k00216LCl05CfhYZW; Fri, 04 Jan 2013 03:41:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id jfhX1k00j3ZTu2S3SfhY7d; Fri, 04 Jan 2013 03:41:32 +0000 Message-ID: <50E64F6B.9000507@alum.mit.edu> Date: Thu, 03 Jan 2013 22:41:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <50E63E7D.5050707@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357270892; bh=8iTsWg+CffmjsaMHxnHNmc7ZJR0xqa4gd33tos5EzKw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b4AbtLEE7kKQ+6wFDb5Zq9PlhZvCQGsFGZrIPrYCjb8oqLaPD9xH9+l6P73hwyDSy 9g9pBsXhnU5FbKCpQNobyyP8tK1fGPhzDisZJi0j/cV97vnLcNYtY9ETVJBWBaKp1M o+OKzT6CuOuZCkQES/dmWRgLcfrTAPT6naLx6WxShhRUBrevarZZubQ5G76Dgd25Of uEY5ARQfBjCcL2SE06i5oplgLnFjpVq7FAcPrEnIKxmBs9cn39o60EmTLVDjZN3Bza h5G6lxRUa8q+XUBiP/JrZZCjkcy+2vjtm5U3Tg4sPcuz7NPFmlMe7+wgbl5py67v+Z 0GNRBPk5QZBVg== Cc: "" Subject: Re: [MMUSIC] The rtp-duplication related drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 03:41:34 -0000 On 1/3/13 9:47 PM, Ali C. Begen (abegen) wrote: > Thanks for the review. > > On Jan 3, 2013, at 9:29 PM, Paul Kyzivat wrote: > >> Ali, >> >> On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote: >>> Hi everyone, >>> >>> The following two drafts have been adopted by MMUSIC a while ago and the main draft discussing the RTP duplication issues is being finalized in AVTEXT (this was also adopted as a WG item a while ago). It is simply waiting for the WG to make a decision on the srcname proposal. >>> >>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ >>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ >> >> I have a question about these: >> >> Each example shows only one group. But couldn't there be multiple duplication groups? >> > There could be. > >> If so, the current proposal has no mechanism for specifying separate duplication-delay for each group. >> > > a=duplication-delay:X could be specified in each media session. For example: > > a=rtpmap:100 MP2T/90000 > a=ssrc:1000 cname:ch1@example.com > a=ssrc:1010 cname:ch1@example.com > a=ssrc-group:DUP 1000 1010 > a=duplication-delay:100 > a=mid:Group1 > a=rtpmap:101 MP2T/90000 > a=ssrc:2000 cname:ch2@example.com > a=ssrc:2010 cname:ch2@example.com > a=ssrc-group:DUP 2000 2010 > a=duplication-delay:150 > a=mid:Group2 This makes the attributes very order dependent. If this is intended, then I think you need more words to say that. Currently it says: If used as a media-level attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" grouping semantics... What does "used with" mean? I assumed it simply meant that both attributes had to be present in the media section. But what you are saying now says that there is some very specific ordering required. E.g. that the a=duplicaation-delay must follow the a=ssrc-group:DUP to which it applies, and precede any other a=ssrc-group:DUP. This is possible, but ugly to specify. > (The SSRC need not be different as SSRC only need to be unique within each media session) > > For the non-ssrc grouping, your comment holds. It does not support specifying different delay values for different groups. Do you think we should support distinct delay values for different groups (which probably means duplication-delay attribute has to be media-level only)? I don't know. Nothing seems appealing. Thanks, Paul > -acbegen > >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From abegen@cisco.com Thu Jan 3 20:20:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD021F8BED for ; Thu, 3 Jan 2013 20:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.989 X-Spam-Level: X-Spam-Status: No, score=-6.989 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XGhidqi-1ly for ; Thu, 3 Jan 2013 20:20:13 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 74BE021F8BE8 for ; Thu, 3 Jan 2013 20:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4071; q=dns/txt; s=iport; t=1357273213; x=1358482813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TZLnqpDe4eFLZAj8Wu/L8eckSuKKiwjFHZxh981w41s=; b=IA36YrEP7ELmDYWRufu6mzHPkQbhLEOwqoJie/wMh+OJ5sJm55bjDEoJ Uk8rOTV/Ru313U4MU3DtWe2lKjsyUxPx8x4+rVHs11f4zuO1nJnsNeKhH 2I3F2XVVIar0MxSUSW+Hv4ntsiOc/Zduv+xWeSQuzpC1YzF3to7x80hpw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACxX5lCtJV2a/2dsb2JhbABFDoJeumEWc4IeAQEBAwEBAQFrCwULAgEIDgoKJCcLJQIEDgUIiAUGAQu2XpA4YQOILYoshE+PLII2PoIm X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208";a="158784271" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jan 2013 04:20:12 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r044KCC3032600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 04:20:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 22:20:12 -0600 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] The rtp-duplication related drafts Thread-Index: AQHN6gIIZX3irh0G9UC8vBTgxKH8HJg41yeAgAAFCQCAAA8mgIAACswA Date: Fri, 4 Jan 2013 04:20:11 +0000 Message-ID: References: <50E63E7D.5050707@alum.mit.edu> <50E64F6B.9000507@alum.mit.edu> In-Reply-To: <50E64F6B.9000507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.199] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <97C8FDB181CC8F4F942B439B2723BEB7@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [MMUSIC] The rtp-duplication related drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 04:20:18 -0000 On Jan 3, 2013, at 10:41 PM, Paul Kyzivat wrote: > On 1/3/13 9:47 PM, Ali C. Begen (abegen) wrote: >> Thanks for the review. >>=20 >> On Jan 3, 2013, at 9:29 PM, Paul Kyzivat wrote: >>=20 >>> Ali, >>>=20 >>> On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote: >>>> Hi everyone, >>>>=20 >>>> The following two drafts have been adopted by MMUSIC a while ago and t= he main draft discussing the RTP duplication issues is being finalized in A= VTEXT (this was also adopted as a WG item a while ago). It is simply waitin= g for the WG to make a decision on the srcname proposal. >>>>=20 >>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ >>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping= / >>>=20 >>> I have a question about these: >>>=20 >>> Each example shows only one group. But couldn't there be multiple dupli= cation groups? >>>=20 >> There could be. >>=20 >>> If so, the current proposal has no mechanism for specifying separate du= plication-delay for each group. >>>=20 >>=20 >> a=3Dduplication-delay:X could be specified in each media session. For ex= ample: >>=20 >> a=3Drtpmap:100 MP2T/90000 >> a=3Dssrc:1000 cname:ch1@example.com >> a=3Dssrc:1010 cname:ch1@example.com >> a=3Dssrc-group:DUP 1000 1010 >> a=3Dduplication-delay:100 >> a=3Dmid:Group1 >> a=3Drtpmap:101 MP2T/90000 >> a=3Dssrc:2000 cname:ch2@example.com >> a=3Dssrc:2010 cname:ch2@example.com >> a=3Dssrc-group:DUP 2000 2010 >> a=3Dduplication-delay:150 >> a=3Dmid:Group2 >=20 > This makes the attributes very order dependent. If this is intended, then= I think you need more words to say that. Currently it says: >=20 > If used as a media-level > attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" > grouping semantics... My mistake, did not copy/paste the whole thing. m=3Dvideo 30000 RTP/AVP 100 c=3DIN IP4 233.252.0.1/127 a=3Dsource-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=3Drtpmap:100 MP2T/90000 a=3Dssrc:1000 cname:ch1@example.com a=3Dssrc:1010 cname:ch1@example.com a=3Dssrc-group:DUP 1000 1010 a=3Dduplication-delay:100 a=3Dmid:Group1 m=3Dvideo 40000 RTP/AVP 101 c=3DIN IP4 233.252.0.2/127 a=3Dsource-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=3Drtpmap:101 MP2T/90000 a=3Dssrc:2000 cname:ch2@example.com a=3Dssrc:2010 cname:ch2@example.com a=3Dssrc-group:DUP 2000 2010 a=3Dduplication-delay:150 a=3Dmid:Group2 so there is one duplication-delay attribute in each media session (specifie= d by a m=3D line). It does not matter whether it is before or after the ssr= c-group line. It is OK as long as it is somewhere before the next m line. >=20 > What does "used with" mean? I assumed it simply meant that both attribute= s had to be present in the media section. But what you are saying now says = that there is some very specific ordering required. E.g. that the a=3Ddupli= caation-delay must follow the a=3Dssrc-group:DUP to which it applies, and p= recede any other a=3Dssrc-group:DUP. This is possible, but ugly to specify. I hope it is clear now? >=20 >> (The SSRC need not be different as SSRC only need to be unique within ea= ch media session) >>=20 >> For the non-ssrc grouping, your comment holds. It does not support speci= fying different delay values for different groups. Do you think we should s= upport distinct delay values for different groups (which probably means dup= lication-delay attribute has to be media-level only)? >=20 > I don't know. Nothing seems appealing. >=20 > Thanks, > Paul >=20 >> -acbegen >>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >=20 From internet-drafts@ietf.org Fri Jan 4 15:16:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904F121F8AA6; Fri, 4 Jan 2013 15:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M+DWMy1fr-2; Fri, 4 Jan 2013 15:16:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ADC21F86F4; Fri, 4 Jan 2013 15:16:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130104231641.3704.7679.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2013 15:16:41 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 23:16:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Media Capabilities Ne= gotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-17.txt Pages : 64 Date : 2013-01-04 Abstract: Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This document updates the IANA Considerations of RFC 5939. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-media-capabilities= -17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Jan 7 07:39:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9751821F892A; Mon, 7 Jan 2013 07:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTV7hiIr0qo3; Mon, 7 Jan 2013 07:39:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873A321F8945; Mon, 7 Jan 2013 07:39:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107153948.26549.18041.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 07:39:48 -0800 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Media Capabilities Negotiation' to Proposed Standard (draft-ietf-mmusic-sdp-media-capabilities-17.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 15:39:49 -0000 The IESG has approved the following document: - 'Session Description Protocol (SDP) Media Capabilities Negotiation' (draft-ietf-mmusic-sdp-media-capabilities-17.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities/ Technical Summary The Session Description Protocol (SDP) has a general framework for endpoints to indicate and negotiate capabilities within SDP. However, the base framework defines capabilities for negotiating transport protocols and attributes. In this document, the SDP capability negotiation framework is extended with the ability to additionally indicate and negotiate media types and their associated parameters. Working Group Summary The first version of the document is dating February 2007. Since then, the MMUSIC working group has been progressing the document until getting satisfied with the current version. Document Quality The document has been reviewed and contributed by many participants of the working group, among others: Culleng Jennings, Christer Holmberg, Matt Lepinski, Joerg Ott, Colin Perkins, Thomas Stach, Ingemar Johansson, Andrew Allen, and Magnus Westerlund. The document was first WGLCed on version 10 (July 2010) and subsequently on version 14 (July 2012). All the open issues have been addressed and the WG has got consensus on version 15. Personnel Miguel Garcia is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director. From iesg-secretary@ietf.org Mon Jan 7 09:30:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB2121F890E; Mon, 7 Jan 2013 09:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDvDVS3ptI-J; Mon, 7 Jan 2013 09:30:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3ED21F88F5; Mon, 7 Jan 2013 09:30:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 09:30:18 -0800 Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 17:30:19 -0000 The RTCWEB and MMUSIC working groups would like to announce an upcoming joint interim meeting. The meeting will be held in the Boston, Massachusetts area on February 5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working group. Full details, including meeting site, nearby hotels, and other logistics have been posted to both the rtcweb and mmusic mailing lists = (http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, = http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html). From fandreas@cisco.com Mon Jan 7 10:36:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C420B21F8467 for ; Mon, 7 Jan 2013 10:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.243 X-Spam-Level: X-Spam-Status: No, score=-9.243 tagged_above=-999 required=5 tests=[AWL=1.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvyjA5mnM9YR for ; Mon, 7 Jan 2013 10:36:52 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 823A421F843E for ; Mon, 7 Jan 2013 10:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3787; q=dns/txt; s=iport; t=1357583812; x=1358793412; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=8oalTZ7gYQjc5776uH/3rq2edzK+lVT7r7IF9MpZULg=; b=GBxJ/kq8NDkIL9VbFhAQPM+VxfgXOCtXdYuEJHJhVat3Fii9zmiiZYLR FQ6ndJBGbVDvxw3AOxSK9lBXjRoka+DkDTKqdHbH5DIBHq6+SMml8nCqy h0H3W9Ie7S2KTAuEavPvUOdCBYPKkbafdgmRunpCMliILarV/rNuH1wOz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8HAHcV61CtJXHA/2dsb2JhbABFg0eCcoVesT0Wc4IeAQEBBCNLCg0EDw0DAQIKFgsCAgkDAgECATsCCAYNBgIBAQWIDgynBI8djG2DFYETA4hhjSqQSYMSgVM X-IronPort-AV: E=Sophos;i="4.84,425,1355097600"; d="scan'208,217";a="159716729" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jan 2013 18:36:52 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r07Iap8N027072 for ; Mon, 7 Jan 2013 18:36:51 GMT Message-ID: <50EB15C3.2010707@cisco.com> Date: Mon, 07 Jan 2013 13:36:51 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic References: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> In-Reply-To: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060009060205040302040807" Subject: [MMUSIC] Fwd: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 18:36:54 -0000 This is a multi-part message in MIME format. --------------060009060205040302040807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Re-sending to MMUSIC list only. Thanks -- Flemming -------- Original Message -------- Subject: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 Date: Mon, 7 Jan 2013 09:30:18 -0800 From: IESG Secretary To: IETF Announcement List CC: , The RTCWEB and MMUSIC working groups would like to announce an upcoming joint interim meeting. The meeting will be held in the Boston, Massachusetts area on February 5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working group. Full details, including meeting site, nearby hotels, and other logistics have been posted to both the rtcweb and mmusic mailing lists (http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html). . --------------060009060205040302040807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Re-sending to MMUSIC list only.

Thanks

-- Flemming


-------- Original Message --------
Subject: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013
Date: Mon, 7 Jan 2013 09:30:18 -0800
From: IESG Secretary <iesg-secretary@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: <rtcweb@ietf.org>, <mmusic@ietf.org> 


The RTCWEB and MMUSIC working groups would like to announce an upcoming
joint interim meeting.

The meeting will be held in the Boston, Massachusetts area on February
5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working
group. Full details, including meeting site, nearby hotels, and other
logistics have been posted to both the rtcweb and mmusic mailing lists 
(http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, 
http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html).
.


--------------060009060205040302040807-- From pkyzivat@alum.mit.edu Mon Jan 7 12:06:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F721F0CDF for ; Mon, 7 Jan 2013 12:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60+0iCiq+o2t for ; Mon, 7 Jan 2013 12:06:42 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 81B651F0CB3 for ; Mon, 7 Jan 2013 12:06:42 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id l0ev1k0081swQuc5586hGa; Mon, 07 Jan 2013 20:06:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id l86h1k00G3ZTu2S3b86hHj; Mon, 07 Jan 2013 20:06:41 +0000 Message-ID: <50EB2AD0.1080701@alum.mit.edu> Date: Mon, 07 Jan 2013 15:06:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <50E63E7D.5050707@alum.mit.edu> <50E64F6B.9000507@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357589201; bh=i3iYgrKEnRN17ymRmTjX/Kf/fg07K2n7u1FLMpoMJ5A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Iz+NrtH+A6lt0tjJnskdJzGkof1BBduweEYClWfy4ofJ9ntzNbh1W255SYasNxlZ9 AFqV+cUnFrAX4m+qLsg5vfkjxtSWS93F3gP1rRfkLq6YDFxEwAA7641wLaprod2aoO 55ZZum6iqmvgxJG6T0HpGYZFnx/0+C98Td8I6yC2JW5vhD+d7+BWfb+cCEYzWG7t2g 8jLdSfqYRHMoAqwbavwRQd9U3SG87QCMIuoKYZrqngxlI/5eUCbU67SRR/dDtRfwfh L3mgf7qh/QddYazuF6Xkjpw8TDc73NawKYW+6K7YvPZZAiZeZCIHPg6Bydk0sahK3P JOEVQR7scznBQ== Cc: "" Subject: Re: [MMUSIC] The rtp-duplication related drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 20:06:44 -0000 On 1/3/13 11:20 PM, Ali C. Begen (abegen) wrote: > > On Jan 3, 2013, at 10:41 PM, Paul Kyzivat wrote: > >> On 1/3/13 9:47 PM, Ali C. Begen (abegen) wrote: >>> Thanks for the review. >>> >>> On Jan 3, 2013, at 9:29 PM, Paul Kyzivat wrote: >>> >>>> Ali, >>>> >>>> On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote: >>>>> Hi everyone, >>>>> >>>>> The following two drafts have been adopted by MMUSIC a while ago and the main draft discussing the RTP duplication issues is being finalized in AVTEXT (this was also adopted as a WG item a while ago). It is simply waiting for the WG to make a decision on the srcname proposal. >>>>> >>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ >>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ >>>> >>>> I have a question about these: >>>> >>>> Each example shows only one group. But couldn't there be multiple duplication groups? >>>> >>> There could be. >>> >>>> If so, the current proposal has no mechanism for specifying separate duplication-delay for each group. >>>> >>> >>> a=duplication-delay:X could be specified in each media session. For example: >>> >>> a=rtpmap:100 MP2T/90000 >>> a=ssrc:1000 cname:ch1@example.com >>> a=ssrc:1010 cname:ch1@example.com >>> a=ssrc-group:DUP 1000 1010 >>> a=duplication-delay:100 >>> a=mid:Group1 >>> a=rtpmap:101 MP2T/90000 >>> a=ssrc:2000 cname:ch2@example.com >>> a=ssrc:2010 cname:ch2@example.com >>> a=ssrc-group:DUP 2000 2010 >>> a=duplication-delay:150 >>> a=mid:Group2 >> >> This makes the attributes very order dependent. If this is intended, then I think you need more words to say that. Currently it says: >> >> If used as a media-level >> attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" >> grouping semantics... > > My mistake, did not copy/paste the whole thing. > > m=video 30000 RTP/AVP 100 > c=IN IP4 233.252.0.1/127 > a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 > a=rtpmap:100 MP2T/90000 > a=ssrc:1000 cname:ch1@example.com > a=ssrc:1010 cname:ch1@example.com > a=ssrc-group:DUP 1000 1010 > a=duplication-delay:100 > a=mid:Group1 > m=video 40000 RTP/AVP 101 > c=IN IP4 233.252.0.2/127 > a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 > a=rtpmap:101 MP2T/90000 > a=ssrc:2000 cname:ch2@example.com > a=ssrc:2010 cname:ch2@example.com > a=ssrc-group:DUP 2000 2010 > a=duplication-delay:150 > a=mid:Group2 > > so there is one duplication-delay attribute in each media session (specified by a m= line). It does not matter whether it is before or after the ssrc-group line. It is OK as long as it is somewhere before the next m line. But then, duplication-delay applies to a=ssrc-group:DUP groups within that media section. You could have two groups of ssrcs in there. So the problem is the same as the problem across different m-lines. E.g. m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=rtpmap:100 MP2T/90000 a=ssrc:1000 cname:ch1@example.com a=ssrc:1010 cname:ch1@example.com a=ssrc:1020 cname:ch1@example.com a=ssrc:1030 cname:ch1@example.com a=ssrc-group:DUP 1000 1010 a=duplication-delay:100 a=ssrc-group:DUP 1020 1030 a=duplication-delay:200 m=video 40000 RTP/AVP 101 c=IN IP4 233.252.0.2/127 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=rtpmap:101 MP2T/90000 a=ssrc:2000 cname:ch2@example.com a=ssrc:2010 cname:ch2@example.com a=ssrc-group:DUP 2000 2010 a=ssrc:2020 cname:ch2@example.com a=ssrc:2030 cname:ch2@example.com a=ssrc-group:DUP 2020 2030 a=duplication-delay:250 From what you say, the two duplication-delay attributes in one media section would make no sense. >> What does "used with" mean? I assumed it simply meant that both attributes had to be present in the media section. But what you are saying now says that there is some very specific ordering required. E.g. that the a=duplicaation-delay must follow the a=ssrc-group:DUP to which it applies, and precede any other a=ssrc-group:DUP. This is possible, but ugly to specify. > > I hope it is clear now? > >> >>> (The SSRC need not be different as SSRC only need to be unique within each media session) >>> >>> For the non-ssrc grouping, your comment holds. It does not support specifying different delay values for different groups. Do you think we should support distinct delay values for different groups (which probably means duplication-delay attribute has to be media-level only)? Well, for the non-ssrc grouping you could put the group name in the a=duplication-delay attribute value. And for the ssrc-grouping case you could put one of the grouped ssrcs in the a=duplication-delay attr value. Thanks, Paul From fandreas@cisco.com Mon Jan 7 17:08:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC311E80D2 for ; Mon, 7 Jan 2013 17:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.514 X-Spam-Level: X-Spam-Status: No, score=-9.514 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3kCnrQI3kZD for ; Mon, 7 Jan 2013 17:07:59 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B455C11E80B8 for ; Mon, 7 Jan 2013 17:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5778; q=dns/txt; s=iport; t=1357607279; x=1358816879; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=iGQRaS/UsDitOkbTdy+lVUkZ8NRqkA+aKEAG4bEURVg=; b=av+Uzwxipo3YJ99O5MILyXqQA8KgLTOGq9DnQP0X1c4xgC4MOGEjLq9b YeFCjXxAw4gm4fmIZFSbKoeLHunanqHhHhYf+j7Cqhyict/FTvcfCT8Cf SlYSL87WlNPWaPoqPQBoj6B22vx+S2aDqW2PtfQH9aMHc8J9Rt8R5PyjE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4HACBw61CtJXG8/2dsb2JhbABFg0eIULE6FnOCHgEBAQQBAQFrCg0ECxEDAQIBCRYPCQMCAQIBFSgIBg0GAgEBBYgODLZ8jG2EKAOIYY0qkEmDEoFT X-IronPort-AV: E=Sophos;i="4.84,427,1355097600"; d="scan'208,217";a="159855514" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jan 2013 01:07:59 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0817wc4013733 for ; Tue, 8 Jan 2013 01:07:58 GMT Message-ID: <50EB716E.9070403@cisco.com> Date: Mon, 07 Jan 2013 20:07:58 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic References: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> <50EB15C3.2010707@cisco.com> In-Reply-To: <50EB15C3.2010707@cisco.com> Content-Type: multipart/alternative; boundary="------------050808000305030204010503" Subject: Re: [MMUSIC] Fwd: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 01:08:00 -0000 This is a multi-part message in MIME format. --------------050808000305030204010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For further details on meeting site, hotels, etc., please see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg05826.html Stay tuned for more details around agenda, etc. Thanks -- Flemming On 1/7/13 1:36 PM, Flemming Andreasen wrote: > Re-sending to MMUSIC list only. > > Thanks > > -- Flemming > > > -------- Original Message -------- > Subject: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 > Date: Mon, 7 Jan 2013 09:30:18 -0800 > From: IESG Secretary > To: IETF Announcement List > CC: , > > > > The RTCWEB and MMUSIC working groups would like to announce an upcoming > joint interim meeting. > > The meeting will be held in the Boston, Massachusetts area on February > 5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working > group. Full details, including meeting site, nearby hotels, and other > logistics have been posted to both the rtcweb and mmusic mailing lists > (http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, > http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html). > . > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------050808000305030204010503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For further details on meeting site, hotels, etc., please see:
	http://www.ietf.org/mail-archive/web/rtcweb/current/msg05826.html

Stay tuned for more details around agenda, etc.

Thanks

-- Flemming


On 1/7/13 1:36 PM, Flemming Andreasen wrote:
Re-sending to MMUSIC list only.

Thanks

-- Flemming


-------- Original Message --------
Subject: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013
Date: Mon, 7 Jan 2013 09:30:18 -0800
From: IESG Secretary <iesg-secretary@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: <rtcweb@ietf.org>, <mmusic@ietf.org> 


The RTCWEB and MMUSIC working groups would like to announce an upcoming
joint interim meeting.

The meeting will be held in the Boston, Massachusetts area on February
5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working
group. Full details, including meeting site, nearby hotels, and other
logistics have been posted to both the rtcweb and mmusic mailing lists 
(http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html, 
http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html).
.






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

--------------050808000305030204010503-- From fandreas@cisco.com Mon Jan 7 19:23:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E1921F870A for ; Mon, 7 Jan 2013 19:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.695 X-Spam-Level: X-Spam-Status: No, score=-9.695 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qJhSGbaV5ky for ; Mon, 7 Jan 2013 19:23:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63221F84F6 for ; Mon, 7 Jan 2013 19:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3903; q=dns/txt; s=iport; t=1357615431; x=1358825031; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=soFoU2b5d1XexTFZ5HDUINd0iho53dkICQBKJ3p/bO0=; b=KNP0duWwJe+s42w3FhSxf5jx+tStC1ktrgmLUIOxJ6Th5Rkjw+xgL2Rv IRQyCx2QLbEYD7Xhr52+W4/3N+fasPk0GAHlfQV+cJFDyAAtG6L1uMVIm DaF8KXe975i9MBSlqxWI7E+YM9WS9FrRkXt79DYPWAyUbRX/QcmppaXNj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIIAHmQ61CtJV2Y/2dsb2JhbABFg0e6DBZzgl1AATwWGAMCAQIBSw0BBwEBBRKHfAy3J4xngVKCXAOIYYl3gzOQSYJnK4FK X-IronPort-AV: E=Sophos;i="4.84,428,1355097600"; d="scan'208";a="159864403" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jan 2013 03:23:50 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r083NnGi032089; Tue, 8 Jan 2013 03:23:50 GMT Message-ID: <50EB9145.8050301@cisco.com> Date: Mon, 07 Jan 2013 22:23:49 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "draft-boucadair-mmusic-altc@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic , Gonzalo Camarillo Subject: [MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 03:23:52 -0000 Hi I am the assigned SDP directorate reviewer for draft-boucadair-mmusic-altc-07 For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: --------- - The document does not adequately cover how it relates to the existing Standards Track mechanism for solving the similar problem in a different and more general way (namely ICE [RFC 5245]) - The document has technical issues - The document has a few minor editorial issues New SDP Information Elements: --------------------------- The draft defines a new "a=altc" attribute Technical Comments: ------------------ 1) The Abstract positions the document as an alternative to ANAT, but without certain problems experienced by ANAT. The abstract fails to mention that a general Standards Track solution in the form of ICE (RFC 5245) has been defined whereas the solution defined in this document has a narrower scope and various limitations. 2) Section 1.1, third paragraph. The document states that ICE is processing intensive and has seen limited deployment. While this is perhaps a matter of debate, it would be helpful if the document would point out the limitations of using instead of ICE. Areas that come to mind here are - lack of NAT traversal (without network/SBC support), - no connectivity verification (verifying functioning path as well as authenticating/correlating initial incoming media packets with signaling), - support for non-contiguous RTP/RTCP port pairs in alternatives There are probably others and it would be helpful to point those out to potential implementers (the simplicity comes with trade-offs). 3) Section 1.1, third paragraph: The document claims that ICE is not usable in closed networks. This is incorrect (it is however correct that there are scenarios where ICE does not work, however those scenarios should then be explained instead). 4) Section 1.1, fourth paragraph: The document claims to be compliant with RFC 6157 because RFC 6157 includes the sentence The use of ICE can be avoided for signaling messages that stay within such managed networks The quote is taken out of context however as it applies to a scenario in RFC 6157 where the entire network is IPv6 based, whereas the mechanism defined here is for scenarios where it is not. 5) Section 3.2, first paragraph A compliant SDP parser will ignore any session description that contains attribute lines it does not support. No - only the unsupported attribute lines will be ignored (which is also what the rest of the draft implies) 6) Section 4.1, attribute definition The optional trailing integer part is not defined. 7) Section 4.1, Bullet list, "port" This does not seem to work with the "a=rtcp" attribute [RFC 4566], and hence there may be issues with non-contiguous RTP/RTCP port pair support in alternatives. 8) Section 4.1, 4th last paragraph The mechanism relies on implicit ordering of attribute lines. If an intermediary changes the order, it would have unintended side-effects. It would be much better to have an explicit ordering mechanism. In the absence of that, the potential reordering issue should be called out. Editorial Comments: ----------------- 1) Section 1.1, second paragraph. Add reference after "DS-Lite" 2) sdp-cap-neg should be SDPCapNeg (multiple occurrences) 3) Section 1.3, first paragraph: Add reference to RFC 4091. 4) Section 1.3, second paragraph: Add text and reference to RFC 6157 for a solution to "SIP layer address family interworking" 5) Section 4.2.3 Add RFC reference after "ICE" 6) Section 4.2.4 Add RFC reference after "SDPCapNeg" Thanks -- Flemming From mohamed.boucadair@orange.com Tue Jan 8 01:59:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790AC21F883A for ; Tue, 8 Jan 2013 01:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5HAx3OsEZrk for ; Tue, 8 Jan 2013 01:59:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E17D321F8484 for ; Tue, 8 Jan 2013 01:59:17 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 23DFA26496F; Tue, 8 Jan 2013 10:59:17 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 041E54C0E6; Tue, 8 Jan 2013 10:59:17 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 8 Jan 2013 10:59:16 +0100 From: To: Flemming Andreasen , "draft-boucadair-mmusic-altc@tools.ietf.org" Date: Tue, 8 Jan 2013 10:59:15 +0100 Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07 Thread-Index: Ac3tT5fE/N6om6rvTs+c2B0tcbwcVgAM4mfQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EA2CC05EE@PUEXCB1B.nanterre.francetelecom.fr> References: <50EB9145.8050301@cisco.com> In-Reply-To: <50EB9145.8050301@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: mmusic , Gonzalo Camarillo Subject: Re: [MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 09:59:22 -0000 Dear Flemming, Thank you for the review.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >De la part de Flemming Andreasen >Envoy=E9 : mardi 8 janvier 2013 04:24 >=C0 : draft-boucadair-mmusic-altc@tools.ietf.org >Cc : mmusic; Gonzalo Camarillo >Objet : [MMUSIC] SDP Directorate: Review of=20 >draft-boucadair-mmusic-altc-07 > >Hi > >I am the assigned SDP directorate reviewer for=20 >draft-boucadair-mmusic-altc-07 > >For background on the SDP directorate, please see the FAQ at > > http://www.ietf.org/iesg/directorate/sdp.html > >Please wait for direction from your document shepherd or AD before=20 >posting a new version of the draft. > >Summary: >--------- >- The document does not adequately cover how it relates to the=20 >existing=20 >Standards Track mechanism for solving the similar problem in a=20 >different=20 >and more general way (namely ICE [RFC 5245]) >- The document has technical issues >- The document has a few minor editorial issues > > >New SDP Information Elements: >--------------------------- >The draft defines a new "a=3Daltc" attribute > > >Technical Comments: >------------------ >1) The Abstract positions the document as an alternative to ANAT, but=20 >without certain problems experienced by ANAT. The abstract fails to=20 >mention that a general Standards Track solution in the form of=20 >ICE (RFC=20 >5245) has been defined whereas the solution defined in this=20 >document has=20 >a narrower scope and various limitations. Med: I updated the abstract as follows:=20 OLD: This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. NEW: This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. The proposed solution is applicable to scenarios where connectivity checks are not required. > >2) Section 1.1, third paragraph. The document states that ICE is=20 >processing intensive and has seen limited deployment. While this is=20 >perhaps a matter of debate, it would be helpful if the document would=20 >point out the limitations of using instead of ICE. Areas that come to=20 >mind here are >- lack of NAT traversal (without network/SBC support), >- no connectivity verification (verifying functioning path as well as=20 >authenticating/correlating initial incoming media packets with=20 >signaling), >- support for non-contiguous RTP/RTCP port pairs in alternatives >There are probably others and it would be helpful to point=20 >those out to=20 >potential implementers (the simplicity comes with trade-offs). Med: The scope of ALTC is very clear: scenarios where there is no need for = connectivity checks. This is already mentioned in Section 2 and I tried to = make it clear in the new proposed abstract text. =20 > >3) Section 1.1, third paragraph: The document claims that ICE is not=20 >usable in closed networks. This is incorrect (it is however=20 >correct that=20 >there are scenarios where ICE does not work, however those scenarios=20 >should then be explained instead). Med: closed networks are provided only as an example. Anyway, I updated the= text as follows:=20 OLD: (e.g., closed networks) NEW: (e.g., closed networks making use of SBCs) > >4) Section 1.1, fourth paragraph: The document claims to be compliant=20 >with RFC 6157 because RFC 6157 includes the sentence > >The use of ICE can be avoided for signaling messages that stay within=20 >such managed networks > >The quote is taken out of context however as it applies to a=20 >scenario in=20 >RFC 6157 where the entire network is IPv6 based, whereas the mechanism=20 >defined here is for scenarios where it is not. Med: The text from RFC6157 is: Implementations are encouraged to use ICE; however, the normative strength of the text above is left at a SHOULD since in some managed networks (such as a closed enterprise network) it is possible for the administrator to have control over the IP version utilized in all nodes and thus deploy an IPv6-only network, for example. The use of ICE can be avoided for signaling messages that stay within such managed networks. IPv6-only is mentioned as an example. The key word IMHO in the above text i= s "managed networks".=20 > >5) Section 3.2, first paragraph > >A compliant SDP parser will ignore any session description=20 >that contains=20 >attribute lines it does not support. > >No - only the unsupported attribute lines will be ignored=20 >(which is also=20 >what the rest of the draft implies) Med: OK. I updated the text. > >6) Section 4.1, attribute definition >The optional trailing integer part is not defined. Med: Thanks for catching this. I updated section 4.1. > >7) Section 4.1, Bullet list, "port" >This does not seem to work with the "a=3Drtcp" attribute [RFC 4566], and=20 >hence there may be issues with non-contiguous RTP/RTCP port=20 >pair support=20 >in alternatives. Med: We updated the text as follows: OLD: Note that for RTCP, if applicable for the given media types, each side would act as if the chosen "altc" attribute's port number was in the 'm=3D' media line. Typically, this would mean RTCP is sent to the odd +1 of the port number, unless some other attribute determines otherwise. NEW: Note that for RTCP, if applicable for the given media types, each side would act as if the chosen "altc" attribute's port number was in the 'm=3D' media line. Typically, this would mean RTCP is sent to the odd +1 of the port number, unless some other attribute determines otherwise. For example the RTP/RTCP multiplexing mechanism defined in [RFC5761] can still be used with ALTC, such that if both sides support multiplexing they will indicate so using the 'a=3Drtcp-mux' attribute as defined in [RFC5761]; but the IP connection address and port they use may be chosen using the ALTC mechanism. If the SDP offerer wishes to use the RTCP attribute defined in [RFC3605], a complication can arise since it may not be clear which address choice the 'a=3Drtcp' attribute applies to, relative the choices offered by ALTC. Technically RFC 3605 allows indicating the address for RTCP explicitly in the 'a=3Drtcp' attribute itself, but this is optional and rarely used. Since RFC 3605 did not prevent encoding multiple 'a=3Drtcp' attributes per media description, this document recommends encoding the first 'a=3Drtcp' attribute to be for the address choice encoded in the "m=3D" line, and a second 'a=3Drtcp' attribute for the alternate address provided by the 'a=3Daltc' attribute. In other words, if the 'a=3Drtcp' attribute explicitly encodes an address in its attribute, then that applies for ALTC as per [RFC3605]; if it does not, then ALTC assumes the first one is for the address in the "m=3D" line, and the second is for the alternate. > >8) Section 4.1, 4th last paragraph >The mechanism relies on implicit ordering of attribute lines. If an=20 >intermediary changes the order, it would have unintended side-effects.=20 >It would be much better to have an explicit ordering mechanism. In the=20 >absence of that, the potential reordering issue should be called out. Med: Is this harmful? If an intermediary entity change the order, this does= not impact the session establishment. Note the document already specify ho= w a remote UA can detect the presence of an intermediary entity changing th= e "c" line is present in the path.=20 > > >Editorial Comments: >----------------- >1) Section 1.1, second paragraph. Add reference after "DS-Lite" > >2) sdp-cap-neg should be SDPCapNeg (multiple occurrences) > >3) Section 1.3, first paragraph: Add reference to RFC 4091. > >4) Section 1.3, second paragraph: Add text and reference to=20 >RFC 6157 for=20 >a solution to "SIP layer address family interworking" > >5) Section 4.2.3 >Add RFC reference after "ICE" > >6) Section 4.2.4 >Add RFC reference after "SDPCapNeg" Med: I implemented all the proposed changed. Thanks.=20 > > >Thanks > >-- Flemming > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic >= From christer.holmberg@ericsson.com Tue Jan 8 04:30:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528EC21F867E for ; Tue, 8 Jan 2013 04:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAbg-ttZJufy for ; Tue, 8 Jan 2013 04:30:07 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F40AE21F8671 for ; Tue, 8 Jan 2013 04:30:06 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-41-50ec114dce8f Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 49.7F.04318.D411CE05; Tue, 8 Jan 2013 13:30:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.11]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:30:05 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 Thread-Index: Ac3tm68F9DIBrFHTT62cRwDB61Qgww== Date: Tue, 8 Jan 2013 12:30:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B09423BESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja6v4JsAg9YOQ4uTr84wWkxd/pjF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mq4df4Fc0HPdMaKl4tmMTcwLm9i7GLk5JAQ MJG4veQmE4QtJnHh3nq2LkYuDiGBQ4wS2/fMYQNJCAksYpTo2hnXxcjBwSZgIdH9TxskLCKg LvF1bw8ziM0sECnx/PYtVpASYQF7iX+duhAlLhKf/85ngbD1JF4d/c0OYrMIqEhcXHsGzOYV 8JZYtmkr2AmMQCd8P7WGCWKkuMStJ/OhThOQWLLnPDOELSrx8vE/VghbUWLn2XaoE/Ilpsz4 yAIxU1Di5MwnLBMYhWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSN7 bmJmTnq5+SZGYIwc3PLbYAfjpvtihxilOViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamBkmhccu+Wla96ikwYJD9a8X/Dr5qm8SbNWTtcp4zrFwqH8KV/giAfvuh8XJS+/LL6n +vjNrGO/hNaIrn6jvm3D6rZNc7+dyA+8XPLs+/ZprpvCkmxFJWV/7XbwNW5h4za+p8Iuu3qF 5EPTy+2LY4y65Lr93y6X5521fImm5VIpH3v2ennBSc1xSizFGYmGWsxFxYkAmuolHF8CAAA= Cc: "draft-ietf-rmt-flute-sdp@tools.ietf.org" Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 12:30:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B09423BESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am the assigned SDP directorate reviewer for draft-ietf-rmt-flute-sdp-03 For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. SUMMARY: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have technical concerns with a number of the technical content of this do= cument, and at least the "Composite Session" concept, as currently defined in the document, would need to be discussed in MMUSIC. I think they= need to be resolved/clarified before this document can be published. Regards, Christer -------------------------------------------------------- TECHNICAL =3D=3D=3D=3D=3D=3D=3D=3D=3D General: ------------ T-GEN-1: The draft seems to define a new generic SDP mechanism= , "Composite Session", for grouping media streams into protocol-specific se= ssions. I am not really sure what that means, but it seems to go outside th= e scope of FLUTE. I also think it overlaps with the SDP BUNDLE work, and su= ch work shall be done in MMUSIC. "The Composite Session mechanism enables the grouping of me= dia lines in to distinct sessions. The complete Composite Session se= mantics are protocol-specific - as determined by the protocol id of= the grouped media lines." T-GEN-2: Maybe I've missed it, but it is a little unclear to m= e why the grouping framework is needed in the first place. If that is descr= ibed somewhere, please tell me :) In section 3.2.1, the text says: "The Composite Session provides an unambiguous way to defin= e multiple FLUTE sessions as distinct from multiple the media-sessions= semantics of RTP." But, what is the technical need for this? T-GEN-3: The draft uses the same source address for every m- l= ine associated with a group, but it uses different addresses in each m- lin= e. Aren't the media streams symmetric? T-GEN-4: There is chapter describing the SDP Offer/Answer aspe= cts. How is the answer generated? What if the answerer does not support (or= , supports, but don't want to use) the mechanism? If the mechanism is not to be used with SDP Offer/Answer, but e.g. for some= kind of declaration, I think that needs to be described. Section 1: ------------- T-1-1: The text says: "Note, this document may also be used to describe sessions = of the experimental FLUTE specification [RFC3926]." I think you need to indicate whether or not there will be any changes in th= e usage of SDP in that case. Section 3.2: --------------- T-3-2: I would like to have some input from the MMUSIC c= ommunity whether "FLUTE/UDP/ESP" is appropriate to describe a IPSec encrypt= ed FLUTE channel, or whether something like "SFLUTE/UDP" should be used ins= tead. Section 3.11: ----------------- T-3_11-1: As the syntax mandates at least one fmt value, I sugg= est that the document specifies which value SHALL be used. EDITORIAL =3D=3D=3D=3D=3D=3D=3D=3D=3D General: ----------- E-GEN-1: The Abstract and Introduction needs to explicitly sta= te that the specification defines a new SDP grouping framework value. The A= bstract also needs to mention the new SDP protocol values. Section 1: ------------- E-1-1: s/defines two new protocol identifiers/defines tw= o new SDP protocol values E-1-2: I suggest to remove "The formal ABNF syntax [RFC5= 234] is used for the attributes." It only needs to be stated in the section= defining the new SDP attributes. Section 3: ------------- E-3-1: I think the second last paragraph, comparing FLUT= E with RTP media streams, sessions etc is confusing. I think it is enough t= o describe that each SDP m- line represents a FLUTE channel. Section 3.1: --------------- E-3_1-1: I would suggest to have a new parent chapter, "SDP E= xtensions", with sub-chapters defining the new SDP protocol values, attribu= tes etc. Section 3.11: ----------------- E-3_11-1: I suggest to remove this section. It's not needed, an= d I don't even agree with the content. Section 4: ------------- E-4-1: Instead of saying "a=3DFEC-declaration line", I s= uggest to say "SDP FEC-declaration attribute". (Also applies to the descrip= tion of the other attributes). --_000_7594FB04B1934943A5C02806D1A2204B09423BESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I am the assigned SDP directorate reviewer for

draft-ietf-rmt-flute-sdp-03

 

For background on the SDP directorate, please see= the FAQ at

 

     http://www.ietf.org/iesg/directorate/sdp.html

 

Please wait for direction from your document shep= herd or AD before posting a new version of the draft.

 

SUMMARY:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I have technical concerns with a number of the techn= ical content of this document, and at least the “Composite Session= 221; concept, as currently

defined in the document, would need to be discussed = in MMUSIC. I think they need to be resolved/clarified before this document = can be published.

 

Regards,

 

Christer

 

 

 

----------------------------------------------------= ----

 

 

 

 

TECHNICAL

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

General:

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

 

T-GEN-1:       &n= bsp;      The draft seems to define a new generic = SDP mechanism, “Composite Session”, for grouping media streams = into protocol-specific sessions. I am not really sure what that means, but = it seems to go outside the scope of FLUTE. I also think it overlaps with the SDP BUNDLE work, and such work sh= all be done in MMUSIC.

 

        &nbs= p;       “The Composite Session mechani= sm enables the grouping of media lines

         &nb= sp;      in to distinct sessions.  The comple= te Composite Session semantics

         &nb= sp;      are protocol-specific - as determined by = the protocol id of the

         &nb= sp;      grouped media lines.”

 

 

T-GEN-2:       &n= bsp;      Maybe I’ve missed it, but it is a = little unclear to me why the grouping framework is needed in the first plac= e. If that is described somewhere, please tell me :)

 

In section 3.2.1, the text says:

 

        &nbs= p;       “The Composite Session provide= s an unambiguous way to define multiple

         &nb= sp;      FLUTE sessions as distinct from multiple = the media-sessions semantics

         &nb= sp;      of RTP.”

 

But, what is the technical need for this?=

 

 

T-GEN-3:       &n= bsp;      The draft uses the same source address f= or every m- line associated with a group, but it uses different addresses i= n each m- line. Aren’t the media streams symmetric?

 

T-GEN-4:       &n= bsp;      There is chapter describing the SDP Offe= r/Answer aspects. How is the answer generated? What if the answerer does no= t support (or, supports, but don’t want to use) the mechanism?

 

If the mechanism is not to be used with SDP Offer/An= swer, but e.g. for some kind of declaration, I think that needs to be descr= ibed.

 

 

Section 1:

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

 

T-1-1:       &nbs= p;            The te= xt says:

 

        &nbs= p;       “Note, this document may also = be used to describe sessions of the

         &nb= sp;      experimental FLUTE specification [RFC3926= ].”

 

I think you need to indicate whether or not there wi= ll be any changes in the usage of SDP in that case.

 

 

Section 3.2:

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

 

T-3-2:       &nbs= p;            I woul= d like to have some input from the MMUSIC community whether “FLUTE/UD= P/ESP” is appropriate to describe a IPSec encrypted FLUTE channel, or= whether something like “SFLUTE/UDP” should be used instead.

 

 

Section 3.11:

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

 

T-3_11-1:       &= nbsp;     As the syntax mandates at least one fmt value= , I suggest that the document specifies which value SHALL be used.

 

 

 

EDITORIAL

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

General:

-----------

 

E-GEN-1:       &n= bsp;      The Abstract and Introduction needs to e= xplicitly state that the specification defines a new SDP grouping framework= value. The Abstract also needs to mention the new SDP protocol values.

 

 

Section 1:

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

 

E-1-1:       &nbs= p;            s/defi= nes two new protocol identifiers/defines two new SDP protocol values

 

E-1-2:        &nb= sp;           I suggest t= o remove “The formal ABNF syntax [RFC5234] is used for the attributes= .” It only needs to be stated in the section defining the new SDP att= ributes.

 

 

Section 3:

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

 

E-3-1:       &nbs= p;            I thin= k the second last paragraph, comparing FLUTE with RTP media streams, sessio= ns etc is confusing. I think it is enough to describe that each SDP m- line= represents a FLUTE channel.

 

 

Section 3.1:

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

 

E-3_1-1:       &n= bsp;       I would suggest to have a new pare= nt chapter, “SDP Extensions”, with sub-chapters defining the ne= w SDP protocol values, attributes etc.

 

 

Section 3.11:

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

 

E-3_11-1:       &= nbsp;     I suggest to remove this section. It’s = not needed, and I don’t even agree with the content.

 

 

Section 4:

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

 

E-4-1:       &nbs= p;            Instea= d of saying “a=3DFEC-declaration line”, I suggest to say “= ;SDP FEC-declaration attribute”. (Also applies to the description of = the other attributes).

 

 

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B09423BESESSMB209ericsso_-- From christer.holmberg@ericsson.com Tue Jan 8 04:56:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9033F21F8B06 for ; Tue, 8 Jan 2013 04:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoaMVFtAz5TM for ; Tue, 8 Jan 2013 04:56:18 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 86DE921F8AE3 for ; Tue, 8 Jan 2013 04:56:17 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-0c-50ec17703cab Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.37.10459.0771CE05; Tue, 8 Jan 2013 13:56:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.11]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:56:15 +0100 From: Christer Holmberg To: "Ali C. Begen (abegen)" , "mmusic@ietf.org" Thread-Topic: The rtp-duplication related drafts - Initial comments on draft-ietf-mmusic-delayed-duplication Thread-Index: Ac3tn4sLCJXHhYY7RfKGLsAQmCTlmA== Date: Tue, 8 Jan 2013 12:56:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B094294@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvjW6B+JsAgwlPpS0ebJ/LaDF1+WMW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStj0/N+poJVPBW/th9nbWBcyNXFyMkhIWAi Mb97DzOELSZx4d56ti5GLg4hgUOMEu3N85kgnEWMEt/eLAVyODjYBCwkuv9pgzSICIRK3Ht0 mxUkLCyQK/FpliGIKSKQJ/FnshpEhZ7Epi0n2EBsFgEViYmX77CC2LwC3hKNK5rZQWxGoLXf T61hArGZBcQlbj2ZzwRxjoDEkj3noU4TlXj5+B8rhK0osfNsOzNEvY7Egt2f2CBsbYllC18z Q8wXlDg58wnLBEbhWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtuYgSG9cEtv3V3MJ46J3KI UZqDRUmcN8z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxqb9TOeO2DyReVLD0hC65vux yiOZO2+nVd9/tsjr3uK9LtzT8vJ65yhvd07215k4h6VRQNYkc+7eO2X1+0/wJaY1fD0Wds+w aMXJ7WEbs7iNTO5tWGInH2tueOqQcWburUq33C7Vi77GB1LSX2yRWM10XFaQrdglSfLxyoQZ E+rkCsJfvHX2V2Ipzkg01GIuKk4EACBuX4A5AgAA Subject: Re: [MMUSIC] The rtp-duplication related drafts - Initial comments on draft-ietf-mmusic-delayed-duplication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 12:56:18 -0000 Hi Ali, Some initial comments on draft-ietf-mmusic-delayed-duplication: Q1: I assume the attribute indicates the SENDING delay, or? I think it need= s to be more explicit. Q2: There are no SDP Offer/Answer considerations. Does the Offer have impac= t on the Answer? What is the expected behavior if the Answerer does not sup= port the mechanism? Etc. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ali C. Begen (abegen) Sent: 4. tammikuuta 2013 0:31 To: mmusic@ietf.org Subject: [MMUSIC] The rtp-duplication related drafts Hi everyone, The following two drafts have been adopted by MMUSIC a while ago and the ma= in draft discussing the RTP duplication issues is being finalized in AVTEXT= (this was also adopted as a WG item a while ago). It is simply waiting for= the WG to make a decision on the srcname proposal. http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ These two mmusic drafts are essentially completed and they are needed to be= done for the avtext draft. I hope they will be WGLC'ed some time soon. In = the mean time, I would like to get any comments, feedback that you might ha= ve. Thanks. -acbegen PS Here is the AVTEXT draft. http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From abegen@cisco.com Tue Jan 8 08:46:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA62B21F84B2 for ; Tue, 8 Jan 2013 08:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.131 X-Spam-Level: X-Spam-Status: No, score=-8.131 tagged_above=-999 required=5 tests=[AWL=1.868, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyQmElRlr7pC for ; Tue, 8 Jan 2013 08:46:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4166721F8487 for ; Tue, 8 Jan 2013 08:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2192; q=dns/txt; s=iport; t=1357663619; x=1358873219; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WjC8YtoY6Z0/9JN1BsJSz4quUXLzLK/X6iawFUg/C60=; b=P/El1Wv2ICulyxiQnx7JJJn8aEdUYy3lTJZ8tKrCrDArle065JaR111e aDF/o1VgqysEcry0xcsLv3er+tSNS4+TpSDZyEcljfG5iOWRxvvFDRGA7 D6FoeMayEWpTRF6NNNsARKjKZDWQB8350DppEiweq5s4iGCpNASsJUByv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJtM7FCtJXG8/2dsb2JhbABEvVsWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAQEEDgUIiAkGDKlOjRmQNGEDlyiPLYJ0giY X-IronPort-AV: E=Sophos;i="4.84,432,1355097600"; d="scan'208";a="160114820" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jan 2013 16:46:58 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r08Gkw2W013513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 16:46:58 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.223]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 10:46:58 -0600 From: "Ali C. Begen (abegen)" To: Christer Holmberg Thread-Topic: The rtp-duplication related drafts - Initial comments on draft-ietf-mmusic-delayed-duplication Thread-Index: Ac3tn4sLCJXHhYY7RfKGLsAQmCTlmAAUodaA Date: Tue, 8 Jan 2013 16:46:57 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B094294@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B094294@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.148] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] The rtp-duplication related drafts - Initial comments on draft-ietf-mmusic-delayed-duplication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 16:47:00 -0000 Hi Christer, On Jan 8, 2013, at 7:56 AM, Christer Holmberg wrote: > Hi Ali, >=20 > Some initial comments on draft-ietf-mmusic-delayed-duplication: >=20 > Q1: I assume the attribute indicates the SENDING delay, or? I think it ne= eds to be more explicit. >=20 Yes, the dup delay refers to the delay applied during sending. The delay be= tween the dup packets might be different on the receiving side. Is this wha= t you asked? > Q2: There are no SDP Offer/Answer considerations. Does the Offer have imp= act on the Answer? What is the expected behavior if the Answerer does not s= upport the mechanism? Etc. >=20 This attribute is used with the grouping defined in the other draft. And O/= A stuff applies to that grouping semantics, which the draft explains. Maybe= , I should put a note regarding this in this draft? Cheers, -acbegen > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Ali C. Begen (abegen) > Sent: 4. tammikuuta 2013 0:31 > To: mmusic@ietf.org > Subject: [MMUSIC] The rtp-duplication related drafts >=20 > Hi everyone, >=20 > The following two drafts have been adopted by MMUSIC a while ago and the = main draft discussing the RTP duplication issues is being finalized in AVTE= XT (this was also adopted as a WG item a while ago). It is simply waiting f= or the WG to make a decision on the srcname proposal. >=20 > http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ > http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ >=20 > These two mmusic drafts are essentially completed and they are needed to = be done for the avtext draft. I hope they will be WGLC'ed some time soon. I= n the mean time, I would like to get any comments, feedback that you might = have. >=20 > Thanks. > -acbegen >=20 > PS Here is the AVTEXT draft. > http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Jan 8 08:50:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A121F8684 for ; Tue, 8 Jan 2013 08:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVGifQhm7-Cq for ; Tue, 8 Jan 2013 08:50:35 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id A2A1521F867B for ; Tue, 8 Jan 2013 08:50:33 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id lSTT1k0031ei1Bg54UqZhb; Tue, 08 Jan 2013 16:50:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id lUqY1k00T3ZTu2S3kUqYkd; Tue, 08 Jan 2013 16:50:33 +0000 Message-ID: <50EC4E57.7010407@alum.mit.edu> Date: Tue, 08 Jan 2013 11:50:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357663833; bh=ecw4PeeXgmsEl96VoHp/v2LjP9T+e2O89khN1K96dVs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WY74EFVuW4eEsVNOTYZj6R2/iHg5h5euXx6NL9Kwt7vn+fSppK9lGCbejQ/KYAH9H 5RaeIYSCSTq38vmVBvEMQSyEJW2yEJpSYPqklRYTIABk//MSVkjUdjQ0WH5wcK96ii vmUXkPZT7Bce05Bz6WPEcD3RNqLbZH8o2OEBN0i+JxlBpgr+OYNrq6yQiOTWAkj8SK vdzIzfvmhd0D8z3/QC21re5YPXXRoEGv7wPcTsK1zA/FfcRHC0cRBkEAuROXjeRT5U ERopuQ0BiuWjf/bzlC50zrXDjdRTTeUpE46aLaNqvIHeKCFup3cIlT5xDfoc/lzhwS 9jMnrLdwnnNKw== Cc: "draft-ietf-rmt-flute-sdp@tools.ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 16:50:36 -0000 When the request for review of this came out, I deferred because I knew nothing of flute. After seeing Christer's comments I was motivated to take a look. I see many issues here, over and above those that Christer identified: First, IIUC flute is intended primarily for use with multicast, though its spec says it can also be used with unicast. This bias towards multicast shows in this document. The examples are all multicast, and unicast is mentioned only twice. Also, offer/answer is only mentioned in passing. There is no discussion of how all the constructs defined in this document should work in an O/A usage. I'm pretty sure they won't work. Of course this isn't necessarily a problem if this functionality is not intended for use in O/A. But if that is the case then it needs to be clearly spelled out. If it *is* intended to be used with O/A, and especially with O/A negotiation of unicast, then a lot more work is needed to specify how this will work. As Christer noted, the Composite Session grouping defined here seems to be addressing much the same problem as BUNDLE and MMT. But of course it has a somewhat different spin on things. This grouping introduces an another level of attribute inheritance that is kind of "interesting". It shares the problem of when and how to aggregate attribute values in the group, but only addresses it for a few attributes. IMO we *really* don't want a bunch of grouping mechanisms, each focused on a different application. This spec has a need to identify the source address. It repurposes a=source-address to satisfy this need. This use is quite different from the intended use. Because of limitations on source addresses for flute, it imposes limitations on the use of the a=source-address attribute. (See section 3.3.) I think these limitations may break using source-address for its intended purpose. Thanks, Paul On 1/8/13 7:30 AM, Christer Holmberg wrote: > Hi, > > I am the assigned SDP directorate reviewer for > > draft-ietf-rmt-flute-sdp-03 > > For background on the SDP directorate, please see the FAQ at > > http://www.ietf.org/iesg/directorate/sdp.html > > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. > > SUMMARY: > > ========== > > I have technical concerns with a number of the technical content of this > document, and at least the “Composite Session” concept, as currently > > defined in the document, would need to be discussed in MMUSIC. I think > they need to be resolved/clarified before this document can be published. > > Regards, > > Christer > > -------------------------------------------------------- > > TECHNICAL > > ========= > > General: > > ------------ > > T-GEN-1: The draft seems to define a new generic SDP > mechanism, “Composite Session”, for grouping media streams into > protocol-specific sessions. I am not really sure what that means, but it > seems to go outside the scope of FLUTE. I also think it overlaps with > the SDP BUNDLE work, and such work shall be done in MMUSIC. > > “The Composite Session mechanism enables the grouping > of media lines > > in to distinct sessions. The complete Composite > Session semantics > > are protocol-specific - as determined by the protocol > id of the > > grouped media lines.” > > T-GEN-2: Maybe I’ve missed it, but it is a little unclear > to me why the grouping framework is needed in the first place. If that > is described somewhere, please tell me :) > > In section 3.2.1, the text says: > > “The Composite Session provides an unambiguous way to > define multiple > > FLUTE sessions as distinct from multiple the > media-sessions semantics > > of RTP.” > > But, what is the technical need for this? > > T-GEN-3: The draft uses the same source address for every > m- line associated with a group, but it uses different addresses in each > m- line. Aren’t the media streams symmetric? > > T-GEN-4: There is chapter describing the SDP Offer/Answer > aspects. How is the answer generated? What if the answerer does not > support (or, supports, but don’t want to use) the mechanism? > > If the mechanism is not to be used with SDP Offer/Answer, but e.g. for > some kind of declaration, I think that needs to be described. > > Section 1: > > ------------- > > T-1-1: The text says: > > “Note, this document may also be used to describe > sessions of the > > experimental FLUTE specification [RFC3926].” > > I think you need to indicate whether or not there will be any changes in > the usage of SDP in that case. > > Section 3.2: > > --------------- > > T-3-2: I would like to have some input from the > MMUSIC community whether “FLUTE/UDP/ESP” is appropriate to describe a > IPSec encrypted FLUTE channel, or whether something like “SFLUTE/UDP” > should be used instead. > > Section 3.11: > > ----------------- > > T-3_11-1: As the syntax mandates at least one fmt value, I > suggest that the document specifies which value SHALL be used. > > EDITORIAL > > ========= > > General: > > ----------- > > E-GEN-1: The Abstract and Introduction needs to explicitly > state that the specification defines a new SDP grouping framework value. > The Abstract also needs to mention the new SDP protocol values. > > Section 1: > > ------------- > > E-1-1: s/defines two new protocol identifiers/defines > two new SDP protocol values > > E-1-2: I suggest to remove “The formal ABNF syntax > [RFC5234] is used for the attributes.” It only needs to be stated in the > section defining the new SDP attributes. > > Section 3: > > ------------- > > E-3-1: I think the second last paragraph, comparing > FLUTE with RTP media streams, sessions etc is confusing. I think it is > enough to describe that each SDP m- line represents a FLUTE channel. > > Section 3.1: > > --------------- > > E-3_1-1: I would suggest to have a new parent chapter, > “SDP Extensions”, with sub-chapters defining the new SDP protocol > values, attributes etc. > > Section 3.11: > > ----------------- > > E-3_11-1: I suggest to remove this section. It’s not needed, > and I don’t even agree with the content. > > Section 4: > > ------------- > > E-4-1: Instead of saying “a=FEC-declaration line”, I > suggest to say “SDP FEC-declaration attribute”. (Also applies to the > description of the other attributes). > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fandreas@cisco.com Tue Jan 8 13:44:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CC121F8765 for ; Tue, 8 Jan 2013 13:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.944 X-Spam-Level: X-Spam-Status: No, score=-8.944 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZu6MclCoi0z for ; Tue, 8 Jan 2013 13:44:26 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 40AB821F84F6 for ; Tue, 8 Jan 2013 13:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12022; q=dns/txt; s=iport; t=1357681466; x=1358891066; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0DthDIP55utyJHG3IemRRcRjWNN70/4R0N4bojUJbEQ=; b=j2UL0fF0slJqiLtNo21jnUVdkemMX9iX2P0bv30Ecs0uFCYcQfv9BIzz MeSC39cGY1rhjdToo/1Z5kultXSBUBJsIqHMMILmEWanZ6KOepAjnk1xe DsTTsnSNbMnSPB1HxBGcyyPQ2QzBO005yPl0rYGw6xLwY8k1Gpl+f4ulP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYIAF+S7FCtJXG8/2dsb2JhbABEg0e6FxZzgh4BAQEDAQEBAS8BBTYKARALGAkWCAcJAwIBAgEVHxETAQUCAQEFEod2Bgypb40njGcBhC0DiGGJeIMzkEmDEoFKAR8 X-IronPort-AV: E=Sophos;i="4.84,433,1355097600"; d="scan'208";a="160291866" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jan 2013 21:44:25 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r08LiOjn000763; Tue, 8 Jan 2013 21:44:24 GMT Message-ID: <50EC9338.7040008@cisco.com> Date: Tue, 08 Jan 2013 16:44:24 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <50EB9145.8050301@cisco.com> <94C682931C08B048B7A8645303FDC9F36EA2CC05EE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA2CC05EE@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mmusic , Gonzalo Camarillo , "draft-boucadair-mmusic-altc@tools.ietf.org" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 21:44:27 -0000 On 1/8/13 4:59 AM, mohamed.boucadair@orange.com wrote: > Dear Flemming, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> De la part de Flemming Andreasen >> Envoyé : mardi 8 janvier 2013 04:24 >> À : draft-boucadair-mmusic-altc@tools.ietf.org >> Cc : mmusic; Gonzalo Camarillo >> Objet : [MMUSIC] SDP Directorate: Review of >> draft-boucadair-mmusic-altc-07 >> >> Hi >> >> I am the assigned SDP directorate reviewer for >> draft-boucadair-mmusic-altc-07 >> >> For background on the SDP directorate, please see the FAQ at >> >> http://www.ietf.org/iesg/directorate/sdp.html >> >> Please wait for direction from your document shepherd or AD before >> posting a new version of the draft. >> >> Summary: >> --------- >> - The document does not adequately cover how it relates to the >> existing >> Standards Track mechanism for solving the similar problem in a >> different >> and more general way (namely ICE [RFC 5245]) >> - The document has technical issues >> - The document has a few minor editorial issues >> >> >> New SDP Information Elements: >> --------------------------- >> The draft defines a new "a=altc" attribute >> >> >> Technical Comments: >> ------------------ >> 1) The Abstract positions the document as an alternative to ANAT, but >> without certain problems experienced by ANAT. The abstract fails to >> mention that a general Standards Track solution in the form of >> ICE (RFC >> 5245) has been defined whereas the solution defined in this >> document has >> a narrower scope and various limitations. > Med: I updated the abstract as follows: > > OLD: > > This document proposes a mechanism which allows to carry multiple IP > addresses, of different address families (e.g., IPv4, IPv6), in the > same SDP offer. The proposed attribute solves the backward > compatibility problem which plagued ANAT, due to its syntax. > > NEW: > > This document proposes a mechanism which allows to carry multiple IP > addresses, of different address families (e.g., IPv4, IPv6), in the > same SDP offer. The proposed attribute solves the backward > compatibility problem which plagued ANAT, due to its syntax. > > The proposed solution is applicable to scenarios where connectivity > checks are not required. I'd suggest adding "If connectivity checks are required, ICE (RFC 5245) provides such a solution". >> 2) Section 1.1, third paragraph. The document states that ICE is >> processing intensive and has seen limited deployment. While this is >> perhaps a matter of debate, it would be helpful if the document would >> point out the limitations of using instead of ICE. Areas that come to >> mind here are >> - lack of NAT traversal (without network/SBC support), >> - no connectivity verification (verifying functioning path as well as >> authenticating/correlating initial incoming media packets with >> signaling), >> - support for non-contiguous RTP/RTCP port pairs in alternatives >> There are probably others and it would be helpful to point >> those out to >> potential implementers (the simplicity comes with trade-offs). > Med: The scope of ALTC is very clear: scenarios where there is no need for connectivity checks. This is already mentioned in Section 2 and I tried to make it clear in the new proposed abstract text. I don't think it will be obvious to people looking at the document what the trade-offs with the Standards Track solution (ICE) are, and hence I think it's advisable to call them out explicitly so people can make an informed decision as to which solution they want to use. >> 3) Section 1.1, third paragraph: The document claims that ICE is not >> usable in closed networks. This is incorrect (it is however >> correct that >> there are scenarios where ICE does not work, however those scenarios >> should then be explained instead). > Med: closed networks are provided only as an example. Anyway, I updated the text as follows: > > OLD: > > (e.g., closed networks) > > NEW: > > (e.g., closed networks making use of SBCs) The statement is still not entirely correct (the SBC can for example support ICE or it could be doing signaling processing only). My understanding of where ICE does not work is in a scenario where an intermediay (proxy, SBC, or whatever) inserts a media relay of some sort in the m= line without updating/supporting ICE as part of that. This will lead to ice-mismatch (detected by ICE by design) and hence abandoning the ICE procedures. a) Is this the scenario you were thinking of, and/or are there others ? b) How does altc work and/or work better in that case (compared to ICE) ? c) Whether using ICE or altc in the above scenario, you still have an issue with NAT traversal that may require some form of latching to work (or do you see altc somehow avoiding this ?) The above should be clarified (or the overly broad statement should be removed instead). >> 4) Section 1.1, fourth paragraph: The document claims to be compliant >> with RFC 6157 because RFC 6157 includes the sentence >> >> The use of ICE can be avoided for signaling messages that stay within >> such managed networks >> >> The quote is taken out of context however as it applies to a >> scenario in >> RFC 6157 where the entire network is IPv6 based, whereas the mechanism >> defined here is for scenarios where it is not. > Med: The text from RFC6157 is: > > Implementations are encouraged to use ICE; however, the normative > strength of the text above is left at a SHOULD since in some > managed networks (such as a closed enterprise network) it is > possible for the administrator to have control over the IP version > utilized in all nodes and thus deploy an IPv6-only network, for > example. The use of ICE can be avoided for signaling messages > that stay within such managed networks. > > IPv6-only is mentioned as an example. The key word IMHO in the above text is "managed networks". I think the key in the above is "it is possible for the administrator to have control over the IP version utilized in all nodes" and thus you know it's safe to use only one particular IP version and hence can avoid using ICE to actually pick a version that works. In any case, I don't think this reference to RFC 6157 compliance is critical for this document and hence it may be easier to simply remove it. >> 5) Section 3.2, first paragraph >> >> A compliant SDP parser will ignore any session description >> that contains >> attribute lines it does not support. >> >> No - only the unsupported attribute lines will be ignored >> (which is also >> what the rest of the draft implies) > Med: OK. I updated the text. Ok >> 6) Section 4.1, attribute definition >> The optional trailing integer part is not defined. > Med: Thanks for catching this. I updated section 4.1. Ok. >> 7) Section 4.1, Bullet list, "port" >> This does not seem to work with the "a=rtcp" attribute [RFC 4566], and >> hence there may be issues with non-contiguous RTP/RTCP port >> pair support >> in alternatives. > Med: We updated the text as follows: > > OLD: > > Note that for RTCP, if applicable for the given media types, each > side would act as if the chosen "altc" attribute's port number was in > the 'm=' media line. Typically, this would mean RTCP is sent to the > odd +1 of the port number, unless some other attribute determines > otherwise. > > NEW: > > Note that for RTCP, if applicable for the given media types, each > side would act as if the chosen "altc" attribute's port number was in > the 'm=' media line. Typically, this would mean RTCP is sent to the > odd +1 of the port number, unless some other attribute determines > otherwise. > > For example the RTP/RTCP multiplexing mechanism defined in [RFC5761] > can still be used with ALTC, such that if both sides support > multiplexing they will indicate so using the 'a=rtcp-mux' attribute > as defined in [RFC5761]; but the IP connection address and port they > use may be chosen using the ALTC mechanism. > > If the SDP offerer wishes to use the RTCP attribute defined in > [RFC3605], a complication can arise since it may not be clear which > address choice the 'a=rtcp' attribute applies to, relative the > choices offered by ALTC. Technically RFC 3605 allows indicating the > address for RTCP explicitly in the 'a=rtcp' attribute itself, but > this is optional and rarely used. Since RFC 3605 did not prevent > encoding multiple 'a=rtcp' attributes per media description, this > document recommends encoding the first 'a=rtcp' attribute to be for > the address choice encoded in the "m=" line, and a second 'a=rtcp' > attribute for the alternate address provided by the 'a=altc' > attribute. In other words, if the 'a=rtcp' attribute explicitly > encodes an address in its attribute, then that applies for ALTC as > per [RFC3605]; if it does not, then ALTC assumes the first one is for > the address in the "m=" line, and the second is for the alternate. I don't think this is a good idea (multiple instances with different values, and also ordering specific). While RFC 3605 may not explicitly disallow the above, it's also not part of it's overall defined semantics, and it's unlikely to produce interoperable implementations if used this way IMO. Rather than having multiple instances with some altc-specific interpretation associated with those, you could extend the altc attribute itself to include the information. Alternatively, you could limit the solution to not support non-contiguous RTP/RTCP ports for anything but the default value provided in the m= line (then add a rule that a=rtcp is to be ignored if another address family is used). >> 8) Section 4.1, 4th last paragraph >> The mechanism relies on implicit ordering of attribute lines. If an >> intermediary changes the order, it would have unintended side-effects. >> It would be much better to have an explicit ordering mechanism. In the >> absence of that, the potential reordering issue should be called out. > Med: Is this harmful? If an intermediary entity change the order, this does not impact the session establishment. Note the document already specify how a remote UA can detect the presence of an intermediary entity changing the "c" line is present in the path. It doesn't produce the intended operation. I thought part of the draft motivation was to enable a preferential selection of the address family in a backwards compatible manner, especially for IPv4-only peers. If the attributes get reordered, the preference no longer works. Since the document is Informational, I guess it's up to you whether this is problematic, but if left as-is, I think you should at least point out this potential issue. >> >> Editorial Comments: >> ----------------- >> 1) Section 1.1, second paragraph. Add reference after "DS-Lite" >> >> 2) sdp-cap-neg should be SDPCapNeg (multiple occurrences) >> >> 3) Section 1.3, first paragraph: Add reference to RFC 4091. >> >> 4) Section 1.3, second paragraph: Add text and reference to >> RFC 6157 for >> a solution to "SIP layer address family interworking" >> >> 5) Section 4.2.3 >> Add RFC reference after "ICE" >> >> 6) Section 4.2.4 >> Add RFC reference after "SDPCapNeg" > Med: I implemented all the proposed changed. Thanks. Ok - thanks -- Flemming >> >> Thanks >> >> -- Flemming >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . From internet-drafts@ietf.org Tue Jan 8 23:58:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDA321F877B; Tue, 8 Jan 2013 23:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBx1lk5eKAXR; Tue, 8 Jan 2013 23:58:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7F21F8792; Tue, 8 Jan 2013 23:58:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130109075826.8271.6132.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 23:58:26 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 07:58:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-16.txt Pages : 37 Date : 2013-01-08 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Wed Jan 9 00:06:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA58321F87AD for ; Wed, 9 Jan 2013 00:06:01 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipno3AcF-FW9 for ; Wed, 9 Jan 2013 00:06:01 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D4FF221F87AC for ; Wed, 9 Jan 2013 00:05:59 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0985vsl020903 for ; Wed, 9 Jan 2013 10:05:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jan 2013 10:05:57 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0318.003; Wed, 9 Jan 2013 08:05:57 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-16.txt Thread-Index: AQHN7j891MB6hJFBIUC5hpw30E3VWZhAo6QA Date: Wed, 9 Jan 2013 08:05:56 +0000 Message-ID: References: <20130109075826.8271.6132.idtracker@ietfa.amsl.com> In-Reply-To: <20130109075826.8271.6132.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYooWkPGcjYGrTIJTnZ5eMCFgp3/fDdwhVl4EK4yZpVIkvBb1VPHREzPmCtXUOXX9mdQ7ZGZgR7058aBUE8VLOxfJQBznhxrN+zCfDGFEi5G9808Mit3oGULDZasoJ4PzoSOcStXcr7t0LfhPSvt9vQqf3jHEJbERRzIiRDBg8lUF5BhiY9e6NV++gzV8AJv9Xg== x-originating-ip: [172.21.81.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jan 2013 08:05:57.0549 (UTC) FILETIME=[27BAE5D0:01CDEE40] X-Nokia-AV: Clean Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 08:06:01 -0000 Submitting version -16 which corrects some typos that were supposed to be i= n already in version -15. Regards, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 9. tammikuuta 2013 9:58 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-16.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-16.txt Pages : 37 Date : 2013-01-08 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Wed Jan 9 11:25:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CA821F882D for ; Wed, 9 Jan 2013 11:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owdkw-QGSO9i for ; Wed, 9 Jan 2013 11:25:07 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 36A1721F87CB for ; Wed, 9 Jan 2013 11:25:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAB8E39E2A2 for ; Wed, 9 Jan 2013 20:25:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id novqCfemOneT for ; Wed, 9 Jan 2013 20:25:04 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8559B39E241 for ; Wed, 9 Jan 2013 20:25:04 +0100 (CET) Message-ID: <50EDC40F.3010501@alvestrand.no> Date: Wed, 09 Jan 2013 20:25:03 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 19:25:08 -0000 Hello, I have encountered an issue, and I'm not sure it's an issue or not. SDP wisdom is sought. Suppose two entities exchange the following offer/answer: offer from X: m=video 97 a=rtpmap:97 foo answer from Y: m=video 98 a=rtpmap:98 foo It's clear from RFC 3264 that now X must send codec foo with payload type 98, and Y must send codec foo with payload type 97. That's not the question. But suppose these are the offer and answer: offer from X: m=video 97 98 a=rtpmap:97 foo a=rtpmap:98 bar answer from Y: m=video 97 98 a=rtpmap:97 bar a=rtpmap:98 foo That is, the payload types collide. It would be possible to write code so that X sends foo with 98 and bar with 97, while Y sends foo with 97 and bar with 98. But is it conformant with the specs to do so? And if this has a clear answer - which paragraph of which RFC makes this clear? (Yes, this discussion is triggered from a real world problem.) Harald From eckelcu@cisco.com Wed Jan 9 13:01:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C258F21F88B4 for ; Wed, 9 Jan 2013 13:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.974 X-Spam-Level: X-Spam-Status: No, score=-9.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxoaOrP2Ohdu for ; Wed, 9 Jan 2013 13:01:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AE2C021F8645 for ; Wed, 9 Jan 2013 13:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2416; q=dns/txt; s=iport; t=1357765306; x=1358974906; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EfF/V/jQ1Pm3JhYtD6SQY5G049bnC3ZY6vW9HHxp8gk=; b=YxKJb7rTsqRpu7/OyAf0cWleMrUdIngxaDibGDg+UOb2Rf4DMspc+hZl fRFRbfgL4jBFCUe8/3RkhRdpi6vZdoINhdym9D8isfMbgR3otpdjwwyo8 4gYoavRlWPxlwFW1GFgH9pHLd+243pPecfPWEBAoGJ2KY2H7Pz5NV+Iea c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGXZ7VCtJV2b/2dsb2JhbABEvVwWc4IeAQEBAwEBAQE3NBAHBAIBCBEEAQELFAkHJwsUCQgCBAESCIgLBQEMtjcEkDlhA6ZVgnSCJA X-IronPort-AV: E=Sophos;i="4.84,440,1355097600"; d="scan'208";a="160669686" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jan 2013 21:01:42 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r09L1g8K029494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jan 2013 21:01:42 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:01:42 -0600 From: "Charles Eckel (eckelcu)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: AQHN7p8Pzrd89LSrqUC7n2O8JcktGJhBeXIg Date: Wed, 9 Jan 2013 21:01:41 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804723EE3@xmb-aln-x08.cisco.com> References: <50EDC40F.3010501@alvestrand.no> In-Reply-To: <50EDC40F.3010501@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 21:01:47 -0000 Please see inline. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Wednesday, January 09, 2013 11:25 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Query: payload type collision with offer/answer >=20 > Hello, > I have encountered an issue, and I'm not sure it's an issue or not. SDP > wisdom is sought. >=20 > Suppose two entities exchange the following offer/answer: >=20 > offer from X: >=20 > m=3Dvideo 97 > a=3Drtpmap:97 foo >=20 > answer from Y: >=20 > m=3Dvideo 98 > a=3Drtpmap:98 foo >=20 > It's clear from RFC 3264 that now X must send codec foo with payload > type 98, and Y must send codec foo with payload type 97. That's not the > question. >=20 > But suppose these are the offer and answer: >=20 > offer from X: >=20 > m=3Dvideo 97 98 > a=3Drtpmap:97 foo > a=3Drtpmap:98 bar >=20 > answer from Y: >=20 > m=3Dvideo 97 98 > a=3Drtpmap:97 bar > a=3Drtpmap:98 foo >=20 > That is, the payload types collide. >=20 > It would be possible to write code so that X sends foo with 98 and bar > with 97, while Y sends foo with 97 and bar with 98. But is it conformant > with the specs to do so? >=20 > And if this has a clear answer - which paragraph of which RFC makes this > clear? > (Yes, this discussion is triggered from a real world problem.) It is recommended to avoid such mismatches when possible, but doing so may = not always be possible. The examples you mention are conformant. The follow= ing text from section 5.1 addresses this: For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. Different payload type numbers may be needed in each direction because of interoperability concerns with H.323. That said there are additional requirements placed on payload type usage by= some codecs, such as SVC. Cheers, Charles =20 > Harald >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Wed Jan 9 14:52:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD53621F8DEB for ; Wed, 9 Jan 2013 14:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtGzkboA2xSY for ; Wed, 9 Jan 2013 14:52:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A689621F8D35 for ; Wed, 9 Jan 2013 14:52:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAD6439E2A2 for ; Wed, 9 Jan 2013 23:52:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyQl1jHMq9ut for ; Wed, 9 Jan 2013 23:52:01 +0100 (CET) Received: from [83.145.61.137] (unknown [83.145.61.137]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5866139E241 for ; Wed, 9 Jan 2013 23:52:01 +0100 (CET) Message-ID: <50EDF490.4000101@alvestrand.no> Date: Wed, 09 Jan 2013 23:52:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> In-Reply-To: <1.77712513fa3f074cccef@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 22:52:07 -0000 On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: > Please see inline. > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Harald Alvestrand > > Sent: Wednesday, January 09, 2013 11:25 AM > > To: mmusic@ietf.org > > Subject: [MMUSIC] Query: payload type collision with offer/answer > > > > Hello, > > I have encountered an issue, and I'm not sure it's an issue or not. SDP > > wisdom is sought. > > > > Suppose two entities exchange the following offer/answer: > > > > offer from X: > > > > m=video 97 > > a=rtpmap:97 foo > > > > answer from Y: > > > > m=video 98 > > a=rtpmap:98 foo > > > > It's clear from RFC 3264 that now X must send codec foo with payload > > type 98, and Y must send codec foo with payload type 97. That's not the > > question. > > > > But suppose these are the offer and answer: > > > > offer from X: > > > > m=video 97 98 > > a=rtpmap:97 foo > > a=rtpmap:98 bar > > > > answer from Y: > > > > m=video 97 98 > > a=rtpmap:97 bar > > a=rtpmap:98 foo > > > > That is, the payload types collide. > > > > It would be possible to write code so that X sends foo with 98 and bar > > with 97, while Y sends foo with 97 and bar with 98. But is it > conformant > > with the specs to do so? > > > > And if this has a clear answer - which paragraph of which RFC makes > this > > clear? > > (Yes, this discussion is triggered from a real world problem.) > > It is recommended to avoid such mismatches when possible, but doing so > may not always be possible. The examples you mention are conformant. > The following text from section 5.1 addresses this: > > For sendrecv RTP > streams, the payload type numbers indicate the value of the payload > type field the offerer expects to receive, and would prefer to send. > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > Different payload type numbers may be needed in each direction > because of interoperability concerns with H.323. I was reading that text, and it clearly says which ones to use if the payload types are different, but I don't think they clearly address the situation with using the same payload type for two different codecs in different directions. In a multicast or transport relay scenario, this would clearly be untenable, since third parties would not be able to send streams that would be interpreted correctly by the two conflicting endpoints, but in a two-party conversation, it's possible to make this work. I just don't know if it's worth the effort to make it so. From emil@sip-communicator.org Wed Jan 9 15:46:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09A21F8476 for ; Wed, 9 Jan 2013 15:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1UsCsYhQa7g for ; Wed, 9 Jan 2013 15:46:07 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4708921F8475 for ; Wed, 9 Jan 2013 15:46:06 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so1338171wgb.12 for ; Wed, 09 Jan 2013 15:46:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=RBQGh3DCQyFLXqUEKxsN5Uz5HnrDf66olhTjS1GZJ1U=; b=A6WK7rKNCmjthAB8mD69ZuMh/IQBuW3Io03ddxV6tmobXWsDIgL0rUCd9pWc9B1wsU MmEWq2hJWVoqG5CjTwJttcFMO8VqtDbTxTCxjubOQnjVC+DqvzxAK7bDxvaiuVfaKtEa 5jtQ5BiwZ0NZj2cIoLEllTQm0cTBW6m2pfZx7D40Ht0JGzCsVk0euUfQHot3Yq/N18fk F7mAaxHQ42EDkdQ/aGJKLo6wPoZvpDIVs6mYIfdksgO2DNcmAPkg6iC8RHrHmXcJf0aU 3E8W8KoZRuFb53O5h9ooxzXcgT9szg1lWqFCJEAR7Kn7gr9rK4g9Kn0fztVviCr4mOua YY6Q== X-Received: by 10.194.235.100 with SMTP id ul4mr111681769wjc.7.1357775165857; Wed, 09 Jan 2013 15:46:05 -0800 (PST) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id l5sm6637754wia.10.2013.01.09.15.46.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Jan 2013 15:46:04 -0800 (PST) Message-ID: <50EE0139.8000909@jitsi.org> Date: Thu, 10 Jan 2013 00:46:01 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> In-Reply-To: <50EDF490.4000101@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm3MskF8xFW2AVBRWiXw/GvFyn//rGhPZ2HajY5OG+pdahY4yrkE0vA1n6xdoAvcwO7Bw9j Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:46:08 -0000 On 09.01.13, 23:52, Harald Alvestrand wrote: > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: >> Please see inline. >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Harald Alvestrand >>> Sent: Wednesday, January 09, 2013 11:25 AM >>> To: mmusic@ietf.org >>> Subject: [MMUSIC] Query: payload type collision with offer/answer >>> >>> Hello, >>> I have encountered an issue, and I'm not sure it's an issue or not. SDP >>> wisdom is sought. >>> >>> Suppose two entities exchange the following offer/answer: >>> >>> offer from X: >>> >>> m=video 97 >>> a=rtpmap:97 foo >>> >>> answer from Y: >>> >>> m=video 98 >>> a=rtpmap:98 foo >>> >>> It's clear from RFC 3264 that now X must send codec foo with payload >>> type 98, and Y must send codec foo with payload type 97. That's not the >>> question. >>> >>> But suppose these are the offer and answer: >>> >>> offer from X: >>> >>> m=video 97 98 >>> a=rtpmap:97 foo >>> a=rtpmap:98 bar >>> >>> answer from Y: >>> >>> m=video 97 98 >>> a=rtpmap:97 bar >>> a=rtpmap:98 foo >>> >>> That is, the payload types collide. >>> >>> It would be possible to write code so that X sends foo with 98 and bar >>> with 97, while Y sends foo with 97 and bar with 98. But is it >> conformant >>> with the specs to do so? >>> >>> And if this has a clear answer - which paragraph of which RFC makes >> this >>> clear? >>> (Yes, this discussion is triggered from a real world problem.) >> >> It is recommended to avoid such mismatches when possible, but doing so >> may not always be possible. The examples you mention are conformant. >> The following text from section 5.1 addresses this: >> >> For sendrecv RTP >> streams, the payload type numbers indicate the value of the payload >> type field the offerer expects to receive, and would prefer to send. >> However, for sendonly and sendrecv streams, the answer might indicate >> different payload type numbers for the same codecs, in which case, >> the offerer MUST send with the payload type numbers from the answer. >> >> Different payload type numbers may be needed in each direction >> because of interoperability concerns with H.323. > I was reading that text, and it clearly says which ones to use if the > payload types are different, but I don't think they clearly address the > situation with using the same payload type for two different codecs in > different directions. > > In a multicast or transport relay scenario, this would clearly be > untenable, since third parties would not be able to send streams that > would be interpreted correctly by the two conflicting endpoints, but in > a two-party conversation, it's possible to make this work. > I just don't know if it's worth the effort to make it so. Well there's also section 8.3.2 in 3264. The section is about updating offers but it seems like the text explicitly prohibits remapping payload types in any scenarios: However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711. Cheers, Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Thu Jan 10 10:50:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6521F8A5E for ; Thu, 10 Jan 2013 10:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSjqLkkr5fxx for ; Thu, 10 Jan 2013 10:50:34 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id DB96421F8A53 for ; Thu, 10 Jan 2013 10:50:32 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id mJ6p1k0071vXlb85FJqXL4; Thu, 10 Jan 2013 18:50:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id mJqX1k00Z3ZTu2S3dJqXhk; Thu, 10 Jan 2013 18:50:31 +0000 Message-ID: <50EF0D77.9040000@alum.mit.edu> Date: Thu, 10 Jan 2013 13:50:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> In-Reply-To: <50EE0139.8000909@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357843831; bh=AUaiohMD+VlBmWWccOENS+nq3RyEXec2YHx4uEJYeJM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VBaz7zhsasd4wEIjvekiPbtxjfv7THY77vsuMlfS/whZPvUstBgETksrb8RHvse6+ CEd3ysHP0ShJo/H7K3ROB7g9Uw+q5fFbn/7FqsJfhZPyUmoCvfbViaTQmiFqGAZdgs kNiULFtAyYZZuH0PV5xtRikdZ9j8ATzlBy6UbVd3GAXaTBFjftTZSYwitD+mpSu3mr rh9wYORUxCQypciubFWdxEFJ+M2MMpwVVUmCjAVPuSOySthe2/GFPL51dJQfEuoh/z onUKDqFyMscX6JKBSKpjROOKhoKwz19PbR66PDfOYH+fBPmaNIYDG8+jmNbBbe3+2h wLlH1EfVvzIGQ== Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 18:50:35 -0000 To the best of my memory the issue Harald has raised is a new one. I don't think it has never been discussed on any of the lists I have been following since 2002. More inline. On 1/9/13 6:46 PM, Emil Ivov wrote: > > > On 09.01.13, 23:52, Harald Alvestrand wrote: >> On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: >>> Please see inline. >>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Harald Alvestrand >>>> Sent: Wednesday, January 09, 2013 11:25 AM >>>> To: mmusic@ietf.org >>>> Subject: [MMUSIC] Query: payload type collision with offer/answer >>>> >>>> Hello, >>>> I have encountered an issue, and I'm not sure it's an issue or not. SDP >>>> wisdom is sought. >>>> >>>> Suppose two entities exchange the following offer/answer: >>>> >>>> offer from X: >>>> >>>> m=video 97 >>>> a=rtpmap:97 foo >>>> >>>> answer from Y: >>>> >>>> m=video 98 >>>> a=rtpmap:98 foo >>>> >>>> It's clear from RFC 3264 that now X must send codec foo with payload >>>> type 98, and Y must send codec foo with payload type 97. That's not the >>>> question. >>>> >>>> But suppose these are the offer and answer: >>>> >>>> offer from X: >>>> >>>> m=video 97 98 >>>> a=rtpmap:97 foo >>>> a=rtpmap:98 bar >>>> >>>> answer from Y: >>>> >>>> m=video 97 98 >>>> a=rtpmap:97 bar >>>> a=rtpmap:98 foo >>>> >>>> That is, the payload types collide. >>>> >>>> It would be possible to write code so that X sends foo with 98 and bar >>>> with 97, while Y sends foo with 97 and bar with 98. But is it >>> conformant >>>> with the specs to do so? >>>> >>>> And if this has a clear answer - which paragraph of which RFC makes >>> this >>>> clear? >>>> (Yes, this discussion is triggered from a real world problem.) >>> >>> It is recommended to avoid such mismatches when possible, but doing so >>> may not always be possible. The examples you mention are conformant. >>> The following text from section 5.1 addresses this: >>> >>> For sendrecv RTP >>> streams, the payload type numbers indicate the value of the payload >>> type field the offerer expects to receive, and would prefer to send. >>> However, for sendonly and sendrecv streams, the answer might indicate >>> different payload type numbers for the same codecs, in which case, >>> the offerer MUST send with the payload type numbers from the answer. >>> >>> Different payload type numbers may be needed in each direction >>> because of interoperability concerns with H.323. >> I was reading that text, and it clearly says which ones to use if the >> payload types are different, but I don't think they clearly address the >> situation with using the same payload type for two different codecs in >> different directions. >> >> In a multicast or transport relay scenario, this would clearly be >> untenable, since third parties would not be able to send streams that >> would be interpreted correctly by the two conflicting endpoints, but in >> a two-party conversation, it's possible to make this work. >> I just don't know if it's worth the effort to make it so. You are right that these arguments work differently for unicast and multicast. I don't recall (I think it was before my time) how much thought was given to multicast in 3264. (It doesn't seem to be very much. And I think the O/A discussions in new additions to SDP rarely consider it at all.) > Well there's also section 8.3.2 in 3264. The section is about updating > offers but it seems like the text explicitly prohibits remapping payload > types in any scenarios: > > However, in the > case of RTP, the mapping from a particular dynamic payload type > number to a particular codec within that media stream MUST NOT change > for the duration of a session. For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers for that media stream within the session. However, it is > acceptable for multiple payload type numbers to be mapped to the same > codec, so that an updated offer could also use payload type number 72 > for G.711. The language above is underspecified. It is my impression that the intent of this language was to ensure there is no ambiguity in the meaning of a payload type. Since the exchange of the SDP is not synchronized with the flow of RTP, if you were to send a new SDP that changed the mapping for a payload type, then the result would be almost certainly to interpret some media packets according to the wrong mapping. But this argument is only about packets flowing in one direction. It isn't a valid argument for requiring the payload types to be consistent in the two directions. And its not clear to me that it even intended that this language apply to both directions. It could be clarified as follows: ... For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers ***by A*** for that media stream within the session. ... Interpreting it to apply to both directions brings it in conflict with the language elsewhere that permits it to be different in the two directions. The use of different mappings in each direction has been discussed over the years, though I couldn't point you to where. IIRC one of the reasons had to do with gatewaying to other protocols. But I can't offer any details. Bottom line: IMO, in the weird case Harald described X ought to follow Postel's Law and accept the answer from Y. But for the same reason I would strongly discourage implementations from acting as Y did. Thanks, Paul From dwing@cisco.com Thu Jan 10 14:06:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D141E21F8830 for ; Thu, 10 Jan 2013 14:06:42 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtPl3p8evApp for ; Thu, 10 Jan 2013 14:06:14 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AB14D21F8615 for ; Thu, 10 Jan 2013 14:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10240; q=dns/txt; s=iport; t=1357855574; x=1359065174; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=S07vIw54wkC9YPuQ8A4k0dz7YwXRbaIes+AdYHsUdNw=; b=frrZEUOe4oAJtlYHye2z385OvlYMDupU79XAZSCQxNcgLelTDUB+mqlf BtOCY5yUzSIf/8jZ2/Wf0XUq6JiyZWQx8oXPrUn6P4rqWkqsKhQA0kNOp h5Zpg6ttR1U/t8hmIFHj7mrLJFAcfhM8cLWK3xz6xx952c4Sp2sQ43P82 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0HAB8671CrRDoI/2dsb2JhbABEDoM5uisWc4IeAQEBAwEBAQEFAh0TLQQDCwUHAQMCCQ4DBAEBAScHGQ4fCQgCBBMLBYgDBQ20RwSMXBWELgOIYIUciA6QSYI3X4FFAh4G X-IronPort-AV: E=Sophos;i="4.84,446,1355097600"; d="scan'208";a="65895187" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 10 Jan 2013 22:06:13 +0000 Received: from DWINGWS01 ([10.156.17.137]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0AM6Dgf009458; Thu, 10 Jan 2013 22:06:13 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> <50E5DAA2.9050600@alum.mit.edu> In-Reply-To: <50E5DAA2.9050600@alum.mit.edu> Date: Thu, 10 Jan 2013 14:06:13 -0800 Message-ID: <01da01cdef7e$b424c9c0$1c6e5d40$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAJlqPoIAbYfQUUCTNZkeJgFC0MA Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 22:06:42 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, January 03, 2013 11:23 AM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? > > I'm totally lost! > I looked back, and count 43 messages in this thread. > At this point I no longer understand the question(s), or what if > anything has been answered. > > Can we start over? > Sort out what the questions are, and then discuss whether we have > answers to them? > (Preferably in separate, well identified, threads.) > > I *think* Harald originally asserted that DTLS/SCTP *can* already be > multiplexed with SRTP audio and video streams. Yes, it can. An UDP packet is either a STUN packet (for ICE connectivity checks), DTLS, or SRTP. This is depicted in Section 5.1.2 of RFC5764: +----------------+ | 127 < B < 192 -+--> forward to RTP | | packet --> | 19 < B < 64 -+--> forward to DTLS | | | B < 2 -+--> forward to STUN +----------------+ A DTLS packet containing application_data is handed to the SCTP stack. As I have mentioned previously, I am concerned with sending both realtime interactive audio/video and non-realtime data over the same UDP 5-tuple, because it becomes difficult (or impossible) to apply QoS to differentiate those very different flows. If everyone always had adequate bandwidth, that concern would vanish. But the industry has never been able to stay ahead of the bandwidth curve. > And so he was asking > *how* this could be specified in SDP. (E.g. Does "bundle" support it?) We need a way for SDP to signal: 1. the UDP port for SCTP. This feels like an SDP media ("m") line to me. 2. SCTP native (native SCTP over IPv6 should be tenable, whereas native SCTP over IPv4 is pretty much untenable), 3. the data carried over each SCTP port (e.g., port NNN for XMPP, port NNNN for file sharing, port NNNNN for screen sharing, and so on). This feels like an SDP media ("m") line to me. I don't think we can use media lines for both (1) and (3), so perhaps bundling is the answer. I don't know. > Along the way, a question came up of how many DTLS/SCTP connections > could be multiplexed with each other and with SRTP media. I think Harald > assumed only one (and assumed there is only a need for one.) But reasons > for more have been discussed. I suggested that it appears that multiple > should be supportable, each with a different SCTP port. > > I think Dan raised some additional issues related to multipath support. SCTP can support multipath, so we need to decide if we allow SCTP to do its own multipath, or if we require ICE to first validate a (new) path before SCTP can try to do its multipath. The same question and issues exist for multipath RTP (draft-singh-avtcore-mprtp) and how multipath RTP should split its functions between ICE, ICE extensions, and SDP. I know that multipath RTP is not a working group document, but it might be a good basis for analyzing multipath SCTP and reaching a conclusion on multipath SCTP that makes sense for both multipath SCTP and multipath RTP (and presumably multipath TCP, RFC6182 and its related documents). -d > Thanks, > Paul > > On 1/2/13 10:32 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Tuesday, December 11, 2012 11:17 AM > >> To: Dan Wing > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >> > >> Hi Dan, > >> > >> Comments inline > >> > >> On 12/11/12 1:53 PM, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Tuesday, December 11, 2012 7:43 AM > >>>> To: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >>>> > >>>> More inline. > >>>> > >>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: > >>>>> Hi Paul, > >>>>> > >>>>> see in line! > >>>>> > >>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >>>>>> Commenting on a different point > >>>>>> > >>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >>>>>> > >>>>>>> The interesting difference is that the multiplexing between > >>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP > >>>>>>> traffic is not carried in SSRCs, which means: > >>>>>>> > >>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may > >>>>>>> have multiple associations, as you state below); you can't have > >>>>>>> multiple lines with proto DTLS/SCTP in a bundle. > >>>>>> > >>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run > >>>>>> directly over IP. It has its own notion of port used to demux > >>>>>> multiple SCTP associations over the same IP address. > >>>>>> > >>>>>> I presume that that same mechanism is still there when SCTP is > >>>>>> run over DTLS over UDP. > >>>>>> > >>>>>> So, the traffic coming over DTLS must first be demuxed into RTP > >>>>>> traffic and SCTP traffic. > >>>>> based on the current stack the SCTP traffic is the only traffic > >>>>> that runs directly over the DTLS stack. > >>>> > >>>> Yes, that is what I thought. But Harald has been asking about > >>>> multiplexing this with RTP traffic. (Actually I think it would be > >>>> DTLS/SRTP traffic that it would be multiplexed with.) > >>>> > >>>>> What I am trying to do is to include the Randell Jesup (I am > >>>>> including him in CC as I am not sure he is subscribed to this > >>>>> mailing list) suggestion to give the possibility to have multiple > >>>>> SCTP > >>>>> *associations* running on top of the same DTLS session and of > >>>>> course providing a way to signal it in SDP. > >>>> > >>>> IIUC, SCTP (having been designed as a transport layer protocol) > >>>> defines its own notion of port, and has fields in its protocol to > >>>> carry the local and remote port number. Presumably those fields are > >>>> still there when run over UDP or DTLS. So it should be possible to > >>>> support multiple SCTP associations over the same DTLS connection, > >>>> each distinguished by its own port pair. > >>> > >>> Yes, SCTP has its own notion of ports. How this works when SCTP is > >>> carried over UDP is not quite clear, especially because SCTP assumes > >>> a NAPT will not rewrite the SCTP port number (SCTP endeavors to make > >>> such port rewriting difficult). But of course a NAPT (and the MAP > >>> techniques) rewrite UDP port numbers. I believe SCTP would only be > >>> able to successfully convey its UDP port numbers for a device that > >>> is not behind a NAT (that is, a server sitting directly on the > >>> Internet, rather than a remote peer that is behind a NAT). Creative > >>> use of PCP, NAT-PMP, or UPnP IGD would improve that situation in the > future. > >> > >> I find what you say above confusing. > >> > >> SCTP running naked over IP would still have its own ports. > >> If that ran over a path with a NAPT, then I could see why the NAPT > >> might want to do the same as it does with UDP and TCP, and so replace > >> addr/port pairs to minimize addr usage. (That's if the NAPT supported > >> SCTP at all - I gather most don't.) > > > > As I mentioned earlier, SCTP does not allow its source port number to > > be changed. > > > >> But with SCTP over DTLS over UDP, there is a UDP port, and then > >> presumably a separate SCTP port carried in the SCTP protocol within > >> the UDP message. > > > > Yep, I assume that is how it works. Effectively, UDP is just used to > > tunnel the SCTP. > > > >> An NAPT on the path would presumably be messing with the UDP port. > >> Given use of DTLS, the NAPT won't even be able to tell that SCTP is > >> being used, much less mess with the SCTP port. > >> > >>>> That of course depends on having a signaling mechanism to set it > up. > >>> > >>> After the initial SCTP association is created, SCTP could be allowed > >>> to do its own thing (that is, chose to find and use other ports). > >> > >> Here you are talking about finding and using other UDP addr/port > pairs? > > > > No, I was referring to the SCTP ports. > > > > -d > > > > > >> That is explicitly excluded in the DTLS/SCTP mapping. > >> > >> Thanks, > >> Paul > >> > >>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP), > >>> but of course they are not identical. > >>> > >>>>> to be clear: at moment WebRTC allows only one SCTP association per > >>>>> PC, so this is something that would be nice to define just to be > >>>>> ready for the future. > >>>> > >>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP > >>>> mechanism shouldn't be limited by the constraints of WebRTC. It > >>>> would be very difficult to define the SDP so that it was impossible > >>>> to set up multiple SCTP associations over different 5-tuples. > >>>> > >>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP > >>>>>> traffic can be demuxed based on SCTP port. And once the traffic > >>>>>> for a single SCTP port is identified, it can be demuxed based on > >>>>>> stream > >> number. > >>>>>> > >>>>>> Representing this in SDP is a challenge. Some variant of the > >>>>>> bundle proposal might allow bundling together several RTP m-lines > >>>>>> and some DTLS/SCTP m-lines. This would require a mechanism for > >>>>>> specifying the SCTP port number - already an open issue (#3) in > >>>>>> draft-ietf-mmusic-sctp-sdp-02. > >>>>> I agree that it is a challange how then to bundle everything > >>>>> together > >>>> > >>>> But it is a challenge that needs to be tackled if we are to realize > >>>> Harald's dream. > >>> > >>> -d > >>> > >>> > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > > > > From internet-drafts@ietf.org Thu Jan 10 14:45:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E3C21F87A9; Thu, 10 Jan 2013 14:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jakCQoZHuXum; Thu, 10 Jan 2013 14:45:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8D21F8566; Thu, 10 Jan 2013 14:45:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 14:45:03 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 22:45:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Analysis of Middlebox Interactions for Signaling Protoco= l Communication along the Media Path Author(s) : Brian Stucker Hannes Tschofenig Gonzalo Salgueiro Filename : draft-ietf-mmusic-media-path-middleboxes-06.txt Pages : 22 Date : 2013-01-10 Abstract: Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middleboxes= -06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gsalguei@cisco.com Thu Jan 10 14:46:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D055221F86F7 for ; Thu, 10 Jan 2013 14:46:33 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9lrGnYOdDsS for ; Thu, 10 Jan 2013 14:46:33 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id DE5A521F845E for ; Thu, 10 Jan 2013 14:46:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.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 r0AMkWF8011153 for ; Thu, 10 Jan 2013 17:46:32 -0500 (EST) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0AMkVnu022340; Thu, 10 Jan 2013 17:46:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 17:46:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> To: mmusic X-Mailer: Apple Mail (2.1283) Cc: obsidian97@gmail.com Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 22:46:33 -0000 MMUSIC -=20 I have simply updated the version of this draft to prevent expiration = because recent discussions with the chairs have confirmed that we are = ready now to progress this milestone. As part of that effort the chairs = requested we clearly define the purpose, scope, and intended audience = for the document.=20 I came a bit late to the party but from my perspective this draft's = purpose is to provide guidance and best practices on mitigating the = issues middleboxes (particularly NATs and firewalls) can cause to = end-to-end SIP/SDP-signaled media streams in different architectures. = The target audience is anyone (i.e. NAT/FW vendors, protocol designers, = etc.) wanting such information ond that might benefit from the design = tips to make their network/protocol/device more middlebox friendly. I believe Flemming's recent comments (as an individual) masterfully = summarized the scope, purpose and target audience for this document. = Thus, I don't want to repeat (less eloquently) what I consider to be the = right approach to this document. For your convenience, here are those = comments: =3D=3D=3D=3D=3D A lot of the SIP and SDP work started out with a somewhat "purist" = Internet view of the world, where things such as middleboxes were not = considered. As other standards and industry organizations became = interested in using SIP and SDP, different architectures were defined = and some of those arcitectures did include the notion of middleboxes = (e.g. 3GPP IMS and CableLabs PacketCable). =46rom an IETF point of view, = there was, at least initially, not a great deal of knowledge about these = architectures and what the middleboxes defined by them were doing. = Conversely, there was (is) also a concern that such middleboxes may = break end-to-end transparency and hence there was a desire to try and = alleviate that.=20 To that effect, it was seen as useful to have a document that could a) Explain what/how middleboxes might be operating in these = architectures b) Provide guidelines as to how such middleboxes could minimize (ideally = avoid) impacting end-to-end transparency and/or how protocols could be = used to try and alleviate any impact such middleboxes might have.=20 The middleboxes draft is trying to address the above as it relates to = the media path. The target audience is thus IETF participants that would = like an overview of how these middleboxes may affect SIP/SDP-signaled = media streams as well as what can be done to try and overcome that. = Similarly, the document is targeted at people involved in these "other" = architecture efforts, with a goal of making it clear how middleboxes may = affect the operation of SIP/SDP-signaled media streams and hence provide = some "design principles". This is not unlike some of the NAT work that = was done in BEHAVE.=20 It could be argued that these architectures have now been around for so = long that producing the above document will not make any difference at = this point. While I have some sympathy for this, I also think we have to = recognize the importance of documenting what we know and to make that = readily available for new people that will be working in this space.=20 In other words, I still believe there is value in pursuing this = document. As to whether it should be a BCP or Informational, I don't = have any strong opinions.=20 =3D=3D=3D=3D=3D As a group can we agree on this scope and that is worthwhile to finally = complete this milestone? Feedback welcome. Cheers, Gonzalo On Jan 10, 2013, at 5:45 PM, Internet-Drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Analysis of Middlebox Interactions for = Signaling Protocol Communication along the Media Path > Author(s) : Brian Stucker > Hannes Tschofenig > Gonzalo Salgueiro > Filename : = draft-ietf-mmusic-media-path-middleboxes-06.txt > Pages : 22 > Date : 2013-01-10 >=20 > Abstract: > Middleboxes are defined as any intermediary box performing functions > apart from normal, standard functions of an IP router on the data > path between a source host and destination host. Two such functions > are network address translation and firewalling. >=20 > When Application Layer Gateways, such as SIP entities, interact with > NATs and firewalls, as described in the MIDCOM architecture, then > problems may occur in the transport of media traffic when signaling > protocol interaction takes place along the media path, as it is the > case for recent key exchange proposals (such as DTLS-SRTP). This > document highlights problems that may arise. Unfortunately, it is > difficult for the end points to detect or predict problematic > behavior and to determine whether the media path is reliably > available for packet exchange. >=20 > This document aims to summarize the various sources and effects of > NAT and firewall control, the reasons that they exist, and possible > means of improving their behavior to allow protocols that rely upon > signaling along the media path to operate effectively. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middleboxe= s-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From dwing@cisco.com Thu Jan 10 15:02:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03E21F84F8 for ; Thu, 10 Jan 2013 15:02:52 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vRborsfoH8w for ; Thu, 10 Jan 2013 15:02:51 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9419621F845E for ; Thu, 10 Jan 2013 15:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6981; q=dns/txt; s=iport; t=1357858970; x=1359068570; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=FoyfaM2GdBmO5hPUzutEsWXYq8E73d0jXvTCAWW0DcY=; b=Ek/I2ebYA/XExeASpIjG4FtH3rREFA1sPUX3o5gTkjeRizWiHtosN/Qi MCYh55Zttk/X78bGN/pO/Wy+qmn0mbWoUq5qb8jqqY5OS/2Z9Dqogz1lv vfGJWI/iG0WInWhkX+G4Ek0UJQnJmWe9Vt+v8RXrtYdVV0dP28ZJrIySw E=; X-IronPort-AV: E=Sophos;i="4.84,447,1355097600"; d="scan'208";a="23033000" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 10 Jan 2013 23:02:40 +0000 Received: from DWINGWS01 ([10.156.17.137]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0AN2cSi032027; Thu, 10 Jan 2013 23:02:39 GMT From: "Dan Wing" To: "'Gonzalo Salgueiro'" , "'mmusic'" References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> In-Reply-To: <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> Date: Thu, 10 Jan 2013 15:02:37 -0800 Message-ID: <021201cdef86$96f50ab0$c4df2010$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJL7yJZmwafjbIh7QDO1X8p3fpnmgIjJZUylzYTgUA= Content-Language: en-us Cc: obsidian97@gmail.com Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:02:52 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Gonzalo Salgueiro > Sent: Thursday, January 10, 2013 2:47 PM > To: mmusic > Cc: obsidian97@gmail.com > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path- > middleboxes-06.txt > > MMUSIC - > > I have simply updated the version of this draft to prevent expiration > because recent discussions with the chairs have confirmed that we are > ready now to progress this milestone. As part of that effort the chairs > requested we clearly define the purpose, scope, and intended audience > for the document. > > I came a bit late to the party but from my perspective this draft's > purpose is to provide guidance and best practices on mitigating the > issues middleboxes (particularly NATs and firewalls) can cause to end- > to-end SIP/SDP-signaled media streams in different architectures. The > target audience is anyone (i.e. NAT/FW vendors, protocol designers, > etc.) wanting such information ond that might benefit from the design > tips to make their network/protocol/device more middlebox friendly. > > I believe Flemming's recent comments (as an individual) masterfully > summarized the scope, purpose and target audience for this document. > Thus, I don't want to repeat (less eloquently) what I consider to be the > right approach to this document. For your convenience, here are those > comments: > > ===== > > A lot of the SIP and SDP work started out with a somewhat "purist" > Internet view of the world, where things such as middleboxes were not > considered. As other standards and industry organizations became > interested in using SIP and SDP, different architectures were defined > and some of those arcitectures did include the notion of middleboxes > (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, > there was, at least initially, not a great deal of knowledge about these > architectures and what the middleboxes defined by them were doing. > Conversely, there was (is) also a concern that such middleboxes may > break end-to-end transparency and hence there was a desire to try and > alleviate that. > > To that effect, it was seen as useful to have a document that could > a) Explain what/how middleboxes might be operating in these > architectures > b) Provide guidelines as to how such middleboxes could minimize (ideally > avoid) impacting end-to-end transparency and/or how protocols could be > used to try and alleviate any impact such middleboxes might have. > > The middleboxes draft is trying to address the above as it relates to > the media path. The target audience is thus IETF participants that would > like an overview of how these middleboxes may affect SIP/SDP-signaled > media streams as well as what can be done to try and overcome that. > Similarly, the document is targeted at people involved in these "other" > architecture efforts, with a goal of making it clear how middleboxes may > affect the operation of SIP/SDP-signaled media streams and hence provide > some "design principles". This is not unlike some of the NAT work that > was done in BEHAVE. > > It could be argued that these architectures have now been around for so > long that producing the above document will not make any difference at > this point. While I have some sympathy for this, I also think we have to > recognize the importance of documenting what we know and to make that > readily available for new people that will be working in this space. > > In other words, I still believe there is value in pursuing this > document. As to whether it should be a BCP or Informational, I don't > have any strong opinions. > > ===== > > As a group can we agree on this scope and that is worthwhile to finally > complete this milestone? Feedback welcome. I am glad this document was resurrected. Can the document say SBC instead of the awkward (and inaccurate) "SIP ALG combined with MIDCOM agent"? Or is saying SBC impolitic. -d > Cheers, > > Gonzalo > > > On Jan 10, 2013, at 5:45 PM, Internet-Drafts@ietf.org wrote: > > > > > 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 : Analysis of Middlebox Interactions for Signaling > Protocol Communication along the Media Path > > Author(s) : Brian Stucker > > Hannes Tschofenig > > Gonzalo Salgueiro > > Filename : draft-ietf-mmusic-media-path-middleboxes-06.txt > > Pages : 22 > > Date : 2013-01-10 > > > > Abstract: > > Middleboxes are defined as any intermediary box performing functions > > apart from normal, standard functions of an IP router on the data > > path between a source host and destination host. Two such functions > > are network address translation and firewalling. > > > > When Application Layer Gateways, such as SIP entities, interact with > > NATs and firewalls, as described in the MIDCOM architecture, then > > problems may occur in the transport of media traffic when signaling > > protocol interaction takes place along the media path, as it is the > > case for recent key exchange proposals (such as DTLS-SRTP). This > > document highlights problems that may arise. Unfortunately, it is > > difficult for the end points to detect or predict problematic > > behavior and to determine whether the media path is reliably > > available for packet exchange. > > > > This document aims to summarize the various sources and effects of > > NAT and firewall control, the reasons that they exist, and possible > > means of improving their behavior to allow protocols that rely upon > > signaling along the media path to operate effectively. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middlebo > > xes > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-media-path-middlebo > > xes-06 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Thu Jan 10 15:23:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7B621F86D6 for ; Thu, 10 Jan 2013 15:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.253 X-Spam-Level: X-Spam-Status: No, score=-9.253 tagged_above=-999 required=5 tests=[AWL=0.746, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ZJS-6ZYPwX for ; Thu, 10 Jan 2013 15:23:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD7F821F85FC for ; Thu, 10 Jan 2013 15:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4716; q=dns/txt; s=iport; t=1357860180; x=1359069780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gZ5i6JuOM+Xqbkkv75yoZ1LTz/Vm5NaXYcZkWd2Uqsw=; b=fabQPrVZ46Qj89IsGXQ578+/gn6pfwFgQz/exuZYEkWoEfExkrSKlnv+ U5OFU+iy0mg4cd6jNyiwtbP8tHk4KZyZ7f8g0naSvlzHIIx0oL3IdNCji HZKUWSREFEPBurJOiv7rqQoYAl7gplTL+uPJ7tamQ0ja6YZNI5lxJyybD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM1M71CtJV2c/2dsb2JhbABEvXUWc4IeAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQEKFAkHJwsUCQgCBAENBQiICwUBDLRcBJA+YQOmU4J1gWYHNw X-IronPort-AV: E=Sophos;i="4.84,447,1355097600"; d="scan'208";a="160952283" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 10 Jan 2013 23:22:59 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0ANMxqW007253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jan 2013 23:22:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 17:22:59 -0600 From: "Charles Eckel (eckelcu)" To: Emil Ivov , Harald Alvestrand Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: AQHN7p8Pzrd89LSrqUC7n2O8JcktGJhBmrDJgABznICAASXGUA== Date: Thu, 10 Jan 2013 23:22:58 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280472896C@xmb-aln-x08.cisco.com> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> In-Reply-To: <50EE0139.8000909@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:23:04 -0000 Please see inline. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Wednesday, January 09, 2013 3:46 PM > To: Harald Alvestrand > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer >=20 >=20 >=20 > On 09.01.13, 23:52, Harald Alvestrand wrote: > > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: > >> Please see inline. > >> > >>> -----Original Message----- > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>> Behalf Of Harald Alvestrand > >>> Sent: Wednesday, January 09, 2013 11:25 AM > >>> To: mmusic@ietf.org > >>> Subject: [MMUSIC] Query: payload type collision with offer/answer > >>> > >>> Hello, > >>> I have encountered an issue, and I'm not sure it's an issue or not. S= DP > >>> wisdom is sought. > >>> > >>> Suppose two entities exchange the following offer/answer: > >>> > >>> offer from X: > >>> > >>> m=3Dvideo 97 > >>> a=3Drtpmap:97 foo > >>> > >>> answer from Y: > >>> > >>> m=3Dvideo 98 > >>> a=3Drtpmap:98 foo > >>> > >>> It's clear from RFC 3264 that now X must send codec foo with payload > >>> type 98, and Y must send codec foo with payload type 97. That's not t= he > >>> question. > >>> > >>> But suppose these are the offer and answer: > >>> > >>> offer from X: > >>> > >>> m=3Dvideo 97 98 > >>> a=3Drtpmap:97 foo > >>> a=3Drtpmap:98 bar > >>> > >>> answer from Y: > >>> > >>> m=3Dvideo 97 98 > >>> a=3Drtpmap:97 bar > >>> a=3Drtpmap:98 foo > >>> > >>> That is, the payload types collide. > >>> > >>> It would be possible to write code so that X sends foo with 98 and ba= r > >>> with 97, while Y sends foo with 97 and bar with 98. But is it > >> conformant > >>> with the specs to do so? > >>> > >>> And if this has a clear answer - which paragraph of which RFC makes > >> this > >>> clear? > >>> (Yes, this discussion is triggered from a real world problem.) > >> > >> It is recommended to avoid such mismatches when possible, but doing so > >> may not always be possible. The examples you mention are conformant. > >> The following text from section 5.1 addresses this: > >> > >> For sendrecv RTP > >> streams, the payload type numbers indicate the value of the payload > >> type field the offerer expects to receive, and would prefer to send. > >> However, for sendonly and sendrecv streams, the answer might indicate > >> different payload type numbers for the same codecs, in which case, > >> the offerer MUST send with the payload type numbers from the answer. > >> > >> Different payload type numbers may be needed in each direction > >> because of interoperability concerns with H.323. > > I was reading that text, and it clearly says which ones to use if the > > payload types are different, but I don't think they clearly address the > > situation with using the same payload type for two different codecs in > > different directions. > > > > In a multicast or transport relay scenario, this would clearly be > > untenable, since third parties would not be able to send streams that > > would be interpreted correctly by the two conflicting endpoints, but in > > a two-party conversation, it's possible to make this work. > > I just don't know if it's worth the effort to make it so. >=20 > Well there's also section 8.3.2 in 3264. The section is about updating > offers but it seems like the text explicitly prohibits remapping payload > types in any scenarios: >=20 > However, in the > case of RTP, the mapping from a particular dynamic payload type > number to a particular codec within that media stream MUST NOT change > for the duration of a session. For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers for that media stream within the session. However, it is > acceptable for multiple payload type numbers to be mapped to the same > codec, so that an updated offer could also use payload type number 72 > for G.711. I viewed this as being a requirement for all offers or answers sent by A to= B, but not necessarily the corresponding answer and offers from B to A. Ot= herwise, it seems to conflict with the text in section 5.1. That said, I ca= n certainly see where someone else may interpret it differently. Cheers, Charles > Cheers, > Emil >=20 >=20 > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emcho@sip-communicator.org Thu Jan 10 15:37:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED7E21F8545 for ; Thu, 10 Jan 2013 15:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATaj+PCfBDo8 for ; Thu, 10 Jan 2013 15:37:31 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id AA38F21F8419 for ; Thu, 10 Jan 2013 15:37:31 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id un1so586613pbc.6 for ; Thu, 10 Jan 2013 15:37:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=skY3VqHndPvB5D2kStI1GhFGRyrSin4MSd3Em1prLbQ=; b=fib1OmjYO4Y120ndF6xBZJpPVfmxnwn6DjXXCcMKEP5pq0L1l4J0CTu7IDNAS0Msn5 hjcYC4KJynDR2zFbE6WSH17lcwFU/OCnNX8iZ0CFNpczw8ZjOS6g26alrz9bjY5hTfZ2 hrRroDpxRRDHqEDc9Xyqp027NVP3nNBli4pYWQG8UgCeDCMU2Gzn122P+wFywklisMsl Lmt4TFvd3NULuCKM7pUuYvzwKwfVbrirZny/ZwAezhAkzpzX+JEtxs1mpOvCoTKQJU42 SNnQOz4gEm5u7p+rmyGU1qMrV606xbe8yfgV4se3jgeI6OtaCZYbN3TJ9CqV3WO2iP9Y /SZQ== X-Received: by 10.68.244.6 with SMTP id xc6mr224847782pbc.94.1357861051168; Thu, 10 Jan 2013 15:37:31 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by mx.google.com with ESMTPS id nw9sm1577827pbb.42.2013.01.10.15.37.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 15:37:31 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id xa7so585867pbc.14 for ; Thu, 10 Jan 2013 15:37:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.191.5 with SMTP id gu5mr223809334pbc.145.1357861050003; Thu, 10 Jan 2013 15:37:30 -0800 (PST) Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:37:29 -0800 (PST) Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:37:29 -0800 (PST) In-Reply-To: <1.3841c28e488bfa397d5b@cisco.com> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <1.3841c28e488bfa397d5b@cisco.com> Date: Fri, 11 Jan 2013 00:37:29 +0100 Message-ID: From: Emil Ivov To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=e89a8ff1c8ae8a317304d2f7a9e1 X-Gm-Message-State: ALoCoQn0Z/iZedu+C9sk55PmVgLttGp5Eu+L2J4tCuYLu/UsiTbdv/ZH7pLFn2F9U07HATPylAoW Cc: mmusic Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:37:33 -0000 --e89a8ff1c8ae8a317304d2f7a9e1 Content-Type: text/plain; charset=ISO-8859-1 On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" wrote: > > Please see inline. > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Emil Ivov > > Sent: Wednesday, January 09, 2013 3:46 PM > > To: Harald Alvestrand > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer > > > > > > > > On 09.01.13, 23:52, Harald Alvestrand wrote: > > > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: > > >> Please see inline. > > >> > > >>> -----Original Message----- > > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietforg] On > > >>> Behalf Of Harald Alvestrand > > >>> Sent: Wednesday, January 09, 2013 11:25 AM > > >>> To: mmusic@ietf.org > > >>> Subject: [MMUSIC] Query: payload type collision with offer/answer > > >>> > > >>> Hello, > > >>> I have encountered an issue, and I'm not sure it's an issue or not. SDP > > >>> wisdom is sought. > > >>> > > >>> Suppose two entities exchange the following offer/answer: > > >>> > > >>> offer from X: > > >>> > > >>> m=video 97 > > >>> a=rtpmap:97 foo > > >>> > > >>> answer from Y: > > >>> > > >>> m=video 98 > > >>> a=rtpmap:98 foo > > >>> > > >>> It's clear from RFC 3264 that now X must send codec foo with payload > > >>> type 98, and Y must send codec foo with payload type 97. That's not the > > >>> question. > > >>> > > >>> But suppose these are the offer and answer: > > >>> > > >>> offer from X: > > >>> > > >>> m=video 97 98 > > >>> a=rtpmap:97 foo > > >>> a=rtpmap:98 bar > > >>> > > >>> answer from Y: > > >>> > > >>> m=video 97 98 > > >>> a=rtpmap:97 bar > > >>> a=rtpmap:98 foo > > >>> > > >>> That is, the payload types collide. > > >>> > > >>> It would be possible to write code so that X sends foo with 98 and bar > > >>> with 97, while Y sends foo with 97 and bar with 98. But is it > > >> conformant > > >>> with the specs to do so? > > >>> > > >>> And if this has a clear answer - which paragraph of which RFC makes > > >> this > > >>> clear? > > >>> (Yes, this discussion is triggered from a real world problem.) > > >> > > >> It is recommended to avoid such mismatches when possible, but doing so > > >> may not always be possible. The examples you mention are conformant. > > >> The following text from section 5.1 addresses this: > > >> > > >> For sendrecv RTP > > >> streams, the payload type numbers indicate the value of the payload > > >> type field the offerer expects to receive, and would prefer to send. > > >> However, for sendonly and sendrecv streams, the answer might indicate > > >> different payload type numbers for the same codecs, in which case, > > >> the offerer MUST send with the payload type numbers from the answer. > > >> > > >> Different payload type numbers may be needed in each direction > > >> because of interoperability concerns with H.323. > > > I was reading that text, and it clearly says which ones to use if the > > > payload types are different, but I don't think they clearly address the > > > situation with using the same payload type for two different codecs in > > > different directions. > > > > > > In a multicast or transport relay scenario, this would clearly be > > > untenable, since third parties would not be able to send streams that > > > would be interpreted correctly by the two conflicting endpoints, but in > > > a two-party conversation, it's possible to make this work. > > > I just don't know if it's worth the effort to make it so. > > > > Well there's also section 8.3.2 in 3264. The section is about updating > > offers but it seems like the text explicitly prohibits remapping payload > > types in any scenarios: > > > > However, in the > > case of RTP, the mapping from a particular dynamic payload type > > number to a particular codec within that media stream MUST NOT change > > for the duration of a session. For example, if A generates an offer > > with G.711 assigned to dynamic payload type number 46, payload type > > number 46 MUST refer to G.711 from that point forward in any offers > > or answers for that media stream within the session. However, it is > > acceptable for multiple payload type numbers to be mapped to the same > > codec, so that an updated offer could also use payload type number 72 > > for G.711. > > I viewed this as being a requirement for all offers or answers sent by > A to B, but not necessarily the corresponding answer and offers from > B to A. Well, it does say: "from that point forward in _any_ offers or answers" > Otherwise, it seems to conflict with the text in section 5.1. Mmm ... which part of 5.1? To me it just seems like a completion (admittedly, somewhat out of place). > That said, I can certainly see where someone else may interpret it > differently. Agreed. Definitely 3264bis material. Cheers, Emil --sent from my mobile > > Cheers, > Charles > > > Cheers, > > Emil > > > > > > -- > > https://jitsi.org > > _______________________________________________ > > 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 --e89a8ff1c8ae8a317304d2f7a9e1 Content-Type: text/html; charset=ISO-8859-1


On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:
>
> Please see inline.
>
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Emil Ivov
> > Sent: Wednesday, January 09, 2013 3:46 PM
> > To: Harald Alvestrand
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> >
> >
> >
> > On 09.01.13, 23:52, Harald Alvestrand wrote:
> > > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote:
> > >> Please see inline.
> > >>
> > >>> -----Original Message-----
> > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietforg] On
> > >>> Behalf Of Harald Alvestrand
> > >>> Sent: Wednesday, January 09, 2013 11:25 AM
> > >>> To: mmusic@ietf.org
> > >>> Subject: [MMUSIC] Query: payload type collision with offer/answer
> > >>>
> > >>> Hello,
> > >>> I have encountered an issue, and I'm not sure it's an issue or not. SDP
> > >>> wisdom is sought.
> > >>>
> > >>> Suppose two entities exchange the following offer/answer:
> > >>>
> > >>> offer from X:
> > >>>
> > >>> m=video 97
> > >>> a=rtpmap:97 foo
> > >>>
> > >>> answer from Y:
> > >>>
> > >>> m=video 98
> > >>> a=rtpmap:98 foo
> > >>>
> > >>> It's clear from RFC 3264 that now X must send codec foo with payload
> > >>> type 98, and Y must send codec foo with payload type 97. That's not the
> > >>> question.
> > >>>
> > >>> But suppose these are the offer and answer:
> > >>>
> > >>> offer from X:
> > >>>
> > >>> m=video 97 98
> > >>> a=rtpmap:97 foo
> > >>> a=rtpmap:98 bar
> > >>>
> > >>> answer from Y:
> > >>>
> > >>> m=video 97 98
> > >>> a=rtpmap:97 bar
> > >>> a=rtpmap:98 foo
> > >>>
> > >>> That is, the payload types collide.
> > >>>
> > >>> It would be possible to write code so that X sends foo with 98 and bar
> > >>> with 97, while Y sends foo with 97 and bar with 98. But is it
> > >> conformant
> > >>> with the specs to do so?
> > >>>
> > >>> And if this has a clear answer - which paragraph of which RFC makes
> > >> this
> > >>> clear?
> > >>> (Yes, this discussion is triggered from a real world problem.)
> > >>
> > >> It is recommended to avoid such mismatches when possible, but doing so
> > >> may not always be possible. The examples you mention are conformant.
> > >> The following text from section 5.1 addresses this:
> > >>
> > >> For sendrecv RTP
> > >> streams, the payload type numbers indicate the value of the payload
> > >> type field the offerer expects to receive, and would prefer to send.
> > >> However, for sendonly and sendrecv streams, the answer might indicate
> > >> different payload type numbers for the same codecs, in which case,
> > >> the offerer MUST send with the payload type numbers from the answer.
> > >>
> > >> Different payload type numbers may be needed in each direction
> > >> because of interoperability concerns with H.323.
> > > I was reading that text, and it clearly says which ones to use if the
> > > payload types are different, but I don't think they clearly address the
> > > situation with using the same payload type for two different codecs in
> > > different directions.
> > >
> > > In a multicast or transport relay scenario, this would clearly be
> > > untenable, since third parties would not be able to send streams that
> > > would be interpreted correctly by the two conflicting endpoints, but in
> > > a two-party conversation, it's possible to make this work.
> > > I just don't know if it's worth the effort to make it so.
> >
> > Well there's also section 8.3.2 in 3264. The section is about updating
> > offers but it seems like the text explicitly prohibits remapping payload
> > types in any scenarios:
> >
> > However, in the
> > case of RTP, the mapping from a particular dynamic payload type
> > number to a particular codec within that media stream MUST NOT change
> > for the duration of a session. For example, if A generates an offer
> > with G.711 assigned to dynamic payload type number 46, payload type
> > number 46 MUST refer to G.711 from that point forward in any offers
> > or answers for that media stream within the session. However, it is
> > acceptable for multiple payload type numbers to be mapped to the same
> > codec, so that an updated offer could also use payload type number 72
> > for G.711.
>
> I viewed this as being a requirement for all offers or answers sent by
> A to B, but not necessarily the corresponding answer and offers from
> B to A.

Well, it does say: "from that point forward in _any_ offers or answers"

> Otherwise, it seems to conflict with the text in section 5.1.

Mmm ... which part of 5.1?

To me it just seems like a completion (admittedly, somewhat out of place).

> That said, I can certainly see where someone else may interpret it
> differently.

Agreed. Definitely 3264bis material.

Cheers,
Emil

--sent from my mobile
>
> Cheers,
> Charles
>
> > Cheers,
> > Emil
> >
> >
> > --
> > https://jitsi.org
> > _______________________________________________
> > 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

--e89a8ff1c8ae8a317304d2f7a9e1-- From matthew@matthew.at Thu Jan 10 15:46:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4111521F8450 for ; Thu, 10 Jan 2013 15:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J2bLaaP+Mwv for ; Thu, 10 Jan 2013 15:46:57 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2321F8442 for ; Thu, 10 Jan 2013 15:46:57 -0800 (PST) Received: from [10.10.155.240] (unknown [10.10.155.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 6199814804B; Thu, 10 Jan 2013 15:46:57 -0800 (PST) Message-ID: <50EF52DA.3030007@matthew.at> Date: Thu, 10 Jan 2013 15:46:34 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> <50EB15C3.2010707@cisco.com> In-Reply-To: <50EB15C3.2010707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fandreas@cisco.com Subject: Re: [MMUSIC] Fwd: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:46:58 -0000 Is there yet an agenda for the upcoming MMUSIC interim or at least a list of drafts we intend to discuss that I could review in advance? Just feels like we're running out of days for advance flight bookings. Matthew Kaufman From eckelcu@cisco.com Thu Jan 10 15:47:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C17621F84DC for ; Thu, 10 Jan 2013 15:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.675 X-Spam-Level: X-Spam-Status: No, score=-8.675 tagged_above=-999 required=5 tests=[AWL=1.324, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2H+0e5URcAG for ; Thu, 10 Jan 2013 15:47:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2852A21F8461 for ; Thu, 10 Jan 2013 15:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6468; q=dns/txt; s=iport; t=1357861662; x=1359071262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2dIkjxj4Q66KvRhgFNOrvEdaqvtyRXiAQBqXbsKraQA=; b=OvpmVtg0Kuvejor1cinE4mOMBEmjpXvLLgsErfIFxxjM7vIEnfVu6Oz2 1HedS39Qtwy1ittC1BOrRUKk0eZ9ijCIKwjjuxglG/ETFlTpLO6/pDSse IpWqo4hVgQTIOa1umNJgPoqaxWanXGiVbar9oYcunhEszHu94XKK5Ef8v I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN5R71CtJXG+/2dsb2JhbABEvXUWc4IeAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQEKFAkHJwsUCQgCBA4FCIgLBQEMtGUEkD5hA6ZTgnWBZgc3 X-IronPort-AV: E=Sophos;i="4.84,447,1355097600"; d="scan'208";a="161172442" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jan 2013 23:47:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0ANlfL0025819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jan 2013 23:47:41 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 17:47:41 -0600 From: "Charles Eckel (eckelcu)" To: Emil Ivov Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: AQHN74t0zrd89LSrqUC7n2O8JcktGJhDOf3g Date: Thu, 10 Jan 2013 23:47:40 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804728A0B@xmb-aln-x08.cisco.com> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com><50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org><1.3841c28e488bfa397d5b@cisco.com> <1.96f025c482c091c166cc@jitsi.org> In-Reply-To: <1.96f025c482c091c166cc@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:47:49 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Thursday, January 10, 2013 3:37 PM > To: Charles Eckel (eckelcu) > Cc: mmusic > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer >=20 >=20 >=20 >=20 > On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" > wrote: > > > > Please see inline. > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > > Behalf Of Emil Ivov > > > Sent: Wednesday, January 09, 2013 3:46 PM > > > To: Harald Alvestrand > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer > > > > > > > > > > > > On 09.01.13, 23:52, Harald Alvestrand wrote: > > > > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: > > > >> Please see inline. > > > >> > > > >>> -----Original Message----- > > > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietforg] > On > > > >>> Behalf Of Harald Alvestrand > > > >>> Sent: Wednesday, January 09, 2013 11:25 AM > > > >>> To: mmusic@ietf.org > > > >>> Subject: [MMUSIC] Query: payload type collision with offer/answer > > > >>> > > > >>> Hello, > > > >>> I have encountered an issue, and I'm not sure it's an issue or no= t. SDP > > > >>> wisdom is sought. > > > >>> > > > >>> Suppose two entities exchange the following offer/answer: > > > >>> > > > >>> offer from X: > > > >>> > > > >>> m=3Dvideo 97 > > > >>> a=3Drtpmap:97 foo > > > >>> > > > >>> answer from Y: > > > >>> > > > >>> m=3Dvideo 98 > > > >>> a=3Drtpmap:98 foo > > > >>> > > > >>> It's clear from RFC 3264 that now X must send codec foo with payl= oad > > > >>> type 98, and Y must send codec foo with payload type 97. That's n= ot > the > > > >>> question. > > > >>> > > > >>> But suppose these are the offer and answer: > > > >>> > > > >>> offer from X: > > > >>> > > > >>> m=3Dvideo 97 98 > > > >>> a=3Drtpmap:97 foo > > > >>> a=3Drtpmap:98 bar > > > >>> > > > >>> answer from Y: > > > >>> > > > >>> m=3Dvideo 97 98 > > > >>> a=3Drtpmap:97 bar > > > >>> a=3Drtpmap:98 foo > > > >>> > > > >>> That is, the payload types collide. > > > >>> > > > >>> It would be possible to write code so that X sends foo with 98 an= d bar > > > >>> with 97, while Y sends foo with 97 and bar with 98. But is it > > > >> conformant > > > >>> with the specs to do so? > > > >>> > > > >>> And if this has a clear answer - which paragraph of which RFC mak= es > > > >> this > > > >>> clear? > > > >>> (Yes, this discussion is triggered from a real world problem.) > > > >> > > > >> It is recommended to avoid such mismatches when possible, but > doing so > > > >> may not always be possible. The examples you mention are > conformant. > > > >> The following text from section 5.1 addresses this: > > > >> > > > >> For sendrecv RTP > > > >> streams, the payload type numbers indicate the value of the payloa= d > > > >> type field the offerer expects to receive, and would prefer to sen= d. > > > >> However, for sendonly and sendrecv streams, the answer might > indicate > > > >> different payload type numbers for the same codecs, in which case, > > > >> the offerer MUST send with the payload type numbers from the > answer. > > > >> > > > >> Different payload type numbers may be needed in each direction > > > >> because of interoperability concerns with H.323. > > > > I was reading that text, and it clearly says which ones to use if t= he > > > > payload types are different, but I don't think they clearly address= the > > > > situation with using the same payload type for two different codecs= in > > > > different directions. > > > > > > > > In a multicast or transport relay scenario, this would clearly be > > > > untenable, since third parties would not be able to send streams th= at > > > > would be interpreted correctly by the two conflicting endpoints, bu= t in > > > > a two-party conversation, it's possible to make this work. > > > > I just don't know if it's worth the effort to make it so. > > > > > > Well there's also section 8.3.2 in 3264. The section is about updatin= g > > > offers but it seems like the text explicitly prohibits remapping payl= oad > > > types in any scenarios: > > > > > > However, in the > > > case of RTP, the mapping from a particular dynamic payload type > > > number to a particular codec within that media stream MUST NOT change > > > for the duration of a session. For example, if A generates an offer > > > with G.711 assigned to dynamic payload type number 46, payload type > > > number 46 MUST refer to G.711 from that point forward in any offers > > > or answers for that media stream within the session. However, it is > > > acceptable for multiple payload type numbers to be mapped to the same > > > codec, so that an updated offer could also use payload type number 72 > > > for G.711. > > > > I viewed this as being a requirement for all offers or answers sent by > > A to B, but not necessarily the corresponding answer and offers from > > B to A. >=20 > Well, it does say: "from that point forward in _any_ offers or answers" >=20 > > Otherwise, it seems to conflict with the text in section 5.1. >=20 > Mmm ... which part of 5.1? This part: However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. Different payload type numbers may be needed in each direction because of interoperability concerns with H.323. =20 Cheers, Charles > To me it just seems like a completion (admittedly, somewhat out of place)= . >=20 > > That said, I can certainly see where someone else may interpret it > > differently. >=20 > Agreed. Definitely 3264bis material. >=20 > Cheers, > Emil >=20 > --sent from my mobile > > > > Cheers, > > Charles > > > > > Cheers, > > > Emil > > > > > > > > > -- > > > https://jitsi.org > > > _______________________________________________ > > > 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 From emcho@sip-communicator.org Thu Jan 10 15:54:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB221F8799 for ; Thu, 10 Jan 2013 15:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD1vSBL8SYLd for ; Thu, 10 Jan 2013 15:54:44 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D521F8501 for ; Thu, 10 Jan 2013 15:54:44 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ro2so595435pbb.39 for ; Thu, 10 Jan 2013 15:54:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EeuPfvsP5IXIfwwYjeW9RrJq8yug6DL59PL+8f4/66U=; b=ZxQzmDQRk7kYBWf8bqxJ3Ej4X/CwnTNhBqMcHvZaf8UxcVdqisAq5nL15K1YBDm6mu 75wXVyFOH74n0m7OhTiP0Gbqpjv6PhebFez4lsAmPUBrrVup/T4szNT+h3rsjSDiK+9c XOGFTeC/cIlR9mJKWa0ipMUmtsA+j9vG9wXGxrk7Hy9pFc0aaQpRPC/q78jaNILY6Jg/ z8Cx9DdkqbIDu39Wn2qlqetEaga0MbblDrl9gX09saGxCsKHU/tawaHLzCH9dCqxRVle nO5QlI1qmily5O2/qsYioKAIR7Oot9c+E2FXwLQ/q2CFsgT9RcCleliYyKHvK0c94cbH PPNw== X-Received: by 10.68.223.131 with SMTP id qu3mr222980467pbc.89.1357862084303; Thu, 10 Jan 2013 15:54:44 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx.google.com with ESMTPS id sb3sm1600845pbc.44.2013.01.10.15.54.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 15:54:44 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fb1so650812pad.25 for ; Thu, 10 Jan 2013 15:54:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.86.101 with SMTP id o5mr202532764paz.15.1357862083128; Thu, 10 Jan 2013 15:54:43 -0800 (PST) Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:54:43 -0800 (PST) Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:54:43 -0800 (PST) In-Reply-To: <1.a70a7a76ba63b579d824@cisco.com> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <1.3841c28e488bfa397d5b@cisco.com> <1.96f025c482c091c166cc@jitsi.org> <1.a70a7a76ba63b579d824@cisco.com> Date: Fri, 11 Jan 2013 00:54:43 +0100 Message-ID: From: Emil Ivov To: "Charles Eckel, (eckelcu)" Content-Type: multipart/alternative; boundary=f46d042de8071e6d3b04d2f7e7fa X-Gm-Message-State: ALoCoQlLTpUAgBxTZH6hGQDZyze7AKIJQyJHXsCzwGIJFm8Vp5sKCwp4H/GKa3nVuRKmt4p66pEp Cc: mmusic Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 23:54:46 -0000 --f46d042de8071e6d3b04d2f7e7fa Content-Type: text/plain; charset=ISO-8859-1 On Jan 11, 2013 12:48 AM, "Charles Eckel (eckelcu)" wrote: > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Emil Ivov > > Sent: Thursday, January 10, 2013 3:37 PM > > To: Charles Eckel (eckelcu) > > Cc: mmusic > > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer > > > > > > > > > > On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" > > wrote: > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > > > Behalf Of Emil Ivov > > > > Sent: Wednesday, January 09, 2013 3:46 PM > > > > To: Harald Alvestrand > > > > Cc: mmusic@ietf.org > > > > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer > > > > > > > > > > > > > > > > On 09.01.13, 23:52, Harald Alvestrand wrote: > > > > > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: > > > > >> Please see inline. > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietforg] > > On > > > > >>> Behalf Of Harald Alvestrand > > > > >>> Sent: Wednesday, January 09, 2013 11:25 AM > > > > >>> To: mmusic@ietf.org > > > > >>> Subject: [MMUSIC] Query: payload type collision with offer/answer > > > > >>> > > > > >>> Hello, > > > > >>> I have encountered an issue, and I'm not sure it's an issue or not. SDP > > > > >>> wisdom is sought. > > > > >>> > > > > >>> Suppose two entities exchange the following offer/answer: > > > > >>> > > > > >>> offer from X: > > > > >>> > > > > >>> m=video 97 > > > > >>> a=rtpmap:97 foo > > > > >>> > > > > >>> answer from Y: > > > > >>> > > > > >>> m=video 98 > > > > >>> a=rtpmap:98 foo > > > > >>> > > > > >>> It's clear from RFC 3264 that now X must send codec foo with payload > > > > >>> type 98, and Y must send codec foo with payload type 97. That's not > > the > > > > >>> question. > > > > >>> > > > > >>> But suppose these are the offer and answer: > > > > >>> > > > > >>> offer from X: > > > > >>> > > > > >>> m=video 97 98 > > > > >>> a=rtpmap:97 foo > > > > >>> a=rtpmap:98 bar > > > > >>> > > > > >>> answer from Y: > > > > >>> > > > > >>> m=video 97 98 > > > > >>> a=rtpmap:97 bar > > > > >>> a=rtpmap:98 foo > > > > >>> > > > > >>> That is, the payload types collide. > > > > >>> > > > > >>> It would be possible to write code so that X sends foo with 98 and bar > > > > >>> with 97, while Y sends foo with 97 and bar with 98. But is it > > > > >> conformant > > > > >>> with the specs to do so? > > > > >>> > > > > >>> And if this has a clear answer - which paragraph of which RFC makes > > > > >> this > > > > >>> clear? > > > > >>> (Yes, this discussion is triggered from a real world problem.) > > > > >> > > > > >> It is recommended to avoid such mismatches when possible, but > > doing so > > > > >> may not always be possible. The examples you mention are > > conformant. > > > > >> The following text from section 5.1 addresses this: > > > > >> > > > > >> For sendrecv RTP > > > > >> streams, the payload type numbers indicate the value of the payload > > > > >> type field the offerer expects to receive, and would prefer to send. > > > > >> However, for sendonly and sendrecv streams, the answer might > > indicate > > > > >> different payload type numbers for the same codecs, in which case, > > > > >> the offerer MUST send with the payload type numbers from the > > answer. > > > > >> > > > > >> Different payload type numbers may be needed in each direction > > > > >> because of interoperability concerns with H.323. > > > > > I was reading that text, and it clearly says which ones to use if the > > > > > payload types are different, but I don't think they clearly address the > > > > > situation with using the same payload type for two different codecs in > > > > > different directions. > > > > > > > > > > In a multicast or transport relay scenario, this would clearly be > > > > > untenable, since third parties would not be able to send streams that > > > > > would be interpreted correctly by the two conflicting endpoints, but in > > > > > a two-party conversation, it's possible to make this work. > > > > > I just don't know if it's worth the effort to make it so. > > > > > > > > Well there's also section 8.3.2 in 3264. The section is about updating > > > > offers but it seems like the text explicitly prohibits remapping payload > > > > types in any scenarios: > > > > > > > > However, in the > > > > case of RTP, the mapping from a particular dynamic payload type > > > > number to a particular codec within that media stream MUST NOT change > > > > for the duration of a session. For example, if A generates an offer > > > > with G.711 assigned to dynamic payload type number 46, payload type > > > > number 46 MUST refer to G.711 from that point forward in any offers > > > > or answers for that media stream within the session. However, it is > > > > acceptable for multiple payload type numbers to be mapped to the same > > > > codec, so that an updated offer could also use payload type number 72 > > > > for G.711. > > > > > > I viewed this as being a requirement for all offers or answers sent by > > > A to B, but not necessarily the corresponding answer and offers from > > > B to A. > > > > Well, it does say: "from that point forward in _any_ offers or answers" > > > > > Otherwise, it seems to conflict with the text in section 5.1. > > > > Mmm ... which part of 5.1? > > This part: > > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > Different payload type numbers may be needed in each direction > because of interoperability concerns with H.323. This part just says the PT numbers can be different in the offer and the answer. It doesn't say they can be the same as other PT numbers that were assigned to other formats, which is what section 8.3.2 prohibits. This is the reason I was seeing 8.3.2 more as a completion rather than a contradiction. Emil --sent from my mobile > > Cheers, > Charles > > > To me it just seems like a completion (admittedly, somewhat out of place). > > > > > That said, I can certainly see where someone else may interpret it > > > differently. > > > > Agreed. Definitely 3264bis material. > > > > Cheers, > > Emil > > > > --sent from my mobile > > > > > > Cheers, > > > Charles > > > > > > > Cheers, > > > > Emil > > > > > > > > > > > > -- > > > > https://jitsi.org > > > > _______________________________________________ > > > > 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 --f46d042de8071e6d3b04d2f7e7fa Content-Type: text/html; charset=ISO-8859-1


On Jan 11, 2013 12:48 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:
>
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Emil Ivov
> > Sent: Thursday, January 10, 2013 3:37 PM
> > To: Charles Eckel (eckelcu)
> > Cc: mmusic
> > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> >
> >
> >
> >
> > On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
> > wrote:
> > >
> > > Please see inline.
> > >
> > > > -----Original Message-----
> > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > > > Behalf Of Emil Ivov
> > > > Sent: Wednesday, January 09, 2013 3:46 PM
> > > > To: Harald Alvestrand
> > > > Cc: mmusic@ietf.org
> > > > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> > > >
> > > >
> > > >
> > > > On 09.01.13, 23:52, Harald Alvestrand wrote:
> > > > > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote:
> > > > >> Please see inline.
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietforg]
> > On
> > > > >>> Behalf Of Harald Alvestrand
> > > > >>> Sent: Wednesday, January 09, 2013 11:25 AM
> > > > >>> To: mmusic@ietf.org
> > > > >>> Subject: [MMUSIC] Query: payload type collision with offer/answer
> > > > >>>
> > > > >>> Hello,
> > > > >>> I have encountered an issue, and I'm not sure it's an issue or not. SDP
> > > > >>> wisdom is sought.
> > > > >>>
> > > > >>> Suppose two entities exchange the following offer/answer:
> > > > >>>
> > > > >>> offer from X:
> > > > >>>
> > > > >>> m=video 97
> > > > >>> a=rtpmap:97 foo
> > > > >>>
> > > > >>> answer from Y:
> > > > >>>
> > > > >>> m=video 98
> > > > >>> a=rtpmap:98 foo
> > > > >>>
> > > > >>> It's clear from RFC 3264 that now X must send codec foo with payload
> > > > >>> type 98, and Y must send codec foo with payload type 97. That's not
> > the
> > > > >>> question.
> > > > >>>
> > > > >>> But suppose these are the offer and answer:
> > > > >>>
> > > > >>> offer from X:
> > > > >>>
> > > > >>> m=video 97 98
> > > > >>> a=rtpmap:97 foo
> > > > >>> a=rtpmap:98 bar
> > > > >>>
> > > > >>> answer from Y:
> > > > >>>
> > > > >>> m=video 97 98
> > > > >>> a=rtpmap:97 bar
> > > > >>> a=rtpmap:98 foo
> > > > >>>
> > > > >>> That is, the payload types collide.
> > > > >>>
> > > > >>> It would be possible to write code so that X sends foo with 98 and bar
> > > > >>> with 97, while Y sends foo with 97 and bar with 98. But is it
> > > > >> conformant
> > > > >>> with the specs to do so?
> > > > >>>
> > > > >>> And if this has a clear answer - which paragraph of which RFC makes
> > > > >> this
> > > > >>> clear?
> > > > >>> (Yes, this discussion is triggered from a real world problem.)
> > > > >>
> > > > >> It is recommended to avoid such mismatches when possible, but
> > doing so
> > > > >> may not always be possible. The examples you mention are
> > conformant.
> > > > >> The following text from section 5.1 addresses this:
> > > > >>
> > > > >> For sendrecv RTP
> > > > >> streams, the payload type numbers indicate the value of the payload
> > > > >> type field the offerer expects to receive, and would prefer to send.
> > > > >> However, for sendonly and sendrecv streams, the answer might
> > indicate
> > > > >> different payload type numbers for the same codecs, in which case,
> > > > >> the offerer MUST send with the payload type numbers from the
> > answer.
> > > > >>
> > > > >> Different payload type numbers may be needed in each direction
> > > > >> because of interoperability concerns with H.323.
> > > > > I was reading that text, and it clearly says which ones to use if the
> > > > > payload types are different, but I don't think they clearly address the
> > > > > situation with using the same payload type for two different codecs in
> > > > > different directions.
> > > > >
> > > > > In a multicast or transport relay scenario, this would clearly be
> > > > > untenable, since third parties would not be able to send streams that
> > > > > would be interpreted correctly by the two conflicting endpoints, but in
> > > > > a two-party conversation, it's possible to make this work.
> > > > > I just don't know if it's worth the effort to make it so.
> > > >
> > > > Well there's also section 8.3.2 in 3264. The section is about updating
> > > > offers but it seems like the text explicitly prohibits remapping payload
> > > > types in any scenarios:
> > > >
> > > > However, in the
> > > > case of RTP, the mapping from a particular dynamic payload type
> > > > number to a particular codec within that media stream MUST NOT change
> > > > for the duration of a session. For example, if A generates an offer
> > > > with G.711 assigned to dynamic payload type number 46, payload type
> > > > number 46 MUST refer to G.711 from that point forward in any offers
> > > > or answers for that media stream within the session. However, it is
> > > > acceptable for multiple payload type numbers to be mapped to the same
> > > > codec, so that an updated offer could also use payload type number 72
> > > > for G.711.
> > >
> > > I viewed this as being a requirement for all offers or answers sent by
> > > A to B, but not necessarily the corresponding answer and offers from
> > > B to A.
> >
> > Well, it does say: "from that point forward in _any_ offers or answers"
> >
> > > Otherwise, it seems to conflict with the text in section 5.1.
> >
> > Mmm ... which part of 5.1?
>
> This part:
>
> However, for sendonly and sendrecv streams, the answer might indicate
> different payload type numbers for the same codecs, in which case,
> the offerer MUST send with the payload type numbers from the answer.
>
> Different payload type numbers may be needed in each direction
> because of interoperability concerns with H.323.

This part just says the PT numbers can be different in the offer and the answer. It doesn't say they can be the same as other PT numbers that were assigned to other formats, which is what section 8.3.2 prohibits.

This is the reason I was seeing 8.3.2 more as a completion rather than a contradiction.

Emil
--sent from my mobile

>
> Cheers,
> Charles
>
> > To me it just seems like a completion (admittedly, somewhat out of place).
> >
> > > That said, I can certainly see where someone else may interpret it
> > > differently.
> >
> > Agreed. Definitely 3264bis material.
> >
> > Cheers,
> > Emil
> >
> > --sent from my mobile
> > >
> > > Cheers,
> > > Charles
> > >
> > > > Cheers,
> > > > Emil
> > > >
> > > >
> > > > --
> > > > https://jitsi.org
> > > > _______________________________________________
> > > > 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

--f46d042de8071e6d3b04d2f7e7fa-- From pkyzivat@alum.mit.edu Thu Jan 10 16:01:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC41D21F8495 for ; Thu, 10 Jan 2013 16:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+NEwcLImmSW for ; Thu, 10 Jan 2013 16:01:57 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C153E21F86D9 for ; Thu, 10 Jan 2013 16:01:55 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id mQ1N1k0091ei1Bg53Q1qp7; Fri, 11 Jan 2013 00:01:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id mQ1q1k00W3ZTu2S3kQ1qNn; Fri, 11 Jan 2013 00:01:50 +0000 Message-ID: <50EF566D.3010809@alum.mit.edu> Date: Thu, 10 Jan 2013 19:01:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dan Wing References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> <50E5DAA2.9050600@alum.mit.edu> <01da01cdef7e$b424c9c0$1c6e5d40$@cisco.com> In-Reply-To: <01da01cdef7e$b424c9c0$1c6e5d40$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357862510; bh=reALpl+oDQPHtF3eVSxRp7iWSACHZIOq2SDDCXTC+CM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=stJzyDBg6pDLRjuE4i5xWNXKR0yWcFZr9B4vyHHERY9s+15Hqbj40Wqiqn5Euudyw WY4Dz5MszyxQEQtbFhZNzkX/6e+Z4xmJEzZNxEVHiX+HvxzcP0nTyO1nJEzFuU2D+6 UyCfJzflbs0EfyDC5LpFLlIkb37Cx76+H8lw6Ji49+9Xi8SgG6apeXZne0C3NN8CyN S0JfYdKdN8HWeIKxLZX83Bb8d586Xny0ZRUVMbWq5sIzpjjYXwxDLoPInPzaMSz3C4 gv6Ytqf2cs/+wCOLyaGfT1Ys7YEtsWxsOtDouy+usaFzYIBaBGVbimmqj+5vWXA7lt u0qkA3H6KyVlA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 00:01:59 -0000 On 1/10/13 5:06 PM, Dan Wing wrote: >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, January 03, 2013 11:23 AM >> To: Dan Wing >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? >> >> I'm totally lost! >> I looked back, and count 43 messages in this thread. >> At this point I no longer understand the question(s), or what if >> anything has been answered. >> >> Can we start over? >> Sort out what the questions are, and then discuss whether we have >> answers to them? >> (Preferably in separate, well identified, threads.) >> >> I *think* Harald originally asserted that DTLS/SCTP *can* already be >> multiplexed with SRTP audio and video streams. > > Yes, it can. > > An UDP packet is either a STUN packet (for ICE connectivity checks), > DTLS, or SRTP. This is depicted in Section 5.1.2 of RFC5764: > > +----------------+ > | 127 < B < 192 -+--> forward to RTP > | | > packet --> | 19 < B < 64 -+--> forward to DTLS > | | > | B < 2 -+--> forward to STUN > +----------------+ > > A DTLS packet containing application_data is handed to the SCTP stack. > > As I have mentioned previously, I am concerned with sending both realtime > interactive audio/video and non-realtime data over the same UDP 5-tuple, > because it becomes difficult (or impossible) to apply QoS to differentiate > those very different flows. If everyone always had adequate bandwidth, that > concern would vanish. But the industry has never been able to stay ahead of > the bandwidth curve. This is all about policy, not mechanism. It seems that some people want to use this mechanism and think it will be good for them. Perhaps there can be a section in some draft on this subject that points out your concern and recommends that people consider carefully what they multiplex on the same 5-tuple. Similar arguments may apply to bundling audio and video onto the same 5-tuple. >> And so he was asking >> *how* this could be specified in SDP. (E.g. Does "bundle" support it?) > > We need a way for SDP to signal: > 1. the UDP port for SCTP. This feels like an SDP media ("m") line to me. > 2. SCTP native (native SCTP over IPv6 should be tenable, whereas native > SCTP over IPv4 is pretty much untenable), > 3. the data carried over each SCTP port (e.g., port NNN for XMPP, port > NNNN for file sharing, port NNNNN for screen sharing, and so on). This > feels like an SDP media ("m") line to me. I don't disagree with any of your points, but you have missed the point I was making. Everything you list applies for SCTP on its own 5-tuple. But then there is the question of how to describe how this shares a 5-tuple with some audio and video streams. The current candidates for representing the bundling of audio and video are the bundle draft and the mmt draft. Neither of these currently supports including DTLS/SCTP with audio or video. So if bundling in the SCTP is a requirement, then both bundle and mmt should be extended cover it if they are to remain in the running. A *native* SCTP session (directly over IPv*) runs on a 5-tuple, including the *SCTP* ports at each end. So the SDP for that needs to specify a port. ISTM that in this case the port field on the m-line would signify the SCTP port. And this is what draft-ietf-mmusic-sctp-sdp says. A DTLS/SCTP session requires a 7-tuple, including both an SCTP port and a UDP port at each end. So the SDP for that needs to specify both an SCTP port and a UDP port. Only one of those can be in the port field of the m-line. (Which one that should be can be argued either way.) draft-ietf-mmusic-sctp-sdp puts the UDP port in the m-line, and has no way to specify the SCTP port. (It has an open issue about that. Presumably it is either defaulted or must go in an attribute.) > I don't think we can use media lines for both (1) and (3), so perhaps > bundling is the answer. I don't know. Even *with* bundling the problem remains. But I agree that if you want to run SCTP on two or more SCTP ports over the same UDP port, then bundle is one way to do it. Each of the bundled m-lines would have to specify the SCTP port, presumably as an attribute. >> Along the way, a question came up of how many DTLS/SCTP connections >> could be multiplexed with each other and with SRTP media. I think Harald >> assumed only one (and assumed there is only a need for one.) But reasons >> for more have been discussed. I suggested that it appears that multiple >> should be supportable, each with a different SCTP port. >> >> I think Dan raised some additional issues related to multipath support. > > SCTP can support multipath, so we need to decide if we allow SCTP to do its > own multipath, or if we require ICE to first validate a (new) path before > SCTP can try to do its multipath. This is outside my area of expertise. > The same question and issues exist for > multipath RTP (draft-singh-avtcore-mprtp) and how multipath RTP should > split its functions between ICE, ICE extensions, and SDP. I know that > multipath RTP is not a working group document, but it might be a good > basis for analyzing multipath SCTP and reaching a conclusion on multipath > SCTP that makes sense for both multipath SCTP and multipath RTP (and > presumably multipath TCP, RFC6182 and its related documents). If you want to multiplex SCTP and RTP on the same connection, and you are going to make SCTP multipath work for that, then why would you not just do RTP over an SCTP channel??? Then you don't need to reinvent how to multipath for RTP. Thanks, Paul > -d > > >> Thanks, >> Paul >> >> On 1/2/13 10:32 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Tuesday, December 11, 2012 11:17 AM >>>> To: Dan Wing >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >>>> >>>> Hi Dan, >>>> >>>> Comments inline >>>> >>>> On 12/11/12 1:53 PM, Dan Wing wrote: >>>>>> -----Original Message----- >>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Tuesday, December 11, 2012 7:43 AM >>>>>> To: mmusic@ietf.org >>>>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >>>>>> >>>>>> More inline. >>>>>> >>>>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: >>>>>>> Hi Paul, >>>>>>> >>>>>>> see in line! >>>>>>> >>>>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: >>>>>>>> Commenting on a different point >>>>>>>> >>>>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: >>>>>>>> >>>>>>>>> The interesting difference is that the multiplexing between >>>>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP >>>>>>>>> traffic is not carried in SSRCs, which means: >>>>>>>>> >>>>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may >>>>>>>>> have multiple associations, as you state below); you can't have >>>>>>>>> multiple lines with proto DTLS/SCTP in a bundle. >>>>>>>> >>>>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run >>>>>>>> directly over IP. It has its own notion of port used to demux >>>>>>>> multiple SCTP associations over the same IP address. >>>>>>>> >>>>>>>> I presume that that same mechanism is still there when SCTP is >>>>>>>> run over DTLS over UDP. >>>>>>>> >>>>>>>> So, the traffic coming over DTLS must first be demuxed into RTP >>>>>>>> traffic and SCTP traffic. >>>>>>> based on the current stack the SCTP traffic is the only traffic >>>>>>> that runs directly over the DTLS stack. >>>>>> >>>>>> Yes, that is what I thought. But Harald has been asking about >>>>>> multiplexing this with RTP traffic. (Actually I think it would be >>>>>> DTLS/SRTP traffic that it would be multiplexed with.) >>>>>> >>>>>>> What I am trying to do is to include the Randell Jesup (I am >>>>>>> including him in CC as I am not sure he is subscribed to this >>>>>>> mailing list) suggestion to give the possibility to have multiple >>>>>>> SCTP >>>>>>> *associations* running on top of the same DTLS session and of >>>>>>> course providing a way to signal it in SDP. >>>>>> >>>>>> IIUC, SCTP (having been designed as a transport layer protocol) >>>>>> defines its own notion of port, and has fields in its protocol to >>>>>> carry the local and remote port number. Presumably those fields are >>>>>> still there when run over UDP or DTLS. So it should be possible to >>>>>> support multiple SCTP associations over the same DTLS connection, >>>>>> each distinguished by its own port pair. >>>>> >>>>> Yes, SCTP has its own notion of ports. How this works when SCTP is >>>>> carried over UDP is not quite clear, especially because SCTP assumes >>>>> a NAPT will not rewrite the SCTP port number (SCTP endeavors to make >>>>> such port rewriting difficult). But of course a NAPT (and the MAP >>>>> techniques) rewrite UDP port numbers. I believe SCTP would only be >>>>> able to successfully convey its UDP port numbers for a device that >>>>> is not behind a NAT (that is, a server sitting directly on the >>>>> Internet, rather than a remote peer that is behind a NAT). Creative >>>>> use of PCP, NAT-PMP, or UPnP IGD would improve that situation in the >> future. >>>> >>>> I find what you say above confusing. >>>> >>>> SCTP running naked over IP would still have its own ports. >>>> If that ran over a path with a NAPT, then I could see why the NAPT >>>> might want to do the same as it does with UDP and TCP, and so replace >>>> addr/port pairs to minimize addr usage. (That's if the NAPT supported >>>> SCTP at all - I gather most don't.) >>> >>> As I mentioned earlier, SCTP does not allow its source port number to >>> be changed. >>> >>>> But with SCTP over DTLS over UDP, there is a UDP port, and then >>>> presumably a separate SCTP port carried in the SCTP protocol within >>>> the UDP message. >>> >>> Yep, I assume that is how it works. Effectively, UDP is just used to >>> tunnel the SCTP. >>> >>>> An NAPT on the path would presumably be messing with the UDP port. >>>> Given use of DTLS, the NAPT won't even be able to tell that SCTP is >>>> being used, much less mess with the SCTP port. >>>> >>>>>> That of course depends on having a signaling mechanism to set it >> up. >>>>> >>>>> After the initial SCTP association is created, SCTP could be allowed >>>>> to do its own thing (that is, chose to find and use other ports). >>>> >>>> Here you are talking about finding and using other UDP addr/port >> pairs? >>> >>> No, I was referring to the SCTP ports. >>> >>> -d >>> >>> >>>> That is explicitly excluded in the DTLS/SCTP mapping. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP), >>>>> but of course they are not identical. >>>>> >>>>>>> to be clear: at moment WebRTC allows only one SCTP association per >>>>>>> PC, so this is something that would be nice to define just to be >>>>>>> ready for the future. >>>>>> >>>>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP >>>>>> mechanism shouldn't be limited by the constraints of WebRTC. It >>>>>> would be very difficult to define the SDP so that it was impossible >>>>>> to set up multiple SCTP associations over different 5-tuples. >>>>>> >>>>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP >>>>>>>> traffic can be demuxed based on SCTP port. And once the traffic >>>>>>>> for a single SCTP port is identified, it can be demuxed based on >>>>>>>> stream >>>> number. >>>>>>>> >>>>>>>> Representing this in SDP is a challenge. Some variant of the >>>>>>>> bundle proposal might allow bundling together several RTP m-lines >>>>>>>> and some DTLS/SCTP m-lines. This would require a mechanism for >>>>>>>> specifying the SCTP port number - already an open issue (#3) in >>>>>>>> draft-ietf-mmusic-sctp-sdp-02. >>>>>>> I agree that it is a challange how then to bundle everything >>>>>>> together >>>>>> >>>>>> But it is a challenge that needs to be tackled if we are to realize >>>>>> Harald's dream. >>>>> >>>>> -d >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> > > From dwing@cisco.com Thu Jan 10 21:51:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD55A21F85EA for ; Thu, 10 Jan 2013 21:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.922 X-Spam-Level: X-Spam-Status: No, score=-109.922 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+y9JfFHjLs8 for ; Thu, 10 Jan 2013 21:51:24 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0252A21F8480 for ; Thu, 10 Jan 2013 21:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14074; q=dns/txt; s=iport; t=1357883480; x=1359093080; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=kB2P0H5DvQH4CIgjzedwo6kXsNSAPWCXaldqbET3YxE=; b=Xr2244rfJbzaro3AI5xXe075qDW0jgQPT7SC0m5L6d4/bGj7AhvxWZC9 YCrjgeFe3Dbdubi/doxuZJ4nVuCNjgilc8Ip4G55CDmDOOjcQamcoLVZC AY2pAZNzelUg2Ue3kCwr2mVw2ZqEkxxfrst0ghiKwbBNNBAXpeqTF6aNQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0HAHGn71CrRDoJ/2dsb2JhbABEDoM5ujEWc4IeAQEBAwEBAQEFAh0TLQQDCwUHAQMCCQ4DBAEBAScHGQ4fCQgCBBMLBYgDBQ20dwSMXBWELgOIYIUciA6QSYI3X4FFAh4G X-IronPort-AV: E=Sophos;i="4.84,449,1355097600"; d="scan'208";a="65404930" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 Jan 2013 05:51:20 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0B5pJrD030730; Fri, 11 Jan 2013 05:51:20 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> <50E5DAA2.9050600@alum.mit.edu> <01da01cdef7e$b424c9c0$1c6e5d40$@cisco.com> <50EF566D.3010809@alum.mit.edu> In-Reply-To: <50EF566D.3010809@alum.mit.edu> Date: Thu, 10 Jan 2013 21:51:19 -0800 Message-ID: <02e201cdefbf$ae035b60$0a0a1220$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAJlqPoIAbYfQUUCTNZkeAHzz35sAnKmFKuX4lsr4A== Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 05:51:32 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, January 10, 2013 4:02 PM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? > > On 1/10/13 5:06 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Thursday, January 03, 2013 11:23 AM > >> To: Dan Wing > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it > multiplex? > >> > >> I'm totally lost! > >> I looked back, and count 43 messages in this thread. > >> At this point I no longer understand the question(s), or what if > >> anything has been answered. > >> > >> Can we start over? > >> Sort out what the questions are, and then discuss whether we have > >> answers to them? > >> (Preferably in separate, well identified, threads.) > >> > >> I *think* Harald originally asserted that DTLS/SCTP *can* already be > >> multiplexed with SRTP audio and video streams. > > > > Yes, it can. > > > > An UDP packet is either a STUN packet (for ICE connectivity checks), > > DTLS, or SRTP. This is depicted in Section 5.1.2 of RFC5764: > > > > +----------------+ > > | 127 < B < 192 -+--> forward to RTP > > | | > > packet --> | 19 < B < 64 -+--> forward to DTLS > > | | > > | B < 2 -+--> forward to STUN > > +----------------+ > > > > A DTLS packet containing application_data is handed to the SCTP stack. > > > > As I have mentioned previously, I am concerned with sending both > > realtime interactive audio/video and non-realtime data over the same > > UDP 5-tuple, because it becomes difficult (or impossible) to apply QoS > > to differentiate those very different flows. If everyone always had > > adequate bandwidth, that concern would vanish. But the industry has > > never been able to stay ahead of the bandwidth curve. > > This is all about policy, not mechanism. It seems that some people want > to use this mechanism and think it will be good for them. Perhaps there > can be a section in some draft on this subject that points out your > concern and recommends that people consider carefully what they > multiplex on the same 5-tuple. > > Similar arguments may apply to bundling audio and video onto the same 5- > tuple. I have been told there is a 3GPP document that might be worth citing on that point. I'll get a pointer soon. I expect there is a long-standing RFC on that point, too, but I don't know of one. > >> And so he was asking > >> *how* this could be specified in SDP. (E.g. Does "bundle" support > >> it?) > > > > We need a way for SDP to signal: > > 1. the UDP port for SCTP. This feels like an SDP media ("m") line > to me. > > 2. SCTP native (native SCTP over IPv6 should be tenable, whereas > > native SCTP over IPv4 is pretty much untenable), > > 3. the data carried over each SCTP port (e.g., port NNN for XMPP, > > port NNNN for file sharing, port NNNNN for screen sharing, and so on). > > This feels like an SDP media ("m") line to me. > > I don't disagree with any of your points, but you have missed the point > I was making. > > Everything you list applies for SCTP on its own 5-tuple. But then there > is the question of how to describe how this shares a 5-tuple with some > audio and video streams. (1), from my list, is the UDP port. This could be the same UDP port as the audio/video media. > The current candidates for representing the > bundling of audio and video are the bundle draft and the mmt draft. > Neither of these currently supports including DTLS/SCTP with audio or > video. So if bundling in the SCTP is a requirement, then both bundle and > mmt should be extended cover it if they are to remain in the running. Yep. > A *native* SCTP session (directly over IPv*) runs on a 5-tuple, > including the *SCTP* ports at each end. So the SDP for that needs to > specify a port. > > ISTM that in this case the port field on the m-line > would signify the SCTP port. And this is what draft-ietf-mmusic-sctp-sdp > says. > > A DTLS/SCTP session requires a 7-tuple, including both an SCTP port and > a UDP port at each end. So the SDP for that needs to specify both an > SCTP port and a UDP port. Only one of those can be in the port field of > the m-line. (Which one that should be can be argued either way.) draft- > ietf-mmusic-sctp-sdp puts the UDP port in the m-line, and has no way to > specify the SCTP port. (It has an open issue about that. > Presumably it is either defaulted or must go in an attribute.) That's a good summary of the current state of the art. > > I don't think we can use media lines for both (1) and (3), so perhaps > > bundling is the answer. I don't know. > > Even *with* bundling the problem remains. But I agree that if you want > to run SCTP on two or more SCTP ports over the same UDP port, then > bundle is one way to do it. Each of the bundled m-lines would have to > specify the SCTP port, presumably as an attribute. > > >> Along the way, a question came up of how many DTLS/SCTP connections > >> could be multiplexed with each other and with SRTP media. I think > >> Harald assumed only one (and assumed there is only a need for one.) > >> But reasons for more have been discussed. I suggested that it appears > >> that multiple should be supportable, each with a different SCTP port. > >> > >> I think Dan raised some additional issues related to multipath > support. > > > > SCTP can support multipath, so we need to decide if we allow SCTP to > > do its own multipath, or if we require ICE to first validate a (new) > > path before SCTP can try to do its multipath. > > This is outside my area of expertise. > > > The same question and issues exist for multipath RTP > > (draft-singh-avtcore-mprtp) and how multipath RTP should split its > > functions between ICE, ICE extensions, and SDP. I know that multipath > > RTP is not a working group document, but it might be a good basis for > > analyzing multipath SCTP and reaching a conclusion on multipath SCTP > > that makes sense for both multipath SCTP and multipath RTP (and > > presumably multipath TCP, RFC6182 and its related documents). > > If you want to multiplex SCTP and RTP on the same connection, and you > are going to make SCTP multipath work for that, then why would you not > just do RTP over an SCTP channel??? Then you don't need to reinvent how > to multipath for RTP. I guess to support remote endpoints that lack SCTP, yet want to do multipath RTP. -d > Thanks, > Paul > > > -d > > > > > >> Thanks, > >> Paul > >> > >> On 1/2/13 10:32 PM, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Tuesday, December 11, 2012 11:17 AM > >>>> To: Dan Wing > >>>> Cc: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >>>> > >>>> Hi Dan, > >>>> > >>>> Comments inline > >>>> > >>>> On 12/11/12 1:53 PM, Dan Wing wrote: > >>>>>> -----Original Message----- > >>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>>>> Behalf Of Paul Kyzivat > >>>>>> Sent: Tuesday, December 11, 2012 7:43 AM > >>>>>> To: mmusic@ietf.org > >>>>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >>>>>> > >>>>>> More inline. > >>>>>> > >>>>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: > >>>>>>> Hi Paul, > >>>>>>> > >>>>>>> see in line! > >>>>>>> > >>>>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >>>>>>>> Commenting on a different point > >>>>>>>> > >>>>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >>>>>>>> > >>>>>>>>> The interesting difference is that the multiplexing between > >>>>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP > >>>>>>>>> traffic is not carried in SSRCs, which means: > >>>>>>>>> > >>>>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which > >>>>>>>>> may have multiple associations, as you state below); you can't > >>>>>>>>> have multiple lines with proto DTLS/SCTP in a bundle. > >>>>>>>> > >>>>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run > >>>>>>>> directly over IP. It has its own notion of port used to demux > >>>>>>>> multiple SCTP associations over the same IP address. > >>>>>>>> > >>>>>>>> I presume that that same mechanism is still there when SCTP is > >>>>>>>> run over DTLS over UDP. > >>>>>>>> > >>>>>>>> So, the traffic coming over DTLS must first be demuxed into RTP > >>>>>>>> traffic and SCTP traffic. > >>>>>>> based on the current stack the SCTP traffic is the only traffic > >>>>>>> that runs directly over the DTLS stack. > >>>>>> > >>>>>> Yes, that is what I thought. But Harald has been asking about > >>>>>> multiplexing this with RTP traffic. (Actually I think it would be > >>>>>> DTLS/SRTP traffic that it would be multiplexed with.) > >>>>>> > >>>>>>> What I am trying to do is to include the Randell Jesup (I am > >>>>>>> including him in CC as I am not sure he is subscribed to this > >>>>>>> mailing list) suggestion to give the possibility to have > >>>>>>> multiple SCTP > >>>>>>> *associations* running on top of the same DTLS session and of > >>>>>>> course providing a way to signal it in SDP. > >>>>>> > >>>>>> IIUC, SCTP (having been designed as a transport layer protocol) > >>>>>> defines its own notion of port, and has fields in its protocol to > >>>>>> carry the local and remote port number. Presumably those fields > >>>>>> are still there when run over UDP or DTLS. So it should be > >>>>>> possible to support multiple SCTP associations over the same DTLS > >>>>>> connection, each distinguished by its own port pair. > >>>>> > >>>>> Yes, SCTP has its own notion of ports. How this works when SCTP is > >>>>> carried over UDP is not quite clear, especially because SCTP > >>>>> assumes a NAPT will not rewrite the SCTP port number (SCTP > >>>>> endeavors to make such port rewriting difficult). But of course a > >>>>> NAPT (and the MAP > >>>>> techniques) rewrite UDP port numbers. I believe SCTP would only be > >>>>> able to successfully convey its UDP port numbers for a device that > >>>>> is not behind a NAT (that is, a server sitting directly on the > >>>>> Internet, rather than a remote peer that is behind a NAT). > >>>>> Creative use of PCP, NAT-PMP, or UPnP IGD would improve that > >>>>> situation in the > >> future. > >>>> > >>>> I find what you say above confusing. > >>>> > >>>> SCTP running naked over IP would still have its own ports. > >>>> If that ran over a path with a NAPT, then I could see why the NAPT > >>>> might want to do the same as it does with UDP and TCP, and so > >>>> replace addr/port pairs to minimize addr usage. (That's if the NAPT > >>>> supported SCTP at all - I gather most don't.) > >>> > >>> As I mentioned earlier, SCTP does not allow its source port number > >>> to be changed. > >>> > >>>> But with SCTP over DTLS over UDP, there is a UDP port, and then > >>>> presumably a separate SCTP port carried in the SCTP protocol within > >>>> the UDP message. > >>> > >>> Yep, I assume that is how it works. Effectively, UDP is just used > >>> to tunnel the SCTP. > >>> > >>>> An NAPT on the path would presumably be messing with the UDP port. > >>>> Given use of DTLS, the NAPT won't even be able to tell that SCTP is > >>>> being used, much less mess with the SCTP port. > >>>> > >>>>>> That of course depends on having a signaling mechanism to set it > >> up. > >>>>> > >>>>> After the initial SCTP association is created, SCTP could be > >>>>> allowed to do its own thing (that is, chose to find and use other > ports). > >>>> > >>>> Here you are talking about finding and using other UDP addr/port > >> pairs? > >>> > >>> No, I was referring to the SCTP ports. > >>> > >>> -d > >>> > >>> > >>>> That is explicitly excluded in the DTLS/SCTP mapping. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> SCTP's behavior in this regard is similar to MPRTP (multipath > >>>>> RTP), but of course they are not identical. > >>>>> > >>>>>>> to be clear: at moment WebRTC allows only one SCTP association > >>>>>>> per PC, so this is something that would be nice to define just > >>>>>>> to be ready for the future. > >>>>>> > >>>>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP > >>>>>> mechanism shouldn't be limited by the constraints of WebRTC. It > >>>>>> would be very difficult to define the SDP so that it was > >>>>>> impossible to set up multiple SCTP associations over different 5- > tuples. > >>>>>> > >>>>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP > >>>>>>>> traffic can be demuxed based on SCTP port. And once the traffic > >>>>>>>> for a single SCTP port is identified, it can be demuxed based > >>>>>>>> on stream > >>>> number. > >>>>>>>> > >>>>>>>> Representing this in SDP is a challenge. Some variant of the > >>>>>>>> bundle proposal might allow bundling together several RTP > >>>>>>>> m-lines and some DTLS/SCTP m-lines. This would require a > >>>>>>>> mechanism for specifying the SCTP port number - already an open > >>>>>>>> issue (#3) in draft-ietf-mmusic-sctp-sdp-02. > >>>>>>> I agree that it is a challange how then to bundle everything > >>>>>>> together > >>>>>> > >>>>>> But it is a challenge that needs to be tackled if we are to > >>>>>> realize Harald's dream. > >>>>> > >>>>> -d > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >>> > >>> > > > > From gonzalo.camarillo@ericsson.com Fri Jan 11 03:28:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BDF21F870E for ; Fri, 11 Jan 2013 03:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XEN6fhEOVR1 for ; Fri, 11 Jan 2013 03:28:00 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9706E21F868F for ; Fri, 11 Jan 2013 03:27:59 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-66-50eff73d077e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2B.BE.32353.D37FFE05; Fri, 11 Jan 2013 12:27:58 +0100 (CET) Received: from [131.160.36.91] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 11 Jan 2013 12:27:57 +0100 Message-ID: <50EFF73D.2060105@ericsson.com> Date: Fri, 11 Jan 2013 13:27:57 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvja7d9/cBBtdes1lMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYeP3mQuOCBacWbpZvYGxhcCXYycHBICJhI31qxigbDFJC7c W8/WxcjFISRwklHi3v+3TBDOakaJn7sXsHYxcnDwCmhLrH5XBtLAIqAq8ev9YTYQm03AQmLL rftgg0QFoiTeX21iBrF5BQQlTs58AhYXEZCR2LtpM1hcWEBfYvaiT8wQiyUlFk3rBKthFtCT mHK1hRHClpfY/nYOWI0Q0Nrlz1pYJjDyz0IydhaSlllIWhYwMq9iZM9NzMxJLzffxAgMp4Nb fhvsYNx0X+wQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBW3Uz9vmPF1 9+TMti+lk7IWL9+by+zlvG95QH9tplXJlxULuVXjHDVOd1+70vU59KhuvI78FhG7jYv9Nq6r XdEf1/q4Kc/3idFiti2ctQxbNFvO/94azx+aU39+bdnXzskfE5MXbN7AzRXCFv1ad54cW2GU ug//uUqrwFNuhVUsD5ducw7oUmIpzkg01GIuKk4EAL4Ise71AQAA Subject: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 11:28:03 -0000 Hi, I just got a publication request for the following draft: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 Please, find below my AD review. Cheers, Gonzalo draft-ietf-mmusic-sdp-cs-16: Page 10: remove the indentation of the following paragraph. Indented paragraphs are typically used to provide clarifications while this one contains normative language: Note that and/or MUST NOT be omitted when unknown since this would violate basic syntax of SDP [RFC4566]. In such cases, they MUST be set to a "-". Section 5.2.3.1 provides a "format" for the cs-correlation attribute. However, its ABNF formal syntax is in Section 5.7. So, why does Section 5.2.3.1 also contain a syntax for the attribute... and what type of syntax is that? Page 14: the text says: To mitigate this problem implementations should consider only some of the rightmost digits from the E.164 Can we provide a more concrete advice (or at least some discussion) on the number of digits to consider? Page 15: we define how to encode a binary value in hexadecimal format and represent it as a two-digit ASCII value. Can we point to an existing specification that defines how to do that instead of specifying it inline? Page 17: the text says: Implementations are advised to select a number of DTMF digits that provide enough assurance that the call is related, but on the other hand do not prolong the bearer setup time unnecessarily. Can we provide a more concrete recommendation? Page 17: Section 5.2.3.4 specifies what to do when the correlation fails. However, that is described in general in Section 5.3.3. Why don't we move all the statements about how to decide whether the sessions are correlated to Section 5.3.3? Now, the following statement contradicts what Section 5.3.3 says, for example: the passive side SHOULD treat the circuit-switched bearer as not correlated to the ongoing session. The indented text right after the statement above talks about suppressing alerting. Such a supression is applicable to any session, not only those that are correlated using DTMF tones. So, we could also move that discussion to Section 5.3.3. Section 5.5: rephrase the following sentence (possibly splitting it into more than one sentence) so that it is clearer: Note that this may result in the recipient of the initial Offer in rejecting the Offer if the recipient of the Offer is not aware of its own E.164 number, and thus concluding that it will not be possible to establish a circuit-switched bearer since neither party is aware of their E.164 number. From gonzalo.camarillo@ericsson.com Fri Jan 11 03:50:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB70721F87DC for ; Fri, 11 Jan 2013 03:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlP+jHz-UoP5 for ; Fri, 11 Jan 2013 03:50:47 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8084C21F87B6 for ; Fri, 11 Jan 2013 03:50:46 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-db-50effc942f9b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CD.28.10459.49CFFE05; Fri, 11 Jan 2013 12:50:45 +0100 (CET) Received: from [131.160.36.91] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 11 Jan 2013 12:50:44 +0100 Message-ID: <50EFFC93.70406@ericsson.com> Date: Fri, 11 Jan 2013 13:50:43 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvje7UP+8DDE584LKYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mg4fvclccEC04szSzewNjC8Euhg5OCQETCR+TPbvYuQEMsUk Ltxbz9bFyMUhJHCSUeL91GZ2CGc1o8SZx3+ZQRp4BTQlTvSwgjSwCKhKbL74iQXEZhOwkNhy 6z6YLSoQJfH+ahMziM0rIChxcuYTsLiIgIzE3k2bweLCAvoSsxd9YoZYLCmxaFonWA2zgJ7E lKstjBC2vMT2t3PAaoQEtCWWP2thmcDIPwvJ2FlIWmYhaVnAyLyKkT03MTMnvdxwEyMwmA5u +a27g/HUOZFDjNIcLErivGGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPZXmHhGv3KY ekhu5b7ckjlfLtQK1j9xZavdt/DTrh+bgldmpfEnH/knOuHvDlfmp02J035+tUs88vLTVp2e uLeH8p8WXbl30jTBbFvM2+UH7pnenX99vje3YXh7Yl6i2YfGbQ1/9gtWxKT9d2O4KaVR2ry+ fsX6S5oq3EZ7kkzfd2wU2/haMFiJpTgj0VCLuag4EQCAqymU9AEAAA== Subject: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 11:50:48 -0000 Hi, I just got a publication request for the following draft: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 Please, find below my AD review. Cheers, Gonzalo draft-ietf-mmusic-sdp-cs-16: Page 10: remove the indentation of the following paragraph. Indented paragraphs are typically used to provide clarifications while this one contains normative language: Note that and/or MUST NOT be omitted when unknown since this would violate basic syntax of SDP [RFC4566]. In such cases, they MUST be set to a "-". Section 5.2.3.1 provides a "format" for the cs-correlation attribute. However, its ABNF formal syntax is in Section 5.7. So, why does Section 5.2.3.1 also contain a syntax for the attribute... and what type of syntax is that? Page 14: the text says: To mitigate this problem implementations should consider only some of the rightmost digits from the E.164 Can we provide a more concrete advice (or at least some discussion) on the number of digits to consider? Page 15: we define how to encode a binary value in hexadecimal format and represent it as a two-digit ASCII value. Can we point to an existing specification that defines how to do that instead of specifying it inline? Page 17: the text says: Implementations are advised to select a number of DTMF digits that provide enough assurance that the call is related, but on the other hand do not prolong the bearer setup time unnecessarily. Can we provide a more concrete recommendation? Page 17: Section 5.2.3.4 specifies what to do when the correlation fails. However, that is described in general in Section 5.3.3. Why don't we move all the statements about how to decide whether the sessions are correlated to Section 5.3.3? Now, the following statement contradicts what Section 5.3.3 says, for example: the passive side SHOULD treat the circuit-switched bearer as not correlated to the ongoing session. The indented text right after the statement above talks about suppressing alerting. Such a supression is applicable to any session, not only those that are correlated using DTMF tones. So, we could also move that discussion to Section 5.3.3. Section 5.5: rephrase the following sentence (possibly splitting it into more than one sentence) so that it is clearer: Note that this may result in the recipient of the initial Offer in rejecting the Offer if the recipient of the Offer is not aware of its own E.164 number, and thus concluding that it will not be possible to establish a circuit-switched bearer since neither party is aware of their E.164 number. From gonzalo.camarillo@ericsson.com Fri Jan 11 03:52:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5921F86A2 for ; Fri, 11 Jan 2013 03:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX87OoGpmeSt for ; Fri, 11 Jan 2013 03:52:18 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 99EBB21F866D for ; Fri, 11 Jan 2013 03:52:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-4f-50effceeda21 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CA.68.10459.EECFFE05; Fri, 11 Jan 2013 12:52:15 +0100 (CET) Received: from [131.160.36.91] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 11 Jan 2013 12:52:14 +0100 Message-ID: <50EFFCEE.1080601@ericsson.com> Date: Fri, 11 Jan 2013 13:52:14 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic References: <50EFFC93.70406@ericsson.com> In-Reply-To: <50EFFC93.70406@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje77P+8DDM4/5bKYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4MmYteMResEayYsXRE+wNjKeEuxg5OSQETCTe3+5nhbDFJC7c W8/WxcjFISRwklHi9e4DUM5qRolXP/4zg1TxCmhLrN5/hgnEZhFQlZh29wsbiM0mYCGx5dZ9 FhBbVCBK4v3VJqh6QYmTM5+AxUUEZCT2btoMFhcWsJFYv34FkM0BtEBTYvaaApAwp4CWxPkT k9khDpKUWDStE6yVWUBPYsrVFkYIW15i+9s5YGOEgM5Z/qyFZQKj4Cwk22YhaZmFpGUBI/Mq RvbcxMyc9HLDTYzA8Du45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwOhhxrdRgSf9vUxR5nO3jX0z25/MU9r/3mJXzeQnx4qkn+cuLw0xv2CbmqD2wuii YiaLzdXvjxrTbvd/Dra4tfLqm0lbmJNk5P51CzrPWuT7cXla4AbOD7blhyTPCHvmazzatNHc xfenoGXSpBMlRw9Nnnj/v4OVgPpXhj1XLj3kSZ3v+dPrYY8SS3FGoqEWc1FxIgBOvKbBDQIA AA== Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 11:52:20 -0000 Sorry for the duplication. I had an email problem when sending the email below and it seems to have made it to the list twice. Gonzalo On 11/01/2013 1:50 PM, Gonzalo Camarillo wrote: > Hi, > > I just got a publication request for the following draft: > > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 > > Please, find below my AD review. > > Cheers, > > Gonzalo > > > draft-ietf-mmusic-sdp-cs-16: > > Page 10: remove the indentation of the following paragraph. Indented > paragraphs are typically used to provide clarifications while this one > contains normative language: > > Note that and/or MUST NOT be > omitted when unknown since this would violate basic syntax of SDP > [RFC4566]. In such cases, they MUST be set to a "-". > > Section 5.2.3.1 provides a "format" for the cs-correlation attribute. > However, its ABNF formal syntax is in Section 5.7. So, why does Section > 5.2.3.1 also contain a syntax for the attribute... and what type of > syntax is that? > > Page 14: the text says: > > To mitigate this problem implementations > should consider only some of the rightmost digits from the E.164 > > Can we provide a more concrete advice (or at least some discussion) on > the number of digits to consider? > > Page 15: we define how to encode a binary value in hexadecimal format > and represent it as a two-digit ASCII value. Can we point to an existing > specification that defines how to do that instead of specifying it inline? > > Page 17: the text says: > > Implementations are advised to select a number of DTMF digits that > provide enough assurance that the call is related, but on the > other hand do not prolong the bearer setup time unnecessarily. > > Can we provide a more concrete recommendation? > > Page 17: Section 5.2.3.4 specifies what to do when the correlation > fails. However, that is described in general in Section 5.3.3. Why don't > we move all the statements about how to decide whether the sessions are > correlated to Section 5.3.3? Now, the following statement contradicts > what Section 5.3.3 says, for example: > > the passive side > SHOULD treat the circuit-switched bearer as not correlated to the > ongoing session. > > The indented text right after the statement above talks about > suppressing alerting. Such a supression is applicable to any session, > not only those that are correlated using DTMF tones. So, we could also > move that discussion to Section 5.3.3. > > Section 5.5: rephrase the following sentence (possibly splitting it into > more than one sentence) so that it is clearer: > > Note that this may result in the recipient of the initial Offer in > rejecting the Offer if the recipient of the Offer is not aware of > its own E.164 number, and thus concluding that it will not be > possible to establish a circuit-switched bearer since neither > party is aware of their E.164 number. > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > From keith.drage@alcatel-lucent.com Fri Jan 11 04:33:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB321F88B5 for ; Fri, 11 Jan 2013 04:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.649 X-Spam-Level: X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA4Zm2rjwefd for ; Fri, 11 Jan 2013 04:33:54 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7421F881A for ; Fri, 11 Jan 2013 04:33:53 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0BCXosK002526 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Jan 2013 13:33:50 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 11 Jan 2013 13:33:50 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "mmusic@ietf.org" Date: Fri, 11 Jan 2013 13:33:48 +0100 Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: Ac3vY2b8mQzP5R7vThKdh4cDjDdB6wAktUlw Message-ID: References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> In-Reply-To: <50EF0D77.9040000@alum.mit.edu> 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.69 on 155.132.188.84 Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 12:33:55 -0000 At least to attempt to answer the history question here relating to multica= st, my understanding is that the authors of RFC 2543 (the original SIP), di= d make attempts to cover multicast, but this was abandoned (although existi= ng RFC 2543 material was not removed) when RFC 3261 was produced. RFC 3264 was a new document at the time RFC 3261 was produced and therefore= my understanding was that it was designed to cover unicast only, because S= IP, as defined in RFC 3261, was the user of offer/answer. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: 10 January 2013 18:51 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer >=20 > To the best of my memory the issue Harald has raised is a new one. I > don't think it has never been discussed on any of the lists I have been > following since 2002. >=20 > More inline. >=20 > On 1/9/13 6:46 PM, Emil Ivov wrote: > > > > > > On 09.01.13, 23:52, Harald Alvestrand wrote: > >> On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote: > >>> Please see inline. > >>> > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>> Behalf Of Harald Alvestrand > >>>> Sent: Wednesday, January 09, 2013 11:25 AM > >>>> To: mmusic@ietf.org > >>>> Subject: [MMUSIC] Query: payload type collision with offer/answer > >>>> > >>>> Hello, > >>>> I have encountered an issue, and I'm not sure it's an issue or not. > SDP > >>>> wisdom is sought. > >>>> > >>>> Suppose two entities exchange the following offer/answer: > >>>> > >>>> offer from X: > >>>> > >>>> m=3Dvideo 97 > >>>> a=3Drtpmap:97 foo > >>>> > >>>> answer from Y: > >>>> > >>>> m=3Dvideo 98 > >>>> a=3Drtpmap:98 foo > >>>> > >>>> It's clear from RFC 3264 that now X must send codec foo with payload > >>>> type 98, and Y must send codec foo with payload type 97. That's not > the > >>>> question. > >>>> > >>>> But suppose these are the offer and answer: > >>>> > >>>> offer from X: > >>>> > >>>> m=3Dvideo 97 98 > >>>> a=3Drtpmap:97 foo > >>>> a=3Drtpmap:98 bar > >>>> > >>>> answer from Y: > >>>> > >>>> m=3Dvideo 97 98 > >>>> a=3Drtpmap:97 bar > >>>> a=3Drtpmap:98 foo > >>>> > >>>> That is, the payload types collide. > >>>> > >>>> It would be possible to write code so that X sends foo with 98 and > bar > >>>> with 97, while Y sends foo with 97 and bar with 98. But is it > >>> conformant > >>>> with the specs to do so? > >>>> > >>>> And if this has a clear answer - which paragraph of which RFC makes > >>> this > >>>> clear? > >>>> (Yes, this discussion is triggered from a real world problem.) > >>> > >>> It is recommended to avoid such mismatches when possible, but doing s= o > >>> may not always be possible. The examples you mention are conformant. > >>> The following text from section 5.1 addresses this: > >>> > >>> For sendrecv RTP > >>> streams, the payload type numbers indicate the value of the payload > >>> type field the offerer expects to receive, and would prefer to send. > >>> However, for sendonly and sendrecv streams, the answer might indicate > >>> different payload type numbers for the same codecs, in which case, > >>> the offerer MUST send with the payload type numbers from the answer. > >>> > >>> Different payload type numbers may be needed in each direction > >>> because of interoperability concerns with H.323. > >> I was reading that text, and it clearly says which ones to use if the > >> payload types are different, but I don't think they clearly address th= e > >> situation with using the same payload type for two different codecs in > >> different directions. > >> > >> In a multicast or transport relay scenario, this would clearly be > >> untenable, since third parties would not be able to send streams that > >> would be interpreted correctly by the two conflicting endpoints, but i= n > >> a two-party conversation, it's possible to make this work. > >> I just don't know if it's worth the effort to make it so. >=20 > You are right that these arguments work differently for unicast and > multicast. I don't recall (I think it was before my time) how much > thought was given to multicast in 3264. (It doesn't seem to be very > much. And I think the O/A discussions in new additions to SDP rarely > consider it at all.) >=20 > > Well there's also section 8.3.2 in 3264. The section is about updating > > offers but it seems like the text explicitly prohibits remapping payloa= d > > types in any scenarios: > > > > However, in the > > case of RTP, the mapping from a particular dynamic payload type > > number to a particular codec within that media stream MUST NOT > change > > for the duration of a session. For example, if A generates an offe= r > > with G.711 assigned to dynamic payload type number 46, payload type > > number 46 MUST refer to G.711 from that point forward in any offers > > or answers for that media stream within the session. However, it i= s > > acceptable for multiple payload type numbers to be mapped to the > same > > codec, so that an updated offer could also use payload type number > 72 > > for G.711. >=20 > The language above is underspecified. >=20 > It is my impression that the intent of this language was to ensure there > is no ambiguity in the meaning of a payload type. Since the exchange of > the SDP is not synchronized with the flow of RTP, if you were to send a > new SDP that changed the mapping for a payload type, then the result > would be almost certainly to interpret some media packets according to > the wrong mapping. >=20 > But this argument is only about packets flowing in one direction. It > isn't a valid argument for requiring the payload types to be consistent > in the two directions. And its not clear to me that it even intended > that this language apply to both directions. It could be clarified as > follows: >=20 > ... For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers ***by A*** for that media stream within the session. ... >=20 > Interpreting it to apply to both directions brings it in conflict with > the language elsewhere that permits it to be different in the two > directions. >=20 > The use of different mappings in each direction has been discussed over > the years, though I couldn't point you to where. IIRC one of the reasons > had to do with gatewaying to other protocols. But I can't offer any > details. >=20 > Bottom line: IMO, in the weird case Harald described X ought to follow > Postel's Law and accept the answer from Y. But for the same reason I > would strongly discourage implementations from acting as Y did. >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Fri Jan 11 04:47:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7042121F877B for ; Fri, 11 Jan 2013 04:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgZF43t6apAR for ; Fri, 11 Jan 2013 04:47:16 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2937D21F8763 for ; Fri, 11 Jan 2013 04:47:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0CAD639E2BE for ; Fri, 11 Jan 2013 13:47:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFO15BpRWFmG for ; Fri, 11 Jan 2013 13:47:12 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5EFCC39E241 for ; Fri, 11 Jan 2013 13:47:12 +0100 (CET) Message-ID: <50F009CE.9060903@alvestrand.no> Date: Fri, 11 Jan 2013 13:47:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> In-Reply-To: <50EF0D77.9040000@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 12:47:17 -0000 On 01/10/2013 07:50 PM, Paul Kyzivat wrote: > >> Well there's also section 8.3.2 in 3264. The section is about updating >> offers but it seems like the text explicitly prohibits remapping payload >> types in any scenarios: >> >> However, in the >> case of RTP, the mapping from a particular dynamic payload type >> number to a particular codec within that media stream MUST NOT >> change >> for the duration of a session. For example, if A generates an offer >> with G.711 assigned to dynamic payload type number 46, payload type >> number 46 MUST refer to G.711 from that point forward in any offers >> or answers for that media stream within the session. However, it is >> acceptable for multiple payload type numbers to be mapped to the >> same >> codec, so that an updated offer could also use payload type >> number 72 >> for G.711. > > The language above is underspecified. > > It is my impression that the intent of this language was to ensure > there is no ambiguity in the meaning of a payload type. Since the > exchange of the SDP is not synchronized with the flow of RTP, if you > were to send a new SDP that changed the mapping for a payload type, > then the result would be almost certainly to interpret some media > packets according to the wrong mapping. > > But this argument is only about packets flowing in one direction. It > isn't a valid argument for requiring the payload types to be > consistent in the two directions. And its not clear to me that it even > intended that this language apply to both directions. It could be > clarified as follows: > > ... For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers ***by A*** for that media stream within the session. ... > > Interpreting it to apply to both directions brings it in conflict with > the language elsewhere that permits it to be different in the two > directions. More than one number for one codec is explicitly permitted. More than one codec for one number in a single direction is clearly impossible. More than one codec for one number in a single RTP session..... that's the question. If one were to go with textual analysis, this would hinge on the meaning of "for that media stream" - which again hinges on whether a media stream is unidirectional or bidirectional. RFC 3264's definition: Media Stream: From RTSP [8], a media stream is a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. In SDP, a media stream is described by an "m=" line and its associated attributes. which points back to RFC 2326: (Media) stream: A single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a source within an RTP session. This is equivalent to the definition of a DSM-CC stream([5]). So if we believe these definitions, there's no prohibition on reusing the payload type. Definitely nice to clarify in a 3264bis. > > The use of different mappings in each direction has been discussed > over the years, though I couldn't point you to where. IIRC one of the > reasons had to do with gatewaying to other protocols. But I can't > offer any details. > > Bottom line: IMO, in the weird case Harald described X ought to follow > Postel's Law and accept the answer from Y. But for the same reason I > would strongly discourage implementations from acting as Y did. > Seems like a conclusion. From christer.holmberg@ericsson.com Fri Jan 11 05:01:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93A021F88E6 for ; Fri, 11 Jan 2013 05:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szxIYtWinHik for ; Fri, 11 Jan 2013 05:01:04 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1566C21F8877 for ; Fri, 11 Jan 2013 05:01:03 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-6f-50f00d0e7c98 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E9.BD.32353.E0D00F05; Fri, 11 Jan 2013 14:01:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.11]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 14:01:02 +0100 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: AQHN7p8Mjyk6kI/FLUWFcqXIpB6gmphBmrXl///+PoCAAT/GgIABLNAAgAAUJmA= Date: Fri, 11 Jan 2013 13:01:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B09BCBD@ESESSMB209.ericsson.se> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> <50F009CE.9060903@alvestrand.no> In-Reply-To: <50F009CE.9060903@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjS4/74cAgyM7OCyO9XWxWUxd/pjF gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4tPghc8F55Yrfky+xNzDukO5i5OSQEDCR 2Hr0JxOELSZx4d56ti5GLg4hgUOMEjO/vGCFcBYzSrya8guoioODTcBCovufNkiDiECwxPJP 28GahQVcJfb+f8UMEXeTmHrmDRuE7Sfx8eh5FhCbRUBVoql3GTuIzSvgLbFmwgoWiPlXGCXW tMwCG8QpoCsxt2MqmM0IdNH3U2vAbGYBcYlbT+ZDXSogsWTPeWYIW1Ti5eN/rBC2osTOs+3M EPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15u vokRGA0Ht/w22MG46b7YIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgr E5x5tzetUbS0CAhaZWuzXeVsIMvRHjO9iwph6sst/M9U1AUoH4+e1+1yYsm/in8crf0CryVO NIu65oVnpm6PDhTOnrkzK+DcZPmQ/4InO8JebI81vPUrpkpSnKdEfcMPs7n3j99yk6tkU2vR UzPcseb2bedztrW/lywLOSpge2Oj/ireVUosxRmJhlrMRcWJAIQQsbJUAgAA Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 13:01:05 -0000 Hi, My understanding of the section 8.3.2 is that the mapping must not change P= ER DIRECTION, and the text "in any offers or answers" refers to a particula= r participant. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 11. tammikuuta 2013 14:47 To: mmusic@ietf.org Subject: Re: [MMUSIC] Query: payload type collision with offer/answer On 01/10/2013 07:50 PM, Paul Kyzivat wrote: > >> Well there's also section 8.3.2 in 3264. The section is about=20 >> updating offers but it seems like the text explicitly prohibits=20 >> remapping payload types in any scenarios: >> >> However, in the >> case of RTP, the mapping from a particular dynamic payload type >> number to a particular codec within that media stream MUST NOT=20 >> change >> for the duration of a session. For example, if A generates an offer >> with G.711 assigned to dynamic payload type number 46, payload type >> number 46 MUST refer to G.711 from that point forward in any offers >> or answers for that media stream within the session. However, it is >> acceptable for multiple payload type numbers to be mapped to the=20 >> same >> codec, so that an updated offer could also use payload type=20 >> number 72 >> for G.711. > > The language above is underspecified. > > It is my impression that the intent of this language was to ensure=20 > there is no ambiguity in the meaning of a payload type. Since the=20 > exchange of the SDP is not synchronized with the flow of RTP, if you=20 > were to send a new SDP that changed the mapping for a payload type,=20 > then the result would be almost certainly to interpret some media=20 > packets according to the wrong mapping. > > But this argument is only about packets flowing in one direction. It=20 > isn't a valid argument for requiring the payload types to be=20 > consistent in the two directions. And its not clear to me that it even=20 > intended that this language apply to both directions. It could be=20 > clarified as follows: > > ... For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers ***by A*** for that media stream within the session. ... > > Interpreting it to apply to both directions brings it in conflict with=20 > the language elsewhere that permits it to be different in the two=20 > directions. More than one number for one codec is explicitly permitted. More than one codec for one number in a single direction is clearly impossi= ble. More than one codec for one number in a single RTP session..... that's the = question. If one were to go with textual analysis, this would hinge on the meaning of= "for that media stream" - which again hinges on whether a media stream is = unidirectional or bidirectional. RFC 3264's definition: Media Stream: From RTSP [8], a media stream is a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. In SDP, a media stream is described by an "m=3D" line and its associated attributes. which points back to RFC 2326: (Media) stream: A single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a source within an RTP session. This is equivalent to the definition of a DSM-CC stream([5]). So if we believe these definitions, there's no prohibition on reusing the p= ayload type. Definitely nice to clarify in a 3264bis. > > The use of different mappings in each direction has been discussed=20 > over the years, though I couldn't point you to where. IIRC one of the=20 > reasons had to do with gatewaying to other protocols. But I can't=20 > offer any details. > > Bottom line: IMO, in the weird case Harald described X ought to follow=20 > Postel's Law and accept the answer from Y. But for the same reason I=20 > would strongly discourage implementations from acting as Y did. > Seems like a conclusion. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Fri Jan 11 05:50:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EB221F890D for ; Fri, 11 Jan 2013 05:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8jlubqtWhrb for ; Fri, 11 Jan 2013 05:50:41 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1121B21F87E3 for ; Fri, 11 Jan 2013 05:50:40 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so892763wey.1 for ; Fri, 11 Jan 2013 05:50:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=kybkuywNrgq+ZBFntvK/iJSUeJZ5heD9/zYmuBCDyeU=; b=L6qPkHtQwrZGIs58CNfbUgOgcf2vPy5ZpIK3J99Exz42NWFG372kwMCivrhHlR9eT7 5SHbgRPapcSWxMWd2SEkoiAbiIWfBzUvqf2GfkF9OYXM42jgU1NUxPIn4WiZasTqiGO8 5GRbcvMCxElzjgjf2NmnxDCFb5nYbSUZzZ8uOXe8lxrdGwpgn5u/XPLViKPwppw9e2Y4 w601QZ1eC+QSElWvKpqRL9NHeRZukGK1P4G/xDiHQXBuoavy2jY45ub/ac1QvDb76Eqc lR6T5y/m9V/YtMGR5U0HFAt2kll3xEFxvFYLGoxhcdi8x/Uy3s3BdtksuIphKFT1208L dSRg== X-Received: by 10.180.73.80 with SMTP id j16mr15479571wiv.5.1357912239528; Fri, 11 Jan 2013 05:50:39 -0800 (PST) Received: from camionet.local ([2a01:e35:2e2c:f600:257f:94b:1bb:6163]) by mx.google.com with ESMTPS id df2sm12955076wib.0.2013.01.11.05.50.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 05:50:38 -0800 (PST) Message-ID: <50F018AB.8090305@jitsi.org> Date: Fri, 11 Jan 2013 14:50:35 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> <50F009CE.9060903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B09BCBD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B09BCBD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmcR79ItRSDFLWgQRfHHo/F7Gv8wSeA16erm+63UGc9Inyx0a9NgJEKxyAbMta8vdKW5ufM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 13:50:43 -0000 On 11.01.13, 14:01, Christer Holmberg wrote: > Hi, > > My understanding of the section 8.3.2 is that the mapping must not change PER DIRECTION, and the text "in any offers or answers" refers to a particular participant. I wasn't around then so it could very well be that this was the intention. Currently however there's nothing in the text that directly supports this and it could be argued that it actually says the exact opposite thing. Or in other words: the payload type number cannot be remapped in "any offers and answers for that media stream in that session". If we want it to meant just "A's offers and answers" then it should be updated to say that. Emil > Regards, > > Christer > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: 11. tammikuuta 2013 14:47 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer > > On 01/10/2013 07:50 PM, Paul Kyzivat wrote: >> >>> Well there's also section 8.3.2 in 3264. The section is about >>> updating offers but it seems like the text explicitly prohibits >>> remapping payload types in any scenarios: >>> >>> However, in the >>> case of RTP, the mapping from a particular dynamic payload type >>> number to a particular codec within that media stream MUST NOT >>> change >>> for the duration of a session. For example, if A generates an offer >>> with G.711 assigned to dynamic payload type number 46, payload type >>> number 46 MUST refer to G.711 from that point forward in any offers >>> or answers for that media stream within the session. However, it is >>> acceptable for multiple payload type numbers to be mapped to the >>> same >>> codec, so that an updated offer could also use payload type >>> number 72 >>> for G.711. >> >> The language above is underspecified. >> >> It is my impression that the intent of this language was to ensure >> there is no ambiguity in the meaning of a payload type. Since the >> exchange of the SDP is not synchronized with the flow of RTP, if you >> were to send a new SDP that changed the mapping for a payload type, >> then the result would be almost certainly to interpret some media >> packets according to the wrong mapping. >> >> But this argument is only about packets flowing in one direction. It >> isn't a valid argument for requiring the payload types to be >> consistent in the two directions. And its not clear to me that it even >> intended that this language apply to both directions. It could be >> clarified as follows: >> >> ... For example, if A generates an offer >> with G.711 assigned to dynamic payload type number 46, payload type >> number 46 MUST refer to G.711 from that point forward in any offers >> or answers ***by A*** for that media stream within the session. ... >> >> Interpreting it to apply to both directions brings it in conflict with >> the language elsewhere that permits it to be different in the two >> directions. > More than one number for one codec is explicitly permitted. > More than one codec for one number in a single direction is clearly impossible. > More than one codec for one number in a single RTP session..... that's the question. > > If one were to go with textual analysis, this would hinge on the meaning of "for that media stream" - which again hinges on whether a media stream is unidirectional or bidirectional. > > RFC 3264's definition: > > Media Stream: From RTSP [8], a media stream is a single media > instance, e.g., an audio stream or a video stream as well as a > single whiteboard or shared application group. In SDP, a media > stream is described by an "m=" line and its associated > attributes. > > which points back to RFC 2326: > > (Media) stream: > A single media instance, e.g., an audio stream or a video > stream as well as a single whiteboard or shared application > group. When using RTP, a stream consists of all RTP and RTCP > packets created by a source within an RTP session. This is > equivalent to the definition of a DSM-CC stream([5]). > > So if we believe these definitions, there's no prohibition on reusing the payload type. > Definitely nice to clarify in a 3264bis. > >> >> The use of different mappings in each direction has been discussed >> over the years, though I couldn't point you to where. IIRC one of the >> reasons had to do with gatewaying to other protocols. But I can't >> offer any details. >> >> Bottom line: IMO, in the weird case Harald described X ought to follow >> Postel's Law and accept the answer from Y. But for the same reason I >> would strongly discourage implementations from acting as Y did. >> > Seems like a conclusion. > > _______________________________________________ > 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 > -- https://jitsi.org From christer.holmberg@ericsson.com Fri Jan 11 06:27:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F22C21F8629 for ; Fri, 11 Jan 2013 06:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNFR43N3MOgY for ; Fri, 11 Jan 2013 06:27:22 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8063E21F866D for ; Fri, 11 Jan 2013 06:27:21 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-7d-50f02148fea9 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FD.EA.32353.84120F05; Fri, 11 Jan 2013 15:27:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.11]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 15:27:20 +0100 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: AQHN7p8Mjyk6kI/FLUWFcqXIpB6gmphBmrXl///+PoCAAT/GgIABLNAAgAAUJmD///2RgIAAGoPA Date: Fri, 11 Jan 2013 14:27:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B09BE9D@ESESSMB209.ericsson.se> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> <50F009CE.9060903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B09BCBD@ESESSMB209.ericsson.se> <50F018AB.8090305@jitsi.org> In-Reply-To: <50F018AB.8090305@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja6H4ocAgwenVC3W7JzAYnGsr4vN YuryxywOzB5XJlxh9Viy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZt740sxcs0Kp4+echcwPj A4UuRg4OCQETidfXfLoYOYFMMYkL99azgdhCAocYJfp2ynQxcgHZixklep+/YAOpZxOwkOj+ pw1SIyIgL9HdtogJxGYWCJa49uAemC0s4Cqx9/8rZogaN4mpZ96wQdhREmt+TWQFsVkEVCU+ 9U4Hi/MKeEu0bZjMCLF3K5PEmh3KIDangKbEhE/tYPWMQLd9P7UGape4xK0n85kgbhaQWLLn PDOELSrx8vE/VghbUWLn2XZmiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUW kpZZSFoWMLKsYmTPTczMSS8338QIjJiDW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYyzveScL5s555bJ7dN5vUjoZaJkraqft2ZHpmSQ1LMV/cucM2dM PV35Z0Wum4Hbj2qnPZNOFjqcUTT/dvf275tmDprNNzatmmp+vvhHaW7cvbh1/hJN75OLzgW7 Ttj8PdtHYmN7749jUU8iFDXnXFa8pCmlpyb5zGHFpJvmjoU/v/rHmL44nKvEUpyRaKjFXFSc CAAFi/ZVZgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 14:27:23 -0000 Hi, >> My understanding of the section 8.3.2 is that the mapping must not chang= e PER DIRECTION, and the text "in any offers or answers" refers to a partic= ular participant. > > I wasn't around then so it could very well be that this was the intention= . Currently however there's nothing in the text that directly=20 > supports this and it could be argued that it actually says the exact oppo= site thing. Or in other words: the payload type number cannot=20 > be remapped in "any offers and answers for that media stream in that sess= ion". > > If we want it to meant just "A's offers and answers" then it should be up= dated to say that. I agree the text could be more clear. Regards, Christer > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Harald Alvestrand > Sent: 11. tammikuuta 2013 14:47 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer >=20 > On 01/10/2013 07:50 PM, Paul Kyzivat wrote: >> >>> Well there's also section 8.3.2 in 3264. The section is about=20 >>> updating offers but it seems like the text explicitly prohibits=20 >>> remapping payload types in any scenarios: >>> >>> However, in the >>> case of RTP, the mapping from a particular dynamic payload type >>> number to a particular codec within that media stream MUST NOT=20 >>> change >>> for the duration of a session. For example, if A generates an offe= r >>> with G.711 assigned to dynamic payload type number 46, payload type >>> number 46 MUST refer to G.711 from that point forward in any offers >>> or answers for that media stream within the session. However, it is >>> acceptable for multiple payload type numbers to be mapped to the=20 >>> same >>> codec, so that an updated offer could also use payload type=20 >>> number 72 >>> for G.711. >> >> The language above is underspecified. >> >> It is my impression that the intent of this language was to ensure=20 >> there is no ambiguity in the meaning of a payload type. Since the=20 >> exchange of the SDP is not synchronized with the flow of RTP, if you=20 >> were to send a new SDP that changed the mapping for a payload type,=20 >> then the result would be almost certainly to interpret some media=20 >> packets according to the wrong mapping. >> >> But this argument is only about packets flowing in one direction. It=20 >> isn't a valid argument for requiring the payload types to be=20 >> consistent in the two directions. And its not clear to me that it=20 >> even intended that this language apply to both directions. It could=20 >> be clarified as follows: >> >> ... For example, if A generates an offer >> with G.711 assigned to dynamic payload type number 46, payload type >> number 46 MUST refer to G.711 from that point forward in any offers >> or answers ***by A*** for that media stream within the session. ... >> >> Interpreting it to apply to both directions brings it in conflict=20 >> with the language elsewhere that permits it to be different in the=20 >> two directions. > More than one number for one codec is explicitly permitted. > More than one codec for one number in a single direction is clearly impos= sible. > More than one codec for one number in a single RTP session..... that's th= e question. >=20 > If one were to go with textual analysis, this would hinge on the meaning = of "for that media stream" - which again hinges on whether a media stream i= s unidirectional or bidirectional. >=20 > RFC 3264's definition: >=20 > Media Stream: From RTSP [8], a media stream is a single media > instance, e.g., an audio stream or a video stream as well as a > single whiteboard or shared application group. In SDP, a media > stream is described by an "m=3D" line and its associated > attributes. >=20 > which points back to RFC 2326: >=20 > (Media) stream: > A single media instance, e.g., an audio stream or a video > stream as well as a single whiteboard or shared application > group. When using RTP, a stream consists of all RTP and RTCP > packets created by a source within an RTP session. This is > equivalent to the definition of a DSM-CC stream([5]). >=20 > So if we believe these definitions, there's no prohibition on reusing the= payload type. > Definitely nice to clarify in a 3264bis. >=20 >> >> The use of different mappings in each direction has been discussed=20 >> over the years, though I couldn't point you to where. IIRC one of the=20 >> reasons had to do with gatewaying to other protocols. But I can't=20 >> offer any details. >> >> Bottom line: IMO, in the weird case Harald described X ought to=20 >> follow Postel's Law and accept the answer from Y. But for the same=20 >> reason I would strongly discourage implementations from acting as Y did. >> > Seems like a conclusion. >=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 >=20 -- https://jitsi.org From fandreas@cisco.com Fri Jan 11 08:22:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB021F8937 for ; Fri, 11 Jan 2013 08:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.066 X-Spam-Level: X-Spam-Status: No, score=-9.066 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXd4bo3mhTpI for ; Fri, 11 Jan 2013 08:22:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA2621F8929 for ; Fri, 11 Jan 2013 08:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=414; q=dns/txt; s=iport; t=1357921333; x=1359130933; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RuZYNOWgbSRcT4FaPL3exi4XlAo1AfE7S8H4ZrrfUds=; b=Ce9h7qyXjilpV1MP9kiggpbh1vEJw6xG6Mjgrr3FjVT8Xp+Wx9VeWGHX ZOVxuR3qWI3tYa9+GqShTxUoyfbIeHWxWhYOdOCgO3rFVCRaEQq1y6ZlM JH92/jY4G+DHGn4S9Q6C47zkVGe+MPGM2INtJSOptguNw8uHhAAF5YSVZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8IACs78FCtJXG8/2dsb2JhbABEg0e6NxZzgh4BAQEEOEABEAsYCRYPCQMCAQIBRQYNAQcBAYgVtXmRJgOIYY0qkEmDEw X-IronPort-AV: E=Sophos;i="4.84,452,1355097600"; d="scan'208";a="161431486" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jan 2013 16:22:11 +0000 Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0BGMAab017732; Fri, 11 Jan 2013 16:22:11 GMT Message-ID: <50F03C32.1020900@cisco.com> Date: Fri, 11 Jan 2013 11:22:10 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Matthew Kaufman References: <20130107173018.14035.3471.idtracker@ietfa.amsl.com> <50EB15C3.2010707@cisco.com> <50EF52DA.3030007@matthew.at> In-Reply-To: <50EF52DA.3030007@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Fwd: RTCWEB & MMUSIC WG Joint Interim Meeting, February 5-7, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:22:20 -0000 We are working on an agenda with the RTCWEB chairs - expect to see something early next week. Thanks -- Flemming On 1/10/13 6:46 PM, Matthew Kaufman wrote: > Is there yet an agenda for the upcoming MMUSIC interim or at least a > list of drafts we intend to discuss that I could review in advance? > Just feels like we're running out of days for advance flight bookings. > > Matthew Kaufman > From pkyzivat@alum.mit.edu Fri Jan 11 08:57:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4BB21F8808 for ; Fri, 11 Jan 2013 08:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i21YyJl+E3lv for ; Fri, 11 Jan 2013 08:57:05 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1176521F87CE for ; Fri, 11 Jan 2013 08:57:04 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id mbHh1k0091c6gX851gx4NR; Fri, 11 Jan 2013 16:57:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id mgx41k0013ZTu2S3jgx499; Fri, 11 Jan 2013 16:57:04 +0000 Message-ID: <50F0445E.1040401@alum.mit.edu> Date: Fri, 11 Jan 2013 11:57:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dan Wing References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> <01f801cde962$f1f6c2c0$d5e44840$@cisco.com> <50E5DAA2.9050600@alum.mit.edu> <01da01cdef7e$b424c9c0$1c6e5d40$@cisco.com> <50EF566D.3010809@alum.mit.edu> <02e201cdefbf$ae035b60$0a0a1220$@cisco.com> In-Reply-To: <02e201cdefbf$ae035b60$0a0a1220$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357923424; bh=sWe+OQkLkK8FJs6+YH6phOE3vwzkoqxvwzDDfpSupHo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AB10xp3mkSbFf6tpMzFiT/1pIvqmEXrr1YdVG5afF9Mn46CtJ2okF2DtJ+PSAt29l xQpSKeBU35n7FeSE2+xxgSMoCpKoChm5/NbZSJTvS1XRIOxCfTy3NGQN+/BlLgdhaz jbtKbtSRQGWNh+5nfWTAQRkR+DWRFMx0O82aIQUZ3emKwTY8Cmy73R+EiwmZhgIQt4 Iqzb7tLG55ZiF1iaSgBJjBHKvj4tq8Sgs2FWBE30WcmfJwwEz8D87VbCylMUpX0TP+ 2d3NENlUowA+DUYIcb/WANmb26W30/VZMdzJPZmWQxCu40Q0uG4LihM7/NEc99Q14B U/ynJoot9CQ8A== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:57:06 -0000 Commenting on one specific point... On 1/11/13 12:51 AM, Dan Wing wrote: >>> We need a way for SDP to signal: >>> 1. the UDP port for SCTP. This feels like an SDP media ("m") line >> to me. >>> 2. SCTP native (native SCTP over IPv6 should be tenable, whereas >>> native SCTP over IPv4 is pretty much untenable), >>> 3. the data carried over each SCTP port (e.g., port NNN for XMPP, >>> port NNNN for file sharing, port NNNNN for screen sharing, and so on). >>> This feels like an SDP media ("m") line to me. >> >> I don't disagree with any of your points, but you have missed the point >> I was making. >> >> Everything you list applies for SCTP on its own 5-tuple. But then there >> is the question of how to describe how this shares a 5-tuple with some >> audio and video streams. > > (1), from my list, is the UDP port. This could be the same UDP port > as the audio/video media. Yes. But SDP doesn't permit two m-lines with the same address and port. Bundle has been proposed to work around that. But currently bundle requires all the bundled m-lines to have the same . And that won't work for bundling SCTP and RTP. The restriction to the same is dictated by the need for a way to demux. Bundle specifies rules for multiple RTP m-lines that ensures they can be demuxed. The demuxing of RTP from SCTP on the same UDP port uses a different mechanism. So for this to work bundle needs: - more elaborate rules for what values may be bundled, and which may not - explicit specification for the demuxing of each of the different m-lines that have been bundled. This is not rocket science. Once you think about it a bit it is fairly evident which combinations work, and how to demux them. But it needs to be written down, directly or by reference. Thanks, Paul From eckelcu@cisco.com Fri Jan 11 09:25:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC60621F86D2 for ; Fri, 11 Jan 2013 09:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.607 X-Spam-Level: X-Spam-Status: No, score=-8.607 tagged_above=-999 required=5 tests=[AWL=1.992, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsOSeStqwzAx for ; Fri, 11 Jan 2013 09:25:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5921F8937 for ; Fri, 11 Jan 2013 09:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4617; q=dns/txt; s=iport; t=1357925057; x=1359134657; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9LW8rhE51zzRf//FY7jD1282iHMcGyaENcgfIWI9OOU=; b=HqiyLAZ696T46LcyU04qAH5aU7Wu8fH6p35kyhhIwusH2FZ/stbRN5N3 cnZclY1mkLi6MjfuZY0NNij5VonKf1A0DEt/+FaTw+q6+HO18OzIqLQfP u/bhaye9JOdkGxqU3fPOCe0AOolkZKw48YZ5hEM38sMnEuoibpudAak92 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGxK8FCtJXG+/2dsb2JhbABEvX4Wc4IeAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIiBABDLV+BJBFYQOmVIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,453,1355097600"; d="scan'208";a="161498551" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jan 2013 17:24:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0BHO2Ll009918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jan 2013 17:24:02 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 11:24:01 -0600 From: "Charles Eckel (eckelcu)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer Thread-Index: AQHN7p8Pzrd89LSrqUC7n2O8JcktGJhBmrDJgABznICAAT/FgIABLNAA///oHRA= Date: Fri, 11 Jan 2013 17:24:01 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804728ECE@xmb-aln-x08.cisco.com> References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> <50F009CE.9060903@alvestrand.no> In-Reply-To: <50F009CE.9060903@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Query: payload type collision with offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 17:25:42 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Friday, January 11, 2013 4:47 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer >=20 > On 01/10/2013 07:50 PM, Paul Kyzivat wrote: > > > >> Well there's also section 8.3.2 in 3264. The section is about updating > >> offers but it seems like the text explicitly prohibits remapping paylo= ad > >> types in any scenarios: > >> > >> However, in the > >> case of RTP, the mapping from a particular dynamic payload type > >> number to a particular codec within that media stream MUST NOT > >> change > >> for the duration of a session. For example, if A generates an off= er > >> with G.711 assigned to dynamic payload type number 46, payload typ= e > >> number 46 MUST refer to G.711 from that point forward in any offer= s > >> or answers for that media stream within the session. However, it i= s > >> acceptable for multiple payload type numbers to be mapped to the > >> same > >> codec, so that an updated offer could also use payload type > >> number 72 > >> for G.711. > > > > The language above is underspecified. > > > > It is my impression that the intent of this language was to ensure > > there is no ambiguity in the meaning of a payload type. Since the > > exchange of the SDP is not synchronized with the flow of RTP, if you > > were to send a new SDP that changed the mapping for a payload type, > > then the result would be almost certainly to interpret some media > > packets according to the wrong mapping. > > > > But this argument is only about packets flowing in one direction. It > > isn't a valid argument for requiring the payload types to be > > consistent in the two directions. And its not clear to me that it even > > intended that this language apply to both directions. It could be > > clarified as follows: > > > > ... For example, if A generates an offer > > with G.711 assigned to dynamic payload type number 46, payload type > > number 46 MUST refer to G.711 from that point forward in any offers > > or answers ***by A*** for that media stream within the session. ... > > > > Interpreting it to apply to both directions brings it in conflict with > > the language elsewhere that permits it to be different in the two > > directions. > More than one number for one codec is explicitly permitted. > More than one codec for one number in a single direction is clearly > impossible. > More than one codec for one number in a single RTP session..... that's > the question. >=20 > If one were to go with textual analysis, this would hinge on the meaning > of "for that media stream" - which again hinges on whether a media > stream is unidirectional or bidirectional. >=20 > RFC 3264's definition: >=20 > Media Stream: From RTSP [8], a media stream is a single media > instance, e.g., an audio stream or a video stream as well as a > single whiteboard or shared application group. In SDP, a media > stream is described by an "m=3D" line and its associated > attributes. >=20 > which points back to RFC 2326: >=20 > (Media) stream: > A single media instance, e.g., an audio stream or a video > stream as well as a single whiteboard or shared application > group. When using RTP, a stream consists of all RTP and RTCP > packets created by a source within an RTP session. This is > equivalent to the definition of a DSM-CC stream([5]). >=20 > So if we believe these definitions, there's no prohibition on reusing > the payload type. > Definitely nice to clarify in a 3264bis. >=20 > > > > The use of different mappings in each direction has been discussed > > over the years, though I couldn't point you to where. IIRC one of the > > reasons had to do with gatewaying to other protocols. But I can't > > offer any details. > > > > Bottom line: IMO, in the weird case Harald described X ought to follow > > Postel's Law and accept the answer from Y. But for the same reason I > > would strongly discourage implementations from acting as Y did. > > > Seems like a conclusion. Agreed, this would be a useful clarification to add as an update to RFC 326= 4. Cheers, Charles >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Fri Jan 11 10:05:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000D721F89AA for ; Fri, 11 Jan 2013 10:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diEUrkDp4xSz for ; Fri, 11 Jan 2013 10:05:27 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB2121F892A for ; Fri, 11 Jan 2013 10:05:26 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id mdQQ1k0020SCNGk59i5Rdk; Fri, 11 Jan 2013 18:05:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id mi5R1k00R3ZTu2S3Vi5Rhg; Fri, 11 Jan 2013 18:05:25 +0000 Message-ID: <50F05464.8040202@alum.mit.edu> Date: Fri, 11 Jan 2013 13:05:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Salvatore Loreto (JO/LMF)" , Gonzalo Camarillo References: <50BD0BA8.3010901@alum.mit.edu> In-Reply-To: <50BD0BA8.3010901@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357927525; bh=PVJBtnCYGqcEGQ7YsXY7FUgKYgKigUt9t5adP9z2jnw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hrA5i5bCc+l1TbQCJ6vGpHidPGvPawkBuevZ8/duwIO6SId4DBk/TpK3UDFKKooSN eQYtt2DLl3PLJLK/xLYmZ2rPVr9UROhOnRWyNg3wzfIhSjqofw/zZG7UDCRx/AjzCA rk59i7mRgZpMLNztiWIjmivXnLacWM7LCEAyY9Rb6EKX8rGFbw3w7UvZ41iKnE2/v7 m/lPvnPoVyXZoHKnr62w+Z4+jwkdbebhgGZXuhYLkF+5O201gFzcW6tehDtew/hBP9 XCX1XeVEkav0CpexYnjL9/OFytwqM3331U+tUHkgqOy2sm9uwgRvAazTIJjkHFFWC5 e38xzqPbbV9gQ== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Some issues with draft-ietf-mmusic-sctp-sdp-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 18:05:32 -0000 Replying to myself, since nobody else did. There has been more discussion recently (subject: SCTP question: Where does it multiplex?) on the same issue I raise below. More inline. On 12/3/12 3:29 PM, Paul Kyzivat wrote: > While commenting on some related discussions I had occasion to look at > this draft again and I found a few issues: > > First, some very specific ones:: > > Section 4.1 says: > > If the sub-field is 'SCTP' or ... > > This is a typo. s/port/proto/ > > But the major issue is that this draft doesn't explain the semantics of > the field. The only things I can find that touch on this are: > > - section 10.1 refers to "SCTP port 54111" and then shows an m-line > with: m=application 54111 SCTP 0 1 2 > But this is just an example, not normative text. > > - section 4.1 says: > > [OPEN ISSUE 3] do we need also an attribute to specify the SCTP port > number for the SCTP over DTLS scenario? that can be useful in the > case where multiple association are running on top of the same DTLS > session. > > This implies that the SCTP port number is *not* what is in the port > field in this case. Presumably because the UDP port number is in > that field. > > ISTM that there needs to be a clear discussion of all the required port > numbers for each case, and how they are specified. When there is more > than one (namely in the SCTP/DTLS and DTLS/SCTP cases), *one* of them > can be in the m-line and the other one must be somewhere else. And if > the one that is not in the m-line is optional, then I guess there must > be a default. For *native* SCTP (directly over IPv* - =SCTP) it seems obvious that the port in the m-line should be the SCTP port. For of SCTP/DTLS (RFC6083) there is again only the SCTP port to consider, so it should presumably go in the m-line. (My earlier comment about this one was wrong.) For of DTLS/SCTP (draft-tuexen-sctp-udp-encaps) we need both the SCTP port and the UDP port, so we must pick which one goes in the m-line. What arguments are there for which should go in the m-line? - Consistency with the other SCTP protos argues for the SCTP port. - The port in the m-line is mandatory. AFAIK there is no default SCTP port. But there *is* a default UDP port for DTLS/SCTP (9899, defined in draft-tuexen-sctp-udp-encaps). This is also an argument for the SCTP port in the m-line. - are there any arguments in favor of the UDP port in the m-line? (I haven't thought of any.) Absent some arguments on the other side, I propose that this document specify that the field of the m-line denote the SCTP port for all of the SCTP s, and specify an attribute to carry the UDP port, with a default of 9899. Thanks, Paul From miguel.a.garcia@ericsson.com Sun Jan 13 01:40:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F5321F863F for ; Sun, 13 Jan 2013 01:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOhcy-U33ndV for ; Sun, 13 Jan 2013 01:40:38 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9C21F8635 for ; Sun, 13 Jan 2013 01:40:38 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-28-50f28115fca9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 16.90.10459.51182F05; Sun, 13 Jan 2013 10:40:37 +0100 (CET) Received: from [159.107.48.76] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 13 Jan 2013 10:40:36 +0100 Message-ID: <50F28113.4000800@ericsson.com> Date: Sun, 13 Jan 2013 10:40:35 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvja5o46cAgy9XRS3eX9C1mLr8MYvF tTmNbA7MHlN+b2T1WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgyWrpfsRV8YqroeLOPvYFx NlMXIyeHhICJxKE9i9ggbDGJC/fWA9lcHEICJxklHk+9wArhrGaUaH6wn6WLkYODV0Bb4sVj W5AGFgFVia4vZ5hBbDYBc4nWjRvZQWxRgSiJ91ebwOK8AoISJ2c+YQGxRQRkJPZu2swMMpNZ oItR4tu/j2BXCAtoSkx+/A6sgVnAVuLCnOssELa8xPa3c8DiQiA1N5cyT2Dkn4Vk7iwkLbOQ tCxgZF7FyJ6bmJmTXm64iREYdge3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGKMT616aer3n7BYNq6rMbj2aszVa0GvrlF9FtarFx3wctuRsM9qwoqGU /fb5u517vnyUP8rMtl/SslUlzz/vQdv/+akhM7u1eQXKfjvtC238OfPRl9q3ifMuN397qlG9 I9s+dfWRrm86mmGHIw/7LXOo+Hu3Piem+uVlW+7GlpPhX1jZGboOKLEUZyQaajEXFScCAHc2 2AMJAgAA Cc: Flemming Andreasen , Gonzalo Camarillo Subject: [MMUSIC] Stepping down as MMUSIC co-chair X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jan 2013 09:40:39 -0000 Dear all: It's been almost two years serving as MMUSIC co-chair. Unfortunately my other non-IETF assignments are preventing me to do the job with the commitment I would like to do. So, I have decided to step down as MMUSIC co-chair. A new co-chair should be announced soon. Cheers, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gonzalo.camarillo@ericsson.com Sun Jan 13 03:08:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102B621F869B for ; Sun, 13 Jan 2013 03:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF-HsGeiFPuh for ; Sun, 13 Jan 2013 03:08:28 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A49EA21F8692 for ; Sun, 13 Jan 2013 03:08:19 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-db-50f295a25e75 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EC.82.32353.2A592F05; Sun, 13 Jan 2013 12:08:18 +0100 (CET) Received: from [131.160.126.20] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Sun, 13 Jan 2013 12:08:18 +0100 Message-ID: <50F295A1.9040806@ericsson.com> Date: Sun, 13 Jan 2013 13:08:17 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <50F28113.4000800@ericsson.com> In-Reply-To: <50F28113.4000800@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje6iqZ8CDF4s1LZ4f0HXYuryxywW 1+Y0sjkwe0z5vZHVY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DK2LjApOAiS8Wtub3MDYwH mLsYOTgkBEwkJl0s7WLkBDLFJC7cW8/WxcjFISRwklFi4qNuRghnDaPEpE+bWECqeAW0Jebv u8AO0swioCpx9HEmSJhNwEJiy637YCWiAlES7682MUOUC0qcnPkELC4iYCrRNmsLmM0skCfx YdUfJhBbWEBX4uahxWwgthDQ+NvHb4HFOQV0JKY9PM0GcZykxKJpnVC9ehJTrrYwQtjyEtvf zmGG6V3+rIVlAqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cvNNjMDAPbjlt8EOxk33xQ4xSnOw KInzhrteCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAeNjif7HpW4ar3R2Ou1Xs9QWUtDPS rEJPGSkxTvQOOlSiYawzZ+kCv6Zo/rky1h3hYSuE2n1mpTySOFh80M+7Nym1W12l7K1ZzBvF k7cv269u+7m89Pq3wNLpvxK2Z732/dL4MKx++edTzJrf7IpN0k1XXK+JnpmVuDQnSpc3O6X9 2o95R48rsRRnJBpqMRcVJwIAkbMn/ioCAAA= Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Stepping down as MMUSIC co-chair X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jan 2013 11:08:29 -0000 Hi, I want to thank Miguel Angel for all his efforts during this period. We were all sorry to hear he had to step down at this point. Ari Keranen will be replacing Miguel Angel. Cheers, Gonzalo On 13/01/2013 11:40 AM, Miguel A. Garcia wrote: > Dear all: > > It's been almost two years serving as MMUSIC co-chair. Unfortunately my > other non-IETF assignments are preventing me to do the job with the > commitment I would like to do. So, I have decided to step down as MMUSIC > co-chair. > > A new co-chair should be announced soon. > > Cheers, > > Miguel From internet-drafts@ietf.org Sun Jan 13 21:47:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CF21F8848; Sun, 13 Jan 2013 21:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JesWK836uS-k; Sun, 13 Jan 2013 21:47:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC64321F8449; Sun, 13 Jan 2013 21:46:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114054657.11222.78832.idtracker@ietfa.amsl.com> Date: Sun, 13 Jan 2013 21:46:57 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-26.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 05:47:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) a= nd Real-time Transport Protocol (RTP) for Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-26.txt Pages : 34 Date : 2013-01-13 Abstract: The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/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, administrators 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 types and attributes, which enable 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-26 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From miguel.a.garcia@ericsson.com Mon Jan 14 01:11:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686F921F88A8 for ; Mon, 14 Jan 2013 01:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5C1pY1UzEJk for ; Mon, 14 Jan 2013 01:11:48 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF821F87C8 for ; Mon, 14 Jan 2013 01:11:36 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-07-50f3cbc761ac Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 07.89.32353.7CBC3F05; Mon, 14 Jan 2013 10:11:36 +0100 (CET) Received: from [159.107.26.63] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 10:11:35 +0100 Message-ID: <50F3CBC6.90901@ericsson.com> Date: Mon, 14 Jan 2013 10:11:34 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <50EFFC93.70406@ericsson.com> In-Reply-To: <50EFFC93.70406@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RvfE6c8BBms+clhMXf6YxeLcp7ss DkweS5b8ZPK4e+sSUwBTFJdNSmpOZllqkb5dAlfGvg1fWAomKlV0T/jC1MC4XqqLkZNDQsBE 4uqZL0wQtpjEhXvr2UBsIYGTjBIPJ2t3MXIB2asZJea3rmcFSfAKaEpcenQPzGYRUJXomLiD GcRmEzCXaN24kR3EFhWIknh/tYkZol5Q4uTMJywgtoiAmcT7f6vAljELBEis/TkdzBYWsJFY v34FUD0H0DJNidlrCkDCnAJaEudPTGaHKLeVuDDnOguELS+x/e0cZog7NSUm31zKPIFRcBaS bbOQtMxC0rKAkXkVI3tuYmZOern5JkZgQB7c8ttgB+Om+2KHGKU5WJTEecNdLwQICaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYLRWOiZoO01DI3OJQ7e7/sLqWSwmbv981RomFt8yutOssHhn ZD/T0sMxO55vvPp3fb56Rt5imQ+BXya2v8vckPjro+OM0GXdr6yvn5dqOjUlcP91Ex/FwzXa 9RNqfjAfEOacqhS8b7v/lcoK63SNnRKld361L7Q5fPFRatSKq88nLprFITvrUrgSS3FGoqEW c1FxIgAp+Sm9FgIAAA== Cc: mmusic Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:11:50 -0000 Hi Gonzalo: Here are some inline comments. I am about to post version -17 addressing your comments: On 11/01/2013 12:50, Gonzalo Camarillo wrote: > Hi, > > I just got a publication request for the following draft: > > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 > > Please, find below my AD review. > > Cheers, > > Gonzalo > > > draft-ietf-mmusic-sdp-cs-16: > > Page 10: remove the indentation of the following paragraph. Indented > paragraphs are typically used to provide clarifications while this one > contains normative language: > > Note that and/or MUST NOT be > omitted when unknown since this would violate basic syntax of SDP > [RFC4566]. In such cases, they MUST be set to a "-". Ok. > > Section 5.2.3.1 provides a "format" for the cs-correlation attribute. > However, its ABNF formal syntax is in Section 5.7. So, why does Section > 5.2.3.1 also contain a syntax for the attribute... and what type of > syntax is that? The sort-of-syntax in Section 5.2.3.1 is simply an introduction to the three types of correlation mechanisms that can be used. So, the syntax is the way to introduce to Sections 5.2.3.2, 5.2.3.3, and 5.2.3.4. But I understand your point. I suggest removing the syntax from there and including a pointer to Section 5.7, where the formal syntax is described. > > Page 14: the text says: > > To mitigate this problem implementations > should consider only some of the rightmost digits from the E.164 > > Can we provide a more concrete advice (or at least some discussion) on > the number of digits to consider? This is a hard problem even to provide guidance, because the PSTN E.164 numbers have a variable length. So, if you want to do it right, you should become aware of the number plan in the network you are camping. But this is outside the scope of the specification. We can add a note to refer to ITU-T E.164 specification in order for implementations to consider what the right number of digits is. > > Page 15: we define how to encode a binary value in hexadecimal format > and represent it as a two-digit ASCII value. Can we point to an existing > specification that defines how to do that instead of specifying it inline? > Yeap, and I found that there is an RFC specifying it (there is always an RFC specifying what you want :-). It is RFC 4648 and we are referring to the base16 (or "hex") encoding. We will change the text accordingly. > Page 17: the text says: > > Implementations are advised to select a number of DTMF digits that > provide enough assurance that the call is related, but on the > other hand do not prolong the bearer setup time unnecessarily. > > Can we provide a more concrete recommendation? Ok, I guess we are talking of 5 to 10 digits. > > Page 17: Section 5.2.3.4 specifies what to do when the correlation > fails. However, that is described in general in Section 5.3.3. Why don't > we move all the statements about how to decide whether the sessions are > correlated to Section 5.3.3? Now, the following statement contradicts > what Section 5.3.3 says, for example: > > the passive side > SHOULD treat the circuit-switched bearer as not correlated to the > ongoing session. ok. > > The indented text right after the statement above talks about > suppressing alerting. Such a supression is applicable to any session, > not only those that are correlated using DTMF tones. So, we could also > move that discussion to Section 5.3.3. ok too. > > Section 5.5: rephrase the following sentence (possibly splitting it into > more than one sentence) so that it is clearer: > > Note that this may result in the recipient of the initial Offer in > rejecting the Offer if the recipient of the Offer is not aware of > its own E.164 number, and thus concluding that it will not be > possible to establish a circuit-switched bearer since neither > party is aware of their E.164 number. Done Thanks, > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gonzalo.camarillo@ericsson.com Mon Jan 14 01:19:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B339E21F8587 for ; Mon, 14 Jan 2013 01:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKyntghYe3LE for ; Mon, 14 Jan 2013 01:19:42 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F152121F855D for ; Mon, 14 Jan 2013 01:19:41 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-7e-50f3cdac6a8c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B7.1B.32353.CADC3F05; Mon, 14 Jan 2013 10:19:41 +0100 (CET) Received: from [131.160.36.129] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 10:19:40 +0100 Message-ID: <50F3CDAC.8090702@ericsson.com> Date: Mon, 14 Jan 2013 11:19:40 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <50EFFC93.70406@ericsson.com> <50F3CBC6.90901@ericsson.com> In-Reply-To: <50F3CBC6.90901@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje7as58DDKac4bCYuvwxi8W5T3dZ HJg8liz5yeRx99YlpgCmKC6blNSczLLUIn27BK6MLQvfMxX8VanY1GvbwHhYpouRk0NCwESi r20CK4QtJnHh3nq2LkYuDiGBk4wSyxfOZ4Rw1jBK/Gq5xwZSxSugLfFy4UMWEJtFQFWiYeMr RhCbTcBCYsut+2BxUYEoifdXm5gh6gUlTs58AhYXETCVaJu1BcxmFgiQWPtzOhOILSxgI7F+ /QqweiEBd4kVndPBdnEKaElsPPyfCeI6SYlF0zqhevUkplxtYYSw5SW2v50D1astsfxZC8sE RqFZSFbPQtIyC0nLAkbmVYzsuYmZOenl5psYgaF6cMtvgx2Mm+6LHWKU5mBREucNd70QICSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoFxZoPQs7smfNlb9i5QeymceScq0XuTrNrNw+VxrbU8 /H6Tg4I25WcFaeZMvOevfbn7/9kJhY++ifyxSgpMni+ap6LNqvZzbU+sseqdyzbZ+SESl6b9 e9T2y9ZkVfy3Veu9Qvj69+8zKWNkE2ef2pV0mFm/ZPI2oT0rGms1jhR7t/UG7r4tWarEUpyR aKjFXFScCACR+d7iIwIAAA== Cc: mmusic Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:19:45 -0000 Hi Miguel Angel, thanks for your quick response. I am OK with all your proposals below. When you implement the changes, please post a new revision of the draft. Thanks, Gonzalo On 14/01/2013 11:11 AM, Miguel A. Garcia wrote: > Hi Gonzalo: > > Here are some inline comments. I am about to post version -17 addressing > your comments: > > > On 11/01/2013 12:50, Gonzalo Camarillo wrote: >> Hi, >> >> I just got a publication request for the following draft: >> >> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 >> >> Please, find below my AD review. >> >> Cheers, >> >> Gonzalo >> >> >> draft-ietf-mmusic-sdp-cs-16: >> >> Page 10: remove the indentation of the following paragraph. Indented >> paragraphs are typically used to provide clarifications while this one >> contains normative language: >> >> Note that and/or MUST NOT be >> omitted when unknown since this would violate basic syntax of SDP >> [RFC4566]. In such cases, they MUST be set to a "-". > > Ok. > >> >> Section 5.2.3.1 provides a "format" for the cs-correlation attribute. >> However, its ABNF formal syntax is in Section 5.7. So, why does Section >> 5.2.3.1 also contain a syntax for the attribute... and what type of >> syntax is that? > > The sort-of-syntax in Section 5.2.3.1 is simply an introduction to the > three types of correlation mechanisms that can be used. So, the syntax > is the way to introduce to Sections 5.2.3.2, 5.2.3.3, and 5.2.3.4. > > But I understand your point. I suggest removing the syntax from there > and including a pointer to Section 5.7, where the formal syntax is > described. > >> >> Page 14: the text says: >> >> To mitigate this problem implementations >> should consider only some of the rightmost digits from the E.164 >> >> Can we provide a more concrete advice (or at least some discussion) on >> the number of digits to consider? > > This is a hard problem even to provide guidance, because the PSTN E.164 > numbers have a variable length. So, if you want to do it right, you > should become aware of the number plan in the network you are camping. > But this is outside the scope of the specification. > > We can add a note to refer to ITU-T E.164 specification in order for > implementations to consider what the right number of digits is. > >> >> Page 15: we define how to encode a binary value in hexadecimal format >> and represent it as a two-digit ASCII value. Can we point to an existing >> specification that defines how to do that instead of specifying it >> inline? >> > > Yeap, and I found that there is an RFC specifying it (there is always an > RFC specifying what you want :-). It is RFC 4648 and we are referring to > the base16 (or "hex") encoding. We will change the text accordingly. > > >> Page 17: the text says: >> >> Implementations are advised to select a number of DTMF digits that >> provide enough assurance that the call is related, but on the >> other hand do not prolong the bearer setup time unnecessarily. >> >> Can we provide a more concrete recommendation? > > Ok, I guess we are talking of 5 to 10 digits. > >> >> Page 17: Section 5.2.3.4 specifies what to do when the correlation >> fails. However, that is described in general in Section 5.3.3. Why don't >> we move all the statements about how to decide whether the sessions are >> correlated to Section 5.3.3? Now, the following statement contradicts >> what Section 5.3.3 says, for example: >> >> the passive side >> SHOULD treat the circuit-switched bearer as not correlated to the >> ongoing session. > > ok. > >> >> The indented text right after the statement above talks about >> suppressing alerting. Such a supression is applicable to any session, >> not only those that are correlated using DTMF tones. So, we could also >> move that discussion to Section 5.3.3. > > ok too. > >> >> Section 5.5: rephrase the following sentence (possibly splitting it into >> more than one sentence) so that it is clearer: >> >> Note that this may result in the recipient of the initial Offer in >> rejecting the Offer if the recipient of the Offer is not aware of >> its own E.164 number, and thus concluding that it will not be >> possible to establish a circuit-switched bearer since neither >> party is aware of their E.164 number. > > Done > > > > Thanks, > > >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From internet-drafts@ietf.org Mon Jan 14 01:20:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84BA21F8B33; Mon, 14 Jan 2013 01:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZWj7sR7KXZa; Mon, 14 Jan 2013 01:20:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4D21F86BB; Mon, 14 Jan 2013 01:20:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114092000.32481.19291.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 01:20:00 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:20:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-17.txt Pages : 37 Date : 2013-01-14 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From miguel.a.garcia@ericsson.com Mon Jan 14 01:20:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD721F8607 for ; Mon, 14 Jan 2013 01:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILaPIo2aqwnv for ; Mon, 14 Jan 2013 01:20:35 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DE87521F855D for ; Mon, 14 Jan 2013 01:20:33 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-27-50f3cde0cce8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3C.51.10459.0EDC3F05; Mon, 14 Jan 2013 10:20:32 +0100 (CET) Received: from [159.107.26.63] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 10:20:32 +0100 Message-ID: <50F3CDDF.5070601@ericsson.com> Date: Mon, 14 Jan 2013 10:20:31 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <50EFFC93.70406@ericsson.com> <50F3CBC6.90901@ericsson.com> <50F3CDAC.8090702@ericsson.com> In-Reply-To: <50F3CDAC.8090702@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RvfB2c8BBl0vtC2mLn/MYnHu010W ByaPJUt+MnncvXWJKYApissmJTUnsyy1SN8ugSvj1YrprAWL1Cue/9vN1MB4Wq6LkYNDQsBE YsvcvC5GTiBTTOLCvfVsXYxcHEICJxklNvcsZoJwVjNK9P58xA5SxSugLbFj1kU2kGYWAVWJ rRcqQcJsAuYSrRs3gpWICkRJvL/axAxRLihxcuYTFhBbRMBM4v2/VUwgNrNAgMTan9PBbGEB G4n161eA1QsJpEvMbW5nA7E5BXQkzs/byw5RbytxYc51FghbXmL72zlQ9ZoSk28uZZ7AKDgL ybpZSFpmIWlZwMi8ipE9NzEzJ73ccBMjMCAPbvmtu4Px1DmRQ4zSHCxK4rxhrhcCgK5ILEnN Tk0tSC2KLyrNSS0+xMjEwSnVwDjRJGbvxcUlP2zm2E3U7ZiV0HOufopKbeSthrRr0ybUfc4M 2aB/w+111/UbU44dnJ224e2Hn0vN5r6XZpq5wviyof0HI60Jv25+S9n31vzXsrIJk/iiczKu HC3aEHm/+LfPyjixsAdcS/If/vHX7L4RWG5qGiI/W6F39585UquKpfLOOdzLNV2qxFKckWio xVxUnAgAR2nmPxYCAAA= Cc: mmusic Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:20:37 -0000 I have just submitted version -17. /Miguel On 14/01/2013 10:19, Gonzalo Camarillo wrote: > Hi Miguel Angel, > > thanks for your quick response. I am OK with all your proposals below. > When you implement the changes, please post a new revision of the draft. > > Thanks, > > Gonzalo > > On 14/01/2013 11:11 AM, Miguel A. Garcia wrote: >> Hi Gonzalo: >> >> Here are some inline comments. I am about to post version -17 addressing >> your comments: >> >> >> On 11/01/2013 12:50, Gonzalo Camarillo wrote: >>> Hi, >>> >>> I just got a publication request for the following draft: >>> >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16 >>> >>> Please, find below my AD review. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> draft-ietf-mmusic-sdp-cs-16: >>> >>> Page 10: remove the indentation of the following paragraph. Indented >>> paragraphs are typically used to provide clarifications while this one >>> contains normative language: >>> >>> Note that and/or MUST NOT be >>> omitted when unknown since this would violate basic syntax of SDP >>> [RFC4566]. In such cases, they MUST be set to a "-". >> >> Ok. >> >>> >>> Section 5.2.3.1 provides a "format" for the cs-correlation attribute. >>> However, its ABNF formal syntax is in Section 5.7. So, why does Section >>> 5.2.3.1 also contain a syntax for the attribute... and what type of >>> syntax is that? >> >> The sort-of-syntax in Section 5.2.3.1 is simply an introduction to the >> three types of correlation mechanisms that can be used. So, the syntax >> is the way to introduce to Sections 5.2.3.2, 5.2.3.3, and 5.2.3.4. >> >> But I understand your point. I suggest removing the syntax from there >> and including a pointer to Section 5.7, where the formal syntax is >> described. >> >>> >>> Page 14: the text says: >>> >>> To mitigate this problem implementations >>> should consider only some of the rightmost digits from the E.164 >>> >>> Can we provide a more concrete advice (or at least some discussion) on >>> the number of digits to consider? >> >> This is a hard problem even to provide guidance, because the PSTN E.164 >> numbers have a variable length. So, if you want to do it right, you >> should become aware of the number plan in the network you are camping. >> But this is outside the scope of the specification. >> >> We can add a note to refer to ITU-T E.164 specification in order for >> implementations to consider what the right number of digits is. >> >>> >>> Page 15: we define how to encode a binary value in hexadecimal format >>> and represent it as a two-digit ASCII value. Can we point to an existing >>> specification that defines how to do that instead of specifying it >>> inline? >>> >> >> Yeap, and I found that there is an RFC specifying it (there is always an >> RFC specifying what you want :-). It is RFC 4648 and we are referring to >> the base16 (or "hex") encoding. We will change the text accordingly. >> >> >>> Page 17: the text says: >>> >>> Implementations are advised to select a number of DTMF digits that >>> provide enough assurance that the call is related, but on the >>> other hand do not prolong the bearer setup time unnecessarily. >>> >>> Can we provide a more concrete recommendation? >> >> Ok, I guess we are talking of 5 to 10 digits. >> >>> >>> Page 17: Section 5.2.3.4 specifies what to do when the correlation >>> fails. However, that is described in general in Section 5.3.3. Why don't >>> we move all the statements about how to decide whether the sessions are >>> correlated to Section 5.3.3? Now, the following statement contradicts >>> what Section 5.3.3 says, for example: >>> >>> the passive side >>> SHOULD treat the circuit-switched bearer as not correlated to the >>> ongoing session. >> >> ok. >> >>> >>> The indented text right after the statement above talks about >>> suppressing alerting. Such a supression is applicable to any session, >>> not only those that are correlated using DTMF tones. So, we could also >>> move that discussion to Section 5.3.3. >> >> ok too. >> >>> >>> Section 5.5: rephrase the following sentence (possibly splitting it into >>> more than one sentence) so that it is clearer: >>> >>> Note that this may result in the recipient of the initial Offer in >>> rejecting the Offer if the recipient of the Offer is not aware of >>> its own E.164 number, and thus concluding that it will not be >>> possible to establish a circuit-switched bearer since neither >>> party is aware of their E.164 number. >> >> Done >> >> >> >> Thanks, >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Mon Jan 14 07:43:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3677C21F8756 for ; Mon, 14 Jan 2013 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.389 X-Spam-Level: X-Spam-Status: No, score=-8.389 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9RRUXJBK10X for ; Mon, 14 Jan 2013 07:43:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7E24F21F8609 for ; Mon, 14 Jan 2013 07:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3272; q=dns/txt; s=iport; t=1358178193; x=1359387793; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Yh33glBgibYPSTEN9EaM8w+1p7o/DsxWFENgUICPqV0=; b=aWCW359tDsaT9clabC0wR3IBiStHNv2po64AjlWFSsyk8s4KLRFc76wZ Y/R2EwHpEcTXzvvAmE5Wnj3VGEuQq77iYE32nxvPyxfzXvggNODfcXSGy I9AJDunVQejlh5zMFMR7++iDIqOAekoEL6dqAsb21hm5PvKjixSHOSPkx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANAl9FCtJXG8/2dsb2JhbABEjBaxahZzgh4BAQEEAQEBawoBEAsEFAkWDwkDAgECARUwBg0BBQIBAYgVDLUWBJEuA4hhjSqQSYMT X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208,217";a="162170229" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jan 2013 15:43:13 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.254.15]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0EFhBqe012828; Mon, 14 Jan 2013 15:43:12 GMT Message-ID: <50F362F8.2050900@cisco.com> Date: Sun, 13 Jan 2013 20:44:24 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <50F28113.4000800@ericsson.com> <1.c0aae1c83d24cfcd39cb@ericsson.com> In-Reply-To: <1.c0aae1c83d24cfcd39cb@ericsson.com> Content-Type: multipart/alternative; boundary="------------020009030406020709040401" Cc: mmusic Subject: Re: [MMUSIC] Stepping down as MMUSIC co-chair X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 15:43:14 -0000 This is a multi-part message in MIME format. --------------020009030406020709040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'd like to echo that. Many thanks to Miguel for a job well done. Regards -- Flemming On 1/13/13 6:08 AM, Gonzalo Camarillo wrote: > Hi, > > I want to thank Miguel Angel for all his efforts during this period. We > were all sorry to hear he had to step down at this point. Ari Keranen > will be replacing Miguel Angel. > > Cheers, > > Gonzalo > > On 13/01/2013 11:40 AM, Miguel A. Garcia wrote: > > Dear all: > > > > It's been almost two years serving as MMUSIC co-chair. Unfortunately my > > other non-IETF assignments are preventing me to do the job with the > > commitment I would like to do. So, I have decided to step down as > MMUSIC > > co-chair. > > > > A new co-chair should be announced soon. > > > > Cheers, > > > > Miguel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------020009030406020709040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'd like to echo that. Many thanks to Miguel for a job well done.

Regards

-- Flemming

On 1/13/13 6:08 AM, Gonzalo Camarillo wrote:
Hi,

I want to thank Miguel Angel for all his efforts during this period. We
were all sorry to hear he had to step down at this point. Ari Keranen
will be replacing Miguel Angel.

Cheers,

Gonzalo

On 13/01/2013 11:40 AM, Miguel A. Garcia wrote:
> Dear all:
>
> It's been almost two years serving as MMUSIC co-chair. Unfortunately my
> other non-IETF assignments are preventing me to do the job with the
> commitment I would like to do. So, I have decided to step down as MMUSIC
> co-chair.
>
> A new co-chair should be announced soon.
>
> Cheers,
>
> Miguel

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

--------------020009030406020709040401-- From ted.ietf@gmail.com Mon Jan 14 09:41:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666FD21F8841; Mon, 14 Jan 2013 09:41:30 -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=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLmsmNTfHczK; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id BA53321F8953; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id s9so5406250iec.27 for ; Mon, 14 Jan 2013 09:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=yKv5GxgAovOXPYnhQiYXqRURyRp0LeG/f0I6Rhh01AA=; b=VMu2U+6VulA8n6W3dmUyb7TUT2fdOnTv1u67s3A6cMDCzWSQoF2e3/s/lhWFnqQ0HL EjoRwxUvLtJB92s9u/qOActYOcLm0iyMa69XF+bWDh2SCkQssLGhecqcrd/yxV81R9JB u1pra2jyTcc/OFqiMMsWPdG2QfjcjCA84VAOqoZ7afU/G2+C3zA1feIyZWFy5Akw4BfF QBIlZXUy7XOxwR8iUkPp6O0NBrIxSs7AX7cOiDOdb2+8uuzBY1iVUfFyWYsHMI3uOoo1 FV4uv0b7EkklqXsUlsEt5zG3pw3xD8DQyVCBxs99w3tajfrxh13k8CxYkUbxxqZ/B+D1 n5nA== MIME-Version: 1.0 X-Received: by 10.50.170.102 with SMTP id al6mr7544813igc.70.1358185289401; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Received: by 10.43.94.5 with HTTP; Mon, 14 Jan 2013 09:41:29 -0800 (PST) Date: Mon, 14 Jan 2013 09:41:29 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , Magnus Westerlund , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , Gonzalo Camarillo , Flemming Andreasen Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 17:41:30 -0000 Below is a proposed agenda which has been discussed among the RTCWEB and MMUSIC chairs; comments welcome. Ted Hardie Day 1 (February 5th, 2013) Multiple Flow SDP representation 90 minutes: Framing discussion (Magnus is working on text) 120 minutes: drafts discussion Objective: decide on architecture for large numbers of similar streams SDP for Data channels 60 minutes: resolve open issues Day 2 (February 6, 2013) SDP Grouping (Bundle/MMT/one-rtp) 60 Minutes: framing discussion 120 Minutes: drafts discussion Objective: select an approach and provide direction to editors Mapping stream/track label concepts to SDP identifiers 60 minutes Objective: determine requirements Day 3: (February 7, 2013) Trickle ICE 120 minutes Objective: review offer/answer semantic impact; establish initiation, termination and error handling JSEP 120 minutes Objective: review and resolve open issues with the document From internet-drafts@ietf.org Mon Jan 14 11:13:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9421F8B0A; Mon, 14 Jan 2013 11:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXqR1Jd50PmU; Mon, 14 Jan 2013 11:13:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D66E21F8B0B; Mon, 14 Jan 2013 11:13:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114191316.31209.61712.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 11:13:16 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-27.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 19:13:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) a= nd Real-time Transport Protocol (RTP) for Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-27.txt Pages : 33 Date : 2013-01-14 Abstract: The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/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, administrators 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 types and attributes, which enable 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-27 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-27 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Tue Jan 15 02:48:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29DD21F8804 for ; Tue, 15 Jan 2013 02:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUD84BtVnZhn for ; Tue, 15 Jan 2013 02:48:29 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0721F87F7 for ; Tue, 15 Jan 2013 02:48:28 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-70-50f533fb6fae Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 82.45.10459.BF335F05; Tue, 15 Jan 2013 11:48:27 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 15 Jan 2013 11:48:27 +0100 Message-ID: <50F533FA.4060004@ericsson.com> Date: Tue, 15 Jan 2013 11:48:26 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com><5097DF12.2020209@alvestrand.no><92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com><50C8548B.5040306@ericsson.com> <1.11d9cd8cb4c2e6b86be1@cisco.com> In-Reply-To: <1.11d9cd8cb4c2e6b86be1@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje5v468BBu1fBS02zfrCZjF1+WMW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStj9owm9oIFIhVbO2YxNzBuE+hi5OCQEDCR WPlHpIuRE8gUk7hwbz1bFyMXh5DASUaJf+d7mSCc5YwS589eZwap4hXQltg36xgTiM0ioCpx 8vIqMJtNwELi5o9GNhBbVMBXYtaeX0wQ9YISJ2c+YQGxRQQMJRZNWscCsphZQF3i6uIgkLCw QI7E6nN3oBa/YpTo37MVbBengL7E7+kPWCGuk5RYNK0TbA6zgJ7ElKstjBC2vETz1tlg9UJA tzU0dbBOYBSahWT1LCQts5C0LGBkXsXInpuYmZNebriJERiqB7f81t3BeOqcyCFGaQ4WJXHe MNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYk9xnrrGYI8pVZFrNnpEjMeH7iho2NhWm eMN6M8FV9p812tUVmyXkXjcwpL39ELtoZ71FLJvC+R/ysnKqsyO7c2Sfa2yc/1Pn91yGc/dT W3wWzCn47JzT2umst1qOt2j1FCaRddlK9/Xa3t+3kNr3/tiq41uXi4cFZSb47JtxvkRP337W gXtKLMUZiYZazEXFiQDaHPnIIwIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: commentson draft-ietf-mmusic-sdp-bundle-negotiation-01) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 10:48:29 -0000 On 2012-12-14 18:29, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, December 12, 2012 1:55 AM >> To: Charles Eckel (eckelcu) >> Cc: Harald Alvestrand; mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft- >> ietf-mmusic-sdp-bundle-negotiation-01) >> >> Hi, >> >> Going through old emails. One important comment: >> >> On 2012-11-05 21:04, Charles Eckel (eckelcu) wrote: >> >> >> >> Last time I looked b=CT was scoped to a whole conference ("supplied > for >> >> the session"), while b=AS was scoped to a single RTP session. But I > may >> >> be misinterpreting RFC 4566 section 5.8. >> > >> > I recommend using b=TIAS, as defined in RFC 3890. This parameter may be >> used at either the session or the media level, and it scope accordingly. >> > What needs to be avoided is summing up the b=TIAS/AS values from the >> bundled media lines and using that as that bandwidth for the bundle > even if >> it exceeds the b=TIAS/AS/CT value from the session level. >> > >> >> I would note that TIAS has no definition in Offer/Answer context. It is >> soley defined for Declarative usage. Yes, I know it is being used in O/A >> contexts, but I still don't understand how a receiver can state the >> actual packet rate to be used by the sender to enable correct > calculation. > > Agreed, TIAS is a declaration of the maximum bandwidth the declarer is > willing to receive. It does not say anything about what the declarer is > going to send. The same is true for AS and CT. > If we want something that indicates the maximum bandwidth the declarer > is planning to send, we would need to extend an existing attribute or > define a new attribute. > However, the restriction I mentioned above regarding bundled streams not > violating limits declared by the corresponding b=TIAS/AS/CT attributes > still applies. > But the thing is that TIAS is defined as the bandwidth one is going to send including packet rate in the declarative usage. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From iesg-secretary@ietf.org Tue Jan 15 07:45:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116FB21F871C; Tue, 15 Jan 2013 07:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJYAjOPIorWX; Tue, 15 Jan 2013 07:45:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4E21F882F; Tue, 15 Jan 2013 07:45:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115154532.11812.87070.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 07:45:32 -0800 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 15:45:34 -0000 The IESG has approved the following document: - 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' (draft-ietf-mmusic-media-loopback-27.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ Technical Summary This document provides extensions to the Session Description Protocol (SDP) and the Real-time Transport Protocol (RTP) for enabling looping of sent media. 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. The extension defined herein adds new SDP media types and attributes, which enable 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. Working Group Summary The first version of the document was available at the end of 2004. Since that time, the working group has been discussing a number of issues toward getting the consensus that is believed to be achieved in version 22. The description of a latching mechanism to traverse NATs and firewalls was discussed and decided to be removed from the actual document in favor of standard NAT traversal techniques such as ICE/STUN/TURN. Document Quality At least four implementations of this functionality are known. Four other vendors have indicated they plan to implement it. The document was WGLCed on version 16. Additionally, the PAYLOAD WG also conducted a thorough review of the same 16 version. As a result of these reviews, 34 changes were requested by, among others, Tolga Asveren, Dan Wing, Emil Ivov, Flemming Andreasen, and Miguel A. Garcia. These comments were subsequently introduced into versions 17 and 18. A new WGLC was issued on version 18, bringing a new set of comments by Flemming Andreasen, Magnus Westerlund, and Gunnar Hellstrom. These were addressed in version 19. At least Magnus Westerlund and Flemming Andreasen did a thorough review of the document as part of the WGLC on version 18. Version 18 was sent to the ietf-types mailing list for review on April 4, 2012. Bjorern Hoehrmann and Magnus Westerlund posted comments that were addressed in version 19. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Miguel A. Garcia is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director From pkyzivat@alum.mit.edu Tue Jan 15 08:39:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF76021F86EA for ; Tue, 15 Jan 2013 08:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7v5RIsFLrF9 for ; Tue, 15 Jan 2013 08:39:09 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id B567721F86E7 for ; Tue, 15 Jan 2013 08:39:08 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id oB0x1k0051ap0As55Gf7Zr; Tue, 15 Jan 2013 16:39:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id oGf71k0123ZTu2S3iGf7us; Tue, 15 Jan 2013 16:39:07 +0000 Message-ID: <50F5862B.30906@alum.mit.edu> Date: Tue, 15 Jan 2013 11:39:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF MMUSIC WG References: <20130115154532.11812.87070.idtracker@ietfa.amsl.com> In-Reply-To: <20130115154532.11812.87070.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358267947; bh=ae/cfNSR18dvJHeV848ioakcfQzxEFR5+GTZetsR+DQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E/1nequh8NUbyOO7XsPIH0UuoXq86/0p+jJLeMvyP5nuAmle+7rfgQvEQYDJEdChm LZcpHeAUAFE/p0+c6IoEp8VxA+e45F68FxPpWNotXAmaFg/dZJI25+JQsIjjsqlY2M v5EtE2iEY0LSKZMdwc1brUUvtvx3ONTKe2q64mNekdP0EY2DoyYFHftm1Oho10OE/z RxqyqXjwJgkUJ6HQRG7jCryPrYkm6YogAQfEtBg+qi/8v1jNoqydqspZDjpyr8709I rYC4lBKDvjJGiF0R/wlrnsG3GAO2obfNyh1e+Vy3pMVIQuAjY4Yu3vpnrQhDg3E8E6 aiq5/cZriI7Wg== Subject: Re: [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:39:09 -0000 Wow - finally! -00 was in December 2004!. Not a record, but up there. Paul On 1/15/13 10:45 AM, The IESG wrote: > The IESG has approved the following document: > - 'An Extension to the Session Description Protocol (SDP) and Real-time > Transport Protocol (RTP) for Media Loopback' > (draft-ietf-mmusic-media-loopback-27.txt) as Proposed Standard > > This document is the product of the Multiparty Multimedia Session Control > Working Group. > > The IESG contact persons are Gonzalo Camarillo and Robert Sparks. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ > > > > > Technical Summary > > This document provides extensions to the Session Description Protocol > (SDP) and the Real-time Transport Protocol (RTP) for enabling looping > of sent media. 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. The extension defined herein adds new SDP media > types and attributes, which enable 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. > > Working Group Summary > > The first version of the document was available at the end of 2004. > Since that time, the working group has been discussing a number of > issues toward getting the consensus that is believed to be achieved in > version 22. > > The description of a latching mechanism to traverse NATs and firewalls > was discussed and decided to be removed from the actual document in > favor of standard NAT traversal techniques such as ICE/STUN/TURN. > > Document Quality > > At least four implementations of this functionality are known. Four > other vendors have indicated they plan to implement it. > > The document was WGLCed on version 16. Additionally, the PAYLOAD WG > also conducted a thorough review of the same 16 version. As a result of > these reviews, 34 changes were requested by, among others, Tolga > Asveren, Dan Wing, Emil Ivov, Flemming Andreasen, and Miguel A. Garcia. > These comments were subsequently introduced into versions 17 and 18. A > new WGLC was issued on version 18, bringing a new set of comments by > Flemming Andreasen, Magnus Westerlund, and Gunnar Hellstrom. These were > addressed in version 19. > > At least Magnus Westerlund and Flemming Andreasen did a thorough review > of the document as part of the WGLC on version 18. > > Version 18 was sent to the ietf-types mailing list for review on April > 4, 2012. Bjorern Hoehrmann and Magnus Westerlund posted comments that > were addressed in version 19. > > Personnel > > Who is the Document Shepherd? Who is the Responsible Area > Director? > > Miguel A. Garcia is the Document Shepherd. Gonzalo Camarillo is the > Responsible Area Director > From brian.rosen@neustar.biz Tue Jan 15 08:48:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C855421F8496 for ; Tue, 15 Jan 2013 08:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfryO7vIi9aa for ; Tue, 15 Jan 2013 08:48:06 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8012021F84C8 for ; Tue, 15 Jan 2013 08:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1358268476; x=1673622862; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ngTk3nViXZB7sU/1DPsoR VrCQ9bTL4MyJpK0AwlY9yg=; b=FdXWiiTILeBQg/1gMlQqRysf+Z/GCV9ULR4Te NvnAbug4Z8NpZrEXJbgeOI0ELtg6FzY4sSfcIN+LnatCkdDBQ== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP id J041123128.13960410; Tue, 15 Jan 2013 11:47:55 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 15 Jan 2013 11:48:02 -0500 From: "Rosen, Brian" To: Paul Kyzivat Date: Tue, 15 Jan 2013 11:48:01 -0500 Thread-Topic: [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) Thread-Index: Ac3zQBTaNPkx6w76R1Kw2GRmfAEipw== Message-ID: <00FB847D-668F-4EBA-B2DF-28FFD734F486@neustar.biz> References: <20130115154532.11812.87070.idtracker@ietfa.amsl.com> <50F5862B.30906@alum.mit.edu> In-Reply-To: <50F5862B.30906@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: dx0LuE/MNev/KfpexO7CBw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Jan 2013 08:58:52 -0800 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:48:06 -0000 Thank you Hadriel for finally getting this finished! Brian On Jan 15, 2013, at 11:39 AM, Paul Kyzivat wrote: > Wow - finally! >=20 > -00 was in December 2004!. Not a record, but up there. >=20 > Paul >=20 > On 1/15/13 10:45 AM, The IESG wrote: >> The IESG has approved the following document: >> - 'An Extension to the Session Description Protocol (SDP) and Real-time >> Transport Protocol (RTP) for Media Loopback' >> (draft-ietf-mmusic-media-loopback-27.txt) as Proposed Standard >>=20 >> This document is the product of the Multiparty Multimedia Session Contro= l >> Working Group. >>=20 >> The IESG contact persons are Gonzalo Camarillo and Robert Sparks. >>=20 >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ >>=20 >>=20 >>=20 >>=20 >> Technical Summary >>=20 >> This document provides extensions to the Session Description Protocol >> (SDP) and the Real-time Transport Protocol (RTP) for enabling looping >> of sent media. 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. The extension defined herein adds new SDP media >> types and attributes, which enable 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. >>=20 >> Working Group Summary >>=20 >> The first version of the document was available at the end of 2004. >> Since that time, the working group has been discussing a number of >> issues toward getting the consensus that is believed to be achieved in >> version 22. >>=20 >> The description of a latching mechanism to traverse NATs and firewalls >> was discussed and decided to be removed from the actual document in >> favor of standard NAT traversal techniques such as ICE/STUN/TURN. >>=20 >> Document Quality >>=20 >> At least four implementations of this functionality are known. Four >> other vendors have indicated they plan to implement it. >>=20 >> The document was WGLCed on version 16. Additionally, the PAYLOAD WG >> also conducted a thorough review of the same 16 version. As a result of >> these reviews, 34 changes were requested by, among others, Tolga >> Asveren, Dan Wing, Emil Ivov, Flemming Andreasen, and Miguel A. Garcia. >> These comments were subsequently introduced into versions 17 and 18. A >> new WGLC was issued on version 18, bringing a new set of comments by >> Flemming Andreasen, Magnus Westerlund, and Gunnar Hellstrom. These were >> addressed in version 19. >>=20 >> At least Magnus Westerlund and Flemming Andreasen did a thorough review >> of the document as part of the WGLC on version 18. >>=20 >> Version 18 was sent to the ietf-types mailing list for review on April >> 4, 2012. Bjorern Hoehrmann and Magnus Westerlund posted comments that >> were addressed in version 19. >>=20 >> Personnel >>=20 >> Who is the Document Shepherd? Who is the Responsible Area >> Director? >>=20 >> Miguel A. Garcia is the Document Shepherd. Gonzalo Camarillo is the >> Responsible Area Director >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Wed Jan 16 04:11:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E4521F86A5 for ; Wed, 16 Jan 2013 04:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQLCK3HTJqav for ; Wed, 16 Jan 2013 04:11:20 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 282E221F869F for ; Wed, 16 Jan 2013 04:11:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 764A039E2D8 for ; Wed, 16 Jan 2013 13:11:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTSB5oHuyPH7 for ; Wed, 16 Jan 2013 13:11:13 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6CE3939E127 for ; Wed, 16 Jan 2013 13:11:10 +0100 (CET) Message-ID: <50F698DD.6020505@alvestrand.no> Date: Wed, 16 Jan 2013 13:11:09 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 12:11:21 -0000 Thanks for getting this out! This is basically 2 days for grouping in SDP (with a slice off for data channels), and 1 day for trickle ICE and all the other issues in JSEP. I would be happy if the chairs could update this draft agenda with links to the current drafts that pertain to each topic - in particular, that will give me some hints on what drafts I need to refresh before they expire; this discussion has been going on for quite some time! Harald On 01/14/2013 06:41 PM, Ted Hardie wrote: > Below is a proposed agenda which has been discussed among the RTCWEB > and MMUSIC chairs; comments welcome. > > Ted Hardie > > > Day 1 (February 5th, 2013) > > Multiple Flow SDP representation > > 90 minutes: Framing discussion (Magnus is working on text) > > 120 minutes: drafts discussion > > > Objective: decide on architecture for large numbers of similar streams > > SDP for Data channels > > 60 minutes: resolve open issues > > Day 2 (February 6, 2013) > > SDP Grouping (Bundle/MMT/one-rtp) > > 60 Minutes: framing discussion > > 120 Minutes: drafts discussion > > Objective: select an approach and provide direction to editors > > Mapping stream/track label concepts to SDP identifiers > > 60 minutes > > Objective: determine requirements > > Day 3: (February 7, 2013) > > Trickle ICE > > 120 minutes > > Objective: review offer/answer semantic impact; establish > initiation, termination and error handling > > JSEP > > 120 minutes > > Objective: review and resolve open issues with the document > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emcho@sip-communicator.org Wed Jan 16 05:09:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE7921F87DC for ; Wed, 16 Jan 2013 05:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drRwXy2j4vu8 for ; Wed, 16 Jan 2013 05:09:13 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2955621F8765 for ; Wed, 16 Jan 2013 05:09:12 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id i12so494487eaa.24 for ; Wed, 16 Jan 2013 05:09:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qJOEg2PCuuowJEAnBmo9G/QZdybUpMmm3cxzGbPpjpU=; b=mHOiICuxTewDit4h14Z4nEil3i03mWbe1LIjlg0eHtEG7zFeKbj/IWUsH3M/Z9nf/s qM7FZULjJZ0wrT+GHr79UPvgbT6U4MWOTnrlXJP8lfuKsTLA/DPNSorXPr4XoDh0dJ4Z asuqcwQdPjiFt/nUvgpiKX2DkHZ/aL+h9zYoTGkc5rik2oSQbHcNfFNF3qYLrrm6UJ+f 9zxLSozh3OhlR1iNpQpEA/Dp75QafkclNwR88yQS7Oyiyph26s2CIC1IjEVN2Ki10BIm xCwKOALJES7XexmPuLX35WBwaqk02Y/PLJWkYz0RpXgUZWi/hxa7iHPpT20Iz7JWlbff Y7Ig== X-Received: by 10.14.215.197 with SMTP id e45mr2893547eep.0.1358341751765; Wed, 16 Jan 2013 05:09:11 -0800 (PST) Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by mx.google.com with ESMTPS id z8sm29449949eeo.11.2013.01.16.05.09.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 05:09:11 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id c1so496205eaa.11 for ; Wed, 16 Jan 2013 05:09:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.14.205.198 with SMTP id j46mr2694035eeo.27.1358341750189; Wed, 16 Jan 2013 05:09:10 -0800 (PST) Received: by 10.14.184.199 with HTTP; Wed, 16 Jan 2013 05:09:09 -0800 (PST) Received: by 10.14.184.199 with HTTP; Wed, 16 Jan 2013 05:09:09 -0800 (PST) In-Reply-To: <50F698DD.6020505@alvestrand.no> References: <50F698DD.6020505@alvestrand.no> Date: Wed, 16 Jan 2013 14:09:09 +0100 Message-ID: From: Emil Ivov To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b3438ea80eebd04d36795c7 X-Gm-Message-State: ALoCoQmmNnxSNf8JFWrfIP2keJkBNNJD0odWMyDdiXHtJi/hTaOeRQfCUGdFJYblnBbP1iOVcPg1 Cc: mmusic Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 13:09:14 -0000 --047d7b3438ea80eebd04d36795c7 Content-Type: text/plain; charset=ISO-8859-1 On Jan 16, 2013 1:11 PM, "Harald Alvestrand" wrote: > > Thanks for getting this out! > > This is basically 2 days for grouping in SDP (with a slice off for data > channels), and 1 day for trickle ICE and all the other issues in JSEP. FWIW, we will be submitting a new trickle ICE revision in the following days. Incidentally, are there going to be arrangements for remote participation/presentation? Emil --sent from my mobile > I would be happy if the chairs could update this draft agenda with > links to the current drafts that pertain to each topic - in particular, > that will give me some hints on what drafts I need to refresh before > they expire; this discussion has been going on for quite some time! > > Harald > > > On 01/14/2013 06:41 PM, Ted Hardie wrote: >> >> Below is a proposed agenda which has been discussed among the RTCWEB >> and MMUSIC chairs; comments welcome. >> >> Ted Hardie >> >> >> Day 1 (February 5th, 2013) >> >> Multiple Flow SDP representation >> >> 90 minutes: Framing discussion (Magnus is working on text) >> >> 120 minutes: drafts discussion >> >> >> Objective: decide on architecture for large numbers of similar streams >> >> SDP for Data channels >> >> 60 minutes: resolve open issues >> >> Day 2 (February 6, 2013) >> >> SDP Grouping (Bundle/MMT/one-rtp) >> >> 60 Minutes: framing discussion >> >> 120 Minutes: drafts discussion >> >> Objective: select an approach and provide direction to editors >> >> Mapping stream/track label concepts to SDP identifiers >> >> 60 minutes >> >> Objective: determine requirements >> >> Day 3: (February 7, 2013) >> >> Trickle ICE >> >> 120 minutes >> >> Objective: review offer/answer semantic impact; establish >> initiation, termination and error handling >> >> JSEP >> >> 120 minutes >> >> Objective: review and resolve open issues with the document >> _______________________________________________ >> 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 --047d7b3438ea80eebd04d36795c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Jan 16, 2013 1:11 PM, "Harald Alvestrand" <<= a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> wrote:<= br> >
> Thanks for getting this out!
>
> This is basically 2 days for grouping in SDP (with a slice off for dat= a
> channels), and 1 day for trickle ICE and all the other issues in JSEP.=

FWIW, we will be submitting a new trickle ICE revision in th= e following days.

Incidentally, are there going to be arrangements for remote = participation/presentation?

Emil

--sent from my mobile

> I would be happy if the chairs could update this draft = agenda with
> links to the current drafts that pertain to each topic - in particular= ,
> that will give me some hints on what drafts I need to refresh before > they expire; this discussion has been going on for quite some time! >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald
>
>
> On 01/14/2013 06:41 PM, Ted Hardie wrote:
>>
>> Below is a proposed agenda which has been discussed among the RTCW= EB
>> and MMUSIC chairs; comments welcome.
>>
>> Ted Hardie
>>
>>
>> Day 1 (February 5th, 2013)
>>
>> Multiple Flow SDP representation
>>
>> =A0 =A0 =A0 =A0 90 minutes: Framing discussion (Magnus is working = on text)
>>
>> =A0 =A0 =A0 =A0120 minutes: drafts discussion
>>
>>
>> =A0 =A0 =A0 =A0Objective: decide on architecture for large numbers= of similar streams
>>
>> SDP for Data channels
>>
>> =A0 =A0 =A0 =A0 =A060 minutes: =A0resolve open issues
>>
>> Day 2 (February 6, 2013)
>>
>> SDP Grouping (Bundle/MMT/one-rtp)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 60 Minutes: framing discussion
>>
>> =A0 =A0 =A0 =A0 =A0 =A0120 Minutes: =A0drafts discussion
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Objective: select an approach and provide = direction to editors
>>
>> Mapping stream/track label concepts to SDP identifiers
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 60 minutes
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Objective: determine requirements
>>
>> Day 3: (February 7, 2013)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Trickle ICE
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 120 minutes
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Objective: review offer/answer semantic= impact; establish
>> initiation, termination and error handling
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0JSEP
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 120 minutes
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Objective: review and resolve open = issues with the document
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

--047d7b3438ea80eebd04d36795c7-- From fluffy@cisco.com Wed Jan 16 22:40:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C1E21F8B0E for ; Wed, 16 Jan 2013 22:40:16 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS85W9Ohhh3O for ; Wed, 16 Jan 2013 22:40:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4821F8B06 for ; Wed, 16 Jan 2013 22:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=143; q=dns/txt; s=iport; t=1358404815; x=1359614415; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9lLqZLi54X8DTfUU817jtZ1L5xTYpt7k3YcvFPgYUJ0=; b=UlhvbhFc6mr7lsHH4jHKCK1Tdo+MyFhaiJ7sS19Vejs5+EHuar6EOO+V gC1pjv7mw5xPtxOgS7lU+SXTJHRMPdFZx/4pvN1Slawxphd92q0/294EU cdpQKUGjKGONYVPfd5lQir4Dg1695fYUXow+8N6CSs1YWqPTbjvEhuTkQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAGAM2b91CtJXG+/2dsb2JhbAAjIb4HFnOCIAEEOlEBKhRCJwQbiBGZQp95kFdhA6ZVgnWCJA X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="163626027" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jan 2013 06:40:15 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0H6eFZC030654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Jan 2013 06:40:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 00:40:14 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" Thread-Topic: draft-reddy-mmusic-stun-auth-fw-traversal-00 Thread-Index: AQHN9H2BXJyM1Np+RkOI2lo8vjcfMw== Date: Thu, 17 Jan 2013 06:40:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] draft-reddy-mmusic-stun-auth-fw-traversal-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 06:40:16 -0000 Why is this draft in music - it seems like a STUN extension. (I understand = an AD might have sent it here but I'm still not getting why?) From mperumal@cisco.com Thu Jan 17 01:52:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31B21F8650 for ; Thu, 17 Jan 2013 01:52:42 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50cMMqBxFHCg for ; Thu, 17 Jan 2013 01:52:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3921F863F for ; Thu, 17 Jan 2013 01:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1358416361; x=1359625961; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=c/1xrrLUlO6WTpJt69GBhIe1yraH1JXbMuN/mjxPiOE=; b=SAvG7RIHrYnQqNYu28fJ9xzZ944wCZeFWDs8x6NOyqMqhZoxANH5mP2l EXE6YPxYbXijSYtLmr4vZnK3MU6SEaYN1Eh6A96VbJp7UlYGEOqbKkpNy tTZ6eTa0rIoPgyDEWUaCfpZW9dTRITXL5+c6PAOT41ygiYXFxqsIemo+c s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0FAOHI91CtJXG+/2dsb2JhbABEhXe4KBZzgh4BAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCIgRDLk8BJBXYQOmVYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="163695448" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jan 2013 09:52:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0H9qf0D006893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Jan 2013 09:52:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.7]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 03:52:41 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Cullen Jennings (fluffy)" , "mmusic@ietf.org WG" Thread-Topic: draft-reddy-mmusic-stun-auth-fw-traversal-00 Thread-Index: AQHN9H2BXJyM1Np+RkOI2lo8vjcfM5hNRTWg Date: Thu, 17 Jan 2013 09:52:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.28.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] draft-reddy-mmusic-stun-auth-fw-traversal-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:52:42 -0000 The draft was initially submitted to RTCWEB since it describes a WebRTC use= -case. The authors were informed by the AD that all the ICE extensions, inc= luding all RTCWEB-related ICE extensions, will be done in MMUSIC and the dr= aft needs to be discussed in MMUSIC. Is BEHAVE a better option? Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f Cullen Jennings (fluffy) |Sent: Thursday, January 17, 2013 12:10 PM |To: mmusic@ietf.org WG |Subject: [MMUSIC] draft-reddy-mmusic-stun-auth-fw-traversal-00 | | |Why is this draft in music - it seems like a STUN extension. (I understand= an AD might have sent it |here but I'm still not getting why?) | | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From tireddy@cisco.com Thu Jan 17 03:19:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652EC21F8B6C for ; Thu, 17 Jan 2013 03:19:57 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoRkoh+WzSTv for ; Thu, 17 Jan 2013 03:19:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCDF21F8B29 for ; Thu, 17 Jan 2013 03:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11930; q=dns/txt; s=iport; t=1358421596; x=1359631196; h=from:to:subject:date:message-id:mime-version; bh=T895+3ZpyOPabhEr85yIxc+3eKg6yN5mUitxP8u5Oj4=; b=VtDgowvfwM9Ty+9MnpUlP0u+qYChZ20L8XVBGXnKwGLulK+E9LAst2hh hlhMXSpMiaKmiofFC87ftxUY30JKho9q4z8yAsRmcCTqVWVEyL3FNb82/ fHaRRojY1HA6ZdV43PenkihdYSaOhSCQ7GD+AZur/QNjQXgcJtl1KMt8A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAAvd91CtJXHA/2dsb2JhbABEgkiBLYJQpS+JDAGII38Wc4IeAQEBBCMKSg4GAQgRBAEBCx0DAgQwFAcBAQUFBBMIAYgQBwWZYY5VkSKQJTJhA5cojy2CdYIk X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208,217";a="163735087" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jan 2013 11:19:56 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0HBJthr032324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Jan 2013 11:19:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 05:19:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-03.txt Thread-Index: AQHN9HvPIDTTOXLWHUeV8k1F5HhrPphNVWlw Date: Thu, 17 Jan 2013 11:19:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148E5642@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.127] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A148E5642xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 11:19:57 -0000 --_000_913383AAA69FF945B8F946018B75898A148E5642xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 d2UgaGF2ZSBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gdGhlIFdHIGFuZCB1 cGRhdGVkIHZlcnNpb24gb2YgTW9iaWxpdHkgd2l0aCBJQ0UgKE1JQ0UpIGhhcyBiZWVuIHN1Ym1p dHRlZC4NCg0KDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctbW11c2lj LWljZS1tb2JpbGl0eS0wMw0KDQoNCg0KQWxsIGNoYW5nZXMgYXJlIHNwZWNpZmljIHRvIE1vYmls aXR5IHVzaW5nIElDRS4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50 cywgc3VnZ2VzdGlvbnMgdG8gaW1wcm92ZSB0aGUgZHJhZnQuDQoNCg0KDQpUaGFua3MNCg0KLS1h dXRob3JzLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDE3LCAyMDEzIDExOjU4IEFNDQpUbzogVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KQ0KQ2M6IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBQYWwgTWFydGlu c2VuIChwYWxtYXJ0aSk7IERhbiBXaW5nIChkd2luZykNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTAzLnR4dA0KDQoN Cg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxp dHktMDMudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVz d2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlDQoNCklFVEYgcmVwb3NpdG9yeS4NCg0KDQoNCkZp bGVuYW1lOiAgIGRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eQ0KDQpSZXZpc2lvbjogICAw Mw0KDQpUaXRsZTogICAgICAgICAgICBNb2JpbGl0eSB3aXRoIElDRSAoTUlDRSkNCg0KQ3JlYXRp b24gZGF0ZTogICAgMjAxMy0wMS0xNw0KDQpXRyBJRDogICAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCg0KTnVtYmVyIG9mIHBhZ2VzOiAxNw0KDQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2Jp bGl0eS0wMy50eHQNCg0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eQ0KDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0 eS0wMw0KDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS0wMw0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAg IFRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgaG93IGVuZHBvaW50IG1vYmlsaXR5IGNhbiBi ZSBhY2hpZXZlZA0KDQogICB1c2luZyBJQ0UuICBUd28gbWVjaGFuaXNtcyBhcmUgc2hvd24sIG9u ZSB3aGVyZSBib3RoIGVuZHBvaW50cw0KDQogICBzdXBwb3J0IElDRSBhbmQgYW5vdGhlciB3aGVy ZSBvbmx5IG9uZSBlbmRwb2ludCBzdXBwb3J0cyBJQ0UuDQoNCg0KDQoNCg0KDQoNCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A148E5642xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25z ICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNl Y3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPndlIGhhdmUgYWRkcmVzc2VkIHRoZSBjb21tZW50 cyByZWNlaXZlZCBmcm9tIHRoZSBXRyBhbmQgdXBkYXRlZCB2ZXJzaW9uIG9mIE1vYmlsaXR5IHdp dGggSUNFIChNSUNFKSBoYXMgYmVlbiBzdWJtaXR0ZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1t bXVzaWMtaWNlLW1vYmlsaXR5LTAzIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDM8L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+QWxsIGNoYW5nZXMgYXJlIHNwZWNpZmljIHRvIE1vYmlsaXR5IHVzaW5nIElDRS4gUGxl YXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cywgc3VnZ2VzdGlvbnMgdG8g aW1wcm92ZSB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS1hdXRob3JzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gPGJyPg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTcsIDIwMTMgMTE6NTggQU08YnI+ DQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCkNjOiBQcmFzaGFudGggUGF0 aWwgKHByYXNwYXRpKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBEYW4gV2luZyAoZHdpbmcp PGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW5nLW1t dXNpYy1pY2UtbW9iaWxpdHktMDMudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS0wMy50eHQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkZpbGVuYW1lOiZuYnNwOyZuYnNwOyBkcmFmdC13aW5nLW1tdXNp Yy1pY2UtbW9iaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJl dmlzaW9uOiZuYnNwOyZuYnNwOyAwMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1vYmlsaXR5IHdpdGggSUNFIChNSUNFKTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q3JlYXRpb24gZGF0ZTombmJzcDsmbmJzcDsm bmJzcDsgMjAxMy0wMS0xNzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ V0cgSUQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+TnVtYmVyIG9mIHBhZ2VzOiAxNzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9i aWxpdHktMDMudHh0Ij4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS0wMy50eHQ8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5Ij4NCmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS0wMyI+DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDM8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaWZmOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13aW5nLW1tdXNpYy1p Y2UtbW9iaWxpdHktMDMiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt d2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTAzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGhvdyBlbmRwb2ludCBtb2Jp bGl0eSBjYW4gYmUgYWNoaWV2ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyB1c2luZyBJQ0UuJm5ic3A7IFR3byBtZWNoYW5pc21zIGFyZSBzaG93 biwgb25lIHdoZXJlIGJvdGggZW5kcG9pbnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc3VwcG9ydCBJQ0UgYW5kIGFub3RoZXIgd2hlcmUgb25s eSBvbmUgZW5kcG9pbnQgc3VwcG9ydHMgSUNFLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo ZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A148E5642xmbrcdx10ciscoc_-- From iesg-secretary@ietf.org Fri Jan 18 07:31:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FE521F890D; Fri, 18 Jan 2013 07:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW0yf9fWkeWi; Fri, 18 Jan 2013 07:31:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2988221F88E8; Fri, 18 Jan 2013 07:31:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130118153147.27107.27976.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2013 07:31:47 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:31:47 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ballot/ No IPR declarations have been submitted directly on this I-D. From btv1==7306b30e559==HKaplan@acmepacket.com Fri Jan 18 11:33:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A539621F8630 for ; Fri, 18 Jan 2013 11:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puw4Icey8Qc3 for ; Fri, 18 Jan 2013 11:33:27 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id C65AC21F8613 for ; Fri, 18 Jan 2013 11:33:26 -0800 (PST) X-ASG-Debug-ID: 1358537603-03fc200e92d8a740001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id ifc5lQ2tX36mIX55 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jan 2013 14:33:23 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Fri, 18 Jan 2013 14:33:23 -0500 From: Hadriel Kaplan To: "rtcweb@ietf.org" , "public-webrtc@w3.org" , "mmusic@ietf.org (E-mail)" , "public-media-capture@w3.org" Thread-Topic: February Interim registration and logistics X-ASG-Orig-Subj: February Interim registration and logistics Thread-Index: AQHN9bKtJlsqwRqOpESjXFiKxPyc6Q== Date: Fri, 18 Jan 2013 19:33:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1358537603 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.120227 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: Dominique Hazael-Massieux , "rai-ads@tools.ietf.org" , "rtcweb-chairs@tools.ietf.org" , =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Harald Alvestrand , "" Subject: [MMUSIC] February Interim registration and logistics X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 19:37:29 -0000 Howdy, We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF MM= USIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at ou= r Corporate Galactic Headquarters in Bedford, Massachusetts.=20 Please register at the following page if you plan to attend: http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c The logistics/venue info page is here: http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics You should NOT register if you're only going to attend remotely. Details f= or remote participation will be sent out later on the relevant mailing list= s. We hope to see you here! And bring warm clothing - it's slightly chilly. ;) -hadriel p.s. We've tested the registration page on several browsers and it works ge= nerally, except for on Lynx, Links, or Elinks. (Lynx and Links because they= don't support Javascript, but why it doesn't work on Elinks w/SpiderMonkey= I haven't looked into) The logistics page seems to work on all browsers.= =20 :) From internet-drafts@ietf.org Mon Jan 21 05:53:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168BD21F87AD; Mon, 21 Jan 2013 05:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG78aV+Cs7gy; Mon, 21 Jan 2013 05:53:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCED21F87B6; Mon, 21 Jan 2013 05:53:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130121135324.11308.20027.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 05:53:24 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jan 2013 13:53:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media = Transport in the Session Description Protocol (SDP) Author(s) : Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-03.txt Pages : 14 Date : 2013-01-21 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Mon Jan 21 21:52:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CD721F87F3; Mon, 21 Jan 2013 21:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6SW-O0MMl8h; Mon, 21 Jan 2013 21:52:00 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9882121F87EE; Mon, 21 Jan 2013 21:51:59 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id f13so2839424eaa.3 for ; Mon, 21 Jan 2013 21:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=6cHenttU8V4siuJsLZ+k5EUcmfq3KW6DnOhb39MI1fM=; b=b4bY3hLqwEt5mMpmoD16E7HqYdFA7NCGywXK8GcDOjf2GSzZKat6R0T8IKYxxcFxpA LetwmxeQGcIv0CDoI92wQk35dRqyZId30Y1mCFoRtFrWgWbJhzr5WZ/ijYZV5DTqKlyf qay2uIKobyWkiB6M8ZQpXDY0jyjWZCc77TJqlqQ/18qhIbECLOrWxZDC6m+9UIqEJ9Ke m10g1PQHms1bl4rgw0Te4Mukz49HbsZ/qQxfwcJyIuO30/waB1BcjtyzjM+6MlhggdGN uW+Kr1QA6OasRskAlxko6RZMb8YhzPRnltSdSOGoMCEgjbFDbWk3TQmwo3rsiDNUCN3s N1ag== X-Received: by 10.14.213.134 with SMTP id a6mr69068759eep.45.1358833918716; Mon, 21 Jan 2013 21:51:58 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id t44sm25496694eeo.2.2013.01.21.21.51.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Jan 2013 21:51:57 -0800 (PST) From: "Roni Even" To: "'Ted Hardie'" , , References: In-Reply-To: Date: Tue, 22 Jan 2013 07:49:04 +0200 Message-ID: <004801cdf864$325287e0$96f797a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCYsEIPwdLZ6w2lmT6EdTEcbci6JbsAgcg Content-Language: en-us Cc: 'Cullen Jennings' , 'Magnus Westerlund' , =?ISO-8859-1?Q?'Ari_Ker=E4nen'?= , 'Gonzalo Camarillo' , 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jan 2013 05:52:01 -0000 Hi, I am not sure what will be discussed in multiple flow SDP representation = and Mapping stream/track label concepts to SDP identifiers. Are there drafts = or is it an open discussion. What about the relation of these two topics to CLUE? Thanks Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Ted Hardie Sent: 14 January, 2013 7:41 PM To: rtcweb@ietf.org; mmusic@ietf.org Cc: Cullen Jennings; Magnus Westerlund; Ari Ker=E4nen; Gonzalo = Camarillo; Flemming Andreasen Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting Below is a proposed agenda which has been discussed among the RTCWEB and MMUSIC chairs; comments welcome. Ted Hardie Day 1 (February 5th, 2013) Multiple Flow SDP representation 90 minutes: Framing discussion (Magnus is working on text) 120 minutes: drafts discussion Objective: decide on architecture for large numbers of similar = streams SDP for Data channels 60 minutes: resolve open issues Day 2 (February 6, 2013) SDP Grouping (Bundle/MMT/one-rtp) 60 Minutes: framing discussion 120 Minutes: drafts discussion Objective: select an approach and provide direction to = editors Mapping stream/track label concepts to SDP identifiers 60 minutes Objective: determine requirements Day 3: (February 7, 2013) Trickle ICE 120 minutes Objective: review offer/answer semantic impact; establish initiation, termination and error handling JSEP 120 minutes Objective: review and resolve open issues with the = document _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Tue Jan 22 00:16:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867BD21F856F; Tue, 22 Jan 2013 00:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.038 X-Spam-Level: X-Spam-Status: No, score=-101.038 tagged_above=-999 required=5 tests=[AWL=-5.146, BAYES_00=-2.599, FS_BROKEN_MEETING=10.357, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxTzJ9Xxal-3; Tue, 22 Jan 2013 00:16:10 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4206421F84B6; Tue, 22 Jan 2013 00:16:09 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-3d-50fe4ac8268f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9A.0D.32353.8CA4EF05; Tue, 22 Jan 2013 09:16:08 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 22 Jan 2013 09:16:07 +0100 Message-ID: <50FE4AC7.4010508@ericsson.com> Date: Tue, 22 Jan 2013 09:16:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <1.e0d2fbab2393f09b6fda@gmail.com> In-Reply-To: <1.e0d2fbab2393f09b6fda@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvre4Jr38BBhs+Cli8v6Br0TGZzWLq 8scsFn/bmS3W/mtnt2ica+fA5jHl90ZWj52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoEr49HC iUwFk6Urrryfy9jA+FC0i5GTQ0LARGLOwlmsELaYxIV769m6GLk4hAROMkrMWDqXHcJZziix 5fVJFpAqXgFtictvr4LZLAKqEl97VzGD2GwCFhI3fzSygdiiAsESGw6uYoKoF5Q4OfMJWL2I gJrE67WfwTYwC8xkknh07DhYkbBAgMS6T7vBbCGBYokF/36BDeUU0Jf4uPsEUAMH0HniEmve cICEmQX0JKZcbWGEsOUlmrfOZoZo1ZZoaOpgncAoNAvJ6llIWmYhaVnAyLyKkT03MTMnvdx8 EyMwrA9u+W2wg3HTfbFDjNIcLErivOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM4M ZHIr3xMraLJoR1gzm/bRzE9qdacK3kpu3S0u/9tabrX6ouI3Jyeye2+TDv7d/FzkvZzvgg9d 0ktSP+Vc8f2ldX9ib2q9/f3j5exXOyanOghvk/aS3P/9r25xSH4sW4f10w/Tis2339Moe3J/ 3s6QcPFjU9ln6zj9cPCs//7Cr0vQaTZjhhJLcUaioRZzUXEiAEgFYYY5AgAA Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?=27Ari_Ker=E4nen=27?= , mmusic@ietf.org, 'Gonzalo Camarillo' , 'Flemming Andreasen' , rtcweb@ietf.org Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jan 2013 08:16:10 -0000 On 2013-01-22 06:49, Roni Even wrote: > Hi, > I am not sure what will be discussed in multiple flow SDP representation > and This is a very fundamental choice of how SDP is going to deal with RTP sessions that include multiple media streams, i.e. SSRCs carrying different media sources and negotiation of media stream related information and parameters. I understand some drafts are under preparation here. This is definitely something that will impact CLUE also. > Mapping stream/track label concepts to SDP identifiers. Are there drafts or > is it an open discussion. This is more an WebRTC focused issues, but it has clearly overlap with the relations discussion on how you identify media sources, different encodings of the same media stream (in simulcast and scalable coding) their repair streams all the way up to WebRTC specific concepts of MediaStream. For this my colleagues and I are preparing a draft. I don't expect it to be available before second half of next week. I think this is relevant for CLUE in the perspective of trying to understand what is common abstractions and what is not. Cheers Magnus > What about the relation of these two topics to CLUE? > > Thanks > Roni Even > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: 14 January, 2013 7:41 PM > To: rtcweb@ietf.org; mmusic@ietf.org > Cc: Cullen Jennings; Magnus Westerlund; Ari Keränen; Gonzalo Camarillo; > Flemming Andreasen > Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm > meeting > > Below is a proposed agenda which has been discussed among the RTCWEB and > MMUSIC chairs; comments welcome. > > Ted Hardie > > > Day 1 (February 5th, 2013) > > Multiple Flow SDP representation > > 90 minutes: Framing discussion (Magnus is working on text) > > 120 minutes: drafts discussion > > > Objective: decide on architecture for large numbers of similar streams > > SDP for Data channels > > 60 minutes: resolve open issues > > Day 2 (February 6, 2013) > > SDP Grouping (Bundle/MMT/one-rtp) > > 60 Minutes: framing discussion > > 120 Minutes: drafts discussion > > Objective: select an approach and provide direction to editors > > Mapping stream/track label concepts to SDP identifiers > > 60 minutes > > Objective: determine requirements > > Day 3: (February 7, 2013) > > Trickle ICE > > 120 minutes > > Objective: review offer/answer semantic impact; establish > initiation, termination and error handling > > JSEP > > 120 minutes > > Objective: review and resolve open issues with the document > _______________________________________________ > 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 -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From prvs=07349a02ec=aallen@rim.com Tue Jan 22 01:55:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657EB21F8726; Tue, 22 Jan 2013 01:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrnKXIo7Fnwo; Tue, 22 Jan 2013 01:55:21 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 719B321F871D; Tue, 22 Jan 2013 01:55:21 -0800 (PST) X-AuditID: 0a412830-b7f646d0000038d1-82-50fe61fd1525 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 30.E2.14545.DF16EF05; Tue, 22 Jan 2013 03:55:09 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0318.001; Tue, 22 Jan 2013 03:55:09 -0600 From: Andrew Allen To: Roni Even , 'Ted Hardie' , "rtcweb@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting Thread-Index: AQHN+GSeGNSqJdYUWUGV+w3VmBsFRZhVGrbA Date: Tue, 22 Jan 2013 09:55:08 +0000 Message-ID: References: <004801cdf864$325287e0$96f797a0$@gmail.com> In-Reply-To: <004801cdf864$325287e0$96f797a0$@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNKsWRmVeSWpSXmKPExsXC5Zyvpfs38V+Awczz1hbXrv1ns3h/Qdei YzKbxablK5ksLq2/x2QxdfljFou/7cwWa/+1s1s0zrVz4PSY8nsjq8evr1fZPHbOusvusWTJ T6YAlqgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzE zNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bns r2thYWqpa6hkp5vQyZOx+NhcpoIW8YqXs5+xNTA+FOxi5OSQEDCRWHKohxXCFpO4cG89Wxcj F4eQQBuTxKZVB1khnM2MEhOeb2UHqWITUJZY/nsGI0hCRGAqo8SN3u1g7cwgLROOy3cxcnAI CwRLLJpuBBIWEQiR2HD9ATOEbSTx7k8fC4jNIqAq0T9/KpjNK+Ahce3vIUYQW0igTqL3fhtY PaeAhcThuzvBxjMKyErsPnudCWKVuMStJ/OZIK4WkFiy5zwzhC0q8fLxP6hvFCVm7JkPdZqe xI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMQrmZhQbmBkm5yXr FWXm6uWllmxiBKUeRw2DHYzv31scYhTgYFTi4c0CpiQh1sSy4srcQ4wSHMxKIryCwUAh3pTE yqrUovz4otKc1OJDjK7AUJnILMWdnA9Mi3kl8cYGBrg5SuK8/P1/A4QE0oFpKTs1tSC1CGYO EwcnyB4uKZFiYHJJLUosLcmIB6XA+GJgEpRqYFx69XZ/D8ep/vtmBdsCk5b03ir3mxlYN4Xh kY7HwylJClHhddOvTv8VXJyzPNr+f6pECfdnpqPfp3apRFumPPORWtdnxVTDrLRqd9Tjzs5t LK77l7+Q+Pb3oNHm96lxscf/H314I/LGbS7tx9OurHMx5tq0MyBmvdKWEPbXnjtzbdPO9a+J tlFiKc5INNRiLipOBADcqoNKfgMAAA== Cc: 'Cullen Jennings' , 'Magnus Westerlund' , =?iso-8859-1?Q?=27Ari_Ker=E4nen=27?= , 'Gonzalo Camarillo' , 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jan 2013 09:55:22 -0000 I think it would be better if the JSEP discussion could take place on the ei= ther day 1 or day 2 so there is some time for offline discussion before the= end of the of the meeting. I think there are some important concerns here w= hich we need to reach resolution on. What are the times for the start and end schedule each day? Adding up the hours it seems that it should be possible to fit more into Day= 1 and Day 2 and still only do a full "IETF work day". Andrew -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Roni Even Sent: Tuesday, January 22, 2013 12:49 AM To: 'Ted Hardie'; rtcweb@ietf.org; mmusic@ietf.org Cc: 'Cullen Jennings'; 'Magnus Westerlund'; 'Ari Ker=E4nen'; 'Gonzalo Camari= llo'; 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm me= eting Hi, I am not sure what will be discussed in multiple flow SDP representation and= Mapping stream/track label concepts to SDP identifiers. Are there drafts or= is it an open discussion. What about the relation of these two topics to CLUE? Thanks Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: 14 January, 2013 7:41 PM To: rtcweb@ietf.org; mmusic@ietf.org Cc: Cullen Jennings; Magnus Westerlund; Ari Ker=E4nen; Gonzalo Camarillo; Fl= emming Andreasen Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm meetin= g Below is a proposed agenda which has been discussed among the RTCWEB and MMU= SIC chairs; comments welcome. Ted Hardie Day 1 (February 5th, 2013) Multiple Flow SDP representation 90 minutes: Framing discussion (Magnus is working on text) 120 minutes: drafts discussion Objective: decide on architecture for large numbers of similar streams SDP for Data channels 60 minutes: resolve open issues Day 2 (February 6, 2013) SDP Grouping (Bundle/MMT/one-rtp) 60 Minutes: framing discussion 120 Minutes: drafts discussion Objective: select an approach and provide direction to editors Mapping stream/track label concepts to SDP identifiers 60 minutes Objective: determine requirements Day 3: (February 7, 2013) Trickle ICE 120 minutes Objective: review offer/answer semantic impact; establish initia= tion, termination and error handling JSEP 120 minutes Objective: review and resolve open issues with the document __= _____________________________________________ 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ron.even.tlv@gmail.com Tue Jan 22 02:44:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9668321F8464; Tue, 22 Jan 2013 02:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=-5.178, BAYES_00=-2.599, FS_BROKEN_MEETING=10.357, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSbngufe1oCo; Tue, 22 Jan 2013 02:44:52 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6772621F8461; Tue, 22 Jan 2013 02:44:51 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so3435529eek.13 for ; Tue, 22 Jan 2013 02:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=2D/vyBdfThW//9yWAfDx1SXCVW6BXlLM/TuV7fl61AQ=; b=I3OR7HrYBup2RlblZfH+HgfOw5Np7qveetGHo7WxXzYLTE9avsxNSUGu+Hx2qV/laN JwcDnxg3puLs+nXS66ygEDZgdsBL7HH9RZHbNrXZHuElZ1HzdsYfj7uHdxDsaPIoftZa SePOvnbLkrq+Cw/iPKHAlsFVT+fcFXACOmW+jhR04whk9v8FPR/oKKtyAypNoTHgbg0f hAwamc9Wz62vCLqEfaizngSBUMuQH9kPp6Aest2mVYICB1/ntdx3X631+F15wNxHWXRn jvJTX+jANAbbM/G/0AgawlfumPJZyqGPbLIP7pXZqO+sEgS71qCPoSXcPW+PVWyMOV3d hhXg== X-Received: by 10.14.202.3 with SMTP id c3mr71863115eeo.4.1358851490500; Tue, 22 Jan 2013 02:44:50 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id k4sm26500384eep.15.2013.01.22.02.44.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Jan 2013 02:44:48 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" References: <1.e0d2fbab2393f09b6fda@gmail.com> <50FE4AC7.4010508@ericsson.com> In-Reply-To: <50FE4AC7.4010508@ericsson.com> Date: Tue, 22 Jan 2013 12:41:54 +0200 Message-ID: <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCYsEIPwdLZ6w2lmT6EdTEcbci6ADpB3QcAxbfwFiWzE+GoA== Content-Language: en-us Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?'Ari_Ker=E4nen'?= , mmusic@ietf.org, 'Gonzalo Camarillo' , 'Flemming Andreasen' , rtcweb@ietf.org Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jan 2013 10:44:52 -0000 Hi Magnus, My concern is that it is not easy to provide a proposal to a subject = that is not clear. I also have views about these topics but seeing no = requirements or use cases it is difficult to write a draft. I believe that the actual syntax depends on the bundle decision so any = work now need to assume a bundle architecture. Are there any requirements for a solution even if we are looking for a = new way or to leverage existing mechanisms like RFC 5576. I will try to write something based on the CLUE RTP mapping draft we are discussing that tries to address a similar problem as far as I = understand. BTW: will these drafts be MMUSIC drafts or RTCweb? Thanks Roni Even -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: 22 January, 2013 10:16 AM To: Roni Even Cc: 'Ted Hardie'; rtcweb@ietf.org; mmusic@ietf.org; 'Cullen Jennings'; = 'Ari Ker=E4nen'; 'Gonzalo Camarillo'; 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting On 2013-01-22 06:49, Roni Even wrote: > Hi, > I am not sure what will be discussed in multiple flow SDP=20 > representation and This is a very fundamental choice of how SDP is going to deal with RTP sessions that include multiple media streams, i.e. SSRCs carrying = different media sources and negotiation of media stream related information and parameters. I understand some drafts are under preparation here. This is definitely something that will impact CLUE also. > Mapping stream/track label concepts to SDP identifiers. Are there=20 > drafts or is it an open discussion. This is more an WebRTC focused issues, but it has clearly overlap with = the relations discussion on how you identify media sources, different = encodings of the same media stream (in simulcast and scalable coding) their repair streams all the way up to WebRTC specific concepts of MediaStream. For this my colleagues and I are preparing a draft. I don't expect it to = be available before second half of next week. I think this is relevant for CLUE in the perspective of trying to = understand what is common abstractions and what is not. Cheers Magnus > What about the relation of these two topics to CLUE? >=20 > Thanks > Roni Even >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Ted Hardie > Sent: 14 January, 2013 7:41 PM > To: rtcweb@ietf.org; mmusic@ietf.org > Cc: Cullen Jennings; Magnus Westerlund; Ari Ker=E4nen; Gonzalo=20 > Camarillo; Flemming Andreasen > Subject: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirm=20 > meeting >=20 > Below is a proposed agenda which has been discussed among the RTCWEB=20 > and MMUSIC chairs; comments welcome. >=20 > Ted Hardie >=20 >=20 > Day 1 (February 5th, 2013) >=20 > Multiple Flow SDP representation >=20 > 90 minutes: Framing discussion (Magnus is working on text) >=20 > 120 minutes: drafts discussion >=20 >=20 > Objective: decide on architecture for large numbers of similar streams >=20 > SDP for Data channels >=20 > 60 minutes: resolve open issues >=20 > Day 2 (February 6, 2013) >=20 > SDP Grouping (Bundle/MMT/one-rtp) >=20 > 60 Minutes: framing discussion >=20 > 120 Minutes: drafts discussion >=20 > Objective: select an approach and provide direction to editors >=20 > Mapping stream/track label concepts to SDP identifiers >=20 > 60 minutes >=20 > Objective: determine requirements >=20 > Day 3: (February 7, 2013) >=20 > Trickle ICE >=20 > 120 minutes >=20 > Objective: review offer/answer semantic impact; establish initiation,=20 > termination and error handling >=20 > JSEP >=20 > 120 minutes >=20 > Objective: review and resolve open issues with the document=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 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Jan 22 03:01:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4121F86EF; Tue, 22 Jan 2013 03:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.009 X-Spam-Level: X-Spam-Status: No, score=-100.009 tagged_above=-999 required=5 tests=[AWL=-4.117, BAYES_00=-2.599, FS_BROKEN_MEETING=10.357, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlMn6xZd9o6r; Tue, 22 Jan 2013 03:01:18 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2621F8650; Tue, 22 Jan 2013 03:01:17 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-d7-50fe717c1401 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7B.FD.32353.C717EF05; Tue, 22 Jan 2013 12:01:16 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 22 Jan 2013 12:01:16 +0100 Message-ID: <50FE717A.7080302@ericsson.com> Date: Tue, 22 Jan 2013 12:01:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <1.e0d2fbab2393f09b6fda@gmail.com> <50FE4AC7.4010508@ericsson.com> <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> In-Reply-To: <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvrW5N4b8Ag5WzdC3eX9C16JjMZjF1 +WMWi7/tzBZr/7WzWzTOtXNg85jyeyOrx85Zd9k9liz5yRTAHMVlk5Kak1mWWqRvl8CV0ftY rmCeaMXZGa+ZGxi/CHQxcnJICJhIHN7znBnCFpO4cG89WxcjF4eQwElGiSnT+lghnOWMEofX tDCCVPEKaEtcuvaGFcRmEVCVmNWxnA3EZhOwkLj5oxHMFhUIlthwcBUTRL2gxMmZT1hAbBEB NYnXaz+DbWAWmMkk8ejYcbAiYYEAiXWfdjNBbNvPKLH2zmGwDZxAU/d/2sHexcgBdJ+4xJo3 HCBhZgE9iSlXIQ5iFpCXaN46G+wFIaDjGpo6WCcwCs1CsnsWkpZZSFoWMDKvYmTPTczMSS83 38QIDOuDW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzL VaTyLRedYT8va9SikGnJ6f18x0bxlxWTnVrco58+MD1tZx0sd6wiln/eRc6t0QFr6mujbpl9 UBfxOGTLu8qPS6Ose/XlytNTS4pCYz4p5v1RzHKIcp6fae9tfKu7c9vFq067Kn+/N5V3Ka2+ cl74SFWwff+9uTyNaWuXLNDZPE0tSKe+VYmlOCPRUIu5qDgRAE7PMK45AgAA Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?=27Ari_Ker=E4nen=27?= , mmusic@ietf.org, 'Gonzalo Camarillo' , 'Flemming Andreasen' , rtcweb@ietf.org Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jan 2013 11:01:18 -0000 On 2013-01-22 11:41, Roni Even wrote: > Hi Magnus, > My concern is that it is not easy to provide a proposal to a subject that is > not clear. I also have views about these topics but seeing no requirements > or use cases it is difficult to write a draft. > I believe that the actual syntax depends on the bundle decision so any work > now need to assume a bundle architecture. And I think the question of how one deals with multiple media streams in an RTP session is an important input into the BUNDLE discussion. > Are there any requirements for a solution even if we are looking for a new > way or to leverage existing mechanisms like RFC 5576. To my understanding what we are trying to achieve is making progress into three different subjects. 1) How multiple media streams are handled in SDP. I think there exist two proposal from the MMUSIC discussion: A) One media description per RTP session and media type. Each media stream are identified and provided with additional information using stream specific parameters. B) Each media description is a media stream and RTP sessions are then expressed as Bundle of media descriptions. 2) How "Bundle" is going to be done. Which of the three proposals do we really believe in. Note that direction of 1) will affect how commonly required the usage of "Bundle" will be. Thus affect the trade-off concerns. 3) What is common relations exist between concepts in WebRTC, CLUE and other multi-media communication contexts that needs to be identified and signalled and at what scopes. This influences the solution for MediaStream identities, our SRCNAME proposal in AVTEXT and CLUE work. There are a number of commonalities here that should be considered. > > I will try to write something based on the CLUE RTP mapping draft we are > discussing that tries to address a similar problem as far as I understand. Please do, the more informed everyone is, the better. > > BTW: will these drafts be MMUSIC drafts or RTCweb? > I don't know . I think ours is likely MMUSIC. I can't answer for the other contributions I expect. I guess the important is that all contributions are announced to the relevant WGs. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Tue Jan 22 05:21:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980CF21F85B1; Tue, 22 Jan 2013 05:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.879 X-Spam-Level: *** X-Spam-Status: No, score=3.879 tagged_above=-999 required=5 tests=[AWL=-4.738, BAYES_20=-0.74, FS_BROKEN_MEETING=10.357, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLRwAuo4sTyv; Tue, 22 Jan 2013 05:21:42 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4463621F84E7; Tue, 22 Jan 2013 05:21:41 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3359447eek.6 for ; Tue, 22 Jan 2013 05:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=DfByt1f/ETAPxKL9GHgD9ZjN+0ndDWCIyiQPuPtnAgI=; b=f81RNNqSCOMfO7RVZ6lRcq5FmGOZ6HLnoC7RIVStF/PWUkKYX6xZ/3+lx9TCSi+ZVb XfdKWqf6adllG1k4vsyvzayWVE6zoVb+MGpZIau08OrFuZzOaklm7EYz5jmSez29AZaf 6ErNbkioLZTrYRj7WiqnaZYwiQqjeQufRS4r7JDVsd7LK5f5JKe+mYph37qdi07/I/El 36s9Jjtn4dEoZ2Ar8P4n/JYXWbXrZJn97jrjb0IiypyPXZ8bi+tsEPjMVqa3CZL9ZaIW YpKjam29rqBIv6lFbvAc+VaqguALP5bQ501ebxZwpcIkDvVN0V2DwqcSX4cJWYa4GrM5 +FUQ== X-Received: by 10.14.213.134 with SMTP id a6mr72754712eep.45.1358860900096; Tue, 22 Jan 2013 05:21:40 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id q44sm26988975eep.5.2013.01.22.05.21.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Jan 2013 05:21:38 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" References: <1.e0d2fbab2393f09b6fda@gmail.com> <50FE4AC7.4010508@ericsson.com> <007d01cdf88d$1b4f2020$51ed6060$@gmail.com> <50FE717A.7080302@ericsson.com> In-Reply-To: <50FE717A.7080302@ericsson.com> Date: Tue, 22 Jan 2013 15:18:45 +0200 Message-ID: <008c01cdf8a3$047b7590$0d7260b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCYsEIPwdLZ6w2lmT6EdTEcbci6ADpB3QcAxbfwFgDRvVEFQJzmxlRlp6rPeA= Content-Language: en-us Cc: 'Cullen Jennings' , =?ISO-8859-1?Q?'Ari_Ker=E4nen'?= , mmusic@ietf.org, 'Gonzalo Camarillo' , 'Flemming Andreasen' , rtcweb@ietf.org Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jan 2013 13:21:42 -0000 Hi Magnus, Thanks, I think that the first subject is what we were also discussing = in CLUE when looking at RTP mapping and we considered the also the = individual drafts on maxssrc, and srcname. As for the two options I am not sure that we must chose. The first one = "A" is the current practice and I agree it is under specified today. The second on "B" depends on how we define bundle. Looking at option "B" = was suggested also for RTP mapping in CLUE (for example with regards to simulcast) Roni=20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: 22 January, 2013 1:01 PM To: Roni Even Cc: 'Ted Hardie'; rtcweb@ietf.org; mmusic@ietf.org; 'Cullen Jennings'; = 'Ari Ker=E4nen'; 'Gonzalo Camarillo'; 'Flemming Andreasen' Subject: Re: [MMUSIC] Proposed agenda for the joint MMUSIC/RTCWEB inteirmmeeting On 2013-01-22 11:41, Roni Even wrote: > Hi Magnus, > My concern is that it is not easy to provide a proposal to a subject=20 > that is not clear. I also have views about these topics but seeing no=20 > requirements or use cases it is difficult to write a draft. > I believe that the actual syntax depends on the bundle decision so any = > work now need to assume a bundle architecture. And I think the question of how one deals with multiple media streams in = an RTP session is an important input into the BUNDLE discussion. > Are there any requirements for a solution even if we are looking for a = > new way or to leverage existing mechanisms like RFC 5576. To my understanding what we are trying to achieve is making progress = into three different subjects. 1) How multiple media streams are handled in SDP. I think there exist = two proposal from the MMUSIC discussion: A) One media description per RTP session and media type. Each media stream are identified and provided with additional information using stream specific parameters. B) Each media description is a media stream and RTP sessions are then expressed as Bundle of media descriptions. 2) How "Bundle" is going to be done. Which of the three proposals do we really believe in. Note that direction of 1) will affect how commonly required the usage of "Bundle" will be. Thus affect the trade-off concerns. 3) What is common relations exist between concepts in WebRTC, CLUE and = other multi-media communication contexts that needs to be identified and = signalled and at what scopes. This influences the solution for MediaStream = identities, our SRCNAME proposal in AVTEXT and CLUE work. There are a number of commonalities here that should be considered. >=20 > I will try to write something based on the CLUE RTP mapping draft we=20 > are discussing that tries to address a similar problem as far as I understand. Please do, the more informed everyone is, the better. >=20 > BTW: will these drafts be MMUSIC drafts or RTCweb? >=20 I don't know . I think ours is likely MMUSIC. I can't answer for the = other contributions I expect. I guess the important is that all contributions = are announced to the relevant WGs. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ernst.horvath@siemens-enterprise.com Wed Jan 23 05:14:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BEC21F879E for ; Wed, 23 Jan 2013 05:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMh6KkuFix59 for ; Wed, 23 Jan 2013 05:14:02 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 37C7621F8635 for ; Wed, 23 Jan 2013 05:14:02 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 652581EB8629 for ; Wed, 23 Jan 2013 14:14:00 +0100 (CET) Received: from MCHP03MSX.global-ad.net ([169.254.2.130]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Wed, 23 Jan 2013 14:14:00 +0100 From: "Horvath, Ernst" To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sctp-sdp-03.txt Thread-Index: AQHN9969/VNAL3O2M0i8PLhllB3bNZhW3GCQ Date: Wed, 23 Jan 2013 13:13:59 +0000 Message-ID: References: <20130121135324.11308.20027.idtracker@ietfa.amsl.com> In-Reply-To: <20130121135324.11308.20027.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jan 2013 13:14:03 -0000 =20 I am sorry to say that the treatment of attributes in this I-D is a bit of = a mess.=20 - In 4.3 the attributes are introduced with a colon-notation, e.g. "a=3Dstr= eam:", but the ABNF definitions in 5.2 through 5.7 use a notation "a=3Dstre= am=3D" etc. The colon-notation is the more common one for SDP attributes. - Looking at the examples, I suspect that 'sctpmap' is the only real attrib= ute and the rest is meant to be parameters of an attribute 'webrtc-DataChan= nel', which appears in examples but is not defined in section 5. If this is= correct then 'webrtc-DataChannel' needs to be added as a new attribute in = section 5, and what is now in 5.2 - 5.7 should become sub-sections of this = attribute definition and be renamed as "parameters". - Section 11 says "This document defines two SDP session and media-level at= tributes", but lists only one (sctpmap). Was the missing one meant to be 'w= ebrtc-DataChannel'? Note: An SDP attribute 'label' is already defined (RFC 4574) and listed in = the IANA registry. This would cause a name clash if 5.3 is really intended = as attribute and not as parameter definition. Thanks, Ernst Horvath = From Simo.Veikkolainen@nokia.com Fri Jan 25 00:17:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF221F8AD8 for ; Fri, 25 Jan 2013 00:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu+f+FTTItXn for ; Fri, 25 Jan 2013 00:17:39 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BDE4E21F8AD4 for ; Fri, 25 Jan 2013 00:17:38 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0P8HGRH017292; Fri, 25 Jan 2013 10:17:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jan 2013 10:17:33 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.203]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0318.003; Fri, 25 Jan 2013 08:17:32 +0000 From: To: Thread-Topic: SDP Miscellaneous capabilities: port numbers Thread-Index: Ac360/A5tRLGpMVQTqKylTouellYSg== Date: Fri, 25 Jan 2013 08:17:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: 2PrCjJ7f5poVv9TjWbkmkpoe9l+M2b40XgaWX2HvB6x+8ekxW/hH5w4lCNi8B0ok5c1YO1LpkfKUqmsRiLvW0+Sb09T+Fkh54VSRVgwD5SFZAOYQERo/r6YDoLilvhsz6J87/P5sV/UXN8QF+H4fTkByjmTMArdbjRh/GK8PHRq6dzOnRI+g+Z8EDZ/BZiQ0R8KH0OnXZ4apXeWiGS8TKR9gezR4H5s2CaSxTeVxbU0iaL5vjghCzKG+aacaT4pO x-originating-ip: [172.21.81.94] Content-Type: multipart/alternative; boundary="_000_D09DAE6B636851459F7575D146EFB54B1C826B64008AM1MPN1026mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2013 08:17:33.0173 (UTC) FILETIME=[6CF6B250:01CDFAD4] X-Nokia-AV: Clean Subject: [MMUSIC] SDP Miscellaneous capabilities: port numbers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 08:17:40 -0000 --_000_D09DAE6B636851459F7575D146EFB54B1C826B64008AM1MPN1026mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG, An issue came up during review of http://tools.ietf.org/html/draft-ietf-mmu= sic-sdp-miscellaneous-caps-03 . Figures 6 to 8 present an example SDP which= uses the "a=3Dccap" connection address capability to present two alternati= ve SDP configurations, one for IP based media, and the other for PSTN based= media. The issue is that these two alternative configurations use a different port= number. However, there is currently no way to indicate alternative port nu= mbers using the SDP capability negotiation mechanism. For PSTN based media, the port number does not carry any meaningful informa= tion, and http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 proposes t= o use a fixed port number (9, the discard port) which is to be ignored at r= eception. So, in this particular example we can add a note that since the a= lternative offered media uses a PSTN bearer, the port should be hardcoded t= o "9" by the implementer. However, for other types of media this does not w= ork, nor is the example usable in the case where PSTN media is included in = the "m=3D" line, and the address for alternative RTP based media using the = "a=3Dccap" attribute. In order to fix the issue, probably something like "port capability attribu= te" should be defined. This has been discussed in the past, but it has its = own challenges (because of overlap with ICE, among other things). The authors' proposal consist of adding a paragraph in the example descript= ion where we indicate that this particular example works because the CS des= cription uses a well-known port number, but in general, the example is not = applicable if the negotiated capabilities require a change in the port numb= er. Regards, Simo & Miguel --_000_D09DAE6B636851459F7575D146EFB54B1C826B64008AM1MPN1026mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG,

 

An issue came up during review of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-03 = . Figures 6 to 8 present an example SDP which uses the "a=3Dccap"= connection address capability to present two alternative SDP configuration= s, one for IP based media, and the other for PSTN based media.

 

The issue is that these two alternative configuratio= ns use a different port number. However, there is currently no way to indic= ate alternative port numbers using the SDP capability negotiation mechanism= .

 

For PSTN based media, the port number does not carry= any meaningful information, and http://t= ools.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 proposes to use a fixed = port number (9, the discard port) which is to be ignored at reception. So, = in this particular example we can add a note that since the alternative offered media uses a PSTN bearer, th= e port should be hardcoded to "9" by the implementer. However, fo= r other types of media this does not work, nor is the example usable in the= case where PSTN media is included in the "m=3D" line, and the address for alternative RTP based media usi= ng the "a=3Dccap" attribute.

 

In order to fix the issue, probably something like &= quot;port capability attribute" should be defined. This has been discu= ssed in the past, but it has its own challenges (because of overlap with IC= E, among other things).

 

The authors’ proposal consist of adding a para= graph in the example description where we indicate that this particular exa= mple works because the CS description uses a well-known port number, but in= general, the example is not applicable if the negotiated capabilities require a change in the port number.

 

Regards,

Simo & Miguel

 

--_000_D09DAE6B636851459F7575D146EFB54B1C826B64008AM1MPN1026mg_-- From prvs=7737eb7039=aallen@rim.com Fri Jan 25 03:25:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7BE21F883C for ; Fri, 25 Jan 2013 03:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glfeVMBTGOOQ for ; Fri, 25 Jan 2013 03:25:33 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B31DF21F87FB for ; Fri, 25 Jan 2013 03:25:32 -0800 (PST) X-AuditID: 0a41282f-b7f8c6d000004b29-de-51026ba16152 Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id B4.FE.19241.1AB62015; Fri, 25 Jan 2013 05:25:21 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0318.001; Fri, 25 Jan 2013 05:25:20 -0600 From: Andrew Allen To: "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: SDP Miscellaneous capabilities: port numbers Thread-Index: Ac360/A5tRLGpMVQTqKylTouellYSgAGqzUQ Date: Fri, 25 Jan 2013 11:25:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338CF8B17XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsXC5Zyvo7swmynQ4G2vkMXU5Y9ZLM59usvi wOSxZMlPJo+7ty4xBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejDMrzrMXzLGt2HtyMXMD4z+TLkZODgkBE4nrHzcz Q9hiEhfurWfrYuTiEBJYyShxoqebGcLZzChx49dfNpAqNgFlieW/ZzCC2CICaRJPnnxg7WLk 4BAWsJT4vpIFxBQRsJJYcqgWosJI4uHOFlYQm0VAVeL9k2lgNq+Ah8Snvg1MILaQQLjEmRdf 2UFsToEIiaYdDWBxRgFZid1nr4PZzALiEreezGeCuFNAYsme81A3i0q8fPyPFcJWlHjc0s0C UZ8v8aRhAgvELkGJkzOfsExgFJmFZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4 Akb2VYyCuRnFBmYGyXnJekWZuXp5qSWbGEHJw1FDfwfj2/cWhxgFOBiVeHg3pzMFCrEmlhVX 5h5ilOBgVhLhlTEBCvGmJFZWpRblxxeV5qQWH2IMAobWRGYp7uR8YGLLK4k3NjAgkqMkznv6 178AIYF0YBLLTk0tSC2CGcrEwQmylEtKpBiYilKLEktLMuJBCTO+GJgypYCp1MPsCbfDz1NR IjPjrpx245LXND8o0PpsFnPIgcNXPWQ+nnjvuq9x44oLJv2ZDkdrSl0Y3Kc/t1BhnnSWo0tF 3OrhjlCFD0xWE1L6/GblyDtYizxY0dEf6RQkf/vQLG3/Gj7B68/9O0/JK4TMnJ2/ZteFJs+u R1wrVUNF5SJ4BCs0uTgXiyqxFGckGmoxFxUnAgD+uAwQbAMAAA== Subject: Re: [MMUSIC] SDP Miscellaneous capabilities: port numbers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 11:25:35 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338CF8B17XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable I am fine with the proposal. Andrew From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Simo.Veikkolainen@nokia.com Sent: Friday, January 25, 2013 3:18 AM To: mmusic@ietf.org Subject: [MMUSIC] SDP Miscellaneous capabilities: port numbers Dear WG, An issue came up during review of http://tools.ietf.org/html/draft-ietf-mmus= ic-sdp-miscellaneous-caps-03 . Figures 6 to 8 present an example SDP which u= ses the "a=3Dccap" connection address capability to present two alternative= SDP configurations, one for IP based media, and the other for PSTN based me= dia. The issue is that these two alternative configurations use a different port= number. However, there is currently no way to indicate alternative port num= bers using the SDP capability negotiation mechanism. For PSTN based media, the port number does not carry any meaningful informat= ion, and http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 proposes to= use a fixed port number (9, the discard port) which is to be ignored at rec= eption. So, in this particular example we can add a note that since the alte= rnative offered media uses a PSTN bearer, the port should be hardcoded to "9= " by the implementer. However, for other types of media this does not work,= nor is the example usable in the case where PSTN media is included in the "= m=3D" line, and the address for alternative RTP based media using the "a=3Dc= cap" attribute. In order to fix the issue, probably something like "port capability attribut= e" should be defined. This has been discussed in the past, but it has its ow= n challenges (because of overlap with ICE, among other things). The authors' proposal consist of adding a paragraph in the example descripti= on where we indicate that this particular example works because the CS descr= iption uses a well-known port number, but in general, the example is not app= licable if the negotiated capabilities require a change in the port number. Regards, Simo & Miguel --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338CF8B17XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

I am fine with the prop= osal.

 

Andrew

 

From: mmusic-boun= ces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com
Sent: Friday, January 25, 2013 3:18 AM
To: mmusic@ietf.org
Subject: [MMUSIC] SDP Miscellaneous capabilities: port numbers

 

Dear WG,

 

An issue came up during review of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-03 .= Figures 6 to 8 present an example SDP which uses the "a=3Dccap" c= onnection address capability to present two alternative SDP configurations,= one for IP based media, and the other for PSTN based media.

 

The issue is that these two alternative configuration= s use a different port number. However, there is currently no way to indicat= e alternative port numbers using the SDP capability negotiation mechanism.

 

For PSTN based media, the port number does not carry= any meaningful information, and http://to= ols.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 proposes to use a fixed po= rt number (9, the discard port) which is to be ignored at reception. So, in= this particular example we can add a note that since the alternative offered media uses a PSTN bearer, the= port should be hardcoded to "9" by the implementer. However, for= other types of media this does not work, nor is the example usable in the c= ase where PSTN media is included in the "m=3D" line, and the address for alternative RTP based media usin= g the "a=3Dccap" attribute.

 

In order to fix the issue, probably something like &q= uot;port capability attribute" should be defined. This has been discuss= ed in the past, but it has its own challenges (because of overlap with ICE,= among other things).

 

The authors’ proposal consist of adding a parag= raph in the example description where we indicate that this particular examp= le works because the CS description uses a well-known port number, but in ge= neral, the example is not applicable if the negotiated capabilities require a change in the port number.

 

Regards,

Simo & Miguel

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338CF8B17XMB104ADSrimnet_-- From ted.ietf@gmail.com Fri Jan 25 08:47:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C621F893E; Fri, 25 Jan 2013 08:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQJAcpfhO30x; Fri, 25 Jan 2013 08:47:55 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id AE80621F88BF; Fri, 25 Jan 2013 08:47:54 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id wc18so668609obb.12 for ; Fri, 25 Jan 2013 08:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ZlIvhBX4rBIPBD9aqA4mHcwHqhFWYzmq23B8S5v6g9A=; b=XSLpVnIkPXJEx1kXqhqQx/tuku0PaFi4bR6QtcIWWWFENhqZWAbCBgKuJHVA/YHyAU sWO3WVQSiU3h5Qh0qetpDTAlFQMJWWWs0RKaBSXRxnPkGOdoMuIZWjuseMN+XaUm439l pPucQpNAnuEHj82lOiuwaW1R5rWFf2CeSqaZFyevKoNA49dbVMj0I98tDqutr/ZaN0YI Jb1bkfNYmaz0bM19vDyROJ6jcA7YjsUiLEjKAWpqIQaftWl+z01+T6s3+LhfOtNNSaTu T/fpj4/uGN63BoPG+Np4paQ7zlk01VHTAG7scnfVr4NZpTX4fjEnpKLXVs36qvtSGq4V EMwA== MIME-Version: 1.0 X-Received: by 10.50.91.168 with SMTP id cf8mr4597586igb.20.1359132474170; Fri, 25 Jan 2013 08:47:54 -0800 (PST) Received: by 10.43.135.202 with HTTP; Fri, 25 Jan 2013 08:47:54 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Jan 2013 08:47:54 -0800 Message-ID: From: Ted Hardie To: mmusic@ietf.org, rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:47:55 -0000 http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation http://tools.ietf.org/html/draft-alvestrand-mmusic-msid http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle http://tools.ietf.org/html/draft-ietf-rtcweb-jsep You may also want to look at the proceedings from the Atlanta meeting; in particular, this was suggested as good background reading: http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt regards, Ted Hardie From btv1==7376abf850a==HKaplan@acmepacket.com Fri Jan 25 12:53:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D57021F858A for ; Fri, 25 Jan 2013 12:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7CXdE68G8JK for ; Fri, 25 Jan 2013 12:53:30 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF321F853C for ; Fri, 25 Jan 2013 12:53:29 -0800 (PST) X-ASG-Debug-ID: 1359147207-03fc20615718e5d0001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id ZkPN6UmvJenKrUsI (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 25 Jan 2013 15:53:27 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Fri, 25 Jan 2013 15:53:27 -0500 From: Hadriel Kaplan To: mmusic Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-ASG-Orig-Subj: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt Thread-Index: AQHN+z4FM3X7H+WSCkyhSNJBoZzcZg== Date: Fri, 25 Jan 2013 20:53:26 +0000 Message-ID: References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> <021201cdef86$96f50ab0$c4df2010$@cisco.com> In-Reply-To: <021201cdef86$96f50ab0$c4df2010$@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1359147207 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.120895 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 20:55:02 -0000 On Jan 10, 2013, at 6:02 PM, Dan Wing wrote: > I am glad this document was resurrected. =20 >=20 > Can the document say SBC instead of the awkward (and inaccurate)=20 > "SIP ALG combined with MIDCOM agent"? Or is saying SBC impolitic. >=20 I don't think it can or should say "SBC" - because this doc does not descri= be what an SBC does. At least not the first half (section 4), which is rea= lly about an inline ALG in the router/firewall. (ie, it's not the target/so= urce of the IP addresses of the packets, doesn't change SIP/SDP, etc.) Anyway, I read this latest draft, and it looks exactly like the older ones,= so I don't see it fixing the issues with the older ones: 1) It claims to describe the impact on ICE, but doesn't 2) Doesn't describe the issues with forked or moved calls on early in-band = media signaling (especially if you actually comply with recommendations #2+= #4) 3) Uses terminology from ancient history (ie, RFC 3303) that no one else us= es 4) Recommendation #5 is backwards I think - it should recommend protocols n= ot to require/expect to exchange media-plane signaling after the session ha= s been terminated. (in other words, since you can't rely on middleboxes bei= ng lenient, don't design a protocol to expect them to be so)=20 -hadriel From dwing@cisco.com Fri Jan 25 21:21:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776A21F8442 for ; Fri, 25 Jan 2013 21:21:36 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5cQVaMpp7hv for ; Fri, 25 Jan 2013 21:21:35 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DEBD721F8A3E for ; Fri, 25 Jan 2013 21:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2180; q=dns/txt; s=iport; t=1359177696; x=1360387296; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=cMw4UPkfMfC5xyWar0+YB8WW3ttEzrDwFK72oSXpkeo=; b=hQeDyayhRczobfMMcNaXMzCWOaV1yliDoevRp9KXrhz51szagekW5HsF cPI9gMA3HLQV0pEL4yBuu4prr4pCerVpbfmcqn6UPSMPONHL8ifxlALvm 3sdnW9Gu47tIOhYGUn/clmUP5H4ZIo5rww5Kw08iQrwD03cea3ao57/M8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHVnA1GrRDoH/2dsb2JhbABFvmIWc4IeAQEBAwEBAQEFAjA0EAcBAwIJDgMBAwEBAScHGQ4fAwYIAgQBEgsFh3kFDb4xBJE/A4hhhR2ID5BIgxg X-IronPort-AV: E=Sophos;i="4.84,542,1355097600"; d="scan'208";a="69670326" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 26 Jan 2013 05:21:35 +0000 Received: from DWINGWS01 ([10.32.240.198]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0Q5LZmx017873; Sat, 26 Jan 2013 05:21:35 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'mmusic'" References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> <021201cdef86$96f50ab0$c4df2010$@cisco.com> In-Reply-To: Date: Fri, 25 Jan 2013 21:21:35 -0800 Message-ID: <085a01cdfb85$02875c60$07961520$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJL7yJZmwafjbIh7QDO1X8p3fpnmgIjJZUyAfEuvdsBsZzdFpcw+6sQ Content-Language: en-us Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jan 2013 05:21:36 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Hadriel Kaplan > Sent: Friday, January 25, 2013 12:53 PM > To: mmusic > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path- > middleboxes-06.txt > > > On Jan 10, 2013, at 6:02 PM, Dan Wing wrote: > > > I am glad this document was resurrected. > > > > Can the document say SBC instead of the awkward (and inaccurate) "SIP > > ALG combined with MIDCOM agent"? Or is saying SBC impolitic. > > > > I don't think it can or should say "SBC" - because this doc does not > describe what an SBC does. At least not the first half (section 4), > which is really about an inline ALG in the router/firewall. (ie, it's > not the target/source of the IP addresses of the packets, doesn't change > SIP/SDP, etc.) Yes, you're right. Thanks. > Anyway, I read this latest draft, and it looks exactly like the older > ones, so I don't see it fixing the issues with the older ones: > 1) It claims to describe the impact on ICE, but doesn't > 2) Doesn't describe the issues with forked or moved calls on early in- > band media signaling (especially if you actually comply with > recommendations #2+#4) > 3) Uses terminology from ancient history (ie, RFC 3303) that no one else > uses Which is where I got confused. I thought it was trying to describe what is sometimes called a 'decomposed SBC', where the B2BUA is controlling the media relaying function using a protocol-similar-to-MIDCOM. I agree nobody uses "MIDCOM" or "MIDCOM architecture" to describe how an ALG within a firewall or an ALG within a NAT (or NAPT) functions. -d > 4) Recommendation #5 is backwards I think - it should recommend > protocols not to require/expect to exchange media-plane signaling after > the session has been terminated. (in other words, since you can't rely > on middleboxes being lenient, don't design a protocol to expect them to > be so) > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Mon Jan 28 09:12:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6251921F881A for ; Mon, 28 Jan 2013 09:12:44 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y7N4WjWzZ8F for ; Mon, 28 Jan 2013 09:12:43 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6B21F87FE for ; Mon, 28 Jan 2013 09:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1359393163; x=1360602763; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZbniOQrykF7dETI+RuP5Zp3AOZkFgzAc5r+o3eediDQ=; b=fqFK9dvKWdqWTw5X6ZlH5nX3fJsVv/ZF/DchGvGFaC+lh6I+3zBmUo/5 F06E8AP1gT62uH3AXBMweiq2R/PN0iwU7TPZWv4E+1AIhddzURV5BLaE2 j//EdSML4Hvfq+7YjerqaKmuIZYwtvHqOvk0cpmFz/3Eg5aXwVZgjEU7F M=; X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="69818573" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 28 Jan 2013 17:12:42 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.16.34]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0SHCf6s008508; Mon, 28 Jan 2013 17:12:41 GMT Message-ID: <5106B189.5090909@cisco.com> Date: Mon, 28 Jan 2013 12:12:41 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> <021201cdef86$96f50ab0$c4df2010$@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 17:12:44 -0000 On 1/25/13 3:53 PM, Hadriel Kaplan wrote: > On Jan 10, 2013, at 6:02 PM, Dan Wing wrote: > >> I am glad this document was resurrected. >> >> Can the document say SBC instead of the awkward (and inaccurate) >> "SIP ALG combined with MIDCOM agent"? Or is saying SBC impolitic. >> > I don't think it can or should say "SBC" - because this doc does not describe what an SBC does. At least not the first half (section 4), which is really about an inline ALG in the router/firewall. (ie, it's not the target/source of the IP addresses of the packets, doesn't change SIP/SDP, etc.) > > Anyway, I read this latest draft, and it looks exactly like the older ones, so I don't see it fixing the issues with the older ones: > 1) It claims to describe the impact on ICE, but doesn't > 2) Doesn't describe the issues with forked or moved calls on early in-band media signaling (especially if you actually comply with recommendations #2+#4) > 3) Uses terminology from ancient history (ie, RFC 3303) that no one else uses > 4) Recommendation #5 is backwards I think - it should recommend protocols not to require/expect to exchange media-plane signaling after the session has been terminated. (in other words, since you can't rely on middleboxes being lenient, don't design a protocol to expect them to be so) Thanks for taking a look and providing your comments Hadriel. As per previous discussions, we wanted to first agree on the scope of the document and whether there was still value in pursuing such a document. As per Gonzalo's e-mail starting this thread, do you have any comments/concerns on that part (if so, please let the authors know what those are) ? Once (/if) we get agreement on the scope, we can then get into detail around the technical aspects of the document as per your comments above. Thanks -- Flemming (MMUSIC co-chair) > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fluffy@cisco.com Tue Jan 29 08:49:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD5A21F894D; Tue, 29 Jan 2013 08:49:48 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR61fe1qOADe; Tue, 29 Jan 2013 08:49:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C076C21F892F; Tue, 29 Jan 2013 08:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=869; q=dns/txt; s=iport; t=1359478187; x=1360687787; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0ZP8xWjVbK3Afd3RGKzg8vLuzKpH3HefkdpjQhZpOY4=; b=A5j1cnZLr9ETEqG9Ck064UwD1Ft3OR6uWIoSy3hdyJcnhdbbaSXRaNtu On2B+Ckh3IVBFdrcikI3RY6xTDnpNabn8dNQVQVZD7i43HzwC42x/lLFG 7ya/TjyxMJff3eXbTKTkdbSe1QkF7PGfYDBXhtOMliLngCx84QuS4bLz5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFADj8B1GtJXHB/2dsb2JhbABEhX+4XxZzgh8BAQQ6RAsCAQgiFBAhESUCBAESCAGHdgMPDLB+hlENiVWMFIQUYQOUN4Jyih2FEoJ3giQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="166925213" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2013 16:49:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TGnlBq018140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 16:49:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:49:47 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim Thread-Index: AQHN/kClnHEZs7eINEKHatjXJ9cqoQ== Date: Tue, 29 Jan 2013 16:49:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <13120A061F414D438181B47449205B03@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Start of a reading list for the IETF MMUSIC/RTCWEB interim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:49:48 -0000 On Jan 25, 2013, at 9:47 AM, Ted Hardie wrote: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation > http://tools.ietf.org/html/draft-alvestrand-mmusic-msid > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep >=20 > You may also want to look at the proceedings from the Atlanta meeting; > in particular, this was suggested as good background reading: > http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt Some more background reading that is useful context=20 draft-ietf-rtcweb-rtp-usage-05 draft-ietf-rtcweb-overview-05 draft-ietf-rtcweb-use-cases-and-requirements-10 Thanks,=20 =20 From emil@sip-communicator.org Tue Jan 29 09:28:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB61B21F8A69 for ; Tue, 29 Jan 2013 09:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgjZOmLfzaPd for ; Tue, 29 Jan 2013 09:28:31 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7AF21F8A89 for ; Tue, 29 Jan 2013 09:28:29 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so2721448wib.0 for ; Tue, 29 Jan 2013 09:28:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding :x-gm-message-state; bh=I/eLBfp0FIPCM5AhWJRB4jVr+3Om8K5v2UvgPq6Bu3s=; b=DO7EIRYOlSg5UzSYggVNve2QJDbiPldbiCja7zc7JOhgaeS1wfbdFKgrFPhQ04/lwz 5KrK3H0MjGoxyIxY4w0p89aGxNAaGIMeytbjoCmG4UJrBMJCjurIvFdOwChhVXbJkEru RvuOxIVfoO/S6IyTE0+BlvGUQJaqewrkQ9Gw2SzRCDaOtk9Ds9K2hWgf8BOzCf7tSEFT 4eY1HLrj+f4eiUg9kioWJH88KHRSeoP6zgzfgCl3xcE8M7VaKqjlKFMo4FfI7xcrmvQg JWmETbyxIaF7tswlAilQONpzpTqf+myxOO9YuOoTRN4q62F2Zxur9VJky8+gqcHIjagM rC8g== X-Received: by 10.194.158.100 with SMTP id wt4mr3919605wjb.37.1359480508375; Tue, 29 Jan 2013 09:28:28 -0800 (PST) Received: from camionet.local ([2a01:e35:8a55:abc0:9021:e9a9:cc32:e173]) by mx.google.com with ESMTPS id bd6sm4136323wib.10.2013.01.29.09.28.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 09:28:27 -0800 (PST) Message-ID: <510806B9.6050105@jitsi.org> Date: Tue, 29 Jan 2013 18:28:25 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: MMUSIC IETF WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlx+hOSDlmPqmU9GmzHVKbRSMnR7UE2n6b8mVqLCCrID4BSl68yyaakpgjPfqqSQUaaltxj Subject: [MMUSIC] Feedback for draft-ietf-mmusic-latching X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 17:28:32 -0000 Hey all, This is just reminder about the latching draft: http://tools.ietf.org/html/draft-ietf-mmusic-latching The authors believe that it is solid enough but comments would be appreciated even if only to point that the text makes sense and does not present major issues. Thanks, Emil -- https://jitsi.org From stefan.lk.hakansson@ericsson.com Wed Jan 30 01:51:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3157221F85E8; Wed, 30 Jan 2013 01:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbvXEtJZZ19O; Wed, 30 Jan 2013 01:50:59 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB721F85E7; Wed, 30 Jan 2013 01:50:58 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-42-5108ed01b4ad Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.0F.19728.10DE8015; Wed, 30 Jan 2013 10:50:57 +0100 (CET) Received: from [150.132.141.90] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 10:50:56 +0100 Message-ID: <5108ED00.9090605@ericsson.com> Date: Wed, 30 Jan 2013 10:50:56 +0100 From: =?windows-1252?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org, rtcweb@ietf.org, "public-webrtc@w3.org" , "public-media-capture@w3.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJJMWRmVeSWpSXmKPExsUyM+JvrS7jW45Ag4YPChZTlz9msbi6eBeL Re/HJYwWa/+1szuweCxZ8pPJ4+i8/awBTFFcNimpOZllqUX6dglcGc8/nmIsWMdXcX36cfYG xq/cXYycHBICJhJLzi5hh7DFJC7cW8/WxcjFISRwklGi+0I/lLOGUWLflNPMIFW8AtoSL06c B+tgEVCVWNh5CyjOwcEmECwxY4oRSFhUIEri/dUmqHJBiZMzn7CAzBERmMoo8WDPZyaQhLCA nMS640/ZQHqZBewlHmwtAwkzC8hLNG+dDdYrJKAr8e71PdYJjHyzkIyahdAxC0nHAkbmVYzs uYmZOenlRpsYgcF1cMtv1R2Md86JHGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoHRePXiR23i0+bpdflXv7LS3uafY7dlc3d/0aKvM8o/OS5k/n4m2PGyxAyTH3JXb0TO m+vb9VNQKSL5+gIb3y9/onnvKR7ZuJgnfEeGoOfOomkybHb1XZsOZh0pypuxuWTHGpsS+cqI D/nG3l8Nr2X1HSl7Wsy10dCWe1KKJMPW09ZuNUHzl5YqsRRnJBpqMRcVJwIAKVISWfwBAAA= Subject: [MMUSIC] Boston meeting agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:51:00 -0000 All, below is a merged agenda covering both W3C and IETF parts of the meeting. Details are likely to change - the main message is that W3C meetings will be before lunch, and IETF after. Before lunch could mean 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A hard stop is planned for 17:00 on Feb 7th as many have planes to catch. (The sources used to assemble the agenda below are the W3C meeting wiki's, [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). --Stefan (for all involved chairs) Feb 5th ======= Morning session: W3C Media Capture TF ------------------------------------- * device enumeration * error handling * “immediate stream” gUM * Resource reservation Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * Multiple Flow SDP representation * SDP for Data channels Feb 6th ======= Morning session: W3C Media Capture TF + WebRTC WG ------------------------------------------------- * Identity aspects of MediaStreams (MediaCap) * Settings/constraints (MediaCap) * Recording (MediaCap) * Call flow (WebRTC) Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * SDP Grouping (Bundle/MMT/one-rtp) * Mapping stream/track label concepts to SDP identifiers Feb 7th ======= Morning session: W3C WebRTC WG ------------------------------ * MediaStream and MediaStreamTrack - SDP interface * Error handling * Data channel * Stats Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * Trickle ICE * JSEP [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013 [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html From emil@sip-communicator.org Wed Jan 30 08:38:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCAB21F8828 for ; Wed, 30 Jan 2013 08:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klmM8Sl5sUpZ for ; Wed, 30 Jan 2013 08:38:40 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id F3FB921F84D1 for ; Wed, 30 Jan 2013 08:38:39 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id o1so1855990wic.6 for ; Wed, 30 Jan 2013 08:38:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding :x-gm-message-state; bh=Ea3Cr9z7PdCD+KuzsxwJ/t8YvLxo3y2l1auWZBJTIsg=; b=MrrC9fqd9HohZxRlEIxR04sc/0YKacfaFkm9EZk9QBsl7n53qHvQRXnQHNTuNteSvI qVUPzzDCxl0RzDHszRtHEBr2z3OwDO6XJhiTvDt+O7QOjzW62lakqePAd91u+aQHCAOM xKFTmVQDoDeaOLWvMCR0S8SMtrYNA3S2v6+eLV5X25hfLmIIqUrFTxQcnTbetpY6IP45 a6Zs+AhcmrkKkCqccXCb82ahtrwq3kLXryb9s5k5qtQzhoXWqmKq6gZQXZFGbctRMVvg SFy5IOFskp4DD5nvJz0gJYreXrtCbFGeR3mwpTpDnbTyxlKQz+cLgVAqWQR/HC/8Sfmr V0hw== X-Received: by 10.180.81.39 with SMTP id w7mr10052908wix.15.1359563918963; Wed, 30 Jan 2013 08:38:38 -0800 (PST) Received: from camionet.local ([2a01:e35:8a55:abc0:8cd6:1817:8e6f:a083]) by mx.google.com with ESMTPS id bz12sm4005015wib.5.2013.01.30.08.38.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 08:38:37 -0800 (PST) Message-ID: <51094C89.7020302@jitsi.org> Date: Wed, 30 Jan 2013 17:38:33 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: MMUSIC IETF WG References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> In-Reply-To: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnh6Qc+VJTTKpQfh/RaGnAcVwGbCtIaen2HmqDrWdhR06aeRpe9ARqY0BCguK28wNJbnDE7 Subject: [MMUSIC] Trickle ICE update and a new SIP usage draft. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:38:41 -0000 Hey all, Justin, Eric and I have just submitted an update to the trickle ICE draft, accommodating comments from Atlanta: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 More details about the changes here: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B Diff2: http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 During the MMUSIC presentation and the mailing list discussions it was also pointed out that it is important for this work to happen in parallel with a SIP usage for trickle ICE. Enrico, Christer and I have therefore submitted the following document: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 As always, comments are welcome! Cheers, Emil -------- Original Message -------- Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt Date: Mon, 28 Jan 2013 11:39:21 -0800 From: internet-drafts@ietf.org To: emcho@jitsi.org CC: justin@uberti.name, ekr@rtfm.com A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Filename: draft-ivov-mmusic-trickle-ice Revision: 00 Title: Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Creation date: 2013-01-28 WG ID: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt Status: http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 Abstract: This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The above mechanism is also referred to as "trickle ICE". The IETF Secretariat From magnus.westerlund@ericsson.com Thu Jan 31 02:46:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FB421F86B2; Thu, 31 Jan 2013 02:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.854 X-Spam-Level: X-Spam-Status: No, score=-102.854 tagged_above=-999 required=5 tests=[AWL=-1.605, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZY4Upxj+m9j; Thu, 31 Jan 2013 02:46:23 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79221F8678; Thu, 31 Jan 2013 02:46:21 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-59-510a4b7dfbb2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 63.D0.10459.D7B4A015; Thu, 31 Jan 2013 11:46:21 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 31 Jan 2013 11:46:21 +0100 Message-ID: <510A4B7C.3000009@ericsson.com> Date: Thu, 31 Jan 2013 11:46:20 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mmusic (E-mail)" , "rtcweb@ietf.org" X-Enigmail-Version: 1.5 Content-Type: multipart/mixed; boundary="------------080706010305080101000300" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3VrfWmyvQYEUfv8XU5Y9ZLNb+a2d3 YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfG950rmAuWn2Ou2NO2jKmB8fYVpi5GTg4JAROJc/eu MkLYYhIX7q1n62Lk4hASOMkosaznG5SznFFi161PYFW8AtoSc4/9YAexWQRUJfbtfMkCYrMJ WEjc/NHIBmKLCgRLbDi4igmiXlDi5MwnYDUiAv4STfO7wOYICzhIrN4+DaieA2izuMSaNxwg YWaBAIlHbe1gJUJAqxqaOlgnMPLNQjJpFpIyCFtPYsrVFihbXqJ562xmCDtHYu7nNlaY+Pa3 c6Di8RJ/1+5mX8DIvoqRPTcxMye93HATIzBID275rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwVp/e45LHaRrTp+TSdH/FpNP5s5ymJFUYBR4R3LZE5g5L R1stX0tR6E4B3b9qefvriz0uff12xW7Tf4XcjHlNezUNuhOK722R0meNNlo3re1zptifWdsc rvo9/p9g0us68UDav9+e0YXLP6//tpyBL5HR5DLzigWeE27/6PBb5F1XerlG99djJZbijERD Leai4kQADkzA5iACAAA= X-Mailman-Approved-At: Thu, 31 Jan 2013 05:42:49 -0800 Subject: [MMUSIC] Draft on Multimedia concepts and relations for Intermim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 10:46:26 -0000 --------------080706010305080101000300 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Hi, Attached is a draft on multimedia concepts and relations that we believe relevant for the upcoming interim. This includes commonalties between WebRTC and CLUE and other RTP usages. Sorry for the late submission, i do hope you have time to review it. At will also be properly submitted to IETF as soon as we figure out why the submission tools refuses to process it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------080706010305080101000300 Content-Type: text/plain; charset="windows-1252"; name="draft-burman-rtcweb-mmusic-media-structure-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-burman-rtcweb-mmusic-media-structure-00.txt" Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Informational Ericsson Expires: August 4, 2013 January 31, 2013 Multi-Media Concepts and Relations draft-burman-rtcweb-mmusic-media-structure-00 Abstract There are currently significant efforts ongoing in IETF regarding more advanced multi-media functionalities, such as the work related to RTCWEB and CLUE. This work includes use cases for both multi- party communication and multiple media streams from an individual end-point. The usage of scalable encoding or simulcast encoding as well as different types of transport mechanisms have created additional needs to correctly identify different types of resources and describe their relations to achieve intended functionalities. The different usages have both commonalities and differences in needs and behavior. This document attempts to review some usages and identify commonalities and needs. It then continues to highlight important aspects that need to be considered in the definition of these usages. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 4, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Burman & Westerlund Expires August 4, 2013 [Page 1] Internet-Draft Media Concepts and Relations January 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Existing RTP Usages . . . . . . . . . . . . . . . . . . . 4 3.1.1. Basic VoIP call . . . . . . . . . . . . . . . . . . . 4 3.1.2. Audio and Video Conference . . . . . . . . . . . . . . 5 3.1.3. Audio and Video Switched Conference . . . . . . . . . 7 3.2. WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mesh-based Multi-party . . . . . . . . . . . . . . . . 9 3.2.2. Multi-source Endpoints . . . . . . . . . . . . . . . . 10 3.2.3. Media Relaying . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Usage of Simulcast . . . . . . . . . . . . . . . . . . 11 3.3. CLUE Telepresence . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Telepresence Functionality . . . . . . . . . . . . . . 13 3.3.2. Distributed Endpoint . . . . . . . . . . . . . . . . . 14 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Commonalities in Use Cases . . . . . . . . . . . . . . . . 14 4.1.1. Media Source . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. Encodings . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Synchronization contexts . . . . . . . . . . . . . . . 17 4.1.4. Distributed Endpoints . . . . . . . . . . . . . . . . 18 4.2. Identified WebRTC issues . . . . . . . . . . . . . . . . . 18 4.3. Relevant to SDP evolution . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Informative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Burman & Westerlund Expires August 4, 2013 [Page 2] Internet-Draft Media Concepts and Relations January 2013 1. Introduction This document concerns itself with the conceptual structures that can be found in different logical levels of a multi-media communication, from transport aspects to high-level needs of the communication application. The intention is to provide considerations and guidance that can be used when discussing how to resolve issues in the RTCWEB and CLUE related standardization. Typical use cases for those WG have commonalities that likely should be addressed similarly and in a way that allows to align them. The document starts with going deeper in the motivation why this has become an important problem at this time. This is followed by studies of some use cases and what concepts they contain, and concludes with a discussion of observed commonalities and important aspects to consider. 2. Motivation There has arisen a number of new needs and requirements lately from work such as WebRTC/RTCWEB [I-D.ietf-rtcweb-overview] and CLUE [I-D.ietf-clue-framework]. The applications considered in those WG has surfaced new requirements on the usage of both RTP [RFC3550] and existing signalling solutions. The main application aspects that have created new needs are: o Multiple Media Streams from an end-point. The fact that an end- point may have multiple media capture devices, such as cameras or microphone mixes. o Group communications involving multiple end-points. This is realized using both mesh based connections as well as centralized conference nodes. These creating a need for dealing with multiple endpoints and/or multiple streams with different origins from a transport peer. o Media Stream Adaptation, both to adjust network resource consumption as well as to handle varying end-point capabilities in group communication. o Transport mechanisms including both higher levels of aggregation [I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-avtcore-multi-media-rtp-session] and the use of application-level transport repair mechanisms such as forward error correction (FEC) and/or retransmission. Burman & Westerlund Expires August 4, 2013 [Page 3] Internet-Draft Media Concepts and Relations January 2013 The presence of multiple media resources or components creates a need to identify, handle and group those resources across multiple different instantiations or alternatives. 3. Use Cases 3.1. Existing RTP Usages There are many different existing RTP usages. This section brings up some that we deem interesting in comparison to the other use cases. 3.1.1. Basic VoIP call This use case is intended to function as a base-line to contrast against the rest of the use cases. The communication context is an audio-only bi-directional communication between two users, Alice and Bob. This communication uses a single multi-media session that can be established in a number of ways, but let's assume SIP/SDP [RFC3261][RFC3264]. This multi- media session contains two end-points, one for Alice and one for Bob. Each end-point has an audio capture device that is used to create a single audio media source at each end-point. +-------+ +-------+ | Alice |<------->| Bob | +-------+ +-------+ Figure 1: Point-to-point Audio The session establishment (SIP/SDP) negotiates the intent to communicate over RTP using only the audio media type. Inherent in the application is an assumption of only a single media source in each direction. The boundaries for the encodings are represented using RTP Payload types in conjunction with the SDP bandwidth parameter (b=). The session establishment is also used to negotiate that RTP will be used, thus resulting in that an RTP session will be created for the audio. The underlying transport flows, in this case a single bi-directional UDP flow for RTP, another for RTCP, is configured by each end-point providing its' IP address and port, which becomes source or destination depending on in which direction the packet is sent. The RTP session will have two RTP media streams, one in each direction, which carries the encoding of the media source the sending implementation has chosen based on the boundaries established by the RTP payload types and other SDP parameters, e.g. codec, and bit- Burman & Westerlund Expires August 4, 2013 [Page 4] Internet-Draft Media Concepts and Relations January 2013 rates. The streams are in the RTP context identified by their SSRCs. 3.1.2. Audio and Video Conference This use case is a multi-party use case with a central conference node performing media mixing. It also includes two media types, both audio and video. The high level topology of the communication session is the following: +-------+ +------------+ +-------+ | |<-Audio->| |<--Audio-->| | | Alice | | | | Bob | | |<-Video->| |<--Video-->| | +-------+ | | +-------+ | Mixer | +-------+ | | +-------+ | |<-Audio->| |<--Audio-->| | |Charlie| | | | David | | |<-Video->| |<--Video-->| | +-------+ +------------+ +-------+ Figure 2: Audio and Video Conference with Centralized Mixing The communication session is a multi-party conference including the four users Alice, Bob, Charlie, and David. This communication session contains four end-points and one middlebox (the Mixer). The communication session is established using four different multi-media sessions; one each between the user's endpoints and the middlebox. Each of these multi-media sessions uses a session establishment method, like SIP/SDP. Looking at a single multi-media session between a user, e.g. Alice, and the Mixer, there exist two media types, audio and video. Alice has two capture devices, one video camera giving her a video media source, and an audio capture device giving an audio media source. These two media sources are captured in the same room by the same end-point and thus have a strong timing relationship, requiring inter-media synchronization at playback to provide the correct fidelity. Thus Alice's endpoint has a synchronization context that both her media sources use. These two media sources are encoded using encoding parameters within the boundaries that has been agreed between the end-point and the Mixer using the session establishment. As has been common practice, each media type will use its own RTP session between the end-point and the mixer. Thus a single audio stream using a single SSRC will flow from Alice to the Mixer in the Audio RTP session and a single video stream will flow in the Video RTP session. Using this division Burman & Westerlund Expires August 4, 2013 [Page 5] Internet-Draft Media Concepts and Relations January 2013 in separate RTP sessions, the bandwidth of both audio and video can be unambiguously and separately negotiated by the SDP bandwidth attributes exchanged between the end-points and the mixer. Each RTP session is using its own Transport Flows. The common synchronization context across Alice's two media streams is identified by binding both streams to the same CNAME, generated by Alice's endpoint. The mixer does not have any physical capture devices, instead it creates conceptual media sources. It provides two media sources towards Alice; one audio being a mix of the audio from Bob, Charlie and David, the second one being a conceptual video source that contains a selection of one of the other video sources received from Bob, Charlie, or David depending on who is speaking. The Mixer's audio and video sources are provided in an encoding using a codec that is supported by both Alice's endpoint and the mixer. These streams are identified by a single SSRC in the respective RTP session. The mixer will have its own synchronization context and it will inject the media from Bob, Charlie and David in a synchronized way into the mixer's synchronization context to maintain the inter-media synchronization of the original media sources. The mixer establishes independent multimedia sessions with each of the participant's endpoints. The mixer will in most cases also have unique conceptual media sources for each of the endpoints. This as audio mixes and video selections typically exclude media sources originating from the receiving end-point. For example, Bob's audio mix will be a mix of Alice, Charlie and David, and will not contain Bob's own audio. This use case may need unique user identities across the whole communication session. An example functionality of this is a participant list which includes audio energy levels showing who is speaking within the audio mix. If that information is carried in RTP using the RTP header extension for Mixer to audio clients [RFC6465] then contributing source identities in the form of CSRC need to be bound to the other end-point's media sources or user identities. This despite the fact that each RTP session towards a particular user's endpoint is terminated in the RTP mixer. This points out the need for identifiers that exist in multiple multi-media session contexts. In most cases this can easily be solved by the application having identities tailored specifically for its own needs, but some applications will benefit from having access to some commonly defined structure for media source identities. Burman & Westerlund Expires August 4, 2013 [Page 6] Internet-Draft Media Concepts and Relations January 2013 3.1.3. Audio and Video Switched Conference This use case is similar to the one above (Section 3.1.2), with the difference that the mixer does not mix media streams by decoding, mixing and re-encoding them, but rather switches a selection of received media more or less unmodified towards receiving end-points. This difference may not be very apparent to the end-user, but the main motivations to eliminate the mixing operation and switch rather than mix are: o Lower processing requirements in the mixer. o Lower complexity in the mixer. o Higher media quality at the receiver given a certain media bitrate. o Lower end-to-end media delay. Without the mixing operation, the mixer has limited ability to create conceptual media sources that are customized for each receiver. The reasons for such customizations comes from sender and receiver differences in available resources and preferences: o Presenting multiple conference users simultaneously, like in a video mosaic. o Alignment of sent media quality to receivers presentation needs. o Alignment of codec type and configuration between sender and receiver. o Alignment of encoded bitrate to the available end-to-end link bandwidth. To enable elimination of the mixing operation, media sent to the mixer must sufficiently well meet the above constraints for all intended receivers. There are several ways to achieve this. One way is to, by some system-wide design, ensure that all senders and receivers are basically identical in all the above aspects. This may however prove unrealistic when variations in conditions and end- points are too large. Another way is to let a sender provide a (small) set of alternative representations for each sent media source, enough to sufficiently well cover the expected range of variation. If those media source representations, encodings, are independent from one another, they constitute a Simulcast of the media source. If an encoding is instead dependent on and thus requires reception of one or more other encodings, the representation Burman & Westerlund Expires August 4, 2013 [Page 7] Internet-Draft Media Concepts and Relations January 2013 of the media source jointly achieved by all dependent encodings is said to be Scalable. Simulcast and Scalable encoding can also be combined. Both Simulcast and Scalable encodings result in that a single media source generates multiple RTP media streams of the same media type. The division of bandwidth between the Simulcast or Scalable streams for a single media source is application specific and will vary. The total bandwidth for a Simulcast or a Scalable source is the sum of all included RTP media streams. Since all streams in a Simulcast or Scalable source originate from the same capture device, they are closely related and should thus share synchronization context. The first and second customizations listed above, presenting multiple conference users simultaneously, aligned with the presentation needs in the receiver, can also be achieved without mixing operation by simply sending appropriate quality media from those users individually to each receiver. The total bandwidth of this user presentation aggregate is the sum of all included RTP media streams. Audio and video from a single user share synchronization context and can be synchronized. Streams that originate from different users do not have the same synchronization context, which is acceptable since they do not need to be synchronized, but just presented jointly. An actual mixer device need not be either mixing-only or switching- only, but may implement both mixing and switching and may also choose dynamically what to do for a specific media and a specific receiving user on a case-by-case basis or based on some policy. 3.2. WebRTC This section brings up two different instantiations of WebRTC [ref-webrtc10] that stresses different aspects. But let's start with reviewing some important aspects of WebRTC and the MediaStream [ref-media-capture] API. In WebRTC, an application gets access to a media source by calling getUserMedia(), which creates a MediaStream [ref-media-capture] (note the capitalization). A MediaStream consists of zero or more MediaStreamTracks, where each MediaStreamTrack is associated with a media source. These locally generated MediaStreams and their tracks are connected to local media sources, which can be media devices such as video cameras or microphones, but can also be files. An WebRTC PeerConnection (PC) is an association between two endpoints that is capable of communicating media from one end to the other. The PC concept includes establishment procedures, including media negotiation. Thus a PC is an instantiation of a Multimedia Session. Burman & Westerlund Expires August 4, 2013 [Page 8] Internet-Draft Media Concepts and Relations January 2013 When one end-point adds a MediaStream to a PC, the other endpoint will by default receive an encoded representation of the MediaStream and the active MediaStreamTracks. 3.2.1. Mesh-based Multi-party This is a use case of WebRTC which establishes a multi-party communication session by establishing an individual PC with each participant in the communication session. +---+ +---+ | A |<---->| B | +---+ +---+ ^ ^ \ / \ / v v +---+ | C | +---+ Figure 3: WebRTC Mesh-based Multi-party Users A, B and C want to have a joint communication session. This communication session is created using a Web-application without any central conference functionality. Instead, it uses a mesh of PeerConnections to connect each participant's endpoint with the other endpoints. In this example, three double-ended connections are required to connect the three participants, and each endpoint has two PCs. This is an audio and video communication and each end-point has one video camera and one microphone as media sources. Each endpoint creates its own MediaStream with one video MediaStreamTrack and one audio MediaStreamTrack. The endpoints add their MediaStream to both of their PCs. Let's now focus on a single PC; in this case the one established between A and B. During the establishment of this PC, the two endpoints agree to use only a single transport flow for all media types, thus a single RTP session is created between A and B. A's MediaStream has one audio media source that is encoded according to the boundaries established by the PeerConnection establishment signalling, which includes the RTP payload types and thus Codecs supported as well as bit-rate boundaries. The encoding of A's media source is then sent in an RTP stream identified by a unique SSRC. In this case, as there are two media sources at A, two encodings will be created which will be transmitted using two different RTP streams Burman & Westerlund Expires August 4, 2013 [Page 9] Internet-Draft Media Concepts and Relations January 2013 with their respective SSRC. Both these streams will reference the same synchronization context through a common CNAME identifier used by A. B will have the same configuration, thus resulting in at least four SSRC being used in the RTP session part of the A-B PC. Depending on the configuration of the two PCs that A has, i.e. the A-B and the A-C ones, A could potentially reuse the encoding of a media source in both contexts, under certain conditions. First, a common codec and configuration needs to exist and the boundaries for these configurations must allow a common work point. In addition, the required bandwidth capacity needs to be available over the paths used by the different PCs. Both of those conditions are not always true. Thus it is quite likely that the endpoint will sometimes instead be required to produce two different encodings of the same media source. If an application needs to reference the media from a particular endpoint, it can use the MediaStream and MediaStreamTrack as they point back to the media sources at a particular endpoint. This as the MediaStream has a scope that is not PeerConnection specific. The programmer can however implement this differently while supporting the same use case. In this case the programmer creates two MediaStreams that each have MediaStreamTracks that share common media sources. This can be done either by calling getUserMedia() twice, or by cloning the MediaStream obtained by the only getUserMedia() call. In this example the result is two MediaStreams that are connected to different PCs. From an identity perspective, the two MediaStreams are different but share common media sources. This fact is currently not made explicit in the API. 3.2.2. Multi-source Endpoints This section concerns itself with endpoints that have more than one media source for a particular media type. A straightforward example would be a laptop with a built in video camera used to capture the user and a second video camera, for example attached by USB, that is used to capture something else the user wants to show. Both these cameras are typically present in the same sound field, so it will be common to have only a single audio media source. A possible way of representing this is to have two MediaStreams, one with the built in camera and the audio, and a second one with the USB camera and the audio. Each MediaStream is intended to be played with audio and video synchronized, but the user (local or remote) or application is likely to switch between the two captures. It becomes important for a receiving endpoint that it can determine Burman & Westerlund Expires August 4, 2013 [Page 10] Internet-Draft Media Concepts and Relations January 2013 that the audio in the two MediaStreams have the same synchronization context. Otherwise a receiver may playback the same media source twice, with some time overlap, at a switch between playing the two MediaStreams. Being able to determine that they are the same media source further allow for removing redundancy by having a single encoding if appropriate for both MediaStreamTracks. 3.2.3. Media Relaying WebRTC endpoints can relay a received MediaStream from one PC to another by the simple API level maneuver of adding the received MediaStream to the other PC. To realize this in the implementation is more complex. This can also cause some issues from a media perspective. If an application spanning across multiple endpoints that relay media between each other makes a mistake, a media loop can be created. Media Loops could become a significant issue. For example could an audio echo be created, i.e. an endpoint receives its own media without detecting that it is its own media and plays it back with some delay. In case a WebRTC endpoint produces a conceptual media source by mixing incoming MediaStreams, if there is no loop detection, a feedback loop can be created. RTP has loop detection to detect and handle such cases within a single RTP session. However, in the context of WebRTC, the RTP session is local to the PC and thus cannot rely on the RTP level loop detection. Instead, if this protection is needed on the WebRTC MediaStream level, it could for example be achieved by having media source identifiers that can be preserved between the different MediaStreams in the PCs. When relaying media and in case one receives multiple encodings of the same source it is beneficial to know that. For example, if one encoding arrives with a delay of 80 ms and another with 450 ms, being able to choose the one with 80 ms and not be forced to delay all media sources from the same synchronization context to the most delayed source improves performance. 3.2.4. Usage of Simulcast In this section we look at a use case applying simulcast from each user's endpoint to a central conference node to avoid the need for an individual encoding to each receiving endpoint. Instead, the central node chooses which of the available encodings that is forwarded to a particular receiver, like in Section 3.1.3. Burman & Westerlund Expires August 4, 2013 [Page 11] Internet-Draft Media Concepts and Relations January 2013 +-----------+ +------------+ Enc2 +---+ | A +-Enc1|----->| |----->| B | | | | | | +---+ | Src-+-Enc2|----->| | Enc1 +---+ +-----------+ | Mixer |----->| C | | | +---+ | | Enc2 +---+ | |----->| D | +------------+ +---+ Figure 4 In this Communication Session there are four users with endpoints and one middlebox (The Mixer). This is an audio and video communication session. The audio source is not simulcasted and the endpoint only needs to produce a single encoding. For the video source, each endpoint will produce multiple encodings (Enc1 and Enc2 in Figure 4) and transfer them simultaneously to the mixer. The mixer picks the most appropriate encoding for the path from the mixer to each receiving client. Currently there exists no specified way in WebRTC to realise the above, although use-cases and requirements discuss simulcast functionality. The authors believe there exist two possible solution alternatives in the WebRTC context: Multiple Encodings within a PeerConnection: The endpoint that wants to provide a simulcast creates one or more MediaStreams with the media sources it wants to transmit over a particular PC. The WebRTC API provides functionality to enable multiple encodings to be produced for a particular MediaStreamTrack and have possibility to configure the desired quality levels and/or differences for each of the encodings. Using Multiple PeerConnections: There exist capabilities to both negotiate and control the codec, bit-rate, video resolution, frame-rate, etc of a particular MediaStreamTrack in the context of one PeerConnection. Thus one method to provide multiple encodings is to establish multiple PeerConnections between A and the Mixer, where each PC is configured to provide the desired quality. Note that this solution comes in two flavors from an application perspective. One is that the same MediaStream object is added to the two PeerConnections. The second is that two different MediaStream objects, with the same number of MediaStreamTracks and representing the same sources, are created (e.g by cloning), one of them added to the first PeerConnection and the second one to the second PeerConnection. Burman & Westerlund Expires August 4, 2013 [Page 12] Internet-Draft Media Concepts and Relations January 2013 Both of these solutions share a common requirement, the need to separate the received RTP streams not only based on media source, but also on the encoding. However, on an API level the solutions appear different. For Multiple Encodings within the context of a PC, the receiver will need new access methods for accessing and manipulating the different encodings. Using multiple PC instead requires that one can easily determine the shared (simulcasted) media source despite receiving it in multiple MediaStreams on different PCs. If the same MediaStream is added to both PC's the id's of the MediaStream and MediaStreamTracks will be the same, while they will be different if different MediaStream's (but representing the same sources) are added to the two PC's. 3.3. CLUE Telepresence The CLUE framework [I-D.ietf-clue-framework] and use case [I-D.ietf-clue-telepresence-use-cases] documents make use of most, if not all, media concepts that were already discussed in previous sections, and adds a few more. 3.3.1. Telepresence Functionality A communicating CLUE Endpoint can, compared to other types of Endpoints, be characterized by using multiple media resources: o Multiple capture devices, such as cameras or microphones, generating the media for a media source. o Multiple render devices, such as displays or speakers. o Multiple Media Types, such as audio, video and presentation streams. o Multiple remote Endpoints, since conference is a typical use case. o Multiple Encodings (encoded representations) of a media source. o Multiple Media Streams representing multiple media sources. To make the multitude of resources more manageable, CLUE introduces some additional structures. For example, related media sources in a multimedia session are grouped into Scenes, which can generally be represented in different ways, described by alternative Scene Entries. CLUE explicitly separates the concept of a media source from the encoded representations of it and a single media source can be used to create multiple Encodings. It is also possible in CLUE to account for constraints in resource handling, like limitations in possible Encoding combinations due to physical device implementation. Burman & Westerlund Expires August 4, 2013 [Page 13] Internet-Draft Media Concepts and Relations January 2013 The number of media resources typically differ between Endpoints. Specifically, the number of available media resources of a certain type used for sending at the sender side typically does not match the number of corresponding media resources used for receiving at the receiver side. Some selection process must thus be applied either at the sender or the receiver to select a subset of resources to be used. Hence, each resource that need to be part of that selection process must have some identification and characterization that can be understood by the selecting party. In the CLUE model, the sender (Provider) announces available resources and the receiver (Consumer) chooses what to receive. This choice is made independently in the two directions of a bi-directional communication. 3.3.2. Distributed Endpoint The definition of a single CLUE Endpoint in the framework [I-D.ietf-clue-framework] says it can consist of several physical devices with source and sink media streams. This means that each logical node of such distributed Endpoint can have a separate transport interface, and thus that media sources originating from the same Endpoint can have different transport addresses. 4. Discussion This section discusses some conclusions the authors make based on the use cases. First we will discuss commonalities between use cases. Secondly we will provide a summary of issues we see affect WebRTC. Lastly we consider aspects that need to be considered in the SDP evolution that is ongoing. 4.1. Commonalities in Use Cases The above use cases illustrate a couple of concepts that are not well defined, nor have they fully specified standard mechanisms or behaviors. This section contains a discussion of such concepts, which the authors believe are useful in more than one context and thus should be defined to provide a common function when needed by multi-media communication applications. 4.1.1. Media Source In several of the above use cases there exist a need for a separation between the media source, the particular encoding and its transport stream. In vanilla RTP there exist a one-to-one mapping between these; one media source is encoded in one particular way and transported as one RTP stream using a single SSRC in a particular RTP session. Burman & Westerlund Expires August 4, 2013 [Page 14] Internet-Draft Media Concepts and Relations January 2013 The reason for not keeping a strict one-to-one mapping, allowing the media source to be identified separately from the RTP media stream (SSRC), varies depending on the application's needs and the desired functionalities: Simulcast: Simulcast is a functionality to provide multiple simultaneous encodings of the same media source. As each encoding is independent of the other, in contrast to scalable encoding, independent transport streams for each encoding is needed. The receiver of a simulcast stream will need to be able to explicitly identify each encoding upon reception, as well as which media source it is an encoding of. This is especially important in a context of multiple media sources being provided from the same endpoint. Mesh-based communication: When a communication application implements multi-party communication through a mesh of transport flows, there exist a need for tracking the original media source, especially when relaying between nodes is possible. It is likely that the encodings provided over the different transports are different. If an application uses relaying between different transports, an endpoint may, intentionally or not, receive multiple encodings of the same media source over the same or different transports. Some applications can handle the needed identification, but some can benefit from a standardized method to identify sources. The second argument above can be generalized into a common need in applications that utilize multiple multimedia sessions, such as multiple PeerConnections or multiple SIP/SDP-established RTP sessions, to form a larger communication session between multiple endpoints. These applications commonly need to track media sources that occur in more than one multimedia session. Looking at both CLUE and WebRTC, they appear to contain their own variants of the concept that was above denoted a media source. In CLUE it is called Media Capture. In WebRTC each MediaStreamTrack is identifiable, however, several MediaStreamTracks can share the actual source, and there is no way for the application to realize this currently. The identification of sources is being discussed, and there is a proposal [ref-leithead] that introduces the concept 'Track Source'. Thus, in this document we see the media source as the generalized commonality between these two concepts. Giving each media source a unique identifier in the communication session/context that is reused in all the PeerConnections or SIP/SDP-established RTP sessions would enable loop detection, correctly associate alternative encodings and provide a common name across the endpoints for application logic to reference the actual media source rather than a Burman & Westerlund Expires August 4, 2013 [Page 15] Internet-Draft Media Concepts and Relations January 2013 particular encoding or transport stream. It is arguable if the application should really know a long term persistent source identification, such as based on hardware identities, for example due to fingerprinting issues, and it would likely be better to use an anonymous identification that is still unique in a sufficiently wide context, for example within the communication application instance. 4.1.2. Encodings An Encoding is a particular encoded representation of a particular media source. In the context of RTP and Signalling, a particular encoding must fit the established parameters, such as RTP payload types, media bandwidths, and other more or less codec-specific media constraints such as resolution, frame-rate, fidelity, audio bandwidth, etc. In the context of an application, it appears that there are primarily two considerations around the use of multiple encodings. The first is how many and what their defining parameters are. This may require to be negotiated, something the existing signalling solutions, like SDP, currently lack support for. For example in SDP, there exist no way to express that you would like to receive three different encodings of a particular video source. In addition, if you for example prefer these three encodings to be 720p/25 Hz, 360p/25 Hz and 180p/12.5 Hz, and even if you could define RTP payload types with these constraints, they must be linked to RTP streams carrying the encodings of the particular source. Also, for some RTP payload types there exist difficulties to express encoding characteristics with the desired granularity. The number of RTP payload types that can be used for a particular potential encoding can also be a constraint, especially as a single RTP payload type could well be used for all three target resolutions and frame rates in the example. Using multiple encodings might even be desirable for multi-party conferences that switches video, rather than composites and re-encodes it. It might be that SDP is not the most suitable place to negotiate this. From an application perspective, utilizing clients that have standardized APIs or protocols to control them, there exist a need for the application to express what it prefers in number of encodings as well as what their primary target parameters are. Secondly, some applications may need explicit indication of what encoding a particular stream represents. In some cases this can be deduced based on information such as RTP payload types and parameters received in the media stream, but such implicit information will not Burman & Westerlund Expires August 4, 2013 [Page 16] Internet-Draft Media Concepts and Relations January 2013 always be detailed enough and it may also be time-consuming to extract. For example, in SDP there is currently limitations for binding the relevant information about a particular encoding to the corresponding RTP stream, unless only a single RTP stream is defined per media description (m= line). The CLUE framework explicitly discusses encodings as constraints that are applied when transforming a media source (capture) into what CLUE calls a capture encoding. This includes both explicit identification as well as a set of boundary parameters such as maximum width, height, frame rate as well as bandwidth. In WebRTC nothing related has yet been defined, and we note this as an issue that needs to be resolved. This as the authors expect that support for multiple encodings will be required to enable simulcast and scalability. 4.1.3. Synchronization contexts The shortcomings around synchronization contexts appears rather limited. In RTP, each RTP media stream is associated with a particular synchronization context through the CNAME session description item. The main concerns here are likely twofold. The first concern is to avoid unnecessary creation of new contexts, and rather correctly associate with the contexts that actually exist. For example, WebRTC MediaStreams are defined so that all MediaStreamTracks within a particular MediaStream shall be synchronized. An easy method for meeting this would be to assign a new CNAME for each MediaStream. However, that would ignore the fact that several media sources from the same synchronization context may appear in different combinations across several MediaStreams. Thus all these MediaStreams should share synchronization context to avoid playback glitches, like playing back different instantiations of a single media source out of sync because the media source was shared between two different MediaStreams. The second problem is that synchronization context identification in RTP, i.e. CNAME, is overloaded as an endpoint identifier. As an example, consider an endpoint that has two synchronization contexts; one for audio and video in the room and another for an audio and video presentation stream, like the output of an DVD player. Relying on that an endpoint has only a single synchronization context and CNAME may be incorrect and could create issues that an application designer as well as RTP and signalling extension specifications need to watch out for. CLUE discusses so far quite little about synchronization, but clearly intends to enable lip synchronization between captures that have that relation. The second issue is however quite likely to be encountered Burman & Westerlund Expires August 4, 2013 [Page 17] Internet-Draft Media Concepts and Relations January 2013 in CLUE due to explicit inclusion of the Scene concept, where different Scenes do not require to share the same synchronization context, but is rather intended for situations where Scenes cannot share synchronization context. 4.1.4. Distributed Endpoints When an endpoint consists of multiple nodes, the added complexity is often local to that endpoint, which is appropriate. However, some few properties of distributed endpoints needs to be tolerated by all entities in a multimedia communication session. The main item is to not assume that a single endpoint will only use a single network address. This is a dangerous assumption even for non-distributed endpoints due to multi-homing and the common deployment of NATs, especially large scale NATs which in worst case uses multiple addresses for a single endpoint's transport flows. Distributed endpoints are brought up in the CLUE context. They are not specifically discussed in the WebRTC context, instead the desire for transport level aggregation makes such endpoints problematic. However, WebRTC does allow for fallback to media type specific transport flows and can thus without issues support distributed endpoints. 4.2. Identified WebRTC issues In the process of identifying commonalities and differences between the different use cases we have identified what to us appears to be issues in the current specification of WebRTC that needs to be reviewed. 1. If simulcast or scalability are to be supported at all, the WebRTC API will need to find a method to deal more explicitly with the existence of different encodings and how these are configured, accessed and referenced. For simulcast, the authors see a quite straightforward solution where each PeerConnection is only allowed to contain a single encoding for a specific media source and the desired quality level can be negotiated for the full PeerConnection. When multiple encodings are desired, multiple PeerConnections with differences in configuration are established. That would only require that the underlying media source can explicitly be indicated and tracked by the receiver. 2. The current API structure allows to have multiple MediaStreams with fully or partially overlapping media sources. This, combined with multiple PeerConnections and the likely possibility to do relaying, there appears to exist a significant need to determine the underlying media source, despite receiving Burman & Westerlund Expires August 4, 2013 [Page 18] Internet-Draft Media Concepts and Relations January 2013 different MediaStreams with particular media sources encoded in different ways. It is proposed that MediaSources are made possible to identify uniquely across multiple PeerConnections in the context of the communication application. It is however likely that while being unique in a sufficiently large context, the identification should also be anonymous to avoid fingerprinting issues, similar to the situation discussed in Section 4.1.1. 3. Implementations of the MediaStream API must be careful in how they name and deal with synchronization contexts, so that the actual underlying synchronization context is preserved when possible. It should be noted that cannot be done when a MediaStream is created that contains media sources from multiple synchronization contexts. This will instead require resynchronization of contributing sources, creation of a new synchronization context, and inserting the sources into that synchronization context. These issues need to be discussed and an appropriate way to resolve them must be chosen. 4.3. Relevant to SDP evolution The joint MMUSIC / RTCWeb WGs interim meeting in February 2013 will discuss a number of SDP related issues around the handling of multiple sources; the aggregation of multiple media types over the same RTP session as well as RTP sharing its transport flow not only with ICE/STUN but also with the WebRTC data channel using SCTP/DTLS/ UDP. These issues will potentially result in a significant impact on SDP. It may also impact other ongoing work as well as existing usages and applications, making these discussions difficult. The above use cases and discussion points to the existence of a number of commonalities between WebRTC and CLUE, and that a solution should preferably be usable by both. It is a very open question how much functionality CLUE requires from SDP, as CLUE WG plans to develop a protocol with a different usage model. The appropriate division in functionality between SDP and this protocol is currently unknown. Based on this document, it is possible to express some protocol requirements when negotiating multimedia sessions and their media configurations. Note that this is written as requirements to consider, given that one believes this functionality is needed in SDP. The Requirements: Burman & Westerlund Expires August 4, 2013 [Page 19] Internet-Draft Media Concepts and Relations January 2013 Encoding negotiation: For Simulcast and Scalability in applications, it must be possible to negotiate the number and the boundary conditions for the desired encodings created from a particular media source. Media Resource Identification: SDP-based applications that need explicit information about media sources, multiple encodings and their related RTP media streams could benefit from a common way of providing this information. This need can result in multiple different actual requirements. Some require a common, explicit identification of media sources across multiple signalling contexts. Some may require explicit indication of which set of encodings that has the same media source and thus which sets of RTP media streams (SSRCs) that are related to a particular media source. RTP media stream parameters: With a greater heterogeneity of the possible encodings and their boundary conditions, situations may arise where some or sets of RTP media streams will need to have specific sets of parameters associated with them, compared to other (sets of) RTP media streams. The above are general requirements and in some cases the appropriate point to address the requirement may not even be SDP. For example, media source identification could primarily be put in an RTCP Session Description (SDES) item, and only when so required by the application also be included in the signalling. The discussion in this document has impact on the high level decision regarding how to relate RTP media streams to SDP media descriptions. However, as it is currently presenting concepts rather than giving concrete proposals on how to enable these concepts as extensions to SDP or other protocols, it is difficult to determine the actual impact that a high level solution will have. However, the authors are convinced that neither of the directions will prevent the definition of suitable concepts in SDP. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Burman & Westerlund Expires August 4, 2013 [Page 20] Internet-Draft Media Concepts and Relations January 2013 6. Security Considerations The realization of the proposed concepts and the resolution will have security considerations. However, at this stage it is unclear if any has not already common considerations regarding preserving privacy, confidentiality and ensure integrity to prevent denial of service or quality degradations. 7. Informative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Multiple Media Types in an RTP Session", draft-ietf-avtcore-multi-media-rtp-session-01 (work in progress), October 2012. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-08 (work in progress), December 2012. [I-D.ietf-clue-telepresence-use-cases] Romanow, A., Botzko, S., Duckworth, M., Even, R., and I. Communications, "Use Cases for Telepresence Multi- streams", draft-ietf-clue-telepresence-use-cases-04 (work in progress), August 2012. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-bundle-negotiation-01 (work in progress), August 2012. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- based Applications", draft-ietf-rtcweb-overview-05 (work in progress), December 2012. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Burman & Westerlund Expires August 4, 2013 [Page 21] Internet-Draft Media Concepts and Relations January 2013 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication", RFC 6465, December 2011. [ref-leithead] Microsoft, "Proposal: Media Capture and Streams Settings API v6, https://dvcs.w3.org/hg/dap/raw-file/tip/ media-stream-capture/proposals/ SettingsAPI_proposal_v6.html", December 2012. [ref-media-capture] "Media Capture and Streams, http://dev.w3.org/2011/webrtc/editor/getusermedia.html", December 2012. [ref-webrtc10] "WebRTC 1.0: Real-time Communication Between Browsers, http://dev.w3.org/2011/webrtc/editor/webrtc.html", January 2013. Authors' Addresses Bo Burman Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 13 11 Email: bo.burman@ericsson.com Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Burman & Westerlund Expires August 4, 2013 [Page 22] --------------080706010305080101000300-- From adam@nostrum.com Thu Jan 31 16:17:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83EE21F8923 for ; Thu, 31 Jan 2013 16:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aBsYYmGZkqL for ; Thu, 31 Jan 2013 16:17:37 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEF621F8A1C for ; Thu, 31 Jan 2013 16:17:36 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r110Ha9K069727 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 18:17:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <510B09A0.5040904@nostrum.com> Date: Thu, 31 Jan 2013 18:17:36 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 00:17:37 -0000 Based on the conversations we've had so far, I've put together the following summary of my thoughts on the topic of whether we want to put multiple media streams in a single m= line. http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt Sorry for the relatively short lead time before next week's meeting -- I had meant to put this kind of summary together a week or two ago, but have been far busier than I anticipated. /a From pkyzivat@alum.mit.edu Thu Jan 31 16:57:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5621F8930 for ; Thu, 31 Jan 2013 16:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41CqTwq46ZR7 for ; Thu, 31 Jan 2013 16:57:35 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E1CB421F8948 for ; Thu, 31 Jan 2013 16:57:34 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id uo2g1k00F0QuhwU53oxaHz; Fri, 01 Feb 2013 00:57:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id uoxa1k0033ZTu2S3NoxaRX; Fri, 01 Feb 2013 00:57:34 +0000 Message-ID: <510B12FD.9060603@alum.mit.edu> Date: Thu, 31 Jan 2013 19:57:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <510B09A0.5040904@nostrum.com> In-Reply-To: <510B09A0.5040904@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359680254; bh=gBPqmlC+BkSyiirVJDKBCrGPBF4Ifge5dDCf7kI5rks=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TVcalhbzT95a30Y5KQ+k/lZ7PWgcqIyCBzklEvGg3V15yJwQ1g7OiWGdddFhbsTpC zSCnUiz+1dyKqS/5xawsU+cyo6r7RbHJwvhrZ+XnNjlP5N6raO/IhnRepoIxsCqVor 5knW18JIRU9tl4+jc9Eio7wQbjhKOdmbtOq0Ktyf4kAUKbpMzdpURcmFvx9tcAomZR ottTl2zuZswQdlTBRjupewtYX+FrA43uVPF1Y3PToul/x545bJsKPx9KmaFdSmO6aE GMovWerC1Ubz3zHBvoaG7Ar6xfWepf2P+z73yLymMqdqLHGLxa6cwaRZHzt5C65V7q VkY8bPwWweBnA== Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 00:57:35 -0000 Adam, Thanks for writing this. A few thoughts about it: 1) Putting session-level attributes in the first m-line has problems if that m-line is rejected and others are accepted. Maybe this can be solved with some more text in a new draft. But it will likely have backward compatibility problems. 2) For option 2, when you talk about a single stream per m= section, exactly what do you mean? Do you mean a single SSRC? If so, is a=ssrc used to specify which one? Or do you mean that the m= section applies to one RTP stream at a time, but might (serially) apply to different SSRCs without new O/A exchanges? I can possibly buy in to having as many m-lines as concurrently active RTP-streams. But having to exchange SDP when SSRCs change is hard to accept. Thanks, Paul On 1/31/13 7:17 PM, Adam Roach wrote: > Based on the conversations we've had so far, I've put together the > following summary of my thoughts on the topic of whether we want to put > multiple media streams in a single m= line. > > http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt > > Sorry for the relatively short lead time before next week's meeting -- I > had meant to put this kind of summary together a week or two ago, but > have been far busier than I anticipated. > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From thomas.stach@siemens-enterprise.com Thu Jan 31 23:48:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0312821F8840 for ; Thu, 31 Jan 2013 23:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcMQGiF9cv2M for ; Thu, 31 Jan 2013 23:48:19 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 388D521F8804 for ; Thu, 31 Jan 2013 23:48:19 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5065123F04BC; Fri, 1 Feb 2013 08:48:18 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.175]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 1 Feb 2013 08:48:18 +0100 From: "Stach, Thomas" To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Thoughts on m= lines and media streams Thread-Index: AQHOABGcgSwdjVW3TEmGpNH9KaxSAJhkoG+w Date: Fri, 1 Feb 2013 07:48:17 +0000 Message-ID: References: <510B09A0.5040904@nostrum.com> In-Reply-To: <510B09A0.5040904@nostrum.com> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 07:48:20 -0000 Adam, thanks for analysing the various proposals and putting the draft together. >From a quick read I have some issues with backward compatibility of your pr= oposal to include=20 "common" attributes only in the first m-section. Assuming that the examples in the draft are offers, an answerer that didn't implement any of the mechanisms would probably show the following behavior. =20 Alternativ 1a and 2 have ICE candidates only for the first m-section. An answerer that doesn't understand the grouping semantics could - dependent on the network topology - end up having audio, but no video connectivity. =20 With having other attributes only in the first m-section we could get other= issues. Alternative 1b doesn't have this problem, but the offer would most likely be rejected resulting in no media at all.=20 I preferred the original mmt proposal as it had additional m-sections, that could be accepted by a legacy answerer without the need for a GW that = performs complex SDP operations. Regards Thomas Adam Roach wrote: > Based on the conversations we've had so far, I've put together the > following summary of my thoughts on the topic of whether we > want to put > multiple media streams in a single m=3D line. >=20 > http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt >=20 > Sorry for the relatively short lead time before next week's > meeting -- I > had meant to put this kind of summary together a week or two ago, but > have been far busier than I anticipated. >=20 > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic=