From rlb@ipv.sx Fri Oct 4 07:41:24 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 107D921F923D for ; Fri, 4 Oct 2013 07:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfhKgguOtEsD for ; Fri, 4 Oct 2013 07:41:11 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id B330821F9649 for ; Fri, 4 Oct 2013 07:36:16 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k14so4053518oag.33 for ; Fri, 04 Oct 2013 07:36:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IiI+xjEZGsDohKOR6lWQge6hqErpf276UhcLhyPgrMY=; b=PMSYdz4Yx1m69UAL7wNQaOchf2NDP3yFSMVWt6rlMLI24FtQve1p4h3gjL5IO/+OF5 j1sIr3KN3L8su7SAZkHkVReBa+lms6UlCnsDK/+A29Py1Wh2XFxa2M0g4C202CV8wnhc z1SbcHvWMnK+1p1WsIBepVzFNtZaUOqe7dn//z2bQp0MP0yTcuL2pRLNEKS+CdhyF7ef iGpbCO+SRAE2KqhzpDio++KQ3Aqw2ATVvFoiBAHOLPT5N82iGAkWkRc2GfPODUCEEQzk mMRZPC+4RI6WkApyPi2DPZB+owieP6W9CsZYF8HIGj3ggZ+apDiA/aDXn4+sEWEYwX44 NcXw== X-Gm-Message-State: ALoCoQkE3961J3PiWlqZkQmYNOOxPaDYfvcp+vCUa8Xm1OSDA73VXCDn1UaqxFU5jehDTlYGTDjr MIME-Version: 1.0 X-Received: by 10.60.138.136 with SMTP id qq8mr234589oeb.59.1380897375958; Fri, 04 Oct 2013 07:36:15 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Fri, 4 Oct 2013 07:36:15 -0700 (PDT) In-Reply-To: <523AEC68.5050005@nteczone.com> References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> Date: Fri, 4 Oct 2013 10:36:15 -0400 Message-ID: From: Richard Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b41ccf890dd6f04e7eb392e Cc: mmusic mailing list Subject: Re: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.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 Oct 2013 14:41:24 -0000 --047d7b41ccf890dd6f04e7eb392e Content-Type: text/plain; charset=ISO-8859-1 Is this really a conflict? In the "c=" line, the addrtype is scoped to either the "ATM" or "E164" nettype, so it's clear which one is meant. I think the only thing to do here is just have both RFC 3108 and this document as references in the registry. --Richard On Thu, Sep 19, 2013 at 8:22 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > FYI, I was looking at the IANA registry for SDP parameters ( > http://www.iana.org/**assignments/sdp-parameters/**sdp-parameters.xhtml) > and noticed that there was a registration for addrtype E164 linked to this > CS draft. > > There's a problem that there's already an addrtype E164 in RFC3108. This > earlier usage of E164 should have been registered with IANA but seems to > have been missed. To complicate things the format of the RFC3108 E164 > addrtype is different to the one in the CS draft. > > I've already raised this with IANA but I thought it would be worth > mentioning in MMUSIC. > > Christian > > > > On 2/07/2013 4:56 AM, The IESG wrote: > >> The IESG has approved the following document: >> - 'Session Description Protocol (SDP) Extension For Setting Audio and >> Video Media Streams Over Circuit-Switched Bearers In The Public >> Switched Telephone Network (PSTN)' >> (draft-ietf-mmusic-sdp-cs-21.**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 Richard Barnes. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/**doc/draft-ietf-mmusic-sdp-cs/ >> >> >> >> >> *Technical Summary >> * >> >> The document 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 Publich Switched Telephone Network (PSTN) >> >> *Working Group Summary >> * >> >> The WG had some discussion around the format to use for E.164 numbers >> and whether to align this with the existing definition in RFC 3108. The >> RFC 3108 definition was seen as deficient and the WG agreed it was >> better to align with relevant parts of the tel URI format defined in RFC >> 3966, not least since SDP address types are defined in the context of a >> particular network type, and hence RFC 3108 compatibility is not a >> concern (the implication is that the "E164" address type may differ >> between network types in SDP). >> >> *Document Quality >> * >> >> There are currently no known implementations of the draft, however the >> draft is a dependency for 3GPP, so future implementations are expected. >> >> The document has received good overall review in the WG, some of which >> resulted in changes to the detailed specification. The document has been >> reviewed in detail several times, including of the last few versions. >> The major contributors to these as well as earlier discussions are >> listed in the Acknowledgements section of the document. >> >> >> *Personnel >> * >> >> Document Shepherd: Flemming Andreasen >> Responsible AD: Gonzalo Camarillo >> ______________________________**_________________ >> 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 > --047d7b41ccf890dd6f04e7eb392e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is this really a conflict? =A0In the "c=3D" line= , the addrtype is scoped to either the "ATM" or "E164" = nettype, so it's clear which one is meant. =A0I think the only thing to= do here is just have both RFC 3108 and this document as references in the = registry.

--Richard


On Thu, Sep 19, 2013 at 8:22 AM, Christian Groves <Christian.Groves@nteczone.com> wrote:
FYI, I was looking at the IANA registry for = SDP parameters ( http://www.iana.org/assignme= nts/sdp-parameters/sdp-parameters.xhtml) and noticed that there = was a registration for addrtype E164 linked to this CS draft.

There's a problem that there's already an addrtype E164 in RFC3108.= This earlier usage of E164 should have been registered with IANA but seems= to have been missed. To complicate things the format of the RFC3108 E164 a= ddrtype is different to the one in the CS draft.

I've already raised this with IANA but I thought it would be worth ment= ioning in MMUSIC.

Christian



On 2/07/2013 4:56 AM, The IESG wrote:
The IESG has approved the following document:
- 'Session Description Protocol (SDP) Extension For Setting Audio and =A0 =A0 Video Media Streams Over Circuit-Switched Bearers In The Public
=A0 =A0 Switched Telephone Network (PSTN)'
=A0 =A0(draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-c= s/




*Technical Summary
*

The document 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 Publich Switched Telephone Network (PSTN)

*Working Group Summary
*

The WG had some discussion around the format to use for E.164 numbers
and whether to align this with the existing definition in RFC 3108. The
RFC 3108 definition was seen as deficient and the WG agreed it was
better to align with relevant parts of the tel URI format defined in RFC 3966, not least since SDP address types are defined in the context of a
particular network type, and hence RFC 3108 compatibility is not a
concern (the implication is that the "E164" address type may diff= er
between network types in SDP).

*Document Quality
*

There are currently no known implementations of the draft, however the
draft is a dependency for 3GPP, so future implementations are expected.

The document has received good overall review in the WG, some of which
resulted in changes to the detailed specification. The document has been reviewed in detail several times, including of the last few versions.
The major contributors to these as well as earlier discussions are
listed in the Acknowledgements section of the document.


*Personnel
*

Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo
_______________________________________________
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

--047d7b41ccf890dd6f04e7eb392e-- From Christian.Groves@nteczone.com Sun Oct 6 03:41: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 B2BEC21F9FC7 for ; Sun, 6 Oct 2013 03:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hToF8Ppz6lQ9 for ; Sun, 6 Oct 2013 03:41:31 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id F11D111E80E6 for ; Sun, 6 Oct 2013 03:41:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJs9UVJ20Uup/2dsb2JhbAANTIM/wSBKgSmDGQEBAQQBAQE1GxsKARALDgoJFgQEBwkDAgECARUfEQYNAQUCAQEFiAmoJZJrj1EHhCMDmTCSN4FS Received: from ppp118-209-75-169.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.75.169]) by ipmail07.adl2.internode.on.net with ESMTP; 06 Oct 2013 21:11:17 +1030 Message-ID: <52513E4B.6080006@nteczone.com> Date: Sun, 06 Oct 2013 21:41:15 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Barnes References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic mailing list Subject: Re: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.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: Sun, 06 Oct 2013 10:41:32 -0000 Hello Richard, I guess you mean the "ATM" or "PSTN" nettype? If you assume "c=" line scopes then in theory there's not an issue. However I'm not aware of any other parameters/values in that registry that are duplicated. This essential means no other SDP parameter/value is scoped to understand the syntax except E164. Regards, Christian On 5/10/2013 12:36 AM, Richard Barnes wrote: > Is this really a conflict? In the "c=" line, the addrtype is scoped > to either the "ATM" or "E164" nettype, so it's clear which one is > meant. I think the only thing to do here is just have both RFC 3108 > and this document as references in the registry. > > --Richard > > > On Thu, Sep 19, 2013 at 8:22 AM, Christian Groves > > > wrote: > > FYI, I was looking at the IANA registry for SDP parameters ( > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) > and noticed that there was a registration for addrtype E164 linked > to this CS draft. > > There's a problem that there's already an addrtype E164 in > RFC3108. This earlier usage of E164 should have been registered > with IANA but seems to have been missed. To complicate things the > format of the RFC3108 E164 addrtype is different to the one in the > CS draft. > > I've already raised this with IANA but I thought it would be worth > mentioning in MMUSIC. > > Christian > > > > On 2/07/2013 4:56 AM, The IESG wrote: > > The IESG has approved the following document: > - 'Session Description Protocol (SDP) Extension For Setting > Audio and > Video Media Streams Over Circuit-Switched Bearers In The > Public > Switched Telephone Network (PSTN)' > (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ > > > > > *Technical Summary > * > > The document 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 Publich Switched Telephone Network (PSTN) > > *Working Group Summary > * > > The WG had some discussion around the format to use for E.164 > numbers > and whether to align this with the existing definition in RFC > 3108. The > RFC 3108 definition was seen as deficient and the WG agreed it was > better to align with relevant parts of the tel URI format > defined in RFC > 3966, not least since SDP address types are defined in the > context of a > particular network type, and hence RFC 3108 compatibility is not a > concern (the implication is that the "E164" address type may > differ > between network types in SDP). > > *Document Quality > * > > There are currently no known implementations of the draft, > however the > draft is a dependency for 3GPP, so future implementations are > expected. > > The document has received good overall review in the WG, some > of which > resulted in changes to the detailed specification. The > document has been > reviewed in detail several times, including of the last few > versions. > The major contributors to these as well as earlier discussions are > listed in the Acknowledgements section of the document. > > > *Personnel > * > > Document Shepherd: Flemming Andreasen > Responsible AD: Gonzalo Camarillo > _______________________________________________ > 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 Sun Oct 6 18:38:38 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 41C4321E8119 for ; Sun, 6 Oct 2013 18:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cclsn8WClqv for ; Sun, 6 Oct 2013 18:38:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 18B1621E8114 for ; Sun, 6 Oct 2013 18:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3530; q=dns/txt; s=iport; t=1381109913; x=1382319513; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TnBYJFBSN7/fZt845I1pACRhiJFsXC8Nn03fMG3tCAU=; b=c8doOkhdN3UH/TlKc2GeX/KDyZtozAsYSoSE9ZR5V5UejSHEEELgZtH1 t+dgcnpjX5eGhxPOqU89amHb85JoTMLd2lqjwvZpxmyY8vN6c/H5THmUZ qdvshET5kLOT5zPloCO+yP37TecYcaEHsk6e7Er5qYCz8n96WZLNLjS7G c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEKAJoPUlKrRDoH/2dsb2JhbABZgwc4rR+UA0qBFxZ0giUBAQEEAQEBNTYKARALGAkWBAsJAwIBAgEVMAYNAQUCAQEFh3wNuk2OGIE5B4QjA5gBgS+QUYFmgVoggTU X-IronPort-AV: E=Sophos;i="4.90,1046,1371081600"; d="scan'208";a="90783712" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 07 Oct 2013 01:38:32 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r971cV4R032743; Mon, 7 Oct 2013 01:38:31 GMT Message-ID: <5252109C.7020609@cisco.com> Date: Sun, 06 Oct 2013 21:38:36 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christian Groves References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> In-Reply-To: <523AEC68.5050005@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic mailing list Subject: Re: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.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 Oct 2013 01:38:38 -0000 Hi Christian We had a thread on this particular issue about a year ago. See http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html and the conclusion in http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html I hope this addresses your concern as it relates to -cs draft. Thanks -- Flemming On 9/19/13 8:22 AM, Christian Groves wrote: > FYI, I was looking at the IANA registry for SDP parameters ( > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) > and noticed that there was a registration for addrtype E164 linked to > this CS draft. > > There's a problem that there's already an addrtype E164 in RFC3108. > This earlier usage of E164 should have been registered with IANA but > seems to have been missed. To complicate things the format of the > RFC3108 E164 addrtype is different to the one in the CS draft. > > I've already raised this with IANA but I thought it would be worth > mentioning in MMUSIC. > > Christian > > > On 2/07/2013 4:56 AM, The IESG wrote: >> The IESG has approved the following document: >> - 'Session Description Protocol (SDP) Extension For Setting Audio and >> Video Media Streams Over Circuit-Switched Bearers In The Public >> Switched Telephone Network (PSTN)' >> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >> >> >> >> >> *Technical Summary >> * >> >> The document 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 Publich Switched Telephone Network (PSTN) >> >> *Working Group Summary >> * >> >> The WG had some discussion around the format to use for E.164 numbers >> and whether to align this with the existing definition in RFC 3108. The >> RFC 3108 definition was seen as deficient and the WG agreed it was >> better to align with relevant parts of the tel URI format defined in RFC >> 3966, not least since SDP address types are defined in the context of a >> particular network type, and hence RFC 3108 compatibility is not a >> concern (the implication is that the "E164" address type may differ >> between network types in SDP). >> >> *Document Quality >> * >> >> There are currently no known implementations of the draft, however the >> draft is a dependency for 3GPP, so future implementations are expected. >> >> The document has received good overall review in the WG, some of which >> resulted in changes to the detailed specification. The document has been >> reviewed in detail several times, including of the last few versions. >> The major contributors to these as well as earlier discussions are >> listed in the Acknowledgements section of the document. >> >> >> *Personnel >> * >> >> Document Shepherd: Flemming Andreasen >> Responsible AD: Gonzalo Camarillo >> _______________________________________________ >> 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 Christian.Groves@nteczone.com Sun Oct 6 20:28: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 A77DB21E8133 for ; Sun, 6 Oct 2013 20:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v80hOlsWPflX for ; Sun, 6 Oct 2013 20:28:45 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5F721E8135 for ; Sun, 6 Oct 2013 20:28:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAFopUlJ20V7x/2dsb2JhbAANS4M/wSNKgS2DGQEBAQQ4GyUBEBkKCRYPCQMCAQIBRQYNAQcBAQWICadaknSOGIE5B4QjA605gV0 Received: from ppp118-209-94-241.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.94.241]) by ipmail04.adl6.internode.on.net with ESMTP; 07 Oct 2013 13:58:43 +1030 Message-ID: <52522A69.4020907@nteczone.com> Date: Mon, 07 Oct 2013 14:28:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Flemming Andreasen References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> In-Reply-To: <5252109C.7020609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic mailing list Subject: [MMUSIC] Updating SDP parameter registry 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 Oct 2013 03:28:46 -0000 Hello Flemming, Thanks for pointing out that thread. If Paul as one of the SDP directorate is OK with it then I don't have any issue with the -cs draft. I think though that the addresstype and nettype from RFC3108 still needs to be picked up by the IANA registry. Regards, Christian On 7/10/2013 12:38 PM, Flemming Andreasen wrote: > Hi Christian > > We had a thread on this particular issue about a year ago. See > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html > > and the conclusion in > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html > > I hope this addresses your concern as it relates to -cs draft. > > Thanks > > -- Flemming > > > On 9/19/13 8:22 AM, Christian Groves wrote: >> FYI, I was looking at the IANA registry for SDP parameters ( >> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >> and noticed that there was a registration for addrtype E164 linked to >> this CS draft. >> >> There's a problem that there's already an addrtype E164 in RFC3108. >> This earlier usage of E164 should have been registered with IANA but >> seems to have been missed. To complicate things the format of the >> RFC3108 E164 addrtype is different to the one in the CS draft. >> >> I've already raised this with IANA but I thought it would be worth >> mentioning in MMUSIC. >> >> Christian From albrecht.schwarz@alcatel-lucent.com Mon Oct 7 03:56:21 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 C29FD21E81E4 for ; Mon, 7 Oct 2013 03:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jlrbt4Ji8nm for ; Mon, 7 Oct 2013 03:56:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E416811E80DE for ; Mon, 7 Oct 2013 03:56:07 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r97Au0Ad024456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Oct 2013 05:56:02 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r97Au001030191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 12:56:00 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.70]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 7 Oct 2013 12:56:00 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: Ac60g62jSxVm2TCNSGW1wolV+AvE6AAhc/7wAMub3fD///RlAP/+GRRQgAO+MAD/66WaMA== Date: Mon, 7 Oct 2013 10:55:59 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC0C68BBFR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mmusic@ietf.org" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session 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 Oct 2013 10:56:22 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC0C68BBFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Christer, I may not commit to submit a problem statement in the next couple of weeks,= just due to time reasons. At least a note (or editor's note) should be added to draft mmusic-udptl-dt= ls in order to indicate the issue and that a solution proposal is still pen= ding. Thanks, Albrecht From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 24. September 2013 16:01 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't think putting a note somewhere in the fax draft is going to solve a= nything. As you indicate, the issue exists in multiple documents, so it's a generic = issues. So, my suggestion is that you put together a short draft which describes th= e problem, and how you want to change it, and then we can have a more gener= ic discussion about it. The WG can then decide whether we shall fix somethi= ng, and if so, in which specs. Regards, Christer ________________________________ From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] Sent: Tuesday, 24 September 2013 4:22 PM To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the "copy & paste" action (across at least three "RFCs") seems to be the ro= ot cause of the issue :-( SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific. We got here (wrt DTLS) three (different!) applications: 1) Key exchange (RFC 5763) 2) Conference control (rfc4582bis) 3) Document transmission (udptl-dtls) All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology. Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility. The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules. What we got so far: SDP O/A rules in three application specific "RFCs" (RFC= 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( There might be two options to correct that copy & paste issue in "udptl-dtl= s" in my opinion: a) expand the SDP O/A rules for more flexibility or b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763) What do you think? Best regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Montag, 23. September 2013 11:54 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say: "The endpoint that is the offerer MUST use the setup attribute value of set= up:actpass" ...which we also copied into the udptl-dtls draft. Now, if you want to change that, and allow the Offerer to "force" the direc= tion, I think you should start a separate thread about that. Because, it is= not specific to fax, in my opinion. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 23. syyskuuta 2013 12:31 To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the decision about "DTLS session establishment direction" is ALWAYS up to t= he SDP ANSWERER (according present 3.1). In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active" and "set= up:passive" (besides codepoint "setup:actpass") in my understanding. I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at: a) T - T b) T -GW The existing udptl-dtls & RFC 5763 text seems to focus on model (a) only: S= DP O/A between two peering, terminal located SIP UAs (there is NOT any SIP = B2BUA). But I could imagine that the SIP/SDP profiles for "T" and "GW" are not nece= ssarily the same in case of model (b): "T" as SDP Offerer may not allowed t= o decide the DTLS session establishment direction, but "GW" as SDP offerer = may need to enforce the DTLS session establishment direction (either way). Regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 19. September 2013 10:02 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server. Section 3.1 states: .... The offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the = SDP setup attribute with the setup:active value. Whichever party is active = MUST initiate a DTLS handshake by sending a ClientHello over each flow (hos= t/port quartet). The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC. BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 18. syyskuuta 2013 18:28 To: Christer Holmberg Cc: mmusic@ietf.org Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of a) T - T b) T -GW c) GW-GW I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints. Christer, I thought that the two directions of 1) SIP session establishment and 2) DTLS session establishment should be NOT tightly coupled (as currently supposed to be in clause 3.1)? The ietf draft should offer the flexibility in decoupling both establishmen= t directions. E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ... In my opinion: the IETF should allow the flexibility, other SDOs could still profile/limit this capability. Best regards, Albrecht PS We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP. --_000_786615F3A85DF44AA2A76164A71FE1AC0C68BBFR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Christer,

I may not commit to submi= t a problem statement in the next couple of weeks, just due to time reasons= .

At least a note (or edito= r’s note) should be added to draft mmusic-udptl-dtls in order to indi= cate the issue and that a solution proposal is still pending.

 <= /p>

Thanks,=

Albrecht

 <= /p>

 <= /p>

From: Christer Holmberg [mailto:christer.holmberg@ericsson.= com]
Sent: Dienstag, 24. September 2013 16:01
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

 

Hi Albrecht,

 

I don't think putting a note somewhere in the fa= x draft is going to solve anything.

 

As you indicate, the issue exists in multiple do= cuments, so it's a generic issues.

 

So, my suggestion is that you put together a sho= rt draft which describes the problem, and how you want to change it, and th= en we can have a more generic discussion about it. The WG can then decide whether we shall fix something, and if so, in which spe= cs.

 

Regards,

 

Christer

 

 

From: Schwarz, Albrecht (Albrecht)= [albrecht.schwarz@alcatel-lucent.com]
Sent: Tuesday, 24 September 2013 4:22 PM
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS,= BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hello Christer,

the "copy & paste" action (across at least three "RFCs&q= uot;) seems to be the root cause of the issue :-(

SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific.
We got here (wrt DTLS) three (different!) applications:
1) Key exchange (RFC 5763)
2) Conference control (rfc4582bis)
3) Document transmission (udptl-dtls)

All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs&= quot; (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 := -(

There might be two options to correct that copy & paste issue in "= udptl-dtls" in my opinion:
a) expand the SDP O/A rules for more flexibility
or
b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763)

What do you think?
Best regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO = (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say:

"The endpoint that is the offerer MUST use the setup attribute value o= f setup:actpass"

...which we also copied into the udptl-dtls draft.

Now, if you want to change that, and allow the Offerer to "force"= the direction, I think you should start a separate thread about that. Beca= use, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS, BRUNO = (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hello Christer,

the decision about "DTLS session establishment direction" is ALWA= YS up to the SDP ANSWERER (according present 3.1).

In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active"= ; and "setup:passive" (besides codepoint "setup:actpass"= ;) in my understanding.

I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at:
a) T - T
b) T -GW

The existing udptl-dtls & RFC 5763 text seems to focus on model (a) onl= y: SDP O/A between two peering, terminal located SIP UAs (there is NOT any = SIP B2BUA).
But I could imagine that the SIP/SDP profiles for "T" and "G= W" are not necessarily the same in case of model (b): "T" as= SDP Offerer may not allowed to decide the DTLS session establishment direc= tion, but "GW" as SDP offerer may need to enforce the DTLS sessio= n establishment direction (either way).

Regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:a= ctive value. Whichever party is active MUST initiate a DTLS handshake by se= nding a ClientHello over each flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination.

Regards,

Christer





-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?<= br> The ietf draft should offer the flexibility in decoupling both establishmen= t directions.

E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP.

--_000_786615F3A85DF44AA2A76164A71FE1AC0C68BBFR711WXCHMBA03zeu_-- From christer.holmberg@ericsson.com Mon Oct 7 04:12: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 0101C21E81E1 for ; Mon, 7 Oct 2013 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.179 X-Spam-Level: X-Spam-Status: No, score=-5.179 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCy1xPWop18y for ; Mon, 7 Oct 2013 04:11:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F178221E817B for ; Mon, 7 Oct 2013 04:11:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-f4-525296f5b587 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9E.72.16099.5F692525; Mon, 7 Oct 2013 13:11:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Mon, 7 Oct 2013 13:11:05 +0200 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHOw0vSqs2p+EtM3Ue3aa2C9ZzcDJnpE5VA Date: Mon, 7 Oct 2013 11:11:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM2K7t+7XaUFBBl1rTSz+tP5itNi6PtFi 6vLHLA7MHq3P9rJ6LFnykymAKYrLJiU1J7MstUjfLoEr4+dkq4LZNxkrDn26wdrAOGsPYxcj J4eEgInE2f17oWwxiQv31rOB2EIChxglNu+P6WLkArIXM0rMmjsFqIiDg03AQqL7nzZIjYiA h8T9BcfA6pkF0iQmdK5nArGFBbwllnb2MUHU+Ehs6D0IZRtJPHk+HWwXi4CKxJaLt1hBbF4B X4k7aw6wQ+yaziLx6uttsAZOgWiJT40XwBYwAh33/dQaJohl4hIfDl5nhjhaQGLJnvNQtqjE y8f/WCFsJYlFtz9D1edL3Go8yA6xTFDi5MwnLBMYRWchGTULSdksJGUQcT2JG1OnsEHY2hLL Fr6GqteVmPHvEAuy+AJG9lWM7LmJmTnp5YabGIHRdXDLb90djKfOiRxilOZgURLn/fDWOUhI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI3eUVPeFm/cXWb5ieDjpuGWHsYZQulGBCMO2dcd/ /uU4/l/y3pF3Gtq3Dv69k1fgqM7ml33GcMan3vbGrTVN++KuzD4stOV20jLd6eeOrLY5V1qz UL/XUz1vx2ve2NPtkfHTKqYsL71Vv+qB9e/SEw/W3j4jKvPzF3MgS926t5denv/avvngCV8l luKMREMt5qLiRADqUy1YfAIAAA== Cc: "mmusic@ietf.org" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session 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 Oct 2013 11:12:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Albrecht, At this point, the community is making a decision about whether to start wo= rking on this. Once that is done, we will start looking into, and discuss, individual tech= nical issues etc, and your input will be highly appreciated. Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 7. lokakuuta 2013 13:56 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, I may not commit to submit a problem statement in the next couple of weeks,= just due to time reasons. At least a note (or editor's note) should be added to draft mmusic-udptl-dt= ls in order to indicate the issue and that a solution proposal is still pen= ding. Thanks, Albrecht From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 24. September 2013 16:01 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't think putting a note somewhere in the fax draft is going to solve a= nything. As you indicate, the issue exists in multiple documents, so it's a generic = issues. So, my suggestion is that you put together a short draft which describes th= e problem, and how you want to change it, and then we can have a more gener= ic discussion about it. The WG can then decide whether we shall fix somethi= ng, and if so, in which specs. Regards, Christer ________________________________ From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] Sent: Tuesday, 24 September 2013 4:22 PM To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the "copy & paste" action (across at least three "RFCs") seems to be the ro= ot cause of the issue :-( SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific. We got here (wrt DTLS) three (different!) applications: 1) Key exchange (RFC 5763) 2) Conference control (rfc4582bis) 3) Document transmission (udptl-dtls) All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology. Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility. The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules. What we got so far: SDP O/A rules in three application specific "RFCs" (RFC= 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( There might be two options to correct that copy & paste issue in "udptl-dtl= s" in my opinion: a) expand the SDP O/A rules for more flexibility or b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763) What do you think? Best regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Montag, 23. September 2013 11:54 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say: "The endpoint that is the offerer MUST use the setup attribute value of set= up:actpass" ...which we also copied into the udptl-dtls draft. Now, if you want to change that, and allow the Offerer to "force" the direc= tion, I think you should start a separate thread about that. Because, it is= not specific to fax, in my opinion. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 23. syyskuuta 2013 12:31 To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the decision about "DTLS session establishment direction" is ALWAYS up to t= he SDP ANSWERER (according present 3.1). In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active" and "set= up:passive" (besides codepoint "setup:actpass") in my understanding. I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at: a) T - T b) T -GW The existing udptl-dtls & RFC 5763 text seems to focus on model (a) only: S= DP O/A between two peering, terminal located SIP UAs (there is NOT any SIP = B2BUA). But I could imagine that the SIP/SDP profiles for "T" and "GW" are not nece= ssarily the same in case of model (b): "T" as SDP Offerer may not allowed t= o decide the DTLS session establishment direction, but "GW" as SDP offerer = may need to enforce the DTLS session establishment direction (either way). Regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 19. September 2013 10:02 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server. Section 3.1 states: .... The offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the = SDP setup attribute with the setup:active value. Whichever party is active = MUST initiate a DTLS handshake by sending a ClientHello over each flow (hos= t/port quartet). The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC. BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 18. syyskuuta 2013 18:28 To: Christer Holmberg Cc: mmusic@ietf.org Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of a) T - T b) T -GW c) GW-GW I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints. Christer, I thought that the two directions of 1) SIP session establishment and 2) DTLS session establishment should be NOT tightly coupled (as currently supposed to be in clause 3.1)? The ietf draft should offer the flexibility in decoupling both establishmen= t directions. E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ... In my opinion: the IETF should allow the flexibility, other SDOs could still profile/limit this capability. Best regards, Albrecht PS We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP. --_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Albrech= t,

 = ;

At this po= int, the community is making a decision about whether to start working on t= his.

 = ;

Once that = is done, we will start looking into, and discuss, individual technical issu= es etc, and your input will be highly appreciated.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com= ]
L=E4hetetty: 7. lokakuuta 2013 13:56
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 

Hello Chri= ster,

I may not = commit to submit a problem statement in the next couple of weeks, just due = to time reasons.

At least a= note (or editor’s note) should be added to draft mmusic-udptl-dtls i= n order to indicate the issue and that a solution proposal is still pending.

 = ;

Thanks,

Albrecht

 = ;

 = ;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Dienstag, 24. September 2013 16:01
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS,= BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

 

Hi Albrecht,

 

I don't think putting a note some= where in the fax draft is going to solve anything.

 

As you indicate, the issue exists= in multiple documents, so it's a generic issues.

 

So, my suggestion is that you put= together a short draft which describes the problem, and how you want to ch= ange it, and then we can have a more generic discussion about it. The WG can then decide whether we shall fix something, and if so= , in which specs.

 

Regards,

 

Christer

 

 

From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com]
Sent: Tuesday, 24 September 2013 4:22 PM
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS,= BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hello Christe= r,

the "copy & paste" action (across at least three "RFCs&q= uot;) seems to be the root cause of the issue :-(

SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific.
We got here (wrt DTLS) three (different!) applications:
1) Key exchange (RFC 5763)
2) Conference control (rfc4582bis)
3) Document transmission (udptl-dtls)

All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs&= quot; (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 := -(

There might be two options to correct that copy & paste issue in "= udptl-dtls" in my opinion:
a) expand the SDP O/A rules for more flexibility
or
b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763)

What do you think?
Best regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO = (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say:

"The endpoint that is the offerer MUST use the setup attribute value o= f setup:actpass"

...which we also copied into the udptl-dtls draft.

Now, if you want to change that, and allow the Offerer to "force"= the direction, I think you should start a separate thread about that. Beca= use, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS, BRUNO = (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hello Christer,

the decision about "DTLS session establishment direction" is ALWA= YS up to the SDP ANSWERER (according present 3.1).

In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active"= ; and "setup:passive" (besides codepoint "setup:actpass"= ;) in my understanding.

I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at:
a) T - T
b) T -GW

The existing udptl-dtls & RFC 5763 text seems to focus on model (a) onl= y: SDP O/A between two peering, terminal located SIP UAs (there is NOT any = SIP B2BUA).
But I could imagine that the SIP/SDP profiles for "T" and "G= W" are not necessarily the same in case of model (b): "T" as= SDP Offerer may not allowed to decide the DTLS session establishment direc= tion, but "GW" as SDP offerer may need to enforce the DTLS sessio= n establishment direction (either way).

Regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:a= ctive value. Whichever party is active MUST initiate a DTLS handshake by se= nding a ClientHello over each flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination.

Regards,

Christer





-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?<= br> The ietf draft should offer the flexibility in decoupling both establishmen= t directions.

E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP.

--_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_-- From magnus.westerlund@ericsson.com Mon Oct 7 05:45: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 3D8B621E81C6 for ; Mon, 7 Oct 2013 05:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.206 X-Spam-Level: X-Spam-Status: No, score=-105.206 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji3Y4oSDjYwz for ; Mon, 7 Oct 2013 05:45:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 220AC21E81F5 for ; Mon, 7 Oct 2013 05:45:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-c2-5252aceb3d76 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 52.A3.16099.BECA2525; Mon, 7 Oct 2013 14:45:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 14:44:12 +0200 Message-ID: <5252ACCC.50303@ericsson.com> Date: Mon, 7 Oct 2013 14:45:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <52446E97.8030700@stpeter.im> In-Reply-To: <52446E97.8030700@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre6bNUFBBit+CVssvLOZ3WLq8scs Fsf29DM7MHtsffeO0WPJkp9MHnP3vGAOYI7isklJzcksSy3St0vgylj0uIul4JRuxYc9U5kb GFcrdzFycEgImEh0rc3rYuQEMsUkLtxbz9bFyMUhJHCYUWLT+YVQzjJGiefzW1hAqngFNCWe f1zDDmKzCKhIzPl0mBXEZhOwkLj5o5ENxBYVCJZo3/6VDaJeUOLkzCdgvSICWhKXrvWB9TIL uEjsmdYK1issYCqxf3Y7I4gtBDL//msmEJsTqP7ogensENdJSmxbdAyqV09iytUWRghbXqJ5 62xmiF5tiYamDtYJjEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLDTcxAsP34JbfujsYT50TOcQo zcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGm6DDm/tCVq9KbUoJuzH75IPI Q7Xhe/mc+BYq/u74cr1ycW1g30/v3Oyy7Ru7c+8zya1N0bvWf2b/onsKGpUHTKOe3j7yoU3v peaqBQL6GYoHe5+9mXyoW+kpk5PwA8nVIo+VoxNULu7nWLQk3WfD7Qc1PraSfaX7JpouFwpa mdvU8Ga/vFWBEktxRqKhFnNRcSIAvJMC0i0CAAA= Cc: mmusic@ietf.org, Claudio Allocchio Subject: Re: [MMUSIC] base64 and datetimes in 2326bis 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 Oct 2013 12:45:54 -0000 Hi Peter, Thanks for your feedback, and see inline. Especially on the DATE and Time issue I would appreciate feedback. On 2013-09-26 19:27, Peter Saint-Andre wrote: > Here is some brief feedback on 2326bis. I'm sorry that I don't > have time for a longer review. > > BASE64 > > The usages of Base64 do not specify which exact encoding of Base64 > they require and what to do about padding bits. For example, > Section 18.54 says: > > The binary MIKEY message SHALL be Base64 [RFC4648] encoded before > being included in the value part of the parameter. > > If the specification assumes that the rules from Section 4 of RFC > 4648 are to be used, that text would be more accurate as: > > The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before > being included in the value part of the parameter, where the > encoding adheres to the definition in Section 4 of RFC 4648 and > where the padding bits are set to zero. Yes, you are correct, it is the Section 4 BASE64 mode of the RFC that we want to use here. This will effect three places: Section 18.2: Each credential MUST consist of one URI identifying the proxy or server, the hash algorithm identifier, and the hash over that agent's ASN.1 distinguished encoding rules (DER) encoded certificate [RFC5280] in BASE64, according to Section 4 of [RFC4648] and where the padding bits are set to zero. Section 18.13: The header MUST include the URI of the next hop (proxy or server) and a BASE64 (according to Section 4 of [RFC4648] and where the padding bits are set to zero) encoded binary structure containing a sequence of DER encoded X.509v3 certificates [RFC5280]. Section 18.54: Under MIKEY parameter This parameter can be included both in request and response messages. The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before being included in the value part of the parameter, where the encoding adheres to the definition in Section 4 of RFC 4648 and where the padding bits are set to zero. > > DATETIME FORMATS > > Section 4.4.3 seems to be underspecified: > > Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, > using UTC (GMT). Fractions of a second may be indicated. > > Example for clock format range request for a starting time of > November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC > playing for 10 min and 5 seconds, a Media-Properties header's > "Time- Limited UTC property for 24th of December 2014 at 15 hours > and 00 mins, and a Terminate-Readon headers "time" property for > 18th of June 2013 at 16 hours, 12 minutes and 56 seconds: > > clock=19961108T143720.25Z-19961108T144725.25Z > Time-Limited=20141224T1500Z time=20130618T161256Z > > ISO 8601 has many profiles. Is the profile defined in RFC 3339 > supported? That would result in a datetime of the following form: > > 1996-11-08T14:37:20.25Z > > Also are timezone offsets allowed? > > If the answers are "no" then it would be good to explain that in > the text. The answers are no on both accounts. The reasons is really the ABNF syntax specified since RTSP 1.0 for this. Thus, I have written a new more complete specification for this time format that matches the ABNF and still uses ISO 8601 relevant sections for some clarifications and specifications. Feedback are much appreciated if you think this is complete. 4.4.3. Absolute Time Absolute time is expressed following a specific types of ISO 8601 [ISO.8601.2000] based timestamps. The date is complete representation calendar date in basic format (YYYYMMDD) without separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day is provided in the complete representation basic format (hhmmss) as specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal fractions of seconds following Section 5.3.1.3 requiring "." (full stop) as decimal separator and limiting the number of digits to no more than nine (9). The time expressed MUST be using UTC (GMT), i.e. no timezone offsets allowed. The full date and time specification is the eight digit date followed by a "T" followed by the six digits time value, optionally followed by a full stop followed by one to nine fractions of a second and ended by "Z", e.g. YYYYMMDDThhmmss.ssZ. The reason for this time format rather than using "Date and Time on the Internet: Timestamps" [RFC3339] are historic and using the format specified in RTSP 1.0. The motivations raised in RFC 3339 applies to why a selection from ISO 8601 was done, but a different and even more restrictive selection was applied in this case. Example for clock format range request for a starting time of November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC playing for 10 min and 5 seconds, a Media-Properties header's "Time- Limited UTC property for 24th of December 2014 at 15 hours and 00 mins, and a Terminate-Readon headers "time" property for 18th of June 2013 at 16 hours, 12 minutes and 56 seconds: clock=19961108T143720.25Z-19961108T144725.25Z Time-Limited=20141224T1500Z time=20130618T161256Z 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 fandreas@cisco.com Mon Oct 7 07:34: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 649AA21E81E0 for ; Mon, 7 Oct 2013 07:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7+fvco03dEV for ; Mon, 7 Oct 2013 07:34:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E822521E81B2 for ; Mon, 7 Oct 2013 07:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1537; q=dns/txt; s=iport; t=1381156456; x=1382366056; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TmKH/ZRYZpLiN3g41hOWiFJuKG+3Fi1HtNCdcNmVE9o=; b=ac3NMvrDGNYh0EV0xY2x8EDegmvHyvty8+AjT+LkzCnkFbkGMyj1biSN EmjZnxpEGWF0lNu4dl1ly8KfNifMWK4/dh4PJ0weETMntevqncDQky6X0 +jh8XtiWssq0PZjXAcuXQsXy3sj6Vj3yJpClN6gvqoIXdy0g4NtkYiq0G 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwLADfFUlKtJV2d/2dsb2JhbABZgwc4rR8DlABKgR4WdIIlAQEBAwE4QAEFCwsYCRYPCQMCAQIBRQYNAQcBAQWHdwYMuj6OGIE5B4QjA5gBkgCDQCCBNQ X-IronPort-AV: E=Sophos;i="4.90,1050,1371081600"; d="scan'208";a="265972416" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 07 Oct 2013 14:34:15 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r97EYE61012263; Mon, 7 Oct 2013 14:34:14 GMT Message-ID: <5252C66C.1080701@cisco.com> Date: Mon, 07 Oct 2013 10:34:20 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christian Groves References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> In-Reply-To: <52522A69.4020907@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic mailing list Subject: Re: [MMUSIC] Updating SDP parameter registry 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 Oct 2013 14:34:33 -0000 On 10/6/13 11:28 PM, Christian Groves wrote: > Hello Flemming, > > Thanks for pointing out that thread. If Paul as one of the SDP > directorate is OK with it then I don't have any issue with the -cs draft. > > I think though that the addresstype and nettype from RFC3108 still > needs to be picked up by the IANA registry. > Agreed. -- Flemming > Regards, Christian > > On 7/10/2013 12:38 PM, Flemming Andreasen wrote: >> Hi Christian >> >> We had a thread on this particular issue about a year ago. See >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >> >> and the conclusion in >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >> >> I hope this addresses your concern as it relates to -cs draft. >> >> Thanks >> >> -- Flemming >> >> >> On 9/19/13 8:22 AM, Christian Groves wrote: >>> FYI, I was looking at the IANA registry for SDP parameters ( >>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>> and noticed that there was a registration for addrtype E164 linked >>> to this CS draft. >>> >>> There's a problem that there's already an addrtype E164 in RFC3108. >>> This earlier usage of E164 should have been registered with IANA but >>> seems to have been missed. To complicate things the format of the >>> RFC3108 E164 addrtype is different to the one in the CS draft. >>> >>> I've already raised this with IANA but I thought it would be worth >>> mentioning in MMUSIC. >>> >>> Christian > > . > From magnus.westerlund@ericsson.com Mon Oct 7 07:42: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 A179211E80F2 for ; Mon, 7 Oct 2013 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE9xZAe8cmFX for ; Mon, 7 Oct 2013 07:42:32 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8C11E80E6 for ; Mon, 7 Oct 2013 07:42:31 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-02-5252c8566703 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 3E.04.25272.658C2525; Mon, 7 Oct 2013 16:42:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 16:42:30 +0200 Message-ID: <5252C886.8030200@ericsson.com> Date: Mon, 7 Oct 2013 16:43:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <52446E97.8030700@stpeter.im> <5252ACCC.50303@ericsson.com> In-Reply-To: <5252ACCC.50303@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW7YiaAgg9+/9SwW3tnMbjF1+WMW i2N7+pkdmD22vnvH6LFkyU8mj7l7XjAHMEdx2aSk5mSWpRbp2yVwZWxce4u94JhrxcaDv5ga GCebdTFyckgImEgsWn6ZCcIWk7hwbz1bFyMXh5DAUUaJI1smMUI4yxglru74xw5SxSugLbFk 2xJmEJtFQEWi9/BqFhCbTcBC4uaPRjYQW1QgWKJ9+1c2iHpBiZMzn4DViAiISjy6uIgVxGYW iJY4u28+2ExhAVOJ/bPbgZZxAC1zl3i9LAkkzCmgJTHr5kQWiOMkJbYtOsYO0aonMeVqCyOE LS/RvHU22DlCQKc1NHWwTmAUmoVk8ywkLbOQtCxgZF7FyFGcWpyUm25ksIkRGMAHt/y22MF4 +a/NIUZpDhYlcd6Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDmfd0Z7Ct8YF7IdXnB Vxf/fZS2e7xBoN3b1Uup0Kdl2cUO091TmFqV309N4RLdWH2MebNk+Mz7l/bdWifULOe45+I+ p1azqvDcBxVyYXwTdip4cthp344Q2vD07787nGVM/6dqvvbfJfCVe2/BL+mM4C8bGI7krwyQ KZ8ilxMX7n/ht/yWuEdKLMUZiYZazEXFiQDcTA1YLgIAAA== Cc: Claudio Allocchio Subject: Re: [MMUSIC] base64 and datetimes in 2326bis 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 Oct 2013 14:42:37 -0000 Hi, Claudio Allocchio sent a private comment regarding the NPT formats definition in Section 4.4.2 having similar format issues like Section 4.4.3. This has resulted in my attempting to write a clearer specification. In that work it is clear that this format is not really using ISO 8601 syntax. I have attempted to try to make clear this in the below new definition of NPT syntax. The syntax is based on ISO 8601 [ISO.8601.2000]. Two different notations are allowed. The npt-hhmmss notation are using a ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). With the exception that it expresses duration since presentation start rather than time since midnight and the hour counter is not limited to 0-24 hours, instead up to nineteen (19) digits of hours are allowed. ISO 8601 time format requires all digits to be used for each format, and all format required needs to be included, e.g. if one use a hh:mm:ss format, then that requires two digits for hours, two digits for minutes and two digits for second, a time value such as 7 minutes and 0 seconds, needs to be expressed as 00:07:00. The npt-sec notation is expressing the duration since presentation start in seconds, using one to nineteen (19) digits. Both notations allows decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with the limitation of at maximum of 9 digits and only allowing "." (full stop) as separator. Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations must allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the ntp-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. So please review this and provide feedback on also this change. Cheers Magnus On 2013-10-07 14:45, Magnus Westerlund wrote: > Hi Peter, > > Thanks for your feedback, and see inline. Especially on the DATE and > Time issue I would appreciate feedback. > > On 2013-09-26 19:27, Peter Saint-Andre wrote: >> Here is some brief feedback on 2326bis. I'm sorry that I don't >> have time for a longer review. >> >> BASE64 >> >> The usages of Base64 do not specify which exact encoding of Base64 >> they require and what to do about padding bits. For example, >> Section 18.54 says: >> >> The binary MIKEY message SHALL be Base64 [RFC4648] encoded before >> being included in the value part of the parameter. >> >> If the specification assumes that the rules from Section 4 of RFC >> 4648 are to be used, that text would be more accurate as: >> >> The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before >> being included in the value part of the parameter, where the >> encoding adheres to the definition in Section 4 of RFC 4648 and >> where the padding bits are set to zero. > > Yes, you are correct, it is the Section 4 BASE64 mode of the RFC that > we want to use here. > > This will effect three places: > > Section 18.2: > > Each credential MUST consist of one URI > identifying the proxy or server, the hash algorithm identifier, and > the hash over that agent's ASN.1 distinguished encoding rules (DER) > encoded certificate [RFC5280] in BASE64, according to Section 4 of > [RFC4648] and where the padding bits are set to zero. > > > Section 18.13: > > The header MUST > include the URI of the next hop (proxy or server) and a BASE64 > (according to Section 4 of [RFC4648] and where the padding bits are > set to zero) encoded binary structure containing a sequence of DER > encoded X.509v3 certificates [RFC5280]. > > > Section 18.54: > > Under MIKEY parameter > > This parameter can be included both in > request and response messages. The binary MIKEY message SHALL > be BASE64 [RFC4648] encoded before being included in the value > part of the parameter, where the encoding adheres to the > definition in Section 4 of RFC 4648 and where the padding bits > are set to zero. > > >> >> DATETIME FORMATS >> >> Section 4.4.3 seems to be underspecified: >> >> Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, >> using UTC (GMT). Fractions of a second may be indicated. >> >> Example for clock format range request for a starting time of >> November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC >> playing for 10 min and 5 seconds, a Media-Properties header's >> "Time- Limited UTC property for 24th of December 2014 at 15 hours >> and 00 mins, and a Terminate-Readon headers "time" property for >> 18th of June 2013 at 16 hours, 12 minutes and 56 seconds: >> >> clock=19961108T143720.25Z-19961108T144725.25Z >> Time-Limited=20141224T1500Z time=20130618T161256Z >> >> ISO 8601 has many profiles. Is the profile defined in RFC 3339 >> supported? That would result in a datetime of the following form: >> >> 1996-11-08T14:37:20.25Z >> >> Also are timezone offsets allowed? >> >> If the answers are "no" then it would be good to explain that in >> the text. > > The answers are no on both accounts. The reasons is really the ABNF > syntax specified since RTSP 1.0 for this. Thus, I have written a new > more complete specification for this time format that matches the ABNF > and still uses ISO 8601 relevant sections for some clarifications and > specifications. Feedback are much appreciated if you think this is > complete. > > 4.4.3. Absolute Time > > Absolute time is expressed following a specific types of ISO 8601 > [ISO.8601.2000] based timestamps. The date is complete > representation calendar date in basic format (YYYYMMDD) without > separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day > is provided in the complete representation basic format (hhmmss) as > specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal > fractions of seconds following Section 5.3.1.3 requiring "." (full > stop) as decimal separator and limiting the number of digits to no > more than nine (9). The time expressed MUST be using UTC (GMT), i.e. > no timezone offsets allowed. The full date and time specification is > the eight digit date followed by a "T" followed by the six digits > time value, optionally followed by a full stop followed by one to > nine fractions of a second and ended by "Z", e.g. > YYYYMMDDThhmmss.ssZ. > > The reason for this time format rather than using "Date and Time > on the Internet: Timestamps" [RFC3339] are historic and using the > format specified in RTSP 1.0. The motivations raised in RFC 3339 > applies to why a selection from ISO 8601 was done, but a different > and even more restrictive selection was applied in this case. > > Example for clock format range request for a starting time of > November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC > playing for 10 min and 5 seconds, a Media-Properties header's "Time- > Limited UTC property for 24th of December 2014 at 15 hours and 00 > mins, and a Terminate-Readon headers "time" property for 18th of June > 2013 at 16 hours, 12 minutes and 56 seconds: > > clock=19961108T143720.25Z-19961108T144725.25Z > Time-Limited=20141224T1500Z > time=20130618T161256Z > > > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 ari.keranen@ericsson.com Mon Oct 7 07:44: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 4241E11E80F7 for ; Mon, 7 Oct 2013 07:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv3mnQqdowdp for ; Mon, 7 Oct 2013 07:44:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E37FC21E808F for ; Mon, 7 Oct 2013 07:44:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-df-5252c8ce2833 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 38.97.16099.EC8C2525; Mon, 7 Oct 2013 16:44:30 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 16:44:29 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D6DEE110477; Mon, 7 Oct 2013 17:44:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1D97D56276; Mon, 7 Oct 2013 17:44:22 +0300 (EEST) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CC38E55CF1; Mon, 7 Oct 2013 17:44:21 +0300 (EEST) Message-ID: <5252C8CC.3090804@ericsson.com> Date: Mon, 7 Oct 2013 17:44:28 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvre65E0FBButOS1i8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2PXxqWMBbs5KmZtamVuYLzG1sXIySEhYCKx bXo7M4QtJnHh3nqwuJDAYUaJGx+5uxi5gOz1jBJ7P69lgnD2Mkqc3LWMEcJZxyjR0XuEGaJl BaNEyxdLEJtXQFviwpsNYHEWARWJ9WtOs4DYbAL2EjcnXGcHsUUFkiX2Lj3NDFEvKHFy5hOw GhEBGYm9mzaDxZmB5sy+M4sJxBYGsnefPs4EEbeVuDDnOguELS+x/e0cqBfUJK6e2wR1j6rE 1X+vGCcwCs9CsmIWkvZZSNoXMDKvYmTPTczMSS833MQIDOKDW37r7mA8dU7kEKM0B4uSOO+H t85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhinHZiWwRsx+eeq24cEH+9zuZndU/nv7/pd +lwCLIGPHNxTQyzNK/dqulbKz38UOHXlZe+9p9Y9s/TZ1Rq3YPHaDgkdjfVrfBTrVpypYGZX UuFLeFzddy8md+JX51fbbVLeTry6Nmb2x5PT5Os7FjuVHzXaJablclrTv3nqEUl/R8/sKf63 FMKUWIozEg21mIuKEwEjUa4/MAIAAA== Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 88 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 Oct 2013 14:44:47 -0000 Hi all, MMUSIC has two sessions tentatively scheduled for the IETF 88 meeting at Vancouver: http://tools.ietf.org/agenda/88/ If you want to request a time slot to discuss a draft, please send an e-mail to the chairs as soon as possible, but latest by the end of Friday 18th. As usual, we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time would you need - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Flemming From pkyzivat@alum.mit.edu Mon Oct 7 10:44: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 8C71511E80FC for ; Mon, 7 Oct 2013 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwm3kUHrhQ3X for ; Mon, 7 Oct 2013 10:44:49 -0700 (PDT) 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 1DEC811E8109 for ; Mon, 7 Oct 2013 10:44:49 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id aF111m0010bG4ec55HkoVS; Mon, 07 Oct 2013 17:44:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id aHko1m00W3ZTu2S3PHko1h; Mon, 07 Oct 2013 17:44:48 +0000 Message-ID: <5252F30F.5000007@alum.mit.edu> Date: Mon, 07 Oct 2013 13:44:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> In-Reply-To: <52522A69.4020907@nteczone.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=1381167888; bh=qaVaFmMxOXzHWtfD6vHQVFpprvhjqYnmGMrniwPOHpU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oSecSkGSq+bZHhKXeS8jUmqTHNDiSAZ+N6FA/WPyBavjMINeB6fXN7Uluj+hfxw4F xiZd2fycTlnkKihMEpk2VID49yo0muWJMTgExaEz4bemTdj9SJL2vPtxRczizkY/B1 gKhqpeWb8Jo9e3uLvQEGRO03jbPCKM1T9PjwcIHSB20Ii9VPHGEyo26i1zIqiX0H8S /zS7hMaZWnLA9FMTSgiLiwDEdPjx2jPByjFVWHNf3QmZ5GaAXmleXf0LbTAG7ZLGfW EdwOFuEmo2yLBXz/COHeYqkzOYgIFINaInDhXSCCVftINWCn8NRzTp6fhCZXrGlxMy 8F0GOxSpAFxOg== Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 17:44:54 -0000 On 10/6/13 11:28 PM, Christian Groves wrote: > Hello Flemming, > > Thanks for pointing out that thread. If Paul as one of the SDP > directorate is OK with it then I don't have any issue with the -cs draft. > > I think though that the addresstype and nettype from RFC3108 still needs > to be picked up by the IANA registry. I agree. I'm not sure what the best way to accomplish that is. Perhaps an errata to 3108, pointing out that it fails to register its new nettype and addrtypes with IANA would start the process. Or is there a better way? Thanks, Paul > Regards, Christian > > On 7/10/2013 12:38 PM, Flemming Andreasen wrote: >> Hi Christian >> >> We had a thread on this particular issue about a year ago. See >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >> >> and the conclusion in >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >> >> I hope this addresses your concern as it relates to -cs draft. >> >> Thanks >> >> -- Flemming >> >> >> On 9/19/13 8:22 AM, Christian Groves wrote: >>> FYI, I was looking at the IANA registry for SDP parameters ( >>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>> and noticed that there was a registration for addrtype E164 linked to >>> this CS draft. >>> >>> There's a problem that there's already an addrtype E164 in RFC3108. >>> This earlier usage of E164 should have been registered with IANA but >>> seems to have been missed. To complicate things the format of the >>> RFC3108 E164 addrtype is different to the one in the CS draft. >>> >>> I've already raised this with IANA but I thought it would be worth >>> mentioning in MMUSIC. >>> >>> Christian > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Mon Oct 7 10:52: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 59DAE21E816A for ; Mon, 7 Oct 2013 10:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNeT6oajIrs7 for ; Mon, 7 Oct 2013 10:52:00 -0700 (PDT) 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 3402111E8102 for ; Mon, 7 Oct 2013 10:51:56 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id aC1B1m0040EZKEL59HrsLf; Mon, 07 Oct 2013 17:51:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id aHrs1m00E3ZTu2S3MHrsU5; Mon, 07 Oct 2013 17:51:52 +0000 Message-ID: <5252F4B7.4070303@alum.mit.edu> Date: Mon, 07 Oct 2013 13:51:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> In-Reply-To: <5252109C.7020609@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=1381168312; bh=bzOPuCuWzFx0ujhTLazZSIFldQmjwUvtdZKWGommGnA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gdP20f+kkNVMZHvHlzQHYLqx883gwm3Cb3Q80jZspph6wT0SHWCYlawnI7f6sNzoV xe9VoghmvGcBe2Pp0Hi1wcwJS6O14Tf8OqEyPUfrEI+DaaugCT+iAJtalxf/R5ZsMb AauC8fBTNNlIhuoQ0OkG/pYDINksVLGl48ni6DAvbX1n0jAkplgWdwXDfksoHSpjuJ nU4TFa2E0r7HgUgeOQF6FmZZk9Z9vQtFrsTC+1d17oK5117ZcBa8UQtCYlhJrlt4XO 2JTAJ9zGVc0S6Z3H8nJRlPK07maajYCmVclYPay7TphSOYFdJFCANlT7qDtQGnufkN zxkChklw2F+0g== Subject: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 17:52:04 -0000 Changing the topic because I'm hijacking the thread. On 10/6/13 9:38 PM, Flemming Andreasen wrote: > Hi Christian > > We had a thread on this particular issue about a year ago. See > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html > > and the conclusion in > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html Thanks for remembering! In that mail I suggested that 4566bis take on updating the format of the IANA registries to reflect the dependency between addrtype and nettype. There are also other ways that the iana registries of SDP parameters are deficient. (Notably the registration of att-field names at session/media/source level.) How do we go about updating 4566bis to improve the iana registries? Thanks, Paul > I hope this addresses your concern as it relates to -cs draft. > > Thanks > > -- Flemming > > > On 9/19/13 8:22 AM, Christian Groves wrote: >> FYI, I was looking at the IANA registry for SDP parameters ( >> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >> and noticed that there was a registration for addrtype E164 linked to >> this CS draft. >> >> There's a problem that there's already an addrtype E164 in RFC3108. >> This earlier usage of E164 should have been registered with IANA but >> seems to have been missed. To complicate things the format of the >> RFC3108 E164 addrtype is different to the one in the CS draft. >> >> I've already raised this with IANA but I thought it would be worth >> mentioning in MMUSIC. >> >> Christian >> >> >> On 2/07/2013 4:56 AM, The IESG wrote: >>> The IESG has approved the following document: >>> - 'Session Description Protocol (SDP) Extension For Setting Audio and >>> Video Media Streams Over Circuit-Switched Bearers In The Public >>> Switched Telephone Network (PSTN)' >>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >>> >>> A URL of this Internet Draft is: >>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>> >>> >>> >>> >>> *Technical Summary >>> * >>> >>> The document 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 Publich Switched Telephone Network (PSTN) >>> >>> *Working Group Summary >>> * >>> >>> The WG had some discussion around the format to use for E.164 numbers >>> and whether to align this with the existing definition in RFC 3108. The >>> RFC 3108 definition was seen as deficient and the WG agreed it was >>> better to align with relevant parts of the tel URI format defined in RFC >>> 3966, not least since SDP address types are defined in the context of a >>> particular network type, and hence RFC 3108 compatibility is not a >>> concern (the implication is that the "E164" address type may differ >>> between network types in SDP). >>> >>> *Document Quality >>> * >>> >>> There are currently no known implementations of the draft, however the >>> draft is a dependency for 3GPP, so future implementations are expected. >>> >>> The document has received good overall review in the WG, some of which >>> resulted in changes to the detailed specification. The document has been >>> reviewed in detail several times, including of the last few versions. >>> The major contributors to these as well as earlier discussions are >>> listed in the Acknowledgements section of the document. >>> >>> >>> *Personnel >>> * >>> >>> Document Shepherd: Flemming Andreasen >>> Responsible AD: Gonzalo Camarillo >>> _______________________________________________ >>> 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 Christian.Groves@nteczone.com Mon Oct 7 15:46: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 6AC9221E81F6 for ; Mon, 7 Oct 2013 15:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt21fufVQx1r for ; Mon, 7 Oct 2013 15:46:31 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4321E81D2 for ; Mon, 7 Oct 2013 15:46:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAEU4U1J20bHs/2dsb2JhbAANTIM/wSlKgTWDGQEBAQQBAQE1GxgDChELGAkWDwkDAgECARUwEwYCAQEFiAmoBpMljhiBQBaEDQOtOYFd Received: from ppp118-209-177-236.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.177.236]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Oct 2013 09:16:17 +1030 Message-ID: <525339B5.3010300@nteczone.com> Date: Tue, 08 Oct 2013 09:46:13 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> In-Reply-To: <5252F30F.5000007@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 22:46:32 -0000 Hello Paul, Is a process needed to create an errata? Wouldn't the fact that they appear in standards track RFCs be enough to include them in the SDP registry based on the SDP directorates (i.e. expert review) recommendation? I agree its not ideal that these older RFCs didn't include an IANA considerations section but I think that rather than spending lots of cycles on this that the SDP directorate could just request IANA to register them to avoid any future overlap issues. Regards, Christian On 8/10/2013 4:44 AM, Paul Kyzivat wrote: > On 10/6/13 11:28 PM, Christian Groves wrote: >> Hello Flemming, >> >> Thanks for pointing out that thread. If Paul as one of the SDP >> directorate is OK with it then I don't have any issue with the -cs >> draft. >> >> I think though that the addresstype and nettype from RFC3108 still needs >> to be picked up by the IANA registry. > > I agree. I'm not sure what the best way to accomplish that is. > Perhaps an errata to 3108, pointing out that it fails to register its > new nettype and addrtypes with IANA would start the process. Or is > there a better way? > > Thanks, > Paul > >> Regards, Christian >> >> On 7/10/2013 12:38 PM, Flemming Andreasen wrote: >>> Hi Christian >>> >>> We had a thread on this particular issue about a year ago. See >>> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>> >>> and the conclusion in >>> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>> >>> I hope this addresses your concern as it relates to -cs draft. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>> and noticed that there was a registration for addrtype E164 linked to >>>> this CS draft. >>>> >>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>> This earlier usage of E164 should have been registered with IANA but >>>> seems to have been missed. To complicate things the format of the >>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>> >>>> I've already raised this with IANA but I thought it would be worth >>>> mentioning in MMUSIC. >>>> >>>> Christian >> >> _______________________________________________ >> 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 internet-drafts@ietf.org Mon Oct 7 22:17: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 B968711E8186; Mon, 7 Oct 2013 22:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo8oQNmhVEFk; Mon, 7 Oct 2013 22:17:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4805A11E8177; Mon, 7 Oct 2013 22:17:03 -0700 (PDT) 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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008051703.25649.53149.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 22:17:03 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 05:17: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 : Latching: Hosted NAT Traversal (HNT) for Media in Real-T= ime Communication Author(s) : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-04.txt Pages : 15 Date : 2013-10-07 Abstract: This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. Latching, which is one of the components of the HNT components, has a number of security issues covered here. Because of those, the IETF advises against use of this mechanism over the Internet and recommends other solutions such as the Interactive Connectivity Establishment (ICE) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-latching-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Oct 8 03:55: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 E1FB111E8173; Tue, 8 Oct 2013 03:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyJrUFTHSRrS; Tue, 8 Oct 2013 03:55:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F8311E819C; Tue, 8 Oct 2013 03:55:50 -0700 (PDT) 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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008105550.25649.12072.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 03:55:50 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:55:56 -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 : Trickle ICE: Incremental Provisioning of Candidates for = the Interactive Connectivity Establishment (ICE) Protocol Author(s) : Emil Ivov Eric Rescorla Justin Uberti Filename : draft-ietf-mmusic-trickle-ice-00.txt Pages : 25 Date : 2013-10-07 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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Claudio.Allocchio@garr.it Tue Oct 8 07:07: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 C4EB421E81DE for ; Tue, 8 Oct 2013 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhITJk5GRI+I for ; Tue, 8 Oct 2013 07:07:02 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9022F11E8195 for ; Tue, 8 Oct 2013 07:06:43 -0700 (PDT) Received: internal info suppressed Date: Tue, 8 Oct 2013 16:06:35 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@eduroam-237-145.wlan.univie.ac.at To: Magnus Westerlund In-Reply-To: <5252C886.8030200@ericsson.com> Message-ID: References: <52446E97.8030700@stpeter.im> <5252ACCC.50303@ericsson.com> <5252C886.8030200@ericsson.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-285503397-1381241198=:19963" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1381241199; bh=TeOILEOGtmTEJFqKe2Sp9l/0pmKM9HqNnvE1/kVR9uo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=drRXVmosWlQ9rMFJUfu10ZnvCh7vvLVkGLmbkNKbXEVdRmu3/bf7KGudd7pUGowsP Awm6APyb7jARcURkI2mqFyR1JiEoK6mbRnVs5g4JRyBeb8voFDF9l3CTyi/RW77oN9 jkah2NjfBDRjk8r+wKTd/px69rQdeUpIO/7gikao= X-Mailman-Approved-At: Tue, 08 Oct 2013 10:43:59 -0700 Cc: mmusic@ietf.org, Claudio Allocchio Subject: Re: [MMUSIC] base64 and datetimes in 2326bis 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 Oct 2013 14:07:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-285503397-1381241198=:19963 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi all, On Mon, 7 Oct 2013, Magnus Westerlund wrote: > Hi, > > Claudio Allocchio sent a private comment regarding the NPT formats > definition in Section 4.4.2 having similar format issues like Section > 4.4.3. This has resulted in my attempting to write a clearer > specification. In that work it is clear that this format is not really > using ISO 8601 syntax. I have attempted to try to make clear this in the > below new definition of NPT syntax. > > The syntax is based on ISO 8601 [ISO.8601.2000]. Two different > notations are allowed. The npt-hhmmss notation are using a ISO 8601 > extended complete representation of the time of the day format > (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators > between hours, minutes and seconds (hh:mm:ss). With the exception > that it expresses duration since presentation start rather than time > since midnight and the hour counter is not limited to 0-24 hours, > instead up to nineteen (19) digits of hours are allowed. OK, tha above is very clear now. > ISO 8601 > time format requires all digits to be used for each format, and all > format required needs to be included, e.g. if one use a hh:mm:ss > format, then that requires two digits for hours, two digits for > minutes and two digits for second, a time value such as 7 minutes and > 0 seconds, needs to be expressed as 00:07:00. The npt-sec notation Minor comment: you could user "MUST" instead of "needs" in the above, as a normative statement, too. It is "minor" anyhow because you're referring to an external specification here. > is expressing the duration since presentation start in seconds, using > one to nineteen (19) digits. Both notations allows decimal fractions > of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with > the limitation of at maximum of 9 digits and only allowing "." (full > stop) as separator. Due to RTSP 1.0 and the fact that the highest > values are expanded beyond two digits, all implementations must allow this is an uppercase "MUST" normative statement. > the highest value to be single digit and SHALL NOT send leading zeros > for hours in the npt-hhmmss notation and leading zeros for seconds in > the ntp-sec notation. The hours and the seconds in the npt-hhmmss > notation SHALL be sent using leading zeros, but receivers SHALL > accept values without leading zeros. > > So please review this and provide feedback on also this change. se above ;-) > > Cheers > > Magnus > > > On 2013-10-07 14:45, Magnus Westerlund wrote: >> Hi Peter, >> >> Thanks for your feedback, and see inline. Especially on the DATE and >> Time issue I would appreciate feedback. >> >> On 2013-09-26 19:27, Peter Saint-Andre wrote: >>> Here is some brief feedback on 2326bis. I'm sorry that I don't >>> have time for a longer review. >>> >>> BASE64 >>> >>> The usages of Base64 do not specify which exact encoding of Base64 >>> they require and what to do about padding bits. For example, >>> Section 18.54 says: >>> >>> The binary MIKEY message SHALL be Base64 [RFC4648] encoded before >>> being included in the value part of the parameter. >>> >>> If the specification assumes that the rules from Section 4 of RFC >>> 4648 are to be used, that text would be more accurate as: >>> >>> The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before >>> being included in the value part of the parameter, where the >>> encoding adheres to the definition in Section 4 of RFC 4648 and >>> where the padding bits are set to zero. >> >> Yes, you are correct, it is the Section 4 BASE64 mode of the RFC that >> we want to use here. >> >> This will effect three places: >> >> Section 18.2: >> >> Each credential MUST consist of one URI >> identifying the proxy or server, the hash algorithm identifier, and >> the hash over that agent's ASN.1 distinguished encoding rules (DER) >> encoded certificate [RFC5280] in BASE64, according to Section 4 of >> [RFC4648] and where the padding bits are set to zero. >> >> >> Section 18.13: >> >> The header MUST >> include the URI of the next hop (proxy or server) and a BASE64 >> (according to Section 4 of [RFC4648] and where the padding bits are >> set to zero) encoded binary structure containing a sequence of DER >> encoded X.509v3 certificates [RFC5280]. >> >> >> Section 18.54: >> >> Under MIKEY parameter >> >> This parameter can be included both in >> request and response messages. The binary MIKEY message SHALL >> be BASE64 [RFC4648] encoded before being included in the value >> part of the parameter, where the encoding adheres to the >> definition in Section 4 of RFC 4648 and where the padding bits >> are set to zero. >> >> >>> >>> DATETIME FORMATS >>> >>> Section 4.4.3 seems to be underspecified: >>> >>> Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, >>> using UTC (GMT). Fractions of a second may be indicated. >>> >>> Example for clock format range request for a starting time of >>> November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC >>> playing for 10 min and 5 seconds, a Media-Properties header's >>> "Time- Limited UTC property for 24th of December 2014 at 15 hours >>> and 00 mins, and a Terminate-Readon headers "time" property for >>> 18th of June 2013 at 16 hours, 12 minutes and 56 seconds: >>> >>> clock=19961108T143720.25Z-19961108T144725.25Z >>> Time-Limited=20141224T1500Z time=20130618T161256Z >>> >>> ISO 8601 has many profiles. Is the profile defined in RFC 3339 >>> supported? That would result in a datetime of the following form: >>> >>> 1996-11-08T14:37:20.25Z >>> >>> Also are timezone offsets allowed? >>> >>> If the answers are "no" then it would be good to explain that in >>> the text. >> >> The answers are no on both accounts. The reasons is really the ABNF >> syntax specified since RTSP 1.0 for this. Thus, I have written a new >> more complete specification for this time format that matches the ABNF >> and still uses ISO 8601 relevant sections for some clarifications and >> specifications. Feedback are much appreciated if you think this is >> complete. >> >> 4.4.3. Absolute Time >> >> Absolute time is expressed following a specific types of ISO 8601 >> [ISO.8601.2000] based timestamps. The date is complete >> representation calendar date in basic format (YYYYMMDD) without >> separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day >> is provided in the complete representation basic format (hhmmss) as >> specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal >> fractions of seconds following Section 5.3.1.3 requiring "." (full >> stop) as decimal separator and limiting the number of digits to no >> more than nine (9). The time expressed MUST be using UTC (GMT), i.e. >> no timezone offsets allowed. The full date and time specification is >> the eight digit date followed by a "T" followed by the six digits >> time value, optionally followed by a full stop followed by one to >> nine fractions of a second and ended by "Z", e.g. >> YYYYMMDDThhmmss.ssZ. >> >> The reason for this time format rather than using "Date and Time >> on the Internet: Timestamps" [RFC3339] are historic and using the >> format specified in RTSP 1.0. The motivations raised in RFC 3339 >> applies to why a selection from ISO 8601 was done, but a different >> and even more restrictive selection was applied in this case. >> >> Example for clock format range request for a starting time of >> November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC >> playing for 10 min and 5 seconds, a Media-Properties header's "Time- >> Limited UTC property for 24th of December 2014 at 15 hours and 00 >> mins, and a Terminate-Readon headers "time" property for 18th of June >> 2013 at 16 hours, 12 minutes and 56 seconds: >> >> clock=19961108T143720.25Z-19961108T144725.25Z >> Time-Limited=20141224T1500Z >> time=20130618T161256Z >> >> >> >> 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 >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> 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 > ---------------------------------------------------------------------- > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-285503397-1381241198=:19963-- From magnus.westerlund@ericsson.com Wed Oct 9 02:19:24 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 6732C21E8147 for ; Wed, 9 Oct 2013 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fQ+ir0b3KOO for ; Wed, 9 Oct 2013 02:19:18 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6E19021E813B for ; Wed, 9 Oct 2013 02:18:56 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-55-52551f7ffac0 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 86.9D.25272.F7F15525; Wed, 9 Oct 2013 11:18:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Wed, 9 Oct 2013 11:18:54 +0200 Message-ID: <52551FB8.3040600@ericsson.com> Date: Wed, 9 Oct 2013 11:19:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Claudio Allocchio References: <52446E97.8030700@stpeter.im> <5252ACCC.50303@ericsson.com> <5252C886.8030200@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrW69fGiQwY3n8hYL72xmt5i6/DGL xbE9/cwOzB5b371j9Fiy5CeTx9w9L5gDmKO4bFJSczLLUov07RK4MjafnMBUsJ+v4tiUk+wN jFu4uxg5OSQETCR2fvvECmGLSVy4t56ti5GLQ0jgKKNE/9OtUM4yRolrTQ1gVbwC2hKru5rY QGwWARWJt9M+MILYbAIWEjd/NILFRQWCJdq3f2WDqBeUODnzCQuILSJgKHH22mawOLOArcT3 9VuZQGxhAVOJ/bPbGSGWrWeU+HHiMFgRp0CIxPRLc5khzpOU2LboGDtEs57ElKstjBC2vETz 1tlgNUJAxzU0dbBOYBSahWT3LCQts5C0LGBkXsXIUZxanJSbbmSwiREYxAe3/LbYwXj5r80h RmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MKatmlAl5qUVocDDov/0RQx/ MNuCQI52+W9Vze+nbX2gLqQ4m6P85M6FHCyteWe1Xf57+mifa1ynYnlR8KCCzsIvB7NNZjgt i0pIODH/Pu8cf6sVhckv5a/2cNgzm5jkNppaTX4ZeHFu7wLVyKpJhz7HpQTE3GcSuM0wwV7/ 6csVYrfe7M/kUGIpzkg01GIuKk4EAAgcHEkwAgAA Cc: mmusic@ietf.org Subject: Re: [MMUSIC] base64 and datetimes in 2326bis 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 Oct 2013 09:19:24 -0000 Hi Claudio, Thanks for the feedback. See inline. On 2013-10-08 16:06, Claudio Allocchio wrote: > > > Hi all, > > On Mon, 7 Oct 2013, Magnus Westerlund wrote: > >> ISO 8601 >> time format requires all digits to be used for each format, and all >> format required needs to be included, e.g. if one use a hh:mm:ss >> format, then that requires two digits for hours, two digits for >> minutes and two digits for second, a time value such as 7 minutes and >> 0 seconds, needs to be expressed as 00:07:00. The npt-sec notation > > Minor comment: you could user "MUST" instead of "needs" in the above, as > a normative statement, too. It is "minor" anyhow because you're > referring to an external specification here. I changed to "is expressed as" being a factual statement in an example. > >> is expressing the duration since presentation start in seconds, using >> one to nineteen (19) digits. Both notations allows decimal fractions >> of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with >> the limitation of at maximum of 9 digits and only allowing "." (full >> stop) as separator. Due to RTSP 1.0 and the fact that the highest >> values are expanded beyond two digits, all implementations must allow > > this is an uppercase "MUST" normative statement. Agreed, fixed in my source. Thanks 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 magnus.westerlund@ericsson.com Wed Oct 9 04:15:28 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 310CA21E813F for ; Wed, 9 Oct 2013 04:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.154 X-Spam-Level: X-Spam-Status: No, score=-105.154 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbCnfS5274Oi for ; Wed, 9 Oct 2013 04:15:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 440A521F9CBF for ; Wed, 9 Oct 2013 04:15:20 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-64-52553ac6cd2b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AC.2D.03802.6CA35525; Wed, 9 Oct 2013 13:15:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Wed, 9 Oct 2013 13:15:18 +0200 Message-ID: <52553B01.9080602@ericsson.com> Date: Wed, 9 Oct 2013 13:16:17 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mmusic (E-mail)" , Elwyn Davies X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvre4xq9Agg0M/rSyOH9jBbjF1+WMW ByaPryfbWTyWLPnJFMAUxWWTkpqTWZZapG+XwJXxc3kTW8FagYo97y+wNzBu4O1i5OSQEDCR aG7axgphi0lcuLeerYuRi0NI4DCjxKFJrxghnGWMEj9Xr2cHqeIV0JZ40zyHDcRmEVCRWHCz hwXEZhOwkLj5oxEsLioQLNG+/SsbRL2gxMmZT8BqRAS8JV5f/8EMYgsD2Ys/PmWD2CwpsW3R MbD5zAJ6ElOutjBC2PISzVtng9ULAe1taOpgncDIPwvJ2FlIWmYhaVnAyLyKkT03MTMnvdxo EyMwyA5u+a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFTd vd3cVUSGoffZ8n6uY18erjQPfPTcJrJ8mkVDqjjzEn2BgztST0enxru4TU4tV2zZbH/zgN3z mWs2x09+fOneqXDzCW3TnP/u+XV7TrXvs0f/mtkeF0xaV7z+xSLvVaciFS0Eiu4db/Iv2HH+ wr8e7X72uGlmuv/v8H6dm1W41f0w2zfXdg0lluKMREMt5qLiRACmnyX/AAIAAA== Subject: [MMUSIC] RTSP 2.0: Additional change in Section 10.4 Timing out connections 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 Oct 2013 11:15:28 -0000 WG, Elwyn, is in the process of sending my editorial comments for the changes since the IETF last call comments was addressed. As part of this he spotted that in section 10.4 there is a note that contains what probably should be specification text. Thus the suggestion is to change the note to a regular text and use RFC 2119 normative language when appropriate. Thus the suggestion is that the fourth paragraph of Section 10.4 will read: In cases multiple RTSP sessions share the same transport connection, abandoning a request and closing the connection may have significant impact on those other sessions. First of all, other RTSP requests may have become queued up due to the request taking long time. Secondly also those sessions loose the possibility to receive server to client requests. To mitigate that situation the RTSP agent SHOULD establish a new connection and send any queued up and non-responded requests on this new connection. Secondly, to ensure that the RTSP server knows which connection that is valid for a particular RTSP session, the RTSP agent SHOULD send a keep-alive request, if no other request will be sent immediately for that RTSP session, for each RTSP session on the old connection. The keep-alive request will normally be a GET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session. Comments and feedbacks on this change. I hope to be able to submit a update with Elwyn's editorial suggestions, and the above change this week. Then I will request that the chairs and AD move forward with the document. 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 elwynd@folly.org.uk Wed Oct 9 08:13: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 CB91421E809C for ; Wed, 9 Oct 2013 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEBjYzvN7kJI for ; Wed, 9 Oct 2013 08:13:21 -0700 (PDT) Received: from bounce.a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7D921E8096 for ; Wed, 9 Oct 2013 08:13:19 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1VTvRr-000096-Qa; Wed, 09 Oct 2013 16:13:15 +0100 From: Elwyn Davies To: "mmusic (E-mail)" , Magnus Westerlund Content-Type: text/plain Organization: Folly Consulting Date: Wed, 09 Oct 2013 16:16:20 +0100 Message-Id: <1381331780.13277.72869.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering. 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 Oct 2013 15:13:29 -0000 In the proces of checking the changes from v34 to v37, I found that there have been some changes to the CSeq specification (Section 18.20) that seem a bit garbled. In para 1, it is stated: > For each new RTSP request an agent creates the CSeq value > MUST be incremented by one. Then later: > Agents receiving a request over a reliable transport with an in-order > delivery MUST ignore how the sequence value increments, i.e. it can > increment with other values than 1. and > Proxies that aggregate several client sessions on the same transport > will have to ensure that the requests sent towards a particular > server have a joint sequence number space. A proxy having one client > with concurrent sessions with two different servers using the same > client proxy connection can avoid rewriting on the proxy to server > connection. The first requirement is contradicted by the second and third stories. We also have: > It also enables detecting loss of a request > and await a retransmission prior to processing a sub-sequent request > when using unreliable transport. I understood that RTSP/2.0 is only specified to run over reliable transports, so this either requires some usage of the subjunctive mood or maybe deletion. However, having non-sequential CSeq values would indeed screw up any future usage of unreliable transport. I wonder if this can be handled by changing the increment requirement so that it applies to requests sent down a given server connection (or channel). Then if unreliable transports ever did come back, the sequencing would still work on a per source/destination address/port quadruple (or whatever), while giving unique (but not necessarily integer sequential) numbering on the multiplexed connections. Anyway, I think that this section needs another pass to sort out the inconsistencies. Regards, Elwyn From emcho@sip-communicator.org Wed Oct 9 08:44: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 9522A11E81B3 for ; Wed, 9 Oct 2013 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zU1DUeWAlvo for ; Wed, 9 Oct 2013 08:44:32 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1976F11E819A for ; Wed, 9 Oct 2013 08:44:31 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so1224546pad.5 for ; Wed, 09 Oct 2013 08:44:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=AA6L5n2ZPxd3G+MTjozhbo9JYYyCU9dsrJ5z3zxgFCY=; b=JTC8egjB2HdguMBOzsUdvDuozCUK08GWIKGUhPBAOL9Cu2Iz+dERd/6CRtE3coRv1/ UcmM2eTb3pMCmXBID1+YfLaDziYyVxj6+Y1k3AJ/Kk2f/dUspzna3aiHLwEA+zRlzmiD JiWK2ufcQP/bZriRKg+vsm1uT7OzXiXLaYz1dabuzByWNdNwNm8kmlBhQGaSM8ucjn90 SUw9e/yneiYsrpvdYCeKyPQwCvVt60W3hn1YavoERJbfVDYP3uUD7qq209eEJ/RtjDgm qgVPFVKTycOYtaOTn6w00wK1Sp3JpMjuV3ZE2u+ad98BkSgnkyTCHwULYlqSZOu6ImI+ 2Y7w== X-Gm-Message-State: ALoCoQmJZDVaqy+6bQeJkiyrkV8I4Om2Jl5DQBlNk9CZS6ebmJCXGux1mggC5mH4MDuxmYdM1oiB X-Received: by 10.68.96.130 with SMTP id ds2mr8513047pbb.99.1381333471571; Wed, 09 Oct 2013 08:44:31 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [2607:f8b0:400e:c02::231]) by mx.google.com with ESMTPSA id a6sm742955pbr.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 08:44:31 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so1144024pdj.22 for ; Wed, 09 Oct 2013 08:44:31 -0700 (PDT) X-Received: by 10.68.164.165 with SMTP id yr5mr8695493pbb.146.1381333471062; Wed, 09 Oct 2013 08:44:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Wed, 9 Oct 2013 08:44:10 -0700 (PDT) From: Emil Ivov Date: Wed, 9 Oct 2013 17:44:10 +0200 Message-ID: To: mmusic Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 15:44:36 -0000 Hey all, We've recently implemented support for DTLS/SRTP and a question that we had somehow avoided in the past with SDES and ZRTP is now back on the table: By default, which profile would a SIP UA use in an outgoing offer? Until recently recently we were offering RTP/AVP by default, which is ok for ZRTP and tolerated by most of the endpoints that support SDES. We also had a couple of config options that allowed Jitsi to (A) create offers with RTP/SAVP(F) in case someone turned out to be picky about the transport or (B) duplicate all m= lines and offer them with every supported transport so that the remote endpoint would pick what it likes. Obviously option (A) is not a suitable default for a generic SIP UA because that would make it incompatible with the majority of the endpoints that exist today. (B) could have worked but now that we are going for "Unified", having the same "m=" line appear with RTP/AVP and then again with RTP/SAVPF would have to be interpreted as two independent streams rather than the same stream being available over two different transports. So, do we have a story here or do we need to create one? Emil -- https://jitsi.org From emcho@sip-communicator.org Wed Oct 9 09:03: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 935AE21E814B for ; Wed, 9 Oct 2013 09:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzY+QRVCGk-n for ; Wed, 9 Oct 2013 09:02:55 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1000421F9E12 for ; Wed, 9 Oct 2013 09:00:51 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kl14so1257893pab.11 for ; Wed, 09 Oct 2013 09:00:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=6evxbVd4JUkNuayGXbsxOIO0NH4QgvgXM/xscZyQqw4=; b=ON/VOIYXZNW8/KCilJHxj1pyXb5a6LksrsVeeYQzr1pY99r3DDXOp0Pvfpq4lg5uIo XRRqtbAhkYhCUHxm+d3CEMVpER8EMXhmcLTSKm/StSVvvexOyjGXwBI52hC7lzuf254M ra9soSfhTDuMuQwufBiLRkqMvWw0L1WtNZn5Am2R80I8XZ8ZAj3C2bG06oGjd44OeHRG +jMO9XNkTCOuCE7bw6HXTGIy96UMWWwIE7ocRDFCrwj6yzGHjAldI9P4iYs3b0rSX8kZ AebPgw/54gVGpv2TiCWL3pKWsmJEQQaSGh51TVHO819kLzZmMYpbDxPPUsyojeUjDHo3 i9MQ== X-Gm-Message-State: ALoCoQntjtFwezWR0Y2WI96fmw9Yp8XXc4oTVElaxYbRPLaniUS3f7hI1/Fwx0Pp/P+9+DEy5H5T X-Received: by 10.68.229.2 with SMTP id sm2mr8767540pbc.68.1381334447042; Wed, 09 Oct 2013 09:00:47 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [2607:f8b0:400e:c03::232]) by mx.google.com with ESMTPSA id l8sm47443956pbl.22.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 09:00:46 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so1250275pad.37 for ; Wed, 09 Oct 2013 09:00:46 -0700 (PDT) X-Received: by 10.68.254.105 with SMTP id ah9mr8697742pbd.87.1381334446601; Wed, 09 Oct 2013 09:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Wed, 9 Oct 2013 09:00:26 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Wed, 9 Oct 2013 18:00:26 +0200 Message-ID: To: mmusic Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 16:03:00 -0000 Oops, hit sent a bit too early. I wanted to add that that the least painful option would obviously be to add tcap attributes as per 5939 and then keep RTP/AVP in the m= line but that would still be rejected by a WebRTC endpoint (right?) so do we need to adjust JSEP to allow RTP/AVP if the m= line contains the necessary transport capabilities? Emil On Wed, Oct 9, 2013 at 5:44 PM, Emil Ivov wrote: > Hey all, > > We've recently implemented support for DTLS/SRTP and a question that > we had somehow avoided in the past with SDES and ZRTP is now back on > the table: > > By default, which profile would a SIP UA use in an outgoing offer? > > Until recently recently we were offering RTP/AVP by default, which is > ok for ZRTP and tolerated by most of the endpoints that support SDES. > > We also had a couple of config options that allowed Jitsi to (A) > create offers with RTP/SAVP(F) in case someone turned out to be picky > about the transport or (B) duplicate all m= lines and offer them with > every supported transport so that the remote endpoint would pick what > it likes. > > Obviously option (A) is not a suitable default for a generic SIP UA > because that would make it incompatible with the majority of the > endpoints that exist today. (B) could have worked but now that we are > going for "Unified", having the same "m=" line appear with RTP/AVP and > then again with RTP/SAVPF would have to be interpreted as two > independent streams rather than the same stream being available over > two different transports. > > So, do we have a story here or do we need to create one? > > Emil > > -- > https://jitsi.org -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 https://jitsi.org FAX: +33.1.77.62.47.31 From pkyzivat@alum.mit.edu Wed Oct 9 09: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 034D311E81D9 for ; Wed, 9 Oct 2013 09:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ohiI1R6u-dn for ; Wed, 9 Oct 2013 09:19:58 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACBF11E81E2 for ; Wed, 9 Oct 2013 09:19:52 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id b2mi1m0050Fqzac5E4KrG3; Wed, 09 Oct 2013 16:19:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id b4Kr1m00m3ZTu2S3U4KrqD; Wed, 09 Oct 2013 16:19:51 +0000 Message-ID: <52558227.3020300@alum.mit.edu> Date: Wed, 09 Oct 2013 12:19:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> In-Reply-To: <525339B5.3010300@nteczone.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=1381335592; bh=TDlwkwNhHQzpT4FVngW3Q0XvdORG9uXGoOju1eddHYE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lYC0d5vaU6PbHfUxG3j7c53gzGRbDzm6Wadc4kcUOpNBXtj6xLEVYmHlL60zc756p r0eIqtZ+o6Pbbd/zi37LldvlvelPsvDWCI7zOFMtRPi5cSXnB5HJuHFz74ar+oudQ2 qxRJh5NgIgtvNoTQFXegem6bXn9JwnsIHbfz1CuvuI3n6+8LcqVnf6rdTy109Ilzji eoV2O9H2lLBXxPyazCEuh2nzdGCASRwqAV2/QGyRk2dWHjlXqljJCz72ZiO/nutej0 PFIfYAMcBoxtDOdF4TRr1syzVgyR/FPh9v7iAxsYQQJn5xoOCfFc+n5b/Ob4KJ8rzI dPTR5bjXTo+nQ== Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 16:20:03 -0000 On 10/7/13 6:46 PM, Christian Groves wrote: > Hello Paul, > > Is a process needed to create an errata? Wouldn't the fact that they > appear in standards track RFCs be enough to include them in the SDP > registry based on the SDP directorates (i.e. expert review) > recommendation? I agree its not ideal that these older RFCs didn't > include an IANA considerations section but I think that rather than > spending lots of cycles on this that the SDP directorate could just > request IANA to register them to avoid any future overlap issues. Unfortunately there are rules. The rules for a particular IANA registry are defined when the registry is created. If you check in the registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that additions to this registry must follow the "Specification Required" policy defined in RFC2434. And the specification must include a particular set of information. (That would typically be in an IANA considerations section.) At the moment all we have is RFC3108, and it doesn't have an IANA considerations section at all. It certainly doesn't give the info needed for an addition to that registry. IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I think we will need a new RFC that does it. This should probably be an update to 3108. An errata is perhaps a formal way to trigger that. Thanks, Paul > Regards, Christian > > On 8/10/2013 4:44 AM, Paul Kyzivat wrote: >> On 10/6/13 11:28 PM, Christian Groves wrote: >>> Hello Flemming, >>> >>> Thanks for pointing out that thread. If Paul as one of the SDP >>> directorate is OK with it then I don't have any issue with the -cs >>> draft. >>> >>> I think though that the addresstype and nettype from RFC3108 still needs >>> to be picked up by the IANA registry. >> >> I agree. I'm not sure what the best way to accomplish that is. >> Perhaps an errata to 3108, pointing out that it fails to register its >> new nettype and addrtypes with IANA would start the process. Or is >> there a better way? >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 7/10/2013 12:38 PM, Flemming Andreasen wrote: >>>> Hi Christian >>>> >>>> We had a thread on this particular issue about a year ago. See >>>> >>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>> >>>> and the conclusion in >>>> >>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>> >>>> I hope this addresses your concern as it relates to -cs draft. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>> and noticed that there was a registration for addrtype E164 linked to >>>>> this CS draft. >>>>> >>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>> This earlier usage of E164 should have been registered with IANA but >>>>> seems to have been missed. To complicate things the format of the >>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>> >>>>> I've already raised this with IANA but I thought it would be worth >>>>> mentioning in MMUSIC. >>>>> >>>>> Christian >>> >>> _______________________________________________ >>> 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 bernard_aboba@hotmail.com Wed Oct 9 10:30: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 43A7E21E8149 for ; Wed, 9 Oct 2013 10:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loOEkAUHy1c7 for ; Wed, 9 Oct 2013 10:30:13 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by ietfa.amsl.com (Postfix) with ESMTP id EE2F821E805F for ; Wed, 9 Oct 2013 10:30:09 -0700 (PDT) Received: from BLU169-W88 ([65.55.111.72]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Oct 2013 10:30:09 -0700 X-TMN: [/BF73eTXoFAlIRiL2P54IqgCd67zzyd3c3SnO1QP9Nk=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_96604804-e2f6-450a-b71e-89a05fa8a377_" From: Bernard Aboba To: "mmusic@ietf.org" Date: Wed, 9 Oct 2013 10:30:08 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2013 17:30:09.0146 (UTC) FILETIME=[33A06DA0:01CEC515] Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 17:30:18 -0000 --_96604804-e2f6-450a-b71e-89a05fa8a377_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Comments below.=20 =20 Emil said:=20 =20 Oops=2C hit sent a bit too early. I wanted to add that that the least painful option would obviously be to add tcap attributes as per 5939 and then keep RTP/AVP in the m=3D line but that would still be rejected by a WebRTC endpoint (right?) so do we need to adjust JSEP to allow RTP/AVP if the m=3D line contains the necessary transport capabilities? =20 [BA] Unfortunately the legacy endpoints whose behavior is the cause of this= issue are unlikely to support RFC 5939=2C so I can't see how that would he= lp.=20 Emil On Wed=2C Oct 9=2C 2013 at 5:44 PM=2C Emil Ivov wrote: > Hey all=2C > > We've recently implemented support for DTLS/SRTP and a question that > we had somehow avoided in the past with SDES and ZRTP is now back on > the table: > > By default=2C which profile would a SIP UA use in an outgoing offer? > > Until recently recently we were offering RTP/AVP by default=2C which is > ok for ZRTP and tolerated by most of the endpoints that support SDES. =20 [BA] I would add that RTP/AVP is also tolerated by endpoints that support f= eedback.=20 > We also had a couple of config options that allowed Jitsi to (A) > create offers with RTP/SAVP(F) in case someone turned out to be picky > about the transport or (B) duplicate all m=3D lines and offer them with > every supported transport so that the remote endpoint would pick what > it likes. =20 [BA] In my experience option B doesn't work that well=2C because implementa= tions that do not support RTP/SAVPF will not always respond by setting the = port to zero on those m lines=2C as they should. Instead they may respond= with an error. So you're likely to have problems=2C "unified" not withsta= nding.=20 > Obviously option (A) is not a suitable default for a generic SIP UA > because that would make it incompatible with the majority of the > endpoints that exist today. (B) could have worked but now that we are > going for "Unified"=2C having the same "m=3D" line appear with RTP/AVP an= d > then again with RTP/SAVPF would have to be interpreted as two > independent streams rather than the same stream being available over > two different transports. > > So=2C do we have a story here or do we need to create one? [BA] If by "have a story here" you mean "have a standards-based way of reli= ably interoperating with non-standards compliant legacy UAs"=2C I think the= answer is unfortunately "no" :( =20 In practice you might try substituting the following for your option B:=20 =20 By default=2C offer RTP/AVP with a=3D lines describing the crypto and feedb= ack features you support. If the answerer is legacy=2C you'll have the h= ighest chance of backward compatibility this way. You may even get back an= answer with a profile of RTP/(S)AVPF=2C indicating that the answerer under= stands what you are really offering. If that happens you can offer RTP/(S)= AVPF in re-invites or other subsequent exchanges. = --_96604804-e2f6-450a-b71e-89a05fa8a377_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] Comments below.
 = =3B
Emil said:
 =3B
Oops=2C hit sent a bit too early. I wante= d to add that that the least
painful option would obviously be to add tc= ap attributes as per 5939
and then keep RTP/AVP in the m=3D line but tha= t would still be rejected
by a WebRTC endpoint (right?) so do we need to= adjust JSEP to allow
RTP/AVP if the m=3D line contains the necessary tr= ansport capabilities?
 =3B
[BA] Unfortunately the legacy endpoint= s =3Bwhose behavior is the cause of this issue =3Bare unlikely to s= upport RFC 5939=2C so I can't see how that would help.

Emil

= On Wed=2C Oct 9=2C 2013 at 5:44 PM=2C Emil Ivov <=3Bemcho at jitsi.org>= =3B wrote:
>=3B Hey all=2C
>=3B
>=3B We've recently implemen= ted support for DTLS/SRTP and a question that
>=3B we had somehow avoi= ded in the past with SDES and ZRTP is now back on
>=3B the table:
&= gt=3B
>=3B By default=2C which profile would a SIP UA use in an outgoi= ng offer?
>=3B
>=3B Until recently recently we were offering RTP/= AVP by default=2C which is
>=3B ok for ZRTP and tolerated by most of t= he endpoints that support SDES.
 =3B
[BA] I would add that RTP/AV= P is also tolerated by endpoints that support feedback.

>=3B We a= lso had a couple of config options that allowed Jitsi to (A)
>=3B crea= te offers with RTP/SAVP(F) in case someone turned out to be picky
>=3B= about the transport or (B) duplicate all m=3D lines and offer them with>=3B every supported transport so that the remote endpoint would pick wh= at
>=3B it likes.
 =3B
[BA] In my experience option B doesn'= t work that well=2C because implementations that do not =3Bsupport RTP/= SAVPF will not always respond by setting the port to zero on those m lines= =2C as they should. =3B =3B Instead they may respond with an error.=  =3B So you're likely to have problems=2C "unified" not withstanding. <= BR>
>=3B Obviously option (A) is not a suitable default for a generic = SIP UA
>=3B because that would make it incompatible with the majority = of the
>=3B endpoints that exist today. (B) could have worked but now = that we are
>=3B going for "Unified"=2C having the same "m=3D" line ap= pear with RTP/AVP and
>=3B then again with RTP/SAVPF would have to be = interpreted as two
>=3B independent streams rather than the same strea= m being available over
>=3B two different transports.
>=3B
>= =3B So=2C do we have a story here or do we need to create one?

[BA] = If by "have a story here" you mean "have a standards-based way of reliably = interoperating with non-standards compliant legacy UAs"=2C I think the answ= er is =3B unfortunately =3B"no" :(
 =3B
In practice you m= ight try substituting the following for your option B:
 =3B
By d= efault=2C offer RTP/AVP with a=3D lines describing the crypto and feedback = features you support. =3B =3B =3B If the answerer is legacy=2C = you'll have the highest chance of backward compatibility this way. =3B = You may even get back an answer =3Bwith a profile of RTP/(S)AVPF=2C ind= icating that the answerer understands what you are really offering. =3B= If that happens you can offer RTP/(S)AVPF in re-invites or other subsequen= t exchanges.
= --_96604804-e2f6-450a-b71e-89a05fa8a377_-- From emcho@sip-communicator.org Wed Oct 9 10:52: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 E202E21E8151 for ; Wed, 9 Oct 2013 10:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhCnr+6NkW4k for ; Wed, 9 Oct 2013 10:52:46 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 00B2711E80E2 for ; Wed, 9 Oct 2013 10:52:45 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id bj1so1405222pad.21 for ; Wed, 09 Oct 2013 10:52:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PBjiyrY1jO5OVevCCahh4SmHdXROtMRYTsQBuebO+XE=; b=De3UyfAjVu1+dvl8Rxe9gM0RfxClj60CQh59y4vUlE8KUw+KsawFwFUCx5/j68gdtv uAkRX4xET5e1a5JaLV6agdD7pYKp3WtJcE5RvxwR3mbMFcNXPC7DCIY6BA1EpmfgoOL0 FiVYPiK1sUV1WsEW+vjuz0j8FuRYusdgJcH/6WJDI5/8kEzfwXgfS7MnZzAUtctaq138 8mvcdKlqYWM0xs6pLNAyu9IKqG/BepbDINX4HCe3Wtwnk/0bfiW30rUhTANhnLF+6LFX Kr3tKBtnxnc1Zs8EPRbl/WD0tRml+nkjwO8NMRqN07fucmPgOHETxJde3muqP+IiDtoM 5Zpg== X-Gm-Message-State: ALoCoQnTgLlmH5nVvXRgRSpCvHNQmNAPb9C8t+z7QWsglqZWW4q2AxXJrgFbSU8At7NuTlKZwHvc X-Received: by 10.66.163.164 with SMTP id yj4mr11008870pab.91.1381341163641; Wed, 09 Oct 2013 10:52:43 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [2607:f8b0:400e:c02::22a]) by mx.google.com with ESMTPSA id f2sm47907803pbg.44.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 10:52:43 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so1309841pdj.1 for ; Wed, 09 Oct 2013 10:52:42 -0700 (PDT) X-Received: by 10.66.118.204 with SMTP id ko12mr3281418pab.184.1381341162962; Wed, 09 Oct 2013 10:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Wed, 9 Oct 2013 10:52:22 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Wed, 9 Oct 2013 19:52:22 +0200 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 17:52:58 -0000 On Wed, Oct 9, 2013 at 7:30 PM, Bernard Aboba wrote: > [BA] Comments below. > > Emil said: > > Oops, hit sent a bit too early. I wanted to add that that the least > painful option would obviously be to add tcap attributes as per 5939 > and then keep RTP/AVP in the m= line but that would still be rejected > by a WebRTC endpoint (right?) so do we need to adjust JSEP to allow > RTP/AVP if the m= line contains the necessary transport capabilities? > > [BA] Unfortunately the legacy endpoints whose behavior is the cause of this > issue are unlikely to support RFC 5939, so I can't see how that would help. Well, at least you'd get to establish an RTP/AVP call with no encryption. The same goes for endpoints that have SDES support and tolerate RTP/AVP as transport when they detect the crypto attributes (without supporting RFC5939). I agree that legacy endpoints with no 5939 support that insist on having RTP/SAVP, would reject it but at least we would limit those cases. > On Wed, Oct 9, 2013 at 5:44 PM, Emil Ivov wrote: >> Hey all, >> >> We've recently implemented support for DTLS/SRTP and a question that >> we had somehow avoided in the past with SDES and ZRTP is now back on >> the table: >> >> By default, which profile would a SIP UA use in an outgoing offer? >> >> Until recently recently we were offering RTP/AVP by default, which is >> ok for ZRTP and tolerated by most of the endpoints that support SDES. > > [BA] I would add that RTP/AVP is also tolerated by endpoints that support > feedback. > >> We also had a couple of config options that allowed Jitsi to (A) >> create offers with RTP/SAVP(F) in case someone turned out to be picky >> about the transport or (B) duplicate all m= lines and offer them with >> every supported transport so that the remote endpoint would pick what >> it likes. > > [BA] In my experience option B doesn't work that well, because > implementations that do not support RTP/SAVPF will not always respond by > setting the port to zero on those m lines, as they should. Instead they > may respond with an error. So you're likely to have problems, "unified" not > withstanding. True. >> Obviously option (A) is not a suitable default for a generic SIP UA >> because that would make it incompatible with the majority of the >> endpoints that exist today. (B) could have worked but now that we are >> going for "Unified", having the same "m=" line appear with RTP/AVP and >> then again with RTP/SAVPF would have to be interpreted as two >> independent streams rather than the same stream being available over >> two different transports. >> >> So, do we have a story here or do we need to create one? > > [BA] If by "have a story here" you mean "have a standards-based way of > reliably interoperating with non-standards compliant legacy UAs", I think > the answer is unfortunately "no" :( Well, not even that. I'd be happy with a story that allows us to generate offers in a way that would allow for an RTP/AVP call to be established with standards compliant legacy and an RTP/SAVPF call with modern endpoints (including gatewayed WebRTC). > In practice you might try substituting the following for your option B: > > By default, offer RTP/AVP with a= lines describing the crypto and feedback > features you support. If the answerer is legacy, you'll have the highest > chance of backward compatibility this way. You may even get back an answer > with a profile of RTP/(S)AVPF, indicating that the answerer understands what > you are really offering. If that happens you can offer RTP/(S)AVPF in > re-invites or other subsequent exchanges. OK, this does sound reasonable but it would also mean that a SIP-2-WebRTC gateway would *always* need to modify the first offer from the SIP UAs even if they are perfectly interoperable otherwise. Not that this is that much of a big deal but I was still hoping we could have at least one case where gatewaying SIP to WebRTC would only be a matter of extracting the SDP and sending it down to the browser. Emil -- https://jitsi.org From fandreas@cisco.com Wed Oct 9 13:59: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 E40C121E81AF for ; Wed, 9 Oct 2013 13:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IwwfSpKjY0v for ; Wed, 9 Oct 2013 13:59:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4F41C21F9B86 for ; Wed, 9 Oct 2013 13:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4403; q=dns/txt; s=iport; t=1381352385; x=1382561985; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tgcbIVAS9v1S8mt/U4ifcw43+/9x/5y7Gw8wPcAvf6I=; b=JGJwz3/oFUk3ol5woAjcVkMVN2XcSNDqVVLrHV/DQJD75z8BXwMr9fI/ NJ8xdNpwmoC2x8FjT5oKO6v/c07fxh1et0XZJDyHCxEr+weAn4h1Nz1b+ JN1xuIkYTsOVjfuHUJxZuD/sSku42I4WpZTZwQsMtnREOM/kCsiRx6nay E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcMALPCVVKtJV2Y/2dsb2JhbABaDoJ5OK05A5QDSoEgFnSCJQEBAQMBAQEBNTMDCgEFCwsOCgkWDwkDAgECARUwBg0BBQIBAQWHdwYMuQWODIE5B4QjA5gDkgGCZVsggTU X-IronPort-AV: E=Sophos;i="4.90,1066,1371081600"; d="scan'208";a="270205784" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2013 20:59:21 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r99KxKDf017414; Wed, 9 Oct 2013 20:59:20 GMT Message-ID: <5255C3A7.6000104@cisco.com> Date: Wed, 09 Oct 2013 16:59:19 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> In-Reply-To: <52558227.3020300@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 20:59:50 -0000 On 10/9/13 12:19 PM, Paul Kyzivat wrote: > On 10/7/13 6:46 PM, Christian Groves wrote: >> Hello Paul, >> >> Is a process needed to create an errata? Wouldn't the fact that they >> appear in standards track RFCs be enough to include them in the SDP >> registry based on the SDP directorates (i.e. expert review) >> recommendation? I agree its not ideal that these older RFCs didn't >> include an IANA considerations section but I think that rather than >> spending lots of cycles on this that the SDP directorate could just >> request IANA to register them to avoid any future overlap issues. > > Unfortunately there are rules. The rules for a particular IANA > registry are defined when the registry is created. If you check in the > registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that > additions to this registry must follow the "Specification Required" > policy defined in RFC2434. And the specification must include a > particular set of information. (That would typically be in an IANA > considerations section.) > > At the moment all we have is RFC3108, and it doesn't have an IANA > considerations section at all. It certainly doesn't give the info > needed for an addition to that registry. > > IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I > think we will need a new RFC that does it. This should probably be an > update to 3108. An errata is perhaps a formal way to trigger that. > Having previously communicated with one of the RFC 3108 authors on this, I would ask for leniency here, not least considering that RFC 3108 predates RFC 4566. In other words, I'd argue that we should simply add the missing registrations. Thanks -- Flemming > Thanks, > Paul > >> Regards, Christian >> >> On 8/10/2013 4:44 AM, Paul Kyzivat wrote: >>> On 10/6/13 11:28 PM, Christian Groves wrote: >>>> Hello Flemming, >>>> >>>> Thanks for pointing out that thread. If Paul as one of the SDP >>>> directorate is OK with it then I don't have any issue with the -cs >>>> draft. >>>> >>>> I think though that the addresstype and nettype from RFC3108 still >>>> needs >>>> to be picked up by the IANA registry. >>> >>> I agree. I'm not sure what the best way to accomplish that is. >>> Perhaps an errata to 3108, pointing out that it fails to register its >>> new nettype and addrtypes with IANA would start the process. Or is >>> there a better way? >>> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 7/10/2013 12:38 PM, Flemming Andreasen wrote: >>>>> Hi Christian >>>>> >>>>> We had a thread on this particular issue about a year ago. See >>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>>> >>>>> and the conclusion in >>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>>> >>>>> I hope this addresses your concern as it relates to -cs draft. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>>> and noticed that there was a registration for addrtype E164 >>>>>> linked to >>>>>> this CS draft. >>>>>> >>>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>>> This earlier usage of E164 should have been registered with IANA but >>>>>> seems to have been missed. To complicate things the format of the >>>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>>> >>>>>> I've already raised this with IANA but I thought it would be worth >>>>>> mentioning in MMUSIC. >>>>>> >>>>>> Christian >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From fandreas@cisco.com Wed Oct 9 14:00: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 1C58D21F9EF6 for ; Wed, 9 Oct 2013 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1X8xRvyZsTM for ; Wed, 9 Oct 2013 14:00:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B120C21E8160 for ; Wed, 9 Oct 2013 14:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4958; q=dns/txt; s=iport; t=1381352448; x=1382562048; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uP1xRnSF3a4u2n/hNXYNnoIAGEIsM9IJFukFw+MdCAk=; b=BxE99nwPlpHj7QyJzGFfG6MYJV9/7KplLM2U7m+hLmIpBPbfL4lyX76g /wH/EFOt+cv/pw+724RPPIYtKQwHx3lVxyICd1Y445iT8RhohDKaq41XC hGYy1ZfsTkFYgPrVQxvpCaVoJ3pMAw3a+0D6G9Y7X8OB6Cx3OR7yFuNKh s=; X-IronPort-AV: E=Sophos;i="4.90,1066,1371081600"; d="scan'208";a="270220410" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 09 Oct 2013 21:00:48 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r99L0lkR019574; Wed, 9 Oct 2013 21:00:47 GMT Message-ID: <5255C3FE.7010602@cisco.com> Date: Wed, 09 Oct 2013 17:00:46 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> In-Reply-To: <5252F4B7.4070303@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 21:00:53 -0000 On 10/7/13 1:51 PM, Paul Kyzivat wrote: > Changing the topic because I'm hijacking the thread. > > On 10/6/13 9:38 PM, Flemming Andreasen wrote: >> Hi Christian >> >> We had a thread on this particular issue about a year ago. See >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >> >> and the conclusion in >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html > > Thanks for remembering! > > In that mail I suggested that 4566bis take on updating the format of > the IANA registries to reflect the dependency between addrtype and > nettype. > > There are also other ways that the iana registries of SDP parameters > are deficient. (Notably the registration of att-field names at > session/media/source level.) > > How do we go about updating 4566bis to improve the iana registries? I think we ask Ali to make sure it is covered as part of 4566bis (possibly with some mailing list discussion first if you believe that is needed). If there are specific text suggestions, then all the better. Thanks -- Flemming > > Thanks, > Paul > >> I hope this addresses your concern as it relates to -cs draft. >> >> Thanks >> >> -- Flemming >> >> >> On 9/19/13 8:22 AM, Christian Groves wrote: >>> FYI, I was looking at the IANA registry for SDP parameters ( >>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>> and noticed that there was a registration for addrtype E164 linked to >>> this CS draft. >>> >>> There's a problem that there's already an addrtype E164 in RFC3108. >>> This earlier usage of E164 should have been registered with IANA but >>> seems to have been missed. To complicate things the format of the >>> RFC3108 E164 addrtype is different to the one in the CS draft. >>> >>> I've already raised this with IANA but I thought it would be worth >>> mentioning in MMUSIC. >>> >>> Christian >>> >>> >>> On 2/07/2013 4:56 AM, The IESG wrote: >>>> The IESG has approved the following document: >>>> - 'Session Description Protocol (SDP) Extension For Setting Audio and >>>> Video Media Streams Over Circuit-Switched Bearers In The Public >>>> Switched Telephone Network (PSTN)' >>>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >>>> >>>> A URL of this Internet Draft is: >>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>> >>>> >>>> >>>> >>>> *Technical Summary >>>> * >>>> >>>> The document 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 Publich Switched Telephone Network (PSTN) >>>> >>>> *Working Group Summary >>>> * >>>> >>>> The WG had some discussion around the format to use for E.164 numbers >>>> and whether to align this with the existing definition in RFC 3108. >>>> The >>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>> better to align with relevant parts of the tel URI format defined >>>> in RFC >>>> 3966, not least since SDP address types are defined in the context >>>> of a >>>> particular network type, and hence RFC 3108 compatibility is not a >>>> concern (the implication is that the "E164" address type may differ >>>> between network types in SDP). >>>> >>>> *Document Quality >>>> * >>>> >>>> There are currently no known implementations of the draft, however the >>>> draft is a dependency for 3GPP, so future implementations are >>>> expected. >>>> >>>> The document has received good overall review in the WG, some of which >>>> resulted in changes to the detailed specification. The document has >>>> been >>>> reviewed in detail several times, including of the last few versions. >>>> The major contributors to these as well as earlier discussions are >>>> listed in the Acknowledgements section of the document. >>>> >>>> >>>> *Personnel >>>> * >>>> >>>> Document Shepherd: Flemming Andreasen >>>> Responsible AD: Gonzalo Camarillo >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From abegen@cisco.com Wed Oct 9 14:04: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 BF30021E81D0 for ; Wed, 9 Oct 2013 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSyyPM9DFLa1 for ; Wed, 9 Oct 2013 14:04:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1732721E81DA for ; Wed, 9 Oct 2013 14:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5501; q=dns/txt; s=iport; t=1381352662; x=1382562262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bWtvAtzmrfw9SGwFIl5d71QFSOhU5nH7uko/EZ8zCMU=; b=WPquzugam3zz/AmxiHiRl0KRpHd8/3sW/D2IB6v6HVsrWPSnl6EN/OQL bHTpY15MCfb3RdClTynad+3NjCuTSFIxYpx8vyWHspjBjHttdrD5mM9Pp x4WI/IiJuDrNkM20lAsoCMTxixiWF9bG48Clyvyl8+YuoQE+D7GUqLOBq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAGzDVVKtJV2a/2dsb2JhbABagmYhOEYMwG1KgSAWdIIlAQEBAwEBAQFrCxACAQgYCiQnCyUCBA4FCAGHdwYBC7kFjgyBBgIxAgWDH4EEA4kCkDCQUoMkgXE5 X-IronPort-AV: E=Sophos;i="4.90,1066,1371081600"; d="scan'208";a="270289363" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2013 21:04:21 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r99L4LBs017869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 21:04:21 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 16:04:20 -0500 From: "Ali C. Begen (abegen)" To: "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] Updating iana SDP parameter registries in 4566bis Thread-Index: AQHOw4X0bEknDqniXEKXCVCKE5GhqZntMgUAgAAA/wA= Date: Wed, 9 Oct 2013 21:04:20 +0000 Message-ID: References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> In-Reply-To: <5255C3FE.7010602@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.36.84] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Paul Kyzivat Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 21:04:48 -0000 On Oct 9, 2013, at 2:00 PM, Flemming Andreasen wrote: >=20 > On 10/7/13 1:51 PM, Paul Kyzivat wrote: >> Changing the topic because I'm hijacking the thread. >>=20 >> On 10/6/13 9:38 PM, Flemming Andreasen wrote: >>> Hi Christian >>>=20 >>> We had a thread on this particular issue about a year ago. See >>>=20 >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>=20 >>> and the conclusion in >>>=20 >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>=20 >> Thanks for remembering! >>=20 >> In that mail I suggested that 4566bis take on updating the format of the= IANA registries to reflect the dependency between addrtype and nettype. >>=20 >> There are also other ways that the iana registries of SDP parameters are= deficient. (Notably the registration of att-field names at session/media/s= ource level.) >>=20 >> How do we go about updating 4566bis to improve the iana registries? >=20 > I think we ask Ali to make sure it is covered as part of 4566bis (possibl= y with some mailing list discussion first if you believe that is needed). I= f there are specific text suggestions, then all the better. So, in the bis document, we can try to make it clearer but are we supposed = to do a whole registry update as well? And certainly, the discussion will b= e a lot easier with some text proposals... >=20 > Thanks >=20 > -- Flemming >=20 >>=20 >> Thanks, >> Paul >>=20 >>> I hope this addresses your concern as it relates to -cs draft. >>>=20 >>> Thanks >>>=20 >>> -- Flemming >>>=20 >>>=20 >>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>> and noticed that there was a registration for addrtype E164 linked to >>>> this CS draft. >>>>=20 >>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>> This earlier usage of E164 should have been registered with IANA but >>>> seems to have been missed. To complicate things the format of the >>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>=20 >>>> I've already raised this with IANA but I thought it would be worth >>>> mentioning in MMUSIC. >>>>=20 >>>> Christian >>>>=20 >>>>=20 >>>> On 2/07/2013 4:56 AM, The IESG wrote: >>>>> The IESG has approved the following document: >>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio and >>>>> Video Media Streams Over Circuit-Switched Bearers In The Public >>>>> Switched Telephone Network (PSTN)' >>>>> (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard >>>>>=20 >>>>> This document is the product of the Multiparty Multimedia Session >>>>> Control >>>>> Working Group. >>>>>=20 >>>>> The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >>>>>=20 >>>>> A URL of this Internet Draft is: >>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> *Technical Summary >>>>> * >>>>>=20 >>>>> The document describes use cases, requirements, and protocol extensio= ns >>>>> for using the Session Description Protocol (SDP) Offer/Answer model f= or >>>>> establishing audio and video media streams over circuit-switched bear= ers >>>>> in the Publich Switched Telephone Network (PSTN) >>>>>=20 >>>>> *Working Group Summary >>>>> * >>>>>=20 >>>>> The WG had some discussion around the format to use for E.164 numbers >>>>> and whether to align this with the existing definition in RFC 3108. T= he >>>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>>> better to align with relevant parts of the tel URI format defined in = RFC >>>>> 3966, not least since SDP address types are defined in the context of= a >>>>> particular network type, and hence RFC 3108 compatibility is not a >>>>> concern (the implication is that the "E164" address type may differ >>>>> between network types in SDP). >>>>>=20 >>>>> *Document Quality >>>>> * >>>>>=20 >>>>> There are currently no known implementations of the draft, however th= e >>>>> draft is a dependency for 3GPP, so future implementations are expecte= d. >>>>>=20 >>>>> The document has received good overall review in the WG, some of whic= h >>>>> resulted in changes to the detailed specification. The document has b= een >>>>> reviewed in detail several times, including of the last few versions. >>>>> The major contributors to these as well as earlier discussions are >>>>> listed in the Acknowledgements section of the document. >>>>>=20 >>>>>=20 >>>>> *Personnel >>>>> * >>>>>=20 >>>>> Document Shepherd: Flemming Andreasen >>>>> Responsible AD: Gonzalo Camarillo >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >>=20 >=20 From pkyzivat@alum.mit.edu Wed Oct 9 15:28: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 4FF0E21E81E7 for ; Wed, 9 Oct 2013 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ65AQzeWKcl for ; Wed, 9 Oct 2013 15:28:40 -0700 (PDT) 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 193AD21E819C for ; Wed, 9 Oct 2013 15:28:31 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id b0HX1m0010xGWP854AUXnz; Wed, 09 Oct 2013 22:28:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id bAUX1m00W3ZTu2S3YAUXMD; Wed, 09 Oct 2013 22:28:31 +0000 Message-ID: <5255D88E.1050600@alum.mit.edu> Date: Wed, 09 Oct 2013 18:28:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Flemming Andreasen References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> In-Reply-To: <5255C3A7.6000104@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=1381357711; bh=p4++TnVErXTLGTihnBZyd4vbV/cJSxgRSXQbAxETbpI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hOSeJtISn5bJvpQT+viI8VOnv0kRKxXKps9n9mZZz9FDivRwADF5MBsbucDTUbfvp HNViukRmC3ADJshiEDnU5OoQd5yRDtRbQVXA8QXT95PlAMWTtfF4gEplBm0FEZ08JW 8/0wCwq9zL229zREuNVLzOZUNVkFtLEfaGDLUUOyx6SWG7bUqLwNhFkJtNL1rP3O8h pOxLiXRIFQ8mcoFeAr1bNmbVE7l1LMXulKjoI7tR0/k/ZmckKnvUkNHKm1LJAYp7ou cyNwUMvbRWE7UVD45FUBPd0mpvXqmxgqRfA+eroF0mmmuVI7OKAfF6EebF/+Wtoo1V kBGuZZxmMyAWw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 22:28:46 -0000 On 10/9/13 4:59 PM, Flemming Andreasen wrote: > > On 10/9/13 12:19 PM, Paul Kyzivat wrote: >> On 10/7/13 6:46 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> Is a process needed to create an errata? Wouldn't the fact that they >>> appear in standards track RFCs be enough to include them in the SDP >>> registry based on the SDP directorates (i.e. expert review) >>> recommendation? I agree its not ideal that these older RFCs didn't >>> include an IANA considerations section but I think that rather than >>> spending lots of cycles on this that the SDP directorate could just >>> request IANA to register them to avoid any future overlap issues. >> >> Unfortunately there are rules. The rules for a particular IANA >> registry are defined when the registry is created. If you check in the >> registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that >> additions to this registry must follow the "Specification Required" >> policy defined in RFC2434. And the specification must include a >> particular set of information. (That would typically be in an IANA >> considerations section.) >> >> At the moment all we have is RFC3108, and it doesn't have an IANA >> considerations section at all. It certainly doesn't give the info >> needed for an addition to that registry. >> >> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I >> think we will need a new RFC that does it. This should probably be an >> update to 3108. An errata is perhaps a formal way to trigger that. >> > Having previously communicated with one of the RFC 3108 authors on this, > I would ask for leniency here, not least considering that RFC 3108 > predates RFC 4566. In other words, I'd argue that we should simply add > the missing registrations. I wasn't trying to be pejorative - just commenting on what seems required to fix it. We just need *some* RFC to do it. It could be 4566bis. But if it isn't one that explicitly updates 3108, then we should take care to instruct IANA to make the registry point to 3108. Thanks, Paul From finlayson@live555.com Wed Oct 9 15:35: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 C84F721F99F0 for ; Wed, 9 Oct 2013 15:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC9aUtw03pMu for ; Wed, 9 Oct 2013 15:35:38 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id EE04D21E8242 for ; Wed, 9 Oct 2013 15:35:36 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r99MZZxX000332 for ; Wed, 9 Oct 2013 15:35:36 -0700 (PDT) (envelope-from finlayson@live555.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ross Finlayson In-Reply-To: <1381331780.13277.72869.camel@mightyatom> Date: Wed, 9 Oct 2013 15:35:34 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <1381331780.13277.72869.camel@mightyatom> To: "mmusic (E-mail)" X-Mailer: Apple Mail (2.1510) Subject: Re: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering. 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 Oct 2013 22:35:43 -0000 > Anyway, I think that this section needs another pass to sort out the > inconsistencies. Or else get rid of the "CSeq" field altogether... Ross. From keith.drage@alcatel-lucent.com Wed Oct 9 15:46:21 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 9500521E81E5 for ; Wed, 9 Oct 2013 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwfv5qXYkSvi for ; Wed, 9 Oct 2013 15:46:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8691621E81C2 for ; Wed, 9 Oct 2013 15:46:16 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r99MkCFC023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 17:46:13 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r99MkBIg004921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 00:46:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 10 Oct 2013 00:46:11 +0200 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] Updating iana SDP parameter registries in 4566bis Thread-Index: AQHOxTKpzKqfPZ+ZVkCM/v/rnUVHr5nsulIAgAA7+6A= Date: Wed, 9 Oct 2013 22:46:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "" , Paul Kyzivat Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 22:46:21 -0000 IANA registrations are a set of change requests to IANA to change things. If the change has already been done, there is probably no absolute necessit= y to repeat them. As an example, if RFCxxxxbis replaced RFCxxxx and made no new IANA registra= tions issues, it would be perfectly appropriate to refer to RFC xxxx has ha= ving performed the IANA actions. Obviously at some point it may be appropriate to document a cumulative hist= ory, particularly where the IANA instructions are unclear at some point. Ho= wever I would not regard it as the prime focus of RFC 4566bis to update the= IANA registrations in this regard. If the need for an IANA registration is clear despite the absence of a spec= ific IANA registration section, just request it. Otherwise more action is r= equired. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Ali C. Begen (abegen) > Sent: 09 October 2013 22:04 > To: Flemming Andreasen (fandreas) > Cc: ; Paul Kyzivat > Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis >=20 >=20 > On Oct 9, 2013, at 2:00 PM, Flemming Andreasen wrote= : >=20 > > > > On 10/7/13 1:51 PM, Paul Kyzivat wrote: > >> Changing the topic because I'm hijacking the thread. > >> > >> On 10/6/13 9:38 PM, Flemming Andreasen wrote: > >>> Hi Christian > >>> > >>> We had a thread on this particular issue about a year ago. See > >>> > >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html > >>> > >>> and the conclusion in > >>> > >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html > >> > >> Thanks for remembering! > >> > >> In that mail I suggested that 4566bis take on updating the format of > the IANA registries to reflect the dependency between addrtype and nettyp= e. > >> > >> There are also other ways that the iana registries of SDP parameters > are deficient. (Notably the registration of att-field names at > session/media/source level.) > >> > >> How do we go about updating 4566bis to improve the iana registries? > > > > I think we ask Ali to make sure it is covered as part of 4566bis > (possibly with some mailing list discussion first if you believe that is > needed). If there are specific text suggestions, then all the better. >=20 > So, in the bis document, we can try to make it clearer but are we suppose= d > to do a whole registry update as well? And certainly, the discussion will > be a lot easier with some text proposals... >=20 >=20 > > > > Thanks > > > > -- Flemming > > > >> > >> Thanks, > >> Paul > >> > >>> I hope this addresses your concern as it relates to -cs draft. > >>> > >>> Thanks > >>> > >>> -- Flemming > >>> > >>> > >>> On 9/19/13 8:22 AM, Christian Groves wrote: > >>>> FYI, I was looking at the IANA registry for SDP parameters ( > >>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) > >>>> and noticed that there was a registration for addrtype E164 linked t= o > >>>> this CS draft. > >>>> > >>>> There's a problem that there's already an addrtype E164 in RFC3108. > >>>> This earlier usage of E164 should have been registered with IANA but > >>>> seems to have been missed. To complicate things the format of the > >>>> RFC3108 E164 addrtype is different to the one in the CS draft. > >>>> > >>>> I've already raised this with IANA but I thought it would be worth > >>>> mentioning in MMUSIC. > >>>> > >>>> Christian > >>>> > >>>> > >>>> On 2/07/2013 4:56 AM, The IESG wrote: > >>>>> The IESG has approved the following document: > >>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio > and > >>>>> Video Media Streams Over Circuit-Switched Bearers In The Public > >>>>> Switched Telephone Network (PSTN)' > >>>>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. > >>>>> > >>>>> A URL of this Internet Draft is: > >>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> *Technical Summary > >>>>> * > >>>>> > >>>>> The document 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 Publich Switched Telephone Network (PSTN) > >>>>> > >>>>> *Working Group Summary > >>>>> * > >>>>> > >>>>> The WG had some discussion around the format to use for E.164 > numbers > >>>>> and whether to align this with the existing definition in RFC 3108. > The > >>>>> RFC 3108 definition was seen as deficient and the WG agreed it was > >>>>> better to align with relevant parts of the tel URI format defined i= n > RFC > >>>>> 3966, not least since SDP address types are defined in the context > of a > >>>>> particular network type, and hence RFC 3108 compatibility is not a > >>>>> concern (the implication is that the "E164" address type may differ > >>>>> between network types in SDP). > >>>>> > >>>>> *Document Quality > >>>>> * > >>>>> > >>>>> There are currently no known implementations of the draft, however > the > >>>>> draft is a dependency for 3GPP, so future implementations are > expected. > >>>>> > >>>>> The document has received good overall review in the WG, some of > which > >>>>> resulted in changes to the detailed specification. The document has > been > >>>>> reviewed in detail several times, including of the last few version= s. > >>>>> The major contributors to these as well as earlier discussions are > >>>>> listed in the Acknowledgements section of the document. > >>>>> > >>>>> > >>>>> *Personnel > >>>>> * > >>>>> > >>>>> Document Shepherd: Flemming Andreasen > >>>>> Responsible AD: Gonzalo Camarillo > >>>>> _______________________________________________ > >>>>> mmusic mailing list > >>>>> mmusic@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mmusic > >>>>> > >>>> > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmusic > >>>> . > >>>> > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> . > >> > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From keith.drage@alcatel-lucent.com Wed Oct 9 15:47:51 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 8898C21E8204 for ; Wed, 9 Oct 2013 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bATIySVNWyP for ; Wed, 9 Oct 2013 15:47:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 09CD821E81CB for ; Wed, 9 Oct 2013 15:47:45 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r99MldtW023912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 17:47:40 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r99MldC5007039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 00:47:39 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 10 Oct 2013 00:47:39 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Flemming Andreasen Thread-Topic: [MMUSIC] Updating SDP parameter registry with RFC3108 values Thread-Index: AQHOxQuw3vE+5VfpPkSFvZv7z22ypZnsuTmAgAAY6wCAACY+UA== Date: Wed, 9 Oct 2013 22:47:38 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> In-Reply-To: <5255D88E.1050600@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 22:47:51 -0000 We don't need an RFC to do it. We existed for years without an IANA registr= ation section but still had IANA registrations. My understanding of the current rule is that they need to exist, and give i= nstructions on how to write them. This is to make their job easier and thei= r output more efficient. There is nothing that says that IANA cannot addres= s issues regarding missing material from reading the rest of the RFC. After= all, the entire RFC has IETF consensus. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: 09 October 2013 23:29 > To: Flemming Andreasen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values >=20 > On 10/9/13 4:59 PM, Flemming Andreasen wrote: > > > > On 10/9/13 12:19 PM, Paul Kyzivat wrote: > >> On 10/7/13 6:46 PM, Christian Groves wrote: > >>> Hello Paul, > >>> > >>> Is a process needed to create an errata? Wouldn't the fact that they > >>> appear in standards track RFCs be enough to include them in the SDP > >>> registry based on the SDP directorates (i.e. expert review) > >>> recommendation? I agree its not ideal that these older RFCs didn't > >>> include an IANA considerations section but I think that rather than > >>> spending lots of cycles on this that the SDP directorate could just > >>> request IANA to register them to avoid any future overlap issues. > >> > >> Unfortunately there are rules. The rules for a particular IANA > >> registry are defined when the registry is created. If you check in the > >> registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that > >> additions to this registry must follow the "Specification Required" > >> policy defined in RFC2434. And the specification must include a > >> particular set of information. (That would typically be in an IANA > >> considerations section.) > >> > >> At the moment all we have is RFC3108, and it doesn't have an IANA > >> considerations section at all. It certainly doesn't give the info > >> needed for an addition to that registry. > >> > >> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I > >> think we will need a new RFC that does it. This should probably be an > >> update to 3108. An errata is perhaps a formal way to trigger that. > >> > > Having previously communicated with one of the RFC 3108 authors on this= , > > I would ask for leniency here, not least considering that RFC 3108 > > predates RFC 4566. In other words, I'd argue that we should simply add > > the missing registrations. >=20 > I wasn't trying to be pejorative - just commenting on what seems > required to fix it. >=20 > We just need *some* RFC to do it. It could be 4566bis. But if it isn't > one that explicitly updates 3108, then we should take care to instruct > IANA to make the registry point to 3108. >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Christian.Groves@nteczone.com Wed Oct 9 16:37: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 2812621E81DC for ; Wed, 9 Oct 2013 16:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adlXaKveDk-7 for ; Wed, 9 Oct 2013 16:37:03 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 97B8621E81CD for ; Wed, 9 Oct 2013 16:37:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAPPnVVJ20WhU/2dsb2JhbAANTYM/wTNKgTaDGQEBAQQBAQE1GxgDChELGAkWDwkDAgECARUwEwYCAQEFiAmlZpMyjgyBQIQjA608gV0 Received: from ppp118-209-104-84.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.84]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Oct 2013 10:07:00 +1030 Message-ID: <5255E893.3090302@nteczone.com> Date: Thu, 10 Oct 2013 10:36:51 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> In-Reply-To: <5255C3A7.6000104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 23:37:04 -0000 I would agree with Flemming here. I think leniency is required as it does predate RFC4566. The parameters are in an RFC and it was a product of the MMUSIC WG so I would argue the "specification required" aspect is met. What information is 'missing'? I think its more of a case that the information is there but just not in a 'nice' format. Strictly speaking even "draft-ietf-mmusic-sdp-cs" doesn't meet the requirements of RFC4566 section 8.2.8 because it doesn't provide the "long-form-name", "contact information" and a one paragraph purpose of the name in the RFC as required. Yet there's a registration for this?? So if we hold RFC3108 to the same standard then all the information we need is: RFC3108 -------- 1. Registration of a new "nettype" value Type SDP Name Reference ---- ------------------ --------- nettype ATM [RFC3108] 2. Registration of new "addrtype" value Type SDP Name Reference ---- ------------------ --------- addrtype E164 [RFC3108] Note: RFC 3108 defines the "E164" addrtype in the context of the "ATM" nettype only. 3. Registration of new "addrtype" value Type SDP Name Reference ---- ------------------ --------- addrtype NSAP [RFC3108] Note: RFC 3108 defines the "NSAP" addrtype in the context of the "ATM" nettype only. 4. Registration of new "addrtype" value Type SDP Name Reference ---- ------------------ --------- addrtype GWID [RFC3108] Note: RFC 3108 defines the "GWID" addrtype in the context of the "ATM" nettype only. There's also another RFC that I'm aware of that defines a nettype and addrtype that would need to be registered also. RFC2848 was a product of the PINT WG. The relevant registrations are below: RFC2848 ------- 1. Registration of a new "nettype" value Type SDP Name Reference ---- ------------------ --------- nettype TN [RFC2848] 2. Registration of new "addrtype" value Type SDP Name Reference ---- ------------------ --------- addrtype RFC2543 [RFC2848] Note: RFC 2848 defines the "RFC2543" addrtype in the context of the "TN" nettype only. Regards, Christian On 10/10/2013 7:59 AM, Flemming Andreasen wrote: > > On 10/9/13 12:19 PM, Paul Kyzivat wrote: >> On 10/7/13 6:46 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> Is a process needed to create an errata? Wouldn't the fact that they >>> appear in standards track RFCs be enough to include them in the SDP >>> registry based on the SDP directorates (i.e. expert review) >>> recommendation? I agree its not ideal that these older RFCs didn't >>> include an IANA considerations section but I think that rather than >>> spending lots of cycles on this that the SDP directorate could just >>> request IANA to register them to avoid any future overlap issues. >> >> Unfortunately there are rules. The rules for a particular IANA >> registry are defined when the registry is created. If you check in >> the registry, it points to RFC4566. Section 8.2.4 of RFC4566 says >> that additions to this registry must follow the "Specification >> Required" policy defined in RFC2434. And the specification must >> include a particular set of information. (That would typically be in >> an IANA considerations section.) >> >> At the moment all we have is RFC3108, and it doesn't have an IANA >> considerations section at all. It certainly doesn't give the info >> needed for an addition to that registry. >> >> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I >> think we will need a new RFC that does it. This should probably be an >> update to 3108. An errata is perhaps a formal way to trigger that. >> > Having previously communicated with one of the RFC 3108 authors on > this, I would ask for leniency here, not least considering that RFC > 3108 predates RFC 4566. In other words, I'd argue that we should > simply add the missing registrations. > > Thanks > > -- Flemming > > > >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 8/10/2013 4:44 AM, Paul Kyzivat wrote: >>>> On 10/6/13 11:28 PM, Christian Groves wrote: >>>>> Hello Flemming, >>>>> >>>>> Thanks for pointing out that thread. If Paul as one of the SDP >>>>> directorate is OK with it then I don't have any issue with the -cs >>>>> draft. >>>>> >>>>> I think though that the addresstype and nettype from RFC3108 still >>>>> needs >>>>> to be picked up by the IANA registry. >>>> >>>> I agree. I'm not sure what the best way to accomplish that is. >>>> Perhaps an errata to 3108, pointing out that it fails to register its >>>> new nettype and addrtypes with IANA would start the process. Or is >>>> there a better way? >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, Christian >>>>> >>>>> On 7/10/2013 12:38 PM, Flemming Andreasen wrote: >>>>>> Hi Christian >>>>>> >>>>>> We had a thread on this particular issue about a year ago. See >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>>>> >>>>>> and the conclusion in >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>>>> >>>>>> I hope this addresses your concern as it relates to -cs draft. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>>>> >>>>>>> and noticed that there was a registration for addrtype E164 >>>>>>> linked to >>>>>>> this CS draft. >>>>>>> >>>>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>>>> This earlier usage of E164 should have been registered with IANA >>>>>>> but >>>>>>> seems to have been missed. To complicate things the format of the >>>>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>>>> >>>>>>> I've already raised this with IANA but I thought it would be worth >>>>>>> mentioning in MMUSIC. >>>>>>> >>>>>>> Christian >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From Christian.Groves@nteczone.com Wed Oct 9 17:30: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 65E2021E8230 for ; Wed, 9 Oct 2013 17:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV4eiKs8wM4v for ; Wed, 9 Oct 2013 17:30:57 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id AA57421E8211 for ; Wed, 9 Oct 2013 17:30:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAOfzVVJ20WhU/2dsb2JhbAANTYM/wTRKgTaDGQEBAQQBAQE1GxsKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBBYgJpXGTL44MgUAGhB0DmTKUCoFd Received: from ppp118-209-104-84.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.84]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Oct 2013 11:00:54 +1030 Message-ID: <5255F537.7080204@nteczone.com> Date: Thu, 10 Oct 2013 11:30:47 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 00:30:58 -0000 Isn't this just the manner in which IANA formats their registry? Both RFC2327 and RFC4566 both have text along the lines of "An address type is only meaningful in the context of a network type, and any registration of an address type MUST specify a registered network type, or be submitted along with a network type registration." Given that as part of the registration the applicable nettype must already have been given. Isn't all we need is for IANA to reflect this information in another column "Registered network type" in the addrtype table at SDP parameter registry. Type SDP Name Registered Nettype Reference addrtype IP4 IN [RFC4566] addrtype IP6 IN [RFC4566] addrtype E164 PSTN [RFC-ietf-mmusic-sdp-cs-21] etc. Regards, Christian On 10/10/2013 9:46 AM, DRAGE, Keith (Keith) wrote: > IANA registrations are a set of change requests to IANA to change things. > > If the change has already been done, there is probably no absolute necessity to repeat them. > > As an example, if RFCxxxxbis replaced RFCxxxx and made no new IANA registrations issues, it would be perfectly appropriate to refer to RFC xxxx has having performed the IANA actions. > > Obviously at some point it may be appropriate to document a cumulative history, particularly where the IANA instructions are unclear at some point. However I would not regard it as the prime focus of RFC 4566bis to update the IANA registrations in this regard. > > If the need for an IANA registration is clear despite the absence of a specific IANA registration section, just request it. Otherwise more action is required. > > Keith > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Ali C. Begen (abegen) >> Sent: 09 October 2013 22:04 >> To: Flemming Andreasen (fandreas) >> Cc: ; Paul Kyzivat >> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis >> >> >> On Oct 9, 2013, at 2:00 PM, Flemming Andreasen wrote: >> >>> On 10/7/13 1:51 PM, Paul Kyzivat wrote: >>>> Changing the topic because I'm hijacking the thread. >>>> >>>> On 10/6/13 9:38 PM, Flemming Andreasen wrote: >>>>> Hi Christian >>>>> >>>>> We had a thread on this particular issue about a year ago. See >>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>>> >>>>> and the conclusion in >>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>> Thanks for remembering! >>>> >>>> In that mail I suggested that 4566bis take on updating the format of >> the IANA registries to reflect the dependency between addrtype and nettype. >>>> There are also other ways that the iana registries of SDP parameters >> are deficient. (Notably the registration of att-field names at >> session/media/source level.) >>>> How do we go about updating 4566bis to improve the iana registries? >>> I think we ask Ali to make sure it is covered as part of 4566bis >> (possibly with some mailing list discussion first if you believe that is >> needed). If there are specific text suggestions, then all the better. >> >> So, in the bis document, we can try to make it clearer but are we supposed >> to do a whole registry update as well? And certainly, the discussion will >> be a lot easier with some text proposals... >> >> >>> Thanks >>> >>> -- Flemming >>> >>>> Thanks, >>>> Paul >>>> >>>>> I hope this addresses your concern as it relates to -cs draft. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>>> and noticed that there was a registration for addrtype E164 linked to >>>>>> this CS draft. >>>>>> >>>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>>> This earlier usage of E164 should have been registered with IANA but >>>>>> seems to have been missed. To complicate things the format of the >>>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>>> >>>>>> I've already raised this with IANA but I thought it would be worth >>>>>> mentioning in MMUSIC. >>>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> On 2/07/2013 4:56 AM, The IESG wrote: >>>>>>> The IESG has approved the following document: >>>>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio >> and >>>>>>> Video Media Streams Over Circuit-Switched Bearers In The Public >>>>>>> Switched Telephone Network (PSTN)' >>>>>>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >>>>>>> >>>>>>> A URL of this Internet Draft is: >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Technical Summary >>>>>>> * >>>>>>> >>>>>>> The document 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 Publich Switched Telephone Network (PSTN) >>>>>>> >>>>>>> *Working Group Summary >>>>>>> * >>>>>>> >>>>>>> The WG had some discussion around the format to use for E.164 >> numbers >>>>>>> and whether to align this with the existing definition in RFC 3108. >> The >>>>>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>>>>> better to align with relevant parts of the tel URI format defined in >> RFC >>>>>>> 3966, not least since SDP address types are defined in the context >> of a >>>>>>> particular network type, and hence RFC 3108 compatibility is not a >>>>>>> concern (the implication is that the "E164" address type may differ >>>>>>> between network types in SDP). >>>>>>> >>>>>>> *Document Quality >>>>>>> * >>>>>>> >>>>>>> There are currently no known implementations of the draft, however >> the >>>>>>> draft is a dependency for 3GPP, so future implementations are >> expected. >>>>>>> The document has received good overall review in the WG, some of >> which >>>>>>> resulted in changes to the detailed specification. The document has >> been >>>>>>> reviewed in detail several times, including of the last few versions. >>>>>>> The major contributors to these as well as earlier discussions are >>>>>>> listed in the Acknowledgements section of the document. >>>>>>> >>>>>>> >>>>>>> *Personnel >>>>>>> * >>>>>>> >>>>>>> Document Shepherd: Flemming Andreasen >>>>>>> Responsible AD: Gonzalo Camarillo >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From tireddy@cisco.com Thu Oct 10 00:40: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 22C0811E8121 for ; Thu, 10 Oct 2013 00:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f01tnasGS47P for ; Thu, 10 Oct 2013 00:40:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6927711E8125 for ; Thu, 10 Oct 2013 00:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3732; q=dns/txt; s=iport; t=1381390787; x=1382600387; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ELlIFzmyfeyE+0lwvGvjdUejeiLFQu87uRcQdnSyHh0=; b=Ke4IBqGNB1HSjxhc9QwQnGR22Psk9lYAVMIjdpuefp1SYc2ZWnTBjrHh n59qQny+b7rmJ8wmRGEcE2TMjQLsMZmutqiC8AI0nQFua7wO4DDOo3cOw Swwd4y5/OgnFEkTZEwXd1qVg9S0euV0HJwn9WaVsosld/YhsBMsZfbQGQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUFACZZVlKtJXG8/2dsb2JhbABZgwc4UoMovXgXgQcWbQeCJQEBAQQjEUMOBgEIEQQBAQMCBh0DAgQwFAEGAQEFBQQTCAGHfQyXX48GkjmBKY1tFiiCZDWBBAOZNJBTgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1070,1371081600"; d="scan'208";a="270382868" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 10 Oct 2013 07:39:47 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9A7dkwr021735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Oct 2013 07:39:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 02:39:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-best-interface-pcp-00.txt Thread-Index: AQHOxXvvJHaq13EQfkGcbmsypi8DeJntbRbg Date: Thu, 10 Oct 2013 07:39:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2000017D@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.66.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-best-interface-pcp-00.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 Oct 2013 07:40:08 -0000 UG9ydCBDb250cm9sIFByb3RvY29sIChQQ1AsIFJGQzY4ODcpIHByb3ZpZGVzIGEgbWVjaGFuaXNt IHRvIGRlc2NyaWJlIGEgZmxvdyB0byB0aGUgbmV0d29yay4gVGhlIHByaW1hcnkgZHJpdmVyIGZv ciBQQ1AgaGFzIGJlZW4gY3JlYXRpbmcgcG9ydCBtYXBwaW5ncyBvbiBOQVQgYW5kIGZpcmV3YWxs IGRldmljZXMuIFdoZW4gZG9pbmcgdGhpcywgUENQIHB1c2hlcyBmbG93IGluZm9ybWF0aW9uIGZy b20gdGhlIGhvc3QgaW50byB0aGUgbmV0d29yayAoc3BlY2lmaWNhbGx5IHRvIHRoZSBuZXR3b3Jr J3MgTkFUIG9yIGZpcmV3YWxsIGRldmljZSksIGFuZCByZWNlaXZlcyBpbmZvcm1hdGlvbiBiYWNr IGZyb20gdGhlIG5ldHdvcmsgKGZyb20gdGhlIE5BVCBvciBmaXJld2FsbCBkZXZpY2UpLg0KDQpQ Q1AgY2FuIGFsc28gYmUgdXNlZCB0byBzaWduYWwgZmxvdyBjaGFyYWN0ZXJpc3RpY3MgdG8gdGhl IG5ldHdvcmssIGFuZCB0aGUgbmV0d29yayB0byBzaWduYWwgaXRzIGFiaWxpdHkgdG8gYWNjb21t b2RhdGUgdGhhdCBmbG93IGJhY2sgdG8gdGhlIGhvc3QuIEluIHRoaXMgZHJhZnQsIElDRSBhZ2Vu dCB1c2VzIFBDUCBGbG93IEV4dGVuc2lvbiB0byBkZXRlcm1pbmUgdGhlIGxpbmsgY2hhcmFjdGVy aXN0aWNzIG9mIHRoZSBob3N0J3MgaW50ZXJmYWNlcywgd2hpY2ggaW5mbHVlbmNlcyB0aGUgSUNF IGNhbmRpZGF0ZSBwcmlvcml0eS4NCg0KWW91ciByZXZpZXdzL2NvbW1lbnRzL3N1Z2dlc3Rpb25z IGFyZSBhcHByZWNpYXRlZC4NCg0KLUF1dGhvcnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTAsIDIwMTMgMTE6MTUgQU0N ClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBWYXJ1biBTaW5naDsgUmVpbmFsZG8g UGVubm8gKHJlcGVubm8pOyBCaWxsIFZlclN0ZWVnOyBCaWxsIFZlciBTdGVlZzsgRGFuIFdpbmcg KGR3aW5nKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRk eS1tbXVzaWMtaWNlLWJlc3QtaW50ZXJmYWNlLXBjcC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtcmVkZHktbW11c2ljLWljZS1iZXN0LWludGVyZmFjZS1wY3AtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXJl ZGR5LW1tdXNpYy1pY2UtYmVzdC1pbnRlcmZhY2UtcGNwDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJ CSBJbXByb3ZpbmcgSUNFIEludGVyZmFjZSBTZWxlY3Rpb24gVXNpbmcgUG9ydCBDb250cm9sIFBy b3RvY29sIChQQ1ApIEZsb3cgRXh0ZW5zaW9uDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xMA0K R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDgNClVSTDog ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVk ZHktbW11c2ljLWljZS1iZXN0LWludGVyZmFjZS1wY3AtMDAudHh0DQpTdGF0dXM6ICAgICAgICAg IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktbW11c2ljLWljZS1i ZXN0LWludGVyZmFjZS1wY3ANCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcmVkZHktbW11c2ljLWljZS1iZXN0LWludGVyZmFjZS1wY3AtMDANCg0KDQpB YnN0cmFjdDoNCiAgIEEgaG9zdCB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMgbmVlZHMgdG8gY2hv b3NlIHRoZSBiZXN0IGludGVyZmFjZQ0KICAgZm9yIGNvbW11bmljYXRpb24uICBPZnRlbnRpbWVz LCB0aGlzIGRlY2lzaW9uIGlzIGJhc2VkIG9uIGEgc3RhdGljDQogICBjb25maWd1cmF0aW9uIGFu ZCBkb2VzIG5vdCBjb25zaWRlciB0aGUgbGluayBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhhdA0KICAg aW50ZXJmYWNlLCB3aGljaCBtYXkgYWZmZWN0IHRoZSB1c2VyIGV4cGVyaWVuY2UuDQoNCiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGZvciBhbiBlbmRwb2ludCB0byBxdWVy eSB0aGUgbGluaw0KICAgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIGFjY2VzcyByb3V0ZXIgKHRo ZSByb3V0ZXIgYXQgdGhlIG90aGVyIGVuZA0KICAgb2YgdGhlIGVuZHBvaW50J3MgYWNjZXNzIGxp bmspIHVzaW5nIGEgUG9ydCBDb250cm9sIFByb3RvY29sIChQQ1ApDQogICBGbG93IEV4dGVuc2lv bi4gIFRoaXMgaW5mb3JtYXRpb24gaW5mbHVlbmNlcyBlbmRwb2ludCdzIEludGVyYWN0aXZlDQog ICBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCAoSUNFKSBjYW5kaWRhdGUgc2VsZWN0aW9uIGFs Z29yaXRobS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From magnus.westerlund@ericsson.com Thu Oct 10 02:25: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 6D0C721F9FA7 for ; Thu, 10 Oct 2013 02:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.989 X-Spam-Level: X-Spam-Status: No, score=-104.989 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61+cahLs5WK8 for ; Thu, 10 Oct 2013 02:25:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3B721F9FD6 for ; Thu, 10 Oct 2013 02:25:05 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-72-5256726ff33d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3B.E6.03802.F6276525; Thu, 10 Oct 2013 11:25:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Thu, 10 Oct 2013 11:25:03 +0200 Message-ID: <525672AF.1090503@ericsson.com> Date: Thu, 10 Oct 2013 11:26:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Elwyn Davies References: <1381331780.13277.72869.camel@mightyatom> In-Reply-To: <1381331780.13277.72869.camel@mightyatom> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+JvrW5BUViQwc4WNovjB3awW0xd/pjF gcnj68l2Fo8lS34yBTBFcdmkpOZklqUW6dslcGU87lYoaHaqmHnnKlsD4znjLkZODgkBE4kH M+ayQthiEhfurWfrYuTiEBI4zChx48gZJghnOaPE9CkfwKp4BbQlfqz5wwxiswioSvxu+csG YrMJWEjc/NEIZosKBEu0b//KBlEvKHFy5hMWEFtEQE1i89cHjCA2s4C6RM/vFrA5wgKWEkcX LgarFxIwlbjVcAOshlPATGLdpQWMENdJSmxbdIwdoldPYsrVFqg58hLNW2czQ/RqSzQ0dbBO YBSahWT1LCQts5C0LGBkXsXInpuYmZNebrSJERiqB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwcs1htXrqqCuztODT0gSxpkKhS1bxi2K2z8rYE/rs 2udexzT2KfV7N4rqvGGPv9T3zbxsjtZ0k+K37XH3zhflzlL5PHdHU4FxdLCHh4+OKPds/zdW FiXaD3Yq8t6cmeq4Ien1MZPiF5tXPH3tHLo48VqSRmfaTu8fcd9ObT35Zv6kVf+bkjY0KbEU ZyQaajEXFScCAOvBovQjAgAA Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering. 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 Oct 2013 09:25:14 -0000 Hi Elwyn, Thanks for spotting ttis. Yes, I agree this is inconsistent, and needs clearer text. On 2013-10-09 17:16, Elwyn Davies wrote: > In the proces of checking the changes from v34 to v37, I found that > there have been some changes to the CSeq specification (Section 18.20) > that seem a bit garbled. > > In para 1, it is stated: >> For each new RTSP request an agent creates the CSeq value >> MUST be incremented by one. > > Then later: >> Agents receiving a request over a reliable transport with an in-order >> delivery MUST ignore how the sequence value increments, i.e. it can >> increment with other values than 1. > This is actually not really a contradiction to the first sentence. You can require to send with monotonically increasing sequence numbers, and require the receiver to not throw a fit if the received messages are not having monotonically increasing sequence numbers. However, it doesn't result in the effect I was after. So it needs reformulation. > and >> Proxies that aggregate several client sessions on the same transport >> will have to ensure that the requests sent towards a particular >> server have a joint sequence number space. A proxy having one client >> with concurrent sessions with two different servers using the same >> client proxy connection can avoid rewriting on the proxy to server >> connection. > > The first requirement is contradicted by the second and third stories. I think the way of fixing this is to clarify that the first statements are for RTSP agents originating requests. RTSP Proxies that aggregates requests on a transport MUST renumber to have monotonically increasing sequence numbers on that next hop transport. However, Proxies that aggregates responses towards an agent just maps back the (if necessary) the sequence numbers the corresponding requests had. And there is okay for that proxy to send responses out of order due to their potentially different request targets. Thus, requests must be forwarded in order and processed in order at the request's destination, the responses can arrive out of order. This will work even if there is unreliable transport. A lost response will result in a retransmitted request, that the next hop that received (and potentially cached) can retransmit the response. > > We also have: >> It also enables detecting loss of a request >> and await a retransmission prior to processing a sub-sequent request >> when using unreliable transport. > > I understood that RTSP/2.0 is only specified to run over reliable > transports, so this either requires some usage of the subjunctive mood > or maybe deletion. However, having non-sequential CSeq values would > indeed screw up any future usage of unreliable transport. > > I wonder if this can be handled by changing the increment requirement so > that it applies to requests sent down a given server connection (or > channel). Then if unreliable transports ever did come back, the > sequencing would still work on a per source/destination address/port > quadruple (or whatever), while giving unique (but not necessarily > integer sequential) numbering on the multiplexed connections. > > Anyway, I think that this section needs another pass to sort out the > inconsistencies. Yes, below you find a rewrite of the text. I tried writing this with minimal exceptions for proxies. So please review it so that you think you understand it and agrees with the rules. 18.20. CSeq The CSeq general-header field specifies the sequence number for an RTSP request-response pair. This field MUST be present in all requests and responses. For each new RTSP request an agent originates on a particular RTSP message transport the CSeq value MUST be incremented by one. The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its request to a server and the server has another when sending request to the client. Each requester and responder is identified with its socket address (IP address and port number), i.e., per direction of a TCP connection. Any retransmitted request MUST contain the same sequence number as the original, i.e., the sequence number is not incremented for retransmissions of the same request. The RTSP agent receiving requests MUST process the requests arriving on particular transport in the order of the sequence numbers. Responses are sent in the order they are generated. The RTSP response MUST have the same sequence number as present in the corresponding request. A RTSP Agent receiving a response MAY receive the responses out of order compared to the order of the requests it sent. Thus, the agent MUST use the sequence number in the response to pair it with the corresponding request. The main purpose of the sequence number is to map responses to requests. The sequence number requirement on using increment of one for each new request is to support any future specification of RTSP message transport over a protocol that don't provide in order delivery or is unreliable. The above rule regarding initial sequence number may appear unnecessary loose. However, they are allowing for a behavior which is not uncommon. When using multiple reliable connections in sequence it may still be easiest to use a single sequence number series for a client connecting with a particular server. Thus, the initial sequence number may be arbitrary depending on the number of previous requests. For any unreliable transport a stricter definition will be required to enable detection of any loss of the first request. When using multiple sequential transport connections, there is no protocol mechanism to ensure in order processing as the sequence number is scoped on the individual transport connection and its five tuple. Thus, there are potential issues with opening a new transport connection to the same host for which there already exist a transport connection with out standing requests and send requests related to the same RTSP session. RTSP Proxies also needs to follow the above rules. This implies that proxies that aggregates requests from multiple clients onto a single transport towards a server or a next hop proxy needs to renumber those request to form a joint sequence number on that transport, fulfilling the above rules. A proxy capable of fulfilling some agents request without emitting its own request, also causes a need to renumber as the number of received requests with a particular target, may not be the same as the number of emitted requests towards that target agent. A proxy that needs to renumber, needs to perform the corresponding renumbering back to the original sequence number for any received response. A proxy MUST maintain the order between responses related to requests originating from the same agent. A client connected to a proxy, and using that transport to send request to multiple servers creates a situation where it is quite likely to receive the responses out of order. This as the proxy will establish different transports from the proxy to the servers and forward the client's requests on. When the responses arrive from the different servers they will be forwarded to the client in the order they arrive at the proxy and can be processed, not the order of the sequence numbers. This is intentional to avoid some sessions requests being blocked by another server's slow processing of requests. 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 magnus.westerlund@ericsson.com Thu Oct 10 02:30:38 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 9DF9721E80E3 for ; Thu, 10 Oct 2013 02:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.086 X-Spam-Level: X-Spam-Status: No, score=-105.086 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fzbXTdILDtV for ; Thu, 10 Oct 2013 02:30:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C45021F9FE9 for ; Thu, 10 Oct 2013 02:30:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-97-525673b5e860 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AA.B2.16099.5B376525; Thu, 10 Oct 2013 11:30:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.328.9; Thu, 10 Oct 2013 11:27:06 +0200 Message-ID: <5256732A.1060708@ericsson.com> Date: Thu, 10 Oct 2013 11:28:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ross Finlayson References: <1381331780.13277.72869.camel@mightyatom> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VndrcViQwd/JUhZTG/+zWkxd/pjF gcljyZKfTB6rl/xhDWCK4rJJSc3JLEst0rdL4Mpob17FWPCaveLK+9fsDYzb2boYOTkkBEwk 7k86xQhhi0lcuLceKM7FISRwmFHi5OLd7BDOckaJAxOvgXXwCmhLrLy8iB3EZhFQlZjdeRbM ZhOwkLj5oxGsRlQgWKJ9+1eoekGJkzOfsHQxcnCICGhJXJ1UAxJmFlCX6PndwgxiCws4SZxv 2ccEUiIkkCHxsdUUJMwpYC/R8XQW1J2SEtsWHWOHaNWTmHK1hRHClpdo3jobbIwQ0GUNTR2s ExiFZiFZPAtJyywkLQsYmVcxsucmZuaklxtuYgQG6sEtv3V3MJ46J3KIUZqDRUmc98Nb5yAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKVCEzS/OUTXmF7mnll0T99Vy3Txkfuf/N+cmj17 oo1DYNJjy6v5TgsPzlbnvLim//2NUBn/3cdeOk6WaRQ4b9H5NfQ+8/SP22Yf3ipTvfwm+6I6 RfmnKVG1XExBjN1MK+f/dquMY9y13Hr19zRN5vW72nPNvV8/iF44r87gbs3+t4HaOwzbNZRY ijMSDbWYi4oTAYDBIdgiAgAA Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering. 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 Oct 2013 09:30:38 -0000 On 2013-10-10 00:35, Ross Finlayson wrote: >> Anyway, I think that this section needs another pass to sort out the >> inconsistencies. > > Or else get rid of the "CSeq" field altogether... I don't think that helps. Then we get another set of problems related to how an originating agent maps requests to responses. Especially in the relation to proxies. For example you can't have an client use one proxy and establish two RTSP session with different servers at the same time without running into blocking issues. 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 elwynd@folly.org.uk Thu Oct 10 04:53:38 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 C184011E814C for ; Thu, 10 Oct 2013 04:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15E6bZ0TIos3 for ; Thu, 10 Oct 2013 04:53:30 -0700 (PDT) Received: from bounce.a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 870F511E8136 for ; Thu, 10 Oct 2013 04:53:21 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1VUEnu-0007O7-3k; Thu, 10 Oct 2013 12:53:18 +0100 From: Elwyn Davies To: Magnus Westerlund In-Reply-To: <525672AF.1090503@ericsson.com> References: <1381331780.13277.72869.camel@mightyatom> <525672AF.1090503@ericsson.com> Content-Type: multipart/mixed; boundary="=-P33sIvtt/sOBL9jKmYzm" Organization: Folly Consulting Date: Thu, 10 Oct 2013 12:56:28 +0100 Message-Id: <1381406189.13277.74238.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering. 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 Oct 2013 11:53:39 -0000 --=-P33sIvtt/sOBL9jKmYzm Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Magnus. The text below is better, but there still seem to be a couple of problems. I have edited the language and added some comments in the attached file (embedded in [[..]]). Regards, Elwyn On Thu, 2013-10-10 at 11:26 +0200, Magnus Westerlund wrote: > Hi Elwyn, >=20 > Thanks for spotting ttis. Yes, I agree this is inconsistent, and needs > clearer text. >=20 > On 2013-10-09 17:16, Elwyn Davies wrote: > > In the proces of checking the changes from v34 to v37, I found that > > there have been some changes to the CSeq specification (Section 18.20) > > that seem a bit garbled. > >=20 > > In para 1, it is stated: > >> For each new RTSP request an agent creates the CSeq value > >> MUST be incremented by one. > >=20 > > Then later: > >> Agents receiving a request over a reliable transport with an in-order > >> delivery MUST ignore how the sequence value increments, i.e. it can > >> increment with other values than 1.=20 > >=20 >=20 > This is actually not really a contradiction to the first sentence. You > can require to send with monotonically increasing sequence numbers, and > require the receiver to not throw a fit if the received messages are not > having monotonically increasing sequence numbers. However, it doesn't > result in the effect I was after. So it needs reformulation. >=20 > > and > >> Proxies that aggregate several client sessions on the same transport > >> will have to ensure that the requests sent towards a particular > >> server have a joint sequence number space. A proxy having one clie= nt > >> with concurrent sessions with two different servers using the same > >> client proxy connection can avoid rewriting on the proxy to server > >> connection. =20 > >=20 > > The first requirement is contradicted by the second and third stories. >=20 > I think the way of fixing this is to clarify that the first statements > are for RTSP agents originating requests. RTSP Proxies that aggregates > requests on a transport MUST renumber to have monotonically increasing > sequence numbers on that next hop transport. However, Proxies that > aggregates responses towards an agent just maps back the (if necessary) > the sequence numbers the corresponding requests had. And there is okay > for that proxy to send responses out of order due to their potentially > different request targets. Thus, requests must be forwarded in order and > processed in order at the request's destination, the responses can > arrive out of order. >=20 > This will work even if there is unreliable transport. A lost response > will result in a retransmitted request, that the next hop that received > (and potentially cached) can retransmit the response. >=20 > >=20 > > We also have: > >> It also enables detecting loss of a request > >> and await a retransmission prior to processing a sub-sequent reques= t > >> when using unreliable transport. =20 > >=20 > > I understood that RTSP/2.0 is only specified to run over reliable > > transports, so this either requires some usage of the subjunctive mood > > or maybe deletion. However, having non-sequential CSeq values would > > indeed screw up any future usage of unreliable transport. > >=20 > > I wonder if this can be handled by changing the increment requirement s= o > > that it applies to requests sent down a given server connection (or > > channel). Then if unreliable transports ever did come back, the > > sequencing would still work on a per source/destination address/port > > quadruple (or whatever), while giving unique (but not necessarily > > integer sequential) numbering on the multiplexed connections. > >=20 > > Anyway, I think that this section needs another pass to sort out the > > inconsistencies. >=20 > Yes, below you find a rewrite of the text. I tried writing this with > minimal exceptions for proxies. So please review it so that you think > you understand it and agrees with the rules. >=20 > 18.20. CSeq >=20 > The CSeq general-header field specifies the sequence number for an > RTSP request-response pair. This field MUST be present in all > requests and responses. For each new RTSP request an agent > originates on a particular RTSP message transport the CSeq value MUST > be incremented by one. The initial sequence number MAY be any > number, however, it is RECOMMENDED to start at 0. Each sequence > number series is unique between each requester and responder, i.e., > the client has one series for its request to a server and the server > has another when sending request to the client. Each requester and > responder is identified with its socket address (IP address and port > number), i.e., per direction of a TCP connection. Any retransmitted > request MUST contain the same sequence number as the original, i.e., > the sequence number is not incremented for retransmissions of the > same request. The RTSP agent receiving requests MUST process the > requests arriving on particular transport in the order of the > sequence numbers. Responses are sent in the order they are > generated. The RTSP response MUST have the same sequence number as > present in the corresponding request. A RTSP Agent receiving a > response MAY receive the responses out of order compared to the order > of the requests it sent. Thus, the agent MUST use the sequence > number in the response to pair it with the corresponding request. >=20 > The main purpose of the sequence number is to map responses to > requests. >=20 > The sequence number requirement on using increment of one for each > new request is to support any future specification of RTSP message > transport over a protocol that don't provide in order delivery or > is unreliable. >=20 > The above rule regarding initial sequence number may appear > unnecessary loose. However, they are allowing for a behavior > which is not uncommon. When using multiple reliable connections > in sequence it may still be easiest to use a single sequence > number series for a client connecting with a particular server. > Thus, the initial sequence number may be arbitrary depending on > the number of previous requests. For any unreliable transport a > stricter definition will be required to enable detection of any > loss of the first request. >=20 > When using multiple sequential transport connections, there is no > protocol mechanism to ensure in order processing as the sequence > number is scoped on the individual transport connection and its > five tuple. Thus, there are potential issues with opening a new > transport connection to the same host for which there already > exist a transport connection with out standing requests and send > requests related to the same RTSP session. >=20 > RTSP Proxies also needs to follow the above rules. This implies that > proxies that aggregates requests from multiple clients onto a single > transport towards a server or a next hop proxy needs to renumber > those request to form a joint sequence number on that transport, > fulfilling the above rules. A proxy capable of fulfilling some > agents request without emitting its own request, also causes a need > to renumber as the number of received requests with a particular > target, may not be the same as the number of emitted requests towards > that target agent. A proxy that needs to renumber, needs to perform > the corresponding renumbering back to the original sequence number > for any received response. A proxy MUST maintain the order between > responses related to requests originating from the same agent. >=20 > A client connected to a proxy, and using that transport to send > request to multiple servers creates a situation where it is quite > likely to receive the responses out of order. This as the proxy > will establish different transports from the proxy to the servers > and forward the client's requests on. When the responses arrive > from the different servers they will be forwarded to the client in > the order they arrive at the proxy and can be processed, not the > order of the sequence numbers. This is intentional to avoid some > sessions requests being blocked by another server's slow > processing of requests. >=20 >=20 > Cheers >=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 --=-P33sIvtt/sOBL9jKmYzm Content-Disposition: attachment; filename="CSeq.txt" Content-Type: text/plain; name="CSeq.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit 18.20. CSeq The CSeq general-header field specifies the sequence number (integer) for an RTSP request-response pair. This field MUST be present in all requests and responses. RTSP agents maintain a sequence number series for each responder to which they have an open message transport channel. For each new RTSP request an agent originates on a particular RTSP message transport the CSeq value MUST be incremented by one. The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its requests to a server and the server has another when sending requests to the client. Each requester and responder is identified by its socket address (IP address and port number), i.e., per direction of a TCP connection. Any retransmitted request MUST contain the same sequence number as the original, i.e., the sequence number is not incremented for retransmissions of the same request. The RTSP agent receiving requests MUST process the requests arriving on a particular transport in the order of the sequence numbers. Responses are sent in the order that they are generated. The RTSP response MUST have the same sequence number as was present in the corresponding request. A RTSP Agent receiving a response MAY receive the responses out of order compared to the order of the requests it sent. Thus, the agent MUST use the sequence number in the response to pair it with the corresponding request. The main purpose of the sequence number is to map responses to requests. The requirement to use a sequence number increment of one for each new request is to support any future specification of RTSP message transport over a protocol that does not provide in order delivery or is unreliable. The above rule regarding the initial sequence number may appear unnecessarily loose. However, it is designed to cater for existing implementations that commonly deployed. When using multiple reliable connections in sequence it may still be easiest to use a single sequence number series for a client connecting with a particular server. Thus, the initial sequence number may be arbitrary depending on the number of previous requests. For any unreliable transport a stricter definition will be required to enable detection of any loss of the first request. When using multiple sequential transport connections, there is no protocol mechanism to ensure in order processing as the sequence number is scoped on the individual transport connection and its five tuple. Thus, there are potential issues with opening a new transport connection to the same host for which there already exists a transport connection with outstanding requests and previously despatched requests related to the same RTSP session. [[I think this is what was meant]]. RTSP Proxies also need to follow the above rules. This implies that proxies that aggregate requests from multiple clients onto a single transport towards a server or a next hop proxy need to renumber these requests to form a unified sequence on that transport, fulfilling the above rules. A proxy capable of fulfilling some agent's request without emitting its own request (e.g., a caching proxy that fulfils a request from its cache), also causes a need to renumber as the number of received requests with a particular target, may not be the same as the number of emitted requests towards that target agent. A proxy that needs to renumber, needs to perform the corresponding renumbering back to the original sequence number for any received response before forwarding it back to the originator of the request. A proxy MUST maintain the order between responses related to requests originating from the same agent. [[I don't see why this ordering requirement is needed for TCP - above we mandate that agents must be able to handle out of order responses. Indeed I think this is directly contradictory to the following note! UDP would be a different matter but that is out of scope. OTOH there might be a need for proxies that actually process responses to carry out the processing in the sequence of the incoming requests that resulted in the responses - I am not sure if this is ever the case.]] A client connected to a proxy, and using that transport to send requests to multiple servers creates a situation where it is quite likely to receive the responses out of order. This is because the proxy will establish separate transports from the proxy to the servers on which to forward the client's requests. When the responses arrive from the different servers they will be forwarded to the client in the order they arrive at the proxy and can be processed, not the order of the client's original sequence numbers. This is intentional to avoid some session's requests being blocked by another server's slow processing of requests. --=-P33sIvtt/sOBL9jKmYzm-- From magnus.westerlund@ericsson.com Thu Oct 10 07:00: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 63A7D21F994A for ; Thu, 10 Oct 2013 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.344 X-Spam-Level: X-Spam-Status: No, score=-103.344 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrJr3P8od2Xp for ; Thu, 10 Oct 2013 07:00:34 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id AC69611E8174 for ; Thu, 10 Oct 2013 07:00:26 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-b8-5256b2f98c52 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 83.38.25272.9F2B6525; Thu, 10 Oct 2013 16:00:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Thu, 10 Oct 2013 16:00:25 +0200 Message-ID: <5256B332.2020608@ericsson.com> Date: Thu, 10 Oct 2013 16:01:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Elwyn Davies References: <1381331780.13277.72869.camel@mightyatom> <525672AF.1090503@ericsson.com> <1381406189.13277.74238.camel@mightyatom> In-Reply-To: <1381406189.13277.74238.camel@mightyatom> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre7PTWFBBqfbzC2OH9jBbjF1+WMW ByaPryfbWTyWLPnJFMAUxWWTkpqTWZZapG+XwJXxcNtpxoLH0RXP7jxgbGC85t7FyMEhIWAi 8WxRdBcjJ5ApJnHh3nq2LkYuDiGBo4wS7x59ZYdwljNKtC+dwQ5SxSugLTF7/XcWEJtFQFXi 18wpbCA2m4CFxM0fjWC2qECwRPv2r2wQ9YISJ2c+AasXEVCT2Pz1ASOIzSygLtHzu4UZxBYW sJQ4unAx1OYGRokLvYuYQBKcAmYSy3tfsUOcJymxbdExdohmPYkpV1ugBslLNG+dDTZICOi4 hqYO1gmMQrOQ7J6FpGUWkpYFjMyrGDmKU4uTctONDDYxAsP14JbfFjsYL/+1OcQozcGiJM77 8a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGh+u2+JtdnG9z+M+rnAShe4aqDKd+yr25 ordv1uVH7g5RN39bnI3L1Pb2MG9+seP3kj8Cuhf3ai/hiVZd9TjGQrnm1vnd5xx/219kVvFZ pLm5apPJ+kXMatJs/0X5rGZ5uMfoV1w599zpulzhvf0WqeeYsmOPG7xtKyn7suDd1qPhKf/+ 76rapsRSnJFoqMVcVJwIAPqujPMlAgAA Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering. 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 Oct 2013 14:00:45 -0000 Hi, Thanks Elwyn for taking a look at these changes. I taken the changes with two exceptions. In a private email you already had provided a better rewrite of one of the sentence going into the below motivation. That I kept, thus that motivation now reads: The above rules relating to the initial sequence number may appear unnecessarily loose. The reason is to cater for some common behavior of existing implementations: When using multiple reliable connections in sequence it may still be easiest to use a single sequence number series for a client connecting with a particular server. Thus, the initial sequence number may be arbitrary depending on the number of previous requests. For any unreliable transport a stricter definition or other solution will be required to enable detection of any loss of the first request. The second thing is this part of the Proxy paragraph: A proxy MUST maintain the order between responses related to requests originating from the same agent. And your comments. [[I don't see why this ordering requirement is needed for TCP - above we mandate that agents must be able to handle out of order responses. Indeed I think this is directly contradictory to the following note! UDP would be a different matter but that is out of scope. OTOH there might be a need for proxies that actually process responses to carry out the processing in the sequence of the incoming requests that resulted in the responses - I am not sure if this is ever the case.]] Yes, my sentence become wrong. The requirement was meant to say that the responses arriving from a particular server may not be reordered. However, I agree with you that this is both an unnecessary requirement due to the requirement to actually match based on sequence number. Secondly, a proxy chain is also unlikely to reorder the responses from a particular server on the way. Thus, I will propose that one is removed. Cheers Magnus On 2013-10-10 13:56, Elwyn Davies wrote: > Hi, Magnus. > > The text below is better, but there still seem to be a couple of > problems. I have edited the language and added some comments in the > attached file (embedded in [[..]]). > > Regards, > Elwyn > > On Thu, 2013-10-10 at 11:26 +0200, Magnus Westerlund wrote: >> Hi Elwyn, >> >> Thanks for spotting ttis. Yes, I agree this is inconsistent, and needs >> clearer text. >> >> On 2013-10-09 17:16, Elwyn Davies wrote: >>> In the proces of checking the changes from v34 to v37, I found that >>> there have been some changes to the CSeq specification (Section 18.20) >>> that seem a bit garbled. >>> >>> In para 1, it is stated: >>>> For each new RTSP request an agent creates the CSeq value >>>> MUST be incremented by one. >>> >>> Then later: >>>> Agents receiving a request over a reliable transport with an in-order >>>> delivery MUST ignore how the sequence value increments, i.e. it can >>>> increment with other values than 1. >>> >> >> This is actually not really a contradiction to the first sentence. You >> can require to send with monotonically increasing sequence numbers, and >> require the receiver to not throw a fit if the received messages are not >> having monotonically increasing sequence numbers. However, it doesn't >> result in the effect I was after. So it needs reformulation. >> >>> and >>>> Proxies that aggregate several client sessions on the same transport >>>> will have to ensure that the requests sent towards a particular >>>> server have a joint sequence number space. A proxy having one client >>>> with concurrent sessions with two different servers using the same >>>> client proxy connection can avoid rewriting on the proxy to server >>>> connection. >>> >>> The first requirement is contradicted by the second and third stories. >> >> I think the way of fixing this is to clarify that the first statements >> are for RTSP agents originating requests. RTSP Proxies that aggregates >> requests on a transport MUST renumber to have monotonically increasing >> sequence numbers on that next hop transport. However, Proxies that >> aggregates responses towards an agent just maps back the (if necessary) >> the sequence numbers the corresponding requests had. And there is okay >> for that proxy to send responses out of order due to their potentially >> different request targets. Thus, requests must be forwarded in order and >> processed in order at the request's destination, the responses can >> arrive out of order. >> >> This will work even if there is unreliable transport. A lost response >> will result in a retransmitted request, that the next hop that received >> (and potentially cached) can retransmit the response. >> >>> >>> We also have: >>>> It also enables detecting loss of a request >>>> and await a retransmission prior to processing a sub-sequent request >>>> when using unreliable transport. >>> >>> I understood that RTSP/2.0 is only specified to run over reliable >>> transports, so this either requires some usage of the subjunctive mood >>> or maybe deletion. However, having non-sequential CSeq values would >>> indeed screw up any future usage of unreliable transport. >>> >>> I wonder if this can be handled by changing the increment requirement so >>> that it applies to requests sent down a given server connection (or >>> channel). Then if unreliable transports ever did come back, the >>> sequencing would still work on a per source/destination address/port >>> quadruple (or whatever), while giving unique (but not necessarily >>> integer sequential) numbering on the multiplexed connections. >>> >>> Anyway, I think that this section needs another pass to sort out the >>> inconsistencies. >> >> Yes, below you find a rewrite of the text. I tried writing this with >> minimal exceptions for proxies. So please review it so that you think >> you understand it and agrees with the rules. >> >> 18.20. CSeq >> >> The CSeq general-header field specifies the sequence number for an >> RTSP request-response pair. This field MUST be present in all >> requests and responses. For each new RTSP request an agent >> originates on a particular RTSP message transport the CSeq value MUST >> be incremented by one. The initial sequence number MAY be any >> number, however, it is RECOMMENDED to start at 0. Each sequence >> number series is unique between each requester and responder, i.e., >> the client has one series for its request to a server and the server >> has another when sending request to the client. Each requester and >> responder is identified with its socket address (IP address and port >> number), i.e., per direction of a TCP connection. Any retransmitted >> request MUST contain the same sequence number as the original, i.e., >> the sequence number is not incremented for retransmissions of the >> same request. The RTSP agent receiving requests MUST process the >> requests arriving on particular transport in the order of the >> sequence numbers. Responses are sent in the order they are >> generated. The RTSP response MUST have the same sequence number as >> present in the corresponding request. A RTSP Agent receiving a >> response MAY receive the responses out of order compared to the order >> of the requests it sent. Thus, the agent MUST use the sequence >> number in the response to pair it with the corresponding request. >> >> The main purpose of the sequence number is to map responses to >> requests. >> >> The sequence number requirement on using increment of one for each >> new request is to support any future specification of RTSP message >> transport over a protocol that don't provide in order delivery or >> is unreliable. >> >> The above rule regarding initial sequence number may appear >> unnecessary loose. However, they are allowing for a behavior >> which is not uncommon. When using multiple reliable connections >> in sequence it may still be easiest to use a single sequence >> number series for a client connecting with a particular server. >> Thus, the initial sequence number may be arbitrary depending on >> the number of previous requests. For any unreliable transport a >> stricter definition will be required to enable detection of any >> loss of the first request. >> >> When using multiple sequential transport connections, there is no >> protocol mechanism to ensure in order processing as the sequence >> number is scoped on the individual transport connection and its >> five tuple. Thus, there are potential issues with opening a new >> transport connection to the same host for which there already >> exist a transport connection with out standing requests and send >> requests related to the same RTSP session. >> >> RTSP Proxies also needs to follow the above rules. This implies that >> proxies that aggregates requests from multiple clients onto a single >> transport towards a server or a next hop proxy needs to renumber >> those request to form a joint sequence number on that transport, >> fulfilling the above rules. A proxy capable of fulfilling some >> agents request without emitting its own request, also causes a need >> to renumber as the number of received requests with a particular >> target, may not be the same as the number of emitted requests towards >> that target agent. A proxy that needs to renumber, needs to perform >> the corresponding renumbering back to the original sequence number >> for any received response. A proxy MUST maintain the order between >> responses related to requests originating from the same agent. >> >> A client connected to a proxy, and using that transport to send >> request to multiple servers creates a situation where it is quite >> likely to receive the responses out of order. This as the proxy >> will establish different transports from the proxy to the servers >> and forward the client's requests on. When the responses arrive >> from the different servers they will be forwarded to the client in >> the order they arrive at the proxy and can be processed, not the >> order of the sequence numbers. This is intentional to avoid some >> sessions requests being blocked by another server's slow >> processing of requests. >> >> >> 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 >> ---------------------------------------------------------------------- >> -- 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 internet-drafts@ietf.org Thu Oct 10 07:26: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 1DDA121F92B8; Thu, 10 Oct 2013 07:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iauRZKBueG+E; Thu, 10 Oct 2013 07:26:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC5121F9302; Thu, 10 Oct 2013 07:26:22 -0700 (PDT) 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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131010142622.30339.52922.idtracker@ietfa.amsl.com> Date: Thu, 10 Oct 2013 07:26:22 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-38.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:26:31 -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 : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-38.txt Pages : 322 Date : 2013-10-10 Abstract: This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-38 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-38 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Thu Oct 10 07:42: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 8A64421F9B25 for ; Thu, 10 Oct 2013 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.12 X-Spam-Level: X-Spam-Status: No, score=-105.12 tagged_above=-999 required=5 tests=[AWL=1.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLv24pTOTO7U for ; Thu, 10 Oct 2013 07:42:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BE16C11E8170 for ; Thu, 10 Oct 2013 07:42:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-42-5256bcd54ac7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.BA.16099.5DCB6525; Thu, 10 Oct 2013 16:42:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Thu, 10 Oct 2013 16:42:29 +0200 Message-ID: <5256BD15.9010905@ericsson.com> Date: Thu, 10 Oct 2013 16:43:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20131010142622.30339.52922.idtracker@ietfa.amsl.com> In-Reply-To: <20131010142622.30339.52922.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre7VPWFBBu9eaFhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGbsfTWYvaJSqOPD8PXMD4ySRLkZODgkBE4m3u56wQthiEhfu rWfrYuTiEBI4zCjx8PtKZghnOaPEzo2TmLoYOTh4BbQlFrxiBGlgEVCVaF52hB3EZhOwkLj5 o5ENxBYVCJZo3/4VzOYVEJQ4OfMJC4gtIqAu0bq5D2yZsICNxKktd8FsIQFHiRmv7oDN5BRw kti15jg7xEGSEtsWHQOzmQX0JKZcbWGEsOUlmrfOZobo1ZZoaOpgncAoOAvJullIWmYhaVnA yLyKkT03MTMnvdxwEyMw/A5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYIxuuVPyVPX6zIq9/NZ2k3gbMxd/2X369df8Pq2zUx7yrW/hOr/LcOFP6eSD n20XR05IO5f0+Z6+W4T2dnbRM9v19r6Tbbt9bsJDgVmns11nHGlclnT2zrunX+N4354p+fTo xcFHN+483aJYHrI2vMYgwtHwQ3o0X9C7sI8Zvx5V/G9kW/mYnStDiaU4I9FQi7moOBEAjR6a uA0CAAA= Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-38.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 Oct 2013 14:42:43 -0000 WG, I have submitted this version of the draft as it contains the following changes: 1. The CSeq text currently being discussed based on Elwyn Davies comment. 2. The proposal for Time format definitions from Peter St Andre and Claudio. 3. Elwyn Davies sent private editorials that has been incorporated. So please provide feedback on these changes. I intended to ask the AD to do an IETF last call on the changes now. During that time the WG can also provide any additional feedback on the changes. Cheers Magnus On 2013-10-10 16:26, 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 : Real Time Streaming Protocol 2.0 (RTSP) > Author(s) : Henning Schulzrinne > Anup Rao > Rob Lanphier > Magnus Westerlund > Martin Stiemerling > Filename : draft-ietf-mmusic-rfc2326bis-38.txt > Pages : 322 > Date : 2013-10-10 > > Abstract: > This memorandum defines RTSP version 2.0 which obsoletes RTSP version > 1.0 defined in RFC 2326. > > The Real Time Streaming Protocol, or RTSP, is an application-level > protocol for setup and control of the delivery of data with real-time > properties. RTSP provides an extensible framework to enable > controlled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 3550). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-38 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-38 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > > -- 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 pkyzivat@alum.mit.edu Thu Oct 10 15:06: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 042DA21E80B0 for ; Thu, 10 Oct 2013 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tId-LUF9YpmF for ; Thu, 10 Oct 2013 15:06:13 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 18D6421E8084 for ; Thu, 10 Oct 2013 15:06:12 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id bP631m00316LCl051a6C06; Thu, 10 Oct 2013 22:06:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ba6C1m00M3ZTu2S3Sa6Cj4; Thu, 10 Oct 2013 22:06:12 +0000 Message-ID: <525724D3.4000404@alum.mit.edu> Date: Thu, 10 Oct 2013 18:06:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5255F537.7080204@nteczone.com> In-Reply-To: <5255F537.7080204@nteczone.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=1381442772; bh=0rcTq+06sFwOKEP49HttOYhAWctKHkjKnzFvLSAylJ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=khw75ORJ0UNlREaT9Dk/aPeATiF45VRQLX0HyQXKhV0qvesBZnFf90LeNgOK2IrLG AI1juSSjZUcODdw8kgeGuFAg0spFNmM5BKKIWSaxTQRaM+IRZbH+NQlz1SlnPme3pj xoe4lceejnIda0fYqM3IqaYdLgGnRfBJTtv14rjIItPIQBuJypCYLracYDaGcndZwm haroCcXK1tf3ChGrXRvxufFtvmpdLnjBAheC8MwP043UfO8jRiRl+QZeOqk0esqIoD vnzp3t4zKN5l+a7SB0FO6NQPvNez906W6Bv3N83elG2odEwB06f8r9+2EJo3LSPz6B Q4tbr9k7dZOhQ== Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 22:06:27 -0000 Christian, In some sense this is not a problem. The constraints apply even though the iana registry doesn't show them. They can be discovered by following the references. But it is annoying and confusing. We have a similar, but worse, problem with the registries for SDP attributes. They come in different types (session, media, and source), and the same attribute can support multiple types. But the registries treat them separately. And the templates used to register them aren't consistent with the registry formats. So I suggested that 4566bis take on updating these IANA registries. In general, all the registries for SDP stuff probably need a good scrubbing. Thanks, Paul On 10/9/13 8:30 PM, Christian Groves wrote: > Isn't this just the manner in which IANA formats their registry? Both > RFC2327 and RFC4566 both have text along the lines of "An address type > is only meaningful in the context of a network type, and any > registration of an address type MUST specify a registered network type, > or be submitted along with a network type registration." > > Given that as part of the registration the applicable nettype must > already have been given. Isn't all we need is for IANA to reflect this > information in another column "Registered network type" in the addrtype > table at SDP parameter registry. > > Type SDP Name Registered Nettype Reference > addrtype IP4 IN [RFC4566] > addrtype IP6 IN [RFC4566] > addrtype E164 PSTN [RFC-ietf-mmusic-sdp-cs-21] > etc. > > > Regards, Christian > > On 10/10/2013 9:46 AM, DRAGE, Keith (Keith) wrote: >> IANA registrations are a set of change requests to IANA to change things. >> >> If the change has already been done, there is probably no absolute >> necessity to repeat them. >> >> As an example, if RFCxxxxbis replaced RFCxxxx and made no new IANA >> registrations issues, it would be perfectly appropriate to refer to >> RFC xxxx has having performed the IANA actions. >> >> Obviously at some point it may be appropriate to document a cumulative >> history, particularly where the IANA instructions are unclear at some >> point. However I would not regard it as the prime focus of RFC 4566bis >> to update the IANA registrations in this regard. >> >> If the need for an IANA registration is clear despite the absence of a >> specific IANA registration section, just request it. Otherwise more >> action is required. >> >> Keith >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>> Of Ali C. Begen (abegen) >>> Sent: 09 October 2013 22:04 >>> To: Flemming Andreasen (fandreas) >>> Cc: ; Paul Kyzivat >>> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis >>> >>> >>> On Oct 9, 2013, at 2:00 PM, Flemming Andreasen >>> wrote: >>> >>>> On 10/7/13 1:51 PM, Paul Kyzivat wrote: >>>>> Changing the topic because I'm hijacking the thread. >>>>> >>>>> On 10/6/13 9:38 PM, Flemming Andreasen wrote: >>>>>> Hi Christian >>>>>> >>>>>> We had a thread on this particular issue about a year ago. See >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>>>> >>>>>> and the conclusion in >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>>> Thanks for remembering! >>>>> >>>>> In that mail I suggested that 4566bis take on updating the format of >>> the IANA registries to reflect the dependency between addrtype and >>> nettype. >>>>> There are also other ways that the iana registries of SDP parameters >>> are deficient. (Notably the registration of att-field names at >>> session/media/source level.) >>>>> How do we go about updating 4566bis to improve the iana registries? >>>> I think we ask Ali to make sure it is covered as part of 4566bis >>> (possibly with some mailing list discussion first if you believe that is >>> needed). If there are specific text suggestions, then all the better. >>> >>> So, in the bis document, we can try to make it clearer but are we >>> supposed >>> to do a whole registry update as well? And certainly, the discussion >>> will >>> be a lot easier with some text proposals... >>> >>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> I hope this addresses your concern as it relates to -cs draft. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>>>> and noticed that there was a registration for addrtype E164 >>>>>>> linked to >>>>>>> this CS draft. >>>>>>> >>>>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>>>> This earlier usage of E164 should have been registered with IANA but >>>>>>> seems to have been missed. To complicate things the format of the >>>>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>>>> >>>>>>> I've already raised this with IANA but I thought it would be worth >>>>>>> mentioning in MMUSIC. >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>> >>>>>>> On 2/07/2013 4:56 AM, The IESG wrote: >>>>>>>> The IESG has approved the following document: >>>>>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio >>> and >>>>>>>> Video Media Streams Over Circuit-Switched Bearers In The Public >>>>>>>> Switched Telephone Network (PSTN)' >>>>>>>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >>>>>>>> >>>>>>>> A URL of this Internet Draft is: >>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Technical Summary >>>>>>>> * >>>>>>>> >>>>>>>> The document 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 Publich Switched Telephone Network (PSTN) >>>>>>>> >>>>>>>> *Working Group Summary >>>>>>>> * >>>>>>>> >>>>>>>> The WG had some discussion around the format to use for E.164 >>> numbers >>>>>>>> and whether to align this with the existing definition in RFC 3108. >>> The >>>>>>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>>>>>> better to align with relevant parts of the tel URI format >>>>>>>> defined in >>> RFC >>>>>>>> 3966, not least since SDP address types are defined in the context >>> of a >>>>>>>> particular network type, and hence RFC 3108 compatibility is not a >>>>>>>> concern (the implication is that the "E164" address type may differ >>>>>>>> between network types in SDP). >>>>>>>> >>>>>>>> *Document Quality >>>>>>>> * >>>>>>>> >>>>>>>> There are currently no known implementations of the draft, however >>> the >>>>>>>> draft is a dependency for 3GPP, so future implementations are >>> expected. >>>>>>>> The document has received good overall review in the WG, some of >>> which >>>>>>>> resulted in changes to the detailed specification. The document has >>> been >>>>>>>> reviewed in detail several times, including of the last few >>>>>>>> versions. >>>>>>>> The major contributors to these as well as earlier discussions are >>>>>>>> listed in the Acknowledgements section of the document. >>>>>>>> >>>>>>>> >>>>>>>> *Personnel >>>>>>>> * >>>>>>>> >>>>>>>> Document Shepherd: Flemming Andreasen >>>>>>>> Responsible AD: Gonzalo Camarillo >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> . >>>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> . >>>>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Thu Oct 10 15:12: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 E4CA021E8132 for ; Thu, 10 Oct 2013 15:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X8r2OIDQ7qs for ; Thu, 10 Oct 2013 15:12:09 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 6126B21E8084 for ; Thu, 10 Oct 2013 15:12:08 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id ba4H1m0021ZXKqc5DaC8gZ; Thu, 10 Oct 2013 22:12:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id baC71m0193ZTu2S3haC7DJ; Thu, 10 Oct 2013 22:12:08 +0000 Message-ID: <52572636.1090702@alum.mit.edu> Date: Thu, 10 Oct 2013 18:12:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.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=1381443128; bh=qLwC/2lFmL4p74RKRv67sZ8uYKjC5QRo5ni8lplDzXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UDwZp2V6h/DPKT2CkvP7dPNm6MELMBJTMbh6ivz0IlpCb7YV8JZpNi8iq59S+TWhC Va2ewwLM8CQ82cVh1jVwgFgH96ZDNihGXqLb9xGQCYlg/VVV3GVriqNCvvHOrjA+Du vPMUmEn+bpe14SD8eGN4RgNuFROOYp9uz5hSuLrTctqqaaP2ANC0wNiJfVf/O05R/t zbAeXmZP1T86kz4AapNjGsKBlsBa1xPYd0xsYnoy5rqEDtzFszV3ja0Lo2FxPEY7CT Dg2sW95mO7J/IpfCHBV7IIH6wmhDoENi1j6T1N2kkwK8JJlIIwRxfjO485C1nnQK/a r5QbVXZHDrfkw== Cc: "Flemming Andreasen \(fandreas\)" , "" Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 22:12:14 -0000 On 10/9/13 6:46 PM, DRAGE, Keith (Keith) wrote: > IANA registrations are a set of change requests to IANA to change things. > > If the change has already been done, there is probably no absolute necessity to repeat them. > > As an example, if RFCxxxxbis replaced RFCxxxx and made no new IANA registrations issues, it would be perfectly appropriate to refer to RFC xxxx has having performed the IANA actions. > > Obviously at some point it may be appropriate to document a cumulative history, particularly where the IANA instructions are unclear at some point. However I would not regard it as the prime focus of RFC 4566bis to update the IANA registrations in this regard. Certainly it is not the primary purpose of 4566bis. But if it isn't done there, then we will need yet another RFC to do it. 4566bis seems like a good place to do it. > If the need for an IANA registration is clear despite the absence of a specific IANA registration section, just request it. Otherwise more action is required. Just request it *how*? If IANA receives an email asking them to make a change, they won't be doing their job unless they consult the existing registry and check the rules for changes/additions. If the rules call for an rfc and a specific template, then they need an rfc with that template filled out. Note that these templates often carry information that isn't captured in the registry itself - depending on the registry reference to the document. Thanks, Paul > Keith > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Ali C. Begen (abegen) >> Sent: 09 October 2013 22:04 >> To: Flemming Andreasen (fandreas) >> Cc: ; Paul Kyzivat >> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis >> >> >> On Oct 9, 2013, at 2:00 PM, Flemming Andreasen wrote: >> >>> >>> On 10/7/13 1:51 PM, Paul Kyzivat wrote: >>>> Changing the topic because I'm hijacking the thread. >>>> >>>> On 10/6/13 9:38 PM, Flemming Andreasen wrote: >>>>> Hi Christian >>>>> >>>>> We had a thread on this particular issue about a year ago. See >>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>>> >>>>> and the conclusion in >>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>> >>>> Thanks for remembering! >>>> >>>> In that mail I suggested that 4566bis take on updating the format of >> the IANA registries to reflect the dependency between addrtype and nettype. >>>> >>>> There are also other ways that the iana registries of SDP parameters >> are deficient. (Notably the registration of att-field names at >> session/media/source level.) >>>> >>>> How do we go about updating 4566bis to improve the iana registries? >>> >>> I think we ask Ali to make sure it is covered as part of 4566bis >> (possibly with some mailing list discussion first if you believe that is >> needed). If there are specific text suggestions, then all the better. >> >> So, in the bis document, we can try to make it clearer but are we supposed >> to do a whole registry update as well? And certainly, the discussion will >> be a lot easier with some text proposals... >> >> >>> >>> Thanks >>> >>> -- Flemming >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> I hope this addresses your concern as it relates to -cs draft. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>>> and noticed that there was a registration for addrtype E164 linked to >>>>>> this CS draft. >>>>>> >>>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>>> This earlier usage of E164 should have been registered with IANA but >>>>>> seems to have been missed. To complicate things the format of the >>>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>>> >>>>>> I've already raised this with IANA but I thought it would be worth >>>>>> mentioning in MMUSIC. >>>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> On 2/07/2013 4:56 AM, The IESG wrote: >>>>>>> The IESG has approved the following document: >>>>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio >> and >>>>>>> Video Media Streams Over Circuit-Switched Bearers In The Public >>>>>>> Switched Telephone Network (PSTN)' >>>>>>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >>>>>>> >>>>>>> A URL of this Internet Draft is: >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Technical Summary >>>>>>> * >>>>>>> >>>>>>> The document 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 Publich Switched Telephone Network (PSTN) >>>>>>> >>>>>>> *Working Group Summary >>>>>>> * >>>>>>> >>>>>>> The WG had some discussion around the format to use for E.164 >> numbers >>>>>>> and whether to align this with the existing definition in RFC 3108. >> The >>>>>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>>>>> better to align with relevant parts of the tel URI format defined in >> RFC >>>>>>> 3966, not least since SDP address types are defined in the context >> of a >>>>>>> particular network type, and hence RFC 3108 compatibility is not a >>>>>>> concern (the implication is that the "E164" address type may differ >>>>>>> between network types in SDP). >>>>>>> >>>>>>> *Document Quality >>>>>>> * >>>>>>> >>>>>>> There are currently no known implementations of the draft, however >> the >>>>>>> draft is a dependency for 3GPP, so future implementations are >> expected. >>>>>>> >>>>>>> The document has received good overall review in the WG, some of >> which >>>>>>> resulted in changes to the detailed specification. The document has >> been >>>>>>> reviewed in detail several times, including of the last few versions. >>>>>>> The major contributors to these as well as earlier discussions are >>>>>>> listed in the Acknowledgements section of the document. >>>>>>> >>>>>>> >>>>>>> *Personnel >>>>>>> * >>>>>>> >>>>>>> Document Shepherd: Flemming Andreasen >>>>>>> Responsible AD: Gonzalo Camarillo >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> . >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Thu Oct 10 15:13:56 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 E67D921E8139 for ; Thu, 10 Oct 2013 15:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tErYL3R4T-NH for ; Thu, 10 Oct 2013 15:13:52 -0700 (PDT) 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 3DA1121E8132 for ; Thu, 10 Oct 2013 15:13:50 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id bXAx1m00316LCl054aDpPf; Thu, 10 Oct 2013 22:13:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id baDp1m00U3ZTu2S3SaDpVR; Thu, 10 Oct 2013 22:13:49 +0000 Message-ID: <5257269D.6080600@alum.mit.edu> Date: Thu, 10 Oct 2013 18:13:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.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=1381443229; bh=AE+X28dqdWscbyi2w9da+cyYOb9ApuEW4abTEFyRWgY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Cenf55Cvb3n5qMMlasv4qXHR6HuvR5+Cwx98jfNaeZ87rt3om3d+nIydvlp+AaDj6 CoggJmoJzv/gEe9s4wBCSChGLFnSZ1vvmXqcCIr6o69234/AYf9LYcV7I3nY44R1Ry wLuZIM8eDDdwuIBni0YjL2hQHGteIYqLW6GztAS+Pq7BFD8MYG5uOW22T7a4aCPthb BR2Q0iBM8ZDLEdk8Uvvy6/B2jzCIRSe5I2vVG7P78nUdNQQ8Cv74EZN1Pki4+fX3zr ATeL0Q7VYRHjXS6LE/CRcWHm9adNvk4Ug535hB9pfkH/LowqAeRhh4EUJu1rtDyxcC dGxKF452OnP9A== Cc: Flemming Andreasen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 22:13:57 -0000 On 10/9/13 6:47 PM, DRAGE, Keith (Keith) wrote: > We don't need an RFC to do it. We existed for years without an IANA registration section but still had IANA registrations. > > My understanding of the current rule is that they need to exist, and give instructions on how to write them. This is to make their job easier and their output more efficient. There is nothing that says that IANA cannot address issues regarding missing material from reading the rest of the RFC. After all, the entire RFC has IETF consensus. Repeating what I just posted in another thread: Just request it *how*? If IANA receives an email asking them to make a change, they won't be doing their job unless they consult the existing registry and check the rules for changes/additions. If the rules call for an rfc and a specific template, then they need an rfc with that template filled out. Note that these templates often carry information that isn't captured in the registry itself - depending on the registry reference to the document. Thanks, Paul > Keith > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 09 October 2013 23:29 >> To: Flemming Andreasen >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values >> >> On 10/9/13 4:59 PM, Flemming Andreasen wrote: >>> >>> On 10/9/13 12:19 PM, Paul Kyzivat wrote: >>>> On 10/7/13 6:46 PM, Christian Groves wrote: >>>>> Hello Paul, >>>>> >>>>> Is a process needed to create an errata? Wouldn't the fact that they >>>>> appear in standards track RFCs be enough to include them in the SDP >>>>> registry based on the SDP directorates (i.e. expert review) >>>>> recommendation? I agree its not ideal that these older RFCs didn't >>>>> include an IANA considerations section but I think that rather than >>>>> spending lots of cycles on this that the SDP directorate could just >>>>> request IANA to register them to avoid any future overlap issues. >>>> >>>> Unfortunately there are rules. The rules for a particular IANA >>>> registry are defined when the registry is created. If you check in the >>>> registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that >>>> additions to this registry must follow the "Specification Required" >>>> policy defined in RFC2434. And the specification must include a >>>> particular set of information. (That would typically be in an IANA >>>> considerations section.) >>>> >>>> At the moment all we have is RFC3108, and it doesn't have an IANA >>>> considerations section at all. It certainly doesn't give the info >>>> needed for an addition to that registry. >>>> >>>> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I >>>> think we will need a new RFC that does it. This should probably be an >>>> update to 3108. An errata is perhaps a formal way to trigger that. >>>> >>> Having previously communicated with one of the RFC 3108 authors on this, >>> I would ask for leniency here, not least considering that RFC 3108 >>> predates RFC 4566. In other words, I'd argue that we should simply add >>> the missing registrations. >> >> I wasn't trying to be pejorative - just commenting on what seems >> required to fix it. >> >> We just need *some* RFC to do it. It could be 4566bis. But if it isn't >> one that explicitly updates 3108, then we should take care to instruct >> IANA to make the registry point to 3108. >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From Christian.Groves@nteczone.com Thu Oct 10 17:17: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 5D96E21F8FDC for ; Thu, 10 Oct 2013 17:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+1Gqcrd4LE6 for ; Thu, 10 Oct 2013 17:17:41 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id C888621F99F8 for ; Thu, 10 Oct 2013 17:17:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBANhCV1J20Xsy/2dsb2JhbAANTIM/wU9LgTaDGQEBAQMBAQEBGhsbGAMKBgcECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYd8EqZ0HJMqBI1+gVAGhB0DrT+BXQ Received: from ppp118-209-123-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.50]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2013 10:47:37 +1030 Message-ID: <52574393.7010504@nteczone.com> Date: Fri, 11 Oct 2013 11:17:23 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu> In-Reply-To: <5257269D.6080600@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 00:17:42 -0000 Hello Paul, On 11/10/2013 9:13 AM, Paul Kyzivat wrote: > On 10/9/13 6:47 PM, DRAGE, Keith (Keith) wrote: >> We don't need an RFC to do it. We existed for years without an IANA >> registration section but still had IANA registrations. >> >> My understanding of the current rule is that they need to exist, and >> give instructions on how to write them. This is to make their job >> easier and their output more efficient. There is nothing that says >> that IANA cannot address issues regarding missing material from >> reading the rest of the RFC. After all, the entire RFC has IETF >> consensus. > > Repeating what I just posted in another thread: > > Just request it *how*? [CNG] Email? Surely if one of the MMUSIC chairs sends an email highlighting the situation that the original registrations were missed and point to the agreed standards tracks RFCs this can be considered. IANA works with experts all the time to manage these pages. If I find an error in the registry I'm responsible for its just a matter of sending an email indicating what the issue is. > If IANA receives an email asking them to make a change, they won't be > doing their job unless they consult the existing registry and check > the rules for changes/additions. If the rules call for an rfc and a > specific template, then they need an rfc with that template filled out. [CNG] I think we need to recognise that what we are trying to do is fix an error not do a brand new registration. > Note that these templates often carry information that isn't captured > in the registry itself - depending on the registry reference to the > document. > > Thanks, > Paul > >> Keith >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf >>> Of Paul Kyzivat >>> Sent: 09 October 2013 23:29 >>> To: Flemming Andreasen >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 >>> values >>> >>> On 10/9/13 4:59 PM, Flemming Andreasen wrote: >>>> >>>> On 10/9/13 12:19 PM, Paul Kyzivat wrote: >>>>> On 10/7/13 6:46 PM, Christian Groves wrote: >>>>>> Hello Paul, >>>>>> >>>>>> Is a process needed to create an errata? Wouldn't the fact that they >>>>>> appear in standards track RFCs be enough to include them in the SDP >>>>>> registry based on the SDP directorates (i.e. expert review) >>>>>> recommendation? I agree its not ideal that these older RFCs didn't >>>>>> include an IANA considerations section but I think that rather than >>>>>> spending lots of cycles on this that the SDP directorate could just >>>>>> request IANA to register them to avoid any future overlap issues. >>>>> >>>>> Unfortunately there are rules. The rules for a particular IANA >>>>> registry are defined when the registry is created. If you check in >>>>> the >>>>> registry, it points to RFC4566. Section 8.2.4 of RFC4566 says that >>>>> additions to this registry must follow the "Specification Required" >>>>> policy defined in RFC2434. And the specification must include a >>>>> particular set of information. (That would typically be in an IANA >>>>> considerations section.) >>>>> >>>>> At the moment all we have is RFC3108, and it doesn't have an IANA >>>>> considerations section at all. It certainly doesn't give the info >>>>> needed for an addition to that registry. >>>>> >>>>> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I >>>>> think we will need a new RFC that does it. This should probably be an >>>>> update to 3108. An errata is perhaps a formal way to trigger that. >>>>> >>>> Having previously communicated with one of the RFC 3108 authors on >>>> this, >>>> I would ask for leniency here, not least considering that RFC 3108 >>>> predates RFC 4566. In other words, I'd argue that we should simply add >>>> the missing registrations. >>> >>> I wasn't trying to be pejorative - just commenting on what seems >>> required to fix it. >>> >>> We just need *some* RFC to do it. It could be 4566bis. But if it isn't >>> one that explicitly updates 3108, then we should take care to instruct >>> IANA to make the registry point to 3108. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> 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 keith.drage@alcatel-lucent.com Thu Oct 10 23:36: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 23F0521F9FF3 for ; Thu, 10 Oct 2013 23:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkm8APk-zvZj for ; Thu, 10 Oct 2013 23:35:54 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A73B921F9EAF for ; Thu, 10 Oct 2013 23:35:54 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9B6ZmqO002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Oct 2013 01:35:49 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9B6ZkBk022684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 08:35:46 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 11 Oct 2013 08:35:46 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Thread-Topic: [MMUSIC] Updating SDP parameter registry with RFC3108 values Thread-Index: AQHOxQuw3vE+5VfpPkSFvZv7z22ypZnugeoAgACFhgA= Date: Fri, 11 Oct 2013 06:35:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu> In-Reply-To: <5257269D.6080600@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Flemming Andreasen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 06:36:00 -0000 In regard to "how" just write an email or fill out the form on the IANA mai= n page. And it works in exactly the same way as when the material exists in the IAN= A considerations section but has not been correctly implemented by IANA. We= don't have to go and write a new RFC in that case. The IANA sections of RFCs are there to provide a convenient means for IANA = to find the information they need, not the arbiter of whether the informati= on can be included in a registry or not. The arbiter of whether the information can be included in the registry or n= ot is the registration policy of that registry. Even if the registration po= licy is RFC required, if it is somewhere else in the RFC, then IANA can sti= ll use that information. Regardless, all of this will take place in conjunc= tion with the appropriate experts to ensure that a mistake does not occur. = IANA consult on anything they are not sure of. As for formatting of the information - we help them as much as possible wit= h the IANA considerations section, but that is all it is "considerations". = IANA have total flexibility in this area. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 10 October 2013 23:14 > To: DRAGE, Keith (Keith) > Cc: Flemming Andreasen; mmusic@ietf.org > Subject: Re: [MMUSIC] Updating SDP parameter registry with=20 > RFC3108 values >=20 > On 10/9/13 6:47 PM, DRAGE, Keith (Keith) wrote: > > We don't need an RFC to do it. We existed for years without=20 > an IANA registration section but still had IANA registrations. > > > > My understanding of the current rule is that they need to=20 > exist, and give instructions on how to write them. This is to=20 > make their job easier and their output more efficient. There=20 > is nothing that says that IANA cannot address issues=20 > regarding missing material from reading the rest of the RFC.=20 > After all, the entire RFC has IETF consensus. >=20 > Repeating what I just posted in another thread: >=20 > Just request it *how*? > If IANA receives an email asking them to make a change, they=20 > won't be doing their job unless they consult the existing=20 > registry and check the rules for changes/additions. If the=20 > rules call for an rfc and a specific template, then they need=20 > an rfc with that template filled out. >=20 > Note that these templates often carry information that isn't=20 > captured in the registry itself - depending on the registry=20 > reference to the document. >=20 > Thanks, > Paul >=20 > > Keith > > > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > >> Behalf Of Paul Kyzivat > >> Sent: 09 October 2013 23:29 > >> To: Flemming Andreasen > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108=20 > >> values > >> > >> On 10/9/13 4:59 PM, Flemming Andreasen wrote: > >>> > >>> On 10/9/13 12:19 PM, Paul Kyzivat wrote: > >>>> On 10/7/13 6:46 PM, Christian Groves wrote: > >>>>> Hello Paul, > >>>>> > >>>>> Is a process needed to create an errata? Wouldn't the fact that=20 > >>>>> they appear in standards track RFCs be enough to=20 > include them in=20 > >>>>> the SDP registry based on the SDP directorates (i.e. expert=20 > >>>>> review) recommendation? I agree its not ideal that these older=20 > >>>>> RFCs didn't include an IANA considerations section but I think=20 > >>>>> that rather than spending lots of cycles on this that the SDP=20 > >>>>> directorate could just request IANA to register them to=20 > avoid any future overlap issues. > >>>> > >>>> Unfortunately there are rules. The rules for a particular IANA=20 > >>>> registry are defined when the registry is created. If=20 > you check in=20 > >>>> the registry, it points to RFC4566. Section 8.2.4 of=20 > RFC4566 says=20 > >>>> that additions to this registry must follow the=20 > "Specification Required" > >>>> policy defined in RFC2434. And the specification must include a=20 > >>>> particular set of information. (That would typically be=20 > in an IANA=20 > >>>> considerations section.) > >>>> > >>>> At the moment all we have is RFC3108, and it doesn't=20 > have an IANA=20 > >>>> considerations section at all. It certainly doesn't give=20 > the info=20 > >>>> needed for an addition to that registry. > >>>> > >>>> IIUC, an errata to 3108 wouldn't, on its own, be=20 > sufficient either.=20 > >>>> I think we will need a new RFC that does it. This should=20 > probably=20 > >>>> be an update to 3108. An errata is perhaps a formal way=20 > to trigger that. > >>>> > >>> Having previously communicated with one of the RFC 3108=20 > authors on=20 > >>> this, I would ask for leniency here, not least=20 > considering that RFC=20 > >>> 3108 predates RFC 4566. In other words, I'd argue that we should=20 > >>> simply add the missing registrations. > >> > >> I wasn't trying to be pejorative - just commenting on what seems=20 > >> required to fix it. > >> > >> We just need *some* RFC to do it. It could be 4566bis. But if it=20 > >> isn't one that explicitly updates 3108, then we should=20 > take care to=20 > >> instruct IANA to make the registry point to 3108. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > = From ari.keranen@ericsson.com Fri Oct 11 00:59: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 9FDD121E815C for ; Fri, 11 Oct 2013 00:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAdd5xSORmxc for ; Fri, 11 Oct 2013 00:58:56 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E83B11E8138 for ; Fri, 11 Oct 2013 00:58:55 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-6a-5257afbe3df4 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 26.1B.03802.EBFA7525; Fri, 11 Oct 2013 09:58:54 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.328.9; Fri, 11 Oct 2013 09:58:44 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 873551103C1 for ; Fri, 11 Oct 2013 10:58:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8F3BA56433 for ; Fri, 11 Oct 2013 10:58:36 +0300 (EEST) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 501555363C for ; Fri, 11 Oct 2013 10:58:36 +0300 (EEST) Message-ID: <5257AFB3.7050109@ericsson.com> Date: Fri, 11 Oct 2013 10:58:43 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic References: <5257A241.7060607@ericsson.com> In-Reply-To: <5257A241.7060607@ericsson.com> X-Forwarded-Message-Id: <5257A241.7060607@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvre6+9eFBBreWSVpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGfseLmIsOKdf0XO7voHxuVoXIyeHhICJxI/OqywQtpjEhXvr 2UBsIYHDjBL/W8y6GLmA7A2MEicnPmCHSFxmlPhzxxEicYRRYuFrkG4QZx+jxJdXW8HaeQW0 JZbt+84IYrMIqEpMmLyECcRmE7CXuDnhOtgkUYFkib1LTzND1AtKnJz5BOwMEQEZib2bNoPF hQXiJM4/e84EsVlb4u6zuWA1nAI6Eit272CEONtc4sidbWB7mQVsJS7Muc4CYctLbH87hxmi Rk3i6rlNzBBzVCWu/nvFOIFRdBaS1bOQtM9C0r6AkXkVI3tuYmZOernRJkZggB/c8lt1B+Od cyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMi78uaDKYJfNvEmCmxu OGTvkPfZZda7U0+sb4WI588xc9L9Z/vPinHl8ueKc146O/Bo7Xr8U6mtz1pVw5J1AnPw8gkX Puf7bMmP/mRSyn2t96EVyxVX9UdTNjf/nOM89xXjypDa0K0dFgck7+4zsggOCs/yvCdefjF6 4qUDE68ePFWVmJ7z4Z4SS3FGoqEWc1FxIgAh22m+PgIAAA== Subject: [MMUSIC] Fwd: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV 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 Oct 2013 07:59:01 -0000 FYI, more volunteers for IETF leadership positions are needed. Cheers, Ari -------- Original Message -------- Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Fri, 11 Oct 2013 09:44:23 +0300 From: Gonzalo Camarillo To: Folks, we need more volunteers (see email below). If you are thinking of running but still have some doubts about it, feel free to talk with me (or with any of the former RAI ADs) and we will be happy to clarify everything for you. Cheers, Gonzalo -------- Original Message -------- Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Tue, 8 Oct 2013 11:45:14 -0700 From: NomCom Chair Reply-To: To: IETF Announcement List CC: UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From fandreas@cisco.com Fri Oct 11 07:47:51 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 EEC7721F9CF1 for ; Fri, 11 Oct 2013 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgX6sNcNOJlR for ; Fri, 11 Oct 2013 07:47:47 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD6021F9B4B for ; Fri, 11 Oct 2013 07:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8910; q=dns/txt; s=iport; t=1381502865; x=1382712465; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XcXQD6OC7u82BEo6kSbY5azivky+QiqedNxE1Y4rzhw=; b=FIrKq2RHw5YkOHK2CkZv9l+SKYnkr4KTgFrHQ/NKzjIIm6YOuQECVzV+ oBIsKdN0k1/7sTlXnmwHfFzMJgcCZ2sQst4zVSf+76mTwbbc6L5uUz1RN N3/Cp7mRZvcP7mmZy/d4p6VunlxS8zqipY1x0/+nVMsmaW3YvrVCFAbgE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4MAIwOWFKtJXHB/2dsb2JhbABZgwc4rUQDlBBLgSMWdIIlAQEBBAEBATU2CgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAQWHfQy7Fo4OgTkHBoQdA5gFgS+QU4NAIIE1 X-IronPort-AV: E=Sophos;i="4.90,1081,1371081600"; d="scan'208";a="271000328" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 11 Oct 2013 14:47:43 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9BElgSr021587; Fri, 11 Oct 2013 14:47:42 GMT Message-ID: <52580F8F.2000903@cisco.com> Date: Fri, 11 Oct 2013 10:47:43 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christian Groves References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5255F537.7080204@nteczone.com> In-Reply-To: <5255F537.7080204@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rai-ads , mmusic@ietf.org Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis 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 Oct 2013 14:47:52 -0000 The chairs are basically working with the ADs and IANA to make such a change and to register the missing nettype and addrtype from RFC 2848 (PINT) and 3108 (ATM). My understanding is that it's not a problem to fix these with IANA, unless anybody in the WG has an issue with doing so (in which case you should let us know). Thanks -- Flemming On 10/9/13 8:30 PM, Christian Groves wrote: > Isn't this just the manner in which IANA formats their registry? Both > RFC2327 and RFC4566 both have text along the lines of "An address type > is only meaningful in the context of a network type, and any > registration of an address type MUST specify a registered network > type, or be submitted along with a network type registration." > > Given that as part of the registration the applicable nettype must > already have been given. Isn't all we need is for IANA to reflect this > information in another column "Registered network type" in the > addrtype table at SDP parameter registry. > > Type SDP Name Registered Nettype Reference > addrtype IP4 IN [RFC4566] > addrtype IP6 IN [RFC4566] > addrtype E164 PSTN [RFC-ietf-mmusic-sdp-cs-21] > etc. > > > Regards, Christian > > On 10/10/2013 9:46 AM, DRAGE, Keith (Keith) wrote: >> IANA registrations are a set of change requests to IANA to change >> things. >> >> If the change has already been done, there is probably no absolute >> necessity to repeat them. >> >> As an example, if RFCxxxxbis replaced RFCxxxx and made no new IANA >> registrations issues, it would be perfectly appropriate to refer to >> RFC xxxx has having performed the IANA actions. >> >> Obviously at some point it may be appropriate to document a >> cumulative history, particularly where the IANA instructions are >> unclear at some point. However I would not regard it as the prime >> focus of RFC 4566bis to update the IANA registrations in this regard. >> >> If the need for an IANA registration is clear despite the absence of >> a specific IANA registration section, just request it. Otherwise more >> action is required. >> >> Keith >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf >>> Of Ali C. Begen (abegen) >>> Sent: 09 October 2013 22:04 >>> To: Flemming Andreasen (fandreas) >>> Cc: ; Paul Kyzivat >>> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis >>> >>> >>> On Oct 9, 2013, at 2:00 PM, Flemming Andreasen >>> wrote: >>> >>>> On 10/7/13 1:51 PM, Paul Kyzivat wrote: >>>>> Changing the topic because I'm hijacking the thread. >>>>> >>>>> On 10/6/13 9:38 PM, Flemming Andreasen wrote: >>>>>> Hi Christian >>>>>> >>>>>> We had a thread on this particular issue about a year ago. See >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html >>>>>> >>>>>> and the conclusion in >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html >>>>> Thanks for remembering! >>>>> >>>>> In that mail I suggested that 4566bis take on updating the format of >>> the IANA registries to reflect the dependency between addrtype and >>> nettype. >>>>> There are also other ways that the iana registries of SDP parameters >>> are deficient. (Notably the registration of att-field names at >>> session/media/source level.) >>>>> How do we go about updating 4566bis to improve the iana registries? >>>> I think we ask Ali to make sure it is covered as part of 4566bis >>> (possibly with some mailing list discussion first if you believe >>> that is >>> needed). If there are specific text suggestions, then all the better. >>> >>> So, in the bis document, we can try to make it clearer but are we >>> supposed >>> to do a whole registry update as well? And certainly, the discussion >>> will >>> be a lot easier with some text proposals... >>> >>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> I hope this addresses your concern as it relates to -cs draft. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> On 9/19/13 8:22 AM, Christian Groves wrote: >>>>>>> FYI, I was looking at the IANA registry for SDP parameters ( >>>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) >>>>>>> >>>>>>> and noticed that there was a registration for addrtype E164 >>>>>>> linked to >>>>>>> this CS draft. >>>>>>> >>>>>>> There's a problem that there's already an addrtype E164 in RFC3108. >>>>>>> This earlier usage of E164 should have been registered with IANA >>>>>>> but >>>>>>> seems to have been missed. To complicate things the format of the >>>>>>> RFC3108 E164 addrtype is different to the one in the CS draft. >>>>>>> >>>>>>> I've already raised this with IANA but I thought it would be worth >>>>>>> mentioning in MMUSIC. >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>> >>>>>>> On 2/07/2013 4:56 AM, The IESG wrote: >>>>>>>> The IESG has approved the following document: >>>>>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio >>> and >>>>>>>> Video Media Streams Over Circuit-Switched Bearers In The >>>>>>>> Public >>>>>>>> Switched Telephone Network (PSTN)' >>>>>>>> (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes. >>>>>>>> >>>>>>>> A URL of this Internet Draft is: >>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Technical Summary >>>>>>>> * >>>>>>>> >>>>>>>> The document 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 Publich Switched Telephone Network (PSTN) >>>>>>>> >>>>>>>> *Working Group Summary >>>>>>>> * >>>>>>>> >>>>>>>> The WG had some discussion around the format to use for E.164 >>> numbers >>>>>>>> and whether to align this with the existing definition in RFC >>>>>>>> 3108. >>> The >>>>>>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>>>>>> better to align with relevant parts of the tel URI format >>>>>>>> defined in >>> RFC >>>>>>>> 3966, not least since SDP address types are defined in the context >>> of a >>>>>>>> particular network type, and hence RFC 3108 compatibility is not a >>>>>>>> concern (the implication is that the "E164" address type may >>>>>>>> differ >>>>>>>> between network types in SDP). >>>>>>>> >>>>>>>> *Document Quality >>>>>>>> * >>>>>>>> >>>>>>>> There are currently no known implementations of the draft, however >>> the >>>>>>>> draft is a dependency for 3GPP, so future implementations are >>> expected. >>>>>>>> The document has received good overall review in the WG, some of >>> which >>>>>>>> resulted in changes to the detailed specification. The document >>>>>>>> has >>> been >>>>>>>> reviewed in detail several times, including of the last few >>>>>>>> versions. >>>>>>>> The major contributors to these as well as earlier discussions are >>>>>>>> listed in the Acknowledgements section of the document. >>>>>>>> >>>>>>>> >>>>>>>> *Personnel >>>>>>>> * >>>>>>>> >>>>>>>> Document Shepherd: Flemming Andreasen >>>>>>>> Responsible AD: Gonzalo Camarillo >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> . >>>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> . >>>>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From iesg-secretary@ietf.org Fri Oct 11 09:16: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 6FFD411E822B; Fri, 11 Oct 2013 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W8tvKQ7e4iN; Fri, 11 Oct 2013 09:16:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831311E820C; Fri, 11 Oct 2013 09:16:00 -0700 (PDT) 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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131011161559.4968.64237.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 09:15:59 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (Real Time Streaming Protocol 2.0 (RTSP)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 16:16:00 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Real Time Streaming Protocol 2.0 (RTSP)' 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-10-25. 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 memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2028/ http://datatracker.ietf.org/ipr/1189/ From pkyzivat@alum.mit.edu Fri Oct 11 09:49: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 1AB3B11E8212 for ; Fri, 11 Oct 2013 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I9AORfODZ+W for ; Fri, 11 Oct 2013 09:49:40 -0700 (PDT) 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 52B3E11E81D5 for ; Fri, 11 Oct 2013 09:49:34 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id bo4T1m0021GhbT851spQbw; Fri, 11 Oct 2013 16:49:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id bspP1m00t3ZTu2S3TspQEL; Fri, 11 Oct 2013 16:49:24 +0000 Message-ID: <52582C13.70906@alum.mit.edu> Date: Fri, 11 Oct 2013 12:49:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.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=1381510164; bh=5JqSafpnXjLQQ96THLEC/ZvAqI7rhHaB0sIoox9S+pA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VOlfKONfqcUIX0BXabfJbE3fUww0Hp/rByeUgRZDtbfuCZRPQ8xv43CBWmHqyhloW YvwpNxTqC+fjJYlL3A+Xf/iPBR5LS/i7AbeZ9Nk/bE7uNOvWCB4fTxmredIefRemrB i7vZL+OwgrlG5xCyGBTHoHdieWYkcPL6hwgl1j9e6gkyY8SZtxYovdm1ccOw962jiW UaNPikQZ48MhCrRxCtH3sEfcGB1xdEN49JYkNmJPXA26tg7tU+OoB1UJVcOlazOPPA eb7tlz96KrXyVlvFukL8d8+i+uMSlCZ0+FXw+NEXJJ0wcSFfKSv4vvzYE4kyrqNBDp UKPeW/y70kkgA== Cc: Flemming Andreasen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 16:49:45 -0000 On 10/11/13 2:35 AM, DRAGE, Keith (Keith) wrote: > In regard to "how" just write an email or fill out the form on the IANA main page. > > And it works in exactly the same way as when the material exists in the IANA considerations section but has not been correctly implemented by IANA. We don't have to go and write a new RFC in that case. > > The IANA sections of RFCs are there to provide a convenient means for IANA to find the information they need, not the arbiter of whether the information can be included in a registry or not. > > The arbiter of whether the information can be included in the registry or not is the registration policy of that registry. Even if the registration policy is RFC required, if it is somewhere else in the RFC, then IANA can still use that information. Regardless, all of this will take place in conjunction with the appropriate experts to ensure that a mistake does not occur. IANA consult on anything they are not sure of. Note that 4566 says that registrations nettype, addrtype, ... contain: o contact name, email address, and telephone number o name being registered (as it will appear in SDP) o long-form name in English o type of name ("media", "proto", "fmt", "bwtype", "nettype", or "addrtype") o a one-paragraph explanation of the purpose of the registered name o a reference to the specification for the registered name (this will typically be an RFC number) But the actual registries don't contain all this information. They depend upon the referenced RFC to contain it. If the RFC doesn't contain all this information, then an after the fact registration is incomplete. In this case, the only questionable piece is the contact. Perhaps it is sufficient to consider the author info in the RFC to substitute for this. (This contact info is at best dubious. It tends to get stale before anybody needs it.) > As for formatting of the information - we help them as much as possible with the IANA considerations section, but that is all it is "considerations". IANA have total flexibility in this area. Do they? If IANA considerations request creation of two registries named X & Y, and lists the fields to be included in each, is IANA free to create one combined registry named XY? I really don't know. I understand that the IANA registries started out as very informal things. As we get more of them, and depend upon them more, it becomes important to get more formal about the way they are handled. That has happened, to an extent. But not uniformly. It is good if we can clean things up as we discover past informality or evolution has made things troublesome. I must say that I am troubled that 4566 does not make the registration of new network or address types mandatory. ("New network(address) types ... *may* be registered with IANA") The current situation almost tripped over this. If new ones aren't registered, then how is someone who wants to define a new one to know if the chosen name is already taken. Thanks, Paul > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 10 October 2013 23:14 >> To: DRAGE, Keith (Keith) >> Cc: Flemming Andreasen; mmusic@ietf.org >> Subject: Re: [MMUSIC] Updating SDP parameter registry with >> RFC3108 values >> >> On 10/9/13 6:47 PM, DRAGE, Keith (Keith) wrote: >>> We don't need an RFC to do it. We existed for years without >> an IANA registration section but still had IANA registrations. >>> >>> My understanding of the current rule is that they need to >> exist, and give instructions on how to write them. This is to >> make their job easier and their output more efficient. There >> is nothing that says that IANA cannot address issues >> regarding missing material from reading the rest of the RFC. >> After all, the entire RFC has IETF consensus. >> >> Repeating what I just posted in another thread: >> >> Just request it *how*? >> If IANA receives an email asking them to make a change, they >> won't be doing their job unless they consult the existing >> registry and check the rules for changes/additions. If the >> rules call for an rfc and a specific template, then they need >> an rfc with that template filled out. >> >> Note that these templates often carry information that isn't >> captured in the registry itself - depending on the registry >> reference to the document. >> >> Thanks, >> Paul >> >>> Keith >>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: 09 October 2013 23:29 >>>> To: Flemming Andreasen >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 >>>> values >>>> >>>> On 10/9/13 4:59 PM, Flemming Andreasen wrote: >>>>> >>>>> On 10/9/13 12:19 PM, Paul Kyzivat wrote: >>>>>> On 10/7/13 6:46 PM, Christian Groves wrote: >>>>>>> Hello Paul, >>>>>>> >>>>>>> Is a process needed to create an errata? Wouldn't the fact that >>>>>>> they appear in standards track RFCs be enough to >> include them in >>>>>>> the SDP registry based on the SDP directorates (i.e. expert >>>>>>> review) recommendation? I agree its not ideal that these older >>>>>>> RFCs didn't include an IANA considerations section but I think >>>>>>> that rather than spending lots of cycles on this that the SDP >>>>>>> directorate could just request IANA to register them to >> avoid any future overlap issues. >>>>>> >>>>>> Unfortunately there are rules. The rules for a particular IANA >>>>>> registry are defined when the registry is created. If >> you check in >>>>>> the registry, it points to RFC4566. Section 8.2.4 of >> RFC4566 says >>>>>> that additions to this registry must follow the >> "Specification Required" >>>>>> policy defined in RFC2434. And the specification must include a >>>>>> particular set of information. (That would typically be >> in an IANA >>>>>> considerations section.) >>>>>> >>>>>> At the moment all we have is RFC3108, and it doesn't >> have an IANA >>>>>> considerations section at all. It certainly doesn't give >> the info >>>>>> needed for an addition to that registry. >>>>>> >>>>>> IIUC, an errata to 3108 wouldn't, on its own, be >> sufficient either. >>>>>> I think we will need a new RFC that does it. This should >> probably >>>>>> be an update to 3108. An errata is perhaps a formal way >> to trigger that. >>>>>> >>>>> Having previously communicated with one of the RFC 3108 >> authors on >>>>> this, I would ask for leniency here, not least >> considering that RFC >>>>> 3108 predates RFC 4566. In other words, I'd argue that we should >>>>> simply add the missing registrations. >>>> >>>> I wasn't trying to be pejorative - just commenting on what seems >>>> required to fix it. >>>> >>>> We just need *some* RFC to do it. It could be 4566bis. But if it >>>> isn't one that explicitly updates 3108, then we should >> take care to >>>> instruct IANA to make the registry point to 3108. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> From fandreas@cisco.com Fri Oct 11 10:04:28 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 593E221E8133 for ; Fri, 11 Oct 2013 10:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCFzHQGYHy9K for ; Fri, 11 Oct 2013 10:04:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E822721F9E11 for ; Fri, 11 Oct 2013 10:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1326; q=dns/txt; s=iport; t=1381511063; x=1382720663; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=M1GMZgYp8i0fQ0YiqvWhx/WUSQEzlA17czIge1kFoCo=; b=UADzIkPNIWTvUzitCvAiV5pjhhrGDue/J7V1RzTlrFBhnTeT1lwxuW8g 8zamevxFVR/BRf2rZgJsps+YZh/eEzltJSB/X/t/sUZU1m5An5R6UiPtD vhfkcNC/zNuFb0KR/P99tsHGXs218NSRmWplm/NX7zvNw/fWqLAf/EVtO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANkuWFKrRDoJ/2dsb2JhbABZgwc4wV5LgSQWdIIlAQEBBAEBATU2CgEQCxgJFgQLCQMCAQIBFTAGDQEFAgEBiAENumYEj0cHhCMDlCiDXZICgWaBWiA X-IronPort-AV: E=Sophos;i="4.90,1082,1371081600"; d="scan'208";a="91931054" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Oct 2013 17:04:22 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9BH4Kt0004091; Fri, 11 Oct 2013 17:04:21 GMT Message-ID: <52582F95.7030206@cisco.com> Date: Fri, 11 Oct 2013 13:04:21 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic References: <52447646.3090607@cisco.com> In-Reply-To: <52447646.3090607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-holmberg-mmusic-udptl-dtls@tools.ietf.org Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-holmberg-mmusic-udptl-dtls-02 as WG item 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 Oct 2013 17:04:28 -0000 Based on the feedback received, the WG has indicated support for this work. The chairs will work with the ADs on adding a milestone for it. Once that is completed, the document will then be submitted as a WG document. Thanks -- Flemming (MMUSIC co-chair) On 9/26/13 2:00 PM, Flemming Andreasen wrote: > Greetings > > Usage of UDPTL over DTLS has been suggested as a mechanism to provide > secure fax and we currently have draft-holmberg-mmusic-udptl-dtls-02 > specifying this. > > 3GPP has indicated a dependency on this work, and we have seen > indications from several people indicating both an interest and > support for the work. An earlier version of the draft received a > couple of comments which we believe have been resolved at this point. > > Based on the above, we would like to propose adding a new milestone > for usage of UDPTL over DTLS in order to provide secure fax and > adoption of draft-holmberg-mmusic-udptl-dtls-02 as a WG item for that > milestone. > > If you have any comments or concerns with the above, please let us > know no later than October 10, 2013. > > Thanks > > -- Ari & Flemming (MMUSIC co-chairs) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fluffy@cisco.com Fri Oct 11 10:37: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 1322221E816A for ; Fri, 11 Oct 2013 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFa+j68Nb6p8 for ; Fri, 11 Oct 2013 10:36:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD721E8151 for ; Fri, 11 Oct 2013 10:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2560; q=dns/txt; s=iport; t=1381513011; x=1382722611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ETIrWtIBC+s3Xc3/oKP3go1CfnFGGMofl2cgCsgiHNw=; b=OFFs7VXmjNlsmCYsM6Hmp7mObpTJlShUl724sR8iOt8mLMI0euqRejrb AMqVBCsWcdhnHV/1rKX1+YA9qLXp1O3AUEoNfM5zuyxeRlHXpVGUt3Cpl eaKxN5bCy4DB9EctlhxaniXYHc9GGz/BHvHtoToi/zyhWNxKJ/qIowHqG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPY1WFKtJV2Y/2dsb2JhbABZgwc4UsENS4EkFnSCJQEBAQMBAQEBNzQLBQkCAgEIDgoKFBAbDAslAgQOBQiHeAYMuwcEBI8QAjEHgx+BBAOqB4Mkgio X-IronPort-AV: E=Sophos;i="4.90,1082,1371081600"; d="scan'208";a="271169091" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2013 17:36:50 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9BHao0X031836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 17:36:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 12:36:50 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? Thread-Index: AQHOxqh3rnELQilnDkeTZ4Bj46q+5Q== Date: Fri, 11 Oct 2013 17:36:50 +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: mmusic Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 17:37:00 -0000 Theory: Obviously the standards say to do RTP/SAVPF=20 Practice: Experimental evidence show that RTP/AVP along with feedback and f= ingerprint attributes works best=20 If you think it is sad that theory does not match practice, submit a draft = on best way to resolve that.=20 On Oct 9, 2013, at 10:00 AM, Emil Ivov wrote: > Oops, hit sent a bit too early. I wanted to add that that the least > painful option would obviously be to add tcap attributes as per 5939 > and then keep RTP/AVP in the m=3D line but that would still be rejected > by a WebRTC endpoint (right?) so do we need to adjust JSEP to allow > RTP/AVP if the m=3D line contains the necessary transport capabilities? >=20 > Emil >=20 >=20 > On Wed, Oct 9, 2013 at 5:44 PM, Emil Ivov wrote: >> Hey all, >>=20 >> We've recently implemented support for DTLS/SRTP and a question that >> we had somehow avoided in the past with SDES and ZRTP is now back on >> the table: >>=20 >> By default, which profile would a SIP UA use in an outgoing offer? >>=20 >> Until recently recently we were offering RTP/AVP by default, which is >> ok for ZRTP and tolerated by most of the endpoints that support SDES. >>=20 >> We also had a couple of config options that allowed Jitsi to (A) >> create offers with RTP/SAVP(F) in case someone turned out to be picky >> about the transport or (B) duplicate all m=3D lines and offer them with >> every supported transport so that the remote endpoint would pick what >> it likes. >>=20 >> Obviously option (A) is not a suitable default for a generic SIP UA >> because that would make it incompatible with the majority of the >> endpoints that exist today. (B) could have worked but now that we are >> going for "Unified", having the same "m=3D" line appear with RTP/AVP and >> then again with RTP/SAVPF would have to be interpreted as two >> independent streams rather than the same stream being available over >> two different transports. >>=20 >> So, do we have a story here or do we need to create one? >>=20 >> Emil >>=20 >> -- >> https://jitsi.org >=20 >=20 >=20 > --=20 > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > https://jitsi.org FAX: +33.1.77.62.47.31 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Fri Oct 11 13:35: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 42FDC11E80E8 for ; Fri, 11 Oct 2013 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SM1dQwhWut1 for ; Fri, 11 Oct 2013 13:35:33 -0700 (PDT) Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com [65.55.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6663B11E80EC for ; Fri, 11 Oct 2013 13:35:33 -0700 (PDT) Received: from BLU169-W109 ([65.55.111.135]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Oct 2013 13:35:32 -0700 X-TMN: [AiuL5fdGS8rTvDAe0oJrLaZL7c9H4PFsHs4DGYnquM0=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c9e07820-a6d8-49ca-8020-a6ecd7f507fb_" From: Bernard Aboba To: "Cullen Jennings (fluffy)" , Emil Ivov Date: Fri, 11 Oct 2013 13:35:32 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 11 Oct 2013 20:35:32.0965 (UTC) FILETIME=[6EC40150:01CEC6C1] Cc: mmusic Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 20:35:49 -0000 --_c9e07820-a6d8-49ca-8020-a6ecd7f507fb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said:=20 > Theory: Obviously the standards say to do RTP/SAVPF=20 >=20 > Practice: Experimental evidence show that RTP/AVP along with feedback and= fingerprint attributes works best=20 >=20 > If you think it is sad that theory does not match practice=2C submit a dr= aft on best way to resolve that.=20 [BA] The best way to resolve that would be for implementations to properly = handle RTP profiles they don't support (by setting the port to zero=2C rath= er than returning an error). Then at least it would be clear what the iss= ue was and one could offer RTP/SAVPF and then if that doesn't work=2C do th= e "practical" thing.=20 =20 There are enough really basic things that aren't widely supported in SIP im= plementations (like multi-part MIME support) that I suppose we could write = a document saying "you really ought to do this. It was a requirement befor= e=2C but we REALLY mean it this time. That means you!". Unfortunately I= don't know it would make a difference :( = --_c9e07820-a6d8-49ca-8020-a6ecd7f507fb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said:

>=3B Theo= ry: Obviously the standards say to do RTP/SAVPF
>=3B
>=3B Pract= ice: Experimental evidence show that RTP/AVP along with feedback and finger= print attributes works best
>=3B
>=3B If you think it is sad th= at theory does not match practice=2C submit a draft on best way to resolve = that.

[BA] The best way to resolve that would be for implementation= s to properly handle RTP profiles they don't support (by setting the port t= o zero=2C rather than returning an error). =3B =3B Then at least it= would be clear what the issue was and one could offer RTP/SAVPF and then i= f that doesn't work=2C do the "practical" thing.
 =3B
There are = enough really basic things that aren't widely =3Bsupported in SIP imple= mentations =3B(like multi-part MIME support) that I suppose we could wr= ite a document saying "you really ought to do this. =3B It was a requir= ement before=2C but we REALLY mean it this time. =3B That means you!".&= nbsp=3B =3B =3B Unfortunately I don't know it would make a differen= ce :(
= --_c9e07820-a6d8-49ca-8020-a6ecd7f507fb_-- From fandreas@cisco.com Fri Oct 11 13:56: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 EBB3C11E817F for ; Fri, 11 Oct 2013 13:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzU761STgw99 for ; Fri, 11 Oct 2013 13:56:35 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E350221F9E1A for ; Fri, 11 Oct 2013 13:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=492; q=dns/txt; s=iport; t=1381524996; x=1382734596; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WsvID6XiXZ0KuRq8Licguf6cQD2dmYDywew7t3+H6ug=; b=caEFi5dO3QiD/p2XvwJ/+wVQJw4Wl39miFi7KptDKChkFWiLoQPFPdj7 iZeiLUpEeGiOROxZWW4KMaul9qDjIvuXLhqiD2Q5IoF0205MO2RnAAHpx hnXSg8PHYh6qwAPS1UFtmVWKU8sIRRInOi4X3yGGLzoPmpq6IU8n2VMoJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE5lWFKrRDoI/2dsb2JhbABaDoJ5v2SDA4ElFnSCJQEBAQQ4QAEQCw4KCRYPCQMCAQIBRQYNAQcBAYgBvAyPRweEIwOYBZICgmVbIA X-IronPort-AV: E=Sophos;i="4.93,1082,1378857600"; d="scan'208";a="94458020" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 11 Oct 2013 20:56:34 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9BKuWcB021851; Fri, 11 Oct 2013 20:56:33 GMT Message-ID: <52586602.7050802@cisco.com> Date: Fri, 11 Oct 2013 16:56:34 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52582C13.70906@alum.mit.edu> In-Reply-To: <52582C13.70906@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DRAGE, Keith \(Keith\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 20:56:41 -0000 On 10/11/13 12:49 PM, Paul Kyzivat wrote: > > I must say that I am troubled that 4566 does not make the registration > of new network or address types mandatory. ("New network(address) > types ... *may* be registered with IANA") The current situation almost > tripped over this. If new ones aren't registered, then how is someone > who wants to define a new one to know if the chosen name is already > taken. > Fair point; want to start a new thread on this ? -- Flemming From fandreas@cisco.com Fri Oct 11 13:59: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 344E511E819E for ; Fri, 11 Oct 2013 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayoXCzvPYHbo for ; Fri, 11 Oct 2013 13:59:00 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6376911E8174 for ; Fri, 11 Oct 2013 13:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6204; q=dns/txt; s=iport; t=1381525131; x=1382734731; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NCrAA73ohRPFM6B5cgEAuP05kT+HEufEPhyibTLPhe4=; b=aZcjJfm3lQNxfEHID5CQlsZaJMCJTRqnLQQBNHi3byX6iJfNNRpwwrGf hV7LbqCTFG+sekSJ4hCKSSolrI72O5vIXQb+UCgZtXV2YrYObCxY7x4DR 4RDWRZ9R6P4HXrWOTBFfnSLsxQ2VlRDyiDkqsHTkNHNkNsAbXmrxUZ8/y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAE5lWFKrRDoI/2dsb2JhbABagwc4iVi4DEuBJRZ0giUBAQEEAQEBawoBDAQcAwECAQkWBAsJAwIBAgEVJgIIBg0BBQIBAYgBDbt7BI82EQcGhB0DlCiDXZICgWaBWiA X-IronPort-AV: E=Sophos;i="4.93,1082,1378857600"; d="scan'208,217";a="94458128" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 11 Oct 2013 20:58:51 +0000 Received: from bxb-fandreas-8811.cisco.com (bxb-fandreas-8811.cisco.com [10.98.149.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9BKwnea023027; Fri, 11 Oct 2013 20:58:49 GMT Message-ID: <5258668A.8020102@cisco.com> Date: Fri, 11 Oct 2013 16:58:50 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rai-ads References: <52582F95.7030206@cisco.com> In-Reply-To: <52582F95.7030206@cisco.com> X-Forwarded-Message-Id: <52582F95.7030206@cisco.com> Content-Type: multipart/alternative; boundary="------------060101000409060505050406" Cc: mmusic Subject: [MMUSIC] Fwd: Re: Suggested new milestone and adoption of draft-holmberg-mmusic-udptl-dtls-02 as WG item 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 Oct 2013 20:59:09 -0000 This is a multi-part message in MIME format. --------------060101000409060505050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi RAI ADs Any issues with adding an MMUSIC milestone per the below (if not, there is some desire to get it approved quickly to the document can be submitted as WG doc before Vancouver) ? Thanks -- Flemming -------- Original Message -------- Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-holmberg-mmusic-udptl-dtls-02 as WG item Date: Fri, 11 Oct 2013 13:04:21 -0400 From: Flemming Andreasen To: mmusic CC: Based on the feedback received, the WG has indicated support for this work. The chairs will work with the ADs on adding a milestone for it. Once that is completed, the document will then be submitted as a WG document. Thanks -- Flemming (MMUSIC co-chair) On 9/26/13 2:00 PM, Flemming Andreasen wrote: > Greetings > > Usage of UDPTL over DTLS has been suggested as a mechanism to provide > secure fax and we currently have draft-holmberg-mmusic-udptl-dtls-02 > specifying this. > > 3GPP has indicated a dependency on this work, and we have seen > indications from several people indicating both an interest and > support for the work. An earlier version of the draft received a > couple of comments which we believe have been resolved at this point. > > Based on the above, we would like to propose adding a new milestone > for usage of UDPTL over DTLS in order to provide secure fax and > adoption of draft-holmberg-mmusic-udptl-dtls-02 as a WG item for that > milestone. > > If you have any comments or concerns with the above, please let us > know no later than October 10, 2013. > > Thanks > > -- Ari & Flemming (MMUSIC co-chairs) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --------------060101000409060505050406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi RAI ADs

Any issues with adding an MMUSIC milestone per the below (if not, there is some desire to get it approved quickly to the document can be submitted as WG doc before Vancouver) ?

Thanks

-- Flemming


-------- Original Message --------
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-holmberg-mmusic-udptl-dtls-02 as WG item
Date: Fri, 11 Oct 2013 13:04:21 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org>
CC: <draft-holmberg-mmusic-udptl-dtls@tools.ietf.org> 


Based on the feedback received, the WG has indicated support for this work.

The chairs will work with the ADs on adding a milestone for it. Once 
that is completed, the document will then be submitted as a WG document.

Thanks

-- Flemming (MMUSIC co-chair)


On 9/26/13 2:00 PM, Flemming Andreasen wrote:
> Greetings
>
> Usage of UDPTL over DTLS has been suggested as a mechanism to provide 
> secure fax and we currently have draft-holmberg-mmusic-udptl-dtls-02 
> specifying this.
>
> 3GPP has indicated a dependency on this work, and we have seen 
> indications from several people indicating both an interest and 
> support for the work. An earlier version of the draft received a 
> couple of comments which we believe have been resolved at this point.
>
> Based on the above, we would like to propose adding a new milestone 
> for usage of UDPTL over DTLS in order to provide secure fax and 
> adoption of draft-holmberg-mmusic-udptl-dtls-02 as a WG item for that 
> milestone.
>
> If you have any comments or concerns with the above, please let us 
> know no later than October 10, 2013.
>
> Thanks
>
> -- Ari & Flemming (MMUSIC co-chairs)
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

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


--------------060101000409060505050406-- From fluffy@cisco.com Fri Oct 11 16:12: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 8B04411E8191 for ; Fri, 11 Oct 2013 16:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qu9b2kcl6iy for ; Fri, 11 Oct 2013 16:12:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B835111E8174 for ; Fri, 11 Oct 2013 16:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1381533150; x=1382742750; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wKBeXREHqo26w+bRfrqmbAkXdt1BJpn7mG67DftEdUw=; b=JXGoblZYMvZ4Cx8ob5CmmiT+i72v8w0AJOuzT7jh0u3cTk87kvyYRM0S +2eHKWLZ4QULHEQr7uAB902MNeCWibefESTtLKsd4u+iVvX/H6wb4CkUx OcqpkIJvpPNNcWLJUPB3mrOysHqA00H1/rBNqHG5T8tOgZkCLWHFnIr+7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAFiFWFKtJV2a/2dsb2JhbABagweBCq8EklqBIhZ0giUBAQEDAXkFCwIBCCIkMiUCBA4FCIdsAwkGvA+MYII6AjEHgx+BBAOJBI0ZjjSFNoMkgik X-IronPort-AV: E=Sophos;i="4.93,478,1378857600"; d="scan'208";a="271230101" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2013 23:12:30 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9BNCUmA018037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 23:12:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 18:12:29 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? Thread-Index: AQHOxsFvwtriYW5u7kSk9BL4x4MuxpnwdQWA Date: Fri, 11 Oct 2013 23:12:29 +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="iso-8859-1" Content-ID: <5AD242BCAF3BEC48BA83476E128B1600@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 23:12:36 -0000 On Oct 11, 2013, at 2:35 PM, Bernard Aboba wrote: > Cullen said:=20 >=20 > > Theory: Obviously the standards say to do RTP/SAVPF=20 > >=20 > > Practice: Experimental evidence show that RTP/AVP along with feedback a= nd fingerprint attributes works best=20 > >=20 > > If you think it is sad that theory does not match practice, submit a dr= aft on best way to resolve that.=20 >=20 > [BA] The best way to resolve that would be for implementations to properl= y handle RTP profiles they don't support (by setting the port to zero, rath= er than returning an error). Then at least it would be clear what the iss= ue was and one could offer RTP/SAVPF and then if that doesn't work, do the = "practical" thing.=20 +1 (thought looking at some test results, lots of them do that) > =20 > There are enough really basic things that aren't widely supported in SIP = implementations (like multi-part MIME support) that I suppose we could writ= e a document saying "you really ought to do this. It was a requirement bef= ore, but we REALLY mean it this time. That means you!". Unfortunately I= don't know it would make a difference :( I given up hope of ever seeing widespread support for multi-part MIME=20 From pkyzivat@alum.mit.edu Fri Oct 11 17:03: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 4BD0A21F9B65 for ; Fri, 11 Oct 2013 17:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIM0+cGn7EED for ; Fri, 11 Oct 2013 17:03:24 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 5982C21F9B08 for ; Fri, 11 Oct 2013 17:03:23 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id bzwH1m0011ap0As5D03Pic; Sat, 12 Oct 2013 00:03:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id c03P1m00E3ZTu2S3i03PAj; Sat, 12 Oct 2013 00:03:23 +0000 Message-ID: <525891C9.4050904@alum.mit.edu> Date: Fri, 11 Oct 2013 20:03:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52582C13.70906@alum.mit.edu> <52586602.7050802@cisco.com> In-Reply-To: <52586602.7050802@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=1381536203; bh=b86ceQVBpE5qBEfRsyBdmyLPpsXDIlr0ZdDeP3zB5wU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gH0khyKnwzRhN+lHyW4W41G3FVhk0f9I3wvoRfn4sEI6tVKeNLsiI184fR3TOguqd J/RC0HCSJx6ia8TajfryGvi0YQrB0XwG4uHoGTX6KokQzYe46lFXRjRdw+5XoJ0+nu HveYXEjeDuDB8p32QbTey80iPy00gZKebKuW3Ryz4A3AmdK7g56a6J/W+78NnFbO0q 6rrDxAUhv1IQjqv5XNTRgkR/ui5g52XBJmCNHoH7aaRHyOFadOpqLNCgDV0sL5MfYM AIkzmovWOrtls4fRraMheX2mzHPARqePFLy2pZjB5c59BiVRAe7qmL2Au88qd1oUCO pgH2dU0XiJ3zQ== Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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, 12 Oct 2013 00:03:30 -0000 On 10/11/13 4:56 PM, Flemming Andreasen wrote: > > On 10/11/13 12:49 PM, Paul Kyzivat wrote: >> >> I must say that I am troubled that 4566 does not make the registration >> of new network or address types mandatory. ("New network(address) >> types ... *may* be registered with IANA") The current situation almost >> tripped over this. If new ones aren't registered, then how is someone >> who wants to define a new one to know if the chosen name is already >> taken. >> > Fair point; want to start a new thread on this ? Does this require a thread of its own? I'm thinking this is just part of a more general task to clean up the IANA registries for SDP. (Probably as part of 4566bis.) But I hesitate to kick of a discussion now that might be active. I am swamped in another context right now. Thanks, Paul From richard.ejzak@alcatel-lucent.com Sun Oct 13 16:00: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 D0D4D11E812F; Sun, 13 Oct 2013 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzogSgXQi7S1; Sun, 13 Oct 2013 16:00:16 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4611E80EE; Sun, 13 Oct 2013 16:00:13 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9DN0Bsc028960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Oct 2013 18:00:11 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9DN0AHG030789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 19:00:10 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Sun, 13 Oct 2013 19:00:10 -0400 From: "Ejzak, Richard P (Richard)" To: DISPATCH , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [dispatch] [MMUSIC] [rtcweb] FW: New Version Notification for draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt Thread-Index: AQHOyGf3HKB+ufbKaUuqcHLlUeseLg== Date: Sun, 13 Oct 2013 23:00:09 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86A163@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [MMUSIC] [dispatch] [rtcweb] FW: New Version Notification for draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.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: Sun, 13 Oct 2013 23:00:22 -0000 UGxlYXNlIG5vdGUgdGhlIHN1Ym1pc3Npb24gb2YgZHJhZnQtZWp6YWstZGlzcGF0Y2gtd2VicnRj LWRhdGEtY2hhbm5lbC1zZHBuZWcuICBJdCBkZXNjcmliZXMgRGF0YUNoYW5uZWwgZXh0ZXJuYWwg bmVnb3RpYXRpb24gcHJvY2VkdXJlcyBiYXNlZCBvbiBTRFAgdG8gc2V0IHVwIERhdGFDaGFubmVs IHRyYW5zcG9ydCBmb3Igd2VsbC1rbm93biBzdWItcHJvdG9jb2xzIGxpa2UgTVNSUCwgQkZDUCwg VDE0MCwgVDM4LCBhbmQgcG9zc2libHkgdGhlIENMVUUgY29udHJvbCBwcm90b2NvbC4gIEl0IG1h a2VzIG5vIGFkZGl0aW9uYWwgZGVtYW5kcyBvbiB0aGUgRGF0YUNoYW5uZWwgZGVzaWduLCBhbHRo b3VnaCB0aGUgZG9jdW1lbnQgcmFpc2VzIG9uZSBzbWFsbCBpc3N1ZSBhbmQgc3VnZ2VzdHMgc29t ZSBjbGFyaWZpY2F0aW9ucyBpbiBleGlzdGluZyBEYXRhQ2hhbm5lbCBkb2N1bWVudHMuIFBsZWFz ZSBleHBlY3Qgb25lIG1vcmUgZG9jdW1lbnQgc29vbiB0aGF0IGRlc2NyaWJlcyB0aGUgYXBwbGlj YXRpb24gb2YgdGhlIGRyYWZ0IHRvIG5lZ290aWF0aW9uIG9mIERhdGFDaGFubmVsIHRyYW5zcG9y dCBmb3IgTVNSUC4NCg0KUmljaGFyZCBFanphaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgT2N0b2JlciAxMywgMjAxMyA1OjQ1IFBNDQpUbzog RWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCk7IE1BUkNPTiwgSkVST01FIChKRVJPTUUpDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWVqemFrLWRpc3BhdGNoLXdl YnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1lanphay1kaXNwYXRjaC13ZWJydGMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmljaGFyZCBFanphayBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZWp6YWstZGlz cGF0Y2gtd2VicnRjLWRhdGEtY2hhbm5lbC1zZHBuZWcNClJldmlzaW9uOgkgMDANClRpdGxlOgkJ IFNEUC1iYXNlZCBXZWJSVEMgZGF0YSBjaGFubmVsIG5lZ290aWF0aW9uDQpDcmVhdGlvbiBkYXRl OgkgMjAxMy0xMC0xNA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDE0DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVqemFrLWRpc3BhdGNoLXdl YnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgUmVhbC1U aW1lIENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmcgZ3JvdXAg aXMNCiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3QgaW50 ZXJhY3RpdmUgcmljaA0KICAgY29tbXVuaWNhdGlvbiB1c2luZyBhdWRpbywgdmlkZW8sIGFuZCBk YXRhIGJldHdlZW4gdHdvIHBlZXJzJyB3ZWItDQogICBicm93c2Vycy4gIEZvciB0aGUgc3VwcG9y dCBvZiBkYXRhIGNvbW11bmljYXRpb24sIHRoZSBSVENXZWIgd29ya2luZw0KICAgZ3JvdXAgaGFz IGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0aGUgY29uY2VwdCBvZiBiaS1kaXJlY3Rpb25hbCBkYXRh DQogICBjaGFubmVscyBvdmVyIFNDVFAsIHdoZXJlIGVhY2ggZGF0YSBjaGFubmVsIG1pZ2h0IGJl IHVzZWQgdG8NCiAgIHRyYW5zcG9ydCBvdGhlciBwcm90b2NvbHMsIGNhbGxlZCBzdWItcHJvdG9j b2xzLiAgRGF0YSBjaGFubmVsIHNldHVwDQogICBjYW4gYmUgZG9uZSB1c2luZyBlaXRoZXIgdGhl IGluLWJhbmQgV2ViUlRDIERhdGEgQ2hhbm5lbCBwcm90b2NvbCBvcg0KICAgc29tZSBleHRlcm5h bCAoaW4tYmFuZCBvciBvdXQtb2YtYmFuZCkgbmVnb3RpYXRpb24uICBUaGlzIGRvY3VtZW50DQog ICBzcGVjaWZpZXMgaG93IHRoZSBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1c2Vk IHRvIGFjaGlldmUNCiAgIHN1Y2ggYW4gZXh0ZXJuYWwgbmVnb3RpYXRpb24uDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From fandreas@cisco.com Sun Oct 13 20: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 4EB3511E80FE for ; Sun, 13 Oct 2013 20:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LURIgw9ynt7G for ; Sun, 13 Oct 2013 20:22:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C66F111E80E2 for ; Sun, 13 Oct 2013 20:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1381720934; x=1382930534; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BJfVWPB54IG3pDEXxHhnNPUY3RLhTic7qyE1VMLvPO0=; b=CaJ2XqU6dzbwpl6DSwY80lMHaPc9A3AKIG3QffH1tJXAD26LXAQoIyBe kaQgc3v/La+nynXpBz55U9GJyuO3bEKjRjl++SGjVweEynbcP/2DHx/Jy Mv3APIXfrKYgzK4Go7LC8KF5uiPzF4X2PACRWMRgpEolPl5zPTfVzMrzw A=; X-IronPort-AV: E=Sophos;i="4.93,488,1378857600"; d="scan'208";a="271470635" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 14 Oct 2013 03:22:14 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.255.183]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9E3MCFe032262; Mon, 14 Oct 2013 03:22:12 GMT Message-ID: <525B3325.4050600@cisco.com> Date: Sun, 13 Oct 2013 19:56:21 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Paul Kyzivat , mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <52522A69.4020907@nteczone.com> <5252F30F.5000007@alum.mit.edu> <525339B5.3010300@nteczone.com> <52558227.3020300@alum.mit.edu> <5255C3A7.6000104@cisco.com> <5255D88E.1050600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B40E4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5257269D.6080600@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0B6174@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52582C13.70906@alum.mit.edu> <52586602.7050802@cisco.com> <525891C9.4050904@alum.mit.edu> In-Reply-To: <525891C9.4050904@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values 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 Oct 2013 03:22:19 -0000 On 10/11/13 8:03 PM, Paul Kyzivat wrote: > On 10/11/13 4:56 PM, Flemming Andreasen wrote: >> >> On 10/11/13 12:49 PM, Paul Kyzivat wrote: >>> >>> I must say that I am troubled that 4566 does not make the registration >>> of new network or address types mandatory. ("New network(address) >>> types ... *may* be registered with IANA") The current situation almost >>> tripped over this. If new ones aren't registered, then how is someone >>> who wants to define a new one to know if the chosen name is already >>> taken. >>> >> Fair point; want to start a new thread on this ? > > Does this require a thread of its own? It's buried so deep in this thread that I thought it would be a good idea, however I have asked Ali to make sure he tracks it as part of the 4566bis update. Thanks -- Flemming > I'm thinking this is just part of a more general task to clean up the > IANA registries for SDP. (Probably as part of 4566bis.) > > But I hesitate to kick of a discussion now that might be active. > I am swamped in another context right now. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From magnus.westerlund@ericsson.com Sun Oct 13 23:11:28 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 DD27211E810A for ; Sun, 13 Oct 2013 23:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.145 X-Spam-Level: X-Spam-Status: No, score=-105.145 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8MlBvEJnC4T for ; Sun, 13 Oct 2013 23:11:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AED3C21F9AA2 for ; Sun, 13 Oct 2013 23:11:21 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-61-525b8b082768 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 19.AB.03802.80B8B525; Mon, 14 Oct 2013 08:11:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Mon, 14 Oct 2013 08:11:19 +0200 Message-ID: <525B8B33.7030402@ericsson.com> Date: Mon, 14 Oct 2013 08:12:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20131011161559.4968.64237.idtracker@ietfa.amsl.com> In-Reply-To: <20131011161559.4968.64237.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+JvrS5Hd3SQwYf7ohZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt4HO9kLvglVfPgY2MDYzd/FyMkhIWAisfpICxuELSZx4d56 IJuLQ0jgMKPE4bOrmSGc5YwSW/r2soNU8QpoS9y8dJEJxGYRUJXYc2AqWJxNwELi5o9GsEmi AsES7du/skHUC0qcnPmEBcQWEVCXaN3cxwpiCwvUSfx73wtWIyTgIPHxxnpmEJtTwFGid34D O8RFkhLbFh0Ds5kF9CSmXG1hhLDlJZq3zmaG6NWWaGjqYJ3AKDgLybpZSFpmIWlZwMi8ipE9 NzEzJ73caBMjMPwObvmtuoPxzjmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamAM/GZQ8O5pxIlr2cX/7nwyXyt3fWFHzTWdlL2nFlg9cNErtu/cdPeS6JFvsjWMb1NT 467tfDNLannenu229vvcE2fL9pn3hM6Um/PGkOv8RN8lDwzydi+rSen3snFQXNZkxCOfuvaz KK906oSp1bOWbj7lM0N76p2+OVvmLfUw9c0Iq/Y2Y9FWYinOSDTUYi4qTgQAlnuvJQ0CAAA= Subject: Re: [MMUSIC] Last Call: (Real Time Streaming Protocol 2.0 (RTSP)) to Proposed Standard 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 Oct 2013 06:11:28 -0000 WG, Please take this probably last chance to review the changes during these last months for this document. Cheers Magnus On 2013-10-11 18:15, The IESG wrote: > > The IESG has received a request from the Multiparty Multimedia Session > Control WG (mmusic) to consider the following document: > - 'Real Time Streaming Protocol 2.0 (RTSP)' > 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-10-25. 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 memorandum defines RTSP version 2.0 which obsoletes RTSP version > 1.0 defined in RFC 2326. > > The Real Time Streaming Protocol, or RTSP, is an application-level > protocol for setup and control of the delivery of data with real-time > properties. RTSP provides an extensible framework to enable > controlled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 3550). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/2028/ > http://datatracker.ietf.org/ipr/1189/ > > > > -- 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 internet-drafts@ietf.org Mon Oct 14 04:33: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 8411021E8160; Mon, 14 Oct 2013 04:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKNoe-dbOGBZ; Mon, 14 Oct 2013 04:33:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5574E21E80CC; Mon, 14 Oct 2013 04:33:07 -0700 (PDT) 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.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014113306.25607.18705.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 04:33:06 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:33:09 -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 : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-05.txt Pages : 27 Date : 2013-10-14 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-bundle-negotiation= -05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Mon Oct 14 04:37: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 0DEC621F9BF3 for ; Mon, 14 Oct 2013 04:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHzau+9L7aDW for ; Mon, 14 Oct 2013 04:37:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 24D6821E80CA for ; Mon, 14 Oct 2013 04:37:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-74-525bd777e4bc Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7A.EB.16099.777DB525; Mon, 14 Oct 2013 13:37:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 13:37:27 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 Thread-Index: Ac7I0TR9IXCLHgP4RGuc1x60hRqEsw== Date: Mon, 14 Oct 2013 11:37:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BDF94@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BDF94ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvrW759eggg5OPhSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIfnrQsuy1TMOfOOvYGxW7KLkZNDQsBE4uvCc2wQtpjEhXvr gWwuDiGBw4wST1rmQDlLGCXen5zF2MXIwcEmYCHR/U8bpEFEQF3i694eZhBbWMBd4s6yl+wQ cR+Jk792skDYehKLfi5hBbFZBFQlmtdNB1vGK+ArcXfXZLB6RqDF30+tYQKxmQXEJW49mc8E cZCAxJI955khbFGJl4//sYKcICGgKLG8Xw6iPF9i981pjBAjBSVOznzCMoFRaBaSSbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMbLnJmbmpJcbbmIEhvzBLb91dzCeOidy iFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYz55Ty/t3CIzlL8yq58UuK8 FecJJoWIQunATebHLBkiz6TtSs3smX/+uUy2rrxBzKX8vfun2lk1fL2rXe7fMvHPjqvBmis2 eLZofMwUkd8iNS1fecFZi6zsXX/Zws6vttButPZJyXI6F3Z92oT5XNXXq8oLjL37FXrb1m+Y 75r+mN2QX2pGnBJLcUaioRZzUXEiAOW2neJHAgAA Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 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 Oct 2013 11:37:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4BDF94ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the BUNDLE draft. I have implemented the modified text for the Offerer and Answerer procedure= s, as presented on the list in September. The procedures now also mention the usage of the SDP 'bundle-only' attribut= e. However, the attribute definition itself has yet not been added to the d= raft, as we still haven't solved the issue regarding usage of port zero. In addition, there are some reference corrections, and the FQDN values in t= he examples are now according to RFC 2606. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4BDF94ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of the BUNDLE dra= ft.

 

I have implemented the modified text for the Offerer= and Answerer procedures, as presented on the list in September.=

 

The procedures now also mention the usage of the SDP= ‘bundle-only’ attribute. However, the attribute definition its= elf has yet not been added to the draft, as we still haven’t solved t= he issue regarding usage of port zero.

 

In addition, there are some reference corrections, a= nd the FQDN values in the examples are now according to RFC 2606.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4BDF94ESESSMB209erics_-- From eckelcu@cisco.com Mon Oct 14 14:54: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 5F3EC21F9223 for ; Mon, 14 Oct 2013 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWRqNqit1iLi for ; Mon, 14 Oct 2013 14:54:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF6921E817A for ; Mon, 14 Oct 2013 14:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4989; q=dns/txt; s=iport; t=1381787667; x=1382997267; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EgYpTzborkh1DqXSnhz+4H/kje8JSfB/4bArEFGFWJ4=; b=DibaVTzFRuSee1dnsEUOUc+OQtirZfhDZt8f9v29RNOqEXCQ2P/+wIJH 4bLcjfz2hy1ZRh++M76lILEtbNtX+TE03dmu+DQj7pmSNpCr9VFuMYMj0 gUlNj3xzd2ufSnhwQCJl1HkezcEVWZhHGNO9qXBZIgBKsB/6NIu2IInAM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAMhnXFKtJV2d/2dsb2JhbABZgwc4Uq8ykhNLgSkWdIIlAQEBBAEBATc0CxIBCA4KChQ3CyUCBAENBQiHbAMOAQy9aoxjgTCBCwIxB4MfgQQDlh2DF4sdhTaDJIFoQQ X-IronPort-AV: E=Sophos;i="4.93,494,1378857600"; d="scan'208";a="272048298" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 14 Oct 2013 21:54:26 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9ELsQlF004297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 21:54:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.239]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 16:54:25 -0500 From: "Charles Eckel (eckelcu)" To: Emil Ivov , Bernard Aboba Thread-Topic: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? Thread-Index: AQHOySfyJf8aUkpaz0KBVgY3fxy31Q== Date: Mon, 14 Oct 2013 21:54:25 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882805C323D9@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [171.68.20.46] Content-Type: text/plain; charset="us-ascii" Content-ID: <76B63E9A1D9B2F4287B172FF67C92442@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default? 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 Oct 2013 21:54:32 -0000 Hi Emil, You may interested in the recommendation provided in the IMTC SIP Security best practice document. This document was shared with the IETF via the following liaison statement. https://datatracker.ietf.org/liaison/1248/ It provides recommendations to negotiated "best effort" security in the presence of legacy endpoints that support a mix of AVP and SAVP. The logic it follows is similar to that for AVP/AVPF, as mentioned by Bernard. Cheers, Charles On 10/9/13 10:52 AM, "Emil Ivov" wrote: >On Wed, Oct 9, 2013 at 7:30 PM, Bernard Aboba >wrote: >> [BA] Comments below. >> >> Emil said: >> >> Oops, hit sent a bit too early. I wanted to add that that the least >> painful option would obviously be to add tcap attributes as per 5939 >> and then keep RTP/AVP in the m=3D line but that would still be rejected >> by a WebRTC endpoint (right?) so do we need to adjust JSEP to allow >> RTP/AVP if the m=3D line contains the necessary transport capabilities? >> >> [BA] Unfortunately the legacy endpoints whose behavior is the cause of >>this >> issue are unlikely to support RFC 5939, so I can't see how that would >>help. > >Well, at least you'd get to establish an RTP/AVP call with no >encryption. The same goes for endpoints that have SDES support and >tolerate RTP/AVP as transport when they detect the crypto attributes >(without supporting RFC5939). > >I agree that legacy endpoints with no 5939 support that insist on >having RTP/SAVP, would reject it but at least we would limit those >cases. > >> On Wed, Oct 9, 2013 at 5:44 PM, Emil Ivov wrote: >>> Hey all, >>> >>> We've recently implemented support for DTLS/SRTP and a question that >>> we had somehow avoided in the past with SDES and ZRTP is now back on >>> the table: >>> >>> By default, which profile would a SIP UA use in an outgoing offer? >>> >>> Until recently recently we were offering RTP/AVP by default, which is >>> ok for ZRTP and tolerated by most of the endpoints that support SDES. >> >> [BA] I would add that RTP/AVP is also tolerated by endpoints that >>support >> feedback. >> >>> We also had a couple of config options that allowed Jitsi to (A) >>> create offers with RTP/SAVP(F) in case someone turned out to be picky >>> about the transport or (B) duplicate all m=3D lines and offer them with >>> every supported transport so that the remote endpoint would pick what >>> it likes. >> >> [BA] In my experience option B doesn't work that well, because >> implementations that do not support RTP/SAVPF will not always respond by >> setting the port to zero on those m lines, as they should. Instead >>they >> may respond with an error. So you're likely to have problems, >>"unified" not >> withstanding. > >True. > >>> Obviously option (A) is not a suitable default for a generic SIP UA >>> because that would make it incompatible with the majority of the >>> endpoints that exist today. (B) could have worked but now that we are >>> going for "Unified", having the same "m=3D" line appear with RTP/AVP an= d >>> then again with RTP/SAVPF would have to be interpreted as two >>> independent streams rather than the same stream being available over >>> two different transports. >>> >>> So, do we have a story here or do we need to create one? >> >> [BA] If by "have a story here" you mean "have a standards-based way of >> reliably interoperating with non-standards compliant legacy UAs", I >>think >> the answer is unfortunately "no" :( > >Well, not even that. I'd be happy with a story that allows us to >generate offers in a way that would allow for an RTP/AVP call to be >established with standards compliant legacy and an RTP/SAVPF call with >modern endpoints (including gatewayed WebRTC). > >> In practice you might try substituting the following for your option B: >> >> By default, offer RTP/AVP with a=3D lines describing the crypto and >>feedback >> features you support. If the answerer is legacy, you'll have the >>highest >> chance of backward compatibility this way. You may even get back an >>answer >> with a profile of RTP/(S)AVPF, indicating that the answerer understands >>what >> you are really offering. If that happens you can offer RTP/(S)AVPF in >> re-invites or other subsequent exchanges. > >OK, this does sound reasonable but it would also mean that a >SIP-2-WebRTC gateway would *always* need to modify the first offer >from the SIP UAs even if they are perfectly interoperable otherwise. >Not that this is that much of a big deal but I was still hoping we >could have at least one case where gatewaying SIP to WebRTC would only >be a matter of extracting the SDP and sending it down to the browser. > >Emil > > >-- >https://jitsi.org >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Mon Oct 14 15: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 E32EF11E80F6 for ; Mon, 14 Oct 2013 15:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNUnnKOEgV7i for ; Mon, 14 Oct 2013 15:50:48 -0700 (PDT) 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 4C0E821E813A for ; Mon, 14 Oct 2013 15:50:44 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9EMoagJ049436 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Oct 2013 17:50:40 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <525C7537.4080209@nostrum.com> Date: Mon, 14 Oct 2013 17:50:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [MMUSIC] Partial Offer/Partial Answer 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: Mon, 14 Oct 2013 22:50:49 -0000 I have submitted a document that formally describes the procedures for using partial offers and partial answers within the RFC 3264 framework. There were already several comments on the mechanism from its description in the unified plan, and I believe that these have all been incorporated as either improvements or clarifications. If I missed something, please let me know. As we discussed in Berlin, the real impetus for this work is for use in RTCWEB. The document is written in a way that considers its potential application to SIP; however, I do not mean to imply that adding a partial offer/partial answer mechanism in SIP is by any means a foregone conclusion. There are a number of open issues in the document, all of which should be clearly marked with an "OPEN ISSUE:" tag. If time allows, I plan to release a -01 version of the document that includes a set of relevant examples ahead of the draft deadline next Monday; however, I cannot promise that I will have time to do so. If I do, the _only_ changes will be in section 6, so any notes that you make should transfer over (including section, page, and paragraph number). If you have time before Vancouver, please post thoughts on the MMUSIC mailing list. Thanks. http://www.ietf.org/id/draft-roach-mmusic-pof-pan-00.txt /a From Christian.Groves@nteczone.com Mon Oct 14 17:05: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 E03B821F89FF for ; Mon, 14 Oct 2013 17:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1234byIOQ0Y for ; Mon, 14 Oct 2013 17:05:03 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id BE77321F9C72 for ; Mon, 14 Oct 2013 17:05:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAFaFXFJ20ckw/2dsb2JhbAANTIM/widLgT6DGQEBAQQBAQEvAQUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiA6qKZM6BI9RFoQPA60+ Received: from ppp118-209-201-48.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.201.48]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Oct 2013 10:34:56 +1030 Message-ID: <525C86A3.1080301@nteczone.com> Date: Tue, 15 Oct 2013 11:04:51 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4BDF94@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BDF94@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 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 Oct 2013 00:05:04 -0000 Hello Christer, The SDP grouping mechanism can be applied to different nettype/addrtypes. The BUNDLE draft appears to define behaviour related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section 2 defines BUNDLE terminology based on IP. Is there an intention that the BUNDLE mechanism is only used for the above net and addrtypes? If so should it be mentioned somewhere in the applicability statement? Regards, Christian On 14/10/2013 10:37 PM, Christer Holmberg wrote: > > Hi, > > I’ve submitted a new version of the BUNDLE draft. > > I have implemented the modified text for the Offerer and Answerer > procedures, as presented on the list in September. > > The procedures now also mention the usage of the SDP ‘bundle-only’ > attribute. However, the attribute definition itself has yet not been > added to the draft, as we still haven’t solved the issue regarding > usage of port zero. > > In addition, there are some reference corrections, and the FQDN values > in the examples are now according to RFC 2606. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Mon Oct 14 17:18: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 6C16F21E80E5 for ; Mon, 14 Oct 2013 17:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE5YeU2JMIFl for ; Mon, 14 Oct 2013 17:18:43 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E521721E8134 for ; Mon, 14 Oct 2013 17:18:41 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q58so7876781wes.3 for ; Mon, 14 Oct 2013 17:18:40 -0700 (PDT) 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=XuE25LlfwSakRw3fbEeVArgLprrkY8AO5Ye7XV3sZ1Q=; b=iU5D/KHWZQeaB8eKTkvm+fAzq9Rb/hc6LSmdrsZITCziMUGHwSaYY9GPMjLqGONqNu cMFvG+wmBTcfqRRzJbQ3mxZN+7K7muDHURBQs/tZZYGRMQSsKYBK+EkKlhDRhre+3Fi+ uLxlWWiyD9WfdKXNgZx6QOShaS9RcZVzAWJznXQgh3OnxUJNZW+6piwCt5i//vDwi8jx QWLDKQ+s7kqE/TbMCIypd/sg7+pncZzC5RsMbziI+0EG2UGyTS6kpjyEh5wolEUsSzAH kjfm07Loa7mUwlw6yQKwwUFjudKOuohELnR3eeES3etnetZHobcOLA45Fu3ULBcKzyeJ Mgpg== MIME-Version: 1.0 X-Received: by 10.194.201.202 with SMTP id kc10mr31740105wjc.1.1381796320902; Mon, 14 Oct 2013 17:18:40 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Mon, 14 Oct 2013 17:18:40 -0700 (PDT) In-Reply-To: <525C7537.4080209@nostrum.com> References: <525C7537.4080209@nostrum.com> Date: Mon, 14 Oct 2013 17:18:40 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 00:18:43 -0000 On 14 October 2013 15:50, Adam Roach wrote: > http://www.ietf.org/id/draft-roach-mmusic-pof-pan-00.txt If I read this correctly, that first open issue is a real humdinger. It's going to be a deal-breaker if it means that I can't add new lines to an existing BUNGLE group. I was tempted to suggest that you include all session-level a= lines, but that's going to expose you to glare on the same scale as unmodified 3264 O/A. I'm going to need to noodle on this for a while, because until that issue is resolved, this doesn't really solve the problem. From adam@nostrum.com Mon Oct 14 17:23: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 1F6ED21E8139 for ; Mon, 14 Oct 2013 17:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ3ky5Qaj7WQ for ; Mon, 14 Oct 2013 17:23:22 -0700 (PDT) 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 4647321E8130 for ; Mon, 14 Oct 2013 17:23:01 -0700 (PDT) Received: from [162.189.90.45] ([172.56.7.74]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9F0Mr8T059147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Oct 2013 19:22:54 -0500 (CDT) (envelope-from adam@nostrum.com) References: <525C7537.4080209@nostrum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Adam Roach Date: Mon, 14 Oct 2013 19:22:47 -0500 To: Martin Thomson Received-SPF: pass (shaman.nostrum.com: 172.56.7.74 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 00:23:23 -0000 It's certainly not unsolvable, it's just unsolved. =46rom an information per= spective, it can be done unambiguously. We just need to come up with an eleg= ant syntax. /a On Oct 14, 2013, at 19:18, Martin Thomson wrote: > On 14 October 2013 15:50, Adam Roach wrote: >> http://www.ietf.org/id/draft-roach-mmusic-pof-pan-00.txt >=20 > If I read this correctly, that first open issue is a real humdinger. > It's going to be a deal-breaker if it means that I can't add new lines > to an existing BUNGLE group. >=20 > I was tempted to suggest that you include all session-level a=3D lines, > but that's going to expose you to glare on the same scale as > unmodified 3264 O/A. I'm going to need to noodle on this for a while, > because until that issue is resolved, this doesn't really solve the > problem. From martin.thomson@gmail.com Mon Oct 14 17:28: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 E29D821E80A3 for ; Mon, 14 Oct 2013 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6poRMgQu+RP for ; Mon, 14 Oct 2013 17:28:58 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1B21E8130 for ; Mon, 14 Oct 2013 17:28:56 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so7872446wes.1 for ; Mon, 14 Oct 2013 17:28:55 -0700 (PDT) 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=kyLTjnhnF728AtT9xgxd/bgIbh4u07bqoScP8kSqzZA=; b=WXOBeF1eRfVIo8qwBIZ4OvoV+uybImosCz5jYjegURDQR1eRakq6D3KIQxOX9/IHMw 5CcporD6PKnK7ExsIlv4O768Ac5jWgSfP95pmRvsJswFW7HPvAl2JI/S4OiyPcQsp81j YdMpRqM9l9YvkDKjS8kc1r28AWiIv9J7Gek/skGGSX8H1I9om7ukrzqw5mUxkffO/A5Q /cJIr8gZ/XHzzqL68pTkaOkiOpqq/Hd9+tgQAaFb3E7aK9GvBKnZ2wuxZehOoZpf3Odh rI6bai6y0LXlahwLb/dwUjYnDcT6dT8xBsIBWueNdoBLMLMugGjJaNbNo0EQCje3Ty6c xiLQ== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr17029578wij.30.1381796935620; Mon, 14 Oct 2013 17:28:55 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Mon, 14 Oct 2013 17:28:55 -0700 (PDT) In-Reply-To: References: <525C7537.4080209@nostrum.com> Date: Mon, 14 Oct 2013 17:28:55 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 00:28:59 -0000 On 14 October 2013 17:22, Adam Roach wrote: > It's certainly not unsolvable, it's just unsolved. From an information perspective, it can be done unambiguously. We just need to come up with an elegant syntax. Leaving impossibilities regarding the juxtaposition of the terms "elegant syntax" and "SDP" aside, I don't disagree. I'm just disappointed that you didn't try. >From an information perspective, would you consider a partial offer that amends a group to (potentially) generate glare for all of the lines already in that group? E.g., I have a group of "a b c" and generate a partial offer to add "d" to that group. Does this cause glare with an offer to amend any of "a", "b", or "c"? I think that could be made to work, but I don't like the ramifications. Without further consideration, all I can envisage is the creation of a new grouping semantic. Maybe I'm just being a little pessimistic. From gunnar.hellstrom@omnitor.se Mon Oct 14 19:45: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 332AD21E808F for ; Mon, 14 Oct 2013 19:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Merq3pR9LDlV for ; Mon, 14 Oct 2013 19:45:19 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id B39E521F84C2 for ; Mon, 14 Oct 2013 19:45:12 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Tue, 15 Oct 2013 04:39:51 +0200 (CEST) Received: from [192.168.0.7] (cpe-74-69-52-124.rochester.res.rr.com [74.69.52.124]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 5B36A3A168 for ; Tue, 15 Oct 2013 04:39:50 +0200 (CEST) Message-ID: <525CAAF8.8060303@omnitor.se> Date: Mon, 14 Oct 2013 22:39:52 -0400 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu> <51EF78CA.6040202@omnitor.se> In-Reply-To: <51EF78CA.6040202@omnitor.se> Content-Type: multipart/mixed; boundary="------------040608040603020104040905" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Oct 2013 02:45:25 -0000 This is a multi-part message in MIME format. --------------040608040603020104040905 Content-Type: multipart/alternative; boundary="------------000108080509080708060005" --------------000108080509080708060005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Randall and all, Attached is a version of the draft on negotiating human language with a discussion added about use of Caller preferences/Callee capabilities or SDP, including a proposed coding based on RFC 3840/3841. I am afraid that this is getting a bit complex, both the specification in SDP and the one in SIP, but I see this structure needed to express all kinds of user needs and relay service types. I also realize that the declarations in sdp about media capabilities represent a good source of information that could be used for routing decisions, so a merge of the SDP and SIP based methods might be of interest. I mean that it for example does not make sense to send a call with video to a callee that cannot handle video. Sorry for not providing a nice formatted draft. There are use cases added, and the sections on coding according to RFC 3840 and 3841. In RFC 3840 / 3841, there is a concept of implicit capabilities. If that could be extended to include contents of sdp, we could possibly combine the SIP and SDP based versions to something doable. You have mentioned a couple of times that we could take a simple approach and not complicate it with asymmetric capabilities or preferences in different directions. I tend to agree that that must still be an option. A coarse selection of service could be done anyway. Selection of exact performance of a relay service including the asymmetric aspects would then need to be handled in some other way. Regards Gunnar ------------------------------------------------------------------------ On 2013-07-24 02:48, Gunnar Hellstrom wrote: > On 2013-07-24 02:05, Paul Kyzivat wrote: >> On 7/23/13 6:35 PM, Gunnar Hellstrom wrote: >>> >>> On 2013-07-23 20:00, Paul Kyzivat wrote: >>>> I just reviewed this new version. I have a number of comments: >>> Good comments Paul, >>>> >>>> * Section 5: >>>> >>>> You don't go into the details of the O/A rules. But I infer you assume >>>> that the answer will be a subset of the offer, with the priorities >>>> possibly changed. This is a common strategy with SDP O/A, but it is >>>> limiting because it doesn't allow the answerer to indicate >>>> capabilities it has that weren't mentioned by the offerer. Knowing >>>> that could be useful, especially if a mismatch is going to result in >>>> recruiting a relay service. >>>> >>>> I suggest that answer allow the answerer to indicate all of its >>>> capabilities and preferences, and at the same time indicate choices >>>> made. (If a choice was made.) >>> Yes, very useful to indicate all. >>>> >>>> * Section 7.1: >>>> >>>> Instead of humanintlang-send and humanintlang-recv, how about just >>>> giving the lang tag and a send/recv/sendrecv parameter with it? This >>>> would be more concise when sendrecv can be used. >>>> >>>> Suggest using a parameter (q) to indicate relative preference for >>>> languages, rather than ordering. This can show degree of preference, >>>> and can show when multiple languages have the same preference. >>>> >>> Have you seen my request for an indication of level of preference >>> between the different modalities? A possiblility to indicate for >>> example >>> that British Sign Language is highly preferred, but English text >>> possible. >>> The q values could be used for coding of such relative level of >>> preference even between modalities. a q=1 for BSL in video, and a q=0.1 >>> for English in text. Right? >> >> That would work within a single medium. >> >> But I don't think we can use that mechanism to trade off between >> different media. For that I think some other, more complex, mechanism >> would be needed. >> >> Or else we would need a more complex definition of which things are >> being prioritized against one another in order to use the q-values. > I proposed a simpler mechanism in a recent mail. It was to insert at > the end of the humintlang tag a character a "!" for highly preferred, > nothing for manageable and "#" for > a non-preferred but possible fall-back language and modality. > > I think it will be very important for most users to have a chance to > indicate this three-level preference order between different media as > well as between different languages within one medium. > > I am hesitating a bit for the type of coding I proposed, and saw your > proposal of q-value as something cleaner. When coding, you could make > sure that the last resort medium gets q-values under 0.4, the strongly > preferred between 0.7 and 1 and the managed ones between 0.4 and 0.6. > > You can see the earlier motivation for the preference between > modalities in the archive at: > http://www.ietf.org/mail-archive/web/mmusic/current/msg11871.html > > >> >>>> Example: >>>> >>>> a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5 >>>> >>>> To accommodate my comment about section 5, perhaps the answer can >>>> "mark" the alternative(s) that have been chosen for use, if any. (I'm >>>> not sure I like this, but for now, lets assume a "*" suffix on the >>>> direction in the answer.) E.g., assuming the offer above, then an >>>> answer like: >>>> >>>> a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5 >>>> >>>> Also in this section, the following: >>>> >>>> Note that while signed language tags are used with a video >>>> stream to >>>> indicate sign language, a spoken language tag for a video stream in >>>> parallel with an audio stream with the same spoken language tag >>>> indicates a request for a supplemental video stream to see the >>>> speaker. >>>> >>>> might be ambiguous in the presence of many streams. It might be good >>>> to define a grouping framework (RFC 5888) usage to group an audio >>>> stream with a video stream that contains the speaker(s) of the audio. >>> This is both a threat and a solution. There are already other >>> reasons to group media in SDP. We have a risk of ending up in a very >>> complex coding in SDP to get this correctly specified in an environment >>> where there are also other reasons to group m-lines. This is why I am >>> still hesitating if the whole thing would not fit better as tags on the >>> SIP level. >> >> I notice Henning just asked about this today, in a different forum. >> >> Perhaps some things are better done at the sip level, and others at >> the SDP level. >> >> Its also possible that correlations between different media streams >> should be left to other mechanisms. E.g., CLUE could signal better >> correlations between audio and video. > Yes, but here we have three media. video, audio and text. CLUE need to > take text on board. > > But you are right, if this mechanism is moved to SIP level, then we > get the complex task to point out to what m-lines with the same medium > do the humintlang-tags for that medium relate to. Simplifications need > to be taken, so that we do not end up in specifying another CLUE. > > I think that part of the background for this draft is that the > mechanism shall be usable in 3GPP Multimedia Telephony . That might be > a reason why it ended up specified in SDP. > > Gunnar >> >> Thanks, >> Paul >> >>>> >>>> Also in this section, the following: >>>> >>>> Clients acting on behalf of end users are expected to set one or >>>> both >>>> 'humintlang-send' and 'humintlang-recv' attributes on each media >>>> stream in an offer when placing an outgoing session but ignore the >>>> attributes when receiving incoming calls. Systems acting on behalf >>>> of call centers and PSAPs are expected to take into account the >>>> values when processing inbound calls. >>>> >>>> Are you intending to exclude clients taking a more active role? (E.g., >>>> Isn't it possible that a client receiving an incoming call in a >>>> language it doesn't support might bridge in a relay service?) >>> I have asked for deletion of this limiting paragraph. >>>> >>>> Should a client that can't do anything useful with the language info >>>> still indicate its language preferences in the answer? I would think >>>> this would still be helpful. It might allow the caller, or a >>>> middlebox, to compensate in some way. What I suggest above allows >>>> that. >>> Yes, I prefer that view. The answering part shall answer if it can. >>> middleboxes or the offering part may do the invocation of services to >>> cover the gaps. >>>> >>>> * Section 7.2 (Advisory vs Required): >>>> >>>> Rather than "*" suffix, would be cleaner to have a separate indicator. >>>> And it seems like this should not be on a particular language tag. If >>>> you speak both Spanish and English, you may want the call to succeed >>>> if the callee can do one or the other, and otherwise fail. A tag per >>>> language doesn't do that. >>> >>> Yes, tricky. I am getting a feeling that we should start a draft >>> describing usage in parallel to this one, so that use cases can be >>> verified. >>> >>>> >>>> Need more discussion for how to denote this. >>>> >>>> Thanks, >>>> Paul >>>> >>> Gunnar >>>> _______________________________________________ >>>> 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 > --------------000108080509080708060005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Randall and all,

Attached is a version of the draft on negotiating human language with a discussion added about use of Caller preferences/Callee capabilities or SDP, including a proposed coding based on RFC 3840/3841.

I am afraid that this is getting a bit complex, both the specification in SDP and the one in SIP, but I see this structure needed to express all kinds of user needs and relay service types.

I also realize that the declarations in sdp about media capabilities represent a good source of information that could be used for routing decisions, so a merge of the SDP and SIP based methods might be of interest.

I mean that it for example does not make sense to send a call with video to a callee that cannot handle video.

Sorry for not providing a nice formatted draft.
There are use cases added, and the sections on coding according to RFC 3840 and 3841.

In RFC 3840 / 3841, there is a concept of implicit capabilities. If that could be extended to include contents of sdp, we could possibly combine the SIP and SDP based versions to something doable.

You have mentioned a couple of times that we could take a simple approach and not complicate it with asymmetric capabilities or preferences in different directions. I tend to agree that that must still be an option. A coarse selection of service could be done anyway. Selection of exact performance of a relay service including the asymmetric aspects would then need to be handled in some other way.

Regards
Gunnar

On 2013-07-24 02:48, Gunnar Hellstrom wrote:
On 2013-07-24 02:05, Paul Kyzivat wrote:
On 7/23/13 6:35 PM, Gunnar Hellstrom wrote:

On 2013-07-23 20:00, Paul Kyzivat wrote:
I just reviewed this new version. I have a number of comments:
Good comments Paul,

* Section 5:

You don't go into the details of the O/A rules. But I infer you assume
that the answer will be a subset of the offer, with the priorities
possibly changed. This is a common strategy with SDP O/A, but it is
limiting because it doesn't allow the answerer to indicate
capabilities it has that weren't mentioned by the offerer. Knowing
that could be useful, especially if a mismatch is going to result in
recruiting a relay service.

I suggest that answer allow the answerer to indicate all of its
capabilities and preferences, and at the same time indicate choices
made. (If a choice was made.)
<GH>Yes, very useful to indicate all.

* Section 7.1:

Instead of humanintlang-send and humanintlang-recv, how about just
giving the lang tag and a send/recv/sendrecv parameter with it? This
would be more concise when sendrecv can be used.

Suggest using a parameter (q) to indicate relative preference for
languages, rather than ordering. This can show degree of preference,
and can show when multiple languages have the same preference.

<GH>Have you seen my request for an indication of level of preference
between the different modalities? A possiblility to indicate for example
that British Sign Language is highly preferred, but English text possible.
The q values could be used for coding of such relative level of
preference even between modalities. a q=1 for BSL in video, and a q=0.1
for English in text.   Right?

That would work within a single medium.

But I don't think we can use that mechanism to trade off between different media. For that I think some other, more complex, mechanism would be needed.

Or else we would need a more complex definition of which things are being prioritized against one another in order to use the q-values.
I proposed a simpler mechanism in a recent mail. It was to insert at the end of the humintlang tag a character a "!" for highly preferred, nothing for manageable and "#" for
a non-preferred but possible fall-back language and modality.

I think it will be very important for most users to have a chance to indicate this three-level preference order between different media as well as between different languages within one medium.

I am hesitating a bit for the type of coding I proposed, and saw your proposal of q-value as something cleaner. When coding, you could make sure that the last resort medium gets q-values under 0.4, the strongly preferred between 0.7 and 1 and the managed ones between 0.4 and 0.6.

You can see the earlier motivation for the preference between modalities in the archive at:
http://www.ietf.org/mail-archive/web/mmusic/current/msg11871.html



Example:

a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5

To accommodate my comment about section 5, perhaps the answer can
"mark" the alternative(s) that have been chosen for use, if any. (I'm
not sure I like this, but for now, lets assume a "*" suffix on the
direction in the answer.) E.g., assuming the offer above, then an
answer like:

a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5

Also in this section, the following:

   Note that while signed language tags are used with a video stream to
   indicate sign language, a spoken language tag for a video stream in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker.

might be ambiguous in the presence of many streams. It might be good
to define a grouping framework (RFC 5888) usage to group an audio
stream with a video stream that contains the speaker(s) of the audio.
<GH>This is both a threat and a solution. There are already other
reasons to group media in SDP. We have a risk of ending up in a very
complex coding in SDP to get this correctly specified in an environment
where there are also other reasons to group m-lines. This is why I am
still hesitating if the whole thing would not fit better as tags on the
SIP level.

I notice Henning just asked about this today, in a different forum.

Perhaps some things are better done at the sip level, and others at the SDP level.

Its also possible that correlations between different media streams should be left to other mechanisms. E.g., CLUE could signal better correlations between audio and video.
Yes, but here we have three media. video, audio and text. CLUE need to take text on board.

But you are right, if this mechanism is moved to SIP level, then we get the complex task to point out to what m-lines with the same medium do the humintlang-tags for that medium relate to. Simplifications need to be taken, so that we do not end up in specifying another CLUE.

I think that part of the background for this draft is that the mechanism shall be usable in 3GPP Multimedia Telephony . That might be a reason why it ended up specified in SDP.

Gunnar

    Thanks,
    Paul


Also in this section, the following:

   Clients acting on behalf of end users are expected to set one or both
   'humintlang-send' and 'humintlang-recv' attributes on each media
   stream in an offer when placing an outgoing session but ignore the
   attributes when receiving incoming calls.  Systems acting on behalf
   of call centers and PSAPs are expected to take into account the
   values when processing inbound calls.

Are you intending to exclude clients taking a more active role? (E.g.,
Isn't it possible that a client receiving an incoming call in a
language it doesn't support might bridge in a relay service?)
<GH>I have asked for deletion of this limiting paragraph.

Should a client that can't do anything useful with the language info
still indicate its language preferences in the answer? I would think
this would still be helpful. It might allow the caller, or a
middlebox, to compensate in some way. What I suggest above allows that.
<GH>Yes, I prefer that view. The answering part shall answer if it can.
middleboxes or the offering part may do the invocation of services to
cover the gaps.

* Section 7.2 (Advisory vs Required):

Rather than "*" suffix, would be cleaner to have a separate indicator.
And it seems like this should not be on a particular language tag. If
you speak both Spanish and English, you may want the call to succeed
if the callee can do one or the other, and otherwise fail. A tag per
language doesn't do that.

<GH>Yes, tricky.  I am getting a feeling that we should start a draft
describing usage in parallel to this one, so that use cases can be
verified.


Need more discussion for how to denote this.

    Thanks,
    Paul

Gunnar
_______________________________________________
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


--------------000108080509080708060005-- --------------040608040603020104040905 Content-Type: application/x-zip-compressed; name="draft-gellens-mmusic-negotiating-human-language-01-gh3-clean.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="draft-gellens-mmusic-negotiating-human-language-01-gh3-clean"; filename*1=".zip" UEsDBBQAAAAIAHiqTkM+uxeRXTgAACi3AABAAAAAZHJhZnQtZ2VsbGVucy1tbXVzaWMtbmVn b3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDEtZ2gzLWNsZWFuLnR4dM19W3PbSJLu8zrC/6FC L5Z2SViS3b5uzw4ty92a9kUjyd1nY6MfILIkogUCHACUzInzY85PPfllZt1AUpJ77BPH3WFL JJCoysr7DQ8fPKT/Pnz4fHp0YH6rm6uiujQ/NfVibu795yQzP9mytFX78MFR1dmmst3wbZNf dHfd+fdFXo7r2cyc2fG0qsv6srCtOarGmUCqJnZi2i7vFu0rc9rl1SRvJq05a/Lx1S1g/7Yo l2bv6cDs7+49efjg8Mu8aCxB+FteLfKGvnrCXz3F1n8ruqlZtNaMc/orn0yKrqir1pwvzU+L qsob8zPtre2aevbwwaiamNOjY3NO105MUU2KcS6X0412Anirq/loL+uuoOsIsz8vZnll3ufV 5SK/tMnVEyBseCmIHM5mi7YYD6tw73CKe4el3jvc3cPjRue0tHzc6aM/t7ZpzTS/tuY6b4p6 Qb/wI7crQmKTlzvGATCVtZN2YPLzoqQ9W/xYTRjKvLEXtrHVmA6jsZeEc6y9nddXthqYm6bo OvxAl5u2uKwIFQ5omxnz29RWDMbSyZ2XRTvF3QUIgxZa0NJw5ItKcWe2xjkheMt0U3qmrMp0 tTmn02AwN/kSv4ebLD+5mFi6b2lmeTeemu0is9nAOHzZHYAzgGybRy3D8RuPt3eD45dL5x4T pr4It0/MPG+6JW3sbFoIpKKlvc3tuOAFFLN53RBtdgLMzmxzScCXfDth9Yb3lfOv9FdFO2Mo xGQdQaet5eZ4QYgam9P8wnZLM6raG9sAa8c14c1sH5+OjndM3QiMLr+yDYPgRZcW641wSvf5 bRFlNwPcmRuik6ot845+of8bW+ZLBlLP6WA6Bo61mfOmmFwyedPSHBrMZMELam23mA/M+aKj rwgP+XxeEsYYEF1e1dWwhwCTE5aJqs02/UBPsF/y2by0jJeKLwHcHBuY59VS9wVUWZDMTqak DeybST1ezOhzM7HtuCnO6aywQhANE4X9QscCrNK+M3MUXyfE1NblgqmO2IseW9kbc/r2mGRM Y/OZybuOLqZjaRlaHi4XjqcfmP9ndlIQQvPLlld3yhJKqIYW+cHO6njRPZlIn7SL8xmYCEg2 Fwtstq4u6oY4dWz94Skv1tdFyzKG4L85ODbPX/Di+MeXDjvpM2j5RHI3Ks4d0jxdu4vNYXVZ EO5wsrLcvL0y7+qGFrF9dHj2boeo/mNNDNdN887U4FBzCeXQEtstTV62tZkUrSJNuHXloXkf Ay3zkjUkGjom3UXT4Ez9VQxINwIa68y06+avHj+e5IRpCH/bZIXtLrK6uXzMgrN9rFAe34YR vjRa2nVeFhNzwewxy78Us8UMC2qLL2ZWV91U6BrYxnaJNxZzWoKdDIh95mU+xk9gp3OiE4vj JK0hWIq23xlH1l0xI6oEWdKuiop4p6nnDcQVeAdKaGXREMAqrBgESTs6rrzEYyEUCz4cO9PH 0jlVuGkLxwDioidcku5rs61bKPKmIAq0rCVB4n01yRg9qOfLpricdiCIAqthcOHj7fEO61sD wiEVvWg7xhwIjiRMCwommV11xUUBbm2FxPv/qSVh+n9Uia8srn/d/xxDxO/9LtA2mCObVXIK jA0JMSJ4t1785ItuWjcg5BGhjhGAkyJhe20n6yWWsP0fJJ5wcBEjM0d6nD1qzXtSuSVDOA7M f0LymtdLN/PVbz2FbSt3dLjf2sAZovbosKrWDgsSMDsgCXtxgUXQQePJoGfQ/Jw1kGhkJ8jc 2jNZTGlhIjX2uiCpSffSL4HMx8RfkGTLgR7t0stes6wXjSLJMxQhi8TGWKwnlngN61TGTvp0 UNnE0l+kaCs8TKyLL2z4ECldkG2W3mJmoL6iGpcLuvGUNHQpVPfm9K15LwgxHUGQ5bR+qSyQ Ty0vyzzNrJOYQs58MPGhsJJoIkENexWbIdVOdktDGpfUeR8+AK5fE1POmVPpBzVMYGyXH7CX sVBr6slC1pd99X9mnyHtQwDbZlawyb00d963BtJThvQkY84UnUvG5533rYH0A0N6ypDYNGBA B0Rr7detTCEBFnB16O2QA5gTTCWk8GCQmtO5hRHFpz3P6e+NkPY3QKLbKoL0eA3Edw2r8T4k 4IrvJwLnfw/YwBFwJ4u2LfIqBvM5O03W9MxDerphTcQ/5EcNibRykpUTNX8dyXl4EaQfNkAi 2/pi3e19PAkkQHlrW37mqSVxSgria8/uOUN6pqaB/UK2AaTdI1jtj4JhdjdUhfQ8Y/E5r2G3 nToz7s67E0gvFE/PmZ4+ktR7RN4U2cVY1LAl9/QRi4D408aOrx/FhmQPEuhpNCEBUpMSu4Zc /8eCEXfXauS/vV0PCfQEY3SL/Ktu6847b4EEejot4MvAktU13/+/vT2G9ALyafRxBLnVkiRs 1DW+8/4VSC+xHksGXUHS889BU0h7u5k5IJuIPFMh7GOoL7jFv5JJwgDvhLSveCJYIIMEXOq0 Z1k23N0Ff5N3vrrSGNL+PSDtCaT92yE9uQekfUBKP1cA+kfDDbqBu1CyaSmgo7VhjDsQo5Ce yJERkkfjq6q+Id/7UoyLO1exHhIh+SS4+nfddQskhsUyAD4axzAiwHdC6UPC4R+JvweiJpvi a6DtieodsQlK5uJoMoGFf+d96yE9fNC3K1Zt8m9pme9/B8uc8YGwE8ITfOtifkvAiQwLYf1t CQJAiNYSUBEviky5rh7XZbszuC18pisliOodIgzB5r9bTohBsZ7gH60BbRubj6f6OHLlJEY0 hsH3pWOXcgHXmCGdc7QrkIth01EjH245A3IuCGC8KLKHu+W8wEPF/azqzi0RJ65PR9yzHWj0 Dd62RFPgFLuInwT5Bg5JGgAMQT8N1/ng2ySES+IoXBx4Y0DO+xG8PGqTIFymDpTEdua6ZXpQ HQfZPJw1kSeCoLTxjjbj4qENeTF0+AN1D9ilojXIc9VPr0PsklyJsitglUqMqNXI0aS44L10 GgzattllNjDXNVnyA4FCR0kfkO6qiY4KupAsO3ICxfkQfz+HazzU6FN0eAxgRsYcjMxZZs5u ajlg/5lGec8tHUTsVotHEjkcTHiIrcHIwCFn5lPFJx3FtN4eJ04rRyZAoNOcCWIxOwedXtDj KntRdD3s5R22R/cR8i05dQxoOzoz2JUb+bGNCUc58u3xjo9Gg2zLYlZosHT9IRM5t/VMovit oCo3F/mYD5WWVj0SX0/of0AbGec4gJiHsAPwZuU8ysCR2wKx5aCl0JxjbI4DtS6+y9Fc8EuA ypFWjWYO5IKLpiDjUcgEgdeaIOWXC4t425uFw+aYPmxIzNE6ybOGHU6iaBmzbcakzWB8WBVo IDd5NbIaR1UlIpxEnUWprI88t+TQlhMOycM3pT1o7oNwdmHwNII3q9UT5tD4BQF2ciPOGDz2 ciWSH6BYEQ4NrnexT5WXtz29S4WGOCsFQ8xDQsMJGUj2sfVkVlRDUGIdlrLd7ki4j3kaIrd1 jHFawKlj4CwlnZIILMkL54i7gVE/50jE9udDOkg67m7HEyDzBGsBd4MXjk2cTHlNjxFxJRtH kqz4x0KRw0hxMY6cI8jF5aJRjeQWJbGVnATCRU6STAMaDMFTqAY5eOXMpsQ4VnREYCrCpsFe +LGE6xREQFok5FUp5YIu97HGW1kwCr2I+JMzyfspJUc0uXG6MSe5U/fuihXT4x59hYhwLPAV 7Rv1e5wlEhdYFivGQ1AQfMo9vUv0aefIXlZdhFz8KAsVkYBoIWkLyWa1kp+BmK46kRKsS/xV Gl9q1vF83raLGYiAjxAn7pz2isWmunU30xrMmV+1LnwhBgZJHAhZF8rwEk0WwIyjaK7M0YdT oiWsKONI9qS2XriSfQLZUoTsGbNK1ZPZOEM8T1Um9lqZvGhIXGlmjAOpgk1SZFc7GhUIgjq2 hlYw544KSx3nDcnaRjJWdClyee5I3FHGh3duuxurltvnw8RK6ThiJqYp9C3nBI+ciaPH67WA 7C1XZSGbGwS8aK4tX3Q19sFGWpIR1AMa8nm5/AztneOh/af2MSwPCoGdU6Gh1hwdqxDqOEGw fXh6RD/v+D1C3LM1O57WtZgpyDamatJJ1RV+l5RhPiYZgWwoLOCJFbQBaVMIvFp26YGwRG7b gBnN5K6RLCI61dYea1jAChil+XlNCm05FMsGD8Jzt4/fnOxIHvHb+zNPvpc/82ZpIOH4zoAM sJMYACEkJgZYYkblZa0kw+Jf7+D4eit0KigVIcrWKVlEJOuJQ2riCtGzQnNj1pGcJyB1hEAD IEDStI/0TLxzo8lyZ3kVm00UAeBO0yl2pnZizGsyFcugCIV9YfDKkiKiQ6hIdJR/POwAwG0X c2Tm5XHM80TSidpqRd1VzH14RCPRuERi+8S5+I4ijS9ih7HlLCAeyTZ57s3VYDiLWEBot/Wb XehqxrbpEIOOiyhGesqKM3PjTSCV8STKCw9KNBPjTuUcB3BpUdO8mQzri+GUTEmR4BO3ySDh VZXOy4X6ZaJq9eNtsYmJ9Jw+aIgr6mvk5o35wNIpolChLIHjSZR2X98Ik7daxrNW/AazhfBD P01KQRGbXedLVYJOhcdqQMSEuxsmBq4gHTyHIds6JMEHM3HidUK2KkcDnJVw4gteEi3NLs/t UlcR64R16gU4S2h0+t4527B6SQ4btUGd04VKpS62gGGUFczYkZhkJZG6Frrn1C+JIaXuk9uY 08Mv9/aSWD+B29vbx0eHC0KX3cnUiuJLgHl1QwapemCHnfU+yYASEhRnA2YsLYylvEwAlWI0 BECik5zZ5zWS10MhPEEITtg51T94qtSyYA8pspwOhZeFByuRxQ+XJwtDA3Ux6SaEd50XJfMh O4lC+K0pa/Fud5gjcdSO7XVNAKgUVpMH1QTyKstYMxI5ZUElzITdeOXevY2NGqL4YVcPLUIi gbGCT0XuQ+uSvDfTgohSbBlnX7Y4d1tdSlwnrFGIhUE4TdFaejB4KLjL3sfidTuGHJMnExmF Wrw0IRkEdbSOpJ2Y7VwUTcx0d9BqxAS5EVDhdsHp4eSgxDJctx86II4lSCEEoQdpsEUlWVaX zi263ibiDdzBYoOwESGwx0xcMVU48mZIiW+SMFZqYw3UzDxfemMHXwr5QBOOF8SAQslJ9Rh+ YzoUlytFuqq2UC8WYkNiBZutCPdb4PVFq8ElMhA6X4iyFSokt1zEhQH1NrYtDttj77+xB7jD JRNEad3Uh5mi8rnI2lHOaXPS86gW5DgNSJsdeFC6xujYc3wM5fZY4nKiwxu9fFyTNlCLJVgr dOg37PhXVwC1JtAo4iP4uqyhffzF+zaJX+PjQVN1vGdajqcmRGuZpYOlMuUgS4t9sgs3ENNu bptpPl+NrUJAamAmNxf2BvV2RSliZ/N6lAPUcBJCuii+2MnKerLItoVdJDGa1pZcwjH1/vWs bjsVZ/34hnGGqz7Pcv2UFwdeUr9BxBfGvuwsCgfdgIO8IPNwb/LYGHaBZC3eJMdhbOfdgm2+ lgw1cIjKBhDPiq3MkfrYXBYR3yQBbx+3dNpUSwSXc6sRWJCWOCG98otv7ZE8/V4eCdj/yi5R 4kdyaOvD59OzrYH8az5+4p9PDv/++ejk8C1+Pv159P69/0GuYDj0wafP7/Ua/BTuPvj04cPh x7cC4MPov7ekynjr0/HZ0aePo/dbLsAnGsSXYzWiWa3Y80Rq7AT16m5O3h2Y/b29l+Z/6Cf8 8DsfBxKocQ1LHAiPIsihtlSexCKP6PXj4ccRL/LJT8fH4Ar8rgssiytbcvVyiH4htlvJVbsv kA7dLp4gQANfkuuzdM3e5w+lBOpHMLO34I6JBk9EqQiuGEG5JJFAygmm2gi6ORZn+Q07yyex s2ySmKr61iIN1t70TpUlbR9Y6GMrbN4fXTDVCTKnDfJS2J6tfueq9Axs912w1SEkzMEJq0XO YMpRn472VJCiFqWYM4+K0aRLzX2259ziaUn5FiBoSmRtXZJ88bVFRi6QrAH6KBpXV0Ql7jZa JOrLGLFSnARMuKCcltb7x26Tjb7D2NEgmUTYkJzi0NuaYKk+KPNMvdboXRtKaRYlm4VEX2yw wBgRKlWju4s9AfhDZG26SNBYPLd7hYGyZGV8bd9S5KW60xL8EiCttq/cLn0ALbZ+4J04s32Q BL9Ew7AWa++C4l3U/qo9oJzTKbJwPhKNxt96LNExKrP4WLOSZx/A69gqdbGYuE0gap0oquj8 +dtRySEQJOZQvdndgfZxLQ0DLEHcRuOQc/ZLhIZ7ooCB3IKG+6FANrsODZtQYMx2mvBUjCd2 ARG7raTkUxXJ4ejgZ/jGZzV5s6hQuqYtsiGU7Yhs+NNlg5uFBCe+9X7enoOxDQdGzCsf2N9x O/GiRKsSE1lyTzmitJwSbakVehdFQyzu1rU9szkHe2H3BZsvZHM7yIL0jL9S/CiYWAQl4gdG 2L1EEAPyYujPiqCY/hXHruOnH8O/VQQ57AgOvAi6FcgaCeSF+ldwnz9LfZbs3HPTvflvkwj6 9lH3H76DjWtWBKVDx7cRlEY1lOh0Ms/ABYSqdULodgEkts9dQmjtiqXGp6rdyjVmqL8hmcep ORwcQ1gfWqP1I/NOpmJPTCc9bdGehTFivUAuft3YtIgpCdeoOmGqHagEmtyXoPlD2mVIccuF uhiSeE74cEqbjMRqER9gXi3JF4w3JwznHu+3BUiRE0+mOgJjjlVjae0c9UT2BR4T+BIbbCVg uS7vgPPCxxcOCUpvgiApVoKFvHDmNMNVSxaezoHSJ/97jwp0R0n++9Z9H5mp3VRjxrF28azg nJB1YQekd3FNUUniJT9HrA0eOPlwi6YyFyX6RiJsOSgMPYo1tsu2szPeby8RGZOYyHxVClgt 6wTbBos0ZmIpLynLEB2BmBf2Y3T4pOK/UpS/RuUvUMXk9LumdPqA1mhxhrP9cm/v3h6Bk/zu WcxjiqS8HKJjLUkGccvfOkNtnRJnOPf2IzafV+5TwHpy7R0uxaou92rxLnXuepHizSuX9moT v0rFijBdh+wNiO5d+1Uq+Ra4f85O1hOX/J+L9nsoQ2+M9GwAfm6SHEgv88JJzyahTNR13NRD EsMDSR86QdOzf2wu0uU8H1+hNxW5JvzdqtD7yhYXL+/i7z1Ljmaob4SURHLPGxXbo9P3O5td 9FsZUgqh+sdOAL1ReKdyc+Vwk/+nvCjpiK9lxEDHd3HivZjs25uWz76PaXm31N1ICBHOGBmJ kZBmmUP4s9nsQDOkdRIjXoByzzMeKYGMok9qhBqpm1q4REo5REa8aUhCttN0XQ8fYCm4Xi5l Dy8en4FshTydvVxiel8QGQNNuC6TxABrJI31RTClBGA5t8FPDqDB75BNjAQSLUk9Caqjo4rI VoqgE9h8H7hgMaNbi5oblTop6dbiQ/dQTh0qmgdaahcqZHvrLSqSv9gwX85HQIgrFO88e8HM 8xaSyNUtGAxNGQv7othKEpL0C++W8aJi1EzJkkrKtfDItahFiQ4jAEeWS2dCJeFcSXpi7EXF efGQ/hap4NKlKDguqmvCxSRNLyphPRdR7GgpF0qSRnElR1ezoh/CIP3l4YNRoDn5iM9n07b6 7NGnMon+zYrJCgR3gFLGj6vo4IRbokszLMgtlNe0bjVAIycm+XamHs/6Xf9c5GEpVQoYcTfC 4jPzsdZ8FSOfUTsSYvFqt4dFVb+C7btJiVyKopURKz1rua3La85mnC95bE61mkiOVP3ARLNK vGND9zgC2HhgDnd8cDp0JmWx6CLhG/NboeNPYqKChw1ZsWIZzXN0lETWFOdOx+O85TwBc3UR ijPWSZaoajRQZ65x5VgoC/G/MG8gLaEY+cpLbVuqK3Zt/A0FpzpGJDb06vkUHgLu0fSvkoSn uTi/KsjiPZOeyi9jjbNG8g1MId6OHKUYe/LAoJh9q4LDCHucVS4pFWNl5QWmr7D2CZdD/85z 2oUYBlMebXFJWs6yM5OWh+sJuzsyIxpkUrTjxtJn46UUuXUqlGQ4TZCSuvXKYVTQ9NivIDqS kPnppmSLXE59v4RYS3jQ+pE4YjLJFBuu5pVYHNHnrCauLJd62i91LBNRfugaOpgWvBJiW4n0 NSh6FG/al4ShIKJAHnAkdKJqyd2rWFIQ5reFtwQ9qXuvxesn173lgOg5/opAkZSLuG+AwoOc tsy/oX+KfiGhc1RFzr0rR3U3CbMhJEJ403Y64b8p52PHZS5esF+Xq9Xr7ebn/OpqIef4B4Yv bFikokiNgdiwSJ+iu5dza6xTV4RRFSwsCphqYt0r+yT+bIMOlEWxFBYD4RLGtmnyOakRHo6h 5+TFWFt0i1CHtWR6aWkNoQkw+sJ+GXM7r7mkZWJvrTcg+MG6XpgS0kkBcWbQDMrUCx5ZcGWl wsTXxT+jKq1zYruKg/R1VKnvqHkpBXaw4pkiWYov5ywUKujynGX96lEwyjAtSA/fla7GE73G Uzu+UgnLFdzE/sTMA3NhSdrKUQl6wXxcF0/XNTA5IP8yM5Li3EbEhHtEQPTifIixTJ6oAi04 +lXR4OEQsnmOSOMT3Z/P3g1fcMXGBA0U+EEx3S4uyGpDM4+vufs17+Phv4yw/d6ueQtdkGo0 Z7ekme2HD7Z9MSKL4XqObj4+Ms6on52a/f1s/8WeWCIxSknAVsm1zrpsd0hwXFZWG5Y+QFIL 1Z/Z0kKyL3udsbw48QzMrD5HvZD0esiHHz6cHb6PmWr7V6HFkSfOE6jWM6jWM+KnHWJLzq6z UhR/0Bv1KV6ShQy4zgkCA/LDmRMoQSIDuNWQeC4260licqDOR61OLsUSXpeidCZzKYsr5rmE sVdq9fgqqWgvKv2lU8NvyHl6Vokt9Bstwps6atIQsp0xkO4vslvcZ5k51V22bAJX8Lq5l5Ov vsmlbpnl1se6Gv7KGnlNVwcUhrCwusvMvCipEosQNPBILmkgciAZhanKZbhJzj2Vj6LFU6sO 1VUOx3yP84AyHoYUS1dwmRNnk2Dr+6u0Wl+eMkNaxHeJamcPcCw07KypdDGxIj9bEBt6CDi+ nlMDEHKRA8YbjwJKHxAfSCBw0FUWKK6DqgFdIElI36DphkeysGBIIByY2BK4iLSAez4rnRRi GCcoHiGtRfUBSZs4QeKrzSEGabXE9my7RV13MhkA9ac4jzEsoSpH6a7txplyrVcLHL5yKsFT orOauRCzmHFg/zovF2zLux2TlG7rRTNeWaPDRGY8IToboDWr2vknixF4veAacKVfBF/MlQyp wX/mzpK5SQLlzKxuuGHrxxBiOhVnzMZRxiwMQeS+KIwcLbhJHFpWFyxVOj3DRVma+VUNK1kr oVfNxgGEnrRfI6WgDZtA8jr55WQOeVW+QJcDPWtxE5N/FJrfuKrgBDm3XXBH7kG5bJFkmEqf Rt6pClWfQHJcWrqeh7QiZxPd2APWenvi2LNkiH0Idh/UFGR1AL8RoaFRcpn3oZGG9OYizHEv SlP3+2cvsh107Y2JHjJQSOwHp54GSUFbXOOLj3VzQ5ZR7nOz8JN6rqK3v4SDIfQxyDG9HV+t v3/QN+No/dtBtCQDZdXE8WAHjJHkow1BG7byCw6u8PVlMfdmG4dr9WlRBQIyxgkdBEdCdW3T V7Ny6jjWCzyr0KiYWMGMmXFTzDuXyuXeXe27FOoM24gzBzy6E37y9o/Eap2kvDtnr+woufqg k8+LgjdJaNm56Ew3/zA9FU9P2FQWGfigfLEublzoINy5Zh0Rv7Ii1NLLjp/b+ukCAQZbYL1m 8yRsgAgGaVHid5e5jSwVJJz4D3gMCY2VaVsaZcaGJvqdn13Kz1aFnDYNuqmWrfV1j5q9kCB7 F7Xas4pYreFOC6QRFgnVLB6kkfj9Cjw5sBgcW/UMr55wiaaGsVs/VkynooT5E35AB9SSRsry aD3RMmRXalcwGKzCPVyYDoF3dvXpOCbicweRAT02Yl5g4bfmCpPTEUuiSrdQqAHOw1LlbLLV mRUiYKUxIqm+5SaRdjkj9YvUUwkOKFoJ6fsZxF2zsN7nIQ/QqSheqVWHITPHVuZwQkKWtTjV ReNDhCIstQGmvoDakI0xh+blVdREoL2OlShuQoGLYYn25XRchjGHXMYSbyDq483nc3o001B1 XTR1Jf1hkFa8TpTS0yOKlgsfJnlzxVEw7NPCTIKNVWIWOEG4ssvzGs1ZAEw2CNGCVBxbbWlN 4wAufI9zrqyGtcEtrhte4yLsnYuoIFTUXNelE6ntl3njbLtwf9/3j7RVnwwGhjzsCg0mXC3n 7UMtOlCfM8JcRGYkrjI33gb/PMuiAZnuVicB5II95iQ/Wg91cv3xegoQlfJPf3j2zLmSVgoH vPDQ26TtQrKtccXSjeOuoCaAvYFi6sLtQSqv3fyY8Cz+5FH+Iz/FARLZLXznhXQsFoIg6O+q lScpw0OdMX0Dwoz5CwLQ0faNZc+LKYTEFvbj+zxkxyIgZYbOQgbBi8zSzJkRDo02qpA0wuKP gAGtTDgc59WjzotltuGsj8lM7AWseGRfb8I9WST+Q9LdnyL6HfDD77TiV3opUpKM4Ff/6Um1 yy//Er4+E9tP5hSYVrp1hyWRbBmtNgjb/leZAzRqN98/6J889JdMKgnJQwHj44TaN3yukQXt 8Mj0QbIWs+Y5DlD6uET1iFYEhAF3ODeS1s5Z48sGHBR5QIg8KVCs44MjRHwbk2HUvmZMCDzb opOOfr+3WjM6+pQiGVjh7peti4nlb4Bwm8XPZ83Gzcva5IYQUzf1q/A6jBVyWGtsAUaazrmn 3lV0cNx8raBNVYKu7ImJkyVe8HW1go3xmsffZDFBWrMF8FsR/bHSl3m/Qqd0XrRzkPyTXZB8 TN0OEoJ8p8PR6cHRUbgyc5O5xfPw81s08zPNG5K5nnc8laNWZGVV2td0HtGFmN55/xALFl1R YLEdky/KIZ2G1Bap1fqSbGo6OnMOQZtzhaFUGEfYj+0x0kTFvLAylbnCboAZHhEj88r93f5s tFhcUJNHaYrAHS5MgMZmmBwKkLDVzHzo9xULHaATG3ND0mFY4PMfnj0VYYQfpPnq29ZuPP8O tRuMmDAEv/Ot+16RahSaD5IHaRSSCxbFgNiMhNnEJibbQeV51ms0ldGZbU5OPUn9xg7bYj78 MpvPh0R83XD3qfmfo+FbhpJtuup3rmalL6Uw0E2P8AcukwRKNaGvCwl0hJvghjjNi2weU1ts UbuhEBfaJRyXsByR7UbOThgn8+kX75PVvqqCbnYXDiKFyklmJm3CsmIoUlbag/XKbL/b2+GR jRwpaDvyktpUOrpb+M/Rx1+Pzg5JLMxf/bEoC9v9VZGSjdGOcXT8eD/bTe44q1+Z/1x//V+S C98RS+ilDWo3/ZVEeX95TeLmxx+eP0vuOJUB8K/MpzmyhrxTmDInuP2/kksRRBkevX1lnj/d /2H3eVWn38po8OEZ+TevZDqiBA4et5M5X5lcPv7x6KM5On5q2v0vWbTK5KLZjzPCILPRk70n 5uzg+PGH05Nj8+/JVfmPcqJDuFbtK+6lJi4vqt5VbFrYtZ8WXe9TJOBfzdoGQ+x7K3yFtTzG eKfnezf2n13evu7G87Vksb9jfiJ9xWUASnRe9VTgaTrMRzAFp3l50aMSpQNi+l0i2nuTgxzy k6f/Ill8n7P+st9m0WI3nPWL58++zVnfeqq9tbzCUx+XV39Mnzxv99v93Zv9PDpXcVNEdCHQ Yjl6a2EsBbsjzAFJXBNf5Z+6B6sz+IvwuoDXZoGYdbeoiH60UYJh3OorOVOhEBvlWbbPYkks No5lNYnzB6HIH9vEwXca8Hm2ZmC5i+uMuCE1enZr7cxlACFa/dSm8bTW0pvgtXBUgeGsmXPH EfvOj+aMpXyrwZfIPTRGLa6oCz8xsRCEXaPsZYd/fox6bCt8K2vhxfeyFk7yzs/AIAUNk9x5 zNZ5cFC08OHWuk7ahAjdxkFb6IgIO4/MNqG/kWjwlsSM4jN057El8y1WPdj+AI6+I7sdQduJ BjpFDq6zgrhC0K97wMRIJ6ppiy0+3i1nEDAQKQrhL3HKWytRQb8siUvKXOdKHTGJLIaoPS8u shPyH3u0tdG/Ta7EStZfeZiz01S5YJV3riQbFgcWV+0k570chaskCrLKARq9RFVEV3RcPy1v SFJxG8V+xBnbls7Lol3pteyFoNqAejbrkeJvYWoR4vHskI5c5cA1q2JIurLVVa179upzo0PU QaMyuDcYqlqK4NbJQcbKiSfOvAlJMCSu6NBCpDSpsx2msvT7Z+QJ01qf4lgFcDWN5lM+ulL9 mHM4O4PIpJX6Q0m5MJxFxfG5lSnb0sMrzqHU5k51bo0i2vnM9JGcGJCqYhgPCQMz2Lm0XJ4T kC3cDb6EC4fxP961liLOrr60vCAdUyLu6ZK3pWFJjwTJVdGKfl5Ul1w945HtEOIvOYb6vFxY l3riOWvkDK0sg84DDQH8qiCutMOLs8TDJt24kzKMpA0Ga7ilEMJaTSDwp3ybdp3JRBvsZ1uw Q6tlhhGKK2LXZDV4wZSrLxBc4Y6dwQa9tWl13jBxK9QxGa1UbAhO716mcOCGpa4iyyOVRZmo bx7acl/lnRn/IcNxllRronHk4DumMdBSDBRWxG8cWk2A+EldeTQMJAybFAUyRiYAEZ2lgdYc XjZkfWoHw4Rts7Em6hUJrLjQ24d4sL7RjT/jBH+UuOfErJwHsrOx+kxKkQg0q8S1Jst6slAU hxiQe9eVhHCFzho6ObGYaU8V6sewsvoiRd1r7EskCE/dGeho8GhSjmcs4WTNhJIpWczIBBq2 i3McLOgUQiOqQJBv/Pg/59CjKFeidVqJuUPSrHR5jkB1M37r2zlibzJMie/mDgZSCqS0xR51 /QB083ptyNhNiFApdPTfvq0jR5Vw0V6xDuaXwuZuDACWBC5xVXxmm2w4K5FiqS/Ge3YA0U0R dsB0vb5g1ri20GgIlaS+OPGeF6X/WAOyjfoACT/ixCTRm+EtNkQHmhh6Tg4CMwmSSL3RlY6g tXLTIYpfIoEYmtg+K1N+c6lSS6fC94KDfl0rsUCJ6emI+8HqnCsB/W1t7pffweY2Ll2tHBc4 gdMTrHPv9jicSZK+vWkbZSvXdUEUNzsvLhfEpF6chqCgZI76g8uZu1x6yZVVJk1eyrre+k1K BgdssyQVg8weYmUmcJyJSDxAh1T2mrvitkFvb6yBvJEhNJsYTfDsbwP+qKc47RB3aDooJRYN 6Vqhx0FDMJL2nWgNtURUw8wonjcXDnBF0t7PbcTTAl3L6iLaVrq56bEZyavLmnPZLtWEJi4e WOA3GT2Dbw8mp2/i4rIkCAHuTF9FgFKuSBTpMJcoASrZVjGytjmTYajtKNsIHfFFxRkDXYd4 4JteP6ZnxW8G8UkZN2M7anrjuEk0vKtNpr1DSIpgjidl2jBXwk8WrJarJpeSm3VjABmQSOFI c4ib0dXOgFDDQ1Q9D1wrpnU9Afg8sjYF2Lr3AA2Slzm7Ph8pakgFLiE1TIoNSBCPXudfRmYN IpEuaRmUiWMwoaJ+OVqCSqaWRjZhQ/nWvTTPz/UNyvcH8THQLbAB3JA+rGZaV27cJ042rKaf nNDueGjlMBseo3tn884/gwFxTcOaHmVdm8uzoxyqQQ1HZ2MOwBPkrPxTEtUbp7rTec+ueq66 7O/FVfwMYq7HYM9NNgRoJ1DoqoChp62ojsSLL9rYbNGGiHWitWddeJInxzXUUyCsOJJIrFeH 7ZLk8BfYNIeSPeZGeX/YE6cQyKjEmXnpVbRuaKwjtzUToeFty0BmHfon9eG0LJ1ouGIRqXh5 kvVekI3aIvCrtJy3cViTIes/x+6NW/F7jBlQVKHWxa9ligz2zazdvjZJoDcIIic8chOiiv+y jaPvHt79PjZOSu3coOZeQZMiLWYR4FCOQEN8PYEUB6h9uRA0jz9BUUlkMtZjGXV6Udhyou8a DCI6DWqbbc4Dv3i6K8nANU9zV+ztZI64kelAJft2asHqzS2asLSMsUrfD2NqroJgCa7T7Sfk OiHdg8NeaqaLX6gkqglaTBOOeDmxr5l0CYOAQ7oyIHHV95IwDHII7JnxTX0hq5dw3VqYHVqr 0TDvIu0WK5+V1yT5l7DEdl0qXFxlQeOn2Hs8KStFpQaQ4JisEesI+gzInHmPrjdgTDtwC1db F3WwT8il1nc5s80dn5BScKgRFT82Wox0NffemufnvYS6acxf5t8ikC7I594Q5Gqrz5ymzH2T ipsTRCaGxFlCrQOJkHNtZY2GRse0FuqhWjX2w936AN/OYrlLwjl4vsmaTVLOcROmJ3WwykUH CvgJR9FFrstbD75wDV7pSkv5YiTYuJ5DHVbX7jExn0eZOQzPhzoLJfsSqnHTP4o1Q3LBlV6g 7/HY09rPQol52Df7ax9IKzinB7iBLUX0QpH46kqKqpABibqAOVr08MFxjYRnkbs0moigqKzF hTDUWnNygyWTflg0zLYaAtBDXSM9RMKRQS3covGZP/jtZ4lEU2Pgswz7xY+SROEwcgLAiT5G IdspiOM1tiSSqNz7AuPmF+cnbjHdYvQxCFmyJltM61uCWKLeaS6F/dIytq6JpuM3s8tTispP f0gUJC/Nq52VemNfJ69OK+7Nh27e/0Si/3U8nZzdYKVel0ryhJrze5fI62QPR1EM42DLAfhx KxNbwNU256F4hZ6DsTIiMBzsnE/35PCno9Ozw5NXuNX9wify19lSX/0kdQ4PH/wfpRJNzeOi vfSqv7BECX8Y86/5TF7jQF6H1dpqYNsByektp+pN7sSjx46Ef6PZGAnhJdImZFMd6rVNNcgt L3JgBnFOKgDIYtSx8FCR0FOszCCDcFiai/w6EajmAEIVQeaxTNFwfhELKS/fcF6fT46ID+Z+ ejWvktai6+NtuIoOPox0/a/Mv68exNbrf/y4m+1vuFxOL1yPI+MbXsjBncWdyq75yfJIDuuT auxDaLW3906dPKTjQP+333A8AnHhx0DIu8PKgHpVqxJHYSRtmi0VkwzJPN4CYlBc7XpBj0Sp vVOoEc31FxZmuPDjkpnTrDi9fahdCInAMJ9YGwlBwJSARiDTqUUZdwRb2+wCRaq+RZ9dK5Xk pbgN0gbQq8rgenl5QzdZu3MIjAFaSC17mXlUkOi6nJVYJ+JIyft9SLNE2QHjO3JX2+KiYBtL da3Q9rUlvq4/lzHwmp6Ln21CYPViUaIZSpvhzqRrkraITn6+0TUrqNmSgAmr5AYKIZsvnGVN tZWKWXAbOSu5MhKfZ5TOY+PMh3JCt8MmsZCp/F20JnrH1I0U57JiccSCRt1SQxs8RUle/SCP /iq+3UPp3cMHv2lA4L5PdS0msCX4QSD+r1uOyPZVOfLia5YvYufhAx9ribfAq4C7LLE7NM9g wS7Lx0sF52qzo2sqmdTcRuakpq9ASmglE+EF82wf7/92TbhrTDT2FX0PiTYCqcryoTRYtOEN bBw8j+6JwHGEoQmVH6Gzhu1eDUXAqktJ1vFNtyx9rjUEUGLrIMgDrBxFT2OnGoOhyFZv1Hwc OauT8H4Dtol1G8t1YLyNu59J1+rtuHMtaYJEZ9wFW9eX88hKYp3OAUK2UrQKQcnA/47o0cMH IIrwFf8mX0Dbxj/6a/xoGNDcPGnWYgnCGkCliE5ULcLkJCFShxBGmN/O97SpmJuinb+ON56w mVEDaySvaOJk7cC5iYWOT8I32kDXk2yphHUv0Xul/vYmscAYe23So5JPZbnmWwgOqZgPOser mjZqGvDclrc8WsZOegM1Lb8ZB2cuBR43Dpx+m85ZylhejXwjd8Pvc5xo/PS6vpJCkLTZ1yOR y/7jW9Z1xt5GUyK9JQfgMiT4l1NAKcGNu7+OO17HBmIbd3tyhV3ej9DcOYZjXCW0/68wYyd/ EjH7X4eY+3Cg6bOgeJlJWAFkqp65t+acL+SDAGQdj/37OCOTGZtWwxqegg95qK895wKOHvoL P4gkkuT795DkiXLic6/6Qw26OpzUqj5zUdT5okHBLnt7a8AvUGKt2pYg5ZyVkihe5PoOiIW/ rHnIzarGYlKIMg/u1K5XPxVtEWdMPRtcr/t89XpVNNern8q1rP9au2nV6qr7fQNftBMelXRe RIZ1CkAscUkKSywxuTaJVbi3jqnNEjWAczQxSNQsDMvZzLMR+0WP7xtP/Yey3Z2aGh1HagSa mmpCn5gRflrgwfJGbtVD0nYWvXg3WGFmq+XrMZHEbkX1kQ5nDCDoC5/gYEeIzqkNecU4/Ooi psFhYECrb1+XXIPGX9eVto5cFt29B4x9E7qCPc2V9a5bIcNZXSXqJy90pVHvvgqpyUApin8L ecPGosUmgBpEmfsV79GZki6P6eoxOpmqIk4Ut1+4MqniYpOjXkR62+9oLeo0ZO8rqPzzrE6t 8oWYDAdeUDry0pegjO5fIQIf/Y9F9FJLvzYhoXVFIh6qLNXXqSSlIXL7anFI56tCkoqQF2hU h5ZwzVowon3qKVBygYqpL6aIJ1tCMsxdj0RIpYjr+gL0Mvo4AvhQtuB5bMSvZTOkxyeaJZJa AwRqJhP2Zly/m0YoHxFZDCWmvB3qR6RUH1y/88h0fqTpVF48E3kyrvrMWZv/Mbz1z+rXaz5h QP870edoC0o+cF9/xAmGT058JAuffOsV9VEVo4m+7hXu0CfbSWJ2R1f0NYCgmjYC+jZbe/jg JRfxjRccgl1LWCDfDVeAMFarabmFaymW/TbY3TM50xGZ73TljhSPOx934ApqVkuglAE3lu6z 81BKfgUBLVuynEHJUr3odChD3JQsjjJn9+l6JwI46ZKWdnbJwH/nX4s44NcXIQk7DXUoRRiA QQIE5ZyF1Fn0GIdWzEDI3xZR4NaquvTbZOn3vkOW/uGDvV06uAOe16Yp8mMXz/yV9ubohi7b 618o7b+XsrlhlmXD3V3geLi7p6RWuzsmPMYN9LLtrIaddCKEgARR4AC3TOiv3wqEshXgjiYw 2kMFKuefg+Vhtr0qgOqOX6DuNICJ87s7fcgyu/CAXx3/CepaY+7968DD+vjkXTZzWyNCDwWw Ot0gAPlQVC4MyPO+fHxYkb5/D6TvCdL3A9TP8wlbMzJagx6wEesxciOchyxCKIFP9y2rlcDt mqdoFxkq0lxAUDrK3BOizsBcw78aB4gzoJFx7rbEb+cEszpIIRkUuiexmnVjluKqeTrUduHH CCBLH3/LpJF95a7vhdtguyGCDnfNhRBl+7Uo6NRJIePCJUg9HGdicn7L9Z5kSjhP7kE4+xy/ TT6fzcjMGSszbyCoTl+QajR1zNqiiVoIsQ02XxKb3xhfwe/r3N1w/gjRH+rrFcbu0VA8zWXB 3vqWa0R1T3L9qFtEFGJBAktcjFrfVP7DimtJZJxPoYVWMifXARLrLS+zDciQ9z9tXOAKBbnU 3UIr1troihM3fsKbjDocJGmlTFuHV+v6jCvtW19rjKjEz6i7njzyFayPk9fOu2FI9AeRfTbw Z0Wr/AzdFxL3YnZHUrz2jW7GVdGYqP1xBR/uJKIwOAchjEylyKPSX1co5TNNfpVxP7UC3Pig Wur0tqaEli1XJbWtVVekpoqSvdIbn9/yEgLMXU3CWcu94tp8GxW//11UvImwwDTrmMvjmhC4 9k077t3DJqhMRwWhwkwxSabRonJJmQkyiStHoO0OXtJL34w6I5E9RegdXzlrLe48Mrc3H608 0ImrI33XstA3u2GQPjjNcyv9LVJqx9zsWT/EysKLu8Who23OlEL5tRKTWIDllbxyHN8WMxRu WnmVNW5OtbzREf7acORVmj4ugvqO07Q4qQ22+9pr17iXq0iqzWh8RZKQ7rmUhXZT7JszNG6m Y2d9iPRTQ1ifwAv1Amdaj2ORHY+u3QiKlHVRBiUebuZyvQm3zw5JK8u0O/d16xQcQlO36K4V QxRja7/YeBAk1ICMABQfDw92EWUOBoQ219de6Qa6ovuJZriDosZu5lLRFGIOIQ4Xwqqr1Mn1 FdpxUt+71cSth+N4SfeI7wXhJJOoPYkn1ZVJWz0cEO0G0q6PZBFSiHFXq4dfDSJkvSUVcQPI asdH0nrCRws/o0eQijnmLFgYVxzyeIPwdzMxo/P6PB+oUjMjYkeYj2gTf0dsyuBHGDxEoq2S dgh+u2dNCn+0mOA19Ic4pDcLEjTk9/2COkZDkhdFFm+JO80hiHlA5lQDya9dxT+Br9uB+WlR 0SrMz3QJPbaeDeRhNyShuw6O8M/5pClsaX7JSbvT76OmoGfQCtxq/lZPK/MLSLigr4/zBV27 /Gdxjfp//u49OWQVLWZU2i92aT7Ysiqu6mv6lmdjH9fllUA6RmvyiW2rAgU2+K0xpxi8NOQ1 SaT6bU6H/VvdlNY1liJP1woEHbNecB9pu7iE6JVfWPJ5FpbDo/+H0RuQAkev8Cv8GB/QafUj nq4hdse17X1NQBCA2N/be/m7MW+afFLhcE6zgdn6xYqAFZseGknqQFuR9VG7SvRHG4dYir9H iKbdGpg3B8dm7+mAzVg8aoDh3+Op2Xv58jkvnIetvXi6+/u/HYVujc/I4Y4uAekgju735szI Hw60aVvWEQ+zYi3kGgjMNqnSnehRe7//m+aDjnv5oHtD8tiTGYpEgSjdWtLmMtDMuD5vQZi/ ZnxqBzxm9arAIW+RdffKPaS/mbfR+D730K2Bn9o4cHbH7rMsWoOEkMwxyZiymNMzRvLYDxlR 4jW6O7bOXIbqCAPsouh+9MdZOu7Unj4feOeDyAJt67NzQho9/uU3Dbs8+S42GVH/PkfMvN2d l2s44Gj4Nivy8+G8IXFA5lnS4Nb+3kfSAb/BGSgemLN2PK0vbFVckgii31VKvslUMDAJ/C0b 9GF8IAmAU6GvQDiQmTgrHNlJZk5nBWq4yd/iBa0uIAkn8pkq3kLLDJ1gisw+FFHrm/c93H3i iY0QGSNr45i5/jMSsXhMe/0px3A50gXYN3n0OYTxR9n4aWbekwbt6hVsbfFOMEQbBBDPx76F U/tAmHF95vjwS+cClh945pX6UpAHLcdkNsL5Xx+Oj3deoSkSL0BEb+QZbIwDQsAK0hXLfRi3 TPMbmE/jrhYmi9DuB1cmqhckFxibIwLC3K62JbjY7k/M4m4q48BzKTG21PiPFnh1EDmvI2kf 0HWc0GNhrCjX82d/X+QlqkIJDeNpVeN1ccT3R9U4469/eP78B9C7JfublMjbxvVmnRIbvy2I s0npj8zL/b39Pf788yn/w38dQtm9Ms3lfxS2u/jrP7oi+4c+TqaX/Zn/vo3IekrU/n8BUEsB AhQAFAAAAAgAeKpOQz67F5FdOAAAKLcAAEAAAAAAAAAAAQAgAAAAAAAAAGRyYWZ0LWdlbGxl bnMtbW11c2ljLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLTAxLWdoMy1jbGVhbi50eHRQ SwUGAAAAAAEAAQBuAAAAuzgAAAAA --------------040608040603020104040905-- From gunnar.hellstrom@omnitor.se Mon Oct 14 20:20: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 E7CC321E8142 for ; Mon, 14 Oct 2013 20:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpQerbcTavIa for ; Mon, 14 Oct 2013 20:20:36 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFD921E8146 for ; Mon, 14 Oct 2013 20:20:30 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Tue, 15 Oct 2013 05:19:48 +0200 (CEST) Received: from [192.168.0.7] (cpe-74-69-52-124.rochester.res.rr.com [74.69.52.124]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 5B36A3A168 for ; Tue, 15 Oct 2013 04:39:50 +0200 (CEST) Message-ID: <525CAAF8.8060303@omnitor.se> Date: Mon, 14 Oct 2013 22:39:52 -0400 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu> <51EF78CA.6040202@omnitor.se> In-Reply-To: <51EF78CA.6040202@omnitor.se> Content-Type: multipart/mixed; boundary="------------040608040603020104040905" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Oct 2013 03:20:43 -0000 This is a multi-part message in MIME format. --------------040608040603020104040905 Content-Type: multipart/alternative; boundary="------------000108080509080708060005" --------------000108080509080708060005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Randall and all, Attached is a version of the draft on negotiating human language with a discussion added about use of Caller preferences/Callee capabilities or SDP, including a proposed coding based on RFC 3840/3841. I am afraid that this is getting a bit complex, both the specification in SDP and the one in SIP, but I see this structure needed to express all kinds of user needs and relay service types. I also realize that the declarations in sdp about media capabilities represent a good source of information that could be used for routing decisions, so a merge of the SDP and SIP based methods might be of interest. I mean that it for example does not make sense to send a call with video to a callee that cannot handle video. Sorry for not providing a nice formatted draft. There are use cases added, and the sections on coding according to RFC 3840 and 3841. In RFC 3840 / 3841, there is a concept of implicit capabilities. If that could be extended to include contents of sdp, we could possibly combine the SIP and SDP based versions to something doable. You have mentioned a couple of times that we could take a simple approach and not complicate it with asymmetric capabilities or preferences in different directions. I tend to agree that that must still be an option. A coarse selection of service could be done anyway. Selection of exact performance of a relay service including the asymmetric aspects would then need to be handled in some other way. Regards Gunnar ------------------------------------------------------------------------ On 2013-07-24 02:48, Gunnar Hellstrom wrote: > On 2013-07-24 02:05, Paul Kyzivat wrote: >> On 7/23/13 6:35 PM, Gunnar Hellstrom wrote: >>> >>> On 2013-07-23 20:00, Paul Kyzivat wrote: >>>> I just reviewed this new version. I have a number of comments: >>> Good comments Paul, >>>> >>>> * Section 5: >>>> >>>> You don't go into the details of the O/A rules. But I infer you assume >>>> that the answer will be a subset of the offer, with the priorities >>>> possibly changed. This is a common strategy with SDP O/A, but it is >>>> limiting because it doesn't allow the answerer to indicate >>>> capabilities it has that weren't mentioned by the offerer. Knowing >>>> that could be useful, especially if a mismatch is going to result in >>>> recruiting a relay service. >>>> >>>> I suggest that answer allow the answerer to indicate all of its >>>> capabilities and preferences, and at the same time indicate choices >>>> made. (If a choice was made.) >>> Yes, very useful to indicate all. >>>> >>>> * Section 7.1: >>>> >>>> Instead of humanintlang-send and humanintlang-recv, how about just >>>> giving the lang tag and a send/recv/sendrecv parameter with it? This >>>> would be more concise when sendrecv can be used. >>>> >>>> Suggest using a parameter (q) to indicate relative preference for >>>> languages, rather than ordering. This can show degree of preference, >>>> and can show when multiple languages have the same preference. >>>> >>> Have you seen my request for an indication of level of preference >>> between the different modalities? A possiblility to indicate for >>> example >>> that British Sign Language is highly preferred, but English text >>> possible. >>> The q values could be used for coding of such relative level of >>> preference even between modalities. a q=1 for BSL in video, and a q=0.1 >>> for English in text. Right? >> >> That would work within a single medium. >> >> But I don't think we can use that mechanism to trade off between >> different media. For that I think some other, more complex, mechanism >> would be needed. >> >> Or else we would need a more complex definition of which things are >> being prioritized against one another in order to use the q-values. > I proposed a simpler mechanism in a recent mail. It was to insert at > the end of the humintlang tag a character a "!" for highly preferred, > nothing for manageable and "#" for > a non-preferred but possible fall-back language and modality. > > I think it will be very important for most users to have a chance to > indicate this three-level preference order between different media as > well as between different languages within one medium. > > I am hesitating a bit for the type of coding I proposed, and saw your > proposal of q-value as something cleaner. When coding, you could make > sure that the last resort medium gets q-values under 0.4, the strongly > preferred between 0.7 and 1 and the managed ones between 0.4 and 0.6. > > You can see the earlier motivation for the preference between > modalities in the archive at: > http://www.ietf.org/mail-archive/web/mmusic/current/msg11871.html > > >> >>>> Example: >>>> >>>> a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5 >>>> >>>> To accommodate my comment about section 5, perhaps the answer can >>>> "mark" the alternative(s) that have been chosen for use, if any. (I'm >>>> not sure I like this, but for now, lets assume a "*" suffix on the >>>> direction in the answer.) E.g., assuming the offer above, then an >>>> answer like: >>>> >>>> a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5 >>>> >>>> Also in this section, the following: >>>> >>>> Note that while signed language tags are used with a video >>>> stream to >>>> indicate sign language, a spoken language tag for a video stream in >>>> parallel with an audio stream with the same spoken language tag >>>> indicates a request for a supplemental video stream to see the >>>> speaker. >>>> >>>> might be ambiguous in the presence of many streams. It might be good >>>> to define a grouping framework (RFC 5888) usage to group an audio >>>> stream with a video stream that contains the speaker(s) of the audio. >>> This is both a threat and a solution. There are already other >>> reasons to group media in SDP. We have a risk of ending up in a very >>> complex coding in SDP to get this correctly specified in an environment >>> where there are also other reasons to group m-lines. This is why I am >>> still hesitating if the whole thing would not fit better as tags on the >>> SIP level. >> >> I notice Henning just asked about this today, in a different forum. >> >> Perhaps some things are better done at the sip level, and others at >> the SDP level. >> >> Its also possible that correlations between different media streams >> should be left to other mechanisms. E.g., CLUE could signal better >> correlations between audio and video. > Yes, but here we have three media. video, audio and text. CLUE need to > take text on board. > > But you are right, if this mechanism is moved to SIP level, then we > get the complex task to point out to what m-lines with the same medium > do the humintlang-tags for that medium relate to. Simplifications need > to be taken, so that we do not end up in specifying another CLUE. > > I think that part of the background for this draft is that the > mechanism shall be usable in 3GPP Multimedia Telephony . That might be > a reason why it ended up specified in SDP. > > Gunnar >> >> Thanks, >> Paul >> >>>> >>>> Also in this section, the following: >>>> >>>> Clients acting on behalf of end users are expected to set one or >>>> both >>>> 'humintlang-send' and 'humintlang-recv' attributes on each media >>>> stream in an offer when placing an outgoing session but ignore the >>>> attributes when receiving incoming calls. Systems acting on behalf >>>> of call centers and PSAPs are expected to take into account the >>>> values when processing inbound calls. >>>> >>>> Are you intending to exclude clients taking a more active role? (E.g., >>>> Isn't it possible that a client receiving an incoming call in a >>>> language it doesn't support might bridge in a relay service?) >>> I have asked for deletion of this limiting paragraph. >>>> >>>> Should a client that can't do anything useful with the language info >>>> still indicate its language preferences in the answer? I would think >>>> this would still be helpful. It might allow the caller, or a >>>> middlebox, to compensate in some way. What I suggest above allows >>>> that. >>> Yes, I prefer that view. The answering part shall answer if it can. >>> middleboxes or the offering part may do the invocation of services to >>> cover the gaps. >>>> >>>> * Section 7.2 (Advisory vs Required): >>>> >>>> Rather than "*" suffix, would be cleaner to have a separate indicator. >>>> And it seems like this should not be on a particular language tag. If >>>> you speak both Spanish and English, you may want the call to succeed >>>> if the callee can do one or the other, and otherwise fail. A tag per >>>> language doesn't do that. >>> >>> Yes, tricky. I am getting a feeling that we should start a draft >>> describing usage in parallel to this one, so that use cases can be >>> verified. >>> >>>> >>>> Need more discussion for how to denote this. >>>> >>>> Thanks, >>>> Paul >>>> >>> Gunnar >>>> _______________________________________________ >>>> 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 > --------------000108080509080708060005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Randall and all,

Attached is a version of the draft on negotiating human language with a discussion added about use of Caller preferences/Callee capabilities or SDP, including a proposed coding based on RFC 3840/3841.

I am afraid that this is getting a bit complex, both the specification in SDP and the one in SIP, but I see this structure needed to express all kinds of user needs and relay service types.

I also realize that the declarations in sdp about media capabilities represent a good source of information that could be used for routing decisions, so a merge of the SDP and SIP based methods might be of interest.

I mean that it for example does not make sense to send a call with video to a callee that cannot handle video.

Sorry for not providing a nice formatted draft.
There are use cases added, and the sections on coding according to RFC 3840 and 3841.

In RFC 3840 / 3841, there is a concept of implicit capabilities. If that could be extended to include contents of sdp, we could possibly combine the SIP and SDP based versions to something doable.

You have mentioned a couple of times that we could take a simple approach and not complicate it with asymmetric capabilities or preferences in different directions. I tend to agree that that must still be an option. A coarse selection of service could be done anyway. Selection of exact performance of a relay service including the asymmetric aspects would then need to be handled in some other way.

Regards
Gunnar

On 2013-07-24 02:48, Gunnar Hellstrom wrote:
On 2013-07-24 02:05, Paul Kyzivat wrote:
On 7/23/13 6:35 PM, Gunnar Hellstrom wrote:

On 2013-07-23 20:00, Paul Kyzivat wrote:
I just reviewed this new version. I have a number of comments:
Good comments Paul,

* Section 5:

You don't go into the details of the O/A rules. But I infer you assume
that the answer will be a subset of the offer, with the priorities
possibly changed. This is a common strategy with SDP O/A, but it is
limiting because it doesn't allow the answerer to indicate
capabilities it has that weren't mentioned by the offerer. Knowing
that could be useful, especially if a mismatch is going to result in
recruiting a relay service.

I suggest that answer allow the answerer to indicate all of its
capabilities and preferences, and at the same time indicate choices
made. (If a choice was made.)
<GH>Yes, very useful to indicate all.

* Section 7.1:

Instead of humanintlang-send and humanintlang-recv, how about just
giving the lang tag and a send/recv/sendrecv parameter with it? This
would be more concise when sendrecv can be used.

Suggest using a parameter (q) to indicate relative preference for
languages, rather than ordering. This can show degree of preference,
and can show when multiple languages have the same preference.

<GH>Have you seen my request for an indication of level of preference
between the different modalities? A possiblility to indicate for example
that British Sign Language is highly preferred, but English text possible.
The q values could be used for coding of such relative level of
preference even between modalities. a q=1 for BSL in video, and a q=0.1
for English in text.   Right?

That would work within a single medium.

But I don't think we can use that mechanism to trade off between different media. For that I think some other, more complex, mechanism would be needed.

Or else we would need a more complex definition of which things are being prioritized against one another in order to use the q-values.
I proposed a simpler mechanism in a recent mail. It was to insert at the end of the humintlang tag a character a "!" for highly preferred, nothing for manageable and "#" for
a non-preferred but possible fall-back language and modality.

I think it will be very important for most users to have a chance to indicate this three-level preference order between different media as well as between different languages within one medium.

I am hesitating a bit for the type of coding I proposed, and saw your proposal of q-value as something cleaner. When coding, you could make sure that the last resort medium gets q-values under 0.4, the strongly preferred between 0.7 and 1 and the managed ones between 0.4 and 0.6.

You can see the earlier motivation for the preference between modalities in the archive at:
http://www.ietf.org/mail-archive/web/mmusic/current/msg11871.html



Example:

a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5

To accommodate my comment about section 5, perhaps the answer can
"mark" the alternative(s) that have been chosen for use, if any. (I'm
not sure I like this, but for now, lets assume a "*" suffix on the
direction in the answer.) E.g., assuming the offer above, then an
answer like:

a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5

Also in this section, the following:

   Note that while signed language tags are used with a video stream to
   indicate sign language, a spoken language tag for a video stream in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker.

might be ambiguous in the presence of many streams. It might be good
to define a grouping framework (RFC 5888) usage to group an audio
stream with a video stream that contains the speaker(s) of the audio.
<GH>This is both a threat and a solution. There are already other
reasons to group media in SDP. We have a risk of ending up in a very
complex coding in SDP to get this correctly specified in an environment
where there are also other reasons to group m-lines. This is why I am
still hesitating if the whole thing would not fit better as tags on the
SIP level.

I notice Henning just asked about this today, in a different forum.

Perhaps some things are better done at the sip level, and others at the SDP level.

Its also possible that correlations between different media streams should be left to other mechanisms. E.g., CLUE could signal better correlations between audio and video.
Yes, but here we have three media. video, audio and text. CLUE need to take text on board.

But you are right, if this mechanism is moved to SIP level, then we get the complex task to point out to what m-lines with the same medium do the humintlang-tags for that medium relate to. Simplifications need to be taken, so that we do not end up in specifying another CLUE.

I think that part of the background for this draft is that the mechanism shall be usable in 3GPP Multimedia Telephony . That might be a reason why it ended up specified in SDP.

Gunnar

    Thanks,
    Paul


Also in this section, the following:

   Clients acting on behalf of end users are expected to set one or both
   'humintlang-send' and 'humintlang-recv' attributes on each media
   stream in an offer when placing an outgoing session but ignore the
   attributes when receiving incoming calls.  Systems acting on behalf
   of call centers and PSAPs are expected to take into account the
   values when processing inbound calls.

Are you intending to exclude clients taking a more active role? (E.g.,
Isn't it possible that a client receiving an incoming call in a
language it doesn't support might bridge in a relay service?)
<GH>I have asked for deletion of this limiting paragraph.

Should a client that can't do anything useful with the language info
still indicate its language preferences in the answer? I would think
this would still be helpful. It might allow the caller, or a
middlebox, to compensate in some way. What I suggest above allows that.
<GH>Yes, I prefer that view. The answering part shall answer if it can.
middleboxes or the offering part may do the invocation of services to
cover the gaps.

* Section 7.2 (Advisory vs Required):

Rather than "*" suffix, would be cleaner to have a separate indicator.
And it seems like this should not be on a particular language tag. If
you speak both Spanish and English, you may want the call to succeed
if the callee can do one or the other, and otherwise fail. A tag per
language doesn't do that.

<GH>Yes, tricky.  I am getting a feeling that we should start a draft
describing usage in parallel to this one, so that use cases can be
verified.


Need more discussion for how to denote this.

    Thanks,
    Paul

Gunnar
_______________________________________________
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


--------------000108080509080708060005-- --------------040608040603020104040905 Content-Type: application/x-zip-compressed; name="draft-gellens-mmusic-negotiating-human-language-01-gh3-clean.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="draft-gellens-mmusic-negotiating-human-language-01-gh3-clean"; filename*1=".zip" UEsDBBQAAAAIAHiqTkM+uxeRXTgAACi3AABAAAAAZHJhZnQtZ2VsbGVucy1tbXVzaWMtbmVn b3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDEtZ2gzLWNsZWFuLnR4dM19W3PbSJLu8zrC/6FC L5Z2SViS3b5uzw4ty92a9kUjyd1nY6MfILIkogUCHACUzInzY85PPfllZt1AUpJ77BPH3WFL JJCoysr7DQ8fPKT/Pnz4fHp0YH6rm6uiujQ/NfVibu795yQzP9mytFX78MFR1dmmst3wbZNf dHfd+fdFXo7r2cyc2fG0qsv6srCtOarGmUCqJnZi2i7vFu0rc9rl1SRvJq05a/Lx1S1g/7Yo l2bv6cDs7+49efjg8Mu8aCxB+FteLfKGvnrCXz3F1n8ruqlZtNaMc/orn0yKrqir1pwvzU+L qsob8zPtre2aevbwwaiamNOjY3NO105MUU2KcS6X0412Anirq/loL+uuoOsIsz8vZnll3ufV 5SK/tMnVEyBseCmIHM5mi7YYD6tw73CKe4el3jvc3cPjRue0tHzc6aM/t7ZpzTS/tuY6b4p6 Qb/wI7crQmKTlzvGATCVtZN2YPLzoqQ9W/xYTRjKvLEXtrHVmA6jsZeEc6y9nddXthqYm6bo OvxAl5u2uKwIFQ5omxnz29RWDMbSyZ2XRTvF3QUIgxZa0NJw5ItKcWe2xjkheMt0U3qmrMp0 tTmn02AwN/kSv4ebLD+5mFi6b2lmeTeemu0is9nAOHzZHYAzgGybRy3D8RuPt3eD45dL5x4T pr4It0/MPG+6JW3sbFoIpKKlvc3tuOAFFLN53RBtdgLMzmxzScCXfDth9Yb3lfOv9FdFO2Mo xGQdQaet5eZ4QYgam9P8wnZLM6raG9sAa8c14c1sH5+OjndM3QiMLr+yDYPgRZcW641wSvf5 bRFlNwPcmRuik6ot845+of8bW+ZLBlLP6WA6Bo61mfOmmFwyedPSHBrMZMELam23mA/M+aKj rwgP+XxeEsYYEF1e1dWwhwCTE5aJqs02/UBPsF/y2by0jJeKLwHcHBuY59VS9wVUWZDMTqak DeybST1ezOhzM7HtuCnO6aywQhANE4X9QscCrNK+M3MUXyfE1NblgqmO2IseW9kbc/r2mGRM Y/OZybuOLqZjaRlaHi4XjqcfmP9ndlIQQvPLlld3yhJKqIYW+cHO6njRPZlIn7SL8xmYCEg2 Fwtstq4u6oY4dWz94Skv1tdFyzKG4L85ODbPX/Di+MeXDjvpM2j5RHI3Ks4d0jxdu4vNYXVZ EO5wsrLcvL0y7+qGFrF9dHj2boeo/mNNDNdN887U4FBzCeXQEtstTV62tZkUrSJNuHXloXkf Ay3zkjUkGjom3UXT4Ez9VQxINwIa68y06+avHj+e5IRpCH/bZIXtLrK6uXzMgrN9rFAe34YR vjRa2nVeFhNzwewxy78Us8UMC2qLL2ZWV91U6BrYxnaJNxZzWoKdDIh95mU+xk9gp3OiE4vj JK0hWIq23xlH1l0xI6oEWdKuiop4p6nnDcQVeAdKaGXREMAqrBgESTs6rrzEYyEUCz4cO9PH 0jlVuGkLxwDioidcku5rs61bKPKmIAq0rCVB4n01yRg9qOfLpricdiCIAqthcOHj7fEO61sD wiEVvWg7xhwIjiRMCwommV11xUUBbm2FxPv/qSVh+n9Uia8srn/d/xxDxO/9LtA2mCObVXIK jA0JMSJ4t1785ItuWjcg5BGhjhGAkyJhe20n6yWWsP0fJJ5wcBEjM0d6nD1qzXtSuSVDOA7M f0LymtdLN/PVbz2FbSt3dLjf2sAZovbosKrWDgsSMDsgCXtxgUXQQePJoGfQ/Jw1kGhkJ8jc 2jNZTGlhIjX2uiCpSffSL4HMx8RfkGTLgR7t0stes6wXjSLJMxQhi8TGWKwnlngN61TGTvp0 UNnE0l+kaCs8TKyLL2z4ECldkG2W3mJmoL6iGpcLuvGUNHQpVPfm9K15LwgxHUGQ5bR+qSyQ Ty0vyzzNrJOYQs58MPGhsJJoIkENexWbIdVOdktDGpfUeR8+AK5fE1POmVPpBzVMYGyXH7CX sVBr6slC1pd99X9mnyHtQwDbZlawyb00d963BtJThvQkY84UnUvG5533rYH0A0N6ypDYNGBA B0Rr7detTCEBFnB16O2QA5gTTCWk8GCQmtO5hRHFpz3P6e+NkPY3QKLbKoL0eA3Edw2r8T4k 4IrvJwLnfw/YwBFwJ4u2LfIqBvM5O03W9MxDerphTcQ/5EcNibRykpUTNX8dyXl4EaQfNkAi 2/pi3e19PAkkQHlrW37mqSVxSgria8/uOUN6pqaB/UK2AaTdI1jtj4JhdjdUhfQ8Y/E5r2G3 nToz7s67E0gvFE/PmZ4+ktR7RN4U2cVY1LAl9/QRi4D408aOrx/FhmQPEuhpNCEBUpMSu4Zc /8eCEXfXauS/vV0PCfQEY3SL/Ktu6847b4EEejot4MvAktU13/+/vT2G9ALyafRxBLnVkiRs 1DW+8/4VSC+xHksGXUHS889BU0h7u5k5IJuIPFMh7GOoL7jFv5JJwgDvhLSveCJYIIMEXOq0 Z1k23N0Ff5N3vrrSGNL+PSDtCaT92yE9uQekfUBKP1cA+kfDDbqBu1CyaSmgo7VhjDsQo5Ce yJERkkfjq6q+Id/7UoyLO1exHhIh+SS4+nfddQskhsUyAD4axzAiwHdC6UPC4R+JvweiJpvi a6DtieodsQlK5uJoMoGFf+d96yE9fNC3K1Zt8m9pme9/B8uc8YGwE8ITfOtifkvAiQwLYf1t CQJAiNYSUBEviky5rh7XZbszuC18pisliOodIgzB5r9bTohBsZ7gH60BbRubj6f6OHLlJEY0 hsH3pWOXcgHXmCGdc7QrkIth01EjH245A3IuCGC8KLKHu+W8wEPF/azqzi0RJ65PR9yzHWj0 Dd62RFPgFLuInwT5Bg5JGgAMQT8N1/ng2ySES+IoXBx4Y0DO+xG8PGqTIFymDpTEdua6ZXpQ HQfZPJw1kSeCoLTxjjbj4qENeTF0+AN1D9ilojXIc9VPr0PsklyJsitglUqMqNXI0aS44L10 GgzattllNjDXNVnyA4FCR0kfkO6qiY4KupAsO3ICxfkQfz+HazzU6FN0eAxgRsYcjMxZZs5u ajlg/5lGec8tHUTsVotHEjkcTHiIrcHIwCFn5lPFJx3FtN4eJ04rRyZAoNOcCWIxOwedXtDj KntRdD3s5R22R/cR8i05dQxoOzoz2JUb+bGNCUc58u3xjo9Gg2zLYlZosHT9IRM5t/VMovit oCo3F/mYD5WWVj0SX0/of0AbGec4gJiHsAPwZuU8ysCR2wKx5aCl0JxjbI4DtS6+y9Fc8EuA ypFWjWYO5IKLpiDjUcgEgdeaIOWXC4t425uFw+aYPmxIzNE6ybOGHU6iaBmzbcakzWB8WBVo IDd5NbIaR1UlIpxEnUWprI88t+TQlhMOycM3pT1o7oNwdmHwNII3q9UT5tD4BQF2ciPOGDz2 ciWSH6BYEQ4NrnexT5WXtz29S4WGOCsFQ8xDQsMJGUj2sfVkVlRDUGIdlrLd7ki4j3kaIrd1 jHFawKlj4CwlnZIILMkL54i7gVE/50jE9udDOkg67m7HEyDzBGsBd4MXjk2cTHlNjxFxJRtH kqz4x0KRw0hxMY6cI8jF5aJRjeQWJbGVnATCRU6STAMaDMFTqAY5eOXMpsQ4VnREYCrCpsFe +LGE6xREQFok5FUp5YIu97HGW1kwCr2I+JMzyfspJUc0uXG6MSe5U/fuihXT4x59hYhwLPAV 7Rv1e5wlEhdYFivGQ1AQfMo9vUv0aefIXlZdhFz8KAsVkYBoIWkLyWa1kp+BmK46kRKsS/xV Gl9q1vF83raLGYiAjxAn7pz2isWmunU30xrMmV+1LnwhBgZJHAhZF8rwEk0WwIyjaK7M0YdT oiWsKONI9qS2XriSfQLZUoTsGbNK1ZPZOEM8T1Um9lqZvGhIXGlmjAOpgk1SZFc7GhUIgjq2 hlYw544KSx3nDcnaRjJWdClyee5I3FHGh3duuxurltvnw8RK6ThiJqYp9C3nBI+ciaPH67WA 7C1XZSGbGwS8aK4tX3Q19sFGWpIR1AMa8nm5/AztneOh/af2MSwPCoGdU6Gh1hwdqxDqOEGw fXh6RD/v+D1C3LM1O57WtZgpyDamatJJ1RV+l5RhPiYZgWwoLOCJFbQBaVMIvFp26YGwRG7b gBnN5K6RLCI61dYea1jAChil+XlNCm05FMsGD8Jzt4/fnOxIHvHb+zNPvpc/82ZpIOH4zoAM sJMYACEkJgZYYkblZa0kw+Jf7+D4eit0KigVIcrWKVlEJOuJQ2riCtGzQnNj1pGcJyB1hEAD IEDStI/0TLxzo8lyZ3kVm00UAeBO0yl2pnZizGsyFcugCIV9YfDKkiKiQ6hIdJR/POwAwG0X c2Tm5XHM80TSidpqRd1VzH14RCPRuERi+8S5+I4ijS9ih7HlLCAeyTZ57s3VYDiLWEBot/Wb XehqxrbpEIOOiyhGesqKM3PjTSCV8STKCw9KNBPjTuUcB3BpUdO8mQzri+GUTEmR4BO3ySDh VZXOy4X6ZaJq9eNtsYmJ9Jw+aIgr6mvk5o35wNIpolChLIHjSZR2X98Ik7daxrNW/AazhfBD P01KQRGbXedLVYJOhcdqQMSEuxsmBq4gHTyHIds6JMEHM3HidUK2KkcDnJVw4gteEi3NLs/t UlcR64R16gU4S2h0+t4527B6SQ4btUGd04VKpS62gGGUFczYkZhkJZG6Frrn1C+JIaXuk9uY 08Mv9/aSWD+B29vbx0eHC0KX3cnUiuJLgHl1QwapemCHnfU+yYASEhRnA2YsLYylvEwAlWI0 BECik5zZ5zWS10MhPEEITtg51T94qtSyYA8pspwOhZeFByuRxQ+XJwtDA3Ux6SaEd50XJfMh O4lC+K0pa/Fud5gjcdSO7XVNAKgUVpMH1QTyKstYMxI5ZUElzITdeOXevY2NGqL4YVcPLUIi gbGCT0XuQ+uSvDfTgohSbBlnX7Y4d1tdSlwnrFGIhUE4TdFaejB4KLjL3sfidTuGHJMnExmF Wrw0IRkEdbSOpJ2Y7VwUTcx0d9BqxAS5EVDhdsHp4eSgxDJctx86II4lSCEEoQdpsEUlWVaX zi263ibiDdzBYoOwESGwx0xcMVU48mZIiW+SMFZqYw3UzDxfemMHXwr5QBOOF8SAQslJ9Rh+ YzoUlytFuqq2UC8WYkNiBZutCPdb4PVFq8ElMhA6X4iyFSokt1zEhQH1NrYtDttj77+xB7jD JRNEad3Uh5mi8rnI2lHOaXPS86gW5DgNSJsdeFC6xujYc3wM5fZY4nKiwxu9fFyTNlCLJVgr dOg37PhXVwC1JtAo4iP4uqyhffzF+zaJX+PjQVN1vGdajqcmRGuZpYOlMuUgS4t9sgs3ENNu bptpPl+NrUJAamAmNxf2BvV2RSliZ/N6lAPUcBJCuii+2MnKerLItoVdJDGa1pZcwjH1/vWs bjsVZ/34hnGGqz7Pcv2UFwdeUr9BxBfGvuwsCgfdgIO8IPNwb/LYGHaBZC3eJMdhbOfdgm2+ lgw1cIjKBhDPiq3MkfrYXBYR3yQBbx+3dNpUSwSXc6sRWJCWOCG98otv7ZE8/V4eCdj/yi5R 4kdyaOvD59OzrYH8az5+4p9PDv/++ejk8C1+Pv159P69/0GuYDj0wafP7/Ua/BTuPvj04cPh x7cC4MPov7ekynjr0/HZ0aePo/dbLsAnGsSXYzWiWa3Y80Rq7AT16m5O3h2Y/b29l+Z/6Cf8 8DsfBxKocQ1LHAiPIsihtlSexCKP6PXj4ccRL/LJT8fH4Ar8rgssiytbcvVyiH4htlvJVbsv kA7dLp4gQANfkuuzdM3e5w+lBOpHMLO34I6JBk9EqQiuGEG5JJFAygmm2gi6ORZn+Q07yyex s2ySmKr61iIN1t70TpUlbR9Y6GMrbN4fXTDVCTKnDfJS2J6tfueq9Axs912w1SEkzMEJq0XO YMpRn472VJCiFqWYM4+K0aRLzX2259ziaUn5FiBoSmRtXZJ88bVFRi6QrAH6KBpXV0Ql7jZa JOrLGLFSnARMuKCcltb7x26Tjb7D2NEgmUTYkJzi0NuaYKk+KPNMvdboXRtKaRYlm4VEX2yw wBgRKlWju4s9AfhDZG26SNBYPLd7hYGyZGV8bd9S5KW60xL8EiCttq/cLn0ALbZ+4J04s32Q BL9Ew7AWa++C4l3U/qo9oJzTKbJwPhKNxt96LNExKrP4WLOSZx/A69gqdbGYuE0gap0oquj8 +dtRySEQJOZQvdndgfZxLQ0DLEHcRuOQc/ZLhIZ7ooCB3IKG+6FANrsODZtQYMx2mvBUjCd2 ARG7raTkUxXJ4ejgZ/jGZzV5s6hQuqYtsiGU7Yhs+NNlg5uFBCe+9X7enoOxDQdGzCsf2N9x O/GiRKsSE1lyTzmitJwSbakVehdFQyzu1rU9szkHe2H3BZsvZHM7yIL0jL9S/CiYWAQl4gdG 2L1EEAPyYujPiqCY/hXHruOnH8O/VQQ57AgOvAi6FcgaCeSF+ldwnz9LfZbs3HPTvflvkwj6 9lH3H76DjWtWBKVDx7cRlEY1lOh0Ms/ABYSqdULodgEkts9dQmjtiqXGp6rdyjVmqL8hmcep ORwcQ1gfWqP1I/NOpmJPTCc9bdGehTFivUAuft3YtIgpCdeoOmGqHagEmtyXoPlD2mVIccuF uhiSeE74cEqbjMRqER9gXi3JF4w3JwznHu+3BUiRE0+mOgJjjlVjae0c9UT2BR4T+BIbbCVg uS7vgPPCxxcOCUpvgiApVoKFvHDmNMNVSxaezoHSJ/97jwp0R0n++9Z9H5mp3VRjxrF28azg nJB1YQekd3FNUUniJT9HrA0eOPlwi6YyFyX6RiJsOSgMPYo1tsu2szPeby8RGZOYyHxVClgt 6wTbBos0ZmIpLynLEB2BmBf2Y3T4pOK/UpS/RuUvUMXk9LumdPqA1mhxhrP9cm/v3h6Bk/zu WcxjiqS8HKJjLUkGccvfOkNtnRJnOPf2IzafV+5TwHpy7R0uxaou92rxLnXuepHizSuX9moT v0rFijBdh+wNiO5d+1Uq+Ra4f85O1hOX/J+L9nsoQ2+M9GwAfm6SHEgv88JJzyahTNR13NRD EsMDSR86QdOzf2wu0uU8H1+hNxW5JvzdqtD7yhYXL+/i7z1Ljmaob4SURHLPGxXbo9P3O5td 9FsZUgqh+sdOAL1ReKdyc+Vwk/+nvCjpiK9lxEDHd3HivZjs25uWz76PaXm31N1ICBHOGBmJ kZBmmUP4s9nsQDOkdRIjXoByzzMeKYGMok9qhBqpm1q4REo5REa8aUhCttN0XQ8fYCm4Xi5l Dy8en4FshTydvVxiel8QGQNNuC6TxABrJI31RTClBGA5t8FPDqDB75BNjAQSLUk9Caqjo4rI VoqgE9h8H7hgMaNbi5oblTop6dbiQ/dQTh0qmgdaahcqZHvrLSqSv9gwX85HQIgrFO88e8HM 8xaSyNUtGAxNGQv7othKEpL0C++W8aJi1EzJkkrKtfDItahFiQ4jAEeWS2dCJeFcSXpi7EXF efGQ/hap4NKlKDguqmvCxSRNLyphPRdR7GgpF0qSRnElR1ezoh/CIP3l4YNRoDn5iM9n07b6 7NGnMon+zYrJCgR3gFLGj6vo4IRbokszLMgtlNe0bjVAIycm+XamHs/6Xf9c5GEpVQoYcTfC 4jPzsdZ8FSOfUTsSYvFqt4dFVb+C7btJiVyKopURKz1rua3La85mnC95bE61mkiOVP3ARLNK vGND9zgC2HhgDnd8cDp0JmWx6CLhG/NboeNPYqKChw1ZsWIZzXN0lETWFOdOx+O85TwBc3UR ijPWSZaoajRQZ65x5VgoC/G/MG8gLaEY+cpLbVuqK3Zt/A0FpzpGJDb06vkUHgLu0fSvkoSn uTi/KsjiPZOeyi9jjbNG8g1MId6OHKUYe/LAoJh9q4LDCHucVS4pFWNl5QWmr7D2CZdD/85z 2oUYBlMebXFJWs6yM5OWh+sJuzsyIxpkUrTjxtJn46UUuXUqlGQ4TZCSuvXKYVTQ9NivIDqS kPnppmSLXE59v4RYS3jQ+pE4YjLJFBuu5pVYHNHnrCauLJd62i91LBNRfugaOpgWvBJiW4n0 NSh6FG/al4ShIKJAHnAkdKJqyd2rWFIQ5reFtwQ9qXuvxesn173lgOg5/opAkZSLuG+AwoOc tsy/oX+KfiGhc1RFzr0rR3U3CbMhJEJ403Y64b8p52PHZS5esF+Xq9Xr7ebn/OpqIef4B4Yv bFikokiNgdiwSJ+iu5dza6xTV4RRFSwsCphqYt0r+yT+bIMOlEWxFBYD4RLGtmnyOakRHo6h 5+TFWFt0i1CHtWR6aWkNoQkw+sJ+GXM7r7mkZWJvrTcg+MG6XpgS0kkBcWbQDMrUCx5ZcGWl wsTXxT+jKq1zYruKg/R1VKnvqHkpBXaw4pkiWYov5ywUKujynGX96lEwyjAtSA/fla7GE73G Uzu+UgnLFdzE/sTMA3NhSdrKUQl6wXxcF0/XNTA5IP8yM5Li3EbEhHtEQPTifIixTJ6oAi04 +lXR4OEQsnmOSOMT3Z/P3g1fcMXGBA0U+EEx3S4uyGpDM4+vufs17+Phv4yw/d6ueQtdkGo0 Z7ekme2HD7Z9MSKL4XqObj4+Ms6on52a/f1s/8WeWCIxSknAVsm1zrpsd0hwXFZWG5Y+QFIL 1Z/Z0kKyL3udsbw48QzMrD5HvZD0esiHHz6cHb6PmWr7V6HFkSfOE6jWM6jWM+KnHWJLzq6z UhR/0Bv1KV6ShQy4zgkCA/LDmRMoQSIDuNWQeC4260licqDOR61OLsUSXpeidCZzKYsr5rmE sVdq9fgqqWgvKv2lU8NvyHl6Vokt9Bstwps6atIQsp0xkO4vslvcZ5k51V22bAJX8Lq5l5Ov vsmlbpnl1se6Gv7KGnlNVwcUhrCwusvMvCipEosQNPBILmkgciAZhanKZbhJzj2Vj6LFU6sO 1VUOx3yP84AyHoYUS1dwmRNnk2Dr+6u0Wl+eMkNaxHeJamcPcCw07KypdDGxIj9bEBt6CDi+ nlMDEHKRA8YbjwJKHxAfSCBw0FUWKK6DqgFdIElI36DphkeysGBIIByY2BK4iLSAez4rnRRi GCcoHiGtRfUBSZs4QeKrzSEGabXE9my7RV13MhkA9ac4jzEsoSpH6a7txplyrVcLHL5yKsFT orOauRCzmHFg/zovF2zLux2TlG7rRTNeWaPDRGY8IToboDWr2vknixF4veAacKVfBF/MlQyp wX/mzpK5SQLlzKxuuGHrxxBiOhVnzMZRxiwMQeS+KIwcLbhJHFpWFyxVOj3DRVma+VUNK1kr oVfNxgGEnrRfI6WgDZtA8jr55WQOeVW+QJcDPWtxE5N/FJrfuKrgBDm3XXBH7kG5bJFkmEqf Rt6pClWfQHJcWrqeh7QiZxPd2APWenvi2LNkiH0Idh/UFGR1AL8RoaFRcpn3oZGG9OYizHEv SlP3+2cvsh107Y2JHjJQSOwHp54GSUFbXOOLj3VzQ5ZR7nOz8JN6rqK3v4SDIfQxyDG9HV+t v3/QN+No/dtBtCQDZdXE8WAHjJHkow1BG7byCw6u8PVlMfdmG4dr9WlRBQIyxgkdBEdCdW3T V7Ny6jjWCzyr0KiYWMGMmXFTzDuXyuXeXe27FOoM24gzBzy6E37y9o/Eap2kvDtnr+woufqg k8+LgjdJaNm56Ew3/zA9FU9P2FQWGfigfLEublzoINy5Zh0Rv7Ii1NLLjp/b+ukCAQZbYL1m 8yRsgAgGaVHid5e5jSwVJJz4D3gMCY2VaVsaZcaGJvqdn13Kz1aFnDYNuqmWrfV1j5q9kCB7 F7Xas4pYreFOC6QRFgnVLB6kkfj9Cjw5sBgcW/UMr55wiaaGsVs/VkynooT5E35AB9SSRsry aD3RMmRXalcwGKzCPVyYDoF3dvXpOCbicweRAT02Yl5g4bfmCpPTEUuiSrdQqAHOw1LlbLLV mRUiYKUxIqm+5SaRdjkj9YvUUwkOKFoJ6fsZxF2zsN7nIQ/QqSheqVWHITPHVuZwQkKWtTjV ReNDhCIstQGmvoDakI0xh+blVdREoL2OlShuQoGLYYn25XRchjGHXMYSbyDq483nc3o001B1 XTR1Jf1hkFa8TpTS0yOKlgsfJnlzxVEw7NPCTIKNVWIWOEG4ssvzGs1ZAEw2CNGCVBxbbWlN 4wAufI9zrqyGtcEtrhte4yLsnYuoIFTUXNelE6ntl3njbLtwf9/3j7RVnwwGhjzsCg0mXC3n 7UMtOlCfM8JcRGYkrjI33gb/PMuiAZnuVicB5II95iQ/Wg91cv3xegoQlfJPf3j2zLmSVgoH vPDQ26TtQrKtccXSjeOuoCaAvYFi6sLtQSqv3fyY8Cz+5FH+Iz/FARLZLXznhXQsFoIg6O+q lScpw0OdMX0Dwoz5CwLQ0faNZc+LKYTEFvbj+zxkxyIgZYbOQgbBi8zSzJkRDo02qpA0wuKP gAGtTDgc59WjzotltuGsj8lM7AWseGRfb8I9WST+Q9LdnyL6HfDD77TiV3opUpKM4Ff/6Um1 yy//Er4+E9tP5hSYVrp1hyWRbBmtNgjb/leZAzRqN98/6J889JdMKgnJQwHj44TaN3yukQXt 8Mj0QbIWs+Y5DlD6uET1iFYEhAF3ODeS1s5Z48sGHBR5QIg8KVCs44MjRHwbk2HUvmZMCDzb opOOfr+3WjM6+pQiGVjh7peti4nlb4Bwm8XPZ83Gzcva5IYQUzf1q/A6jBVyWGtsAUaazrmn 3lV0cNx8raBNVYKu7ImJkyVe8HW1go3xmsffZDFBWrMF8FsR/bHSl3m/Qqd0XrRzkPyTXZB8 TN0OEoJ8p8PR6cHRUbgyc5O5xfPw81s08zPNG5K5nnc8laNWZGVV2td0HtGFmN55/xALFl1R YLEdky/KIZ2G1Bap1fqSbGo6OnMOQZtzhaFUGEfYj+0x0kTFvLAylbnCboAZHhEj88r93f5s tFhcUJNHaYrAHS5MgMZmmBwKkLDVzHzo9xULHaATG3ND0mFY4PMfnj0VYYQfpPnq29ZuPP8O tRuMmDAEv/Ot+16RahSaD5IHaRSSCxbFgNiMhNnEJibbQeV51ms0ldGZbU5OPUn9xg7bYj78 MpvPh0R83XD3qfmfo+FbhpJtuup3rmalL6Uw0E2P8AcukwRKNaGvCwl0hJvghjjNi2weU1ts UbuhEBfaJRyXsByR7UbOThgn8+kX75PVvqqCbnYXDiKFyklmJm3CsmIoUlbag/XKbL/b2+GR jRwpaDvyktpUOrpb+M/Rx1+Pzg5JLMxf/bEoC9v9VZGSjdGOcXT8eD/bTe44q1+Z/1x//V+S C98RS+ilDWo3/ZVEeX95TeLmxx+eP0vuOJUB8K/MpzmyhrxTmDInuP2/kksRRBkevX1lnj/d /2H3eVWn38po8OEZ+TevZDqiBA4et5M5X5lcPv7x6KM5On5q2v0vWbTK5KLZjzPCILPRk70n 5uzg+PGH05Nj8+/JVfmPcqJDuFbtK+6lJi4vqt5VbFrYtZ8WXe9TJOBfzdoGQ+x7K3yFtTzG eKfnezf2n13evu7G87Vksb9jfiJ9xWUASnRe9VTgaTrMRzAFp3l50aMSpQNi+l0i2nuTgxzy k6f/Ill8n7P+st9m0WI3nPWL58++zVnfeqq9tbzCUx+XV39Mnzxv99v93Zv9PDpXcVNEdCHQ Yjl6a2EsBbsjzAFJXBNf5Z+6B6sz+IvwuoDXZoGYdbeoiH60UYJh3OorOVOhEBvlWbbPYkks No5lNYnzB6HIH9vEwXca8Hm2ZmC5i+uMuCE1enZr7cxlACFa/dSm8bTW0pvgtXBUgeGsmXPH EfvOj+aMpXyrwZfIPTRGLa6oCz8xsRCEXaPsZYd/fox6bCt8K2vhxfeyFk7yzs/AIAUNk9x5 zNZ5cFC08OHWuk7ahAjdxkFb6IgIO4/MNqG/kWjwlsSM4jN057El8y1WPdj+AI6+I7sdQduJ BjpFDq6zgrhC0K97wMRIJ6ppiy0+3i1nEDAQKQrhL3HKWytRQb8siUvKXOdKHTGJLIaoPS8u shPyH3u0tdG/Ta7EStZfeZiz01S5YJV3riQbFgcWV+0k570chaskCrLKARq9RFVEV3RcPy1v SFJxG8V+xBnbls7Lol3pteyFoNqAejbrkeJvYWoR4vHskI5c5cA1q2JIurLVVa179upzo0PU QaMyuDcYqlqK4NbJQcbKiSfOvAlJMCSu6NBCpDSpsx2msvT7Z+QJ01qf4lgFcDWN5lM+ulL9 mHM4O4PIpJX6Q0m5MJxFxfG5lSnb0sMrzqHU5k51bo0i2vnM9JGcGJCqYhgPCQMz2Lm0XJ4T kC3cDb6EC4fxP961liLOrr60vCAdUyLu6ZK3pWFJjwTJVdGKfl5Ul1w945HtEOIvOYb6vFxY l3riOWvkDK0sg84DDQH8qiCutMOLs8TDJt24kzKMpA0Ga7ilEMJaTSDwp3ybdp3JRBvsZ1uw Q6tlhhGKK2LXZDV4wZSrLxBc4Y6dwQa9tWl13jBxK9QxGa1UbAhO716mcOCGpa4iyyOVRZmo bx7acl/lnRn/IcNxllRronHk4DumMdBSDBRWxG8cWk2A+EldeTQMJAybFAUyRiYAEZ2lgdYc XjZkfWoHw4Rts7Em6hUJrLjQ24d4sL7RjT/jBH+UuOfErJwHsrOx+kxKkQg0q8S1Jst6slAU hxiQe9eVhHCFzho6ObGYaU8V6sewsvoiRd1r7EskCE/dGeho8GhSjmcs4WTNhJIpWczIBBq2 i3McLOgUQiOqQJBv/Pg/59CjKFeidVqJuUPSrHR5jkB1M37r2zlibzJMie/mDgZSCqS0xR51 /QB083ptyNhNiFApdPTfvq0jR5Vw0V6xDuaXwuZuDACWBC5xVXxmm2w4K5FiqS/Ge3YA0U0R dsB0vb5g1ri20GgIlaS+OPGeF6X/WAOyjfoACT/ixCTRm+EtNkQHmhh6Tg4CMwmSSL3RlY6g tXLTIYpfIoEYmtg+K1N+c6lSS6fC94KDfl0rsUCJ6emI+8HqnCsB/W1t7pffweY2Ll2tHBc4 gdMTrHPv9jicSZK+vWkbZSvXdUEUNzsvLhfEpF6chqCgZI76g8uZu1x6yZVVJk1eyrre+k1K BgdssyQVg8weYmUmcJyJSDxAh1T2mrvitkFvb6yBvJEhNJsYTfDsbwP+qKc47RB3aDooJRYN 6Vqhx0FDMJL2nWgNtURUw8wonjcXDnBF0t7PbcTTAl3L6iLaVrq56bEZyavLmnPZLtWEJi4e WOA3GT2Dbw8mp2/i4rIkCAHuTF9FgFKuSBTpMJcoASrZVjGytjmTYajtKNsIHfFFxRkDXYd4 4JteP6ZnxW8G8UkZN2M7anrjuEk0vKtNpr1DSIpgjidl2jBXwk8WrJarJpeSm3VjABmQSOFI c4ib0dXOgFDDQ1Q9D1wrpnU9Afg8sjYF2Lr3AA2Slzm7Ph8pakgFLiE1TIoNSBCPXudfRmYN IpEuaRmUiWMwoaJ+OVqCSqaWRjZhQ/nWvTTPz/UNyvcH8THQLbAB3JA+rGZaV27cJ042rKaf nNDueGjlMBseo3tn884/gwFxTcOaHmVdm8uzoxyqQQ1HZ2MOwBPkrPxTEtUbp7rTec+ueq66 7O/FVfwMYq7HYM9NNgRoJ1DoqoChp62ojsSLL9rYbNGGiHWitWddeJInxzXUUyCsOJJIrFeH 7ZLk8BfYNIeSPeZGeX/YE6cQyKjEmXnpVbRuaKwjtzUToeFty0BmHfon9eG0LJ1ouGIRqXh5 kvVekI3aIvCrtJy3cViTIes/x+6NW/F7jBlQVKHWxa9ligz2zazdvjZJoDcIIic8chOiiv+y jaPvHt79PjZOSu3coOZeQZMiLWYR4FCOQEN8PYEUB6h9uRA0jz9BUUlkMtZjGXV6Udhyou8a DCI6DWqbbc4Dv3i6K8nANU9zV+ztZI64kelAJft2asHqzS2asLSMsUrfD2NqroJgCa7T7Sfk OiHdg8NeaqaLX6gkqglaTBOOeDmxr5l0CYOAQ7oyIHHV95IwDHII7JnxTX0hq5dw3VqYHVqr 0TDvIu0WK5+V1yT5l7DEdl0qXFxlQeOn2Hs8KStFpQaQ4JisEesI+gzInHmPrjdgTDtwC1db F3WwT8il1nc5s80dn5BScKgRFT82Wox0NffemufnvYS6acxf5t8ikC7I594Q5Gqrz5ymzH2T ipsTRCaGxFlCrQOJkHNtZY2GRse0FuqhWjX2w936AN/OYrlLwjl4vsmaTVLOcROmJ3WwykUH CvgJR9FFrstbD75wDV7pSkv5YiTYuJ5DHVbX7jExn0eZOQzPhzoLJfsSqnHTP4o1Q3LBlV6g 7/HY09rPQol52Df7ax9IKzinB7iBLUX0QpH46kqKqpABibqAOVr08MFxjYRnkbs0moigqKzF hTDUWnNygyWTflg0zLYaAtBDXSM9RMKRQS3covGZP/jtZ4lEU2Pgswz7xY+SROEwcgLAiT5G IdspiOM1tiSSqNz7AuPmF+cnbjHdYvQxCFmyJltM61uCWKLeaS6F/dIytq6JpuM3s8tTispP f0gUJC/Nq52VemNfJ69OK+7Nh27e/0Si/3U8nZzdYKVel0ryhJrze5fI62QPR1EM42DLAfhx KxNbwNU256F4hZ6DsTIiMBzsnE/35PCno9Ozw5NXuNX9wify19lSX/0kdQ4PH/wfpRJNzeOi vfSqv7BECX8Y86/5TF7jQF6H1dpqYNsByektp+pN7sSjx46Ef6PZGAnhJdImZFMd6rVNNcgt L3JgBnFOKgDIYtSx8FCR0FOszCCDcFiai/w6EajmAEIVQeaxTNFwfhELKS/fcF6fT46ID+Z+ ejWvktai6+NtuIoOPox0/a/Mv68exNbrf/y4m+1vuFxOL1yPI+MbXsjBncWdyq75yfJIDuuT auxDaLW3906dPKTjQP+333A8AnHhx0DIu8PKgHpVqxJHYSRtmi0VkwzJPN4CYlBc7XpBj0Sp vVOoEc31FxZmuPDjkpnTrDi9fahdCInAMJ9YGwlBwJSARiDTqUUZdwRb2+wCRaq+RZ9dK5Xk pbgN0gbQq8rgenl5QzdZu3MIjAFaSC17mXlUkOi6nJVYJ+JIyft9SLNE2QHjO3JX2+KiYBtL da3Q9rUlvq4/lzHwmp6Ln21CYPViUaIZSpvhzqRrkraITn6+0TUrqNmSgAmr5AYKIZsvnGVN tZWKWXAbOSu5MhKfZ5TOY+PMh3JCt8MmsZCp/F20JnrH1I0U57JiccSCRt1SQxs8RUle/SCP /iq+3UPp3cMHv2lA4L5PdS0msCX4QSD+r1uOyPZVOfLia5YvYufhAx9ribfAq4C7LLE7NM9g wS7Lx0sF52qzo2sqmdTcRuakpq9ASmglE+EF82wf7/92TbhrTDT2FX0PiTYCqcryoTRYtOEN bBw8j+6JwHGEoQmVH6Gzhu1eDUXAqktJ1vFNtyx9rjUEUGLrIMgDrBxFT2OnGoOhyFZv1Hwc OauT8H4Dtol1G8t1YLyNu59J1+rtuHMtaYJEZ9wFW9eX88hKYp3OAUK2UrQKQcnA/47o0cMH IIrwFf8mX0Dbxj/6a/xoGNDcPGnWYgnCGkCliE5ULcLkJCFShxBGmN/O97SpmJuinb+ON56w mVEDaySvaOJk7cC5iYWOT8I32kDXk2yphHUv0Xul/vYmscAYe23So5JPZbnmWwgOqZgPOser mjZqGvDclrc8WsZOegM1Lb8ZB2cuBR43Dpx+m85ZylhejXwjd8Pvc5xo/PS6vpJCkLTZ1yOR y/7jW9Z1xt5GUyK9JQfgMiT4l1NAKcGNu7+OO17HBmIbd3tyhV3ej9DcOYZjXCW0/68wYyd/ EjH7X4eY+3Cg6bOgeJlJWAFkqp65t+acL+SDAGQdj/37OCOTGZtWwxqegg95qK895wKOHvoL P4gkkuT795DkiXLic6/6Qw26OpzUqj5zUdT5okHBLnt7a8AvUGKt2pYg5ZyVkihe5PoOiIW/ rHnIzarGYlKIMg/u1K5XPxVtEWdMPRtcr/t89XpVNNern8q1rP9au2nV6qr7fQNftBMelXRe RIZ1CkAscUkKSywxuTaJVbi3jqnNEjWAczQxSNQsDMvZzLMR+0WP7xtP/Yey3Z2aGh1HagSa mmpCn5gRflrgwfJGbtVD0nYWvXg3WGFmq+XrMZHEbkX1kQ5nDCDoC5/gYEeIzqkNecU4/Ooi psFhYECrb1+XXIPGX9eVto5cFt29B4x9E7qCPc2V9a5bIcNZXSXqJy90pVHvvgqpyUApin8L ecPGosUmgBpEmfsV79GZki6P6eoxOpmqIk4Ut1+4MqniYpOjXkR62+9oLeo0ZO8rqPzzrE6t 8oWYDAdeUDry0pegjO5fIQIf/Y9F9FJLvzYhoXVFIh6qLNXXqSSlIXL7anFI56tCkoqQF2hU h5ZwzVowon3qKVBygYqpL6aIJ1tCMsxdj0RIpYjr+gL0Mvo4AvhQtuB5bMSvZTOkxyeaJZJa AwRqJhP2Zly/m0YoHxFZDCWmvB3qR6RUH1y/88h0fqTpVF48E3kyrvrMWZv/Mbz1z+rXaz5h QP870edoC0o+cF9/xAmGT058JAuffOsV9VEVo4m+7hXu0CfbSWJ2R1f0NYCgmjYC+jZbe/jg JRfxjRccgl1LWCDfDVeAMFarabmFaymW/TbY3TM50xGZ73TljhSPOx934ApqVkuglAE3lu6z 81BKfgUBLVuynEHJUr3odChD3JQsjjJn9+l6JwI46ZKWdnbJwH/nX4s44NcXIQk7DXUoRRiA QQIE5ZyF1Fn0GIdWzEDI3xZR4NaquvTbZOn3vkOW/uGDvV06uAOe16Yp8mMXz/yV9ubohi7b 618o7b+XsrlhlmXD3V3geLi7p6RWuzsmPMYN9LLtrIaddCKEgARR4AC3TOiv3wqEshXgjiYw 2kMFKuefg+Vhtr0qgOqOX6DuNICJ87s7fcgyu/CAXx3/CepaY+7968DD+vjkXTZzWyNCDwWw Ot0gAPlQVC4MyPO+fHxYkb5/D6TvCdL3A9TP8wlbMzJagx6wEesxciOchyxCKIFP9y2rlcDt mqdoFxkq0lxAUDrK3BOizsBcw78aB4gzoJFx7rbEb+cEszpIIRkUuiexmnVjluKqeTrUduHH CCBLH3/LpJF95a7vhdtguyGCDnfNhRBl+7Uo6NRJIePCJUg9HGdicn7L9Z5kSjhP7kE4+xy/ TT6fzcjMGSszbyCoTl+QajR1zNqiiVoIsQ02XxKb3xhfwe/r3N1w/gjRH+rrFcbu0VA8zWXB 3vqWa0R1T3L9qFtEFGJBAktcjFrfVP7DimtJZJxPoYVWMifXARLrLS+zDciQ9z9tXOAKBbnU 3UIr1troihM3fsKbjDocJGmlTFuHV+v6jCvtW19rjKjEz6i7njzyFayPk9fOu2FI9AeRfTbw Z0Wr/AzdFxL3YnZHUrz2jW7GVdGYqP1xBR/uJKIwOAchjEylyKPSX1co5TNNfpVxP7UC3Pig Wur0tqaEli1XJbWtVVekpoqSvdIbn9/yEgLMXU3CWcu94tp8GxW//11UvImwwDTrmMvjmhC4 9k077t3DJqhMRwWhwkwxSabRonJJmQkyiStHoO0OXtJL34w6I5E9RegdXzlrLe48Mrc3H608 0ImrI33XstA3u2GQPjjNcyv9LVJqx9zsWT/EysKLu8Who23OlEL5tRKTWIDllbxyHN8WMxRu WnmVNW5OtbzREf7acORVmj4ugvqO07Q4qQ22+9pr17iXq0iqzWh8RZKQ7rmUhXZT7JszNG6m Y2d9iPRTQ1ifwAv1Amdaj2ORHY+u3QiKlHVRBiUebuZyvQm3zw5JK8u0O/d16xQcQlO36K4V QxRja7/YeBAk1ICMABQfDw92EWUOBoQ219de6Qa6ovuJZriDosZu5lLRFGIOIQ4Xwqqr1Mn1 FdpxUt+71cSth+N4SfeI7wXhJJOoPYkn1ZVJWz0cEO0G0q6PZBFSiHFXq4dfDSJkvSUVcQPI asdH0nrCRws/o0eQijnmLFgYVxzyeIPwdzMxo/P6PB+oUjMjYkeYj2gTf0dsyuBHGDxEoq2S dgh+u2dNCn+0mOA19Ic4pDcLEjTk9/2COkZDkhdFFm+JO80hiHlA5lQDya9dxT+Br9uB+WlR 0SrMz3QJPbaeDeRhNyShuw6O8M/5pClsaX7JSbvT76OmoGfQCtxq/lZPK/MLSLigr4/zBV27 /Gdxjfp//u49OWQVLWZU2i92aT7Ysiqu6mv6lmdjH9fllUA6RmvyiW2rAgU2+K0xpxi8NOQ1 SaT6bU6H/VvdlNY1liJP1woEHbNecB9pu7iE6JVfWPJ5FpbDo/+H0RuQAkev8Cv8GB/QafUj nq4hdse17X1NQBCA2N/be/m7MW+afFLhcE6zgdn6xYqAFZseGknqQFuR9VG7SvRHG4dYir9H iKbdGpg3B8dm7+mAzVg8aoDh3+Op2Xv58jkvnIetvXi6+/u/HYVujc/I4Y4uAekgju735szI Hw60aVvWEQ+zYi3kGgjMNqnSnehRe7//m+aDjnv5oHtD8tiTGYpEgSjdWtLmMtDMuD5vQZi/ ZnxqBzxm9arAIW+RdffKPaS/mbfR+D730K2Bn9o4cHbH7rMsWoOEkMwxyZiymNMzRvLYDxlR 4jW6O7bOXIbqCAPsouh+9MdZOu7Unj4feOeDyAJt67NzQho9/uU3Dbs8+S42GVH/PkfMvN2d l2s44Gj4Nivy8+G8IXFA5lnS4Nb+3kfSAb/BGSgemLN2PK0vbFVckgii31VKvslUMDAJ/C0b 9GF8IAmAU6GvQDiQmTgrHNlJZk5nBWq4yd/iBa0uIAkn8pkq3kLLDJ1gisw+FFHrm/c93H3i iY0QGSNr45i5/jMSsXhMe/0px3A50gXYN3n0OYTxR9n4aWbekwbt6hVsbfFOMEQbBBDPx76F U/tAmHF95vjwS+cClh945pX6UpAHLcdkNsL5Xx+Oj3deoSkSL0BEb+QZbIwDQsAK0hXLfRi3 TPMbmE/jrhYmi9DuB1cmqhckFxibIwLC3K62JbjY7k/M4m4q48BzKTG21PiPFnh1EDmvI2kf 0HWc0GNhrCjX82d/X+QlqkIJDeNpVeN1ccT3R9U4469/eP78B9C7JfublMjbxvVmnRIbvy2I s0npj8zL/b39Pf788yn/w38dQtm9Ms3lfxS2u/jrP7oi+4c+TqaX/Zn/vo3IekrU/n8BUEsB AhQAFAAAAAgAeKpOQz67F5FdOAAAKLcAAEAAAAAAAAAAAQAgAAAAAAAAAGRyYWZ0LWdlbGxl bnMtbW11c2ljLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLTAxLWdoMy1jbGVhbi50eHRQ SwUGAAAAAAEAAQBuAAAAuzgAAAAA --------------040608040603020104040905-- From adam@nostrum.com Mon Oct 14 20:28: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 1010D21E814F for ; Mon, 14 Oct 2013 20:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.83 X-Spam-Level: X-Spam-Status: No, score=-101.83 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjmi8zGBTG-5 for ; Mon, 14 Oct 2013 20:28:08 -0700 (PDT) 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 B04E021E815E for ; Mon, 14 Oct 2013 20:28:03 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9F3Rp2b078517 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 22:27:51 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <525CB632.3030602@nostrum.com> Date: Mon, 14 Oct 2013 22:27:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Thomson References: <525C7537.4080209@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020804020700080006050800" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 03:28:09 -0000 This is a multi-part message in MIME format. --------------020804020700080006050800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/14/13 19:28, Martin Thomson wrote: > On 14 October 2013 17:22, Adam Roach wrote: >> It's certainly not unsolvable, it's just unsolved. From an information perspective, it can be done unambiguously. We just need to come up with an elegant syntax. > Leaving impossibilities regarding the juxtaposition of the terms > "elegant syntax" and "SDP" aside, I don't disagree. I'm just > disappointed that you didn't try. The issue here was actually having too many ideas, not lacking any; and spelling all of them out in formal detail would have made the "open issue" much larger than was reasonable. I briefly considered putting several of them into an appendix, but writing out these approaches at the level of formality worthy of a document would have delayed things by another day or two, and I already was running much later delivering this than I was happy with. I'll sketch out three of the more interesting ways you can skin this cat below. > From an information perspective, would you consider a partial offer > that amends a group to (potentially) generate glare for all of the > lines already in that group? E.g., I have a group of "a b c" and > generate a partial offer to add "d" to that group. Does this cause > glare with an offer to amend any of "a", "b", or "c"? I would hate that. > I think that could be made to work, but I don't like the > ramifications. Without further consideration, all I can envisage is > the creation of a new grouping semantic. Maybe I'm just being a > little pessimistic. I think so. Either that or just a bit unimaginative. For the trivial case where we care *only* about being able to put new lines into bundles, we could very easily specify that any new media section that contains the same port as one or more other media sections is implicitly added to the same bundle as those media sections. It's an easy, clean, "done and done" solution. It's also very specific to solving the BUNDLE case (which is the must-have here) which means that it leaves any other grouping (LS, FID, SRF, ANAT, FEC, DDP) out to dry. For that reason, I don't think this is the approach we want. The other two solutions that I would propose, which solve the general grouping case, are somewhat less elegant syntactically (all sniping aside), and vary primarily in how they choose to identify group lines. In the first case, you identify the a=group lines at the session level by the order in which they appear (the first one has an index of 1; the second has an index of 2; and so on). Then, we could do something like define a new attribute, valid only in sdpfrag, and stripped out between partial processing and incorporation into the overall session, that indicates "this media section is also added to the indicated group." For example, if you had an ongoing session that looked like this (yeah, I'm just grabbing from RFC 5888 because it's the easiest way to demonstrate my point, although I've changed the MIDs to match the notion of randomness that pof/pan calls for): v=0 o=Laura 289083124 289083124 IN IP4 one.example.com c=IN IP4 192.0.2.1 t=0 0 a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V m=audio 30000 RTP/AVP 0 a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN m=video 30002 RTP/AVP 31 a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V And wanted to add a new video stream to the LS group, you could send a partial offer like: m=video30004 RTP/AVP 31 a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO a=add-group:1 And that would mean "add this media to the first a=group line that is indicated at the session level," resulting in an final session that looks like this: v=0 o=Laura 289083124 289083124 IN IP4 one.example.com c=IN IP4 192.0.2.1 t=0 0 a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO m=audio 30000 RTP/AVP 0 a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN m=video 30002 RTP/AVP 31 a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V m=video 30004 RTP/AVP 31 a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO (Note the on the a=group line is different than it had been before; also note that the third m-section does not include an "a=add-group" attribute, even though one was present in the partial offer). An alternate approach, if we think that the use of numerical indices to point to the group we're talking about, is to instead say "add to the group that is uniquely identified as containing at least the following MIDs (and probably some others too)." For this example, the end result is the same, but the "add-group" attribute would instead look something like this: a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V Which means "there is only one LS group that contains the MID 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V, and this media section should be added to it." If the combination of LS and "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V" were not sufficiently unique to identify the group, then the attribute would include enough other MIDs until the group were uniquely identified; e.g.: a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V ZLSQLQ*YBSYMLZD4ETXME5892052JKRN And so on. If, by some fluke, you wanted to add a new media section to a group that happened to be of the same type as another group whose members were a strict superset of the group you wanted to talk about, you'd have to fall back to a full offer. This is such an extreme corner case, however, that I don't think it bears much hand-wringing to worry about the glare that might result from such a situation. For both of these last two cases, we would probably want to allow a partial offer or partial answer to also include an "a=group" at the session level, but only if it is defining a completely new group (i.e., not expanding an existing group). If we do this, we might choose to allow such POFs and PANs to incorporate media sections that aren't described in the sdpfrag (that is, existing and otherwise unmodified media sections). This does make the index-based approach to indicating group lines a bit more fiddly, as we need to define a canonical ordering for group lines in the rare circumstance that both sides try to add a new group simultaneously. As with this issue itself, it's an eminently solvable problem, but it *is* more specification and more code. Of these three approaches, which I think are the most promising of the ones I've been able to come up with, I personally like the last one (where you describe a group by its type and the smallest set of MIDs required to uniquely identify it). I suspect they could all be refined and made slightly more elegant if we had enough people put their minds to the issue. /a --------------020804020700080006050800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 10/14/13 19:28, Martin Thomson wrote:
On 14 October 2013 17:22, Adam Roach <adam@nostrum.com> wrote:

It's certainly not unsolvable, it's just unsolved. From an information perspective, it can be done unambiguously. We just need to come up with an elegant syntax.

Leaving impossibilities regarding the juxtaposition of the terms
"elegant syntax" and "SDP" aside, I don't disagree.  I'm just
disappointed that you didn't try.

The issue here was actually having too many ideas, not lacking any; and spelling all of them out in formal detail would have made the "open issue" much larger than was reasonable. I briefly considered putting several of them into an appendix, but writing out these approaches at the level of formality worthy of a document would have delayed things by another day or two, and I already was running much later delivering this than I was happy with.

I'll sketch out three of the more interesting ways you can skin this cat below.

From an information perspective, would you consider a partial offer
that amends a group to (potentially) generate glare for all of the
lines already in that group?  E.g., I have a group of "a b c" and
generate a partial offer to add "d" to that group.  Does this cause
glare with an offer to amend any of "a", "b", or "c"?

I would hate that.

I think that could be made to work, but I don't like the
ramifications.  Without further consideration, all I can envisage is
the creation of a new grouping semantic.  Maybe I'm just being a
little pessimistic.

I think so. Either that or just a bit unimaginative.

For the trivial case where we care *only* about being able to put new lines into bundles, we could very easily specify that any new media section that contains the same port as one or more other media sections is implicitly added to the same bundle as those media sections. It's an easy, clean, "done and done" solution. It's also very specific to solving the BUNDLE case (which is the must-have here) which means that it leaves any other grouping (LS, FID, SRF, ANAT, FEC, DDP) out to dry. For that reason, I don't think this is the approach we want.

The other two solutions that I would propose, which solve the general grouping case, are somewhat less elegant syntactically (all sniping aside), and vary primarily in how they choose to identify group lines. In the first case, you identify the a=group lines at the session level by the order in which they appear (the first one has an index of 1; the second has an index of 2; and so on).

Then, we could do something like define a new attribute, valid only in sdpfrag, and stripped out between partial processing and incorporation into the overall session, that indicates "this media section is also added to the indicated group."

For example, if you had an ongoing session that looked like this (yeah, I'm just grabbing from RFC 5888 because it's the easiest way to demonstrate my point, although I've changed the MIDs to match the notion of randomness that pof/pan calls for):

v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=audio 30000 RTP/AVP 0
a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=video 30002 RTP/AVP 31
a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

    And wanted to add a new video stream to the LS group, you could send
    a partial offer like:

    

    m=video 30004 RTP/AVP 31

    a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO

    a=add-group:1

    

    And that would mean "add this media to the first a=group line that
    is indicated at the session level," resulting in an final session
    that looks like this:

    

    
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
m=audio 30000 RTP/AVP 0
a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=video 30002 RTP/AVP 31
a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=video 30004 RTP/AVP 31
a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO



    (Note the on the a=group line is different than it had been before;
    also note that the third m-section does not include an "a=add-group"
    attribute, even though one was present in the partial offer).

    

    An alternate approach, if we think that the use of numerical indices
    to point to the group we're talking about, is to instead say "add to
    the group that is uniquely identified as containing at least the
    following MIDs (and probably some others too)." For this example,
    the end result is the same, but the "add-group" attribute would
    instead look something like this:

    

    a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

    

    Which means "there is only one LS group that contains the MID
    8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V, and this media section should be
    added to it." If the combination of LS and
    "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V" were not sufficiently unique to
    identify the group, then the attribute would include enough other
    MIDs until the group were uniquely identified; e.g.:

    

    a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
    

    

    And so on. If, by some fluke, you wanted to add a new media section
    to a group that happened to be of the same type as another group
    whose members were a strict superset of the group you wanted to talk
    about, you'd have to fall back to a full offer. This is such an
    extreme corner case, however, that I don't think it bears much
    hand-wringing to worry about the glare that might result from such a
    situation.

    

    For both of these last two cases, we would probably want to allow a
    partial offer or partial answer to also include an "a=group" at the
    session level, but only if it is defining a completely new group
    (i.e., not expanding an existing group). If we do this, we might
    choose to allow such POFs and PANs to incorporate media sections
    that aren't described in the sdpfrag (that is, existing and
    otherwise unmodified media sections). This does make the index-based
    approach to indicating group lines a bit more fiddly, as we need to
    define a canonical ordering for group lines in the rare circumstance
    that both sides try to add a new group simultaneously. As with this
    issue itself, it's an eminently solvable problem, but it *is* more
    specification and more code.

    

    Of these three approaches, which I think are the most promising of
    the ones I've been able to come up with, I personally like the last
    one (where you describe a group by its type and the smallest set of
    MIDs required to uniquely identify it). I suspect they could all be
    refined and made slightly more elegant if we had enough people put
    their minds to the issue.

    

    /a

  


--------------020804020700080006050800--

From christer.holmberg@ericsson.com  Mon Oct 14 23:56: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 BD02021F92B8 for ; Mon, 14 Oct 2013 23:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.724
X-Spam-Level: 
X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.524,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOT9Sun5Oz62 for ; Mon, 14 Oct 2013 23:56:38 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8911821E8097 for ; Mon, 14 Oct 2013 23:56:32 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-a1-525ce71fd8ac
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B6.7B.16099.F17EC525; Tue, 15 Oct 2013 08:56:31 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 08:56:30 +0200
From: Christer Holmberg 
To: James Rafferty 
Thread-Topic: Comments on Example in draft-holmberg-mmusic-udptl-dtls-02
Thread-Index: AQHOyRtYidocw9Tdsk6gkjcUnbENIZn1VNyg
Date: Tue, 15 Oct 2013 06:56:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEAA5@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4AA894@ESESSMB209.ericsson.se> <525C52DB.2030806@humancomm.com>
In-Reply-To: <525C52DB.2030806@humancomm.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BEAA5ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra7885ggg1MLZS2W3HzJYjF1+WMW ByaP7i2XmT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx+P9UtoLDjhVH/z1jbGD8bdHFyMkhIWAi cf3VFkYIW0ziwr31bF2MXBxCAocZJe59X88E4SxhlDjTOAeoioODTcBCovufNkiDiICOxIbj F1hBwswC6hJXFweBmMIC7hKfdsRBVHhITF9zmhHCNpK4cuYaG4jNIqAqsfLqYVYQm1fAV2JC w1t2EFtIoEBixtt/LCA2p4CuxJEfj8F6GYFO+35qDROIzSwgLvHh4HVmiJMFJJbsOQ9li0q8 fPyPFcJWklh7eDsLRH2+xI/mk+wQuwQlTs58wjKBUXQWklGzkJTNQlIGEdeTuDF1ChuErS2x bOFrqHpdiRn/DrEgiy9gZF/FyJ6bmJmTXm64iREYTwe3/NbdwXjqnMghRmkOFiVx3g9vnYOE BNITS1KzU1MLUovii0pzUosPMTJxcEo1MBp6pjKE1Cve7H4gO/XuKfvow0nbkzTfL9150+7w zBPbpvYdy06KD/SI7gyfqjyp7U62Wq/7Jqu/E1Iaun03HVx6PrJq7ZrpTVeYGGcvUOSy/1ar 5dFy+vecae6uf44ai8c06h+Xn+DtbDW1eu7OyaptdVcY9wccC+vQZt7wLzLh9cSz64JyTiix FGckGmoxFxUnAgCeJ7C8dQIAAA==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Comments on Example in draft-holmberg-mmusic-udptl-dtls-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: Tue, 15 Oct 2013 06:56:43 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEAA5ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi James,

Thanks for your comment! It seems to make sense. We'll take it into conside=
ration when submitting the next version of the draft.

Regards,

Christer

L=E4hett=E4j=E4: James Rafferty [mailto:jrafferty@humancomm.com]
L=E4hetetty: 14. lokakuuta 2013 23:24
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org
Aihe: Comments on Example in draft-holmberg-mmusic-udptl-dtls-02

Hi Christer,

I read the latest -02 draft.

My main comment is on the example in Appendix A.  In normal use of T.38 UDP=
TL with SIP, the sessions all tend to begin with a Voice over IP SIP sessio=
n, then a re-invite is used to initiate the UDPTL fax session.  In the earl=
y days of T.38, the main use case was the VoIP / FoIP gateway, so there was=
 always a voice session first.   We're starting to see some IAF use of T.38=
 now, but the implementations tend to abide by the convention of starting w=
ith VoIP first, then switching to fax.

I don't think we need to modify the example in the draft, but just have a s=
entence or two, or a note, saying that the example shows how the secure UDP=
TL session will work once the need for an IP fax session has been establish=
ed.

James

On 9/24/2013 2:38 AM, Christer Holmberg wrote:
Hi fax lovers,

We've submitted a new version (-02) of the draft-holmberg-mmusic-udptl-dtls=
 draft.

There are no technical changes in the new version, but we've done some edit=
orial changes. Also, Gonzalo Salgueiro has been added as co-author of the d=
raft.

Regards,

Christer




_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic


--_000_7594FB04B1934943A5C02806D1A2204B1C4BEAA5ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Jame=
s,


&n=
bsp;


Thanks =
for your comment! It seems to make sense. We’ll take it into consider=
ation when submitting the next version of the draft.


&n=
bsp;


Regards=
,


&n=
bsp;


Christe=
r


&n=
bsp;






L=E4h=
ett=E4j=E4: James Ra=
fferty [mailto:jrafferty@humancomm.com]


L=E4hetetty: 14. lokakuuta 2013 23:24

Vastaanottaja: Christer Holmberg

Kopio: mmusic@ietf.org

Aihe: Comments on Example in draft-holmberg-mmusic-udptl-dtls-02






 




Hi Christer, 



I read the latest -02 draft.  



My main comment is on the example in Appendix A.  In normal use of T.3=
8 UDPTL with SIP, the sessions all tend to begin with a Voice over IP SIP s=
ession, then a re-invite is used to initiate the UDPTL fax session.  I=
n the early days of T.38, the main use case
 was the VoIP / FoIP gateway, so there was always a voice session first.&nb=
sp;  We're starting to see some IAF use of T.38 now, but the implement=
ations tend to abide by the convention of starting with VoIP first, then sw=
itching to fax. 




I don't think we need to modify the example in the draft, but just have a s=
entence or two, or a note, saying that the example shows how the secure UDP=
TL session will work once the need for an IP fax session has been establish=
ed. 




James  



On 9/24/2013 2:38 AM, Christer Holmberg wrote:






Hi fax lovers,


 


We’ve submitted a new version (-02) of the dra=
ft-holmberg-mmusic-udptl-dtls draft.


 


There are no technical changes in the new version, b=
ut we’ve done some editorial changes. Also, Gonzalo Salgueiro has bee=
n added as co-author of the draft.


 


Regards,


 


Christer











_______________________________________________


mmusic mailing list


mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic




 






--_000_7594FB04B1934943A5C02806D1A2204B1C4BEAA5ESESSMB209erics_--

From christer.holmberg@ericsson.com  Mon Oct 14 23:59: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 E42CE21E80B5 for ; Mon, 14 Oct 2013 23:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.45
X-Spam-Level: 
X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[AWL=0.199,  BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMMHQThcYICz for ; Mon, 14 Oct 2013 23:59:25 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA57521E80AE for ; Mon, 14 Oct 2013 23:59:21 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-35-525ce7c8f121
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 68.EB.16099.8C7EC525; Tue, 15 Oct 2013 08:59:20 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 08:59:20 +0200
From: Christer Holmberg 
To: Christian Groves , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05
Thread-Index: AQHOyTo1KEU3Tm7zLEKYXCiwQVD7ppn1VQxQ
Date: Tue, 15 Oct 2013 06:59:19 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEABF@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4BDF94@ESESSMB209.ericsson.se> <525C86A3.1080301@nteczone.com>
In-Reply-To: <525C86A3.1080301@nteczone.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre6J5zFBBqdOW1t8ed/IYjF1+WMW ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStjy91djAWX+CvO7TrD3MD4mKeLkZNDQsBE 4t3LdYwQtpjEhXvr2boYuTiEBA4zShxe/JEVwlnCKDH35B6gDAcHm4CFRPc/bZAGEYFoiUkL m9lAbGGBMIkPh1vYIOLhEuvXvmaHsI0kli58DRZnEVCVmHr9IROIzSvgK/F+0XEwW0ggX2L5 9vVg9ZwCOhLnTqxmAbEZgQ76fmoNWA2zgLjEh4PXmSEOFZBYsuc8lC0q8fLxP1YIW0li7eHt LBD1ehI3pk5hg7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNe briJERgLB7f81t3BeOqcyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw SsQK/2qbFnVzy48jS92WTbBeptrBxFDwwyglZP7Sue/Xq0ZuylyxetGxlS3Jglqr4tLDr1z7 n7bgG3/F9NsmoRfUKk0/PPjtv3Ang+rGxtMXrUOqG1atemnRes9nr/CUlx2BURfWR5oIXtM5 /Nowvm/pz596k3fcXXuoTrM54pTkbYvkw6vuPFViKc5INNRiLipOBACJ+zM5UwIAAA==
Subject: Re: [MMUSIC] Draft new version:	draft-ietf-mmusic-sdp-bundle-negotiation-05
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 Oct 2013 06:59:31 -0000

Hi Christian,

I believe you asked me this question before, my answer was that the current=
 scope is only IPv4/IPv6, and I agreed to mention it in the draft.

It seems like I forgot to do that, but I'll add some text in the next versi=
on. Thanks for reminding me!

Regards,

Christer






-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P=
uolesta Christian Groves
L=E4hetetty: 15. lokakuuta 2013 3:05
Vastaanottaja: mmusic@ietf.org
Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiat=
ion-05

Hello Christer,

The SDP grouping mechanism can be applied to different nettype/addrtypes. T=
he BUNDLE draft appears to define behaviour related only to the nettype=3DI=
N and addrtypes=3DIPv4/IPv6. i.e. section 2 defines BUNDLE terminology base=
d on IP.

Is there an intention that the BUNDLE mechanism is only used for the above =
net and addrtypes? If so should it be mentioned somewhere in the applicabil=
ity statement?

Regards, Christian

On 14/10/2013 10:37 PM, Christer Holmberg wrote:
>
> Hi,
>
> I've submitted a new version of the BUNDLE draft.
>
> I have implemented the modified text for the Offerer and Answerer=20
> procedures, as presented on the list in September.
>
> The procedures now also mention the usage of the SDP 'bundle-only'=20
> attribute. However, the attribute definition itself has yet not been=20
> added to the draft, as we still haven't solved the issue regarding=20
> usage of port zero.
>
> In addition, there are some reference corrections, and the FQDN values=20
> in the examples are now according to RFC 2606.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> 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 adam@nostrum.com  Tue Oct 15 08:52: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 89DBA21F9E6B for ; Tue, 15 Oct 2013 08:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.358
X-Spam-Level: 
X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TOdYGBstGsU for ; Tue, 15 Oct 2013 08:52:09 -0700 (PDT)
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 B66B521F9E3B for ; Tue, 15 Oct 2013 08:52:08 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FFq3ZD066369 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Oct 2013 10:52:03 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525D649E.5040608@nostrum.com>
Date: Tue, 15 Oct 2013 10:51:58 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "mmusic@ietf.org" 
Content-Type: multipart/alternative; boundary="------------080006050401020700030105"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 15:52:20 -0000

This is a multi-part message in MIME format.
--------------080006050401020700030105
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

There's been a bit of a brouhaha (from small but disproportionately 
vocal quarters) around the use of port zero in an offer for bundle-only 
lines. So I wanted to take a step back and see whether we could untangle 
this knot a bit.

The key property that we need here is that bundle-only lines must be 
formed in a way that causes them to be rejected by non-bundling agents, 
but accepted by bundling agents. Since bundle deals with ports, that 
seems like an extremely natural place to make the distinction. It has 
the spectacular advantage of being defined in a crystal clear way in RFC 
3264:

   "A port number of zero in the offer indicates that the
    stream is offered but MUST NOT be used.  This has no useful semantics
    in an initial offer, but is allowed for reasons of completeness..."

   "A stream that is offered with a port of zero MUST be marked with port
    zero in the answer."

By overriding this second normative statement for bundle clients, we 
turn it into an extremely well-defined extension point.

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

But this is exactly the approach that is causing people heartburn, so 
let's look at other potential ways of achieving the goal. In a media 
section, there are only a small handful of fields that an implementation 
is required to read and understand:

   m= /   ...
   c=  

Taken one-by-one:

 1. Extending "media" would be somewhat problematic, since we use this
    information extensively in our use cases. We would effectively have
    to register bundle-only variations on "audio," "video," and
    "application" (at a minimum), which is horribly inelegant.

 2. Port is discussed above.

 3. Setting "number of ports" to zero would clearly have the semantics
    that we're interested in here. The down-side of using this approach
    is that (in my experience) there are a lot of implementations that
    simply ignore the "number of ports" field, and a small handful that
    simply choke when it is present.

 4. Proto is an interesting one. Right now, we use RTP/SAVPF and
    DTLS/SCTP. We could conceivably additionally register
    RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would
    presumably be rejected by non-bundle clients as unrecognized.

 5. Fmt isn't really an option -- we need to use it to identify formats.

 6. Moving on to the c= line (which, if present, is mandatory to parse,
    understand, and honor), nettype is pretty much hardwired to "IN." We
    could register an "IN-BUNDLEONLY" option, but there's a good chance
    that implementations don't really look at the value of this field,
    so they wouldn't reject the new value.

 7. Addrtype is necessary for indicating IP4 versus IP6. We could
    register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is
    approximately as elegant as option #1.

 8. Overloading connection-address would be dicey, since it ruins the
    ability to send different streams to different places. While WebRTC
    might not care too much about these use cases, they *are* important
    in other contexts.

In summary: of the above options, the strongest option still seems to be 
"port," followed (perhaps) by "proto." We could probably force "media" 
or "addrtype" to work, but these would be pretty messy. I think "number 
of ports" and "nettype" are at high risk of being ignored by non-bundle 
implementations (i.e., they won't trigger the failure we want), and we 
need to maintain the existing meanings for "fmt" and "connection-address".

Even more tersely: if we don't want to port zero, I think the only other 
realistic option is registering new "proto" values.

/a


--------------080006050401020700030105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    There's been a bit of a brouhaha (from small but disproportionately
    vocal quarters) around the use of port zero in an offer for
    bundle-only lines. So I wanted to take a step back and see whether
    we could untangle this knot a bit.

    

    The key property that we need here is that bundle-only lines must be
    formed in a way that causes them to be rejected by non-bundling
    agents, but accepted by bundling agents. Since bundle deals with
    ports, that seems like an extremely natural place to make the
    distinction. It has the spectacular advantage of being defined in a
    crystal clear way in RFC 3264:

    

      "A port number of zero in the offer indicates that the

       stream is offered but MUST NOT be used.  This has no useful
    semantics

       in an initial offer, but is allowed for reasons of
    completeness..."

    

      "A stream that is offered with a port of zero MUST be marked with
    port

       zero in the answer."

    

    By overriding this second normative statement for bundle clients, we
    turn it into an extremely well-defined extension point.

    

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

    

    But this is exactly the approach that is causing people heartburn,
    so let's look at other potential ways of achieving the goal. In a
    media section, there are only a small handful of fields that an
    implementation is required to read and understand:

    

      m=<media> <port>/<number of ports> <proto>
    <fmt> ...

      c=<nettype> <addrtype> <connection-address>

    

    Taken one-by-one:

    

    
    
      
  1. Extending "media" would be somewhat problematic, since we use
        this information extensively in our use cases. We would
        effectively have to register bundle-only variations on "audio,"
        "video," and "application" (at a minimum), which is horribly
        inelegant.
    
        
    
      
    2. 
      
  2. Port is discussed above.
    
        
    
      
    3. 
      
  3. Setting "number of ports" to zero would clearly have the
        semantics that we're interested in here. The down-side of using
        this approach is that (in my experience) there are a lot of
        implementations that simply ignore the "number of ports" field,
        and a small handful that simply choke when it is present.
    
        
    
      
    4. 
      
  4. Proto is an interesting one. Right now, we use RTP/SAVPF and
        DTLS/SCTP. We could conceivably additionally register
        RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would
        presumably be rejected by non-bundle clients as unrecognized.
    
        
    
      
    5. 
      
  5. Fmt isn't really an option -- we need to use it to identify
        formats.
    
        
    
      
    6. 
      
  6. Moving on to the c= line (which, if present, is mandatory to
        parse, understand, and honor), nettype is pretty much hardwired
        to "IN." We could register an "IN-BUNDLEONLY" option, but
        there's a good chance that implementations don't really look at
        the value of this field, so they wouldn't reject the new value.
    
        
    
      
    7. 
      
  7. Addrtype is necessary for indicating IP4 versus IP6. We could
        register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is
        approximately as elegant as option #1.
    
        
    
      
    8. 
      
  8. Overloading connection-address would be dicey, since it ruins
        the ability to send different streams to different places. While
        WebRTC might not care too much about these use cases, they *are*
        important in other contexts.
    9. 
    

    
In summary: of the above options, the strongest option still
      seems to be "port," followed (perhaps) by "proto." We could
      probably force "media" or "addrtype" to work, but these would be
      pretty messy. I think "number of ports" and "nettype" are at high
      risk of being ignored by non-bundle implementations (i.e., they
      won't trigger the failure we want), and we need to maintain the
      existing meanings for "fmt" and "connection-address".

    

    
Even more tersely: if we don't want to port zero, I think the
      only other realistic option is registering new "proto" values.

    

    
/a

    

  


--------------080006050401020700030105--

From christer.holmberg@ericsson.com  Tue Oct 15 09:05: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 5AAD521F9E3B for ; Tue, 15 Oct 2013 09:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.158
X-Spam-Level: 
X-Spam-Status: No, score=-5.158 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7dUMYMZEkse for ; Tue, 15 Oct 2013 09:04:53 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C16CA21F9DD6 for ; Tue, 15 Oct 2013 09:04:51 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-5c-525d67a2daab
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.93.16099.2A76D525; Tue, 15 Oct 2013 18:04:50 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 18:04:49 +0200
From: Christer Holmberg 
To: Adam Roach , Martin Thomson 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft
Thread-Index: AQHOyS/VDi7jGJKfu0+LtCEoj80NX5n0xEsAgAABJ4CAAAG3gIAAMfgAgADxe5aAAAORvg==
Date: Tue, 15 Oct 2013 16:04:49 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEEE8@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com>   , <525CB632.3030602@nostrum.com>
In-Reply-To: <525CB632.3030602@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BEEE8ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvre6i9Nggg40dkhZ7/i5it7h25h+j xdTlj1kcmD12zrrL7rFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZezrec9UMKG+4uDL/0wN jNszuhg5OCQETCS6Z0d2MXICmWISF+6tZwOxhQQOM0r8fy4AYS9hlPhw1A6knE3AQqL7nzZI WETAR2Lq7ZvMIGFmAXWJq4uDQMLCQBVzfs1khSixlJj0Zg47hB0m0fjqGJjNIqAqsX/RNjCb V8BX4kL/L5YuRi6gTT1MEg+mHgA7gVNAW+Jpfw/YIEag076fWsMEYjMLiEvcejKfCeJkAYkl e84zQ9iiEi8f/2OFsBUl2p82MELU50tcn72BBWKZoMTJmU9YJjCKzkIyahaSsllIyiDiehI3 pk5hg7C1JZYtfM0MYetKzPh3CKrGWuLb2SnsyGoWMHKsYmTPTczMSS833MQIjLyDW37r7mA8 dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg5oiwXbt6we0NWxg7l eObHR5Sb3s/e/X5Cm3WVx8zkpV1bzTecTs7WvqqQ5/kh8H3PrhWaMgKxSUZ/7gf80tDL8yjK m9mj+a9akKVyqsmPoDePFk7/tm2vYPfqWNWZin7a85P8uRjXvec1qRRnmlD2LdGx5bx2hsE8 s9NflTI/hOxmmlrz0FGJpTgj0VCLuag4EQDDdNhNigIAAA==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 16:05:00 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEEE8ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

> From an information perspective, would you consider a partial offer
> that amends a group to (potentially) generate glare for all of the
> lines already in that group?  E.g., I have a group of "a b c" and
> generate a partial offer to add "d" to that group.  Does this cause
> glare with an offer to amend any of "a", "b", or "c"?

Well, there are cases where the adding of "d" could implicitly affect "a", =
"b" and/or "c".

Example:

    - Assume you use BUNDLE, and "a", "b" and "c" have previuosly been adde=
d to a BUNDLE group, sharing a single address.

    - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND also=
 requests the "d" address to become the new BUNDLE address.

    - If the new address is approved by the answerer (Bob), that means that=
 the address of "a", "b" and "c" will implicitly change.

    - Now, if Bob at the same time sends a POF in the other direction, towa=
rds Alice, modifying "a", "b" and/or "c", there might be a glare situation,=
 in which Alice should reject the POF.

The easiest way to prevent this would be to say that an Offer/POF, MUST inc=
lude all m- lines which may be affected (explictily or implicitly) by the O=
ffer/POF.

Maybe change of BUNDLE address isn't the most realistic example, but there =
are also SDP attributes etc which must be identical for each m- line within=
 a BUNDLE group, etc.

Regards,

Christer



















I would hate that.


I think that could be made to work, but I don't like the
ramifications.  Without further consideration, all I can envisage is
the creation of a new grouping semantic.  Maybe I'm just being a
little pessimistic.


I think so. Either that or just a bit unimaginative.

For the trivial case where we care *only* about being able to put new lines=
 into bundles, we could very easily specify that any new media section that=
 contains the same port as one or more other media sections is implicitly a=
dded to the same bundle as those media sections. It's an easy, clean, "done=
 and done" solution. It's also very specific to solving the BUNDLE case (wh=
ich is the must-have here) which means that it leaves any other grouping (L=
S, FID, SRF, ANAT, FEC, DDP) out to dry. For that reason, I don't think thi=
s is the approach we want.

The other two solutions that I would propose, which solve the general group=
ing case, are somewhat less elegant syntactically (all sniping aside), and =
vary primarily in how they choose to identify group lines. In the first cas=
e, you identify the a=3Dgroup lines at the session level by the order in wh=
ich they appear (the first one has an index of 1; the second has an index o=
f 2; and so on).

Then, we could do something like define a new attribute, valid only in sdpf=
rag, and stripped out between partial processing and incorporation into the=
 overall session, that indicates "this media section is also added to the i=
ndicated group."

For example, if you had an ongoing session that looked like this (yeah, I'm=
 just grabbing from RFC 5888 because it's the easiest way to demonstrate my=
 point, although I've changed the MIDs to match the notion of randomness th=
at pof/pan calls for):


v=3D0
o=3DLaura 289083124 289083124 IN IP4 one.example.com
c=3DIN IP4 192.0.2.1
t=3D0 0
a=3Dgroup:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-=
J1V
m=3Daudio 30000 RTP/AVP 0
a=3Dmid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=3Dvideo 30002 RTP/AVP 31
a=3Dmid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V


And wanted to add a new video stream to the LS group, you could send a part=
ial offer like:

m=3Dvideo 30004 RTP/AVP 31
a=3Dmid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
a=3Dadd-group:1

And that would mean "add this media to the first a=3Dgroup line that is ind=
icated at the session level," resulting in an final session that looks like=
 this:


v=3D0
o=3DLaura 289083124 289083124 IN IP4 one.example.com
c=3DIN IP4 192.0.2.1
t=3D0 0
a=3Dgroup:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-=
J1V
UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
m=3Daudio 30000 RTP/AVP 0
a=3Dmid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=3Dvideo 30002 RTP/AVP 31
a=3Dmid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=3Dvideo 30004 RTP/AVP 31
a=3Dmid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO



(Note the on the a=3Dgroup line is different than it had been before; also =
note that the third m-section does not include an "a=3Dadd-group" attribute=
, even though one was present in the partial offer).

An alternate approach, if we think that the use of numerical indices to poi=
nt to the group we're talking about, is to instead say "add to the group th=
at is uniquely identified as containing at least the following MIDs (and pr=
obably some others too)." For this example, the end result is the same, but=
 the "add-group" attribute would instead look something like this:

a=3Dadd-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

Which means "there is only one LS group that contains the MID 8WVTFSA^ASZ7R=
70!9#OZ0WRKA0BR-J1V, and this media section should be added to it." If the =
combination of LS and "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V" were not sufficien=
tly unique to identify the group, then the attribute would include enough o=
ther MIDs until the group were uniquely identified; e.g.:

a=3Dadd-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V ZLSQLQ*YBSYMLZD4ETXME5892=
052JKRN

And so on. If, by some fluke, you wanted to add a new media section to a gr=
oup that happened to be of the same type as another group whose members wer=
e a strict superset of the group you wanted to talk about, you'd have to fa=
ll back to a full offer. This is such an extreme corner case, however, that=
 I don't think it bears much hand-wringing to worry about the glare that mi=
ght result from such a situation.

For both of these last two cases, we would probably want to allow a partial=
 offer or partial answer to also include an "a=3Dgroup" at the session leve=
l, but only if it is defining a completely new group (i.e., not expanding a=
n existing group). If we do this, we might choose to allow such POFs and PA=
Ns to incorporate media sections that aren't described in the sdpfrag (that=
 is, existing and otherwise unmodified media sections). This does make the =
index-based approach to indicating group lines a bit more fiddly, as we nee=
d to define a canonical ordering for group lines in the rare circumstance t=
hat both sides try to add a new group simultaneously. As with this issue it=
self, it's an eminently solvable problem, but it *is* more specification an=
d more code.

Of these three approaches, which I think are the most promising of the ones=
 I've been able to come up with, I personally like the last one (where you =
describe a group by its type and the smallest set of MIDs required to uniqu=
ely identify it). I suspect they could all be refined and made slightly mor=
e elegant if we had enough people put their minds to the issue.

/a

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEEE8ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <33F71DB7FAFFA446B88E0D9C3BA3ED5F@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


> From an information perspective, would you consider a partial off=
er=0A=
> that amends a group to (potentially) generate glare for all of the=0A=
> lines already in that group?  E.g., I have a group of "a b c"=
; and=0A=
> generate a partial offer to add "d" to that group.  Does thi=
s cause=0A=
> glare with an offer to amend any of "a", "b", or &=
quot;c"?


Well, there are cases where the adding of "d" could implicit=
ly affect "a", "b" and/or "c".


Example:


    - Assume you use BUNDLE, and "a", &q=
uot;b" and "c" have previuosly been added to a BUNDLE group,=
 sharing a single address. 


    - Then, Alice sends a POF, which adds "d&=
quot; to the BUNDLE group, AND also requests the "d" address to b=
ecome the new BUNDLE address. 


    - If the new address is approved by the answer=
er (Bob), that means that the address of "a", "b" and &=
quot;c" will implicitly change.


    - Now, if Bob at the same time sends a POF in =
the other direction, towards Alice, modifying "a", "b" =
and/or "c", there might be a glare situation, in which Alice shou=
ld reject the POF.


The easiest way to prevent this would be to say that an Offer/POF, MUS=
T include all m- lines which may be affected (explictily or implicitly) by =
the Offer/POF.


Maybe change of BUNDLE address isn't the most realistic example, but t=
here are also SDP attributes etc which must be identical for each m- line w=
ithin a BUNDLE group, etc.


Regards,


Christer


 


 


 


 


 


 


 


 


 






I would hate that.








I think that could be made to work, but I don't like the=0A=
ramifications.  Without further consideration, all I can envisage is=0A=
the creation of a new grouping semantic.  Maybe I'm just being a=0A=
little pessimistic.=0A=






I think so. Either that or just a bit unimaginative.



For the trivial case where we care *only* about being able to put new lines=
 into bundles, we could very easily specify that any new media section that=
 contains the same port as one or more other media sections is implicitly a=
dded to the same bundle as those
 media sections. It's an easy, clean, "done and done" solution. I=
t's also very specific to solving the BUNDLE case (which is the must-have h=
ere) which means that it leaves any other grouping (LS, FID, SRF, ANAT, FEC=
, DDP) out to dry. For that reason, I don't
 think this is the approach we want.



The other two solutions that I would propose, which solve the general group=
ing case, are somewhat less elegant syntactically (all sniping aside), and =
vary primarily in how they choose to identify group lines. In the first cas=
e, you identify the a=3Dgroup lines
 at the session level by the order in which they appear (the first one has =
an index of 1; the second has an index of 2; and so on).



Then, we could do something like define a new attribute, valid only in sdpf=
rag, and stripped out between partial processing and incorporation into the=
 overall session, that indicates "this media section is also added to =
the indicated group."



For example, if you had an ongoing session that looked like this (yeah, I'm=
 just grabbing from RFC 5888 because it's the easiest way to demonstrate my=
 point, although I've changed the MIDs to match the notion of randomness th=
at pof/pan calls for):




v=3D0=0A=
o=3DLaura 289083124 289083124 IN IP4 one.example.com=0A=
c=3DIN IP4 192.0.2.1=0A=
t=3D0 0=0A=
a=3Dgroup:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-=
J1V=0A=
m=3Daudio 30000 RTP/AVP 0=0A=
a=3Dmid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN=0A=
m=3Dvideo 30002 RTP/AVP 31=0A=
a=3Dmid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V=0A=


And wanted to add a new video stream to the LS group, you could send a part=
ial offer like:



m=3Dvideo 30004 RTP/AVP 31

a=3Dmid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO

a=3Dadd-group:1



And that would mean "add this media to the first a=3Dgroup line that i=
s indicated at the session level," resulting in an final session that =
looks like this:




v=3D0=0A=
o=3DLaura 289083124 289083124 IN IP4 one.example.com=0A=
c=3DIN IP4 192.0.2.1=0A=
t=3D0 0=0A=
a=3Dgroup:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-=
J1V=0A=
UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO=0A=
m=3Daudio 30000 RTP/AVP 0=0A=
a=3Dmid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN=0A=
m=3Dvideo 30002 RTP/AVP 31=0A=
a=3Dmid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V=0A=
m=3Dvideo 30004 RTP/AVP 31=0A=
a=3Dmid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO=0A=
=0A=


(Note the on the a=3Dgroup line is different than it had been before; also =
note that the third m-section does not include an "a=3Dadd-group"=
 attribute, even though one was present in the partial offer).



An alternate approach, if we think that the use of numerical indices to poi=
nt to the group we're talking about, is to instead say "add to the gro=
up that is uniquely identified as containing at least the following MIDs (a=
nd probably some others too)." For this
 example, the end result is the same, but the "add-group" attribu=
te would instead look something like this:



a=3Dadd-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V



Which means "there is only one LS group that contains the MID 8WVTFSA^=
ASZ7R70!9#OZ0WRKA0BR-J1V, and this media section should be added to it.&quo=
t; If the combination of LS and "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V"=
; were not sufficiently unique to identify the group,
 then the attribute would include enough other MIDs until the group were un=
iquely identified; e.g.:



a=3Dadd-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V ZLS=
QLQ*YBSYMLZD4ETXME5892052JKRN




And so on. If, by some fluke, you wanted to add a new media section to a gr=
oup that happened to be of the same type as another group whose members wer=
e a strict superset of the group you wanted to talk about, you'd have to fa=
ll back to a full offer. This is
 such an extreme corner case, however, that I don't think it bears much han=
d-wringing to worry about the glare that might result from such a situation=
.



For both of these last two cases, we would probably want to allow a partial=
 offer or partial answer to also include an "a=3Dgroup" at the se=
ssion level, but only if it is defining a completely new group (i.e., not e=
xpanding an existing group). If we do this,
 we might choose to allow such POFs and PANs to incorporate media sections =
that aren't described in the sdpfrag (that is, existing and otherwise unmod=
ified media sections). This does make the index-based approach to indicatin=
g group lines a bit more fiddly,
 as we need to define a canonical ordering for group lines in the rare circ=
umstance that both sides try to add a new group simultaneously. As with thi=
s issue itself, it's an eminently solvable problem, but it *is* more specif=
ication and more code.



Of these three approaches, which I think are the most promising of the ones=
 I've been able to come up with, I personally like the last one (where you =
describe a group by its type and the smallest set of MIDs required to uniqu=
ely identify it). I suspect they
 could all be refined and made slightly more elegant if we had enough peopl=
e put their minds to the issue.



/a








--_000_7594FB04B1934943A5C02806D1A2204B1C4BEEE8ESESSMB209erics_--

From adam@nostrum.com  Tue Oct 15 09:13:56 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 3661211E818C for ; Tue, 15 Oct 2013 09:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.393
X-Spam-Level: 
X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX4036ieXJ32 for ; Tue, 15 Oct 2013 09:13:55 -0700 (PDT)
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 98ABD11E8140 for ; Tue, 15 Oct 2013 09:13:49 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FGDhhk070462 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 11:13:44 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525D69B2.7080905@nostrum.com>
Date: Tue, 15 Oct 2013 11:13:38 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Martin Thomson 
References: <525C7537.4080209@nostrum.com>			, <525CB632.3030602@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BEEE8@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BEEE8@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 16:13:56 -0000

On 10/15/13 11:04, Christer Holmberg wrote:
> - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND 
> also requests the "d" address to become the new BUNDLE address.

I think you've simply identified one more class of thing we need to 
prohibit in a partial offer. Either that or:

> The easiest way to prevent this would be to say that an Offer/POF, 
> MUST include all m- lines which may be affected (explictily or 
> implicitly) by the Offer/POF.

Which I think would work, but (for the cases we care about for WebRTC, 
at least) would be approximately as likely to glare as a full offer.


/a

From christer.holmberg@ericsson.com  Tue Oct 15 09:26:12 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 6DD6E21F9CCC for ; Tue, 15 Oct 2013 09:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.754
X-Spam-Level: 
X-Spam-Status: No, score=-5.754 tagged_above=-999 required=5 tests=[AWL=0.494,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmFCX8JUWldK for ; Tue, 15 Oct 2013 09:26:06 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3BC21E80F1 for ; Tue, 15 Oct 2013 09:25:30 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-e9-525d6c78a4ad
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FD.F5.16099.87C6D525; Tue, 15 Oct 2013 18:25:29 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 18:25:28 +0200
From: Christer Holmberg 
To: Adam Roach , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Bundle-only, Port 0, and other options
Thread-Index: AQHOyb6UYlrVbVrjzE+6A+wFMyNYppn17aY2gAAFL7w=
Date: Tue, 15 Oct 2013 16:25:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEF17@ESESSMB209.ericsson.se>
References: <525D649E.5040608@nostrum.com>
In-Reply-To: <525D649E.5040608@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BEF17ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrW5lTmyQQe9HVos9fxexW0xd/pjF gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MpYumIOU8HqiIp3pxUbGF97dDFyckgImEjc efKXEcIWk7hwbz1bFyMXh5DAYUaJzq7D7BDOEkaJZXMXADkcHGwCFhLd/7RBTBEBN4l5p9JB eoUFbCSu3pvKBGKLCNhK/P/QywxhW0lMfLgLzGYRUJW4/ukS2C5eAV+J6VM2sIDYQgJaEu9e vQKLcwpoS8x8ewcszgh0z/dTa8BmMguIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwFSXanzYw QtTnSyw50c4EsUtQ4uTMJywTGEVmIRk1C0nZLCRlEHE9iRtTp7BB2NoSyxa+ZoawdSVm/DsE VWMt0bnmBzOymgWMHKsY2XMTM3PSyw03MQLj6eCW37o7GE+dEznEKM3BoiTO++Gtc5CQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxkiJ3t6XxRl5yz1CF3kdu3TfYo7WpEx3B/ZJcl4XhVce zeNhebyna0edKi/bkjTtu11Nvy6eO/n1/FoT6cbqKZ+0eO1XFk63yzwj8vN5eGT3yoi06a5F h69d+ydtflhh/4kFxxL/FR2UeOXHFypz0qfAZ+87lnffZvrWMXqv2snG5b354UnxZUosxRmJ hlrMRcWJAGBWG9N1AgAA
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 16:26:12 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEF17ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Adam,



I have also been thinking about defining new BUNDLE values for media types,=
 address types etc, but I agree it's probably something we shouldn't do - a=
t least not for media type and net/address type.



Also, your alternatives are based on the assumption the the bundle-only m- =
lines are added before it is known whether the Answerer supports. There has=
 been a suggestion that the bundle-only m- lines are added in the "2nd Offe=
r" (BAS Offer in BUNDLE), when the Answerer has indicated support of BUNDLE=
, and selected the BUNDLE address for the Offerer. In that case, the BUNDLE=
 address can be addded to each m- line (including the bundle-only m- lines)=
 in the BUNDLE group.



Regards,



Christer



________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Adam R=
oach [adam@nostrum.com]
Sent: Tuesday, 15 October 2013 6:51 PM
To: mmusic@ietf.org
Subject: [MMUSIC] Bundle-only, Port 0, and other options

There's been a bit of a brouhaha (from small but disproportionately vocal q=
uarters) around the use of port zero in an offer for bundle-only lines. So =
I wanted to take a step back and see whether we could untangle this knot a =
bit.

The key property that we need here is that bundle-only lines must be formed=
 in a way that causes them to be rejected by non-bundling agents, but accep=
ted by bundling agents. Since bundle deals with ports, that seems like an e=
xtremely natural place to make the distinction. It has the spectacular adva=
ntage of being defined in a crystal clear way in RFC 3264:

  "A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness..."

  "A stream that is offered with a port of zero MUST be marked with port
   zero in the answer."

By overriding this second normative statement for bundle clients, we turn i=
t into an extremely well-defined extension point.

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

But this is exactly the approach that is causing people heartburn, so let's=
 look at other potential ways of achieving the goal. In a media section, th=
ere are only a small handful of fields that an implementation is required t=
o read and understand:

  m=3D /   ...
  c=3D  

Taken one-by-one:


  1.  Extending "media" would be somewhat problematic, since we use this in=
formation extensively in our use cases. We would effectively have to regist=
er bundle-only variations on "audio," "video," and "application" (at a mini=
mum), which is horribly inelegant.

  2.  Port is discussed above.

  3.  Setting "number of ports" to zero would clearly have the semantics th=
at we're interested in here. The down-side of using this approach is that (=
in my experience) there are a lot of implementations that simply ignore the=
 "number of ports" field, and a small handful that simply choke when it is =
present.

  4.  Proto is an interesting one. Right now, we use RTP/SAVPF and DTLS/SCT=
P. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY and DTLS=
/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle clients =
as unrecognized.

  5.  Fmt isn't really an option -- we need to use it to identify formats.

  6.  Moving on to the c=3D line (which, if present, is mandatory to parse,=
 understand, and honor), nettype is pretty much hardwired to "IN." We could=
 register an "IN-BUNDLEONLY" option, but there's a good chance that impleme=
ntations don't really look at the value of this field, so they wouldn't rej=
ect the new value.

  7.  Addrtype is necessary for indicating IP4 versus IP6. We could registe=
r IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as elegant a=
s option #1.

  8.  Overloading connection-address would be dicey, since it ruins the abi=
lity to send different streams to different places. While WebRTC might not =
care too much about these use cases, they *are* important in other contexts=
.

In summary: of the above options, the strongest option still seems to be "p=
ort," followed (perhaps) by "proto." We could probably force "media" or "ad=
drtype" to work, but these would be pretty messy. I think "number of ports"=
 and "nettype" are at high risk of being ignored by non-bundle implementati=
ons (i.e., they won't trigger the failure we want), and we need to maintain=
 the existing meanings for "fmt" and "connection-address".

Even more tersely: if we don't want to port zero, I think the only other re=
alistic option is registering new "proto" values.

/a

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEF17ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










Hi Adam,


 


I have also been thinking about defining new BUNDLE values for media typ=
es, address types etc, but I agree it's probably something we shouldn't do =
- at least not for media type and net/address type.


 


Also, your alternatives are based on the assumption the the bundle-only =
m- lines are added before it is known whether the Answerer supports. There =
has been a suggestion that the bundle-only m- lines are added in the &=
quot;2nd Offer" (BAS Offer in BUNDLE), when
 the Answerer has indicated support of BUNDLE, and selected the BUNDLE addr=
ess for the Offerer. In that case, the BUNDLE address can be addded to each=
 m- line (including the bundle-only m- lines) in the BUNDLE group.


 


Regards,


 


Christer


 




From: mmusic-bounces@ietf.org [mmusic-bou=
nces@ietf.org] on behalf of Adam Roach [adam@nostrum.com]

Sent: Tuesday, 15 October 2013 6:51 PM

To: mmusic@ietf.org

Subject: [MMUSIC] Bundle-only, Port 0, and other options








There's been a bit of a brouhaha (from small but disproportionately vo=
cal quarters) around the use of port zero in an offer for bundle-only lines=
. So I wanted to take a step back and see whether we could untangle this kn=
ot a bit.



The key property that we need here is that bundle-only lines must be formed=
 in a way that causes them to be rejected by non-bundling agents, but accep=
ted by bundling agents. Since bundle deals with ports, that seems like an e=
xtremely natural place to make the
 distinction. It has the spectacular advantage of being defined in a crysta=
l clear way in RFC 3264:



  "A port number of zero in the offer indicates that the

   stream is offered but MUST NOT be used.  This has no usef=
ul semantics

   in an initial offer, but is allowed for reasons of completenes=
s..."



  "A stream that is offered with a port of zero MUST be marked wi=
th port

   zero in the answer."



By overriding this second normative statement for bundle clients, we turn i=
t into an extremely well-defined extension point.



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



But this is exactly the approach that is causing people heartburn, so let's=
 look at other potential ways of achieving the goal. In a media section, th=
ere are only a small handful of fields that an implementation is required t=
o read and understand:



  m=3D<media> <port>/<number of ports> <proto>=
 <fmt> ...

  c=3D<nettype> <addrtype> <connection-address>



Taken one-by-one:




    

  1. Extending "media" would be somewhat problematic, since we use=
 this information extensively in our use cases. We would effectively have t=
o register bundle-only variations on "audio," "video," =
and "application" (at a minimum), which is horribly inelegant.

    

  2. Port is discussed above.
    

    

  3. Setting "number of ports" to zero would clearly have the=
 semantics that we're interested in here. The down-side of using this appro=
ach is that (in my experience) there are a lot of implementations that simp=
ly ignore the "number of ports" field, and a small
 handful that simply choke when it is present.
    

    

  4. Proto is an interesting one. Right now, we use RTP/SAVPF and DTLS/=
SCTP. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY and D=
TLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle clien=
ts as unrecognized.
    

    

  5. Fmt isn't really an option -- we need to use it to identify format=
s.
    

    

  6. Moving on to the c=3D line (which, if present, is mandatory to par=
se, understand, and honor), nettype is pretty much hardwired to "IN.&q=
uot; We could register an "IN-BUNDLEONLY" option, but there's a g=
ood chance that implementations don't really look at the value
 of this field, so they wouldn't reject the new value.
    

    

  7. Addrtype is necessary for indicating IP4 versus IP6. We could regi=
ster IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as elegan=
t as option #1.
    

    

  8. Overloading connection-address would be dicey, since it ruins the =
ability to send different streams to different places. While WebRTC might n=
ot care too much about these use cases, they *are* important in other conte=
xts.



In summary: of the above options, the strongest option still seems to be=
 "port," followed (perhaps) by "proto." We could probab=
ly force "media" or "addrtype" to work, but these would=
 be pretty messy. I think "number of ports" and "nettype&quo=
t; are at high risk
 of being ignored by non-bundle implementations (i.e., they won't trigger t=
he failure we want), and we need to maintain the existing meanings for &quo=
t;fmt" and "connection-address".




Even more tersely: if we don't want to port zero, I think the only other=
 realistic option is registering new "proto" values.




/a










--_000_7594FB04B1934943A5C02806D1A2204B1C4BEF17ESESSMB209erics_--

From martin.thomson@gmail.com  Tue Oct 15 09:47: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 5F33021E80E4 for ; Tue, 15 Oct 2013 09:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hOug0PemQla for ; Tue, 15 Oct 2013 09:47:44 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3F65A21F9AA8 for ; Tue, 15 Oct 2013 09:47:36 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id y10so6510661wgg.32 for ; Tue, 15 Oct 2013 09:47:34 -0700 (PDT)
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=4TbCEeNNeo+k1wdF01r/krqTZ2AHPgnw7LmRlS1vjoE=; b=jao+K5rWEo2FKay0m/QxdGIUq8Ga/jz/4O5n/FHOIqaNWgBG0zhGe6YFwRi3czzh8F U22hopAfZUHQeaxBexpdMFa9z8xE10H0JByclGDR26WaDiIWr8rppO0538pyTWGpRayG 3syMb3BTXnAtohdNG2zimXYXnNp/LZGa4EdM1dUpzCS/M1Joyf53975+16tAZX76yMTd tcOuNbZ85OmqqADnu5rFs5QNc4cNDUpNMt8T7TDrkV3BsOVo0a+32l5xkLwiruvru+EO zZfHlydAuYpOT7jNmPemeEY1P9SlPOS4jaQdAlN2kLil0WTcyQrBF9SeDUWA/zBvVwNQ kbwA==
MIME-Version: 1.0
X-Received: by 10.194.94.167 with SMTP id dd7mr3177432wjb.43.1381855654282; Tue, 15 Oct 2013 09:47:34 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 09:47:34 -0700 (PDT)
In-Reply-To: <525CB632.3030602@nostrum.com>
References: <525C7537.4080209@nostrum.com>    <525CB632.3030602@nostrum.com>
Date: Tue, 15 Oct 2013 09:47:34 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 16:47:44 -0000

On 14 October 2013 20:27, Adam Roach  wrote:
> I'll sketch out three of the more interesting ways you can skin this cat
> below.

The solution with no syntax is somewhat tempting, but - at least
academically - it seems nice to be able to negotiate the inclusion of
new m-sections in groups.

I think that your other two solutions are the same solution, and both
do what I had hoped to avoid, which is create another way to get to
a=group.  I concede that the general approach is sound hough.  I've a
third way of doing that, which commits the cardinal sin of ignoring
RFC5888 and replicates functionality.  But your two options kinda did
that anyway (and so did similar things I came up with).

m=whatever ...
a=mid:cnp2346987
a=rgroup:BUNDLE w3nv567890 <- same
m=something ...
a=mid:5709gw78v45
a=rgroup:BUNDLE w3nv567890 <- identifier

That fixes a problem that I've had with 5888 for a long time: the lack
of a stable identifier.  Eventually all things need identifiers.
Using indices or references to other members of groups is indirect and
brittle.

This doesn't allow for ordering of groups, which is a good thing, even
if it does make the selection of the bundle address harder, but that
might be achieved by the use of a new attribute.

From adam@nostrum.com  Tue Oct 15 10:05: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 4AAAB11E81F0 for ; Tue, 15 Oct 2013 10:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.819
X-Spam-Level: 
X-Spam-Status: No, score=-101.819 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIJSz2Kk1Fow for ; Tue, 15 Oct 2013 10:05:54 -0700 (PDT)
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 E6C9D11E81A1 for ; Tue, 15 Oct 2013 10:05:22 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FH5Hp5076408 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 12:05:17 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525D75C8.70607@nostrum.com>
Date: Tue, 15 Oct 2013 12:05:12 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <525C7537.4080209@nostrum.com>				<525CB632.3030602@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 17:05:58 -0000

On 10/15/13 11:47, Martin Thomson wrote:
> I've a
> third way of doing that, which commits the cardinal sin of ignoring
> RFC5888 and replicates functionality.  But your two options kinda did
> that anyway (and so did similar things I came up with).
>
> m=whatever ...
> a=mid:cnp2346987
> a=rgroup:BUNDLE w3nv567890 <- same
> m=something ...
> a=mid:5709gw78v45
> a=rgroup:BUNDLE w3nv567890 <- identifier
>
> That fixes a problem that I've had with 5888 for a long time: the lack
> of a stable identifier.  Eventually all things need identifiers.
> Using indices or references to other members of groups is indirect and
> brittle.

True, but this has its own point of brittleness: if a media section is 
part of two groups of the same type, you're back to the issue of not 
being able to clearly indicate which of the groups this rgroup attribute 
applies to.

If we can accept the constraint of each media group only belonging to 
(at most) one group of each type, then any single member of a group is 
sufficient to serve as a unique identifier.

/a

From martin.thomson@gmail.com  Tue Oct 15 10:53: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 048F91F0D5C for ; Tue, 15 Oct 2013 10:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih3LSr2otD8J for ; Tue, 15 Oct 2013 10:53:36 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 09B3811E81F3 for ; Tue, 15 Oct 2013 10:53:19 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id u57so9024269wes.32 for ; Tue, 15 Oct 2013 10:53:19 -0700 (PDT)
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=05kr1bn1tSFwHMRo3DMys26ZYwpjezbHnbFc572ztgs=; b=HH+Cgs07K7aRxa+bE6qt5RFgTLl7XaEi0nJFtyfuuj/EJzUXQxz1x9Rjsvw5QAv0tO VRx6Mnjb7oePX3A8O9upHJN2D2542mCdPuPqwqWTGTgrM6HIykYha3HYBhuUEDpT0WA/ B+bTGYabPcSr0M6aV/UbX9u0XzTctXFtoPFYYSpRbtEFaYBm6g4GiJpKoulVtpbbs7FT sSX4h/pJP1muEimHW4U+Kxfwn2Ig+CYGJ56TOofaRUjVO1zIRNOsb25ymEMr2K1s08Uw O4brMXOCpHeFJdsRMfp3kBKBXyeQRu8v86h+0U3+eGSGjb6sb0Wkg+vbzSvPsQKW6XCe 2Nxg==
MIME-Version: 1.0
X-Received: by 10.194.110.138 with SMTP id ia10mr36371080wjb.3.1381859599111;  Tue, 15 Oct 2013 10:53:19 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 10:53:19 -0700 (PDT)
In-Reply-To: <525D75C8.70607@nostrum.com>
References: <525C7537.4080209@nostrum.com>    <525CB632.3030602@nostrum.com>  <525D75C8.70607@nostrum.com>
Date: Tue, 15 Oct 2013 10:53:19 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 17:53:37 -0000

On 15 October 2013 10:05, Adam Roach  wrote:
> True, but this has its own point of brittleness: if a media section is part
> of two groups of the same type, you're back to the issue of not being able
> to clearly indicate which of the groups this rgroup attribute applies to.

This specifically avoids that brittleness - the identifier in the
a=rgroup: is an identifier for the *group*, so if a media section is
part of two groups of the same type, then it's going to get two
different group identifiers.

m=whatever
a=mid:blah
a=rgroup:LS groupA
a=rgroup:LS groupB

Rather than identify one member of a group in order to identify the
group by proxy, it identifies the group directly.  The cost is that
you can't use 5888 any more.

From pkyzivat@alum.mit.edu  Tue Oct 15 11:07: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 8FE1F11E81A1 for ; Tue, 15 Oct 2013 11:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.267
X-Spam-Level: 
X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=0.170,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi5GCP3l5NFg for ; Tue, 15 Oct 2013 11:07:22 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3762911E814C for ; Tue, 15 Oct 2013 11:07:20 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id dW631m0040bG4ec5AW7KPL; Tue, 15 Oct 2013 18:07:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id dW7K1m00k3ZTu2S3PW7K0t; Tue, 15 Oct 2013 18:07:19 +0000
Message-ID: <525D8456.1070600@alum.mit.edu>
Date: Tue, 15 Oct 2013 14:07:18 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <525D649E.5040608@nostrum.com>
In-Reply-To: <525D649E.5040608@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=1381860439; bh=QV2wcy21agnFH/S3IXeX7d58oHw5sdxK2bLTGe5SGLc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=U9V70+Gm52MNQhWdxBngdTZA+W43nReDRWICYjA4qkWwc4fInP2bvHmmrNmmZQ77/ tn6dQpRyzoamDusHRyk/dq6hzOGZkYJtJEk3JyPsDqh8TuhTDuPFOvbzprxVF5gnuo 9fCbpsccCavYJB4cD8xQlM83JRzGea/xyzvuQU7Q6XE6dMd+7SGBTXJJ3Oe+OAUbCs zUEdD0zpwp/np/ionkWrd9YsHw4ucXcz3aBfD7m519YE5Pwz6Uux1wzHKcGanhblGw dcrOSlJkH8yexgIZuxX6A4CsG424rW79DNhiaqPYpXk4LSTMc76ZhkWbHmeiBksy3d fACcXTwWeHb2w==
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 18:07:34 -0000

Adam,

I agree with most of your analysis. Comment inline.

On 10/15/13 11:51 AM, Adam Roach wrote:

> There's been a bit of a brouhaha (from small but disproportionately
> vocal quarters) around the use of port zero in an offer for bundle-only
> lines. So I wanted to take a step back and see whether we could untangle
> this knot a bit.
>
> The key property that we need here is that bundle-only lines must be
> formed in a way that causes them to be rejected by non-bundling agents,
> but accepted by bundling agents. Since bundle deals with ports, that
> seems like an extremely natural place to make the distinction. It has
> the spectacular advantage of being defined in a crystal clear way in RFC
> 3264:
>
>    "A port number of zero in the offer indicates that the
>     stream is offered but MUST NOT be used.  This has no useful semantics
>     in an initial offer, but is allowed for reasons of completeness..."
>
>    "A stream that is offered with a port of zero MUST be marked with port
>     zero in the answer."
>
> By overriding this second normative statement for bundle clients, we
> turn it into an extremely well-defined extension point.
>
> ----------------------------------------------------------------------
>
> But this is exactly the approach that is causing people heartburn, so
> let's look at other potential ways of achieving the goal. In a media
> section, there are only a small handful of fields that an implementation
> is required to read and understand:
>
>    m= /   ...
>    c=  
>
> Taken one-by-one:
>
>  1. Extending "media" would be somewhat problematic, since we use this
>     information extensively in our use cases. We would effectively have
>     to register bundle-only variations on "audio," "video," and
>     "application" (at a minimum), which is horribly inelegant.
>
>  2. Port is discussed above.
>
>  3. Setting "number of ports" to zero would clearly have the semantics
>     that we're interested in here. The down-side of using this approach
>     is that (in my experience) there are a lot of implementations that
>     simply ignore the "number of ports" field, and a small handful that
>     simply choke when it is present.
>
>  4. Proto is an interesting one. Right now, we use RTP/SAVPF and
>     DTLS/SCTP. We could conceivably additionally register
>     RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would
>     presumably be rejected by non-bundle clients as unrecognized.
>
>  5. Fmt isn't really an option -- we need to use it to identify formats.
>
>  6. Moving on to the c= line (which, if present, is mandatory to parse,
>     understand, and honor), nettype is pretty much hardwired to "IN." We
>     could register an "IN-BUNDLEONLY" option, but there's a good chance
>     that implementations don't really look at the value of this field,
>     so they wouldn't reject the new value.
>
>  7. Addrtype is necessary for indicating IP4 versus IP6. We could
>     register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is
>     approximately as elegant as option #1.
>
>  8. Overloading connection-address would be dicey, since it ruins the
>     ability to send different streams to different places. While WebRTC
>     might not care too much about these use cases, they *are* important
>     in other contexts.

I don't understand this last point. We are only talking about 
bundle-only lines that are either going to use the address and port of 
the bundle (defined elsewhere) or aren't going to be used at all.

IMO we *could* use an invalid address (pick one) as the indicator if the 
port number is a problem.

OTOH, I'm not convinced this is better. I can imagine problems arising 
from this too.

	Thanks,
	Paul

> In summary: of the above options, the strongest option still seems to be
> "port," followed (perhaps) by "proto." We could probably force "media"
> or "addrtype" to work, but these would be pretty messy. I think "number
> of ports" and "nettype" are at high risk of being ignored by non-bundle
> implementations (i.e., they won't trigger the failure we want), and we
> need to maintain the existing meanings for "fmt" and "connection-address".
>
> Even more tersely: if we don't want to port zero, I think the only other
> realistic option is registering new "proto" values.
>
> /a
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From christer.holmberg@ericsson.com  Tue Oct 15 11:07: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 0919211E81E6 for ; Tue, 15 Oct 2013 11:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level: 
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At3eMSc7Spow for ; Tue, 15 Oct 2013 11:07:43 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F31CE21F9D87 for ; Tue, 15 Oct 2013 11:07:35 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-a7-525d8466410f
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id BC.84.25272.6648D525; Tue, 15 Oct 2013 20:07:34 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 20:07:34 +0200
From: Christer Holmberg 
To: Adam Roach , "mmusic@ietf.org" 
Thread-Topic: POF/PAN Editorial: Allign with BUNDLE terminology
Thread-Index: Ac7J0WwMpXCumPu6SpGouNWNgyQuYA==
Date: Tue, 15 Oct 2013 18:07:33 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEF82@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com>
In-Reply-To: <525C7537.4080209@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BEF82ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW5aS2yQwblubYs9fxexW0xd/pjF gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mo4vHEpW0GHeMWNg+cZGxh7RboYOTkkBEwk /u1vYYOwxSQu3FsPZHNxCAkcZZR4uXoWC4SzhFHi/vxZzF2MHBxsAhYS3f+0QUwRATeJeafS QUxhASuJs/dkQcaICNhL3JrymhnC1pPY9uomI4jNIqAqcfrqKTCbV8BXYt6Em2A1QgJaEt+X rwazOQW0JX7PWsgCYjMCnfP91BomEJtZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B8rhK0k8WPD JRaI+nyJy/Mb2CF2CUqcnPmEZQKjyCwko2YhKZuFpAwiridxY+oUNghbW2LZwtfMELauxIx/ h6BqrCUmXGhjQlazgJFjFSNHcWpxUm66kcEmRmBEHdzy22IH4+W/NocYpTlYlMR5P751DhIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuKd648Q1e+ImLxZ3i+4Qb245Ybzx4YfZOyTjby3P ubNM3TCHI+D+n4qKvmblqvS8w9Lsp4xaGYXydB5mtE748/dDmZoJn26S90PDwrPJz0RvLe+r OmLLu2XjAU99d62nG9/NbW5JWpDnnWj/tcLe4Vjw31D1h7p/o/zFGdLezWos1sgtfbVWiaU4 I9FQi7moOBEAEaIMhHYCAAA=
Subject: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology
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 Oct 2013 18:07:59 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEF82ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



In BUNDLE we talk about "adding of media description" and "disabling of med=
ia description", rather than adding and removal of streams.



I think it would be useful, and more clear, to use similar terminology in t=
he POF/PAN spec.



It has been commented that the the word "remove" can confuse people, as med=
ia descriptions aren't removed (eventhough the associated streams may be).



Regards,



Christer





--_000_7594FB04B1934943A5C02806D1A2204B1C4BEF82ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <5D8B19C889FF1A41B4E7E32765AD0AA8@ericsson.com>
Content-Transfer-Encoding: quoted-printable












Hi,


 

In BUNDLE we talk abou=
t "adding of media description" and "disabling of media desc=
ription", rather than adding and removal of streams.



 

I think it would be us=
eful, and more clear, to use similar terminology in the POF/PAN spec.<=
/span>


 

It has been commented =
that the the word "remove" can confuse people, as media descripti=
ons aren't removed (eventhough the associated streams may be).


 

Regards,=



 

Christer=



 

 





--_000_7594FB04B1934943A5C02806D1A2204B1C4BEF82ESESSMB209erics_--

From martin.thomson@gmail.com  Tue Oct 15 11:19:51 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 33BE311E8145 for ; Tue, 15 Oct 2013 11:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqiZB8VmVmmv for ; Tue, 15 Oct 2013 11:19:34 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2C84E11E8121 for ; Tue, 15 Oct 2013 11:19:07 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id i19so1555384wiw.1 for ; Tue, 15 Oct 2013 11:19:06 -0700 (PDT)
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=Hcm8mzsw6vRejkdfCeS1ooW/qCp7TlRwjCw1+jy31Z0=; b=IXCHXbE5jU2/hV3PAi6Q3xBMMa5zJ8ZGpbWVppIg297NK8CVRd0hnDdI3G5FVQ3FTs xYDhsxxMK5jnwxFudyubrtTF6MSl2OSxsUEmZtV89Mb238yHxoxNyb9mB8evpjmXRqhA VonWyFUnYHVJilpMKgOou3haLGem4bdjah+cQYM0//ps4o/AhZl0xKBH4JeryQq0AFsD KNL+LMIRR6Ys4R1CP0StouhCYFxxCyL6YFl8inVmwDtAAdt/2GJYGYrLNjnHT1YZcjXl aeYfroHr3/HHVWybpLD26FcWSKAeuMFgst37vmdHyAQozYcmZnfsVXG6O4OWpHt+bcxt QmNQ==
MIME-Version: 1.0
X-Received: by 10.180.208.49 with SMTP id mb17mr20846665wic.64.1381861145988;  Tue, 15 Oct 2013 11:19:05 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 11:19:05 -0700 (PDT)
In-Reply-To: <525D649E.5040608@nostrum.com>
References: <525D649E.5040608@nostrum.com>
Date: Tue, 15 Oct 2013 11:19:05 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 18:20:13 -0000

On 15 October 2013 08:51, Adam Roach  wrote:
> Proto is an interesting one. Right now, we use RTP/SAVPF and DTLS/SCTP. We
> could conceivably additionally register RTP/SAVPF/BUNDLEONLY and
> DTLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle
> clients as unrecognized.

While this is your "backup", I'm not sure that it's safe, given what
we've seen regarding this field.  Folks are using the wrong string and
somehow, things still proceed.  That would suggest that unsupported
"proto" isn't being used as grounds for rejecting a media section.

From adam@nostrum.com  Tue Oct 15 11:20: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 E26B211E8144 for ; Tue, 15 Oct 2013 11:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.072
X-Spam-Level: 
X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YDPJhkd4Ab7 for ; Tue, 15 Oct 2013 11:20:55 -0700 (PDT)
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 CB9FA11E8121 for ; Tue, 15 Oct 2013 11:20:54 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FIKlGv085213 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 13:20:49 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525D8779.60901@nostrum.com>
Date: Tue, 15 Oct 2013 13:20:41 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <525C7537.4080209@nostrum.com>				<525CB632.3030602@nostrum.com>		<525D75C8.70607@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 18:20:56 -0000

On 10/15/13 12:53, Martin Thomson wrote:
> On 15 October 2013 10:05, Adam Roach  wrote:
>> True, but this has its own point of brittleness: if a media section is part
>> of two groups of the same type, you're back to the issue of not being able
>> to clearly indicate which of the groups this rgroup attribute applies to.
> This specifically avoids that brittleness - the identifier in the
> a=rgroup: is an identifier for the *group*, so if a media section is
> part of two groups of the same type, then it's going to get two
> different group identifiers.
>
> m=whatever
> a=mid:blah
> a=rgroup:LS groupA
> a=rgroup:LS groupB
>
> Rather than identify one member of a group in order to identify the
> group by proxy, it identifies the group directly.  The cost is that
> you can't use 5888 any more.

Oh, I see. You're throwing 5888 out the window. I specifically didn't 
want to do that. The approaches I described were meant to be a means of 
communicating incremental changes to existing 5888 groups in a way that 
otherwise maintained 5888 processing as-is.

I think this is somewhere that backwards compatibility is actually 
somewhat important.

/a

From christer.holmberg@ericsson.com  Tue Oct 15 11:26: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 47BC811E8121 for ; Tue, 15 Oct 2013 11:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Level: 
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[AWL=0.507,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xSpXhVvAV-A for ; Tue, 15 Oct 2013 11:26:50 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F411E8160 for ; Tue, 15 Oct 2013 11:26:44 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-3a-525d88db48e0
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D0.58.03802.BD88D525; Tue, 15 Oct 2013 20:26:35 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 20:26:35 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Bundle-only, Port 0, and other options
Thread-Index: AQHOyb6UYlrVbVrjzE+6A+wFMyNYppn17cAAgAAimfCAAARSbA==
Date: Tue, 15 Oct 2013 18:26:34 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEFD6@ESESSMB209.ericsson.se>
References: <525D649E.5040608@nostrum.com>,<525D8456.1070600@alum.mit.edu>
In-Reply-To: <525D8456.1070600@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BEFD6ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre7tjtggg8ff5SymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjw7WAglnqFb8/PmJpYJym2MXIySEhYCKx +NYuNghbTOLCvfVANheHkMBhRome3/MYQRJCAksYJY5frupi5OBgE7CQ6P6nDRIWEfCVePb4 NlivsICNxNV7U5kg4rYS/z/0MoOUiwg4SSz7VAoSZhFQldiwZDc7iM0L1Lq1aysbxHQvic5T q8BsTgEdia3nroPVMAKd8/3UGrCRzALiEreezGeCOFNAYsme88wQtqjEy8f/WCFsJYkfGy6x QNTnS3Qen8AKsUtQ4uTMJywTGEVmIRk1C0nZLCRlEHE9iRtTp7BB2NoSyxa+ZoawdSVm/DsE VWMtcfHUOyZkNQsYOVYxsucmZuaklxttYgRG08Etv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjJYHC5fcqnp9sdJGW/RR2vofd4OvMLC4MZw8Y38lVa72 guPOOZu5/mu8jcru5FSviH7Vqvwz5r/B6Q0ODzXb7Tb9ZLU2FmGw/uZ1QEdoguDxjz4ON33t 53CIXIkUb64LTQl1cuySDq8I33h+ToNsUhlDftHxhQsOKRxTUr3ZcqX6+Am7RDVbJZbijERD Leai4kQAbGW5gnQCAAA=
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 18:26:55 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEFD6ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



>>  8. Overloading connection-address would be dicey, since it ruins the
>>     ability to send different streams to different places. While WebRTC
>>     might not care too much about these use cases, they *are* important
>>     in other contexts.
>
> I don't understand this last point. We are only talking about
> bundle-only lines that are either going to use the address and port of
> the bundle (defined elsewhere) or aren't going to be used at all.
>
> IMO we *could* use an invalid address (pick one) as the indicator if the
> port number is a problem.



0.0.0.0



Regards,



Christer









> In summary: of the above options, the strongest option still seems to be
> "port," followed (perhaps) by "proto." We could probably force "media"
> or "addrtype" to work, but these would be pretty messy. I think "number
> of ports" and "nettype" are at high risk of being ignored by non-bundle
> implementations (i.e., they won't trigger the failure we want), and we
> need to maintain the existing meanings for "fmt" and "connection-address"=
.
>
> Even more tersely: if we don't want to port zero, I think the only other
> realistic option is registering new "proto" values.
>
> /a
>
>
>
> _______________________________________________
> 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

--_000_7594FB04B1934943A5C02806D1A2204B1C4BEFD6ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <5A0A38297DED17499A00264A0B2E0DE1@ericsson.com>
Content-Transfer-Encoding: quoted-printable












Hi,


 


>>  8. Over=
loading connection-address would be dicey, since it ruins the

>>     ability to send different streams to diffe=
rent places. While WebRTC

>>     might not care too much about these use ca=
ses, they *are* important

>>     in other contexts.

>

> I don't understand this last point. We are only talking about 

> bundle-only lines that are either going to use the address and port of=
 

> the bundle (defined elsewhere) or aren't going to be used at all.

>

> IMO we *could* use an invalid address (pick one) as the indicator if t=
he 

> port number is a problem.


 

0.0.0.0<=
/p>

 


Regards,


 


Christer


 




 


 


 


> In summary: of the above options, the strongest option still seems =
to be

> "port," followed (perhaps) by "proto." We could pr=
obably force "media"

> or "addrtype" to work, but these would be pretty messy. I th=
ink "number

> of ports" and "nettype" are at high risk of being ignor=
ed by non-bundle

> implementations (i.e., they won't trigger the failure we want), and we=


> need to maintain the existing meanings for "fmt" and "c=
onnection-address".

>

> Even more tersely: if we don't want to port zero, I think the only oth=
er

> realistic option is registering new "proto" values.

>

> /a

>

>

>

> _______________________________________________

> 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








--_000_7594FB04B1934943A5C02806D1A2204B1C4BEFD6ESESSMB209erics_--

From christer.holmberg@ericsson.com  Tue Oct 15 12:02: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 31A5E11E8203 for ; Tue, 15 Oct 2013 12:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.759
X-Spam-Level: 
X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.489,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIhHuGqwGK0B for ; Tue, 15 Oct 2013 12:02:34 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7611E81F9 for ; Tue, 15 Oct 2013 12:02:32 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-6f-525d914643a1
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 14.6B.03802.6419D525; Tue, 15 Oct 2013 21:02:30 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 21:02:30 +0200
From: Christer Holmberg 
To: Adam Roach , Martin Thomson 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft
Thread-Index: AQHOyS/VDi7jGJKfu0+LtCEoj80NX5n0xEsAgAABJ4CAAAG3gIAAMfgAgADxe5aAAAORvv//4O8AgABQPB+AAAB5ZQ==
Date: Tue, 15 Oct 2013 19:02:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BF001@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com>   , <525CB632.3030602@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BEEE8@ESESSMB209.ericsson.se>, <525D69B2.7080905@nostrum.com>
In-Reply-To: <525D69B2.7080905@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BF001ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvra7bxNggg6VvxS32/F3EbnHtzD9G i6nLH7M4MHvsnHWX3WPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgyjix1Lzgr0zF4rcz2BoY d0l0MXJySAiYSCx6coEVwhaTuHBvPVsXIxeHkMBhRokrl2exQjhLGCW+XOpj6WLk4GATsJDo /qcN0iAi4CMx9fZNZpAws4C6xNXFQSBhYaCKOb9mskKUWEpMejOHHaRERCBL4unWWpAwi4Cq xJkJnWAlvAK+EtOOnoXa9J5J4n7XTkaQBKeAtsTiH5PYQWxGoNu+n1rDBGIzC4hL3Hoynwni ZgGJJXvOM0PYohIvH/+D+kVJ4seGSywQ9fkSmy7dYYNYJihxcuYTlgmMorOQjJqFpGwWkjKI uJ7EjalT2CBsbYllC18zQ9i6EjP+HQKqAfneWuLffXFkJQsYOVYxsucmZuaklxttYgRG3sEt v1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMs7vfxkWdYt /1jMlsvWGFAu9zdZduv8CSVfV1564Pn2UpVUBnfkOsc1yonzmiLN1p3bvDRUMmLFC68JV+on LbW2jQqR/X7kVs/zgzcZmK9FttR+sF/EPuVw/E/lyYmsbvGx15cEf7R+2lr/e6OY+qubbhHS 3O/Ynnk539d/eb1Dhe3eL5dXvUosxRmJhlrMRcWJAL0wTsiKAgAA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 19:02:43 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BF001ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



>> - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND
>> also requests the "d" address to become the new BUNDLE address.
>
> I think you've simply identified one more class of thing we need to
> prohibit in a partial offer. Either that or:
>
>> The easiest way to prevent this would be to say that an Offer/POF,
>> MUST include all m- lines which may be affected (explictily or
>> implicitly) by the Offer/POF.
>
> Which I think would work, but (for the cases we care about for WebRTC,
> at least) would be approximately as likely to glare as a full offer.



It would be nice to get some input on what people want to do with POF/PANs.



Yes, they want to add streams etc, but exactly what information do they nee=
d to be able to modify when doing that.



Regards,



Christer





--_000_7594FB04B1934943A5C02806D1A2204B1C4BF001ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <377DABA819D685468EC4769AC3C4443E@ericsson.com>
Content-Transfer-Encoding: quoted-printable












Hi,


 

>> - Then, Alice=
 sends a POF, which adds "d" to the BUNDLE group, AND


>> also requests the "d" address to become the new BUNDLE a=
ddress.

>

> I think you've simply identified one more class of thing we need to 
> prohibit in a partial offer. Either that or:

>

>> The easiest way to prevent this would be to say that an Offer/POF,=
 

>> MUST include all m- lines which may be affected (explictily or 
>> implicitly) by the Offer/POF.

>

> Which I think would work, but (for the cases we care about for WebRTC,=
 

> at least) would be approximately as likely to glare as a full offer.


 

It would be nice to ge=
t some input on what people want to do with POF/PANs.


 

Yes, they want to add =
streams etc, but exactly what information do they need to be able to m=
odify when doing that.


 

Regards,=



 

Christer=



 

 






--_000_7594FB04B1934943A5C02806D1A2204B1C4BF001ESESSMB209erics_--

From adam@nostrum.com  Tue Oct 15 12:07: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 2902211E8151 for ; Tue, 15 Oct 2013 12:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.765
X-Spam-Level: 
X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSzj1td-0o+7 for ; Tue, 15 Oct 2013 12:07:03 -0700 (PDT)
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 3BC9621F9FA5 for ; Tue, 15 Oct 2013 12:06:59 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FJ6vFT090327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 14:06:57 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525D924C.7090802@nostrum.com>
Date: Tue, 15 Oct 2013 14:06:52 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Paul Kyzivat , mmusic@ietf.org
References: <525D649E.5040608@nostrum.com> <525D8456.1070600@alum.mit.edu>
In-Reply-To: <525D8456.1070600@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 19:07:05 -0000

On 10/15/13 13:07, Paul Kyzivat wrote:
> I don't understand this last point. We are only talking about 
> bundle-only lines that are either going to use the address and port of 
> the bundle (defined elsewhere) or aren't going to be used at all.

What I'm thinking about is something that defines a setup like this:

...
a=group:BUNDLE a1 a2
a=group:BUNDLE v1 v2
...
m=audio ...
c=IN IP4 1.1.1.1
a=mid:a1
...
m=audio ...
c=IN IP4 1.1.1.1
a=mid:a2
...
m=video ...
c=IN IP4 2.2.2.2
a=mid:v1
...
m=video ...
c=IN IP4 2.2.2.2
a=mid:v2
...

Or, in plain English: we want to two audio streams to be bundled 
together and sent to 1.1.1.1; and the two video streams to be bundled 
together and sent to 2.2.2.2. And now I see what you're saying: if we 
just used 0.0.0.0 in the "bundle only" lines, then you'd get the 
transport address from the non-bundle-only sections in the bundle, just 
like we were proposing to do for the ports.

So, yes, I agree that this would be a potentially viable way to put 
together a line that "won't work" for legacy clients; however, given 
that implementations may not check for "0.0.0.0" as a special value, 
their behavior is likely to be far more difficult to predict than using 
port 0 (which has well-defined, crystal clear semantics in legacy use).

/a

From adam@nostrum.com  Tue Oct 15 12:08: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 4C5D611E8151 for ; Tue, 15 Oct 2013 12:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.331
X-Spam-Level: 
X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C89hR3Call6Y for ; Tue, 15 Oct 2013 12:08:29 -0700 (PDT)
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 A6E6621F9FA5 for ; Tue, 15 Oct 2013 12:08:29 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FJ8IWf090390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 14:08:19 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525D929D.5060305@nostrum.com>
Date: Tue, 15 Oct 2013 14:08:13 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Martin Thomson 
References: <525C7537.4080209@nostrum.com>			, <525CB632.3030602@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BEEE8@ESESSMB209.ericsson.se>, <525D69B2.7080905@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BF001@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BF001@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------070205000205050306090807"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 19:08:30 -0000

This is a multi-part message in MIME format.
--------------070205000205050306090807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/15/13 14:02, Christer Holmberg wrote:
>
> Hi,
>
> >> - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND
> >> also requests the "d" address to become the new BUNDLE address.
> >
> > I think you've simply identified one more class of thing we need to
> > prohibit in a partial offer. Either that or:
> >
> >> The easiest way to prevent this would be to say that an Offer/POF,
> >> MUST include all m- lines which may be affected (explictily or
> >> implicitly) by the Offer/POF.
> >
> > Which I think would work, but (for the cases we care about for WebRTC,
> > at least) would be approximately as likely to glare as a full offer.
>
> It would be nice to get some input on what people want to do with 
> POF/PANs.
>

Paging Justin Uberti...

/a

--------------070205000205050306090807
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/15/13 14:02, Christer Holmberg
      wrote:

    

    

      
      
      
      
      

        
Hi,

        
 

        
>> -
              Then, Alice sends a POF, which adds "d" to the BUNDLE
              group, AND
              

              >> also requests the "d" address to become the new
              BUNDLE address.

              >

              > I think you've simply identified one more class of
              thing we need to 

              > prohibit in a partial offer. Either that or:

              >

              >> The easiest way to prevent this would be to say
              that an Offer/POF, 

              >> MUST include all m- lines which may be affected
              (explictily or 

              >> implicitly) by the Offer/POF.

              >

              > Which I think would work, but (for the cases we care
              about for WebRTC, 

              > at least) would be approximately as likely to glare
              as a full offer.

        
 

        
It would be
              nice to get some input on what people want to do with
              POF/PANs.

      

    

    

    Paging Justin Uberti...

    

    /a

  


--------------070205000205050306090807--

From christer.holmberg@ericsson.com  Tue Oct 15 12:22: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 C024D11E8166 for ; Tue, 15 Oct 2013 12:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.177
X-Spam-Level: 
X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86R4IMXNsqx6 for ; Tue, 15 Oct 2013 12:22:25 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62811E8163 for ; Tue, 15 Oct 2013 12:22:24 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-ee-525d95ef14e2
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1E.DC.03802.FE59D525; Tue, 15 Oct 2013 21:22:23 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 21:22:23 +0200
From: Christer Holmberg 
To: Adam Roach , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Bundle-only, Port 0, and other options
Thread-Index: AQHOyb6UYlrVbVrjzE+6A+wFMyNYppn17cAAgAAQpQCAACNuJIAAAm+y
Date: Tue, 15 Oct 2013 19:22:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BF026@ESESSMB209.ericsson.se>
References: <525D649E.5040608@nostrum.com> <525D8456.1070600@alum.mit.edu>,<525D924C.7090802@nostrum.com>
In-Reply-To: <525D924C.7090802@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BF026ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre77qbFBBm8vWljs+buI3WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPGbtfMISwBzFZZOSmpNZllqkb5fAlbF//xPGgsUqFVe+dDM2 MF6X7WLk5JAQMJFYu6mHBcIWk7hwbz1bFyMXh5DAYUaJWbM6GCGcJYwSr6ZNYOpi5OBgE7CQ 6P6nDdIgIpAn8ePDdrBmYQEbiav3pjJBxG0l/n/oZQYpFxFwk9i01hHEZBFQlejeqwlSwSvg K3H55lw2kLCQQLbEjRVgAzkFtCUWTHkCNpAR6Jrvp9aADWQWEJe49WQ+E8SVAhJL9pxnhrBF JV4+/scKMkZCQEli2tY0iPJ8idV/vrBBbBKUODnzCcsERpFZSCbNQlI2C0kZRFxP4sbUKWwQ trbEsoWvmSFsXYkZ/w5B1VhLXGu/yoysZgEjxypG9tzEzJz0cqNNjMD4Orjlt+oOxjvnRA4x SnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUej43iu/WzgFnBQz6nieH/mg fO3wqpA1iSdDGf9v2NR4vJFzY0Vpas2z/VErr7ks2bNoXm3W53s/LEP2K6c42Z65cmETs+1f Lp6Z5XxH2vx5l01pFP/54aX0d+/7n5d3CBvk/5A8673f8GVq7HHtyypuIcq+V/c9/h08s/XY 8njJZ/9TJnf8Z1NiKc5INNRiLipOBAC0p7jjfQIAAA==
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 19:22:31 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BF026ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Hi,



>> I don't understand this last point. We are only talking about
>> bundle-only lines that are either going to use the address and port of
>> the bundle (defined elsewhere) or aren't going to be used at all.
>
> What I'm thinking about is something that defines a setup like this:
>
> ...
> a=3Dgroup:BUNDLE a1 a2
> a=3Dgroup:BUNDLE v1 v2
> ...
> m=3Daudio ...
> c=3DIN IP4 1.1.1.1
> a=3Dmid:a1
> ...
> m=3Daudio ...
> c=3DIN IP4 1.1.1.1
> a=3Dmid:a2
> ...
> m=3Dvideo ...
> c=3DIN IP4 2.2.2.2
> a=3Dmid:v1
> ...
> m=3Dvideo ...
> c=3DIN IP4 2.2.2.2
> a=3Dmid:v2
> ...
>
> Or, in plain English: we want to two audio streams to be bundled
> together and sent to 1.1.1.1; and the two video streams to be bundled
> together and sent to 2.2.2.2. And now I see what you're saying: if we
> just used 0.0.0.0 in the "bundle only" lines, then you'd get the
> transport address from the non-bundle-only sections in the bundle, just
> like we were proposing to do for the ports.

>
> So, yes, I agree that this would be a potentially viable way to put
> together a line that "won't work" for legacy clients; however, given
> that implementations may not check for "0.0.0.0" as a special value,
> their behavior is likely to be far more difficult to predict than using
> port 0 (which has well-defined, crystal clear semantics in legacy use).



It would have the same semantics also in bundle use - EXCEPT when used in t=
hat one initial Offer :)



Regards,



Christer





--_000_7594FB04B1934943A5C02806D1A2204B1C4BF026ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <999A66BB36BE0440A067C4AE7E9F610A@ericsson.com>
Content-Transfer-Encoding: quoted-printable











 


Hi,


 


>> I don't under=
stand this last point. We are only talking about


>> bundle-only lines that are either going to use the address and por=
t of 

>> the bundle (defined elsewhere) or aren't going to be used at all.<=
br>
>

> What I'm thinking about is something that defines a setup like this:
>

> ...

> a=3Dgroup:BUNDLE a1 a2

> a=3Dgroup:BUNDLE v1 v2

> ...

> m=3Daudio ...

> c=3DIN IP4 1.1.1.1

> a=3Dmid:a1

> ...

> m=3Daudio ...

> c=3DIN IP4 1.1.1.1

> a=3Dmid:a2

> ...

> m=3Dvideo ...

> c=3DIN IP4 2.2.2.2

> a=3Dmid:v1

> ...

> m=3Dvideo ...

> c=3DIN IP4 2.2.2.2

> a=3Dmid:v2

> ...

>

> Or, in plain English: we want to two audio streams to be bundled 

> together and sent to 1.1.1.1; and the two video streams to be bundled =


> together and sent to 2.2.2.2. And now I see what you're saying: if we =


> just used 0.0.0.0 in the "bundle only" lines, then you'd get=
 the 

> transport address from the non-bundle-only sections in the bundle, jus=
t 

> like we were proposing to do for the ports.



>

> So, yes, I agree that this would be a potentially viable way to put 
> together a line that "won't work" for legacy clients; howeve=
r, given 

> that implementations may not check for "0.0.0.0" as a specia=
l value, 

> their behavior is likely to be far more difficult to predict than usin=
g 

> port 0 (which has well-defined, crystal clear semantics in legacy use)=
.


 


It would have the same semantics also in bundle use - EXCEPT when u=
sed in that one initial Offer :)


 


Regards,


 


Christer


 


 






--_000_7594FB04B1934943A5C02806D1A2204B1C4BF026ESESSMB209erics_--

From suhasietf@gmail.com  Tue Oct 15 13:07: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 78AB811E81E6 for ; Tue, 15 Oct 2013 13:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AMGP-NRySeH for ; Tue, 15 Oct 2013 13:07:19 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 809B611E8201 for ; Tue, 15 Oct 2013 13:07:05 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id x55so8973164wes.36 for ; Tue, 15 Oct 2013 13:07:03 -0700 (PDT)
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=H7KekHunAHWcqZkjSusHDXYserHVMhGBAzLVrBiCEdI=; b=b9STkxXEWmxqxzGS+uURx7RKCeRVT/RxB9cN+QDVyNkZxuIDLC/3lCcqnu2neIF2fS fWb1aZwr6z8fiCUtxNLlR/vdOxctgefVZUxaG5X0+8+r1mDjuTOTRqKln9BaRX3QlDli 03LG3GbmrxtvP2lBJIZJMtL7GCglAcJkEEAmDn3v8szG+fSIzZX9iLZx2JJzNIGT2RqL 7vTwWZdR8vJ4+C8zf6BME6TqU963FFIcTMbWiPfW+wk1CAWAOdgZJa+NP/r/Ibr1dWvU idw0YOiNbPIRIoL5oE5UIdnEKMjVUchyHDzO4mgjRGLIUITwiGBTN4jJULr9Y4sLdy67 Jnuw==
MIME-Version: 1.0
X-Received: by 10.194.173.163 with SMTP id bl3mr36954384wjc.10.1381867623007;  Tue, 15 Oct 2013 13:07:03 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Tue, 15 Oct 2013 13:07:02 -0700 (PDT)
In-Reply-To: <525D649E.5040608@nostrum.com>
References: <525D649E.5040608@nostrum.com>
Date: Tue, 15 Oct 2013 13:07:02 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=089e013c6220cbd15f04e8cd205d
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 20:07:22 -0000

--089e013c6220cbd15f04e8cd205d
Content-Type: text/plain; charset=ISO-8859-1

RFC3264 also says the following about 0.0.0.0

"RFC 2543 [10] specified that placing a user on hold was accomplished

   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer."


>From the above, 0.0.0.0  can be used along with bundle-only along with
the combination of things being discussed here.. Since with this, the
end-points that are BUNDLE capable will be able to parse this and
respond with answerer's BUNDLE address.  Ofcourse, this will be
followed by updated Offer with Offerer's BUNDLE Address to complete
the BAS procedures.


./Suhas



On Tue, Oct 15, 2013 at 8:51 AM, Adam Roach  wrote:

>  There's been a bit of a brouhaha (from small but disproportionately vocal
> quarters) around the use of port zero in an offer for bundle-only lines. So
> I wanted to take a step back and see whether we could untangle this knot a
> bit.
>
> The key property that we need here is that bundle-only lines must be
> formed in a way that causes them to be rejected by non-bundling agents, but
> accepted by bundling agents. Since bundle deals with ports, that seems like
> an extremely natural place to make the distinction. It has the spectacular
> advantage of being defined in a crystal clear way in RFC 3264:
>
>   "A port number of zero in the offer indicates that the
>    stream is offered but MUST NOT be used.  This has no useful semantics
>    in an initial offer, but is allowed for reasons of completeness..."
>
>   "A stream that is offered with a port of zero MUST be marked with port
>    zero in the answer."
>
> By overriding this second normative statement for bundle clients, we turn
> it into an extremely well-defined extension point.
>
> ----------------------------------------------------------------------
>
> But this is exactly the approach that is causing people heartburn, so
> let's look at other potential ways of achieving the goal. In a media
> section, there are only a small handful of fields that an implementation is
> required to read and understand:
>
>   m= /   ...
>   c=  
>
> Taken one-by-one:
>
>
>    1. Extending "media" would be somewhat problematic, since we use this
>    information extensively in our use cases. We would effectively have to
>    register bundle-only variations on "audio," "video," and "application" (at
>    a minimum), which is horribly inelegant.
>
>     2. Port is discussed above.
>
>     3. Setting "number of ports" to zero would clearly have the semantics
>    that we're interested in here. The down-side of using this approach is that
>    (in my experience) there are a lot of implementations that simply ignore
>    the "number of ports" field, and a small handful that simply choke when it
>    is present.
>
>     4. Proto is an interesting one. Right now, we use RTP/SAVPF and
>    DTLS/SCTP. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY
>    and DTLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle
>    clients as unrecognized.
>
>     5. Fmt isn't really an option -- we need to use it to identify
>    formats.
>
>     6. Moving on to the c= line (which, if present, is mandatory to
>    parse, understand, and honor), nettype is pretty much hardwired to "IN." We
>    could register an "IN-BUNDLEONLY" option, but there's a good chance that
>    implementations don't really look at the value of this field, so they
>    wouldn't reject the new value.
>
>     7. Addrtype is necessary for indicating IP4 versus IP6. We could
>    register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as
>    elegant as option #1.
>
>     8. Overloading connection-address would be dicey, since it ruins the
>    ability to send different streams to different places. While WebRTC might
>    not care too much about these use cases, they *are* important in other
>    contexts.
>
> In summary: of the above options, the strongest option still seems to be
> "port," followed (perhaps) by "proto." We could probably force "media" or
> "addrtype" to work, but these would be pretty messy. I think "number of
> ports" and "nettype" are at high risk of being ignored by non-bundle
> implementations (i.e., they won't trigger the failure we want), and we need
> to maintain the existing meanings for "fmt" and "connection-address".
>
> Even more tersely: if we don't want to port zero, I think the only other
> realistic option is registering new "proto" values.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--089e013c6220cbd15f04e8cd205d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


RFC3264 also says the following about 0.0.0.0

"RFC 2543=
 [10] specified that placing a user on hold was accomplished

   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and break=
s
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer."

From the above, 0.0.0.0 =A0can be used along with bundle-only along =
with the combination of things being discussed here.. Since with this, the =
end-points that are BUNDLE capable will be able to parse this and respond w=
ith answerer's BUNDLE address. =A0Ofcourse, this will be followed by up=
dated Offer with Offerer's BUNDLE Address to complete the BAS procedure=
s.



./Suhas




On Tue,=
 Oct 15, 2013 at 8:51 AM, Adam Roach <adam@nostrum.com> wrote=
:


 =20

   =20
 =20
  

    There's been a bit of a brouhaha (from small but disproportionately
    vocal quarters) around the use of port zero in an offer for
    bundle-only lines. So I wanted to take a step back and see whether
    we could untangle this knot a bit.

    

    The key property that we need here is that bundle-only lines must be
    formed in a way that causes them to be rejected by non-bundling
    agents, but accepted by bundling agents. Since bundle deals with
    ports, that seems like an extremely natural place to make the
    distinction. It has the spectacular advantage of being defined in a
    crystal clear way in RFC 3264:

    

    =A0 "A port number of zero in the offer indicates that the

    =A0=A0 stream is offered but MUST NOT be used.=A0 This has no useful
    semantics

    =A0=A0 in an initial offer, but is allowed for reasons of
    completeness..."

    

    =A0 "A stream that is offered with a port of zero MUST be marked w=
ith
    port

    =A0=A0 zero in the answer."

    

    By overriding this second normative statement for bundle clients, we
    turn it into an extremely well-defined extension point.

    

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

    

    But this is exactly the approach that is causing people heartburn,
    so let's look at other potential ways of achieving the goal. In a
    media section, there are only a small handful of fields that an
    implementation is required to read and understand:

    

    =A0 m=3D<media> <port>/<number of ports> <proto>=
;
    <fmt> ...

    =A0 c=3D<nettype> <addrtype> <connection-address>

    

    Taken one-by-one:

    

    
    
      
  1. Extending "media" would be somewhat problematic, since =
we use
        this information extensively in our use cases. We would
        effectively have to register bundle-only variations on "audio,=
"
        "video," and "application" (at a minimum), whic=
h is horribly
        inelegant.
    
        
    
      
    2. 
      
  2. Port is discussed above.
    
        
    
      
    3. 
      
  3. Setting "number of ports" to zero would clearly have th=
e
        semantics that we're interested in here. The down-side of using
        this approach is that (in my experience) there are a lot of
        implementations that simply ignore the "number of ports" =
field,
        and a small handful that simply choke when it is present.
    
        
    
      
    4. 
      
  4. Proto is an interesting one. Right now, we use RTP/SAVPF and
        DTLS/SCTP. We could conceivably additionally register
        RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would
        presumably be rejected by non-bundle clients as unrecognized.
    
        
    
      
    5. 
      
  5. Fmt isn't really an option -- we need to use it to identify
        formats.
    
        
    
      
    6. 
      
  6. Moving on to the c=3D line (which, if present, is mandatory to
        parse, understand, and honor), nettype is pretty much hardwired
        to "IN." We could register an "IN-BUNDLEONLY" o=
ption, but
        there's a good chance that implementations don't really loo=
k at
        the value of this field, so they wouldn't reject the new value.=

    
        
    
      
    7. 
      
  7. Addrtype is necessary for indicating IP4 versus IP6. We could
        register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is
        approximately as elegant as option #1.
    
        
    
      
    8. 
      
  8. Overloading connection-address would be dicey, since it ruins
        the ability to send different streams to different places. While
        WebRTC might not care too much about these use cases, they *are*
        important in other contexts.
    9. 
    

    
In summary: of the above options, the strongest option still
      seems to be "port," followed (perhaps) by "proto."=
; We could
      probably force "media" or "addrtype" to work, but=
 these would be
      pretty messy. I think "number of ports" and "nettype&q=
uot; are at high
      risk of being ignored by non-bundle implementations (i.e., they
      won't trigger the failure we want), and we need to maintain the
      existing meanings for "fmt" and "connection-address&qu=
ot;.

    

    
Even more tersely: if we don't want to port zero, I think the
      only other realistic option is registering new "proto" valu=
es.

    

    
/a

    

  



_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--089e013c6220cbd15f04e8cd205d--

From martin.thomson@gmail.com  Tue Oct 15 13:25: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 9EBAC11E81D7 for ; Tue, 15 Oct 2013 13:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUxGfF9noyNx for ; Tue, 15 Oct 2013 13:25:16 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C537311E81E6 for ; Tue, 15 Oct 2013 13:25:15 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u56so8985663wes.5 for ; Tue, 15 Oct 2013 13:25:05 -0700 (PDT)
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=wjE725ABAO+d62wp/fFyGBUeGjRxridQKJ6QfFtfCAk=; b=biFsud5nNg28HoTaJ52tUwMitCfcUMHPD/RDq2wrEONro7QZjwOafH8Nj24Y7CWDhR fP5iIt1lUBJ37rBwLyVbV5URYVo1lfseAFjO2oPTiZ4bmmAyJeD1PUHfAJbikMlORRRp 9bhqQ8g0bmjTcEoNdbb0w5hsXOdaAE6irDLWOu1G3vT6kFC2amdAbYYZxTfOW5QHEH4p c82ZiGsU9SMZlULj7XaEMwL0bUmLrxCjim7Fn3ANJVOH/tFl2Cr9mBlhwmN4NJPfXjhX aVlYfdXOcRn2CSdQ1tg7VnGVJgDIeo2xQOdgAnaBH6FpYJHb1dYfj+vIeSr3uf0vdoBC fa+A==
MIME-Version: 1.0
X-Received: by 10.180.211.206 with SMTP id ne14mr21326458wic.30.1381868705542;  Tue, 15 Oct 2013 13:25:05 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 13:25:05 -0700 (PDT)
In-Reply-To: <525D8779.60901@nostrum.com>
References: <525C7537.4080209@nostrum.com>    <525CB632.3030602@nostrum.com>  <525D75C8.70607@nostrum.com>  <525D8779.60901@nostrum.com>
Date: Tue, 15 Oct 2013 13:25:05 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 20:25:17 -0000

On 15 October 2013 11:20, Adam Roach  wrote:
> Oh, I see. You're throwing 5888 out the window. I specifically didn't want
> to do that. The approaches I described were meant to be a means of
> communicating incremental changes to existing 5888 groups in a way that
> otherwise maintained 5888 processing as-is.
>
> I think this is somewhere that backwards compatibility is actually somewhat
> important.

Yep, intentionally.  I think that the effect of what you have proposed
is the same, or close enough that it doesn't matter I'm just being
more honest about it.

From suhasietf@gmail.com  Tue Oct 15 13:28: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 CA01B11E81E6 for ; Tue, 15 Oct 2013 13:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej6iUGulm6Ut for ; Tue, 15 Oct 2013 13:28:11 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C71D911E81F3 for ; Tue, 15 Oct 2013 13:28:08 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id l18so5064473wgh.6 for ; Tue, 15 Oct 2013 13:28:07 -0700 (PDT)
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=f2d3XCb9tCws2b//ioNkagH0WPCq6FFDr2sltC0h++k=; b=LC3GjhI/+76+0K8B04Nrrkj9qvXtKZnCHhDVcRvmODvblXIKzFPvuGxcNjvhJgOiqP 99iYj4jcp093v0yrCy1/ZoI+D7K9MPPLlKYRDCPBWCNJKW8BBmuiyup5dftMmvufUBaf YRuZyRH0Z4ZGAbiRVI796xH4Pa/mT4u65sK0JBZF0lqJJ+XuK+ZB3G0VUCbLE4OzSt6K 5n8baO9VS3mjWfrKgZB6IbbAyarHwVR1nKr3wv7Z4mOBHaUWKQikyY9OCMRnUWvArsYm 1imbtjgIGZ0snhIjvrtjT1KuMCHZNUAPtaPPGZm3PzgVy4kgvGX8tA5TyVXEzTlfL5qb ozkA==
MIME-Version: 1.0
X-Received: by 10.180.182.82 with SMTP id ec18mr21049575wic.13.1381868887716;  Tue, 15 Oct 2013 13:28:07 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Tue, 15 Oct 2013 13:28:07 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BEF82@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BEF82@ESESSMB209.ericsson.se>
Date: Tue, 15 Oct 2013 13:28:07 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b6250b82db95904e8cd6c91
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology
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 Oct 2013 20:28:11 -0000

--047d7b6250b82db95904e8cd6c91
Content-Type: text/plain; charset=ISO-8859-1

I think this needs to be discussed a bit more

As i see, we have following scenarios

1. Adding a new stream
     ==> This corresponds to adding a new source and hence new m= line

2. Deleting a already existing stream
    ==> This is undoing #1 i.e remove the source altogther from input.
           This is typically implemented by setting Port to Zero for the
corresponding to the m=line

3. Disabling an already Existing stream
    ==> This is where things get little murky and it depends on the
use-case I believe.
            One use-case is if the user wanted to put the stream on hold.
This can be done via direction attribute (preferred) vs setting port to
zero ( not preferred)

4. Enabling a disabled stream
    ==> This again undoes #3.

Having said that, this is what I propose
- Add/Remove stream corresponds to source coming and going away
- Enable/Disable corresponds to stream being used or not given that source
still is connected to the session.


Any thoughts ?

Cheers
Suhas




On Tue, Oct 15, 2013 at 11:07 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>   Hi,
>
>
>
> In BUNDLE we talk about "adding of media description" and "disabling of
> media description", rather than adding and removal of streams.
>
>
>
> I think it would be useful, and more clear, to use similar terminology in
> the POF/PAN spec.
>
>
>
> It has been commented that the the word "remove" can confuse people, as
> media descriptions aren't removed (eventhough the associated streams may
> be).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--047d7b6250b82db95904e8cd6c91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I think this needs to be discussed a bit more

As i see, we have following scenarios

1. Adding a n=
ew stream
=A0 =A0 =A0=3D=3D> This corresponds to adding a new =
source and hence new m=3D line



2. Deleting a already existing stream
=A0 =A0=
 =3D=3D> This is undoing #1 i.e remove the source altogther from input.=
=A0
=A0 =A0 =A0 =A0 =A0 =A0This is typically implemented by setti=
ng Port to Zero for the corresponding to the m=3Dline



3. Disabling an already Existing stream
=A0 =
=A0 =3D=3D> This is where things get little murky and it depends on the =
use-case I believe.=A0
=A0 =A0 =A0 =A0 =A0 =A0 One use-case is if=
 the user wanted to put the stream on hold. This can be done via direction =
attribute (preferred) vs setting port to zero ( not preferred)


=A0=A0
4. Enabling a disabled stream
=
=A0 =A0 =3D=3D> This again undoes #3.

Having sa=
id that, this is what I propose
- Add/Remove stream corresponds t=
o source coming and going away


- Enable/Disable corresponds to stream being used or not given that so=
urce still is connected to the session.


=

Any thoughts ?

Cheers
Suhas



=A0=A0


On Tue, Oct 15, 2013 at 11:07 AM, Christer Holmber=
g <christer.holmberg@ericsson.com> wrote:














Hi,


=A0


In BUNDLE we talk about "addin=
g of media description" and "disabling of media description"=
, rather than adding and removal of streams.



=A0


I think it would be useful, and mor=
e clear,=A0to use similar terminology in the POF/PAN spec.

=A0


It has been commented that the the =
word "remove" can confuse people, as media descriptions aren'=
t removed (eventhough the associated streams may be).


=A0


Regards,


=A0


Christer


=A0


=A0







_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--047d7b6250b82db95904e8cd6c91--

From christer.holmberg@ericsson.com  Tue Oct 15 13:34: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 3E86811E8209 for ; Tue, 15 Oct 2013 13:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMpvMxrudQYy for ; Tue, 15 Oct 2013 13:34:40 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 888DC11E81EA for ; Tue, 15 Oct 2013 13:34:39 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-44-525da6de0fc0
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 57.10.25272.ED6AD525; Tue, 15 Oct 2013 22:34:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 22:34:38 +0200
From: Christer Holmberg 
To: Suhas Nandakumar 
Thread-Topic: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology
Thread-Index: Ac7J0WwMpXCumPu6SpGouNWNgyQuYAAAt8GAAARgCHQAAAs7MA==
Date: Tue, 15 Oct 2013 20:34:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BF370@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BEF82@ESESSMB209.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BF370ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvre69ZbFBBvM6dC32/F3EbjF1+WMW i51zO5gdmD12zrrL7rFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZczoOc5acMCuYtmXR+wN jH9Muhg5OSQETCT2HO1kgrDFJC7cW8/WxcjFISRwlFHifXszO4SzhFFiXesz1i5GDg42AQuJ 7n/aIA0iAloSqxfPBWtmFnCT+Pt/BjOILSzgLvHk5y02kHIRAQ+JjoYgiHInidNvtzGC2CwC qhIbL90AK+EV8JVo69eB2LSZUWL37y9sIDWcAoESC9p3g41nBLrt+6k1UKvEJW49mQ91s4DE kj3nmSFsUYmXj/+BXSkhoCQxbWsaRHm+xLa7R1lAbF4BQYmTM5+wTGAUnYVk0iwkZbOQlEHE 9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEFSNtcTca+9R1Cxg5FjFyFGcWpyUm25ksIkRGH0Ht/y2 2MF4+a/NIUZpDhYlcd6Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBqmmp3zNt/QD95 7nZeZzO2gGLj3XuCGqc73LlVL8XhbFJVPndl7JQUpjdptnXc3GbKB2fy2HA+W5K3+er3Ftfu K9Pnpsftune9a+tms6C3ESni926nPvqYefjN2ci++e0f/R2Ov7z84f39r051hVuvRR5j/7H3 4p3wrGLFyh1+t3l6H25XyVuqxFKckWioxVxUnAgAuNUVv4wCAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology
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 Oct 2013 20:34:45 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BF370ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



In BUNDLE disable means putting the port to zero.



But, again, BUNDLE does not talk about streams, but about media descriptors=
 (m- lines).



Regards,



Christer



________________________________
From: Suhas Nandakumar [suhasietf@gmail.com]
Sent: Tuesday, 15 October 2013 11:28 PM
To: Christer Holmberg
Cc: Adam Roach; mmusic@ietf.org
Subject: Re: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology

I think this needs to be discussed a bit more

As i see, we have following scenarios

1. Adding a new stream
     =3D=3D> This corresponds to adding a new source and hence new m=3D lin=
e

2. Deleting a already existing stream
    =3D=3D> This is undoing #1 i.e remove the source altogther from input.
           This is typically implemented by setting Port to Zero for the co=
rresponding to the m=3Dline

3. Disabling an already Existing stream
    =3D=3D> This is where things get little murky and it depends on the use=
-case I believe.
            One use-case is if the user wanted to put the stream on hold. T=
his can be done via direction attribute (preferred) vs setting port to zero=
 ( not preferred)

4. Enabling a disabled stream
    =3D=3D> This again undoes #3.

Having said that, this is what I propose
- Add/Remove stream corresponds to source coming and going away
- Enable/Disable corresponds to stream being used or not given that source =
still is connected to the session.


Any thoughts ?

Cheers
Suhas




On Tue, Oct 15, 2013 at 11:07 AM, Christer Holmberg > wrote:

Hi,



In BUNDLE we talk about "adding of media description" and "disabling of med=
ia description", rather than adding and removal of streams.



I think it would be useful, and more clear, to use similar terminology in t=
he POF/PAN spec.



It has been commented that the the word "remove" can confuse people, as med=
ia descriptions aren't removed (eventhough the associated streams may be).



Regards,



Christer





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



--_000_7594FB04B1934943A5C02806D1A2204B1C4BF370ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










Hi,


 


In BUNDLE disable means putting the port to zero.


 


But, again, BUNDLE does not talk about streams, but about media descript=
ors (m- lines).


 


Regards,


 


Christer


 




From: Suhas Nandakumar [suhasietf@gmail.c=
om]

Sent: Tuesday, 15 October 2013 11:28 PM

To: Christer Holmberg

Cc: Adam Roach; mmusic@ietf.org

Subject: Re: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminol=
ogy










I think this needs to be discussed a bit more




As i see, we have following scenarios







1. Adding a new stream


     =3D=3D> This corresponds to adding a new source=
 and hence new m=3D line







2. Deleting a already existing stream


    =3D=3D> This is undoing #1 i.e remove the source alto=
gther from input. 


           This is typically implemented=
 by setting Port to Zero for the corresponding to the m=3Dline







3. Disabling an already Existing stream


    =3D=3D> This is where things get little murky and it =
depends on the use-case I believe. 


            One use-case is if the user =
wanted to put the stream on hold. This can be done via direction attribute =
(preferred) vs setting port to zero ( not preferred)


  


4. Enabling a disabled stream






    =3D=3D> This again undoes #3.







Having said that, this is what I propose


- Add/Remove stream corresponds to source coming and going away


- Enable/Disable corresponds to stream being used or not given that so=
urce still is connected to the session.












Any thoughts ?







Cheers


Suhas







  









On Tue, Oct 15, 2013 at 11:07 AM, Christer Holmb=
erg 
<chr=
ister.holmberg@ericsson.com> wrote:








Hi,=



&nb=
sp;


In BUNDLE we talk=
 about "adding of media description" and "disabling of media=
 description", rather than adding and removal of streams.



&nb=
sp;


I think it would =
be useful, and more clear, to use similar terminology in the POF/PAN s=
pec.


&nb=
sp;


It has been comme=
nted that the the word "remove" can confuse people, as media desc=
riptions aren't removed (eventhough the associated streams may be).<=
/font>


&nb=
sp;


Regards,



&nb=
sp;


Christer


&nb=
sp;


 







_______________________________________________

mmusic mailing list

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


















--_000_7594FB04B1934943A5C02806D1A2204B1C4BF370ESESSMB209erics_--

From adam@nostrum.com  Tue Oct 15 13:40: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 9B16D11E820E for ; Tue, 15 Oct 2013 13:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.354
X-Spam-Level: 
X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+EsYpFD5oRa for ; Tue, 15 Oct 2013 13:40:33 -0700 (PDT)
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 5E7C111E81EA for ; Tue, 15 Oct 2013 13:40:29 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FKeOUq000989 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 15:40:25 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525DA833.3010602@nostrum.com>
Date: Tue, 15 Oct 2013 15:40:19 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <525C7537.4080209@nostrum.com>				<525CB632.3030602@nostrum.com>		<525D75C8.70607@nostrum.com>		<525D8779.60901@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 20:40:33 -0000

On 10/15/13 15:25, Martin Thomson wrote:
> On 15 October 2013 11:20, Adam Roach  wrote:
>> Oh, I see. You're throwing 5888 out the window.
>> ...
> Yep, intentionally.  I think that the effect of what you have proposed
> is the same, or close enough that it doesn't matter

How so? With what I propose, the resulting SDP that each side has at the 
end of the transaction is identical to that which would result from a 
full offer/answer exchange using RFC5888.

/a

From martin.thomson@gmail.com  Tue Oct 15 13:46: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 6F58E21F9123 for ; Tue, 15 Oct 2013 13:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix7Y1vru5jn6 for ; Tue, 15 Oct 2013 13:46:14 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D27821F9929 for ; Tue, 15 Oct 2013 13:46:06 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id c11so4345088wgh.26 for ; Tue, 15 Oct 2013 13:45:56 -0700 (PDT)
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=oWxx56DXElS0CiYxeOxAwlqyR0F2JVmHSfxcQQzEy88=; b=Zson17zZG8uDixyEdtbOSKdlcKfkPMUnLnGgsTfYU7NjgLSbBlFji0tm7drb/9elqv 1xNYMkrKCL8jDi9nS/YfGMyWwHJwRMCJa1Bcbsi3Kbz+ssBP+hZhb4TOhPHAh23FSy4i GMUUdzWPOy06yqWwNDtISplqDB3mJGAH6rFlsUiuv3H7P3T8Y21kCiqxgHwcNqYUT6z0 qmRFOxWvZ7JECOFOsBLHR8G/18dIaphoj7M72u5LxkeNvpT43ZUxeSTUWGJXVppdDflF axQh6lRDC/yXKgT7uKmvxEI8sfe4+teFRrPZZ2TezwF5Le4caitIzDjYQmsUaITRl5TB FpJw==
MIME-Version: 1.0
X-Received: by 10.180.37.164 with SMTP id z4mr21500720wij.30.1381869956520; Tue, 15 Oct 2013 13:45:56 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 13:45:56 -0700 (PDT)
In-Reply-To: <525DA833.3010602@nostrum.com>
References: <525C7537.4080209@nostrum.com>    <525CB632.3030602@nostrum.com>  <525D75C8.70607@nostrum.com>  <525D8779.60901@nostrum.com>  <525DA833.3010602@nostrum.com>
Date: Tue, 15 Oct 2013 13:45:56 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 20:46:14 -0000

On 15 October 2013 13:40, Adam Roach  wrote:
> How so? With what I propose, the resulting SDP that each side has at the end
> of the transaction is identical to that which would result from a full
> offer/answer exchange using RFC5888.

That's only true through synthesis.  A process that is more
deterministic with what I propose.

Both rely on synthesis, I just went from a sometimes dependency to an
always dependency.

From pkyzivat@alum.mit.edu  Tue Oct 15 14:19: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 B2D0B11E80E0 for ; Tue, 15 Oct 2013 14:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.023
X-Spam-Level: 
X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[AWL=-0.140,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_18=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjEUifxPzeuE for ; Tue, 15 Oct 2013 14:19:14 -0700 (PDT)
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 B986511E812B for ; Tue, 15 Oct 2013 14:19:11 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id dPri1m0010QuhwU5CZKBbJ; Tue, 15 Oct 2013 21:19:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id dZKB1m0063ZTu2S3NZKBjz; Tue, 15 Oct 2013 21:19:11 +0000
Message-ID: <525DB14E.8060804@alum.mit.edu>
Date: Tue, 15 Oct 2013 17:19:10 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <525C7537.4080209@nostrum.com>
In-Reply-To: <525C7537.4080209@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=1381871951; bh=pdCaipNJIle9Pdc6rgaddWbblUT1VaGe5yRaWTrByOQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Tei1fXpwBj2+qUtY/fd4iP7+KyFtO0CiAcPrbcBsE9i91jTYb1kDSAXp+1a/t5TrH qx6aXclKucYQTRydNAO2iBCCvwDV9fuVYgtEMV94OMSMKPZgJMAZf3dLxWFLRtL1tc zc64bS8p8tY7/YWKfLXY13VEoLWeoIUC/HR0UIlbu5sIoM+7qhp8/aquqb4GfZ0plP h8dZmMt5C/qrprYBBC5ASfT15qvLdUfGPEU+2SY87pk/Sdlm3TQ1xxJA+0SzyDyppO 3ayGzJCubZfbSA85GyHt0DQRwHw2ea1VJpGlmSRzaGmBVoPvWOKckv9UaeREkZ9ty1 z1SExBNjyqB+g==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 21:19:18 -0000

Adam,

I was pretty down on the initial proposal. It seemed like too much of a 
hack. But with this writeup its looking more plausible. Here are 
comments that I collected while reading:

General comments:

I believe it is valid to have multiple mid lines per media section. In 
that case, which one is used for ordering? What if I want to move a mid 
line from one media section to another, or remove one?

Simple answer: doing anything with multiple mids per m-line, changing 
mids, and moving mids from one m-line to another can only be done with a 
full O/A.

The use of the term "remove" to describe setting the m-line port to zero 
(many places) seems inappropriate and confusing, since the m-line 
remains. I suggest using "deactivate" or "reject" instead.

Section 1:

In the following:

    Many of the emerging uses for both SIP and RTCWEB involve sessions
    with a large number of media streams, with streams being added and
    removed frequently.  This kind of session churn increases the
    incidence of glare significantly.

s/incidence of/potential for/

(While the number of changes is relevant, its the likelihood that the 
changes on both ends are synchronized that makes the most difference. 
For unsynchronized changes to glare the fraction of session time spent 
changing streams must be negligible.)

Section 3.2:

I don't understand the open issue. How do stream changes result in glare?

Then, in:

    If the recipient of a partial offer that contains an existing MID has
    also sent a partial offer to change that exact same stream, and
    neither the received nor the sent partial offer contains an
    "a=inactive" attribute, then a legitimate glare condition has arisen.

Why is a=inactive an exception? Where are the special rules for it?

Section 5.2:

The restriction to changing a *single* media section per partial offer 
is intended? What is wrong with changing several media sections in the 
same partial offer? (Other than increasing the possibility of glare.)

I'm bothered by the use of random values for the new mid values. (I just 
hate *depending* on two random values being different.) Instead, how 
about specifying that each end use a unique prefix. We can find some 
method to select the prefix. E.g., userid + sessionid from the o-line. 
(Forbid use of partial offers if those aren't unique.)

Section 5.3:

I think you need to s/less than/less than or equal to/ in:

    The agent then examines the o= line in the received partial offer.
    If the  value is less than the most recently
    received full (non-partial) offer or answer, then the partial offer
    is stale and MUST be rejected.

Section 5.4:

The following:

    When a partial answer is received, the offerer matches each media
    section in the partial answer to its corresponding media section
    according to its MID.

doesn't specify the source of the media sections to match against. I 
think you mean "to its corresponding media section in the partial offer".

Section 5.5:

The following:

    Whenever a partial offer or partial answer is processed, the agent
    performs the following steps to ensure that a common view of session
    state is maintained:

doesn't say *when* this will be done. IIUC this is to be done by the 
offerer upon successful receipt of the partial answer, and by the 
answerer upon the sending of the partial answer. Right?

Steps 3 & 4:

Deciding *when* to do this is tricky. I don't know exactly what you have 
in mind. I do have an idea for a simpler way:

For all partial updates following a particular O/A, order *all* the 
added media sections by their mid value. A new O/A then freezes those 
and starts over.

That's all.

	Thanks,
	Paul

On 10/14/13 6:50 PM, Adam Roach wrote:
> I have submitted a document that formally describes the procedures for
> using partial offers and partial answers within the RFC 3264 framework.
> There were already several comments on the mechanism from its
> description in the unified plan, and I believe that these have all been
> incorporated as either improvements or clarifications. If I missed
> something, please let me know.
>
> As we discussed in Berlin, the real impetus for this work is for use in
> RTCWEB. The document is written in a way that considers its potential
> application to SIP; however, I do not mean to imply that adding a
> partial offer/partial answer mechanism in SIP is by any means a foregone
> conclusion.
>
> There are a number of open issues in the document, all of which should
> be clearly marked with an "OPEN ISSUE:" tag. If time allows, I plan to
> release a -01 version of the document that includes a set of relevant
> examples ahead of the draft deadline next Monday; however, I cannot
> promise that I will have time to do so. If I do, the _only_ changes will
> be in section 6, so any notes that you make should transfer over
> (including section, page, and paragraph number).
>
> If you have time before Vancouver, please post thoughts on the MMUSIC
> mailing list. Thanks.
>
> http://www.ietf.org/id/draft-roach-mmusic-pof-pan-00.txt
>
> /a
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From martin.thomson@gmail.com  Tue Oct 15 14:32: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 CFE5121F9CEA for ; Tue, 15 Oct 2013 14:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1oCf4qu5E14 for ; Tue, 15 Oct 2013 14:32:20 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 84DB021F9CFB for ; Tue, 15 Oct 2013 14:32:18 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id y10so6788893wgg.20 for ; Tue, 15 Oct 2013 14:32:17 -0700 (PDT)
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=ORiimihCn32kWIHiJOxupUZVWyuttyerDQsCBIja8ns=; b=e4nmUpEpCGQM9IBBvjzpBq7tFBv7CJv5Ywpn5ETGnCcDmnbf8xHItFnsV7x+explr4 GqultZxZ53T7qmoIS4PsnPlibHunXpA1bTSu+7ZYh8tpjlSS2TK6fmJvfUYeS+f0f9sF ss7rLsFGlzyN+QpfV8Z7GD8B6AKbJFrRQJNLZw8Db3sMo0LHgMaq4gPfMETMMFwvIuxs Qy2pcX2Rt1Qojkwa7GcqiQRGi01BKCjUwRnV3fSM27jjS5KDs2R0u/EGA5Jra7XELxzv 9RclPUNbgipWY33G1NhFC6+2JwvVIHPovrpnRV195BeBzneOuCfqbTNzjLK+MeV90W96 iPcg==
MIME-Version: 1.0
X-Received: by 10.180.78.193 with SMTP id d1mr21356227wix.22.1381872737532; Tue, 15 Oct 2013 14:32:17 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 14:32:17 -0700 (PDT)
In-Reply-To: <525DB14E.8060804@alum.mit.edu>
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu>
Date: Tue, 15 Oct 2013 14:32:17 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 21:32:21 -0000

On 15 October 2013 14:19, Paul Kyzivat  wrote:
> I'm bothered by the use of random values for the new mid values. (I just
> hate *depending* on two random values being different.)

But I really like that part.  There's more than a little schadenfreude
involved though.  I know that this irritates people.

Tell you what, I'll bet that you won't find a collision.

What annoys *me* is the requirement to use all 79 characters.  The
only way to do that efficiently is to waste good random entropy.

From martin.thomson@gmail.com  Tue Oct 15 14:34: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 1A1C221F9CEA for ; Tue, 15 Oct 2013 14:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ31KVW9ROiV for ; Tue, 15 Oct 2013 14:34:36 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1B42A21F9D09 for ; Tue, 15 Oct 2013 14:34:34 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id cb5so6172012wib.2 for ; Tue, 15 Oct 2013 14:34:34 -0700 (PDT)
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=2Rayt+vAEmsO88sMABeQSGsPkrUdSDTrWvYMgjGE3h8=; b=vUUPPdoqpAqBtbgeT1upL8uiVA11JKqnKnPZMrdJggwg4Jm5qK6XEedz3jFXi/Qy6X oAOmOkKW1gZz551XhKSwSCZaUT/NGQK6FcXwdCrH+JbP8h68IHqAJkGJQox3e4FEkDuu T/orbxdcOV2TbiRysuACwA1ZHuZXC8z6HNvmillplE/ROFNmfuNootQVk+nEAYkL8qpw wg8Ex59G+wASbffsdvTz9F7OTClj+v5jr04f2TCZGpzARfDVymuEJCX6WcR1SGGwh/g6 onDMxSRxSc1xJXg7TCkEEt/RshbI12K3ZDwaUwqgGzCYNiSLqMNnm7dRDEqLg+skHi6N FhBQ==
MIME-Version: 1.0
X-Received: by 10.180.37.164 with SMTP id z4mr21645961wij.30.1381872874190; Tue, 15 Oct 2013 14:34:34 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 15 Oct 2013 14:34:34 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BF370@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4BEF82@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4BF370@ESESSMB209.ericsson.se>
Date: Tue, 15 Oct 2013 14:34:34 -0700
Message-ID: 
From: Martin Thomson 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] POF/PAN Editorial: Allign with BUNDLE terminology
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 Oct 2013 21:34:37 -0000

On 15 October 2013 13:34, Christer Holmberg
 wrote:
> But, again, BUNDLE does not talk about streams, but about media descriptors
> (m- lines).

I'm sure that you can work this out.

http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-02

From pkyzivat@alum.mit.edu  Tue Oct 15 15:08: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 2C8AA11E814F for ; Tue, 15 Oct 2013 15:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level: 
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=0.164,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBz48KnCZsJA for ; Tue, 15 Oct 2013 15:07:38 -0700 (PDT)
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 231A911E8189 for ; Tue, 15 Oct 2013 15:07:10 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id dXSJ1m0021vXlb851a6vfo; Tue, 15 Oct 2013 22:06:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id da6v1m00X3ZTu2S3da6vcw; Tue, 15 Oct 2013 22:06:55 +0000
Message-ID: <525DBC7E.5080609@alum.mit.edu>
Date: Tue, 15 Oct 2013 18:06:54 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@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=1381874815; bh=Cdvz5EBmsXdYoM+vCFmrql5Al8zgU9jzk9zfCNB49Gs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ha818PBPIBG2o7rylJr4A0dA8H65MsASDDDmhtM56N74Tc+Or3Vv5qdRFe7/Xbcp7 WZkjAlHYcUl69bjqlEr8EJqD1AwTyH/s52RAXNOPasDhGZ3dcYQy5GSP8Msw07sRwK X65n/ZUNKIe8xDq0+tBKXDdUL+nuh7sCJuMUBp2fhc31KcyL0fBJzQtXfCSxI1XaU8 J5YyxgO5LP06szXtCfI/c2NXO6aYE8hzrkHAk7naf7dd67AMoFAabb3Zj9avC6AkV6 Bh2BrWl92YGTvvxtoqfcMWb86x5PvrcuIf7JkEAJUXDyLNChcErBTHts/F3AqB6noU p/8YDZGwDWi6w==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Tue, 15 Oct 2013 22:08:03 -0000

On 10/15/13 5:32 PM, Martin Thomson wrote:
> On 15 October 2013 14:19, Paul Kyzivat  wrote:
>> I'm bothered by the use of random values for the new mid values. (I just
>> hate *depending* on two random values being different.)
>
> But I really like that part.  There's more than a little schadenfreude
> involved though.  I know that this irritates people.
>
> Tell you what, I'll bet that you won't find a collision.

Probably not. But I don't believe in using "probably" when deciding if 
things work. (I'm ok with it when people are satisfied with being told 
that the algorithm "probably" works.)

I'm still expecting to have trouble breathing sometime because all the 
air randomly decided to move to the other side of the room. :-)

	Thanks,
	Paul


From christer.holmberg@ericsson.com  Tue Oct 15 23:48: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 8FDCA11E80F9 for ; Tue, 15 Oct 2013 23:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.893
X-Spam-Level: 
X-Spam-Status: No, score=-3.893 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+YBscnFe771 for ; Tue, 15 Oct 2013 23:48:40 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1015E21F9E54 for ; Tue, 15 Oct 2013 23:48:39 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-52-525e36c775ce
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D6.64.25272.7C63E525; Wed, 16 Oct 2013 08:48:39 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 08:48:38 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft
Thread-Index: AQHOyS/VDi7jGJKfu0+LtCEoj80NX5n2JHkAgAADq4CAAAmsAIAArivg
Date: Wed, 16 Oct 2013 06:48:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BF7D5@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu>  <525DBC7E.5080609@alum.mit.edu>
In-Reply-To: <525DBC7E.5080609@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre5xs7ggg7PfJSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj/+JT7AXLhSoadh1kbWA8zNfFyMkhIWAi Me/BZjYIW0ziwr31QDYXh5DAUUaJlu0XoZwljBJznp5k72Lk4GATsJDo/qcN0iAi4Cvx7PFt sGZhoPCcXzNZIeKWEpPezGGHsN0kbl/sB7NZBFQluj+uZgQZwwvU+3RqDEhYSGAzo8SP9UUg NqeAjsTTsy8YQWxGoHu+n1rDBGIzC4hL3HoynwniTgGJJXvOM0PYohIvH/9jBRkpIaAosbxf DqJcR2LB7k9sELa2xLKFr8HKeQUEJU7OfMIygVF0FpKps5C0zELSMgtJywJGllWMHMWpxUm5 6UYGmxiBkXBwy2+LHYyX/9ocYpTmYFES5/341jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A+PmKV6WC07ZyMx+Pltm89FllayrF+18kqen2xwYdD/6T2fTtZna8VxBu7c+2BbzablKvUXD 8gezrjKVz5je/y5MNtlD23Z246yb53x+ysmzByUrS11+EWRQ4/h1vV3U+uL1rK+nbPt9/vvU JTma1yfs7nZwfDvXJX7FmkcGnTvjJjTzr7KUf+enxFKckWioxVxUnAgAaG1bUVICAAA=
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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, 16 Oct 2013 06:48:45 -0000

Hi,

Eventhough there might not be a collision, I think there can be ambiguity (=
as defined in section 3.1 of POF/PAN).

Example:

- Alice sends a POF (mid=3Dx) to Bob. At the same time Bob sends a POF (mid=
=3Dy) to Alice.
- Bob sends a PAN to Alice's POF.

Now, Alice does not know whether Bob sent his POF before he received Alice'=
s POF.  Alice may make assumptions based on the order she receives the POF =
and PAN, but that is not necessarily the same order in which they were sent=
 by Bob.

So, Alice and Bob (not to mention possible intermediaries) may have differe=
nt views on whether there were ambiguity or not, which may affect in which =
order they add the m- lines to the "session SDP":

- If Alice receives the PAN before the POF, she may assume there was no amb=
iguity, and assume order x, y.
- If Bob receives Alice's POF before he receives the PAN to his own POF, he=
 will trigger the procedures for ambiguity, which may result in order y, x =
(based on the lexical comparison).

Please let me know if you didn't understand the use-case, and I'll try to d=
raw a picture :)

Regards,

Christer










-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Paul Kyzivat
Sent: 16. lokakuuta 2013 1:07
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft

On 10/15/13 5:32 PM, Martin Thomson wrote:
> On 15 October 2013 14:19, Paul Kyzivat  wrote:
>> I'm bothered by the use of random values for the new mid values. (I=20
>> just hate *depending* on two random values being different.)
>
> But I really like that part.  There's more than a little schadenfreude=20
> involved though.  I know that this irritates people.
>
> Tell you what, I'll bet that you won't find a collision.

Probably not. But I don't believe in using "probably" when deciding if thin=
gs work. (I'm ok with it when people are satisfied with being told that the=
 algorithm "probably" works.)

I'm still expecting to have trouble breathing sometime because all the air =
randomly decided to move to the other side of the room. :-)

	Thanks,
	Paul

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

From adam@nostrum.com  Wed Oct 16 01:35: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 3E23F21F9D95 for ; Wed, 16 Oct 2013 01:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.373
X-Spam-Level: 
X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj0R0AdK2nCV for ; Wed, 16 Oct 2013 01:35:58 -0700 (PDT)
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 138EB21F9E40 for ; Wed, 16 Oct 2013 01:35:51 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9G8Zjlk080297 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 03:35:47 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <525E4FDC.8080907@nostrum.com>
Date: Wed, 16 Oct 2013 03:35:40 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu>		<525DBC7E.5080609@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4BF7D5@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BF7D5@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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, 16 Oct 2013 08:35:59 -0000

On 10/16/13 01:48, Christer Holmberg wrote:
> - Alice sends a POF (mid=x) to Bob. At the same time Bob sends a POF (mid=y) to Alice.
> - Bob sends a PAN to Alice's POF.
>
> Now, Alice does not know whether Bob sent his POF before he received Alice's POF.  Alice may make assumptions based on the order she receives the POF and PAN, but that is not necessarily the same order in which they were sent by Bob.

Ah, I'd meant to mention that we need to ensure reliable, in-order 
delivery of POFs and PANs, and that the higher-level protocol is 
responsible for doing so. All of the processing is based on this rather 
important assumption.

/a

From bo.burman@ericsson.com  Wed Oct 16 01:44: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 6148711E8298 for ; Wed, 16 Oct 2013 01:44:02 -0700 (PDT)
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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCpQ7BOyS2pf for ; Wed, 16 Oct 2013 01:43:56 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2795011E8167 for ; Wed, 16 Oct 2013 01:43:54 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-8b-525e51c4a34f
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 07.C6.16099.4C15E525; Wed, 16 Oct 2013 10:43:48 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.148]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 10:43:47 +0200
From: Bo Burman 
To: Christer Holmberg , Jonathan Lennox 
Thread-Topic: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration
Thread-Index: Ac6f7ikjB1DJ6cLXRlGYV8ZqhT4gnQOHMl7wAA+0SAAAHO6sAAbhV9rg
Date: Wed, 16 Oct 2013 08:43:47 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C47766D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C49D736@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C49EFB2@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C49EFB2@ESESSMB209.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DFA05C6ESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvre6RwLggg85TIhb7F59ntpi6/DGL A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4Mp4Ou8IS8HDaUwVL37sZW9g/PSdsYuRk0NC wERi4b9jULaYxIV769lAbCGBw4wSW99ldTFyAdlLGCVW9c1kBkmwCWhIzN9xF6xBRCBO4v6B PawgNrOAjMSMs41MILawQK7EpZZVbBA1eRJtk+6xQthuElsXzAGzWQRUJebt+Aw2k1fAV+Lx 7XOsEMs6mCS+zFrAApLgFPCTOPZkN9hQRgFZifvf77FALBOXuPVkPhPE1QISS/acZ4awRSVe Pv7HCmErSlydvpwJoj5f4t7Sf1DLBCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsTG4StLbFs 4WtmGPvMgcdMyOILGNlXMbLnJmbmpJcbbmIERtbBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxTvu7bK1UjbSJYdPThd6OOP83bcu5cTLzsW9Ifpevr FsurxVD1YI7S3auvs1MTG8oOqk8wklE2c759sDdtQ1aT2rKlciKrG9mnXN/V8Xz5iq1n5iz0 8amJD9ZV9z0d/O383a6sMq1r6yUacpsK7AJefN9X/+/sJjatszprzpxen+09ZcIto1AlluKM REMt5qLiRAB4lZafegIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration
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 Oct 2013 08:44:02 -0000

--_000_BBE9739C2C302046BD34B42713A1E2A22DFA05C6ESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I agree with Jonathan that in order to make two PT values "equal", their rt=
pmap and fmtp lines must be equal, as a start.

I don't think there is any "correct" criterion that can be used to judge PT=
 for equality, but we just have to decide on a "reasonable" one that is as =
simple as possible without causing any major problems.

I have assumed a conceptual equality criterion where PT value A should be c=
onsidered equal to another PT value B if an RTP stream with PT A can be fed=
 into a decoder stack configured with PT B, and vice versa, without causing=
 either decoder stack to "break".

I don't think we should require the fmtp lines are textually equal, but onl=
y that the same parameters are present and have the same values. The order =
of the parameters on the fmtp line does not matter. There is also the case =
when a parameter is specified with the default value for one PT and omitted=
 for the other. To identify those as equal, which they semantically are, wo=
uld require an "equality parser" to know every default value of every fmtp =
parameter for all codecs. This seems unreasonable.

Regarding Jonathan's question on H.264 sprop-..., I guess they don't strict=
ly need to be equal to make the PTs equal, but they may have to be. They ef=
fectively configure the decoder in some way and if there is a mismatch, the=
 decoding process will likely break; like mis-interpretations or buffer ove=
rflows. On the other hand, some sprop-... can be updated by in-band informa=
tion, overriding what is specified on the fmtp line, and in this case the f=
mtp line sprop-... information is obsolete. Requiring that all fmtp of the =
line is equal however makes a simple rule, which should be preferable and I=
 don't think it is too restrictive or excessive.

However, if the potentially equal PT values are defined as part of differen=
t media descriptions, other media level attributes also contribute to the d=
ecoder stack configuration. Some attributes, like maxptime, can clearly cau=
se problems (in this case buffer overflow) if it differs. Others, like ptim=
e, framerate and imageattr are more of a receiver preference within a more =
formal "conformance point" and would not "break" a decoder stack if they di=
ffer.

I agree it can be a good idea to add some text into the mux-attributes draf=
t about attributes that have to be the same to consider two PT in different=
 media descriptions to be "equal", of course given that rtpmap and fmtp are=
 also equal.

/Bo

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Christer Holmberg
Sent: den 11 september 2013 09:12
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

It would be so easy if we could define the PT mappings on the SDP session l=
evel, and then simply refer to them within the m- lines :)

Regards,

Christer

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 10. syyskuuta 2013 22:18
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

My strawman proposal at the mic in Berlin was that a codec configuration is=
 defined by the top-level media type of the m=3D line and the content of a =
given PT value's rtpmap and fmtp lines.  I.e., the full media type, with al=
l its parameters.

The questions I would have to this straw man are:

* Is this excessive?  E.g., should items like H.264's sprop- parameters be =
allowed to differ across m=3D line blocks?

* Is this sufficient?  Should other items (sometimes) indexed by PT (e.g., =
the imageattr, rtcp-fb, or extmap attributes) need to be the same across m-=
lines as well?

My suggestion would be that this work should be folded into the work being =
done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should be =
integrated with BUNDLE).  Currently (I believe) the mux-attributes draft as=
sumes that PTs are unique across m-lines, so this work is going to imply ch=
anges to the analysis of a number of attributes in that draft, regardless. =
 Probably a new category will need to be defined for attributes which have =
to be consistent per payload type.

On Sep 10, 2013, at 5:56 AM, Christer Holmberg > wrote:


Hi,

Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q=
7 in Berlin.

Questions:

Q1: "Can we agree that, within a BUNDLE group (including all m- lines assoc=
iated with the group), any given PT value can only be used for a single cod=
ec configuration?"
Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there are=
 opinions that simply referencing RFC 3550 might not be clear enough?"
Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in m=
ultiple RTP m- lines, for the SAME codec configuration?"

Outcome:

Q1: Yes
Q2: Yes, Lennox will send suggested text to clarify the term "codec configu=
ration".
Q7: Yes.

So, again, we need definition text for "codec configuration". Jonathan prom=
ised to submit something, but anyone is of course welcome to do that.

The other alternative is to not say anything about PT value usages within t=
he scope of BUNDLE, but that is not what the meeting wanted.

Regards,

Christer


From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 23. elokuuta 2013 13:53
To: mmusic
Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value fo=
r single codec configuration

Hi,

One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7=
 in my slides) was regarding the usage of any given PT value.

My take of the outcome was that:

-          We agreed that any given PT value can only be used for a single =
codec configuration (Q1)
-          We agreed that we need some definition text for "codec configura=
tion" (Q2)
-          We agreed that, within a BUNDLE group, any given PT value can be=
 used in multiple m- lines, as long as it is used for a single codec config=
uration (Q7).

Jonathan Lennox promised to suggest some definition text for "codec configu=
ration", so let's wait for that until we go into those discussions.

But, if you have any issues with the agreements in general, please bring th=
em up :)

Regards,

Christer




--
Jonathan Lennox
jonathan@vidyo.com


--_000_BBE9739C2C302046BD34B42713A1E2A22DFA05C6ESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

I agree with Jonathan tha=
t in order to make two PT values “equal”, their rtpmap and fmtp=
 lines must be equal, as a start.


 <=
/p>

I don’t think there=
 is any “correct” criterion that can be used to judge PT for eq=
uality, but we just have to decide on a “reasonable” one that i=
s as simple
 as possible without causing any major problems.


 <=
/p>

I have assumed a conceptu=
al equality criterion where PT value A should be considered equal to anothe=
r PT value B if an RTP stream with PT A can be fed into
 a decoder stack configured with PT B, and vice versa, without causing eith=
er decoder stack to “break”.


 <=
/p>

I don’t think we sh=
ould require the fmtp lines are textually equal, but only that the same par=
ameters are present and have the same values. The order of the
 parameters on the fmtp line does not matter. There is also the case when a=
 parameter is specified with the default value for one PT and omitted for t=
he other. To identify those as equal, which they semantically are, would re=
quire an “equality parser” to know
 every default value of every fmtp parameter for all codecs. This seems unr=
easonable.


 <=
/p>

Regarding Jonathan’=
s question on H.264 sprop-…, I guess they don’t strictly need t=
o be equal to make the PTs equal, but they may have to be. They effectively
 configure the decoder in some way and if there is a mismatch, the decoding=
 process will likely break; like mis-interpretations or buffer overflows. O=
n the other hand, some sprop-… can be updated by in-band information,=
 overriding what is specified on the fmtp
 line, and in this case the fmtp line sprop-… information is obsolete=
. Requiring that all fmtp of the line is equal however makes a simple rule,=
 which should be preferable and I don’t think it is too restrictive o=
r excessive.


 <=
/p>

However, if the potential=
ly equal PT values are defined as part of different media descriptions, oth=
er media level attributes also contribute to the decoder
 stack configuration. Some attributes, like maxptime, can clearly cause pro=
blems (in this case buffer overflow) if it differs. Others, like ptime, fra=
merate and imageattr are more of a receiver preference within a more formal=
 “conformance point” and would not
 “break” a decoder stack if they differ.


 <=
/p>

I agree it can be a good =
idea to add some text into the mux-attributes draft about attributes that h=
ave to be the same to consider two PT in different media
 descriptions to be “equal”, of course given that rtpmap and fm=
tp are also equal.


 <=
/p>

/Bo


 <=
/p>







From: mmusic-b=
ounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: den 11 september 2013 09:12

To: Jonathan Lennox

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 <=
/p>

It would be so easy if we=
 could define the PT mappings on the SDP session level, and then simply ref=
er to them within the m- lines :)


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>



 




My strawman proposal at the mic in Berlin was that a=
 codec configuration is defined by the top-level media type of the m=3D lin=
e and the content of a given PT value's rtpmap and fmtp lines.  I.e., =
the full media type, with all its parameters.






 






The questions I would have to this straw man are:






 






* Is this excessive?  E.g., should items like H=
.264's sprop- parameters be allowed to differ across m=3D line blocks?=







 






* Is this sufficient?  Should other items (some=
times) indexed by PT (e.g., the imageattr, rtcp-fb, or extmap attributes) n=
eed to be the same across m-lines as well?






 






My suggestion would be that this work should be fold=
ed into the work being done in draft-nandakumar-mmusic-sdp-mux-attribu=
tes (which really should be integrated with BUNDLE).  Currently (I bel=
ieve) the mux-attributes draft assumes that
 PTs are unique across m-lines, so this work is going to imply changes to t=
he analysis of a number of attributes in that draft, regardless.  Prob=
ably a new category will need to be defined for attributes which have to be=
 consistent per payload type.




 





 






 






Hi,






 






Below is the “offic=
ial” (from the minutes) outcome of questions Q1,Q2 and Q7 in Berlin.<=
/span>






 






Questions:<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif"">






 






Q1: “Can we agree t=
hat, within a BUNDLE group (including all m- lines associated with the grou=
p), any given PT value can only be used for a single codec configuration?&#=
8221;






Q2: “If Q1, do we a=
gree that we need EXPLICIT text somewhere*, as there are opinions that simp=
ly referencing RFC 3550 might not be clear enough?”






Q7: “Within a BUNDL=
E group, do we allow the usage of the same PT value in multiple RTP m- line=
s, for the SAME codec configuration?”<=
/span>






 






Outcome:






 






Q1: Yes






Q2: Yes, Lennox will send=
 suggested text to clarify the term “codec configuration”.






Q7: Yes.






 






So, again, we need defini=
tion text for “codec configuration”. Jonathan promised to submi=
t something, but anyone is of course welcome to do that.






 






The other alternative is =
to not say anything about PT value usages within the scope of BUNDLE, but t=
hat is not what the meeting wanted.





 






Regards,






 






Christer






 






 










From: mmusic-bounces@ie=
tf.org [mailto=
:mmusic-bo=
unces@ietf.org] On
 Behalf Of Christer H=
olmberg

Sent: 23. elokuuta=
 2013 13:53

To: mmusic

Subject: [MMUSIC] =
DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec con=
figuration










 






Hi,






 






One of the open issues related to BUNDL=
E presented in Berlin (Q1, Q2 and Q7 in my slides) was regarding the usage =
of any given PT value.






 






My take of the outcome was that:






 






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that
 any given PT value can only be used for a single codec configuration (Q1)<=
o:p>






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that
 we need some definition text for “codec configuration” (Q2)






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that,
 within a BUNDLE group, any given PT value can be used in multiple m- lines=
, as long as it is used for a single codec configuration (Q7).






 






Jonathan Lennox promised to suggest som=
e definition text for “codec configuration”, so let’s wai=
t for that until we go into those discussions.






 






But, if you have any issues with the ag=
reements in general, please bring them up :)






 






Regards,






 






Christer






 <=
o:p>






 <=
o:p>






 <=
o:p>








 






--






Jonathan Lennox

jonathan@vidyo.com






 








--_000_BBE9739C2C302046BD34B42713A1E2A22DFA05C6ESESSMB105erics_--

From christer.holmberg@ericsson.com  Wed Oct 16 02:12:24 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 68DBE21F967A for ; Wed, 16 Oct 2013 02:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.694
X-Spam-Level: 
X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.554,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ+yW5zcRm0v for ; Wed, 16 Oct 2013 02:12:18 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3E12D21F9CE8 for ; Wed, 16 Oct 2013 02:12:17 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-49-525e586f9746
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AD.11.03802.F685E525; Wed, 16 Oct 2013 11:12:15 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 11:12:15 +0200
From: Christer Holmberg 
To: Bo Burman , Jonathan Lennox 
Thread-Topic: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration
Thread-Index: Ac6f7ikjB1DJ6cLXRlGYV8ZqhT4gnQOHMl7wAA+0SAAAHO6sAAbhV9rgAALm/OA=
Date: Wed, 16 Oct 2013 09:12:14 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BFC2D@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C47766D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C49D736@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C49EFB2@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BFC2DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW5+RFyQQe81S4v9i88zW0xd/pjF gcljyZKfTB5tz+6wBzBFcdmkpOZklqUW6dslcGW0PG5nKri2nqmiYc8m5gbGrX1MXYycHBIC JhKrz89nhbDFJC7cW8/WxcjFISRwmFHiwYdVUM4SRonOiW8Yuxg5ONgELCS6/2mDmCICPhIH 96WB9DILyEjMONsINlNYIFfiUgtIKydQSZ5E26R7rBC2n0TThwdgcRYBVYn991azg9i8Ar4S 95ceYoVYdYZJYveOQ4wgCU6ghtmvWsFsRqDjvp9awwSxTFzi1pP5UA8ISCzZc54ZwhaVePn4 HyvIbRICihLL++VATGaBfInu2WUQqwQlTs58wjKBUXQWkkGzEKpmIamCKNGRWLD7ExuErS2x bOFrZhj7zIHHTMjiCxjZVzGy5yZm5qSXG21iBEbUwS2/VXcw3jkncohRmoNFSZz3w1vnICGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mk+7szpbtMy7f5PLp4BaJoMkyAp98Wt9yCiaY1/Vw 7nnMzcdpnsS/xderpX+az72tuYaXX2l/Wvxgf/svvqPLhe+GOjsI+l5nN7fbd5th804pbbbl t5TOWKdolxcuE/AXnPZp/r28RMOFTpK3F7BOaBDPsOv4GX7xRVjdt6elVjP4I7UZGFOVWIoz Eg21mIuKEwEPN4EadgIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration
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 Oct 2013 09:12:24 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4BFC2DESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Bo,

Thanks for your input!

I'd ask anyone who might have an opinion about this to take a look at the p=
roposal, comment on the list if needed, and hopefully we can agree on way f=
orward in Vancouver (or, even earlier :)

Regards,

Christer

From: Bo Burman
Sent: 16. lokakuuta 2013 11:44
To: Christer Holmberg; Jonathan Lennox
Cc: mmusic
Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

I agree with Jonathan that in order to make two PT values "equal", their rt=
pmap and fmtp lines must be equal, as a start.

I don't think there is any "correct" criterion that can be used to judge PT=
 for equality, but we just have to decide on a "reasonable" one that is as =
simple as possible without causing any major problems.

I have assumed a conceptual equality criterion where PT value A should be c=
onsidered equal to another PT value B if an RTP stream with PT A can be fed=
 into a decoder stack configured with PT B, and vice versa, without causing=
 either decoder stack to "break".

I don't think we should require the fmtp lines are textually equal, but onl=
y that the same parameters are present and have the same values. The order =
of the parameters on the fmtp line does not matter. There is also the case =
when a parameter is specified with the default value for one PT and omitted=
 for the other. To identify those as equal, which they semantically are, wo=
uld require an "equality parser" to know every default value of every fmtp =
parameter for all codecs. This seems unreasonable.

Regarding Jonathan's question on H.264 sprop-..., I guess they don't strict=
ly need to be equal to make the PTs equal, but they may have to be. They ef=
fectively configure the decoder in some way and if there is a mismatch, the=
 decoding process will likely break; like mis-interpretations or buffer ove=
rflows. On the other hand, some sprop-... can be updated by in-band informa=
tion, overriding what is specified on the fmtp line, and in this case the f=
mtp line sprop-... information is obsolete. Requiring that all fmtp of the =
line is equal however makes a simple rule, which should be preferable and I=
 don't think it is too restrictive or excessive.

However, if the potentially equal PT values are defined as part of differen=
t media descriptions, other media level attributes also contribute to the d=
ecoder stack configuration. Some attributes, like maxptime, can clearly cau=
se problems (in this case buffer overflow) if it differs. Others, like ptim=
e, framerate and imageattr are more of a receiver preference within a more =
formal "conformance point" and would not "break" a decoder stack if they di=
ffer.

I agree it can be a good idea to add some text into the mux-attributes draf=
t about attributes that have to be the same to consider two PT in different=
 media descriptions to be "equal", of course given that rtpmap and fmtp are=
 also equal.

/Bo

From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: den 11 september 2013 09:12
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

It would be so easy if we could define the PT mappings on the SDP session l=
evel, and then simply refer to them within the m- lines :)

Regards,

Christer

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 10. syyskuuta 2013 22:18
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

My strawman proposal at the mic in Berlin was that a codec configuration is=
 defined by the top-level media type of the m=3D line and the content of a =
given PT value's rtpmap and fmtp lines.  I.e., the full media type, with al=
l its parameters.

The questions I would have to this straw man are:

* Is this excessive?  E.g., should items like H.264's sprop- parameters be =
allowed to differ across m=3D line blocks?

* Is this sufficient?  Should other items (sometimes) indexed by PT (e.g., =
the imageattr, rtcp-fb, or extmap attributes) need to be the same across m-=
lines as well?

My suggestion would be that this work should be folded into the work being =
done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should be =
integrated with BUNDLE).  Currently (I believe) the mux-attributes draft as=
sumes that PTs are unique across m-lines, so this work is going to imply ch=
anges to the analysis of a number of attributes in that draft, regardless. =
 Probably a new category will need to be defined for attributes which have =
to be consistent per payload type.

On Sep 10, 2013, at 5:56 AM, Christer Holmberg > wrote:


Hi,

Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q=
7 in Berlin.

Questions:

Q1: "Can we agree that, within a BUNDLE group (including all m- lines assoc=
iated with the group), any given PT value can only be used for a single cod=
ec configuration?"
Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there are=
 opinions that simply referencing RFC 3550 might not be clear enough?"
Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in m=
ultiple RTP m- lines, for the SAME codec configuration?"

Outcome:

Q1: Yes
Q2: Yes, Lennox will send suggested text to clarify the term "codec configu=
ration".
Q7: Yes.

So, again, we need definition text for "codec configuration". Jonathan prom=
ised to submit something, but anyone is of course welcome to do that.

The other alternative is to not say anything about PT value usages within t=
he scope of BUNDLE, but that is not what the meeting wanted.

Regards,

Christer


From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 23. elokuuta 2013 13:53
To: mmusic
Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value fo=
r single codec configuration

Hi,

One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7=
 in my slides) was regarding the usage of any given PT value.

My take of the outcome was that:

-          We agreed that any given PT value can only be used for a single =
codec configuration (Q1)
-          We agreed that we need some definition text for "codec configura=
tion" (Q2)
-          We agreed that, within a BUNDLE group, any given PT value can be=
 used in multiple m- lines, as long as it is used for a single codec config=
uration (Q7).

Jonathan Lennox promised to suggest some definition text for "codec configu=
ration", so let's wait for that until we go into those discussions.

But, if you have any issues with the agreements in general, please bring th=
em up :)

Regards,

Christer




--
Jonathan Lennox
jonathan@vidyo.com


--_000_7594FB04B1934943A5C02806D1A2204B1C4BFC2DESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Bo,<=
/p>

 <=
/p>

Thanks for your input!


 <=
/p>

I’d ask anyone who =
might have an opinion about this to take a look at the proposal, comment on=
 the list if needed, and hopefully we can agree on way forward
 in Vancouver (or, even earlier :)


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>





From: Bo Burma=
n


Sent: 16. lokakuuta 2013 11:44

To: Christer Holmberg; Jonathan Lennox

Cc: mmusic

Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 <=
/p>

I agree with Jonathan tha=
t in order to make two PT values “equal”, their rtpmap and fmtp=
 lines must be equal, as a start.


 <=
/p>

I don’t think there=
 is any “correct” criterion that can be used to judge PT for eq=
uality, but we just have to decide on a “reasonable” one that i=
s as simple
 as possible without causing any major problems.


 <=
/p>

I have assumed a conceptu=
al equality criterion where PT value A should be considered equal to anothe=
r PT value B if an RTP stream with PT A can be fed into
 a decoder stack configured with PT B, and vice versa, without causing eith=
er decoder stack to “break”.


 <=
/p>

I don’t think we sh=
ould require the fmtp lines are textually equal, but only that the same par=
ameters are present and have the same values. The order of the
 parameters on the fmtp line does not matter. There is also the case when a=
 parameter is specified with the default value for one PT and omitted for t=
he other. To identify those as equal, which they semantically are, would re=
quire an “equality parser” to know
 every default value of every fmtp parameter for all codecs. This seems unr=
easonable.


 <=
/p>

Regarding Jonathan’=
s question on H.264 sprop-…, I guess they don’t strictly need t=
o be equal to make the PTs equal, but they may have to be. They effectively
 configure the decoder in some way and if there is a mismatch, the decoding=
 process will likely break; like mis-interpretations or buffer overflows. O=
n the other hand, some sprop-… can be updated by in-band information,=
 overriding what is specified on the fmtp
 line, and in this case the fmtp line sprop-… information is obsolete=
. Requiring that all fmtp of the line is equal however makes a simple rule,=
 which should be preferable and I don’t think it is too restrictive o=
r excessive.


 <=
/p>

However, if the potential=
ly equal PT values are defined as part of different media descriptions, oth=
er media level attributes also contribute to the decoder
 stack configuration. Some attributes, like maxptime, can clearly cause pro=
blems (in this case buffer overflow) if it differs. Others, like ptime, fra=
merate and imageattr are more of a receiver preference within a more formal=
 “conformance point” and would not
 “break” a decoder stack if they differ.


 <=
/p>

I agree it can be a good =
idea to add some text into the mux-attributes draft about attributes that h=
ave to be the same to consider two PT in different media
 descriptions to be “equal”, of course given that rtpmap and fm=
tp are also equal.


 <=
/p>

/Bo


 <=
/p>







From:
mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: den 11 september 2013 09:12

To: Jonathan Lennox

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 <=
/p>

It would be so easy if we=
 could define the PT mappings on the SDP session level, and then simply ref=
er to them within the m- lines :)


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>



 




My strawman proposal at the mic in Berlin was that a=
 codec configuration is defined by the top-level media type of the m=3D lin=
e and the content of a given PT value's rtpmap and fmtp lines.  I.e., =
the full media type, with all its parameters.






 






The questions I would have to this straw man are:






 






* Is this excessive?  E.g., should items like H=
.264's sprop- parameters be allowed to differ across m=3D line blocks?=







 






* Is this sufficient?  Should other items (some=
times) indexed by PT (e.g., the imageattr, rtcp-fb, or extmap attributes) n=
eed to be the same across m-lines as well?






 






My suggestion would be that this work should be fold=
ed into the work being done in draft-nandakumar-mmusic-sdp-mux-attribu=
tes (which really should be integrated with BUNDLE).  Currently (I bel=
ieve) the mux-attributes draft assumes that
 PTs are unique across m-lines, so this work is going to imply changes to t=
he analysis of a number of attributes in that draft, regardless.  Prob=
ably a new category will need to be defined for attributes which have to be=
 consistent per payload type.




 





 






 






Hi,






 






Below is the “offic=
ial” (from the minutes) outcome of questions Q1,Q2 and Q7 in Berlin.<=
/span>






 






Questions:<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif"">






 






Q1: “Can we agree t=
hat, within a BUNDLE group (including all m- lines associated with the grou=
p), any given PT value can only be used for a single codec configuration?&#=
8221;






Q2: “If Q1, do we a=
gree that we need EXPLICIT text somewhere*, as there are opinions that simp=
ly referencing RFC 3550 might not be clear enough?”






Q7: “Within a BUNDL=
E group, do we allow the usage of the same PT value in multiple RTP m- line=
s, for the SAME codec configuration?”<=
/span>






 






Outcome:






 






Q1: Yes






Q2: Yes, Lennox will send=
 suggested text to clarify the term “codec configuration”.






Q7: Yes.






 






So, again, we need defini=
tion text for “codec configuration”. Jonathan promised to submi=
t something, but anyone is of course welcome to do that.






 






The other alternative is =
to not say anything about PT value usages within the scope of BUNDLE, but t=
hat is not what the meeting wanted.





 






Regards,






 






Christer






 






 










From: mmusic-bounces@ie=
tf.org [mailto=
:mmusic-bo=
unces@ietf.org] On
 Behalf Of Christer H=
olmberg

Sent: 23. elokuuta=
 2013 13:53

To: mmusic

Subject: [MMUSIC] =
DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec con=
figuration










 






Hi,






 






One of the open issues related to BUNDL=
E presented in Berlin (Q1, Q2 and Q7 in my slides) was regarding the usage =
of any given PT value.






 






My take of the outcome was that:






 






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that
 any given PT value can only be used for a single codec configuration (Q1)<=
o:p>






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that
 we need some definition text for “codec configuration” (Q2)






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that,
 within a BUNDLE group, any given PT value can be used in multiple m- lines=
, as long as it is used for a single codec configuration (Q7).






 






Jonathan Lennox promised to suggest som=
e definition text for “codec configuration”, so let’s wai=
t for that until we go into those discussions.






 






But, if you have any issues with the ag=
reements in general, please bring them up :)






 






Regards,






 






Christer






 <=
o:p>






 <=
o:p>






 <=
o:p>








 






--






Jonathan Lennox

jonathan@vidyo.com






 








--_000_7594FB04B1934943A5C02806D1A2204B1C4BFC2DESESSMB209erics_--

From adam@nostrum.com  Thu Oct 17 08:29:21 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 68ECE11E826F for ; Thu, 17 Oct 2013 08:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.389
X-Spam-Level: 
X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZbxGp1rPGM0 for ; Thu, 17 Oct 2013 08:29:21 -0700 (PDT)
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 3711E11E8257 for ; Thu, 17 Oct 2013 08:29:16 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9HFTFjC003518 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 17 Oct 2013 10:29:15 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52600246.4000901@nostrum.com>
Date: Thu, 17 Oct 2013 10:29:10 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "mmusic@ietf.org" 
References: <525C7537.4080209@nostrum.com>
In-Reply-To: <525C7537.4080209@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 15:29:21 -0000

On 10/14/13 17:50, Adam Roach wrote:
> If time allows, I plan to release a -01 version of the document that 
> includes a set of relevant examples ahead of the draft deadline next 
> Monday...

...and, thanks to Suhas, I now have those examples in the document. The 
only changes in this version are in section 6 and later (although I do 
note that adding a second author has changed the pagination slightly):

http://www.ietf.org/id/draft-roach-mmusic-pof-pan-01.txt

/a

From adam@nostrum.com  Thu Oct 17 09:28: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 B409D11E828E for ; Thu, 17 Oct 2013 09:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.103
X-Spam-Level: 
X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uwQowbDcMBf for ; Thu, 17 Oct 2013 09:28:26 -0700 (PDT)
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 EE35F11E827C for ; Thu, 17 Oct 2013 09:28:24 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9HGSKpt010045 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 11:28:22 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5260101F.409@nostrum.com>
Date: Thu, 17 Oct 2013 11:28:15 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Paul Kyzivat , mmusic@ietf.org
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu>
In-Reply-To: <525DB14E.8060804@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 16:28:26 -0000

On 10/15/13 16:19, Paul Kyzivat wrote:
> I believe it is valid to have multiple mid lines per media section.

I don't think that's right. I'll admit that RFC5888 doesn't specifically 
talk about ordinality, but there is strong implication here that we're 
required to have a one-to-one relationship. Consider the language:

    In a given
    session description, each "m" line is identified by a token, which is
    carried in a "mid" attribute below the "m" line.

We're always talking about these things in the singular when referring 
to their use in a media section. If we need to make this constraint an 
explicit precondition for using partials, than I'm okay doing so -- but 
I don't think it's really a constraint above and beyond what's implied 
by RFC 5888 itself.

> The use of the term "remove" to describe setting the m-line port to 
> zero (many places) seems inappropriate and confusing, since the m-line 
> remains. I suggest using "deactivate" or "reject" instead.

Sure, I'm okay making that editorial change.

> Section 3.2:
>
> I don't understand the open issue. How do stream changes result in glare?

I send you a partial offer to set a sendrecv stream to sendonly at the 
same time as you send me a partial offer to change that very same stream 
to inactive.


> Then, in:
>
>    If the recipient of a partial offer that contains an existing MID has
>    also sent a partial offer to change that exact same stream, and
>    neither the received nor the sent partial offer contains an
>    "a=inactive" attribute, then a legitimate glare condition has arisen.
>
> Why is a=inactive an exception? Where are the special rules for it?

Ah, crap. I missed one. This was copied from unified plan, where I had 
conflated a=inactive (mute stream) with port=0 (remove stream). This 
should read "...contains a port of zero..."

>
>
> Section 5.2:
>
> The restriction to changing a *single* media section per partial offer 
> is intended? What is wrong with changing several media sections in the 
> same partial offer? (Other than increasing the possibility of glare.)

That's the open issue from section 3.2. I just didn't tag it as open in 
both places -- I figured pointing it out the first time we talk about 
the issue would be enough.

And, yes, it's all about glare. After all, the entire raison d'etre for 
this mechanism is glare minimization.

> I'm bothered by the use of random values for the new mid values. (I 
> just hate *depending* on two random values being different.) Instead, 
> how about specifying that each end use a unique prefix. We can find 
> some method to select the prefix. E.g., userid + sessionid from the 
> o-line. (Forbid use of partial offers if those aren't unique.)

Sure, we can consider alternate proposals for this. I'll point out that 
you're more likely to have a collision between {userid,sessionid} of two 
clients than you will from 202 bits of randomness (which is what is 
currently proposed). Consider that sessionid is (supposed to be) derived 
from a notion of the current time, so the chances of colliding are 
exceedingly high. Similarly, the userid for SDP is frequently a fixed 
string rather than some variable string.

Your misgivings aside, I'm pretty much in the camp that believes that 
math works, even the statistics and probability parts of it.

I'd be more interested in entering into a conversation about how many 
bits of randomness are acceptable. I'm pretty sure 202 is massive 
overkill. Version 4 UUIDs, for contrast, use 122 bits of randomness, 
which we would get with 20-character SDP tokens. Given their limited 
scope (just one session), we could probably get away with far less than 
this.

> Section 5.3:
>
> I think you need to s/less than/less than or equal to/ in:
>
>    The agent then examines the o= line in the received partial offer.
>    If the  value is less than the most recently
>    received full (non-partial) offer or answer, then the partial offer
>    is stale and MUST be rejected.

Sure. "Equal to" would only arise from a misimplemented peer, but I'm 
happy to just call it stale.

> Section 5.4:
>
> The following:
>
>    When a partial answer is received, the offerer matches each media
>    section in the partial answer to its corresponding media section
>    according to its MID.
>
> doesn't specify the source of the media sections to match against. I 
> think you mean "to its corresponding media section in the partial offer".

Yep, that was the intention. I'll make this clearer.

> Section 5.5:
>
> The following:
>
>    Whenever a partial offer or partial answer is processed, the agent
>    performs the following steps to ensure that a common view of session
>    state is maintained:
>
> doesn't say *when* this will be done. IIUC this is to be done by the 
> offerer upon successful receipt of the partial answer, and by the 
> answerer upon the sending of the partial answer. Right?

Right; in both cases, after all other processing described in this 
document has taken place.

> Steps 3 & 4:
>
> Deciding *when* to do this is tricky. I don't know exactly what you 
> have in mind. I do have an idea for a simpler way:
>
> For all partial updates following a particular O/A, order *all* the 
> added media sections by their mid value. A new O/A then freezes those 
> and starts over.

That occurred to me, mostly because it allows for multiple partial 
offers to be in flight simultaneously in the same direction.

What concerned me was the difficulty in dealing with such freezes 
between sending a full offer and receiving its corresponding full 
answer, since any glare that arises from that exchange requires 
unfreezing the lines, but only back to the point that was created after 
the (now second-) most recent offer/answer exchange.

I also didn't like the way it interacted internally with our own 
implementation, since we would have a pretty hard time re-ordering 
streams after we brought them up and running. It's not too painful to do 
this upon processing of an answer (particularly because we've already 
seen the other side's offer, and know where each line is going to end up).

It's not impossible to fix, but it sure would be more complicated and 
bug-prone. I don't expect we're the only ones who would run into 
difficulty in this arena, especially since I know we share this part of 
our code with a major hardware vendor who is active in the WebRTC space.

/a

From christer.holmberg@ericsson.com  Thu Oct 17 10:39: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 2FEBA11E8146 for ; Thu, 17 Oct 2013 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.405
X-Spam-Level: 
X-Spam-Status: No, score=-5.405 tagged_above=-999 required=5 tests=[AWL=0.244,  BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqj0MMygXTc8 for ; Thu, 17 Oct 2013 10:39:35 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 226B311E80DE for ; Thu, 17 Oct 2013 10:39:32 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-8b-526020d37f38
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7C.B6.03802.4D020625; Thu, 17 Oct 2013 19:39:32 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 19:39:32 +0200
From: Christer Holmberg 
To: Adam Roach , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft
Thread-Index: AQHOyS/VDi7jGJKfu0+LtCEoj80NX5n2JHkAgALTYoCAAC6v8A==
Date: Thu, 17 Oct 2013 17:39:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C1282@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu> <5260101F.409@nostrum.com>
In-Reply-To: <5260101F.409@nostrum.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje4VhYQgg0XneC32/F3EbjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgynj++RRLwTnRipXfp7E1 MDYKdjFycEgImEh0vwjoYuQEMsUkLtxbz9bFyMUhJHCYUaJh3jt2CGcJo8TnxV+ZQBrYBCwk uv9pgzSICORJ/PiwnQXEFgYKfz3ymQkibikx6c0cdpByEQEniY6fSiAmi4CqxOmz6iAVvAK+ EluerGMEsYUE0iWe7ZrFBmJzCqhL7L5wDSzOCHTO91NrwCYyC4hLfDh4nRniTAGJJXvOQ9mi Ei8f/2OFsJUk1h6GuIZZQEdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaS lgWMLKsY2XMTM3PSy402MQIj4+CW36o7GO+cEznEKM3BoiTO++GtcxDQN4klqdmpqQWpRfFF pTmpxYcYmTg4pRoYDY97HAuSdZ7LyyCzWJFtZ4FjedFmZYmPH9jZPmZ0H/g1If5bg4/2Qh0O jtkd2ysMDr6vlNSu7vsjdp+tTFRwTbnn0RVz1AsWzMxQ105LP/646LU+UzLjQce7J8vNHH57 KNQW8C49dHdphe0SBvVHp99r3fqzcuGpybtf71+t6dqyTSvz3IWzSizFGYmGWsxFxYkAloIF 7loCAAA=
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 17:39:41 -0000

Hi,

>> I believe it is valid to have multiple mid lines per media section.
>
> I don't think that's right. I'll admit that RFC5888 doesn't specifically =
talk about ordinality, but there is strong implication here that we're requ=
ired to have a one-to-one relationship. Consider the language:
>
>    In a given
>    session description, each "m" line is identified by a token, which is
>    carried in a "mid" attribute below the "m" line.
>
> We're always talking about these things in the singular when referring to=
 their use in a media section. If we need to make this constraint an explic=
it precondition for using partials, than I'm okay doing so -- but I don't t=
hink it's really a constraint above and beyond what's implied by RFC 5888 i=
tself.

Is it allowed to have multiple instances of ANY attribute (in case of a=3Df=
mtp, for any given PT value) for any given m- line?

>> The use of the term "remove" to describe setting the m-line port to=20
>> zero (many places) seems inappropriate and confusing, since the m-line=20
>> remains. I suggest using "deactivate" or "reject" instead.
>
> Sure, I'm okay making that editorial change.

I suggest using "disable", in order to be aligned with BUNDLE (or, we'll ch=
ange the terminology in BUNDLE).


>> Section 5.2:
>>
>> The restriction to changing a *single* media section per partial offer=20
>> is intended? What is wrong with changing several media sections in the=20
>> same partial offer? (Other than increasing the possibility of glare.)
>
> That's the open issue from section 3.2. I just didn't tag it as open in=20
> both places -- I figured pointing it out the first time we talk about=20
> the issue would be enough.
>
> And, yes, it's all about glare. After all, the entire raison d'etre for=20
> this mechanism is glare minimization.

Some time ago, I raised a question related to this, whether it would be all=
owed to send a POF including ALL m- lines of the session (in other words: s=
ending a POF which is identical to a full Offer).

(Of course, that would defeat the whole purpose of POF/PAN.)

>> Section 5.3:
>>
>> I think you need to s/less than/less than or equal to/ in:
>>
>>    The agent then examines the o=3D line in the received partial offer.
>>    If the  value is less than the most recently
>>    received full (non-partial) offer or answer, then the partial offer
>>    is stale and MUST be rejected.
>
> Sure. "Equal to" would only arise from a misimplemented peer, but I'm=20
> happy to just call it stale.

I don't think one should reject an equal value.=20

WHY one would send a POF with an equal sess-version, I don't know, but perh=
aps for "auditing"...

Regards,

Christer

From pkyzivat@alum.mit.edu  Thu Oct 17 10:48: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 6253611E8118 for ; Thu, 17 Oct 2013 10:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.278
X-Spam-Level: 
X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxPrY5jRPupO for ; Thu, 17 Oct 2013 10:48:20 -0700 (PDT)
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 E5FF011E81A2 for ; Thu, 17 Oct 2013 10:48:16 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id eHJn1m0041ap0As5CHoGyS; Thu, 17 Oct 2013 17:48:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id eHoG1m0073ZTu2S3iHoGmw; Thu, 17 Oct 2013 17:48:16 +0000
Message-ID: <526022DF.6070003@alum.mit.edu>
Date: Thu, 17 Oct 2013 13:48:15 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Adam Roach 
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu> <5260101F.409@nostrum.com>
In-Reply-To: <5260101F.409@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382032096; bh=J5kxQcT87cG653Q9HYe2uy3RBuvpfEwZDLCAV3mLipk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oT/voUYqjhGtdNLBW6FqtxtorfnfTgiBZ2g+HKJCa1yWbGxOwdyyocCnXoygOiVrn hEo6StoKMFYqUp5fzUDeoI9lcXgeIQxcJy+NqcC3EOK/pm6UOffY7Rc3Qa7LaJyphy RxnJ2ew3dII/n5sIf8FZcyi958Gw+coP80EgNwcMR4cjU5xRZQjTUaIc4RK5i4fNdJ 8OKA9seo/nh2YTsbIG7HCIGEWeZVgK1duKo5eeqEHyZ0YA0Kmi2rSQ9cS2wP1atBUP sj2mr9AIA8uT38McIB1yELm8VTbm+fVx3+GNnf6CpkmhzALpMyAyw4TIM+V0+5flX/ 1uxVN3CGeWJ8w==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 17:48:26 -0000

On 10/17/13 12:28 PM, Adam Roach wrote:
> On 10/15/13 16:19, Paul Kyzivat wrote:
>> I believe it is valid to have multiple mid lines per media section.
>
> I don't think that's right. I'll admit that RFC5888 doesn't specifically
> talk about ordinality, but there is strong implication here that we're
> required to have a one-to-one relationship. Consider the language:
>
>     In a given
>     session description, each "m" line is identified by a token, which is
>     carried in a "mid" attribute below the "m" line.
>
> We're always talking about these things in the singular when referring
> to their use in a media section. If we need to make this constraint an
> explicit precondition for using partials, than I'm okay doing so -- but
> I don't think it's really a constraint above and beyond what's implied
> by RFC 5888 itself.

My thinking was that when grouping is being used for multiple purposes, 
each might use its own mid values.

The requirement that to use grouping at all every m-line must have a mid 
decreases the motivation to do that. And certainly a single mid is 
*sufficient*. But its hard to contemplate what all possible 
implementations might do.

Rather than *assuming* 5888 forbids multiple mids, or updating to to 
make that explicit, I think its easier to just say that you can't use 
partials if there are multiple mids for any m-line.

Even then, I don't think that 5888 requires that the mids in a 2nd offer 
must be the same, or in the same order, as in the prior offer. I don't 
think you depend on that, but it is worth keeping in mind.

>> Section 3.2:
>>
>> I don't understand the open issue. How do stream changes result in glare?
>
> I send you a partial offer to set a sendrecv stream to sendonly at the
> same time as you send me a partial offer to change that very same stream
> to inactive.

OK.

>> Section 5.2:
>>
>> The restriction to changing a *single* media section per partial offer
>> is intended? What is wrong with changing several media sections in the
>> same partial offer? (Other than increasing the possibility of glare.)
>
> That's the open issue from section 3.2. I just didn't tag it as open in
> both places -- I figured pointing it out the first time we talk about
> the issue would be enough.
>
> And, yes, it's all about glare. After all, the entire raison d'etre for
> this mechanism is glare minimization.

I guess this is just a question of whether you want to protect people 
from themselves, or give them enough rope to do good and bad things.

If multiple changes were *permitted*, then an application that wants to 
minimize the glare can restrict itself to one change per pof. Some other 
application, that has special knowledge about the usage may know that 
certain combinations of changes have low probability of glaring.

>> I'm bothered by the use of random values for the new mid values. (I
>> just hate *depending* on two random values being different.) Instead,
>> how about specifying that each end use a unique prefix. We can find
>> some method to select the prefix. E.g., userid + sessionid from the
>> o-line. (Forbid use of partial offers if those aren't unique.)
>
> Sure, we can consider alternate proposals for this. I'll point out that
> you're more likely to have a collision between {userid,sessionid} of two
> clients than you will from 202 bits of randomness (which is what is
> currently proposed). Consider that sessionid is (supposed to be) derived
> from a notion of the current time, so the chances of colliding are
> exceedingly high. Similarly, the userid for SDP is frequently a fixed
> string rather than some variable string.

Obviously some other value could be used. All we need is a unique 
designator for each end within the single session. Then all the mids can 
be derived from that. Each one doesn't need to be random.

For instance, we could call the offering end of the most recent O/A "O" 
and the answerer for that "A". And then each side could use that as a 
prefix for all new mids assigned by POFs from that side.

> Your misgivings aside, I'm pretty much in the camp that believes that
> math works, even the statistics and probability parts of it.

And I'm in the camp that never gambles.

Statistics says that even exceedingly low probability events *can* 
happen. Its ok to count on low probability events not happening if you 
are willing to accept the consequences when they do happen. Even if that 
is only expected to happen once in a trillion years, that doesn't mean 
you have to wait a trillion years for it to happen. It could be tomorrow.

> I'd be more interested in entering into a conversation about how many
> bits of randomness are acceptable. I'm pretty sure 202 is massive
> overkill. Version 4 UUIDs, for contrast, use 122 bits of randomness,
> which we would get with 20-character SDP tokens. Given their limited
> scope (just one session), we could probably get away with far less than
> this.
>
>> Section 5.3:
>>
>> I think you need to s/less than/less than or equal to/ in:
>>
>>    The agent then examines the o= line in the received partial offer.
>>    If the  value is less than the most recently
>>    received full (non-partial) offer or answer, then the partial offer
>>    is stale and MUST be rejected.
>
> Sure. "Equal to" would only arise from a misimplemented peer, but I'm
> happy to just call it stale.

Oh. Duh. You are right. Leave as it is.

>> Steps 3 & 4:
>>
>> Deciding *when* to do this is tricky. I don't know exactly what you
>> have in mind. I do have an idea for a simpler way:
>>
>> For all partial updates following a particular O/A, order *all* the
>> added media sections by their mid value. A new O/A then freezes those
>> and starts over.
>
> That occurred to me, mostly because it allows for multiple partial
> offers to be in flight simultaneously in the same direction.
>
> What concerned me was the difficulty in dealing with such freezes
> between sending a full offer and receiving its corresponding full
> answer, since any glare that arises from that exchange requires
> unfreezing the lines, but only back to the point that was created after
> the (now second-) most recent offer/answer exchange.

I don't see the problem. After sending a full offer everything *is* 
frozen until the the answer is accepted or rejected. That's true without 
POF/PAN.

Or do you mean that you are accepting and queuing *pending* partial 
updates while waiting for the answer? But that doesn't seem like an 
issue either. Just defer assigning the mids until the POF is to be sent.

> I also didn't like the way it interacted internally with our own
> implementation, since we would have a pretty hard time re-ordering
> streams after we brought them up and running. It's not too painful to do
> this upon processing of an answer (particularly because we've already
> seen the other side's offer, and know where each line is going to end up).
>
> It's not impossible to fix, but it sure would be more complicated and
> bug-prone. I don't expect we're the only ones who would run into
> difficulty in this arena, especially since I know we share this part of
> our code with a major hardware vendor who is active in the WebRTC space.

I won't argue with this. But it does need to be traded off against the 
issue in the note. That seems to have similar problems.

	Thanks,
	Paul


From pkyzivat@alum.mit.edu  Thu Oct 17 10:58: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 91AF311E82C9 for ; Thu, 17 Oct 2013 10:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level: 
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=-0.145,  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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPgvAmRR7sDk for ; Thu, 17 Oct 2013 10:58:41 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id A597B11E80DE for ; Thu, 17 Oct 2013 10:58:37 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id eDRd1m0031ei1Bg51HydhK; Thu, 17 Oct 2013 17:58:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id eHyc1m00t3ZTu2S3kHydcB; Thu, 17 Oct 2013 17:58:37 +0000
Message-ID: <5260254C.90504@alum.mit.edu>
Date: Thu, 17 Oct 2013 13:58:36 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Christer Holmberg 
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu> <5260101F.409@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C1282@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C1282@ESESSMB209.ericsson.se>
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=1382032717; bh=KjqptYNe9kf6wPwsNPItc2q0FhhukfrtY6+KHwOx/wE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CfXRDW7YTHv9FeejxN3y2XeM6aOwHtMMjfxGdSfPCtHTaCRnwMRqzWo0W/7afczkh 7qeRZSbS844N5Qf9O6/OMJbNsq8c5tL8dUJi40aJZU5zBRRxByNrMG5UfQEGCLAeye jXJtyCZmMNjexdP2PobQzJqCfceqSD7jd111pNhb4Ga1LazpeCQjH+1DQneU6QPlBz vQ80Fsm9k3fET89T794HUr6ADM2esbujiEMGhtQiTdPo56bSOKnwSwyxbrps1XPe22 sK2ROYvX7gTptxzRkPv3kWX9wtjtx5ellzyK220/yntNefDCLeu3SsaBanJ2mtdNLq FLYr6MFcxt7hw==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 17:58:47 -0000

On 10/17/13 1:39 PM, Christer Holmberg wrote:

> Is it allowed to have multiple instances of ANY attribute (in case of a=fmtp, for any given PT value) for any given m- line?

Sure. Some examples:

- label
- candidate
- ssrc

	Thanks,
	Paul

From adam@nostrum.com  Thu Oct 17 11:28: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 CC1D811E813F for ; Thu, 17 Oct 2013 11:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.397
X-Spam-Level: 
X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OawtBrnIwYzQ for ; Thu, 17 Oct 2013 11:28:44 -0700 (PDT)
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 C54D711E81A2 for ; Thu, 17 Oct 2013 11:28:43 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9HISaI4023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 13:28:37 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52602C4F.2070809@nostrum.com>
Date: Thu, 17 Oct 2013 13:28:31 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Paul Kyzivat 
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu> <5260101F.409@nostrum.com> <526022DF.6070003@alum.mit.edu>
In-Reply-To: <526022DF.6070003@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 18:28:44 -0000

On 10/17/13 12:48, Paul Kyzivat wrote:
> My thinking was that when grouping is being used for multiple 
> purposes, each might use its own mid values. 

Again, that's not really supported by any of the text in RFC5888.

/a

From christer.holmberg@ericsson.com  Thu Oct 17 11:36: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 9122A11E82AA for ; Thu, 17 Oct 2013 11:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.712
X-Spam-Level: 
X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=0.537,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NRRnTDAv6-I for ; Thu, 17 Oct 2013 11:36:46 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4071A11E82D0 for ; Thu, 17 Oct 2013 11:36:39 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-2f-52602e3279fd
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A9.AA.03802.23E20625; Thu, 17 Oct 2013 20:36:34 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 20:36:34 +0200
From: Christer Holmberg 
To: Adam Roach , Paul Kyzivat 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft
Thread-Index: AQHOyS/VDi7jGJKfu0+LtCEoj80NX5n2JHkAgALTYoCAABZagIAAC0CAgAAjJfA=
Date: Thu, 17 Oct 2013 18:36:33 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C138D@ESESSMB209.ericsson.se>
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu> <5260101F.409@nostrum.com> <526022DF.6070003@alum.mit.edu> <52602C4F.2070809@nostrum.com>
In-Reply-To: <52602C4F.2070809@nostrum.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvja6RXkKQweEtyhZ7/i5it5i6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZazYF1Bwkali64KlrA2M /xm7GDk5JARMJBqvdjJB2GISF+6tZ+ti5OIQEjjMKLFmbRcThLOEUeLI5MesXYwcHGwCFhLd /7RBGkQE3CVOPbjMDBJmFlCXuLo4CCQsDFTx9chnJogSS4lJb+awQ9h+EicXrGQFsVkEVCVW TPjFDGLzCvhKTHv+hA3EFhJYwSjx/bkpiM0poC3Re3QbWD0j0G3fT60Bm8ksIC7x4eB1Zoib BSSW7DkPZYtKvHz8jxXCVpJYe3g7C0S9jsSC3Z/YIGxtiWULX0PtFZQ4OfMJywRGsVlIxs5C 0jILScssJC0LGFlWMbLnJmbmpJcbbWIExszBLb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYyaNpr67ccSJXdmeAcdyDxt3jOxiJfl9C6PlGsxP7cdYHN9 laBts+aTvv/+yUsnLj79onnazjmXTpp+eFo2/Z29+cclR4Tb51+MkT8cevSwQvhCp7U+N5JW CnyezpTaNq9U4e2sjbySXnU3GztTuQ8Jh73lbPfktvk5/6HllaSkrOT766Kk9xorsRRnJBpq MRcVJwIAeBoO42cCAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 18:36:52 -0000

Hi,

> My thinking was that when grouping is being used for multiple=20
> purposes, each might use its own mid values.

Why would that be needed? A mid is only a reference, and I see no reason wh=
y you couldn't use the same value in multiple groups - as long as the value=
 refers to the same m- line.

Regards,

Christer


From pkyzivat@alum.mit.edu  Thu Oct 17 12:01:24 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 8141111E832E for ; Thu, 17 Oct 2013 12:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.279
X-Spam-Level: 
X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=0.158,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBKBN6HVvN7T for ; Thu, 17 Oct 2013 12:01:15 -0700 (PDT)
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 E4D3F11E82F8 for ; Thu, 17 Oct 2013 12:00:59 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id eBcF1m0050EZKEL5FK0xt0; Thu, 17 Oct 2013 19:00:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id eK0x1m00L3ZTu2S3MK0xX0; Thu, 17 Oct 2013 19:00:57 +0000
Message-ID: <526033E9.7010006@alum.mit.edu>
Date: Thu, 17 Oct 2013 15:00:57 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Adam Roach 
References: <525C7537.4080209@nostrum.com> <525DB14E.8060804@alum.mit.edu> <5260101F.409@nostrum.com> <526022DF.6070003@alum.mit.edu> <52602C4F.2070809@nostrum.com>
In-Reply-To: <52602C4F.2070809@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382036457; bh=n/N5L5aA+VTVP017ebnhMTVW5ykBfDxaXoghfrr3ZGs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Lmmm+rXvfnZi2RU5lNiN4f+k9m3cxWbKIOFKyo2u0jBN87e84xsepw6LoKLR8DqcX 9+ERMMr7fTK0ah2cS6ablFa1f4Y6gc1rerkrgmQPx8TliTX+oTWQMadZdnYIBRmcDo 88PAVbQMvENLozJVsE4SuCCvb4cC3OV8BxkjJhE2t3HlN7mb/yneIUqNJXDgwtVBZz 3ErndWnnU1V5vj1HnDvug7TGqsaih7k4lfXtZ1Bipj7A8+deAGF4cPlT/uSzUm2iDE EqI3fAMbiLpm+35EIS0fpww4I9lsVYPkJkLw0IXoLnbg4erfMmdIKLrUXkJhC4dc93 94odrVNXGS8rg==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer 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: Thu, 17 Oct 2013 19:01:24 -0000

On 10/17/13 2:28 PM, Adam Roach wrote:
> On 10/17/13 12:48, Paul Kyzivat wrote:
>> My thinking was that when grouping is being used for multiple
>> purposes, each might use its own mid values.
>
> Again, that's not really supported by any of the text in RFC5888.

True. But it also doesn't forbid it.

Its pretty clear that it didn't consider the possibility of multiple mid 
lines per m-line.

I won't belabor the point.

	Thanks,
	Paul


From finlayson@live555.com  Thu Oct 17 13:59: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 5429D11E82A4 for ; Thu, 17 Oct 2013 13:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FnGSGLYpHMY for ; Thu, 17 Oct 2013 13:59:34 -0700 (PDT)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id D939B11E813A for ; Thu, 17 Oct 2013 13:57:39 -0700 (PDT)
Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r9HKvdjs034972 for ; Thu, 17 Oct 2013 13:57:39 -0700 (PDT) (envelope-from finlayson@live555.com)
From: Ross Finlayson 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E12BAE3-C323-4D20-A663-DEA369393C86@live555.com>
Date: Thu, 17 Oct 2013 13:57:39 -0700
To: mmusic@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [MMUSIC] draft-finlayson-rtsp-register-command-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 Oct 2013 20:59:42 -0000

I've just submitted a personal Internet-Draft =
"draft-finlayson-rtsp-register-command-00" that defines an optional new =
RTSP command "REGISTER".  This command - which has been implemented and =
found to be useful (especially for RTSP proxy servers) - replaces (and =
improves upon) functionality that had previously been implemented using =
the "ANNOUNCE" command (a command which no longer exists in RTSP 2.0).

This is somewhat esoteric, but should there be sufficient interest, I =
can imagine it conceivably becoming a MMUSIC work item.  In any case, =
I'll be in Vancouver if anyone wishes to discuss it.

	Ross.


From ietf-secretariat-reply@ietf.org  Fri Oct 18 04:02: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 3148D21F9D50 for ; Fri, 18 Oct 2013 04:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level: 
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJLuAFo3BxVJ for ; Fri, 18 Oct 2013 04:02:44 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1711E81B1 for ; Fri, 18 Oct 2013 04:02:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131018110244.2331.47683.idtracker@ietfa.amsl.com>
Date: Fri, 18 Oct 2013 04:02:44 -0700
From: IETF Secretariat 
Subject: [MMUSIC] Milestones changed for mmusic WG
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 11:02:45 -0000

Changed milestone "Submit SDP extensions for duplicated streams as
Proposed Standard", resolved as "Done", added
draft-ietf-mmusic-duplication-grouping,
draft-ietf-mmusic-delayed-duplication to milestone.

Changed milestone "Submit RTSP NAT considerations draft as a Proposed
Standard", set due date to October 2013 from July 2013, added
draft-ietf-mmusic-rtsp-nat-evaluation, draft-ietf-mmusic-rtsp-nat to
milestone.

Changed milestone "Submit SDP considerations for G.723 Annex A and
G.729 Annex B as Proposed Standard", set due date to October 2013 from
July 2013, added draft-ietf-mmusic-sdp-g723-g729 to milestone.

Deleted milestone "Submit Considerations for using SDP offer/answer
with middleboxes for Informational".

Changed milestone "Submit a document describing current practices in
hosted NAT traversal as Informational", set due date to November 2013
from July 2013, added draft-ietf-mmusic-latching to milestone.

Changed milestone "Submit SCTP-Based Media Transport in SDP as
Proposed Standard.", set due date to December 2013 from November 2013,
added draft-ietf-mmusic-sctp-sdp to milestone.

Changed milestone "Submit SDP extensions to classify traffic as
Proposed Standard", set due date to March 2014 from September 2013,
added draft-ietf-mmusic-traffic-class-for-sdp to milestone.

Changed milestone "Submit SDP extensions to negotiate multiplexed
media streams as Proposed Standard", set due date to April 2014 from
September 2013, added draft-ietf-mmusic-sdp-bundle-negotiation to
milestone.

Changed milestone "Submit Trickle ICE as Proposed Standard", set due
date to April 2014 from December 2013, added
draft-ietf-mmusic-trickle-ice to milestone.

Changed milestone "Submit SIP usage for Trickle ICE as Proposed
Standard", set due date to April 2014 from March 2014.

Changed milestone "Submit SDP extension for cross session stream
identification as Proposed Standard", set due date to May 2014 from
December 2013, added draft-ietf-mmusic-msid to milestone.

Changed milestone "Submit a revision of ICE (RFC 5245) as Proposed
Standard", set due date to May 2014 from January 2014, added
draft-ietf-mmusic-ice-sip-sdp, draft-ietf-mmusic-rfc5245bis to
milestone.

Changed milestone "Submit revised SDP specification to IETF as
Proposed Standard", set due date to June 2014 from November 2013,
added draft-ietf-mmusic-rfc4566bis to milestone.

URL: http://datatracker.ietf.org/wg/mmusic/charter/

From ietf-secretariat-reply@ietf.org  Fri Oct 18 04:20: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 695B711E81F9 for ; Fri, 18 Oct 2013 04:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level: 
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm1AB6F-ILWp for ; Fri, 18 Oct 2013 04:20:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC59611E81D5 for ; Fri, 18 Oct 2013 04:20:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131018112036.2313.24771.idtracker@ietfa.amsl.com>
Date: Fri, 18 Oct 2013 04:20:36 -0700
From: IETF Secretariat 
Subject: [MMUSIC] Milestones changed for mmusic WG
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 11:20:37 -0000

Changed milestone "Submit UDPTL over DTLS as Proposed Standard", set
state to active from review, accepting new milestone.

URL: http://datatracker.ietf.org/wg/mmusic/charter/

From ari.keranen@ericsson.com  Fri Oct 18 07:34: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 00C0611E81CD for ; Fri, 18 Oct 2013 07:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.962
X-Spam-Level: 
X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsW30mq6eCYJ for ; Fri, 18 Oct 2013 07:34:30 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 196BC11E81F3 for ; Fri, 18 Oct 2013 07:34:29 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-3e-526146f4710e
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0E.75.03802.4F641625; Fri, 18 Oct 2013 16:34:29 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Fri, 18 Oct 2013 16:34:28 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id BD6531103CA; Fri, 18 Oct 2013 17:34:28 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5D7474EA13; Fri, 18 Oct 2013 17:34:28 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 165EA4EA12; Fri, 18 Oct 2013 17:34:28 +0300 (EEST)
Message-ID: <526146F2.1060203@ericsson.com>
Date: Fri, 18 Oct 2013 17:34:26 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RverW2KQwcRuXov3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZUxfe4at4C1bxdI9b1gbGE+wdjFyckgImEis OnOWHcIWk7hwbz1bFyMXh5DAYUaJxm3HmUESQgIbGCUWfZSBSOxllJg65Qc7RGIdo8ScqW4Q 9gpGiX/79UFsXgFtiWsv14A1swioSpzYcxbMZhOwl7g54TpYr6hAssSju6fYIOoFJU7OfMIC YosIyEjs3bQZqJ6DQ1ggW+L+wSyQMLOArcSFOddZIGx5ie1v5zBDHK0mcfXcJqg7VSWu/nvF OIFRaBaSqbOQtM9C0r6AkXkVI3tuYmZOernRJkZgoB7c8lt1B+OdcyKHGKU5WJTEeT+8dQ4S EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDh/cVSiz/J5LazHGwP6FundfvI3UrywfN6yS7vr FBdO2hYQcDrwbr3c+fOPFa6f79yew8vlc2p6/Ywba2JlM8tWiLdY3M/9qZL0VCDz01KuTpn6 va1pd4KuOj4+3vtt9zuWqncvXkR+n2YvXBJQ13b2f6nTJd+nH47vNJpxQ+lDoQ7PJ/X9d3Yp sRRnJBpqMRcVJwIADTTVUSICAAA=
Subject: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 14:34:37 -0000

Hi all,

When single 5-tuple is used for media associated with multiple SDP media 
descriptions (i.e., Bundle) the WG has identified the need to analyze 
and specify applicability and impact of different attributes on media 
description bundling.

The draft-nandakumar-mmusic-sdp-mux-attributes-04 ("Framework for SDP 
Attributes when Multiplexing") provides this analysis. The draft has 
been presented and discussed over the past few meetings and the feedback 
on both the need for the work and the draft itself has been positive.

Based on the above, we would like to propose adding a new milestone for
and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as a WG 
item for that milestone.

If you have any comments or concerns with the above, please let us know 
no later than November 1st, 2013.


Thanks,
Ari & Flemming
(MMUSIC co-chairs)

From ari.keranen@ericsson.com  Fri Oct 18 07:38: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 CEF6311E819D for ; Fri, 18 Oct 2013 07:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.962
X-Spam-Level: 
X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8yu9Fehb3Dj for ; Fri, 18 Oct 2013 07:38:00 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B961011E81C8 for ; Fri, 18 Oct 2013 07:37:59 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-9d-526147c6eabf
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FA.4F.16099.6C741625; Fri, 18 Oct 2013 16:37:58 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Fri, 18 Oct 2013 16:37:58 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id EF65D1103CA for ; Fri, 18 Oct 2013 17:37:57 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 954C94EA13	for ; Fri, 18 Oct 2013 17:37:57 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 594974EA12	for ; Fri, 18 Oct 2013 17:37:57 +0300 (EEST)
Message-ID: <526147C3.9040204@ericsson.com>
Date: Fri, 18 Oct 2013 17:37:55 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3RveYe2KQQdsdNYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY/X/hILJnBVn+0+zNDDuYu9i5OSQEDCR+PFoEjOELSZx4d56 ti5GLg4hgcOMEu8ntTNDOBsYJabffcYO4VxmlFh1dgFYi5DAEUaJJUssIRL7GCVu3znKApLg FdCW+LV5AZjNIqAqMa9hEyOIzSZgL3FzwnWw3aICyRKP7p5ig6gXlDg58wlYvYiAjMTeTZuB FnBwCAsYSxxaqgcSZhawlbgw5zoLhC0vsf3tHKiz1SSuntsEdY+qxNV/rxgnMArNQjJ1FpL2 WUjaFzAyr2Jkz03MzEkvN9zECAzMg1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYYzTEZRLm/43qaTg1627zyeDfim+XBE04bKNersd///vEN2+zH7DX Zzo+yheWbvb8JBOwfFXP8ykbwusX6xazHv/ir+G3YDHro2S54/nvWARvMZyax9mvOfd8u//V 9z1Wu52tZ4sqB3e915x0/PwKtj8nt1k/FuQx/hq0KTX+0hnrOpa3D2UnKLEUZyQaajEXFScC AAB0mIEaAgAA
Subject: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 14:38:05 -0000

Hi all,

Trying to close the open issue on the pacing of ICE connectivity checks, 
we still need to come up with the "new conservative default value" for 
the minimum pacing time with non-RTP traffic.

When this was discussed at the Orlando meeting, I proposed 100 ms (see 
[1] and [2]) but during the meeting there was a question that why could 
not we make this even smaller (e.g., 20 ms).

If we think about the worst case scenario with maximum length username 
fragment (256 bytes), that results in maximum size ICE connectivity 
check packets of about 330 bytes. Add a few extensions, rounding it up 
to 350 bytes, we're still at 35 ms "safe" pacing interval if we follow 
the rationale proposed by Cullen in [1] (i.e., similar bandwidth 
requirement as with G.711).

So, to be "conservative enough", how about 50 ms RECOMMENDED pacing 
value if there's no better knowledge of the network? And if there is, 
scale accordingly, but not below 20ms.


Cheers,
Ari

[1] http://www.ietf.org/mail-archive/web/mmusic/current/msg10448.html
[2] 
http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic#_Interactive_Connectivity_Establishment

From emcho@sip-communicator.org  Fri Oct 18 07:44: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 9209B11E819D for ; Fri, 18 Oct 2013 07:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHOMJQ-vgFwP for ; Fri, 18 Oct 2013 07:44:55 -0700 (PDT)
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 509C111E82C4 for ; Fri, 18 Oct 2013 07:44:52 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id y10so1691908pdj.10 for ; Fri, 18 Oct 2013 07:44:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Xgb+eTDiAFCeJelZe3QUtBkKn8stbnb0Ic9F7hoCFMk=; b=bTNxjCWESn+VpFZSfjk0YHBduvYJkGFVSRH/XY05wbZK6fu/c0DBAxU0aNJWZp+4c+ p1ATklmuMIJBQjy9ezweanumbPB4htAuKcVJwPyD8qt34bmk7rzvqoRRKuzhpuaycisp jTR2mgsn/ij4Ro3MvAcAJ/om6OjsVcBPGWeXOUhYYcyglWZBQPbsz0RvwFYt6nS5eGA7 RwrVUu7K9Zi8NNTQjKbvz2qiC4Y7GGDIFMTgwAQZ/x+YwhEP4GOl9xXBlQHNw8TQJJuD DOfatXIJEjpBiWs4IIwcvKaA0XnjBvDQJFrJu8v/UrdI5e501gYkjZJwfatZiZqgc4Mt 6kFQ==
X-Gm-Message-State: ALoCoQlxdQN/9wFA08OAUtsVJ8Akqh/UJgHUj0R4ye4s5sgamWPEgyWPAJX5waEY381hhgVZhhIJ
X-Received: by 10.68.253.1 with SMTP id zw1mr3496475pbc.30.1382107491925; Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [2607:f8b0:400e:c03::230]) by mx.google.com with ESMTPSA id fk4sm4844708pab.23.2013.10.18.07.44.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id bj1so4604317pad.7 for ; Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
X-Received: by 10.67.11.103 with SMTP id eh7mr3838142pad.153.1382107491412; Fri, 18 Oct 2013 07:44:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Fri, 18 Oct 2013 07:44:31 -0700 (PDT)
In-Reply-To: <526147C3.9040204@ericsson.com>
References: <526147C3.9040204@ericsson.com>
From: Emil Ivov 
Date: Fri, 18 Oct 2013 09:44:31 -0500
Message-ID: 
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 14:44:59 -0000

It might be worth reminding exactly what these 50ms would be
protecting us against, and why is it that we don't need to be
protected against it in the case of RTP where 20ms is accepted as a
fine default value.

Emil

--sent from my mobile

On Fri, Oct 18, 2013 at 9:37 AM, Ari Ker=E4nen  w=
rote:
> Hi all,
>
> Trying to close the open issue on the pacing of ICE connectivity checks, =
we
> still need to come up with the "new conservative default value" for the
> minimum pacing time with non-RTP traffic.
>
> When this was discussed at the Orlando meeting, I proposed 100 ms (see [1=
]
> and [2]) but during the meeting there was a question that why could not w=
e
> make this even smaller (e.g., 20 ms).
>
> If we think about the worst case scenario with maximum length username
> fragment (256 bytes), that results in maximum size ICE connectivity check
> packets of about 330 bytes. Add a few extensions, rounding it up to 350
> bytes, we're still at 35 ms "safe" pacing interval if we follow the
> rationale proposed by Cullen in [1] (i.e., similar bandwidth requirement =
as
> with G.711).
>
> So, to be "conservative enough", how about 50 ms RECOMMENDED pacing value=
 if
> there's no better knowledge of the network? And if there is, scale
> accordingly, but not below 20ms.
>
>
> Cheers,
> Ari
>
> [1] http://www.ietf.org/mail-archive/web/mmusic/current/msg10448.html
> [2]
> http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic#_Interactive=
_Connectivity_Establishment
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



--=20
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From martin.thomson@gmail.com  Fri Oct 18 09:44: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 0EF0011E8286 for ; Fri, 18 Oct 2013 09:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.381
X-Spam-Level: 
X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3nnqEXbxqyg for ; Fri, 18 Oct 2013 09:44:39 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC9811E810F for ; Fri, 18 Oct 2013 09:44:39 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id h11so1317804wiv.10 for ; Fri, 18 Oct 2013 09:44:38 -0700 (PDT)
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:content-transfer-encoding; bh=IA3nBOoBpG7dSg8Kpphs1xli2snAURTyRwBDHXpdzzU=; b=to7Sp/RLCIxziQxdmqIsecqBjd+ZsLR11OtQhUZjPziEsFU/5p636LepBLZrgoMgYB BpVuqLp88CLd4tLoyE0iaDaxjpHg/hJOE9KqUJsj+Yh0FXPzkIV7qeKMxvpGjVUJoy2T QrI5IZLb1W6L+P1G7qdiiDMUmqXQ3QIjZHQ2StiIn/VJb2qvFavy17RxG1ZeBsoObcGa YLb202aB+C/y/0ioiCwiXdCA8LQ3pmVJY+5P3zXHpGdvL2URb1qm5NkbF9T1IPrE3+0Z jZhvTV+j45fQpH/vKER6pR/NsU1rnCjQQyRMbyOtmqv6fexSEauK5oS9ypdcerofVAQQ b3Rw==
MIME-Version: 1.0
X-Received: by 10.194.174.36 with SMTP id bp4mr3357682wjc.7.1382114678606; Fri, 18 Oct 2013 09:44:38 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Fri, 18 Oct 2013 09:44:38 -0700 (PDT)
In-Reply-To: <526147C3.9040204@ericsson.com>
References: <526147C3.9040204@ericsson.com>
Date: Fri, 18 Oct 2013 09:44:38 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 16:44:40 -0000

On 18 October 2013 07:37, Ari Ker=C3=A4nen  wrote=
:
> So, to be "conservative enough", how about 50 ms RECOMMENDED pacing value=
 if there's no better knowledge of the network? And if there is, scale acco=
rdingly, but not below 20ms.

I see no reason not to make this 50ms.  20ms might cross the line, but
I'll let people argue about what is safe below that.  I have done some
calculations on this and even at 20ms, it's not out of proportion.
(I'll send a pointer out when I submit the draft later today).

A good reason not to have a larger pacing timer is the effect that it
has on RTO.  For some configurations, the standard formulae lead to
ICE taking far too long to complete.

--Martin

From gsalguei@cisco.com  Fri Oct 18 09:59: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 6FCB411E833A for ; Fri, 18 Oct 2013 09:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level: 
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otXnTEd7FOTj for ; Fri, 18 Oct 2013 09:58:56 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E911E831A for ; Fri, 18 Oct 2013 09:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1190; q=dns/txt; s=iport; t=1382115460; x=1383325060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KIISmRWx53MR61No9qNUAgk6vtRci+xmF/QSooMeEn4=; b=Isr7Aq6mawNxxCT14Z1e0c7k2iVdnG+9ee/IJlMrY5ebz26NjMHgEncQ x9YcAC2aOSmdVBtcFjaUye5vc6p2Y9earIbm3qmY8VH+17f0tnKdh2STV WgXaZdn3K6ni1dW4UbS5oioLna1I5iMp7g1ZAMAljH3MNNjmDJ522bzCy 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFALlnYVKtJV2Y/2dsb2JhbABagwc4Ur1YS4EhFnSCJQEBAQMBAQEBawsFCwIBCCIZCycLJQIEDgUIh3gGDMEeBI8jAjEHgx+BCgOJB6EJgWaBPoIp
X-IronPort-AV: E=Sophos;i="4.93,523,1378857600"; d="scan'208";a="273850394"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 18 Oct 2013 16:57:39 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9IGvdqx005718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 16:57:39 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 11:57:39 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
Thread-Topic: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
Thread-Index: AQHOzA8vS90jukD6SEauGGG5Dx6iq5n7AgAA
Date: Fri, 18 Oct 2013 16:57:39 +0000
Message-ID: 
References: <526146F2.1060203@ericsson.com>
In-Reply-To: <526146F2.1060203@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.132.54]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <4F566897442E6245A583D7102DB0C2A6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic 
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 16:59:16 -0000

I support its adoption.

Gonzalo

On Oct 18, 2013, at 10:34 AM, Ari Ker=E4nen  wrot=
e:

> Hi all,
>=20
> When single 5-tuple is used for media associated with multiple SDP media =
descriptions (i.e., Bundle) the WG has identified the need to analyze and s=
pecify applicability and impact of different attributes on media descriptio=
n bundling.
>=20
> The draft-nandakumar-mmusic-sdp-mux-attributes-04 ("Framework for SDP Att=
ributes when Multiplexing") provides this analysis. The draft has been pres=
ented and discussed over the past few meetings and the feedback on both the=
 need for the work and the draft itself has been positive.
>=20
> Based on the above, we would like to propose adding a new milestone for
> and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as a WG ite=
m for that milestone.
>=20
> If you have any comments or concerns with the above, please let us know n=
o later than November 1st, 2013.
>=20
>=20
> Thanks,
> Ari & Flemming
> (MMUSIC co-chairs)
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From adam@nostrum.com  Fri Oct 18 10:31: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 2641511E819D for ; Fri, 18 Oct 2013 10:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.258
X-Spam-Level: 
X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NY3A5s8T9I9 for ; Fri, 18 Oct 2013 10:31:02 -0700 (PDT)
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 5E8AA11E8267 for ; Fri, 18 Oct 2013 10:31:00 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9IHUuos081897 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 12:30:57 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5261704B.9090307@nostrum.com>
Date: Fri, 18 Oct 2013 12:30:51 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Emil Ivov , =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
References: <526147C3.9040204@ericsson.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070109050902040904080409"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 17:31:03 -0000

This is a multi-part message in MIME format.
--------------070109050902040904080409
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/18/13 09:44, Emil Ivov wrote:
> It might be worth reminding exactly what these 50ms would be
> protecting us against

They're protecting us against RTP arriving at a rate of 20ms per packet.

> and why is it that we don't need to be
> protected against it in the case of RTP where 20ms is accepted as a
> fine default value.

Well, it's not. This is exactly why we ended up requiring ICE: it 
ensures explicit consent before you start blowing media at someone.

See also http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html

/a

--------------070109050902040904080409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/18/13 09:44, Emil Ivov wrote:

    

    

      
It might be worth reminding exactly what these 50ms would be
protecting us against

    

    

    They're protecting us against RTP arriving at a rate of 20ms per
    packet.

    

    

      
and why is it that we don't need to be
protected against it in the case of RTP where 20ms is accepted as a
fine default value.


    

    

    Well, it's not. This is exactly why we ended up requiring ICE: it
    ensures explicit consent before you start blowing media at someone.

    

    See also
    
    http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html

    

    /a

  


--------------070109050902040904080409--

From christer.holmberg@ericsson.com  Fri Oct 18 10:59:50 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 7A95A11E8298 for ; Fri, 18 Oct 2013 10:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.518
X-Spam-Level: 
X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=0.431,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNraGa0gtX9B for ; Fri, 18 Oct 2013 10:59:36 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E9DFB11E80F9 for ; Fri, 18 Oct 2013 10:59:34 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-6a-526177051f2e
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 82.40.16099.50771625; Fri, 18 Oct 2013 19:59:33 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 19:59:33 +0200
From: Christer Holmberg 
To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic 
Thread-Topic: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
Thread-Index: AQHOzA8t4zrL84kCH0KGTaqOxZeTCJn6v3Gw
Date: Fri, 18 Oct 2013 17:59:32 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C2EF6@ESESSMB209.ericsson.se>
References: <526146F2.1060203@ericsson.com>
In-Reply-To: <526146F2.1060203@ericsson.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvjS5reWKQwYwmXYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY9HM/SwFH7gqzs5dzdrA2M7ZxcjBISFgInHhL3cXIyeQKSZx 4d56NhBbSOAwo8TUR75djFxA9hJGibauj6wg9WwCFhLd/7RBakQEIiV+9n1jArGFBSokrrw+ zQYRr5RYue4vI0i5iICRxJ9bFSBhFgFVieXPdjGD2LwCvhLbjq1kglilLXGncSoLiM0poCOx /90LVhCbEeic76fWgNUwC4hLfDh4nRniTAGJJXvOQ9miEi8f/2OFsJUkFt3+DFWvJ3Fj6hQ2 CFtbYtnC11B7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eWGmxiBAX9wy2/d HYynzokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PNGnspsfUNvf8C XvcukyqMYzsUY77+mXDmGUnFOetep4rt+HZI0OJo+dPly7/8yk3XOr1qv9OSrQc+CmdyFwVG xpkx2O2dcdBJ0spiC1P4cq2wBosZ3pH+McK9y+smayRkO9ybtMh4e6PsL+8Vr7ae2N2r9jpk YZrS/NdPbjM9Zn+a965r81olluKMREMt5qLiRABC9+brRgIAAA==
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 17:59:50 -0000

Hi,

I support the adoption.

Regards,

Christer

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P=
uolesta Ari Ker=E4nen
L=E4hetetty: 18. lokakuuta 2013 17:34
Vastaanottaja: mmusic
Aihe: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmu=
sic-sdp-mux-attributes-04 as WG item

Hi all,

When single 5-tuple is used for media associated with multiple SDP media de=
scriptions (i.e., Bundle) the WG has identified the need to analyze and spe=
cify applicability and impact of different attributes on media description =
bundling.

The draft-nandakumar-mmusic-sdp-mux-attributes-04 ("Framework for SDP Attri=
butes when Multiplexing") provides this analysis. The draft has been presen=
ted and discussed over the past few meetings and the feedback on both the n=
eed for the work and the draft itself has been positive.

Based on the above, we would like to propose adding a new milestone for and=
 adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as a WG item for=
 that milestone.

If you have any comments or concerns with the above, please let us know no =
later than November 1st, 2013.


Thanks,
Ari & Flemming
(MMUSIC co-chairs)
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

From christer.holmberg@ericsson.com  Fri Oct 18 11:12: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 6F83E11E825D for ; Fri, 18 Oct 2013 11:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.691
X-Spam-Level: 
X-Spam-Status: No, score=-5.691 tagged_above=-999 required=5 tests=[AWL=0.558,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta1VqJ1Q57MU for ; Fri, 18 Oct 2013 11:11:59 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 54C1611E827D for ; Fri, 18 Oct 2013 11:11:57 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-d6-526179ecddef
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.E7.03802.CE971625; Fri, 18 Oct 2013 20:11:56 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 20:11:56 +0200
From: Christer Holmberg 
To: Adam Roach , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWg==
Date: Fri, 18 Oct 2013 18:11:55 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvje6bysQgg8crrC32/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj3J0eloIjrBVNK/IbGNexdDFyckgImEg8 3vSVFcIWk7hwbz1bFyMXh5DAYUaJJY39rBDOEkaJXxMfAHVwcLAJWEh0/9MGMUUE3CTmnUoH 6RUW8JLomdkLNlNEwFvi//2rLBAlehIXj6mAhFkEVCVOLfgNVsIr4Csxd+ZMdhCbEWjt91Nr mEBsZgFxiQ8HrzNDnCMgsWTPeShbVOLl439QZypJLLr9GapeR2LB7k9sELa2xLKFr5kh5gtK nJz5hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAoP64JbfqjsY75wTOcQozcGi JM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGRm2mDSFuDus6jO3s6oVD3VQLF3kW 5Tpof23/f3D68u6y/Jem5y4UOuxZwKJk25XUnuHo+F9Tl+Wn12WmRaYV6cvFathevbg2ie2c qMChcgaP/T9es1TvrV6lkHBdiZGHW/Kt8vUNb2/LaOTMlq71Pm9pvu9Um0yrRtsqMw2ZqV/2 cO+ae0KJpTgj0VCLuag4EQA/EOvKOAIAAA==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 18:12:05 -0000

Hi,

The draft says that one will use the "application/sdpfrag" MIME type value =
for POFs and PANs.

What about using "application/sdp" - ie the same MIME type value as for "no=
rmal" SDP Offers and Answers? From a SDP syntax perspective it should not b=
e a problem - any SDP parser will be able to parse a POF/PAN.

An entity that does not support POF/PAN would probably trigger an error. BU=
T, maybe that is good: It could be a mechanism to verify that all SDP proce=
ssing/inspecting entities along the signaling path actually support the mec=
hanism. At least for SIP I can't think of any other mechanism to do that (w=
e can't use Proxy-Require).

Comments?

Regards,

Christer


From jonathan@vidyo.com  Fri Oct 18 11:13: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 223C711E825D for ; Fri, 18 Oct 2013 11:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.83
X-Spam-Level: 
X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.150,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5XSx1lqGZnM for ; Fri, 18 Oct 2013 11:13:37 -0700 (PDT)
Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id 36DD311E8288 for ; Fri, 18 Oct 2013 11:13:34 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/18/2013 2:13:33 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-32/SG:2 10/18/2013 2:13:11 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.859708 p=-0.975709 Source White
X-Signature-Violations: 0-0-0-4345-c
X-Note-419: 15.6003 ms. Fail:0 Chk:1350 of 1350 total
X-Note: SCH-CT/SI:0-1350/SG:1 10/18/2013 2:13:15 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G457 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 41399798; Fri, 18 Oct 2013 14:13:33 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 13:13:31 -0500
From: Jonathan Lennox 
To: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
Thread-Topic: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
Thread-Index: AQHOzBs9gZhl3Wu2WUSAyyM/u+wPN5n7FxoA
Date: Fri, 18 Oct 2013 18:13:30 +0000
Message-ID: <5EA4CE0C-7596-409B-AE72-BD23C9299E16@vidyo.com>
References: <526146F2.1060203@ericsson.com>
In-Reply-To: <526146F2.1060203@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <42D519341BD8F84AAF33597865923190@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic 
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 18:13:42 -0000

I think this is an integral and necessary part of BUNDLE -- should it reall=
y be a separate milestone?  (If the document editors want to structure the =
BUNDLE work as one document defining the core concepts, and another describ=
ing the applicability to all existing SDP attributes, that's fine, but it s=
eems to me it's still one work item.)

I definitely agree this work should be adopted by the WG, though, in whatev=
er form.

On Oct 18, 2013, at 10:34 AM, Ari Ker=E4nen 
 wrote:

> Hi all,
>=20
> When single 5-tuple is used for media associated with multiple SDP media =
descriptions (i.e., Bundle) the WG has identified the need to analyze and s=
pecify applicability and impact of different attributes on media descriptio=
n bundling.
>=20
> The draft-nandakumar-mmusic-sdp-mux-attributes-04 ("Framework for SDP Att=
ributes when Multiplexing") provides this analysis. The draft has been pres=
ented and discussed over the past few meetings and the feedback on both the=
 need for the work and the draft itself has been positive.
>=20
> Based on the above, we would like to propose adding a new milestone for
> and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as a WG ite=
m for that milestone.
>=20
> If you have any comments or concerns with the above, please let us know n=
o later than November 1st, 2013.
>=20
>=20
> Thanks,
> Ari & Flemming
> (MMUSIC co-chairs)
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20


From martin.thomson@gmail.com  Fri Oct 18 11:18: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 937FD11E82F2 for ; Fri, 18 Oct 2013 11:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBEEMQ1m50xS for ; Fri, 18 Oct 2013 11:18:44 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DBEA711E82F8 for ; Fri, 18 Oct 2013 11:18:40 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id t60so4177845wes.30 for ; Fri, 18 Oct 2013 11:18:39 -0700 (PDT)
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=i0vV7pzlenwSsaik+bqV83qjO+PeBj9u5aNL9Ev3jqc=; b=ZObVUtzeRYjVHqrKRKTaJm9SyoEdvG21iXdrb3mNrWaZmRDTotEYa94Usm0qTdpU21 QnOcXHNI7olgc4hNLkp7jBkva3msiUpLdLuLU7vsWd1QHlQEMQOPaS/rpY6IGc8AjD8v N8z/PtRLUQjCd4VZOqxSqe7PIWv6LHD2RI6AjGtH8hgCx5ARcDxgwp72hdH4zKIaAVNw m2Hqv/MHWLY+Qoshc8TeAqIuIhueyBil6UC3Z8b3QFaK/OhO/FligaQrUnqvC41ijgyP 1Nwqd/83eyIVhQqu4PV0lpVbwMw0uPp5ZdSlmSXtHyiFidQ+yUh28q4/3G60169Zdhv6 N3eA==
MIME-Version: 1.0
X-Received: by 10.180.86.230 with SMTP id s6mr477591wiz.64.1382120319879; Fri, 18 Oct 2013 11:18:39 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Fri, 18 Oct 2013 11:18:39 -0700 (PDT)
In-Reply-To: <5EA4CE0C-7596-409B-AE72-BD23C9299E16@vidyo.com>
References: <526146F2.1060203@ericsson.com> <5EA4CE0C-7596-409B-AE72-BD23C9299E16@vidyo.com>
Date: Fri, 18 Oct 2013 11:18:39 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 18:18:44 -0000

On 18 October 2013 11:13, Jonathan Lennox  wrote:
> I think this is an integral and necessary part of BUNDLE -- should it really be a separate milestone?

I had the same sentiment.  Adding the draft name to the existing
milestone should be sufficient.

From pkyzivat@alum.mit.edu  Fri Oct 18 11:33: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 6AA4C11E8302 for ; Fri, 18 Oct 2013 11:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.272
X-Spam-Level: 
X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=0.165,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUfQd9je1oLq for ; Fri, 18 Oct 2013 11:33:25 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 7938711E80DE for ; Fri, 18 Oct 2013 11:33:25 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id eb9f1m0021vXlb85EiZQBo; Fri, 18 Oct 2013 18:33:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id eiZQ1m00i3ZTu2S3diZQCl; Fri, 18 Oct 2013 18:33:24 +0000
Message-ID: <52617EF3.8040705@alum.mit.edu>
Date: Fri, 18 Oct 2013 14:33:23 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>
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=1382121204; bh=Wb44MGBHKZCzBsz+j/F3mRhvH2shrIISNVVw7tv+HmY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kkBAMjsiA0XR+HKaAW4+ZP5t02dmsu8n/BIrx/m5TE097SaXAHutFKrKBHV+4l6hK c9+BQGe0eV92xS+71Tnm9yq0v7VS70XWqCMcgnWs7fPgazqRl4r1UR+OB9RZ9PzB+W 445UqQO3bbqmKAqVba7iBlgfXGFS9/2xibzFuB+/lm2IO6wcJavX7vo8CeuePiS9av WayXfwtt4oX6gufghi/gAv2AwP5vPyNgqgVO/ZL6ju1HujwWOtZ9toAiqlxov5YCbh ery9YofdvP7MhqO1bg1pnkRb3TtNZ2fg8WImJu8rNAoueQCNyLHc18MihWWsnxeCZO Qt55hfNiuu6/g==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 18:33:31 -0000

On 10/18/13 2:11 PM, Christer Holmberg wrote:
> Hi,
>
> The draft says that one will use the "application/sdpfrag" MIME type value for POFs and PANs.
>
> What about using "application/sdp" - ie the same MIME type value as for "normal" SDP Offers and Answers? From a SDP syntax perspective it should not be a problem - any SDP parser will be able to parse a POF/PAN.
>
> An entity that does not support POF/PAN would probably trigger an error. BUT, maybe that is good: It could be a mechanism to verify that all SDP processing/inspecting entities along the signaling path actually support the mechanism. At least for SIP I can't think of any other mechanism to do that (we can't use Proxy-Require).
>
> Comments?

It isn't the same as SDP. The SDP fragments aren't syntactically valid 
SDP - they are missing some mandatory fields.

Conceivably the POF/PAN stuff could require more, so that they are 
syntactically valid SDP. But do we want to?

And required processing is semantically different. If it were the same 
content type then some other means would be required to indicate that it 
is being used for POF/PAN, not offer/answer. Adam isn't talking about 
that part. In sip, that could be done via content-disposition.

	Thanks,
	Paul


From juberti@google.com  Fri Oct 18 11:35:15 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 152A511E81B8 for ; Fri, 18 Oct 2013 11:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpngt1BMzObd for ; Fri, 18 Oct 2013 11:35:14 -0700 (PDT)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D155911E82FE for ; Fri, 18 Oct 2013 11:35:09 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id hz11so529895vcb.38 for ; Fri, 18 Oct 2013 11:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AlfOOJniPesGFc7Kc0D9RtymNKBZyGYBD+UcV/hHUqM=; b=jHRHpmi3/M/Cjjv63Brovm5EFa/4Ibk8fOc3K668k44lAMKEugrgtE4XupSUMtfwyY RzmHHkMZRGwkFJ7SMNmHjVZ1IgZAns7TxmLnXLe/Hr5CxU8ZZGBdtrZOCKJEuMHlxvt6 6+cgTCE0WFv+yOOAanJCRH4L+fYqXuj15qgzPPa8Iuo20VNJew+cc2mHf6sGfOCa+uMq JvsCPmvdp+k1PKI1a7TFAmqORaXBTA70GMCgfojCbN3LRbN9X0XqPcRXCxXiAwXvVJ48 ORGGaFaCTC9Og+zt6hlNrurf167uO09mnuSE5VtJ0bR/Aod+XnQOqK50jBU0xIiyLMi4 ZJiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AlfOOJniPesGFc7Kc0D9RtymNKBZyGYBD+UcV/hHUqM=; b=cUcZRhmsBC6R5gkXXcdJgP9pm9EU7ejMf9xKY89ELh7EDpWc/owAx0uSwTGr91bWlb tfGvOPVHKJUeo/PVQNYPbxSS6Ney6IPFKmZFwTzkSjel2FlpUShmJN7BU7BQ/eiI9RZK P7Jcvu2B4/2i1DUDIUq6sWWyLWZLXGkwLzUdaAlz+lxf6qxcs0RBdOpLiG85z3EL4rw8 R+/fPux3dWQiMnRtU+J2/LJtn8zjWttqUi4vZAh2jtqSFQRYBo6E9qtZDZV5OdFudHUE i022aeCo3ZpV23JhI5/f8NM+rj9Xb/Y74+DWnhS+XvfZPxVWHsmZBeyRFHN6cC5DGiFL lXcg==
X-Gm-Message-State: ALoCoQnW2C0GdOSsaxt189f0CT02eT52Nssl33GXTaEmYZIs7kf0lbX1wqYF1maf4zfW7Qd21Ee7SnG8RcpMPaGWJi2uar4zpxaUCCr6Mnoe+VEjJ5Y1fK5juGIk3TMPqeIDn1oNDa2/ZLoekcDeKCDmx2NM6lHggGAFM7b1AGcdLO1akY3W7HAbw9jMvQiPMFb7UMXPs7vc
X-Received: by 10.52.231.5 with SMTP id tc5mr6871vdc.36.1382121309109; Fri, 18 Oct 2013 11:35:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 18 Oct 2013 11:34:49 -0700 (PDT)
In-Reply-To: <5261704B.9090307@nostrum.com>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com>
From: Justin Uberti 
Date: Fri, 18 Oct 2013 11:34:49 -0700
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=089e01176b43aaa62c04e90831f1
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 18:35:15 -0000

--089e01176b43aaa62c04e90831f1
Content-Type: text/plain; charset=UTF-8

FWIW, we are now doing trials to understand what is the absolute lower
bound for ICE checks on today's internet (i.e. what is the minimum time to
allow for a NAT to create a new UDP binding).


On Fri, Oct 18, 2013 at 10:30 AM, Adam Roach  wrote:

>  On 10/18/13 09:44, Emil Ivov wrote:
>
> It might be worth reminding exactly what these 50ms would be
> protecting us against
>
>
> They're protecting us against RTP arriving at a rate of 20ms per packet.
>
>
>  and why is it that we don't need to be
> protected against it in the case of RTP where 20ms is accepted as a
> fine default value.
>
>
> Well, it's not. This is exactly why we ended up requiring ICE: it ensures
> explicit consent before you start blowing media at someone.
>
> See also http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html
>
> /a
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--089e01176b43aaa62c04e90831f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


FWIW, we are now doing trials to understand what is the ab=
solute lower bound for ICE checks on today's internet (i.e. what is the=
 minimum time to allow for a NAT to create a new UDP binding).




On Fri, Oct 18, 2013 at 10:30 AM, Adam R=
oach <adam@nostrum.com> wrote:



 =20
   =20
 =20
  

    
On 10/18/13 09:44, Emil Ivov wrote:

    

    

      
It might be worth reminding exactly what these 50ms would be
protecting us against

    

    

    They're protecting us against RTP arriving at a rate of 20ms per
    packet.


    

    

      
and why is it that we don't need to be
protected against it in the case of RTP where 20ms is accepted as a
fine default value.


    

    

    Well, it's not. This is exactly why we ended up requiring ICE: it
    ensures explicit consent before you start blowing media at someone.

    

    See also
   =20
    http://www.ietf.org/mail-archive/web/mmusic/curren=
t/msg04589.html

    

    /a

  



_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--089e01176b43aaa62c04e90831f1--

From christer.holmberg@ericsson.com  Fri Oct 18 11:50: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 11DCE11E8323 for ; Fri, 18 Oct 2013 11:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.891
X-Spam-Level: 
X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlE+3wGfjPan for ; Fri, 18 Oct 2013 11:50:43 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF211E8338 for ; Fri, 18 Oct 2013 11:50:39 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-2a-526182fd5738
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 63.F0.25272.DF281625; Fri, 18 Oct 2013 20:50:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 20:50:37 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WA=
Date: Fri, 18 Oct 2013 18:50:36 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu>
In-Reply-To: <52617EF3.8040705@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6/psQgg9U3OCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj95tZ7AVT+SouTD3G2sC4hbuLkZNDQsBE 4s7Xp0wQtpjEhXvr2boYuTiEBI4ySlz/2sMO4SxhlDiypJmli5GDg03AQqL7nzZIg4iAr8Sz x7fZQGxhAS+Jnpm9LBBxb4n/969C2VYSHTc2gNWwCKhKrN3cxgYyhheo9+sZeRBTSCBfYsce A5AKTgEdifX/JzOC2IxA53w/tQbsNGYBcYkPB68zQ5wpILFkz3koW1Ti5eN/rBC2ksSK7ZcY Iep1JBbs/sQGYWtLLFv4GqyeV0BQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXIUZxanJSb bmSwiREYCQe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MB72Mt82sVl/8g2nZVa7GEV3XWyIWs9k2bhWedLNSRLeK3SfxKVm3lmd+r14YdIRtbbz0s9s vhsp7HQsOXb4Z+eWB49DEvi3xFQfm1a6ROhluzvHq64+s4j/XjbT1la0LnvRZNxasWbBjWeX G/MvXj8t/iY22OC47pfSMzy7o2S8X605sFe75JYSS3FGoqEWc1FxIgD7DOiOUgIAAA==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 18:50:49 -0000

Hi,

>> The draft says that one will use the "application/sdpfrag" MIME type val=
ue for POFs and PANs.
>>
>> What about using "application/sdp" - ie the same MIME type value as for =
"normal" SDP Offers and Answers? From a SDP syntax perspective it should no=
t be a problem - any SDP parser will be able to parse a POF/PAN.
>>
>> An entity that does not support POF/PAN would probably trigger an error.=
 BUT, maybe that is good: It could be a mechanism to verify that all SDP pr=
ocessing/inspecting=20
>> entities along the signaling path actually support the mechanism. At lea=
st for SIP I can't think of any other mechanism to do that (we can't use Pr=
oxy-Require).
>>
>> Comments?
>
> It isn't the same as SDP. The SDP fragments aren't syntactically valid SD=
P - they are missing some mandatory fields.
>
> Conceivably the POF/PAN stuff could require more, so that they are syntac=
tically valid SDP. But do we want to?
>
> And required processing is semantically different. If it were the same co=
ntent type then some other means would be required to indicate that it is b=
eing used for POF/PAN, not offer/answer.

Well, for that there are many alternatives: SDP attribute, Content-XXX para=
meter, etc.

> Adam isn't talking about that part. In sip, that could be done via conten=
t-disposition.

Content-Disposition does not apply to intermediaries. So, a proxy that only=
 understands application/sdp (e.g. for gate control purpose) will not even =
look at the C-D header field value for other bodies. And, unless such proxy=
 understands POF/PAN, there may not be any media passing through...

Regards,

Christer




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

From adam@nostrum.com  Fri Oct 18 11:55: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 4236411E8116 for ; Fri, 18 Oct 2013 11:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.421
X-Spam-Level: 
X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJVuo6dVGtQ3 for ; Fri, 18 Oct 2013 11:55:42 -0700 (PDT)
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 A2D6911E82B9 for ; Fri, 18 Oct 2013 11:55:40 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9IItcpg091285 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 13:55:39 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52618425.7040409@nostrum.com>
Date: Fri, 18 Oct 2013 13:55:33 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Paul Kyzivat , mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu>
In-Reply-To: <52617EF3.8040705@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 18:55:43 -0000

On 10/18/13 13:33, Paul Kyzivat wrote:
> On 10/18/13 2:11 PM, Christer Holmberg wrote:
>> Hi,
>>
>> The draft says that one will use the "application/sdpfrag" MIME type 
>> value for POFs and PANs.
>>
>> What about using "application/sdp" - ie the same MIME type value as 
>> for "normal" SDP Offers and Answers? From a SDP syntax perspective it 
>> should not be a problem - any SDP parser will be able to parse a 
>> POF/PAN.
>>
>> An entity that does not support POF/PAN would probably trigger an 
>> error. BUT, maybe that is good: It could be a mechanism to verify 
>> that all SDP processing/inspecting entities along the signaling path 
>> actually support the mechanism. At least for SIP I can't think of any 
>> other mechanism to do that (we can't use Proxy-Require).
>>
>> Comments?
>
> It isn't the same as SDP. The SDP fragments aren't syntactically valid 
> SDP - they are missing some mandatory fields.

This is exactly my sentiment as well.

/a

From jonathan@vidyo.com  Fri Oct 18 12:06: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 4D28B11E830F for ; Fri, 18 Oct 2013 12:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFuWGdPjgH14 for ; Fri, 18 Oct 2013 12:06:03 -0700 (PDT)
Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5A07011E8299 for ; Fri, 18 Oct 2013 12:06:03 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/18/2013 3:06:00 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-145/SG:5 10/18/2013 3:05:50 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=1 p=-0.978697 Source White
X-Signature-Violations: 0-0-0-10736-c
X-Note-419: 15.6023 ms. Fail:0 Chk:1350 of 1350 total
X-Note: SCH-CT/SI:0-1350/SG:1 10/18/2013 3:05:53 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G457 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 66221768; Fri, 18 Oct 2013 15:06:00 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 14:05:59 -0500
From: Jonathan Lennox 
To: Suhas Nandakumar 
Thread-Topic: Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-04
Thread-Index: AQHOuVx7/6GahdVxV0GQyPn7t3kaCJn1ry+AgAWcEQA=
Date: Fri, 18 Oct 2013 19:05:58 +0000
Message-ID: <6B861291-61A1-46D5-A208-767D6B17C2C7@vidyo.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_6B86129161A146D5A208767D6B17C2C7vidyocom_"
MIME-Version: 1.0
Cc: mmusic 
Subject: Re: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-04
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 Oct 2013 19:06:08 -0000

--_000_6B86129161A146D5A208767D6B17C2C7vidyocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, Suhas (and all) --

On these two sections:

Section 5.31 (Comedia over TLS) is correct; fingerprint is IDENTICAL.


For Section SDP Source Attributes (RFC 5576), I think there are two possibi=
lities.

The simpler is to say that individual SSRC values in a=3Dssrc attributes MU=
ST NOT be repeated across bundled m-lines, but other than that the behavior=
 is normal.

The more complicated is to say that SSRC attributes MAY be repeated across =
bundled m-lines, iff the media stream satisfies more than one m-line.  In t=
his case, it's up to the individual source attributes to define what's allo=
wed.

In neither case do these semantics match any of the named attribute categor=
ies, unfortunately.


On Oct 15, 2013, at 1:26 AM, Suhas Nandakumar > wrote:

Hello Jonathan

   I was wondering If you got chance to look at this review request.

Thanks in Advance

Cheers
Suhas


On Tue, Sep 24, 2013 at 12:29 PM, Suhas Nandakumar > wrote:
Hello Jonathan,

Could you please help in reviewing the following sections from the SDP Attr=
ibute Multiplexing Draft

RFC 5576 - SDP Source Attributes
Section 5.14. 11.1

RFC 4572 - Comedia over TLS
Section 5.31


  The document is available here:
     http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-=
04

Thanks in Advance

Regards
Suhas Nandakumar



--_000_6B86129161A146D5A208767D6B17C2C7vidyocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <9013547DAEB6F8488CFC161D4BCF3C3B@vidyo.com>
Content-Transfer-Encoding: quoted-printable







Hi, Suhas (and all) --







On these two sections:







Section 5.31 (Comedia over TLS) is correct; fingerprint is IDENTICAL.<=
/div>











For Section SDP Source Attributes (RFC 5576), I think there are two po=
ssibilities.







The simpler is to say that individual SSRC values in a=3Dssrc attribut=
es MUST NOT be repeated across bundled m-lines, but other than that the beh=
avior is normal.







The more complicated is to say that SSRC attributes MAY be repeated ac=
ross bundled m-lines, iff the media stream satisfies more than one m-line. =
 In this case, it's up to the individual source attributes to define w=
hat's allowed.







In neither case do these semantics match any of the named attribute ca=
tegories, unfortunately.











On Oct 15, 2013, at 1:26 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:






Hello Jonathan






   I was wondering If you got chance to look at this review =
request.







Thanks in Advance







Cheers


Suhas









On Tue, Sep 24, 2013 at 12:29 PM, Suhas Nandakum=
ar 
<suhasietf@gmai=
l.com> wrote:








Hello Jonathan,







Could you please help in reviewing the following se=
ctions from the SDP Attribute Multiplexing Draft







RFC 5576 - SDP Source Attributes


Section 5.14. 11.1







RFC 4572 - Comedia over TLS


Section 5.31












  The document is available here:









Thanks in Advance









Regards

Suhas Nandakumar




















--_000_6B86129161A146D5A208767D6B17C2C7vidyocom_--

From adam@nostrum.com  Fri Oct 18 12:10: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 9BDD811E8315 for ; Fri, 18 Oct 2013 12:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.43
X-Spam-Level: 
X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8gt7CIU+W0b for ; Fri, 18 Oct 2013 12:10:47 -0700 (PDT)
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 DC7D311E8299 for ; Fri, 18 Oct 2013 12:10:46 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9IJAfO0092951 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 14:10:42 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <526187AC.8060200@nostrum.com>
Date: Fri, 18 Oct 2013 14:10:36 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 19:10:47 -0000

On 10/18/13 13:50, Christer Holmberg wrote:
> Content-Disposition does not apply to intermediaries. So, a proxy that 
> only understands application/sdp (e.g. for gate control purpose) will 
> not even look at the C-D header field value for other bodies. And, 
> unless such proxy understands POF/PAN, there may not be any media 
> passing through...

Right. A middlebox that doesn't understand application/sdpfrag won't 
know to look at its contents and let the new streams through. And a 
middlebox that sees something marked as "application/sdp" that conveys 
only a tiny fraction of the session will probably be just as 
catastrophic; I would imagine everything but the modified streams would 
be shut off. There's no way to win here.

At some point, we have to come to peace with the fact that any 
middleboxes that aren't primarily in the business of stifling progress 
will need to keep pace with protocol extensions as they get deployed.

/a

From christer.holmberg@ericsson.com  Fri Oct 18 13:44: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 EC15A11E8330 for ; Fri, 18 Oct 2013 13:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.673
X-Spam-Level: 
X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.576,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x26Opnu2AA6i for ; Fri, 18 Oct 2013 13:44:04 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 449A611E80E3 for ; Fri, 18 Oct 2013 13:44:03 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-30-52619d92e5fe
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2A.2F.03802.29D91625; Fri, 18 Oct 2013 22:44:03 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 22:44:02 +0200
From: Christer Holmberg 
To: Adam Roach , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WCAAC+BAP//xcmg
Date: Fri, 18 Oct 2013 20:44:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com>
In-Reply-To: <526187AC.8060200@nostrum.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje7kuYlBBr/XsFrs+buI3WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPGbtfMISwBzFZZOSmpNZllqkb5fAlXHx/36mghvcFWfa77M3 MG7g7mLk5JAQMJGYv/o2G4QtJnHh3nogm4tDSOAwo8SZnQtYQBJCAksYJWb+9+hi5OBgE7CQ 6P6nDRIWEciT+PFhO1iJsICXRM/MXhaIuLfE//tXoWw3id9LT7KD2CwCqhLT3m4As3kFfCVO 7PrJBLHrCqPE/y1NYA2cAtoSlx4+BytiBDro+6k1TCA2s4C4xIeD15khDhWQWLLnPJQtKvHy 8T9WCFtJYsX2S4wgdzILaEqs36UP0aooMaX7IdReQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjA yLKKkT03MTMnvdxoEyMwNg5u+a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYMz3WBVkuMk353b1vY3ClZw3NWM3SruZfmt0WjLfcFJ0/IxS4dM7Lt6xyXIw jCnTq32z7dxRQXGHmfGngqrOhD45EtrEdKLw5tf6i89WBOhOl1784fapzes3cu+SW/825JGr 0F3lw7G3Lz5+tX1Gi7FL57H4iuK1OyLuN/jv2Zv3Ibhg3v6FObOUWIozEg21mIuKEwGucoH+ WwIAAA==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 20:44:11 -0000

SGksDQoNCj4+IENvbnRlbnQtRGlzcG9zaXRpb24gZG9lcyBub3QgYXBwbHkgdG8gaW50ZXJtZWRp
YXJpZXMuIFNvLCBhIHByb3h5IHRoYXQgDQo+PiBvbmx5IHVuZGVyc3RhbmRzIGFwcGxpY2F0aW9u
L3NkcCAoZS5nLiBmb3IgZ2F0ZSBjb250cm9sIHB1cnBvc2UpIHdpbGwgDQo+PiBub3QgZXZlbiBs
b29rIGF0IHRoZSBDLUQgaGVhZGVyIGZpZWxkIHZhbHVlIGZvciBvdGhlciBib2RpZXMuIEFuZCwg
DQo+PiB1bmxlc3Mgc3VjaCBwcm94eSB1bmRlcnN0YW5kcyBQT0YvUEFOLCB0aGVyZSBtYXkgbm90
IGJlIGFueSBtZWRpYSANCj4+IHBhc3NpbmcgdGhyb3VnaC4uLg0KPg0KPiBSaWdodC4gQSBtaWRk
bGVib3ggdGhhdCBkb2Vzbid0IHVuZGVyc3RhbmQgYXBwbGljYXRpb24vc2RwZnJhZyB3b24ndCBr
bm93IHRvIGxvb2sgYXQgaXRzIGNvbnRlbnRzIGFuZCBsZXQgdGhlIG5ldyBzdHJlYW1zIHRocm91
Z2guIEFuZCBhIG1pZGRsZWJveCB0aGF0IHNlZXMgDQo+IHNvbWV0aGluZyBtYXJrZWQgYXMgImFw
cGxpY2F0aW9uL3NkcCIgdGhhdCBjb252ZXlzIG9ubHkgYSB0aW55IGZyYWN0aW9uIG9mIHRoZSBz
ZXNzaW9uIHdpbGwgcHJvYmFibHkgYmUganVzdCBhcyBjYXRhc3Ryb3BoaWM7IEkgd291bGQgaW1h
Z2luZSBldmVyeXRoaW5nIGJ1dCB0aGUgDQo+IG1vZGlmaWVkIHN0cmVhbXMgd291bGQgYmUgc2h1
dCBvZmYuIFRoZXJlJ3Mgbm8gd2F5IHRvIHdpbiBoZXJlLg0KDQpJIHRoaW5rIGl0IHdvdWxkIHJl
amVjdCB0aGUgT2ZmZXIgLSBhdCBsZWFzdCB0aGF0J3Mgd2hhdCBpdCBzaG91bGQgZG8gYWNjb3Jk
aW5nIHRvIDMyNjQuDQoNCj4gQXQgc29tZSBwb2ludCwgd2UgaGF2ZSB0byBjb21lIHRvIHBlYWNl
IHdpdGggdGhlIGZhY3QgdGhhdCBhbnkgbWlkZGxlYm94ZXMgdGhhdCBhcmVuJ3QgcHJpbWFyaWx5
IGluIHRoZSBidXNpbmVzcyBvZiBzdGlmbGluZyBwcm9ncmVzcyB3aWxsIG5lZWQgdG8ga2VlcCBw
YWNlIHdpdGggcHJvdG9jb2wgZXh0ZW5zaW9ucyBhcyB0aGV5IGdldCBkZXBsb3llZC4NCg0KSSBy
ZWFsbHkgd2lzaCB0aGluZ3Mgd29ya2VkIHRoYXQgd2F5IDopDQoNClJlZ2FyZHMsDQoNCkNocmlz
dGVyDQoNCg==

From pkyzivat@alum.mit.edu  Fri Oct 18 13:48: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 0327111E832E for ; Fri, 18 Oct 2013 13:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.275
X-Spam-Level: 
X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.162,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYBWYCTNuW79 for ; Fri, 18 Oct 2013 13:48:25 -0700 (PDT)
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 E890C11E81F2 for ; Fri, 18 Oct 2013 13:48:23 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id eeN41m0051ZXKqc5CkoPtV; Fri, 18 Oct 2013 20:48:23 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id ekoP1m00N3ZTu2S3hkoPR3; Fri, 18 Oct 2013 20:48:23 +0000
Message-ID: <52619E95.4050405@alum.mit.edu>
Date: Fri, 18 Oct 2013 16:48:21 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>
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=1382129303; bh=F54IemTsyYUeMOa+EKCVAODZJMjZERQ+piTLUuaCrD8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Pcyv0uaPzOHaScK0YRT+M7XFn6SaZXKJmrfG+Rc9GGBjPhZzDJYcfoeQZCL80gx1c yBmmSq9FFCNWyFzukNlbVEqff9Q11RtAN1HYN2EOzR34ty6BszFiOoG44QPM69lu+6 aurM4sJ5oBIyx8f0e6D4YZWA1udGUMcxTNzbxZbTv2/nFgpwonL6Hdib9AE51xxmbm E1r6JQw5ifhyoujJOi71ZERUd1Ubt8Lnf6xJlVEkEQ0o6njA5baMw+GOE97frASDmR 7yovVLzA5uMDSqGNhDzDhBRva3Br2OWnZTF/0pujqdCr+f/f1+bg+C96mdA78/PrZZ a+LWO0Fee735w==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 20:48:30 -0000

On 10/18/13 2:50 PM, Christer Holmberg wrote:
> Hi,
>
>>> The draft says that one will use the "application/sdpfrag" MIME type value for POFs and PANs.
>>>
>>> What about using "application/sdp" - ie the same MIME type value as for "normal" SDP Offers and Answers? From a SDP syntax perspective it should not be a problem - any SDP parser will be able to parse a POF/PAN.
>>>
>>> An entity that does not support POF/PAN would probably trigger an error. BUT, maybe that is good: It could be a mechanism to verify that all SDP processing/inspecting
>>> entities along the signaling path actually support the mechanism. At least for SIP I can't think of any other mechanism to do that (we can't use Proxy-Require).
>>>
>>> Comments?
>>
>> It isn't the same as SDP. The SDP fragments aren't syntactically valid SDP - they are missing some mandatory fields.
>>
>> Conceivably the POF/PAN stuff could require more, so that they are syntactically valid SDP. But do we want to?
>>
>> And required processing is semantically different. If it were the same content type then some other means would be required to indicate that it is being used for POF/PAN, not offer/answer.
>
> Well, for that there are many alternatives: SDP attribute, Content-XXX parameter, etc.

Yes, though some more appropriate than others.

>> Adam isn't talking about that part. In sip, that could be done via content-disposition.
>
> Content-Disposition does not apply to intermediaries. So, a proxy that only understands application/sdp (e.g. for gate control purpose) will not even look at the C-D header field value for other bodies. And, unless such proxy understands POF/PAN, there may not be any media passing through...

Why do you say that C-D doesn't apply to intermediaries?
In general I would argue that intermediaries have no business caring 
about SDP at all, but that is now water over the dam.

If intermediaries are making decisions about the body, then they are 
obligated to really understand what the significance of the body is 
before messing with it. They have no business jumping to conclusions 
without considering all the factors that influence that.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From pkyzivat@alum.mit.edu  Fri Oct 18 13:53:50 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 772C611E81F2 for ; Fri, 18 Oct 2013 13:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.278
X-Spam-Level: 
X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfinq7H-nWtJ for ; Fri, 18 Oct 2013 13:53:43 -0700 (PDT)
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 55FF711E8312 for ; Fri, 18 Oct 2013 13:53:34 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id ejH41m0040mv7h058ktZw1; Fri, 18 Oct 2013 20:53:33 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id ektZ1m00k3ZTu2S3XktZ28; Fri, 18 Oct 2013 20:53:33 +0000
Message-ID: <52619FCC.3090606@alum.mit.edu>
Date: Fri, 18 Oct 2013 16:53:32 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382129613; bh=Nxo+NqUMSFbTNPuoELaplXS2iJwdTJuHQELGxsTEYcI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LDYvET/5cf7Xa7bRI5wBRgts12LQOFsQ4vH4WqdxkzVramK/bCzqq2Sy3z0dZVsW0 pCMcn+GRkpvZFo6bgDe8Z97tOxxWBdyE71Aghg5W3CJjD5THwcYUkhfyAG5v7YmBWY la2WNewuNq/zWzmobEMhwA8qTzXdudFr6FCTJtZ4d5+ZG06ijHc31xw+mmRli8iaYd 6HEYZc1x+QI5+2kEYg3MF3ZdTIecDbRJqf6DZRKoFoTU6Ol3pJOVnaN8uY79VTRYWR ulKZa7uQsdesAkcSttfR2SNRrthUSkgde9O5HJnDGsl/vd5CektCJwIUYG5VsHgtFz Qjr3sHGo7v3NQ==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 20:53:50 -0000

On 10/18/13 4:44 PM, Christer Holmberg wrote:
> Hi,
>
>>> Content-Disposition does not apply to intermediaries. So, a proxy that
>>> only understands application/sdp (e.g. for gate control purpose) will
>>> not even look at the C-D header field value for other bodies. And,
>>> unless such proxy understands POF/PAN, there may not be any media
>>> passing through...
>>
>> Right. A middlebox that doesn't understand application/sdpfrag won't know to look at its contents and let the new streams through. And a middlebox that sees
>> something marked as "application/sdp" that conveys only a tiny fraction of the session will probably be just as catastrophic; I would imagine everything but the
>> modified streams would be shut off. There's no way to win here.
>
> I think it would reject the Offer - at least that's what it should do according to 3264.

3264 only talks about how to process offers and answers described in 
SDP. It does not say how those are conveyed in sip. 3261 says that they 
are carried in body parts of content-type application/sdp with 
content-disposition of 'session'. If a body part has content-type 
application/sdp but has a disposition other than 'session' then it isn't 
an offer or answer according to 3261, and so 3264 doesn't apply.

>> At some point, we have to come to peace with the fact that any middleboxes that aren't primarily in the business of stifling progress will need to keep pace with protocol extensions as they get deployed.
>
> I really wish things worked that way :)

So progress ends because middleboxes don't permit it?

Maybe you are right. Then sip will go the way of h323 while the world 
moves on to webrtc.

	Thanks,
	Paul


From christer.holmberg@ericsson.com  Fri Oct 18 14:06: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 A948B11E80E3 for ; Fri, 18 Oct 2013 14:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level: 
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.564,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFLhxa-L548K for ; Fri, 18 Oct 2013 14:06:17 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7888821F9ECE for ; Fri, 18 Oct 2013 14:06:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-d7-5261a2c7ab0e
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 34.20.03802.7C2A1625; Fri, 18 Oct 2013 23:06:15 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 23:06:15 +0200
From: Christer Holmberg 
To: Paul Kyzivat 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WCAAC+BAP//xcmggABW+gD//9xWsA==
Date: Fri, 18 Oct 2013 21:06:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu>
In-Reply-To: <52619FCC.3090606@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvje7xRYlBBju7ZSz2/F3EbjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgyvjSvp21YJl4xZ/rm1gb GG+IdTFyckgImEg8n7ubDcIWk7hwbz2QzcUhJHCYUeLxk62MEM4SRolVu2+xdzFycLAJWEh0 /9MGMUUENCQmbVUD6WUWcJP4+38GM4gtLBAgsWT2E3aIkkCJC9v0QcIiAmESHy5sZQGxWQRU JRY8fsQOYvMK+Erc7lvABLFpF5PE0clLwO7hFNCRmLl+GVgRI9Bt30+tYYLYJS7x4eB1Zoib BSSW7DkPZYtKvHz8jxXCVpJYsf0SI8gNzAKaEut36UO0KkpM6X4ItVdQ4uTMJywTGMVmIZk6 C6FjFpKOWUg6FjCyrGJkz03MzEkvN9rECIyYg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYtyx8rd20++Zkl+2vvqbZXSr/HGE/d49K0onTGz5xcklX ysd4fV+6cnfylfYrXYKG55+/c920ss4z2OutUkbtBR/bnON/pK0DP0mYuZ7+9YKz+o/Wz939 zraLNnSqX1vUsTXu79fzv9m3ZNZFTdh48IOJWXTmXUXWgOVHZ0U+jfvI9o77o2x+gBJLcUai oRZzUXEiAPVLpnxmAgAA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:06:23 -0000

SGksDQoNCj4+Pj4gQ29udGVudC1EaXNwb3NpdGlvbiBkb2VzIG5vdCBhcHBseSB0byBpbnRlcm1l
ZGlhcmllcy4gU28sIGEgcHJveHkgDQo+Pj4+IHRoYXQgb25seSB1bmRlcnN0YW5kcyBhcHBsaWNh
dGlvbi9zZHAgKGUuZy4gZm9yIGdhdGUgY29udHJvbCANCj4+Pj4gcHVycG9zZSkgd2lsbCBub3Qg
ZXZlbiBsb29rIGF0IHRoZSBDLUQgaGVhZGVyIGZpZWxkIHZhbHVlIGZvciBvdGhlciANCj4+Pj4g
Ym9kaWVzLiBBbmQsIHVubGVzcyBzdWNoIHByb3h5IHVuZGVyc3RhbmRzIFBPRi9QQU4sIHRoZXJl
IG1heSBub3QgYmUgDQo+Pj4+IGFueSBtZWRpYSBwYXNzaW5nIHRocm91Z2guLi4NCj4+Pg0KPj4+
IFJpZ2h0LiBBIG1pZGRsZWJveCB0aGF0IGRvZXNuJ3QgdW5kZXJzdGFuZCBhcHBsaWNhdGlvbi9z
ZHBmcmFnIHdvbid0IA0KPj4+IGtub3cgdG8gbG9vayBhdCBpdHMgY29udGVudHMgYW5kIGxldCB0
aGUgbmV3IHN0cmVhbXMgdGhyb3VnaC4gQW5kIGEgDQo+Pj4gbWlkZGxlYm94IHRoYXQgc2VlcyBz
b21ldGhpbmcgbWFya2VkIGFzICJhcHBsaWNhdGlvbi9zZHAiIHRoYXQgY29udmV5cyBvbmx5IGEg
dGlueSBmcmFjdGlvbiBvZiB0aGUgc2Vzc2lvbiB3aWxsIHByb2JhYmx5IGJlIGp1c3QgYXMgY2F0
YXN0cm9waGljOyBJIHdvdWxkIGltYWdpbmUgZXZlcnl0aGluZyBidXQgdGhlIG1vZGlmaWVkIHN0
cmVhbXMgd291bGQgYmUgc2h1dCBvZmYuIFRoZXJlJ3Mgbm8gd2F5IHRvIHdpbiBoZXJlLg0KPj4N
Cj4+IEkgdGhpbmsgaXQgd291bGQgcmVqZWN0IHRoZSBPZmZlciAtIGF0IGxlYXN0IHRoYXQncyB3
aGF0IGl0IHNob3VsZCBkbyBhY2NvcmRpbmcgdG8gMzI2NC4NCj4NCj4gMzI2NCBvbmx5IHRhbGtz
IGFib3V0IGhvdyB0byBwcm9jZXNzIG9mZmVycyBhbmQgYW5zd2VycyBkZXNjcmliZWQgaW4gU0RQ
LiBJdCBkb2VzIG5vdCBzYXkgaG93IHRob3NlIGFyZSBjb252ZXllZCBpbiBzaXAuIDMyNjEgc2F5
cyB0aGF0IHRoZXkgYXJlIGNhcnJpZWQgaW4gYm9keSBwYXJ0cyBvZiBjb250ZW50LXR5cGUgYXBw
bGljYXRpb24vc2RwIHdpdGggDQo+IGNvbnRlbnQtZGlzcG9zaXRpb24gb2YgJ3Nlc3Npb24nLiBJ
ZiBhIGJvZHkgcGFydCBoYXMgY29udGVudC10eXBlIGFwcGxpY2F0aW9uL3NkcCBidXQgaGFzIGEg
ZGlzcG9zaXRpb24gb3RoZXIgdGhhbiAnc2Vzc2lvbicgdGhlbiBpdCBpc24ndCBhbiBvZmZlciBv
ciBhbnN3ZXIgYWNjb3JkaW5nIHRvIDMyNjEsIGFuZCBzbyAzMjY0IGRvZXNuJ3QgYXBwbHkuDQoN
CjMyNjQgc2F5cyB0aGF0IGFsbCBtLSBsaW5lIG11c3QgYmUgcHJlc2VudCBpbiBhbiBPZmZlciAt
IGV2ZW4gaWYgdGhleSBhcmUgbm90IG1vZGlmaWVkLiBTbywgd2hhdCBJIG1lYW50IHdhcyB0aGF0
IGluIGNhc2UgYWxsIG0tIGxpbmVzIGFyZSBOT1QgcHJlc2VudCAoaW4gdGhlIGNhc2Ugb2YgYSBQ
T0YpLCBzdWNoIE9mZmVyIHdvdWxkIGJlIHJlamVjdGVkIC0gdW5sZXNzIHRoZSBtaWRkbGVib3gg
dW5kZXJzdGFuZHMgdGhlIFBPRi9QQU4gbWVjaGFuaXNtIC4NCgkNCj4+PiBBdCBzb21lIHBvaW50
LCB3ZSBoYXZlIHRvIGNvbWUgdG8gcGVhY2Ugd2l0aCB0aGUgZmFjdCB0aGF0IGFueSBtaWRkbGVi
b3hlcyB0aGF0IGFyZW4ndCBwcmltYXJpbHkgaW4gdGhlIGJ1c2luZXNzIG9mIHN0aWZsaW5nIHBy
b2dyZXNzIHdpbGwgbmVlZCB0byBrZWVwIHBhY2Ugd2l0aCBwcm90b2NvbCBleHRlbnNpb25zIGFz
IHRoZXkgZ2V0IGRlcGxveWVkLg0KPj4NCj4+IEkgcmVhbGx5IHdpc2ggdGhpbmdzIHdvcmtlZCB0
aGF0IHdheSA6KQ0KPg0KPiBTbyBwcm9ncmVzcyBlbmRzIGJlY2F1c2UgbWlkZGxlYm94ZXMgZG9u
J3QgcGVybWl0IGl0Pw0KPg0KPiBNYXliZSB5b3UgYXJlIHJpZ2h0LiBUaGVuIHNpcCB3aWxsIGdv
IHRoZSB3YXkgb2YgaDMyMyB3aGlsZSB0aGUgd29ybGQgbW92ZXMgb24gdG8gd2VicnRjLg0KDQpJ
IHRoaW5rIHRoYXQgZ2V0dGluZyBleHBsaWNpdCByZWplY3Rpb25zLCByYXRoZXIgdGhhbiBoYXZp
bmcgdG8gdHJ5IHRvIGZpZ3VyZSBvdXQgd2hlcmUgdGhpbmdzIGdvIHdyb25nLCBpcyBnb29kIGZv
ciBwcm9ncmVzcyA6KQ0KDQpBbnl3YXksIGl0IHdhc24ndCByZWFsbHkgYSBzdWdnZXN0aW9uIC0g
SSBqdXN0IHdhbnRlZCB0byBkbyBzb21lIGJyYWluc3Rvcm1pbmcgOikNCg0KUmVnYXJkcywNCg0K
Q2hyaXN0ZXINCg0K

From christer.holmberg@ericsson.com  Fri Oct 18 14:09: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 A9B5B11E8332 for ; Fri, 18 Oct 2013 14:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level: 
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.553,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL5bxHsMn3Uw for ; Fri, 18 Oct 2013 14:09:00 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7201A11E80E3 for ; Fri, 18 Oct 2013 14:08:54 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-66-5261a3651434
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 05.50.03802.563A1625; Fri, 18 Oct 2013 23:08:53 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 23:08:53 +0200
From: Christer Holmberg 
To: Paul Kyzivat 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WCAAErRgP//2WXA
Date: Fri, 18 Oct 2013 21:08:51 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C3413@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <52619E95.4050405@alum.mit.edu>
In-Reply-To: <52619E95.4050405@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW7q4sQgg/v/1SymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjzPsJLAXTWCvOHbjC3sA4gaWLkZNDQsBE 4nD/DWYIW0ziwr31bF2MXBxCAocZJaZM3cEI4SxhlJh3ZDprFyMHB5uAhUT3P20QU0RAQ2LS VjUQk1lAXeLq4iCQMcICARJLZj9hh6gIlLiwTR8kLCLgJnG28w3YJhYBVYmpbx6AXcAr4Cux /uI3VohFVxklJvesZwVJcAroSLSf6mQDsRmBTvt+ag0TiM0sIC7x4eB1qJMFJJbsOQ9li0q8 fPyPFcJWklix/RIjRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0L GFlWMbLnJmbmpJcbbWIExsfBLb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYxFy0+cbbzEe0fWbdLLu1N3750WIMTO93LPtq0RzGxS3HuY3arb3DneHjrJ 1ndQ6KeQnkc1t7Fv7ab5dnlxG7a8fSDzX/HazdSPH/V7VHaJvTS7FHFu0eJD/pNWNr8NrVCa +NhB93VZeWCIYHuId+DOrLWtu8sOPNi78spd1kPLF74o7qmW4LqrxFKckWioxVxUnAgAkHqu h10CAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:09:07 -0000

Hi,

>> Content-Disposition does not apply to intermediaries. So, a proxy that o=
nly understands application/sdp (e.g. for gate control purpose) will not ev=
en look=20
>> at the C-D header field value for other bodies. And, unless such proxy u=
nderstands POF/PAN, there may not be any media passing through...
>
> Why do you say that C-D doesn't apply to intermediaries?

I am saying that an intermediary that is only interested in application/sdp=
 bodies (because that is where it assumes all SDP information is going to b=
e carried) is not going to look at the C-D value associated with applicatio=
n/foo bodies.

Regards,

Christer



From adam@nostrum.com  Fri Oct 18 14:10: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 5D91711E81F2 for ; Fri, 18 Oct 2013 14:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level: 
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFotou-z+NGz for ; Fri, 18 Oct 2013 14:10:01 -0700 (PDT)
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 E44E511E832E for ; Fri, 18 Oct 2013 14:09:58 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9IL9pun006119 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 16:09:53 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5261A39A.1060505@nostrum.com>
Date: Fri, 18 Oct 2013 16:09:46 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:10:01 -0000

On 10/18/13 15:44, Christer Holmberg wrote:
> Hi,
>
>>> Content-Disposition does not apply to intermediaries. So, a proxy that
>>> only understands application/sdp (e.g. for gate control purpose) will
>>> not even look at the C-D header field value for other bodies. And,
>>> unless such proxy understands POF/PAN, there may not be any media
>>> passing through...
>> Right. A middlebox that doesn't understand application/sdpfrag won't know to look at its contents and let the new streams through. And a middlebox that sees
>> something marked as "application/sdp" that conveys only a tiny fraction of the session will probably be just as catastrophic; I would imagine everything but the
>> modified streams would be shut off. There's no way to win here.
> I think it would reject the Offer - at least that's what it should do according to 3264.

The kinds of middleboxes you're talking about don't, in my experience, 
give much weight to anything written in any RFCs anywhere.

/a

From christer.holmberg@ericsson.com  Fri Oct 18 14:16: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 EEF4B11E8319 for ; Fri, 18 Oct 2013 14:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.707
X-Spam-Level: 
X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.542,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1xLE7rXPntP for ; Fri, 18 Oct 2013 14:16:17 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C087E11E8151 for ; Fri, 18 Oct 2013 14:16:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-0a-5261a51ea9c0
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6A.A0.03802.E15A1625; Fri, 18 Oct 2013 23:16:14 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 23:16:14 +0200
From: Christer Holmberg 
To: Adam Roach , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WCAAC+BAP//xcmggABbgwD//9zJoA==
Date: Fri, 18 Oct 2013 21:16:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C344F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <5261A39A.1060505@nostrum.com>
In-Reply-To: <5261A39A.1060505@nostrum.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvja7c0sQgg7Pr9C32/F3EbjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgypjTv5WpYAVTRcfEtAbG BUxdjJwcEgImEv09a5khbDGJC/fWs3UxcnEICRxmlJi3vg8sISSwhFHi6luXLkYODjYBC4nu f9ogYRGBPIkfH7azgNjCAgESS2Y/YQcpEREIlLiwTR+iJExi4f7tbCA2i4CqxJevX1lBbF4B X4lNZz6zQ0zfySQxc74OiM0poC2xesdPsNMYgc75fmoNmM0sIC7x4eB1qDMFJJbsOQ9li0q8 fPyPFcJWklix/RIjyAnMApoS63fpQ7QqSkzpfsgOsVZQ4uTMJywTGEVnIZk6C6FjFpKOWUg6 FjCyrGJkz03MzEkvN9rECIyKg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYV0++dtvklO2CEx2i2lufprIetHXPW66VdPrqj8p5SZLd8t59q12vhR6d bi20bJGvmoty3fwoFe2lDYbp+25Pnl91MZrjaBmPbED6JYflnGes219OF+6vMTmX83R91plH Yk2bEnb82mehp1H7Pz3saZnElg+ab+qv99pkTvhkpbv04qoKtatdSizFGYmGWsxFxYkAdYm6 0FgCAAA=
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:16:37 -0000

SGksDQoNCj5UaGUga2luZHMgb2YgbWlkZGxlYm94ZXMgeW91J3JlIHRhbGtpbmcgYWJvdXQgZG9u
J3QsIGluIG15IGV4cGVyaWVuY2UsIGdpdmUgbXVjaCB3ZWlnaHQgdG8gYW55dGhpbmcgd3JpdHRl
biBpbiBhbnkgUkZDcyBhbnl3aGVyZS4NCg0KVGhhdCdzIHdoeSBIYWRyaWVsIHNob3VsZCB3cml0
ZSBhbGwgb3VyIFJGQ3MgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K

From adam@nostrum.com  Fri Oct 18 14: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 7427C11E81DB for ; Fri, 18 Oct 2013 14:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxgRssp1omxv for ; Fri, 18 Oct 2013 14:17:40 -0700 (PDT)
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 1B3C411E8319 for ; Fri, 18 Oct 2013 14:17:34 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9ILHUjD007006 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 16:17:30 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5261A565.6070209@nostrum.com>
Date: Fri, 18 Oct 2013 16:17:25 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Paul Kyzivat , Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu>
In-Reply-To: <52619FCC.3090606@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:17:40 -0000

On 10/18/13 15:53, Paul Kyzivat wrote:
> On 10/18/13 4:44 PM, Christer Holmberg wrote:
>
>>> At some point, we have to come to peace with the fact that any 
>>> middleboxes that aren't primarily in the business of stifling 
>>> progress will need to keep pace with protocol extensions as they get 
>>> deployed.
>>
>> I really wish things worked that way :)
>
> So progress ends because middleboxes don't permit it?
>
> Maybe you are right. Then sip will go the way of h323 while the world 
> moves on to webrtc.

That only happens if we don't allow the behavior of deployed SIP 
middleboxes decimate WebRTC's capabilities.

So far, we've done a really bad job at preventing this. Certain parties 
have been taking the SIP SBC albatross and trying really hard to hang it 
on RTCWEB's neck. If we're serious about being able to do anything new, 
we need to push back.

/a

From pkyzivat@alum.mit.edu  Fri Oct 18 14:41: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 4C42D11E8352 for ; Fri, 18 Oct 2013 14:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.285
X-Spam-Level: 
X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOgafPD+igjN for ; Fri, 18 Oct 2013 14:41:34 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 3274911E8354 for ; Fri, 18 Oct 2013 14:41:19 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta14.westchester.pa.mail.comcast.net with comcast id ej1T1m0011swQuc5Elh5UX; Fri, 18 Oct 2013 21:41:05 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id elh51m00W3ZTu2S3blh5Ui; Fri, 18 Oct 2013 21:41:05 +0000
Message-ID: <5261AAF0.3030509@alum.mit.edu>
Date: Fri, 18 Oct 2013 17:41:04 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382132465; bh=OJ2/vKiieyfQYEWPi+M3JzZ9A7KctIp2ZfrelbzwsqA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LVGxccQocZCSdUcRd07b6/7bLOR6n7NVgY8ts2CAPD+JvtEHs9W9hIHa96LAc8wqD 3mvd3kbTI+gTkcY8jyn9eCCtEu0VEE/NyhD2MeMe8D+laEEPZuSkN4WXFMrMJaLzfc gMBMivpYdiikrq/BduTnD1j1nn9TXHaAwWa4i4EQ1NmDmMkAALItGiwgQiiHdoN4mC 3/Zq5VJnt4FzJGXDCktTwkfYb48YulV9p21MHUuWff/fIbFXbdg6REYuo5zaPY1HBE QnvwXTMc3Be+IA1F7MIKLzQyXKN5LnSsZVcpnLW7HKX6vEOUXniTDIEeVnnIkHC7Mu attEMZzyxN5gg==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:41:40 -0000

Christer,

I think you and I are thinking of this differently.

I'm thinking that the POFs and PANs are something new, different from 
offers and answers. They go on *between* offers and answers.

IIUC you are thinking of POFs and PANs as extended forms of offers and 
answers.

Conceptually the difference is insignificant. But practically the 
difference could be quite large regarding what changes need to be made 
to support it.

And practically it makes a difference regarding the detail of what goes 
inside a POF/PAN. (Do they have to be syntactically correct according to 
application/sdp?)

	Thanks,
	Paul

On 10/18/13 5:06 PM, Christer Holmberg wrote:
> Hi,
>
>>>>> Content-Disposition does not apply to intermediaries. So, a proxy
>>>>> that only understands application/sdp (e.g. for gate control
>>>>> purpose) will not even look at the C-D header field value for other
>>>>> bodies. And, unless such proxy understands POF/PAN, there may not be
>>>>> any media passing through...
>>>>
>>>> Right. A middlebox that doesn't understand application/sdpfrag won't
>>>> know to look at its contents and let the new streams through. And a
>>>> middlebox that sees something marked as "application/sdp" that conveys only a tiny fraction of the session will probably be just as catastrophic; I would imagine everything but the modified streams would be shut off. There's no way to win here.
>>>
>>> I think it would reject the Offer - at least that's what it should do according to 3264.
>>
>> 3264 only talks about how to process offers and answers described in SDP. It does not say how those are conveyed in sip. 3261 says that they are carried in body parts of content-type application/sdp with
>> content-disposition of 'session'. If a body part has content-type application/sdp but has a disposition other than 'session' then it isn't an offer or answer according to 3261, and so 3264 doesn't apply.
>
> 3264 says that all m- line must be present in an Offer - even if they are not modified. So, what I meant was that in case all m- lines are NOT present (in the case of a POF), such Offer would be rejected - unless the middlebox understands the POF/PAN mechanism .
> 	
>>>> At some point, we have to come to peace with the fact that any middleboxes that aren't primarily in the business of stifling progress will need to keep pace with protocol extensions as they get deployed.
>>>
>>> I really wish things worked that way :)
>>
>> So progress ends because middleboxes don't permit it?
>>
>> Maybe you are right. Then sip will go the way of h323 while the world moves on to webrtc.
>
> I think that getting explicit rejections, rather than having to try to figure out where things go wrong, is good for progress :)
>
> Anyway, it wasn't really a suggestion - I just wanted to do some brainstorming :)
>
> Regards,
>
> Christer
>


From christer.holmberg@ericsson.com  Fri Oct 18 14:55: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 9793711E8242 for ; Fri, 18 Oct 2013 14:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.531,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c-DQZWB1y8t for ; Fri, 18 Oct 2013 14:55:21 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6B52B11E8121 for ; Fri, 18 Oct 2013 14:55:17 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-d7-5261ae4167e0
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BF.F1.03802.14EA1625; Fri, 18 Oct 2013 23:55:14 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 23:55:13 +0200
From: Christer Holmberg 
To: Paul Kyzivat 
Thread-Topic: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WCAAC+BAP//xcmggABW+gD//9xWsAAGHkAA///cq+A=
Date: Fri, 18 Oct 2013 21:55:12 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu>
In-Reply-To: <5261AAF0.3030509@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvja7TusQgg9/NvBZ7/i5it5i6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZew78Z2lYId8xbq5R1gb GC/IdTFyckgImEg8unSfDcIWk7hwbz2QzcUhJHCYUeL9n5nsEM4SRollf5eydDFycLAJWEh0 /9MGMUUENCQmbVUD6WUWcJP4+38GM4gtLBAicevLeTBbRCBUou3ARCYIO0li3/PtjCA2i4Cq xNfuBawgNq+Ar8TyY7Oh9i5glpjRsxjsIE4BHYmVC+aygNiMQMd9P7WGCWKZuMSHg9eZIY4W kFiy5zyULSrx8vE/VghbSWLF9kuMIHcyC2hKrN+lD9GqKDGl+yE7xF5BiZMzn7BMYBSbhWTq LISOWUg6ZiHpWMDIsoqRPTcxMye93GgTIzBmDm75rbqD8c45kUOM0hwsSuK8H946BwkJpCeW pGanphakFsUXleakFh9iZOLglGpg3Pl9PvfdyM8nH/t+VIpYqHQoP0/eefOO6rSovj6pC71K 7mzcbQz370jNtuER8QticLnJLqj/Vip7cvDjNSs+397GszLbJUkzXW762UNCvC9rrj2xCVfP PMhd28d6+LnSZX2ud1MlRf0l9wolnCnKr5QsmC4WcFjiwXq+W8ULXZlsr1yu7hZTYinOSDTU Yi4qTgQABwWsSGcCAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 21:55:34 -0000

SGksDQoNCj4gSSB0aGluayB5b3UgYW5kIEkgYXJlIHRoaW5raW5nIG9mIHRoaXMgZGlmZmVyZW50
bHkuDQo+DQo+IEknbSB0aGlua2luZyB0aGF0IHRoZSBQT0ZzIGFuZCBQQU5zIGFyZSBzb21ldGhp
bmcgbmV3LCBkaWZmZXJlbnQgZnJvbSBvZmZlcnMgYW5kIGFuc3dlcnMuIFRoZXkgZ28gb24gKmJl
dHdlZW4qIG9mZmVycyBhbmQgYW5zd2Vycy4NCj4NCj4gSUlVQyB5b3UgYXJlIHRoaW5raW5nIG9m
IFBPRnMgYW5kIFBBTnMgYXMgZXh0ZW5kZWQgZm9ybXMgb2Ygb2ZmZXJzIGFuZCBhbnN3ZXJzLg0K
DQpJdCdzIG5vdCB0aGUgd2F5IEkgdGhpbmsgLSBJIGp1c3Qgd2FudGVkIHRvIGV4cGxvcmUgaG93
L2lmIHRoaW5ncyB3b3VsZCB3b3JrIElGIHdlIHdlcmUgdGhpbmtpbmcgbGlrZSB0aGF0LCBhbmQg
d2hhdCB0aGUgcHJvcyBhbmQgY29ucyB3b3VsZCBiZSA6KQ0KDQpXZSBoYXZlIHRvIGtlZXAgaW4g
bWluZCB0aGF0LCBubyBtYXR0ZXIgaG93IHdlIGxvb2sgYXQgaXQsIHRoZSBPZmZlcnMvQW5zd2Vy
cyBhbmQgUE9Gcy9QQU5zIGFyZSB0aWdodGx5IGNvbm5lY3RlZCwgbWVhbmluZyB0aGF0IHRoZXkg
aW1wYWN0IHRoZSBzYW1lIFNEUCBzdGF0ZSwgY2FuIGNhdXNlIHJhY2UgY29uZGl0aW9ucyBldGMu
DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KT24gMTAvMTgvMTMgNTowNiBQTSwg
Q2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+IEhpLA0KPg0KPj4+Pj4gQ29udGVudC1EaXNwb3Np
dGlvbiBkb2VzIG5vdCBhcHBseSB0byBpbnRlcm1lZGlhcmllcy4gU28sIGEgcHJveHkgDQo+Pj4+
PiB0aGF0IG9ubHkgdW5kZXJzdGFuZHMgYXBwbGljYXRpb24vc2RwIChlLmcuIGZvciBnYXRlIGNv
bnRyb2wNCj4+Pj4+IHB1cnBvc2UpIHdpbGwgbm90IGV2ZW4gbG9vayBhdCB0aGUgQy1EIGhlYWRl
ciBmaWVsZCB2YWx1ZSBmb3IgDQo+Pj4+PiBvdGhlciBib2RpZXMuIEFuZCwgdW5sZXNzIHN1Y2gg
cHJveHkgdW5kZXJzdGFuZHMgUE9GL1BBTiwgdGhlcmUgDQo+Pj4+PiBtYXkgbm90IGJlIGFueSBt
ZWRpYSBwYXNzaW5nIHRocm91Z2guLi4NCj4+Pj4NCj4+Pj4gUmlnaHQuIEEgbWlkZGxlYm94IHRo
YXQgZG9lc24ndCB1bmRlcnN0YW5kIGFwcGxpY2F0aW9uL3NkcGZyYWcgDQo+Pj4+IHdvbid0IGtu
b3cgdG8gbG9vayBhdCBpdHMgY29udGVudHMgYW5kIGxldCB0aGUgbmV3IHN0cmVhbXMgdGhyb3Vn
aC4gDQo+Pj4+IEFuZCBhIG1pZGRsZWJveCB0aGF0IHNlZXMgc29tZXRoaW5nIG1hcmtlZCBhcyAi
YXBwbGljYXRpb24vc2RwIiB0aGF0IGNvbnZleXMgb25seSBhIHRpbnkgZnJhY3Rpb24gb2YgdGhl
IHNlc3Npb24gd2lsbCBwcm9iYWJseSBiZSBqdXN0IGFzIGNhdGFzdHJvcGhpYzsgSSB3b3VsZCBp
bWFnaW5lIGV2ZXJ5dGhpbmcgYnV0IHRoZSBtb2RpZmllZCBzdHJlYW1zIHdvdWxkIGJlIHNodXQg
b2ZmLiBUaGVyZSdzIG5vIHdheSB0byB3aW4gaGVyZS4NCj4+Pg0KPj4+IEkgdGhpbmsgaXQgd291
bGQgcmVqZWN0IHRoZSBPZmZlciAtIGF0IGxlYXN0IHRoYXQncyB3aGF0IGl0IHNob3VsZCBkbyBh
Y2NvcmRpbmcgdG8gMzI2NC4NCj4+DQo+PiAzMjY0IG9ubHkgdGFsa3MgYWJvdXQgaG93IHRvIHBy
b2Nlc3Mgb2ZmZXJzIGFuZCBhbnN3ZXJzIGRlc2NyaWJlZCBpbiANCj4+IFNEUC4gSXQgZG9lcyBu
b3Qgc2F5IGhvdyB0aG9zZSBhcmUgY29udmV5ZWQgaW4gc2lwLiAzMjYxIHNheXMgdGhhdCB0aGV5
IGFyZSBjYXJyaWVkIGluIGJvZHkgcGFydHMgb2YgY29udGVudC10eXBlIGFwcGxpY2F0aW9uL3Nk
cCB3aXRoIGNvbnRlbnQtZGlzcG9zaXRpb24gb2YgJ3Nlc3Npb24nLiBJZiBhIGJvZHkgcGFydCBo
YXMgY29udGVudC10eXBlIGFwcGxpY2F0aW9uL3NkcCBidXQgaGFzIGEgZGlzcG9zaXRpb24gb3Ro
ZXIgdGhhbiAnc2Vzc2lvbicgdGhlbiBpdCBpc24ndCBhbiBvZmZlciBvciBhbnN3ZXIgYWNjb3Jk
aW5nIHRvIDMyNjEsIGFuZCBzbyAzMjY0IGRvZXNuJ3QgYXBwbHkuDQo+DQo+IDMyNjQgc2F5cyB0
aGF0IGFsbCBtLSBsaW5lIG11c3QgYmUgcHJlc2VudCBpbiBhbiBPZmZlciAtIGV2ZW4gaWYgdGhl
eSBhcmUgbm90IG1vZGlmaWVkLiBTbywgd2hhdCBJIG1lYW50IHdhcyB0aGF0IGluIGNhc2UgYWxs
IG0tIGxpbmVzIGFyZSBOT1QgcHJlc2VudCAoaW4gdGhlIGNhc2Ugb2YgYSBQT0YpLCBzdWNoIE9m
ZmVyIHdvdWxkIGJlIHJlamVjdGVkIC0gdW5sZXNzIHRoZSBtaWRkbGVib3ggdW5kZXJzdGFuZHMg
dGhlIFBPRi9QQU4gbWVjaGFuaXNtIC4NCj4gCQ0KPj4+PiBBdCBzb21lIHBvaW50LCB3ZSBoYXZl
IHRvIGNvbWUgdG8gcGVhY2Ugd2l0aCB0aGUgZmFjdCB0aGF0IGFueSBtaWRkbGVib3hlcyB0aGF0
IGFyZW4ndCBwcmltYXJpbHkgaW4gdGhlIGJ1c2luZXNzIG9mIHN0aWZsaW5nIHByb2dyZXNzIHdp
bGwgbmVlZCB0byBrZWVwIHBhY2Ugd2l0aCBwcm90b2NvbCBleHRlbnNpb25zIGFzIHRoZXkgZ2V0
IGRlcGxveWVkLg0KPj4+DQo+Pj4gSSByZWFsbHkgd2lzaCB0aGluZ3Mgd29ya2VkIHRoYXQgd2F5
IDopDQo+Pg0KPj4gU28gcHJvZ3Jlc3MgZW5kcyBiZWNhdXNlIG1pZGRsZWJveGVzIGRvbid0IHBl
cm1pdCBpdD8NCj4+DQo+PiBNYXliZSB5b3UgYXJlIHJpZ2h0LiBUaGVuIHNpcCB3aWxsIGdvIHRo
ZSB3YXkgb2YgaDMyMyB3aGlsZSB0aGUgd29ybGQgbW92ZXMgb24gdG8gd2VicnRjLg0KPg0KPiBJ
IHRoaW5rIHRoYXQgZ2V0dGluZyBleHBsaWNpdCByZWplY3Rpb25zLCByYXRoZXIgdGhhbiBoYXZp
bmcgdG8gdHJ5IHRvIA0KPiBmaWd1cmUgb3V0IHdoZXJlIHRoaW5ncyBnbyB3cm9uZywgaXMgZ29v
ZCBmb3IgcHJvZ3Jlc3MgOikNCj4NCj4gQW55d2F5LCBpdCB3YXNuJ3QgcmVhbGx5IGEgc3VnZ2Vz
dGlvbiAtIEkganVzdCB3YW50ZWQgdG8gZG8gc29tZSANCj4gYnJhaW5zdG9ybWluZyA6KQ0KPg0K
PiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KDQo=

From internet-drafts@ietf.org  Fri Oct 18 14:59: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 85CF511E8177; Fri, 18 Oct 2013 14:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level: 
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRu-s9o15349; Fri, 18 Oct 2013 14:58:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3720D11E8180; Fri, 18 Oct 2013 14:58:52 -0700 (PDT)
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.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131018215852.21887.32914.idtracker@ietfa.amsl.com>
Date: Fri, 18 Oct 2013 14:58:52 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 21:59:09 -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           : UDP Transport Layer (UDPTL) over Datagram Transport Laye=
r Security (DTLS)
	Author(s)       : Christer Holmberg
                          Ivo Sedlacek
                          Gonzalo Salgueiro
	Filename        : draft-ietf-mmusic-udptl-dtls-00.txt
	Pages           : 15
	Date            : 2013-10-18

Abstract:
   This document specifies how the UDP Transport Layer (UDPTL) protocol
   can be transported over the Datagram Transport Layer Security (DTLS)
   protocol, how the usage of UDPTL over DTLS is indicated in the
   Session Description Protocol (SDP), and how UDPTL over DTLS is
   negotiated in a session established using the Session Initiation
   Protocol (SIP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From emcho@sip-communicator.org  Fri Oct 18 15:03: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 0FD7821F9B6A for ; Fri, 18 Oct 2013 15:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-1.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8skCSVNyW-r for ; Fri, 18 Oct 2013 15:02:58 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 160D211E8104 for ; Fri, 18 Oct 2013 15:02:54 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id z10so5407685pdj.3 for ; Fri, 18 Oct 2013 15:02:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BlVfoG1e2M1upFtuC7OE//zCsKHkZlD87PLmSA366zg=; b=ZYh61pgbC+PkIo+54OdDd1eDqktb+8UTTMVDwdrkQvumysiq175t8hzg0fDpaVqzcT WJBmSRT5ar6tdqeIlVJB01hY7zqRBe6njZlmnisVm85A0Hdv1bhJkPfg0Se48tRvt+z2 YXBz9VUoR9g02rWOOrYMn/teiDY3NrM2y67B7Tpx7AEd1b+IdM2u3yjqjrB2w16Tzyu5 BzmeWFqEUL27TE9+OuuiLm3G32VGsXeN0U+qkNZxk6e18zFRxKsLdY5ka2TNW5FTW6m1 6KfmIzQ1OwSgCjM2nduOyslbAstjkQjARhAbWN9Jhdd2xRD8Xu647+nrFIvuFV+vykBh +VjA==
X-Gm-Message-State: ALoCoQm20yvPXGQQyD0COki0OV4+W1Zbf1vJ4TcFZFprhpRuTi0NVKafbirtzPW3e18yTUDTxlDL
X-Received: by 10.66.25.208 with SMTP id e16mr3516731pag.131.1382133310625; Fri, 18 Oct 2013 14:55:10 -0700 (PDT)
Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [2607:f8b0:400e:c01::234]) by mx.google.com with ESMTPSA id vz4sm6853112pab.11.2013.10.18.14.55.09 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 14:55:09 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id wy17so1450552pbc.39 for ; Fri, 18 Oct 2013 14:55:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.66.188.203 with SMTP id gc11mr5385234pac.63.1382133309705; Fri, 18 Oct 2013 14:55:09 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Fri, 18 Oct 2013 14:55:09 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Fri, 18 Oct 2013 14:55:09 -0700 (PDT)
In-Reply-To: <526146F2.1060203@ericsson.com>
References: <526146F2.1060203@ericsson.com>
Date: Fri, 18 Oct 2013 16:55:09 -0500
Message-ID: 
From: Emil Ivov 
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
Content-Type: multipart/alternative; boundary=047d7bf0c664f52bb104e90afc48
Cc: mmusic 
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 22:03:02 -0000

--047d7bf0c664f52bb104e90afc48
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is obviously an important part of BUNDLE so I support this work.

As to the milestone: ok either way.

--sent from my mobile
On 18 Oct 2013 09:34, "Ari Ker=E4nen"  wrote:

> Hi all,
>
> When single 5-tuple is used for media associated with multiple SDP media
> descriptions (i.e., Bundle) the WG has identified the need to analyze and
> specify applicability and impact of different attributes on media
> description bundling.
>
> The draft-nandakumar-mmusic-sdp-**mux-attributes-04 ("Framework for SDP
> Attributes when Multiplexing") provides this analysis. The draft has been
> presented and discussed over the past few meetings and the feedback on bo=
th
> the need for the work and the draft itself has been positive.
>
> Based on the above, we would like to propose adding a new milestone for
> and adoption of draft-nandakumar-mmusic-sdp-**mux-attributes-04 as a WG
> item for that milestone.
>
> If you have any comments or concerns with the above, please let us know n=
o
> later than November 1st, 2013.
>
>
> Thanks,
> Ari & Flemming
> (MMUSIC co-chairs)
> ______________________________**_________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/**listinfo/mmusic
>

--047d7bf0c664f52bb104e90afc48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


This is obviously an important part of BUNDLE so I support t=
his work.


As to the milestone: ok either way.


--sent from my mobile


On 18 Oct 2013 09:34, "Ari Ker=E4nen" =
<ari.keranen@ericsson.com> wrote:

Hi all,



When single 5-tuple is used for media associated with multiple SDP media de=
scriptions (i.e., Bundle) the WG has identified the need to analyze and spe=
cify applicability and impact of different attributes on media description =
bundling.




The draft-nandakumar-mmusic-sdp-mux-attributes-04 ("Framework f=
or SDP Attributes when Multiplexing") provides this analysis. The draf=
t has been presented and discussed over the past few meetings and the feedb=
ack on both the need for the work and the draft itself has been positive.



Based on the above, we would like to propose adding a new milestone for

and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as a W=
G item for that milestone.



If you have any comments or concerns with the above, please let us know no =
later than November 1st, 2013.





Thanks,

Ari & Flemming

(MMUSIC co-chairs)

_______________________________________________

mmusic mailing list

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




--047d7bf0c664f52bb104e90afc48--

From emcho@sip-communicator.org  Fri Oct 18 15:11: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 A8AB821F99B0 for ; Fri, 18 Oct 2013 15:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.428,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tgh3nSW4dros for ; Fri, 18 Oct 2013 15:11:42 -0700 (PDT)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09421F995A for ; Fri, 18 Oct 2013 15:11:39 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id ro12so4410614pbb.13 for ; Fri, 18 Oct 2013 15:11:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q0kAl9+QltVOTeZeDhzWTCmWKUx9GwN3HJd5Z0rVLtI=; b=klzW/j8cZv13T2NBSfkxbeThMjcXJucn91zGohclKnaewx4N1gp1DDYq6LzeMjMhvS RnxGb/uizrAowfLgkLnppDIfV3MRfU6gN4zuGdlysKqWfW+Gc3H84Jz2TfvUhFqJXi9g qJ+tvUSSOkUUoAoqXazjI5aLd9+w5L6pfENjlRx7aNuXMpr4VpBg5Z7MJnpzh4yNYK2/ Q2hiZOS/DKib4kbi6zuHu0fCK9JnIxiIM4mCpqG+TaJKtTJLYy9EZe6Xbl/BrGpKpChF BSO+TCIIja6vrLwSGw7Mc91qIPDIKV0MESIws3ZDI6l7XpiMrjtXbio6a85DgLxJte0F bIPQ==
X-Gm-Message-State: ALoCoQnuiMx9uKxJUkaNVPTqbb7xTvjZdhZfPfbzAAPTMjvhRQORdj0SVxKEIX7IlAQ7hEhyfrV3
X-Received: by 10.67.21.130 with SMTP id hk2mr5713797pad.76.1382134299095; Fri, 18 Oct 2013 15:11:39 -0700 (PDT)
Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [2607:f8b0:400e:c01::230]) by mx.google.com with ESMTPSA id ab4sm4538326pbc.43.2013.10.18.15.11.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 15:11:38 -0700 (PDT)
Received: by mail-pb0-f48.google.com with SMTP id ma3so4403821pbc.21 for ; Fri, 18 Oct 2013 15:11:38 -0700 (PDT)
X-Received: by 10.69.0.201 with SMTP id ba9mr17440pbd.184.1382134298634; Fri, 18 Oct 2013 15:11:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Fri, 18 Oct 2013 15:11:18 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>
From: Emil Ivov 
Date: Fri, 18 Oct 2013 17:11:18 -0500
Message-ID: 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b2e0acde70bd904e90b37c8
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 22:11:46 -0000

--047d7b2e0acde70bd904e90b37c8
Content-Type: text/plain; charset=ISO-8859-1

I do think that a different MIME type makes more sense here for the reasons
Paul explained.

It might be worth adding that the same MIME type would be used when sending
candidate updates with Trickle ICE for SIP, which to me at least, makes a
lot of sense.

--sent from my mobile
On 18 Oct 2013 16:55, "Christer Holmberg" 
wrote:

> Hi,
>
> > I think you and I are thinking of this differently.
> >
> > I'm thinking that the POFs and PANs are something new, different from
> offers and answers. They go on *between* offers and answers.
> >
> > IIUC you are thinking of POFs and PANs as extended forms of offers and
> answers.
>
> It's not the way I think - I just wanted to explore how/if things would
> work IF we were thinking like that, and what the pros and cons would be :)
>
> We have to keep in mind that, no matter how we look at it, the
> Offers/Answers and POFs/PANs are tightly connected, meaning that they
> impact the same SDP state, can cause race conditions etc.
>
> Regards,
>
> Christer
>
>
>
>
>
> On 10/18/13 5:06 PM, Christer Holmberg wrote:
> > Hi,
> >
> >>>>> Content-Disposition does not apply to intermediaries. So, a proxy
> >>>>> that only understands application/sdp (e.g. for gate control
> >>>>> purpose) will not even look at the C-D header field value for
> >>>>> other bodies. And, unless such proxy understands POF/PAN, there
> >>>>> may not be any media passing through...
> >>>>
> >>>> Right. A middlebox that doesn't understand application/sdpfrag
> >>>> won't know to look at its contents and let the new streams through.
> >>>> And a middlebox that sees something marked as "application/sdp" that
> conveys only a tiny fraction of the session will probably be just as
> catastrophic; I would imagine everything but the modified streams would be
> shut off. There's no way to win here.
> >>>
> >>> I think it would reject the Offer - at least that's what it should do
> according to 3264.
> >>
> >> 3264 only talks about how to process offers and answers described in
> >> SDP. It does not say how those are conveyed in sip. 3261 says that they
> are carried in body parts of content-type application/sdp with
> content-disposition of 'session'. If a body part has content-type
> application/sdp but has a disposition other than 'session' then it isn't an
> offer or answer according to 3261, and so 3264 doesn't apply.
> >
> > 3264 says that all m- line must be present in an Offer - even if they
> are not modified. So, what I meant was that in case all m- lines are NOT
> present (in the case of a POF), such Offer would be rejected - unless the
> middlebox understands the POF/PAN mechanism .
> >
> >>>> At some point, we have to come to peace with the fact that any
> middleboxes that aren't primarily in the business of stifling progress will
> need to keep pace with protocol extensions as they get deployed.
> >>>
> >>> I really wish things worked that way :)
> >>
> >> So progress ends because middleboxes don't permit it?
> >>
> >> Maybe you are right. Then sip will go the way of h323 while the world
> moves on to webrtc.
> >
> > I think that getting explicit rejections, rather than having to try to
> > figure out where things go wrong, is good for progress :)
> >
> > Anyway, it wasn't really a suggestion - I just wanted to do some
> > brainstorming :)
> >
> > Regards,
> >
> > Christer
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--047d7b2e0acde70bd904e90b37c8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I do think that a different MIME type makes=
 more sense here for the reasons Paul explained.
It might be worth ad=
ding that the same MIME type would be used when sending candidate updates w=
ith Trickle ICE for SIP, which to me at least, makes a lot of sense.



--sent from my mobile


On 18 Oct 2013 16:55, "Christer Holmberg&qu=
ot; <christer.holmberg@ericsson.com> wrote:



Hi,



> I think you and I are thinking of this differently.

>

> I'm thinking that the POFs and PANs are something new, different f=
rom offers and answers. They go on *between* offers and answers.

>

> IIUC you are thinking of POFs and PANs as extended forms of offers and=
 answers.



It's not the way I think - I just wanted to explore how/if things would=
 work IF we were thinking like that, and what the pros and cons would be :)=




We have to keep in mind that, no matter how we look at it, the Offers/Answe=
rs and POFs/PANs are tightly connected, meaning that they impact the same S=
DP state, can cause race conditions etc.



Regards,



Christer











On 10/18/13 5:06 PM, Christer Holmberg wrote:

> Hi,

>

>>>>> Content-Disposition does not apply to intermediaries. =
So, a proxy

>>>>> that only understands application/sdp (e.g. for gate c=
ontrol

>>>>> purpose) will not even look at the C-D header field va=
lue for

>>>>> other bodies. And, unless such proxy understands POF/P=
AN, there

>>>>> may not be any media passing through...

>>>>

>>>> Right. A middlebox that doesn't understand application=
/sdpfrag

>>>> won't know to look at its contents and let the new str=
eams through.

>>>> And a middlebox that sees something marked as "applic=
ation/sdp" that conveys only a tiny fraction of the session will proba=
bly be just as catastrophic; I would imagine everything but the modified st=
reams would be shut off. There's no way to win here.




>>>

>>> I think it would reject the Offer - at least that's what i=
t should do according to 3264.

>>

>> 3264 only talks about how to process offers and answers described =
in

>> SDP. It does not say how those are conveyed in sip. 3261 says that=
 they are carried in body parts of content-type application/sdp with conten=
t-disposition of 'session'. If a body part has content-type applica=
tion/sdp but has a disposition other than 'session' then it isn'=
;t an offer or answer according to 3261, and so 3264 doesn't apply.




>

> 3264 says that all m- line must be present in an Offer - even if they =
are not modified. So, what I meant was that in case all m- lines are NOT pr=
esent (in the case of a POF), such Offer would be rejected - unless the mid=
dlebox understands the POF/PAN mechanism .




>

>>>> At some point, we have to come to peace with the fact that=
 any middleboxes that aren't primarily in the business of stifling prog=
ress will need to keep pace with protocol extensions as they get deployed.<=
br>



>>>

>>> I really wish things worked that way :)

>>

>> So progress ends because middleboxes don't permit it?

>>

>> Maybe you are right. Then sip will go the way of h323 while the wo=
rld moves on to webrtc.

>

> I think that getting explicit rejections, rather than having to try to=


> figure out where things go wrong, is good for progress :)

>

> Anyway, it wasn't really a suggestion - I just wanted to do some
> brainstorming :)

>

> Regards,

>

> Christer

>



_______________________________________________

mmusic mailing list

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






--047d7b2e0acde70bd904e90b37c8--

From adam@nostrum.com  Fri Oct 18 15:40: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 3F0CC21F9AD5 for ; Fri, 18 Oct 2013 15:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.452
X-Spam-Level: 
X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXLBoNGlJdE5 for ; Fri, 18 Oct 2013 15:40:01 -0700 (PDT)
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 7218F21F9B12 for ; Fri, 18 Oct 2013 15:40:01 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9IMdve0015946 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 17:39:57 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5261B8B8.4080803@nostrum.com>
Date: Fri, 18 Oct 2013 17:39:52 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <5261A39A.1060505@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C344F@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C344F@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 22:40:02 -0000

On 10/18/13 16:16, Christer Holmberg wrote:
> That's why Hadriel should write all our RFCs

You know, there was a point in time at which I would have suspected that 
would work. I would have believed that it would have produced specs that 
would, at the very least, play nicely with middleboxes. And vice-versa. 
Because if there's one person playing in this space who understands 
middleboxes, I would think Hadriel is that person.

But consider the INSIPID effort, which Hadriel did, in fact, author.

At the end of a year and a half of hashing out details, Hadriel 
explained (in a personal, not corporate capacity) that the resulting 
identifier is *unlikely* to make it through middleboxes. Keep in mind 
that the only reason for this work to have occurred is to create an 
identifier that makes it through middleboxes.

Um. What?

 From that, I think the lesson to take away is that middleboxes are 
going to do what middleboxes do, and that we are utter fools for trying 
to appease them. I think it also demonstrates that the Faustian deals we 
cut every time we concede defeat to middlebox behavior are even more ill 
conceived than we first imagined: at least Mephistopheles honored his 
end of the deal.

I think this also tells us that no one can act as an emissary for 
middleboxes, even someone as experienced as Hadriel. Claims about what 
middleboxes do, don't do, can do, or won't do should be viewed with 
extreme skepticism. Any such statements are so heavily caveated as to be 
devoid of meaning.

To be clear, this isn't intended as a smear against Hadriel. When he 
delivered the message that INSIPID was pretty well worthless, he did so 
exactly as a messenger and not as a perpetrator. The failure of 
middleboxes to use this mechanism we designed exclusively for them is 
not his fault. No, this is a criticism leveled at middlebox vendors in 
general. Even where the IETF makes concessions to middleboxes, the 
middleboxes don't play nicely with those concessions. Nothing could have 
been a more direct pander to middleboxes than INSIPID, and its failure 
at their hands is apparently complete and without mitigation.

The writing on the wall is clear. This kowtowing to unknowable and 
infinitely mutable middlebox requirements is both unproductive and 
harmful to innovation. It needs to stop. And it needs to stop now. It's 
done untold damage to SIP's ability to innovate. I have no interest in 
inviting the rampaging bull that gored SIP into WebRTC's home. I'm done 
entertaining arguments that we need to fetter innovation in order to 
accommodate implementations that have no interest in what the IETF has 
to say.

/a

P.S. Yes, I know your comment was meant to be tongue-in-cheek, but it 
threw into vivid relief the reality that the IETF's attempts to play 
nice with middleboxes have been utterly unrequited.

From pkyzivat@alum.mit.edu  Fri Oct 18 16:18: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 51FB821F9C55 for ; Fri, 18 Oct 2013 16:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Level: 
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsJGbNiylZby for ; Fri, 18 Oct 2013 16:18:13 -0700 (PDT)
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 47BF621F9C81 for ; Fri, 18 Oct 2013 16:18:13 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id enHW1m0010SCNGk59nJCgL; Fri, 18 Oct 2013 23:18:12 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id enJC1m00N3ZTu2S3VnJCWD; Fri, 18 Oct 2013 23:18:12 +0000
Message-ID: <5261C1B3.2050507@alum.mit.edu>
Date: Fri, 18 Oct 2013 19:18:11 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Adam Roach 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <5261A39A.1060505@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C344F@ESESSMB209.ericsson.se> <5261B8B8.4080803@nostrum.com>
In-Reply-To: <5261B8B8.4080803@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382138292; bh=BIzHo75Px/WQFY6zK4wy/O1QnC42eCShANJe+wnROQk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bgxYibfIewOF3D4Bn+PBe0RicJI2neF/I6e+YFUH/JlW9TTQ1EkgRU9CjYs2iOwGQ VIc88YYc06k3d5O/ARtVWcfaMx9D6jPc15K36oW8jcvqH5fjV9qdybCD/txsj0zEpn czDcuMtugP2tCH8/SjHO75MjweN8vA/jOE+QHYQjEf05ApgUF2HDsUh7DePAN06Eou +Ujd2I7iSHKWgCYedda7IWAFdWtrZWp/0Evd1NU2B8NpgY7jFkghYoDpoJHV1IOM1m BPcL+gN5LswqcRVlXDNceBnIyBrb2XFIBHt7rtwmu41orrendF5g4zdC/nkmicY28G Nr5gonJVE11CQ==
Cc: "mmusic@ietf.org" , Christer Holmberg 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 23:18:19 -0000

Adam,

I'm pretty sure that Hadriel will speak up in a minute and say that the 
SBCs only do what they do because that is what administrators want them 
to do.

So on one hand it is the administrators that we should curse, not the 
vendors of middleboxes.

OTOH, ISTM that the administrators and middlebox vendors are 
codependent. Administrators do stuff because they can, even if it is a 
bad idea.

I guess ultimately it is a competition. Admins want to forbid anything 
they don't fully understand. But that prevents introduction of new stuff.

So ultimately I think we just have to define the new stuff, even if the 
middleboxes will often break it. And then let demand push the admins and 
middlebox vendors to allow it.

	Thanks,
	Paul

On 10/18/13 6:39 PM, Adam Roach wrote:
> On 10/18/13 16:16, Christer Holmberg wrote:
>> That's why Hadriel should write all our RFCs
>
> You know, there was a point in time at which I would have suspected that
> would work. I would have believed that it would have produced specs that
> would, at the very least, play nicely with middleboxes. And vice-versa.
> Because if there's one person playing in this space who understands
> middleboxes, I would think Hadriel is that person.
>
> But consider the INSIPID effort, which Hadriel did, in fact, author.
>
> At the end of a year and a half of hashing out details, Hadriel
> explained (in a personal, not corporate capacity) that the resulting
> identifier is *unlikely* to make it through middleboxes. Keep in mind
> that the only reason for this work to have occurred is to create an
> identifier that makes it through middleboxes.
>
> Um. What?
>
>  From that, I think the lesson to take away is that middleboxes are
> going to do what middleboxes do, and that we are utter fools for trying
> to appease them. I think it also demonstrates that the Faustian deals we
> cut every time we concede defeat to middlebox behavior are even more ill
> conceived than we first imagined: at least Mephistopheles honored his
> end of the deal.
>
> I think this also tells us that no one can act as an emissary for
> middleboxes, even someone as experienced as Hadriel. Claims about what
> middleboxes do, don't do, can do, or won't do should be viewed with
> extreme skepticism. Any such statements are so heavily caveated as to be
> devoid of meaning.
>
> To be clear, this isn't intended as a smear against Hadriel. When he
> delivered the message that INSIPID was pretty well worthless, he did so
> exactly as a messenger and not as a perpetrator. The failure of
> middleboxes to use this mechanism we designed exclusively for them is
> not his fault. No, this is a criticism leveled at middlebox vendors in
> general. Even where the IETF makes concessions to middleboxes, the
> middleboxes don't play nicely with those concessions. Nothing could have
> been a more direct pander to middleboxes than INSIPID, and its failure
> at their hands is apparently complete and without mitigation.
>
> The writing on the wall is clear. This kowtowing to unknowable and
> infinitely mutable middlebox requirements is both unproductive and
> harmful to innovation. It needs to stop. And it needs to stop now. It's
> done untold damage to SIP's ability to innovate. I have no interest in
> inviting the rampaging bull that gored SIP into WebRTC's home. I'm done
> entertaining arguments that we need to fetter innovation in order to
> accommodate implementations that have no interest in what the IETF has
> to say.
>
> /a
>
> P.S. Yes, I know your comment was meant to be tongue-in-cheek, but it
> threw into vivid relief the reality that the IETF's attempts to play
> nice with middleboxes have been utterly unrequited.
>


From pkyzivat@alum.mit.edu  Fri Oct 18 16:24: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 8833011E80E6 for ; Fri, 18 Oct 2013 16:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.29
X-Spam-Level: 
X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.147,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8DsusoIIvyU for ; Fri, 18 Oct 2013 16:24:07 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id B466F11E80E3 for ; Fri, 18 Oct 2013 16:24:06 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id em2k1m0020QuhwU56nQ6JV; Fri, 18 Oct 2013 23:24:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id enQ51m00u3ZTu2S3NnQ68y; Fri, 18 Oct 2013 23:24:06 +0000
Message-ID: <5261C314.8020001@alum.mit.edu>
Date: Fri, 18 Oct 2013 19:24:04 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se> 
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=1382138646; bh=vROW0cxRfrw3Yist5E2goHpHnsFqTAO0zKyCc5kcIDM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZVrV+EMhnhTpPM7xsyC6AmaSTzZo7yQ25O/GqaZX8qwVEt7j5z9iG97wBapIEekbo ARsehTmUEpXQb2TwqbCZBj12gLcxYF+Jn1a+C0gyZNKBK8a014xRXlNJlDaZu0K+Mf kOR/fOkUawhffBwqQR27vh5VNprdoSGS9Ho5pEycewehYqj0GORVnoE1KgavsJkmcs D9ur7L00AkZ0AFc+czYxLWfo9bCmNyYl72hp6AcDZ1XCOuZroiOfXuYTU6iIQ7nxsA 6E3boicy5h3cL3zn2Oqy53caLbfNV+M9acY0oL4pz9lM8EW6eEqswM2p7QVpVpj2+S GGOvsWBxIsVMg==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 23:24:11 -0000

On 10/18/13 6:11 PM, Emil Ivov wrote:
> I do think that a different MIME type makes more sense here for the
> reasons Paul explained.

In the sip world, we may *also* want a new content-disposition. Using 
'session' as the content-disposition with the new content type implies 
that the the body is just a different representation of an offer or 
answer. (We were once considering exactly that with SDPng.)

We *might* want to think of it that way, or not.

> It might be worth adding that the same MIME type would be used when
> sending candidate updates with Trickle ICE for SIP, which to me at
> least, makes a lot of sense.

I still wonder why trickle ICE needs a *different* mechanism for partial 
offers. Couldn't we just use this one?

	Thanks,
	Paul

> --sent from my mobile
>
> On 18 Oct 2013 16:55, "Christer Holmberg"
> >
> wrote:
>
>     Hi,
>
>      > I think you and I are thinking of this differently.
>      >
>      > I'm thinking that the POFs and PANs are something new, different
>     from offers and answers. They go on *between* offers and answers.
>      >
>      > IIUC you are thinking of POFs and PANs as extended forms of
>     offers and answers.
>
>     It's not the way I think - I just wanted to explore how/if things
>     would work IF we were thinking like that, and what the pros and cons
>     would be :)
>
>     We have to keep in mind that, no matter how we look at it, the
>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>     they impact the same SDP state, can cause race conditions etc.
>
>     Regards,
>
>     Christer
>
>
>
>
>
>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>      > Hi,
>      >
>      >>>>> Content-Disposition does not apply to intermediaries. So, a proxy
>      >>>>> that only understands application/sdp (e.g. for gate control
>      >>>>> purpose) will not even look at the C-D header field value for
>      >>>>> other bodies. And, unless such proxy understands POF/PAN, there
>      >>>>> may not be any media passing through...
>      >>>>
>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>      >>>> won't know to look at its contents and let the new streams
>     through.
>      >>>> And a middlebox that sees something marked as
>     "application/sdp" that conveys only a tiny fraction of the session
>     will probably be just as catastrophic; I would imagine everything
>     but the modified streams would be shut off. There's no way to win here.
>      >>>
>      >>> I think it would reject the Offer - at least that's what it
>     should do according to 3264.
>      >>
>      >> 3264 only talks about how to process offers and answers described in
>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>     that they are carried in body parts of content-type application/sdp
>     with content-disposition of 'session'. If a body part has
>     content-type application/sdp but has a disposition other than
>     'session' then it isn't an offer or answer according to 3261, and so
>     3264 doesn't apply.
>      >
>      > 3264 says that all m- line must be present in an Offer - even if
>     they are not modified. So, what I meant was that in case all m-
>     lines are NOT present (in the case of a POF), such Offer would be
>     rejected - unless the middlebox understands the POF/PAN mechanism .
>      >
>      >>>> At some point, we have to come to peace with the fact that any
>     middleboxes that aren't primarily in the business of stifling
>     progress will need to keep pace with protocol extensions as they get
>     deployed.
>      >>>
>      >>> I really wish things worked that way :)
>      >>
>      >> So progress ends because middleboxes don't permit it?
>      >>
>      >> Maybe you are right. Then sip will go the way of h323 while the
>     world moves on to webrtc.
>      >
>      > I think that getting explicit rejections, rather than having to
>     try to
>      > figure out where things go wrong, is good for progress :)
>      >
>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>      > brainstorming :)
>      >
>      > Regards,
>      >
>      > Christer
>      >
>
>     _______________________________________________
>     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 emcho@sip-communicator.org  Fri Oct 18 16:41: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 4A1BF11E80E4 for ; Fri, 18 Oct 2013 16:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.367,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBlYBKErZx8I for ; Fri, 18 Oct 2013 16:41:07 -0700 (PDT)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDE621F9CAC for ; Fri, 18 Oct 2013 16:41:07 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id kl14so5265754pab.39 for ; Fri, 18 Oct 2013 16:41:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LT0aIEdMNAtZA1TUxbQhQuoew03/SUFEY0PiIY6ZGjA=; b=AQ4/hVEGUzRoCdtLFnZlBcqQgFcAypcG4OjLL01IYLKHTRHh1rGaNgD+VAeWgItefk NS0BQlAbkiAhtZN87GcMkj077sca27oa7m/3h4dcNOcnz6pQ4YCbtGB5DdN5/L8jjI3t WKHNzSiAgBNK6bRtOZhLpxQ4KnUOqMQzqZNdiUekRd7DlqU/KsMYlZUhEpYa6cWHNXRN Y/n/mqh/yheN46jyhjAbypUK8t6nGYsnr4xAJfSw3oIJRsVJmeC/kvtvgdmtAwj36qBk radVW0hggSsB1QAJLSqky0XVdrViqiPbiUh69WOiQY+gI9TcfM3VGVt04//aaoG6fObf Zy5A==
X-Gm-Message-State: ALoCoQn8otJQhBeU4FDdR8FkQAq9IGljvtiugbNKY7xni5f2y6dYPaRBlVO7KgUrisklIKoW5WLa
X-Received: by 10.68.169.161 with SMTP id af1mr5501527pbc.22.1382139666755; Fri, 18 Oct 2013 16:41:06 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [2607:f8b0:400e:c02::22b]) by mx.google.com with ESMTPSA id hz10sm4823291pbc.36.2013.10.18.16.41.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 16:41:06 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id z10so5471027pdj.16 for ; Fri, 18 Oct 2013 16:41:06 -0700 (PDT)
X-Received: by 10.68.21.66 with SMTP id t2mr5373537pbe.151.1382139666200; Fri, 18 Oct 2013 16:41:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Fri, 18 Oct 2013 16:40:46 -0700 (PDT)
In-Reply-To: <5261C314.8020001@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>
From: Emil Ivov 
Date: Fri, 18 Oct 2013 18:40:46 -0500
Message-ID: 
To: Paul Kyzivat 
Content-Type: text/plain; charset=ISO-8859-1
Cc: mmusic 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 23:41:11 -0000

On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat  wrote:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies that
> the the body is just a different representation of an offer or answer. (We
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>> >
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, there
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers described
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     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



-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From christer.holmberg@ericsson.com  Fri Oct 18 23:10: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 94B6F11E8168 for ; Fri, 18 Oct 2013 23:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level: 
X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.521,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSqlXDVbGMIg for ; Fri, 18 Oct 2013 23:10:41 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1F111E8176 for ; Fri, 18 Oct 2013 23:10:39 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-85-5262225e97bb
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C5.63.03802.E5222625; Sat, 19 Oct 2013 08:10:39 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 08:10:38 +0200
From: Christer Holmberg 
To: Emil Ivov , Paul Kyzivat 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eQ==
Date: Sat, 19 Oct 2013 06:10:38 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW68UlKQwYM93BZrdk5gsZi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgyWtb+ZCt4aVBxdf8hlgbG NpUuRk4OCQETiWsTnjJB2GISF+6tZwOxhQQOM0p0/i/oYuQCspcwSjxq6WbsYuTgYBOwkOj+ pw1SIyLgKvH4xiuwemYBGYkZZxvB5ggLeEn0H7zNBFHjLfH//lUWCNtJ4t7DbWBxFgFViZvH f4DFeQXcJFZvWcoOsWsSq8TsWcvYQRKcAoESbdubmUFsRqDjvp9awwSxTFzi1pP5UEcLSCzZ c54ZwhaVePn4HytEjY7Egt2foI7Tlli28DUzxDJBiZMzn7BMYBSdhWTULCQts5C0zELSsoCR ZRUje25iZk56udEmRmB0HNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAKJE15dluJeajvx5ue8F24rGg/emdKt1vl99aufO/u2JNZ//dxTVfn25mvbRW S+b8/ZPtOQbhXavKuUJuxCqcPtBuuMJm6qRLJh/e+Zk4L1qkz+RjaFRRpO04oaXnvvPaqR92 rFlzX1TwstgukQeTL/iurn05eeqFs1PeXfneqRZ7qcXgdt4fpyglluKMREMt5qLiRABIG0H1 XAIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 06:10:45 -0000

Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).

So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov  wrote:


On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat  wrote=
:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies th=
at
> the the body is just a different representation of an offer or answer. (W=
e
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>> >
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, the=
re
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers describe=
d
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     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



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

From christer.holmberg@ericsson.com  Fri Oct 18 23:21: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 1CE0F21F9F4F for ; Fri, 18 Oct 2013 23:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.737
X-Spam-Level: 
X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.512,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RATK5k1eVEoY for ; Fri, 18 Oct 2013 23:20:59 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD0C221F9F40 for ; Fri, 18 Oct 2013 23:20:58 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-5a-526224c9de70
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 24.C3.03802.9C422625; Sat, 19 Oct 2013 08:20:57 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 08:20:57 +0200
From: Christer Holmberg 
To: Paul Kyzivat , Adam Roach 
Thread-Topic: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//5J2A///a5WCAAC+BAP//xcmggABbgwD//9zJoAAHjHYAAAFWlIAAEvS2pQ==
Date: Sat, 19 Oct 2013 06:20:56 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <5261A39A.1060505@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C344F@ESESSMB209.ericsson.se> <5261B8B8.4080803@nostrum.com>,<5261C1B3.2050507@alum.mit.edu>
In-Reply-To: <5261C1B3.2050507@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje5JlaQggwWfVC32/F3EbjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgyjhz7DtzwULlimv7pzM3 MLbLdDFyckgImEh0felngrDFJC7cW8/WxcjFISRwmFFi65LfjBDOEkaJaZMeA2U4ONgELCS6 /2mDNIgIuEtMPruOESTMLKAucXVxEEhYWCBE4m7nJSaIklCJtgMTmUBKRASyJG59FwYJswio Sry7ORkszCvgJnH9bAbEon3MEnvvXmABqeEU0JF49uUvM4jNCHTa91NrwEYyC4hL3HoyH+pk AYkle84zQ9iiEi8f/2OFqNGRWLD7ExuErS2xbOFrsBpeAUGJkzOfsExgFJ2FZNQsJC2zkLTM QtKygJFlFSN7bmJmTnq50SZGYGwc3PJbdQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cDo5/Jiit/0yQ+OaLyPcyl8fHBpgt+CyawPdywOuZ73X2lqTFt3k4PS vifPtFysTq+XzG7Q2/CNt/oZ53M2sQ1Pp4vX7Hixw6U87/PrE5MOXGk7GcKXfGplW/HePbxf rPS/bLg05/jsLzM/J8SYmzvl8v1XePFol8SSgBr9LXNsCvz4uvfkMRx6r8RSnJFoqMVcVJwI AA/C2YpbAgAA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 06:21:05 -0000

Hi,

I think everyone agrees that in order to make POF/PAN work, certain interme=
diaries must support the mechanism. I didn't suggest that using app/sdp wou=
ld make POF/PAN work with non-supporting intermediaries. I only said that i=
t would be easier to identify such non-supporting intermediaries, as they w=
ould reject the POF.

But, if we don't even agree that non-supporting intermediaries would reject=
 a POF, but rather think that media e.g. has been disabled, that advantage =
goes away.

Part of innovation is to discuss/explore different ideas - even the SBC-fri=
endly ones :)

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat  wrote:


Adam,

I'm pretty sure that Hadriel will speak up in a minute and say that the
SBCs only do what they do because that is what administrators want them
to do.

So on one hand it is the administrators that we should curse, not the
vendors of middleboxes.

OTOH, ISTM that the administrators and middlebox vendors are
codependent. Administrators do stuff because they can, even if it is a
bad idea.

I guess ultimately it is a competition. Admins want to forbid anything
they don't fully understand. But that prevents introduction of new stuff.

So ultimately I think we just have to define the new stuff, even if the
middleboxes will often break it. And then let demand push the admins and
middlebox vendors to allow it.

        Thanks,
        Paul

On 10/18/13 6:39 PM, Adam Roach wrote:
> On 10/18/13 16:16, Christer Holmberg wrote:
>> That's why Hadriel should write all our RFCs
>
> You know, there was a point in time at which I would have suspected that
> would work. I would have believed that it would have produced specs that
> would, at the very least, play nicely with middleboxes. And vice-versa.
> Because if there's one person playing in this space who understands
> middleboxes, I would think Hadriel is that person.
>
> But consider the INSIPID effort, which Hadriel did, in fact, author.
>
> At the end of a year and a half of hashing out details, Hadriel
> explained (in a personal, not corporate capacity) that the resulting
> identifier is *unlikely* to make it through middleboxes. Keep in mind
> that the only reason for this work to have occurred is to create an
> identifier that makes it through middleboxes.
>
> Um. What?
>
>  From that, I think the lesson to take away is that middleboxes are
> going to do what middleboxes do, and that we are utter fools for trying
> to appease them. I think it also demonstrates that the Faustian deals we
> cut every time we concede defeat to middlebox behavior are even more ill
> conceived than we first imagined: at least Mephistopheles honored his
> end of the deal.
>
> I think this also tells us that no one can act as an emissary for
> middleboxes, even someone as experienced as Hadriel. Claims about what
> middleboxes do, don't do, can do, or won't do should be viewed with
> extreme skepticism. Any such statements are so heavily caveated as to be
> devoid of meaning.
>
> To be clear, this isn't intended as a smear against Hadriel. When he
> delivered the message that INSIPID was pretty well worthless, he did so
> exactly as a messenger and not as a perpetrator. The failure of
> middleboxes to use this mechanism we designed exclusively for them is
> not his fault. No, this is a criticism leveled at middlebox vendors in
> general. Even where the IETF makes concessions to middleboxes, the
> middleboxes don't play nicely with those concessions. Nothing could have
> been a more direct pander to middleboxes than INSIPID, and its failure
> at their hands is apparently complete and without mitigation.
>
> The writing on the wall is clear. This kowtowing to unknowable and
> infinitely mutable middlebox requirements is both unproductive and
> harmful to innovation. It needs to stop. And it needs to stop now. It's
> done untold damage to SIP's ability to innovate. I have no interest in
> inviting the rampaging bull that gored SIP into WebRTC's home. I'm done
> entertaining arguments that we need to fetter innovation in order to
> accommodate implementations that have no interest in what the IETF has
> to say.
>
> /a
>
> P.S. Yes, I know your comment was meant to be tongue-in-cheek, but it
> threw into vivid relief the reality that the IETF's attempts to play
> nice with middleboxes have been utterly unrequited.
>


From emcho@sip-communicator.org  Sat Oct 19 05:19: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 4C4F611E81A9 for ; Sat, 19 Oct 2013 05:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.655
X-Spam-Level: 
X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.321,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ5zuvebPpK0 for ; Sat, 19 Oct 2013 05:19:40 -0700 (PDT)
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1E11E81A6 for ; Sat, 19 Oct 2013 05:19:37 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id bj1so5874467pad.0 for ; Sat, 19 Oct 2013 05:19:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bx2qOJFuWg738FcRTgZmRiJOEdEglLQCYNaCyvi0bh8=; b=mB1TNpDl0HwoyuK3cNe1EBnm2WLPjYM2deLYbPVXgyxYIq19UR9MLqYkX4Y/itQm4p FPjI4miUUuSN4dY15qazBYoUCPk0ATo7BD92R5CFxpIb5ePifRnxs3mzMrSJbjglAdrs fygu/0nQe+Pl8BiTaSVHXsqnC523KkdMb91lLM+JT7ePaBHZXYO9PkmkeTIbfBfcFnp7 NXTUZgFNglbcRLlu3J1FMwXpgpiMdNq4B6Kb38fwbKOp3UxOO/rCQ2BuzS3ZDmzTRHOp OAicYfzpQQ/F+MA8/SV6nvx4oqbZjNS6aHq9mloGiZAnjKYZeVPesw9Oox/43AfokeR/ QkwA==
X-Gm-Message-State: ALoCoQlw7AKquXu4FGqIRMxaSx7F4WIczjcQ+7M+0y4/j58AdDyNRJS+U0gc2B1fFxaRT0xzqRNS
X-Received: by 10.68.178.197 with SMTP id da5mr8045074pbc.28.1382185177189; Sat, 19 Oct 2013 05:19:37 -0700 (PDT)
Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [2607:f8b0:400e:c01::22a]) by mx.google.com with ESMTPSA id ry4sm11405387pab.4.2013.10.19.05.19.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 05:19:36 -0700 (PDT)
Received: by mail-pb0-f42.google.com with SMTP id un15so5015936pbc.1 for ; Sat, 19 Oct 2013 05:19:36 -0700 (PDT)
X-Received: by 10.68.255.229 with SMTP id at5mr7938964pbd.130.1382185176442; Sat, 19 Oct 2013 05:19:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 05:19:15 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>  
From: Emil Ivov 
Date: Sat, 19 Oct 2013 07:19:15 -0500
Message-ID: 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b5da0db74cf4304e9171017
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 12:19:44 -0000

--047d7b5da0db74cf4304e9171017
Content-Type: text/plain; charset=ISO-8859-1

Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" 
wrote:

> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session SDP
> (bacause, as you said, they are sent within SDP).
>

I don't think this is accurate. Use of SDP for additional candidates is
just a coincidence. It was readily available syntax for describing
candidates and it might be convenient in some implementations (although
this is probably of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer
and could have just as easily be based on JSON or XML or anything else.

Also, trickled candidates DO NOT update the session SDP the way a new m=
line does. There is only a loose relation between them and subsequent O/As.
The origin field does NOT need to be updated. New candidates in new O/As
may appear without having been trickled and trickled candidates can just
well be omitted in subsequent O/As. In other words, a trickled candidate
would only affect the state of the ICE agent in exactly the same way a peer
reflexive candidate would and it would be orthogonal to O/A, again, just as
peer reflexive candidates are.


> So, while we would need to think about whether using POF/PAN would make
> sense or not, why do you think that we "can't" do it?
>

OK, maybe "can't" is not entirely accurate here. I am sure that we *could*
make it would with O/A if we really put our backs into it. In a similar
way, I am sure we could also make it work by exchanging candidates in a
shared Dropbox folder. In either case, I don't see why we would want to
incur such a thing on our selves. I don't see any advantage to doing this.

On the downside, trickling candidates in Offer/Answer would imply the
following problems:

*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare
and I sincerely advise anyone supporting offer answer for trickle to first
try and implement it).
* Ambiguity between ICE restarts and trickle updates.

Also, given how we have already had this discussion and converged on use of
INFO, it is unclear to to me as to why we are revisiting this. I don't
think anyone has reported any problems on the alternative.

Cheers,
Emil


>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov  wrote:
>
>
> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat 
> wrote:
> > On 10/18/13 6:11 PM, Emil Ivov wrote:
> >>
> >> I do think that a different MIME type makes more sense here for the
> >> reasons Paul explained.
> >
> >
> > In the sip world, we may *also* want a new content-disposition. Using
> > 'session' as the content-disposition with the new content type implies
> that
> > the the body is just a different representation of an offer or answer.
> (We
> > were once considering exactly that with SDPng.)
> >
> > We *might* want to think of it that way, or not.
> >
> >
> >> It might be worth adding that the same MIME type would be used when
> >> sending candidate updates with Trickle ICE for SIP, which to me at
> >> least, makes a lot of sense.
> >
> >
> > I still wonder why trickle ICE needs a *different* mechanism for partial
> > offers. Couldn't we just use this one?
>
> By "this one", do you mean POF/PAN or application/sdpfrag?
>
> We don't need anything different than application/sdpfrag.
>
> We can't use POF/PAN because we are not sending offers and answers. We
> are just exchanging candidates in agent-to-agent messages. The use of
> SDP is an unfortunate coincidence, not an indication of offers and
> answers.
>
> Emil
>
> >
> >         Thanks,
> >         Paul
> >
> >> --sent from my mobile
> >>
> >> On 18 Oct 2013 16:55, "Christer Holmberg"
> >>  >>
> >>
> >> wrote:
> >>
> >>     Hi,
> >>
> >>      > I think you and I are thinking of this differently.
> >>      >
> >>      > I'm thinking that the POFs and PANs are something new, different
> >>     from offers and answers. They go on *between* offers and answers.
> >>      >
> >>      > IIUC you are thinking of POFs and PANs as extended forms of
> >>     offers and answers.
> >>
> >>     It's not the way I think - I just wanted to explore how/if things
> >>     would work IF we were thinking like that, and what the pros and cons
> >>     would be :)
> >>
> >>     We have to keep in mind that, no matter how we look at it, the
> >>     Offers/Answers and POFs/PANs are tightly connected, meaning that
> >>     they impact the same SDP state, can cause race conditions etc.
> >>
> >>     Regards,
> >>
> >>     Christer
> >>
> >>
> >>
> >>
> >>
> >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
> >>      > Hi,
> >>      >
> >>      >>>>> Content-Disposition does not apply to intermediaries. So, a
> >> proxy
> >>      >>>>> that only understands application/sdp (e.g. for gate control
> >>      >>>>> purpose) will not even look at the C-D header field value for
> >>      >>>>> other bodies. And, unless such proxy understands POF/PAN,
> there
> >>      >>>>> may not be any media passing through...
> >>      >>>>
> >>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
> >>      >>>> won't know to look at its contents and let the new streams
> >>     through.
> >>      >>>> And a middlebox that sees something marked as
> >>     "application/sdp" that conveys only a tiny fraction of the session
> >>     will probably be just as catastrophic; I would imagine everything
> >>     but the modified streams would be shut off. There's no way to win
> >> here.
> >>      >>>
> >>      >>> I think it would reject the Offer - at least that's what it
> >>     should do according to 3264.
> >>      >>
> >>      >> 3264 only talks about how to process offers and answers
> described
> >> in
> >>      >> SDP. It does not say how those are conveyed in sip. 3261 says
> >>     that they are carried in body parts of content-type application/sdp
> >>     with content-disposition of 'session'. If a body part has
> >>     content-type application/sdp but has a disposition other than
> >>     'session' then it isn't an offer or answer according to 3261, and so
> >>     3264 doesn't apply.
> >>      >
> >>      > 3264 says that all m- line must be present in an Offer - even if
> >>     they are not modified. So, what I meant was that in case all m-
> >>     lines are NOT present (in the case of a POF), such Offer would be
> >>     rejected - unless the middlebox understands the POF/PAN mechanism .
> >>      >
> >>      >>>> At some point, we have to come to peace with the fact that any
> >>     middleboxes that aren't primarily in the business of stifling
> >>     progress will need to keep pace with protocol extensions as they get
> >>     deployed.
> >>      >>>
> >>      >>> I really wish things worked that way :)
> >>      >>
> >>      >> So progress ends because middleboxes don't permit it?
> >>      >>
> >>      >> Maybe you are right. Then sip will go the way of h323 while the
> >>     world moves on to webrtc.
> >>      >
> >>      > I think that getting explicit rejections, rather than having to
> >>     try to
> >>      > figure out where things go wrong, is good for progress :)
> >>      >
> >>      > Anyway, it wasn't really a suggestion - I just wanted to do some
> >>      > brainstorming :)
> >>      >
> >>      > Regards,
> >>      >
> >>      > Christer
> >>      >
> >>
> >>     _______________________________________________
> >>     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
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> https://jitsi.org                       FAX:   +33.1.77.62.47.31
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--047d7b5da0db74cf4304e9171017
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




Hey Christer,


On 19 Oct 2013 08:10, "Christer Holmberg&qu=
ot; <christer.holmberg@ericsson.com> wrote:



Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).

I don't think this is accurate. Use of SDP for additional candi=
dates is just a coincidence. It was readily available syntax for describing=
 candidates and it might be convenient in some implementations (although th=
is is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answ=
er and could have just as easily be based on JSON or XML or anything else. =


Also, trickled candidates DO NOT update the session SDP =
the way a new m=3D line does. There is only a loose relation between them a=
nd subsequent O/As. The origin field does NOT need to be updated. New candi=
dates in new O/As may appear without having been trickled and trickled cand=
idates can just well be omitted in subsequent O/As. In other words, a trick=
led candidate would only affect the state of the ICE agent in exactly the s=
ame way a peer reflexive candidate would and it would be orthogonal to O/A,=
 again, just as peer reflexive candidates are.



=A0

So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?

OK, maybe "can't" is not entirely a=
ccurate here. I am sure that we *could* make it would with O/A if we really=
 put our backs into it. In a similar way, I am sure we could also make it w=
ork by exchanging candidates in a shared Dropbox folder. In either case, I =
don't see why we would want to incur such a thing on our selves. I don&=
#39;t see any advantage to doing this.



On the downside, trickling candidates in Offer/Answer would =
imply the following problems:

*=A0 Very high glare probab=
ility.
* Unnecessarily complex implementation (really, this w=
ould be a nightmare and I sincerely advise anyone supporting offer answer f=
or trickle to first try and implement it). 



* Ambiguity between ICE restarts and trickle updates.

Also, given how we have already had this discussion and converged o=
n use of INFO, it is unclear to to me as to why we are revisiting this. I d=
on't think anyone has reported any problems on the alternative.



Cheers,
Emil 
=A0



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type=
 implies that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We<=
br>
are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

> =A0 =A0 =A0 =A0 Thanks,

> =A0 =A0 =A0 =A0 Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>



>>

>> wrote:

>>

>> =A0 =A0 Hi,

>>

>> =A0 =A0 =A0> I think you and I are thinking of this differently=
.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I'm thinking that the POFs and PANs are someth=
ing new, different

>> =A0 =A0 from offers and answers. They go on *between* offers and a=
nswers.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> IIUC you are thinking of POFs and PANs as extended=
 forms of

>> =A0 =A0 offers and answers.

>>

>> =A0 =A0 It's not the way I think - I just wanted to explore ho=
w/if things

>> =A0 =A0 would work IF we were thinking like that, and what the pro=
s and cons

>> =A0 =A0 would be :)

>>

>> =A0 =A0 We have to keep in mind that, no matter how we look at it,=
 the

>> =A0 =A0 Offers/Answers and POFs/PANs are tightly connected, meanin=
g that

>> =A0 =A0 they impact the same SDP state, can cause race conditions =
etc.

>>

>> =A0 =A0 Regards,

>>

>> =A0 =A0 Christer

>>

>>

>>

>>

>>

>> =A0 =A0 On 10/18/13 5:06 PM, Christer Holmberg wrote:

>> =A0 =A0 =A0> Hi,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>>> Content-Disposition does not apply=
 to intermediaries. So, a

>> proxy

>> =A0 =A0 =A0>>>>> that only understands application/=
sdp (e.g. for gate control

>> =A0 =A0 =A0>>>>> purpose) will not even look at the=
 C-D header field value for

>> =A0 =A0 =A0>>>>> other bodies. And, unless such pro=
xy understands POF/PAN, there

>> =A0 =A0 =A0>>>>> may not be any media passing throu=
gh...

>> =A0 =A0 =A0>>>>

>> =A0 =A0 =A0>>>> Right. A middlebox that doesn't un=
derstand application/sdpfrag

>> =A0 =A0 =A0>>>> won't know to look at its contents=
 and let the new streams

>> =A0 =A0 through.

>> =A0 =A0 =A0>>>> And a middlebox that sees something ma=
rked as

>> =A0 =A0 "application/sdp" that conveys only a tiny fract=
ion of the session

>> =A0 =A0 will probably be just as catastrophic; I would imagine eve=
rything

>> =A0 =A0 but the modified streams would be shut off. There's no=
 way to win

>> here.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I think it would reject the Offer - at lea=
st that's what it

>> =A0 =A0 should do according to 3264.

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> 3264 only talks about how to process offers an=
d answers described

>> in

>> =A0 =A0 =A0>> SDP. It does not say how those are conveyed in=
 sip. 3261 says

>> =A0 =A0 that they are carried in body parts of content-type applic=
ation/sdp

>> =A0 =A0 with content-disposition of 'session'. If a body p=
art has

>> =A0 =A0 content-type application/sdp but has a disposition other t=
han

>> =A0 =A0 'session' then it isn't an offer or answer acc=
ording to 3261, and so

>> =A0 =A0 3264 doesn't apply.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> 3264 says that all m- line must be present in an O=
ffer - even if

>> =A0 =A0 they are not modified. So, what I meant was that in case a=
ll m-

>> =A0 =A0 lines are NOT present (in the case of a POF), such Offer w=
ould be

>> =A0 =A0 rejected - unless the middlebox understands the POF/PAN me=
chanism .

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>> At some point, we have to come to peac=
e with the fact that any

>> =A0 =A0 middleboxes that aren't primarily in the business of s=
tifling

>> =A0 =A0 progress will need to keep pace with protocol extensions a=
s they get

>> =A0 =A0 deployed.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I really wish things worked that way :)
>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> So progress ends because middleboxes don't=
 permit it?

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> Maybe you are right. Then sip will go the way =
of h323 while the

>> =A0 =A0 world moves on to webrtc.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I think that getting explicit rejections, rather t=
han having to

>> =A0 =A0 try to

>> =A0 =A0 =A0> figure out where things go wrong, is good for prog=
ress :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Anyway, it wasn't really a suggestion - I just=
 wanted to do some

>> =A0 =A0 =A0> brainstorming :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Regards,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Christer

>> =A0 =A0 =A0>

>>

>> =A0 =A0 _______________________________________________

>> =A0 =A0 mmusic mailing list

>> =A0 =A0 mmusi=
c@ietf.org <mailto:mmusic@ietf.org>

>> =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 67000 Strasbou=
rg,

Project Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 France

Jitsi

emcho@jitsi.org =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PHONE: +33.1.77.62.43.30

https://jitsi.org =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FAX: =A0 +33.1.77.62.47.31
_______________________________________________

mmusic mailing list

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






--047d7b5da0db74cf4304e9171017--

From emil@sip-communicator.org  Sat Oct 19 05:34: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 9474611E81C6 for ; Sat, 19 Oct 2013 05:33:55 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwmRTxujyMTj for ; Sat, 19 Oct 2013 05:33:38 -0700 (PDT)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6C74A11E819E for ; Sat, 19 Oct 2013 05:33:31 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so4836181wgh.5 for ; Sat, 19 Oct 2013 05:33:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eSUP5wgYIF4EDcwZB50htaDgUDp2lqRoN9FeyviWIcw=; b=FNjP5Zazcd0NnRfU8W7xrt5RqiWdV4QbpbQ5McQOWqiJ/f+NwNW9Sgt78qLxLfsxF6 x2XRFRykDBPEUiigBQ5TkW6Ujpy76eqDKqQITnQtPCiZ8lMG3C/pvq8I4oc/idxCTI4c HOSYzrukMTGRh7fB6FVf9V63ITpfspiy+kHdB44J46Dvup9HsgC3F/qjdqqTBUTjDYiT GWn8HG13eI3OhsPnugrfKgpXL0Qjhjk+2Q91HaS7D6pIYQ/uHWA8zHIeQwTNN11g5/yR uMOE081uwDCmqfL1ntLMU7oxy4lCvZhXle9MGAcFEq8uGpzyUMqzHqE5LGcEws7q4VLW g2EA==
X-Gm-Message-State: ALoCoQm+wsp6/6SGTh2Wfc/0GGHze97Hwyf65mJTpvh4JQFq5b099/yU4Hugj9CJ5OVkR9e6jja2
X-Received: by 10.194.175.66 with SMTP id by2mr145526wjc.59.1382186010579; Sat, 19 Oct 2013 05:33:30 -0700 (PDT)
Received: from camionet.local (smb-rsycl-01.wifihubtelecom.net. [213.174.124.177]) by mx.google.com with ESMTPSA id jf2sm12796552wic.2.2013.10.19.05.33.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 05:33:29 -0700 (PDT)
Message-ID: <52627C14.8080309@jitsi.org>
Date: Sat, 19 Oct 2013 14:33:24 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Adam Roach 
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com>
In-Reply-To: <5261704B.9090307@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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, 19 Oct 2013 12:34:04 -0000

Hey Adam,

On 18.10.13, 19:30, Adam Roach wrote:
> On 10/18/13 09:44, Emil Ivov wrote:
>> It might be worth reminding exactly what these 50ms would be
>> protecting us against
>
> They're protecting us against RTP arriving at a rate of 20ms per packet.

That would indeed be one of the reasons to pace checks (in addition to 
fragile NAT boxes IIRC), however in either case, I fail to realise why 
we need a different pacing strategy for non-RTP. This is what I was 
asking about.

Connectivity check hammers can still resort to RTP if the pacing timer 
is their only problem and I don't see why shaky NATs would tolerate a 
20ms rate for RTP but only a 50ms for anything else.

This entire separation sounds quite arbitrary right now. I see why we 
would pick a value that we consider somewhat safe and secure but I don't 
understand why we would need two!?

Emil

>> and why is it that we don't need to be
>> protected against it in the case of RTP where 20ms is accepted as a
>> fine default value.
>
> Well, it's not. This is exactly why we ended up requiring ICE: it
> ensures explicit consent before you start blowing media at someone.
>
> See also http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html



-- 
https://jitsi.org

From palmarti@cisco.com  Sat Oct 19 06:53: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 2A1DF11E81BA for ; Sat, 19 Oct 2013 06:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4332xRnKAtfH for ; Sat, 19 Oct 2013 06:53:14 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7543D11E81A2 for ; Sat, 19 Oct 2013 06:53:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1711; q=dns/txt; s=iport; t=1382190794; x=1383400394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zimSZABaeESOWafp6L9gdn+ZB19Mi/5l6gbJtU0wpCc=; b=i6CWwKKScg5b04oTslQ96XGd279MUEWvmheBv8jljHIJY1uVbg9oCWSp RRQoKHl63pMMk861dbBQCH7A0eBavfjAHaUuRK10IOZH+hajhmz7f5Zom 7mK5kGslEe6EKSo2JVPicGzD3nB6UWRfKK6OZW66HVOqPQAEWLMavhJh/ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAE2OYlKtJXG9/2dsb2JhbABagwc4Ur1lS4ElFnSCJQEBAQMBAQEBawsFCwIBCA4KCiQnCyUCBA4FCAGHdwYMwCeOI4EGAjECBYMfgQoDiQehCYMkgXE5
X-IronPort-AV: E=Sophos;i="4.93,528,1378857600"; d="scan'208";a="274103827"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 19 Oct 2013 13:53:14 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9JDrDMN032201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Oct 2013 13:53:13 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.250]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sat, 19 Oct 2013 08:53:13 -0500
From: "Pal Martinsen (palmarti)" 
To: Emil Ivov 
Thread-Topic: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Thread-Index: AQHOzA+s6uVAbsdUW06agGLCJqsZo5n63M2AgAAueYCAAT86AIAAFk2A
Date: Sat, 19 Oct 2013 13:53:12 +0000
Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org>
In-Reply-To: <52627C14.8080309@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.195.129]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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, 19 Oct 2013 13:53:19 -0000

On Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:

> Hey Adam,
>=20
> On 18.10.13, 19:30, Adam Roach wrote:
>> On 10/18/13 09:44, Emil Ivov wrote:
>>> It might be worth reminding exactly what these 50ms would be
>>> protecting us against
>>=20
>> They're protecting us against RTP arriving at a rate of 20ms per packet.
>=20
> That would indeed be one of the reasons to pace checks (in addition to fr=
agile NAT boxes IIRC), however in either case, I fail to realise why we nee=
d a different pacing strategy for non-RTP. This is what I was asking about.
>=20
> Connectivity check hammers can still resort to RTP if the pacing timer is=
 their only problem and I don't see why shaky NATs would tolerate a 20ms ra=
te for RTP but only a 50ms for anything else.
>=20
> This entire separation sounds quite arbitrary right now. I see why we wou=
ld pick a value that we consider somewhat safe and secure but I don't under=
stand why we would need two!?

I agree. No need to add more complexity. ICE should be ignorant of what tra=
ffic goes through the pinholes.

.-.
P=E5l-Erik

>=20
> Emil
>=20
>>> and why is it that we don't need to be
>>> protected against it in the case of RTP where 20ms is accepted as a
>>> fine default value.
>>=20
>> Well, it's not. This is exactly why we ended up requiring ICE: it
>> ensures explicit consent before you start blowing media at someone.
>>=20
>> See also http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.ht=
ml
>=20
>=20
>=20
> --=20
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From christer.holmberg@ericsson.com  Sat Oct 19 08:44: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 327DB11E81F3 for ; Sat, 19 Oct 2013 08:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.921
X-Spam-Level: 
X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=-1.323, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmpGUQiOyjDg for ; Sat, 19 Oct 2013 08:44:01 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3958E11E81ED for ; Sat, 19 Oct 2013 08:43:57 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-9f-5262a8bcf5e8
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E2.E0.25272.CB8A2625; Sat, 19 Oct 2013 17:43:57 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 17:43:56 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eYAARXaAgABat3w=
Date: Sat, 19 Oct 2013 15:43:55 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_yv22u8tdcxanwt643ccmsn7t1382197429573emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvje7eFUlBBj1TGC3W7JzAYjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlTDt0mrXg7m7GioMTLrA3 MC6dydjFyMkhIWAi8f3eThYIW0ziwr31bF2MXBxCAkcZJbZ/vswM4SxhlJjRdhUow8HBJmAh 0f1PG6RBREBeorttEROIzSzgJLH/w2tmEFtYwEui/+BtJogab4n/96+yQNh+Eq93HWEDsVkE VCUOrG8DO4JXwE1iecMeqF3T2CQWnV/ACpLgFAiUuHD9NNhQRqDrvp9aA7VMXOLWk/lMEFcL SCzZc54ZwhaVePn4HytETY7Esz6Iz3gFBCVOznzCMoFRZBaS9llIymYhKYOI60ncmDqFDcLW lli28DUzhK0rMePfIRZk8QWM7KsYOYpTi5Ny040MNjECo+rglt8WOxgv/7U5xCjNwaIkzvvx rXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaVHPzBGcJ1bfGfjffsPjDDVMMvYdLrctnp i6Nm73y6/IXC/4MdNZnyM51N7k4KCOs/lBVqOU/scaIEu9XpdT/CWaU6Qu0mHw653C9w3Lk8 zmIja6+dbQdX5PyiR8KL5WIFXjbcLL9wauEk1Z9POF3Un2Upbbx6fJ1XiZbRdxX56D2S3kX9 P5RYijMSDbWYi4oTATD+Mdl4AgAA
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 15:44:06 -0000

--_000_yv22u8tdcxanwt643ccmsn7t1382197429573emailandroidcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Emil,

Assume you have an m- line, for which you provide candidates using trickle =
ICE.

Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.

Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov  wrote:



Hey Christer,

On 19 Oct 2013 08:10, "Christer Holmberg" > wrote:
Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).

I don't think this is accurate. Use of SDP for additional candidates is jus=
t a coincidence. It was readily available syntax for describing candidates =
and it might be convenient in some implementations (although this is probab=
ly of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.

Also, trickled candidates DO NOT update the session SDP the way a new m=3D =
line does. There is only a loose relation between them and subsequent O/As.=
 The origin field does NOT need to be updated. New candidates in new O/As m=
ay appear without having been trickled and trickled candidates can just wel=
l be omitted in subsequent O/As. In other words, a trickled candidate would=
 only affect the state of the ICE agent in exactly the same way a peer refl=
exive candidate would and it would be orthogonal to O/A, again, just as pee=
r reflexive candidates are.

So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?

OK, maybe "can't" is not entirely accurate here. I am sure that we *could* =
make it would with O/A if we really put our backs into it. In a similar way=
, I am sure we could also make it work by exchanging candidates in a shared=
 Dropbox folder. In either case, I don't see why we would want to incur suc=
h a thing on our selves. I don't see any advantage to doing this.

On the downside, trickling candidates in Offer/Answer would imply the follo=
wing problems:

*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare a=
nd I sincerely advise anyone supporting offer answer for trickle to first t=
ry and implement it).
* Ambiguity between ICE restarts and trickle updates.

Also, given how we have already had this discussion and converged on use of=
 INFO, it is unclear to to me as to why we are revisiting this. I don't thi=
nk anyone has reported any problems on the alternative.

Cheers,
Emil


Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov > wrote:


On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat > wrote:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies th=
at
> the the body is just a different representation of an offer or answer. (W=
e
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>>  <=
mailto:christer.holmberg@ericsson.com>>
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, the=
re
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers describe=
d
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     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



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1=
.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_yv22u8tdcxanwt643ccmsn7t1382197429573emailandroidcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi Emil,=0A=
=0A=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.=0A=
=0A=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.=0A=
=0A=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Emil Ivov <emcho@jitsi.org> wrote:=0A=
=0A=









Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg&qu=
ot; <christer.holmberg@ericsson.com> wrote:



Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).









I don't think this is accurate. Use of SDP for additional candidates i=
s just a coincidence. It was readily available syntax for describing candid=
ates and it might be convenient in some implementations (although this is p=
robably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session SDP the way a new =
m=3D line does. There is only a loose relation between them and subsequent =
O/As. The origin field does NOT need to be updated. New candidates in new O=
/As may appear without having been
 trickled and trickled candidates can just well be omitted in subsequent O/=
As. In other words, a trickled candidate would only affect the state of the=
 ICE agent in exactly the same way a peer reflexive candidate would and it =
would be orthogonal to O/A, again,
 just as peer reflexive candidates are.




 





So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?









OK, maybe "can't" is not entirely accurate here. I am sure t=
hat we *could* make it would with O/A if we really put our backs into it. I=
n a similar way, I am sure we could also make it work by exchanging candida=
tes in a shared Dropbox folder. In either
 case, I don't see why we would want to incur such a thing on our selves. I=
 don't see any advantage to doing this.






On the downside, trickling candidates in Offer/Answer would imply the =
following problems:






*  Very high glare probability.




* Unnecessarily complex implementation (really, this would be a nightm=
are and I sincerely advise anyone supporting offer answer for trickle to fi=
rst try and implement it).





* Ambiguity between ICE restarts and trickle updates.






Also, given how we have already had this discussion and converged on u=
se of INFO, it is unclear to to me as to why we are revisiting this. I don'=
t think anyone has reported any problems on the alternative.



Cheers,

Emil 




 





Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type implies=
 that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We

are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

>         Thanks,

>         Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>

>>

>> wrote:

>>

>>     Hi,

>>

>>      > I think you and I are thinking of this di=
fferently.

>>      >

>>      > I'm thinking that the POFs and PANs are s=
omething new, different

>>     from offers and answers. They go on *between* offers=
 and answers.

>>      >

>>      > IIUC you are thinking of POFs and PANs as=
 extended forms of

>>     offers and answers.

>>

>>     It's not the way I think - I just wanted to explore =
how/if things

>>     would work IF we were thinking like that, and what t=
he pros and cons

>>     would be :)

>>

>>     We have to keep in mind that, no matter how we look =
at it, the

>>     Offers/Answers and POFs/PANs are tightly connected, =
meaning that

>>     they impact the same SDP state, can cause race condi=
tions etc.

>>

>>     Regards,

>>

>>     Christer

>>

>>

>>

>>

>>

>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:

>>      > Hi,

>>      >

>>      >>>>> Content-Disposition does =
not apply to intermediaries. So, a

>> proxy

>>      >>>>> that only understands app=
lication/sdp (e.g. for gate control

>>      >>>>> purpose) will not even lo=
ok at the C-D header field value for

>>      >>>>> other bodies. And, unless=
 such proxy understands POF/PAN, there

>>      >>>>> may not be any media pass=
ing through...

>>      >>>>

>>      >>>> Right. A middlebox that doesn=
't understand application/sdpfrag

>>      >>>> won't know to look at its con=
tents and let the new streams

>>     through.

>>      >>>> And a middlebox that sees som=
ething marked as

>>     "application/sdp" that conveys only a tiny=
 fraction of the session

>>     will probably be just as catastrophic; I would imagi=
ne everything

>>     but the modified streams would be shut off. There's =
no way to win

>> here.

>>      >>>

>>      >>> I think it would reject the Offer=
 - at least that's what it

>>     should do according to 3264.

>>      >>

>>      >> 3264 only talks about how to process =
offers and answers described

>> in

>>      >> SDP. It does not say how those are co=
nveyed in sip. 3261 says

>>     that they are carried in body parts of content-type =
application/sdp

>>     with content-disposition of 'session'. If a body par=
t has

>>     content-type application/sdp but has a disposition o=
ther than

>>     'session' then it isn't an offer or answer according=
 to 3261, and so

>>     3264 doesn't apply.

>>      >

>>      > 3264 says that all m- line must be presen=
t in an Offer - even if

>>     they are not modified. So, what I meant was that in =
case all m-

>>     lines are NOT present (in the case of a POF), such O=
ffer would be

>>     rejected - unless the middlebox understands the POF/=
PAN mechanism .

>>      >

>>      >>>> At some point, we have to com=
e to peace with the fact that any

>>     middleboxes that aren't primarily in the business of=
 stifling

>>     progress will need to keep pace with protocol extens=
ions as they get

>>     deployed.

>>      >>>

>>      >>> I really wish things worked that =
way :)

>>      >>

>>      >> So progress ends because middleboxes =
don't permit it?

>>      >>

>>      >> Maybe you are right. Then sip will go=
 the way of h323 while the

>>     world moves on to webrtc.

>>      >

>>      > I think that getting explicit rejections,=
 rather than having to

>>     try to

>>      > figure out where things go wrong, is good=
 for progress :)

>>      >

>>      > Anyway, it wasn't really a suggestion - I=
 just wanted to do some

>>      > brainstorming :)

>>      >

>>      > Regards,

>>      >

>>      > Christer

>>      >

>>

>>     _______________________________________________

>>     mmusic mailing list

>>     mmusic@ietf.org <mailto:mmusic@ietf.org>

>>     https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D.                 &n=
bsp;     67000 Strasbourg,

Project Lead                  =
         France

Jitsi

emcho@jitsi.org &n=
bsp;                     =
 PHONE:
+33.1.77.62.43.30

https://jitsi.org  =
;                     FAX=
:  
+33.1.77.62.47.31

_______________________________________________

mmusic mailing list

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












--_000_yv22u8tdcxanwt643ccmsn7t1382197429573emailandroidcom_--

From emcho@sip-communicator.org  Sat Oct 19 08:56: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 9BD1911E81CB for ; Sat, 19 Oct 2013 08:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.691
X-Spam-Level: 
X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.285,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iao+Qu5TenJe for ; Sat, 19 Oct 2013 08:56:34 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56411E81DF for ; Sat, 19 Oct 2013 08:56:32 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rr4so5082252pbb.20 for ; Sat, 19 Oct 2013 08:56:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ExTXyHo97FihD7sk4oqXciE1BLrKP07TTEErDqXuFhk=; b=fqzRQ9a9rWuV5wjhD6V4M47Yr5N0x4NGwnJIF3+RdBpQaG7badMs5XipeV/2ZxCQ3O 3Dk0EdIhHaNVT04+RPdqjh3bnAZ3eukIiDnCB3o4zdNylH+E3tsfm0Hkb0Ei9RF9wqPS TSG1ZMo5tRkgq7Ln18eyfiYGbpByJr3uuGIywBqqhv74JjG/dw9PFAjW1DiuZ+T1KbFK PeeL1nMy9eLxSIvVHpfr1PN885phK8ecqjzl3aEL16OHTjsUMompHRP+AzCHNDkrWTRO VT3m3maqqxncONYnbXdW8WuPT0LEU3vEX+YPgdwCoI2lZWA+EGrYkGSxhTILsHVm4wDo XkJQ==
X-Gm-Message-State: ALoCoQluYi5OWsEzaSluB0a+ZGPSAmt1ve3LA/0ZpQ7x9yE7acJDQ4ATTm9mXaNJUZmfG2yJkmvb
X-Received: by 10.68.192.195 with SMTP id hi3mr8792495pbc.18.1382198178467; Sat, 19 Oct 2013 08:56:18 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [2607:f8b0:400e:c02::231]) by mx.google.com with ESMTPSA id y9sm12596056pas.10.2013.10.19.08.56.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 08:56:17 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id p10so3525232pdj.8 for ; Sat, 19 Oct 2013 08:56:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.190.197 with SMTP id gs5mr8708539pbc.90.1382198177213; Sat, 19 Oct 2013 08:56:17 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 08:56:16 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 08:56:16 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>    
Date: Sat, 19 Oct 2013 10:56:16 -0500
Message-ID: 
From: Emil Ivov 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=e89a8ffba9795cce3504e91a178d
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 15:56:43 -0000

--e89a8ffba9795cce3504e91a178d
Content-Type: text/plain; charset=ISO-8859-1

The new SDP O/A you mention would cause an ICE restart and that's what will
define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about
trickled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" 
wrote:

>  Hi Emil,
>
> Assume you have an m- line, for which you provide candidates using trickle ICE.
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it will inherit the address properties and candidates of the BUNDLE group.
>
> Are you saying that the previously provided trickle candidates are still comsidered valid, eventhough they are associated with different address properties etc?
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov  wrote:
>
>
>   Hey Christer,
>  On 19 Oct 2013 08:10, "Christer Holmberg" 
> wrote:
>
>> Hi Emil,
>>
>> Similar to POF/PAN, the sending of candidates do affect the session SDP
>> (bacause, as you said, they are sent within SDP).
>>
>
>  I don't think this is accurate. Use of SDP for additional candidates is
> just a coincidence. It was readily available syntax for describing
> candidates and it might be convenient in some implementations (although
> this is probably of marginal value).
>
> The point is that the syntax is not due to a relationship to Offer/Answer
> and could have just as easily be based on JSON or XML or anything else.
>
>  Also, trickled candidates DO NOT update the session SDP the way a new m=
> line does. There is only a loose relation between them and subsequent O/As.
> The origin field does NOT need to be updated. New candidates in new O/As
> may appear without having been trickled and trickled candidates can just
> well be omitted in subsequent O/As. In other words, a trickled candidate
> would only affect the state of the ICE agent in exactly the same way a peer
> reflexive candidate would and it would be orthogonal to O/A, again, just as
> peer reflexive candidates are.
>
>
>> So, while we would need to think about whether using POF/PAN would make
>> sense or not, why do you think that we "can't" do it?
>>
>
>  OK, maybe "can't" is not entirely accurate here. I am sure that we
> *could* make it would with O/A if we really put our backs into it. In a
> similar way, I am sure we could also make it work by exchanging candidates
> in a shared Dropbox folder. In either case, I don't see why we would want
> to incur such a thing on our selves. I don't see any advantage to doing
> this.
>
>  On the downside, trickling candidates in Offer/Answer would imply the
> following problems:
>
>  *  Very high glare probability.
>  * Unnecessarily complex implementation (really, this would be a
> nightmare and I sincerely advise anyone supporting offer answer for trickle
> to first try and implement it).
>  * Ambiguity between ICE restarts and trickle updates.
>
>  Also, given how we have already had this discussion and converged on use
> of INFO, it is unclear to to me as to why we are revisiting this. I don't
> think anyone has reported any problems on the alternative.
>
> Cheers,
> Emil
>
>
>>
>> Regards,
>>
>> Christer
>>
>> Sent from my Sony Ericsson Xperia arc S
>>
>> Emil Ivov  wrote:
>>
>>
>> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat 
>> wrote:
>> > On 10/18/13 6:11 PM, Emil Ivov wrote:
>> >>
>> >> I do think that a different MIME type makes more sense here for the
>> >> reasons Paul explained.
>> >
>> >
>> > In the sip world, we may *also* want a new content-disposition. Using
>> > 'session' as the content-disposition with the new content type implies
>> that
>> > the the body is just a different representation of an offer or answer.
>> (We
>> > were once considering exactly that with SDPng.)
>> >
>> > We *might* want to think of it that way, or not.
>> >
>> >
>> >> It might be worth adding that the same MIME type would be used when
>> >> sending candidate updates with Trickle ICE for SIP, which to me at
>> >> least, makes a lot of sense.
>> >
>> >
>> > I still wonder why trickle ICE needs a *different* mechanism for partial
>> > offers. Couldn't we just use this one?
>>
>> By "this one", do you mean POF/PAN or application/sdpfrag?
>>
>> We don't need anything different than application/sdpfrag.
>>
>> We can't use POF/PAN because we are not sending offers and answers. We
>> are just exchanging candidates in agent-to-agent messages. The use of
>> SDP is an unfortunate coincidence, not an indication of offers and
>> answers.
>>
>> Emil
>>
>> >
>> >         Thanks,
>> >         Paul
>> >
>> >> --sent from my mobile
>> >>
>> >> On 18 Oct 2013 16:55, "Christer Holmberg"
>> >> > >>
>> >>
>> >> wrote:
>> >>
>> >>     Hi,
>> >>
>> >>      > I think you and I are thinking of this differently.
>> >>      >
>> >>      > I'm thinking that the POFs and PANs are something new, different
>> >>     from offers and answers. They go on *between* offers and answers.
>> >>      >
>> >>      > IIUC you are thinking of POFs and PANs as extended forms of
>> >>     offers and answers.
>> >>
>> >>     It's not the way I think - I just wanted to explore how/if things
>> >>     would work IF we were thinking like that, and what the pros and
>> cons
>> >>     would be :)
>> >>
>> >>     We have to keep in mind that, no matter how we look at it, the
>> >>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>> >>     they impact the same SDP state, can cause race conditions etc.
>> >>
>> >>     Regards,
>> >>
>> >>     Christer
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>> >>      > Hi,
>> >>      >
>> >>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> >> proxy
>> >>      >>>>> that only understands application/sdp (e.g. for gate control
>> >>      >>>>> purpose) will not even look at the C-D header field value
>> for
>> >>      >>>>> other bodies. And, unless such proxy understands POF/PAN,
>> there
>> >>      >>>>> may not be any media passing through...
>> >>      >>>>
>> >>      >>>> Right. A middlebox that doesn't understand
>> application/sdpfrag
>> >>      >>>> won't know to look at its contents and let the new streams
>> >>     through.
>> >>      >>>> And a middlebox that sees something marked as
>> >>     "application/sdp" that conveys only a tiny fraction of the session
>> >>     will probably be just as catastrophic; I would imagine everything
>> >>     but the modified streams would be shut off. There's no way to win
>> >> here.
>> >>      >>>
>> >>      >>> I think it would reject the Offer - at least that's what it
>> >>     should do according to 3264.
>> >>      >>
>> >>      >> 3264 only talks about how to process offers and answers
>> described
>> >> in
>> >>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>> >>     that they are carried in body parts of content-type application/sdp
>> >>     with content-disposition of 'session'. If a body part has
>> >>     content-type application/sdp but has a disposition other than
>> >>     'session' then it isn't an offer or answer according to 3261, and
>> so
>> >>     3264 doesn't apply.
>> >>      >
>> >>      > 3264 says that all m- line must be present in an Offer - even if
>> >>     they are not modified. So, what I meant was that in case all m-
>> >>     lines are NOT present (in the case of a POF), such Offer would be
>> >>     rejected - unless the middlebox understands the POF/PAN mechanism .
>> >>      >
>> >>      >>>> At some point, we have to come to peace with the fact that
>> any
>> >>     middleboxes that aren't primarily in the business of stifling
>> >>     progress will need to keep pace with protocol extensions as they
>> get
>> >>     deployed.
>> >>      >>>
>> >>      >>> I really wish things worked that way :)
>> >>      >>
>> >>      >> So progress ends because middleboxes don't permit it?
>> >>      >>
>> >>      >> Maybe you are right. Then sip will go the way of h323 while the
>> >>     world moves on to webrtc.
>> >>      >
>> >>      > I think that getting explicit rejections, rather than having to
>> >>     try to
>> >>      > figure out where things go wrong, is good for progress :)
>> >>      >
>> >>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>> >>      > brainstorming :)
>> >>      >
>> >>      > Regards,
>> >>      >
>> >>      > Christer
>> >>      >
>> >>
>> >>     _______________________________________________
>> >>     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
>>
>>
>>
>> --
>> Emil Ivov, Ph.D.                       67000 Strasbourg,
>> Project Lead                           France
>> Jitsi
>> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
>> https://jitsi.org                       FAX:   +33.1.77.62.47.31
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

--e89a8ffba9795cce3504e91a178d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


The new SDP O/A you mention would cause an ICE restart and t=
hat's what will define agent state. Not previously exchange trickled ca=
ndidates. 


I am not sure I understand the relation to your argument tho=
ugh (about trickled candidates affecting session SDP) so I might be missing=
 your point.


Emil



--sent from my mobile


On 19 Oct 2013 17:43, "Christer Holmberg&qu=
ot; <christer.holmberg=
@ericsson.com> wrote:








Hi =
Emil,

Assume you have an m- line, for which you provide candidates using trickle =
ICE.

Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.

Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov <emcho@ji=
tsi.org> wrote:










Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg&qu=
ot; <christer.holmberg@ericsson.com> wrote:



Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).









I don't think this is accurate. Use of SDP for additional candidat=
es is just a coincidence. It was readily available syntax for describing ca=
ndidates and it might be convenient in some implementations (although this =
is probably of marginal value).




The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session SDP the way a new =
m=3D line does. There is only a loose relation between them and subsequent =
O/As. The origin field does NOT need to be updated. New candidates in new O=
/As may appear without having been
 trickled and trickled candidates can just well be omitted in subsequent O/=
As. In other words, a trickled candidate would only affect the state of the=
 ICE agent in exactly the same way a peer reflexive candidate would and it =
would be orthogonal to O/A, again,
 just as peer reflexive candidates are.




=A0





So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?









OK, maybe "can't" is not entirely accurate here. I am su=
re that we *could* make it would with O/A if we really put our backs into i=
t. In a similar way, I am sure we could also make it work by exchanging can=
didates in a shared Dropbox folder. In either
 case, I don't see why we would want to incur such a thing on our selve=
s. I don't see any advantage to doing this.






On the downside, trickling candidates in Offer/Answer would imply the =
following problems:






*=A0 Very high glare probability.




* Unnecessarily complex implementation (really, this would be a nightm=
are and I sincerely advise anyone supporting offer answer for trickle to fi=
rst try and implement it).





* Ambiguity between ICE restarts and trickle updates.






Also, given how we have already had this discussion and converged on u=
se of INFO, it is unclear to to me as to why we are revisiting this. I don&=
#39;t think anyone has reported any problems on the alternative.



Cheers,

Emil 




=A0





Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type=
 implies that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We<=
br>
are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

> =A0 =A0 =A0 =A0 Thanks,

> =A0 =A0 =A0 =A0 Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>


>>

>> wrote:

>>

>> =A0 =A0 Hi,

>>

>> =A0 =A0 =A0> I think you and I are thinking of this differently=
.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I'm thinking that the POFs and PANs are someth=
ing new, different

>> =A0 =A0 from offers and answers. They go on *between* offers and a=
nswers.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> IIUC you are thinking of POFs and PANs as extended=
 forms of

>> =A0 =A0 offers and answers.

>>

>> =A0 =A0 It's not the way I think - I just wanted to explore ho=
w/if things

>> =A0 =A0 would work IF we were thinking like that, and what the pro=
s and cons

>> =A0 =A0 would be :)

>>

>> =A0 =A0 We have to keep in mind that, no matter how we look at it,=
 the

>> =A0 =A0 Offers/Answers and POFs/PANs are tightly connected, meanin=
g that

>> =A0 =A0 they impact the same SDP state, can cause race conditions =
etc.

>>

>> =A0 =A0 Regards,

>>

>> =A0 =A0 Christer

>>

>>

>>

>>

>>

>> =A0 =A0 On 10/18/13 5:06 PM, Christer Holmberg wrote:

>> =A0 =A0 =A0> Hi,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>>> Content-Disposition does not apply=
 to intermediaries. So, a

>> proxy

>> =A0 =A0 =A0>>>>> that only understands application/=
sdp (e.g. for gate control

>> =A0 =A0 =A0>>>>> purpose) will not even look at the=
 C-D header field value for

>> =A0 =A0 =A0>>>>> other bodies. And, unless such pro=
xy understands POF/PAN, there

>> =A0 =A0 =A0>>>>> may not be any media passing throu=
gh...

>> =A0 =A0 =A0>>>>

>> =A0 =A0 =A0>>>> Right. A middlebox that doesn't un=
derstand application/sdpfrag

>> =A0 =A0 =A0>>>> won't know to look at its contents=
 and let the new streams

>> =A0 =A0 through.

>> =A0 =A0 =A0>>>> And a middlebox that sees something ma=
rked as

>> =A0 =A0 "application/sdp" that conveys only a tiny fract=
ion of the session

>> =A0 =A0 will probably be just as catastrophic; I would imagine eve=
rything

>> =A0 =A0 but the modified streams would be shut off. There's no=
 way to win

>> here.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I think it would reject the Offer - at lea=
st that's what it

>> =A0 =A0 should do according to 3264.

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> 3264 only talks about how to process offers an=
d answers described

>> in

>> =A0 =A0 =A0>> SDP. It does not say how those are conveyed in=
 sip. 3261 says

>> =A0 =A0 that they are carried in body parts of content-type applic=
ation/sdp

>> =A0 =A0 with content-disposition of 'session'. If a body p=
art has

>> =A0 =A0 content-type application/sdp but has a disposition other t=
han

>> =A0 =A0 'session' then it isn't an offer or answer acc=
ording to 3261, and so

>> =A0 =A0 3264 doesn't apply.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> 3264 says that all m- line must be present in an O=
ffer - even if

>> =A0 =A0 they are not modified. So, what I meant was that in case a=
ll m-

>> =A0 =A0 lines are NOT present (in the case of a POF), such Offer w=
ould be

>> =A0 =A0 rejected - unless the middlebox understands the POF/PAN me=
chanism .

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>> At some point, we have to come to peac=
e with the fact that any

>> =A0 =A0 middleboxes that aren't primarily in the business of s=
tifling

>> =A0 =A0 progress will need to keep pace with protocol extensions a=
s they get

>> =A0 =A0 deployed.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I really wish things worked that way :)
>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> So progress ends because middleboxes don't=
 permit it?

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> Maybe you are right. Then sip will go the way =
of h323 while the

>> =A0 =A0 world moves on to webrtc.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I think that getting explicit rejections, rather t=
han having to

>> =A0 =A0 try to

>> =A0 =A0 =A0> figure out where things go wrong, is good for prog=
ress :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Anyway, it wasn't really a suggestion - I just=
 wanted to do some

>> =A0 =A0 =A0> brainstorming :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Regards,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Christer

>> =A0 =A0 =A0>

>>

>> =A0 =A0 _______________________________________________

>> =A0 =A0 mmusic mailing list

>> =A0 =A0 mmusi=
c@ietf.org <mailto:mmusic@ietf.org>

>> =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 67000 Strasbou=
rg,

Project Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 France

Jitsi

emcho@jitsi.org =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PHONE:
+33.1.77.62.43.30

https://jitsi.org =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FAX: =A0
+33.1.77.62.47.31

_______________________________________________

mmusic mailing list

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















--e89a8ffba9795cce3504e91a178d--

From christer.holmberg@ericsson.com  Sat Oct 19 09:44: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 B103A21F9EFE for ; Sat, 19 Oct 2013 09:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.897
X-Spam-Level: 
X-Spam-Status: No, score=-3.897 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTXGet4gYEur for ; Sat, 19 Oct 2013 09:44:18 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC7C21F9EFB for ; Sat, 19 Oct 2013 09:44:16 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-6c-5262b6dfd086
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B6.E2.25272.FD6B2625; Sat, 19 Oct 2013 18:44:15 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 18:44:15 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eYAARXaAgABat3z//+HsAIAALhiw
Date: Sat, 19 Oct 2013 16:44:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4D6F06ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvje79bUlBBj1rxSzW7JzAYjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBl3H2zg6lg3mKmijvz7zI2 MB75xtjFyMkhIWAicWz/FyYIW0ziwr31bF2MXBxCAkcZJS51dzJBOEsYJQ6v2MvSxcjBwSZg IdH9TxukQURAXqK7bRFYM7OAk8S1rpfMILawgJdEz8xeFogab4n/969C2VES2z8uB6thEVCV mPX5MZjNK+ArcWfpFzBbSGAOu8SJ77IgNqdAoMTRziawXkag476fWgO1S1ziw8HrzBBHC0gs 2XMeyhaVePn4HyuErSSx9vB2Foj6fIll27+yQewSlDg58wnLBEbRWUhGzUJSNgtJGURcT+LG 1ClsELa2xLKFr6HqdSVm/DvEgiy+gJF9FSNHcWpxUm66kcEmRmCsHdzy22IH4+W/NocYpTlY lMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKQWMmKut17kZw+WuxvLMyP+3VbT6rmL2 zJy7M25XHizk5mD+qbQ62V86Wm1GJPdMvoaT2zgan13m3fDBfgJrztrrvvKvV0iu9f6ixsYZ mTjdzVKXe+ezlafXZ0UprzsX0Pr28eW5zrE70yYcOaQfdWrHVJbzssJdMz+ZuUrvDbjZUaeZ 8jH+4YZSJZbijERDLeai4kQA8LbdDIMCAAA=
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 16:44:23 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4D6F06ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am trying to figure out how/if O/A and trickle ICE interact when it comes=
 to providing candidates.

But, let's start with a more simple example:


-          I provide candidates A, B and C using O/A

-          Later, I provide candidates D and E using trickle ICE

-          Then, I send a new O/A, with candidates A, B and C

Now, are candidates D and E still valid, or did my new O/A disable them?

Regards,

Christer

L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
L=E4hetetty: 19. lokakuuta 2013 18:56
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


The new SDP O/A you mention would cause an ICE restart and that's what will=
 define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about tric=
kled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" > wrote:

Hi Emil,



Assume you have an m- line, for which you provide candidates using trickle =
ICE.



Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.



Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov > wrote:



Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" > wrote:
Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).

I don't think this is accurate. Use of SDP for additional candidates is jus=
t a coincidence. It was readily available syntax for describing candidates =
and it might be convenient in some implementations (although this is probab=
ly of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.
Also, trickled candidates DO NOT update the session SDP the way a new m=3D =
line does. There is only a loose relation between them and subsequent O/As.=
 The origin field does NOT need to be updated. New candidates in new O/As m=
ay appear without having been trickled and trickled candidates can just wel=
l be omitted in subsequent O/As. In other words, a trickled candidate would=
 only affect the state of the ICE agent in exactly the same way a peer refl=
exive candidate would and it would be orthogonal to O/A, again, just as pee=
r reflexive candidates are.

So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?

OK, maybe "can't" is not entirely accurate here. I am sure that we *could* =
make it would with O/A if we really put our backs into it. In a similar way=
, I am sure we could also make it work by exchanging candidates in a shared=
 Dropbox folder. In either case, I don't see why we would want to incur suc=
h a thing on our selves. I don't see any advantage to doing this.
On the downside, trickling candidates in Offer/Answer would imply the follo=
wing problems:
*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare a=
nd I sincerely advise anyone supporting offer answer for trickle to first t=
ry and implement it).
* Ambiguity between ICE restarts and trickle updates.
Also, given how we have already had this discussion and converged on use of=
 INFO, it is unclear to to me as to why we are revisiting this. I don't thi=
nk anyone has reported any problems on the alternative.

Cheers,
Emil


Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov > wrote:


On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat > wrote:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies th=
at
> the the body is just a different representation of an offer or answer. (W=
e
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>>  <=
mailto:christer.holmberg@ericsson.com>>
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, the=
re
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers describe=
d
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     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



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1=
.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_7594FB04B1934943A5C02806D1A2204B1C4D6F06ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 =
;


I am tryin=
g to figure out how/if O/A and trickle ICE interact when it comes to provid=
ing candidates.


 =
;


But, let&#=
8217;s start with a more simple example:      =
;   



 =
;


-         
I =
provide candidates A, B and C using O/A


-         
La=
ter, I provide candidates D and E using trickle ICE


-         
Th=
en, I send a new O/A, with candidates A, B and C


 =
;


Now, are c=
andidates D and E still valid, or did my new O/A disable them?


 =
;


Regards,


 =
;


Christer


 =
;


L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


 


The new SDP O/A you mention would cause an ICE restart and that's what w=
ill define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" =
<christer.holmberg@eri=
csson.com> wrote:




Hi Emil,


=
 


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
 


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.


=
 


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?


=
 


=
Regards,


=
 


=
Christer


=
 


=
Sent from my Sony Ericsson Xperia arc S


=
 


=
Emil Ivov <emcho@ji=
tsi.org> wrote:


=
 






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




 






I don't think this is=
 accurate. Use of SDP for additional candidates is just a coincidence. It w=
as readily available syntax for describing candidates and it might be conve=
nient in some implementations (although
 this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session =
SDP the way a new m=3D line does. There is only a loose relation between th=
em and subsequent O/As. The origin field does NOT need to be updated. New c=
andidates in new O/As may appear without
 having been trickled and trickled candidates can just well be omitted in s=
ubsequent O/As. In other words, a trickled candidate would only affect the =
state of the ICE agent in exactly the same way a peer reflexive candidate w=
ould and it would be orthogonal
 to O/A, again, just as peer reflexive candidates are.






 






So, while we would need to think about whether using=
 POF/PAN would make sense or not, why do you think that we "can't"=
; do it?






 






OK, maybe "can't=
" is not entirely accurate here. I am sure that we *could* make it wou=
ld with O/A if we really put our backs into it. In a similar way, I am sure=
 we could also make it work by exchanging candidates
 in a shared Dropbox folder. In either case, I don't see why we would want =
to incur such a thing on our selves. I don't see any advantage to doing thi=
s.






On the downside, tric=
kling candidates in Offer/Answer would imply the following problems:






*  Very high glare probability.






* Unnecessarily complex implementation (really, this=
 would be a nightmare and I sincerely advise anyone supporting offer answer=
 for trickle to first try and implement it).







* Ambiguity between I=
CE restarts and trickle updates.






Also, given how we have already had this discussion =
and converged on use of INFO, it is unclear to to me as to why we are revis=
iting this. I don't think anyone has reported any problems on the alternati=
ve.



Cheers,

Emil 






 








Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type implies=
 that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We

are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

>         Thanks,

>         Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>

>>

>> wrote:

>>

>>     Hi,

>>

>>      > I think you and I are thinking of this di=
fferently.

>>      >

>>      > I'm thinking that the POFs and PANs are s=
omething new, different

>>     from offers and answers. They go on *between* offers=
 and answers.

>>      >

>>      > IIUC you are thinking of POFs and PANs as=
 extended forms of

>>     offers and answers.

>>

>>     It's not the way I think - I just wanted to explore =
how/if things

>>     would work IF we were thinking like that, and what t=
he pros and cons

>>     would be :)

>>

>>     We have to keep in mind that, no matter how we look =
at it, the

>>     Offers/Answers and POFs/PANs are tightly connected, =
meaning that

>>     they impact the same SDP state, can cause race condi=
tions etc.

>>

>>     Regards,

>>

>>     Christer

>>

>>

>>

>>

>>

>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:

>>      > Hi,

>>      >

>>      >>>>> Content-Disposition does =
not apply to intermediaries. So, a

>> proxy

>>      >>>>> that only understands app=
lication/sdp (e.g. for gate control

>>      >>>>> purpose) will not even lo=
ok at the C-D header field value for

>>      >>>>> other bodies. And, unless=
 such proxy understands POF/PAN, there

>>      >>>>> may not be any media pass=
ing through...

>>      >>>>

>>      >>>> Right. A middlebox that doesn=
't understand application/sdpfrag

>>      >>>> won't know to look at its con=
tents and let the new streams

>>     through.

>>      >>>> And a middlebox that sees som=
ething marked as

>>     "application/sdp" that conveys only a tiny=
 fraction of the session

>>     will probably be just as catastrophic; I would imagi=
ne everything

>>     but the modified streams would be shut off. There's =
no way to win

>> here.

>>      >>>

>>      >>> I think it would reject the Offer=
 - at least that's what it

>>     should do according to 3264.

>>      >>

>>      >> 3264 only talks about how to process =
offers and answers described

>> in

>>      >> SDP. It does not say how those are co=
nveyed in sip. 3261 says

>>     that they are carried in body parts of content-type =
application/sdp

>>     with content-disposition of 'session'. If a body par=
t has

>>     content-type application/sdp but has a disposition o=
ther than

>>     'session' then it isn't an offer or answer according=
 to 3261, and so

>>     3264 doesn't apply.

>>      >

>>      > 3264 says that all m- line must be presen=
t in an Offer - even if

>>     they are not modified. So, what I meant was that in =
case all m-

>>     lines are NOT present (in the case of a POF), such O=
ffer would be

>>     rejected - unless the middlebox understands the POF/=
PAN mechanism .

>>      >

>>      >>>> At some point, we have to com=
e to peace with the fact that any

>>     middleboxes that aren't primarily in the business of=
 stifling

>>     progress will need to keep pace with protocol extens=
ions as they get

>>     deployed.

>>      >>>

>>      >>> I really wish things worked that =
way :)

>>      >>

>>      >> So progress ends because middleboxes =
don't permit it?

>>      >>

>>      >> Maybe you are right. Then sip will go=
 the way of h323 while the

>>     world moves on to webrtc.

>>      >

>>      > I think that getting explicit rejections,=
 rather than having to

>>     try to

>>      > figure out where things go wrong, is good=
 for progress :)

>>      >

>>      > Anyway, it wasn't really a suggestion - I=
 just wanted to do some

>>      > brainstorming :)

>>      >

>>      > Regards,

>>      >

>>      > Christer

>>      >

>>

>>     _______________________________________________

>>     mmusic mailing list

>>     mmusic@ietf.org <mailto:mmusic@ietf.org>

>>     https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D.                 &n=
bsp;     67000 Strasbourg,

Project Lead                  =
         France

Jitsi

emcho@jitsi.org &n=
bsp;                     =
 PHONE:
+33.1.77.62.43.30=


https://jitsi.org  =
;                     FAX=
:  
+33.1.77.62.47.31=


_______________________________________________

mmusic mailing list

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


















--_000_7594FB04B1934943A5C02806D1A2204B1C4D6F06ESESSMB209erics_--

From suhasietf@gmail.com  Sat Oct 19 09: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 2B88E11E8220 for ; Sat, 19 Oct 2013 09:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level: 
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HouQVIGCAoLB for ; Sat, 19 Oct 2013 09:53:29 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D75BE11E8214 for ; Sat, 19 Oct 2013 09:53:28 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id c11so4886927wgh.2 for ; Sat, 19 Oct 2013 09:53:28 -0700 (PDT)
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=MRyOAt/mo4bareEV+onoYBWkLtoVFnNukSNdfU+8SsU=; b=wfYg/lw7d4GqreZtEQawlgJQBe9GgCpDbVypXqYnVktLKrBMMXNawiD5RrxG8hXX/h yGgdMAAnaFtYqFtODY1jGtsp22PZKUohV7Ia0HVI5b+Zdu9XejmjD48ErwRPpgNfQGMz Cugx3JaqS1Gyyja8Lx+Wg9okru8P5/5EJeRnN/VGRUxqwZo/w+aZiiud/PDrqAwvyhs6 NSR0oiZDCWa8g9Rwt2XBXLD/j0wNlwPsJQU9fjICiHbbGSf5bWTrfhKgtJwwVyd7xvqM Jc7n8/XCPzUDUsJiM9nXTOUbsX2guYoeC2ljlvqGAwufnIE3WhthP1kwai79BypdeV6E 25Kw==
MIME-Version: 1.0
X-Received: by 10.180.210.146 with SMTP id mu18mr3708759wic.10.1382201607869;  Sat, 19 Oct 2013 09:53:27 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Sat, 19 Oct 2013 09:53:27 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>
Date: Sat, 19 Oct 2013 09:53:27 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=001a11c37fa6d859af04e91ae3c4
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 16:53:30 -0000

--001a11c37fa6d859af04e91ae3c4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Saturday, October 19, 2013, Christer Holmberg wrote:

>  Hi,****
>
> ** **
>
> I am trying to figure out how/if O/A and trickle ICE interact when it
> comes to providing candidates.****
>
> ** **
>
> But, let=92s start with a more simple example:          ****
>
> ** **
>
> **-          **I provide candidates A, B and C using O/A****
>
> **-          **Later, I provide candidates D and E using trickle ICE****
>
> **-          **Then, I send a new O/A, with candidates A, B and C****
>
> ** **
>
> Shouldn't the new O/A have all the candidates from A through E listed ..
Just a guess

> Now, are candidates D and E still valid, or did my new O/A disable them?*=
*
> **
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *L=E4hett=E4j=E4:* Emil Ivov [mailto:emcho@jitsi.org  'emcho@jitsi.org');>]
> *L=E4hetetty:* 19. lokakuuta 2013 18:56
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Paul Kyzivat; mmusic
> *Aihe:* Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value=
*
> ***
>
> ** **
>
> The new SDP O/A you mention would cause an ICE restart and that's what
> will define agent state. Not previously exchange trickled candidates. ***=
*
>
> I am not sure I understand the relation to your argument though (about
> trickled candidates affecting session SDP) so I might be missing your poi=
nt.
> ****
>
> Emil****
>
> --sent from my mobile****
>
> On 19 Oct 2013 17:43, "Christer Holmberg" 
> wrote:****
>
> Hi Emil,****
>
> ** **
>
> Assume you have an m- line, for which you provide candidates using trickl=
e ICE.****
>
> ** **
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means i=
t will inherit the address properties and candidates of the BUNDLE group.**=
**
>
> ** **
>
> Are you saying that the previously provided trickle candidates are still =
comsidered valid, eventhough they are associated with different address pro=
perties etc?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> Sent from my Sony Ericsson Xperia arc S****
>
> ** **
>
> Emil Ivov  wrote:****
>
> ** **
>
>  Hey Christer,****
>
> On 19 Oct 2013 08:10, "Christer Holmberg" 
> wrote:****
>
> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session SDP
> (bacause, as you said, they are sent within SDP).****
>
> ** **
>
> I don't think this is accurate. Use of SDP for additional candidates is
> just a coincidence. It was readily available syntax for describing
> candidates and it might be convenient in some implementations (although
> this is probably of marginal value).
>
> The point is that the syntax is not due to a relationship to Offer/Answer
> and could have just as easily be based on JSON or XML or anything else. *=
*
> **
>
> Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D
> line does. There is only a loose relation between them and subsequent O/A=
s.
> The origin field does NOT need to be updated. New candidates in new O/As
> may appear without having been trickled and trickled candidates can just
> well be omitted in subsequent O/As. In other words, a trickled candidate
> would only affect the state of the ICE agent in exactly the same way a pe=
er
> reflexive candidate would and it would be orthogonal to O/A, again, just =
as
> peer reflexive candidates are.****
>
>  ****
>
> So, while we would need to think about whether using POF/PAN would make
> sense or not, why do you think that we "can't" do it?****
>
>  ** **
>
> OK, maybe "can't" is no
>

--001a11c37fa6d859af04e91ae3c4
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Saturday, October 19, 2013, Christer Holmberg  wrote:











Hi,=



=A0=



I am tryin=
g to figure out how/if O/A and trickle ICE interact when it comes to provid=
ing candidates.



=A0=



But, let=
=92s start with a more simple example:=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=



-=A0=A0=A0=A0=A0=A0=A0=A0=A0
I pro=
vide candidates A, B and C using O/A


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Later=
, I provide candidates D and E using trickle ICE


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Then,=
 I send a new O/A, with candidates A, B and C


=A0=

=
Shouldn't the new O/A have all the candidates from A through E listed .=
.=A0


Just a guess=A0=A0


Now, are c=
andidates D and E still valid, or did my new O/A disable them?



=A0=



Regards,


=A0=



Christer


=A0=



L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


=A0


The new SDP O/A you mention would cause an ICE restart and that's wh=
at will define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" <christer.holm=
berg@ericsson.com> wrote:




Hi Emil,


=
=A0


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
=A0


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.<=
/u>



=
=A0


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?



=
=A0


=
Regards,


=
=A0


=
Christer


=
=A0


=
Sent from my Sony Ericsson Xperia arc S


=
=A0


=
Emil Ivov <emcho@jitsi.org> wrote:


=
=A0






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" <christer.holm=
berg@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




=A0






I don't think this is accurate. Use o=
f SDP for additional candidates is just a coincidence. It was readily avail=
able syntax for describing candidates and it might be convenient in some im=
plementations (although
 this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D line does. There is only a loose relation between them and subsequent O=
/As. The origin field does NOT need to be updated. New candidates in new O/=
As may appear without
 having been trickled and trickled candidates can just well be omitted in s=
ubsequent O/As. In other words, a trickled candidate would only affect the =
state of the ICE agent in exactly the same way a peer reflexive candidate w=
ould and it would be orthogonal
 to O/A, again, just as peer reflexive candidates are.






=A0






So, while we would need to think about whether using POF/PAN would make =
sense or not, why do you think that we "can't" do it?<=
u>






=A0






OK, maybe "can't" is no
=








--001a11c37fa6d859af04e91ae3c4--

From emcho@sip-communicator.org  Sat Oct 19 09:54: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 39D8321F9EF6 for ; Sat, 19 Oct 2013 09:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.22
X-Spam-Level: 
X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.244,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTJFLoAvM5if for ; Sat, 19 Oct 2013 09:54:49 -0700 (PDT)
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7B43511E8214 for ; Sat, 19 Oct 2013 09:54:36 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id y10so2845141pdj.38 for ; Sat, 19 Oct 2013 09:54:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ookfUasqc/pATBuNbcOrRfw8htrBPKP8Sl/th8iczl8=; b=acnZFSIGJJchkRKHmqog9a4lHniPYjIFwiU/nHQORsZ158tC4J0oTmdbP9ywfpogV3 DD1o9icb10Nq1lISoLmERDHD94km7O/t+PIA4Vg5Dge7rDgDUEazt5RaeSMMIq4kKzMI DEieiqznHh06i2XiEulmkXu7cdTdsxaTkI1oyLisjFk9gC6H/p+2FTTHgQ2WdXLP6IXI YqR6M9WCRzs9wUxOX7YcNABWKY2WBRCnMtKjuVLKwIkVKNPWSkYRWSkHTP+dHWKYT/az WPyNgE1r6+wYelLyi5LZs/sf5pCPVxbHdDLWZcIzjZLMDkbyeSrQN2QDAxd4GdLuTk7t Pk5w==
X-Gm-Message-State: ALoCoQk+eYwTjDwpnUO3W68Dpcl+wrZr/BW1SDJW23P8dbMG8yyC7wXD3AKeqe7GYmEGlWWhK6D8
X-Received: by 10.66.145.166 with SMTP id sv6mr9194399pab.31.1382201676092; Sat, 19 Oct 2013 09:54:36 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [2607:f8b0:400e:c02::22b]) by mx.google.com with ESMTPSA id f2sm9768201pbg.44.2013.10.19.09.54.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 09:54:35 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id z10so6294172pdj.2 for ; Sat, 19 Oct 2013 09:54:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.235.72 with SMTP id uk8mr8868389pbc.93.1382201674866; Sat, 19 Oct 2013 09:54:34 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 09:54:34 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 09:54:34 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>
Date: Sat, 19 Oct 2013 11:54:34 -0500
Message-ID: 
From: Emil Ivov 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b33914fd6c48b04e91ae7e6
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 16:54:53 -0000

--047d7b33914fd6c48b04e91ae7e6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

If D and E are not provided and checked in the new O/A then they are no
longer valid. Think of them as peer reflexive.

--sent from my mobile
On 19 Oct 2013 18:44, "Christer Holmberg" 
wrote:

>  Hi,****
>
> ** **
>
> I am trying to figure out how/if O/A and trickle ICE interact when it
> comes to providing candidates.****
>
> ** **
>
> But, let=92s start with a more simple example:          ****
>
> ** **
>
> **-          **I provide candidates A, B and C using O/A****
>
> **-          **Later, I provide candidates D and E using trickle ICE****
>
> **-          **Then, I send a new O/A, with candidates A, B and C****
>
> ** **
>
> Now, are candidates D and E still valid, or did my new O/A disable them?*=
*
> **
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *L=E4hett=E4j=E4:* Emil Ivov [mailto:emcho@jitsi.org]
> *L=E4hetetty:* 19. lokakuuta 2013 18:56
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Paul Kyzivat; mmusic
> *Aihe:* Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value=
*
> ***
>
> ** **
>
> The new SDP O/A you mention would cause an ICE restart and that's what
> will define agent state. Not previously exchange trickled candidates. ***=
*
>
> I am not sure I understand the relation to your argument though (about
> trickled candidates affecting session SDP) so I might be missing your poi=
nt.
> ****
>
> Emil****
>
> --sent from my mobile****
>
> On 19 Oct 2013 17:43, "Christer Holmberg" 
> wrote:****
>
> Hi Emil,****
>
> ** **
>
> Assume you have an m- line, for which you provide candidates using trickl=
e ICE.****
>
> ** **
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means i=
t will inherit the address properties and candidates of the BUNDLE group.**=
**
>
> ** **
>
> Are you saying that the previously provided trickle candidates are still =
comsidered valid, eventhough they are associated with different address pro=
perties etc?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> Sent from my Sony Ericsson Xperia arc S****
>
> ** **
>
> Emil Ivov  wrote:****
>
> ** **
>
>  Hey Christer,****
>
> On 19 Oct 2013 08:10, "Christer Holmberg" 
> wrote:****
>
> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session SDP
> (bacause, as you said, they are sent within SDP).****
>
> ** **
>
> I don't think this is accurate. Use of SDP for additional candidates is
> just a coincidence. It was readily available syntax for describing
> candidates and it might be convenient in some implementations (although
> this is probably of marginal value).
>
> The point is that the syntax is not due to a relationship to Offer/Answer
> and could have just as easily be based on JSON or XML or anything else. *=
*
> **
>
> Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D
> line does. There is only a loose relation between them and subsequent O/A=
s.
> The origin field does NOT need to be updated. New candidates in new O/As
> may appear without having been trickled and trickled candidates can just
> well be omitted in subsequent O/As. In other words, a trickled candidate
> would only affect the state of the ICE agent in exactly the same way a pe=
er
> reflexive candidate would and it would be orthogonal to O/A, again, just =
as
> peer reflexive candidates are.****
>
>  ****
>
> So, while we would need to think about whether using POF/PAN would make
> sense or not, why do you think that we "can't" do it?****
>
>  ** **
>
> OK, maybe "can't" is not entirely accurate here. I am sure that we *could=
*
> make it would with O/A if we really put our backs into it. In a similar
> way, I am sure we could also make it work by exchanging candidates in a
> shared Dropbox folder. In either case, I don't see why we would want to
> incur such a thing on our selves. I don't see any advantage to doing this=
.
> ****
>
> On the downside, trickling candidates in Offer/Answer would imply the
> following problems:****
>
> *  Very high glare probability.****
>
> * Unnecessarily complex implementation (really, this would be a nightmare
> and I sincerely advise anyone supporting offer answer for trickle to firs=
t
> try and implement it). ****
>
> * Ambiguity between ICE restarts and trickle updates.****
>
> Also, given how we have already had this discussion and converged on use
> of INFO, it is unclear to to me as to why we are revisiting this. I don't
> think anyone has reported any problems on the alternative.
>
> Cheers,
> Emil ****
>
>  ****
>
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov  wrote:
>
>
> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat 
> wrote:
> > On 10/18/13 6:11 PM, Emil Ivov wrote:
> >>
> >> I do think that a different MIME type makes more sense here for the
> >> reasons Paul explained.
> >
> >
> > In the sip world, we may *also* want a new content-disposition. Using
> > 'session' as the content-disposition with the new content type implies
> that
> > the the body is just a different representation of an offer or answer.
> (We
> > were once considering exactly that with SDPng.)
> >
> > We *might* want to think of it that way, or not.
> >
> >
> >> It might be worth adding that the same MIME type would be used when
> >> sending candidate updates with Trickle ICE for SIP, which to me at
> >> least, makes a lot of sense.
> >
> >
> > I still wonder why trickle ICE needs a *different* mechanism for partia=
l
> > offers. Couldn't we just use this one?
>
> By "this one", do you mean POF/PAN or application/sdpfrag?
>
> We don't need anything different than application/sdpfrag.
>
> We can't use POF/PAN because we are not sending offers and answers. We
> are just exchanging candidates in agent-to-agent messages. The use of
> SDP is an unfortunate coincidence, not an indication of offers and
> answers.
>
> Emil
>
> >
> >         Thanks,
> >         Paul
> >
> >> --sent from my mobile
> >>
> >> On 18 Oct 2013 16:55, "Christer Holmberg"
> >>  >>
> >>
> >> wrote:
> >>
> >>     Hi,
> >>
> >>      > I think you and I are thinking of this differently.
> >>      >
> >>      > I'm thinking that the POFs and PANs are something new, differen=
t
> >>     from offers and answers. They go on *between* offers and answers.
> >>      >
> >>      > IIUC you are thinking of POFs and PANs as extended forms of
> >>     offers and answers.
> >>
> >>     It's not the way I think - I just wanted to explore how/if things
> >>     would work IF we were thinking like that, and what the pros and co=
ns
> >>     would be :)
> >>
> >>     We have to keep in mind that, no matter how we look at it, the
> >>     Offers/Answers and POFs/PANs are tightly connected, meaning that
> >>     they impact the same SDP state, can cause race conditions etc.
> >>
> >>     Regards,
> >>
> >>     Christer
> >>
> >>
> >>
> >>
> >>
> >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
> >>      > Hi,
> >>      >
> >>      >>>>> Content-Disposition does not apply to intermediaries. So, a
> >> proxy
> >>      >>>>> that only understands application/sdp (e.g. for gate contro=
l
> >>      >>>>> purpose) will not even look at the C-D header field value f=
or
> >>      >>>>> other bodies. And, unless such proxy understands POF/PAN,
> there
> >>      >>>>> may not be any media passing through...
> >>      >>>>
> >>      >>>> Right. A middlebox that doesn't understand application/sdpfr=
ag
> >>      >>>> won't know to look at its contents and let the new streams
> >>     through.
> >>      >>>> And a middlebox that sees something marked as
> >>     "application/sdp" that conveys only a tiny fraction of the session
> >>     will probably be just as catastrophic; I would imagine everything
> >>     but the modified streams would be shut off. There's no way to win
> >> here.
> >>      >>>
> >>      >>> I think it would reject the Offer - at least that's what it
> >>     should do according to 3264.
> >>      >>
> >>      >> 3264 only talks about how to process offers and answers
> described
> >> in
> >>      >> SDP. It does not say how those are conveyed in sip. 3261 says
> >>     that they are carried in body parts of content-type application/sd=
p
> >>     with content-disposition of 'session'. If a body part has
> >>     content-type application/sdp but has a disposition other than
> >>     'session' then it isn't an offer or answer according to 3261, and =
so
> >>     3264 doesn't apply.
> >>      >
> >>      > 3264 says that all m- line must be present in an Offer - even i=
f
> >>     they are not modified. So, what I meant was that in case all m-
> >>     lines are NOT present (in the case of a POF), such Offer would be
> >>     rejected - unless the middlebox understands the POF/PAN mechanism =
.
> >>      >
> >>      >>>> At some point, we have to come to peace with the fact that a=
ny
> >>     middleboxes that aren't primarily in the business of stifling
> >>     progress will need to keep pace with protocol extensions as they g=
et
> >>     deployed.
> >>      >>>
> >>      >>> I really wish things worked that way :)
> >>      >>
> >>      >> So progress ends because middleboxes don't permit it?
> >>      >>
> >>      >> Maybe you are right. Then sip will go the way of h323 while th=
e
> >>     world moves on to webrtc.
> >>      >
> >>      > I think that getting explicit rejections, rather than having to
> >>     try to
> >>      > figure out where things go wrong, is good for progress :)
> >>      >
> >>      > Anyway, it wasn't really a suggestion - I just wanted to do som=
e
> >>      > brainstorming :)
> >>      >
> >>      > Regards,
> >>      >
> >>      > Christer
> >>      >
> >>
> >>     _______________________________________________
> >>     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
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> https://jitsi.org                       FAX:   +33.1.77.62.47.31
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic****
>
>

--047d7b33914fd6c48b04e91ae7e6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


If D and E are not provided and checked in the new O/A then =
they are no longer valid. Think of them as peer reflexive.


--sent from my mobile


On 19 Oct 2013 18:44, "Christer Holmberg&qu=
ot; <christer.holmberg=
@ericsson.com> wrote:












Hi,=



=A0=



I am tryin=
g to figure out how/if O/A and trickle ICE interact when it comes to provid=
ing candidates.



=A0=



But, let=
=92s start with a more simple example:=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=



-=A0=A0=A0=A0=A0=A0=A0=A0=A0
I pro=
vide candidates A, B and C using O/A


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Later=
, I provide candidates D and E using trickle ICE


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Then,=
 I send a new O/A, with candidates A, B and C


=A0=



Now, are c=
andidates D and E still valid, or did my new O/A disable them?



=A0=



Regards,


=A0=



Christer


=A0=



L=E4hett=E4j=E4: Emil Ivov [mailto:e=
mcho@jitsi.org]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


=A0


The new SDP O/A you mention would cause an ICE restart and that's wh=
at will define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi Emil,


=
=A0


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
=A0


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.<=
/u>



=
=A0


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?



=
=A0


=
Regards,


=
=A0


=
Christer


=
=A0


=
Sent from my Sony Ericsson Xperia arc S


=
=A0


=
Emil Ivov <emcho@ji=
tsi.org> wrote:


=
=A0






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




=A0






I don't think thi=
s is accurate. Use of SDP for additional candidates is just a coincidence. =
It was readily available syntax for describing candidates and it might be c=
onvenient in some implementations (although
 this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session =
SDP the way a new m=3D line does. There is only a loose relation between th=
em and subsequent O/As. The origin field does NOT need to be updated. New c=
andidates in new O/As may appear without
 having been trickled and trickled candidates can just well be omitted in s=
ubsequent O/As. In other words, a trickled candidate would only affect the =
state of the ICE agent in exactly the same way a peer reflexive candidate w=
ould and it would be orthogonal
 to O/A, again, just as peer reflexive candidates are.






=A0






So, while we would need to think about whether using=
 POF/PAN would make sense or not, why do you think that we "can't&=
quot; do it?






=A0






OK, maybe "can&#=
39;t" is not entirely accurate here. I am sure that we *could* make it=
 would with O/A if we really put our backs into it. In a similar way, I am =
sure we could also make it work by exchanging candidates
 in a shared Dropbox folder. In either case, I don't see why we would w=
ant to incur such a thing on our selves. I don't see any advantage to d=
oing this.






On the downside, tric=
kling candidates in Offer/Answer would imply the following problems:=







*=A0 Very high glare probability.






* Unnecessarily complex implementation (really, this=
 would be a nightmare and I sincerely advise anyone supporting offer answer=
 for trickle to first try and implement it).







* Ambiguity between I=
CE restarts and trickle updates.






Also, given how we have already had this discussion =
and converged on use of INFO, it is unclear to to me as to why we are revis=
iting this. I don't think anyone has reported any problems on the alter=
native.




Cheers,

Emil 






=A0








Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type=
 implies that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We<=
br>
are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

> =A0 =A0 =A0 =A0 Thanks,

> =A0 =A0 =A0 =A0 Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>


>>

>> wrote:

>>

>> =A0 =A0 Hi,

>>

>> =A0 =A0 =A0> I think you and I are thinking of this differently=
.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I'm thinking that the POFs and PANs are someth=
ing new, different

>> =A0 =A0 from offers and answers. They go on *between* offers and a=
nswers.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> IIUC you are thinking of POFs and PANs as extended=
 forms of

>> =A0 =A0 offers and answers.

>>

>> =A0 =A0 It's not the way I think - I just wanted to explore ho=
w/if things

>> =A0 =A0 would work IF we were thinking like that, and what the pro=
s and cons

>> =A0 =A0 would be :)

>>

>> =A0 =A0 We have to keep in mind that, no matter how we look at it,=
 the

>> =A0 =A0 Offers/Answers and POFs/PANs are tightly connected, meanin=
g that

>> =A0 =A0 they impact the same SDP state, can cause race conditions =
etc.

>>

>> =A0 =A0 Regards,

>>

>> =A0 =A0 Christer

>>

>>

>>

>>

>>

>> =A0 =A0 On 10/18/13 5:06 PM, Christer Holmberg wrote:

>> =A0 =A0 =A0> Hi,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>>> Content-Disposition does not apply=
 to intermediaries. So, a

>> proxy

>> =A0 =A0 =A0>>>>> that only understands application/=
sdp (e.g. for gate control

>> =A0 =A0 =A0>>>>> purpose) will not even look at the=
 C-D header field value for

>> =A0 =A0 =A0>>>>> other bodies. And, unless such pro=
xy understands POF/PAN, there

>> =A0 =A0 =A0>>>>> may not be any media passing throu=
gh...

>> =A0 =A0 =A0>>>>

>> =A0 =A0 =A0>>>> Right. A middlebox that doesn't un=
derstand application/sdpfrag

>> =A0 =A0 =A0>>>> won't know to look at its contents=
 and let the new streams

>> =A0 =A0 through.

>> =A0 =A0 =A0>>>> And a middlebox that sees something ma=
rked as

>> =A0 =A0 "application/sdp" that conveys only a tiny fract=
ion of the session

>> =A0 =A0 will probably be just as catastrophic; I would imagine eve=
rything

>> =A0 =A0 but the modified streams would be shut off. There's no=
 way to win

>> here.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I think it would reject the Offer - at lea=
st that's what it

>> =A0 =A0 should do according to 3264.

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> 3264 only talks about how to process offers an=
d answers described

>> in

>> =A0 =A0 =A0>> SDP. It does not say how those are conveyed in=
 sip. 3261 says

>> =A0 =A0 that they are carried in body parts of content-type applic=
ation/sdp

>> =A0 =A0 with content-disposition of 'session'. If a body p=
art has

>> =A0 =A0 content-type application/sdp but has a disposition other t=
han

>> =A0 =A0 'session' then it isn't an offer or answer acc=
ording to 3261, and so

>> =A0 =A0 3264 doesn't apply.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> 3264 says that all m- line must be present in an O=
ffer - even if

>> =A0 =A0 they are not modified. So, what I meant was that in case a=
ll m-

>> =A0 =A0 lines are NOT present (in the case of a POF), such Offer w=
ould be

>> =A0 =A0 rejected - unless the middlebox understands the POF/PAN me=
chanism .

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>> At some point, we have to come to peac=
e with the fact that any

>> =A0 =A0 middleboxes that aren't primarily in the business of s=
tifling

>> =A0 =A0 progress will need to keep pace with protocol extensions a=
s they get

>> =A0 =A0 deployed.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I really wish things worked that way :)
>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> So progress ends because middleboxes don't=
 permit it?

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> Maybe you are right. Then sip will go the way =
of h323 while the

>> =A0 =A0 world moves on to webrtc.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I think that getting explicit rejections, rather t=
han having to

>> =A0 =A0 try to

>> =A0 =A0 =A0> figure out where things go wrong, is good for prog=
ress :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Anyway, it wasn't really a suggestion - I just=
 wanted to do some

>> =A0 =A0 =A0> brainstorming :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Regards,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Christer

>> =A0 =A0 =A0>

>>

>> =A0 =A0 _______________________________________________

>> =A0 =A0 mmusic mailing list

>> =A0 =A0 mmusi=
c@ietf.org <mailto:mmusic@ietf.org>

>> =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 67000 Strasbou=
rg,

Project Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 France

Jitsi

emcho@jitsi.org =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PHONE:
+33.1.77.62.43.30=


https://jitsi.org =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FAX: =A0
+33.1.77.62.47.31=


_______________________________________________

mmusic mailing list

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





















--047d7b33914fd6c48b04e91ae7e6--

From emcho@sip-communicator.org  Sat Oct 19 09:56: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 B7A2111E821C for ; Sat, 19 Oct 2013 09:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level: 
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AWL=0.279,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPagh9n5kK2B for ; Sat, 19 Oct 2013 09:56:01 -0700 (PDT)
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 369EB11E8225 for ; Sat, 19 Oct 2013 09:55:54 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id kx10so6039877pab.29 for ; Sat, 19 Oct 2013 09:55:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0vVYcU0Tjbkv/iZfwQhiq17BaisJ0UE19AhuAt0ucQM=; b=cKgE5KOERT9j3jypNjYf7/7AU4Vg3p9avqTQ2XNcUcKzR06g9BJb8CvLY+XNj5r7WN sZjh+1mhP4HSDky+bmLFsDg9RqNe7tXpjbM9znap4qnWwENtsS+0x1aY+m//nr8pbUZj YrgnEGXKe+G4txVm0ANwdnXyhH2yBacrYSKpOOWfjm2ZShZCmFp3kaE0saVUgH4GoVgZ rRHaWxU19Gt5WbbvC7RLDMvMuWtyIQ2kX80Z09I3DO85RJ8zBE8OQZ4fDFJP31906R34 f8P0dzB2S4e4NX0WBpcecPRWEuWdfvIwUCnU3O3mjZiQFLrzZALkFwCg7boDXL1P6CSm bVNg==
X-Gm-Message-State: ALoCoQn1huN79mV8uKa3L67KpNSsUhhOT4TESAJaSdtvtEIIBmy1Zpd6RU/KKLr2/aUyDuVq6UBB
X-Received: by 10.66.66.161 with SMTP id g1mr844455pat.175.1382201753781; Sat, 19 Oct 2013 09:55:53 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [2607:f8b0:400e:c02::230]) by mx.google.com with ESMTPSA id sb9sm9852629pbb.0.2013.10.19.09.55.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 09:55:52 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id g10so4968235pdj.21 for ; Sat, 19 Oct 2013 09:55:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.235.72 with SMTP id uk8mr8872124pbc.93.1382201752707; Sat, 19 Oct 2013 09:55:52 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 09:55:52 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 09:55:52 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se> 
Date: Sat, 19 Oct 2013 11:55:52 -0500
Message-ID: 
From: Emil Ivov 
To: Suhas Nandakumar 
Content-Type: multipart/alternative; boundary=047d7b33914f7a755804e91aec5e
Cc: mmusic , Paul Kyzivat , Christer Holmberg 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 16:56:15 -0000

--047d7b33914f7a755804e91aec5e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yes it could. It will be up to the implementation. Not providing them is
definitely an option.

--sent from my mobile
On 19 Oct 2013 18:53, "Suhas Nandakumar"  wrote:

>
>
> On Saturday, October 19, 2013, Christer Holmberg wrote:
>
>>  Hi,****
>>
>> ** **
>>
>> I am trying to figure out how/if O/A and trickle ICE interact when it
>> comes to providing candidates.****
>>
>> ** **
>>
>> But, let=92s start with a more simple example:          ****
>>
>> ** **
>>
>> **-          **I provide candidates A, B and C using O/A****
>>
>> **-          **Later, I provide candidates D and E using trickle ICE****
>>
>> **-          **Then, I send a new O/A, with candidates A, B and C****
>>
>> ** **
>>
>> Shouldn't the new O/A have all the candidates from A through E listed ..
> Just a guess
>
>> Now, are candidates D and E still valid, or did my new O/A disable them?=
*
>> ***
>>
>> ** **
>>
>> Regards,****
>>
>> ** **
>>
>> Christer****
>>
>> ** **
>>
>> *L=E4hett=E4j=E4:* Emil Ivov [mailto:emcho@jitsi.org]
>> *L=E4hetetty:* 19. lokakuuta 2013 18:56
>> *Vastaanottaja:* Christer Holmberg
>> *Kopio:* Paul Kyzivat; mmusic
>> *Aihe:* Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type valu=
e
>> ****
>>
>> ** **
>>
>> The new SDP O/A you mention would cause an ICE restart and that's what
>> will define agent state. Not previously exchange trickled candidates. **=
*
>> *
>>
>> I am not sure I understand the relation to your argument though (about
>> trickled candidates affecting session SDP) so I might be missing your po=
int.
>> ****
>>
>> Emil****
>>
>> --sent from my mobile****
>>
>> On 19 Oct 2013 17:43, "Christer Holmberg" 
>> wrote:****
>>
>> Hi Emil,****
>>
>> ** **
>>
>> Assume you have an m- line, for which you provide candidates using trick=
le ICE.****
>>
>> ** **
>>
>> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means =
it will inherit the address properties and candidates of the BUNDLE group.*=
***
>>
>> ** **
>>
>> Are you saying that the previously provided trickle candidates are still=
 comsidered valid, eventhough they are associated with different address pr=
operties etc?****
>>
>> ** **
>>
>> Regards,****
>>
>> ** **
>>
>> Christer****
>>
>> ** **
>>
>> Sent from my Sony Ericsson Xperia arc S****
>>
>> ** **
>>
>> Emil Ivov  wrote:****
>>
>> ** **
>>
>>  Hey Christer,****
>>
>> On 19 Oct 2013 08:10, "Christer Holmberg" 
>> wrote:****
>>
>> Hi Emil,
>>
>> Similar to POF/PAN, the sending of candidates do affect the session SDP
>> (bacause, as you said, they are sent within SDP).****
>>
>> ** **
>>
>> I don't think this is accurate. Use of SDP for additional candidates is
>> just a coincidence. It was readily available syntax for describing
>> candidates and it might be convenient in some implementations (although
>> this is probably of marginal value).
>>
>> The point is that the syntax is not due to a relationship to Offer/Answe=
r
>> and could have just as easily be based on JSON or XML or anything else. =
*
>> ***
>>
>> Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D
>> line does. There is only a loose relation between them and subsequent O/=
As.
>> The origin field does NOT need to be updated. New candidates in new O/As
>> may appear without having been trickled and trickled candidates can just
>> well be omitted in subsequent O/As. In other words, a trickled candidate
>> would only affect the state of the ICE agent in exactly the same way a p=
eer
>> reflexive candidate would and it would be orthogonal to O/A, again, just=
 as
>> peer reflexive candidates are.****
>>
>>  ****
>>
>> So, while we would need to think about whether using POF/PAN would make
>> sense or not, why do you think that we "can't" do it?****
>>
>>  ** **
>>
>> OK, maybe "can't" is no
>>
>

--047d7b33914f7a755804e91aec5e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Yes it could. It will be up to the implementation. Not provi=
ding them is definitely an option.


--sent from my mobile


On 19 Oct 2013 18:53, "Suhas Nandakumar&quo=
t; <suhasietf@gmail.com> w=
rote:



On Saturday, October 19, 2013, Christer Holmberg  wrote:











Hi,=



=A0=



I am tryin=
g to figure out how/if O/A and trickle ICE interact when it comes to provid=
ing candidates.




=A0=



But, let=
=92s start with a more simple example:=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=



-=A0=A0=A0=A0=A0=A0=A0=A0=A0
I pro=
vide candidates A, B and C using O/A


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Later=
, I provide candidates D and E using trickle ICE


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Then,=
 I send a new O/A, with candidates A, B and C


=A0=

=
Shouldn't the new O/A have all the candidates from A through E listed .=
.=A0



Just a guess=A0=A0


Now, are c=
andidates D and E still valid, or did my new O/A disable them?




=A0=



Regards,


=A0=



Christer


=A0=



L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


=A0


The new SDP O/A you mention would cause an ICE restart and that's wh=
at will define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" <christer.holm=
berg@ericsson.com> wrote:




Hi Emil,


=
=A0


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
=A0


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.<=
/u>




=
=A0


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?




=
=A0


=
Regards,


=
=A0


=
Christer


=
=A0


=
Sent from my Sony Ericsson Xperia arc S


=
=A0


=
Emil Ivov <emcho@jitsi.org> wrote:


=
=A0






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" <christer.holm=
berg@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




=A0






I don't think this is accurate. Use o=
f SDP for additional candidates is just a coincidence. It was readily avail=
able syntax for describing candidates and it might be convenient in some im=
plementations (although
 this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D line does. There is only a loose relation between them and subsequent O=
/As. The origin field does NOT need to be updated. New candidates in new O/=
As may appear without
 having been trickled and trickled candidates can just well be omitted in s=
ubsequent O/As. In other words, a trickled candidate would only affect the =
state of the ICE agent in exactly the same way a peer reflexive candidate w=
ould and it would be orthogonal
 to O/A, again, just as peer reflexive candidates are.






=A0






So, while we would need to think about whether using POF/PAN would make =
sense or not, why do you think that we "can't" do it?<=
u>






=A0






OK, maybe "can't" is no
=










--047d7b33914f7a755804e91aec5e--

From christer.holmberg@ericsson.com  Sat Oct 19 09:59: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 6B43011E8220 for ; Sat, 19 Oct 2013 09:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.7
X-Spam-Level: 
X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyRnZbIOtBIh for ; Sat, 19 Oct 2013 09:59:10 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B98C221F9D69 for ; Sat, 19 Oct 2013 09:59:06 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-03-5262ba5929c5
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A7.84.16099.95AB2625; Sat, 19 Oct 2013 18:59:05 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 18:59:05 +0200
From: Christer Holmberg 
To: Suhas Nandakumar 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eYAARXaAgABat3z//+HsAIAALhiw///h4oCAACHdUA==
Date: Sat, 19 Oct 2013 16:59:04 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4D8F74@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvjW7krqQgg8/b9C3W7JzAYjF1+WMW ixUbDrBa7JzbwezA4vH3/Qcmj52z7rJ7LFnyk8nj/5vAAJYoLpuU1JzMstQifbsErozmrg/M BY+kK6ZeaGJrYFwv1sXIwSEhYCLx/ZJfFyMnkCkmceHeerYuRi4OIYHDjBKb3j9jhnCWMErM 7OthBWlgE7CQ6P6nDdIgIqAlsXrxXCYQm1kgUWLh9TfMILawgJdEz8xeFogab4n/96+ygLSK CGRJTGkIBwmzCKhK3LsyhRHE5hXwlfg/+QAriC0ksJxD4vEpsDinQKDE8m0r2EBsRqDbvp9a A7VKXOLDwevMEDcLSCzZcx7KFpV4+fgfK4StJLH28HYWiHo9iRtTp7BB2NoSyxa+ZobYKyhx cuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS833MQIjKKDW37r7mA8dU7kEKM0B4uS OO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgdXZYt/le18WiP4oEly1N+n5q15Pr0 wLR/rJ8eLGA4lTltnZWS9zxrAZc/Rl72VZc3hH0/v9Ii+NyagOd199ZocOzbMPv231fSHyOX MKuH3DNPeOyQ+Fhd0vyarly4xqmp/Jc/z/3w7H68Z2G9fp1ByJSzN7fyxx/7Xm/t+cDIUczE pkH6mGu/EktxRqKhFnNRcSIAnOqh23ACAAA=
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 16:59:16 -0000

Hi,
=A0
>> I am trying to figure out how/if O/A and trickle ICE interact when it co=
mes to providing candidates.
>>
>> But, let's start with a more simple example:=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=20
>>
>>-=A0=A0=A0=A0=A0=A0=A0=A0=A0 I provide candidates A, B and C using O/A
>>-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Later, I provide candidates D and E using tr=
ickle ICE
>>-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Then, I send a new O/A, with candidates A, B=
 and C
>>=A0
>Shouldn't the new O/A have all the candidates from A through E listed ..=
=A0
>Just a guess=A0=A0

They may be listed.

But, Emil said: "New candidates in new O/As may appear without having been =
trickled and trickled candidates can just well be omitted in subsequent O/A=
s."

So, my question is in the case they are omitted in subsequent O/As: are the=
y removed, or does the subsequent O/A simply have no affect on the trickled=
 candidates?

Regards,

Christer




L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]=20
L=E4hetetty: 19. lokakuuta 2013 18:56
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
=A0
The new SDP O/A you mention would cause an ICE restart and that's what will=
 define agent state. Not previously exchange trickled candidates.=20
I am not sure I understand the relation to your argument though (about tric=
kled candidates affecting session SDP) so I might be missing your point.
Emil
--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg"  =
wrote:
Hi Emil,
=A0
Assume you have an m- line, for which you provide candidates using trickle =
ICE.
=A0
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.
=A0
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?
=A0
Regards,
=A0
Christer
=A0
Sent from my Sony Ericsson Xperia arc S
=A0
Emil Ivov  wrote:
=A0
Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg"  =
wrote:
Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).
=A0
I don't think this is accurate. Use of SDP for additional candidates is jus=
t a coincidence. It was readily available syntax for describing candidates =
and it might be convenient in some implementations (although this is probab=
ly of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.=20
Also, trickled candidates DO NOT update the session SDP the way a new m=3D =
line does. There is only a loose relation between them and subsequent O/As.=
 The origin field does NOT need to be updated. New candidates in new O/As m=
ay appear without having been trickled and trickled candidates can just wel=
l be omitted in subsequent O/As. In other words, a trickled candidate would=
 only affect the state of the ICE agent in exactly the same way a peer refl=
exive candidate would and it would be orthogonal to O/A, again, just as pee=
r reflexive candidates are.
=A0
So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?
=A0
OK, maybe "can't" is no

From christer.holmberg@ericsson.com  Sat Oct 19 10:01: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 0D86111E8215 for ; Sat, 19 Oct 2013 10:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Level: 
X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.539,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PpHT85y-wjg for ; Sat, 19 Oct 2013 10:01:29 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B39111E822C for ; Sat, 19 Oct 2013 10:01:24 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-d7-5262bae22957
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4D.A4.16099.2EAB2625; Sat, 19 Oct 2013 19:01:22 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 19:01:22 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eYAARXaAgABat3z//+HsAIAALhiw///iMgCAACMJcA==
Date: Sat, 19 Oct 2013 17:01:21 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4D8F8AESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje6jXUlBBiv2a1qs2TmBxWLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPP6/CQxgjuKySUnNySxLLdK3S+DKeHSvgaXg5Xqmio3PvzE1 MH5pYupi5OSQEDCRmNx0kQXCFpO4cG89G4gtJHCYUWL/5tIuRi4gewmjxIJFqxm7GDk42AQs JLr/aYPUiAjIS3S3LQKbwyzgJHGt6yUziC0sECCxZPYTdpByEYFAiQvb9CHKsyT6l/aClbMI qEr8+DoJbC2vgK/Ek4k/GCFWLeeQmLOtlx0kwQnU+37rPbCZjEC3fT+1BmqXuMSHg9eZIW4W kFiy5zyULSrx8vE/VghbSWLt4e0sEPX5EvfeTGeEWCYocXLmE5YJjKKzkIyahaRsFpIyiLie xI2pU9ggbG2JZQtfQ9XrSsz4d4gFWXwBI/sqRvbcxMyc9HLDTYzAODu45bfuDsZT50QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHClZ7D7KscYiS5D1tM+TRpU7Ha mSd/SmbH1Oc5vdm4/27Lt5sSuxZ0LtERUX/yXevyOxnWRfw/n/w897v6zfxZv+30ttxkedxy urbXWedWxs3JW34nLA1gFXpfF7a3rOv0rDU9wRPfzM2q35N3fk+Gdfl13jlH9XqX6S0VXCQo co3rlkDpqbPCSizFGYmGWsxFxYkAtEbzC4ECAAA=
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 17:01:34 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4D8F8AESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

> If D and E are not provided and checked in the new O/A then they are no l=
onger valid. Think of them as peer reflexive.

In that case there could be a race condition, if trickled candidates are pr=
ovided at the same time as an ongoing O/A.

Regards,

Christer





--sent from my mobile
On 19 Oct 2013 18:44, "Christer Holmberg" > wrote:
Hi,

I am trying to figure out how/if O/A and trickle ICE interact when it comes=
 to providing candidates.

But, let's start with a more simple example:


-          I provide candidates A, B and C using O/A

-          Later, I provide candidates D and E using trickle ICE

-          Then, I send a new O/A, with candidates A, B and C

Now, are candidates D and E still valid, or did my new O/A disable them?

Regards,

Christer

L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
L=E4hetetty: 19. lokakuuta 2013 18:56
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


The new SDP O/A you mention would cause an ICE restart and that's what will=
 define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about tric=
kled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" > wrote:

Hi Emil,



Assume you have an m- line, for which you provide candidates using trickle =
ICE.



Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.



Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov > wrote:



Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" > wrote:
Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).

I don't think this is accurate. Use of SDP for additional candidates is jus=
t a coincidence. It was readily available syntax for describing candidates =
and it might be convenient in some implementations (although this is probab=
ly of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.
Also, trickled candidates DO NOT update the session SDP the way a new m=3D =
line does. There is only a loose relation between them and subsequent O/As.=
 The origin field does NOT need to be updated. New candidates in new O/As m=
ay appear without having been trickled and trickled candidates can just wel=
l be omitted in subsequent O/As. In other words, a trickled candidate would=
 only affect the state of the ICE agent in exactly the same way a peer refl=
exive candidate would and it would be orthogonal to O/A, again, just as pee=
r reflexive candidates are.

So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?

OK, maybe "can't" is not entirely accurate here. I am sure that we *could* =
make it would with O/A if we really put our backs into it. In a similar way=
, I am sure we could also make it work by exchanging candidates in a shared=
 Dropbox folder. In either case, I don't see why we would want to incur suc=
h a thing on our selves. I don't see any advantage to doing this.
On the downside, trickling candidates in Offer/Answer would imply the follo=
wing problems:
*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare a=
nd I sincerely advise anyone supporting offer answer for trickle to first t=
ry and implement it).
* Ambiguity between ICE restarts and trickle updates.
Also, given how we have already had this discussion and converged on use of=
 INFO, it is unclear to to me as to why we are revisiting this. I don't thi=
nk anyone has reported any problems on the alternative.

Cheers,
Emil


Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov > wrote:


On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat > wrote:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies th=
at
> the the body is just a different representation of an offer or answer. (W=
e
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>>  <=
mailto:christer.holmberg@ericsson.com>>
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, the=
re
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers describe=
d
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     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



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1=
.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_7594FB04B1934943A5C02806D1A2204B1C4D8F8AESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


> If D and E are not provided and checked in the new O/A then they are =
no longer valid.
Think of them as peer reflexive.<=
/o:p>


In that case there could be a =
race condition, if trickled candidates are provided at the same time as an =
ongoing O/A.


Regards,


Christer


 


 


--sent from my mobile




On 19 Oct 2013 18:44, "Christer Holmberg" =
<christer.holmberg@eri=
csson.com> wrote:






Hi,

 =



I am trying to figure ou=
t how/if O/A and trickle ICE interact when it comes to providing
 candidates.


 =



But, let’s start w=
ith a more simple example:        &=
nbsp;



 =



-      =
   
I provide candidates A, B =
and C using O/A


-      =
   
Later, I provide candidate=
s D and E using trickle ICE


-      =
   
Then, I send a new O/A, wi=
th candidates A, B and C


 =



Now, are candidates D an=
d E still valid, or did my new O/A disable them?


 =



Regards,


 =



Christer


 =



L=E4hett=E4j=E4: Emil Ivov [=
mailto:emcho@jitsi.org=
]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


 


The new SDP O/A you mention would cause an ICE restart and that's what w=
ill define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" <christer.holmberg=
@ericsson.com> wrote:




Hi Emil,


=
 


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
 


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.


=
 


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?


=
 


=
Regards,


=
 


=
Christer


=
 


=
Sent from my Sony Ericsson Xperia arc S


=
 


=
Emil Ivov <emcho@ji=
tsi.org> wrote:


=
 






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" <christer.holmberg=
@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




 






I don't think this is accurate. Use of SDP for additional candidates is =
just a coincidence. It was readily available syntax for describing candidat=
es and it might be convenient in some
 implementations (although this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session SDP the way a =
new m=3D line does. There is only a loose relation between them and subsequ=
ent O/As. The origin field does NOT need
 to be updated. New candidates in new O/As may appear without having been t=
rickled and trickled candidates can just well be omitted in subsequent O/As=
. In other words, a trickled candidate would only affect the state of the I=
CE agent in exactly the same way
 a peer reflexive candidate would and it would be orthogonal to O/A, again,=
 just as peer reflexive candidates are.






 






So, while we would need to think about whether using POF/PAN would=
 make sense or not, why do you think that we "can't" do it?<=
/o:p>






 






OK, maybe "can't" is not entirely accurate here. I am sure tha=
t we *could* make it would with O/A if we really put our backs into it. In =
a similar way, I am sure we could also make it
 work by exchanging candidates in a shared Dropbox folder. In either case, =
I don't see why we would want to incur such a thing on our selves. I don't =
see any advantage to doing this.






On the downside, trickling candidates in Offer/Answer would imply the fo=
llowing problems:






*  Very high glare probability.






* Unnecessarily complex implementation (really, this would be a ni=
ghtmare and I sincerely advise anyone supporting offer answer for trickle t=
o first try and implement it).







* Ambiguity between ICE restarts and trickle updates.






Also, given how we have already had this discussion and converged =
on use of INFO, it is unclear to to me as to why we are revisiting this. I =
don't think anyone has reported any
 problems on the alternative.



Cheers,

Emil 






 








Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type implies=
 that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We

are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

>         Thanks,

>         Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>

>>

>> wrote:

>>

>>     Hi,

>>

>>      > I think you and I are thinking of this di=
fferently.

>>      >

>>      > I'm thinking that the POFs and PANs are s=
omething new, different

>>     from offers and answers. They go on *between* offers=
 and answers.

>>      >

>>      > IIUC you are thinking of POFs and PANs as=
 extended forms of

>>     offers and answers.

>>

>>     It's not the way I think - I just wanted to explore =
how/if things

>>     would work IF we were thinking like that, and what t=
he pros and cons

>>     would be :)

>>

>>     We have to keep in mind that, no matter how we look =
at it, the

>>     Offers/Answers and POFs/PANs are tightly connected, =
meaning that

>>     they impact the same SDP state, can cause race condi=
tions etc.

>>

>>     Regards,

>>

>>     Christer

>>

>>

>>

>>

>>

>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:

>>      > Hi,

>>      >

>>      >>>>> Content-Disposition does =
not apply to intermediaries. So, a

>> proxy

>>      >>>>> that only understands app=
lication/sdp (e.g. for gate control

>>      >>>>> purpose) will not even lo=
ok at the C-D header field value for

>>      >>>>> other bodies. And, unless=
 such proxy understands POF/PAN, there

>>      >>>>> may not be any media pass=
ing through...

>>      >>>>

>>      >>>> Right. A middlebox that doesn=
't understand application/sdpfrag

>>      >>>> won't know to look at its con=
tents and let the new streams

>>     through.

>>      >>>> And a middlebox that sees som=
ething marked as

>>     "application/sdp" that conveys only a tiny=
 fraction of the session

>>     will probably be just as catastrophic; I would imagi=
ne everything

>>     but the modified streams would be shut off. There's =
no way to win

>> here.

>>      >>>

>>      >>> I think it would reject the Offer=
 - at least that's what it

>>     should do according to 3264.

>>      >>

>>      >> 3264 only talks about how to process =
offers and answers described

>> in

>>      >> SDP. It does not say how those are co=
nveyed in sip. 3261 says

>>     that they are carried in body parts of content-type =
application/sdp

>>     with content-disposition of 'session'. If a body par=
t has

>>     content-type application/sdp but has a disposition o=
ther than

>>     'session' then it isn't an offer or answer according=
 to 3261, and so

>>     3264 doesn't apply.

>>      >

>>      > 3264 says that all m- line must be presen=
t in an Offer - even if

>>     they are not modified. So, what I meant was that in =
case all m-

>>     lines are NOT present (in the case of a POF), such O=
ffer would be

>>     rejected - unless the middlebox understands the POF/=
PAN mechanism .

>>      >

>>      >>>> At some point, we have to com=
e to peace with the fact that any

>>     middleboxes that aren't primarily in the business of=
 stifling

>>     progress will need to keep pace with protocol extens=
ions as they get

>>     deployed.

>>      >>>

>>      >>> I really wish things worked that =
way :)

>>      >>

>>      >> So progress ends because middleboxes =
don't permit it?

>>      >>

>>      >> Maybe you are right. Then sip will go=
 the way of h323 while the

>>     world moves on to webrtc.

>>      >

>>      > I think that getting explicit rejections,=
 rather than having to

>>     try to

>>      > figure out where things go wrong, is good=
 for progress :)

>>      >

>>      > Anyway, it wasn't really a suggestion - I=
 just wanted to do some

>>      > brainstorming :)

>>      >

>>      > Regards,

>>      >

>>      > Christer

>>      >

>>

>>     _______________________________________________

>>     mmusic mailing list

>>     mmusic@ietf.org <mailto:mmusic@ietf.org>

>>     https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D.                 &n=
bsp;     67000 Strasbourg,

Project Lead                  =
         France

Jitsi

emcho@jitsi.org &n=
bsp;                     =
 PHONE:
+33.1.77.62.43.30=


https://jitsi.org  =
;                     FAX=
:  
+33.1.77.62.47.31=


_______________________________________________

mmusic mailing list

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
























--_000_7594FB04B1934943A5C02806D1A2204B1C4D8F8AESESSMB209erics_--

From emcho@sip-communicator.org  Sat Oct 19 10:49: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 23A9F11E8242 for ; Sat, 19 Oct 2013 10:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=0.255,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yl17YyAvXSE for ; Sat, 19 Oct 2013 10:49:05 -0700 (PDT)
Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6891F11E8248 for ; Sat, 19 Oct 2013 10:49:03 -0700 (PDT)
Received: by mail-pb0-f49.google.com with SMTP id xb12so5174867pbc.36 for ; Sat, 19 Oct 2013 10:49:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9kRlyK9mfjksBd1jYTlN4hKjCxKjEUwD/1ytpglFQb0=; b=NLu1Htv1VkpwOJQNxe7NBup4ZNcNH+zW6EkTXM069RiNqy0VZyM8UAs3Z0CgPWQPN4 JetBsYh69Ur8uCQJqjcfxETBNBFA+VuTm9QgVuLZTudAT7zDl2nWWxu0Dr2LHC261QYm SYEHGr58JKqTyos0cTDtBb962NFGTinUzAHdIRJIH0PxXs5sEqWmsDqWlIVO+CdIKU/5 /31DXCLhNUbsBz+EpGPdU7M61BBokPcbB8t2hNBUZslX6z+Ss9ug5OlIy0mi82wUupHq 5JL3FRBPEuayR03usv07eeAWpuZGEIuOwXWx4NeoiGTHLK0TQwzKYfVM+e8YLEp7IATW C+Nw==
X-Gm-Message-State: ALoCoQmIU7s/ba54671gZVg3meyj+jCO/iYxRRz5HqCGSPfPzOFZtamnktQ8XVigtuYmI39lFFPP
X-Received: by 10.66.158.196 with SMTP id ww4mr9562662pab.57.1382204942864; Sat, 19 Oct 2013 10:49:02 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPSA id tz3sm10041046pbc.20.2013.10.19.10.49.01 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 10:49:01 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id kl14so6039233pab.39 for ; Sat, 19 Oct 2013 10:49:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.234.165 with SMTP id uf5mr9092295pbc.41.1382204941337; Sat, 19 Oct 2013 10:49:01 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 10:49:01 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sat, 19 Oct 2013 10:49:01 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>
Date: Sat, 19 Oct 2013 12:49:01 -0500
Message-ID: 
From: Emil Ivov 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b33cb768928d504e91baa22
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 17:49:09 -0000

--047d7b33cb768928d504e91baa22
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Could you please be more specific? I am not sure I see it.

Emil

--sent from my mobile
On 19 Oct 2013 19:01, "Christer Holmberg" 
wrote:

>  Hi,****
>
> > If D and E are not provided and checked in the new O/A then they are no
> longer valid. Think of them as peer reflexive.****
>
> In that case there could be a race condition, if trickled candidates are
> provided at the same time as an ongoing O/A.****
>
> Regards,****
>
> Christer****
>
> ** **
>
> ** **
>
> --sent from my mobile****
>
> On 19 Oct 2013 18:44, "Christer Holmberg" 
> wrote:****
>
> Hi,****
>
>  ****
>
> I am trying to figure out how/if O/A and trickle ICE interact when it
> comes to providing candidates.****
>
>  ****
>
> But, let=92s start with a more simple example:          ****
>
>  ****
>
> -          I provide candidates A, B and C using O/A****
>
> -          Later, I provide candidates D and E using trickle ICE****
>
> -          Then, I send a new O/A, with candidates A, B and C****
>
>  ****
>
> Now, are candidates D and E still valid, or did my new O/A disable them?*=
*
> **
>
>  ****
>
> Regards,****
>
>  ****
>
> Christer****
>
>  ****
>
> *L=E4hett=E4j=E4:* Emil Ivov [mailto:emcho@jitsi.org]
> *L=E4hetetty:* 19. lokakuuta 2013 18:56
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Paul Kyzivat; mmusic
> *Aihe:* Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value=
*
> ***
>
>  ****
>
> The new SDP O/A you mention would cause an ICE restart and that's what
> will define agent state. Not previously exchange trickled candidates. ***=
*
>
> I am not sure I understand the relation to your argument though (about
> trickled candidates affecting session SDP) so I might be missing your poi=
nt.
> ****
>
> Emil****
>
> --sent from my mobile****
>
> On 19 Oct 2013 17:43, "Christer Holmberg" 
> wrote:****
>
> Hi Emil,****
>
>  ****
>
> Assume you have an m- line, for which you provide candidates using trickl=
e ICE.****
>
>  ****
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means i=
t will inherit the address properties and candidates of the BUNDLE group.**=
**
>
>  ****
>
> Are you saying that the previously provided trickle candidates are still =
comsidered valid, eventhough they are associated with different address pro=
perties etc?****
>
>  ****
>
> Regards,****
>
>  ****
>
> Christer****
>
>  ****
>
> Sent from my Sony Ericsson Xperia arc S****
>
>  ****
>
> Emil Ivov  wrote:****
>
>  ****
>
>  Hey Christer,****
>
> On 19 Oct 2013 08:10, "Christer Holmberg" 
> wrote:****
>
> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session SDP
> (bacause, as you said, they are sent within SDP).****
>
>  ****
>
> I don't think this is accurate. Use of SDP for additional candidates is
> just a coincidence. It was readily available syntax for describing
> candidates and it might be convenient in some implementations (although
> this is probably of marginal value).
>
> The point is that the syntax is not due to a relationship to Offer/Answer
> and could have just as easily be based on JSON or XML or anything else. *=
*
> **
>
> Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D
> line does. There is only a loose relation between them and subsequent O/A=
s.
> The origin field does NOT need to be updated. New candidates in new O/As
> may appear without having been trickled and trickled candidates can just
> well be omitted in subsequent O/As. In other words, a trickled candidate
> would only affect the state of the ICE agent in exactly the same way a pe=
er
> reflexive candidate would and it would be orthogonal to O/A, again, just =
as
> peer reflexive candidates are.****
>
>  ****
>
> So, while we would need to think about whether using POF/PAN would make
> sense or not, why do you think that we "can't" do it?****
>
>   ****
>
> OK, maybe "can't" is not entirely accurate here. I am sure that we *could=
*
> make it would with O/A if we really put our backs into it. In a similar
> way, I am sure we could also make it work by exchanging candidates in a
> shared Dropbox folder. In either case, I don't see why we would want to
> incur such a thing on our selves. I don't see any advantage to doing this=
.
> ****
>
> On the downside, trickling candidates in Offer/Answer would imply the
> following problems:****
>
> *  Very high glare probability.****
>
> * Unnecessarily complex implementation (really, this would be a nightmare
> and I sincerely advise anyone supporting offer answer for trickle to firs=
t
> try and implement it). ****
>
> * Ambiguity between ICE restarts and trickle updates.****
>
> Also, given how we have already had this discussion and converged on use
> of INFO, it is unclear to to me as to why we are revisiting this. I don't
> think anyone has reported any problems on the alternative.
>
> Cheers,
> Emil ****
>
>  ****
>
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov  wrote:
>
>
> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat 
> wrote:
> > On 10/18/13 6:11 PM, Emil Ivov wrote:
> >>
> >> I do think that a different MIME type makes more sense here for the
> >> reasons Paul explained.
> >
> >
> > In the sip world, we may *also* want a new content-disposition. Using
> > 'session' as the content-disposition with the new content type implies
> that
> > the the body is just a different representation of an offer or answer.
> (We
> > were once considering exactly that with SDPng.)
> >
> > We *might* want to think of it that way, or not.
> >
> >
> >> It might be worth adding that the same MIME type would be used when
> >> sending candidate updates with Trickle ICE for SIP, which to me at
> >> least, makes a lot of sense.
> >
> >
> > I still wonder why trickle ICE needs a *different* mechanism for partia=
l
> > offers. Couldn't we just use this one?
>
> By "this one", do you mean POF/PAN or application/sdpfrag?
>
> We don't need anything different than application/sdpfrag.
>
> We can't use POF/PAN because we are not sending offers and answers. We
> are just exchanging candidates in agent-to-agent messages. The use of
> SDP is an unfortunate coincidence, not an indication of offers and
> answers.
>
> Emil
>
> >
> >         Thanks,
> >         Paul
> >
> >> --sent from my mobile
> >>
> >> On 18 Oct 2013 16:55, "Christer Holmberg"
> >>  >>
> >>
> >> wrote:
> >>
> >>     Hi,
> >>
> >>      > I think you and I are thinking of this differently.
> >>      >
> >>      > I'm thinking that the POFs and PANs are something new, differen=
t
> >>     from offers and answers. They go on *between* offers and answers.
> >>      >
> >>      > IIUC you are thinking of POFs and PANs as extended forms of
> >>     offers and answers.
> >>
> >>     It's not the way I think - I just wanted to explore how/if things
> >>     would work IF we were thinking like that, and what the pros and co=
ns
> >>     would be :)
> >>
> >>     We have to keep in mind that, no matter how we look at it, the
> >>     Offers/Answers and POFs/PANs are tightly connected, meaning that
> >>     they impact the same SDP state, can cause race conditions etc.
> >>
> >>     Regards,
> >>
> >>     Christer
> >>
> >>
> >>
> >>
> >>
> >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
> >>      > Hi,
> >>      >
> >>      >>>>> Content-Disposition does not apply to intermediaries. So, a
> >> proxy
> >>      >>>>> that only understands application/sdp (e.g. for gate contro=
l
> >>      >>>>> purpose) will not even look at the C-D header field value f=
or
> >>      >>>>> other bodies. And, unless such proxy understands POF/PAN,
> there
> >>      >>>>> may not be any media passing through...
> >>      >>>>
> >>      >>>> Right. A middlebox that doesn't understand application/sdpfr=
ag
> >>      >>>> won't know to look at its contents and let the new streams
> >>     through.
> >>      >>>> And a middlebox that sees something marked as
> >>     "application/sdp" that conveys only a tiny fraction of the session
> >>     will probably be just as catastrophic; I would imagine everything
> >>     but the modified streams would be shut off. There's no way to win
> >> here.
> >>      >>>
> >>      >>> I think it would reject the Offer - at least that's what it
> >>     should do according to 3264.
> >>      >>
> >>      >> 3264 only talks about how to process offers and answers
> described
> >> in
> >>      >> SDP. It does not say how those are conveyed in sip. 3261 says
> >>     that they are carried in body parts of content-type application/sd=
p
> >>     with content-disposition of 'session'. If a body part has
> >>     content-type application/sdp but has a disposition other than
> >>     'session' then it isn't an offer or answer according to 3261, and =
so
> >>     3264 doesn't apply.
> >>      >
> >>      > 3264 says that all m- line must be present in an Offer - even i=
f
> >>     they are not modified. So, what I meant was that in case all m-
> >>     lines are NOT present (in the case of a POF), such Offer would be
> >>     rejected - unless the middlebox understands the POF/PAN mechanism =
.
> >>      >
> >>      >>>> At some point, we have to come to peace with the fact that a=
ny
> >>     middleboxes that aren't primarily in the business of stifling
> >>     progress will need to keep pace with protocol extensions as they g=
et
> >>     deployed.
> >>      >>>
> >>      >>> I really wish things worked that way :)
> >>      >>
> >>      >> So progress ends because middleboxes don't permit it?
> >>      >>
> >>      >> Maybe you are right. Then sip will go the way of h323 while th=
e
> >>     world moves on to webrtc.
> >>      >
> >>      > I think that getting explicit rejections, rather than having to
> >>     try to
> >>      > figure out where things go wrong, is good for progress :)
> >>      >
> >>      > Anyway, it wasn't really a suggestion - I just wanted to do som=
e
> >>      > brainstorming :)
> >>      >
> >>      > Regards,
> >>      >
> >>      > Christer
> >>      >
> >>
> >>     _______________________________________________
> >>     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
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> https://jitsi.org                       FAX:   +33.1.77.62.47.31
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic****
>
>

--047d7b33cb768928d504e91baa22
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Could you please be more specific? I am not sure I see it.

Emil


--sent from my mobile


On 19 Oct 2013 19:01, "Christer Holmberg&qu=
ot; <christer.holmberg=
@ericsson.com> wrote:












Hi,=



> If D and E are not provided and checked in the new O/A then they are =
no longer valid.
Think of them as peer reflexive.


In that case there could be a =
race condition, if trickled candidates are provided at the same time as an =
ongoing O/A.



Regards,<=
/p>

Christer<=
/p>

=A0


=A0


--sent from my mobile




On 19 Oct 2013 18:44, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:






Hi,=



=A0=



I am tryin=
g to figure out how/if O/A and trickle ICE interact when it comes to provid=
ing
 candidates.


=A0=



But, let=
=92s start with a more simple example:=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=



-=A0=A0=A0=A0=A0=A0=A0=A0=A0
I provide candidates A, B =
and C using O/A


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Later, I provide candidate=
s D and E using trickle ICE


-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Then, I send a new O/A, wi=
th candidates A, B and C


=A0=



Now, are c=
andidates D and E still valid, or did my new O/A disable them?



=A0=



Regards,


=A0=



Christer


=A0=



L=E4hett=E4j=E4: Emil Ivov [mailto:e=
mcho@jitsi.org]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


=A0


The new SDP O/A you mention would cause an ICE restart and that's wh=
at will define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi Emil,


=
=A0


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
=A0


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.



=
=A0


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?



=
=A0


=
Regards,


=
=A0


=
Christer


=
=A0


=
Sent from my Sony Ericsson Xperia arc S


=
=A0


=
Emil Ivov <emcho@ji=
tsi.org> wrote:


=
=A0






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




=A0






I don't think thi=
s is accurate. Use of SDP for additional candidates is just a coincidence. =
It was readily available syntax for describing candidates and it might be c=
onvenient in some
 implementations (although this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session =
SDP the way a new m=3D line does. There is only a loose relation between th=
em and subsequent O/As. The origin field does NOT need
 to be updated. New candidates in new O/As may appear without having been t=
rickled and trickled candidates can just well be omitted in subsequent O/As=
. In other words, a trickled candidate would only affect the state of the I=
CE agent in exactly the same way
 a peer reflexive candidate would and it would be orthogonal to O/A, again,=
 just as peer reflexive candidates are.






=A0






So, while we would need to think about whether using=
 POF/PAN would make sense or not, why do you think that we "can't&=
quot; do it?






=A0






OK, maybe "can&#=
39;t" is not entirely accurate here. I am sure that we *could* make it=
 would with O/A if we really put our backs into it. In a similar way, I am =
sure we could also make it
 work by exchanging candidates in a shared Dropbox folder. In either case, =
I don't see why we would want to incur such a thing on our selves. I do=
n't see any advantage to doing this.






On the downside, tric=
kling candidates in Offer/Answer would imply the following problems:=







*=A0 Very high glare probability.






* Unnecessarily complex implementation (really, this=
 would be a nightmare and I sincerely advise anyone supporting offer answer=
 for trickle to first try and implement it).







* Ambiguity between I=
CE restarts and trickle updates.






Also, given how we have already had this discussion =
and converged on use of INFO, it is unclear to to me as to why we are revis=
iting this. I don't think anyone has reported any
 problems on the alternative.



Cheers,

Emil 






=A0








Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type=
 implies that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We<=
br>
are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

> =A0 =A0 =A0 =A0 Thanks,

> =A0 =A0 =A0 =A0 Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>


>>

>> wrote:

>>

>> =A0 =A0 Hi,

>>

>> =A0 =A0 =A0> I think you and I are thinking of this differently=
.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I'm thinking that the POFs and PANs are someth=
ing new, different

>> =A0 =A0 from offers and answers. They go on *between* offers and a=
nswers.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> IIUC you are thinking of POFs and PANs as extended=
 forms of

>> =A0 =A0 offers and answers.

>>

>> =A0 =A0 It's not the way I think - I just wanted to explore ho=
w/if things

>> =A0 =A0 would work IF we were thinking like that, and what the pro=
s and cons

>> =A0 =A0 would be :)

>>

>> =A0 =A0 We have to keep in mind that, no matter how we look at it,=
 the

>> =A0 =A0 Offers/Answers and POFs/PANs are tightly connected, meanin=
g that

>> =A0 =A0 they impact the same SDP state, can cause race conditions =
etc.

>>

>> =A0 =A0 Regards,

>>

>> =A0 =A0 Christer

>>

>>

>>

>>

>>

>> =A0 =A0 On 10/18/13 5:06 PM, Christer Holmberg wrote:

>> =A0 =A0 =A0> Hi,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>>> Content-Disposition does not apply=
 to intermediaries. So, a

>> proxy

>> =A0 =A0 =A0>>>>> that only understands application/=
sdp (e.g. for gate control

>> =A0 =A0 =A0>>>>> purpose) will not even look at the=
 C-D header field value for

>> =A0 =A0 =A0>>>>> other bodies. And, unless such pro=
xy understands POF/PAN, there

>> =A0 =A0 =A0>>>>> may not be any media passing throu=
gh...

>> =A0 =A0 =A0>>>>

>> =A0 =A0 =A0>>>> Right. A middlebox that doesn't un=
derstand application/sdpfrag

>> =A0 =A0 =A0>>>> won't know to look at its contents=
 and let the new streams

>> =A0 =A0 through.

>> =A0 =A0 =A0>>>> And a middlebox that sees something ma=
rked as

>> =A0 =A0 "application/sdp" that conveys only a tiny fract=
ion of the session

>> =A0 =A0 will probably be just as catastrophic; I would imagine eve=
rything

>> =A0 =A0 but the modified streams would be shut off. There's no=
 way to win

>> here.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I think it would reject the Offer - at lea=
st that's what it

>> =A0 =A0 should do according to 3264.

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> 3264 only talks about how to process offers an=
d answers described

>> in

>> =A0 =A0 =A0>> SDP. It does not say how those are conveyed in=
 sip. 3261 says

>> =A0 =A0 that they are carried in body parts of content-type applic=
ation/sdp

>> =A0 =A0 with content-disposition of 'session'. If a body p=
art has

>> =A0 =A0 content-type application/sdp but has a disposition other t=
han

>> =A0 =A0 'session' then it isn't an offer or answer acc=
ording to 3261, and so

>> =A0 =A0 3264 doesn't apply.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> 3264 says that all m- line must be present in an O=
ffer - even if

>> =A0 =A0 they are not modified. So, what I meant was that in case a=
ll m-

>> =A0 =A0 lines are NOT present (in the case of a POF), such Offer w=
ould be

>> =A0 =A0 rejected - unless the middlebox understands the POF/PAN me=
chanism .

>> =A0 =A0 =A0>

>> =A0 =A0 =A0>>>> At some point, we have to come to peac=
e with the fact that any

>> =A0 =A0 middleboxes that aren't primarily in the business of s=
tifling

>> =A0 =A0 progress will need to keep pace with protocol extensions a=
s they get

>> =A0 =A0 deployed.

>> =A0 =A0 =A0>>>

>> =A0 =A0 =A0>>> I really wish things worked that way :)
>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> So progress ends because middleboxes don't=
 permit it?

>> =A0 =A0 =A0>>

>> =A0 =A0 =A0>> Maybe you are right. Then sip will go the way =
of h323 while the

>> =A0 =A0 world moves on to webrtc.

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> I think that getting explicit rejections, rather t=
han having to

>> =A0 =A0 try to

>> =A0 =A0 =A0> figure out where things go wrong, is good for prog=
ress :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Anyway, it wasn't really a suggestion - I just=
 wanted to do some

>> =A0 =A0 =A0> brainstorming :)

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Regards,

>> =A0 =A0 =A0>

>> =A0 =A0 =A0> Christer

>> =A0 =A0 =A0>

>>

>> =A0 =A0 _______________________________________________

>> =A0 =A0 mmusic mailing list

>> =A0 =A0 mmusi=
c@ietf.org <mailto:mmusic@ietf.org>

>> =A0 =A0 https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 67000 Strasbou=
rg,

Project Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 France

Jitsi

emcho@jitsi.org =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PHONE:
+33.1.77.62.43.30=


https://jitsi.org =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FAX: =A0
+33.1.77.62.47.31=


_______________________________________________

mmusic mailing list

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



























--047d7b33cb768928d504e91baa22--

From christer.holmberg@ericsson.com  Sat Oct 19 14:27: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 E606511E82A6 for ; Sat, 19 Oct 2013 14:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.530,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hihx9U5VZMzZ for ; Sat, 19 Oct 2013 14:27:47 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0300911E829E for ; Sat, 19 Oct 2013 14:27:44 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-0b-5262f94fa414
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 99.E6.03802.F49F2625; Sat, 19 Oct 2013 23:27:43 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 23:27:43 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eYAARXaAgABat3z//+HsAIAALhiw///iMgCAACMJcP//7C2AAASGVbA=
Date: Sat, 19 Oct 2013 21:27:41 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4DA0FAESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja7/z6Qgg4enFC3W7JzAYjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlrJ6pUrDtE1PFlY/XmRoY t+5j6mLk4JAQMJFY/Mipi5ETyBSTuHBvPVsXIxeHkMBhRomedzNZQRJCAksYJW5f9wapZxOw kOj+pw0SFhGQl+huW8QEYjMLOElc63rJDGILC4RI3PpynhmiJlSi7cBEJgi7TOLDq8lsIDaL gKrEq79r2UFsXgFfiWNLV7JD7N3EKXFr122wBKdAoMTvX9vBbEag476fWgO1TFziw8HrzBBH C0gs2XMeyhaVePn4HyuErSSx6PZnsB+ZBfIlFh3ghNglKHFy5hOWCYyis5BMmoVQNQtJFUSJ nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvoqRPTcxMye93GgTIzDCDm75rbqD8c45kUOM 0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgZJaaWtx+6mLCDbEEo7dhAiKr F53mzFbYMsWiaV+69KaFwi326dUGEVcmvnujtp9/BVPuzoKYxfvF5m/WvRi6+B3rxgyuf+s0 vpgfcrQwFDf+Nnef+Jk9m3xmH+eU971yiXWOvQKTe9Pmw6JdNwJaLZb6RqXHv38st93k4Ktv W8otC4SFMgWnKbEUZyQaajEXFScCAOywNId+AgAA
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 19 Oct 2013 21:27:53 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4DA0FAESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Example:


1.       Alice sends an SDP Offer to Bob.


2.       Bob sends the SDP Answer to Alice, with candidates A, B and C.



3.       After that, Bob sends, using trickle ICE, candidates D and E to Al=
ice.

If Alice receives the SDP Answer first, and then the trickle ICE request, s=
he will assume that Bob first provided candidates A, B and C (in the SDP An=
swer), and then added D and E (in the trickle ICE request).

If Alice receives the trickle ICE request first, and then the SDP Answer, s=
he will assume that Bob first provided candidates D and E (in the trickle I=
CE request), but then replaced them with candidates A, B and C (as the SDP =
Answer did not contain candidates D and E).

Regards,

Christer

L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
L=E4hetetty: 19. lokakuuta 2013 20:49
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type v=
alue


Could you please be more specific? I am not sure I see it.

Emil

--sent from my mobile
On 19 Oct 2013 19:01, "Christer Holmberg" > wrote:
Hi,

> If D and E are not provided and checked in the new O/A then they are no l=
onger valid. Think of them as peer reflexive.

In that case there could be a race condition, if trickled candidates are pr=
ovided at the same time as an ongoing O/A.

Regards,

Christer





--sent from my mobile
On 19 Oct 2013 18:44, "Christer Holmberg" > wrote:
Hi,

I am trying to figure out how/if O/A and trickle ICE interact when it comes=
 to providing candidates.

But, let's start with a more simple example:


-          I provide candidates A, B and C using O/A

-          Later, I provide candidates D and E using trickle ICE

-          Then, I send a new O/A, with candidates A, B and C

Now, are candidates D and E still valid, or did my new O/A disable them?

Regards,

Christer

L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
L=E4hetetty: 19. lokakuuta 2013 18:56
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


The new SDP O/A you mention would cause an ICE restart and that's what will=
 define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about tric=
kled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" > wrote:

Hi Emil,



Assume you have an m- line, for which you provide candidates using trickle =
ICE.



Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.



Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov > wrote:



Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" > wrote:
Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).

I don't think this is accurate. Use of SDP for additional candidates is jus=
t a coincidence. It was readily available syntax for describing candidates =
and it might be convenient in some implementations (although this is probab=
ly of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.
Also, trickled candidates DO NOT update the session SDP the way a new m=3D =
line does. There is only a loose relation between them and subsequent O/As.=
 The origin field does NOT need to be updated. New candidates in new O/As m=
ay appear without having been trickled and trickled candidates can just wel=
l be omitted in subsequent O/As. In other words, a trickled candidate would=
 only affect the state of the ICE agent in exactly the same way a peer refl=
exive candidate would and it would be orthogonal to O/A, again, just as pee=
r reflexive candidates are.

So, while we would need to think about whether using POF/PAN would make sen=
se or not, why do you think that we "can't" do it?

OK, maybe "can't" is not entirely accurate here. I am sure that we *could* =
make it would with O/A if we really put our backs into it. In a similar way=
, I am sure we could also make it work by exchanging candidates in a shared=
 Dropbox folder. In either case, I don't see why we would want to incur suc=
h a thing on our selves. I don't see any advantage to doing this.
On the downside, trickling candidates in Offer/Answer would imply the follo=
wing problems:
*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare a=
nd I sincerely advise anyone supporting offer answer for trickle to first t=
ry and implement it).
* Ambiguity between ICE restarts and trickle updates.
Also, given how we have already had this discussion and converged on use of=
 INFO, it is unclear to to me as to why we are revisiting this. I don't thi=
nk anyone has reported any problems on the alternative.

Cheers,
Emil


Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov > wrote:


On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat > wrote:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies th=
at
> the the body is just a different representation of an offer or answer. (W=
e
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>>  <=
mailto:christer.holmberg@ericsson.com>>
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, the=
re
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers describe=
d
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     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



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1=
.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_7594FB04B1934943A5C02806D1A2204B1C4DA0FAESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Example:


 =
;


1.      
Al=
ice sends an SDP Offer to Bob.


 =
;


2.      
Bo=
b sends the SDP Answer to Alice, with candidates A, B and C.


 


3.      
Af=
ter that, Bob sends, using trickle ICE, candidates D and E to Alice.


 =
;


If Alice r=
eceives the SDP Answer first, and then the trickle ICE request, she will as=
sume that Bob first provided candidates A, B and C (in the
 SDP Answer), and then added D and E (in the trickle ICE request).


 =
;


If Alice r=
eceives the trickle ICE request first, and then the SDP Answer, she will as=
sume that Bob first provided candidates D and E (in the trickle
 ICE request), but then replaced them with candidates A, B and C (as the SD=
P Answer did not contain candidates D and E).


 =
;


Regards,


 =
;


Christer


 =
;


L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]


L=E4hetetty: 19. lokakuuta 2013 20:49

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME=
 type value


 


Could you please be more specific? I am not sure I see it.

Emil


--sent from my mobile




On 19 Oct 2013 19:01, "Christer Holmberg" =
<christer.holmberg@eri=
csson.com> wrote:






Hi,

> If D and E are not provided and checked in the new O/A then they are =
no longer valid.
Think of them as peer reflexive.


In that case there could be a =
race condition, if trickled candidates are provided at the same time as an =
ongoing O/A.


Regards,


Christer


 


 


--sent from my mobile




On 19 Oct 2013 18:44, "Christer Holmberg" <christer.holmberg=
@ericsson.com> wrote:






Hi,

 =



I am trying to figure ou=
t how/if O/A and trickle ICE interact when it comes to providing
 candidates.


 =



But, let’s start w=
ith a more simple example:        &=
nbsp;



 =



-      =
   
I provide candidates A, B =
and C using O/A


-      =
   
Later, I provide candidate=
s D and E using trickle ICE


-      =
   
Then, I send a new O/A, wi=
th candidates A, B and C


 =



Now, are candidates D an=
d E still valid, or did my new O/A disable them?


 =



Regards,


 =



Christer


 =



L=E4hett=E4j=E4: Emil Ivov [=
mailto:emcho@jitsi.org=
]


L=E4hetetty: 19. lokakuuta 2013 18:56

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic

Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type va=
lue


 


The new SDP O/A you mention would cause an ICE restart and that's what w=
ill define agent state. Not previously exchange trickled candidates.



I am not sure I understand the relation to your argument though (about t=
rickled candidates affecting session SDP) so I might be missing your point.=



Emil


--sent from my mobile




On 19 Oct 2013 17:43, "Christer Holmberg" <christer.holmberg=
@ericsson.com> wrote:




Hi Emil,


=
 


=
Assume you have an m- line, for which you provide candidates using trickle =
ICE.


=
 


=
Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it =
will inherit the address properties and candidates of the BUNDLE group.


=
 


=
Are you saying that the previously provided trickle candidates are still co=
msidered valid, eventhough they are associated with different address prope=
rties etc?


=
 


=
Regards,


=
 


=
Christer


=
 


=
Sent from my Sony Ericsson Xperia arc S


=
 


=
Emil Ivov <emcho@ji=
tsi.org> wrote:


=
 






Hey Christer,




On 19 Oct 2013 08:10, "Christer Holmberg" <christer.holmberg=
@ericsson.com> wrote:


Hi Emil,



Similar to POF/PAN, the sending of candidates do affect the session SDP (ba=
cause, as you said, they are sent within SDP).




 






I don't think this is accurate. Use of SDP for additional candidates is =
just a coincidence. It was readily available syntax for describing candidat=
es and it might be convenient in some
 implementations (although this is probably of marginal value).



The point is that the syntax is not due to a relationship to Offer/Answer a=
nd could have just as easily be based on JSON or XML or anything else.







Also, trickled candidates DO NOT update the session SDP the way a =
new m=3D line does. There is only a loose relation between them and subsequ=
ent O/As. The origin field does NOT need
 to be updated. New candidates in new O/As may appear without having been t=
rickled and trickled candidates can just well be omitted in subsequent O/As=
. In other words, a trickled candidate would only affect the state of the I=
CE agent in exactly the same way
 a peer reflexive candidate would and it would be orthogonal to O/A, again,=
 just as peer reflexive candidates are.






 






So, while we would need to think about whether using POF/PAN would=
 make sense or not, why do you think that we "can't" do it?<=
/o:p>






 






OK, maybe "can't" is not entirely accurate here. I am sure tha=
t we *could* make it would with O/A if we really put our backs into it. In =
a similar way, I am sure we could also make it
 work by exchanging candidates in a shared Dropbox folder. In either case, =
I don't see why we would want to incur such a thing on our selves. I don't =
see any advantage to doing this.






On the downside, trickling candidates in Offer/Answer would imply the fo=
llowing problems:






*  Very high glare probability.






* Unnecessarily complex implementation (really, this would be a ni=
ghtmare and I sincerely advise anyone supporting offer answer for trickle t=
o first try and implement it).







* Ambiguity between ICE restarts and trickle updates.






Also, given how we have already had this discussion and converged =
on use of INFO, it is unclear to to me as to why we are revisiting this. I =
don't think anyone has reported any
 problems on the alternative.



Cheers,

Emil 






 








Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <emcho@ji=
tsi.org> wrote:





On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 10/18/13 6:11 PM, Emil Ivov wrote:

>>

>> I do think that a different MIME type makes more sense here for th=
e

>> reasons Paul explained.

>

>

> In the sip world, we may *also* want a new content-disposition. Using<=
br>
> 'session' as the content-disposition with the new content type implies=
 that

> the the body is just a different representation of an offer or answer.=
 (We

> were once considering exactly that with SDPng.)

>

> We *might* want to think of it that way, or not.

>

>

>> It might be worth adding that the same MIME type would be used whe=
n

>> sending candidate updates with Trickle ICE for SIP, which to me at=


>> least, makes a lot of sense.

>

>

> I still wonder why trickle ICE needs a *different* mechanism for parti=
al

> offers. Couldn't we just use this one?



By "this one", do you mean POF/PAN or application/sdpfrag?



We don't need anything different than application/sdpfrag.



We can't use POF/PAN because we are not sending offers and answers. We

are just exchanging candidates in agent-to-agent messages. The use of

SDP is an unfortunate coincidence, not an indication of offers and

answers.



Emil



>

>         Thanks,

>         Paul

>

>> --sent from my mobile

>>

>> On 18 Oct 2013 16:55, "Christer Holmberg"

>> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com=
>>

>>

>> wrote:

>>

>>     Hi,

>>

>>      > I think you and I are thinking of this di=
fferently.

>>      >

>>      > I'm thinking that the POFs and PANs are s=
omething new, different

>>     from offers and answers. They go on *between* offers=
 and answers.

>>      >

>>      > IIUC you are thinking of POFs and PANs as=
 extended forms of

>>     offers and answers.

>>

>>     It's not the way I think - I just wanted to explore =
how/if things

>>     would work IF we were thinking like that, and what t=
he pros and cons

>>     would be :)

>>

>>     We have to keep in mind that, no matter how we look =
at it, the

>>     Offers/Answers and POFs/PANs are tightly connected, =
meaning that

>>     they impact the same SDP state, can cause race condi=
tions etc.

>>

>>     Regards,

>>

>>     Christer

>>

>>

>>

>>

>>

>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:

>>      > Hi,

>>      >

>>      >>>>> Content-Disposition does =
not apply to intermediaries. So, a

>> proxy

>>      >>>>> that only understands app=
lication/sdp (e.g. for gate control

>>      >>>>> purpose) will not even lo=
ok at the C-D header field value for

>>      >>>>> other bodies. And, unless=
 such proxy understands POF/PAN, there

>>      >>>>> may not be any media pass=
ing through...

>>      >>>>

>>      >>>> Right. A middlebox that doesn=
't understand application/sdpfrag

>>      >>>> won't know to look at its con=
tents and let the new streams

>>     through.

>>      >>>> And a middlebox that sees som=
ething marked as

>>     "application/sdp" that conveys only a tiny=
 fraction of the session

>>     will probably be just as catastrophic; I would imagi=
ne everything

>>     but the modified streams would be shut off. There's =
no way to win

>> here.

>>      >>>

>>      >>> I think it would reject the Offer=
 - at least that's what it

>>     should do according to 3264.

>>      >>

>>      >> 3264 only talks about how to process =
offers and answers described

>> in

>>      >> SDP. It does not say how those are co=
nveyed in sip. 3261 says

>>     that they are carried in body parts of content-type =
application/sdp

>>     with content-disposition of 'session'. If a body par=
t has

>>     content-type application/sdp but has a disposition o=
ther than

>>     'session' then it isn't an offer or answer according=
 to 3261, and so

>>     3264 doesn't apply.

>>      >

>>      > 3264 says that all m- line must be presen=
t in an Offer - even if

>>     they are not modified. So, what I meant was that in =
case all m-

>>     lines are NOT present (in the case of a POF), such O=
ffer would be

>>     rejected - unless the middlebox understands the POF/=
PAN mechanism .

>>      >

>>      >>>> At some point, we have to com=
e to peace with the fact that any

>>     middleboxes that aren't primarily in the business of=
 stifling

>>     progress will need to keep pace with protocol extens=
ions as they get

>>     deployed.

>>      >>>

>>      >>> I really wish things worked that =
way :)

>>      >>

>>      >> So progress ends because middleboxes =
don't permit it?

>>      >>

>>      >> Maybe you are right. Then sip will go=
 the way of h323 while the

>>     world moves on to webrtc.

>>      >

>>      > I think that getting explicit rejections,=
 rather than having to

>>     try to

>>      > figure out where things go wrong, is good=
 for progress :)

>>      >

>>      > Anyway, it wasn't really a suggestion - I=
 just wanted to do some

>>      > brainstorming :)

>>      >

>>      > Regards,

>>      >

>>      > Christer

>>      >

>>

>>     _______________________________________________

>>     mmusic mailing list

>>     mmusic@ietf.org <mailto:mmusic@ietf.org>

>>     https://www.ietf.org/mailman/listinfo/mmusic

>>

>>

>>

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/mmusic

>>

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic







--

Emil Ivov, Ph.D.                 &n=
bsp;     67000 Strasbourg,

Project Lead                  =
         France

Jitsi

emcho@jitsi.org &n=
bsp;                     =
 PHONE:
+33.1.77.62.43.30=


https://jitsi.org  =
;                     FAX=
:  
+33.1.77.62.47.31=


_______________________________________________

mmusic mailing list

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






























--_000_7594FB04B1934943A5C02806D1A2204B1C4DA0FAESESSMB209erics_--

From pkyzivat@alum.mit.edu  Sat Oct 19 19:55:15 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 7B40911E8128 for ; Sat, 19 Oct 2013 19:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.293
X-Spam-Level: 
X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqU-vTi0-nsi for ; Sat, 19 Oct 2013 19:55:07 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 960BD11E811B for ; Sat, 19 Oct 2013 19:55:06 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id fEqN1m0011swQuc5AEv5HJ; Sun, 20 Oct 2013 02:55:05 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id fEv51m00c3ZTu2S3bEv5ih; Sun, 20 Oct 2013 02:55:05 +0000
Message-ID: <52634609.2000501@alum.mit.edu>
Date: Sat, 19 Oct 2013 22:55:05 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@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=1382237705; bh=EYqHJ6KYbMy/IghAkrOIAIUHobBChnFoWFYJHyz6Jx4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F/Xr642X+d4jTw9k6WdbA8c14K2oB3zXrcMS9yY1r07yNZpMNGz0EmPEVUr5Q+8I4 EMYjp9ZsHLFKUepRyImqpZ7yEqdIpa2444Qkw8GDIObt4FpXnmXe28etuVApQ05wGr evZK2IcwE1rXaEpg66WeeZ4defVFUTfpqcniv2yAC+dJJVBVKhqF7Zc4Tc7w3mrXAn LnO4GIJeNIjNy0Qyalgkn8B2oJk8HdzLrao7IuDk/vEdgYHD76wxxgR/Etg15/Qty9 6ho1p/EbQpkXHctXS99dHxz+3sDMEZbJGzlKZmgyxAcFlFZRnlysp/3Dj6NfLIZY1o ysd7poe6REFqw==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 02:55:15 -0000

On 10/19/13 11:56 AM, Emil Ivov wrote:
> The new SDP O/A you mention would cause an ICE restart and that's what
> will define agent state. Not previously exchange trickled candidates.

Are you saying that every O/A causes an ICE restart for every m-line 
that is using ICE? That would be very unfortunate.

	Thanks,
	Paul

> I am not sure I understand the relation to your argument though (about
> trickled candidates affecting session SDP) so I might be missing your point.
>
> Emil
>
> --sent from my mobile
>
> On 19 Oct 2013 17:43, "Christer Holmberg"
> >
> wrote:
>
>     Hi Emil,
>
>     Assume you have an m- line, for which you provide candidates using trickle ICE.
>
>     Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it will inherit the address properties and candidates of the BUNDLE group.
>
>     Are you saying that the previously provided trickle candidates are still comsidered valid, eventhough they are associated with different address properties etc?
>
>     Regards,
>
>     Christer
>
>     Sent from my Sony Ericsson Xperia arc S
>
>     Emil Ivov > wrote:
>
>     Hey Christer,
>
>     On 19 Oct 2013 08:10, "Christer Holmberg"
>          > wrote:
>
>         Hi Emil,
>
>         Similar to POF/PAN, the sending of candidates do affect the
>         session SDP (bacause, as you said, they are sent within SDP).
>
>
>     I don't think this is accurate. Use of SDP for additional candidates
>     is just a coincidence. It was readily available syntax for
>     describing candidates and it might be convenient in some
>     implementations (although this is probably of marginal value).
>
>     The point is that the syntax is not due to a relationship to
>     Offer/Answer and could have just as easily be based on JSON or XML
>     or anything else.
>
>     Also, trickled candidates DO NOT update the session SDP the way a
>     new m= line does. There is only a loose relation between them and
>     subsequent O/As. The origin field does NOT need to be updated. New
>     candidates in new O/As may appear without having been trickled and
>     trickled candidates can just well be omitted in subsequent O/As. In
>     other words, a trickled candidate would only affect the state of the
>     ICE agent in exactly the same way a peer reflexive candidate would
>     and it would be orthogonal to O/A, again, just as peer reflexive
>     candidates are.
>
>         So, while we would need to think about whether using POF/PAN
>         would make sense or not, why do you think that we "can't" do it?
>
>
>     OK, maybe "can't" is not entirely accurate here. I am sure that we
>     *could* make it would with O/A if we really put our backs into it.
>     In a similar way, I am sure we could also make it work by exchanging
>     candidates in a shared Dropbox folder. In either case, I don't see
>     why we would want to incur such a thing on our selves. I don't see
>     any advantage to doing this.
>
>     On the downside, trickling candidates in Offer/Answer would imply
>     the following problems:
>
>     *  Very high glare probability.
>     * Unnecessarily complex implementation (really, this would be a
>     nightmare and I sincerely advise anyone supporting offer answer for
>     trickle to first try and implement it).
>     * Ambiguity between ICE restarts and trickle updates.
>
>     Also, given how we have already had this discussion and converged on
>     use of INFO, it is unclear to to me as to why we are revisiting
>     this. I don't think anyone has reported any problems on the alternative.
>
>     Cheers,
>     Emil
>
>
>         Regards,
>
>         Christer
>
>         Sent from my Sony Ericsson Xperia arc S
>
>         Emil Ivov > wrote:
>
>
>         On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat
>         > wrote:
>          > On 10/18/13 6:11 PM, Emil Ivov wrote:
>          >>
>          >> I do think that a different MIME type makes more sense here
>         for the
>          >> reasons Paul explained.
>          >
>          >
>          > In the sip world, we may *also* want a new
>         content-disposition. Using
>          > 'session' as the content-disposition with the new content
>         type implies that
>          > the the body is just a different representation of an offer
>         or answer. (We
>          > were once considering exactly that with SDPng.)
>          >
>          > We *might* want to think of it that way, or not.
>          >
>          >
>          >> It might be worth adding that the same MIME type would be
>         used when
>          >> sending candidate updates with Trickle ICE for SIP, which to
>         me at
>          >> least, makes a lot of sense.
>          >
>          >
>          > I still wonder why trickle ICE needs a *different* mechanism
>         for partial
>          > offers. Couldn't we just use this one?
>
>         By "this one", do you mean POF/PAN or application/sdpfrag?
>
>         We don't need anything different than application/sdpfrag.
>
>         We can't use POF/PAN because we are not sending offers and
>         answers. We
>         are just exchanging candidates in agent-to-agent messages. The
>         use of
>         SDP is an unfortunate coincidence, not an indication of offers and
>         answers.
>
>         Emil
>
>          >
>          >         Thanks,
>          >         Paul
>          >
>          >> --sent from my mobile
>          >>
>          >> On 18 Oct 2013 16:55, "Christer Holmberg"
>          >>          
>                  >>
>          >>
>          >> wrote:
>          >>
>          >>     Hi,
>          >>
>          >>      > I think you and I are thinking of this differently.
>          >>      >
>          >>      > I'm thinking that the POFs and PANs are something
>         new, different
>          >>     from offers and answers. They go on *between* offers and
>         answers.
>          >>      >
>          >>      > IIUC you are thinking of POFs and PANs as extended
>         forms of
>          >>     offers and answers.
>          >>
>          >>     It's not the way I think - I just wanted to explore
>         how/if things
>          >>     would work IF we were thinking like that, and what the
>         pros and cons
>          >>     would be :)
>          >>
>          >>     We have to keep in mind that, no matter how we look at
>         it, the
>          >>     Offers/Answers and POFs/PANs are tightly connected,
>         meaning that
>          >>     they impact the same SDP state, can cause race
>         conditions etc.
>          >>
>          >>     Regards,
>          >>
>          >>     Christer
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>          >>      > Hi,
>          >>      >
>          >>      >>>>> Content-Disposition does not apply to
>         intermediaries. So, a
>          >> proxy
>          >>      >>>>> that only understands application/sdp (e.g. for
>         gate control
>          >>      >>>>> purpose) will not even look at the C-D header
>         field value for
>          >>      >>>>> other bodies. And, unless such proxy understands
>         POF/PAN, there
>          >>      >>>>> may not be any media passing through...
>          >>      >>>>
>          >>      >>>> Right. A middlebox that doesn't understand
>         application/sdpfrag
>          >>      >>>> won't know to look at its contents and let the new
>         streams
>          >>     through.
>          >>      >>>> And a middlebox that sees something marked as
>          >>     "application/sdp" that conveys only a tiny fraction of
>         the session
>          >>     will probably be just as catastrophic; I would imagine
>         everything
>          >>     but the modified streams would be shut off. There's no
>         way to win
>          >> here.
>          >>      >>>
>          >>      >>> I think it would reject the Offer - at least that's
>         what it
>          >>     should do according to 3264.
>          >>      >>
>          >>      >> 3264 only talks about how to process offers and
>         answers described
>          >> in
>          >>      >> SDP. It does not say how those are conveyed in sip.
>         3261 says
>          >>     that they are carried in body parts of content-type
>         application/sdp
>          >>     with content-disposition of 'session'. If a body part has
>          >>     content-type application/sdp but has a disposition other
>         than
>          >>     'session' then it isn't an offer or answer according to
>         3261, and so
>          >>     3264 doesn't apply.
>          >>      >
>          >>      > 3264 says that all m- line must be present in an
>         Offer - even if
>          >>     they are not modified. So, what I meant was that in case
>         all m-
>          >>     lines are NOT present (in the case of a POF), such Offer
>         would be
>          >>     rejected - unless the middlebox understands the POF/PAN
>         mechanism .
>          >>      >
>          >>      >>>> At some point, we have to come to peace with the
>         fact that any
>          >>     middleboxes that aren't primarily in the business of
>         stifling
>          >>     progress will need to keep pace with protocol extensions
>         as they get
>          >>     deployed.
>          >>      >>>
>          >>      >>> I really wish things worked that way :)
>          >>      >>
>          >>      >> So progress ends because middleboxes don't permit it?
>          >>      >>
>          >>      >> Maybe you are right. Then sip will go the way of
>         h323 while the
>          >>     world moves on to webrtc.
>          >>      >
>          >>      > I think that getting explicit rejections, rather than
>         having to
>          >>     try to
>          >>      > figure out where things go wrong, is good for progress :)
>          >>      >
>          >>      > Anyway, it wasn't really a suggestion - I just wanted
>         to do some
>          >>      > brainstorming :)
>          >>      >
>          >>      > Regards,
>          >>      >
>          >>      > Christer
>          >>      >
>          >>
>          >>     _______________________________________________
>          >>     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
>
>
>
>         --
>         Emil Ivov, Ph.D.                       67000 Strasbourg,
>         Project Lead                           France
>         Jitsi
>         emcho@jitsi.org 
>           PHONE: +33.1.77.62.43.30 
>         https://jitsi.org                       FAX: +33.1.77.62.47.31
>         
>         _______________________________________________
>         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 emcho@sip-communicator.org  Sun Oct 20 04:12: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 32C8E11E83A8 for ; Sun, 20 Oct 2013 04:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.241
X-Spam-Level: 
X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mCobVMu4h6l for ; Sun, 20 Oct 2013 04:11:59 -0700 (PDT)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id AE4ED11E8170 for ; Sun, 20 Oct 2013 04:11:57 -0700 (PDT)
Received: by mail-pd0-f170.google.com with SMTP id v10so1096148pde.29 for ; Sun, 20 Oct 2013 04:11:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=pZiTaSZSRZtotGPCbrX+8gi7Cyp+tgeSSXMnNDNqybc=; b=iVGD/rtb41zG+IsueRnsXHTcWnMXaSNyjIUgO/zFsAULZIS1xmpYbp6kTX/fLDLkxA 8cu9UR6SMcRblaKWOgAPQ6/jbQ72wA9ENulOad40M/+/mNBZlS6uthQnYnyQF3zImhdj QCac6yK1LKuOL4EwiTGNFfQzS7yKXchPQuknxPx4cNZmh42FgFpiLfV7hAjCc0r0Jbu9 HCXaijhzTRU8KHmXZ28gszA8ettY1ilDpybH169mhlhxz+oio3/NCEgKKbjy8fAgW+cT fQTNkmXs8NNLCSEEHSABWSLv23TtPy03tn5IiRvEqnhvnYhTS76/2K6ndQItdAoNd8pj Wspw==
X-Gm-Message-State: ALoCoQmHcibzNVMOY3AvgWNqcP7L/QfsjX+vlG2CLKEIXxZ7F/I9VFBQfzOXSVWvv6gPHk8xto1z
X-Received: by 10.66.66.202 with SMTP id h10mr12977275pat.70.1382267517244; Sun, 20 Oct 2013 04:11:57 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [2607:f8b0:400e:c02::22c]) by mx.google.com with ESMTPSA id ye1sm17748982pab.19.2013.10.20.04.11.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 04:11:56 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id z10so6995931pdj.31 for ; Sun, 20 Oct 2013 04:11:56 -0700 (PDT)
X-Received: by 10.66.162.73 with SMTP id xy9mr26024pab.172.1382267516764; Sun, 20 Oct 2013 04:11:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 04:11:34 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se>
From: Emil Ivov 
Date: Sun, 20 Oct 2013 13:11:34 +0200
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 11:12:03 -0000

Hey Christer,

Before Berlin we agreed (and it is my fault for not putting that in
text yet) that the answerer will wait for PRACK or an INFO request
with end-of-candidates, before trickling further candidates.

There is hence no way for the situation you describe to occur.

Emil

On Sat, Oct 19, 2013 at 11:27 PM, Christer Holmberg
 wrote:
> Example:
>
>
>
> 1.       Alice sends an SDP Offer to Bob.
>
> 2.       Bob sends the SDP Answer to Alice, with candidates A, B and C.
>
> 3.       After that, Bob sends, using trickle ICE, candidates D and E to
> Alice.
>
> If Alice receives the SDP Answer first, and then the trickle ICE request,
> she will assume that Bob first provided candidates A, B and C (in the SDP
> Answer), and then added D and E (in the trickle ICE request).
>
> If Alice receives the trickle ICE request first, and then the SDP Answer,
> she will assume that Bob first provided candidates D and E (in the trickl=
e
> ICE request), but then replaced them with candidates A, B and C (as the S=
DP
> Answer did not contain candidates D and E).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
> L=E4hetetty: 19. lokakuuta 2013 20:49
>
>
> Vastaanottaja: Christer Holmberg
> Kopio: Paul Kyzivat; mmusic
> Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value
>
>
>
> Could you please be more specific? I am not sure I see it.
>
> Emil
>
> --sent from my mobile
>
> On 19 Oct 2013 19:01, "Christer Holmberg" 
> wrote:
>
> Hi,
>
>> If D and E are not provided and checked in the new O/A then they are no
>> longer valid. Think of them as peer reflexive.
>
> In that case there could be a race condition, if trickled candidates are
> provided at the same time as an ongoing O/A.
>
> Regards,
>
> Christer
>
>
>
>
>
> --sent from my mobile
>
> On 19 Oct 2013 18:44, "Christer Holmberg" 
> wrote:
>
> Hi,
>
>
>
> I am trying to figure out how/if O/A and trickle ICE interact when it com=
es
> to providing candidates.
>
>
>
> But, let=92s start with a more simple example:
>
>
>
> -          I provide candidates A, B and C using O/A
>
> -          Later, I provide candidates D and E using trickle ICE
>
> -          Then, I send a new O/A, with candidates A, B and C
>
>
>
> Now, are candidates D and E still valid, or did my new O/A disable them?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
> L=E4hetetty: 19. lokakuuta 2013 18:56
> Vastaanottaja: Christer Holmberg
> Kopio: Paul Kyzivat; mmusic
> Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
>
>
>
> The new SDP O/A you mention would cause an ICE restart and that's what wi=
ll
> define agent state. Not previously exchange trickled candidates.
>
> I am not sure I understand the relation to your argument though (about
> trickled candidates affecting session SDP) so I might be missing your poi=
nt.
>
> Emil
>
> --sent from my mobile
>
> On 19 Oct 2013 17:43, "Christer Holmberg" 
> wrote:
>
> Hi Emil,
>
>
>
> Assume you have an m- line, for which you provide candidates using trickl=
e
> ICE.
>
>
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means i=
t
> will inherit the address properties and candidates of the BUNDLE group.
>
>
>
> Are you saying that the previously provided trickle candidates are still
> comsidered valid, eventhough they are associated with different address
> properties etc?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Sent from my Sony Ericsson Xperia arc S
>
>
>
> Emil Ivov  wrote:
>
>
>
> Hey Christer,
>
> On 19 Oct 2013 08:10, "Christer Holmberg" 
> wrote:
>
> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session SDP
> (bacause, as you said, they are sent within SDP).
>
>
>
> I don't think this is accurate. Use of SDP for additional candidates is j=
ust
> a coincidence. It was readily available syntax for describing candidates =
and
> it might be convenient in some implementations (although this is probably=
 of
> marginal value).
>
> The point is that the syntax is not due to a relationship to Offer/Answer
> and could have just as easily be based on JSON or XML or anything else.
>
> Also, trickled candidates DO NOT update the session SDP the way a new m=
=3D
> line does. There is only a loose relation between them and subsequent O/A=
s.
> The origin field does NOT need to be updated. New candidates in new O/As =
may
> appear without having been trickled and trickled candidates can just well=
 be
> omitted in subsequent O/As. In other words, a trickled candidate would on=
ly
> affect the state of the ICE agent in exactly the same way a peer reflexiv=
e
> candidate would and it would be orthogonal to O/A, again, just as peer
> reflexive candidates are.
>
>
>
> So, while we would need to think about whether using POF/PAN would make
> sense or not, why do you think that we "can't" do it?
>
>
>
> OK, maybe "can't" is not entirely accurate here. I am sure that we *could=
*
> make it would with O/A if we really put our backs into it. In a similar w=
ay,
> I am sure we could also make it work by exchanging candidates in a shared
> Dropbox folder. In either case, I don't see why we would want to incur su=
ch
> a thing on our selves. I don't see any advantage to doing this.
>
> On the downside, trickling candidates in Offer/Answer would imply the
> following problems:
>
> *  Very high glare probability.
>
> * Unnecessarily complex implementation (really, this would be a nightmare
> and I sincerely advise anyone supporting offer answer for trickle to firs=
t
> try and implement it).
>
> * Ambiguity between ICE restarts and trickle updates.
>
> Also, given how we have already had this discussion and converged on use =
of
> INFO, it is unclear to to me as to why we are revisiting this. I don't th=
ink
> anyone has reported any problems on the alternative.
>
> Cheers,
> Emil
>
>
>
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov  wrote:
>
>
> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat  wro=
te:
>> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>>
>>> I do think that a different MIME type makes more sense here for the
>>> reasons Paul explained.
>>
>>
>> In the sip world, we may *also* want a new content-disposition. Using
>> 'session' as the content-disposition with the new content type implies
>> that
>> the the body is just a different representation of an offer or answer. (=
We
>> were once considering exactly that with SDPng.)
>>
>> We *might* want to think of it that way, or not.
>>
>>
>>> It might be worth adding that the same MIME type would be used when
>>> sending candidate updates with Trickle ICE for SIP, which to me at
>>> least, makes a lot of sense.
>>
>>
>> I still wonder why trickle ICE needs a *different* mechanism for partial
>> offers. Couldn't we just use this one?
>
> By "this one", do you mean POF/PAN or application/sdpfrag?
>
> We don't need anything different than application/sdpfrag.
>
> We can't use POF/PAN because we are not sending offers and answers. We
> are just exchanging candidates in agent-to-agent messages. The use of
> SDP is an unfortunate coincidence, not an indication of offers and
> answers.
>
> Emil
>
>>
>>         Thanks,
>>         Paul
>>
>>> --sent from my mobile
>>>
>>> On 18 Oct 2013 16:55, "Christer Holmberg"
>>> =
>
>>>
>>> wrote:
>>>
>>>     Hi,
>>>
>>>      > I think you and I are thinking of this differently.
>>>      >
>>>      > I'm thinking that the POFs and PANs are something new, different
>>>     from offers and answers. They go on *between* offers and answers.
>>>      >
>>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>>     offers and answers.
>>>
>>>     It's not the way I think - I just wanted to explore how/if things
>>>     would work IF we were thinking like that, and what the pros and con=
s
>>>     would be :)
>>>
>>>     We have to keep in mind that, no matter how we look at it, the
>>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>>     they impact the same SDP state, can cause race conditions etc.
>>>
>>>     Regards,
>>>
>>>     Christer
>>>
>>>
>>>
>>>
>>>
>>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>>      > Hi,
>>>      >
>>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>>> proxy
>>>      >>>>> that only understands application/sdp (e.g. for gate control
>>>      >>>>> purpose) will not even look at the C-D header field value fo=
r
>>>      >>>>> other bodies. And, unless such proxy understands POF/PAN,
>>> there
>>>      >>>>> may not be any media passing through...
>>>      >>>>
>>>      >>>> Right. A middlebox that doesn't understand application/sdpfra=
g
>>>      >>>> won't know to look at its contents and let the new streams
>>>     through.
>>>      >>>> And a middlebox that sees something marked as
>>>     "application/sdp" that conveys only a tiny fraction of the session
>>>     will probably be just as catastrophic; I would imagine everything
>>>     but the modified streams would be shut off. There's no way to win
>>> here.
>>>      >>>
>>>      >>> I think it would reject the Offer - at least that's what it
>>>     should do according to 3264.
>>>      >>
>>>      >> 3264 only talks about how to process offers and answers describ=
ed
>>> in
>>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>>     that they are carried in body parts of content-type application/sdp
>>>     with content-disposition of 'session'. If a body part has
>>>     content-type application/sdp but has a disposition other than
>>>     'session' then it isn't an offer or answer according to 3261, and s=
o
>>>     3264 doesn't apply.
>>>      >
>>>      > 3264 says that all m- line must be present in an Offer - even if
>>>     they are not modified. So, what I meant was that in case all m-
>>>     lines are NOT present (in the case of a POF), such Offer would be
>>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>>      >
>>>      >>>> At some point, we have to come to peace with the fact that an=
y
>>>     middleboxes that aren't primarily in the business of stifling
>>>     progress will need to keep pace with protocol extensions as they ge=
t
>>>     deployed.
>>>      >>>
>>>      >>> I really wish things worked that way :)
>>>      >>
>>>      >> So progress ends because middleboxes don't permit it?
>>>      >>
>>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>>     world moves on to webrtc.
>>>      >
>>>      > I think that getting explicit rejections, rather than having to
>>>     try to
>>>      > figure out where things go wrong, is good for progress :)
>>>      >
>>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>>      > brainstorming :)
>>>      >
>>>      > Regards,
>>>      >
>>>      > Christer
>>>      >
>>>
>>>     _______________________________________________
>>>     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
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> https://jitsi.org                       FAX:   +33.1.77.62.47.31
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



--=20
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From emcho@sip-communicator.org  Sun Oct 20 04:24: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 E38B321F9EE1 for ; Sun, 20 Oct 2013 04:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level: 
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfHVUdDKZuWa for ; Sun, 20 Oct 2013 04:24:49 -0700 (PDT)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id C040721F9EDB for ; Sun, 20 Oct 2013 04:24:47 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id q10so5040592pdj.0 for ; Sun, 20 Oct 2013 04:24:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zxdDY5Vg6wnuCXLi5wMl3fXiW4JNjE12QJTIAwBterI=; b=MUUNR0cUIAFmn3g9+MYoER0WU8QlymiNpYHCy94U/Ha/rmaz9//qYEWpRAJlmnEDiG usCe1VUi+JnDjXQwqxAKWp8m2LiWyTCH2YP7A8FiM4PB3u3vpfoslTJau6Ok4aLm7Cle VHjfhbT5BFT/ggahYRlsw3tyvgxpSizDNYCfRrYF0UbovW2BobL3+OWXPDk5WBY5UZg4 ps1L2GNPcPj8uhGTCJ6rRc0V2NoP1ZGDjYwBhqkulAYlGT1NOIdbkSTYACN1k8qOSlVi lRTCO8DEUJmWZvo4lf3h5Hc+Ug83AvwBLBDJ3+qElLyJJDSJwFq/EwJwTdi/2UKTvqkO wwcQ==
X-Gm-Message-State: ALoCoQnJqas2mjU4X6oDCh+FjB0gjg+/JPHWTX2+NYcgUO3PdDBVw+/B2Dhtln4qGyW2Gypc7D8o
X-Received: by 10.66.161.38 with SMTP id xp6mr1172620pab.145.1382268287294; Sun, 20 Oct 2013 04:24:47 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [2607:f8b0:400e:c02::231]) by mx.google.com with ESMTPSA id ef10sm17860686pac.1.2013.10.20.04.24.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 04:24:46 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id p10so4142072pdj.36 for ; Sun, 20 Oct 2013 04:24:46 -0700 (PDT)
X-Received: by 10.68.244.2 with SMTP id xc2mr12425842pbc.58.1382268286580; Sun, 20 Oct 2013 04:24:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 04:24:26 -0700 (PDT)
In-Reply-To: <52634609.2000501@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <52634609.2000501@alum.mit.edu>
From: Emil Ivov 
Date: Sun, 20 Oct 2013 13:24:26 +0200
Message-ID: 
To: Paul Kyzivat 
Content-Type: text/plain; charset=ISO-8859-1
Cc: mmusic 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 11:24:53 -0000

Hey Paul,

On Sun, Oct 20, 2013 at 4:55 AM, Paul Kyzivat  wrote:
> On 10/19/13 11:56 AM, Emil Ivov wrote:
>>
>> The new SDP O/A you mention would cause an ICE restart and that's what
>> will define agent state. Not previously exchange trickled candidates.
>
> Are you saying that every O/A causes an ICE restart for every m-line that is
> using ICE? That would be very unfortunate.

No, of course not. An offer that contains the currently in-use
addresses (local and remote), contains no other candidates, and has
the same ice-pwd and ice-ufrag, will not cause an ICE restart: Section
9.1.2.2 in 5245.

Emil


>
>         Thanks,
>         Paul
>
>> I am not sure I understand the relation to your argument though (about
>> trickled candidates affecting session SDP) so I might be missing your
>> point.
>>
>> Emil
>>
>> --sent from my mobile
>>
>> On 19 Oct 2013 17:43, "Christer Holmberg"
>> >
>>
>> wrote:
>>
>>     Hi Emil,
>>
>>     Assume you have an m- line, for which you provide candidates using
>> trickle ICE.
>>
>>     Then, you add the m- line to a BUNDLE group, using SDP O/A, which
>> means it will inherit the address properties and candidates of the BUNDLE
>> group.
>>
>>     Are you saying that the previously provided trickle candidates are
>> still comsidered valid, eventhough they are associated with different
>> address properties etc?
>>
>>     Regards,
>>
>>     Christer
>>
>>     Sent from my Sony Ericsson Xperia arc S
>>
>>     Emil Ivov > wrote:
>>
>>     Hey Christer,
>>
>>     On 19 Oct 2013 08:10, "Christer Holmberg"
>>     >     > wrote:
>>
>>         Hi Emil,
>>
>>         Similar to POF/PAN, the sending of candidates do affect the
>>         session SDP (bacause, as you said, they are sent within SDP).
>>
>>
>>     I don't think this is accurate. Use of SDP for additional candidates
>>     is just a coincidence. It was readily available syntax for
>>     describing candidates and it might be convenient in some
>>     implementations (although this is probably of marginal value).
>>
>>     The point is that the syntax is not due to a relationship to
>>     Offer/Answer and could have just as easily be based on JSON or XML
>>     or anything else.
>>
>>     Also, trickled candidates DO NOT update the session SDP the way a
>>     new m= line does. There is only a loose relation between them and
>>     subsequent O/As. The origin field does NOT need to be updated. New
>>     candidates in new O/As may appear without having been trickled and
>>     trickled candidates can just well be omitted in subsequent O/As. In
>>     other words, a trickled candidate would only affect the state of the
>>     ICE agent in exactly the same way a peer reflexive candidate would
>>     and it would be orthogonal to O/A, again, just as peer reflexive
>>     candidates are.
>>
>>         So, while we would need to think about whether using POF/PAN
>>         would make sense or not, why do you think that we "can't" do it?
>>
>>
>>     OK, maybe "can't" is not entirely accurate here. I am sure that we
>>     *could* make it would with O/A if we really put our backs into it.
>>     In a similar way, I am sure we could also make it work by exchanging
>>     candidates in a shared Dropbox folder. In either case, I don't see
>>     why we would want to incur such a thing on our selves. I don't see
>>     any advantage to doing this.
>>
>>     On the downside, trickling candidates in Offer/Answer would imply
>>     the following problems:
>>
>>     *  Very high glare probability.
>>     * Unnecessarily complex implementation (really, this would be a
>>     nightmare and I sincerely advise anyone supporting offer answer for
>>     trickle to first try and implement it).
>>     * Ambiguity between ICE restarts and trickle updates.
>>
>>     Also, given how we have already had this discussion and converged on
>>     use of INFO, it is unclear to to me as to why we are revisiting
>>     this. I don't think anyone has reported any problems on the
>> alternative.
>>
>>     Cheers,
>>     Emil
>>
>>
>>         Regards,
>>
>>         Christer
>>
>>         Sent from my Sony Ericsson Xperia arc S
>>
>>         Emil Ivov > wrote:
>>
>>
>>         On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat
>>         > wrote:
>>          > On 10/18/13 6:11 PM, Emil Ivov wrote:
>>          >>
>>          >> I do think that a different MIME type makes more sense here
>>         for the
>>          >> reasons Paul explained.
>>          >
>>          >
>>          > In the sip world, we may *also* want a new
>>         content-disposition. Using
>>          > 'session' as the content-disposition with the new content
>>         type implies that
>>          > the the body is just a different representation of an offer
>>         or answer. (We
>>          > were once considering exactly that with SDPng.)
>>          >
>>          > We *might* want to think of it that way, or not.
>>          >
>>          >
>>          >> It might be worth adding that the same MIME type would be
>>         used when
>>          >> sending candidate updates with Trickle ICE for SIP, which to
>>         me at
>>          >> least, makes a lot of sense.
>>          >
>>          >
>>          > I still wonder why trickle ICE needs a *different* mechanism
>>         for partial
>>          > offers. Couldn't we just use this one?
>>
>>         By "this one", do you mean POF/PAN or application/sdpfrag?
>>
>>         We don't need anything different than application/sdpfrag.
>>
>>         We can't use POF/PAN because we are not sending offers and
>>         answers. We
>>         are just exchanging candidates in agent-to-agent messages. The
>>         use of
>>         SDP is an unfortunate coincidence, not an indication of offers and
>>         answers.
>>
>>         Emil
>>
>>          >
>>          >         Thanks,
>>          >         Paul
>>          >
>>          >> --sent from my mobile
>>          >>
>>          >> On 18 Oct 2013 16:55, "Christer Holmberg"
>>          >> >         
>>         >
>>         >>
>>          >>
>>          >> wrote:
>>          >>
>>          >>     Hi,
>>          >>
>>          >>      > I think you and I are thinking of this differently.
>>          >>      >
>>          >>      > I'm thinking that the POFs and PANs are something
>>         new, different
>>          >>     from offers and answers. They go on *between* offers and
>>         answers.
>>          >>      >
>>          >>      > IIUC you are thinking of POFs and PANs as extended
>>         forms of
>>          >>     offers and answers.
>>          >>
>>          >>     It's not the way I think - I just wanted to explore
>>         how/if things
>>          >>     would work IF we were thinking like that, and what the
>>         pros and cons
>>          >>     would be :)
>>          >>
>>          >>     We have to keep in mind that, no matter how we look at
>>         it, the
>>          >>     Offers/Answers and POFs/PANs are tightly connected,
>>         meaning that
>>          >>     they impact the same SDP state, can cause race
>>         conditions etc.
>>          >>
>>          >>     Regards,
>>          >>
>>          >>     Christer
>>          >>
>>          >>
>>          >>
>>          >>
>>          >>
>>          >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>          >>      > Hi,
>>          >>      >
>>          >>      >>>>> Content-Disposition does not apply to
>>         intermediaries. So, a
>>          >> proxy
>>          >>      >>>>> that only understands application/sdp (e.g. for
>>         gate control
>>          >>      >>>>> purpose) will not even look at the C-D header
>>         field value for
>>          >>      >>>>> other bodies. And, unless such proxy understands
>>         POF/PAN, there
>>          >>      >>>>> may not be any media passing through...
>>          >>      >>>>
>>          >>      >>>> Right. A middlebox that doesn't understand
>>         application/sdpfrag
>>          >>      >>>> won't know to look at its contents and let the new
>>         streams
>>          >>     through.
>>          >>      >>>> And a middlebox that sees something marked as
>>          >>     "application/sdp" that conveys only a tiny fraction of
>>         the session
>>          >>     will probably be just as catastrophic; I would imagine
>>         everything
>>          >>     but the modified streams would be shut off. There's no
>>         way to win
>>          >> here.
>>          >>      >>>
>>          >>      >>> I think it would reject the Offer - at least that's
>>         what it
>>          >>     should do according to 3264.
>>          >>      >>
>>          >>      >> 3264 only talks about how to process offers and
>>         answers described
>>          >> in
>>          >>      >> SDP. It does not say how those are conveyed in sip.
>>         3261 says
>>          >>     that they are carried in body parts of content-type
>>         application/sdp
>>          >>     with content-disposition of 'session'. If a body part has
>>          >>     content-type application/sdp but has a disposition other
>>         than
>>          >>     'session' then it isn't an offer or answer according to
>>         3261, and so
>>          >>     3264 doesn't apply.
>>          >>      >
>>          >>      > 3264 says that all m- line must be present in an
>>         Offer - even if
>>          >>     they are not modified. So, what I meant was that in case
>>         all m-
>>          >>     lines are NOT present (in the case of a POF), such Offer
>>         would be
>>          >>     rejected - unless the middlebox understands the POF/PAN
>>         mechanism .
>>          >>      >
>>          >>      >>>> At some point, we have to come to peace with the
>>         fact that any
>>          >>     middleboxes that aren't primarily in the business of
>>         stifling
>>          >>     progress will need to keep pace with protocol extensions
>>         as they get
>>          >>     deployed.
>>          >>      >>>
>>          >>      >>> I really wish things worked that way :)
>>          >>      >>
>>          >>      >> So progress ends because middleboxes don't permit it?
>>          >>      >>
>>          >>      >> Maybe you are right. Then sip will go the way of
>>         h323 while the
>>          >>     world moves on to webrtc.
>>          >>      >
>>          >>      > I think that getting explicit rejections, rather than
>>         having to
>>          >>     try to
>>          >>      > figure out where things go wrong, is good for progress
>> :)
>>          >>      >
>>          >>      > Anyway, it wasn't really a suggestion - I just wanted
>>         to do some
>>          >>      > brainstorming :)
>>          >>      >
>>          >>      > Regards,
>>          >>      >
>>          >>      > Christer
>>          >>      >
>>          >>
>>          >>     _______________________________________________
>>          >>     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
>>
>>
>>
>>         --
>>         Emil Ivov, Ph.D.                       67000 Strasbourg,
>>         Project Lead                           France
>>         Jitsi
>>         emcho@jitsi.org 
>>           PHONE: +33.1.77.62.43.30 
>>         https://jitsi.org                       FAX: +33.1.77.62.47.31
>>         
>>
>>         _______________________________________________
>>         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



-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From christer.holmberg@ericsson.com  Sun Oct 20 05:29: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 AD1EE11E81B2 for ; Sun, 20 Oct 2013 05:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.903
X-Spam-Level: 
X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQos8USXu6Gw for ; Sun, 20 Oct 2013 05:29:50 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E92FC11E83C3 for ; Sun, 20 Oct 2013 05:29:49 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-23-5263ccbc7283
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 2C.4E.25272.CBCC3625; Sun, 20 Oct 2013 14:29:48 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 14:29:48 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzE8G0I7mmVcCn0Sk2tTAgwzDTpn6+B8AgAAEqgCAAI51eYAARXaAgABat3z//+HsAIAALhiw///iMgCAACMJcP//7C2AAASGVbAAH+LgAAAGvyCw
Date: Sun, 20 Oct 2013 12:29:47 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4DC401@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C33FB@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6eM8lBBrNu6Fus2TmBxWLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPP6/CQxgjuKySUnNySxLLdK3S+DKuDP1PFvBpJyKE20b2BoY HwR2MXJySAiYSDw99IIJwhaTuHBvPVsXIxeHkMBRRollCyezQzhLGCX2zjzJ2MXIwcEmYCHR /U8bpEFEQF6iu20RWDOzgJPEta6XzCC2sECIxK0v55khakIl2g5MZIKwmxgl/p4JAhnDIqAq ceuYFkiYV8BX4vuhU6wQq/ZySZw99BGsl1MgUOLlxotgNiPQcd9PrYHaJS7x4eB1ZoijBSSW 7DkPZYtKvHz8jxXCVpJYsf0SI0S9nsSNqVPYIGxtoL9eM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXIUpxYn5aYbGWxiBMbNwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2M15tkFgU5tBqfecnkm9O+1XfyySttM+08X9a/vx0hGiyQMu9/ Y1eAjfKmq4q7rXm6p3L4mf60P/cxjbdRMbeFLSskao9d9z81xjdh53i/S7yec99HSjBfyuN/ p4E9//qNjU+LXm8/y2nMqs1zeUVlk1Cco6fVxqlufg9t0hcvm+zxdtr0lVVKLMUZiYZazEXF iQAokvyvaQIAAA==
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 12:29:55 -0000

Hi Emil,

In general, my point is the following: if there are multiple mechanisms to =
add/remove (explicit or implicit) candidates, it needs to be clear how they=
 interact, and whether there can be ambiguous situations etc (e.g. if it is=
 unclear in which order candidates have been provided).

And, I assume we now have 3 different mechanisms to provide candidates: SDP=
 O/A, SDP POF/PAN (I assume it will be allowed to provide candidates using =
POF/PAN, if e.g. a new m- line is added), and Trickle ICE.

But, if you claim there is no way such ambiguous situations can occur, fine=
 :)

Regards,

Christer

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]=20
L=E4hetetty: 20. lokakuuta 2013 14:12
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type v=
alue

Hey Christer,

Before Berlin we agreed (and it is my fault for not putting that in text ye=
t) that the answerer will wait for PRACK or an INFO request with end-of-can=
didates, before trickling further candidates.

There is hence no way for the situation you describe to occur.

Emil

On Sat, Oct 19, 2013 at 11:27 PM, Christer Holmberg  wrote:
> Example:
>
>
>
> 1.       Alice sends an SDP Offer to Bob.
>
> 2.       Bob sends the SDP Answer to Alice, with candidates A, B and C.
>
> 3.       After that, Bob sends, using trickle ICE, candidates D and E to
> Alice.
>
> If Alice receives the SDP Answer first, and then the trickle ICE=20
> request, she will assume that Bob first provided candidates A, B and C=20
> (in the SDP Answer), and then added D and E (in the trickle ICE request).
>
> If Alice receives the trickle ICE request first, and then the SDP=20
> Answer, she will assume that Bob first provided candidates D and E (in=20
> the trickle ICE request), but then replaced them with candidates A, B=20
> and C (as the SDP Answer did not contain candidates D and E).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
> L=E4hetetty: 19. lokakuuta 2013 20:49
>
>
> Vastaanottaja: Christer Holmberg
> Kopio: Paul Kyzivat; mmusic
> Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME=20
> type value
>
>
>
> Could you please be more specific? I am not sure I see it.
>
> Emil
>
> --sent from my mobile
>
> On 19 Oct 2013 19:01, "Christer Holmberg"=20
> 
> wrote:
>
> Hi,
>
>> If D and E are not provided and checked in the new O/A then they are=20
>> no longer valid. Think of them as peer reflexive.
>
> In that case there could be a race condition, if trickled candidates=20
> are provided at the same time as an ongoing O/A.
>
> Regards,
>
> Christer
>
>
>
>
>
> --sent from my mobile
>
> On 19 Oct 2013 18:44, "Christer Holmberg"=20
> 
> wrote:
>
> Hi,
>
>
>
> I am trying to figure out how/if O/A and trickle ICE interact when it=20
> comes to providing candidates.
>
>
>
> But, let's start with a more simple example:
>
>
>
> -          I provide candidates A, B and C using O/A
>
> -          Later, I provide candidates D and E using trickle ICE
>
> -          Then, I send a new O/A, with candidates A, B and C
>
>
>
> Now, are candidates D and E still valid, or did my new O/A disable them?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
> L=E4hetetty: 19. lokakuuta 2013 18:56
> Vastaanottaja: Christer Holmberg
> Kopio: Paul Kyzivat; mmusic
> Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type=20
> value
>
>
>
> The new SDP O/A you mention would cause an ICE restart and that's what=20
> will define agent state. Not previously exchange trickled candidates.
>
> I am not sure I understand the relation to your argument though (about=20
> trickled candidates affecting session SDP) so I might be missing your poi=
nt.
>
> Emil
>
> --sent from my mobile
>
> On 19 Oct 2013 17:43, "Christer Holmberg"=20
> 
> wrote:
>
> Hi Emil,
>
>
>
> Assume you have an m- line, for which you provide candidates using=20
> trickle ICE.
>
>
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which=20
> means it will inherit the address properties and candidates of the BUNDLE=
 group.
>
>
>
> Are you saying that the previously provided trickle candidates are=20
> still comsidered valid, eventhough they are associated with different=20
> address properties etc?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Sent from my Sony Ericsson Xperia arc S
>
>
>
> Emil Ivov  wrote:
>
>
>
> Hey Christer,
>
> On 19 Oct 2013 08:10, "Christer Holmberg"=20
> 
> wrote:
>
> Hi Emil,
>
> Similar to POF/PAN, the sending of candidates do affect the session=20
> SDP (bacause, as you said, they are sent within SDP).
>
>
>
> I don't think this is accurate. Use of SDP for additional candidates=20
> is just a coincidence. It was readily available syntax for describing=20
> candidates and it might be convenient in some implementations=20
> (although this is probably of marginal value).
>
> The point is that the syntax is not due to a relationship to=20
> Offer/Answer and could have just as easily be based on JSON or XML or any=
thing else.
>
> Also, trickled candidates DO NOT update the session SDP the way a new=20
> m=3D line does. There is only a loose relation between them and subsequen=
t O/As.
> The origin field does NOT need to be updated. New candidates in new=20
> O/As may appear without having been trickled and trickled candidates=20
> can just well be omitted in subsequent O/As. In other words, a=20
> trickled candidate would only affect the state of the ICE agent in=20
> exactly the same way a peer reflexive candidate would and it would be=20
> orthogonal to O/A, again, just as peer reflexive candidates are.
>
>
>
> So, while we would need to think about whether using POF/PAN would=20
> make sense or not, why do you think that we "can't" do it?
>
>
>
> OK, maybe "can't" is not entirely accurate here. I am sure that we=20
> *could* make it would with O/A if we really put our backs into it. In=20
> a similar way, I am sure we could also make it work by exchanging=20
> candidates in a shared Dropbox folder. In either case, I don't see why=20
> we would want to incur such a thing on our selves. I don't see any advant=
age to doing this.
>
> On the downside, trickling candidates in Offer/Answer would imply the=20
> following problems:
>
> *  Very high glare probability.
>
> * Unnecessarily complex implementation (really, this would be a=20
> nightmare and I sincerely advise anyone supporting offer answer for=20
> trickle to first try and implement it).
>
> * Ambiguity between ICE restarts and trickle updates.
>
> Also, given how we have already had this discussion and converged on=20
> use of INFO, it is unclear to to me as to why we are revisiting this.=20
> I don't think anyone has reported any problems on the alternative.
>
> Cheers,
> Emil
>
>
>
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov  wrote:
>
>
> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat  wro=
te:
>> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>>
>>> I do think that a different MIME type makes more sense here for the=20
>>> reasons Paul explained.
>>
>>
>> In the sip world, we may *also* want a new content-disposition. Using=20
>> 'session' as the content-disposition with the new content type=20
>> implies that the the body is just a different representation of an=20
>> offer or answer. (We were once considering exactly that with SDPng.)
>>
>> We *might* want to think of it that way, or not.
>>
>>
>>> It might be worth adding that the same MIME type would be used when=20
>>> sending candidate updates with Trickle ICE for SIP, which to me at=20
>>> least, makes a lot of sense.
>>
>>
>> I still wonder why trickle ICE needs a *different* mechanism for=20
>> partial offers. Couldn't we just use this one?
>
> By "this one", do you mean POF/PAN or application/sdpfrag?
>
> We don't need anything different than application/sdpfrag.
>
> We can't use POF/PAN because we are not sending offers and answers. We=20
> are just exchanging candidates in agent-to-agent messages. The use of=20
> SDP is an unfortunate coincidence, not an indication of offers and=20
> answers.
>
> Emil
>
>>
>>         Thanks,
>>         Paul
>>
>>> --sent from my mobile
>>>
>>> On 18 Oct 2013 16:55, "Christer Holmberg"
>>> >> >
>>>
>>> wrote:
>>>
>>>     Hi,
>>>
>>>      > I think you and I are thinking of this differently.
>>>      >
>>>      > I'm thinking that the POFs and PANs are something new, different
>>>     from offers and answers. They go on *between* offers and answers.
>>>      >
>>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>>     offers and answers.
>>>
>>>     It's not the way I think - I just wanted to explore how/if things
>>>     would work IF we were thinking like that, and what the pros and con=
s
>>>     would be :)
>>>
>>>     We have to keep in mind that, no matter how we look at it, the
>>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>>     they impact the same SDP state, can cause race conditions etc.
>>>
>>>     Regards,
>>>
>>>     Christer
>>>
>>>
>>>
>>>
>>>
>>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>>      > Hi,
>>>      >
>>>      >>>>> Content-Disposition does not apply to intermediaries. So,=20
>>> a proxy
>>>      >>>>> that only understands application/sdp (e.g. for gate control
>>>      >>>>> purpose) will not even look at the C-D header field value fo=
r
>>>      >>>>> other bodies. And, unless such proxy understands POF/PAN,=20
>>> there
>>>      >>>>> may not be any media passing through...
>>>      >>>>
>>>      >>>> Right. A middlebox that doesn't understand application/sdpfra=
g
>>>      >>>> won't know to look at its contents and let the new streams
>>>     through.
>>>      >>>> And a middlebox that sees something marked as
>>>     "application/sdp" that conveys only a tiny fraction of the session
>>>     will probably be just as catastrophic; I would imagine everything
>>>     but the modified streams would be shut off. There's no way to=20
>>> win here.
>>>      >>>
>>>      >>> I think it would reject the Offer - at least that's what it
>>>     should do according to 3264.
>>>      >>
>>>      >> 3264 only talks about how to process offers and answers=20
>>> described in
>>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>>     that they are carried in body parts of content-type application/sdp
>>>     with content-disposition of 'session'. If a body part has
>>>     content-type application/sdp but has a disposition other than
>>>     'session' then it isn't an offer or answer according to 3261, and s=
o
>>>     3264 doesn't apply.
>>>      >
>>>      > 3264 says that all m- line must be present in an Offer - even if
>>>     they are not modified. So, what I meant was that in case all m-
>>>     lines are NOT present (in the case of a POF), such Offer would be
>>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>>      >
>>>      >>>> At some point, we have to come to peace with the fact that an=
y
>>>     middleboxes that aren't primarily in the business of stifling
>>>     progress will need to keep pace with protocol extensions as they ge=
t
>>>     deployed.
>>>      >>>
>>>      >>> I really wish things worked that way :)
>>>      >>
>>>      >> So progress ends because middleboxes don't permit it?
>>>      >>
>>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>>     world moves on to webrtc.
>>>      >
>>>      > I think that getting explicit rejections, rather than having to
>>>     try to
>>>      > figure out where things go wrong, is good for progress :)
>>>      >
>>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>>      > brainstorming :)
>>>      >
>>>      > Regards,
>>>      >
>>>      > Christer
>>>      >
>>>
>>>     _______________________________________________
>>>     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
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> https://jitsi.org                       FAX:   +33.1.77.62.47.31
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



--=20
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From parthasarathi.ravindran@nsn.com  Sun Oct 20 07:37: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 7689911E81E8 for ; Sun, 20 Oct 2013 07:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlNnEb1aiA-l for ; Sun, 20 Oct 2013 07:37:21 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE6E11E81A2 for ; Sun, 20 Oct 2013 07:37:13 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9KEb8cs032447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Oct 2013 16:37:08 +0200
Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9KEb677032633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 16:37:07 +0200
Received: from SGSIHTC008.nsn-intra.net (10.159.225.25) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 20 Oct 2013 22:37:05 +0800
Received: from SGSIMBX006.nsn-intra.net ([169.254.6.23]) by SGSIHTC008.nsn-intra.net ([10.159.225.25]) with mapi id 14.03.0123.003; Sun, 20 Oct 2013 22:37:05 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" 
To: ext Adam Roach , Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: Ac7MLXQzW94qgC3aROioOA+dkUcdWv//gAiAgAAE0ACAAAWWAIAAGhqAgAAHMgD//TkKUA==
Date: Sun, 20 Oct 2013 14:37:04 +0000
Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C47CE2@SGSIMBX006.nsn-intra.net>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <5261A39A.1060505@nostrum.com>
In-Reply-To: <5261A39A.1060505@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.225.119]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1657
X-purgate-ID: 151667::1382279828-00004A43-627D0B89/0-0/0-0
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 14:37:33 -0000

My experience in SBC is different wherein SBC are only the boxes which are =
complaints to RFC (if required by the customer) and make sure that interop =
with non-compliant boxes/endpoints in the network.

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 ext Adam Roach
Sent: Saturday, October 19, 2013 2:40 AM
To: Christer Holmberg; Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

On 10/18/13 15:44, Christer Holmberg wrote:
> Hi,
>
>>> Content-Disposition does not apply to intermediaries. So, a proxy that
>>> only understands application/sdp (e.g. for gate control purpose) will
>>> not even look at the C-D header field value for other bodies. And,
>>> unless such proxy understands POF/PAN, there may not be any media
>>> passing through...
>> Right. A middlebox that doesn't understand application/sdpfrag won't kno=
w to look at its contents and let the new streams through. And a middlebox =
that sees
>> something marked as "application/sdp" that conveys only a tiny fraction =
of the session will probably be just as catastrophic; I would imagine every=
thing but the
>> modified streams would be shut off. There's no way to win here.
> I think it would reject the Offer - at least that's what it should do acc=
ording to 3264.

The kinds of middleboxes you're talking about don't, in my experience,=20
give much weight to anything written in any RFCs anywhere.

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

From partha@parthasarathi.co.in  Sun Oct 20 10:07: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 1A68511E81BA for ; Sun, 20 Oct 2013 10:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.036
X-Spam-Level: 
X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vetBoDatZuS for ; Sun, 20 Oct 2013 10:07:24 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id DAA8D11E8202 for ; Sun, 20 Oct 2013 10:07:20 -0700 (PDT)
Received: from userPC (unknown [122.179.103.73]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id BC86F869256; Sun, 20 Oct 2013 17:07:15 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382288839; bh=D0VDyZjbRQ82yiBPDX9F6bkRifOKJ8cC2evp1vYi4CU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=C1LaQKh2iYw+9EGEarUB2utlH7/1KN1gzZ/RjmilY4Mev5mL+TTObADmLgGziCOrU Eq6pnZ/+uD1kyxXOpLvg51MpUKLqACKGx7w8/BfJk4Gj6nNj6B8ARY2RgZQhycZs6r UkmSaO6eAi3cZ6q9FRpl/+44CHqllCvfJSj1HO/w=
From: "Parthasarathi R" 
To: "'Paul Kyzivat'" , "'Christer Holmberg'" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu>	<7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>	<526187AC.8060200@nostrum.com>	<7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu>
In-Reply-To: <52619FCC.3090606@alum.mit.edu>
Date: Sun, 20 Oct 2013 22:37:11 +0530
Message-ID: <001901cecdb6$d49f6180$7dde2480$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7MRDPYj7jJx/LdSruzl2C3gpSSawBbmfAg
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020204.52640DC7.005F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 17:07:29 -0000

Paul,

> Maybe you are right. Then sip will go the way of h323 while the world
> moves on to webrtc.

It is amazing to hear from you that h323 way of media negotiation is better
than SIP now :-)

Let us assume content-disposition "partial-session" for partial offer/answer
exist. So, RFC 3264 does not applies for "partial-session". How the normal
interaction and race condition between "session" and "partial-session" will
be handled as both impact the same session in the media layer? Could you
please explain.

Thanks
Partha



> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Saturday, October 19, 2013 2:24 AM
> To: Christer Holmberg
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value
> 
> On 10/18/13 4:44 PM, Christer Holmberg wrote:
> > Hi,
> >
> >>> Content-Disposition does not apply to intermediaries. So, a proxy
> that
> >>> only understands application/sdp (e.g. for gate control purpose)
> will
> >>> not even look at the C-D header field value for other bodies. And,
> >>> unless such proxy understands POF/PAN, there may not be any media
> >>> passing through...
> >>
> >> Right. A middlebox that doesn't understand application/sdpfrag won't
> know to look at its contents and let the new streams through. And a
> middlebox that sees
> >> something marked as "application/sdp" that conveys only a tiny
> fraction of the session will probably be just as catastrophic; I would
> imagine everything but the
> >> modified streams would be shut off. There's no way to win here.
> >
> > I think it would reject the Offer - at least that's what it should do
> according to 3264.
> 
> 3264 only talks about how to process offers and answers described in
> SDP. It does not say how those are conveyed in sip. 3261 says that they
> are carried in body parts of content-type application/sdp with
> content-disposition of 'session'. If a body part has content-type
> application/sdp but has a disposition other than 'session' then it
> isn't
> an offer or answer according to 3261, and so 3264 doesn't apply.
> 
> >> At some point, we have to come to peace with the fact that any
> middleboxes that aren't primarily in the business of stifling progress
> will need to keep pace with protocol extensions as they get deployed.
> >
> > I really wish things worked that way :)
> 
> So progress ends because middleboxes don't permit it?
> 
> Maybe you are right. Then sip will go the way of h323 while the world
> moves on to webrtc.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From adam@nostrum.com  Sun Oct 20 10:12: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 165E911E81F9 for ; Sun, 20 Oct 2013 10:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.76
X-Spam-Level: 
X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd32Q5Af4BWN for ; Sun, 20 Oct 2013 10:12:48 -0700 (PDT)
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 A29BC11E810A for ; Sun, 20 Oct 2013 10:12:48 -0700 (PDT)
Received: from [192.168.0.191] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9KHCgXP099594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Oct 2013 12:12:44 -0500 (CDT) (envelope-from adam@nostrum.com)
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in>
Mime-Version: 1.0 (1.0)
In-Reply-To: <001901cecdb6$d49f6180$7dde2480$@co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (10B350)
From: Adam Roach 
Date: Sun, 20 Oct 2013 12:12:37 -0500
To: Parthasarathi R 
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 17:12:49 -0000

On Oct 20, 2013, at 12:07, "Parthasarathi R"  wr=
ote:

> Let us assume content-disposition "partial-session" for partial offer/answ=
er
> exist. So, RFC 3264 does not applies for "partial-session". How the normal=

> interaction and race condition between "session" and "partial-session" wil=
l
> be handled as both impact the same session in the media layer? Could you
> please explain.


This is covered in the current draft. After you read it, let me know if you h=
ad trouble finding the section dealing with this interaction.=20

/a=

From partha@parthasarathi.co.in  Sun Oct 20 11:06: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 553AA11E8230 for ; Sun, 20 Oct 2013 11:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level: 
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.483,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIwgPDytBhlx for ; Sun, 20 Oct 2013 11:06:09 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.157]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEAF11E8231 for ; Sun, 20 Oct 2013 11:05:08 -0700 (PDT)
Received: from userPC (unknown [122.179.103.73]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 34EB186927F; Sun, 20 Oct 2013 18:05:02 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382292308; bh=z5EMOZxIYDOYRsK49assbkHfONF9pBa0jb2lhT5a+Sc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ffC63VzKfzTY/OoFpgT87pzYYxYE5OFqn7yWPftgcyaDP7HgZEK+SDDqKRhyZ0ejs UOkOHbSW/igm6nrRs9l5SAc6IUUmtIkyemfYTJIbYHD8dVTEddMpoVMMMeBGoDzWAl pgD3ljeX7iesXbS21XcumA/eQqFn10oFclO/x6/k=
From: "Parthasarathi R" 
To: "'Adam Roach'" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in> 
In-Reply-To: 
Date: Sun, 20 Oct 2013 23:34:59 +0530
Message-ID: <001d01cecdbe$e81edc60$b85c9520$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Nt53FURUW6vxQRtyhhn0pYubFMAABhHCQ
Content-Language: en-us
X-CTCH-RefID: str=0001.0A02020A.52641B53.00EB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154
Cc: mmusic@ietf.org, 'Paul Kyzivat' , 'Christer Holmberg' 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 18:06:14 -0000

Adam,

I'm looking for the interaction between full offer and partial offer glare
situation. In the current draft, Sec 6.5.2 & Sec 6.6.2 deals with partial
offer/answer situation only.

Thanks
Partha

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Sunday, October 20, 2013 10:43 PM
> To: Parthasarathi R
> Cc: Paul Kyzivat; Christer Holmberg; mmusic@ietf.org
> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value
> 
> 
> 
> On Oct 20, 2013, at 12:07, "Parthasarathi R"
>  wrote:
> 
> > Let us assume content-disposition "partial-session" for partial
> offer/answer
> > exist. So, RFC 3264 does not applies for "partial-session". How the
> normal
> > interaction and race condition between "session" and "partial-
> session" will
> > be handled as both impact the same session in the media layer? Could
> you
> > please explain.
> 
> 
> This is covered in the current draft. After you read it, let me know if
> you had trouble finding the section dealing with this interaction.
> 
> /a=


From adam@nostrum.com  Sun Oct 20 11:28: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 E2EDA11E8237 for ; Sun, 20 Oct 2013 11:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.436
X-Spam-Level: 
X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzCfIeW2gKxW for ; Sun, 20 Oct 2013 11:28:49 -0700 (PDT)
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 DB71F11E8247 for ; Sun, 20 Oct 2013 11:28:43 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9KIRmHK007890 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Oct 2013 13:27:48 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5264209F.6020301@nostrum.com>
Date: Sun, 20 Oct 2013 13:27:43 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Parthasarathi R 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in>  <001d01cecdbe$e81edc60$b85c9520$@co.in>
In-Reply-To: <001d01cecdbe$e81edc60$b85c9520$@co.in>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic@ietf.org, 'Paul Kyzivat' , 'Christer Holmberg' 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 18:28:50 -0000

On 10/20/13 13:04, Parthasarathi R wrote:
> I'm looking for the interaction between full offer and partial offer glare
> situation. In the current draft, Sec 6.5.2 & Sec 6.6.2 deals with partial
> offer/answer situation only.
>
Perhaps adding examples was a mistake. The examples are supposed to help 
with comprehension, but they do not form a part of the specification.

Really, this situation is intended to be covered in section 5.6: a 
partial offer crossing the wire with a full offer is a full glare 
situation. Neither is put into effect, and whatever procedures the 
higher-level protocol says to do to resolve glare are undertaken [1].

If you think there's any specific ambiguity here, please point it out; 
in particular, talk about how two different implementors might read this 
and reasonably do two incompatible things.

/a

___
[1] For SIP, these procedures involve 491 responses and the timer 
described in RFC 3261 section 14.1, but we're not necessarily 
considering partial for SIP at the moment.

From adam@nostrum.com  Sun Oct 20 12:28: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 7641011E8273 for ; Sun, 20 Oct 2013 12:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.442
X-Spam-Level: 
X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFJdTwgJt9sw for ; Sun, 20 Oct 2013 12:28:03 -0700 (PDT)
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 58A3B11E8263 for ; Sun, 20 Oct 2013 12:28:02 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9KJRvDK014156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Oct 2013 14:27:58 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52642EB8.3060203@nostrum.com>
Date: Sun, 20 Oct 2013 14:27:52 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Emil Ivov 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<5261AAF0.3030509@alum.mit.edu>	<7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>		<5261C314.8020001@alum.mit.edu>						<7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>		<7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>	 <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020208030909010406020208"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 19:28:04 -0000

This is a multi-part message in MIME format.
--------------020208030909010406020208
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/19/13 16:27, Christer Holmberg wrote:
>
> Example:
>
> 1.Alice sends an SDP Offer to Bob.
>
> 2.Bob sends the SDP Answer to Alice, with candidates A, B and C.
>
> 3.After that, Bob sends, using trickle ICE, candidates D and E to Alice.
>
> If Alice receives the SDP Answer first, and then the trickle ICE 
> request, she will assume that Bob first provided candidates A, B and C 
> (in the SDP Answer), and then added D and E (in the trickle ICE request).
>
> If Alice receives the trickle ICE request first, and then the SDP Answer
>

Don't do that then.

It's been pretty clear from the start that any session *modification* 
mechanism that does not also contain the full session state completely 
falls apart in the face of unordered delivery. This is a fundamental 
information problem, and you aren't going to write rules that somehow 
cause it not to be true.

We haven't yet tackled how to send trickle ICE in SIP, much less partial 
offers and partial answers. When we do, the only way it's going to have 
any chance of working at all is by requiring ordered delivery.

/a

--------------020208030909010406020208
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/19/13 16:27, Christer Holmberg
      wrote:

    

    

      
      
      
      

        
Example:

        
 

        
1.      
              Alice sends an SDP Offer to Bob.

        
 

        
2.      
              Bob sends the SDP Answer to Alice, with
            candidates A, B and C.

        
 

        
3.      
              After that, Bob sends, using trickle ICE,
            candidates D and E to Alice.

        
 

        
If Alice receives the SDP Answer first, and
            then the trickle ICE request, she will assume that Bob first
            provided candidates A, B and C (in the SDP Answer), and then
            added D and E (in the trickle ICE request).

        
 

        
If Alice receives the trickle ICE request
            first, and then the SDP Answer

      

    

    

    Don't do that then.

    

    It's been pretty clear from the start that any session
    *modification* mechanism that does not also contain the full session
    state completely falls apart in the face of unordered delivery. This
    is a fundamental information problem, and you aren't going to write
    rules that somehow cause it not to be true.

    

    We haven't yet tackled how to send trickle ICE in SIP, much less
    partial offers and partial answers. When we do, the only way it's
    going to have any chance of working at all is by requiring ordered
    delivery.

    

    /a

  


--------------020208030909010406020208--

From christer.holmberg@ericsson.com  Sun Oct 20 12: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 CC43011E822C for ; Sun, 20 Oct 2013 12:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.881
X-Spam-Level: 
X-Spam-Status: No, score=-3.881 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyZGR7z8QG+T for ; Sun, 20 Oct 2013 12:50:42 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD111E81D0 for ; Sun, 20 Oct 2013 12:50:38 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-94-5264340d5fbf
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0A.FD.25272.D0434625; Sun, 20 Oct 2013 21:50:37 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 21:50:36 +0200
From: Christer Holmberg 
To: Adam Roach , Emil Ivov 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzcp+iLSYC/YIgkW4GBkoIrtjKJn9/Sjg
Date: Sun, 20 Oct 2013 19:50:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com>
In-Reply-To: <52642EB8.3060203@nostrum.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjS6vSUqQwa/ZUhZ7/i5it1izcwKL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjJ5/H8T6DFr5xOWAJYoLpuU1JzMstQifbsErozu25vZ Cxp4Kz5vPsTYwHiFp4uRk0NCwETi9NQ2dghbTOLCvfVsILaQwFFGicdXgOJcQPYSRom789ay dDFycLAJWEh0/9MGqRERsJNYtGkhC4jNLOAksf/Da2YQW1jAS6JnZi8LRI23xP/7V6FsI4kH ax6wgtgsAqoSDdOaweK8Ar4S5381MELsesYuMenrVLCDOAW0Jc4eXcIEYjMCHff91BomiGXi Eh8OXmeGOFpAYsme81C2qMTLx/9YIWwliUW3PzOB3MwsoCmxfpc+RKuixJTuh+wQewUlTs58 wjKBUWwWkqmzEDpmIemYhaRjASPLKkaO4tTipNx0I4NNjMA4Orjlt8UOxst/bQ4xSnOwKInz fnzrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMTOO+9uuq3LRBdx7nO+/Z7ublrXppsTV HAH7ndsWxC55f2rn7ws1e5I8Jihx1Ox5KJmodfmC59PJoV/ldGd9nHqp1M05Pnxm3BGzV7Pf eHfpahXJbK79VMJ1SlCgyWlK3GzbRU2TX71ZlZ2QWP1ZYfWCN/u2/Xty33fHgspP9oKf+Nrc 7k6doKjEUpyRaKjFXFScCABGqrKwcQIAAA==
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 19:50:48 -0000

DQpIaSwNCg0KPj4gRXhhbXBsZToNCj4+DQo+PiAxLiBBbGljZSBzZW5kcyBhbiBTRFAgT2ZmZXIg
dG8gQm9iLg0KPj7CoA0KPj4gMi4gQm9iIHNlbmRzIHRoZSBTRFAgQW5zd2VyIHRvIEFsaWNlLCB3
aXRoIGNhbmRpZGF0ZXMgQSwgQiBhbmQgQy4NCj4+wqANCj4+IDMuIEFmdGVyIHRoYXQsIEJvYiBz
ZW5kcywgdXNpbmcgdHJpY2tsZSBJQ0UsIGNhbmRpZGF0ZXMgRCBhbmQgRSB0byBBbGljZS4NCj4+
wqANCj4+IElmIEFsaWNlIHJlY2VpdmVzIHRoZSBTRFAgQW5zd2VyIGZpcnN0LCBhbmQgdGhlbiB0
aGUgdHJpY2tsZSBJQ0UgcmVxdWVzdCwgc2hlIHdpbGwgYXNzdW1lIHRoYXQgQm9iIGZpcnN0IHBy
b3ZpZGVkIGNhbmRpZGF0ZXMgQSwgQiBhbmQgQyAoaW4gdGhlIFNEUCBBbnN3ZXIpLCBhbmQgdGhl
biBhZGRlZCBEIGFuZCBFIChpbiB0aGUgdHJpY2tsZSBJQ0UgcmVxdWVzdCkuDQo+PsKgDQo+PiBJ
ZiBBbGljZSByZWNlaXZlcyB0aGUgdHJpY2tsZSBJQ0UgcmVxdWVzdCBmaXJzdCwgYW5kIHRoZW4g
dGhlIFNEUCBBbnN3ZXINCj4NCj4gRG9uJ3QgZG8gdGhhdCB0aGVuLg0KPg0KPiBJdCdzIGJlZW4g
cHJldHR5IGNsZWFyIGZyb20gdGhlIHN0YXJ0IHRoYXQgYW55IHNlc3Npb24gKm1vZGlmaWNhdGlv
biogbWVjaGFuaXNtIHRoYXQgZG9lcyBub3QgYWxzbyBjb250YWluIHRoZSBmdWxsIHNlc3Npb24g
c3RhdGUgY29tcGxldGVseSBmYWxscyBhcGFydCBpbiB0aGUgZmFjZSBvZiB1bm9yZGVyZWQgZGVs
aXZlcnkuIFRoaXMgaXMgYSBmdW5kYW1lbnRhbCBpbmZvcm1hdGlvbiBwcm9ibGVtLCBhbmQgeW91
IGFyZW4ndCBnb2luZyB0byB3cml0ZSBydWxlcyB0aGF0IHNvbWVob3cgY2F1c2UgaXQgbm90IHRv
IGJlIHRydWUuDQo+DQo+IFdlIGhhdmVuJ3QgeWV0IHRhY2tsZWQgaG93IHRvIHNlbmQgdHJpY2ts
ZSBJQ0UgaW4gU0lQLCBtdWNoIGxlc3MgcGFydGlhbCBvZmZlcnMgYW5kIHBhcnRpYWwgYW5zd2Vy
cy4gV2hlbiB3ZSBkbywgdGhlIG9ubHkgd2F5IGl0J3MgZ29pbmcgdG8gaGF2ZSBhbnkgY2hhbmNl
IG9mIHdvcmtpbmcgYXQgYWxsIGlzIGJ5IHJlcXVpcmluZyBvcmRlcmVkIGRlbGl2ZXJ5Lg0KDQpJ
IHRvdGFsbHkgYWdyZWUsIGFuZCBteSBvcGluaW9uICh3aGljaCBJIHRyaWVkIHRvIGV4cGxhaW4g
dG8gRW1pbCkgaXMgdGhhdCBpdCBhcHBsaWVzIGFsc28gdG8gY2FuZGlkYXRlcy4gDQoNClJlZ2Fy
ZHMsDQoNCkNocmlzdGVyDQo=

From pkyzivat@alum.mit.edu  Sun Oct 20 13:06: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 7656A11E8421 for ; Sun, 20 Oct 2013 13:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.295
X-Spam-Level: 
X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dl-KBzgPFQJ for ; Sun, 20 Oct 2013 13:06:22 -0700 (PDT)
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 BAD7F11E83CE for ; Sun, 20 Oct 2013 13:06:08 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id fXkp1m0020Fqzac58Y68mM; Sun, 20 Oct 2013 20:06:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id fY671m00o3ZTu2S3UY67T5; Sun, 20 Oct 2013 20:06:08 +0000
Message-ID: <526437AF.1070002@alum.mit.edu>
Date: Sun, 20 Oct 2013 16:06:07 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Parthasarathi R 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu>	<7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>	<526187AC.8060200@nostrum.com>	<7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in>
In-Reply-To: <001901cecdb6$d49f6180$7dde2480$@co.in>
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=1382299568; bh=ScfB7SGkdPlUvUVJxsPPjbkbO+cMmWoSc29UEjjXeys=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qxEN9Is7ousJ6l7EDJSFFZmOvokOWsWBVhS4U9S3fvQKTg6n3kLsodkG8fnV2yo74 lPOoZRjjIow8oSY3yVSxwAerpXIILdBmewZwzwYJJ+xO+FO60/bV21v/+9sS/4hAKG u3xEn/7xQ2KH2oTuNVJJKYSXNZJDTZdE20zjIQH64UwUNfv6P0p8NVN8+6zNUvnOUu fTvMYqq4FfVs+P/Vc6FEohUEEAyzH2lecLc+0nJCleVjPhwH/7VBIjD3sR4jBR8ivO iOtMtFyLeuGQ6ZJ6DrWPzXqNueIEpPlmxkra3kM+TAwJpl17qOj5HFhjpQ0RtKcJ4w VzoWFC7R+Bt6Q==
Cc: mmusic@ietf.org, 'Christer Holmberg' 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:06:27 -0000

On 10/20/13 1:07 PM, Parthasarathi R wrote:
> Paul,
>
>> Maybe you are right. Then sip will go the way of h323 while the world
>> moves on to webrtc.
>
> It is amazing to hear from you that h323 way of media negotiation is better
> than SIP now :-)

Even though you included a smiley, I think maybe you didn't understand 
how I meant that statement. I didn't intend to suggest that sip should 
adopt any new behavior from h323. I meant that then sip may become old 
and obsolete, the way h323 is. (Some think it already has. It certainly 
is working on it.)

	Thanks,
	Paul

> Let us assume content-disposition "partial-session" for partial offer/answer
> exist. So, RFC 3264 does not applies for "partial-session". How the normal
> interaction and race condition between "session" and "partial-session" will
> be handled as both impact the same session in the media layer? Could you
> please explain.
>
> Thanks
> Partha
>
>
>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Paul Kyzivat
>> Sent: Saturday, October 19, 2013 2:24 AM
>> To: Christer Holmberg
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
>> value
>>
>> On 10/18/13 4:44 PM, Christer Holmberg wrote:
>>> Hi,
>>>
>>>>> Content-Disposition does not apply to intermediaries. So, a proxy
>> that
>>>>> only understands application/sdp (e.g. for gate control purpose)
>> will
>>>>> not even look at the C-D header field value for other bodies. And,
>>>>> unless such proxy understands POF/PAN, there may not be any media
>>>>> passing through...
>>>>
>>>> Right. A middlebox that doesn't understand application/sdpfrag won't
>> know to look at its contents and let the new streams through. And a
>> middlebox that sees
>>>> something marked as "application/sdp" that conveys only a tiny
>> fraction of the session will probably be just as catastrophic; I would
>> imagine everything but the
>>>> modified streams would be shut off. There's no way to win here.
>>>
>>> I think it would reject the Offer - at least that's what it should do
>> according to 3264.
>>
>> 3264 only talks about how to process offers and answers described in
>> SDP. It does not say how those are conveyed in sip. 3261 says that they
>> are carried in body parts of content-type application/sdp with
>> content-disposition of 'session'. If a body part has content-type
>> application/sdp but has a disposition other than 'session' then it
>> isn't
>> an offer or answer according to 3261, and so 3264 doesn't apply.
>>
>>>> At some point, we have to come to peace with the fact that any
>> middleboxes that aren't primarily in the business of stifling progress
>> will need to keep pace with protocol extensions as they get deployed.
>>>
>>> I really wish things worked that way :)
>>
>> So progress ends because middleboxes don't permit it?
>>
>> Maybe you are right. Then sip will go the way of h323 while the world
>> moves on to webrtc.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>


From christer.holmberg@ericsson.com  Sun Oct 20 13:11: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 8D37F11E8264 for ; Sun, 20 Oct 2013 13:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[AWL=-1.261,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQNnAJClqfDp for ; Sun, 20 Oct 2013 13:11:03 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA1CA11E8266 for ; Sun, 20 Oct 2013 13:11:00 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-90-526438d3a5ab
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.9E.25272.3D834625; Sun, 20 Oct 2013 22:11:00 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 22:10:59 +0200
From: Christer Holmberg 
To: Paul Kyzivat , Parthasarathi R 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzbbWoAMqBAdc60mHdfNiXNf4hpn94quAgAAiFiA=
Date: Sun, 20 Oct 2013 20:10:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4DDCB4@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in> <526437AF.1070002@alum.mit.edu>
In-Reply-To: <526437AF.1070002@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje4Vi5Qgg21PmCymLn/MYjH5Ux+r xYoNB1gdmD3+vv/A5LFkyU8mjw/zv7AHMEdx2aSk5mSWpRbp2yVwZUxeNImx4J5kRU/7MfYG xusiXYycHBICJhLPrzxnhLDFJC7cW8/WxcjFISRwlFHi4bMFUM4SRolrzWeYuhg5ONgELCS6 /2mDNIgIREj0fH3EChJmFlCXuLo4CCQsLOAl0TOzlwWixFvi//2rULaVxPKGo4wg5SwCqhLN V2NBwrwCvhLXN3UyQ2xqYZZY8OgaG0iCU0BH4sGPjewgNiPQbd9PrWECsZkFxCU+HLzODHGz gMSSPeehbFGJl4//sULYShKLbn+GqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlI WmYhaZmFpGUBI8sqRo7i1OKk3HQjg02MwLg5uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoExrc3r6uV/0v0b2c48yMy8fmDHap8+Wf7nOxtZl7lNm/Si o7zm1Ze3V1/z5MQs6jPw+VRhuvKh+PLkIyFZx35NY3YX31KeI2v9nDOyjcP5Ssup9M+88RlV Gq9c3jn0vTBfzsa0M9nvgllt9MOFz+V3zlL8Mj3WW/DsZqFc1fUr7BQD29MbJm9XYinOSDTU Yi4qTgQAARyC2mkCAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:11:08 -0000

>>> Maybe you are right. Then sip will go the way of h323 while the world=20
>>> moves on to webrtc.
>>
>> It is amazing to hear from you that h323 way of media negotiation is=20
>> better than SIP now :-)
>
> Even though you included a smiley, I think maybe you didn't understand ho=
w I meant that statement. I didn't intend to suggest that sip should adopt =
any new behavior from h323.

Throughout the years I think we have tried (and are still trying) very hard=
 to adopt H.245 features into SDP O/A...

Regards,

Christer








> Let us assume content-disposition "partial-session" for partial=20
> offer/answer exist. So, RFC 3264 does not applies for=20
> "partial-session". How the normal interaction and race condition=20
> between "session" and "partial-session" will be handled as both impact=20
> the same session in the media layer? Could you please explain.
>
> Thanks
> Partha
>
>
>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Paul Kyzivat
>> Sent: Saturday, October 19, 2013 2:24 AM
>> To: Christer Holmberg
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type=20
>> value
>>
>> On 10/18/13 4:44 PM, Christer Holmberg wrote:
>>> Hi,
>>>
>>>>> Content-Disposition does not apply to intermediaries. So, a proxy
>> that
>>>>> only understands application/sdp (e.g. for gate control purpose)
>> will
>>>>> not even look at the C-D header field value for other bodies. And,=20
>>>>> unless such proxy understands POF/PAN, there may not be any media=20
>>>>> passing through...
>>>>
>>>> Right. A middlebox that doesn't understand application/sdpfrag=20
>>>> won't
>> know to look at its contents and let the new streams through. And a=20
>> middlebox that sees
>>>> something marked as "application/sdp" that conveys only a tiny
>> fraction of the session will probably be just as catastrophic; I=20
>> would imagine everything but the
>>>> modified streams would be shut off. There's no way to win here.
>>>
>>> I think it would reject the Offer - at least that's what it should=20
>>> do
>> according to 3264.
>>
>> 3264 only talks about how to process offers and answers described in=20
>> SDP. It does not say how those are conveyed in sip. 3261 says that=20
>> they are carried in body parts of content-type application/sdp with=20
>> content-disposition of 'session'. If a body part has content-type=20
>> application/sdp but has a disposition other than 'session' then it=20
>> isn't an offer or answer according to 3261, and so 3264 doesn't=20
>> apply.
>>
>>>> At some point, we have to come to peace with the fact that any
>> middleboxes that aren't primarily in the business of stifling=20
>> progress will need to keep pace with protocol extensions as they get dep=
loyed.
>>>
>>> I really wish things worked that way :)
>>
>> So progress ends because middleboxes don't permit it?
>>
>> Maybe you are right. Then sip will go the way of h323 while the world=20
>> moves on to webrtc.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>


From emcho@sip-communicator.org  Sun Oct 20 13:19: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 5CF8F11E842B for ; Sun, 20 Oct 2013 13:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.705
X-Spam-Level: 
X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK3sY6UdPp1h for ; Sun, 20 Oct 2013 13:18:59 -0700 (PDT)
Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF4311E842E for ; Sun, 20 Oct 2013 13:18:58 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id rq2so6015672pbb.5 for ; Sun, 20 Oct 2013 13:18:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0EeHoopku3TU1Qq7Spxv/waLye+QvycIiix2z9furYk=; b=jYt6UuIPtab3xiOVDlTca3t5s8KUfG16USTEGlJsX4yc0sqOH8cBTgASvTiS3hxhCT zAE6UKgytAX2AJyjnTL5v+S98w0tFNdjwa675HgP6KnDRrIqdVaf6JPCFdyZgoNBlUDO d8kpk660MTfqDfldhvHAObajMSgc1wOtEsxAKCEYl9ZUNMgXWVoumjrgH2iOMTqtwOZD xnD7DooSY3IwoFWzjwKwRajq0ryi+SOcI3nDV+9Tj/gBo65IsDLR0hHLh0jxQOpUAWM4 PdoNwZaSEvVekhktMIThDsUzuXtVJvq7a4MAfTj2oZmHpFivRbJ+5OwQ7MKJYtMq8hXM POuA==
X-Gm-Message-State: ALoCoQlBQqIuTF7izNqep+5TjoeedWlrPB78bZT/u1L+yCzaTHi6gV8GqssMhQ6r1mdAFt1u7lyR
X-Received: by 10.66.170.168 with SMTP id an8mr14765116pac.58.1382300337655; Sun, 20 Oct 2013 13:18:57 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [2607:f8b0:400e:c03::233]) by mx.google.com with ESMTPSA id b3sm16238208pbu.38.2013.10.20.13.18.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 13:18:56 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id ld10so3853319pab.24 for ; Sun, 20 Oct 2013 13:18:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.233.135 with SMTP id tw7mr14119143pbc.112.1382300336164;  Sun, 20 Oct 2013 13:18:56 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 13:18:54 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 13:18:54 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>
Date: Sun, 20 Oct 2013 22:18:54 +0200
Message-ID: 
From: Emil Ivov 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b33da0a82af5a04e931e00d
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:19:04 -0000

--047d7b33da0a82af5a04e931e00d
Content-Type: text/plain; charset=ISO-8859-1

Christer, "I tried to explain" to you that what you are saying has been
addressed and cannot happen. If you believe that there is a specific
situation that is still possible and is a problem, then please describe
that rather than continuing to suggest that things don't work without any
valid arguments whatsoever.

--sent from my mobile
On 20 Oct 2013 21:50, "Christer Holmberg" 
wrote:

>
> Hi,
>
> >> Example:
> >>
> >> 1. Alice sends an SDP Offer to Bob.
> >>
> >> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.
> >>
> >> 3. After that, Bob sends, using trickle ICE, candidates D and E to
> Alice.
> >>
> >> If Alice receives the SDP Answer first, and then the trickle ICE
> request, she will assume that Bob first provided candidates A, B and C (in
> the SDP Answer), and then added D and E (in the trickle ICE request).
> >>
> >> If Alice receives the trickle ICE request first, and then the SDP Answer
> >
> > Don't do that then.
> >
> > It's been pretty clear from the start that any session *modification*
> mechanism that does not also contain the full session state completely
> falls apart in the face of unordered delivery. This is a fundamental
> information problem, and you aren't going to write rules that somehow cause
> it not to be true.
> >
> > We haven't yet tackled how to send trickle ICE in SIP, much less partial
> offers and partial answers. When we do, the only way it's going to have any
> chance of working at all is by requiring ordered delivery.
>
> I totally agree, and my opinion (which I tried to explain to Emil) is that
> it applies also to candidates.
>
> Regards,
>
> Christer
>

--047d7b33da0a82af5a04e931e00d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Christer, "I tried to explain" to you that what yo=
u are saying has been addressed and cannot happen. If you believe that ther=
e is a specific situation that is still possible and is a problem, then ple=
ase describe that rather than continuing to suggest that things don't w=
ork without any valid arguments whatsoever.



--sent from my mobile


On 20 Oct 2013 21:50, "Christer Holmberg&qu=
ot; <christer.holmberg=
@ericsson.com> wrote:



Hi,



>> Example:

>>

>> 1. Alice sends an SDP Offer to Bob.

>>=A0

>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.<=
br>
>>=A0

>> 3. After that, Bob sends, using trickle ICE, candidates D and E to=
 Alice.

>>=A0

>> If Alice receives the SDP Answer first, and then the trickle ICE r=
equest, she will assume that Bob first provided candidates A, B and C (in t=
he SDP Answer), and then added D and E (in the trickle ICE request).


>>=A0

>> If Alice receives the trickle ICE request first, and then the SDP =
Answer

>

> Don't do that then.

>

> It's been pretty clear from the start that any session *modificati=
on* mechanism that does not also contain the full session state completely =
falls apart in the face of unordered delivery. This is a fundamental inform=
ation problem, and you aren't going to write rules that somehow cause i=
t not to be true.


>

> We haven't yet tackled how to send trickle ICE in SIP, much less p=
artial offers and partial answers. When we do, the only way it's going =
to have any chance of working at all is by requiring ordered delivery.




I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.



Regards,



Christer




--047d7b33da0a82af5a04e931e00d--

From emcho@sip-communicator.org  Sun Oct 20 13: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 39D2D11E843B for ; Sun, 20 Oct 2013 13:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level: 
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiHfs1d1eAEN for ; Sun, 20 Oct 2013 13:23:31 -0700 (PDT)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83911E824F for ; Sun, 20 Oct 2013 13:23:31 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id y13so7316142pdi.40 for ; Sun, 20 Oct 2013 13:23:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yDX9T6WsGy2ZrpyXd8ta4XnKzO0nrvctrsApb04viAc=; b=TszTn7OEKxPaegARaL4ofgTuGt6XYGsYcfRQuZti1+KIDyLQPWmwQRsakKuFe20gWm ry/HWJyWTFFR/K4ga2dW227U3XbBvenG2ZZ5xxi0UY0HE9ly7TTGIEjGsGV/LiIvc8z8 0HzjU4sRvloEsJhTkdyg5jkmPQ+hfMhT1yJRIhO2fRPWwT1daCogriP7qz6otRIVP3bM injuugVqa4Ffy4z+DvWLR1PcNgJ1Tmfha7jstJMoeUi6zxu5deHC5yRLnhjAV+aAXxEp IzOWNzddroNh+0u+NSJiXiEHo3gU8EhDrRu0E9XGBX/HQ6xAp/DwhPN3JyrgtrNH0jZd AJhg==
X-Gm-Message-State: ALoCoQlAqVWqK9W7FN7l0mKh6ERjFu3qx4ZNyII2BHRiW45DVSYFWrEpLJz+ypYA0WMcG8+BUVYB
X-Received: by 10.66.154.1 with SMTP id vk1mr14649948pab.85.1382300610931; Sun, 20 Oct 2013 13:23:30 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [2607:f8b0:400e:c02::22f]) by mx.google.com with ESMTPSA id pu5sm20379011pac.21.2013.10.20.13.23.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 13:23:29 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id g10so5834346pdj.34 for ; Sun, 20 Oct 2013 13:23:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.219.167 with SMTP id pp7mr3379073pbc.125.1382300609750; Sun, 20 Oct 2013 13:23:29 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 13:23:29 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 13:23:29 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se> 
Date: Sun, 20 Oct 2013 22:23:29 +0200
Message-ID: 
From: Emil Ivov 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=e89a8f3b559cd144ae04e931f012
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:23:36 -0000

--e89a8f3b559cd144ae04e931f012
Content-Type: text/plain; charset=ISO-8859-1

One more thought:

Please understand that trickle ICE is NOT a session modification. Please
try to isolate the SDP syntax that it uses from general O/A. It is not part
of it.

Think of it as JSON if that would make thinks easier.

Emil

--sent from my mobile
On 20 Oct 2013 22:18, "Emil Ivov"  wrote:

> Christer, "I tried to explain" to you that what you are saying has been
> addressed and cannot happen. If you believe that there is a specific
> situation that is still possible and is a problem, then please describe
> that rather than continuing to suggest that things don't work without any
> valid arguments whatsoever.
>
> --sent from my mobile
> On 20 Oct 2013 21:50, "Christer Holmberg" 
> wrote:
>
>>
>> Hi,
>>
>> >> Example:
>> >>
>> >> 1. Alice sends an SDP Offer to Bob.
>> >>
>> >> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.
>> >>
>> >> 3. After that, Bob sends, using trickle ICE, candidates D and E to
>> Alice.
>> >>
>> >> If Alice receives the SDP Answer first, and then the trickle ICE
>> request, she will assume that Bob first provided candidates A, B and C (in
>> the SDP Answer), and then added D and E (in the trickle ICE request).
>> >>
>> >> If Alice receives the trickle ICE request first, and then the SDP
>> Answer
>> >
>> > Don't do that then.
>> >
>> > It's been pretty clear from the start that any session *modification*
>> mechanism that does not also contain the full session state completely
>> falls apart in the face of unordered delivery. This is a fundamental
>> information problem, and you aren't going to write rules that somehow cause
>> it not to be true.
>> >
>> > We haven't yet tackled how to send trickle ICE in SIP, much less
>> partial offers and partial answers. When we do, the only way it's going to
>> have any chance of working at all is by requiring ordered delivery.
>>
>> I totally agree, and my opinion (which I tried to explain to Emil) is
>> that it applies also to candidates.
>>
>> Regards,
>>
>> Christer
>>
>

--e89a8f3b559cd144ae04e931f012
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


One more thought:


Please understand that trickle ICE is NOT a session modifica=
tion. Please try to isolate the SDP syntax that it uses from general O/A. I=
t is not part of it.


Think of it as JSON if that would make thinks easier.


Emil


--sent from my mobile


On 20 Oct 2013 22:18, "Emil Ivov" <=
emcho@jitsi.org> wrote:


Christer, "I tried to explain" to you that what yo=
u are saying has been addressed and cannot happen. If you believe that ther=
e is a specific situation that is still possible and is a problem, then ple=
ase describe that rather than continuing to suggest that things don't w=
ork without any valid arguments whatsoever.




--sent from my mobile


On 20 Oct 2013 21:50, "Christer Holmberg&qu=
ot; <christer.holmberg@ericsson.com> wrote:




Hi,



>> Example:

>>

>> 1. Alice sends an SDP Offer to Bob.

>>=A0

>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.<=
br>
>>=A0

>> 3. After that, Bob sends, using trickle ICE, candidates D and E to=
 Alice.

>>=A0

>> If Alice receives the SDP Answer first, and then the trickle ICE r=
equest, she will assume that Bob first provided candidates A, B and C (in t=
he SDP Answer), and then added D and E (in the trickle ICE request).



>>=A0

>> If Alice receives the trickle ICE request first, and then the SDP =
Answer

>

> Don't do that then.

>

> It's been pretty clear from the start that any session *modificati=
on* mechanism that does not also contain the full session state completely =
falls apart in the face of unordered delivery. This is a fundamental inform=
ation problem, and you aren't going to write rules that somehow cause i=
t not to be true.



>

> We haven't yet tackled how to send trickle ICE in SIP, much less p=
artial offers and partial answers. When we do, the only way it's going =
to have any chance of working at all is by requiring ordered delivery.





I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.



Regards,



Christer






--e89a8f3b559cd144ae04e931f012--

From christer.holmberg@ericsson.com  Sun Oct 20 13:38: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 0222F11E8440 for ; Sun, 20 Oct 2013 13:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.665
X-Spam-Level: 
X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.583,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1APElOmXS955 for ; Sun, 20 Oct 2013 13:38:16 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9B49A11E8436 for ; Sun, 20 Oct 2013 13:38:15 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-3b-52643f33ab41
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5E.E7.03802.33F34625; Sun, 20 Oct 2013 22:38:12 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 22:38:11 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzcp+iLSYC/YIgkW4GBkoIrtjKJn9/Sjg///o7gCAAAFHgIAAI63Q
Date: Sun, 20 Oct 2013 20:38:10 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4DDD6F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4DDD6FESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja6JfUqQwYIbPBZ7/i5it1izcwKL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjJ5/H8T6DFr5xOWAJYoLpuU1JzMstQifbsErozTvaYF 870qNtxvZmlgXGPfxcjJISFgInFw0WZGCFtM4sK99WxdjFwcQgKHGSWOP/3BDuEsYZQ4uus4 SxcjBwebgIVE9z9tkAYRAXmJ7rZFTCA2s0CyxKnGj2CDhAUCJJbMfsIOUi4iEChxYZs+RLmb xMwzrawgYRYBVYmns4RAwrwCvhJ7D31khdi0g1Pi0lWQGzg5OIFaryy6CWYzAt32/dQaqFXi Eh8OXmeGuFlAYsme81C2qMTLx/9YIWwliUW3P0PV50vMXLeUCWKZoMTJmU9YJjCKzkIyahaS sllIyiDiehI3pk5hg7C1JZYtfA1Vrysx498hFmTxBYzsqxjZcxMzc9LLjTYxAqPu4JbfqjsY 75wTOcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGOvc1ad2f16Xcu/no 6uI0h7QjPN/kv6UFlj/xfjAxTebylf+RyiI6W56HP7MMCZ3KyvPkkk3V9fJOsb5lFYGuProl Mlu+v1H+edH9ofSW/8dySkoD2Fwr/tRPTtxpr7z6l65OrlzuEd2EZQxHPfva57H01sc+dGJK idePdyu0mHR10kWOmjIlluKMREMt5qLiRAB73OAjiAIAAA==
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:38:35 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4DDD6FESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Emil,

No matter whether you consider the ICE state (including the candidates) par=
t of the SDP session state or not, SDP session modification requests (read:=
 SDP Offers and Answers) DO impact the ICE State, as Offers and Answers can=
 be used to carry candidates.

Regards,

Christer

L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
L=E4hetetty: 20. lokakuuta 2013 23:23
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; Adam Roach; mmusic
Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


One more thought:

Please understand that trickle ICE is NOT a session modification. Please tr=
y to isolate the SDP syntax that it uses from general O/A. It is not part o=
f it.

Think of it as JSON if that would make thinks easier.

Emil

--sent from my mobile
On 20 Oct 2013 22:18, "Emil Ivov" >=
 wrote:

Christer, "I tried to explain" to you that what you are saying has been add=
ressed and cannot happen. If you believe that there is a specific situation=
 that is still possible and is a problem, then please describe that rather =
than continuing to suggest that things don't work without any valid argumen=
ts whatsoever.

--sent from my mobile
On 20 Oct 2013 21:50, "Christer Holmberg" > wrote:

Hi,

>> Example:
>>
>> 1. Alice sends an SDP Offer to Bob.
>>
>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.
>>
>> 3. After that, Bob sends, using trickle ICE, candidates D and E to Alice=
.
>>
>> If Alice receives the SDP Answer first, and then the trickle ICE request=
, she will assume that Bob first provided candidates A, B and C (in the SDP=
 Answer), and then added D and E (in the trickle ICE request).
>>
>> If Alice receives the trickle ICE request first, and then the SDP Answer
>
> Don't do that then.
>
> It's been pretty clear from the start that any session *modification* mec=
hanism that does not also contain the full session state completely falls a=
part in the face of unordered delivery. This is a fundamental information p=
roblem, and you aren't going to write rules that somehow cause it not to be=
 true.
>
> We haven't yet tackled how to send trickle ICE in SIP, much less partial =
offers and partial answers. When we do, the only way it's going to have any=
 chance of working at all is by requiring ordered delivery.

I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4DDD6FESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Emil,


 <=
/p>

No matter =
whether you consider the ICE state (including the candidates) part of the S=
DP session state or not, SDP session modification requests
 (read: SDP Offers and Answers) DO impact the ICE State, as Offers and Answ=
ers can be used to carry candidates.


 =
;


Regards,


 =
;


Christer


 =
;


L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]


L=E4hetetty: 20. lokakuuta 2013 23:23

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; Adam Roach; mmusic

Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME typ=
e value


 


One more thought:


Please understand that trickle ICE is NOT a session modification. Please=
 try to isolate the SDP syntax that it uses from general O/A. It is not par=
t of it.


Think of it as JSON if that would make thinks easier.


Emil


--sent from my mobile




On 20 Oct 2013 22:18, "Emil Ivov" <emcho@jitsi.org> wrote:

Christer, "I tried to explain" to you that what you are saying=
 has been addressed and cannot happen. If you believe that there is a speci=
fic situation that is still possible and is a problem, then please describe=
 that rather than continuing to suggest that
 things don't work without any valid arguments whatsoever.


--sent from my mobile




On 20 Oct 2013 21:50, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi,



>> Example:

>>

>> 1. Alice sends an SDP Offer to Bob.

>> 

>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.<=
br>
>> 

>> 3. After that, Bob sends, using trickle ICE, candidates D and E to=
 Alice.

>> 

>> If Alice receives the SDP Answer first, and then the trickle ICE r=
equest, she will assume that Bob first provided candidates A, B and C (in t=
he SDP Answer), and then added D and E (in the trickle ICE request).

>> 

>> If Alice receives the trickle ICE request first, and then the SDP =
Answer

>

> Don't do that then.

>

> It's been pretty clear from the start that any session *modification* =
mechanism that does not also contain the full session state completely fall=
s apart in the face of unordered delivery. This is a fundamental informatio=
n problem, and you aren't going to
 write rules that somehow cause it not to be true.

>

> We haven't yet tackled how to send trickle ICE in SIP, much less parti=
al offers and partial answers. When we do, the only way it's going to have =
any chance of working at all is by requiring ordered delivery.



I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.



Regards,



Christer










--_000_7594FB04B1934943A5C02806D1A2204B1C4DDD6FESESSMB209erics_--

From christer.holmberg@ericsson.com  Sun Oct 20 13:42: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 3EDF011E844C for ; Sun, 20 Oct 2013 13:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.849
X-Spam-Level: 
X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf3fK8gJUqov for ; Sun, 20 Oct 2013 13:42:15 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id AC9CE11E8278 for ; Sun, 20 Oct 2013 13:42:14 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-ac-526440257ea1
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 33.7F.25272.52044625; Sun, 20 Oct 2013 22:42:13 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 22:42:13 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzcp+iLSYC/YIgkW4GBkoIrtjKJn9/Sjg///o7gCAACb34A==
Date: Sun, 20 Oct 2013 20:42:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4DDD82@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4DDD82ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja6qQ0qQwdw7lhZ7/i5it1izcwKL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjJ5/H8T6DFr5xOWAJYoLpuU1JzMstQifbsEroy9PcoF B1wrPre9ZGxgfGTdxcjJISFgItGxZCMjhC0mceHeerYuRi4OIYGjjBKXuh6zQDhLGCWaPs5i 7mLk4GATsJDo/qcN0iAiIC/R3baICcRmFkiW+PnnOBuILSwQILFk9hN2kHIRgUCJC9v0Icqd JLZ0vAPbxSKgKvH2YgtYOa+Ar8SP03eZIVZ95JCY9bwfLMEJ1Pt01QkWEJsR6Ljvp9ZA7RKX +HDwOjPE0QISS/ach7JFJV4+/scKYStJLLr9Gao+X2L1u/+MEMsEJU7OfMIygVF0FpJRs5CU zUJSBhHXk7gxdQobhK0tsWzha6h6XYkZ/w6xIIsvYGRfxchRnFqclJtuZLCJERh5B7f8ttjB ePmvzSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwXt+W/Gf7MhbeBQqp Tj6Lb99cafNbcvWyi1+N7dWULJdOOpw34ZSU/7M3FteerV5n03Dx0hmD45+e78/fs3dd8oeP mokSuUl9EhpN7EVtkQGvrZ+8dH9ee67b6c0SvsSp/vU5sWfvS3Vc6t1aNPuElstE3uap6Qba Hw4kZ2buvaZ2OHFm9eyUa0osxRmJhlrMRcWJAKrCnCmKAgAA
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:42:22 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4DDD82ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Emil,

I am not suggesting that things don't work.

I am saying that we need to be very sure that there isn't a risk for ambigu=
ous situations, where different endpoints may end up having different "unde=
rstandings" of the ICE state.

Regards,

Christer

L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]
L=E4hetetty: 20. lokakuuta 2013 23:19
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic; Adam Roach
Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


Christer, "I tried to explain" to you that what you are saying has been add=
ressed and cannot happen. If you believe that there is a specific situation=
 that is still possible and is a problem, then please describe that rather =
than continuing to suggest that things don't work without any valid argumen=
ts whatsoever.

--sent from my mobile
On 20 Oct 2013 21:50, "Christer Holmberg" > wrote:

Hi,

>> Example:
>>
>> 1. Alice sends an SDP Offer to Bob.
>>
>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.
>>
>> 3. After that, Bob sends, using trickle ICE, candidates D and E to Alice=
.
>>
>> If Alice receives the SDP Answer first, and then the trickle ICE request=
, she will assume that Bob first provided candidates A, B and C (in the SDP=
 Answer), and then added D and E (in the trickle ICE request).
>>
>> If Alice receives the trickle ICE request first, and then the SDP Answer
>
> Don't do that then.
>
> It's been pretty clear from the start that any session *modification* mec=
hanism that does not also contain the full session state completely falls a=
part in the face of unordered delivery. This is a fundamental information p=
roblem, and you aren't going to write rules that somehow cause it not to be=
 true.
>
> We haven't yet tackled how to send trickle ICE in SIP, much less partial =
offers and partial answers. When we do, the only way it's going to have any=
 chance of working at all is by requiring ordered delivery.

I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4DDD82ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Emil,


 <=
/p>

I am not s=
uggesting that things don’t work.


 =
;


I am sayin=
g that we need to be very sure that there isn’t a risk for ambiguous =
situations, where different endpoints may end up having different
 “understandings” of the ICE state.


 =
;


Regards,


 =
;


Christer


 =
;


L=E4hett=E4j=E4: Emil Ivov [mailto:emcho@jitsi.org]


L=E4hetetty: 20. lokakuuta 2013 23:19

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; mmusic; Adam Roach

Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME typ=
e value


 


Christer, "I tried to explain" to you that what you are saying=
 has been addressed and cannot happen. If you believe that there is a speci=
fic situation that is still possible and is a problem, then please describe=
 that rather than continuing to suggest that
 things don't work without any valid arguments whatsoever.


--sent from my mobile




On 20 Oct 2013 21:50, "Christer Holmberg" =
<christer.holmberg@eri=
csson.com> wrote:




Hi,



>> Example:

>>

>> 1. Alice sends an SDP Offer to Bob.

>> 

>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.<=
br>
>> 

>> 3. After that, Bob sends, using trickle ICE, candidates D and E to=
 Alice.

>> 

>> If Alice receives the SDP Answer first, and then the trickle ICE r=
equest, she will assume that Bob first provided candidates A, B and C (in t=
he SDP Answer), and then added D and E (in the trickle ICE request).

>> 

>> If Alice receives the trickle ICE request first, and then the SDP =
Answer

>

> Don't do that then.

>

> It's been pretty clear from the start that any session *modification* =
mechanism that does not also contain the full session state completely fall=
s apart in the face of unordered delivery. This is a fundamental informatio=
n problem, and you aren't going to
 write rules that somehow cause it not to be true.

>

> We haven't yet tackled how to send trickle ICE in SIP, much less parti=
al offers and partial answers. When we do, the only way it's going to have =
any chance of working at all is by requiring ordered delivery.



I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.



Regards,



Christer








--_000_7594FB04B1934943A5C02806D1A2204B1C4DDD82ESESSMB209erics_--

From pkyzivat@alum.mit.edu  Sun Oct 20 13:55: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 219C211E828C for ; Sun, 20 Oct 2013 13:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level: 
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGmL3kZaaHHE for ; Sun, 20 Oct 2013 13:55:32 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 9056811E843C for ; Sun, 20 Oct 2013 13:55:31 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id fYCV1m00317dt5G5AYvW5G; Sun, 20 Oct 2013 20:55:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id fYvW1m00M3ZTu2S3ZYvW3B; Sun, 20 Oct 2013 20:55:30 +0000
Message-ID: <52644342.2040605@alum.mit.edu>
Date: Sun, 20 Oct 2013 16:55:30 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Emil Ivov 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>  
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=1382302531; bh=GInpQehSoJjBKgiFtYIHPLVycvftvg+xk/2AKRlKmaM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=L8fD5vpiJ9/zPxgF/Ws4sBUU6cSdFvq8kp0pk4cTAcFOkP1KuPOS/MO6B2UP7E+Br WFTy4Lk3V+6jTZKJYBpT/cKDh9khvx93GFxOTR/T3vDLAW5jZVMswhFL0VTClZk8UD rustUwv7UQidK1OxjDu5v6RTo04Ck4KYec20VKHV0bqn3fRyIdSZ+owGIe1uvxgGB2 x8i6mn3wu0yuhPTI1zdyCACa45cthALguPhH8gxc78iAdNru0v3z30iGH0mJtqvFPq iUwtk8hxz8cZdYxjSGuZ9EjzqFBZDa/4ydBR/c5MHel7n4+ZwPHDYDb/1sRRL6odNu F/1YquHprmi1g==
Cc: mmusic , Christer Holmberg 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 20:55:44 -0000

On 10/20/13 4:23 PM, Emil Ivov wrote:
> One more thought:
>
> Please understand that trickle ICE is NOT a session modification.

Isn't the session modified as a result of the trickle ICE? (E.g., end up 
using a different media address than it otherwise would have.)

And the use of trickle ICE can (I think) require that a subsequent offer 
be sent (or answered) differently than it would had trickle ice not been 
used.

And AFAIK everything that can be accomplished with trickle ICE could 
also be accomplished with Partial Offer/Answer. So the differences 
aren't functional ones. I presume that trickle ICE is expected to be 
faster, and/or easier to implement. (But easier to implement becomes 
moot if both need to be implemented.)

In my book those justify considering it a session modification.

	Thanks,
	Paul

> Please
> try to isolate the SDP syntax that it uses from general O/A. It is not
> part of it.
>
> Think of it as JSON if that would make thinks easier.
>
> Emil
>
> --sent from my mobile
>
> On 20 Oct 2013 22:18, "Emil Ivov"  > wrote:
>
>     Christer, "I tried to explain" to you that what you are saying has
>     been addressed and cannot happen. If you believe that there is a
>     specific situation that is still possible and is a problem, then
>     please describe that rather than continuing to suggest that things
>     don't work without any valid arguments whatsoever.
>
>     --sent from my mobile
>
>     On 20 Oct 2013 21:50, "Christer Holmberg"
>          > wrote:
>
>
>         Hi,
>
>          >> Example:
>          >>
>          >> 1. Alice sends an SDP Offer to Bob.
>          >>
>          >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>         and C.
>          >>
>          >> 3. After that, Bob sends, using trickle ICE, candidates D
>         and E to Alice.
>          >>
>          >> If Alice receives the SDP Answer first, and then the trickle
>         ICE request, she will assume that Bob first provided candidates
>         A, B and C (in the SDP Answer), and then added D and E (in the
>         trickle ICE request).
>          >>
>          >> If Alice receives the trickle ICE request first, and then
>         the SDP Answer
>          >
>          > Don't do that then.
>          >
>          > It's been pretty clear from the start that any session
>         *modification* mechanism that does not also contain the full
>         session state completely falls apart in the face of unordered
>         delivery. This is a fundamental information problem, and you
>         aren't going to write rules that somehow cause it not to be true.
>          >
>          > We haven't yet tackled how to send trickle ICE in SIP, much
>         less partial offers and partial answers. When we do, the only
>         way it's going to have any chance of working at all is by
>         requiring ordered delivery.
>
>         I totally agree, and my opinion (which I tried to explain to
>         Emil) is that it applies also to candidates.
>
>         Regards,
>
>         Christer
>


From emcho@sip-communicator.org  Sun Oct 20 14:18: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 3FBCB11E844C for ; Sun, 20 Oct 2013 14:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.708
X-Spam-Level: 
X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=0.268,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qixqeYmwpE3Q for ; Sun, 20 Oct 2013 14:18:00 -0700 (PDT)
Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1904A11E8244 for ; Sun, 20 Oct 2013 14:17:59 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up15so6053291pbc.26 for ; Sun, 20 Oct 2013 14:17:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vHaA8GmIP0vwB2jWUGwzWs/SpFYylYF/7wH6V4xj/oU=; b=WGGAGrpHRygGrBXH6gAyQT7QkR0L2gWYQ3GNP7ixbVW4+GxMe61StUzkd/gkoycOMp q9pq54pzC61ipqdp7Y/xLXgUJvr5BPOtqoHiYz/dPv9E9fDfcHfZa0Wv/3p9CBtKASBk ORC+8CmhiMnyFxGVHwih4ZeZ1ujgSzqVt4m2Du35PGEBcvsXKIW4ByG/fURzDWtTS6SF awwhv0w3NcUCl38I/Hlrz2pR091HKAY3ey/zU48i6vQda6/HhikEuzgceLE6q1cMIuF2 1xsy65oKm6ly0AaL6OdLRJu7b2FUcdIKPMziw7QSKiVqzTwxRjPN7KM2zMNNn/rLjDtj Qb9Q==
X-Gm-Message-State: ALoCoQkFFjrD7ePC7k6ZV0Lh0j9QuK0MLuQBDMue5gPuhZAieoZjweEreGb7noCgueQiKnLHFwUq
X-Received: by 10.68.204.5 with SMTP id ku5mr14446791pbc.88.1382303879541; Sun, 20 Oct 2013 14:17:59 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [2607:f8b0:400e:c03::231]) by mx.google.com with ESMTPSA id iu7sm16389122pbc.45.2013.10.20.14.17.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 14:17:58 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id lj1so5654389pab.36 for ; Sun, 20 Oct 2013 14:17:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.197.129 with SMTP id iu1mr37047pbc.139.1382303877939; Sun, 20 Oct 2013 14:17:57 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 14:17:57 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 14:17:57 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4DDD6F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <5261AAF0.3030509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C34F9@ESESSMB209.ericsson.se>  <5261C314.8020001@alum.mit.edu>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>   <7594FB04B1934943A5C02806D1A2204B1C4DDD6F@ESESSMB209.ericsson.se>
Date: Sun, 20 Oct 2013 23:17:57 +0200
Message-ID: 
From: Emil Ivov 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=e89a8ff1cce49ddf5e04e932b30c
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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, 20 Oct 2013 21:18:05 -0000

--e89a8ff1cce49ddf5e04e932b30c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, they do have an impact. They reset it. Please describe a scenario
where you think this is a problem.

--sent from my mobile
On 20 Oct 2013 22:38, "Christer Holmberg" 
wrote:

>  Hi Emil,****
>
> ** **
>
> No matter whether you consider the ICE state (including the candidates)
> part of the SDP session state or not, SDP session modification requests
> (read: SDP Offers and Answers) DO impact the ICE State, as Offers and
> Answers can be used to carry candidates.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *L=E4hett=E4j=E4:* Emil Ivov [mailto:emcho@jitsi.org]
> *L=E4hetetty:* 20. lokakuuta 2013 23:23
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Paul Kyzivat; Adam Roach; mmusic
> *Aihe:* Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value****
>
> ** **
>
> One more thought:****
>
> Please understand that trickle ICE is NOT a session modification. Please
> try to isolate the SDP syntax that it uses from general O/A. It is not pa=
rt
> of it.****
>
> Think of it as JSON if that would make thinks easier.****
>
> Emil****
>
> --sent from my mobile****
>
> On 20 Oct 2013 22:18, "Emil Ivov"  wrote:****
>
> Christer, "I tried to explain" to you that what you are saying has been
> addressed and cannot happen. If you believe that there is a specific
> situation that is still possible and is a problem, then please describe
> that rather than continuing to suggest that things don't work without any
> valid arguments whatsoever.****
>
> --sent from my mobile****
>
> On 20 Oct 2013 21:50, "Christer Holmberg" 
> wrote:****
>
>
> Hi,
>
> >> Example:
> >>
> >> 1. Alice sends an SDP Offer to Bob.
> >>
> >> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.
> >>
> >> 3. After that, Bob sends, using trickle ICE, candidates D and E to
> Alice.
> >>
> >> If Alice receives the SDP Answer first, and then the trickle ICE
> request, she will assume that Bob first provided candidates A, B and C (i=
n
> the SDP Answer), and then added D and E (in the trickle ICE request).
> >>
> >> If Alice receives the trickle ICE request first, and then the SDP Answ=
er
> >
> > Don't do that then.
> >
> > It's been pretty clear from the start that any session *modification*
> mechanism that does not also contain the full session state completely
> falls apart in the face of unordered delivery. This is a fundamental
> information problem, and you aren't going to write rules that somehow cau=
se
> it not to be true.
> >
> > We haven't yet tackled how to send trickle ICE in SIP, much less partia=
l
> offers and partial answers. When we do, the only way it's going to have a=
ny
> chance of working at all is by requiring ordered delivery.
>
> I totally agree, and my opinion (which I tried to explain to Emil) is tha=
t
> it applies also to candidates.
>
> Regards,
>
> Christer****
>

--e89a8ff1cce49ddf5e04e932b30c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Yes, they do have an impact. They reset it. Please describe =
a scenario where you think this is a problem. 


--sent from my mobile


On 20 Oct 2013 22:38, "Christer Holmberg&qu=
ot; <christer.holmberg=
@ericsson.com> wrote:












Hi Emil,


=A0<=
/p>

No matter =
whether you consider the ICE state (including the candidates) part of the S=
DP session state or not, SDP session modification requests
 (read: SDP Offers and Answers) DO impact the ICE State, as Offers and Answ=
ers can be used to carry candidates.


=A0=



Regards,


=A0=



Christer


=A0=



L=E4hett=E4j=E4: Emil Ivov [mailto:e=
mcho@jitsi.org]


L=E4hetetty: 20. lokakuuta 2013 23:23

Vastaanottaja: Christer Holmberg

Kopio: Paul Kyzivat; Adam Roach; mmusic

Aihe: Re: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME typ=
e value


=A0


One more thought:


Please understand that trickle ICE is NOT a session modification. Please=
 try to isolate the SDP syntax that it uses from general O/A. It is not par=
t of it.


Think of it as JSON if that would make thinks easier.


Emil


--sent from my mobile




On 20 Oct 2013 22:18, "Emil Ivov" <emcho@jitsi.org> wr=
ote:


Christer, "I tried to explain" to you that what you are saying=
 has been addressed and cannot happen. If you believe that there is a speci=
fic situation that is still possible and is a problem, then please describe=
 that rather than continuing to suggest that
 things don't work without any valid arguments whatsoever.


--sent from my mobile




On 20 Oct 2013 21:50, "Christer Holmberg" =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi,



>> Example:

>>

>> 1. Alice sends an SDP Offer to Bob.

>>=A0

>> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.<=
br>
>>=A0

>> 3. After that, Bob sends, using trickle ICE, candidates D and E to=
 Alice.

>>=A0

>> If Alice receives the SDP Answer first, and then the trickle ICE r=
equest, she will assume that Bob first provided candidates A, B and C (in t=
he SDP Answer), and then added D and E (in the trickle ICE request).


>>=A0

>> If Alice receives the trickle ICE request first, and then the SDP =
Answer

>

> Don't do that then.

>

> It's been pretty clear from the start that any session *modificati=
on* mechanism that does not also contain the full session state completely =
falls apart in the face of unordered delivery. This is a fundamental inform=
ation problem, and you aren't going to
 write rules that somehow cause it not to be true.

>

> We haven't yet tackled how to send trickle ICE in SIP, much less p=
artial offers and partial answers. When we do, the only way it's going =
to have any chance of working at all is by requiring ordered delivery.




I totally agree, and my opinion (which I tried to explain to Emil) is that =
it applies also to candidates.



Regards,



Christer













--e89a8ff1cce49ddf5e04e932b30c--

From emcho@sip-communicator.org  Sun Oct 20 18:04: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 BE72911E82F9 for ; Sun, 20 Oct 2013 18:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.723
X-Spam-Level: 
X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=0.254,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yydmzDVc716s for ; Sun, 20 Oct 2013 18:04:05 -0700 (PDT)
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6711E82F0 for ; Sun, 20 Oct 2013 18:04:05 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id kx10so7233095pab.15 for ; Sun, 20 Oct 2013 18:04:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u5zWnBzHiqgN6Mdn6lp3eNRx6hSdv3BdvYaDkq7XJhc=; b=Ei7le7bp5Nc2o24Bo2CcdZfZx/T4RwQplv7M40kBRNjgst13bsi/xKrrGGDV5OmbnW LMFDFHfOercSbWEsc2xR3JjYR6Zg+RDDEdI/4Y4qValdgAdPlHwx8yVdwX7VryElqV6N HJDn5VYUsi+T8/yh09+D3LXyr+K7GmkdufPstXWiZpyppVK7EwR3F0te1zgK0Ehb0N5r /jMKbt9+9z8bECJUErKZMXYQU39TDu9/st9/qdVN2kybuvLe+1FVfFeAgqyqV9T/O8D2 Shtfe8onQ1iqETe+Bfduew/Ikco1LlF7xMYQV6bUcRuR5hFgnWXmVTZ7mEdXGlg0+rbg Zb6g==
X-Gm-Message-State: ALoCoQkbYJhQEz8heYqRuB75zlu8EESE0RPA1TMeNHg2CLJngjVCRxMMzREhEu8wUkkWKmb1Y029
X-Received: by 10.66.178.143 with SMTP id cy15mr15592017pac.105.1382317444913;  Sun, 20 Oct 2013 18:04:04 -0700 (PDT)
Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [2607:f8b0:400e:c01::229]) by mx.google.com with ESMTPSA id iu7sm17050966pbc.45.2013.10.20.18.04.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 18:04:04 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp16so6270398pbb.28 for ; Sun, 20 Oct 2013 18:04:04 -0700 (PDT)
X-Received: by 10.68.6.138 with SMTP id b10mr188649pba.149.1382317444327; Sun, 20 Oct 2013 18:04:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Sun, 20 Oct 2013 18:03:44 -0700 (PDT)
In-Reply-To: <52644342.2040605@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>   <52644342.2040605@alum.mit.edu>
From: Emil Ivov 
Date: Mon, 21 Oct 2013 03:03:44 +0200
Message-ID: 
To: Paul Kyzivat 
Content-Type: text/plain; charset=ISO-8859-1
Cc: mmusic , Christer Holmberg 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 01:04:09 -0000

On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat  wrote:
> On 10/20/13 4:23 PM, Emil Ivov wrote:
>>
>> One more thought:
>>
>> Please understand that trickle ICE is NOT a session modification.
>
>
> Isn't the session modified as a result of the trickle ICE? (E.g., end up
> using a different media address than it otherwise would have.)
>
> And the use of trickle ICE can (I think) require that a subsequent offer be
> sent (or answered) differently than it would had trickle ice not been used.

The above statements are also true for vanilla ICE and peer reflexive
candidates, where ICE processing not reflected in SDP can already lead
to potential changes of addresses. If the change occurs, then an O/A
would follow. Currently Trickle ICE works along these exact same
lines.

> And AFAIK everything that can be accomplished with trickle ICE could also be
> accomplished with Partial Offer/Answer.

I already agreed that it is implementable ... the point is that it
would be *incredibly inconvenient*. I already gave a few reasons
earlier in this thread, let's try again:

* there would be an extremely high glare probability (which is
perfectly avoidable without O/A), * there would be a lot of added
complexity. Imagine POFs / PANs that send additional candidates *and*
change codecs and/or add/remove streams.
*  it would be very clumsy: after trickling candidates with a POF,
agents would block and wait for a PAN before they can do it again
* POF/PAN would be a dependency for trickle and there is no reason for it to be.
* In Berlin we agreed that we are adopting Unified for WebRTC cases.
There are Plan B and No Plan style implementations out there and my
understanding is that they have not been outlawed. Such
implementations would be unlikely to adopt POF/PAN. Yet, it would be
great if we made it possible for them to still use Trickle ICE.

The disadvantages aside:

Why would we want to do it this way?
What would we hope to gain?

> So the differences aren't functional
> ones.
> I presume that trickle ICE is expected to be faster, and/or easier to
> implement. (But easier to implement becomes moot if both need to be
> implemented.)

I can promise you that it doesn't. You don't have to take my word for
it. Just try and implement it.

> In my book those justify considering it a session modification.

Let's not take things out of context. Christer's point was that
because it is a session modification, it has to be done in
Offer/Answer.

This is wrong.

You can consider it a session modification if you like but it is not
the kind that requires Offer/Answer. Vanilla ICE proves this.

Emil






>         Thanks,
>         Paul
>
>> Please
>> try to isolate the SDP syntax that it uses from general O/A. It is not
>> part of it.
>>
>> Think of it as JSON if that would make thinks easier.
>>
>> Emil
>>
>> --sent from my mobile
>>
>> On 20 Oct 2013 22:18, "Emil Ivov" > > wrote:
>>
>>     Christer, "I tried to explain" to you that what you are saying has
>>     been addressed and cannot happen. If you believe that there is a
>>     specific situation that is still possible and is a problem, then
>>     please describe that rather than continuing to suggest that things
>>     don't work without any valid arguments whatsoever.
>>
>>     --sent from my mobile
>>
>>     On 20 Oct 2013 21:50, "Christer Holmberg"
>>     >     > wrote:
>>
>>
>>         Hi,
>>
>>          >> Example:
>>          >>
>>          >> 1. Alice sends an SDP Offer to Bob.
>>          >>
>>          >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>>         and C.
>>          >>
>>          >> 3. After that, Bob sends, using trickle ICE, candidates D
>>         and E to Alice.
>>          >>
>>          >> If Alice receives the SDP Answer first, and then the trickle
>>         ICE request, she will assume that Bob first provided candidates
>>         A, B and C (in the SDP Answer), and then added D and E (in the
>>         trickle ICE request).
>>          >>
>>          >> If Alice receives the trickle ICE request first, and then
>>         the SDP Answer
>>          >
>>          > Don't do that then.
>>          >
>>          > It's been pretty clear from the start that any session
>>         *modification* mechanism that does not also contain the full
>>         session state completely falls apart in the face of unordered
>>         delivery. This is a fundamental information problem, and you
>>         aren't going to write rules that somehow cause it not to be true.
>>          >
>>          > We haven't yet tackled how to send trickle ICE in SIP, much
>>         less partial offers and partial answers. When we do, the only
>>         way it's going to have any chance of working at all is by
>>         requiring ordered delivery.
>>
>>         I totally agree, and my opinion (which I tried to explain to
>>         Emil) is that it applies also to candidates.
>>
>>         Regards,
>>
>>         Christer
>>
>



-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From suhasietf@gmail.com  Sun Oct 20 21:15:50 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 1D23611E8132; Sun, 20 Oct 2013 21:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.179
X-Spam-Level: 
X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXRGX3ZZ3Qrq; Sun, 20 Oct 2013 21:15:49 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5611E8331; Sun, 20 Oct 2013 21:15:46 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id w61so6117884wes.10 for ; Sun, 20 Oct 2013 21:15:45 -0700 (PDT)
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 :content-type; bh=J7rAvLJWqb947tjl/QGXz7PnLpQC4g+F4JNkzPbGChg=; b=EVcW5sUI3KBx702zXL41x4AtP2F0fXA2M0XuvwEKL4p2E+6H92orXR4uplPHopqVlV lggY5Oghk+BVBe9DLsgIC7zBNug6QEL252kn1X5jyP3ePEcFJ2bEosy0kbVLynEumxQL F3JLE13P9NNxOGpqTXxkI3ryipY1zG/AdpjKvT9SJrHrPAAIS6KFX6kZEiQmcKb5zIH8 wvjDZShJvVnV8fsGdHCf7V9eh83ZVb9Y8B3arXXq3exW8KL/EC58NOXReH1D4n3xeajI A1QNeURBb7r6/VktpsQBlLra9QpLzVMcms6OQ5TlD+9iK01E829GlWFumsXy7Z1zyrDI DiFA==
MIME-Version: 1.0
X-Received: by 10.180.182.82 with SMTP id ec18mr8020801wic.13.1382328945431; Sun, 20 Oct 2013 21:15:45 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Sun, 20 Oct 2013 21:15:45 -0700 (PDT)
In-Reply-To: <20131021041042.22714.10689.idtracker@ietfa.amsl.com>
References: <20131021041042.22714.10689.idtracker@ietfa.amsl.com>
Date: Sun, 20 Oct 2013 21:15:45 -0700
Message-ID: 
From: Suhas Nandakumar 
To: mmusic WG , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b6250b8c1593a04e938896d
Subject: [MMUSIC] Fwd: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-05.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 Oct 2013 04:15:50 -0000

--047d7b6250b8c1593a04e938896d
Content-Type: text/plain; charset=ISO-8859-1

Hello All

  Sorry for cross-posting. A new version
of draft-nandakumar-mmusic-sdp-mux-attributes has been submitted.

By this version have analyzed over 80% of sections by various experts. A
Big Thanks to every one who has been helping improve this document every
time.

I have also listed few OPEN ISSUES that needs to be discussed and I request
everyone to go over them and provide their valuable insights.

I plan to send follow up emails on these issues in the coming weeks.

Cheers
Suhas

---------- Forwarded message ----------
From: 
Date: Sun, Oct 20, 2013 at 9:10 PM
Subject: New Version Notification for
draft-nandakumar-mmusic-sdp-mux-attributes-05.txt
To: Suhas Nandakumar , Suhas Nandakumar <
snandaku@cisco.com>



A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-05.txt
has been successfully submitted by Suhas Nandakumar and posted to the
IETF repository.

Filename:        draft-nandakumar-mmusic-sdp-mux-attributes
Revision:        05
Title:           A Framework for SDP Attributes when Multiplexing
Creation date:   2013-10-18
Group:           Individual Submission
Number of pages: 57
URL:
http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-sdp-mux-attributes-05.txt
Status:
http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes
Htmlized:
http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-05
Diff:
http://www.ietf.org/rfcdiff?url2=draft-nandakumar-mmusic-sdp-mux-attributes-05

Abstract:
   The Session Description Protocol (SDP) provides mechanisms to
   describe attributes of multimedia sessions and of individual media
   streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
   multimedia session.  In the RTCWeb WG, there is a need to use a
   single 5-tuple for sending and receiving media associated with
   multiple media descriptions ("m=" lines).  Such a requirement has
   raised concerns over the semantic implications of the SDP attributes
   associated with the RTP Sessions multiplexed over a single transport
   layer flow.

   The scope of this specification is to provide a framework for
   analyzing the multiplexing characteristics of SDP attributes.  The
   specification also categorizes existing attributes based on the
   framework described herein.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--047d7b6250b8c1593a04e938896d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello All

=A0 Sorry for cross-posting. =
A new version of=A0draft-nandakumar-mmusic-sdp-mux-attributes has been subm=
itted.=A0

By this version have analyzed over 80% o=
f sections by various experts. A Big Thanks to every one who has been helpi=
ng improve this document every time.=A0



I have also listed few OPEN ISSUES that needs to be dis=
cussed and I request everyone to go over them and provide their valuable in=
sights.

I plan to send follow up emails on these i=
ssues in the coming weeks.



Cheers
Suhas

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>

Date: Sun, Oct 20, 2013 at 9:10 PM
Subject: New Version Notification for=
 draft-nandakumar-mmusic-sdp-mux-attributes-05.txt
To: Suhas Nandakumar =
<suhasietf@gmail.com>, Suh=
as Nandakumar <snandaku@cisco.com<=
/a>>





A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-05.txt

has been successfully submitted by Suhas Nandakumar and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-nandakumar-mmusic-sdp-mux-attributes

Revision: =A0 =A0 =A0 =A005

Title: =A0 =A0 =A0 =A0 =A0 A Framework for SDP Attributes when Multiplexing=


Creation date: =A0 2013-10-18

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 57

URL: =A0 =A0 =A0 =A0 =A0 =A0 http:=
//www.ietf.org/internet-drafts/draft-nandakumar-mmusic-sdp-mux-attributes-0=
5.txt


Status: =A0 =A0 =A0 =A0 =A0http://datatracker=
.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/=
html/draft-nandakumar-mmusic-sdp-mux-attributes-05

Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www=
.ietf.org/rfcdiff?url2=3Ddraft-nandakumar-mmusic-sdp-mux-attributes-05<=
br>


Abstract:

=A0 =A0The Session Description Protocol (SDP) provides mechanisms to

=A0 =A0describe attributes of multimedia sessions and of individual media
=A0 =A0streams (e.g., Real-time Transport Protocol (RTP) sessions) within a=


=A0 =A0multimedia session. =A0In the RTCWeb WG, there is a need to use a
=A0 =A0single 5-tuple for sending and receiving media associated with

=A0 =A0multiple media descriptions ("m=3D" lines). =A0Such a requ=
irement has

=A0 =A0raised concerns over the semantic implications of the SDP attributes=


=A0 =A0associated with the RTP Sessions multiplexed over a single transport=


=A0 =A0layer flow.



=A0 =A0The scope of this specification is to provide a framework for

=A0 =A0analyzing the multiplexing characteristics of SDP attributes. =A0The=


=A0 =A0specification also categorizes existing attributes based on the

=A0 =A0framework described herein.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







--047d7b6250b8c1593a04e938896d--

From christer.holmberg@ericsson.com  Sun Oct 20 22:32: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 498D311E84AD for ; Sun, 20 Oct 2013 22:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.83
X-Spam-Level: 
X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-1.231,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbujGdjcVGDm for ; Sun, 20 Oct 2013 22:32:48 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A4E1111E84A3 for ; Sun, 20 Oct 2013 22:32:37 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-8a-5264bc73c3dd
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 73.AB.25272.37CB4625; Mon, 21 Oct 2013 07:32:36 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 07:32:35 +0200
From: Christer Holmberg 
To: Emil Ivov , Paul Kyzivat 
Thread-Topic: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzcp+iLSYC/YIgkW4GBkoIrtjKJn9/Sjg///o7gCAAAFHgIAACPIAgABFWwCAAGyk5Q==
Date: Mon, 21 Oct 2013 05:32:34 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>      <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>   <52644342.2040605@alum.mit.edu>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW7JnpQgg/U3ZSz2/F3EbrFm5wQW i6nLH7NYrNhwgNWBxePv+w9MHkuW/GTy+P8m0GPWzicsASxRXDYpqTmZZalF+nYJXBnn765k K7isX9F66iVTA+NtpS5GTg4JAROJPY3TWCFsMYkL99azdTFycQgJHGWUaL+6lQnCWcIosba7 h7mLkYODTcBCovufNkiDiICrxOMbr9hAbGYBa4mFV6YwgtjCAgES/48/AisXEQiUuLBNH6I8 TGLNlsXsIDaLgKrEpmnNTCA2r4CbxMsFL6BWXeCQeP96FdgcTqDeIztWgzUwAh33/dQaJohd 4hK3nsxngjhaQGLJnvPMELaoxMvH/1ghavQkbkydAnWbtsSyha+ZIZYJSpyc+YRlAqPoLCSj ZiFpmYWkZRaSlgWMLKsYOYpTi5Ny040MNjECY+bglt8WOxgv/7U5xCjNwaIkzvvxrXOQkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbe836P90xVN9m7g/tDUvF7DW03jc9XFR0C3FdUMDaE 11y92njp0uY25QLLGQnRc/9XaZdovTUQWqS2V6Plgm3KzHksytJhRYr9b//Pnc7m/T128hxP odQ84YhLMQtKdCYmv+SdV36yRl35UdrK2N83FfjEo54pb95z51GGwNudsms2CYolr1JiKc5I NNRiLipOBAClLzASZwIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 05:32:57 -0000

Hi Emil,

I am not saying that trickle ICE has to be done using O/A. In Berlin I agre=
ed that e.g. INFO seems to be a feasible mechanism.

What I am saying is that O/A also impact the ICE state, including candidate=
s that you have trickeled using a non-O/A mechanism.

And, similar to POF/PAN, also for trickle ICE we need to describe the usage=
 with BUNDLE, e.g. whether a trickled candidate applies (I assume it does) =
to all m- lines within a BUNDLE group, etc.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov  wrote:


On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat  wrot=
e:
> On 10/20/13 4:23 PM, Emil Ivov wrote:
>>
>> One more thought:
>>
>> Please understand that trickle ICE is NOT a session modification.
>
>
> Isn't the session modified as a result of the trickle ICE? (E.g., end up
> using a different media address than it otherwise would have.)
>
> And the use of trickle ICE can (I think) require that a subsequent offer =
be
> sent (or answered) differently than it would had trickle ice not been use=
d.

The above statements are also true for vanilla ICE and peer reflexive
candidates, where ICE processing not reflected in SDP can already lead
to potential changes of addresses. If the change occurs, then an O/A
would follow. Currently Trickle ICE works along these exact same
lines.

> And AFAIK everything that can be accomplished with trickle ICE could also=
 be
> accomplished with Partial Offer/Answer.

I already agreed that it is implementable ... the point is that it
would be *incredibly inconvenient*. I already gave a few reasons
earlier in this thread, let's try again:

* there would be an extremely high glare probability (which is
perfectly avoidable without O/A), * there would be a lot of added
complexity. Imagine POFs / PANs that send additional candidates *and*
change codecs and/or add/remove streams.
*  it would be very clumsy: after trickling candidates with a POF,
agents would block and wait for a PAN before they can do it again
* POF/PAN would be a dependency for trickle and there is no reason for it t=
o be.
* In Berlin we agreed that we are adopting Unified for WebRTC cases.
There are Plan B and No Plan style implementations out there and my
understanding is that they have not been outlawed. Such
implementations would be unlikely to adopt POF/PAN. Yet, it would be
great if we made it possible for them to still use Trickle ICE.

The disadvantages aside:

Why would we want to do it this way?
What would we hope to gain?

> So the differences aren't functional
> ones.
> I presume that trickle ICE is expected to be faster, and/or easier to
> implement. (But easier to implement becomes moot if both need to be
> implemented.)

I can promise you that it doesn't. You don't have to take my word for
it. Just try and implement it.

> In my book those justify considering it a session modification.

Let's not take things out of context. Christer's point was that
because it is a session modification, it has to be done in
Offer/Answer.

This is wrong.

You can consider it a session modification if you like but it is not
the kind that requires Offer/Answer. Vanilla ICE proves this.

Emil






>         Thanks,
>         Paul
>
>> Please
>> try to isolate the SDP syntax that it uses from general O/A. It is not
>> part of it.
>>
>> Think of it as JSON if that would make thinks easier.
>>
>> Emil
>>
>> --sent from my mobile
>>
>> On 20 Oct 2013 22:18, "Emil Ivov" > > wrote:
>>
>>     Christer, "I tried to explain" to you that what you are saying has
>>     been addressed and cannot happen. If you believe that there is a
>>     specific situation that is still possible and is a problem, then
>>     please describe that rather than continuing to suggest that things
>>     don't work without any valid arguments whatsoever.
>>
>>     --sent from my mobile
>>
>>     On 20 Oct 2013 21:50, "Christer Holmberg"
>>     >     > wrote:
>>
>>
>>         Hi,
>>
>>          >> Example:
>>          >>
>>          >> 1. Alice sends an SDP Offer to Bob.
>>          >>
>>          >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>>         and C.
>>          >>
>>          >> 3. After that, Bob sends, using trickle ICE, candidates D
>>         and E to Alice.
>>          >>
>>          >> If Alice receives the SDP Answer first, and then the trickle
>>         ICE request, she will assume that Bob first provided candidates
>>         A, B and C (in the SDP Answer), and then added D and E (in the
>>         trickle ICE request).
>>          >>
>>          >> If Alice receives the trickle ICE request first, and then
>>         the SDP Answer
>>          >
>>          > Don't do that then.
>>          >
>>          > It's been pretty clear from the start that any session
>>         *modification* mechanism that does not also contain the full
>>         session state completely falls apart in the face of unordered
>>         delivery. This is a fundamental information problem, and you
>>         aren't going to write rules that somehow cause it not to be true=
.
>>          >
>>          > We haven't yet tackled how to send trickle ICE in SIP, much
>>         less partial offers and partial answers. When we do, the only
>>         way it's going to have any chance of working at all is by
>>         requiring ordered delivery.
>>
>>         I totally agree, and my opinion (which I tried to explain to
>>         Emil) is that it applies also to candidates.
>>
>>         Regards,
>>
>>         Christer
>>
>



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From internet-drafts@ietf.org  Mon Oct 21 02:27: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 671CC21F9FD5; Mon, 21 Oct 2013 02:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level: 
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39asirIyVIN5; Mon, 21 Oct 2013 02:27:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6218A11E8193; Mon, 21 Oct 2013 02:27:26 -0700 (PDT)
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.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021092725.29495.54918.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 02:27:25 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-05.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 09:27:35 -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-05.txt
	Pages           : 13
	Date            : 2013-10-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-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From salvatore.loreto@ericsson.com  Mon Oct 21 02:35: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 0796511E84BD for ; Mon, 21 Oct 2013 02:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.436
X-Spam-Level: 
X-Spam-Status: No, score=-105.436 tagged_above=-999 required=5 tests=[AWL=-2.838, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvUwpa-i7MaZ for ; Mon, 21 Oct 2013 02:34:45 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DAF5F11E8501 for ; Mon, 21 Oct 2013 02:33:18 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-4d-5264f4da070a
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 82.07.25272.AD4F4625; Mon, 21 Oct 2013 11:33:15 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.209]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 11:33:14 +0200
From: Salvatore Loreto 
To: "mmusic@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-mmusic-sctp-sdp-05.txt
Thread-Index: AQHOzj/LqerJdhxybESUNjW6q64bng==
Date: Mon, 21 Oct 2013 09:33:13 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2DAB5B@ESESSMB109.ericsson.se>
References: <20131021092727.29495.24485.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A2DAB5BESESSMB109ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje7tLylBBof6mCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIdn5jMVtFhV7HjQxtTAuNK4i5GTQ0LAROLT20eMELaYxIV7 69lAbCGBo4wSE1Z6dDFyAdlLGCWePT4PlmATMJN4/nALM4gtIqAu8XVvD5DNwSEs4CNx5EIs RNhH4nPPMiYIW09i4cHFYPNZBFQlPs28zApi8wp4S7z6e4cVpFVIwFFiT4sUSJgR6ITvp9aA tTILiEvcejKfCeI0AYkle84zQ9iiEi8f/2OFsJUkVmy/xAhRny9x7fBDZojxghInZz5hmcAo PAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGOoXmuJp4e2MCGrWcDIsYqRozi1OCk3 3chgEyMwSg5u+W2xg/HyX5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YLz+8MFOhhVs+gUbOu6VWC06xSTWdiP1W6afSJcwo/TN762P5E+2rHX6U3c4P/++15p6Vz0b 5+DViTdPnNYUqXi0ab/8Gl3LpJA9+stkbkZOtHn/QJHnjiej/qLCn0+eVOTMm/+26ByXX7vD x3wexVcC/JoG216biU+/zjuxfenKayb/UmXu3lRiKc5INNRiLipOBACWnlX3YAIAAA==
Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-sctp-sdp-05.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 Oct 2013 09:35:17 -0000

--_000_2B9B48179856DC4FA00C93C79EB7E64A2DAB5BESESSMB109ericsso_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi there,

I have just uploaded the last version of the sctp-sdp draft
that just include all the clarification text that I have been asked to add
plus some minor editing.

feedback and comments are as usual very welcome

best regards
Salvatore

Begin forwarded message:

From: >
Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-05.txt
Date: October 21, 2013 12:27:27 PM GMT+03:00
To: Gonzalo Camarillo >, Salvatore Loreto >, Salvatore Loreto >


A new version of I-D, draft-ietf-mmusic-sctp-sdp-05.txt
has been successfully submitted by Salvatore Loreto and posted to the
IETF repository.

Filename: draft-ietf-mmusic-sctp-sdp
Revision: 05
Title: Stream Control Transmission Protocol (SCTP)-Based Media Transport in=
 the Session Description Protocol (SDP)
Creation date: 2013-10-21
Group: mmusic
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp=
-sdp-05.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp
Htmlized:        http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-=
sdp-05

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.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--_000_2B9B48179856DC4FA00C93C79EB7E64A2DAB5BESESSMB109ericsso_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Hi there,






I have just uploaded the last version of the sctp-sdp draft 

that just include all the clarification text that I have been asked to=
 add 


plus some minor editing.







feedback and comments are as usual very welcome







best regards


Salvatore





Begin forwarded message:







From:
<<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=






Subject:
Ne=
w Version Notification for draft-ietf-mmusic-sctp-sdp-05.txt





Date:
Octob=
er 21, 2013 12:27:27 PM GMT+03:00





To:
Gonza=
lo Camarillo <gonzalo.=
camarillo@ericsson.com>, Salvatore Loreto <Salvatore.Loreto@ericsson.com>,
 Salvatore Loreto <salv=
atore.loreto@ericsson.com>








A new version of I-D, draft-ietf-mmusic-sctp-sdp-05.txt

has been successfully submitted by Salvatore Loreto and posted to the

IETF repository.



Filename: d=
raft-ietf-mmusic-sctp-sdp

Revision: 0=
5

Title: Stream Control =
Transmission Protocol (SCTP)-Based Media Transport in the Session Descripti=
on Protocol (SDP)

Creation date: 2013-10-21

Group: mmusic

Number of pages: 13

URL:            &nbs=
p;http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-05.=
txt

Status:          http://datatracke=
r.ietf.org/doc/draft-ietf-mmusic-sctp-sdp

Htmlized:        http://tools.ietf.org/html/dr=
aft-ietf-mmusic-sctp-sdp-05

Diff:            h=
ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-05



Abstract:

  SCTP (Stream Control Transmission Protocol) is a transport prot=
ocol

  used to establish associations between two endpoints.  Thi=
s document

  describes how to express media transport over SCTP in SDP (Sess=
ion

  Description Protocol).  This document defines the 'SCTP', =
'SCTP/DTLS'

  and 'DTLS/SCTP' protocol identifiers for SDP.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



The IETF Secretariat
















--_000_2B9B48179856DC4FA00C93C79EB7E64A2DAB5BESESSMB109ericsso_--

From christer.holmberg@ericsson.com  Mon Oct 21 03:04: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 EF12211E8240 for ; Mon, 21 Oct 2013 03:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.811
X-Spam-Level: 
X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBqwY-hivftX for ; Mon, 21 Oct 2013 03:04:45 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 21A5911E8469 for ; Mon, 21 Oct 2013 03:04:21 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-e8-5264fc2421a1
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FE.BC.25272.42CF4625; Mon, 21 Oct 2013 12:04:21 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 12:04:20 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: POF/PAN: Need for more m- lines in the PAN than in the associated POF
Thread-Index: Ac7OQ5BzDoF3484rR3mEswcOZZqeKw==
Date: Mon, 21 Oct 2013 10:04:20 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E55E5@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.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E55E5ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvja7qn5Qgg9/zuCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPkbpzMWPLCr2PVwCmsD43/TLkZODgkBE4mZr7cyQdhiEhfu rWfrYuTiEBI4yijRc/EQM4SzhFHi47sLQBkODjYBC4nuf9ogDSIC6hJf9/Ywg4SFBQIkpnWx Q4RDJY5vecsCYetJNF66yApiswioSpzoWAhWwyvgK/G58yUjiM0ItPf7qTVgNzALiEvcejIf 6h4BiSV7zjND2KISLx//Y4WwFSWuTl8OVZ8v0XWqH2qmoMTJmU9YJjAKzUIyahaSsllIyiDi OhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRo7i1OKk3HQjg02MwLA/uOW3xQ7Gy39tDjFK c7AoifN+fOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExfVcIs572Wb+vLpL83fKnW2w9 fGyKX98SZ6jZ9vV7ubWF8855s36mxJUuihesqDx8lyP+c9vBn/FLtkvMXZxXsyxHZMvD7SIZ 68q4/DaFXX2Wd7xh6fqOlzv2vJ2xff3zM+2XTuwwKHz9/NL983vP+1rFuNSc+3b7s+S6lqBJ Zr6inkc3fPtUr8RSnJFoqMVcVJwIAAgICn1JAgAA
Subject: [MMUSIC] POF/PAN: Need for more m- lines in the PAN than in the associated POF
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 Oct 2013 10:04:54 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E55E5ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

The following issue is related to the case where a media description in a P=
OF implicitly affect other media descriptions (not present in the POF), but=
 this e-mail looks at a similar case from a PAN perspective.

Section 5.3 says:

        If the preceding steps have been performed for each media section
        without resulting in a rejection, then the agent forms a partial
        answer consisting of a single o=3D line, and all of the media secti=
ons
        that were generated as part of the preceding steps. Note that this
        processing will always yield the same number of media sections in a
        partial answer as were present in the partial offer.


The text says that the PAN will contain the same number of media sections a=
s the associated POF. But, what if the POF also caused other media sections=
 to change? Those media sections cannot be added to the PAN.

(If the offerer "knows" which media sections will be modified by the answer=
er in the PAN, it can of course included those in the POF - even if they ar=
e not modified in the POF)

The answerer can of course send the PAN, followed by an Offer/POF which mod=
ifies the other affected media sections that didn't "fit" into the PAN. But=
, that may not always be very feasible, especially if some properties in th=
ose media sections are removed or changed.

So, I think we would need some text saying that a POF might have to be reje=
cted, if it will affect media sections that cannot be put into associated P=
AN.

Again, whether situations like this will occur in real-life of course depen=
ds on what people will use POFs/PANs for, so some input (re-pinging Justin)=
 would be useful.

Regards,

Christer









--_000_7594FB04B1934943A5C02806D1A2204B1C4E55E5ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


The following issue is related to the case where a m=
edia description in a POF implicitly affect other media descriptions (not p=
resent in the POF), but this e-mail looks at a similar case from a PAN pers=
pective.


 


Section 5.3 says:


 


        If the precedin=
g steps have been performed for each media section


        without resulting in=
 a rejection, then the agent forms a partial


        answer consisting of=
 a single o=3D line, and all of the media sections


        that were generated =
as part of the preceding steps. Note that this


        processing will alwa=
ys yield the same number of media sections in a


        partial answer as we=
re present in the partial offer.


 


 


The text says that the PAN will contain the same num=
ber of media sections as the associated POF. But, what if the POF also caus=
ed other media sections to change? Those media sections cannot be added to =
the PAN.


 


(If the offerer “knows” which media sect=
ions will be modified by the answerer in the PAN, it can of course included=
 those in the POF - even if they are not modified in the POF)

 


The answerer can of course send the PAN, followed by=
 an Offer/POF which modifies the other affected media sections that didn=
217;t “fit” into the PAN. But, that may not always be very feas=
ible, especially if some properties in those media sections
 are removed or changed.


 


So, I think we would need some text saying that a PO=
F might have to be rejected, if it will affect media sections that cannot b=
e put into associated PAN.


 


Again, whether situations like this will occur in re=
al-life of course depends on what people will use POFs/PANs for, so some in=
put (re-pinging Justin) would be useful.


 


Regards,


 


Christer


 


 


 


 


 


 


 


 






--_000_7594FB04B1934943A5C02806D1A2204B1C4E55E5ESESSMB209erics_--

From ari.keranen@ericsson.com  Mon Oct 21 05: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 123B211E819F for ; Mon, 21 Oct 2013 05:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.136
X-Spam-Level: 
X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=-1.837, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-Ea5XS6Pj9U for ; Mon, 21 Oct 2013 05:01:12 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87D11E84AF for ; Mon, 21 Oct 2013 05:01:07 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-79-52651781db18
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.61.25272.18715625; Mon, 21 Oct 2013 14:01:05 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Mon, 21 Oct 2013 14:01:05 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 8E9551103CD; Mon, 21 Oct 2013 15:01:05 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 176C54EA46; Mon, 21 Oct 2013 15:01:05 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B99AC4EA45; Mon, 21 Oct 2013 15:01:04 +0300 (EEST)
Message-ID: <52651780.60108@ericsson.com>
Date: Mon, 21 Oct 2013 15:01:04 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Pal Martinsen (palmarti)" , Emil Ivov 
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com>
In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvjW6jeGqQwdLt5hZ7/i5it1izcwKL xdTlj1ks3l9fyeLA4jHl90ZWjyVLfjJ5/H8T6DFr5xOWAJYoLpuU1JzMstQifbsEroz+1ZdY CrbyVUxceo+xgfEAdxcjJ4eEgInEg7Pb2CBsMYkL99YD2VwcQgJHGSXO9X5kgnA2MErM+NDP CuHsZZS4enEaC4SzjlGi6eQ7qMwKRokv59awggzjFdCUuHaxjRHEZhFQlTj0ajeYzSZgL3Fz wnV2EFtUIFni0d1TbBD1ghInZz5hAbFFBIIk7nR+ZQKxmQWsJRZemQLWKyzgIPH8zTp2iGVv GSV2PzsDtoxTwFeitfsSI0SDrcSFOddZIGx5ie1v5zBDfKcmcfXcJjBbCOigq/9eMU5gFJ2F ZPcsJO2zkLQvYGRexchRnFqclJtuZLCJERglB7f8ttjBePmvzSFGaQ4WJXHej2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwGp1law/Q8Um6k/EjXsNi3gX2rS83Tw24vPB6tViRwOdb 5+/+2NtXxvDxkPsjsZ9u54S6H/wuvs1V+kvidktcvSPXpkdiz9OCF385pvfMa0nqt1kyuybF up5pes1t/lMh45vWmnWLWp793fr93cmEkAkbj9eZqz+4FG0YvuzInSYB9h0Gh95PeavEUpyR aKjFXFScCACdZEI6YAIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 12:01:18 -0000

On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
> On Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>> On 18.10.13, 19:30, Adam Roach wrote:
>>> On 10/18/13 09:44, Emil Ivov wrote:
>>>> It might be worth reminding exactly what these 50ms would be
>>>> protecting us against
>>>
>>> They're protecting us against RTP arriving at a rate of 20ms per
>>> packet.
>>
>> That would indeed be one of the reasons to pace checks (in addition
>> to fragile NAT boxes IIRC), however in either case, I fail to
>> realise why we need a different pacing strategy for non-RTP. This
>> is what I was asking about.
>>
>> Connectivity check hammers can still resort to RTP if the pacing
>> timer is their only problem and I don't see why shaky NATs would
>> tolerate a 20ms rate for RTP but only a 50ms for anything else.
>>
>> This entire separation sounds quite arbitrary right now. I see why
>> we would pick a value that we consider somewhat safe and secure but
>> I don't understand why we would need two!?
>
> I agree. No need to add more complexity. ICE should be ignorant of
> what traffic goes through the pinholes.

The idea would be to have one recommended value (or set of) for all 
kinds of traffic but with RTP you would have this "additional piece of 
information" (due to the knowledge of your traffic pattern and the 
formula to relate that to pacing) that would allow you to go below the 
conservative recommended value. If you would have something similar with 
non-RTP traffic, you could use that.

But then for both endpoints agreeing on the value in order to have 
connectivity checks happening simultaneously for the same pairs, we'd 
probably need to do some negotiation, similar to what was done with ICE 
on HIP (http://tools.ietf.org/html/rfc5770#section-4.4).


Cheers,
Ari

From ari.keranen@ericsson.com  Mon Oct 21 05:03: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 5C02111E82DA for ; Mon, 21 Oct 2013 05:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.021
X-Spam-Level: 
X-Spam-Status: No, score=-4.021 tagged_above=-999 required=5 tests=[AWL=-1.722, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81V8EwAEFE8O for ; Mon, 21 Oct 2013 05:02:48 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D879411E83A0 for ; Mon, 21 Oct 2013 05:02:46 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-50-526517e53cc3
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.B1.25272.5E715625; Mon, 21 Oct 2013 14:02:46 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Mon, 21 Oct 2013 14:02:45 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 787F11103CD; Mon, 21 Oct 2013 15:02:45 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 031CA4EA46; Mon, 21 Oct 2013 15:02:45 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B668C4EA45; Mon, 21 Oct 2013 15:02:44 +0300 (EEST)
Message-ID: <526517E4.5090901@ericsson.com>
Date: Mon, 21 Oct 2013 15:02:44 +0300
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <526147C3.9040204@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje4z8dQgg9e7mC2unfnHaDF1+WMW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj2vfVbAX32SqOPGdrYFzB2sXIySEhYCKx 8NNddghbTOLCvfVsXYxcHEICRxkllj5ewwKSEBLYwCgx+6gNRGIvo8Suyf9ZIZx1jBIPPj+B clYwSsx68YsRpIVXQFvifPc8sHYWAVWJuRufge1gE7CVWP3qJlhcVCBZ4tHdU2wQ9YISJ2c+ AYuLCOhKLDr7AKyeWUBGYsbZRiYQW1jAQeL5m3XsECcVSLz6cZS5i5GDg1MgUGLPenmIcguJ xW8OQrXKSzRvnc0M8ZqaxNVzm5ghWlUlrv57xTiBUXQWks2zkLTPQtK+gJF5FSNHcWpxUm66 kcEmRmDYH9zy22IH4+W/NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA uJnjUjNfR949gaW/6tMl7tpz9/nm2++fve+kVLtwqvzMDZ3SLzi0Ol8yzf66q5BBvuvx8iD3 5uLaxqMXdP6bNBatX6DIY+KVfLxDw6ND/IC87PGvGxp2W068WFEWLsrwMnx7iw5P6FfeF6/f le/ZHracfVlQocmn9o5dueudXz3Uvtz68V2jEktxRqKhFnNRcSIAZSBJhUkCAAA=
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 12:03:30 -0000

On 10/18/13 7:44 PM, Martin Thomson wrote:
> On 18 October 2013 07:37, Ari Keränen  wrote:
>> So, to be "conservative enough", how about 50 ms RECOMMENDED pacing value if there's no better knowledge of the network? And if there is, scale accordingly, but not below 20ms.
>
> I see no reason not to make this 50ms.  20ms might cross the line, but
> I'll let people argue about what is safe below that.  I have done some
> calculations on this and even at 20ms, it's not out of proportion.
> (I'll send a pointer out when I submit the draft later today).

Sounds interesting, looking forward to the pointer.

> A good reason not to have a larger pacing timer is the effect that it
> has on RTO.  For some configurations, the standard formulae lead to
> ICE taking far too long to complete.

Very true.


Cheers,
Ari


From ari.keranen@ericsson.com  Mon Oct 21 05:05: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 7D90B11E84AE for ; Mon, 21 Oct 2013 05:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.745
X-Spam-Level: 
X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.204,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHwWSRV2A6wl for ; Mon, 21 Oct 2013 05:05:09 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63711E84F3 for ; Mon, 21 Oct 2013 05:04:41 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-1a-526518409630
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.71.16099.04815625; Mon, 21 Oct 2013 14:04:16 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Mon, 21 Oct 2013 14:04:15 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 717BF1103CD; Mon, 21 Oct 2013 15:04:15 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F3C564EA47; Mon, 21 Oct 2013 15:04:14 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A90234EA46; Mon, 21 Oct 2013 15:04:14 +0300 (EEST)
Message-ID: <5265183E.6070709@ericsson.com>
Date: Mon, 21 Oct 2013 15:04:14 +0300
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Justin Uberti 
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvja6DRGqQwb4VOhZ7/i5it1izcwKL xdapQhZTlz9mcWDxWLCp1GPJkp9MHv/fBHrM2vmEJYAlissmJTUnsyy1SN8ugSujfccMxoJ1 XBXL/j1hbWD8xN7FyMEhIWAisW2KSBcjJ5ApJnHh3no2EFtI4DCjxIrZvF2MXED2BkaJybv/ s0Ak9jJK3FrMB5FYxyjxYOdRdghnBaPExQldYO28AtoSTcfnsoPYLAKqEr+vzQXrZhOwlVj9 6iaYLSqQLPHo7imoekGJkzOfgMVFBNQkHs7axQpiMwtESaw+tB2sRljAQeL5m3XsEFdcYZSY dNigi5Gdg1MgUKKREaLaQmLxm4PsELa8xPa3c5ghHlOTuHpuEzNEp6rE1X+vGCcwis5CsngW kvZZSNoXMDKvYmTPTczMSS833MQIjImDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2amp BalF8UWlOanFhxiZODilGhiVni9c7VW2yijrpb31hL5ZrWdM2j7IP+S/MjnrqOkZ/bClP43b VPWOCaTqJrNOsmRg65p53/fxpid1PdpKxq8k0x7N3HHx7oo6rpP3xNSPzeyaJaG2yGOBaZeG Xh7Tjm8H97zecyOqozBU4/28qY+aHv+uOLFb/GmgRIrZi5jwb8FL1h5PsRVRYinOSDTUYi4q TgQABVmEElcCAAA=
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 12:05:17 -0000

On 10/18/13 9:34 PM, Justin Uberti wrote:
> FWIW, we are now doing trials to understand what is the absolute lower
> bound for ICE checks on today's internet (i.e. what is the minimum time
> to allow for a NAT to create a new UDP binding).

This sounds very interesting and something we should take into account. 
I hope you can share your results on this soon.


Cheers,
Ari

> On Fri, Oct 18, 2013 at 10:30 AM, Adam Roach  > wrote:
>
>     On 10/18/13 09:44, Emil Ivov wrote:
>>     It might be worth reminding exactly what these 50ms would be
>>     protecting us against
>
>     They're protecting us against RTP arriving at a rate of 20ms per packet.
>
>
>>     and why is it that we don't need to be
>>     protected against it in the case of RTP where 20ms is accepted as a
>>     fine default value.
>
>     Well, it's not. This is exactly why we ended up requiring ICE: it
>     ensures explicit consent before you start blowing media at someone.
>
>     See also
>     http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html
>
>     /a
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org 
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>


From pkyzivat@alum.mit.edu  Mon Oct 21 06:53: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 4CE8B11E8508 for ; Mon, 21 Oct 2013 06:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.3
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0P00OzDUQHx for ; Mon, 21 Oct 2013 06:53:38 -0700 (PDT)
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 7AB5E11E81A7 for ; Mon, 21 Oct 2013 06:53:25 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id fnpP1m0051YDfWL53ptQvj; Mon, 21 Oct 2013 13:53:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id fptQ1m00M3ZTu2S3gptQdq; Mon, 21 Oct 2013 13:53:24 +0000
Message-ID: <526531D2.3090503@alum.mit.edu>
Date: Mon, 21 Oct 2013 09:53:22 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>   <52644342.2040605@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=1382363604; bh=LUa7EPV+vh5FxmOWeBEvX8v9ABi6aEJSfOEtfM7/2e8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GTuNAsSqrneCd2E3swtsDMAJnLIBT9Qlj47kIo/e6ISG04U13HLnouj1R+OGMfdLc zqnuzcTUFfZCn3TL14C6Vj0xMoEjZygzCwVhC5szO9RTgdxLyfH1PEtzW27PxmLN6H 2HR8vHncfCc+FhokxVVKea3a5CQn4KG6um392RD7IHxw2nlGvyjLwIiuI8e6G/HC66 bzVDXjqZb52n0TrKVPdSza9bcIhXkTmX2hf1XmnE4Z/qzyQY0lbUC+dsYJ5iBP4YGt b67OPuHWtoqO/L0Rszbgw+5wYAGjQ4U4uSMuDLglINTfb9tlEJc/XSuQCH5+JwLIlG 4JRuKmsSfC9Qw==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 13:53:48 -0000

Emil,

I'm open to your arguments that there is reason to have trickle ICE 
alongside O/A and POF/PAN.

But then we must recognize that these all have interactions with one 
another. Rather than just ignore them, or hand wave, ISTM that these 
need to be specified. It introduces complexity, and dealing with that is 
part of the job.

Vanilla ICE specifies the interactions between O/A and the discovery of 
candidates via ICE itself. But should it be updated to talk about all 
these other mechanisms as well? If not, where should those be 
documented? Should trickle ICE discuss interactions with POF/PAN, or 
should POF/PAN discuss interactions with trickle ICE, or both?

	Thanks,
	Paul

On 10/20/13 9:03 PM, Emil Ivov wrote:
> On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat  wrote:
>> On 10/20/13 4:23 PM, Emil Ivov wrote:
>>>
>>> One more thought:
>>>
>>> Please understand that trickle ICE is NOT a session modification.
>>
>>
>> Isn't the session modified as a result of the trickle ICE? (E.g., end up
>> using a different media address than it otherwise would have.)
>>
>> And the use of trickle ICE can (I think) require that a subsequent offer be
>> sent (or answered) differently than it would had trickle ice not been used.
>
> The above statements are also true for vanilla ICE and peer reflexive
> candidates, where ICE processing not reflected in SDP can already lead
> to potential changes of addresses. If the change occurs, then an O/A
> would follow. Currently Trickle ICE works along these exact same
> lines.
>
>> And AFAIK everything that can be accomplished with trickle ICE could also be
>> accomplished with Partial Offer/Answer.
>
> I already agreed that it is implementable ... the point is that it
> would be *incredibly inconvenient*. I already gave a few reasons
> earlier in this thread, let's try again:
>
> * there would be an extremely high glare probability (which is
> perfectly avoidable without O/A), * there would be a lot of added
> complexity. Imagine POFs / PANs that send additional candidates *and*
> change codecs and/or add/remove streams.
> *  it would be very clumsy: after trickling candidates with a POF,
> agents would block and wait for a PAN before they can do it again
> * POF/PAN would be a dependency for trickle and there is no reason for it to be.
> * In Berlin we agreed that we are adopting Unified for WebRTC cases.
> There are Plan B and No Plan style implementations out there and my
> understanding is that they have not been outlawed. Such
> implementations would be unlikely to adopt POF/PAN. Yet, it would be
> great if we made it possible for them to still use Trickle ICE.
>
> The disadvantages aside:
>
> Why would we want to do it this way?
> What would we hope to gain?
>
>> So the differences aren't functional
>> ones.
>> I presume that trickle ICE is expected to be faster, and/or easier to
>> implement. (But easier to implement becomes moot if both need to be
>> implemented.)
>
> I can promise you that it doesn't. You don't have to take my word for
> it. Just try and implement it.
>
>> In my book those justify considering it a session modification.
>
> Let's not take things out of context. Christer's point was that
> because it is a session modification, it has to be done in
> Offer/Answer.
>
> This is wrong.
>
> You can consider it a session modification if you like but it is not
> the kind that requires Offer/Answer. Vanilla ICE proves this.
>
> Emil
>
>
>
>
>
>
>>          Thanks,
>>          Paul
>>
>>> Please
>>> try to isolate the SDP syntax that it uses from general O/A. It is not
>>> part of it.
>>>
>>> Think of it as JSON if that would make thinks easier.
>>>
>>> Emil
>>>
>>> --sent from my mobile
>>>
>>> On 20 Oct 2013 22:18, "Emil Ivov" >> > wrote:
>>>
>>>      Christer, "I tried to explain" to you that what you are saying has
>>>      been addressed and cannot happen. If you believe that there is a
>>>      specific situation that is still possible and is a problem, then
>>>      please describe that rather than continuing to suggest that things
>>>      don't work without any valid arguments whatsoever.
>>>
>>>      --sent from my mobile
>>>
>>>      On 20 Oct 2013 21:50, "Christer Holmberg"
>>>      >>      > wrote:
>>>
>>>
>>>          Hi,
>>>
>>>           >> Example:
>>>           >>
>>>           >> 1. Alice sends an SDP Offer to Bob.
>>>           >>
>>>           >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>>>          and C.
>>>           >>
>>>           >> 3. After that, Bob sends, using trickle ICE, candidates D
>>>          and E to Alice.
>>>           >>
>>>           >> If Alice receives the SDP Answer first, and then the trickle
>>>          ICE request, she will assume that Bob first provided candidates
>>>          A, B and C (in the SDP Answer), and then added D and E (in the
>>>          trickle ICE request).
>>>           >>
>>>           >> If Alice receives the trickle ICE request first, and then
>>>          the SDP Answer
>>>           >
>>>           > Don't do that then.
>>>           >
>>>           > It's been pretty clear from the start that any session
>>>          *modification* mechanism that does not also contain the full
>>>          session state completely falls apart in the face of unordered
>>>          delivery. This is a fundamental information problem, and you
>>>          aren't going to write rules that somehow cause it not to be true.
>>>           >
>>>           > We haven't yet tackled how to send trickle ICE in SIP, much
>>>          less partial offers and partial answers. When we do, the only
>>>          way it's going to have any chance of working at all is by
>>>          requiring ordered delivery.
>>>
>>>          I totally agree, and my opinion (which I tried to explain to
>>>          Emil) is that it applies also to candidates.
>>>
>>>          Regards,
>>>
>>>          Christer
>>>
>>
>
>
>


From adam@nostrum.com  Mon Oct 21 07:00: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 8C15911E8546 for ; Mon, 21 Oct 2013 07:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level: 
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLDOQott0CeK for ; Mon, 21 Oct 2013 07:00:08 -0700 (PDT)
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 006F111E854F for ; Mon, 21 Oct 2013 06:58:17 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9LDw9tR041455 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 08:58:10 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <526532EC.3090603@nostrum.com>
Date: Mon, 21 Oct 2013 08:58:04 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , "mmusic@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B1C4E55E5@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4E55E5@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------070302070304010105050400"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] POF/PAN: Need for more m- lines in the PAN than in the associated POF
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 Oct 2013 14:00:11 -0000

This is a multi-part message in MIME format.
--------------070302070304010105050400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/21/13 05:04, Christer Holmberg wrote:
>
> Hi,
>
> The following issue is related to the case where a media description 
> in a POF implicitly affect other media descriptions (not present in 
> the POF), but this e-mail looks at a similar case from a PAN perspective.
>
> Section 5.3 says:
>
> If the preceding steps have been performed for each media section
>
>      without resulting in a rejection, then the agent forms a partial
>
>      answer consisting of a single o= line, and all of the media sections
>
>      that were generated as part of the preceding steps. Note that this
>
>      processing will always yield the same number of media sections in a
>
>       partial answer as were present in the partial offer.
>
> The text says that the PAN will contain the same number of media 
> sections as the associated POF. But, what if the POF also caused other 
> media sections to change?
>

Can you give a concrete example of how this might happen?

/a

--------------070302070304010105050400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/21/13 05:04, Christer Holmberg
      wrote:

    

    

      
      
      
      

        
Hi,

        
 

        
The following issue is related to the case
          where a media description in a POF implicitly affect other
          media descriptions (not present in the POF), but this e-mail
          looks at a similar case from a PAN perspective.

        
 

        
Section 5.3 says:

        
 

        
       
            If the preceding steps have been performed for each media
            section

        
  
                 without resulting in a rejection, then the agent forms
            a partial

        
  
                 answer consisting of a single o= line, and all of the
            media sections

        
  
                 that were generated as part of the preceding steps.
            Note that this

        
  
                 processing will always yield the same number of media
            sections in a

        
 
                  partial answer as were present in the partial offer.

        
 

        
 

        
The text says that the PAN will contain the
          same number of media sections as the associated POF. But, what
          if the POF also caused other media sections to change?

      

    

    

    Can you give a concrete example of how this might happen?

    

    /a

  


--------------070302070304010105050400--

From christer.holmberg@ericsson.com  Mon Oct 21 07:19:50 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 6746F21E8084 for ; Mon, 21 Oct 2013 07:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.618
X-Spam-Level: 
X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=0.630,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tni+E4vY8s20 for ; Mon, 21 Oct 2013 07:19:44 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 946A011E85BD for ; Mon, 21 Oct 2013 07:19:29 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-47-526537f034be
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.D7.16099.0F735625; Mon, 21 Oct 2013 16:19:28 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 16:19:28 +0200
From: Christer Holmberg 
To: Adam Roach , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] POF/PAN: Need for more m- lines in the PAN than in the associated POF
Thread-Index: Ac7OQ5BzDoF3484rR3mEswcOZZqeKwAETvQAAARhs4A=
Date: Mon, 21 Oct 2013 14:19:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E5BFD@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4E55E5@ESESSMB209.ericsson.se> <526532EC.3090603@nostrum.com>
In-Reply-To: <526532EC.3090603@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E5BFDESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje4H89Qggy3/DCz2/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStjRdMlloIvKRWt3/+yNTBOSepi5OSQEDCR 6JjQzQRhi0lcuLeerYuRi0NI4DCjxJbpa1ggnCWMEtPmP2XtYuTgYBOwkOj+pw1iigi4Scw7 lQ7SKywQK7H7/3+wOSICcRI3nx1nhrCtJGb8vMAIYrMIqEr0dtwBq+EV8JV4ueQgWI2QQJ7E y1cQN3AKaEs8ev6LDcRmBLrn+6k1YHFmAXGJW0/mQ90pILFkz3lmCFtU4uXjf6wQtqLE1enL oerzJSYdW8gCsUtQ4uTMJywTGEVmIRk1C0nZLCRls4A+YxbQlFi/Sx+iRFFiSvdDdghbQ6J1 zlx2ZPEFjOyrGNlzEzNz0ssNNzEC4+bglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkaF6gDPXC7Lb/KmGuLXz8gUBl3hT6h1MN59THfFzaOHuE/fONsS w3H9SdnDD5ezp0rPFHy1WyP5b+sW0+LWG8byh9w1nhwsKCmZqPY2Q81+0SUHBrGVmeF/Mjb/ 7UhJ8meYLjfn+9+26oOzpEIye26f2m5o9brGwI47VknxZNU6zZcHKm7Z1iqxFGckGmoxFxUn AgC5QU6GaQIAAA==
Subject: Re: [MMUSIC] POF/PAN: Need for more m- lines in the PAN than in the associated POF
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 Oct 2013 14:19:50 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5BFDESESSMB209erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCk9uZSBleGFtcGxlIGlzIGEgdmlkZW8gZW5jb2RpbmcgZW5naW5lLCB0aGF0IGNhbiBo
YW5kbGUgYSBjZXJ0YWluIG51bWJlciBvZiBtYWNybyBibG9ja3MgcGVyIHNlY29uZC4gQXNzdW1p
bmcgbXkgZXhpc3RpbmcgbS0gbGluZXMgYXJlIHVzaW5nIDcwJSwgYW5kIHRoZSBuZXcgbS0gbGlu
ZSB3b3VsZCByZXF1aXJlIDQwJSBtb3JlLCBJIG1heSBoYXZlIHRvIGFkanVzdCBzb21lIHByb3Bl
cnRpZXMgb2YgdGhlIGV4aXN0aW5nIG0tIGxpbmVzLg0KDQpPbmUgY2FuIG9mIGNvdXJzZSBhc2sg
d2hldGhlciBJIHNob3VsZCBkbyB0aGF0IGluIHRoZSBBbnN3ZXIgdG8gYmVnaW4gd2l0aCwgb3Ig
c2VuZCBhIHNlcGFyYXRlIE9mZmVyLiBJIGd1ZXNzIGl0IGRlcGVuZHMgb24gaG93IHRpbWUtY3Jp
dGljYWwgdGhlIGNoYW5nZSBpcywgaG93IHVzZXIgZXhwZXJpZW5jZSB3b3VsZCBiZSBhZmZlY3Rl
ZCwgZXRjLg0KDQpCdXQsIEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBtZW50aW9uIGluIHRo
ZSBkcmFmdCwgdGhhdCBzdWNoIHNjZW5hcmlvIGNhbiBvY2N1ciwgYW5kIGhvdyBpdCBjYW4gYmUg
ZGVhbHQgd2l0aCAoaXQgbWF5IGJlIG9idmlvdXMgdG8gdXMsIGJ1dCBub3QgdGhlIGV2ZXJ5b25l
IGVsc2Ugb3V0IHRoZXJlKS4NCg0KQW5kLCBhcyB3ZSBkaXNjdXNzZWQgZWFybGllciwgd2l0aCBC
VU5ETEUgdGhlIGNoYW5nZSBvZiBvbmUgbS0gbGluZSBtYXkgaW1wbGljaXRseSBjaGFuZ2Ugb3Ro
ZXIgbS0gbGluZXMuIEJ1dCwgdGhhdCBuZWVkcyB0byBiZSBzdHVkaWVkIGEgbGl0dGxlIG1vcmUu
DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFk
YW1Abm9zdHJ1bS5jb21dDQpTZW50OiAyMS4gbG9rYWt1dXRhIDIwMTMgMTY6NTgNClRvOiBDaHJp
c3RlciBIb2xtYmVyZzsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gUE9G
L1BBTjogTmVlZCBmb3IgbW9yZSBtLSBsaW5lcyBpbiB0aGUgUEFOIHRoYW4gaW4gdGhlIGFzc29j
aWF0ZWQgUE9GDQoNCk9uIDEwLzIxLzEzIDA1OjA0LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToN
CkhpLA0KDQpUaGUgZm9sbG93aW5nIGlzc3VlIGlzIHJlbGF0ZWQgdG8gdGhlIGNhc2Ugd2hlcmUg
YSBtZWRpYSBkZXNjcmlwdGlvbiBpbiBhIFBPRiBpbXBsaWNpdGx5IGFmZmVjdCBvdGhlciBtZWRp
YSBkZXNjcmlwdGlvbnMgKG5vdCBwcmVzZW50IGluIHRoZSBQT0YpLCBidXQgdGhpcyBlLW1haWwg
bG9va3MgYXQgYSBzaW1pbGFyIGNhc2UgZnJvbSBhIFBBTiBwZXJzcGVjdGl2ZS4NCg0KU2VjdGlv
biA1LjMgc2F5czoNCg0KICAgICAgICBJZiB0aGUgcHJlY2VkaW5nIHN0ZXBzIGhhdmUgYmVlbiBw
ZXJmb3JtZWQgZm9yIGVhY2ggbWVkaWEgc2VjdGlvbg0KICAgICAgICB3aXRob3V0IHJlc3VsdGlu
ZyBpbiBhIHJlamVjdGlvbiwgdGhlbiB0aGUgYWdlbnQgZm9ybXMgYSBwYXJ0aWFsDQogICAgICAg
IGFuc3dlciBjb25zaXN0aW5nIG9mIGEgc2luZ2xlIG89IGxpbmUsIGFuZCBhbGwgb2YgdGhlIG1l
ZGlhIHNlY3Rpb25zDQogICAgICAgIHRoYXQgd2VyZSBnZW5lcmF0ZWQgYXMgcGFydCBvZiB0aGUg
cHJlY2VkaW5nIHN0ZXBzLiBOb3RlIHRoYXQgdGhpcw0KICAgICAgICBwcm9jZXNzaW5nIHdpbGwg
YWx3YXlzIHlpZWxkIHRoZSBzYW1lIG51bWJlciBvZiBtZWRpYSBzZWN0aW9ucyBpbiBhDQogICAg
ICAgIHBhcnRpYWwgYW5zd2VyIGFzIHdlcmUgcHJlc2VudCBpbiB0aGUgcGFydGlhbCBvZmZlci4N
Cg0KDQpUaGUgdGV4dCBzYXlzIHRoYXQgdGhlIFBBTiB3aWxsIGNvbnRhaW4gdGhlIHNhbWUgbnVt
YmVyIG9mIG1lZGlhIHNlY3Rpb25zIGFzIHRoZSBhc3NvY2lhdGVkIFBPRi4gQnV0LCB3aGF0IGlm
IHRoZSBQT0YgYWxzbyBjYXVzZWQgb3RoZXIgbWVkaWEgc2VjdGlvbnMgdG8gY2hhbmdlPw0KDQpD
YW4geW91IGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlIG9mIGhvdyB0aGlzIG1pZ2h0IGhhcHBlbj8N
Cg0KL2ENCg==

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5BFDESESSMB209erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6
YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh
ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ
cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w
cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+
PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9
ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0
PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K
PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj5PbmUgZXhhbXBsZSBpcyBhIHZpZGVvIGVuY29kaW5nIGVuZ2lu
ZSwgdGhhdCBjYW4gaGFuZGxlIGEgY2VydGFpbiBudW1iZXIgb2YgbWFjcm8gYmxvY2tzIHBlciBz
ZWNvbmQuIEFzc3VtaW5nIG15IGV4aXN0aW5nIG0tIGxpbmVzIGFyZSB1c2luZyA3MCUsIGFuZCB0
aGUgbmV3IG0tIGxpbmUgd291bGQgcmVxdWlyZSA0MCUgbW9yZSwgSSBtYXkgaGF2ZSB0byBhZGp1
c3QNCiBzb21lIHByb3BlcnRpZXMgb2YgdGhlIGV4aXN0aW5nIG0tIGxpbmVzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T25lIGNhbiBvZiBjb3Vyc2UgYXNrIHdoZXRoZXIg
SSBzaG91bGQgZG8gdGhhdCBpbiB0aGUgQW5zd2VyIHRvIGJlZ2luIHdpdGgsIG9yIHNlbmQgYSBz
ZXBhcmF0ZSBPZmZlci4gSSBndWVzcyBpdCBkZXBlbmRzIG9uIGhvdyB0aW1lLWNyaXRpY2FsIHRo
ZSBjaGFuZ2UgaXMsIGhvdyB1c2VyIGV4cGVyaWVuY2Ugd291bGQgYmUgYWZmZWN0ZWQsIGV0Yy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCwgSSB0aGluayBpdCB3b3Vs
ZCBiZSBnb29kIHRvIG1lbnRpb24gaW4gdGhlIGRyYWZ0LCB0aGF0IHN1Y2ggc2NlbmFyaW8gY2Fu
IG9jY3VyLCBhbmQgaG93IGl0IGNhbiBiZSBkZWFsdCB3aXRoIChpdCBtYXkgYmUgb2J2aW91cyB0
byB1cywgYnV0IG5vdCB0aGUgZXZlcnlvbmUgZWxzZSBvdXQgdGhlcmUpLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW5kLCBhcyB3ZSBkaXNjdXNzZWQgZWFybGllciwgd2l0
aCBCVU5ETEUgdGhlIGNoYW5nZSBvZiBvbmUgbS0gbGluZSBtYXkgaW1wbGljaXRseSBjaGFuZ2Ug
b3RoZXIgbS0gbGluZXMuIEJ1dCwgdGhhdCBuZWVkcyB0byBiZSBzdHVkaWVkIGEgbGl0dGxlIG1v
cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEFkYW0gUm9hY2ggW21h
aWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIxLiBsb2tha3V1dGEg
MjAxMyAxNjo1ODxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc7IG1tdXNpY0BpZXRm
Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gUE9GL1BBTjogTmVlZCBmb3Ig
bW9yZSBtLSBsaW5lcyBpbiB0aGUgUEFOIHRoYW4gaW4gdGhlIGFzc29jaWF0ZWQgUE9GPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEwLzIx
LzEzIDA1OjA0LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl
IGZvbGxvd2luZyBpc3N1ZSBpcyByZWxhdGVkIHRvIHRoZSBjYXNlIHdoZXJlIGEgbWVkaWEgZGVz
Y3JpcHRpb24gaW4gYSBQT0YgaW1wbGljaXRseSBhZmZlY3Qgb3RoZXIgbWVkaWEgZGVzY3JpcHRp
b25zIChub3QgcHJlc2VudCBpbiB0aGUgUE9GKSwgYnV0IHRoaXMgZS1tYWlsIGxvb2tzIGF0IGEg
c2ltaWxhciBjYXNlIGZyb20gYSBQQU4gcGVyc3BlY3RpdmUuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlNlY3Rpb24gNS4zIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIHByZWNlZGlu
ZyBzdGVwcyBoYXZlIGJlZW4gcGVyZm9ybWVkIGZvciBlYWNoIG1lZGlhIHNlY3Rpb248L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i
c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRob3V0IHJlc3VsdGluZyBpbiBhIHJlamVj
dGlvbiwgdGhlbiB0aGUgYWdlbnQgZm9ybXMgYSBwYXJ0aWFsPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgYW5zd2VyIGNvbnNpc3Rpbmcgb2YgYSBzaW5nbGUgbz0gbGluZSwgYW5k
IGFsbCBvZiB0aGUgbWVkaWEgc2VjdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB0aGF0IHdlcmUgZ2VuZXJhdGVkIGFzIHBhcnQgb2YgdGhlIHByZWNlZGluZyBzdGVwcy4g
Tm90ZSB0aGF0IHRoaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm9jZXNz
aW5nIHdpbGwgYWx3YXlzIHlpZWxkIHRoZSBzYW1lIG51bWJlciBvZiBtZWRpYSBzZWN0aW9ucyBp
biBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFydGlhbCBhbnN3ZXIgYXMg
d2VyZSBwcmVzZW50IGluIHRoZSBwYXJ0aWFsIG9mZmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgUEFOIHdpbGwgY29udGFpbiB0aGUg
c2FtZSBudW1iZXIgb2YgbWVkaWEgc2VjdGlvbnMgYXMgdGhlIGFzc29jaWF0ZWQgUE9GLiBCdXQs
IHdoYXQgaWYgdGhlIFBPRiBhbHNvIGNhdXNlZCBvdGhlciBtZWRpYSBzZWN0aW9ucyB0byBjaGFu
Z2U/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCkNhbiB5b3UgZ2l2ZSBhIGNvbmNy
ZXRlIGV4YW1wbGUgb2YgaG93IHRoaXMgbWlnaHQgaGFwcGVuPzxicj4NCjxicj4NCi9hPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5BFDESESSMB209erics_--

From christer.holmberg@ericsson.com  Mon Oct 21 10:21: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 E8A4411E86BD for ; Mon, 21 Oct 2013 10:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.636
X-Spam-Level: 
X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=0.612,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBsAwU4Vx3gk for ; Mon, 21 Oct 2013 10:21:38 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D192311E86B5 for ; Mon, 21 Oct 2013 10:21:27 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-b5-5265629695c8
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.8B.16099.69265625; Mon, 21 Oct 2013 19:21:26 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 19:21:26 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: POF/PAN: New stream with port zero forbidden?
Thread-Index: Ac7OgfjA77+0GO2qTbek9EQ1ZYCQEQ==
Content-Class: urn:content-classes:message
Date: Mon, 21 Oct 2013 17:21:25 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E5ED6@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.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E5ED6ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje60pNQgg6f7NSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBu3VzIXrBKsuL32IGsD4zG+LkZODgkBE4k1bzcxQdhiEhfu rWcDsYUEDjNKfJ0b0sXIBWQvYZT403uEuYuRg4NNwEKi+582SI2IgLrE1709zCC2sICZxO6p jSwQcWuJGXceMEHYehLT1u0Es5kFtCR2TNjHCDKGRUBVYtMXRpAwr4CvxKMdF1lBbEagE76f WgNVLi5x68l8qNMEJJbsOc8MYYtKvHz8jxVkjISAksS0rWkQ5fkSZ6acZYIYKShxcuYTlgmM wrOQLJ6FZOosJC2zkLRAxPUkbkydwgZha0ssW/iaGcLWlZjx7xBUjbXE6bcrGJHVLGDkXMXI npuYmZNebriJERg5B7f81t3BeOqcyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUwmsj/1SyTzbEODbC9V/0ksLnBVuboSqPdy75s/2cfxfn/5MdXr728Q3WbH+76FzhP OWf6rU12ug9sggO8L0szH3X7d0JUKya3tNR+tZf7bKXmwMuVe4pm3WS42XLxjWtzqJCp+Kbq vxsunfNNiVu2Lp7xUqe6KcdZm8ilMZtVtN5xLJ+hN3+GEktxRqKhFnNRcSIAFcBqkGoCAAA=
Subject: [MMUSIC] POF/PAN: New stream with port zero forbidden?
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 Oct 2013 17:21:45 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5ED6ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



In section 5.3, the first sub-bullet of bullet 3 (new stream) says:



          "If the received media section contains a port number of zero,
          then the recipient MUST reject the partial offer as invalid
          behavior: this mechanism does not support the atomic addition
          and removal of the same stream."



Now, while I can't think of a use-case why anyone would send a POF with por=
t zero (for a new stream), what is the reason for forbidding it?



Regards,



Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5ED6ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <21D2DD78887ED54E8BE9A11422183ABE@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


 


In section 5.3, the first sub-bullet of bullet 3 (new stream) says:=



 


          "If the=
 received media section contains a port number of zero,

          then the recipient M=
UST reject the partial offer as invalid

          behavior: this mecha=
nism does not support the atomic addition

          and removal of the s=
ame stream."


 


Now, while I can't think of a use-case why anyone would send a=
 POF with port zero (for a new stream), what is the reason for forbidd=
ing it?


 


Regards,


 


Christer








--_000_7594FB04B1934943A5C02806D1A2204B1C4E5ED6ESESSMB209erics_--

From christer.holmberg@ericsson.com  Mon Oct 21 10:55: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 B558F11E8122 for ; Mon, 21 Oct 2013 10:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.354
X-Spam-Level: 
X-Spam-Status: No, score=-5.354 tagged_above=-999 required=5 tests=[AWL=0.294,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5btsGW824Mh for ; Mon, 21 Oct 2013 10:54:54 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0411E823F for ; Mon, 21 Oct 2013 10:54:30 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-cf-52656a549805
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.ED.16099.45A65625; Mon, 21 Oct 2013 19:54:29 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 19:54:28 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: POF/PAN: SDP group attribute in a POF/PAN?
Thread-Index: Ac7OhpamIvENB/S3QrGtxwOPSJ1SZw==
Content-Class: urn:content-classes:message
Date: Mon, 21 Oct 2013 17:54:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@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.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E5FB0ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW5oVmqQwfHrLBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvuu4+wFJ8UqHl/lbGA8KdTFyMkhIWAi8fTeOnYIW0ziwr31 bCC2kMBhRonJsxK7GLmA7CWMEn9efwBKcHCwCVhIdP/TBqkREVCX+Lq3hxnEFhYwlujsPcAG EbeQmL+ihxHC1pO48H47K4jNLKAlsWPCPrA4i4CqxJ9Lp8BsXgFfiXmnb4HdwAh0w/dTa5gg 6sUlbj2ZzwRxm4DEkj3nmSFsUYmXj/+xgpwjIaAkMW1rGkR5vsTOZ5+YIEYKSpyc+YRlAqPw LCSbZyGZOgtJyywkLRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7BFTDAWRbS7R9LUZWsoCRcxUj e25iZk56ueEmRmDcHNzyW3cH46lzIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAyPG5znHqC+EHP2SqA8Xn3nk8u/lV/s0UQSGHp1pbO9Kk5rc7y5/i773l6D6z5Wbd n9V8zOyqYSZRmVE/jn2OP7s+LmGn55ddRt5+b+dKfnu4vu8m68KdiycYL7xsWPTe8IXWuR/G doWxt6V2dKd+D2o9ZLGCdfqbBVNDpIwVxZeZ+c9m1noiosRSnJFoqMVcVJwIAO8SE5NpAgAA
Subject: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 17:55:02 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5FB0ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



The OPEN ISSUE in section 3 talks about how to deal with the SDP group attr=
ibute, which is a session-level information element (and, for that reason m=
ay not be allowed in a POF/PAN).



One of the issues is how to associate an m- line to a specific group, and t=
here are some ideas on how to identity to which group(s) an m- line is adde=
d, without having to include the group attribute associated with the group.



However, at least for BUNDLE it is not enough to be able to identity the gr=
oup: one also needs to specify the location of the m- line mid value in the=
 group:BUNDLE mid value list.



One suggestion is to indciate the group only for new streams, which may sol=
ve some issues.. But, at least for BUNDLE that could result in a glare, if =
there is more than one POF adding a new stream to the BUNDLE group (and the=
refore updating the group:BUNDLE attribute) at the same time.



Regards,



Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4E5FB0ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <34CA6D248D73AA4489B64A0F81A24B69@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


 


The OPEN ISSUE in section 3 talks about how to deal with the SDP group a=
ttribute, which is a session-level information element (and, for that reaso=
n may not be allowed in a POF/PAN).


 


One of the issues is how to associate an m- line to a specific grou=
p, and there are some ideas on how to identity to which group(s) an m- line=
 is added, without having to include the group attribute associated with th=
e group.


 


However, at least for BUNDLE it is not enough to be able to identity the=
 group: one also needs to specify the location of the m- line mid=
 value in the group:BUNDLE mid value list.


 


One suggestion is to indciate the group only for new streams, which may =
solve some issues.. But, at least for BUNDLE that could result in a glare, =
if there is more than one POF adding a new stream to the BUNDLE group&=
nbsp;(and therefore updating the group:BUNDLE
 attribute) at the same time.


 


Regards,


 


Christer






--_000_7594FB04B1934943A5C02806D1A2204B1C4E5FB0ESESSMB209erics_--

From partha@parthasarathi.co.in  Mon Oct 21 11:13: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 C2F6011E81D0 for ; Mon, 21 Oct 2013 11:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.457
X-Spam-Level: 
X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAP56AAo59VA for ; Mon, 21 Oct 2013 11:13:22 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id E9BAB11E836C for ; Mon, 21 Oct 2013 11:13:21 -0700 (PDT)
Received: from userPC (unknown [122.179.74.220]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 8CF99639035; Mon, 21 Oct 2013 18:13:15 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382379200; bh=vQrgTrQ2aOKmQqACAK/0jrmvl/ulunxST4LX4Ipb9X8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=F8fa3K9qRBU7yh03+mmA6Lf9Pvl0unPMoBAaQ4uHlaiv0UfE3GS7F2RaeKxWilwYu TCkPPy6KhtiA87QeZIhkvZpoyzkICwFKp4XBdE36N+9wIjj+cUU/bLhPcm4+39zGGd izv0OYLe8IJ8QmRkZLQzz30SWoQBaJS6wyBjenYk=
From: "Parthasarathi R" 
To: "'Adam Roach'" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se> <52617EF3.8040705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se> <526187AC.8060200@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in>  <001d01cecdbe$e81edc60$b85c9520$@co.in> <5264209F.6020301@nostrum.com>
In-Reply-To: <5264209F.6020301@nostrum.com>
Date: Mon, 21 Oct 2013 23:43:11 +0530
Message-ID: <00a001cece89$380b7740$a82265c0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7NwjXIpOsrdvCdRquKd7GsU17YMQAwYxdA
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020204.52656EC0.01C1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Cc: mmusic@ietf.org, 'Paul Kyzivat' , 'Christer Holmberg' 
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 18:13:40 -0000

Hi Adam,

The cross wire scenario of full offer and partial offer (POF) has to be =
considered as full glare and has to be handled by higher protocol. In =
terms of SIP(higher protocol), the full glare situation has to be =
handled in UPDATE/INFO as sec 4.2 recommends in POF&PAN draft. In case =
the content-disposition is "partial-session" [note 1] for POF, UPDATE =
glare handling will not kick start in SIP full offer side as per Sec 5.2 =
of RFC 3311 [note 2] and also, INFO has no glare handling in SIP. Could =
you please explain how the full offer and partial offer glare is handled =
for SIP.=20

BTW, I would agree with you in case POA&PAN draft recommends for =
Re-INVITE for POF as 491 handling for RE-INVITE happens without depends =
upon offer.  =20

Thanks
Partha

Note 1: (Initial mail)
Let us assume content-disposition "partial-session" for partial =
offer/answer exist. So, RFC 3264 does not applies for "partial-session".

Note 2:=20
If an UPDATE is received that contains an offer, and the UAS has
   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response.


> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Sunday, October 20, 2013 11:58 PM
> To: Parthasarathi R
> Cc: 'Paul Kyzivat'; 'Christer Holmberg'; mmusic@ietf.org
> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value
>=20
> On 10/20/13 13:04, Parthasarathi R wrote:
> > I'm looking for the interaction between full offer and partial offer
> glare
> > situation. In the current draft, Sec 6.5.2 & Sec 6.6.2 deals with
> partial
> > offer/answer situation only.
> >
> Perhaps adding examples was a mistake. The examples are supposed to
> help
> with comprehension, but they do not form a part of the specification.
>=20
> Really, this situation is intended to be covered in section 5.6: a
> partial offer crossing the wire with a full offer is a full glare
> situation. Neither is put into effect, and whatever procedures the
> higher-level protocol says to do to resolve glare are undertaken [1].
>=20
> If you think there's any specific ambiguity here, please point it out;
> in particular, talk about how two different implementors might read
> this
> and reasonably do two incompatible things.
>=20
> /a
>=20
> ___
> [1] For SIP, these procedures involve 491 responses and the timer
> described in RFC 3261 section 14.1, but we're not necessarily
> considering partial for SIP at the moment.


From partha@parthasarathi.co.in  Mon Oct 21 11:29: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 0D54811E8441 for ; Mon, 21 Oct 2013 11:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.018
X-Spam-Level: 
X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.247,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUdEkHQJJdUc for ; Mon, 21 Oct 2013 11:28:51 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id 109DB11E84EE for ; Mon, 21 Oct 2013 11:28:48 -0700 (PDT)
Received: from userPC (unknown [122.179.74.220]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id AF250639035; Mon, 21 Oct 2013 18:28:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382380128; bh=waw19atRprWoSQlAly0NV+TP85xFiM89RtL+KsiEKLg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZPhUkD4Fyj0biyNwqzjMsdJH3WNfLaJIffMF5rUmgCQaWtK+Yvfja0ZyPs3IIkG2R NdesVjmFXXIU1yyCoe0RNcah0VNzQchKVXVRUylaJHYCfbOwdQsuIWz2e5n80XGXtR ZnLS/E/nkEtcjGxPR81OKllB87IzberQnLbpHmrg=
From: "Parthasarathi R" 
To: "'Paul Kyzivat'" 
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>	<52617EF3.8040705@alum.mit.edu>	<7594FB04B1934943A5C02806D1A2204B1C4C309C@ESESSMB209.ericsson.se>	<526187AC.8060200@nostrum.com>	<7594FB04B1934943A5C02806D1A2204B1C4C338F@ESESSMB209.ericsson.se> <52619FCC.3090606@alum.mit.edu> <001901cecdb6$d49f6180$7dde2480$@co.in> <526437AF.1070002@alum.mit.edu>
In-Reply-To: <526437AF.1070002@alum.mit.edu>
Date: Mon, 21 Oct 2013 23:58:41 +0530
Message-ID: <00a201cece8b$60ac6590$220530b0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Nz9B7GDRjbzlQSdOzBPB3sgg7CAAuX+xA
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020209.52657260.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 18:29:05 -0000

Paul,

Please read inline.

Thanks
Partha

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Monday, October 21, 2013 1:36 AM
> To: Parthasarathi R
> Cc: 'Christer Holmberg'; mmusic@ietf.org
> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> value
> 
> On 10/20/13 1:07 PM, Parthasarathi R wrote:
> > Paul,
> >
> >> Maybe you are right. Then sip will go the way of h323 while the
> world
> >> moves on to webrtc.
> >
> > It is amazing to hear from you that h323 way of media negotiation is
> better
> > than SIP now :-)
> 
> Even though you included a smiley, I think maybe you didn't understand
> how I meant that statement. 
 You are right. I thought your statement that SIP will adopt H.323
media negotiation model while move to WebRTC. 

I didn't intend to suggest that sip should
> adopt any new behavior from h323. I meant that then sip may become old
> and obsolete, the way h323 is. (Some think it already has. It certainly
> is working on it.)
 I sense the same. while SIP was picking up, ISUP was transported in
SIP (SIP-I/T). Now, SIP is transported in WebSocket while WebSocket is
picking up. The history may repeat. 

> 
> 	Thanks,
> 	Paul
> 
> > Let us assume content-disposition "partial-session" for partial
> offer/answer
> > exist. So, RFC 3264 does not applies for "partial-session". How the
> normal
> > interaction and race condition between "session" and "partial-
> session" will
> > be handled as both impact the same session in the media layer? Could
> you
> > please explain.
> >
> > Thanks
> > Partha
> >
> >
> >
> >> -----Original Message-----
> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> Behalf Of Paul Kyzivat
> >> Sent: Saturday, October 19, 2013 2:24 AM
> >> To: Christer Holmberg
> >> Cc: mmusic@ietf.org
> >> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
> >> value
> >>
> >> On 10/18/13 4:44 PM, Christer Holmberg wrote:
> >>> Hi,
> >>>
> >>>>> Content-Disposition does not apply to intermediaries. So, a proxy
> >> that
> >>>>> only understands application/sdp (e.g. for gate control purpose)
> >> will
> >>>>> not even look at the C-D header field value for other bodies.
> And,
> >>>>> unless such proxy understands POF/PAN, there may not be any media
> >>>>> passing through...
> >>>>
> >>>> Right. A middlebox that doesn't understand application/sdpfrag
> won't
> >> know to look at its contents and let the new streams through. And a
> >> middlebox that sees
> >>>> something marked as "application/sdp" that conveys only a tiny
> >> fraction of the session will probably be just as catastrophic; I
> would
> >> imagine everything but the
> >>>> modified streams would be shut off. There's no way to win here.
> >>>
> >>> I think it would reject the Offer - at least that's what it should
> do
> >> according to 3264.
> >>
> >> 3264 only talks about how to process offers and answers described in
> >> SDP. It does not say how those are conveyed in sip. 3261 says that
> they
> >> are carried in body parts of content-type application/sdp with
> >> content-disposition of 'session'. If a body part has content-type
> >> application/sdp but has a disposition other than 'session' then it
> >> isn't
> >> an offer or answer according to 3261, and so 3264 doesn't apply.
> >>
> >>>> At some point, we have to come to peace with the fact that any
> >> middleboxes that aren't primarily in the business of stifling
> progress
> >> will need to keep pace with protocol extensions as they get
> deployed.
> >>>
> >>> I really wish things worked that way :)
> >>
> >> So progress ends because middleboxes don't permit it?
> >>
> >> Maybe you are right. Then sip will go the way of h323 while the
> world
> >> moves on to webrtc.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> >


From partha@parthasarathi.co.in  Mon Oct 21 11:29: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 5B42111E8493 for ; Mon, 21 Oct 2013 11:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Level: 
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.225,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vspKDBMeiO9x for ; Mon, 21 Oct 2013 11:29:36 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2996D11E84EE for ; Mon, 21 Oct 2013 11:29:32 -0700 (PDT)
Received: from userPC (unknown [122.179.74.220]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 53F636390F7; Mon, 21 Oct 2013 18:29:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382380171; bh=CyoHe1yIMlfSbUhA9F9/VPAFtUUeKjw8umS7eyEIAK8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=J20nx0PYXQlViT9u6j1ltKwyM4oNLojKaQEetZdaPy5vMRUwnrnI0OoIg/aB9MazL 74imnwuqI9cw/1C0aI5cjh31icffvOSDHHETC8dGJYgpvcPgfO2v3IZdS4aX4aL2Uk hkIXgzPOspLAJmdYVcHf1QsbDphUpI2F5+/bUz+c=
From: "Parthasarathi R" 
To: "'Emil Ivov'" , "'Christer Holmberg'" , 
Date: Mon, 21 Oct 2013 23:59:23 +0530
Message-ID: <00a401cece8b$7b00f780$7102e680$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feA==
Content-Language: en-us
X-CTCH-RefID: str=0001.0A02020A.5265728B.022E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 2
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Cc: mmusic@ietf.org
Subject: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Mon, 21 Oct 2013 18:29:40 -0000

Hi all,

I have mailed earlier why SIP INFO is not the right choice for Trickle ICE
in
http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html. The main
reason is the glare handling. I have added the callflow in Sec 6.4 of
draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will look for
Trickle ICE handling in SIP w.r.t JSEP mapping. Could you please explain how
glare with Trickle ICE Info package will be handled.

Thanks
Partha



From emcho@sip-communicator.org  Mon Oct 21 12:07: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 9992411E86E6 for ; Mon, 21 Oct 2013 12:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXmq1m31venx for ; Mon, 21 Oct 2013 12:07:01 -0700 (PDT)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id AEEF211E86E3 for ; Mon, 21 Oct 2013 12:03:17 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id wy17so4435401pbc.25 for ; Mon, 21 Oct 2013 12:03:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=LIVzneut62veHfD/UfzWwLHkyRb7ZZFNZd3DiiZQRvc=; b=aY03e55A6j1cCf397BuD95T06P7yyAYQvRQLc1QEdCqKtFgXz8DOrd4WLxDm6zS63H VmhmldysMHyyRTYWEguddhmvfCe1p7r3YBWyOU3yHoLEfUmPo8N1eVCxBQe7eoVL+i/0 oK8hPvIhADD/GRtC0x4OozKcSi9/0hgz1b8r7HWnRX3Xw4DbTQA8mph++1U01Rqp0yR6 HmCQZqQHQGDy8m/hhPjZH+Y1rUmjKkuzSYwSVDtUk5KLTU8F4RzHpaR5STMRbHAlX66D cZxLvaldRmcOow/Ujz3fRyQMEJ8Z1QumbgMvIaN9Nl8zWE+7IxHW8Dj/a+k+AfayEx6f KjxA==
X-Gm-Message-State: ALoCoQkjgzqgyzWJ72oSbxqs/7SpovgNpmHELN3evDNuvnr3moQHLpGmRfPGDpFjbtx0jVmQ6roE
X-Received: by 10.66.177.71 with SMTP id co7mr3129930pac.181.1382382186501; Mon, 21 Oct 2013 12:03:06 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [2607:f8b0:400e:c02::22d]) by mx.google.com with ESMTPSA id ed3sm22580128pbc.6.2013.10.21.12.03.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 12:03:05 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id r10so5820302pdi.4 for ; Mon, 21 Oct 2013 12:03:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.164.165 with SMTP id yr5mr4176513pbb.146.1382382185653; Mon, 21 Oct 2013 12:03:05 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Mon, 21 Oct 2013 12:03:05 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Mon, 21 Oct 2013 12:03:05 -0700 (PDT)
Date: Mon, 21 Oct 2013 21:03:05 +0200
Message-ID: 
From: Emil Ivov 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=047d7b10c92f1ed0b904e944ef67
Cc: mmusic 
Subject: [MMUSIC] How trickle ICE and INFO relate to O/A (Was: Partial Offer/Partial Answer draft - MIME type value)
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 Oct 2013 19:07:06 -0000

--047d7b10c92f1ed0b904e944ef67
Content-Type: text/plain; charset=ISO-8859-1

Paul, Christer,

On that we agree. There are relationships between the trickle and O/A and
they need to be explored.

We'll update the document shortly in order to reflect what seemed like
consensus in the beginning of the summer and we'll take it from there.

I do agree with Paul that some clarifications might be needed in Vanilla
ICE as well. I'll follow up on that in the following days.

Emil

--sent from my mobile
On 21 Oct 2013 15:53, "Paul Kyzivat"  wrote:

> Emil,
>
> I'm open to your arguments that there is reason to have trickle ICE
> alongside O/A and POF/PAN.
>
> But then we must recognize that these all have interactions with one
> another. Rather than just ignore them, or hand wave, ISTM that these need
> to be specified. It introduces complexity, and dealing with that is part of
> the job.
>
> Vanilla ICE specifies the interactions between O/A and the discovery of
> candidates via ICE itself. But should it be updated to talk about all these
> other mechanisms as well? If not, where should those be documented? Should
> trickle ICE discuss interactions with POF/PAN, or should POF/PAN discuss
> interactions with trickle ICE, or both?
>
>         Thanks,
>         Paul
>
> On 10/20/13 9:03 PM, Emil Ivov wrote:
>
>> On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat 
>> wrote:
>>
>>> On 10/20/13 4:23 PM, Emil Ivov wrote:
>>>
>>>>
>>>> One more thought:
>>>>
>>>> Please understand that trickle ICE is NOT a session modification.
>>>>
>>>
>>>
>>> Isn't the session modified as a result of the trickle ICE? (E.g., end up
>>> using a different media address than it otherwise would have.)
>>>
>>> And the use of trickle ICE can (I think) require that a subsequent offer
>>> be
>>> sent (or answered) differently than it would had trickle ice not been
>>> used.
>>>
>>
>> The above statements are also true for vanilla ICE and peer reflexive
>> candidates, where ICE processing not reflected in SDP can already lead
>> to potential changes of addresses. If the change occurs, then an O/A
>> would follow. Currently Trickle ICE works along these exact same
>> lines.
>>
>>  And AFAIK everything that can be accomplished with trickle ICE could
>>> also be
>>> accomplished with Partial Offer/Answer.
>>>
>>
>> I already agreed that it is implementable ... the point is that it
>> would be *incredibly inconvenient*. I already gave a few reasons
>> earlier in this thread, let's try again:
>>
>> * there would be an extremely high glare probability (which is
>> perfectly avoidable without O/A), * there would be a lot of added
>> complexity. Imagine POFs / PANs that send additional candidates *and*
>> change codecs and/or add/remove streams.
>> *  it would be very clumsy: after trickling candidates with a POF,
>> agents would block and wait for a PAN before they can do it again
>> * POF/PAN would be a dependency for trickle and there is no reason for it
>> to be.
>> * In Berlin we agreed that we are adopting Unified for WebRTC cases.
>> There are Plan B and No Plan style implementations out there and my
>> understanding is that they have not been outlawed. Such
>> implementations would be unlikely to adopt POF/PAN. Yet, it would be
>> great if we made it possible for them to still use Trickle ICE.
>>
>> The disadvantages aside:
>>
>> Why would we want to do it this way?
>> What would we hope to gain?
>>
>>  So the differences aren't functional
>>> ones.
>>> I presume that trickle ICE is expected to be faster, and/or easier to
>>> implement. (But easier to implement becomes moot if both need to be
>>> implemented.)
>>>
>>
>> I can promise you that it doesn't. You don't have to take my word for
>> it. Just try and implement it.
>>
>>  In my book those justify considering it a session modification.
>>>
>>
>> Let's not take things out of context. Christer's point was that
>> because it is a session modification, it has to be done in
>> Offer/Answer.
>>
>> This is wrong.
>>
>> You can consider it a session modification if you like but it is not
>> the kind that requires Offer/Answer. Vanilla ICE proves this.
>>
>> Emil
>>
>>
>>
>>
>>
>>
>>           Thanks,
>>>          Paul
>>>
>>>  Please
>>>> try to isolate the SDP syntax that it uses from general O/A. It is not
>>>> part of it.
>>>>
>>>> Think of it as JSON if that would make thinks easier.
>>>>
>>>> Emil
>>>>
>>>> --sent from my mobile
>>>>
>>>> On 20 Oct 2013 22:18, "Emil Ivov" >>> > wrote:
>>>>
>>>>      Christer, "I tried to explain" to you that what you are saying has
>>>>      been addressed and cannot happen. If you believe that there is a
>>>>      specific situation that is still possible and is a problem, then
>>>>      please describe that rather than continuing to suggest that things
>>>>      don't work without any valid arguments whatsoever.
>>>>
>>>>      --sent from my mobile
>>>>
>>>>      On 20 Oct 2013 21:50, "Christer Holmberg"
>>>>      
>>>>      >>
>>>> wrote:
>>>>
>>>>
>>>>          Hi,
>>>>
>>>>           >> Example:
>>>>           >>
>>>>           >> 1. Alice sends an SDP Offer to Bob.
>>>>           >>
>>>>           >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>>>>          and C.
>>>>           >>
>>>>           >> 3. After that, Bob sends, using trickle ICE, candidates D
>>>>          and E to Alice.
>>>>           >>
>>>>           >> If Alice receives the SDP Answer first, and then the
>>>> trickle
>>>>          ICE request, she will assume that Bob first provided candidates
>>>>          A, B and C (in the SDP Answer), and then added D and E (in the
>>>>          trickle ICE request).
>>>>           >>
>>>>           >> If Alice receives the trickle ICE request first, and then
>>>>          the SDP Answer
>>>>           >
>>>>           > Don't do that then.
>>>>           >
>>>>           > It's been pretty clear from the start that any session
>>>>          *modification* mechanism that does not also contain the full
>>>>          session state completely falls apart in the face of unordered
>>>>          delivery. This is a fundamental information problem, and you
>>>>          aren't going to write rules that somehow cause it not to be
>>>> true.
>>>>           >
>>>>           > We haven't yet tackled how to send trickle ICE in SIP, much
>>>>          less partial offers and partial answers. When we do, the only
>>>>          way it's going to have any chance of working at all is by
>>>>          requiring ordered delivery.
>>>>
>>>>          I totally agree, and my opinion (which I tried to explain to
>>>>          Emil) is that it applies also to candidates.
>>>>
>>>>          Regards,
>>>>
>>>>          Christer
>>>>
>>>>
>>>
>>
>>
>>
> ______________________________**_________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/**listinfo/mmusic
>

--047d7b10c92f1ed0b904e944ef67
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Paul, Christer,


On that we agree. There are relationships between the trickl=
e and O/A and they need to be explored. 


We'll update the document shortly in order to reflect wh=
at seemed like consensus in the beginning of the summer and we'll take =
it from there.


I do agree with Paul that some clarifications might be neede=
d in Vanilla ICE as well. I'll follow up on that in the following days.=



Emil


--sent from my mobile


On 21 Oct 2013 15:53, "Paul Kyzivat" &=
lt;pkyzivat@alum.mit.edu> w=
rote:

Emil,



I'm open to your arguments that there is reason to have trickle ICE alo=
ngside O/A and POF/PAN.



But then we must recognize that these all have interactions with one anothe=
r. Rather than just ignore them, or hand wave, ISTM that these need to be s=
pecified. It introduces complexity, and dealing with that is part of the jo=
b.




Vanilla ICE specifies the interactions between O/A and the discovery of can=
didates via ICE itself. But should it be updated to talk about all these ot=
her mechanisms as well? If not, where should those be documented? Should tr=
ickle ICE discuss interactions with POF/PAN, or should POF/PAN discuss inte=
ractions with trickle ICE, or both?




=A0 =A0 =A0 =A0 Thanks,

=A0 =A0 =A0 =A0 Paul



On 10/20/13 9:03 PM, Emil Ivov wrote:



On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:



On 10/20/13 4:23 PM, Emil Ivov wrote:





One more thought:



Please understand that trickle ICE is NOT a session modification.







Isn't the session modified as a result of the trickle ICE? (E.g., end u=
p

using a different media address than it otherwise would have.)



And the use of trickle ICE can (I think) require that a subsequent offer be=


sent (or answered) differently than it would had trickle ice not been used.=






The above statements are also true for vanilla ICE and peer reflexive

candidates, where ICE processing not reflected in SDP can already lead

to potential changes of addresses. If the change occurs, then an O/A

would follow. Currently Trickle ICE works along these exact same

lines.





And AFAIK everything that can be accomplished with trickle ICE could also b=
e

accomplished with Partial Offer/Answer.





I already agreed that it is implementable ... the point is that it

would be *incredibly inconvenient*. I already gave a few reasons

earlier in this thread, let's try again:



* there would be an extremely high glare probability (which is

perfectly avoidable without O/A), * there would be a lot of added

complexity. Imagine POFs / PANs that send additional candidates *and*

change codecs and/or add/remove streams.

* =A0it would be very clumsy: after trickling candidates with a POF,

agents would block and wait for a PAN before they can do it again

* POF/PAN would be a dependency for trickle and there is no reason for it t=
o be.

* In Berlin we agreed that we are adopting Unified for WebRTC cases.

There are Plan B and No Plan style implementations out there and my

understanding is that they have not been outlawed. Such

implementations would be unlikely to adopt POF/PAN. Yet, it would be

great if we made it possible for them to still use Trickle ICE.



The disadvantages aside:



Why would we want to do it this way?

What would we hope to gain?





So the differences aren't functional

ones.

I presume that trickle ICE is expected to be faster, and/or easier to

implement. (But easier to implement becomes moot if both need to be

implemented.)





I can promise you that it doesn't. You don't have to take my word f=
or

it. Just try and implement it.





In my book those justify considering it a session modification.





Let's not take things out of context. Christer's point was that

because it is a session modification, it has to be done in

Offer/Answer.



This is wrong.



You can consider it a session modification if you like but it is not

the kind that requires Offer/Answer. Vanilla ICE proves this.



Emil















=A0 =A0 =A0 =A0 =A0Thanks,

=A0 =A0 =A0 =A0 =A0Paul





Please

try to isolate the SDP syntax that it uses from general O/A. It is not

part of it.



Think of it as JSON if that would make thinks easier.



Emil



--sent from my mobile



On 20 Oct 2013 22:18, "Emil Ivov" <emcho@jitsi.org

<mailto:emcho@jitsi=
.org>> wrote:



=A0 =A0 =A0Christer, "I tried to explain" to you that what you ar=
e saying has

=A0 =A0 =A0been addressed and cannot happen. If you believe that there is a=


=A0 =A0 =A0specific situation that is still possible and is a problem, then=


=A0 =A0 =A0please describe that rather than continuing to suggest that thin=
gs

=A0 =A0 =A0don't work without any valid arguments whatsoever.



=A0 =A0 =A0--sent from my mobile



=A0 =A0 =A0On 20 Oct 2013 21:50, "Christer Holmberg"

=A0 =A0 =A0<christer.holmberg@ericsson.com

=A0 =A0 =A0<mailto:christer.holmberg@ericsson.com>> wrote:





=A0 =A0 =A0 =A0 =A0Hi,



=A0 =A0 =A0 =A0 =A0 >> Example:

=A0 =A0 =A0 =A0 =A0 >>

=A0 =A0 =A0 =A0 =A0 >> 1. Alice sends an SDP Offer to Bob.

=A0 =A0 =A0 =A0 =A0 >>

=A0 =A0 =A0 =A0 =A0 >> 2. Bob sends the SDP Answer to Alice, with can=
didates A, B

=A0 =A0 =A0 =A0 =A0and C.

=A0 =A0 =A0 =A0 =A0 >>

=A0 =A0 =A0 =A0 =A0 >> 3. After that, Bob sends, using trickle ICE, c=
andidates D

=A0 =A0 =A0 =A0 =A0and E to Alice.

=A0 =A0 =A0 =A0 =A0 >>

=A0 =A0 =A0 =A0 =A0 >> If Alice receives the SDP Answer first, and th=
en the trickle

=A0 =A0 =A0 =A0 =A0ICE request, she will assume that Bob first provided can=
didates

=A0 =A0 =A0 =A0 =A0A, B and C (in the SDP Answer), and then added D and E (=
in the

=A0 =A0 =A0 =A0 =A0trickle ICE request).

=A0 =A0 =A0 =A0 =A0 >>

=A0 =A0 =A0 =A0 =A0 >> If Alice receives the trickle ICE request firs=
t, and then

=A0 =A0 =A0 =A0 =A0the SDP Answer

=A0 =A0 =A0 =A0 =A0 >

=A0 =A0 =A0 =A0 =A0 > Don't do that then.

=A0 =A0 =A0 =A0 =A0 >

=A0 =A0 =A0 =A0 =A0 > It's been pretty clear from the start that any=
 session

=A0 =A0 =A0 =A0 =A0*modification* mechanism that does not also contain the =
full

=A0 =A0 =A0 =A0 =A0session state completely falls apart in the face of unor=
dered

=A0 =A0 =A0 =A0 =A0delivery. This is a fundamental information problem, and=
 you

=A0 =A0 =A0 =A0 =A0aren't going to write rules that somehow cause it no=
t to be true.

=A0 =A0 =A0 =A0 =A0 >

=A0 =A0 =A0 =A0 =A0 > We haven't yet tackled how to send trickle ICE=
 in SIP, much

=A0 =A0 =A0 =A0 =A0less partial offers and partial answers. When we do, the=
 only

=A0 =A0 =A0 =A0 =A0way it's going to have any chance of working at all =
is by

=A0 =A0 =A0 =A0 =A0requiring ordered delivery.



=A0 =A0 =A0 =A0 =A0I totally agree, and my opinion (which I tried to explai=
n to

=A0 =A0 =A0 =A0 =A0Emil) is that it applies also to candidates.



=A0 =A0 =A0 =A0 =A0Regards,



=A0 =A0 =A0 =A0 =A0Christer



















_______________________________________________

mmusic mailing list

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




--047d7b10c92f1ed0b904e944ef67--

From emcho@sip-communicator.org  Mon Oct 21 12:13: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 8F78611E86EF for ; Mon, 21 Oct 2013 12:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipPeDnEgitkK for ; Mon, 21 Oct 2013 12:13:48 -0700 (PDT)
Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 936FC11E824A for ; Mon, 21 Oct 2013 12:13:00 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id uo15so5957719pbc.23 for ; Mon, 21 Oct 2013 12:13:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HhZPIGnSHrJ/IBvKoj5cLd4bfFbZz3jxrwgW+5oBQnk=; b=g1tHbbl3gXh0AfmuIhqBu1O+dDl15zSibKw7lSWtGFDG+zbKx7rX7/sxciY5M6kFy0 K/trPhNZJvU9hzHQDW0Udeh7dcxXt/n/Xv+A9W1dIvikWomxVKzGvoF0RgWXtHSsaUsg QcfthWevEabmdPIgOCqOJ1ONZ4fLhHrOwLoWwAH+D2w9QfhTKkfs4B+EzCMmdxKO+eCZ AKaBp5wHwnebAmiyfBoV0uiB+03Zoo7J3VSXjOzBLIRrKWyHHptvc+JP5r9BAZonSVqP uMh2IH6sTeoiB/63JwijQjLFWHCI0eEZlM9C+rNS39dUPpwO8prWRFBkJBzLjYA31+bd NTNQ==
X-Gm-Message-State: ALoCoQkG4s2fZ430g3q14EtNuH1mBV3VNQ26Ve1Ev8qUstPWB1c+UjbmG9W7ZWoPnJV3pN//izx3
X-Received: by 10.68.139.168 with SMTP id qz8mr19084358pbb.1.1382382780218; Mon, 21 Oct 2013 12:13:00 -0700 (PDT)
Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [2607:f8b0:400e:c01::22c]) by mx.google.com with ESMTPSA id y5sm22594023pbs.18.2013.10.21.12.12.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 12:12:59 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id xa7so7445627pbc.31 for ; Mon, 21 Oct 2013 12:12:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.25.170 with SMTP id d10mr19352787pbg.78.1382382779202; Mon, 21 Oct 2013 12:12:59 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Mon, 21 Oct 2013 12:12:59 -0700 (PDT)
Received: by 10.66.191.163 with HTTP; Mon, 21 Oct 2013 12:12:59 -0700 (PDT)
In-Reply-To: <52651780.60108@ericsson.com>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>
Date: Mon, 21 Oct 2013 21:12:59 +0200
Message-ID: 
From: Emil Ivov 
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
Content-Type: multipart/alternative; boundary=bcaec520e8757fb56104e9451215
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 19:13:52 -0000

--bcaec520e8757fb56104e9451215
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I still don't get it. Why would we recommend values for different
applications? We already tell applications to pace checks in accordance
with expected traffic, which they supposedly can gauge better than the text
in our RFC.

A minimum value does make sense because it would basically say: "don't go
below this value or you might brake the network or otherwise cause harm".
That's actually useful advice.

Now, having two such values starts being weird again, unless we have data
that shoes that networks break differently depending on the UDP payload or
port number or whatever.

--sent from my mobile
On 21 Oct 2013 14:01, "Ari Ker=E4nen"  wrote:

> On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
>
>> On Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>>
>>> On 18.10.13, 19:30, Adam Roach wrote:
>>>
>>>> On 10/18/13 09:44, Emil Ivov wrote:
>>>>
>>>>> It might be worth reminding exactly what these 50ms would be
>>>>> protecting us against
>>>>>
>>>>
>>>> They're protecting us against RTP arriving at a rate of 20ms per
>>>> packet.
>>>>
>>>
>>> That would indeed be one of the reasons to pace checks (in addition
>>> to fragile NAT boxes IIRC), however in either case, I fail to
>>> realise why we need a different pacing strategy for non-RTP. This
>>> is what I was asking about.
>>>
>>> Connectivity check hammers can still resort to RTP if the pacing
>>> timer is their only problem and I don't see why shaky NATs would
>>> tolerate a 20ms rate for RTP but only a 50ms for anything else.
>>>
>>> This entire separation sounds quite arbitrary right now. I see why
>>> we would pick a value that we consider somewhat safe and secure but
>>> I don't understand why we would need two!?
>>>
>>
>> I agree. No need to add more complexity. ICE should be ignorant of
>> what traffic goes through the pinholes.
>>
>
> The idea would be to have one recommended value (or set of) for all kinds
> of traffic but with RTP you would have this "additional piece of
> information" (due to the knowledge of your traffic pattern and the formul=
a
> to relate that to pacing) that would allow you to go below the conservati=
ve
> recommended value. If you would have something similar with non-RTP
> traffic, you could use that.
>
> But then for both endpoints agreeing on the value in order to have
> connectivity checks happening simultaneously for the same pairs, we'd
> probably need to do some negotiation, similar to what was done with ICE o=
n
> HIP (http://tools.ietf.org/html/**rfc5770#section-4.4
> ).
>
>
> Cheers,
> Ari
>

--bcaec520e8757fb56104e9451215
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I still don't get it. Why would we recommend values for =
different applications? We already tell applications to pace checks in acco=
rdance with expected traffic, which they supposedly can gauge better than t=
he text in our RFC.



A minimum value does make sense because it would basically s=
ay: "don't go below this value or you might brake the network or o=
therwise cause harm". That's actually useful advice.


Now, having two such values starts being weird again, unless=
 we have data that shoes that networks break differently depending on the U=
DP payload or port number or whatever.


--sent from my mobile


On 21 Oct 2013 14:01, "Ari Ker=E4nen" =
<ari.keranen@ericsson.com> wrote:

On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:



On Oct 19, 2013, at 05:33 AM, Emil Ivov <emcho@jitsi.org> wrote:



On 18.10.13, 19:30, Adam Roach wrote:



On 10/18/13 09:44, Emil Ivov wrote:



It might be worth reminding exactly what these 50ms would be

protecting us against





They're protecting us against RTP arriving at a rate of 20ms per

packet.





That would indeed be one of the reasons to pace checks (in addition

to fragile NAT boxes IIRC), however in either case, I fail to

realise why we need a different pacing strategy for non-RTP. This

is what I was asking about.



Connectivity check hammers can still resort to RTP if the pacing

timer is their only problem and I don't see why shaky NATs would

tolerate a 20ms rate for RTP but only a 50ms for anything else.



This entire separation sounds quite arbitrary right now. I see why

we would pick a value that we consider somewhat safe and secure but

I don't understand why we would need two!?





I agree. No need to add more complexity. ICE should be ignorant of

what traffic goes through the pinholes.





The idea would be to have one recommended value (or set of) for all kinds o=
f traffic but with RTP you would have this "additional piece of inform=
ation" (due to the knowledge of your traffic pattern and the formula t=
o relate that to pacing) that would allow you to go below the conservative =
recommended value. If you would have something similar with non-RTP traffic=
, you could use that.




But then for both endpoints agreeing on the value in order to have connecti=
vity checks happening simultaneously for the same pairs, we'd probably =
need to do some negotiation, similar to what was done with ICE on HIP (ht=
tp://tools.ietf.org/html/rfc5770#section-4.4).






Cheers,

Ari




--bcaec520e8757fb56104e9451215--

From christer.holmberg@ericsson.com  Mon Oct 21 12:14: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 5424A11E870A for ; Mon, 21 Oct 2013 12:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.658
X-Spam-Level: 
X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=0.590,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XEaO6XsAPab for ; Mon, 21 Oct 2013 12:14:05 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 63A8E11E86CD for ; Mon, 21 Oct 2013 12:13:05 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-97-52657cc081e3
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.E2.16099.0CC75625; Mon, 21 Oct 2013 21:13:04 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 21:13:03 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
Thread-Index: AQHOzmT9AmgtOoxHq0W2DgjzT8BLSZn/hWKmgAAA9AY=
Date: Mon, 21 Oct 2013 19:13:02 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E60F2@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1C4D6F06@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4D8F8A@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4DA0FA@ESESSMB209.ericsson.se> <52642EB8.3060203@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4DDC7D@ESESSMB209.ericsson.se>   <52644342.2040605@alum.mit.edu> , <526531D2.3090503@alum.mit.edu>
In-Reply-To: <526531D2.3090503@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E60F2ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje6BmtQggyNX+S2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujaeti5oJ/sxgr3m6dztzA+KS+i5GTQ0LA ROLpv3mMELaYxIV769m6GLk4hAQOM0rcfLOBEcJZwiix+2UnUxcjBwebgIVE9z9tkAYRAV+J Z49vs4HYwgJeEv++z2GFiHtL/L9/lQXCtpJoXf4BLM4ioCoxZW4rWJwXqHfhhU3sILaQwDt2 iakdTiA2p4COxMxHs8BqGIEO+n5qDROIzSwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXkNAkB JYlpW9MgyvMlWqbdYoJYJShxcuYTlgmMIrOQTJqFpGwWkjKIuJ7EjalT2CBsbYllC18zQ9i6 EjP+HYKqsZZ4cmMCI7KaBYwcqxjZcxMzc9LLDTcxAmPq4JbfujsYT50TOcQozcGiJM774a1z kJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGmeFTZ8zcLCUqUD2HI23JL33zeTXfpJdfyV5T kMwscoH/1wbrC/ei5SY88+uTWl05Yfk2933zfwtxMeRu7JwUmNXO7LGwe575WibvgtcZTEE9 PA2bHqXcOHPp54v74WaSiXm1DGuW87E2+mRs9ljEXf7v2T8m0RaFyOB9El8zj51v+7Ve6kSw EktxRqKhFnNRcSIAN1+yvXcCAAA=
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
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 Oct 2013 19:14:13 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E60F2ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



Assuming we treat (as has been suggested by Emil) trickle candidates as ser=
ver reflexive candidates, would SDP have any impact on those? We don't sign=
al server relexive candidates in SDP, do we?



So, in that case, if I later send an updated Offer, which does NOT contain =
the trickle candidates, I guess the Offer should NOT disable the trickle ca=
ndidates (unless in case of an ICE restart, that is)?



Regards,



Christer









________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Paul K=
yzivat [pkyzivat@alum.mit.edu]
Sent: Monday, 21 October 2013 4:53 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

Emil,

I'm open to your arguments that there is reason to have trickle ICE
alongside O/A and POF/PAN.

But then we must recognize that these all have interactions with one
another. Rather than just ignore them, or hand wave, ISTM that these
need to be specified. It introduces complexity, and dealing with that is
part of the job.

Vanilla ICE specifies the interactions between O/A and the discovery of
candidates via ICE itself. But should it be updated to talk about all
these other mechanisms as well? If not, where should those be
documented? Should trickle ICE discuss interactions with POF/PAN, or
should POF/PAN discuss interactions with trickle ICE, or both?

        Thanks,
        Paul

On 10/20/13 9:03 PM, Emil Ivov wrote:
> On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat  wr=
ote:
>> On 10/20/13 4:23 PM, Emil Ivov wrote:
>>>
>>> One more thought:
>>>
>>> Please understand that trickle ICE is NOT a session modification.
>>
>>
>> Isn't the session modified as a result of the trickle ICE? (E.g., end up
>> using a different media address than it otherwise would have.)
>>
>> And the use of trickle ICE can (I think) require that a subsequent offer=
 be
>> sent (or answered) differently than it would had trickle ice not been us=
ed.
>
> The above statements are also true for vanilla ICE and peer reflexive
> candidates, where ICE processing not reflected in SDP can already lead
> to potential changes of addresses. If the change occurs, then an O/A
> would follow. Currently Trickle ICE works along these exact same
> lines.
>
>> And AFAIK everything that can be accomplished with trickle ICE could als=
o be
>> accomplished with Partial Offer/Answer.
>
> I already agreed that it is implementable ... the point is that it
> would be *incredibly inconvenient*. I already gave a few reasons
> earlier in this thread, let's try again:
>
> * there would be an extremely high glare probability (which is
> perfectly avoidable without O/A), * there would be a lot of added
> complexity. Imagine POFs / PANs that send additional candidates *and*
> change codecs and/or add/remove streams.
> *  it would be very clumsy: after trickling candidates with a POF,
> agents would block and wait for a PAN before they can do it again
> * POF/PAN would be a dependency for trickle and there is no reason for it=
 to be.
> * In Berlin we agreed that we are adopting Unified for WebRTC cases.
> There are Plan B and No Plan style implementations out there and my
> understanding is that they have not been outlawed. Such
> implementations would be unlikely to adopt POF/PAN. Yet, it would be
> great if we made it possible for them to still use Trickle ICE.
>
> The disadvantages aside:
>
> Why would we want to do it this way?
> What would we hope to gain?
>
>> So the differences aren't functional
>> ones.
>> I presume that trickle ICE is expected to be faster, and/or easier to
>> implement. (But easier to implement becomes moot if both need to be
>> implemented.)
>
> I can promise you that it doesn't. You don't have to take my word for
> it. Just try and implement it.
>
>> In my book those justify considering it a session modification.
>
> Let's not take things out of context. Christer's point was that
> because it is a session modification, it has to be done in
> Offer/Answer.
>
> This is wrong.
>
> You can consider it a session modification if you like but it is not
> the kind that requires Offer/Answer. Vanilla ICE proves this.
>
> Emil
>
>
>
>
>
>
>>          Thanks,
>>          Paul
>>
>>> Please
>>> try to isolate the SDP syntax that it uses from general O/A. It is not
>>> part of it.
>>>
>>> Think of it as JSON if that would make thinks easier.
>>>
>>> Emil
>>>
>>> --sent from my mobile
>>>
>>> On 20 Oct 2013 22:18, "Emil Ivov" >> > wrote:
>>>
>>>      Christer, "I tried to explain" to you that what you are saying has
>>>      been addressed and cannot happen. If you believe that there is a
>>>      specific situation that is still possible and is a problem, then
>>>      please describe that rather than continuing to suggest that things
>>>      don't work without any valid arguments whatsoever.
>>>
>>>      --sent from my mobile
>>>
>>>      On 20 Oct 2013 21:50, "Christer Holmberg"
>>>      >>      > wrote:
>>>
>>>
>>>          Hi,
>>>
>>>           >> Example:
>>>           >>
>>>           >> 1. Alice sends an SDP Offer to Bob.
>>>           >>
>>>           >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>>>          and C.
>>>           >>
>>>           >> 3. After that, Bob sends, using trickle ICE, candidates D
>>>          and E to Alice.
>>>           >>
>>>           >> If Alice receives the SDP Answer first, and then the trick=
le
>>>          ICE request, she will assume that Bob first provided candidate=
s
>>>          A, B and C (in the SDP Answer), and then added D and E (in the
>>>          trickle ICE request).
>>>           >>
>>>           >> If Alice receives the trickle ICE request first, and then
>>>          the SDP Answer
>>>           >
>>>           > Don't do that then.
>>>           >
>>>           > It's been pretty clear from the start that any session
>>>          *modification* mechanism that does not also contain the full
>>>          session state completely falls apart in the face of unordered
>>>          delivery. This is a fundamental information problem, and you
>>>          aren't going to write rules that somehow cause it not to be tr=
ue.
>>>           >
>>>           > We haven't yet tackled how to send trickle ICE in SIP, much
>>>          less partial offers and partial answers. When we do, the only
>>>          way it's going to have any chance of working at all is by
>>>          requiring ordered delivery.
>>>
>>>          I totally agree, and my opinion (which I tried to explain to
>>>          Emil) is that it applies also to candidates.
>>>
>>>          Regards,
>>>
>>>          Christer
>>>
>>
>
>
>

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

--_000_7594FB04B1934943A5C02806D1A2204B1C4E60F2ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











Hi,


 


Assuming we treat (as has been suggested by Emil) trickle candidate=
s as server reflexive candidates, would SDP have any impact on those? We do=
n't signal server relexive candidates in SDP, do we?


 


So, in that case, if I later send an updated Offer, which does NOT conta=
in the trickle candidates, I guess the Offer should NOT disable t=
he trickle candidates (unless in case of an ICE restart, that is)?


 


Regards,


 


Christer


 


 


 


 






From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behal=
f of Paul Kyzivat [pkyzivat@alum.mit.edu]

Sent: Monday, 21 October 2013 4:53 PM

To: mmusic@ietf.org

Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type=
 value











Emil,



I'm open to your arguments that there is reason to have trickle ICE 

alongside O/A and POF/PAN.



But then we must recognize that these all have interactions with one 

another. Rather than just ignore them, or hand wave, ISTM that these 

need to be specified. It introduces complexity, and dealing with that is 
part of the job.



Vanilla ICE specifies the interactions between O/A and the discovery of 
candidates via ICE itself. But should it be updated to talk about all 

these other mechanisms as well? If not, where should those be 

documented? Should trickle ICE discuss interactions with POF/PAN, or 

should POF/PAN discuss interactions with trickle ICE, or both?



        Thanks,

        Paul



On 10/20/13 9:03 PM, Emil Ivov wrote:

> On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat <pkyzivat@alum.mit.e=
du> wrote:

>> On 10/20/13 4:23 PM, Emil Ivov wrote:

>>>

>>> One more thought:

>>>

>>> Please understand that trickle ICE is NOT a session modificati=
on.

>>

>>

>> Isn't the session modified as a result of the trickle ICE? (E.g., =
end up

>> using a different media address than it otherwise would have.)

>>

>> And the use of trickle ICE can (I think) require that a subsequent=
 offer be

>> sent (or answered) differently than it would had trickle ice not b=
een used.

>

> The above statements are also true for vanilla ICE and peer reflexive<=
br>
> candidates, where ICE processing not reflected in SDP can already lead=


> to potential changes of addresses. If the change occurs, then an O/A
> would follow. Currently Trickle ICE works along these exact same

> lines.

>

>> And AFAIK everything that can be accomplished with trickle ICE cou=
ld also be

>> accomplished with Partial Offer/Answer.

>

> I already agreed that it is implementable ... the point is that it

> would be *incredibly inconvenient*. I already gave a few reasons

> earlier in this thread, let's try again:

>

> * there would be an extremely high glare probability (which is

> perfectly avoidable without O/A), * there would be a lot of added

> complexity. Imagine POFs / PANs that send additional candidates *and*<=
br>
> change codecs and/or add/remove streams.

> *  it would be very clumsy: after trickling candidates with a POF=
,

> agents would block and wait for a PAN before they can do it again

> * POF/PAN would be a dependency for trickle and there is no reason for=
 it to be.

> * In Berlin we agreed that we are adopting Unified for WebRTC cases.
> There are Plan B and No Plan style implementations out there and my
> understanding is that they have not been outlawed. Such

> implementations would be unlikely to adopt POF/PAN. Yet, it would be
> great if we made it possible for them to still use Trickle ICE.

>

> The disadvantages aside:

>

> Why would we want to do it this way?

> What would we hope to gain?

>

>> So the differences aren't functional

>> ones.

>> I presume that trickle ICE is expected to be faster, and/or easier=
 to

>> implement. (But easier to implement becomes moot if both need to b=
e

>> implemented.)

>

> I can promise you that it doesn't. You don't have to take my word for<=
br>
> it. Just try and implement it.

>

>> In my book those justify considering it a session modification.
>

> Let's not take things out of context. Christer's point was that

> because it is a session modification, it has to be done in

> Offer/Answer.

>

> This is wrong.

>

> You can consider it a session modification if you like but it is not
> the kind that requires Offer/Answer. Vanilla ICE proves this.

>

> Emil

>

>

>

>

>

>

>>          Thanks,

>>          Paul

>>

>>> Please

>>> try to isolate the SDP syntax that it uses from general O/A. I=
t is not

>>> part of it.

>>>

>>> Think of it as JSON if that would make thinks easier.

>>>

>>> Emil

>>>

>>> --sent from my mobile

>>>

>>> On 20 Oct 2013 22:18, "Emil Ivov" <emcho@jitsi.or=
g

>>> <mailt=
o:emcho@jitsi.org>> wrote:

>>>

>>>      Christer, "I tried to expla=
in" to you that what you are saying has

>>>      been addressed and cannot happen=
. If you believe that there is a

>>>      specific situation that is still=
 possible and is a problem, then

>>>      please describe that rather than=
 continuing to suggest that things

>>>      don't work without any valid arg=
uments whatsoever.

>>>

>>>      --sent from my mobile

>>>

>>>      On 20 Oct 2013 21:50, "Chri=
ster Holmberg"

>>>      <christer.holmberg@ericsson.c=
om

>>>      <mailto:christer.holmberg@ericsson.c=
om>> wrote:

>>>

>>>

>>>          Hi,

>>>

>>>           &g=
t;> Example:

>>>           &g=
t;>

>>>           &g=
t;> 1. Alice sends an SDP Offer to Bob.

>>>           &g=
t;>

>>>           &g=
t;> 2. Bob sends the SDP Answer to Alice, with candidates A, B

>>>          and C.
>>>           &g=
t;>

>>>           &g=
t;> 3. After that, Bob sends, using trickle ICE, candidates D

>>>          and E to=
 Alice.

>>>           &g=
t;>

>>>           &g=
t;> If Alice receives the SDP Answer first, and then the trickle

>>>          ICE requ=
est, she will assume that Bob first provided candidates

>>>          A, B and=
 C (in the SDP Answer), and then added D and E (in the

>>>          trickle =
ICE request).

>>>           &g=
t;>

>>>           &g=
t;> If Alice receives the trickle ICE request first, and then

>>>          the SDP =
Answer

>>>           &g=
t;

>>>           &g=
t; Don't do that then.

>>>           &g=
t;

>>>           &g=
t; It's been pretty clear from the start that any session

>>>          *modific=
ation* mechanism that does not also contain the full

>>>          session =
state completely falls apart in the face of unordered

>>>          delivery=
. This is a fundamental information problem, and you

>>>          aren't g=
oing to write rules that somehow cause it not to be true.

>>>           &g=
t;

>>>           &g=
t; We haven't yet tackled how to send trickle ICE in SIP, much

>>>          less par=
tial offers and partial answers. When we do, the only

>>>          way it's=
 going to have any chance of working at all is by

>>>          requirin=
g ordered delivery.

>>>

>>>          I totall=
y agree, and my opinion (which I tried to explain to

>>>          Emil) is=
 that it applies also to candidates.

>>>

>>>          Regards,=


>>>

>>>          Christer=


>>>

>>

>

>

>



_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic








--_000_7594FB04B1934943A5C02806D1A2204B1C4E60F2ESESSMB209erics_--

From adam@nostrum.com  Mon Oct 21 12:29: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 EEDF711E8557 for ; Mon, 21 Oct 2013 12:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.154
X-Spam-Level: 
X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwEK+K2nMS4P for ; Mon, 21 Oct 2013 12:29:23 -0700 (PDT)
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 E5A1311E8452 for ; Mon, 21 Oct 2013 12:29:22 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9LJTICH081348 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 14:29:19 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52658089.6030008@nostrum.com>
Date: Mon, 21 Oct 2013 14:29:13 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , "mmusic@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 19:29:24 -0000

On 10/21/13 12:54, Christer Holmberg wrote:
> one also needs to specify the location of the m- line mid value in the 
> group:BUNDLE mid value list.

I don't believe that's true.

The only ordering consideration that I'm aware of for group:BUNDLE is 
that the first indicated mid is the one that the transport information 
is taken from. By the time we're into partial exchanges, the transport 
information for all the lines in the same bundle should be identical.

To ensure a common view of groups, we probably want to define things 
such that new lines added to a group are appended to the list. Is there 
any reason you can think this doesn't work for BUNDLE?

To be clear, let's set aside the prospect of changing transport 
addresses for a BUNDLE: I don't think it's unreasonable to require a 
full offer/answer exchange to do that kind of thing.

/a

From pkyzivat@alum.mit.edu  Mon Oct 21 12:59: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 D135111E8750 for ; Mon, 21 Oct 2013 12:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.597
X-Spam-Level: 
X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[AWL=-0.766,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_56=0.6,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctBIBRcsxyFv for ; Mon, 21 Oct 2013 12:59:47 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id D38D811E8755 for ; Mon, 21 Oct 2013 12:57:40 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id foRo1m0061HzFnQ5Evxfl9; Mon, 21 Oct 2013 19:57:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id fvxf1m00i3ZTu2S3avxfyt; Mon, 21 Oct 2013 19:57:39 +0000
Message-ID: <52658733.30802@alum.mit.edu>
Date: Mon, 21 Oct 2013 15:57:39 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com>
In-Reply-To: <52658089.6030008@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=1382385459; bh=7gMdNy8IYfmsOLJ/zO9Crq1z89inBgLyeO9JPVNVXl0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BSaC6pCDuhBpAQ/V6O84qpEhzjnrl8lG6DSLdFnDHL8WXhur17OCCHvj23CgVMK4Y PN5uBKLRL4alDb//pN+X867lu3qRjEBLyYZexj1BMy1C2ZC8dgiwd3nUCH7UPycqUo I9Bf/L0r7Eddjyvhlcm9d1suuFJB9RfQ/dRt0fiukyzQr4dBTdI9giHzXCSevBo4Po wjj6bSeBKoz/OgClXcENnJ8hN/k0Kzusu+LW9/S47IpVLJSZfVHHigdjyo9OXPwkO6 1AefOLpCIUq1uQP0meeAkRUSvyHThwB8+yMeCmf1sAAFhVf2JjV8jPDrv8iZTgA7Gx 3Nt7rl/Jpv1jg==
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 19:59:53 -0000

On 10/21/13 3:29 PM, Adam Roach wrote:
> On 10/21/13 12:54, Christer Holmberg wrote:
>> one also needs to specify the location of the m- line mid value in the
>> group:BUNDLE mid value list.
>
> I don't believe that's true.
>
> The only ordering consideration that I'm aware of for group:BUNDLE is
> that the first indicated mid is the one that the transport information
> is taken from. By the time we're into partial exchanges, the transport
> information for all the lines in the same bundle should be identical.

I guess that could be specified as a requirement for use of POF.

> To ensure a common view of groups, we probably want to define things
> such that new lines added to a group are appended to the list. Is there
> any reason you can think this doesn't work for BUNDLE?
>
> To be clear, let's set aside the prospect of changing transport
> addresses for a BUNDLE: I don't think it's unreasonable to require a
> full offer/answer exchange to do that kind of thing.

In conjunction with limiting to groups with all m-lines/ports the same, 
that does simplify things.

There remains the problem of indicating *which* (if any) group a newly 
added m-line joins.

There could be many group lines, even multiple with the same semantics. 
In particular there could be several independent bundles. There is 
nothing that is guaranteed to uniquely identify one of them.

The best I can see is to invent some new media-level attribute. For 
example, a=groupref. This could have the same syntax as a=group, but 
different usage. The 'semantics' and 'identification-tag's in it would 
be used to query a=group lines in the full SDP. Any that match would get 
the mid of this new m-line added. (This would allow you to say "I want 
this m-line bundled the same as this other m-line.) We might allow "*" 
to wildcard the semantics so you could add the m-line to different kinds 
of groups.

Of course there could be an error if this groupref didn't match 
anything. That could be defined to either fail, add to no group, or 
define a new group.

This would be a funny kind of SDP attribute, because it might not have 
meaning in a full SDP. (Or I guess it could be defined to work in a 
similar way. There would be some differences.)

	Thanks,
	Paul


From christer.holmberg@ericsson.com  Mon Oct 21 13:01:56 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 AF35C11E86B6 for ; Mon, 21 Oct 2013 13:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.366
X-Spam-Level: 
X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=0.282,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9guVP7mSAqXg for ; Mon, 21 Oct 2013 13:01:49 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C51B711E8422 for ; Mon, 21 Oct 2013 13:00:50 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-f6-526587f11e86
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.1F.03802.1F785625; Mon, 21 Oct 2013 22:00:49 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 22:00:49 +0200
From: Christer Holmberg 
To: Adam Roach , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
Thread-Index: Ac7OhpamIvENB/S3QrGtxwOPSJ1SZ///+PCAgAAiIGL///fD3w==
Date: Mon, 21 Oct 2013 20:00:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E63CB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se>, <52658089.6030008@nostrum.com>
In-Reply-To: <52658089.6030008@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje7H9tQgg+ZjxhZ7/i5it5i6/DGL A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxcPZ0toLHuhU/pm1ga2B8q9rFyMkhIWAi MeFnOyOELSZx4d56ti5GLg4hgcOMEgvfL2OCcJYwSnRv/wHkcHCwCVhIdP/TBjFFBNwk5p1K B+kVFnCQeDF5BSuILSLgKLFh2V9miBInicOz9EDCLAKqEhcndbGA2LwCvhKt6zuYQGwhgRyJ iT+ng53AKaAtcevlcmYQmxHonO+n1oDVMAuIS9x6Mp8J4kwBiSV7zjND2KISLx//YwVZJSGg JDFtaxpEeb7E5kn9UKsEJU7OfMIygVFkFpJJs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1di xr9DUDXWEnMb9jMhq1nAyLGKkT03MTMnvdxoEyMwmg5u+a26g/HOOZFDjNIcLErivB/eOgcJ CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCySC91xYL34u97EoHkiK09t1tias8PRelbKizm9 FWL9N+UCtQ8ePFJ3iDPuooNfm+sCj9zodYkzdq/XUNeJvjmH45ZTzBIO24rA/1FzmwPPFKo2 ZP+fI/T3uvOf34EMTXUXJ/eEuy4zvMZ/50p8j3WgAIN6SthdoRMrdj6KTbqzOpjf5bXZeSWW 4oxEQy3mouJEAG+rIIp0AgAA
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 20:01:56 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



>> one also needs to specify the location of the m- line mid value in the
>> group:BUNDLE mid value list.
>
> I don't believe that's true.
>
> The only ordering consideration that I'm aware of for group:BUNDLE is
> that the first indicated mid is the one that the transport information
> is taken from.



If, for whatever reason, the Answerer does not/cannot choose the first in t=
he list, it shall try the next in the list, etc.



But, that only becomes an issue when the BUNDLE address has yet not been ne=
gotiated - or when one tries to re-negotiate it (discussed below).



> By the time we're into partial exchanges, the transport
> information for all the lines in the same bundle should be identical.



...assuming we don't also want to re-negotiate the BUNDLE address with the =
POF, in which case the POF might contain that new address.



But, as we discussed earlier, and as you also indicated at the end of your =
e-mail, maybe using POF for transport re-negotiation is something we can di=
sallow.

> To ensure a common view of groups, we probably want to define things
> such that new lines added to a group are appended to the list. Is there
> any reason you can think this doesn't work for BUNDLE?

I need to think about it, but nothing comes to my mind at the moment.



And, if both endpoints add a new m- line to the BUNDLE group at the same ti=
me, I guess the order in which they mids are appended to the list could be =
based on the order in which the m- lines themselves are added to the SDP st=
ate.

> To be clear, let's set aside the prospect of changing transport
> addresses for a BUNDLE: I don't think it's unreasonable to require a
> full offer/answer exchange to do that kind of thing.



I agree.



Regards,



Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <4BE94EE9FCDB714793DB19E844D0D46D@ericsson.com>
Content-Transfer-Encoding: quoted-printable











Hi,


 

>> one also need=
s to specify the location of the m- line mid value in the


>> group:BUNDLE mid value list.

>

> I don't believe that's true.

>

> The only ordering consideration that I'm aware of for group:BUNDLE is =


> that the first indicated mid is the one that the transport information=
 

> is taken from.


 

If, for whatever reaso=
n, the Answerer does not/cannot choose the first in the list, it shall try =
the next in the list, etc.


 

But, that only becomes=
 an issue when the BUNDLE address has yet not been negotiated - or when one=
 tries to re-negotiate it (discussed below).


 

> By the time =
we're into partial exchanges, the transport


> information for all the lines in the same bundle should be identical.<=
/span>


 

...assuming we don't a=
lso want to re-negotiate the BUNDLE address with the POF, in which cas=
e the POF might contain that new address.


 

But, as we discussed e=
arlier, and as you also indicated at the end of your e-mail, maybe using PO=
F for transport re-negotiation is something we can disallow.<=
/p>




> To ensure a common view of groups, we probably want to define things <=
br>
> such that new lines added to a group are appended to the list. Is ther=
e 

> any reason you can think this doesn't work for BUNDLE?




I need to think about it, but nothing comes to my mind at the moment.

 


And, if both endpoints add a new m- line to the BUNDLE group at the same=
 time, I guess the order in which they mids are appended to the list could =
be based on the order in which the m- lines themselves are added to the SDP=
 state.




> To be clear, let's set aside the prospect of changing transport 

> addresses for a BUNDLE: I don't think it's unreasonable to require a <=
br>
> full offer/answer exchange to do that kind of thing.


 


I agree. 


 


Regards,


 


Christer








--_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_--

From john@jlc.net  Mon Oct 21 14:54: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 068E811E8707 for ; Mon, 21 Oct 2013 14:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.447
X-Spam-Level: 
X-Spam-Status: No, score=-106.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aaD9a8tHxIl for ; Mon, 21 Oct 2013 14:53:56 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C531911E872E for ; Mon, 21 Oct 2013 14:53:49 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 0525FC94C7; Mon, 21 Oct 2013 17:53:45 -0400 (EDT)
Date: Mon, 21 Oct 2013 17:53:45 -0400
From: John Leslie 
To: Paul Kyzivat 
Message-ID: <20131021215344.GE67188@verdi>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com> <52658733.30802@alum.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52658733.30802@alum.mit.edu>
User-Agent: Mutt/1.4.1i
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 21:54:03 -0000

Paul Kyzivat  wrote:
> 
> There remains the problem of indicating *which* (if any) group a newly 
> added m-line joins.

   Not only don't I see an _answer_ to this -- I don't even think we have
a common understanding of the _question_.

   :^(

--
John Leslie 

From suhasietf@gmail.com  Mon Oct 21 15:05: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 63EEA11E864B for ; Mon, 21 Oct 2013 15:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt3OkBSdB7uq for ; Mon, 21 Oct 2013 15:05:17 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA0411E8750 for ; Mon, 21 Oct 2013 15:05:07 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id z12so7256053wgg.12 for ; Mon, 21 Oct 2013 15:05:01 -0700 (PDT)
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=OBLUml1FIQHulmYceoXOcM0uRdenKj0bbuLOC+qlsSw=; b=xYOoc7Iw4I0hIH4HsGIgv0wLtOCDPzDnT0rZoRVbtLStFCSMBoKLx7s52ZshJ5tpmj i2r0256Sfm1bAfDzsLaqRa71dVH7VXdi3ZntJMm2mdB26YIoEmKrKAgboDK0gkJaitYc 01Pg1Wx0um76/h3Vn+32q0ouBqXjUtr/Jw6ocB+MwaYfQFojbfE693VaOeIgF0wHXHju eglwt0ZZPOoT5XV5snLXNzcplSH0f9c+LsJeBoa8ZUENLedssq19wkYRZ10cuK8FqeYi mlCvnjLiUNYSMPsMjX4Sl2W0qpkfyss083z0bF6/eBn0F3/NrMlkPIKtxtDYujNqOhVq G66w==
MIME-Version: 1.0
X-Received: by 10.180.182.82 with SMTP id ec18mr11641124wic.13.1382393101529;  Mon, 21 Oct 2013 15:05:01 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Mon, 21 Oct 2013 15:05:01 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4E63CB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C4E63CB@ESESSMB209.ericsson.se>
Date: Mon, 21 Oct 2013 15:05:01 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b6250b8c1b67a04e94779c1
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 22:05:18 -0000

--047d7b6250b8c1b67a04e94779c1
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 21, 2013 at 1:00 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> >> one also needs to specify the location of the m- line mid value in the
> >> group:BUNDLE mid value list.
> >
> > I don't believe that's true.
> >
> > The only ordering consideration that I'm aware of for group:BUNDLE is
> > that the first indicated mid is the one that the transport information
> > is taken from.
>
>
>
> If, for whatever reason, the Answerer does not/cannot choose the first in
> the list, it shall try the next in the list, etc.
>
>
>
> But, that only becomes an issue when the BUNDLE address has yet not been
> negotiated - or when one tries to re-negotiate it (discussed below).
>
>
>
> > By the time we're into partial exchanges, the transport
> > information for all the lines in the same bundle should be identical.
>
>
>
> ...assuming we don't also want to re-negotiate the BUNDLE address with the
> POF, in which case the POF might contain that new address.
>
>
>
> But, as we discussed earlier, and as you also indicated at the end of your
> e-mail, maybe using POF for transport re-negotiation is something we can
> disallow.
>
+1. Another side affect with this is, if the POF corresponds to m=line
whose mid is the first entry in the a=group:BUNDLE and this POF changes the
C= and Port field. Even in this, the BUNDLE draft might want to add a
requirement that it is disallowed for POF/PAN scenario.

> > To ensure a common view of groups, we probably want to define things
> > such that new lines added to a group are appended to the list. Is there
> > any reason you can think this doesn't work for BUNDLE?
>
> I need to think about it, but nothing comes to my mind at the moment.
>
>
>
> And, if both endpoints add a new m- line to the BUNDLE group at the same
> time, I guess the order in which they mids are appended to the list could
> be based on the order in which the m- lines themselves are added to the SDP
> state.
>

The draft discusses on the rules to append the m=lines based on the
lexically ordering of their mid values and the same rules applies here as
well. This would form common view in this case.

>
> > To be clear, let's set aside the prospect of changing transport
> > addresses for a BUNDLE: I don't think it's unreasonable to require a
> > full offer/answer exchange to do that kind of thing.
>
>
>
> I agree.
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--047d7b6250b8c1b67a04e94779c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Mon, Oct 21, 2013 at 1:00 PM, Christer Holmberg <c=
hrister.holmberg@ericsson.com> wrote:













Hi,


=A0


>> one also needs to specify =
the location of the m- line mid value in the


>> group:BUNDLE mid value list.

>

> I don't believe that's true.

>

> The only ordering consideration that I'm aware of for group:BUNDLE=
 is 

> that the first indicated mid is the one that the transport information=
 

> is taken from.


=A0


If, for whatever reason, the =
Answerer does not/cannot choose the first in the list, it shall try the nex=
t in the list, etc.


=A0


But, that only becomes an issue whe=
n the BUNDLE address has yet not been negotiated - or when one tries to re-=
negotiate=A0it=A0(discussed below).


=A0


>=A0By the time we're into p=
artial exchanges, the transport


> information for all the lines in the same bundle should be identical.<=
/span>


=A0


...assuming we don't also=
=A0want to re-negotiate the BUNDLE address with the POF, in which case the =
POF might contain that new address.


=A0


But, as we discussed earlier, and a=
s you also indicated at the end of your e-mail, maybe using POF for transpo=
rt re-negotiation is something we can disallow.


+1. Another side affect with this is, if the POF correspo=
nds to m=3Dline whose mid is the first entry in the a=3Dgroup:BUNDLE and th=
is POF changes the C=3D and Port field. Even in this, the BUNDLE draft migh=
t want to add a requirement that it is disallowed for POF/PAN scenario.



> To ensure a common view of groups, we probably want to define things <=
br>
> such that new lines added to a group are appended to the list. Is ther=
e 

> any reason you can think this doesn't work for BUNDLE?




I need to think about it, but nothing comes to my mind at the mome=
nt.


=A0


And, if both endpoints add a new m- line to the BUNDLE group at the same=
 time, I guess the order in which they mids are appended to the list could =
be based on the order in which the m- lines themselves are added to the SDP=
 state.



The draft discus=
ses on the rules to append the m=3Dlines based on the lexically ordering of=
 their mid values and the same rules applies here as well. This would form =
common view in this case.=A0






> To be clear, let's set aside the prospect of changing transport 
> addresses for a BUNDLE: I don't think it's unreasonable to req=
uire a 

> full offer/answer exchange to do that kind of thing.


=A0


I agree. 


=A0


Regards,


=A0


Christer









_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--047d7b6250b8c1b67a04e94779c1--

From pkyzivat@alum.mit.edu  Mon Oct 21 15:29: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 7CB8021E8063 for ; Mon, 21 Oct 2013 15:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.01
X-Spam-Level: 
X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.153,  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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUO5+7esn0gw for ; Mon, 21 Oct 2013 15:29:14 -0700 (PDT)
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 A9EC511E8789 for ; Mon, 21 Oct 2013 15:29:11 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id fo1b1m0060vyq2s58yVBDw; Mon, 21 Oct 2013 22:29:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id fyVA1m00p3ZTu2S3RyVARe; Mon, 21 Oct 2013 22:29:10 +0000
Message-ID: <5265AAB6.40008@alum.mit.edu>
Date: Mon, 21 Oct 2013 18:29:10 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: John Leslie 
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com> <52658733.30802@alum.mit.edu> <20131021215344.GE67188@verdi>
In-Reply-To: <20131021215344.GE67188@verdi>
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=1382394551; bh=GlecvapbNyKH0Tpz1mcXjgmYRa640F+f6zUFmC7GYGE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EA+AN6WBr4eUtkCAvGrowS7yzWZLgeBPPdf3mrT1C9DS5y8qT/QSDCzyJO6l2OZ5R WdhJCj1WoOQ8wZfoa2WKyhivHDfVXTGo9WUOj8Hyxrsb4SbAJ8cYHcsBWRe4ifKSDh cXeUdi3z44l/+XFK2hd32WLIJ+smtLaSHDig8riQUJDKp1sQJxDTbHJ00ukd9S9SEL C2pDgF4Oon29+JCF5/GV8vMIeBqRvr/zEE7Gf3is598aTfGD7H7BKMn6nEE39k1Ojx LbOzvUWyQ+Nw0jSLPyjjy5zikaxTu5QAw8Rc6bfeN2mepjLV4KTMU8HrCBG/w4sbr0 UGZf2WCvLWz8w==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 22:29:20 -0000

On 10/21/13 5:53 PM, John Leslie wrote:
> Paul Kyzivat  wrote:
>>
>> There remains the problem of indicating *which* (if any) group a newly
>> added m-line joins.
>
>     Not only don't I see an _answer_ to this -- I don't even think we have
> a common understanding of the _question_.
>
>     :^(

Here is an example:

a=group:bundle A B
a=group:bundle C D
m=audio ...
a=mid:A
m=audio ...
a=mid:B
m=video ...
m=mid:C
m=video ...
a=mid:D

Then we do a POF

m=video ...
a=mid:E

We want to add this to the 2nd bundle. How do we say that?
I'm suggesting:

m=video ...
a=mid:E
a=groupref:bundle C

The only a=group that matches that is the second one, so this implicitly 
updates that one to:

a=group:bundle C D E

Make sense? Its all a hack of course. But everything that is done to SDP 
is a hack.

	Thanks,
	Paul


From suhasietf@gmail.com  Mon Oct 21 15:38: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 3893211E8799 for ; Mon, 21 Oct 2013 15:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.091
X-Spam-Level: 
X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkkgigJc3W8Z for ; Mon, 21 Oct 2013 15:38:47 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2311E86AF for ; Mon, 21 Oct 2013 15:38:27 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id hm4so4720963wib.14 for ; Mon, 21 Oct 2013 15:38:26 -0700 (PDT)
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=w+klix3iIgUMqS7RXdSDb+MBAfv3u7PMxNylqQh/U2A=; b=AasXM2pVAp6eyzF7RTNlMQ9N1qNd95oHLOAgWenDJ/flISvK2CosrEnthmUh2tZ6e3 AozwY6jByzwXEWMUTFemhdtt72zi8wPX9us48MQfafunBnMr06ytZgKUhXXmgEHx93aX QU4ZPDNarEWPfolwpaKgATVpi3zYdkrE4rrQMxuXcKw6aQnb3SayAZuhkQFa2j1xNO/O i6PM7BFOSDssC7cL7c5bTGHVa1Bdmy0hf3d+2Gjz6NXHgQGhQL6dc/d48AILk/4z9edQ 2yVkEbGj+HpkqQxMv1SY55oGzwa3O9yqRU2NIs/Rx/FsSZX+b53uwq7tT9AQmO04Pmlp cQbg==
MIME-Version: 1.0
X-Received: by 10.180.39.212 with SMTP id r20mr11719683wik.13.1382395106796; Mon, 21 Oct 2013 15:38:26 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Mon, 21 Oct 2013 15:38:26 -0700 (PDT)
In-Reply-To: <5265AAB6.40008@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com> <52658733.30802@alum.mit.edu> <20131021215344.GE67188@verdi> <5265AAB6.40008@alum.mit.edu>
Date: Mon, 21 Oct 2013 15:38:26 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=001a11c2b01c47aaed04e947f195
Cc: mmusic WG 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 22:38:49 -0000

--001a11c2b01c47aaed04e947f195
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 21, 2013 at 3:29 PM, Paul Kyzivat  wrote:

> On 10/21/13 5:53 PM, John Leslie wrote:
>
>> Paul Kyzivat  wrote:
>>
>>>
>>> There remains the problem of indicating *which* (if any) group a newly
>>> added m-line joins.
>>>
>>
>>     Not only don't I see an _answer_ to this -- I don't even think we have
>> a common understanding of the _question_.
>>
>>     :^(
>>
>
> Here is an example:
>
> a=group:bundle A B
> a=group:bundle C D
> m=audio ...
> a=mid:A
> m=audio ...
> a=mid:B
> m=video ...
> m=mid:C
> m=video ...
> a=mid:D
>
> Then we do a POF
>
> m=video ...
> a=mid:E
>
> We want to add this to the 2nd bundle. How do we say that?
> I'm suggesting:
>
> m=video ...
> a=mid:E
> a=groupref:bundle C
>
> The only a=group that matches that is the second one, so this implicitly
> updates that one to:
>
> a=group:bundle C D E
>
> Make sense? Its all a hack of course. But everything that is done to SDP
> is a hack.
>

I think even this case can break if you use FEC based grouping mechanism

a=group:FEC-XR a b c
a=group:FEC-XR a d

now if we want to add the new "mid e" to the list where i have mid a listed
, we end up at the same point.

How about  we can extend groupref to include the entire group line as below

m=video ...
a=mid:E
a=groupref:FEC-XR a d

==> this would end up as
a=group:FEC-XR a b c
a=group:FEC-XR a d e   // new one added to the right line



>
>         Thanks,
>         Paul
>
>
> ______________________________**_________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/**listinfo/mmusic
>

--001a11c2b01c47aaed04e947f195
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Mon, Oct 21, 2013 at 3:29 PM, Paul Kyzivat <=
;pkyzivat@alum.m=
it.edu> wrote:


On 10/21/13 5:53 PM, John Leslie wrote:<=
br>



Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:





There remains the problem of indicating *which* (if any) group a newly

added m-line joins.





=A0 =A0 Not only don't I see an _answer_ to this -- I don't even th=
ink we have

a common understanding of the _question_.



=A0 =A0 :^(





Here is an example:



a=3Dgroup:bundle A B

a=3Dgroup:bundle C D

m=3Daudio ...

a=3Dmid:A

m=3Daudio ...

a=3Dmid:B

m=3Dvideo ...

m=3Dmid:C

m=3Dvideo ...

a=3Dmid:D



Then we do a POF



m=3Dvideo ...

a=3Dmid:E



We want to add this to the 2nd bundle. How do we say that?

I'm suggesting:



m=3Dvideo ...

a=3Dmid:E

a=3Dgroupref:bundle C



The only a=3Dgroup that matches that is the second one, so this implicitly =
updates that one to:



a=3Dgroup:bundle C D E



Make sense? Its all a hack of course. But everything that is done to SDP is=
 a hack.

I think even this case can bre=
ak if you use FEC based grouping mechanism

a=3Dgro=
up:FEC-XR a b c


a=3Dgroup:FEC-XR a d

now if we want to add th=
e new "mid e" to the list where i have mid a listed , we end up a=
t the same point.=A0

How about =A0we can extend gr=
oupref to include the entire group line as below


=A0
m=3Dvideo ...
a=3Dmid:E
a=3Dgroupref:FEC-XR a d

=3D=3D> this would end up as
a=
=3Dgroup:FEC-XR a b c
a=3Dgroup:FEC-XR a d e =A0 // new one added=
 to the right line



=A0



=A0 =A0 =A0 =A0 Thanks,

=A0 =A0 =A0 =A0 Paul




_______________________________________________

mmusic mailing list

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





--001a11c2b01c47aaed04e947f195--

From adam@nostrum.com  Mon Oct 21 15:49:50 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 780F111E87BC for ; Mon, 21 Oct 2013 15:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.148
X-Spam-Level: 
X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T24CEdrKF91W for ; Mon, 21 Oct 2013 15:49:47 -0700 (PDT)
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 04F0111E832F for ; Mon, 21 Oct 2013 15:47:17 -0700 (PDT)
Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9LMlDm2004195 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 17:47:13 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5265AEEC.4050806@nostrum.com>
Date: Mon, 21 Oct 2013 17:47:08 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Suhas Nandakumar , Paul Kyzivat 
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se>	<52658089.6030008@nostrum.com> <52658733.30802@alum.mit.edu>	<20131021215344.GE67188@verdi> <5265AAB6.40008@alum.mit.edu> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070307060806070403000106"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic WG 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 22:49:50 -0000

This is a multi-part message in MIME format.
--------------070307060806070403000106
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/21/13 17:38, Suhas Nandakumar wrote:
>
>
>
> On Mon, Oct 21, 2013 at 3:29 PM, Paul Kyzivat  > wrote:
>
>     On 10/21/13 5:53 PM, John Leslie wrote:
>
>         Paul Kyzivat          > wrote:
>
>
>             There remains the problem of indicating *which* (if any)
>             group a newly
>             added m-line joins.
>
>
>             Not only don't I see an _answer_ to this -- I don't even
>         think we have
>         a common understanding of the _question_.
>
>             :^(
>
>
>     Here is an example:
>
>     a=group:bundle A B
>     a=group:bundle C D
>     m=audio ...
>     a=mid:A
>     m=audio ...
>     a=mid:B
>     m=video ...
>     m=mid:C
>     m=video ...
>     a=mid:D
>
>     Then we do a POF
>
>     m=video ...
>     a=mid:E
>
>     We want to add this to the 2nd bundle. How do we say that?
>     I'm suggesting:
>
>     m=video ...
>     a=mid:E
>     a=groupref:bundle C
>
>     The only a=group that matches that is the second one, so this
>     implicitly updates that one to:
>
>     a=group:bundle C D E
>
>     Make sense? Its all a hack of course. But everything that is done
>     to SDP is a hack.
>
>
> I think even this case can break if you use FEC based grouping mechanism
>
> a=group:FEC-XR a b c
> a=group:FEC-XR a d
>
> now if we want to add the new "mid e" to the list where i have mid a 
> listed , we end up at the same point.
>
> How about  we can extend groupref to include the entire group line as 
> below
> m=video ...
> a=mid:E
> a=groupref:FEC-XR a d
>
> ==> this would end up as
> a=group:FEC-XR a b c
> a=group:FEC-XR a d e   // new one added to the right line
>
>

This is giving me a strong sense of deja vu.

http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

/a

--------------070307060806070403000106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/21/13 17:38, Suhas Nandakumar
      wrote:

    

    

      


        


          

          
On Mon, Oct 21, 2013 at 3:29 PM, Paul
            Kyzivat <pkyzivat@alum.mit.edu>
            wrote:

            

              
On 10/21/13 5:53 PM, John Leslie wrote:

                
Paul
                  Kyzivat <pkyzivat@alum.mit.edu>
                  wrote:

                  


                    There remains the problem of indicating *which* (if
                    any) group a newly

                    added m-line joins.

                  

                  

                      Not only don't I see an _answer_ to this -- I
                  don't even think we have

                  a common understanding of the _question_.

                  

                      :^(

                

                

              

              Here is an example:

              

              a=group:bundle A B

              a=group:bundle C D

              m=audio ...

              a=mid:A

              m=audio ...

              a=mid:B

              m=video ...

              m=mid:C

              m=video ...

              a=mid:D

              

              Then we do a POF

              

              m=video ...

              a=mid:E

              

              We want to add this to the 2nd bundle. How do we say that?

              I'm suggesting:

              

              m=video ...

              a=mid:E

              a=groupref:bundle C

              

              The only a=group that matches that is the second one, so
              this implicitly updates that one to:

              

              a=group:bundle C D E

              

              Make sense? Its all a hack of course. But everything that
              is done to SDP is a hack.

            

            


            

            
I think even this case can break if you use FEC based
              grouping mechanism

            


            

            
a=group:FEC-XR a b c

            
a=group:FEC-XR a d

            


            

            
now if we want to add the new "mid e" to the list where
              i have mid a listed , we end up at the same point. 

            


            

            
How about  we can extend groupref to include the entire
              group line as below

            
 

            
m=video ...

              a=mid:E

              a=groupref:FEC-XR a d

            

            


            

            
==> this would end up as

            

              
a=group:FEC-XR a b c

              
a=group:FEC-XR a d e   // new one added to the right
                line

            

            


            

            
 

            

          

        

      

    

    

    This is giving me a strong sense of deja vu. 

    

    http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

    

    /a

  


--------------070307060806070403000106--

From suhasietf@gmail.com  Mon Oct 21 15:51: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 0D54111E864F for ; Mon, 21 Oct 2013 15:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level: 
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clhB3bdO5sBO for ; Mon, 21 Oct 2013 15:51:03 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E78FB11E87B3 for ; Mon, 21 Oct 2013 15:49:59 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id u57so7353523wes.32 for ; Mon, 21 Oct 2013 15:49:58 -0700 (PDT)
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=+qP0K619R3yo6Wb3DqTWKIdy/ffT7z3Yg4/SDmpxKMY=; b=y8dIzAJQTqK/Rb7Or98H4romD+lp9FVfrC5wKjtVE8RQJKPZBldUo78TweDhCw3oNS LGvJyLrUY9Bn1ym4bKa3lAS9yCmSXYMuWxZM7anCyI3S/eEUgTgfdX3HVyrLQcP9SxyQ gVi/n/qpKnUp5yJa6zriZxXOPtbEy+xj7xZVMGCmo9jV9xzkaNpsGADAfPAt/osxGPgI qG74jOW4WAGEVvGvpVvMgrDE7fk5wN5+XyJbHtpCUQxQJSda7V/J3qLyY26GcEWe+UKd U9DYUnZGqARSyhLr8P4599BM6movbi4rLsJaSI11pXUeuu3E25GOKoi58U8kRHUpLe+M 6j6A==
MIME-Version: 1.0
X-Received: by 10.180.108.131 with SMTP id hk3mr529124wib.10.1382395798088; Mon, 21 Oct 2013 15:49:58 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Mon, 21 Oct 2013 15:49:58 -0700 (PDT)
In-Reply-To: <5265AEEC.4050806@nostrum.com>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com> <52658733.30802@alum.mit.edu> <20131021215344.GE67188@verdi> <5265AAB6.40008@alum.mit.edu>  <5265AEEC.4050806@nostrum.com>
Date: Mon, 21 Oct 2013 15:49:58 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=e89a8f3ba34b7bf11a04e9481a00
Cc: mmusic WG , Paul Kyzivat 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 22:51:04 -0000

--e89a8f3ba34b7bf11a04e9481a00
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 21, 2013 at 3:47 PM, Adam Roach  wrote:

>  On 10/21/13 17:38, Suhas Nandakumar wrote:
>
>
>
>
> On Mon, Oct 21, 2013 at 3:29 PM, Paul Kyzivat wrote:
>
>> On 10/21/13 5:53 PM, John Leslie wrote:
>>
>>> Paul Kyzivat  wrote:
>>>
>>>>
>>>> There remains the problem of indicating *which* (if any) group a newly
>>>> added m-line joins.
>>>>
>>>
>>>     Not only don't I see an _answer_ to this -- I don't even think we
>>> have
>>> a common understanding of the _question_.
>>>
>>>     :^(
>>>
>>
>>  Here is an example:
>>
>> a=group:bundle A B
>> a=group:bundle C D
>> m=audio ...
>> a=mid:A
>> m=audio ...
>> a=mid:B
>> m=video ...
>> m=mid:C
>> m=video ...
>> a=mid:D
>>
>> Then we do a POF
>>
>> m=video ...
>> a=mid:E
>>
>> We want to add this to the 2nd bundle. How do we say that?
>> I'm suggesting:
>>
>> m=video ...
>> a=mid:E
>> a=groupref:bundle C
>>
>> The only a=group that matches that is the second one, so this implicitly
>> updates that one to:
>>
>> a=group:bundle C D E
>>
>> Make sense? Its all a hack of course. But everything that is done to SDP
>> is a hack.
>>
>
>  I think even this case can break if you use FEC based grouping mechanism
>
>  a=group:FEC-XR a b c
> a=group:FEC-XR a d
>
>  now if we want to add the new "mid e" to the list where i have mid a
> listed , we end up at the same point.
>
>  How about  we can extend groupref to include the entire group line as
> below
>
> m=video ...
> a=mid:E
> a=groupref:FEC-XR a d
>
>  ==> this would end up as
>  a=group:FEC-XR a b c
> a=group:FEC-XR a d e   // new one added to the right line
>
>
>
>
> This is giving me a strong sense of deja vu.
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html
>
>
Completely agreed. It is the same solution.

/a
>

--e89a8f3ba34b7bf11a04e9481a00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Mon, Oct 21, 2013 at 3:47 PM, Adam Roach <<=
a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g=
t; wrote:



 =20
   =20
 =20
  

    
On 10/21/13 17:38, Suhas Nandakumar
      wrote:

    

    

      


        


          

          
On Mon, Oct 21, 2013 at 3:29 PM, Paul
            Kyzivat <pkyzivat@alum.mit.edu>
            wrote:

            

              
On 10/21/13 5:53 PM, John Leslie wrote:

                
Paul
                  Kyzivat <pkyzivat@alum.mit.edu>
                  wrote:

                  


                    There remains the problem of indicating *which* (if
                    any) group a newly

                    added m-line joins.

                  

                  

                  =A0 =A0 Not only don't I see an _answer_ to this -- I
                  don't even think we have

                  a common understanding of the _question_.

                  

                  =A0 =A0 :^(

                

                

              

              Here is an example:

              

              a=3Dgroup:bundle A B

              a=3Dgroup:bundle C D

              m=3Daudio ...

              a=3Dmid:A

              m=3Daudio ...

              a=3Dmid:B

              m=3Dvideo ...

              m=3Dmid:C

              m=3Dvideo ...

              a=3Dmid:D

              

              Then we do a POF

              

              m=3Dvideo ...

              a=3Dmid:E

              

              We want to add this to the 2nd bundle. How do we say that?
              I'm suggesting:

              

              m=3Dvideo ...

              a=3Dmid:E

              a=3Dgroupref:bundle C

              

              The only a=3Dgroup that matches that is the second one, so
              this implicitly updates that one to:

              

              a=3Dgroup:bundle C D E

              

              Make sense? Its all a hack of course. But everything that
              is done to SDP is a hack.

            

            


            

            
I think even this case can break if you use FEC based
              grouping mechanism

            


            

            
a=3Dgroup:FEC-XR a b c

            
a=3Dgroup:FEC-XR a d

            


            

            
now if we want to add the new "mid e" to the lis=
t where
              i have mid a listed , we end up at the same point.=A0

            


            

            
How about =A0we can extend groupref to include the entire
              group line as below

            
=A0

            
m=3Dvideo ...

              a=3Dmid:E

              a=3Dgroupref:FEC-XR a d

            

            


            

            
=3D=3D> this would end up as

            

              
a=3Dgroup:FEC-XR a b c

              
a=3Dgroup:FEC-XR a d e =A0 // new one added to the right
                line

            

            


            

            
=A0

            

          

        

      

    

    

    This is giving me a strong sense of deja vu. 

    

    http://www.ietf.org/mail-archive/web/mmusic/curren=
t/msg12427.html

    

Completely agr=
eed. It is the same solution.




    /a

  






--e89a8f3ba34b7bf11a04e9481a00--

From pkyzivat@alum.mit.edu  Mon Oct 21 16:14: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 7B60E11E8763 for ; Mon, 21 Oct 2013 16:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.29
X-Spam-Level: 
X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.147,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olujclxjK6HN for ; Mon, 21 Oct 2013 16:14:01 -0700 (PDT)
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 ACC6111E86B0 for ; Mon, 21 Oct 2013 16:14:01 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id fmfQ1m00327AodY59zE012; Mon, 21 Oct 2013 23:14:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id fzE01m00Q3ZTu2S3fzE0D4; Mon, 21 Oct 2013 23:14:00 +0000
Message-ID: <5265B537.1010505@alum.mit.edu>
Date: Mon, 21 Oct 2013 19:13:59 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Adam Roach , Suhas Nandakumar 
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se>	<52658089.6030008@nostrum.com> <52658733.30802@alum.mit.edu>	<20131021215344.GE67188@verdi> <5265AAB6.40008@alum.mit.edu>  <5265AEEC.4050806@nostrum.com>
In-Reply-To: <5265AEEC.4050806@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382397240; bh=71AocHWLEqEK9bJJDW85qt3ihQP7tEJAmw6DlK25qOE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h028Do4/7nxtJfzp9gWG+gfmIMd8q3rkhqEwBlvAeF0LgdwKXq5Pvz1cx9guM6jxn Wzq5iUc+nf9rE3t/mgodxBr1NAimSvhWjHZwa4JwSU5aKj+AqAEr5gx5ybRVoeoeXN uFYfLtHNORmv/L5+VDebIfU4LSWwCHjSldnnYlHCeRc0n/w4OD9mgja7vXAqBhoOLo hsz84QC4bSsA4iF4XWVJNiomnJR3PpECBz3mhdJfvhJZJp1VYT3cPLIlMPS1PWPDBp 88tO6AZg77SM+6gKf/106vqSx36rwggTpjaofP+7E4fgfmzO4yzJcG4Ypm+SZszkQt duDABlGvLj6xg==
Cc: mmusic WG 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 23:14:06 -0000

On 10/21/13 6:47 PM, Adam Roach wrote:

>
> This is giving me a strong sense of deja vu.
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

Oops! You are right. I remember seeing that mail, but not reading it 
thoroughly. So either I remembered more than I thought, or else I 
reinvented it.

	Sorry,
	Paul


From ari.keranen@ericsson.com  Mon Oct 21 16:28:21 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 CE6DC11E871F for ; Mon, 21 Oct 2013 16:28:21 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSwPjC9Hq3Wf for ; Mon, 21 Oct 2013 16:28:16 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 573BD11E82BB for ; Mon, 21 Oct 2013 16:28:14 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-34-5265b88dd773
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F7.CF.16099.D88B5625; Tue, 22 Oct 2013 01:28:13 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.37]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 01:11:52 +0200
From: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
To: Emil Ivov 
Thread-Topic: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Thread-Index: Ac7MD6NfvGuI93GmRnipYmfd4J6njP//4E2AgAAueYCAAT86AIAAFkwAgAM3nwCAAEZjgIAAQsKA
Date: Mon, 21 Oct 2013 23:11:51 +0000
Message-ID: <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <207A714EE01D6C4F8B7E942EA8ECEC08@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW7vjtQgg5aFshZ7/i5it1izcwKL xdTlj1ks3l9fyeLA4jHl90ZWjyVLfjJ5/H8T6DFr5xOWAJYoLpuU1JzMstQifbsEroyOH/eY Cm6IVyx4NoutgfGrUBcjJ4eEgInEx73XGCFsMYkL99azdTFycQgJHGaU6LmwhhXCWcwocfHj bCaQKjYBe4nJaz6CdYgIyEt0ty0CizML5El8fPCYDcQWFnCQeP5mHTtEjaPE/SXrWSHsKImX z/eAxVkEVCVmfjrKDGLzCvhKTG7fyAKx7BaTxMoXS4CGcnBwCgRKLP6tBFLDCHTd91NroHaJ S9x6Mp8J4moBiSV7zjND2KISLx//Y4WwlSTWHt7OAlGvJ3Fj6hQ2CNta4vKC9+wQtrbEsoWv oW4QlDg58wnLBEbxWUhWzELSPgtJ+ywk7bOQtC9gZF3FyJ6bmJmTXm64iREYewe3/NbdwXjq nMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLJ9nKFiPGO/U7ok66Lq tru39zBN7S7yYWF7wdjwZPGberm6yoba4IiFP+Z6xJ5K6uVMO5gyY5/Y9bNRvgkrPJgvrU5t 46z+Ehiwzf/YUsn9N1gY67+9n7LBxFnzaPfcPu6kZyL+s13rp702F8nx9DnVyR+6L5Ktafe+ fDWtjoKlzK+UDSdcV2Ipzkg01GIuKk4EAAMElHaLAgAA
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 23:28:22 -0000

On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:

> I still don't get it. Why would we recommend values for different applica=
tions? We already tell applications to pace checks in accordance with expec=
ted traffic, which they supposedly can gauge better than the text in our RF=
C.
>=20
> A minimum value does make sense because it would basically say: "don't go=
 below this value or you might brake the network or otherwise cause harm". =
That's actually useful advice.

Exactly. We're not proposing (different) values for different application. =
The proposal is to pace checks according to the expected traffic. For RTP t=
here is a formula, for other traffic you're on your own (come up with formu=
la, or what ever). The "second" value is only for the cases where you don't=
 know better and should use something conservative.


Cheers,
Ari

> Now, having two such values starts being weird again, unless we have data=
 that shoes that networks break differently depending on the UDP payload or=
 port number or whatever.
>=20
> --sent from my mobile
>=20
> On 21 Oct 2013 14:01, "Ari Ker=E4nen"  wrote:
> On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
> On Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
> On 18.10.13, 19:30, Adam Roach wrote:
> On 10/18/13 09:44, Emil Ivov wrote:
> It might be worth reminding exactly what these 50ms would be
> protecting us against
>=20
> They're protecting us against RTP arriving at a rate of 20ms per
> packet.
>=20
> That would indeed be one of the reasons to pace checks (in addition
> to fragile NAT boxes IIRC), however in either case, I fail to
> realise why we need a different pacing strategy for non-RTP. This
> is what I was asking about.
>=20
> Connectivity check hammers can still resort to RTP if the pacing
> timer is their only problem and I don't see why shaky NATs would
> tolerate a 20ms rate for RTP but only a 50ms for anything else.
>=20
> This entire separation sounds quite arbitrary right now. I see why
> we would pick a value that we consider somewhat safe and secure but
> I don't understand why we would need two!?
>=20
> I agree. No need to add more complexity. ICE should be ignorant of
> what traffic goes through the pinholes.
>=20
> The idea would be to have one recommended value (or set of) for all kinds=
 of traffic but with RTP you would have this "additional piece of informati=
on" (due to the knowledge of your traffic pattern and the formula to relate=
 that to pacing) that would allow you to go below the conservative recommen=
ded value. If you would have something similar with non-RTP traffic, you co=
uld use that.
>=20
> But then for both endpoints agreeing on the value in order to have connec=
tivity checks happening simultaneously for the same pairs, we'd probably ne=
ed to do some negotiation, similar to what was done with ICE on HIP (http:/=
/tools.ietf.org/html/rfc5770#section-4.4).
>=20
>=20
> Cheers,
> Ari


From emcho@sip-communicator.org  Mon Oct 21 16:38: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 06BA511E880D for ; Mon, 21 Oct 2013 16:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b94Bv8inOh4m for ; Mon, 21 Oct 2013 16:37:59 -0700 (PDT)
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50211E880E for ; Mon, 21 Oct 2013 16:37:52 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id bj1so8872236pad.0 for ; Mon, 21 Oct 2013 16:37:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=X1WAdJQC7cjAFEvVn/1DTKkJ+QINf+r2JP1M6N2CitE=; b=DVRDcxuaMwrmdAzSpXThEONMtL6d4mk8DU6E03BsP6F8YAuw7FHFE5jQRSNsWKiEnQ IHmBJBKP4FI0MwURsYgc/7f1lBSvvbfFHNh8s3+tySWZRa6LjvU8pR5HbYMKLfZ+L9B1 cq2+SrIKmg/b56g1MrvPqERmFa3qfoFzAqKBa7uf/rcsDHdNwK2Ys0G5E8ZfQseDSL/2 0HqkFEdYxLUN+nOn3Xi+36dgHnfmswnTA047OTyuv1uZlugcLmQUx9NjfnGr3i/XxlJY 2zlETiAElq0UFmxJZWSCa+EUesNu9MRGPx/fBdKo96kLi/pKfvYTvpEHSQxSeevq1NG4 xBJg==
X-Gm-Message-State: ALoCoQl1vWYbt9ZCzjCCAiC0/oWtf+cRZfkG/yvUi6YLaDCoNjVaggU/zisskt3q8QXcczzzPFoS
X-Received: by 10.66.147.9 with SMTP id tg9mr20482600pab.5.1382398662725; Mon, 21 Oct 2013 16:37:42 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [2607:f8b0:400e:c02::22c]) by mx.google.com with ESMTPSA id 7sm28623113paf.22.2013.10.21.16.37.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 16:37:42 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id z10so9330671pdj.17 for ; Mon, 21 Oct 2013 16:37:40 -0700 (PDT)
X-Received: by 10.66.50.131 with SMTP id c3mr19948161pao.111.1382398660564; Mon, 21 Oct 2013 16:37:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Mon, 21 Oct 2013 16:37:19 -0700 (PDT)
In-Reply-To: <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>
From: Emil Ivov 
Date: Tue, 22 Oct 2013 01:37:19 +0200
Message-ID: 
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 23:38:04 -0000

On Tue, Oct 22, 2013 at 1:11 AM, Ari Ker=E4nen  w=
rote:
>
> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>
>> I still don't get it. Why would we recommend values for different applic=
ations? We already tell applications to pace checks in accordance with expe=
cted traffic, which they supposedly can gauge better than the text in our R=
FC.
>>
>> A minimum value does make sense because it would basically say: "don't g=
o below this value or you might brake the network or otherwise cause harm".=
 That's actually useful advice.
>
> Exactly. We're not proposing (different) values for different application=
. The proposal is to pace checks according to the expected traffic. For RTP=
 there is a formula, for other traffic you're on your own (come up with for=
mula, or what ever). The "second" value is only for the cases where you don=
't know better and should use something conservative.

If you don't know better why wouldn't you just use RTP's 20 ms pacing
given that we've already blessed it as safe and harmless and NAT
friendly?

Emil



>
>
> Cheers,
> Ari
>
>> Now, having two such values starts being weird again, unless we have dat=
a that shoes that networks break differently depending on the UDP payload o=
r port number or whatever.
>>
>> --sent from my mobile
>>
>> On 21 Oct 2013 14:01, "Ari Ker=E4nen"  wrote:
>> On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
>> On Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>> On 18.10.13, 19:30, Adam Roach wrote:
>> On 10/18/13 09:44, Emil Ivov wrote:
>> It might be worth reminding exactly what these 50ms would be
>> protecting us against
>>
>> They're protecting us against RTP arriving at a rate of 20ms per
>> packet.
>>
>> That would indeed be one of the reasons to pace checks (in addition
>> to fragile NAT boxes IIRC), however in either case, I fail to
>> realise why we need a different pacing strategy for non-RTP. This
>> is what I was asking about.
>>
>> Connectivity check hammers can still resort to RTP if the pacing
>> timer is their only problem and I don't see why shaky NATs would
>> tolerate a 20ms rate for RTP but only a 50ms for anything else.
>>
>> This entire separation sounds quite arbitrary right now. I see why
>> we would pick a value that we consider somewhat safe and secure but
>> I don't understand why we would need two!?
>>
>> I agree. No need to add more complexity. ICE should be ignorant of
>> what traffic goes through the pinholes.
>>
>> The idea would be to have one recommended value (or set of) for all kind=
s of traffic but with RTP you would have this "additional piece of informat=
ion" (due to the knowledge of your traffic pattern and the formula to relat=
e that to pacing) that would allow you to go below the conservative recomme=
nded value. If you would have something similar with non-RTP traffic, you c=
ould use that.
>>
>> But then for both endpoints agreeing on the value in order to have conne=
ctivity checks happening simultaneously for the same pairs, we'd probably n=
eed to do some negotiation, similar to what was done with ICE on HIP (http:=
//tools.ietf.org/html/rfc5770#section-4.4).
>>
>>
>> Cheers,
>> Ari
>



--=20
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From emcho@sip-communicator.org  Mon Oct 21 18:09: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 A83CE11E82E7 for ; Mon, 21 Oct 2013 18:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2amwzM4-TVFO for ; Mon, 21 Oct 2013 18:09:54 -0700 (PDT)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 228FA11E81A4 for ; Mon, 21 Oct 2013 18:09:19 -0700 (PDT)
Received: by mail-pd0-f170.google.com with SMTP id v10so3074137pde.29 for ; Mon, 21 Oct 2013 18:09:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WTcaInBOVYE1bzIqjF6K63vHI5W8taunptfOnpfiS9Y=; b=WOXwaI8lwr7Ad+ilH0xNnxx/db+dAZ3geXCAhRpJfbF7qvSHv3OWdaHURpxL6cNe8o jMSV1yDGgTdrUSe0Ap5sbvuCuY1MGpNDUYz69hrBp8g85R755GRUQPWXcyx+2YY+HbTk 9adUMPsxW47YGJXSPNo95sFvtkk6LaWXfXKDFD+0AFO2mBxT2cFeaRFt7pMFrFGMEoXH +64bbwYbl5p9w8x2y2lIH4F0lVX/CWMyVE+nZKUOu2Zs3X0OpCW4te7Z+2pKd2ivsnbe m2CRgXd/DsvS/Hvbt5EDHKWrscNWvj9G12lIqVfiyFyVAs6GOrdzGMXZ1grNI9qlT7x+ uscw==
X-Gm-Message-State: ALoCoQkA9hFg8DTksHWXKp0WJsv8J27QLE+ruR29pdRVVbYCftYa4WjMa+R6297sEC1Dd/38fPf6
X-Received: by 10.68.211.202 with SMTP id ne10mr4409253pbc.168.1382404158917;  Mon, 21 Oct 2013 18:09:18 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [2607:f8b0:400e:c02::229]) by mx.google.com with ESMTPSA id ef10sm29037945pac.1.2013.10.21.18.09.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 18:09:18 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id q10so6983040pdj.14 for ; Mon, 21 Oct 2013 18:09:18 -0700 (PDT)
X-Received: by 10.66.191.137 with SMTP id gy9mr5422912pac.147.1382404158278; Mon, 21 Oct 2013 18:09:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Mon, 21 Oct 2013 18:08:58 -0700 (PDT)
In-Reply-To: <00a401cece8b$7b00f780$7102e680$@co.in>
References: <00a401cece8b$7b00f780$7102e680$@co.in>
From: Emil Ivov 
Date: Tue, 22 Oct 2013 03:08:58 +0200
Message-ID: 
To: Parthasarathi R 
Content-Type: text/plain; charset=ISO-8859-1
Cc: mmusic , Christer Holmberg 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 01:09:58 -0000

On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
 wrote:
> Hi all,
>
> I have mailed earlier why SIP INFO is not the right choice for Trickle ICE
> in
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.

I remember. Have you noticed my answer?

http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html

> The main
> reason is the glare handling. I have added the callflow in Sec 6.4 of
> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will look for
> Trickle ICE handling in SIP w.r.t JSEP mapping.

I am confused. You say that your main issue is glare handling and yet
your draft proposes a solution that *introduces* glare (through
crossing UPDATEs) and then doesn't say anything about handling it. Is
this intentional? Am I missing something?

> Could you please explain how
> glare with Trickle ICE Info package will be handled.

That's simple. Glare does NOT occur when trickling through INFO.

Emil

--
https://jitsi.org

From ekr@rtfm.com  Mon Oct 21 21:25: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 E18AC11E8330 for ; Mon, 21 Oct 2013 21:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L7bPmIXKdSR for ; Mon, 21 Oct 2013 21:25:47 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8F1311E833F for ; Mon, 21 Oct 2013 21:25:38 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id ez12so4953136wid.11 for ; Mon, 21 Oct 2013 21:25:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3OATKh/+rDtsixJP9idAMZPaK/1k9Vz6VrkKDguY5yI=; b=fZDqIQ+iVDsVwzNcjMXxxwh95t8+cvw/L7m6FlC9qVw3um7dMLLeReu00+67v+vO4y 2OYhMPuKcFKC3NAWuNxWy9WGHTT+TlWCYkqMJAhGKAS6ehHv9VJHZvvhfUr8dDT2G02t IfU+qNRzeNQMgqv1VgOKa0yb9AU5zSG317sPw71GlkeyODcWItnEoGuqSeGasSjllyeL 754ZqittRHdvxKArpK6JZCiZShq7Nbu9hE746Su0+DsWSmwX/+B56WSfEzxKaEYWfC7V TmBjfIYJ102MhvlTO5NMJ4GxOuTS7OFip5vCaFza3XaaISaRWdI4t4eCtK9aF4Q3G8Xa Qi1A==
X-Gm-Message-State: ALoCoQnF1epOzhQPOKFrteQd3p30SqdSoeGcBsfZRFvxg5+iqC4EQo9j9BEwHWNSsHTSx1b6O4Rx
X-Received: by 10.180.24.197 with SMTP id w5mr12484309wif.8.1382415937945; Mon, 21 Oct 2013 21:25:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Mon, 21 Oct 2013 21:24:57 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <525D649E.5040608@nostrum.com>
References: <525D649E.5040608@nostrum.com>
From: Eric Rescorla 
Date: Mon, 21 Oct 2013 21:24:57 -0700
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=f46d044286e2e9d56604e94cca45
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Bundle-only, Port 0, and other options
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 Oct 2013 04:25:53 -0000

--f46d044286e2e9d56604e94cca45
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 15, 2013 at 8:51 AM, Adam Roach  wrote:

>  There's been a bit of a brouhaha (from small but disproportionately vocal
> quarters) around the use of port zero in an offer for bundle-only lines. So
> I wanted to take a step back and see whether we could untangle this knot a
> bit.
>
> The key property that we need here is that bundle-only lines must be
> formed in a way that causes them to be rejected by non-bundling agents, but
> accepted by bundling agents
>

Just for clarity, it must be rejected in such a way that failure to compelte
ICE, etc. does not lead to connection failure.

-Ekr


> . Since bundle deals with ports, that seems like an extremely natural
> place to make the distinction. It has the spectacular advantage of being
> defined in a crystal clear way in RFC 3264:
>
>   "A port number of zero in the offer indicates that the
>    stream is offered but MUST NOT be used.  This has no useful semantics
>    in an initial offer, but is allowed for reasons of completeness..."
>
>   "A stream that is offered with a port of zero MUST be marked with port
>    zero in the answer."
>
> By overriding this second normative statement for bundle clients, we turn
> it into an extremely well-defined extension point.
>
> ----------------------------------------------------------------------
>
> But this is exactly the approach that is causing people heartburn, so
> let's look at other potential ways of achieving the goal. In a media
> section, there are only a small handful of fields that an implementation is
> required to read and understand:
>
>   m= /   ...
>   c=  
>
> Taken one-by-one:
>
>
>    1. Extending "media" would be somewhat problematic, since we use this
>    information extensively in our use cases. We would effectively have to
>    register bundle-only variations on "audio," "video," and "application" (at
>    a minimum), which is horribly inelegant.
>
>     2. Port is discussed above.
>
>     3. Setting "number of ports" to zero would clearly have the semantics
>    that we're interested in here. The down-side of using this approach is that
>    (in my experience) there are a lot of implementations that simply ignore
>    the "number of ports" field, and a small handful that simply choke when it
>    is present.
>
>     4. Proto is an interesting one. Right now, we use RTP/SAVPF and
>    DTLS/SCTP. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY
>    and DTLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle
>    clients as unrecognized.
>
>     5. Fmt isn't really an option -- we need to use it to identify
>    formats.
>
>     6. Moving on to the c= line (which, if present, is mandatory to
>    parse, understand, and honor), nettype is pretty much hardwired to "IN." We
>    could register an "IN-BUNDLEONLY" option, but there's a good chance that
>    implementations don't really look at the value of this field, so they
>    wouldn't reject the new value.
>
>     7. Addrtype is necessary for indicating IP4 versus IP6. We could
>    register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as
>    elegant as option #1.
>
>     8. Overloading connection-address would be dicey, since it ruins the
>    ability to send different streams to different places. While WebRTC might
>    not care too much about these use cases, they *are* important in other
>    contexts.
>
> In summary: of the above options, the strongest option still seems to be
> "port," followed (perhaps) by "proto." We could probably force "media" or
> "addrtype" to work, but these would be pretty messy. I think "number of
> ports" and "nettype" are at high risk of being ignored by non-bundle
> implementations (i.e., they won't trigger the failure we want), and we need
> to maintain the existing meanings for "fmt" and "connection-address".
>
> Even more tersely: if we don't want to port zero, I think the only other
> realistic option is registering new "proto" values.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--f46d044286e2e9d56604e94cca45
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Oct 15, 2013 at 8:51 AM, Adam Roach <<=
a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g=
t; wrote:




 =20

   =20
 =20
  

    There's been a bit of a brouhaha (from small but disproportionately
    vocal quarters) around the use of port zero in an offer for
    bundle-only lines. So I wanted to take a step back and see whether
    we could untangle this knot a bit.

    

    The key property that we need here is that bundle-only lines must be
    formed in a way that causes them to be rejected by non-bundling
    agents, but accepted by bundling agents

Just for clarity, it must be rejected in such a way that failure to =
compelte
ICE, etc. does not lead to connection failure.




-Ekr
=A0
=

. Since bundle deals with
    ports, that seems like an extremely natural place to make the
    distinction. It has the spectacular advantage of being defined in a
    crystal clear way in RFC 3264:

    

    =A0 "A port number of zero in the offer indicates that the

    =A0=A0 stream is offered but MUST NOT be used.=A0 This has no useful
    semantics

    =A0=A0 in an initial offer, but is allowed for reasons of
    completeness..."

    

    =A0 "A stream that is offered with a port of zero MUST be marked w=
ith
    port

    =A0=A0 zero in the answer."

    

    By overriding this second normative statement for bundle clients, we
    turn it into an extremely well-defined extension point.

    

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

    

    But this is exactly the approach that is causing people heartburn,
    so let's look at other potential ways of achieving the goal. In a
    media section, there are only a small handful of fields that an
    implementation is required to read and understand:

    

    =A0 m=3D<media> <port>/<number of ports> <proto>=
;
    <fmt> ...

    =A0 c=3D<nettype> <addrtype> <connection-address>

    

    Taken one-by-one:

    

    
    
      
  1. Extending "media" would be somewhat problematic, since =
we use
        this information extensively in our use cases. We would
        effectively have to register bundle-only variations on "audio,=
"
        "video," and "application" (at a minimum), whic=
h is horribly
        inelegant.
    
        
    
      
    2. 
      
  2. Port is discussed above.
    
        
    
      
    3. 
      
  3. Setting "number of ports" to zero would clearly have th=
e
        semantics that we're interested in here. The down-side of using
        this approach is that (in my experience) there are a lot of
        implementations that simply ignore the "number of ports" =
field,
        and a small handful that simply choke when it is present.
    
        
    
      
    4. 
      
  4. Proto is an interesting one. Right now, we use RTP/SAVPF and
        DTLS/SCTP. We could conceivably additionally register
        RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would
        presumably be rejected by non-bundle clients as unrecognized.
    
        
    
      
    5. 
      
  5. Fmt isn't really an option -- we need to use it to identify
        formats.
    
        
    
      
    6. 
      
  6. Moving on to the c=3D line (which, if present, is mandatory to
        parse, understand, and honor), nettype is pretty much hardwired
        to "IN." We could register an "IN-BUNDLEONLY" o=
ption, but
        there's a good chance that implementations don't really loo=
k at
        the value of this field, so they wouldn't reject the new value.=

    
        
    
      
    7. 
      
  7. Addrtype is necessary for indicating IP4 versus IP6. We could
        register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is
        approximately as elegant as option #1.
    
        
    
      
    8. 
      
  8. Overloading connection-address would be dicey, since it ruins
        the ability to send different streams to different places. While
        WebRTC might not care too much about these use cases, they *are*
        important in other contexts.
    9. 
    

    
In summary: of the above options, the strongest option still
      seems to be "port," followed (perhaps) by "proto."=
; We could
      probably force "media" or "addrtype" to work, but=
 these would be
      pretty messy. I think "number of ports" and "nettype&q=
uot; are at high
      risk of being ignored by non-bundle implementations (i.e., they
      won't trigger the failure we want), and we need to maintain the
      existing meanings for "fmt" and "connection-address&qu=
ot;.

    

    
Even more tersely: if we don't want to port zero, I think the
      only other realistic option is registering new "proto" valu=
es.

    

    
/a

    

  



_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--f46d044286e2e9d56604e94cca45--

From suhasietf@gmail.com  Mon Oct 21 23:36: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 DC6F911E8484 for ; Mon, 21 Oct 2013 23:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.856
X-Spam-Level: 
X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9sc-bR4pmX6 for ; Mon, 21 Oct 2013 23:36:41 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 338E011E847E for ; Mon, 21 Oct 2013 23:36:23 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id m15so7543813wgh.25 for ; Mon, 21 Oct 2013 23:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=LZukQVwrfzYCAotSDeLyLQJ5cCrXrgPKN/h8VAuDtPw=; b=Kcrnty8qx/LFtnIQE0mKj7XSV75GpiWL2E+itH4a1RmAILoTJ6Nwb1FAufW2XEqrnF +8F1odauQL2auwo5AihhDbV/jTnx8C8Gt+cQObOl+tZhX74BoUkLTtxvyt3eBHW4qL+b SIqBZdnlIDOlPPQqVeBTn8+dGc8pg/7UZIxgrAQ2YhhDpwfhQnDQQauMVXUgH9wELJtS tKRrsjmYAsFmHhf2//NwCFoIR39u+Abxr1h4TmtjgX2AvRVheUoFCm3kcMQplf8hPYe2 8qIv4B2Nwkvd5MJ3XZE7S8kM/yrSkxNjSPEVRY0VV1P7uo74izjeoqS6ys8gtxxdX3zU Ghlw==
MIME-Version: 1.0
X-Received: by 10.180.185.101 with SMTP id fb5mr12960218wic.11.1382423780036;  Mon, 21 Oct 2013 23:36:20 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Mon, 21 Oct 2013 23:36:20 -0700 (PDT)
Date: Mon, 21 Oct 2013 23:36:20 -0700
Message-ID: 
From: Suhas Nandakumar 
To: mmusic WG 
Content-Type: multipart/alternative; boundary=001a11c2448e56982204e94e9e2e
Cc: Cullen Jennings , Harald Alvestrand , Christer Holmberg 
Subject: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??
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 Oct 2013 06:36:42 -0000

--001a11c2448e56982204e94e9e2e
Content-Type: text/plain; charset=ISO-8859-1

Hello All

   Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05 defines
one category of OPEN ISSUE that was raised while analyzing multiplexing
behavior of RFC4855, RFC5583 attributes for example.

As an example, let's consider the  SDP Example (copied from the draft)


// PTs are shared and have different feedback types
   a=group:BUNDLE audio video
   m=audio 3456 RTP/AVP 98
   a=mid:audio
   a=rtpmap:98 iLBC/8000
   a=rtcp-fb ack                  // Positive ACK
   m=video 3456 RTP/AVP 98
   a=mid:video
   a=rtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK


In the above case, PT 98 is repeated between the audio and video media
lines. Audio media line has rtcp-fb ack and video media line has rtcp-fb
nack.

Since RTCP reporting happens per RTP Session, we can see the following high
level questions :

0. Should this be allowed ?

1. What should be the expected behavior in this scenario ?

2. What category assignment makes sense in here - IDENTICAL or NORMAL ??


Cheers
Suhas

--001a11c2448e56982204e94e9e2e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello All

=A0 =A0Section 5.2 in the dra=
ft-nandakumar-mmusic-sdp-mux-attributes-05 defines one category of OPEN ISS=
UE that was raised while analyzing multiplexing behavior of RFC4855, RFC558=
3 attributes for example.



As an example, let's consider the =A0SDP Example (c=
opied from the draft)

// PTs are shared and have different feedback types
   a=3Dgroup:BUNDLE audio video
   m=3Daudio 3456 RTP/AVP 98
   a=3Dmid:audio
   a=3Drtpmap:98 iLBC/8000
   a=3Drtcp-fb ack                  // Positive ACK
   m=3Dvideo 3456 RTP/AVP 98
   a=3Dmid:video
   a=3Drtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK

In the above case, PT=
 98 is repeated between the audio and video media lines. Audio media line h=
as rtcp-fb ack and video=A0media line has rtcp-fb nack.=A0



<=
font color=3D"#000000">Since RTCP reporting happens per RTP Session, we can=
 see the following high level questions :=A0



0. Should this be allowed ?=A0

1. What should be t=
he expected behavior in this scenario ?



<=
span style=3D"color:rgb(0,0,0);font-size:1em">2. What category assignment m=
akes sense in here - IDENTICAL or NORMAL ??




Cheers
Suhas

=






--001a11c2448e56982204e94e9e2e--

From christer.holmberg@ericsson.com  Tue Oct 22 00:07:24 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 396EA11E848B for ; Tue, 22 Oct 2013 00:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.377
X-Spam-Level: 
X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W45bu+g7omgU for ; Tue, 22 Oct 2013 00:07:18 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53311E8480 for ; Tue, 22 Oct 2013 00:07:07 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-d9-526624193f84
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 54.EF.03802.91426625; Tue, 22 Oct 2013 09:07:05 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 09:07:05 +0200
From: Christer Holmberg 
To: Suhas Nandakumar , mmusic WG 
Thread-Topic: BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??
Thread-Index: AQHOzvEGAK09jdqBHE6Hl1BA4xIV25oATL0l
Date: Tue, 22 Oct 2013 07:07:04 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_y6y54kq11531bhadxepc59up1382425621852emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvja6kSlqQway3hhYdk9ksTtw4zWwx dfljFoudczuYHVg8pvzeyOqxc9Zddo8Fm0o9liz5yRTAEsVlk5Kak1mWWqRvl8CVMeH0TtaC TSoVNw8sZmxgXC/XxcjJISFgIrFseSszhC0mceHeejYQW0jgMKPE3cthEPYSRon1Tzm7GDk4 2AQsJLr/aYOERQTcJfZd/8wKYjMLeEmcPnuABcQWFvCVWLfoCRtETYDE2f1vmSFsI4krbxuY QMawCKhKLDmZBBLmFXCTOPUQokQIqHzJ5fXsIDanQKDE5tl9YGMYgS77fmoNE8QqcYlbT+Yz QVwsILFkz3mo60UlXj7+B3VOjkRrUy8LxHxBiZMzn7BMYBSZhaR9FpKyWUjKIOJ6EjemTmGD sLUlli18zQxh60rM+HeIBVl8ASP7Kkb23MTMnPRyo02MwMg6uOW36g7GO+dEDjFKc7AoifN+ eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx5aVv1n8Du6+J6+atN//V8d85MtPtzL2y qSlKIruyVNJTmoVzj+5zf9QRaKM9j6HU2Z5FcO5jmzchd39nFSSaPnNcXrfp5J4C7Vcrn/yI On5l6bbUD2FljhvrshpTMuwT5p+Zkif357mJNnfI1Y3h/j9mMm3eHMd+Lzml2kM5xqD9/rJt ErOUWIozEg21mIuKEwEBhsqaegIAAA==
Cc: Cullen Jennings , Harald Alvestrand 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??
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 Oct 2013 07:07:24 -0000

--_000_y6y54kq11531bhadxepc59up1382425621852emailandroidcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

There is an ongoing discussion regarding the usage of identical PT values, =
where Jonathan and Bo have suggested criteria.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Suhas Nandakumar  wrote:



Hello All

   Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05 defines=
 one category of OPEN ISSUE that was raised while analyzing multiplexing be=
havior of RFC4855, RFC5583 attributes for example.

As an example, let's consider the  SDP Example (copied from the draft)



// PTs are shared and have different feedback types
   a=3Dgroup:BUNDLE audio video
   m=3Daudio 3456 RTP/AVP 98
   a=3Dmid:audio
   a=3Drtpmap:98 iLBC/8000
   a=3Drtcp-fb ack                  // Positive ACK
   m=3Dvideo 3456 RTP/AVP 98
   a=3Dmid:video
   a=3Drtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK

In the above case, PT 98 is repeated between the audio and video media line=
s. Audio media line has rtcp-fb ack and video media line has rtcp-fb nack.

Since RTCP reporting happens per RTP Session, we can see the following high=
 level questions :

0. Should this be allowed ?

1. What should be the expected behavior in this scenario ?

2. What category assignment makes sense in here - IDENTICAL or NORMAL ??


Cheers
Suhas



--_000_y6y54kq11531bhadxepc59up1382425621852emailandroidcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi,=0A=
=0A=
There is an ongoing discussion regarding the usage of identical PT values, =
where Jonathan and Bo have suggested criteria.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Suhas Nandakumar <suhasietf@gmail.com> wrote:=0A=
=0A=





Hello All






   Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attrib=
utes-05 defines one category of OPEN ISSUE that was raised while analyzing =
multiplexing behavior of RFC4855, RFC5583 attributes for example.







As an example, let's consider the  SDP Example (copied from the d=
raft)









// PTs are shared and have different feedback types
   a=3Dgroup:BUNDLE audio video
   m=3Daudio 3456 RTP/AVP 98
   a=3Dmid:audio
   a=3Drtpmap:98 iLBC/8000
   a=3Drtcp-fb ack                  // Positive ACK
   m=3Dvideo 3456 RTP/AVP 98
   a=3Dmid:video
   a=3Drtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK











In the above case, PT =
98 is repeated between the audio and video media lines. Audio media line ha=
s rtcp-fb ack and video media line has rtcp-fb nack. 







Since RTCP reporting happens per RTP Session, =
we can see the following high level questions : 







0. Should this be allowed ? 







1. What should be the =
expected behavior in this scenario ?







2. What category assig=
nment makes sense in here - IDENTICAL or NORMAL ??












Cheers


Suhas


















--_000_y6y54kq11531bhadxepc59up1382425621852emailandroidcom_--

From ari.keranen@ericsson.com  Tue Oct 22 01:01: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 4FEC411E8177 for ; Tue, 22 Oct 2013 01:01:32 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhiUjn8zg+po for ; Tue, 22 Oct 2013 01:01:27 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A63B511E82FB for ; Tue, 22 Oct 2013 01:01:24 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-13-526630d3d890
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 47.A0.16099.3D036625; Tue, 22 Oct 2013 10:01:23 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.37]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 10:01:23 +0200
From: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
To: Emil Ivov 
Thread-Topic: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Thread-Index: Ac7MD6NfvGuI93GmRnipYmfd4J6njP//4E2AgAAueYCAAT86AIAAFkwAgAM3nwCAAEZjgIAAQsKAgAAHGICAAIzVAA==
Date: Tue, 22 Oct 2013 08:01:21 +0000
Message-ID: <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7C043CFE6AF7654695DC6C8AB16BC00C@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje5lg7QggyuLjCz2/F3EbrFm5wQW i6nLH7NYvL++ksWBxWPK742sHkuW/GTy+P8m0GPWzicsASxRXDYpqTmZZalF+nYJXBnLe3Yz F/QqVqxYuZelgfGXZBcjJ4eEgInE/IM7WSFsMYkL99azdTFycQgJHGaU6Dy9mA0kISSwmFHi 7UFxEJtNwF5i8pqPjCC2iIC8RHfbIiYQm1kgT+Ljg8dg9cICDhLP36xjh6hxlLi/ZD0rhJ0l 0X5gF0sXIwcHi4CqxKVd8iBhXgFfib8/LrJA7H3KLHGi8w3YHE6BQIkbe+eD7WIEOu77qTVQ u8Qlbj2ZzwRxtIDEkj3nmSFsUYmXj/9BPaMksej2Z6h6PYkbU6ewQdjWEj9/PIGytSWWLXzN DHGEoMTJmU9YJjCKz0KyYhaS9llI2mchaZ+FpH0BI+sqRvbcxMyc9HLDTYzAyDu45bfuDsZT 50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbH/yW1+1p/uF28vmB2q uS/9/Zd2yd8mH2YXzZy0Iu7Ioyudz3R+7N594P11759BuzmDvW6z7TTm+m892VKjoNNNq1iv hb2xqnMmR43tXotb256H31HM9Nu8y/zJ3carE+x/qjxi+xufpp0/34vB92OTRrrcyoRGt1Le 4hM9xXd/W13m1JWqsVRiKc5INNRiLipOBADEN5miigIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 08:01:32 -0000

On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
> On Tue, Oct 22, 2013 at 1:11 AM, Ari Ker=E4nen =
 wrote:
>>=20
>> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>>=20
>>> I still don't get it. Why would we recommend values for different appli=
cations? We already tell applications to pace checks in accordance with exp=
ected traffic, which they supposedly can gauge better than the text in our =
RFC.
>>>=20
>>> A minimum value does make sense because it would basically say: "don't =
go below this value or you might brake the network or otherwise cause harm"=
. That's actually useful advice.
>>=20
>> Exactly. We're not proposing (different) values for different applicatio=
n. The proposal is to pace checks according to the expected traffic. For RT=
P there is a formula, for other traffic you're on your own (come up with fo=
rmula, or what ever). The "second" value is only for the cases where you do=
n't know better and should use something conservative.
>=20
> If you don't know better why wouldn't you just use RTP's 20 ms pacing
> given that we've already blessed it as safe and harmless and NAT
> friendly?
>=20

20 ms pacing has been blessed NAT friendly but not necessarily safe and har=
mless for the rest of the network. Also, if you start sending connectivity =
checks faster than your uplink can handle, you'll end up with false negativ=
es due to dropped connectivity check packets. Hence I do see value in being=
 a bit conservative if you don't know better.

But would you like to see only a single value, 20 ms, which should be used =
always for pacing and no other recommended values whatsoever?


Cheers,
Ari


>>=20
>>> Now, having two such values starts being weird again, unless we have da=
ta that shoes that networks break differently depending on the UDP payload =
or port number or whatever.
>>>=20
>>> --sent from my mobile
>>>=20
>>> On 21 Oct 2013 14:01, "Ari Ker=E4nen"  wrote:
>>> On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
>>> On Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>>> On 18.10.13, 19:30, Adam Roach wrote:
>>> On 10/18/13 09:44, Emil Ivov wrote:
>>> It might be worth reminding exactly what these 50ms would be
>>> protecting us against
>>>=20
>>> They're protecting us against RTP arriving at a rate of 20ms per
>>> packet.
>>>=20
>>> That would indeed be one of the reasons to pace checks (in addition
>>> to fragile NAT boxes IIRC), however in either case, I fail to
>>> realise why we need a different pacing strategy for non-RTP. This
>>> is what I was asking about.
>>>=20
>>> Connectivity check hammers can still resort to RTP if the pacing
>>> timer is their only problem and I don't see why shaky NATs would
>>> tolerate a 20ms rate for RTP but only a 50ms for anything else.
>>>=20
>>> This entire separation sounds quite arbitrary right now. I see why
>>> we would pick a value that we consider somewhat safe and secure but
>>> I don't understand why we would need two!?
>>>=20
>>> I agree. No need to add more complexity. ICE should be ignorant of
>>> what traffic goes through the pinholes.
>>>=20
>>> The idea would be to have one recommended value (or set of) for all kin=
ds of traffic but with RTP you would have this "additional piece of informa=
tion" (due to the knowledge of your traffic pattern and the formula to rela=
te that to pacing) that would allow you to go below the conservative recomm=
ended value. If you would have something similar with non-RTP traffic, you =
could use that.
>>>=20
>>> But then for both endpoints agreeing on the value in order to have conn=
ectivity checks happening simultaneously for the same pairs, we'd probably =
need to do some negotiation, similar to what was done with ICE on HIP (http=
://tools.ietf.org/html/rfc5770#section-4.4).
>>>=20
>>>=20
>>> Cheers,
>>> Ari
>>=20
>=20
>=20
>=20
> --=20
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> https://jitsi.org                       FAX:   +33.1.77.62.47.31


From christer.holmberg@ericsson.com  Tue Oct 22 01:02: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 C5ECE11E82FB for ; Tue, 22 Oct 2013 01:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.381
X-Spam-Level: 
X-Spam-Status: No, score=-5.381 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orp1NJKUsi6S for ; Tue, 22 Oct 2013 01:02:29 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB1FC11E817D for ; Tue, 22 Oct 2013 01:02:28 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-4a-526631134345
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6F.D0.16099.31136625; Tue, 22 Oct 2013 10:02:27 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 10:02:27 +0200
From: Christer Holmberg 
To: Harald Alvestrand , Suhas Nandakumar 
Thread-Topic: BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??
Thread-Index: AQHOzvEGAK09jdqBHE6Hl1BA4xIV25oAONYAgAAjADA=
Date: Tue, 22 Oct 2013 08:02:26 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E8C0A@ESESSMB209.ericsson.se>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E8C0AESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja6wYVqQwYt9phYdk9ksTtw4zWwx dfljFoudczuYHVg8pvzeyOqxc9Zddo8Fm0o9liz5yRTAEsVlk5Kak1mWWqRvl8CVcXLpaZaC U5UVl29pNDCuKOti5OSQEDCR+Hm8jwnCFpO4cG89WxcjF4eQwGFGiSV3zzNDOEsYJRZdu83e xcjBwSZgIdH9TxukQUTAT+LGpS/MIDazgLPE1uMgJZwcwgK+Ert6bjFD1ARInN3/Fsq2kpjw o5MVxGYRUJXoWXwUbDEvUP2B5lNQu6YzSrxf3Q02iFMgUOLG5VNgDYxA130/tYYJYpm4xK0n 86GuFpBYsuc8M4QtKvHy8T9WCFtR4ur05VD1+RIv/t5lg1gmKHFy5hOWCYyis5CMmoWkbBaS sllALzMLaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYzsuYmZOenlhpsYgVF3cMtv3R2M p86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj5xX/xx220z5khR+e GVN0tJX9mlbvnuDt2l8Wv/56xUrWyVwxMTo5P+qh1neN3TerpVRCVugHHlr1177qnvKhi0eT uBSObjj9OXiinN2js36iDzLkcxd/tfq03+Ofx/Q2VQ3nFbde5O8+KJVVuT39seXdKULTGk3+ aU/4ayRqMK/q5u2cZd5vlFiKMxINtZiLihMB2WqgfYgCAAA=
Cc: Cullen Jennings , mmusic WG 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??
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 Oct 2013 08:02:35 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4E8C0AESESSMB209erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNClBsZWFzZSBub3RlIHRoZSDigJxERUNJU0lPTiAoQkVSTElOLVExL1EyL1E3KTogVXNh
Z2Ugb2Ygc3BlY2lmaWMgUFQgdmFsdWUgZm9yIHNpbmdsZSBjb2RlYyBjb25maWd1cmF0aW9u4oCd
IHRocmVhZCwgd2VyZSBKb25hdGhhbiBhbmQgQm8gaGF2ZSBwcmVzZW50ZWQgc29tZSBpZGVhcyBm
b3IgdGhlIFBULXZhbHVlLXJldXNlIGNyaXRlcmlhLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K
DQpGcm9tOiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmh0YUBnb29nbGUuY29tXQ0KU2VudDog
MjIuIGxva2FrdXV0YSAyMDEzIDEwOjU2DQpUbzogU3VoYXMgTmFuZGFrdW1hcg0KQ2M6IG1tdXNp
YyBXRzsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEN1bGxlbiBKZW5uaW5ncw0KU3ViamVjdDogUmU6IEJV
TkRMRS9TRFAgOiBJU1NVRSMxOiBTaG91bGQgQlVORExFIGFsbG93L2Rpc2FsbG93IFBUIHNoYXJp
bmcgPz8NCg0KMDogTm8sIHVzaW5nIFBUIDk4IGZvciBib3RoIGF1ZGlvIGFuZCB2aWRlbyBzaG91
bGQgYWJzb2x1dGVseSBub3QgYmUgYWxsb3dlZC4gUmV1c2Ugb2YgYSBQVCBmb3IgZGlmZmVyZW50
IGNvZGVjcyBNVVNUIE5PVCBiZSBkb25lLiBJIHRob3VnaHQgdGhhdCB3YXMgcHJldHR5IGNsZWFy
IGluIEJVTkRMRSBhbHJlYWR5OyBpZiBpdCdzIG5vdCAxMDAlIGNyeXN0YWwgY2xlYXIsIGl0IG5l
ZWRzIHRvIGJlIG1hZGUgY2xlYXIuDQoNCjE6IEVpdGhlciB0aGUgU0RQIHNob3VsZCBiZSByZWpl
Y3RlZCBvdXRyaWdodCBvciB0aGUgcmVzcG9uc2UgdG8gdGhpcyBTRFAgbmVlZHMgdG8gZGlzYWxs
b3cgYnVuZGxpbmcgdGhvc2UgdHdvIGxpbmVzLiBUaGlzIGJlbG9uZ3MgaW4gdGhlIEJVTkRMRSBz
cGVjLCBhbmQgSSB0aG91Z2h0IGl0IHdhcyBwcmV0dHkgY2xlYXIgYWxyZWFkeS4NCg0KMjogSWYg
dGhlIHF1ZXN0aW9uIGlzIGFib3V0IHRoZSAiYT1ydGNwLWZiIiBmaWVsZCwgSSB0aGluayBpdCBz
aG91bGQgYmUgY2xhc3NpZmllZCBhcyBOT1JNQUwuIElmIGl0IGlzIGFib3V0ICJhPXJ0Y3AtZmI6
OTgiLCBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIGNhbGwgaXQgSURFTlRJQ0FMLg0KDQoNCg0KDQpP
biBUdWUsIE9jdCAyMiwgMjAxMyBhdCA4OjM2IEFNLCBTdWhhcyBOYW5kYWt1bWFyIDxzdWhhc2ll
dGZAZ21haWwuY29tPG1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIZWxsbyBB
bGwNCg0KICAgU2VjdGlvbiA1LjIgaW4gdGhlIGRyYWZ0LW5hbmRha3VtYXItbW11c2ljLXNkcC1t
dXgtYXR0cmlidXRlcy0wNSBkZWZpbmVzIG9uZSBjYXRlZ29yeSBvZiBPUEVOIElTU1VFIHRoYXQg
d2FzIHJhaXNlZCB3aGlsZSBhbmFseXppbmcgbXVsdGlwbGV4aW5nIGJlaGF2aW9yIG9mIFJGQzQ4
NTUsIFJGQzU1ODMgYXR0cmlidXRlcyBmb3IgZXhhbXBsZS4NCg0KQXMgYW4gZXhhbXBsZSwgbGV0
J3MgY29uc2lkZXIgdGhlICBTRFAgRXhhbXBsZSAoY29waWVkIGZyb20gdGhlIGRyYWZ0KQ0KDQoN
Cg0KDQoNCg0KDQovLyBQVHMgYXJlIHNoYXJlZCBhbmQgaGF2ZSBkaWZmZXJlbnQgZmVlZGJhY2sg
dHlwZXMNCg0KICAgYT1ncm91cDpCVU5ETEUgYXVkaW8gdmlkZW8NCg0KICAgbT1hdWRpbyAzNDU2
IFJUUC9BVlAgOTgNCg0KICAgYT1taWQ6YXVkaW8NCg0KICAgYT1ydHBtYXA6OTggaUxCQy84MDAw
DQoNCiAgIGE9cnRjcC1mYiBhY2sgICAgICAgICAgICAgICAgICAvLyBQb3NpdGl2ZSBBQ0sNCg0K
ICAgbT12aWRlbyAzNDU2IFJUUC9BVlAgOTgNCg0KICAgYT1taWQ6dmlkZW8NCg0KICAgYT1ydHBt
YXA6OTggVlA4LzkwMDAwDQoNCiAgIGEtcnRjcC1mYjo5OCBuYWNrIHJwc2kgICAgICAgIC8vIE5h
Y2sgQUNLDQoNCkluIHRoZSBhYm92ZSBjYXNlLCBQVCA5OCBpcyByZXBlYXRlZCBiZXR3ZWVuIHRo
ZSBhdWRpbyBhbmQgdmlkZW8gbWVkaWEgbGluZXMuIEF1ZGlvIG1lZGlhIGxpbmUgaGFzIHJ0Y3At
ZmIgYWNrIGFuZCB2aWRlbyBtZWRpYSBsaW5lIGhhcyBydGNwLWZiIG5hY2suDQoNClNpbmNlIFJU
Q1AgcmVwb3J0aW5nIGhhcHBlbnMgcGVyIFJUUCBTZXNzaW9uLCB3ZSBjYW4gc2VlIHRoZSBmb2xs
b3dpbmcgaGlnaCBsZXZlbCBxdWVzdGlvbnMgOg0KDQowLiBTaG91bGQgdGhpcyBiZSBhbGxvd2Vk
ID8NCg0KMS4gV2hhdCBzaG91bGQgYmUgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGluIHRoaXMgc2Nl
bmFyaW8gPw0KDQoyLiBXaGF0IGNhdGVnb3J5IGFzc2lnbm1lbnQgbWFrZXMgc2Vuc2UgaW4gaGVy
ZSAtIElERU5USUNBTCBvciBOT1JNQUwgPz8NCg0KDQpDaGVlcnMNClN1aGFzDQoNCg0KDQo=

--_000_7594FB04B1934943A5C02806D1A2204B1C4E8C0AESESSMB209erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0
dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7
DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6
aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz
aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBub3RlIHRoZSDi
gJxERUNJU0lPTiAoQkVSTElOLVExL1EyL1E3KTogVXNhZ2Ugb2Ygc3BlY2lmaWMgUFQgdmFsdWUg
Zm9yIHNpbmdsZSBjb2RlYyBjb25maWd1cmF0aW9u4oCdIHRocmVhZCwgd2VyZSBKb25hdGhhbiBh
bmQgQm8gaGF2ZSBwcmVzZW50ZWQgc29tZSBpZGVhcw0KIGZvciB0aGUgUFQtdmFsdWUtcmV1c2Ug
Y3JpdGVyaWEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEhhcmFsZCBBbHZlc3RyYW5kIFttYWls
dG86aHRhQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjIuIGxva2FrdXV0YSAyMDEz
IDEwOjU2PGJyPg0KPGI+VG86PC9iPiBTdWhhcyBOYW5kYWt1bWFyPGJyPg0KPGI+Q2M6PC9iPiBt
bXVzaWMgV0c7IENocmlzdGVyIEhvbG1iZXJnOyBDdWxsZW4gSmVubmluZ3M8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IEJVTkRMRS9TRFAgOiBJU1NVRSMxOiBTaG91bGQgQlVORExFIGFsbG93L2Rp
c2FsbG93IFBUIHNoYXJpbmcgPz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4wOiBObywgdXNpbmcgUFQgOTggZm9yIGJvdGggYXVkaW8gYW5kIHZpZGVvIHNob3VsZCBhYnNv
bHV0ZWx5IG5vdCBiZSBhbGxvd2VkLiBSZXVzZSBvZiBhIFBUIGZvciBkaWZmZXJlbnQgY29kZWNz
IE1VU1QgTk9UIGJlIGRvbmUuIEkgdGhvdWdodCB0aGF0IHdhcyBwcmV0dHkgY2xlYXIgaW4gQlVO
RExFIGFscmVhZHk7IGlmIGl0J3Mgbm90IDEwMCUgY3J5c3RhbCBjbGVhciwgaXQgbmVlZHMgdG8g
YmUgbWFkZSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjE6IEVpdGhlciB0aGUgU0RQIHNob3VsZCBiZSByZWplY3RlZCBvdXRyaWdodCBvciB0aGUg
cmVzcG9uc2UgdG8gdGhpcyBTRFAgbmVlZHMgdG8gZGlzYWxsb3cgYnVuZGxpbmcgdGhvc2UgdHdv
IGxpbmVzLiBUaGlzIGJlbG9uZ3MgaW4gdGhlIEJVTkRMRSBzcGVjLCBhbmQgSSB0aG91Z2h0IGl0
IHdhcyBwcmV0dHkgY2xlYXIgYWxyZWFkeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjogSWYgdGhlIHF1ZXN0aW9uIGlzIGFib3V0IHRoZSAm
cXVvdDthPXJ0Y3AtZmImcXVvdDsgZmllbGQsIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGNsYXNzaWZp
ZWQgYXMgTk9STUFMLiBJZiBpdCBpcyBhYm91dCAmcXVvdDthPXJ0Y3AtZmI6OTgmcXVvdDssIGl0
IG1ha2VzIG1vcmUgc2Vuc2UgdG8gY2FsbCBpdCBJREVOVElDQUwuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMjIsIDIwMTMgYXQgODozNiBBTSwgU3VoYXMgTmFu
ZGFrdW1hciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0i
X2JsYW5rIj5zdWhhc2lldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gQWxsPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7U2VjdGlvbiA1LjIgaW4g
dGhlIGRyYWZ0LW5hbmRha3VtYXItbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0wNSBkZWZpbmVz
IG9uZSBjYXRlZ29yeSBvZiBPUEVOIElTU1VFIHRoYXQgd2FzIHJhaXNlZCB3aGlsZSBhbmFseXpp
bmcgbXVsdGlwbGV4aW5nIGJlaGF2aW9yIG9mIFJGQzQ4NTUsIFJGQzU1ODMgYXR0cmlidXRlcyBm
b3IgZXhhbXBsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+QXMgYW4gZXhhbXBsZSwgbGV0J3MgY29uc2lkZXIgdGhlICZuYnNwO1NEUCBFeGFt
cGxlIChjb3BpZWQgZnJvbSB0aGUgZHJhZnQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+Ly8gUFRzIGFyZSBzaGFyZWQgYW5kIGhhdmUgZGlmZmVyZW50
IGZlZWRiYWNrIHR5cGVzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgYT1ncm91cDpCVU5ETEUgYXVkaW8gdmlk
ZW88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPiZuYnNwOyZuYnNwOyBtPWF1ZGlvIDM0NTYgUlRQL0FWUCA5ODxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i
c3A7IGE9bWlkOmF1ZGlvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgYT1ydHBtYXA6OTggaUxCQy84MDAwPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
Ij4mbmJzcDsmbmJzcDsgYT1ydGNwLWZiIGFjayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAvLyBQb3NpdGl2ZSBBQ0s8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyBtPXZpZGVv
IDM0NTYgUlRQL0FWUCA5ODxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IGE9bWlkOnZpZGVvPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsm
bmJzcDsgYT1ydHBtYXA6OTggVlA4LzkwMDAwPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgYS1ydGNwLWZiOjk4
IG5hY2sgcnBzaSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBO
YWNrIEFDSzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBhYm92ZSBjYXNlLCBQVCA5OCBpcyByZXBlYXRl
ZCBiZXR3ZWVuIHRoZSBhdWRpbyBhbmQgdmlkZW8gbWVkaWEgbGluZXMuIEF1ZGlvIG1lZGlhIGxp
bmUgaGFzIHJ0Y3AtZmIgYWNrIGFuZCB2aWRlbyZuYnNwO21lZGlhIGxpbmUgaGFzIHJ0Y3AtZmIg
bmFjay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaW5jZSBSVENQIHJlcG9ydGluZyBo
YXBwZW5zIHBlciBSVFAgU2Vzc2lvbiwgd2UgY2FuIHNlZSB0aGUgZm9sbG93aW5nIGhpZ2ggbGV2
ZWwgcXVlc3Rpb25zIDombmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MC4gU2hv
dWxkIHRoaXMgYmUgYWxsb3dlZCA/Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBXaGF0IHNob3VsZCBiZSB0aGUgZXhw
ZWN0ZWQgYmVoYXZpb3IgaW4gdGhpcyBzY2VuYXJpbyA/PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFdoYXQgY2F0ZWdvcnkgYXNzaWdubWVu
dCBtYWtlcyBzZW5zZSBpbiBoZXJlIC0gSURFTlRJQ0FMIG9yIE5PUk1BTCA/PzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVyczxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiM4ODg4ODgiPlN1aGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7594FB04B1934943A5C02806D1A2204B1C4E8C0AESESSMB209erics_--

From hta@google.com  Tue Oct 22 00:56:56 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 D7C6611E817D for ; Tue, 22 Oct 2013 00:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcr7GVQvKnpc for ; Tue, 22 Oct 2013 00:56:56 -0700 (PDT)
Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFDF11E814C for ; Tue, 22 Oct 2013 00:56:35 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id oz11so4153851veb.36 for ; Tue, 22 Oct 2013 00:56:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FRx+feUyjqkv/mOeSbvuOYeXYJ8LvkhfavOs9/Ya820=; b=CUUa0Qbi/xy3eeTyf5nRv4mQmAz+SPZAqK7vMZQiVGFvBFZZbVL5kLQhpkeMFZEwmD e8ZC0U4d7a6QTdlxXU9AlE8nhxlZBrlGKMT1YBvyr/awUJjYYfRcPv9zIRo4ykdqSkuk Vu6dezmJ6VSzlre2Sjiu9lgCz7/uftgh8w7pdSdMMD80iPkjnc0bYOfehIChGowKCQ1F UIQLHK5LMaCNQ9WSekf3gVGY3MDP0YkUrUbLaUyzDlrIGSU5k4ozAIYl6Jcy3WvfbLc5 FbLUBLalWwYilIlFtISRAYIoOeeqwFNZzu9Lh4Rk0abfdkkntJ/eNmZEolCNTs1ql/Sf JQrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FRx+feUyjqkv/mOeSbvuOYeXYJ8LvkhfavOs9/Ya820=; b=XHXZeHwjT6NhxermG8FP2pXeVSCyrYs8JuVpddSThgvuircxtGqsAjyLNSzvhfzHla Y8A3hvRM/FVWd8cmPKWDihaMwgdzxXJ/O4xWeDXEJXWslOQ5ObcoCMm7MFgFWe8ulFpH mR/TbqMcZwFBE49Oz27ekUwJMf2qqJYMeOHvMq8YslTZHnKzutQE0fkyGAANnsQPAMl9 ld9VVFEBvWLgZOUXf//C8fPz120O6zgDKTp9fUVDoFXrhV2fYXHbexIJDLHMKdaHJyIk t8NYpZrY0bY3n/V57z00Vyj1w3nfc1xLr04s5kiGt3u6oKoG+eBPcFkuzAPZXYw0+f16 Fd/A==
X-Gm-Message-State: ALoCoQmxwypjTOweN+RsJ5qR72ayEQkISlmXT4MRYjcY8292aOpLnX0R2WItuYSQ1cKbZUQ0c0jgM4vwGVB4N73lW/aehCTjOywM9KxyenjI0hA7/K34TVmnZgYojvjcBiZjbu0aVbOIpXusUwYUeWuJihyOkAia7hhpit6JxFncOZ47C7QRHJOWedL73ooPcZcXdd00lSLZ
X-Received: by 10.52.118.73 with SMTP id kk9mr11829934vdb.13.1382428572093; Tue, 22 Oct 2013 00:56:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.176.8 with HTTP; Tue, 22 Oct 2013 00:55:50 -0700 (PDT)
In-Reply-To: 
References: 
From: Harald Alvestrand 
Date: Tue, 22 Oct 2013 09:55:50 +0200
Message-ID: 
To: Suhas Nandakumar 
Content-Type: multipart/alternative; boundary=089e0122f0f2f7b5ef04e94fbb60
X-Mailman-Approved-At: Tue, 22 Oct 2013 01:02:38 -0700
Cc: Cullen Jennings , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??
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 Oct 2013 07:56:57 -0000

--089e0122f0f2f7b5ef04e94fbb60
Content-Type: text/plain; charset=UTF-8

0: No, using PT 98 for both audio and video should absolutely not be
allowed. Reuse of a PT for different codecs MUST NOT be done. I thought
that was pretty clear in BUNDLE already; if it's not 100% crystal clear, it
needs to be made clear.

1: Either the SDP should be rejected outright or the response to this SDP
needs to disallow bundling those two lines. This belongs in the BUNDLE
spec, and I thought it was pretty clear already.

2: If the question is about the "a=rtcp-fb" field, I think it should be
classified as NORMAL. If it is about "a=rtcp-fb:98", it makes more sense to
call it IDENTICAL.





On Tue, Oct 22, 2013 at 8:36 AM, Suhas Nandakumar wrote:

> Hello All
>
>    Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05
> defines one category of OPEN ISSUE that was raised while analyzing
> multiplexing behavior of RFC4855, RFC5583 attributes for example.
>
> As an example, let's consider the  SDP Example (copied from the draft)
>
>
>
> // PTs are shared and have different feedback types
>    a=group:BUNDLE audio video
>    m=audio 3456 RTP/AVP 98
>    a=mid:audio
>    a=rtpmap:98 iLBC/8000
>    a=rtcp-fb ack                  // Positive ACK
>    m=video 3456 RTP/AVP 98
>    a=mid:video
>    a=rtpmap:98 VP8/90000
>    a-rtcp-fb:98 nack rpsi        // Nack ACK
>
>
> In the above case, PT 98 is repeated between the audio and video media
> lines. Audio media line has rtcp-fb ack and video media line has rtcp-fb
> nack.
>
> Since RTCP reporting happens per RTP Session, we can see the following
> high level questions :
>
> 0. Should this be allowed ?
>
> 1. What should be the expected behavior in this scenario ?
>
> 2. What category assignment makes sense in here - IDENTICAL or NORMAL ??
>
>
> Cheers
> Suhas
>
>
>

--089e0122f0f2f7b5ef04e94fbb60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


0: No, using PT 98 for both audio and video should absolut=
ely not be allowed. Reuse of a PT for different codecs MUST NOT be done. I =
thought that was pretty clear in BUNDLE already; if it's not 100% cryst=
al clear, it needs to be made clear.



1: Either the SDP should be rejected outright or the respons=
e to this SDP needs to disallow bundling those two lines. This belongs in t=
he BUNDLE spec, and I thought it was pretty clear already.




2: If the question is about the "a=3Drtcp-fb" field, I=
 think it should be classified as NORMAL. If it is about "a=3Drtcp-fb:=
98", it makes more sense to call it IDENTICAL.







On Tue, Oct 22, 2013 at 8:36 AM, Suhas Nandakumar <suh=
asietf@gmail.com> wrote:



Hello All

=C2=A0 =C2=A0Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attribute=
s-05 defines one category of OPEN ISSUE that was raised while analyzing mul=
tiplexing behavior of RFC4855, RFC5583 attributes for example.





As an example, let's consider the =C2=A0SDP Example=
 (copied from the draft)


// PTs are shared and have different feedback types
   a=3Dgroup:BUNDLE audio video
   m=3Daudio 3456 RTP/AVP 98
   a=3Dmid:audio
   a=3Drtpmap:98 iLBC/8000
   a=3Drtcp-fb ack                  // Positive ACK
   m=3Dvideo 3456 RTP/AVP 98
   a=3Dmid:video
   a=3Drtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK

In the above case, PT 98 is repeated b=
etween the audio and video media lines. Audio media line has rtcp-fb ack an=
d video=C2=A0media line has rtcp-fb na=
ck.=C2=A0





Since RTCP reporting happens per RTP Session, we can see the followin=
g high level questions :=C2=A0


0. Should this be allowed ?=C2=A0=


1. What should be the expected behavior in this sc=
enario ?





2. What category assignment makes sense in here - IDENTICAL or =
NORMAL ??




Cheers
Suhas











--089e0122f0f2f7b5ef04e94fbb60--

From christer.holmberg@ericsson.com  Tue Oct 22 01:10: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 78A8F11E8165 for ; Tue, 22 Oct 2013 01:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[AWL=-1.261,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQsF-1w-yzFb for ; Tue, 22 Oct 2013 01:09:58 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F159711E8344 for ; Tue, 22 Oct 2013 01:09:56 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-f5-526632d3fdb0
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C3.43.25272.3D236625; Tue, 22 Oct 2013 10:09:55 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 10:09:55 +0200
From: Christer Holmberg 
To: Paul Kyzivat , Adam Roach , "Suhas Nandakumar" 
Thread-Topic: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
Thread-Index: Ac7OhpamIvENB/S3QrGtxwOPSJ1SZ///+PCAgAAH8oCAACBwgIAACeUAgAAClwCAAAJvAIAAB4CA//9KrtA=
Date: Tue, 22 Oct 2013 08:09:54 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E8C2B@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com>	<52658733.30802@alum.mit.edu> <20131021215344.GE67188@verdi>	<5265AAB6.40008@alum.mit.edu>  <5265AEEC.4050806@nostrum.com> <5265B537.1010505@alum.mit.edu>
In-Reply-To: <5265B537.1010505@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje5lo7Qgg9+bbCz2/F3EbjF1+WMW ixUbDrBa7JzbwezA4vH3/Qcmj52z7rJ7LFnyk8lj1s4nLAEsUVw2Kak5mWWpRfp2CVwZu6eu ZyzYzlfR9H0JWwPjOe4uRk4OCQETiYZFO5ghbDGJC/fWs3UxcnEICRxllNj36SM7SEJIYAmj xJsbHF2MHBxsAhYS3f+0QUwRgWKJu/uzQCqYBeQlLixZwwRiCws4SLyYvIIVxBYRcJTYsOwv M4SdJLH81mxGkFYWAVWJ48cDQcK8Ar4Su9Z+YYHYeplJYtezbSwgCU4BHYkFk2+DzWQEOu37 KYj5zALiEreezGeCOFlAYsme81Dni0q8fPyPFcJWlLg6fTlUPdCc3Z/YIGxtiWULXzNDLBaU ODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjFyFKcWJ+WmGxlsYgRG0sEtvy12MF7+a3OIUZqD RUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjD5tjGVXt20Ob37Aq6Oy4GFEwj9b 5wuG+oyXl5/V3rHxASvro5dPVzpk+vVsT9C2eLW1OvTChsN/dM2bE343pG2zbz2utt7UJiSi Ufecz8teLqFjfXcvz+sykNTZYSeRHL8gpGfZStEqBuuaWS1cFiKnwlJup3De82UNnNk3Z4qb //WHAu//KrEUZyQaajEXFScCACmtKVhyAgAA
Cc: mmusic WG 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 08:10:03 -0000

Hi,

I have to say that I don't like the idea of copy/pasting the group attribut=
e, including the values, into the m- line (as a groupref attribute), just i=
n order to indicate to which group an m- line shall be added.

It sounds very hacky to me. In addition, it would require string comparison=
 just to identify the group. And, if a group contains multiple mid values (=
people have sometimes talked about tens, even hundreds, of mid values withi=
n a BUNDLE group), where the length of each mid value is 32 bytes, it will =
become a very heavy and clumsy procedure.

As Adam suggested in one e-mail, for BUNDLE one option could be to find the=
 group based on the address properties (which must be identical for each m-=
 line within a BUNDLE group, and identical for each BUNDLE group), ie there=
 would be no need to explicitly indicate the group.

For other groups that may not work. But, again, POF/PAN does not have to be=
 a mechanism which allows people to do "anything" - we need to collect the =
use-cases for which POF/PAN is required.

Regards,

Christer


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Paul Kyzivat
Sent: 22. lokakuuta 2013 2:14
To: Adam Roach; Suhas Nandakumar
Cc: mmusic WG
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?



On 10/21/13 6:47 PM, Adam Roach wrote:

>
> This is giving me a strong sense of deja vu.
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

Oops! You are right. I remember seeing that mail, but not reading it thorou=
ghly. So either I remembered more than I thought, or else I reinvented it.

	Sorry,
	Paul

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

From christer.holmberg@ericsson.com  Tue Oct 22 03:59: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 6939421F9F3D for ; Tue, 22 Oct 2013 03:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.844
X-Spam-Level: 
X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaSB5S95mujk for ; Tue, 22 Oct 2013 03:59:06 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D98F921F9EA2 for ; Tue, 22 Oct 2013 03:59:05 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-ce-52665a78b5e8
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B4.B4.25272.87A56625; Tue, 22 Oct 2013 12:59:05 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 12:59:01 +0200
From: Christer Holmberg 
To: Christer Holmberg , Paul Kyzivat , Adam Roach , Suhas Nandakumar 
Thread-Topic: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
Thread-Index: Ac7OhpamIvENB/S3QrGtxwOPSJ1SZ///+PCAgAAH8oCAACBwgIAACeUAgAAClwCAAAJvAIAAB4CA//9KrtD//mQ9gA==
Date: Tue, 22 Oct 2013 10:58:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E8F30@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se> <52658089.6030008@nostrum.com>	<52658733.30802@alum.mit.edu> <20131021215344.GE67188@verdi>	<5265AAB6.40008@alum.mit.edu>  <5265AEEC.4050806@nostrum.com> <5265B537.1010505@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4E8C2B@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4E8C2B@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.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW5lVFqQwb27vBZ7/i5it5i6/DGL xYoNB1gtds7tYHZg8fj7/gOTx85Zd9k9liz5yeQxa+cTlgCWKC6blNSczLLUIn27BK6MSXOf sRb0ClXc+d7P2sD4iK+LkYNDQsBEon2/VRcjJ5ApJnHh3nq2LkYuDiGBo4wSd39NYodwljBK LJu6nR2kgU3AQqL7nzZIXERgOaPErAVbmUG6mQXkJS4sWcMEYgsLOEi8mLyCFcQWEXCU2LDs LzOEnSXR+GYRWA2LgKrEy93vGUFsXgFfibbln6A2T2eWWHFoOVgRp4CfxMPZF9lBbEag876f gljALCAucevJfCaIswUkluw5zwxhi0q8fPyPFcJWlLg6fTlUvY7Egt0gC0BsbYllC18zQywW lDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxchSnFiflphsZbGIExtPBLb8tdjBe/mtziFGa g0VJnPfjW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzatx8oXZGbu/dnzunCrNeVG22F Nwm8Mwr31Yj8e2O2hNEjtVKLeemhChF7I6KZJmxTU+dd7aI8ab1D0Y2Lt+ZsmDittstrvX+N inVSwd4lAvvD7G7HO9o2btosnWk7X3GjxjeFGd4+wVr+6h/zXmVzWzM/2nzK3+mO9bM9p/fn /b6xQvl8VY0SS3FGoqEWc1FxIgCkZChNdQIAAA==
Cc: mmusic WG 
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?
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 Oct 2013 10:59:11 -0000

"and unique for each BUNDLE group", that is.

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Christer Holmberg
Sent: 22. lokakuuta 2013 11:10
To: Paul Kyzivat; Adam Roach; Suhas Nandakumar
Cc: mmusic WG
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?

Hi,

I have to say that I don't like the idea of copy/pasting the group attribut=
e, including the values, into the m- line (as a groupref attribute), just i=
n order to indicate to which group an m- line shall be added.

It sounds very hacky to me. In addition, it would require string comparison=
 just to identify the group. And, if a group contains multiple mid values (=
people have sometimes talked about tens, even hundreds, of mid values withi=
n a BUNDLE group), where the length of each mid value is 32 bytes, it will =
become a very heavy and clumsy procedure.

As Adam suggested in one e-mail, for BUNDLE one option could be to find the=
 group based on the address properties (which must be identical for each m-=
 line within a BUNDLE group, and identical for each BUNDLE group), ie there=
 would be no need to explicitly indicate the group.

For other groups that may not work. But, again, POF/PAN does not have to be=
 a mechanism which allows people to do "anything" - we need to collect the =
use-cases for which POF/PAN is required.

Regards,

Christer


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Paul Kyzivat
Sent: 22. lokakuuta 2013 2:14
To: Adam Roach; Suhas Nandakumar
Cc: mmusic WG
Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?



On 10/21/13 6:47 PM, Adam Roach wrote:

>
> This is giving me a strong sense of deja vu.
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg12427.html

Oops! You are right. I remember seeing that mail, but not reading it thorou=
ghly. So either I remembered more than I thought, or else I reinvented it.

	Sorry,
	Paul

_______________________________________________
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 ari.keranen@ericsson.com  Tue Oct 22 06:30: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 3FDC411E838D for ; Tue, 22 Oct 2013 06:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.756
X-Spam-Level: 
X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=0.193,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrLmHUcw234Y for ; Tue, 22 Oct 2013 06:30:35 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5750311E8388 for ; Tue, 22 Oct 2013 06:30:33 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-f6-52667df7aa37
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.CD.16099.7FD76625; Tue, 22 Oct 2013 15:30:31 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Tue, 22 Oct 2013 15:30:31 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 336431103CF; Tue, 22 Oct 2013 16:30:31 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AAADC4EAD2; Tue, 22 Oct 2013 16:30:30 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 579264E94F; Tue, 22 Oct 2013 16:30:30 +0300 (EEST)
Message-ID: <52667DF5.70307@ericsson.com>
Date: Tue, 22 Oct 2013 16:30:29 +0300
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson , Jonathan Lennox 
References: <526146F2.1060203@ericsson.com>	<5EA4CE0C-7596-409B-AE72-BD23C9299E16@vidyo.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje732rQgg+1vtCzeX9C12L/4PLPF tTP/GC2mLn/M4sDiMeX3RlaPnbPusnssWfKTyaPt2R32AJYoLpuU1JzMstQifbsEroyjT8+y FdxiqZj77xlLA+Md5i5GTg4JAROJLUub2CFsMYkL99azdTFycQgJHGaUeH55HwuEs4FR4nLn KlYIZy+jxK3Vm5kgnHWMEk9ntLKA9AsJrGCU+LylvouRg4NXQFOi46YGSJhFQFVi7ZQ/jCA2 m4CtxOpXN8HKRQWSJR7dPcUGYvMKCEqcnPkELC4iECrx7/lfJhCbWUBGYsbZRjBbWKBCovNy GzvE3oWMEov3fAFLcAoESjyftIoNosFCYvGbg+wQtrzE9rdzoP5Uk7h6bhMzxJ2qElf/vWKc wCg6C8nuWUjaZyFpX8DIvIqRPTcxMye93HATIzA+Dm75rbuD8dQ5kUOM0hwsSuK8H946BwkJ pCeWpGanphakFsUXleakFh9iZOLglGpgVGOfurEp4Enl4Ta5h41dp40LZ3/ulNlm9YBF886u WWe3NiyZ6OXV5Md7+/3DvQv2Gx9b7j/bkM3wct6XK88sMmbt+izcX/+HMe4Fy0I1saAXXQLb bB/Pr4hfYvan8bjGy328llWZjw6/07gWIfzkXEi56Ka7TafvH+E+U72go+KgIrfXN9GkXUos xRmJhlrMRcWJAK/3krVdAgAA
Cc: mmusic 
Subject: Re: [MMUSIC] Suggested new milestone and adoption of draft-nandakumar-mmusic-sdp-mux-attributes-04 as WG item
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 Oct 2013 13:30:42 -0000

On 10/18/13 9:18 PM, Martin Thomson wrote:
> On 18 October 2013 11:13, Jonathan Lennox  wrote:
>> I think this is an integral and necessary part of BUNDLE -- should it really be a separate milestone?
>
> I had the same sentiment.  Adding the draft name to the existing
> milestone should be sufficient.

Separate milestone makes tracking and correlating work a bit easier for 
us (chairs) so we prefer to have it that way unless there's a very good 
reason to do it other way. We can, and most likely will, of course still 
progress the work in tandem.


Cheers,
Ari

From emil@sip-communicator.org  Tue Oct 22 08:20: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 056FF11E83AB for ; Tue, 22 Oct 2013 08:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+SbjdViNZnQ for ; Tue, 22 Oct 2013 08:20:42 -0700 (PDT)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 29C7211E84B4 for ; Tue, 22 Oct 2013 08:20:36 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id u57so8201990wes.4 for ; Tue, 22 Oct 2013 08:20:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z0Hfx3ulgp6MRmyFzQee65Qekj9wj4Vz0Vfmwp73WK0=; b=PCCqrtDn9D8cFbYhdXedwMVnR77DDmXWfyDxznGjZqBRbYfLIDd0SSkqHg5Os4VFuQ T91mIocWdD98cqX3PrFedRB4omfy30erkLKl9Mdh0y/OWBticX7o19RXNIrMPTdGxK2r fDFUUPTBCIOW/fe5Jg9mKNwim+1qfSowhPeHm3eI9DN5GuxxFHby7bqfNFeq+TccsTuo 6Zg0y8Mly5+vHycrC3tqCojFHovZX+Vet2jwe8fx7fXW9EvtYZvVYRYu3XtxuxFfu3+v UH973hXI4wZW7aoIx3oW1gcTlF0hW1WsoRl7Vuljl6c8BMJwDF7QWyMHnItm628ptxLR HqSQ==
X-Gm-Message-State: ALoCoQkRyKenNxMzE3D4rEUt1LYF4/TAicA9unFU8HecityRlD7YKRZBxO3Hbwke56OpdcoK8xZk
X-Received: by 10.194.178.166 with SMTP id cz6mr2822103wjc.53.1382455236137; Tue, 22 Oct 2013 08:20:36 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:391c:95c6:5a62:75b2]) by mx.google.com with ESMTPSA id w10sm7441296wia.4.2013.10.22.08.20.34 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 08:20:35 -0700 (PDT)
Message-ID: <526697C4.6030207@jitsi.org>
Date: Tue, 22 Oct 2013 17:20:36 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>  <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se>
In-Reply-To: <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 15:20:47 -0000

Hey Ari,

On 22.10.13, 10:01, Ari Ker=E4nen wrote:
> On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
>> On Tue, Oct 22, 2013 at 1:11 AM, Ari Ker=E4nen
>>  wrote:
>>>
>>> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>>>
>>>> I still don't get it. Why would we recommend values for
>>>> different applications? We already tell applications to pace
>>>> checks in accordance with expected traffic, which they
>>>> supposedly can gauge better than the text in our RFC.
>>>>
>>>> A minimum value does make sense because it would basically say:
>>>> "don't go below this value or you might brake the network or
>>>> otherwise cause harm". That's actually useful advice.
>>>
>>> Exactly. We're not proposing (different) values for different
>>> application. The proposal is to pace checks according to the
>>> expected traffic. For RTP there is a formula, for other traffic
>>> you're on your own (come up with formula, or what ever). The
>>> "second" value is only for the cases where you don't know better
>>> and should use something conservative.
>>
>> If you don't know better why wouldn't you just use RTP's 20 ms
>> pacing given that we've already blessed it as safe and harmless and
>> NAT friendly?
>>
>
> 20 ms pacing has been blessed NAT friendly but not necessarily safe
> and harmless for the rest of the network.

Apparently we are happy to take the chance (5245):

    Experiments have shown
    that once every 20 ms is well supported, but not much lower than
    that.  This is why Ta has a lower bound of 20 ms.

> Also, if you start sending
> connectivity checks faster than your uplink can handle, you'll end up
> with false negatives due to dropped connectivity check packets.

Sure, but a second bound of 50ms does not address this. Not more than=20
20ms or 500ms. You can always be on a link that will be saturated.

> Hence
> I do see value in being a bit conservative if you don't know better.

> But would you like to see only a single value, 20 ms, which should be
> used always for pacing and no other recommended values whatsoever?

Yes. If we could say, "go at a pace that emulates that of the ensuing=20
streams, but never go below 20ms", I'd be happy.

I'd also be happy if experimentation shows that the 20ms value needs to=20
be changed to something else.

Emil

>
>
> Cheers, Ari
>
>
>>>
>>>> Now, having two such values starts being weird again, unless we
>>>> have data that shoes that networks break differently depending
>>>> on the UDP payload or port number or whatever.
>>>>
>>>> --sent from my mobile
>>>>
>>>> On 21 Oct 2013 14:01, "Ari Ker=E4nen" 
>>>> wrote: On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote: On
>>>> Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>>>> On 18.10.13, 19:30, Adam Roach wrote: On 10/18/13 09:44, Emil
>>>> Ivov wrote: It might be worth reminding exactly what these 50ms
>>>> would be protecting us against
>>>>
>>>> They're protecting us against RTP arriving at a rate of 20ms
>>>> per packet.
>>>>
>>>> That would indeed be one of the reasons to pace checks (in
>>>> addition to fragile NAT boxes IIRC), however in either case, I
>>>> fail to realise why we need a different pacing strategy for
>>>> non-RTP. This is what I was asking about.
>>>>
>>>> Connectivity check hammers can still resort to RTP if the
>>>> pacing timer is their only problem and I don't see why shaky
>>>> NATs would tolerate a 20ms rate for RTP but only a 50ms for
>>>> anything else.
>>>>
>>>> This entire separation sounds quite arbitrary right now. I see
>>>> why we would pick a value that we consider somewhat safe and
>>>> secure but I don't understand why we would need two!?
>>>>
>>>> I agree. No need to add more complexity. ICE should be ignorant
>>>> of what traffic goes through the pinholes.
>>>>
>>>> The idea would be to have one recommended value (or set of) for
>>>> all kinds of traffic but with RTP you would have this
>>>> "additional piece of information" (due to the knowledge of your
>>>> traffic pattern and the formula to relate that to pacing) that
>>>> would allow you to go below the conservative recommended value.
>>>> If you would have something similar with non-RTP traffic, you
>>>> could use that.
>>>>
>>>> But then for both endpoints agreeing on the value in order to
>>>> have connectivity checks happening simultaneously for the same
>>>> pairs, we'd probably need to do some negotiation, similar to
>>>> what was done with ICE on HIP
>>>> (http://tools.ietf.org/html/rfc5770#section-4.4).
>>>>
>>>>
>>>> Cheers, Ari
>>>
>>
>>
>>
>> -- Emil Ivov, Ph.D.                       67000 Strasbourg, Project
>> Lead                           France Jitsi emcho@jitsi.org
>> PHONE: +33.1.77.62.43.30 https://jitsi.org
>> FAX:   +33.1.77.62.47.31
>
>

--=20
https://jitsi.org


From partha@parthasarathi.co.in  Tue Oct 22 10:02: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 CEFB611E81B3 for ; Tue, 22 Oct 2013 10:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhCkS02GdiLf for ; Tue, 22 Oct 2013 10:02:04 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.154]) by ietfa.amsl.com (Postfix) with ESMTP id 655A311E81BF for ; Tue, 22 Oct 2013 10:02:04 -0700 (PDT)
Received: from userPC (unknown [122.179.44.8]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 71D02869236; Tue, 22 Oct 2013 17:01:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382461323; bh=VY9vv13Frj15nA+p2W3iAjJAOFAaq5kjBqhK7WTttXY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RKNu3RYC4ksGprarfzUjnHNUs/jKUgkzQ5DVpOmm4Xk2wP50Ay5irKGsgCIhHfJ1b 6ELqWvPTei1LzlUZYGv5T3UqyyqpK8yeYcudODf511kI3UjOfVSm+whUeKG3q3YGw8 nmx3cDjprKSAWWWx7yyoM1mRlNxVoOCnDBZtACjU=
From: "Parthasarathi R" 
To: "'Emil Ivov'" 
References: <00a401cece8b$7b00f780$7102e680$@co.in> 
In-Reply-To: 
Date: Tue, 22 Oct 2013 22:31:51 +0530
Message-ID: <00ce01cecf48$6c0b5500$4421ff00$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Ow1WTIRfI7ZqFQkWN1nmCTzoWUwAe2y3A
Content-Language: en-us
X-CTCH-RefID: str=0001.0A0C0208.5266AF8B.00F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154
Cc: 'mmusic' , 'Christer Holmberg' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 17:02:09 -0000

Emil,

In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
unavoidable as per RFC 3264 offer/answer mechanism. The glare handling has
to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVITE.
draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant
SIP UA and no need of extra extension.

INFO based mechanism fails to identify the actual glare situation in
offer/answer.

Of course,  it is possible to reduce the trickle ICE glare handling with
special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in case
both endpoints supports the mechanism. 

Please read inline for more comments.

Thanks
Partha

 

> -----Original Message-----
> From: Emil Ivov [mailto:emcho@jitsi.org]
> Sent: Tuesday, October 22, 2013 6:39 AM
> To: Parthasarathi R
> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
> mmusic-trickle-ice-sip-01
> 
> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>  wrote:
> > Hi all,
> >
> > I have mailed earlier why SIP INFO is not the right choice for
> Trickle ICE
> > in
> > http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
> 
> I remember. Have you noticed my answer?
> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
> 

 Please note that my question is after your answer (msg11964 >
msg11932). 

> > The main
> > reason is the glare handling. I have added the callflow in Sec 6.4 of
> > draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
> look for
> > Trickle ICE handling in SIP w.r.t JSEP mapping.
> 
> I am confused. You say that your main issue is glare handling and yet
> your draft proposes a solution that *introduces* glare (through
> crossing UPDATEs) and then doesn't say anything about handling it. Is
> this intentional? Am I missing something?
> 

 491 is the only known glare handling. We shall work and further
enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situation.
I wish to confirm that INFO mechanism does not work for this situation
before deep diving. 

> > Could you please explain how
> > glare with Trickle ICE Info package will be handled.
> 
> That's simple. Glare does NOT occur when trickling through INFO.

 The actual glare situation will be missed in INFO 

> 
> Emil
> 
> --
> https://jitsi.org


From emil@sip-communicator.org  Tue Oct 22 10:52: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 3B8C011E8225 for ; Tue, 22 Oct 2013 10:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg6tmmZF3BYi for ; Tue, 22 Oct 2013 10:52:22 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3E60F11E83C0 for ; Tue, 22 Oct 2013 10:52:09 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id f12so8319056wgh.19 for ; Tue, 22 Oct 2013 10:52:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zNA40Lic+axiXvYHJfl4+5jjO5z9v59Bvj9lwHUu/Bs=; b=WOPvZxv3LK9M2UgLY5tKwVCn943qdsOBjZ2/QAOoc/7q3RiILVEet3nv5mU48Qsww+ kw5OI83seNPRwC+1P0oxNBTjCW7iqKdkUHfQaWyZTxv8QAyiXzR/MEPv5M5j0zkIgKwu SgI6kkCWX6JnuePMf+4/q8fNKWT/yc8WK3Lv2AVmG78k8FG31tmEfwJ++J2s87ssPCS6 oELJn26h59WXSTbunr2xJI8InnL2fC1EZDJRQ//obv4ygdZvG1Jtr9SHs4/wclEjOA44 gRCgVEwhT8OmE2ivJnf4iI5vxETtMUMzsiGAlv9i+js0eMOw1/p5T1SrtYxRm2lTnLkB jg2g==
X-Gm-Message-State: ALoCoQlUryyhQoft4X6I41GXxCawbXA2779huEoXP/qNbuI2FxeR474/oZLOsF+AiyLp9Gg0X9Bv
X-Received: by 10.180.89.206 with SMTP id bq14mr15681889wib.56.1382464328284;  Tue, 22 Oct 2013 10:52:08 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPSA id jf2sm8677590wic.2.2013.10.22.10.52.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 10:52:07 -0700 (PDT)
Message-ID: <5266BB46.4070305@jitsi.org>
Date: Tue, 22 Oct 2013 19:52:06 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Parthasarathi R 
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>
In-Reply-To: <00ce01cecf48$6c0b5500$4421ff00$@co.in>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mmusic' , 'Christer Holmberg' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 17:52:27 -0000

On 22.10.13, 19:01, Parthasarathi R wrote:
> Emil,
>
> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
> unavoidable

I don't think this is true.

> as per RFC 3264 offer/answer mechanism. The glare handling has
> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVITE.
> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant
> SIP UA and no need of extra extension.

Yes, there is a well defined mechanism for handling glare with 3264. 
With that I agree. (Adoption and implementation levels are a different 
story but let's not worry about that right now.)

The thing is that this mechanism would be hugely inefficient for 
trickle. The likelihood of glare occurring even more than once there is 
extremely high when using UPDATEs.

You are actually quite likely to make the whole process even longer than 
Vanilla ICE so unless your purpose is to make Trickle pointless, I don't 
think this is a good idea.

> INFO based mechanism fails to identify the actual glare situation in
> offer/answer.

I think you might have misunderstood the way trickle ICE works with INFO.

Once the initial offer/answer is complete (and those rely on the regular 
glare handling, independently of trickle or ICE) there are no additional 
offers and answers.

INFO requests transport asynchronous signalling between ICE agents (NOT 
offers and answers) and it is perfectly fine for either party to be 
sending them at any point in time. There's no possibility of glare here.

Does this help clarify things?

Emil


> Of course,  it is possible to reduce the trickle ICE glare handling with
> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in case
> both endpoints supports the mechanism.
>
> Please read inline for more comments.
>
> Thanks
> Partha
>
>
>
>> -----Original Message-----
>> From: Emil Ivov [mailto:emcho@jitsi.org]
>> Sent: Tuesday, October 22, 2013 6:39 AM
>> To: Parthasarathi R
>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
>> mmusic-trickle-ice-sip-01
>>
>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>>  wrote:
>>> Hi all,
>>>
>>> I have mailed earlier why SIP INFO is not the right choice for
>> Trickle ICE
>>> in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>
>> I remember. Have you noticed my answer?
>>
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>
>
>  Please note that my question is after your answer (msg11964 >
> msg11932). 
>
>>> The main
>>> reason is the glare handling. I have added the callflow in Sec 6.4 of
>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
>> look for
>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>>
>> I am confused. You say that your main issue is glare handling and yet
>> your draft proposes a solution that *introduces* glare (through
>> crossing UPDATEs) and then doesn't say anything about handling it. Is
>> this intentional? Am I missing something?
>>
>
>  491 is the only known glare handling. We shall work and further
> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situation.
> I wish to confirm that INFO mechanism does not work for this situation
> before deep diving. 
>
>>> Could you please explain how
>>> glare with Trickle ICE Info package will be handled.
>>
>> That's simple. Glare does NOT occur when trickling through INFO.
>
>  The actual glare situation will be missed in INFO 
>
>>
>> Emil
>>
>> --
>> https://jitsi.org
>
>

-- 
https://jitsi.org

From christer.holmberg@ericsson.com  Tue Oct 22 11:04: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 AED4211E81C1 for ; Tue, 22 Oct 2013 11:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.812
X-Spam-Level: 
X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND+d9bdohrgZ for ; Tue, 22 Oct 2013 11:04:40 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 480FA11E810C for ; Tue, 22 Oct 2013 11:04:40 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-4e-5266be37fdcc
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 01.30.25272.73EB6625; Tue, 22 Oct 2013 20:04:39 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 20:04:38 +0200
From: Christer Holmberg 
To: Emil Ivov , Parthasarathi R 
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54o=
Date: Tue, 22 Oct 2013 18:04:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org>
In-Reply-To: <5266BB46.4070305@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rtd8X1qQwflmEYs1OyewWLTc8bKY uvwxi8XkT32sDiweS5b8ZPL4/ybQ48P8L+weLed62QNYorhsUlJzMstSi/TtErgy1tw7x1pw KLrizO9T7A2Mk3y6GDk5JARMJNasXcoIYYtJXLi3nq2LkYtDSOAoo8TW4/sZIZwljBKH780E cjg42AQsJLr/aYM0iAj4Stze3soMYjMLxEns37ESzBYWSJR48vMvK0RNksT7xd/ZQVpFBPwk Ns+MAAmzCKhKnLk1hQXE5gUa09w3BaxVSOAgo0Tvn2yQck4BTYntX4NAwoxAp30/tYYJYpO4 xK0n85kgThaQWLLnPDOELSrx8vE/VpBWCQEliWlb0yDK8yWWP9rFBrFJUOLkzCcsExhFZyGZ NAtJ2SwkZRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7BFVjLbHi0j4WZDULGDlWMXIUpxYn5aYb GWxiBMbiwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M 3ls/3+/NKNhuIPzZ5fHZqNhv0zaZi22czvTKSOVQzDSOnUUBN91vzZruJjDp34rz6Y5Fuo/m phnN65+6dxtbtphf5IbEd1mzjX7reXD8cbOZLWTOmTR17juetX07crrtlPwv7vzGf2lpUntb i6658nTdgut1bVrr77rP3nmu2T6g+xyDkqSREktxRqKhFnNRcSIA4jblD5MCAAA=
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 18:04:46 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



IF we consider trickle candidates as being identical to server reflexive ca=
ndidates, I am not sure whether there is a risk of an O/A glare. Because, w=
e don't signal server reflexive candidates in O/A either, do we?



If so, then I assume that Offers and Answers would have no impact on trickl=
e candidates (unless, of course, there is an ICE restart). Or?



Regards,



Christer





________________________________
From: Emil Ivov [emcho@jitsi.org]
Sent: Tuesday, 22 October 2013 8:52 PM
To: Parthasarathi R
Cc: Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusi=
c-trickle-ice-sip-01

On 22.10.13, 19:01, Parthasarathi R wrote:
> Emil,
>
> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
> unavoidable

I don't think this is true.

> as per RFC 3264 offer/answer mechanism. The glare handling has
> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVIT=
E.
> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant
> SIP UA and no need of extra extension.

Yes, there is a well defined mechanism for handling glare with 3264.
With that I agree. (Adoption and implementation levels are a different
story but let's not worry about that right now.)

The thing is that this mechanism would be hugely inefficient for
trickle. The likelihood of glare occurring even more than once there is
extremely high when using UPDATEs.

You are actually quite likely to make the whole process even longer than
Vanilla ICE so unless your purpose is to make Trickle pointless, I don't
think this is a good idea.

> INFO based mechanism fails to identify the actual glare situation in
> offer/answer.

I think you might have misunderstood the way trickle ICE works with INFO.

Once the initial offer/answer is complete (and those rely on the regular
glare handling, independently of trickle or ICE) there are no additional
offers and answers.

INFO requests transport asynchronous signalling between ICE agents (NOT
offers and answers) and it is perfectly fine for either party to be
sending them at any point in time. There's no possibility of glare here.

Does this help clarify things?

Emil


> Of course,  it is possible to reduce the trickle ICE glare handling with
> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in c=
ase
> both endpoints supports the mechanism.
>
> Please read inline for more comments.
>
> Thanks
> Partha
>
>
>
>> -----Original Message-----
>> From: Emil Ivov [mailto:emcho@jitsi.org]
>> Sent: Tuesday, October 22, 2013 6:39 AM
>> To: Parthasarathi R
>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
>> mmusic-trickle-ice-sip-01
>>
>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>>  wrote:
>>> Hi all,
>>>
>>> I have mailed earlier why SIP INFO is not the right choice for
>> Trickle ICE
>>> in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>
>> I remember. Have you noticed my answer?
>>
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>
>
>  Please note that my question is after your answer (msg11964 >
> msg11932). 
>
>>> The main
>>> reason is the glare handling. I have added the callflow in Sec 6.4 of
>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
>> look for
>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>>
>> I am confused. You say that your main issue is glare handling and yet
>> your draft proposes a solution that *introduces* glare (through
>> crossing UPDATEs) and then doesn't say anything about handling it. Is
>> this intentional? Am I missing something?
>>
>
>  491 is the only known glare handling. We shall work and further
> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situati=
on.
> I wish to confirm that INFO mechanism does not work for this situation
> before deep diving. 
>
>>> Could you please explain how
>>> glare with Trickle ICE Info package will be handled.
>>
>> That's simple. Glare does NOT occur when trickling through INFO.
>
>  The actual glare situation will be missed in INFO 
>
>>
>> Emil
>>
>> --
>> https://jitsi.org
>
>

--
https://jitsi.org

--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <164E0BE3209F4F4780A6CD0732B7F623@ericsson.com>
Content-Transfer-Encoding: quoted-printable











Hi,


 


IF we consider trickle candidates as being identical to server refl=
exive candidates, I am not sure whether there is a risk of an O/A glare. Be=
cause, we don't signal server reflexive candidates in O/A either, do we?

 


If so, then I assume that Offers and Answers would have no impact on tri=
ckle candidates (unless, of course, there is an ICE restart). Or?


 


Regards,


 


Christer


 


 






From: Emil Ivov [emcho@jitsi.org]

Sent: Tuesday, 22 October 2013 8:52 PM

To: Parthasarathi R

Cc: Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'

Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivo=
v-mmusic-trickle-ice-sip-01











On 22.10.13, 19:01, Parthasarathi R wrote:

> Emil,

>

> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
> unavoidable



I don't think this is true.



> as per RFC 3264 offer/answer mechanism. The glare handling has

> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-IN=
VITE.

> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE co=
mpliant

> SIP UA and no need of extra extension.



Yes, there is a well defined mechanism for handling glare with 3264. 

With that I agree. (Adoption and implementation levels are a different 

story but let's not worry about that right now.)



The thing is that this mechanism would be hugely inefficient for 

trickle. The likelihood of glare occurring even more than once there is 
extremely high when using UPDATEs.



You are actually quite likely to make the whole process even longer than 
Vanilla ICE so unless your purpose is to make Trickle pointless, I don't 
think this is a good idea.



> INFO based mechanism fails to identify the actual glare situation in
> offer/answer.



I think you might have misunderstood the way trickle ICE works with INFO.


Once the initial offer/answer is complete (and those rely on the regular 
glare handling, independently of trickle or ICE) there are no additional 
offers and answers.



INFO requests transport asynchronous signalling between ICE agents (NOT 
offers and answers) and it is perfectly fine for either party to be 

sending them at any point in time. There's no possibility of glare here.


Does this help clarify things?



Emil





> Of course,  it is possible to reduce the trickle ICE glare handli=
ng with

> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE i=
n case

> both endpoints supports the mechanism.

>

> Please read inline for more comments.

>

> Thanks

> Partha

>

>

>

>> -----Original Message-----

>> From: Emil Ivov [mailto:emcho@jitsi.org]

>> Sent: Tuesday, October 22, 2013 6:39 AM

>> To: Parthasarathi R

>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic

>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-i=
vov-

>> mmusic-trickle-ice-sip-01

>>

>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R

>> <partha@parthasarathi.co.in> wrote:

>>> Hi all,

>>>

>>> I have mailed earlier why SIP INFO is not the right choice for=


>> Trickle ICE

>>> in

>>> 
http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.

>>

>> I remember. Have you noticed my answer?

>>

>> 
http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html

>>

>

> <Partha> Please note that my question is after your answer (msg1=
1964 >

> msg11932). </Partha>

>

>>> The main

>>> reason is the glare handling. I have added the callflow in Sec=
 6.4 of

>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling=
 will

>> look for

>>> Trickle ICE handling in SIP w.r.t JSEP mapping.

>>

>> I am confused. You say that your main issue is glare handling and =
yet

>> your draft proposes a solution that *introduces* glare (through
>> crossing UPDATEs) and then doesn't say anything about handling it.=
 Is

>> this intentional? Am I missing something?

>>

>

> <Partha> 491 is the only known glare handling. We shall work and=
 further

> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situ=
ation.

> I wish to confirm that INFO mechanism does not work for this situation=


> before deep diving. </Partha>

>

>>> Could you please explain how

>>> glare with Trickle ICE Info package will be handled.

>>

>> That's simple. Glare does NOT occur when trickling through INFO.
>

> <Partha> The actual glare situation will be missed in INFO </=
Partha>

>

>>

>> Emil

>>

>> --

>> https://jitsi.org=


>

>



-- 

https://jitsi.org








--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_--

From christer.holmberg@ericsson.com  Tue Oct 22 11:12: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 EDB4111E814F for ; Tue, 22 Oct 2013 11:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.797
X-Spam-Level: 
X-Spam-Status: No, score=-3.797 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f74OlVdQHB9I for ; Tue, 22 Oct 2013 11:12:24 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 82E0711E8210 for ; Tue, 22 Oct 2013 11:12:23 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-a7-5266c006223c
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 84.A0.25272.600C6625; Tue, 22 Oct 2013 20:12:22 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 20:12:22 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: POF/PAN: Length of mid values
Thread-Index: Ac7PUkEvfSSwviXnTPSLJog1JkUgBQ==
Content-Class: urn:content-classes:message
Date: Tue, 22 Oct 2013 18:12:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@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.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4EBB9CESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjS7bgbQgg41bDCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ9rGtkKPgtV7N7zn72B8RJ/FyMnh4SAicShB6/ZIWwxiQv3 1rN1MXJxCAkcZZRY/nkFM4SzhFFi9emVLF2MHBxsAhYS3f+0QRpEBNQlvu7tYQaxhQXUJJ5c /s4CEdeWaFxznRnC1pNY8a4ZbAGzgJbEjgn7GEFsFgFViablrWD1vAK+Eq8bXrCC2IxAR3w/ tYYJol5c4taT+UwQxwlILNlznhnCFpV4+fgfK8g5EgJKEtO2pkGU50tM+jWJEWKkoMTJmU9Y JjAKz0KyeRaSqbOQtMxC0gIR15O4MXUKG4StLbFs4WtmCFtXYsa/Q1A11hKv/s5hR1azgJFz FSNHcWpxUm66kcEmRmD8HNzy22IH4+W/NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXA+OSPunzQgl4BVeuPrz7L9ux3Pbr0/PTpZSk+8XKBM/cr7e9SOCi0oFl2gn9w bdEu09X21v+OxK1f2ZWadWLd7Ie3EnmOcwY16jHJ6L1/0sn8Z/7UQ5VlG+uLGDS/2h2Rtmhx rDJ7evDu1J26egeYvryvdlbwv/3uxbN1iXcfvSn7F++Ue7evVomlOCPRUIu5qDgRAHtNVKpt AgAA
Subject: [MMUSIC] POF/PAN: Length of mid values
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 Oct 2013 18:12:43 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB9CESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



The draft currently says that the length of the mid value must be at least =
32 randomly chosen characters. AFAIK, the only reason is to prevent that tw=
o endpoints would choose the same mid value.



However, as I indicated in another reply, there might be cases where e.g. a=
 BUNDLE group contains LOTS of m- lines (read: mid values), which means we =
could end up with really long SDP message bodies - just because of the mid =
values.



Wouldn't it be possible to simply assign e.g. a 1 character mid value prefi=
x to the Offerer and the Answerer? That would ensure that they don't assign=
 the same mid value to an m- line, because at least the prefix would always=
 be different.



Regards,



Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB9CESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










Hi,


 


The draft currently says that the length of the mid value must be at lea=
st 32 randomly chosen characters. AFAIK, the only reason is to prevent that=
 two endpoints would choose the same mid value.


 


However, as I indicated in another reply, there might be cases where e.g=
. a BUNDLE group contains LOTS of m- lines (read: mid values), which m=
eans we could end up with really long SDP message bodies - just because of =
the mid values.



 


Wouldn't it be possible to simply assign e.g. a 1 character mid value&nb=
sp;prefix to the Offerer and the Answerer? That would ensure that they don'=
t assign the same mid value to an m- line, because at least the prefix woul=
d always be different.


 


Regards,


 


Christer






--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB9CESESSMB209erics_--

From emil@sip-communicator.org  Tue Oct 22 11:15: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 30C2C11E8215 for ; Tue, 22 Oct 2013 11:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCcf16g-q1F3 for ; Tue, 22 Oct 2013 11:15:08 -0700 (PDT)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id E37A211E814F for ; Tue, 22 Oct 2013 11:15:06 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id t60so8362830wes.26 for ; Tue, 22 Oct 2013 11:15:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EbkRq/XUhG+IyJHXlyDyWdGwzs2OgN6tZzCN7G03D8w=; b=Vr4Fs2TFlHBixhe0ckAmc2JzSoMbfH9nihnrkhlpvBmHpeUyT8rl2tJMDMgyNdRJgY 39KJuOYyEoH09i7u5XTOulRiC4oPDmd0R6EXplM3yZuXNzXv2fCxXHD/TpieCo0Z13jd H9vjbAtVpX0QYo/3tj4DjkC12zxYCh0Dt0gmxZ/PzeVYou08V55Rv8w/tJWimcS7yS2y GBBM40gFECx3o207AFVpjw/54L8m5VDGi/y5CvFj6PxXF3inrZisLwTLtS1ga+qhqKbO IOvguYmVsi4u2BMOZjR7deb0rjdygcd69zAsvFdQnlGkdULGCqwSp14Vql4GwdSK64IM F1Cw==
X-Gm-Message-State: ALoCoQmQm5eEBo1lVctHxXIVZvZWdsoRE4u3PHhgUw88+nCL1TkM1OgjFXdRKfGno4SfjkdxymHh
X-Received: by 10.180.105.194 with SMTP id go2mr15812392wib.39.1382465706104;  Tue, 22 Oct 2013 11:15:06 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPSA id b7sm8867528wiz.8.2013.10.22.11.15.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 11:15:05 -0700 (PDT)
Message-ID: <5266C0A7.5040305@jitsi.org>
Date: Tue, 22 Oct 2013 20:15:03 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Christer Holmberg 
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 18:15:14 -0000

On 22.10.13, 20:04, Christer Holmberg wrote:
> Hi,
>
> IF we consider trickle candidates as being identical to server reflexive

You mean peer reflexive, right?

> candidates, I am not sure whether there is a risk of an O/A glare.

I don't think so either.

> Because, we don't signal server reflexive candidates in O/A either, do we?
>
> If so, then I assume that Offers and Answers would have no impact on
> trickle candidates (unless, of course, there is an ICE restart). Or?

Yes, I believe that's the way to go. We might need to state this 
explicitly in 5245 in order to avoid confusion.

Emil

>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Emil Ivov [emcho@jitsi.org]
> *Sent:* Tuesday, 22 October 2013 8:52 PM
> *To:* Parthasarathi R
> *Cc:* Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
> *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on
> draft-ivov-mmusic-trickle-ice-sip-01
>
> On 22.10.13, 19:01, Parthasarathi R wrote:
>> Emil,
>>
>> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
>> unavoidable
>
> I don't think this is true.
>
>> as per RFC 3264 offer/answer mechanism. The glare handling has
>> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVITE.
>> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant
>> SIP UA and no need of extra extension.
>
> Yes, there is a well defined mechanism for handling glare with 3264.
> With that I agree. (Adoption and implementation levels are a different
> story but let's not worry about that right now.)
>
> The thing is that this mechanism would be hugely inefficient for
> trickle. The likelihood of glare occurring even more than once there is
> extremely high when using UPDATEs.
>
> You are actually quite likely to make the whole process even longer than
> Vanilla ICE so unless your purpose is to make Trickle pointless, I don't
> think this is a good idea.
>
>> INFO based mechanism fails to identify the actual glare situation in
>> offer/answer.
>
> I think you might have misunderstood the way trickle ICE works with INFO.
>
> Once the initial offer/answer is complete (and those rely on the regular
> glare handling, independently of trickle or ICE) there are no additional
> offers and answers.
>
> INFO requests transport asynchronous signalling between ICE agents (NOT
> offers and answers) and it is perfectly fine for either party to be
> sending them at any point in time. There's no possibility of glare here.
>
> Does this help clarify things?
>
> Emil
>
>
>> Of course,  it is possible to reduce the trickle ICE glare handling with
>> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in case
>> both endpoints supports the mechanism.
>>
>> Please read inline for more comments.
>>
>> Thanks
>> Partha
>>
>>
>>
>>> -----Original Message-----
>>> From: Emil Ivov [mailto:emcho@jitsi.org]
>>> Sent: Tuesday, October 22, 2013 6:39 AM
>>> To: Parthasarathi R
>>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
>>> mmusic-trickle-ice-sip-01
>>>
>>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>>>  wrote:
>>>> Hi all,
>>>>
>>>> I have mailed earlier why SIP INFO is not the right choice for
>>> Trickle ICE
>>>> in
>>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>>
>>> I remember. Have you noticed my answer?
>>>
>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>>
>>
>>  Please note that my question is after your answer (msg11964 >
>> msg11932). 
>>
>>>> The main
>>>> reason is the glare handling. I have added the callflow in Sec 6.4 of
>>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
>>> look for
>>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>>>
>>> I am confused. You say that your main issue is glare handling and yet
>>> your draft proposes a solution that *introduces* glare (through
>>> crossing UPDATEs) and then doesn't say anything about handling it. Is
>>> this intentional? Am I missing something?
>>>
>>
>>  491 is the only known glare handling. We shall work and further
>> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situation.
>> I wish to confirm that INFO mechanism does not work for this situation
>> before deep diving. 
>>
>>>> Could you please explain how
>>>> glare with Trickle ICE Info package will be handled.
>>>
>>> That's simple. Glare does NOT occur when trickling through INFO.
>>
>>  The actual glare situation will be missed in INFO 
>>
>>>
>>> Emil
>>>
>>> --
>>>https://jitsi.org 
>>
>>
>
> --
> https://jitsi.org 

-- 
https://jitsi.org

From christer.holmberg@ericsson.com  Tue Oct 22 11: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 8570C11E8178 for ; Tue, 22 Oct 2013 11:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.607
X-Spam-Level: 
X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[AWL=0.641,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o408dDGk0UO for ; Tue, 22 Oct 2013 11:31:42 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C2CE911E8137 for ; Tue, 22 Oct 2013 11:31:37 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-13-5266c488c45b
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 43.6B.03802.884C6625; Tue, 22 Oct 2013 20:31:36 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 20:31:36 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54r//+FhgIAAIpUB///8bUA=
Date: Tue, 22 Oct 2013 18:31:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org>
In-Reply-To: <5266C0A7.5040305@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4EBBEAESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RrfjSFqQwb5XOhZrdk5gsWi542Ux dfljFovJn/pYHVg8liz5yeTx/02gx4f5X9g9Ws71sgewRHHZpKTmZJalFunbJXBlHFjZylyw qJGx4uHVbrYGxnM5XYycHBICJhI922+yQthiEhfurWfrYuTiEBI4zChx8NABZghnCaPEhyfN jF2MHBxsAhYS3f+0QRpEBOQlutsWMYHUMAv0MEos/tHADJIQFkiUePLzLytEUZLE+8Xf2WHs pydvM4HYLAKqEusPvWQEsXkFfCUe7G+AWraISWLGlJ1gzZwCmhL9LW0sIDYj0HnfT60Ba2YW EJe49WQ+E8TZAhJL9pxnhrBFJV4+/scKcqiEgJLEtK1pEOX5Em3rr7JD7BKUODnzCcsERtFZ SCbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w5B1VhLbN3dx4ysZgEjxypG9tzEzJz0 cqNNjMCYPLjlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB ccqS2vilRXr7pqlZibjKv1flfGpzf/sVozAhZtsInUMnDd1VlBI4U/tLv33bkcbNFeb47fK+ 3e6ffsx8mF09yzl74dPCO3f3Mfboepv2GrNeMeAVtf397ZbW05cJzT5brp97oqYR5u3ZZ5cX rJe1pi37YswqIfv1vlGm03QMZ9bM8T2jJmSixFKckWioxVxUnAgA/Vb9WJcCAAA=
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 18:31:47 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4EBBEAESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



>> IF we consider trickle candidates as being identical to server reflexive
>
> You mean peer reflexive, right?



Yes.



But, that actually makes me wonder. Because, I DO believe that peer reflexi=
ve candidates actually ARE sent in SDP Offers/Answers (server reflexive can=
didates obviously aren't). At least I couldn't any text in 5245 indicating =
otherwise.



So, that would mean that if an Offer is received without the peer refexive =
candidates, the answerer would remove them.



The issue that can occur is if you:

- first send an Answer (to an Offer), without candidate X;

- then you send a trickle request with candidate X;

- the trickle request reaches the remote endpoint BEFORE the Answer. The tr=
ickle request will add the candidate, but then the Answer will remove it (a=
s it does not contain candidate X).



Do you understand what I mean? :)



Regards,



Christer









>> candidates, I am not sure whether there is a risk of an O/A glare.
>
> I don't think so either.

>
>> Because, we don't signal server reflexive candidates in O/A either, do w=
e?
>>
>> If so, then I assume that Offers and Answers would have no impact on
>> trickle candidates (unless, of course, there is an ICE restart). Or?
>
> Yes, I believe that's the way to go. We might need to state this
> explicitly in 5245 in order to avoid confusion.





Emil

>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Emil Ivov [emcho@jitsi.org]
> *Sent:* Tuesday, 22 October 2013 8:52 PM
> *To:* Parthasarathi R
> *Cc:* Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
> *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on
> draft-ivov-mmusic-trickle-ice-sip-01
>
> On 22.10.13, 19:01, Parthasarathi R wrote:
>> Emil,
>>
>> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
>> unavoidable
>
> I don't think this is true.
>
>> as per RFC 3264 offer/answer mechanism. The glare handling has
>> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVI=
TE.
>> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE complian=
t
>> SIP UA and no need of extra extension.
>
> Yes, there is a well defined mechanism for handling glare with 3264.
> With that I agree. (Adoption and implementation levels are a different
> story but let's not worry about that right now.)
>
> The thing is that this mechanism would be hugely inefficient for
> trickle. The likelihood of glare occurring even more than once there is
> extremely high when using UPDATEs.
>
> You are actually quite likely to make the whole process even longer than
> Vanilla ICE so unless your purpose is to make Trickle pointless, I don't
> think this is a good idea.
>
>> INFO based mechanism fails to identify the actual glare situation in
>> offer/answer.
>
> I think you might have misunderstood the way trickle ICE works with INFO.
>
> Once the initial offer/answer is complete (and those rely on the regular
> glare handling, independently of trickle or ICE) there are no additional
> offers and answers.
>
> INFO requests transport asynchronous signalling between ICE agents (NOT
> offers and answers) and it is perfectly fine for either party to be
> sending them at any point in time. There's no possibility of glare here.
>
> Does this help clarify things?
>
> Emil
>
>
>> Of course,  it is possible to reduce the trickle ICE glare handling with
>> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in =
case
>> both endpoints supports the mechanism.
>>
>> Please read inline for more comments.
>>
>> Thanks
>> Partha
>>
>>
>>
>>> -----Original Message-----
>>> From: Emil Ivov [mailto:emcho@jitsi.org]
>>> Sent: Tuesday, October 22, 2013 6:39 AM
>>> To: Parthasarathi R
>>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
>>> mmusic-trickle-ice-sip-01
>>>
>>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>>>  wrote:
>>>> Hi all,
>>>>
>>>> I have mailed earlier why SIP INFO is not the right choice for
>>> Trickle ICE
>>>> in
>>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>>
>>> I remember. Have you noticed my answer?
>>>
>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>>
>>
>>  Please note that my question is after your answer (msg11964 >
>> msg11932). 
>>
>>>> The main
>>>> reason is the glare handling. I have added the callflow in Sec 6.4 of
>>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
>>> look for
>>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>>>
>>> I am confused. You say that your main issue is glare handling and yet
>>> your draft proposes a solution that *introduces* glare (through
>>> crossing UPDATEs) and then doesn't say anything about handling it. Is
>>> this intentional? Am I missing something?
>>>
>>
>>  491 is the only known glare handling. We shall work and further
>> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situat=
ion.
>> I wish to confirm that INFO mechanism does not work for this situation
>> before deep diving. 
>>
>>>> Could you please explain how
>>>> glare with Trickle ICE Info package will be handled.
>>>
>>> That's simple. Glare does NOT occur when trickling through INFO.
>>
>>  The actual glare situation will be missed in INFO 
>>
>>>
>>> Emil
>>>
>>> --
>>>https://jitsi.org 
>>
>>
>
> --
> https://jitsi.org 

--
https://jitsi.org

--_000_7594FB04B1934943A5C02806D1A2204B1C4EBBEAESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <3D72533CCC400E4D8890C4D408B49197@ericsson.com>
Content-Transfer-Encoding: quoted-printable












Hi,


 


>> IF we conside=
r trickle candidates as being identical to server reflexive

>

> You mean peer reflexive, right?


 

Yes.


 

But, that actually mak=
es me wonder. Because, I DO believe that peer reflexive candidates actually=
 ARE sent in SDP Offers/Answers (server reflexive candidates obviously aren=
't). At least I couldn't any text in
 5245 indicating otherwise.


 

So, that would mean th=
at if an Offer is received without the peer refexive candidates, the answer=
er would remove them.


 

The issue that can occ=
ur is if you:


- first send an A=
nswer (to an Offer), without candidate X;



- then you send a tric=
kle request with candidate X;


- the trickle request =
reaches the remote endpoint BEFORE the Answer. The trickle request will add=
 the candidate, but then the Answer will remove it (as it does not contain =
candidate X).


 

Do you understand what=
 I mean? :)


 

Regards,=



 

Christer=



 

 

 

 



>> candidates, I am not sure whether there is a risk of an O/A glare.=


>

> I don't think so either.


>

>> Because, we don't signal server reflexive candidates in O/A either=
, do we?

>>

>> If so, then I assume that Offers and Answers would have no impact =
on

>> trickle candidates (unless, of course, there is an ICE restart). O=
r?

>

> Yes, I believe that's the way to go. We might need to state this 

> explicitly in 5245 in order to avoid confusion.




 


 




Emil



>

> Regards,

>

> Christer

>

> ----------------------------------------------------------------------=
--

> *From:* Emil Ivov [emcho@jitsi.org]

> *Sent:* Tuesday, 22 October 2013 8:52 PM

> *To:* Parthasarathi R

> *Cc:* Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'

> *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on

> draft-ivov-mmusic-trickle-ice-sip-01

>

> On 22.10.13, 19:01, Parthasarathi R wrote:

>> Emil,

>>

>> In case of ICE Trickle handling in SIP (based on RFC 3261), glare =
is

>> unavoidable

>

> I don't think this is true.

>

>> as per RFC 3264 offer/answer mechanism. The glare handling has

>> to be done by SIP provided mechanism like 491 handling in UPDATE/R=
E-INVITE.

>> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & IC=
E compliant

>> SIP UA and no need of extra extension.

>

> Yes, there is a well defined mechanism for handling glare with 3264.
> With that I agree. (Adoption and implementation levels are a different=


> story but let's not worry about that right now.)

>

> The thing is that this mechanism would be hugely inefficient for

> trickle. The likelihood of glare occurring even more than once there i=
s

> extremely high when using UPDATEs.

>

> You are actually quite likely to make the whole process even longer th=
an

> Vanilla ICE so unless your purpose is to make Trickle pointless, I don=
't

> think this is a good idea.

>

>> INFO based mechanism fails to identify the actual glare situation =
in

>> offer/answer.

>

> I think you might have misunderstood the way trickle ICE works with IN=
FO.

>

> Once the initial offer/answer is complete (and those rely on the regul=
ar

> glare handling, independently of trickle or ICE) there are no addition=
al

> offers and answers.

>

> INFO requests transport asynchronous signalling between ICE agents (NO=
T

> offers and answers) and it is perfectly fine for either party to be
> sending them at any point in time. There's no possibility of glare her=
e.

>

> Does this help clarify things?

>

> Emil

>

>

>> Of course,  it is possible to reduce the trickle ICE glare ha=
ndling with

>> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDA=
TE in case

>> both endpoints supports the mechanism.

>>

>> Please read inline for more comments.

>>

>> Thanks

>> Partha

>>

>>

>>

>>> -----Original Message-----

>>> From: Emil Ivov [mailto:emcho@jitsi.org]

>>> Sent: Tuesday, October 22, 2013 6:39 AM

>>> To: Parthasarathi R

>>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic

>>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on dra=
ft-ivov-

>>> mmusic-trickle-ice-sip-01

>>>

>>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R

>>> <partha@parthasarathi.co.in> wrote:

>>>> Hi all,

>>>>

>>>> I have mailed earlier why SIP INFO is not the right choice=
 for

>>> Trickle ICE

>>>> in

>>>>http://www.ietf.org/mail-archive/web/m=
music/current/msg11964.html.

>>>

>>> I remember. Have you noticed my answer?

>>>

>>>http://www.ietf.org/mail-archive/web/mmusi=
c/current/msg11932.html

>>>

>>

>> <Partha> Please note that my question is after your answer (=
msg11964 >

>> msg11932). </Partha>

>>

>>>> The main

>>>> reason is the glare handling. I have added the callflow in=
 Sec 6.4 of

>>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE hand=
ling will

>>> look for

>>>> Trickle ICE handling in SIP w.r.t JSEP mapping.

>>>

>>> I am confused. You say that your main issue is glare handling =
and yet

>>> your draft proposes a solution that *introduces* glare (throug=
h

>>> crossing UPDATEs) and then doesn't say anything about handling=
 it. Is

>>> this intentional? Am I missing something?

>>>

>>

>> <Partha> 491 is the only known glare handling. We shall work=
 and further

>> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare =
situation.

>> I wish to confirm that INFO mechanism does not work for this situa=
tion

>> before deep diving. </Partha>

>>

>>>> Could you please explain how

>>>> glare with Trickle ICE Info package will be handled.

>>>

>>> That's simple. Glare does NOT occur when trickling through INF=
O.

>>

>> <Partha> The actual glare situation will be missed in INFO &=
lt;/Partha>

>>

>>>

>>> Emil

>>>

>>> --

>>>https://jitsi.=
org <https://jitsi.=
org/>

>>

>>

>

> --

> https://jitsi.org=
 <https://jitsi.org/>



-- 

https://jitsi.org








--_000_7594FB04B1934943A5C02806D1A2204B1C4EBBEAESESSMB209erics_--

From palmarti@cisco.com  Tue Oct 22 12:56: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 E716F11E8217 for ; Tue, 22 Oct 2013 12:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO8kvxcU1MGH for ; Tue, 22 Oct 2013 12:56:16 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9849411E821A for ; Tue, 22 Oct 2013 12:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5586; q=dns/txt; s=iport; t=1382471757; x=1383681357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SJVzZzHTGbcI2RNTkWETVqtGSRYSdvxDBS5t2yYPxIQ=; b=nEZC2TrDSnftFjva3GgaWrlPu9pVp0Rb2v4LHhvihUh0TFFFbJYRXYRb rF4eOo13T82b5M3/WWS0SPWSguf2nNqnQ61tPCwSoWp/DFIQrg/wx2T9y YNo81cdsEIOsBrI0C0acODGgTgyBOQyB/LKQ62U4xNEaLQcnhmLePPvV/ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwFAKHXZlKtJXG+/2dsb2JhbABZgwc4VL5KgSsWdIIlAQEBAwF5BQkCAgEIDgoKJBsXJQIEDgUIh3gGDbsGBI8XAjEHgx+BCgOJB4sjhQ6QWIMkgio
X-IronPort-AV: E=Sophos;i="4.93,550,1378857600"; d="scan'208";a="275260338"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2013 19:55:52 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9MJtqoe002040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 19:55:52 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.250]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 14:55:52 -0500
From: "Pal Martinsen (palmarti)" 
To: Emil Ivov 
Thread-Topic: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Thread-Index: AQHOzA+s6uVAbsdUW06agGLCJqsZo5n63M2AgAAueYCAAT86AIAAFk2AgAMFVACAAHitgIAAQr2AgAAHHoCAAIzTgIAAeroAgABM6AA=
Date: Tue, 22 Oct 2013 19:55:52 +0000
Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB11558AEE@xmb-rcd-x06.cisco.com>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>  <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se> <526697C4.6030207@jitsi.org>
In-Reply-To: <526697C4.6030207@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.211.209]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8C20037052E7DB41817F7AA65DD39BD0@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 19:56:21 -0000

On Oct 22, 2013, at 17:20 PM, Emil Ivov  wrote:

> Hey Ari,
>=20
> On 22.10.13, 10:01, Ari Ker=E4nen wrote:
>> On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
>>> On Tue, Oct 22, 2013 at 1:11 AM, Ari Ker=E4nen
>>>  wrote:
>>>>=20
>>>> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>>>>=20
>>>>> I still don't get it. Why would we recommend values for
>>>>> different applications? We already tell applications to pace
>>>>> checks in accordance with expected traffic, which they
>>>>> supposedly can gauge better than the text in our RFC.
>>>>>=20
>>>>> A minimum value does make sense because it would basically say:
>>>>> "don't go below this value or you might brake the network or
>>>>> otherwise cause harm". That's actually useful advice.
>>>>=20
>>>> Exactly. We're not proposing (different) values for different
>>>> application. The proposal is to pace checks according to the
>>>> expected traffic. For RTP there is a formula, for other traffic
>>>> you're on your own (come up with formula, or what ever). The
>>>> "second" value is only for the cases where you don't know better
>>>> and should use something conservative.
>>>=20
>>> If you don't know better why wouldn't you just use RTP's 20 ms
>>> pacing given that we've already blessed it as safe and harmless and
>>> NAT friendly?
>>>=20
>>=20
>> 20 ms pacing has been blessed NAT friendly but not necessarily safe
>> and harmless for the rest of the network.
>=20
> Apparently we are happy to take the chance (5245):
>=20
>   Experiments have shown
>   that once every 20 ms is well supported, but not much lower than
>   that.  This is why Ta has a lower bound of 20 ms.
>=20
>> Also, if you start sending
>> connectivity checks faster than your uplink can handle, you'll end up
>> with false negatives due to dropped connectivity check packets.
>=20
> Sure, but a second bound of 50ms does not address this. Not more than 20m=
s or 500ms. You can always be on a link that will be saturated.
>=20
>> Hence
>> I do see value in being a bit conservative if you don't know better.
>=20
>> But would you like to see only a single value, 20 ms, which should be
>> used always for pacing and no other recommended values whatsoever?
>=20
> Yes. If we could say, "go at a pace that emulates that of the ensuing str=
eams, but never go below 20ms", I'd be happy.
>=20
> I'd also be happy if experimentation shows that the 20ms value needs to b=
e changed to something else.
>=20
I second that.

In the scenario where we have different types of medialines in the same SDP=
, for instance RTP and BFCP i think it makes sense to use the same value.=20

If you set up a separate non RTP session it might be worthwhile choosing a =
more conservative value.=20

.-.
P=E5l-Erik




> Emil
>=20
>>=20
>>=20
>> Cheers, Ari
>>=20
>>=20
>>>>=20
>>>>> Now, having two such values starts being weird again, unless we
>>>>> have data that shoes that networks break differently depending
>>>>> on the UDP payload or port number or whatever.
>>>>>=20
>>>>> --sent from my mobile
>>>>>=20
>>>>> On 21 Oct 2013 14:01, "Ari Ker=E4nen" 
>>>>> wrote: On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote: On
>>>>> Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>>>>> On 18.10.13, 19:30, Adam Roach wrote: On 10/18/13 09:44, Emil
>>>>> Ivov wrote: It might be worth reminding exactly what these 50ms
>>>>> would be protecting us against
>>>>>=20
>>>>> They're protecting us against RTP arriving at a rate of 20ms
>>>>> per packet.
>>>>>=20
>>>>> That would indeed be one of the reasons to pace checks (in
>>>>> addition to fragile NAT boxes IIRC), however in either case, I
>>>>> fail to realise why we need a different pacing strategy for
>>>>> non-RTP. This is what I was asking about.
>>>>>=20
>>>>> Connectivity check hammers can still resort to RTP if the
>>>>> pacing timer is their only problem and I don't see why shaky
>>>>> NATs would tolerate a 20ms rate for RTP but only a 50ms for
>>>>> anything else.
>>>>>=20
>>>>> This entire separation sounds quite arbitrary right now. I see
>>>>> why we would pick a value that we consider somewhat safe and
>>>>> secure but I don't understand why we would need two!?
>>>>>=20
>>>>> I agree. No need to add more complexity. ICE should be ignorant
>>>>> of what traffic goes through the pinholes.
>>>>>=20
>>>>> The idea would be to have one recommended value (or set of) for
>>>>> all kinds of traffic but with RTP you would have this
>>>>> "additional piece of information" (due to the knowledge of your
>>>>> traffic pattern and the formula to relate that to pacing) that
>>>>> would allow you to go below the conservative recommended value.
>>>>> If you would have something similar with non-RTP traffic, you
>>>>> could use that.
>>>>>=20
>>>>> But then for both endpoints agreeing on the value in order to
>>>>> have connectivity checks happening simultaneously for the same
>>>>> pairs, we'd probably need to do some negotiation, similar to
>>>>> what was done with ICE on HIP
>>>>> (http://tools.ietf.org/html/rfc5770#section-4.4).
>>>>>=20
>>>>>=20
>>>>> Cheers, Ari
>>>>=20
>>>=20
>>>=20
>>>=20
>>> -- Emil Ivov, Ph.D.                       67000 Strasbourg, Project
>>> Lead                           France Jitsi emcho@jitsi.org
>>> PHONE: +33.1.77.62.43.30 https://jitsi.org
>>> FAX:   +33.1.77.62.47.31
>>=20
>>=20
>=20
> --=20
> https://jitsi.org
>=20


From emil@sip-communicator.org  Tue Oct 22 13:06: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 0159921E8056 for ; Tue, 22 Oct 2013 13:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.018
X-Spam-Level: 
X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=0.581,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGNBoF3xZBxP for ; Tue, 22 Oct 2013 13:06:18 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4645211E824B for ; Tue, 22 Oct 2013 13:06:15 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id ey11so6307835wid.0 for ; Tue, 22 Oct 2013 13:06:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6CgwRdY8fGqXuMPW3+LgKR4LOlKKqAXUAEAlQB6Q2p4=; b=YkgOMYWCeT9zsof07Np5OPkRay/Ebo3JTLr+zDPiJeOfSrl4UJxU6a+70Hsp3HUY/W Pv1ZKUsGfPwzWuisttAj465nJbDxFCmM5XL32pjMT9IdmIWPPgpWgZ87JdrVO2icLAsB Qevn1dPDLVP8SnS6bFctYCPaMv8I7bwKAxytNSkThnkDvxkSdhWRFN0tWC+SCKjWvARo ogbrjovYLWHhI75h/Li/PuW/2jTk9cUwcntKIZClXVZRcew7+AKXixZk/Y9TufwFMCki qH3urxfi5l043wR9dNi/D/0zKtQVzyujOhKLf4Sk+y/aA1w2UtHIGKBdG9CRnYjDCiOC zAQQ==
X-Gm-Message-State: ALoCoQnfXZePpQrn2zwJwIWGIQxZL+u5pBlxJ+J4pFbTTKkO30ZexprXIsFm1N4fjbv1zhPRv5jn
X-Received: by 10.180.105.194 with SMTP id go2mr16179315wib.39.1382472374315;  Tue, 22 Oct 2013 13:06:14 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a04:14f0:a1dd:6d47:cf93:2d4]) by mx.google.com with ESMTPSA id e5sm9691172wiy.2.2013.10.22.13.06.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 13:06:13 -0700 (PDT)
Message-ID: <5266DAB0.7020001@jitsi.org>
Date: Tue, 22 Oct 2013 22:06:08 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Christer Holmberg 
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 22 Oct 2013 20:06:59 -0000

On 22.10.13, 20:31, Christer Holmberg wrote:
> Hi,
>
>>> IF we consider trickle candidates as being identical to server reflexive
>>
>> You mean peer reflexive, right?
>
> Yes.
>
> But, that actually makes me wonder. Because, I DO believe that peer
> reflexive candidates actually ARE sent in SDP Offers/Answers (server
> reflexive candidates obviously aren't). At least I couldn't any text in
> 5245 indicating otherwise.

Mmmmm .... I am not sure I am following. Server reflexive candidates ARE 
signalled in offer/answer with vanilla ICE. That's how agents learn 
about them.

Peer reflexive candidates MAY be signalled with an updated offer. There 
is no requirement to do this, it can't be relied upon and the benefit is 
limited, if any. The implementations that I am aware of don't do it and 
I believe that, especially with trickle, we can easily update 5245bis 
not to include this.

> So, that would mean that if an Offer is received without the peer
> refexive candidates, the answerer would remove them.

You lost me. How would an answerer remove candidates from an offer if 
they weren't there in the first place? Did you mean to say something else?

> The issue that can occur is if you:
>
> - first send an Answer (to an Offer), without candidate X;
>
> - then you send a trickle request with candidate X;
>
> - the trickle request reaches the remote endpoint BEFORE the Answer.

We agreed that the answerer would either wait for a PRACK or an INFO 
with end-of-candidates before starting trickling, so I don't think this 
can happen.

> The
> trickle request will add the candidate, but then the Answer will remove
> it (as it does not contain candidate X).
>
> Do you understand what I mean? :)

I think I do but I am not sure. Why would you consider lack of a 
candidate as an indication that a candidate needs to be removed if 
including that candidate was a MAY in the first place?

I think that in 5245bis we could easily limit offer/answer updates to 
only impact ICE in two ways (which I believe is how current 
implementations work anyway):

1. None: ICE ufrag and pwd are the same and the offer only includes the 
candidates currently in use. (i.e. the O/A was performed for some other 
session modification)
2. ICE Restart: ICE ufrag and pwd are different and this is a complete 
reinitialization of ICE processing.

How does that sound?

Emil


> Christer
>
>
>  >> candidates, I am not sure whether there is a risk of an O/A glare.
>  >
>  > I don't think so either.
>
>  >
>  >> Because, we don't signal server reflexive candidates in O/A either,
> do we?
>  >>
>  >> If so, then I assume that Offers and Answers would have no impact on
>  >> trickle candidates (unless, of course, there is an ICE restart). Or?
>  >
>  > Yes, I believe that's the way to go. We might need to state this
>  > explicitly in 5245 in order to avoid confusion.
>
>
> Emil
>
>  >
>  > Regards,
>  >
>  > Christer
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Emil Ivov [emcho@jitsi.org]
>  > *Sent:* Tuesday, 22 October 2013 8:52 PM
>  > *To:* Parthasarathi R
>  > *Cc:* Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
>  > *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on
>  > draft-ivov-mmusic-trickle-ice-sip-01
>  >
>  > On 22.10.13, 19:01, Parthasarathi R wrote:
>  >> Emil,
>  >>
>  >> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is
>  >> unavoidable
>  >
>  > I don't think this is true.
>  >
>  >> as per RFC 3264 offer/answer mechanism. The glare handling has
>  >> to be done by SIP provided mechanism like 491 handling in
> UPDATE/RE-INVITE.
>  >> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE
> compliant
>  >> SIP UA and no need of extra extension.
>  >
>  > Yes, there is a well defined mechanism for handling glare with 3264.
>  > With that I agree. (Adoption and implementation levels are a different
>  > story but let's not worry about that right now.)
>  >
>  > The thing is that this mechanism would be hugely inefficient for
>  > trickle. The likelihood of glare occurring even more than once there is
>  > extremely high when using UPDATEs.
>  >
>  > You are actually quite likely to make the whole process even longer than
>  > Vanilla ICE so unless your purpose is to make Trickle pointless, I don't
>  > think this is a good idea.
>  >
>  >> INFO based mechanism fails to identify the actual glare situation in
>  >> offer/answer.
>  >
>  > I think you might have misunderstood the way trickle ICE works with INFO.
>  >
>  > Once the initial offer/answer is complete (and those rely on the regular
>  > glare handling, independently of trickle or ICE) there are no additional
>  > offers and answers.
>  >
>  > INFO requests transport asynchronous signalling between ICE agents (NOT
>  > offers and answers) and it is perfectly fine for either party to be
>  > sending them at any point in time. There's no possibility of glare here.
>  >
>  > Does this help clarify things?
>  >
>  > Emil
>  >
>  >
>  >> Of course,  it is possible to reduce the trickle ICE glare handling with
>  >> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE
> in case
>  >> both endpoints supports the mechanism.
>  >>
>  >> Please read inline for more comments.
>  >>
>  >> Thanks
>  >> Partha
>  >>
>  >>
>  >>
>  >>> -----Original Message-----
>  >>> From: Emil Ivov [mailto:emcho@jitsi.org]
>  >>> Sent: Tuesday, October 22, 2013 6:39 AM
>  >>> To: Parthasarathi R
>  >>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>  >>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-
>  >>> mmusic-trickle-ice-sip-01
>  >>>
>  >>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>  >>>  wrote:
>  >>>> Hi all,
>  >>>>
>  >>>> I have mailed earlier why SIP INFO is not the right choice for
>  >>> Trickle ICE
>  >>>> in
>  >>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>  >>>
>  >>> I remember. Have you noticed my answer?
>  >>>
>  >>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>  >>>
>  >>
>  >>  Please note that my question is after your answer (msg11964 >
>  >> msg11932). 
>  >>
>  >>>> The main
>  >>>> reason is the glare handling. I have added the callflow in Sec 6.4 of
>  >>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will
>  >>> look for
>  >>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>  >>>
>  >>> I am confused. You say that your main issue is glare handling and yet
>  >>> your draft proposes a solution that *introduces* glare (through
>  >>> crossing UPDATEs) and then doesn't say anything about handling it. Is
>  >>> this intentional? Am I missing something?
>  >>>
>  >>
>  >>  491 is the only known glare handling. We shall work and further
>  >> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare
> situation.
>  >> I wish to confirm that INFO mechanism does not work for this situation
>  >> before deep diving. 
>  >>
>  >>>> Could you please explain how
>  >>>> glare with Trickle ICE Info package will be handled.
>  >>>
>  >>> That's simple. Glare does NOT occur when trickling through INFO.
>  >>
>  >>  The actual glare situation will be missed in INFO 
>  >>
>  >>>
>  >>> Emil
>  >>>
>  >>> --
>  >>>https://jitsi.org  
>  >>
>  >>
>  >
>  > --
>  > https://jitsi.org  
>
> --
> https://jitsi.org 
>

-- 
https://jitsi.org

From martin.thomson@gmail.com  Tue Oct 22 15:31: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 6631F11E8294 for ; Tue, 22 Oct 2013 15:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo7g185kaoen for ; Tue, 22 Oct 2013 15:31:08 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B911E8283 for ; Tue, 22 Oct 2013 15:31:05 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id w61so8718919wes.38 for ; Tue, 22 Oct 2013 15:31:04 -0700 (PDT)
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=qBVyGzf4083hfd9WqFBSYNyYyNm/vG18z5KbOjEr0BQ=; b=eemu7z/tYMK9Ei46NrcDqeGt7D5A91WmKuByi8Ou8GYLtBMu42AEo2ZUqW8o6fKTyO udg/CNo14ooeqk+IlvchOZ3kF28MmBULiICh03kP3UtAubrYg0jOXbBKlXLhO63G7ppi XJXU9XTXf2vKo0YT3E0Z0gZNfI6tvA+XpI/HuR17xABgbnMYeBhWDGSMDuH9IL/XpyFa XWBeg/wvgEne/laq+dcMlvtvMnGC79Zi6w8fTPA0cp30fwJs5JZdz1VWH/ZT9JxBkUvL gCzII8JzsupOqD4mxDqKszh76zMLBQT70WfIDxFktSYdIFvIT2bwvSKswzKSRZrxOVDD 9thg==
MIME-Version: 1.0
X-Received: by 10.194.89.233 with SMTP id br9mr20438625wjb.15.1382481064451; Tue, 22 Oct 2013 15:31:04 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 22 Oct 2013 15:31:04 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@ESESSMB209.ericsson.se>
Date: Tue, 22 Oct 2013 15:31:04 -0700
Message-ID: 
From: Martin Thomson 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] POF/PAN: Length of mid values
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 Oct 2013 22:31:14 -0000

On 22 October 2013 11:12, Christer Holmberg
 wrote:
> Wouldn't it be possible to simply assign e.g. a 1 character mid value prefix
> to the Offerer and the Answerer?

That would be possible iff you could derive that from the original
context consistently, but I'm not sure that this is possible in SIP
given 3PCC and all the crazy shit that goes on there.

From pkyzivat@alum.mit.edu  Tue Oct 22 20:06: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 68A8511E8100 for ; Tue, 22 Oct 2013 20:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.292
X-Spam-Level: 
X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFIZEacGR1Dz for ; Tue, 22 Oct 2013 20:05:57 -0700 (PDT)
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 F164211E80EC for ; Tue, 22 Oct 2013 20:05:56 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id gSzC1m00k0xGWP851T5wp1; Wed, 23 Oct 2013 03:05:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id gT5w1m0093ZTu2S3YT5wys; Wed, 23 Oct 2013 03:05:56 +0000
Message-ID: <52673D14.7010800@alum.mit.edu>
Date: Tue, 22 Oct 2013 23:05:56 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@ESESSMB209.ericsson.se> 
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=1382497556; bh=2NDCqpRN1rU155oGUY8Ko0QvVnPrHWZSfOmbnR2KWvs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AIXDIXcvUs/zewQKSr6cLWmKe2pVkzWs2yTBFNSub4ZRtm3jLIrBjBh5n9toOlI9l mr3edTB7hkFjupGSf9Z+EfhI5Oc/QQDNI9sHBEMlJeQr9cvtqb+P5Ta54f+FBhV3UQ Y6KYCwNoiWDK/WH/Q0gVE5QRopXyQdeRFVTbgMW/LhqiGWl/miRDeNrTbPWe5Jau3N tX0mEMjCeQwqny9uHdzo6CFK6IO+CTSJVOo9dGbRrJ6v/B2GMc7T+O6kh68DiwUqpj M/xJm6WuX3TaR97zYD7nvvxD1GboAmB02/1vbMEo3UQFX6GMji4du3ln3nBId9mvqP bbu2YPh9Oaumw==
Subject: Re: [MMUSIC] POF/PAN: Length of mid values
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 Oct 2013 03:06:03 -0000

On 10/22/13 6:31 PM, Martin Thomson wrote:
> On 22 October 2013 11:12, Christer Holmberg
>  wrote:
>> Wouldn't it be possible to simply assign e.g. a 1 character mid value prefix
>> to the Offerer and the Answerer?
>
> That would be possible iff you could derive that from the original
> context consistently, but I'm not sure that this is possible in SIP
> given 3PCC and all the crazy shit that goes on there.

I thought about that too.

We *could* say that if there is a middle box that turns offers into 
answers, it also has to fix up the resulting mess. It would, in 
principle, know enough to do it. Boxes that do that already have to fix 
up other stuff.

Or we could define an O/A negotiation for the prefixes. That would still 
require a middle box to do some fixup, but it would be simpler.

Or, as I suggested earlier, we could derive a prefix from other stuff in 
the offer and answer that is likely to result in unique prefixes for the 
two sides. And just ban POF/PAN if it doesn't. (In that case another O/A 
could probably resolve it.)

	Thanks,
	Paul

From christer.holmberg@ericsson.com  Tue Oct 22 20:35: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 9368611E8105 for ; Tue, 22 Oct 2013 20:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.631
X-Spam-Level: 
X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.619,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0KpFj2ANkQo for ; Tue, 22 Oct 2013 20:35:54 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C336E11E82B8 for ; Tue, 22 Oct 2013 20:35:49 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-4e-5267440a6fe6
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.28.03802.A0447625; Wed, 23 Oct 2013 05:35:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 05:35:38 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] POF/PAN: Length of mid values
Thread-Index: Ac7PUkEvfSSwviXnTPSLJog1JkUgBQAE1/MAAAmZgAAABTpZSA==
Date: Wed, 23 Oct 2013 03:35:37 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@ESESSMB209.ericsson.se> , <52673D14.7010800@alum.mit.edu>
In-Reply-To: <52673D14.7010800@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+JvjS6XS3qQwftT+hZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxt+USe8EJ7opl81ezNzBO4Oxi5OSQEDCR 6O/oYoOwxSQu3FsPZHNxCAkcZpRo+fofylnCKHHy+j8gh4ODTcBCovufNkiDiICvxLPHt8Ga hQWMJd5OnssMETeRePx+ATuE7SSx5vdMJpBWFgFViUOLRUFMXgE3iVvTc0EqhAS2MEp8PGEN YnMK6EjMX3wPbCIj0DnfT61hArGZBcQlbj2ZzwRxpoDEkj3nmSFsUYmXj/+xQtToSCzY/YkN wtaWWLbwNVgNr4CgxMmZT1gmMIrMQjJqFpKWWUhaZiFpWcDIsoqRPTcxMye93GgTIzDcD275 rbqD8c45kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgtLS2VNOZ4T/n +nmdToda0cvZso+bgzkXrZ+55sIXtktsny/zVn34uW3ylNWqGzsNhBf9/CHWWu/0JfDz/vSM O8c8H+yZHtUYyuzd7hAnsiPWM3LbOmmvVGa9yF71xmLWN1zRW2Z+a5vmoLQ45Yjpy7KL31/d lCgxXhpXUmTzZ2fKjAMGeqfUlFiKMxINtZiLihMB1rl0t0UCAAA=
Subject: Re: [MMUSIC] POF/PAN: Length of mid values
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 Oct 2013 03:35:59 -0000

Hi,

Yed, the prefix could also be negotiated, e.g. using a new 'midpref' attrib=
ute.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat  wrote:


On 10/22/13 6:31 PM, Martin Thomson wrote:
> On 22 October 2013 11:12, Christer Holmberg
>  wrote:
>> Wouldn't it be possible to simply assign e.g. a 1 character mid value pr=
efix
>> to the Offerer and the Answerer?
>
> That would be possible iff you could derive that from the original
> context consistently, but I'm not sure that this is possible in SIP
> given 3PCC and all the crazy shit that goes on there.

I thought about that too.

We *could* say that if there is a middle box that turns offers into
answers, it also has to fix up the resulting mess. It would, in
principle, know enough to do it. Boxes that do that already have to fix
up other stuff.

Or we could define an O/A negotiation for the prefixes. That would still
require a middle box to do some fixup, but it would be simpler.

Or, as I suggested earlier, we could derive a prefix from other stuff in
the offer and answer that is likely to result in unique prefixes for the
two sides. And just ban POF/PAN if it doesn't. (In that case another O/A
could probably resolve it.)

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

From christer.holmberg@ericsson.com  Wed Oct 23 03:25: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 CF3A911E831F for ; Wed, 23 Oct 2013 03:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.638
X-Spam-Level: 
X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.611,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HJNbNFFN+oY for ; Wed, 23 Oct 2013 03:25:44 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C229811E831B for ; Wed, 23 Oct 2013 03:25:40 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-da-5267a4238990
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 16.76.03802.324A7625; Wed, 23 Oct 2013 12:25:39 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 12:25:39 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54r//+FhgIAAIpUB///8bUCAAAAHAP/+8S7A
Date: Wed, 23 Oct 2013 10:25:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org>
In-Reply-To: <5266DAB0.7020001@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja7ykvQgg+MT9C3W7JzAYtFyx8ti 6vLHLBaTP/WxOrB4LFnyk8nj/5tAjw/zv7B7tJzrZQ9gieKySUnNySxLLdK3S+DKuPP2PWvB BcuKj+feszcwTtTtYuTkkBAwkZh8fDM7hC0mceHeerYuRi4OIYHDjBKHds1lgXCWMEpMXf+O uYuRg4NNwEKi+582SIOIgLxEd9siJpAaZoEeRonFPxqYQRLCAokST37+ZYUoSpJ4v/g7O4Sd JzHzz1smEJtFQFXiz5GpjCA2r4CvxN8Jy9hAbCGBVmaJMxM1QWxOAU2J62+3sYDYjEDXfT+1 BqyXWUBc4taT+UwQVwtILNlznhnCFpV4+fgfK4StKHF1+nKoeh2JBbs/sUHY2hLLFr5mhtgr KHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxiZM9NzMxJLzfaxAiMpINbfqvuYLxzTuQQozQH i5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGE0DAytYhfzstvhMun82JD9U3PCC 6iTL3aaXEzNdvpw5m3+kR8RV1dPLrylTd11ySMIM7VS1cC3V7QrCG5Lse24sOXijw9Jh7dxW 3ucp0We/zZp8O+2yR1K7+t9UHqYz/3bOf+LpeOae45NNhu9LPfa8zl5s/iAtdZec9AF7d7Gf P5PN3UuVlViKMxINtZiLihMBPSgdoXICAAA=
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Wed, 23 Oct 2013 10:25:48 -0000

Hi Emil,

First, I completely messed up with the candidate types. Sorry for the confu=
sion :)

Anyway, it doesn't really matter what type of candidates are trickled - it'=
s about whether trickled candidates can be affected by Offers/Answers.

>> So, that would mean that if an Offer is received without the peer=20
>> refexive candidates, the answerer would remove them.
>
> You lost me. How would an answerer remove candidates from an offer if the=
y weren't there in the first place? Did you mean to say something else?

I referred to the example below, where an Offer does not contain a candidat=
e that was previously trickled, and whether the answerer will then assume t=
hat the candidate is no longer valid.

>> The issue that can occur is if you:
>>
>> - first send an Answer (to an Offer), without candidate X;
>>
>> - then you send a trickle request with candidate X;
>>
>> - the trickle request reaches the remote endpoint BEFORE the Answer.
>
> We agreed that the answerer would either wait for a PRACK or an INFO with=
 end-of-candidates before starting trickling, so I don't think this can hap=
pen.

But, in the example above the Offer, and the Answer, may not contain any ne=
w candidates, the Answer simply contains a list of previously negotiated ca=
ndidates. I don't think there will be an INFO with end-of-candidates in tha=
t case, or a PRACK (in case the Offer was received in an UPDATE, or in a PO=
F).

Anyway, once some rules regarding WHEN candidates can be trickled, it may b=
e easier to point on concrete issues (if any).

It would also be easier to explain the issues with a whiteboard :)

> I think I do but I am not sure. Why would you consider lack of a candidat=
e as an indication that a candidate needs to be removed if including that c=
andidate was a MAY in the first place?

Again, IF we say that trickled candidates MAY be present in Offers/Answers,=
 and will not be removed in case they are not present, then there should be=
 no issue.

Regards,

Christer





>  >> Because, we don't signal server reflexive candidates in O/A=20
> either, do we?
>  >>
>  >> If so, then I assume that Offers and Answers would have no impact=20
> on  >> trickle candidates (unless, of course, there is an ICE restart). O=
r?
>  >
>  > Yes, I believe that's the way to go. We might need to state this  >=20
> explicitly in 5245 in order to avoid confusion.
>
>
> Emil
>
>  >
>  > Regards,
>  >
>  > Christer
>  >
>  >=20
> ----------------------------------------------------------------------
> --  > *From:* Emil Ivov [emcho@jitsi.org]  > *Sent:* Tuesday, 22=20
> October 2013 8:52 PM  > *To:* Parthasarathi R  > *Cc:* Christer=20
> Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
>  > *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on  >=20
> draft-ivov-mmusic-trickle-ice-sip-01
>  >
>  > On 22.10.13, 19:01, Parthasarathi R wrote:
>  >> Emil,
>  >>
>  >> In case of ICE Trickle handling in SIP (based on RFC 3261), glare=20
> is  >> unavoidable  >  > I don't think this is true.
>  >
>  >> as per RFC 3264 offer/answer mechanism. The glare handling has  >>=20
> to be done by SIP provided mechanism like 491 handling in=20
> UPDATE/RE-INVITE.
>  >> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE=20
> compliant  >> SIP UA and no need of extra extension.
>  >
>  > Yes, there is a well defined mechanism for handling glare with 3264.
>  > With that I agree. (Adoption and implementation levels are a=20
> different  > story but let's not worry about that right now.)  >  >=20
> The thing is that this mechanism would be hugely inefficient for  >=20
> trickle. The likelihood of glare occurring even more than once there=20
> is  > extremely high when using UPDATEs.
>  >
>  > You are actually quite likely to make the whole process even longer=20
> than  > Vanilla ICE so unless your purpose is to make Trickle=20
> pointless, I don't  > think this is a good idea.
>  >
>  >> INFO based mechanism fails to identify the actual glare situation=20
> in  >> offer/answer.
>  >
>  > I think you might have misunderstood the way trickle ICE works with IN=
FO.
>  >
>  > Once the initial offer/answer is complete (and those rely on the=20
> regular  > glare handling, independently of trickle or ICE) there are=20
> no additional  > offers and answers.
>  >
>  > INFO requests transport asynchronous signalling between ICE agents=20
> (NOT  > offers and answers) and it is perfectly fine for either party=20
> to be  > sending them at any point in time. There's no possibility of gla=
re here.
>  >
>  > Does this help clarify things?
>  >
>  > Emil
>  >
>  >
>  >> Of course,  it is possible to reduce the trickle ICE glare=20
> handling with  >> special SDP handling (enhanced offer/answer) within=20
> RE-INVITE/UPDATE in case  >> both endpoints supports the mechanism.
>  >>
>  >> Please read inline for more comments.
>  >>
>  >> Thanks
>  >> Partha
>  >>
>  >>
>  >>
>  >>> -----Original Message-----
>  >>> From: Emil Ivov [mailto:emcho@jitsi.org]  >>> Sent: Tuesday,=20
> October 22, 2013 6:39 AM  >>> To: Parthasarathi R  >>> Cc: Christer=20
> Holmberg; Enrico Marocco (TiLab); mmusic  >>> Subject: Re: UPDATE=20
> mechanism for Trickle ICE - Comment on draft-ivov-  >>>=20
> mmusic-trickle-ice-sip-01  >>>  >>> On Mon, Oct 21, 2013 at 8:29 PM,=20
> Parthasarathi R  >>>  wrote:
>  >>>> Hi all,
>  >>>>
>  >>>> I have mailed earlier why SIP INFO is not the right choice for =20
> >>> Trickle ICE  >>>> in =20
> >>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>  >>>
>  >>> I remember. Have you noticed my answer?
>  >>>
>  >>>http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>  >>>
>  >>
>  >>  Please note that my question is after your answer=20
> (msg11964 >  >> msg11932).   >>  >>>> The main  >>>> reason=20
> is the glare handling. I have added the callflow in Sec 6.4 of  >>>>=20
> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will =20
> >>> look for  >>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>  >>>
>  >>> I am confused. You say that your main issue is glare handling and=20
> yet  >>> your draft proposes a solution that *introduces* glare=20
> (through  >>> crossing UPDATEs) and then doesn't say anything about=20
> handling it. Is  >>> this intentional? Am I missing something?
>  >>>
>  >>
>  >>  491 is the only known glare handling. We shall work and=20
> further  >> enhance glare handling in UPDATE/RE-INVITE as it is=20
> obvious glare situation.
>  >> I wish to confirm that INFO mechanism does not work for this=20
> situation  >> before deep diving.   >>  >>>> Could you please=20
> explain how  >>>> glare with Trickle ICE Info package will be handled.
>  >>>
>  >>> That's simple. Glare does NOT occur when trickling through INFO.
>  >>
>  >>  The actual glare situation will be missed in INFO=20
>   >>  >>>  >>> Emil  >>>  >>> --  >>>https://jitsi.org=20
>    >>  >>  >  > --  >=20
> https://jitsi.org  
>
> --
> https://jitsi.org 
>

--
https://jitsi.org

From christer.holmberg@ericsson.com  Wed Oct 23 03:36: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 1F80211E836A for ; Wed, 23 Oct 2013 03:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.819
X-Spam-Level: 
X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWA4U6sMvyYl for ; Wed, 23 Oct 2013 03:36:50 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7111E835A for ; Wed, 23 Oct 2013 03:36:47 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-3b-5267a6bebf29
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.69.09019.EB6A7625; Wed, 23 Oct 2013 12:36:46 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 12:36:46 +0200
From: Christer Holmberg 
To: Bo Burman , Jonathan Lennox 
Thread-Topic: DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnw==
Date: Wed, 23 Oct 2013 10:36:46 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@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.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje6+ZelBBvdmmVjsX3ye2WLq8scs DkweS5b8ZPJoe3aHPYApissmJTUnsyy1SN8ugSvjyJcu5oKeJcwVd683sTQwfv7O1MXIySEh YCKxYV4rG4QtJnHh3nowW0jgKKPEqhcCEPYSRomjJ5m7GDk42AQsJLr/aYOYIgI+Egf3pYFU MAvISMw42wg2UVhgJqPEw29AcS6gknmMEl0bFzCCJEQE9CR6XqxhAbFZBFQlOs+vBFvFK+Ar cersUrBmRqATvp9awwQxVFzi1pP5UGcKSCzZc54ZwhaVePn4HyuErShxdfpyqPp8iY/Tr7NA zBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUZxa nJSbbmSwiREYJQe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJx cEo1MJ7c5+Lm3NxTw65Vt7Jx1bLtefPm7Taa1WowcSZnMz/rhQd+T+f/KlNjnp7inch4dOIV w5tR55+5PV3UUtxzqCbb7X+X+95nkxb7NUm+i0pIE9lxnpV9v3ptg9JtZc4ZYUZeDsIsV/9n PJjZHatwdU30/mQG7nsXvq+d216hYb6hbeJ3z+8hb5VYijMSDbWYi4oTAVcS4otgAgAA
X-Mailman-Approved-At: Wed, 23 Oct 2013 03:38:04 -0700
Cc: mmusic 
Subject: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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 Oct 2013 10:36:57 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Below is a copy of the current text in my Vancouver slide regarding the cri=
teria for PT value re-usage in multiple m- lines within a BUNDLE group.

It is based on the ideas provided by Jonathan L and Bo B.

As you can see, apart from the rtpmap and fmtp attributes, it is not possib=
le to define an exclusive list of attributes that must be identical. Such l=
ists may also be codec dependent. Instead, the text talks more generally ab=
out memory and buffer sizes.


>       REQUIREMENTS
-      Decoder agnostic
>       It shall be possible to switch decoders between media flows using t=
he same PT value
-      Codec agnostic
>       The criteria shall be applicable to any codec
>       CRITERIA
-      SDP rtpmap and fmtp attribute values must be equal (order of attribu=
te parameters not significant)
>       All parameters must be included
-      Explictily
-      Implicitly, if a default value is defined for the parameter
>       Parameters not included are assigned their default values (if defin=
ed)
-      Decoder maximum memory and buffer sizes shall be assumed to match

Regards,

Christer




From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Christer Holmberg
Sent: 16. lokakuuta 2013 12:12
To: Bo Burman; Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi Bo,

Thanks for your input!

I'd ask anyone who might have an opinion about this to take a look at the p=
roposal, comment on the list if needed, and hopefully we can agree on way f=
orward in Vancouver (or, even earlier :)

Regards,

Christer

From: Bo Burman
Sent: 16. lokakuuta 2013 11:44
To: Christer Holmberg; Jonathan Lennox
Cc: mmusic
Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

I agree with Jonathan that in order to make two PT values "equal", their rt=
pmap and fmtp lines must be equal, as a start.

I don't think there is any "correct" criterion that can be used to judge PT=
 for equality, but we just have to decide on a "reasonable" one that is as =
simple as possible without causing any major problems.

I have assumed a conceptual equality criterion where PT value A should be c=
onsidered equal to another PT value B if an RTP stream with PT A can be fed=
 into a decoder stack configured with PT B, and vice versa, without causing=
 either decoder stack to "break".

I don't think we should require the fmtp lines are textually equal, but onl=
y that the same parameters are present and have the same values. The order =
of the parameters on the fmtp line does not matter. There is also the case =
when a parameter is specified with the default value for one PT and omitted=
 for the other. To identify those as equal, which they semantically are, wo=
uld require an "equality parser" to know every default value of every fmtp =
parameter for all codecs. This seems unreasonable.

Regarding Jonathan's question on H.264 sprop-..., I guess they don't strict=
ly need to be equal to make the PTs equal, but they may have to be. They ef=
fectively configure the decoder in some way and if there is a mismatch, the=
 decoding process will likely break; like mis-interpretations or buffer ove=
rflows. On the other hand, some sprop-... can be updated by in-band informa=
tion, overriding what is specified on the fmtp line, and in this case the f=
mtp line sprop-... information is obsolete. Requiring that all fmtp of the =
line is equal however makes a simple rule, which should be preferable and I=
 don't think it is too restrictive or excessive.

However, if the potentially equal PT values are defined as part of differen=
t media descriptions, other media level attributes also contribute to the d=
ecoder stack configuration. Some attributes, like maxptime, can clearly cau=
se problems (in this case buffer overflow) if it differs. Others, like ptim=
e, framerate and imageattr are more of a receiver preference within a more =
formal "conformance point" and would not "break" a decoder stack if they di=
ffer.

I agree it can be a good idea to add some text into the mux-attributes draf=
t about attributes that have to be the same to consider two PT in different=
 media descriptions to be "equal", of course given that rtpmap and fmtp are=
 also equal.

/Bo

From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: den 11 september 2013 09:12
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

It would be so easy if we could define the PT mappings on the SDP session l=
evel, and then simply refer to them within the m- lines :)

Regards,

Christer

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 10. syyskuuta 2013 22:18
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

My strawman proposal at the mic in Berlin was that a codec configuration is=
 defined by the top-level media type of the m=3D line and the content of a =
given PT value's rtpmap and fmtp lines.  I.e., the full media type, with al=
l its parameters.

The questions I would have to this straw man are:

* Is this excessive?  E.g., should items like H.264's sprop- parameters be =
allowed to differ across m=3D line blocks?

* Is this sufficient?  Should other items (sometimes) indexed by PT (e.g., =
the imageattr, rtcp-fb, or extmap attributes) need to be the same across m-=
lines as well?

My suggestion would be that this work should be folded into the work being =
done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should be =
integrated with BUNDLE).  Currently (I believe) the mux-attributes draft as=
sumes that PTs are unique across m-lines, so this work is going to imply ch=
anges to the analysis of a number of attributes in that draft, regardless. =
 Probably a new category will need to be defined for attributes which have =
to be consistent per payload type.

On Sep 10, 2013, at 5:56 AM, Christer Holmberg > wrote:


Hi,

Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q=
7 in Berlin.

Questions:

Q1: "Can we agree that, within a BUNDLE group (including all m- lines assoc=
iated with the group), any given PT value can only be used for a single cod=
ec configuration?"
Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there are=
 opinions that simply referencing RFC 3550 might not be clear enough?"
Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in m=
ultiple RTP m- lines, for the SAME codec configuration?"

Outcome:

Q1: Yes
Q2: Yes, Lennox will send suggested text to clarify the term "codec configu=
ration".
Q7: Yes.

So, again, we need definition text for "codec configuration". Jonathan prom=
ised to submit something, but anyone is of course welcome to do that.

The other alternative is to not say anything about PT value usages within t=
he scope of BUNDLE, but that is not what the meeting wanted.

Regards,

Christer


From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 23. elokuuta 2013 13:53
To: mmusic
Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value fo=
r single codec configuration

Hi,

One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7=
 in my slides) was regarding the usage of any given PT value.

My take of the outcome was that:

-          We agreed that any given PT value can only be used for a single =
codec configuration (Q1)
-          We agreed that we need some definition text for "codec configura=
tion" (Q2)
-          We agreed that, within a BUNDLE group, any given PT value can be=
 used in multiple m- lines, as long as it is used for a single codec config=
uration (Q7).

Jonathan Lennox promised to suggest some definition text for "codec configu=
ration", so let's wait for that until we go into those discussions.

But, if you have any issues with the agreements in general, please bring th=
em up :)

Regards,

Christer




--
Jonathan Lennox
jonathan@vidyo.com


--_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

Below is a copy of the cu=
rrent text in my Vancouver slide regarding the criteria for PT value re-usa=
ge in multiple m- lines within a BUNDLE group.


 <=
/p>

It is based on the ideas =
provided by Jonathan L and Bo B.


 <=
/p>

As you can see, apart fro=
m the rtpmap and fmtp attributes, it is not possible to define an exclusive=
 list of attributes that must be identical. Such lists may
 also be codec dependent. Instead, the text talks more generally about memo=
ry and buffer sizes.


 <=
/p>

 <=
/p>


&=
#8250;  &n=
bsp;   
REQUIREMENTS



–=
;   &=
nbsp; 
Decoder agnost=
ic



›=
;   &=
nbsp;  
It shall be possi=
ble to switch decoders between media flows using the same PT value



–=
;   &=
nbsp; 
Codec agnostic




›=
;   &=
nbsp;  
The criteria shal=
l be applicable to any codec



&=
#8250;  &n=
bsp;   
CRITERIA



–=
;   &=
nbsp; 
SDP
rtpmap and fmtp attribute values must be equal (order =
of attribute parameters not significant)



›=
;   &=
nbsp;  
All parameters mu=
st be included



-    &=
nbsp;
Explictily



-    &=
nbsp;
Implicitly, if a =
default value is defined for the parameter




›=
;   &=
nbsp;  
Parameters not in=
cluded are assigned their default values (if defined)



–=
;   &=
nbsp; 
Decoder maximum m=
emory and buffer sizes shall be assumed to match


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: mmusic-b=
ounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: 16. lokakuuta 2013 12:12

To: Bo Burman; Jonathan Lennox

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi Bo,<=
/p>

 <=
/p>

Thanks for your input!


 <=
/p>

I’d ask anyone who =
might have an opinion about this to take a look at the proposal, comment on=
 the list if needed, and hopefully we can agree on way forward
 in Vancouver (or, even earlier :)


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>





From: Bo Burma=
n


Sent: 16. lokakuuta 2013 11:44

To: Christer Holmberg; Jonathan Lennox

Cc: mmusic

Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 <=
/p>

I agree with Jonathan tha=
t in order to make two PT values “equal”, their rtpmap and fmtp=
 lines must be equal, as a start.


 <=
/p>

I don’t think there=
 is any “correct” criterion that can be used to judge PT for eq=
uality, but we just have to decide on a “reasonable” one that i=
s as simple
 as possible without causing any major problems.


 <=
/p>

I have assumed a conceptu=
al equality criterion where PT value A should be considered equal to anothe=
r PT value B if an RTP stream with PT A can be fed into
 a decoder stack configured with PT B, and vice versa, without causing eith=
er decoder stack to “break”.


 <=
/p>

I don’t think we sh=
ould require the fmtp lines are textually equal, but only that the same par=
ameters are present and have the same values. The order of the
 parameters on the fmtp line does not matter. There is also the case when a=
 parameter is specified with the default value for one PT and omitted for t=
he other. To identify those as equal, which they semantically are, would re=
quire an “equality parser” to know
 every default value of every fmtp parameter for all codecs. This seems unr=
easonable.


 <=
/p>

Regarding Jonathan’=
s question on H.264 sprop-…, I guess they don’t strictly need t=
o be equal to make the PTs equal, but they may have to be. They effectively
 configure the decoder in some way and if there is a mismatch, the decoding=
 process will likely break; like mis-interpretations or buffer overflows. O=
n the other hand, some sprop-… can be updated by in-band information,=
 overriding what is specified on the fmtp
 line, and in this case the fmtp line sprop-… information is obsolete=
. Requiring that all fmtp of the line is equal however makes a simple rule,=
 which should be preferable and I don’t think it is too restrictive o=
r excessive.


 <=
/p>

However, if the potential=
ly equal PT values are defined as part of different media descriptions, oth=
er media level attributes also contribute to the decoder
 stack configuration. Some attributes, like maxptime, can clearly cause pro=
blems (in this case buffer overflow) if it differs. Others, like ptime, fra=
merate and imageattr are more of a receiver preference within a more formal=
 “conformance point” and would not
 “break” a decoder stack if they differ.


 <=
/p>

I agree it can be a good =
idea to add some text into the mux-attributes draft about attributes that h=
ave to be the same to consider two PT in different media
 descriptions to be “equal”, of course given that rtpmap and fm=
tp are also equal.


 <=
/p>

/Bo


 <=
/p>







From:
mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: den 11 september 2013 09:12

To: Jonathan Lennox

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 <=
/p>

It would be so easy if we=
 could define the PT mappings on the SDP session level, and then simply ref=
er to them within the m- lines :)


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>



 




My strawman proposal at the mic in Berlin was that a=
 codec configuration is defined by the top-level media type of the m=3D lin=
e and the content of a given PT value's rtpmap and fmtp lines.  I.e., =
the full media type, with all its parameters.






 






The questions I would have to this straw man are:






 






* Is this excessive?  E.g., should items like H=
.264's sprop- parameters be allowed to differ across m=3D line blocks?=







 






* Is this sufficient?  Should other items (some=
times) indexed by PT (e.g., the imageattr, rtcp-fb, or extmap attributes) n=
eed to be the same across m-lines as well?






 






My suggestion would be that this work should be fold=
ed into the work being done in draft-nandakumar-mmusic-sdp-mux-attribu=
tes (which really should be integrated with BUNDLE).  Currently (I bel=
ieve) the mux-attributes draft assumes that
 PTs are unique across m-lines, so this work is going to imply changes to t=
he analysis of a number of attributes in that draft, regardless.  Prob=
ably a new category will need to be defined for attributes which have to be=
 consistent per payload type.




 





 






 






Hi,






 






Below is the “offic=
ial” (from the minutes) outcome of questions Q1,Q2 and Q7 in Berlin.<=
/span>






 






Questions:<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif"">






 






Q1: “Can we agree t=
hat, within a BUNDLE group (including all m- lines associated with the grou=
p), any given PT value can only be used for a single codec configuration?&#=
8221;






Q2: “If Q1, do we a=
gree that we need EXPLICIT text somewhere*, as there are opinions that simp=
ly referencing RFC 3550 might not be clear enough?”






Q7: “Within a BUNDL=
E group, do we allow the usage of the same PT value in multiple RTP m- line=
s, for the SAME codec configuration?”<=
/span>






 






Outcome:






 






Q1: Yes






Q2: Yes, Lennox will send=
 suggested text to clarify the term “codec configuration”.






Q7: Yes.






 






So, again, we need defini=
tion text for “codec configuration”. Jonathan promised to submi=
t something, but anyone is of course welcome to do that.






 






The other alternative is =
to not say anything about PT value usages within the scope of BUNDLE, but t=
hat is not what the meeting wanted.





 






Regards,






 






Christer






 






 










From: mmusic-bounces@ie=
tf.org [mailto=
:mmusic-bo=
unces@ietf.org] On
 Behalf Of Christer H=
olmberg

Sent: 23. elokuuta=
 2013 13:53

To: mmusic

Subject: [MMUSIC] =
DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec con=
figuration










 






Hi,






 






One of the open issues related to BUNDL=
E presented in Berlin (Q1, Q2 and Q7 in my slides) was regarding the usage =
of any given PT value.






 






My take of the outcome was that:






 






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that
 any given PT value can only be used for a single codec configuration (Q1)<=
o:p>






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that
 we need some definition text for “codec configuration” (Q2)






-<=
span style=3D"font-size:7.0pt">       &n=
bsp;  We agreed that,
 within a BUNDLE group, any given PT value can be used in multiple m- lines=
, as long as it is used for a single codec configuration (Q7).






 






Jonathan Lennox promised to suggest som=
e definition text for “codec configuration”, so let’s wai=
t for that until we go into those discussions.






 






But, if you have any issues with the ag=
reements in general, please bring them up :)






 






Regards,






 






Christer






 <=
o:p>






 <=
o:p>






 <=
o:p>








 






--






Jonathan Lennox

jonathan@vidyo.com






 








--_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_--

From emil@sip-communicator.org  Wed Oct 23 06:08: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 0209111E8190 for ; Wed, 23 Oct 2013 06:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68nanSjvSE86 for ; Wed, 23 Oct 2013 06:08:31 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id AB15F11E835D for ; Wed, 23 Oct 2013 06:08:22 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hn9so836799wib.11 for ; Wed, 23 Oct 2013 06:08:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MknhpDsKTJb81r7itLzF5hsKpz883ltTGKPqWq8sD5k=; b=bmPKMm2cIiA9O3pIFAnzVjUrT7opvEvOu6K56nHJACPDWq+tPhWsNEjIU7eaWiqKrA Yyo4ZVNZDBaGwKGuaUshFuEhxoLcZfbIC5Ti3CpRfyCy0+xucgt4SZZ9bVPmPqI8fqoH aZcRxI5S2ifhx8Sme2PoGnutCkOgyJgSvrR8rrv9Ve4fNfIVs0ulSdJ+Pcm9IinmepKz hlvhofNab2P3wTGFsJVHDYi2oX3Sdr+VuRuIR7nP3kDyOixdHpSSv35vt7/pyMI8DJLh oXbgvSiTLLSkRUOWu308uv9oTztt3GpsvJHdj7MjVOExs7Y4jIpvZXGLiM6V+aeaCbcN hlhA==
X-Gm-Message-State: ALoCoQlhZwz3XLUHY2AShr7OPf7+WhVY7I+TSR/+2zgSXBwUzrMOg53N8xAVyb2KhS8qH05p5c3Y
X-Received: by 10.180.187.2 with SMTP id fo2mr2011392wic.65.1382533702075; Wed, 23 Oct 2013 06:08:22 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPSA id y20sm16843827wib.0.2013.10.23.06.08.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:08:21 -0700 (PDT)
Message-ID: <5267CA43.8020304@jitsi.org>
Date: Wed, 23 Oct 2013 15:08:19 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Christer Holmberg 
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Wed, 23 Oct 2013 13:08:36 -0000

Hey Christer,

On 23.10.13, 12:25, Christer Holmberg wrote:
> Hi Emil,
>
> First, I completely messed up with the candidate types. Sorry for the
> confusion :)
>
> Anyway, it doesn't really matter what type of candidates are trickled
> - it's about whether trickled candidates can be affected by
> Offers/Answers.

And by affected you really mean invalidated. OK, I think I understand now.

I don't think there's anything in 5245 that defines semantics which 
would invalidate existing candidates.

I do agree that we could further clarify this in 5245bis and/or Trickle 
for SIP.

>>> So, that would mean that if an Offer is received without the
>>> peer refexive candidates, the answerer would remove them.
>>
>> You lost me. How would an answerer remove candidates from an offer
>> if they weren't there in the first place? Did you mean to say
>> something else?
>
> I referred to the example below, where an Offer does not contain a
> candidate that was previously trickled, and whether the answerer will
> then assume that the candidate is no longer valid.

Right. I don't think there's such a risk. 5245 explicitly forbids update 
Offers and Answers to remove candidates that have been announced 
previously and it allows (as in MAY, not SHOULD) that new candidates be 
added.

The former should address your concern and I believe we could simply 
remove the latter as it is of little use, if any.

>>> The issue that can occur is if you:
>>>
>>> - first send an Answer (to an Offer), without candidate X;
>>>
>>> - then you send a trickle request with candidate X;
>>>
>>> - the trickle request reaches the remote endpoint BEFORE the
>>> Answer.
>>
>> We agreed that the answerer would either wait for a PRACK or an
>> INFO with end-of-candidates before starting trickling, so I don't
>> think this can happen.
>
> But, in the example above the Offer, and the Answer, may not contain
> any new candidates, the Answer simply contains a list of previously
> negotiated candidates. I don't think there will be an INFO with
> end-of-candidates in that case, or a PRACK (in case the Offer was
> received in an UPDATE, or in a POF).

Yes, maybe not. This would be a non-restarting update Offer and we could 
specify that such offers (and their answers) don't get to change ICE. 
Only ICE restarts do.

> Anyway, once some rules regarding WHEN candidates can be trickled, it
> may be easier to point on concrete issues (if any).

OK.

> It would also be easier to explain the issues with a whiteboard :)
>
>> I think I do but I am not sure. Why would you consider lack of a
>> candidate as an indication that a candidate needs to be removed if
>> including that candidate was a MAY in the first place?
>
> Again, IF we say that trickled candidates MAY be present in
> Offers/Answers, and will not be removed in case they are not present,
> then there should be no issue.

OK, agreed.

Emil

>
> Regards,
>
> Christer
>
>
>
>
>
>>>> Because, we don't signal server reflexive candidates in O/A
>> either, do we?
>>>>
>>>> If so, then I assume that Offers and Answers would have no
>>>> impact
>> on  >> trickle candidates (unless, of course, there is an ICE
>> restart). Or?
>>>
>>> Yes, I believe that's the way to go. We might need to state this
>>> >
>> explicitly in 5245 in order to avoid confusion.
>>
>>
>> Emil
>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>> ----------------------------------------------------------------------
>>
>>
--  > *From:* Emil Ivov [emcho@jitsi.org]  > *Sent:* Tuesday, 22
>> October 2013 8:52 PM  > *To:* Parthasarathi R  > *Cc:* Christer
>> Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
>>> *Subject:* Re: UPDATE mechanism for Trickle ICE - Comment on  >
>> draft-ivov-mmusic-trickle-ice-sip-01
>>>
>>> On 22.10.13, 19:01, Parthasarathi R wrote:
>>>> Emil,
>>>>
>>>> In case of ICE Trickle handling in SIP (based on RFC 3261),
>>>> glare
>> is  >> unavoidable  >  > I don't think this is true.
>>>
>>>> as per RFC 3264 offer/answer mechanism. The glare handling has
>>>> >>
>> to be done by SIP provided mechanism like 491 handling in
>> UPDATE/RE-INVITE.
>>>> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE &
>>>> ICE
>> compliant  >> SIP UA and no need of extra extension.
>>>
>>> Yes, there is a well defined mechanism for handling glare with
>>> 3264. With that I agree. (Adoption and implementation levels are
>>> a
>> different  > story but let's not worry about that right now.)  >
>> > The thing is that this mechanism would be hugely inefficient for
>> > trickle. The likelihood of glare occurring even more than once
>> there is  > extremely high when using UPDATEs.
>>>
>>> You are actually quite likely to make the whole process even
>>> longer
>> than  > Vanilla ICE so unless your purpose is to make Trickle
>> pointless, I don't  > think this is a good idea.
>>>
>>>> INFO based mechanism fails to identify the actual glare
>>>> situation
>> in  >> offer/answer.
>>>
>>> I think you might have misunderstood the way trickle ICE works
>>> with INFO.
>>>
>>> Once the initial offer/answer is complete (and those rely on the
>> regular  > glare handling, independently of trickle or ICE) there
>> are no additional  > offers and answers.
>>>
>>> INFO requests transport asynchronous signalling between ICE
>>> agents
>> (NOT  > offers and answers) and it is perfectly fine for either
>> party to be  > sending them at any point in time. There's no
>> possibility of glare here.
>>>
>>> Does this help clarify things?
>>>
>>> Emil
>>>
>>>
>>>> Of course,  it is possible to reduce the trickle ICE glare
>> handling with  >> special SDP handling (enhanced offer/answer)
>> within RE-INVITE/UPDATE in case  >> both endpoints supports the
>> mechanism.
>>>>
>>>> Please read inline for more comments.
>>>>
>>>> Thanks Partha
>>>>
>>>>
>>>>
>>>>> -----Original Message----- From: Emil Ivov
>>>>> [mailto:emcho@jitsi.org]  >>> Sent: Tuesday,
>> October 22, 2013 6:39 AM  >>> To: Parthasarathi R  >>> Cc:
>> Christer Holmberg; Enrico Marocco (TiLab); mmusic  >>> Subject: Re:
>> UPDATE mechanism for Trickle ICE - Comment on draft-ivov-  >>>
>> mmusic-trickle-ice-sip-01  >>>  >>> On Mon, Oct 21, 2013 at 8:29
>> PM, Parthasarathi R  >>>  wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I have mailed earlier why SIP INFO is not the right choice
>>>>>> for
>>>>> Trickle ICE  >>>> in
>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>
>>>>>>
>>>
>>>>> I remember. Have you noticed my answer?
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>
>>>>>
>>>
>>>>
>>>>  Please note that my question is after your answer
>> (msg11964 >  >> msg11932).   >>  >>>> The main  >>>>
>> reason is the glare handling. I have added the callflow in Sec 6.4
>> of  >>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE
>> handling will
>>>>> look for  >>>> Trickle ICE handling in SIP w.r.t JSEP
>>>>> mapping.
>>>>>
>>>>> I am confused. You say that your main issue is glare handling
>>>>> and
>> yet  >>> your draft proposes a solution that *introduces* glare
>> (through  >>> crossing UPDATEs) and then doesn't say anything
>> about handling it. Is  >>> this intentional? Am I missing
>> something?
>>>>>
>>>>
>>>>  491 is the only known glare handling. We shall work
>>>> and
>> further  >> enhance glare handling in UPDATE/RE-INVITE as it is
>> obvious glare situation.
>>>> I wish to confirm that INFO mechanism does not work for this
>> situation  >> before deep diving.   >>  >>>> Could you
>> please explain how  >>>> glare with Trickle ICE Info package will
>> be handled.
>>>>>
>>>>> That's simple. Glare does NOT occur when trickling through
>>>>> INFO.
>>>>
>>>>  The actual glare situation will be missed in INFO
>>   >>  >>>  >>> Emil  >>>  >>> --  >>>https://jitsi.org
>>    >>  >>  >  > --  >
>> https://jitsi.org  
>>
>> -- https://jitsi.org 
>>
>
> -- https://jitsi.org
>

-- 
https://jitsi.org

From ari.keranen@ericsson.com  Wed Oct 23 06:31: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 961D511E83C5 for ; Wed, 23 Oct 2013 06:31:11 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8L0PTR4FD8g for ; Wed, 23 Oct 2013 06:31:06 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E8DCA11E8196 for ; Wed, 23 Oct 2013 06:31:05 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-f7-5267cf98ad75
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.96.03802.89FC7625; Wed, 23 Oct 2013 15:31:05 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.37]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 15:31:04 +0200
From: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
To: Emil Ivov 
Thread-Topic: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Thread-Index: Ac7MD6NfvGuI93GmRnipYmfd4J6njP//4E2AgAAueYCAAT86AIAAFkwAgAM3nwCAAEZjgIAAQsKAgAAHGICAAIzVAIAAergAgAFzuoA=
Date: Wed, 23 Oct 2013 13:31:03 +0000
Message-ID: <861759C7815040489720E3CC184F51DD1C481E05@ESESSMB205.ericsson.se>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>  <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se> <526697C4.6030207@jitsi.org>
In-Reply-To: <526697C4.6030207@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <04860AEB79BB6D46BB3E5DFC9E7D73C1@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje7M8+lBBvuOM1vs+buI3WLNzgks FlOXP2axeH99JYsDi8eU3xtZPZYs+cnk8f9NoMesnU9YAliiuGxSUnMyy1KL9O0SuDK2bVvC XvBbp+JTz37WBsY2lS5GTg4JAROJd5snM0PYYhIX7q1n62Lk4hASOMwo8WftA1YIZzGjxPfX 69hAqtgE7CUmr/nICGKLCMhLdLctYgKxmQXyJD4+eAxWIyzgIPH8zTp2iBpHiftL1rNC2GUS TWsh4iwCqhJPT0Js5hXwlfj3fzs7xLITLBKHu1eCNXAKaEr0fL0GtoAR6Lzvp9ZALROXuPVk PhPE2QISS/ach3pBVOLl43+sELaSxIrtlxgh6vUkbkydAnQcB5BtLTH9hzNEWFti2cLXUDcI Spyc+YRlAqP4LCQbZiHpnoXQPQtJ9ywk3QsYWVcxsucmZuaklxttYgRG3sEtv1V3MN45J3KI UZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjC6Ch9ZO71KrPHu+YfJ9uedz 74mcPTHbKiazh0Peq0bzmRhnfc/zNw9CJ8x+8DH90Wfdvql75h1O+ynf9Gt++Qr2kvBJry9a NjoUvLx0oyZe59y1gxdfLX5cX/WQU/HeFoOrc9J8zFoVT13pnHy4TWf6auuVS0LOzngSmfHu 08sUx4XvOK+oXTdSYinOSDTUYi4qTgQAfn67+4oCAAA=
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 13:31:11 -0000

Hi Emil,

On Oct 22, 2013, at 6:20 PM, Emil Ivov wrote:
> On 22.10.13, 10:01, Ari Ker=E4nen wrote:
>> On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
>>> On Tue, Oct 22, 2013 at 1:11 AM, Ari Ker=E4nen
>>>  wrote:
>>>>=20
>>>> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>>>>=20
>>>>> I still don't get it. Why would we recommend values for
>>>>> different applications? We already tell applications to pace
>>>>> checks in accordance with expected traffic, which they
>>>>> supposedly can gauge better than the text in our RFC.
>>>>>=20
>>>>> A minimum value does make sense because it would basically say:
>>>>> "don't go below this value or you might brake the network or
>>>>> otherwise cause harm". That's actually useful advice.
>>>>=20
>>>> Exactly. We're not proposing (different) values for different
>>>> application. The proposal is to pace checks according to the
>>>> expected traffic. For RTP there is a formula, for other traffic
>>>> you're on your own (come up with formula, or what ever). The
>>>> "second" value is only for the cases where you don't know better
>>>> and should use something conservative.
>>>=20
>>> If you don't know better why wouldn't you just use RTP's 20 ms
>>> pacing given that we've already blessed it as safe and harmless and
>>> NAT friendly?
>>>=20
>>=20
>> 20 ms pacing has been blessed NAT friendly but not necessarily safe
>> and harmless for the rest of the network.
>=20
> Apparently we are happy to take the chance (5245):
>=20
>   Experiments have shown
>   that once every 20 ms is well supported, but not much lower than
>   that.  This is why Ta has a lower bound of 20 ms.

Yes, with NAT binding creation.

>> Also, if you start sending
>> connectivity checks faster than your uplink can handle, you'll end up
>> with false negatives due to dropped connectivity check packets.
>=20
> Sure, but a second bound of 50ms does not address this. Not more than 20m=
s or 500ms. You can always be on a link that will be saturated.
>=20

Of course if the link is already fully saturated there's not much you can d=
o (except detect that using it is a bad idea). But the chances of that happ=
ening on a non-saturated link are naturally getting lower and lower the lon=
ger pacing you have. With 500 ms pacing there aren't many real-world links =
(unless they're saturated) that could not handle it. Then the question is i=
f 50 ms is "conservative enough"?

>> Hence
>> I do see value in being a bit conservative if you don't know better.
>=20
>> But would you like to see only a single value, 20 ms, which should be
>> used always for pacing and no other recommended values whatsoever?
>=20
> Yes. If we could say, "go at a pace that emulates that of the ensuing str=
eams, but never go below 20ms", I'd be happy.

I agree, that's what we should say ("come up with formula or whatever for y=
our non-RTP traffic to emulate the ensuing streams"). It's just for the cas=
es where you don't have any good information on the ensuing streams when yo=
u'd need this second, more conservative, value to fall back to.

> I'd also be happy if experimentation shows that the 20ms value needs to b=
e changed to something else.

Me too. Let's see what Justin's experiments tell us about this.


Cheers,
Ari

>>=20
>>>>=20
>>>>> Now, having two such values starts being weird again, unless we
>>>>> have data that shoes that networks break differently depending
>>>>> on the UDP payload or port number or whatever.
>>>>>=20
>>>>> --sent from my mobile
>>>>>=20
>>>>> On 21 Oct 2013 14:01, "Ari Ker=E4nen" 
>>>>> wrote: On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote: On
>>>>> Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>>>>> On 18.10.13, 19:30, Adam Roach wrote: On 10/18/13 09:44, Emil
>>>>> Ivov wrote: It might be worth reminding exactly what these 50ms
>>>>> would be protecting us against
>>>>>=20
>>>>> They're protecting us against RTP arriving at a rate of 20ms
>>>>> per packet.
>>>>>=20
>>>>> That would indeed be one of the reasons to pace checks (in
>>>>> addition to fragile NAT boxes IIRC), however in either case, I
>>>>> fail to realise why we need a different pacing strategy for
>>>>> non-RTP. This is what I was asking about.
>>>>>=20
>>>>> Connectivity check hammers can still resort to RTP if the
>>>>> pacing timer is their only problem and I don't see why shaky
>>>>> NATs would tolerate a 20ms rate for RTP but only a 50ms for
>>>>> anything else.
>>>>>=20
>>>>> This entire separation sounds quite arbitrary right now. I see
>>>>> why we would pick a value that we consider somewhat safe and
>>>>> secure but I don't understand why we would need two!?
>>>>>=20
>>>>> I agree. No need to add more complexity. ICE should be ignorant
>>>>> of what traffic goes through the pinholes.
>>>>>=20
>>>>> The idea would be to have one recommended value (or set of) for
>>>>> all kinds of traffic but with RTP you would have this
>>>>> "additional piece of information" (due to the knowledge of your
>>>>> traffic pattern and the formula to relate that to pacing) that
>>>>> would allow you to go below the conservative recommended value.
>>>>> If you would have something similar with non-RTP traffic, you
>>>>> could use that.
>>>>>=20
>>>>> But then for both endpoints agreeing on the value in order to
>>>>> have connectivity checks happening simultaneously for the same
>>>>> pairs, we'd probably need to do some negotiation, similar to
>>>>> what was done with ICE on HIP
>>>>> (http://tools.ietf.org/html/rfc5770#section-4.4).
>>>>>=20
>>>>>=20
>>>>> Cheers, Ari
>>>>=20
>>>=20
>>=20


From fandreas@cisco.com  Wed Oct 23 06:34: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 28EA611E8371 for ; Wed, 23 Oct 2013 06:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsFERzwdPjFQ for ; Wed, 23 Oct 2013 06:34:12 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29911E837B for ; Wed, 23 Oct 2013 06:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5831; q=dns/txt; s=iport; t=1382535239; x=1383744839; h=message-id:date:from:mime-version:to:subject; bh=9rs5H7MYdt0HJXKdl32Gd3R5aNxD9Q3qeij6WweiHEg=; b=CUVt31BmC4Uqa1w5SxjYLxNs1l3fvOCIoTq1Eaa9AX7o6dBA/RBdr9bE plv81/I/kmpC2hB2eNFSwS+227vZ7r1/S5DhBOaFYDdAHgWqCxIvvnQPw VcQx2HXI91B/BygL+m+oGkU0yGeajmyDt5S/jsCGvoBN0nRmKwl69ADVJ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGHPZ1KrRDoG/2dsb2JhbABZgwc4iVu2bhZ0gxJPNAJMDQYCAQGIAQ6ZO6FeBJN/A5gJkgeDQCA
X-IronPort-AV: E=Sophos;i="4.93,554,1378857600"; d="scan'208,217";a="92837421"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 23 Oct 2013 13:33:58 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.252.179]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9NDXtr8011483 for ; Wed, 23 Oct 2013 13:33:56 GMT
Message-ID: <5267D043.40907@cisco.com>
Date: Wed, 23 Oct 2013 09:33:55 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: multipart/alternative; boundary="------------070403000903010505060901"
Subject: [MMUSIC] MMUSIC Draft Agenda for IETF 88
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 Oct 2013 13:34:23 -0000

This is a multi-part message in MIME format.
--------------070403000903010505060901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greetings

We have uploaded the MMUSIC draft agenda for IETF 88 at

     https://datatracker.ietf.org/meeting/88/agenda/mmusic/

and shown below as well.

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

Thanks

-- Ari & Flemming (MMUSIC chairs)


            IETF-88, Vancouver, BC, Canada

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

   Multiparty Multimedia Session Control (MMUSIC) WG

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

** AGENDA **

  
Chairs: Flemming Andreasen (fandreas@cisco.com)
         Ari Keranen (ari.keranen@ericsson.com)

  

MONDAY, November 4, 2013 (Regency B), 09:00-11:30  (150 mins)
=============================================================
  
9:00-9:15 Introduction and Status Update (Chairs)


9:15-9:35, draft-even-mmusic-application-token-01 (20 mins)

    The Session Description Protocol (SDP) Application Token Attribute
  

9:35-9:55, draft-nandakumar-mmusic-sdp-mux-attributes-02 (20 mins)

    A Framework for SDP Attributes when Multiplexing


9:55-10:25, draft-ietf-mmusic-rfc5245bis-00 (30 mins)

    Interactive Connectivity Establishment (ICE)


10:25-10:45, draft-thomson-mmusic-ice-webrtc-00 (20 mins)

    Using Interactive Connectivity Establishment (ICE) in Web Real-Time
    Communications (WebRTC)


10:45-11:00, draft-reddy-mmusic-ice-happy-eyeballs-03 (15 mins)

    Happy Eyeballs Extension for ICE


11:00-11:15, draft-martinsen-mmusic-malice-00 (15 mins)

    Meta-data Attribute signaLling with ICE


11:15-11:30, draft-reddy-mmusic-ice-best-interface-pcp-00 (15 mins)

    Improving ICE Interface Selection Using Port Control Protocol (PCP)
    Flow Extension



WEDNESDAY, November 6, 2013 (Regency A), 13:00-15:30 (150 mins)
===============================================================

13:00-14:30, draft-ietf-mmusic-sdp-bundle-negotiation-05 (90 mins)

    Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers


14:30-15:00, draft-roach-mmusic-pof-pan-00 (30 mins)

    Using Partial Offers and Partial Answers in a Multimedia Session

  
15:00-15:30, draft-westerlund-avtcore-rtp-simulcast-03 (30 mins)

    Using Simulcast in RTP Sessions



--------------070403000903010505060901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Greetings

    

    We have uploaded the MMUSIC draft agenda for IETF 88 at

    

        https://datatracker.ietf.org/meeting/88/agenda/mmusic/

    

    and shown below as well. 

    

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

    

    Thanks

    

    -- Ari & Flemming (MMUSIC chairs)

    

    

    
    
           IETF-88, Vancouver, BC, Canada

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

  Multiparty Multimedia Session Control (MMUSIC) WG

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

** AGENDA **

 
Chairs: Flemming Andreasen (fandreas@cisco.com)
        Ari Keranen (ari.keranen@ericsson.com)

 

MONDAY, November 4, 2013 (Regency B), 09:00-11:30  (150 mins)
=============================================================
 
9:00-9:15 Introduction and Status Update (Chairs)


9:15-9:35, draft-even-mmusic-application-token-01 (20 mins)

   The Session Description Protocol (SDP) Application Token Attribute
 

9:35-9:55, draft-nandakumar-mmusic-sdp-mux-attributes-02 (20 mins)

   A Framework for SDP Attributes when Multiplexing


9:55-10:25, draft-ietf-mmusic-rfc5245bis-00 (30 mins)

   Interactive Connectivity Establishment (ICE)


10:25-10:45, draft-thomson-mmusic-ice-webrtc-00 (20 mins)

   Using Interactive Connectivity Establishment (ICE) in Web Real-Time
   Communications (WebRTC)


10:45-11:00, draft-reddy-mmusic-ice-happy-eyeballs-03 (15 mins)

   Happy Eyeballs Extension for ICE


11:00-11:15, draft-martinsen-mmusic-malice-00 (15 mins)

   Meta-data Attribute signaLling with ICE


11:15-11:30, draft-reddy-mmusic-ice-best-interface-pcp-00 (15 mins)

   Improving ICE Interface Selection Using Port Control Protocol (PCP)
   Flow Extension



WEDNESDAY, November 6, 2013 (Regency A), 13:00-15:30 (150 mins)
===============================================================

13:00-14:30, draft-ietf-mmusic-sdp-bundle-negotiation-05 (90 mins)

   Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers


14:30-15:00, draft-roach-mmusic-pof-pan-00 (30 mins)

   Using Partial Offers and Partial Answers in a Multimedia Session

 
15:00-15:30, draft-westerlund-avtcore-rtp-simulcast-03 (30 mins) 

   Using Simulcast in RTP Sessions

    

  


--------------070403000903010505060901--

From emcho@sip-communicator.org  Wed Oct 23 06:45: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 C3C3811E81B0 for ; Wed, 23 Oct 2013 06:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhvNiMJVFrb6 for ; Wed, 23 Oct 2013 06:45:26 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE9C21F9EBE for ; Wed, 23 Oct 2013 06:45:17 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id bj1so1207638pad.35 for ; Wed, 23 Oct 2013 06:45:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=oQKK4TsPJHQv+kHe4pmVYAcnGLYUDASGMkrX0qKkNI0=; b=VcwiKYTz3wAjjTeWHIhBefUKg787BHzT//OCp8PSlLOEd7RG9W2ggXo9uyw/Jk62P9 BTwt2HYBKxvYeUTwN8/VX/qLYxknHx0ZyTnQoZJQToowy+aQyrm9XzUAQ1AK8gfs+UkP HOKglUuS/0hNapwMCr1Rrig0etguA9u8ehbaB7GFjjaELp6KjOmJvR9R3/1ngaMb3p2L VEvJ+gK3bi//95zvNe5JQf0UkxzVDyxJsJQHZ+e9eZLCb0WSzGpaYSn9MQjqOrHI98jU EBe6O0nJSa6A+UD7hSOkOuH61bzmS6A5PQRnhfhG5qSjqcPIiEv8V5sFJPsAuwa9PbDt FFSg==
X-Gm-Message-State: ALoCoQl9+lJY43gaZ/DTBw1g2YwcRpIAh6S4xoP7anK9KThSlnBcwI7lsvaQwS26LHjJO1B8+ptJ
X-Received: by 10.69.2.129 with SMTP id bo1mr1776045pbd.144.1382535917218; Wed, 23 Oct 2013 06:45:17 -0700 (PDT)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [2607:f8b0:400e:c01::232]) by mx.google.com with ESMTPSA id uw6sm4708268pbc.8.2013.10.23.06.45.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:45:16 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id uo15so953064pbc.23 for ; Wed, 23 Oct 2013 06:45:16 -0700 (PDT)
X-Received: by 10.68.179.1 with SMTP id dc1mr1502370pbc.78.1382535916597; Wed, 23 Oct 2013 06:45:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Wed, 23 Oct 2013 06:44:56 -0700 (PDT)
In-Reply-To: <861759C7815040489720E3CC184F51DD1C481E05@ESESSMB205.ericsson.se>
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>  <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se> <526697C4.6030207@jitsi.org> <861759C7815040489720E3CC184F51DD1C481E05@ESESSMB205.ericsson.se>
From: Emil Ivov 
Date: Wed, 23 Oct 2013 15:44:56 +0200
Message-ID: 
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 13:45:31 -0000

On Wed, Oct 23, 2013 at 3:31 PM, Ari Ker=E4nen  w=
rote:
> Hi Emil,
>
> On Oct 22, 2013, at 6:20 PM, Emil Ivov wrote:
>> On 22.10.13, 10:01, Ari Ker=E4nen wrote:
>>> On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
>>>> On Tue, Oct 22, 2013 at 1:11 AM, Ari Ker=E4nen
>>>>  wrote:
>>>>>
>>>>> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>>>>>
>>>>>> I still don't get it. Why would we recommend values for
>>>>>> different applications? We already tell applications to pace
>>>>>> checks in accordance with expected traffic, which they
>>>>>> supposedly can gauge better than the text in our RFC.
>>>>>>
>>>>>> A minimum value does make sense because it would basically say:
>>>>>> "don't go below this value or you might brake the network or
>>>>>> otherwise cause harm". That's actually useful advice.
>>>>>
>>>>> Exactly. We're not proposing (different) values for different
>>>>> application. The proposal is to pace checks according to the
>>>>> expected traffic. For RTP there is a formula, for other traffic
>>>>> you're on your own (come up with formula, or what ever). The
>>>>> "second" value is only for the cases where you don't know better
>>>>> and should use something conservative.
>>>>
>>>> If you don't know better why wouldn't you just use RTP's 20 ms
>>>> pacing given that we've already blessed it as safe and harmless and
>>>> NAT friendly?
>>>>
>>>
>>> 20 ms pacing has been blessed NAT friendly but not necessarily safe
>>> and harmless for the rest of the network.
>>
>> Apparently we are happy to take the chance (5245):
>>
>>   Experiments have shown
>>   that once every 20 ms is well supported, but not much lower than
>>   that.  This is why Ta has a lower bound of 20 ms.
>
> Yes, with NAT binding creation.
>
>>> Also, if you start sending
>>> connectivity checks faster than your uplink can handle, you'll end up
>>> with false negatives due to dropped connectivity check packets.
>>
>> Sure, but a second bound of 50ms does not address this. Not more than 20=
ms or 500ms. You can always be on a link that will be saturated.
>>
>
> Of course if the link is already fully saturated there's not much you can=
 do (except detect that using it is a bad idea). But the chances of that ha=
ppening on a non-saturated link are naturally getting lower and lower the l=
onger pacing you have. With 500 ms pacing there aren't many real-world link=
s (unless they're saturated) that could not handle it. Then the question is=
 if 50 ms is "conservative enough"?
>
>>> Hence
>>> I do see value in being a bit conservative if you don't know better.
>>
>>> But would you like to see only a single value, 20 ms, which should be
>>> used always for pacing and no other recommended values whatsoever?
>>
>> Yes. If we could say, "go at a pace that emulates that of the ensuing st=
reams, but never go below 20ms", I'd be happy.
>
> I agree, that's what we should say ("come up with formula or whatever for=
 your non-RTP traffic to emulate the ensuing streams"). It's just for the c=
ases where you don't have any good information on the ensuing streams when =
you'd need this second, more conservative, value to fall back to.

Come on :). This sounds like trying to recommend a reasonable number
of prayers per day. Either you know what your traffic is and you
emulate it, or you don't and in that case you just have to stay above
20 ms (or our potential new boundary).

Note that "knowing what your traffic is" is not limited to knowing its
exact bandwidth. You could also just know that it is real-time or not,
involving user interaction or not.  In all of these cases you are free
to choose 50, 100, 500ms depending on your needs. We can certainly
explain that rationale. This will be helpful. We could maybe even
place an upper bound above which ICE becomes dysfunctional (just a
thought, not saying it's necessary)  but just slapping an arbitrary
number is not helping anyone.

Emil

>
>> I'd also be happy if experimentation shows that the 20ms value needs to =
be changed to something else.
>
> Me too. Let's see what Justin's experiments tell us about this.
>
>
> Cheers,
> Ari
>
>>>
>>>>>
>>>>>> Now, having two such values starts being weird again, unless we
>>>>>> have data that shoes that networks break differently depending
>>>>>> on the UDP payload or port number or whatever.
>>>>>>
>>>>>> --sent from my mobile
>>>>>>
>>>>>> On 21 Oct 2013 14:01, "Ari Ker=E4nen" 
>>>>>> wrote: On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote: On
>>>>>> Oct 19, 2013, at 05:33 AM, Emil Ivov  wrote:
>>>>>> On 18.10.13, 19:30, Adam Roach wrote: On 10/18/13 09:44, Emil
>>>>>> Ivov wrote: It might be worth reminding exactly what these 50ms
>>>>>> would be protecting us against
>>>>>>
>>>>>> They're protecting us against RTP arriving at a rate of 20ms
>>>>>> per packet.
>>>>>>
>>>>>> That would indeed be one of the reasons to pace checks (in
>>>>>> addition to fragile NAT boxes IIRC), however in either case, I
>>>>>> fail to realise why we need a different pacing strategy for
>>>>>> non-RTP. This is what I was asking about.
>>>>>>
>>>>>> Connectivity check hammers can still resort to RTP if the
>>>>>> pacing timer is their only problem and I don't see why shaky
>>>>>> NATs would tolerate a 20ms rate for RTP but only a 50ms for
>>>>>> anything else.
>>>>>>
>>>>>> This entire separation sounds quite arbitrary right now. I see
>>>>>> why we would pick a value that we consider somewhat safe and
>>>>>> secure but I don't understand why we would need two!?
>>>>>>
>>>>>> I agree. No need to add more complexity. ICE should be ignorant
>>>>>> of what traffic goes through the pinholes.
>>>>>>
>>>>>> The idea would be to have one recommended value (or set of) for
>>>>>> all kinds of traffic but with RTP you would have this
>>>>>> "additional piece of information" (due to the knowledge of your
>>>>>> traffic pattern and the formula to relate that to pacing) that
>>>>>> would allow you to go below the conservative recommended value.
>>>>>> If you would have something similar with non-RTP traffic, you
>>>>>> could use that.
>>>>>>
>>>>>> But then for both endpoints agreeing on the value in order to
>>>>>> have connectivity checks happening simultaneously for the same
>>>>>> pairs, we'd probably need to do some negotiation, similar to
>>>>>> what was done with ICE on HIP
>>>>>> (http://tools.ietf.org/html/rfc5770#section-4.4).
>>>>>>
>>>>>>
>>>>>> Cheers, Ari
>>>>>
>>>>
>>>
>



--=20
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

From christer.holmberg@ericsson.com  Wed Oct 23 07:06: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 619EF21E808F for ; Wed, 23 Oct 2013 07:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.806
X-Spam-Level: 
X-Spam-Status: No, score=-3.806 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK5gnEkLvs-M for ; Wed, 23 Oct 2013 07:06:17 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9828211E83F4 for ; Wed, 23 Oct 2013 07:06:11 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-4f-5267d7cfec1a
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 56.AC.09019.FC7D7625; Wed, 23 Oct 2013 16:06:07 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 16:06:07 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54r//+FhgIAAIpUB///8bUCAAAAHAP/+8S7AgAIsaoD//9DwgA==
Date: Wed, 23 Oct 2013 14:06:06 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org>
In-Reply-To: <5267CA43.8020304@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje756+lBBjM2iFus2TmBxaLljpfF 1OWPWSwmf+pjdWDxWLLkJ5PH/zeBHh/mf2H3aDnXyx7AEsVlk5Kak1mWWqRvl8CV8WyRe0Gj YMXEDVeYGhiP83YxcnJICJhIbNr+nhnCFpO4cG89WxcjF4eQwFFGiWmPfzNCOEsYJXa/aACq 4uBgE7CQ6P6nDdIgIiAv0d22iAmkhlmgh1Fi8Y8GsEnCAokST37+ZYUoSpJ4v/g7O4RdJ/Fp 21+wGhYBVYneyXuZQGxeAV+Jcye62EBsIYEXzBKfd+mD2JwCmhLbFzeA9TICXff91BqwemYB cYlbT+YzQVwtILFkz3moD0QlXj7+xwphK0pcnb4cql5HYsHuT2wQtrbEsoWvmSH2CkqcnPmE ZQKj2CwkY2chaZmFpGUWkpYFjCyrGDmKU4uTctONDDYxAiPp4JbfFjsYL/+1OcQozcGiJM77 8a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGg09PduetDvqxofgRY+UcRyGZc6+l2b9y KEgcMn9Qt1n2h1un3x2bCe/uKsVkTz53vPK5y5Jwt1tqi87lTHblFe7c9+BOzNZg+8Xln1/u 9+conPvkmcWjB+yxWbOOile+8aqL9HthtGKywV6paP9nUVeX7/0TnPG0xSHSt4v5+0xlK6nL UxcdVGIpzkg01GIuKk4EALk6i45yAgAA
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Wed, 23 Oct 2013 14:06:23 -0000

Hi,

>> First, I completely messed up with the candidate types. Sorry for the=20
>> confusion :)
>>
>> Anyway, it doesn't really matter what type of candidates are trickled
>> - it's about whether trickled candidates can be affected by=20
>> Offers/Answers.
>
> And by affected you really mean invalidated. OK, I think I understand now=
.
>
> I don't think there's anything in 5245 that defines semantics which would=
 invalidate existing candidates.

Generally, in SDP Offer/Answer, when an SDP attribute is not present, it me=
ans that it's invalidated, or the default value (if such has been specified=
) is assumed.

You could of course argue that, if a candidate has never been carried in an=
 SDP Offer/Answer to begin with, SDP Offer/Answers should have no impact on=
 it.

But, that really depends on whether the candidates are considered part of t=
he SDP state or not. IF so, trickled candidates would update that state, in=
 the same way SDP Offers/Answers do.

My point is that these things need to be clearly clarified.

>>>> So, that would mean that if an Offer is received without the peer=20
>>>> refexive candidates, the answerer would remove them.
>>>
>>> You lost me. How would an answerer remove candidates from an offer if=20
>>> they weren't there in the first place? Did you mean to say something=20
>>> else?
>>
>> I referred to the example below, where an Offer does not contain a=20
>> candidate that was previously trickled, and whether the answerer will=20
>> then assume that the candidate is no longer valid.
>
> Right. I don't think there's such a risk. 5245 explicitly forbids update =
Offers and Answers to remove candidates that have been announced previously=
 and it allows (as in MAY, not SHOULD) that new candidates be added.
>
> The former should address your concern and I believe we could simply remo=
ve the latter as it is of little use, if any.

Well, then there is of course a risk that the receiver of the Answer will t=
rigger an error, as the trickled candidate is not included in the Answer (a=
s the Answer was sent before the candidate was trickled :)

Regards,

Christer

From emil@sip-communicator.org  Wed Oct 23 07:42: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 E971F11E838B for ; Wed, 23 Oct 2013 07:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3El7ureSnuTx for ; Wed, 23 Oct 2013 07:42:32 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id E443C11E838A for ; Wed, 23 Oct 2013 07:42:31 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id c11so903776wgh.26 for ; Wed, 23 Oct 2013 07:42:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iTGsUOlGOZXeNzn8eG/0KqKaq6WMm3A4c13abF2g+CA=; b=E126rfkhZysdDybxXypzP/WgOWA90wI8x1wGJlOy3sq+B65MLVHFYLOsNIp37sm/KO FGWLpAWyOCmiM5n4HG+1G+JpruD1ZqL0yobOAajFr2VMEffMuF/v0IiBDr6yRaZt9DS6 oLS7uoBh9ARWn9VGzL75KH6+p49gS+5kShhXmggQTteGEg3ZzB8Fs6nOQzKQ1B1nD17G AVVXTf+oXRC6w69qpSW8K/P288pXUhb/9d9EvE0wuy7mvNJMsMdIb+pAZVVFEucAawC5 iwNV2odEhcJ94wf7psE3Ab6MgwU/WlFae8xnpDHPts1yCxNtXcc8D0eH52ujcPJhHA1V HUSA==
X-Gm-Message-State: ALoCoQmjtf1EyfTr+ejRvSMQrvFKUAmez9hCdkuILm1PSqojmWlwvUAvv4f/pyAsl5cfUkLRNS83
X-Received: by 10.194.94.33 with SMTP id cz1mr1910192wjb.73.1382539351076; Wed, 23 Oct 2013 07:42:31 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPSA id fr4sm17514330wib.0.2013.10.23.07.42.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 07:42:30 -0700 (PDT)
Message-ID: <5267E052.6020401@jitsi.org>
Date: Wed, 23 Oct 2013 16:42:26 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Christer Holmberg 
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Wed, 23 Oct 2013 14:42:37 -0000

On 23.10.13, 16:06, Christer Holmberg wrote:
> Hi,
>
>>> First, I completely messed up with the candidate types. Sorry for the
>>> confusion :)
>>>
>>> Anyway, it doesn't really matter what type of candidates are trickled
>>> - it's about whether trickled candidates can be affected by
>>> Offers/Answers.
>>
>> And by affected you really mean invalidated. OK, I think I understand now.
>>
>> I don't think there's anything in 5245 that defines semantics which would invalidate existing candidates.
>
> Generally, in SDP Offer/Answer, when an SDP attribute is not present, it means that it's invalidated, or the default value (if such has been specified) is assumed.

What I meant was that 5245 explicitly states that all previously 
signalled candidates MUST be signalled in updated Offers, so candidate 
removal in the middle of ICE processing is not something that is defined 
for ICE.

Also, non-signalled candidates, like peer reflexive, are not required to 
be signalled in update Offers, so their absence in an offer cannot in 
any way be construed as a request for their removal.

> You could of course argue that, if a candidate has never been carried in an SDP Offer/Answer to begin with, SDP Offer/Answers should have no impact on it.

Yes, that's exactly what I'd argue since this is pretty much what 5245 
says (I say "pretty much" because it doesn't explicitly state it for 
trickle, but the general case matches).

> But, that really depends on whether the candidates are considered
> part of the SDP state or not. IF so, trickled candidates would update
> that state, in the same way SDP Offers/Answers do.

Right, and I've already mentioned that I don't see any reason to 
consider them as part of the SDP state, just as you wouldn't consider 
peer-reflexive candidates to be part of it.

> My point is that these things need to be clearly clarified.

I also agree that a clarification would be helpful (especially a clear 
one ;) ). It's easy to get lost in all this.

>>>>> So, that would mean that if an Offer is received without the peer
>>>>> refexive candidates, the answerer would remove them.
>>>>
>>>> You lost me. How would an answerer remove candidates from an offer if
>>>> they weren't there in the first place? Did you mean to say something
>>>> else?
>>>
>>> I referred to the example below, where an Offer does not contain a
>>> candidate that was previously trickled, and whether the answerer will
>>> then assume that the candidate is no longer valid.
>>
>> Right. I don't think there's such a risk. 5245 explicitly forbids update Offers and Answers to remove candidates that have been announced previously and it allows (as in MAY, not SHOULD) that new candidates be added.
>>
>> The former should address your concern and I believe we could simply remove the latter as it is of little use, if any.
>
> Well, then there is of course a risk that the receiver of the Answer
> will trigger an error, as the trickled candidate is not included in
> the Answer (as the Answer was sent before the candidate was trickled
> :)

Lost me again. I think some ascii art or a web sequence diag [0] would 
be very helpful here. Want to give it a try?

Or we could continue this discussion once we have the specific cases in 
the new version of the draft. Hopefully it would be easier that way.

Emil

[0] WebSequenceDiagrams: https://www.websequencediagrams.com/

>
> Regards,
>
> Christer
>

-- 
https://jitsi.org

From ari.keranen@ericsson.com  Wed Oct 23 10:33: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 5641D11E81CB for ; Wed, 23 Oct 2013 10:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.941
X-Spam-Level: 
X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[AWL=-1.642, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPZd7s1usIZb for ; Wed, 23 Oct 2013 10:33:38 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0ED11E81DE for ; Wed, 23 Oct 2013 10:33:36 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-7b-5268086d9111
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B7.B3.09019.D6808625; Wed, 23 Oct 2013 19:33:34 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Wed, 23 Oct 2013 19:33:33 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 730631103CF; Wed, 23 Oct 2013 20:33:33 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DDAFA4EADC; Wed, 23 Oct 2013 20:33:32 +0300 (EEST)
Received: from As-MacBook-Air.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 732094EADB; Wed, 23 Oct 2013 20:33:32 +0300 (EEST)
Message-ID: <52680871.5050304@ericsson.com>
Date: Wed, 23 Oct 2013 20:33:37 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Emil Ivov 
References: <526147C3.9040204@ericsson.com>  <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org> <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com> <52651780.60108@ericsson.com>  <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>  <861759C7815040489720E3CC184F51DD1C4791C6@ESESSMB205.ericsson.se> <526697C4.6030207@jitsi.org> <861759C7815040489720E3CC184F51DD1C481E05@ESESSMB205.ericsson.se> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjW4eR0aQwZulzBZ7/i5it1izcwKL xdTlj1ks3l9fyeLA4jHl90ZWjyVLfjJ5/H8T6DFr5xOWAJYoLpuU1JzMstQifbsErozNLReZ C9pUKr52ijUwPpXpYuTkkBAwkdiyfgkzhC0mceHeerYuRi4OIYGjjBJLzq1mgXA2MEr0bD7M CuHsZZTofTmXHcJZxyhxsOMxG0i/kMAKRomOR8kgNq+AtsTGj8uZQGwWAVWJ3v9rwHawCdhL 3JxwnR3EFhVIlrg4/xQbRL2gxMmZT1hAbBEBeYnutkVgvcwCeRIfH0DMFxZwkHj+Zh3U4r2s EpfXbQRLcAoESuxYvoANosFW4sKc6ywQtrxE89bZUM+pSVw9t4kZ4lBViav/XjFOYBSdhWT3 LCTts5C0L2BkXsXIUZxanJSbbmSwiREYIQe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MG489N3w2/x3nkqPgnlO3ok33TH9tMOpxT0aqyYl6swxV/Tq nHNoS8Zu85vFIpqVz+4uZoyLDNj7JkOaIza98PDXDdfZ3j7XuWHLV9QFjLRnm6aazA7/rxv0 YcM0GYstuQVVra/uvdkWJJB+e7VX151trsfZd/7f9fe+Ht9OI5VfSunfz/CFxyixFGckGmox FxUnAgBeOox3XgIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
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 Oct 2013 17:33:45 -0000

On 10/23/13 4:44 PM, Emil Ivov wrote:
> On Wed, Oct 23, 2013 at 3:31 PM, Ari Keränen  wrote:
>> Hi Emil,
>>
>> On Oct 22, 2013, at 6:20 PM, Emil Ivov wrote:
>>> On 22.10.13, 10:01, Ari Keränen wrote:
>>>> On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
>>>>> On Tue, Oct 22, 2013 at 1:11 AM, Ari Keränen
>>>>>  wrote:
>>>>>>
>>>>>> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>>>>>>
>>>>>>> I still don't get it. Why would we recommend values for
>>>>>>> different applications? We already tell applications to pace
>>>>>>> checks in accordance with expected traffic, which they
>>>>>>> supposedly can gauge better than the text in our RFC.
>>>>>>>
>>>>>>> A minimum value does make sense because it would basically say:
>>>>>>> "don't go below this value or you might brake the network or
>>>>>>> otherwise cause harm". That's actually useful advice.
>>>>>>
>>>>>> Exactly. We're not proposing (different) values for different
>>>>>> application. The proposal is to pace checks according to the
>>>>>> expected traffic. For RTP there is a formula, for other traffic
>>>>>> you're on your own (come up with formula, or what ever). The
>>>>>> "second" value is only for the cases where you don't know better
>>>>>> and should use something conservative.
>>>>>
>>>>> If you don't know better why wouldn't you just use RTP's 20 ms
>>>>> pacing given that we've already blessed it as safe and harmless and
>>>>> NAT friendly?
>>>>>
>>>>
>>>> 20 ms pacing has been blessed NAT friendly but not necessarily safe
>>>> and harmless for the rest of the network.
>>>
>>> Apparently we are happy to take the chance (5245):
>>>
>>>    Experiments have shown
>>>    that once every 20 ms is well supported, but not much lower than
>>>    that.  This is why Ta has a lower bound of 20 ms.
>>
>> Yes, with NAT binding creation.
>>
>>>> Also, if you start sending
>>>> connectivity checks faster than your uplink can handle, you'll end up
>>>> with false negatives due to dropped connectivity check packets.
>>>
>>> Sure, but a second bound of 50ms does not address this. Not more than 20ms or 500ms. You can always be on a link that will be saturated.
>>>
>>
>> Of course if the link is already fully saturated there's not much you can do (except detect that using it is a bad idea). But the chances of that happening on a non-saturated link are naturally getting lower and lower the longer pacing you have. With 500 ms pacing there aren't many real-world links (unless they're saturated) that could not handle it. Then the question is if 50 ms is "conservative enough"?
>>
>>>> Hence
>>>> I do see value in being a bit conservative if you don't know better.
>>>
>>>> But would you like to see only a single value, 20 ms, which should be
>>>> used always for pacing and no other recommended values whatsoever?
>>>
>>> Yes. If we could say, "go at a pace that emulates that of the ensuing streams, but never go below 20ms", I'd be happy.
>>
>> I agree, that's what we should say ("come up with formula or whatever for your non-RTP traffic to emulate the ensuing streams"). It's just for the cases where you don't have any good information on the ensuing streams when you'd need this second, more conservative, value to fall back to.
>
> Come on :). This sounds like trying to recommend a reasonable number
> of prayers per day.

If that's what it takes.. ;)

> Either you know what your traffic is and you
> emulate it, or you don't and in that case you just have to stay above
> 20 ms (or our potential new boundary).

So if you don't know about your traffic, you would opt to go for the 
most aggressive, least conservative value? I would find it natural to be 
more conservative in that case, play it safe.

> Note that "knowing what your traffic is" is not limited to knowing its
> exact bandwidth. You could also just know that it is real-time or not,
> involving user interaction or not.  In all of these cases you are free
> to choose 50, 100, 500ms depending on your needs. We can certainly
> explain that rationale. This will be helpful. We could maybe even
> place an upper bound above which ICE becomes dysfunctional (just a
> thought, not saying it's necessary)  but just slapping an arbitrary
> number is not helping anyone.

Yes, explaining the rationale definitely makes sense. However, what is 
"safe", I'm assuming, has to do with generated traffic volume, i.e., 
bandwidth consumption, either for you, your peer, or perhaps for a DoS 
attack target.


Cheers,
Ari


From fluffy@cisco.com  Wed Oct 23 11:17:38 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 7CA9711E83AA for ; Wed, 23 Oct 2013 11:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Level: 
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaB2txF8KXlf for ; Wed, 23 Oct 2013 11:17:33 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2811E83C1 for ; Wed, 23 Oct 2013 11:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=326; q=dns/txt; s=iport; t=1382552253; x=1383761853; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=95JE9IEm8zm0tAjPAB6vImXaVey2RMWpnArdsgjpDqA=; b=JZMVPBVUJYT1zZ24Vyuf6LiyrATu//HYVANnpwfUHYR6fxn4wTW8W8YY kMc39g59a5QSibZJzTqlLYGnMDR2cRZaEiC94hiP6SAI/3ibsQUdY7rYB axq6FypFezncM/r+YHRJRjL/WtOoFhmILEezRUKzNLLts4KEIo1sxGwY5 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsNAEMSaFKtJXG8/2dsb2JhbAA4IYMHgQy+U4EuFnSCJwEEgQsBKlYnBAEah367E48dg1eBCwOJB6EJgySCKg
X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="275750724"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2013 18:17:16 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9NIHG30003255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 18:17:16 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 13:17:16 -0500
From: "Cullen Jennings (fluffy)" 
To: mmusic WG , =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Flemming Andreasen (fandreas)" 
Thread-Topic: Agenda and conflict with PerPass
Thread-Index: AQHO0BwZYFOMTLhpikqdtBiDDGT8zg==
Date: Wed, 23 Oct 2013 18:17:15 +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="iso-8859-1"
Content-ID: <1E38096DA33CE34FA030EEE45E27349C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] Agenda and conflict with PerPass
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 Oct 2013 18:17:38 -0000

I will need to be at the PerPass meeting which conflicts with the Wednesday=
 mmusic session but I will be at the monday session. I suspect that I am no=
t the only person with this conflict.

Anything that can be done to push the more controversial WebRTC related ite=
ms towards monday would be much appreciated.=20





From mary.ietf.barnes@gmail.com  Wed Oct 23 11:30: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 C9C2311E8145 for ; Wed, 23 Oct 2013 11:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.434
X-Spam-Level: 
X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzcZHV5jZxEO for ; Wed, 23 Oct 2013 11:30:03 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7B56211E8126 for ; Wed, 23 Oct 2013 11:30:03 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id l18so1221732wgh.6 for ; Wed, 23 Oct 2013 11:30:02 -0700 (PDT)
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=iCucq32gLZAf1C7Ne3Xs/vkhqpDZ9/DgMzGkTgsA+RM=; b=bhal+b7vnK9p29fs2Y8MMR3NoKhTJ3G8rvUuh590qOs6iQBpJxdyywdguaZmNekE56 9Ar5xxuTccAi0YcvYSWSJWIy84FU5SYwA1z2FaU4hDBBcAvB8J0cavoEx3ondaWWgKWy vUwjsTKNgtsuYM/g5OmVt7ESQ122OZaiKU6GpDYNviQfq/mW877/H6Rz2I9a722HpyBh 0sShtaaJoemHTIqdmLqAijjlA6eXaMJ9dnVG53ycULuX65XMrumREOJl4PV00yr43RVL 3CN2l+PhEmeoQbpTjTkexjHPYvarm/v3Y1LoKLV41PQrv2nUN8A3INT/Z2nsy79wdwL4 uqnA==
MIME-Version: 1.0
X-Received: by 10.180.188.49 with SMTP id fx17mr3234427wic.33.1382553002757; Wed, 23 Oct 2013 11:30:02 -0700 (PDT)
Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 11:30:02 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 23 Oct 2013 13:30:02 -0500
Message-ID: 
From: Mary Barnes 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=001a11c25bda9cd27a04e96cb40f
Cc: "Flemming Andreasen \(fandreas\)" , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic WG 
Subject: Re: [MMUSIC] Agenda and conflict with PerPass
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 Oct 2013 18:30:05 -0000

--001a11c25bda9cd27a04e96cb40f
Content-Type: text/plain; charset=ISO-8859-1

I thought of that too as I think PerPass is of broad interest, but it
looked to me that there just isn't enough to fit all the RTCWEB topics into
one slot.  I'm wondering though since I haven't heard anything from the
ADs, if we couldn't use the extra time at the end of DISPATCH on Tuesday
for some of these topics?

Mary.


On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (fluffy)
wrote:

>
> I will need to be at the PerPass meeting which conflicts with the
> Wednesday mmusic session but I will be at the monday session. I suspect
> that I am not the only person with this conflict.
>
> Anything that can be done to push the more controversial WebRTC related
> items towards monday would be much appreciated.
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--001a11c25bda9cd27a04e96cb40f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I thought of that too as I think PerPass is of broad inter=
est, but it looked to me that there just isn't enough to fit all the RT=
CWEB topics into one slot. =A0I'm wondering though since I haven't =
heard anything from the ADs, if we couldn't use the extra time at the e=
nd of DISPATCH on Tuesday for some of these topics? =A0


Mary.=A0


On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (flu=
ffy) <fluffy@cisco.com> wrote:




I will need to be at the PerPass meeting which conflicts with the Wednesday=
 mmusic session but I will be at the monday session. I suspect that I am no=
t the only person with this conflict.



Anything that can be done to push the more controversial WebRTC related ite=
ms towards monday would be much appreciated.









_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--001a11c25bda9cd27a04e96cb40f--

From christer.holmberg@ericsson.com  Wed Oct 23 13:37: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 A66E711E8254 for ; Wed, 23 Oct 2013 13:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.617
X-Spam-Level: 
X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.631,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnjX-z5YswR8 for ; Wed, 23 Oct 2013 13:37:33 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEC8F11E8247 for ; Wed, 23 Oct 2013 13:37:10 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-1e-52683375b8dc
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.AB.16099.57338625; Wed, 23 Oct 2013 22:37:09 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 22:37:09 +0200
From: Christer Holmberg 
To: Mary Barnes , "Cullen Jennings (fluffy)" 
Thread-Topic: [MMUSIC] Agenda and conflict with PerPass
Thread-Index: AQHO0BwZYFOMTLhpikqdtBiDDGT8zpoCegYAgABDN7qAAAHXIQ==
Date: Wed, 23 Oct 2013 20:37:09 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EE3AE@ESESSMB209.ericsson.se>
References: , 
In-Reply-To: 
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_7594FB04B1934943A5C02806D1A2204B1C4EE3AEESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+JvjW6pcUaQwdH1RhbvL+hadExms/i8 fz+zxdTlj1kcWDym/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZWx/uZe94KhWxeYv WxkbGO8odzFycEgImEisWhfZxcgJZIpJXLi3nq2LkYtDSOAwo8T8i3eZIJwljBIfD29gBGlg E7CQ6P6nDdIgIhAr8ejGe2aQGmaBKYwS9zqOMIIkhAXMJFbcbWQBqRcRMJfYuSgOot5J4tTa PhYQm0VAVWLtusmsIDavgK/E7utvGSF2TWSUWNw+CWwOp0CgxO2FB9lAbEag676fWsMEYjML iEvcejKfCeJqAYkle84zQ9iiEi8f/2OFsBUldp5tZwa5gVkgX+LZe0GIXYISJ2c+YZnAKDoL yaRZCFWzkFRBlOhJ3Jg6hQ3C1pZYtvA1M4StKzHj3yGoGmuJHZ8vsCOrWcDIsYqRPTcxMye9 3HATIzACD275rbuD8dQ5kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg FH3LyKOjfH7lz7vX2zLuTD5a1egaNO+b2M+JvAVcJpN3XBc8set/dAZfkYfy9y6VM5F1Ll+d 5fz7t90+lLk554vxTBVLQ69O5rd3nm+xcyvs2xJv6lMlcjtLOmPCdFH2Yo9Wi395N9TFV34W vNrt2+fMvGTj/8NS57QfJzIV8rAFPKk78bhbiaU4I9FQi7moOBEAIAPuWo4CAAA=
Cc: "Flemming Andreasen \(fandreas\)" , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic WG 
Subject: Re: [MMUSIC] Agenda and conflict with PerPass
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 Oct 2013 20:37:53 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4EE3AEESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



I requested BUNDLE to be handled on Wednesday, due to the ECRIT conflict on=
 monday (there are some topics I cover in ECRIT). However, ECRIT has not pu=
blished their agenda yet, so I don't know what/when will be discussed.



But, if peole can't attend the MMUSIC session on Wednesday, we'll probably =
have to switch. Because, at the end of the day, my hope is to actually clos=
e some BUNDLE issues.



I understand Adam is also interested in PerPass, which means the POF/PAN st=
uff would have to be switched.



Regards,



Christer



________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Mary B=
arnes [mary.ietf.barnes@gmail.com]
Sent: Wednesday, 23 October 2013 9:30 PM
To: Cullen Jennings (fluffy)
Cc: Flemming Andreasen (fandreas); Ari Ker=E4nen; mmusic WG
Subject: Re: [MMUSIC] Agenda and conflict with PerPass

I thought of that too as I think PerPass is of broad interest, but it looke=
d to me that there just isn't enough to fit all the RTCWEB topics into one =
slot.  I'm wondering though since I haven't heard anything from the ADs, if=
 we couldn't use the extra time at the end of DISPATCH on Tuesday for some =
of these topics?

Mary.


On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (fluffy) > wrote:

I will need to be at the PerPass meeting which conflicts with the Wednesday=
 mmusic session but I will be at the monday session. I suspect that I am no=
t the only person with this conflict.

Anything that can be done to push the more controversial WebRTC related ite=
ms towards monday would be much appreciated.




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


--_000_7594FB04B1934943A5C02806D1A2204B1C4EE3AEESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <4860E894CAE24E4692B056FE8C824930@ericsson.com>
Content-Transfer-Encoding: quoted-printable










Hi,


 


I requested BUNDLE to be handled on Wednesday, due to the ECRIT conflict=
 on monday (there are some topics I cover in ECRIT). However, ECRIT has not=
 published their agenda yet, so I don't know what/when will be discussed.

 


But, if peole can't attend the MMUSIC session on Wednesday, we'll p=
robably have to switch. Because, at the end of the day, my hope is to actua=
lly close some BUNDLE issues.


 


I understand Adam is also interested in PerPass, which means the POF/PAN=
 stuff would have to be switched.


 


Regards,


 


Christer


 




From: mmusic-bounces@ietf.org [mmusic-bou=
nces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]

Sent: Wednesday, 23 October 2013 9:30 PM

To: Cullen Jennings (fluffy)

Cc: Flemming Andreasen (fandreas); Ari Ker=E4nen; mmusic WG

Subject: Re: [MMUSIC] Agenda and conflict with PerPass










I thought of that too as I think PerPass is of broad inter=
est, but it looked to me that there just isn't enough to fit all the RTCWEB=
 topics into one slot.  I'm wondering though since I haven't heard any=
thing from the ADs, if we couldn't use
 the extra time at the end of DISPATCH on Tuesday for some of these topics?=
  






Mary. 









On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings=
 (fluffy)
<fluffy@cisco.com> wrote:





I will need to be at the PerPass meeting which conflicts with the Wednesday=
 mmusic session but I will be at the monday session. I suspect that I am no=
t the only person with this conflict.



Anything that can be done to push the more controversial WebRTC related ite=
ms towards monday would be much appreciated.









_______________________________________________

mmusic mailing list

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
















--_000_7594FB04B1934943A5C02806D1A2204B1C4EE3AEESESSMB209erics_--

From fandreas@cisco.com  Wed Oct 23 18:33: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 D7A0D11E80DC for ; Wed, 23 Oct 2013 18:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.298
X-Spam-Level: 
X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmqnqeglhdqh for ; Wed, 23 Oct 2013 18:33:29 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD9B11E82A1 for ; Wed, 23 Oct 2013 18:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8334; q=dns/txt; s=iport; t=1382578406; x=1383788006; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1HtbA/IuRN8EiGi8Ae7aR+F6oTrIKpFDC39N9G1zPOA=; b=CNDPmiPGAKsOwttc39rf9eeIppBwUex0eByp0nBoGNL7csv1MZs+H+3E BlKSgIf8PUe5rmDXmv1hh1IQQSa3KaGkOIzklsx/P7RSfpW41ds3QGvz+ LGDA6kqo9fVBvj0hErOevZNq/kf9yopBoxWFc6wUcDUnAPx144kuAeBkd o=;
X-IronPort-AV: E=Sophos;i="4.93,558,1378857600"; d="scan'208,217";a="95459422"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 24 Oct 2013 01:33:24 +0000
Received: from che-vpn-cluster-1-349.cisco.com (che-vpn-cluster-1-349.cisco.com [10.86.241.94]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9O1XJaT026482; Thu, 24 Oct 2013 01:33:20 GMT
Message-ID: <526878E0.4090501@cisco.com>
Date: Wed, 23 Oct 2013 21:33:20 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Christer Holmberg , Mary Barnes , "Cullen Jennings (fluffy)" , mmusic WG 
References: ,  <7594FB04B1934943A5C02806D1A2204B1C4EE3AE@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EE3AE@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------010302070003080307070507"
Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
Subject: Re: [MMUSIC] Agenda and conflict with PerPass
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, 24 Oct 2013 01:33:34 -0000

This is a multi-part message in MIME format.
--------------010302070003080307070507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Seperately, the chairs have received a request to move the Wednesday 
MMUSIC session as follows:

	Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose, ccamp, l3vpn, homenet and tsvarea.  There are no listed conflicts that would result from this change

This would seem to resolve conflicts for some of the WG participants on 
Wednesday, but the question is if it introduces new problems. If anybody 
has any concerns with such a move, please let us know ASAP. It would be 
good to hear from those in favor too.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)

On 10/23/13 4:37 PM, Christer Holmberg wrote:
>
> Hi,
>
> I requested BUNDLE to be handled on Wednesday, due to the ECRIT 
> conflict on monday (there are some topics I cover in ECRIT). However, 
> ECRIT has not published their agenda yet, so I don't know what/when 
> will be discussed.
>
> But, if peole can't attend the MMUSIC session on Wednesday, we'll 
> probably have to switch. Because, at the end of the day, my hope is to 
> actually close some BUNDLE issues.
>
> I understand Adam is also interested in PerPass, which means the 
> POF/PAN stuff would have to be switched.
>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of 
> Mary Barnes [mary.ietf.barnes@gmail.com]
> *Sent:* Wednesday, 23 October 2013 9:30 PM
> *To:* Cullen Jennings (fluffy)
> *Cc:* Flemming Andreasen (fandreas); Ari Keränen; mmusic WG
> *Subject:* Re: [MMUSIC] Agenda and conflict with PerPass
>
> I thought of that too as I think PerPass is of broad interest, but it 
> looked to me that there just isn't enough to fit all the RTCWEB topics 
> into one slot.  I'm wondering though since I haven't heard anything 
> from the ADs, if we couldn't use the extra time at the end of DISPATCH 
> on Tuesday for some of these topics?
>
> Mary.
>
>
> On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (fluffy) 
> > wrote:
>
>
>     I will need to be at the PerPass meeting which conflicts with the
>     Wednesday mmusic session but I will be at the monday session. I
>     suspect that I am not the only person with this conflict.
>
>     Anything that can be done to push the more controversial WebRTC
>     related items towards monday would be much appreciated.
>
>
>
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org 
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>


--------------010302070003080307070507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Seperately, the chairs have received a request to move the Wednesday
    MMUSIC session as follows:

    
	Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose, ccamp, l3vpn, homenet and tsvarea.  There are no listed conflicts that would result from this change

    This would seem to resolve conflicts for some of the WG participants
    on Wednesday, but the question is if it introduces new problems. If
    anybody has any concerns with such a move, please let us know ASAP.
    It would be good to hear from those in favor too. 

    

    Thanks 

    

    -- Ari & Flemming (MMUSIC co-chairs)

    

    
On 10/23/13 4:37 PM, Christer Holmberg
      wrote:

    

    

      
      
      

        
Hi,

        
 

        
I requested BUNDLE to be handled on Wednesday, due to the
          ECRIT conflict on monday (there are some topics I cover in
          ECRIT). However, ECRIT has not published their agenda yet, so
          I don't know what/when will be discussed.

        
 

        
But, if peole can't attend the MMUSIC session on Wednesday,
          we'll probably have to switch. Because, at the end of the day,
          my hope is to actually close some BUNDLE issues.

        
 

        
I understand Adam is also interested in PerPass, which means
          the POF/PAN stuff would have to be switched.

        
 

        
Regards,

        
 

        
Christer

        
 

        

        
From:
            mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf
            of Mary Barnes [mary.ietf.barnes@gmail.com]

            Sent: Wednesday, 23 October 2013 9:30 PM

            To: Cullen Jennings (fluffy)

            Cc: Flemming Andreasen (fandreas); Ari Keränen;
            mmusic WG

            Subject: Re: [MMUSIC] Agenda and conflict with
            PerPass

          

        

        

          
I thought of that too as I think PerPass is of
            broad interest, but it looked to me that there just isn't
            enough to fit all the RTCWEB topics into one slot.  I'm
            wondering though since I haven't heard anything from the
            ADs, if we couldn't use the extra time at the end of
            DISPATCH on Tuesday for some of these topics?  
            


            

            
Mary. 

          

          


            

            
On Wed, Oct 23, 2013 at 1:17 PM,
              Cullen Jennings (fluffy)
              <fluffy@cisco.com>
              wrote:

              

                

                I will need to be at the PerPass meeting which conflicts
                with the Wednesday mmusic session but I will be at the
                monday session. I suspect that I am not the only person
                with this conflict.

                

                Anything that can be done to push the more controversial
                WebRTC related items towards monday would be much
                appreciated.

                

                

                

                

                _______________________________________________

                mmusic mailing list

                mmusic@ietf.org

                https://www.ietf.org/mailman/listinfo/mmusic

              

            

            

          

        

      

    

    

  


--------------010302070003080307070507--

From christer.holmberg@ericsson.com  Thu Oct 24 00:01:12 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 B351D11E8160 for ; Thu, 24 Oct 2013 00:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhBay8Vr8oF5 for ; Thu, 24 Oct 2013 00:01:08 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1611E8109 for ; Thu, 24 Oct 2013 00:01:04 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-8f-5268c5af874f
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 95.73.09019.FA5C8625; Thu, 24 Oct 2013 09:01:04 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 09:01:03 +0200
From: Christer Holmberg 
To: Flemming Andreasen , Mary Barnes , "Cullen Jennings (fluffy)" , mmusic WG 
Thread-Topic: [MMUSIC] Agenda and conflict with PerPass
Thread-Index: AQHO0BwZYFOMTLhpikqdtBiDDGT8zpoCegYAgABDN7qAAAHXIYAAMTcAgAB9F2s=
Date: Thu, 24 Oct 2013 07:01:02 +0000
Message-ID: 
References: ,  <7594FB04B1934943A5C02806D1A2204B1C4EE3AE@ESESSMB209.ericsson.se>, <526878E0.4090501@cisco.com>
In-Reply-To: <526878E0.4090501@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_dxbemu4b2h62dyagbnjqq87r1382598059689emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvje6GoxlBBltmcFu8v6Br0TGZzeLz /v3MFlOXP2ZxYPGY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlXH9wDrmgj3WFcv/ zWVvYDxu2MXIySEhYCLRtH4SO4QtJnHh3no2EFtI4CijxPH13BD2EkaJ5a+zuhg5ONgELCS6 /2l3MXJxiAgsZZTY+LuPCaSGWcBWYu6lC6wgtrCAmcTdGy1sIPUiAuYSOxfFgYRFBPwkjjx7 ywhiswioSvx/uxjM5hVwk3i76ggbyEwhgU+MEjNuHGYGSXAKaErsmvsezGYEuu37qTVQu8Ql bj2ZzwRxs4DEkj3nmSFsUYmXj/+xQtTkSCyYvIUFYoGgxMmZT1gmMIrMQtI+C0nZLCRlEHE9 iRtTp7BB2NoSyxa+ZoawdSVm/DvEgiy+gJF9FSNHcWpxUm66kcEmRmBUHdzy22IH4+W/NocY pTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuCEwSuK9A1+SWdwu6VDXjnTl i2oTH1taCTzSuv639eRuSftkV5FzHaG89U/jZvmq2616vauqXf5YkH1hXNKL5a+rQ3//nRne ru+mKXfMvWzvzYojzP+P2s8+sfz9vNfbd1o2nt0Rt6iFd5aao0vHi1VajYKVIZUvFB/oBZ0v YBV46Kq/K7xNiaU4I9FQi7moOBEAASTk0HgCAAA=
Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
Subject: Re: [MMUSIC] Agenda and conflict with PerPass
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, 24 Oct 2013 07:01:12 -0000

--_000_dxbemu4b2h62dyagbnjqq87r1382598059689emailandroidcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am in favor of such move.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Flemming Andreasen  wrote:



Seperately, the chairs have received a request to move the Wednesday MMUSIC=
 session as follows:

        Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose, c=
camp, l3vpn, homenet and tsvarea.  There are no listed conflicts that would=
 result from this change

This would seem to resolve conflicts for some of the WG participants on Wed=
nesday, but the question is if it introduces new problems. If anybody has a=
ny concerns with such a move, please let us know ASAP. It would be good to =
hear from those in favor too.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)

On 10/23/13 4:37 PM, Christer Holmberg wrote:

Hi,



I requested BUNDLE to be handled on Wednesday, due to the ECRIT conflict on=
 monday (there are some topics I cover in ECRIT). However, ECRIT has not pu=
blished their agenda yet, so I don't know what/when will be discussed.



But, if peole can't attend the MMUSIC session on Wednesday, we'll probably =
have to switch. Because, at the end of the day, my hope is to actually clos=
e some BUNDLE issues.



I understand Adam is also interested in PerPass, which means the POF/PAN st=
uff would have to be switched.



Regards,



Christer



________________________________
From: mmusic-bounces@ietf.org [mmusic-bounc=
es@ietf.org] on behalf of Mary Barnes [mary=
.ietf.barnes@gmail.com]
Sent: Wednesday, 23 October 2013 9:30 PM
To: Cullen Jennings (fluffy)
Cc: Flemming Andreasen (fandreas); Ari Ker=E4nen; mmusic WG
Subject: Re: [MMUSIC] Agenda and conflict with PerPass

I thought of that too as I think PerPass is of broad interest, but it looke=
d to me that there just isn't enough to fit all the RTCWEB topics into one =
slot.  I'm wondering though since I haven't heard anything from the ADs, if=
 we couldn't use the extra time at the end of DISPATCH on Tuesday for some =
of these topics?

Mary.


On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (fluffy) > wrote:

I will need to be at the PerPass meeting which conflicts with the Wednesday=
 mmusic session but I will be at the monday session. I suspect that I am no=
t the only person with this conflict.

Anything that can be done to push the more controversial WebRTC related ite=
ms towards monday would be much appreciated.




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



--_000_dxbemu4b2h62dyagbnjqq87r1382598059689emailandroidcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi,=0A=
=0A=
I am in favor of such move.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Flemming Andreasen <fandreas@cisco.com> wrote:=0A=
=0A=



Seperately, the chairs have received a request to move the Wednesday M=
MUSIC session as follows:


	Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose, cca=
mp, l3vpn, homenet and tsvarea.  There are no listed conflicts that would r=
esult from this change

This would seem to resolve conflicts for some of the WG participants on Wed=
nesday, but the question is if it introduces new problems. If anybody has a=
ny concerns with such a move, please let us know ASAP. It would be good to =
hear from those in favor too.




Thanks 



-- Ari & Flemming (MMUSIC co-chairs)




On 10/23/13 4:37 PM, Christer Holmberg wrote=
:








Hi,


 


I requested BUNDLE to be handled on Wednesday, due to the ECRIT conflict=
 on monday (there are some topics I cover in ECRIT). However, ECRIT has not=
 published their agenda yet, so I don't know what/when will be discussed.

 


But, if peole can't attend the MMUSIC session on Wednesday, we'll p=
robably have to switch. Because, at the end of the day, my hope is to actua=
lly close some BUNDLE issues.


 


I understand Adam is also interested in PerPass, which means the POF/PAN=
 stuff would have to be switched.


 


Regards,


 


Christer


 




From:
mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf =
of Mary Barnes [mary.ietf.barnes@gmail.com]

Sent: Wednesday, 23 October 2013 9:30 PM

To: Cullen Jennings (fluffy)

Cc: Flemming Andreasen (fandreas); Ari Ker=E4nen; mmusic WG

Subject: Re: [MMUSIC] Agenda and conflict with PerPass








I thought of that too as I think PerPass is of broad inter=
est, but it looked to me that there just isn't enough to fit all the RTCWEB=
 topics into one slot.  I'm wondering though since I haven't heard any=
thing from the ADs, if we couldn't use
 the extra time at the end of DISPATCH on Tuesday for some of these topics?=
  






Mary. 









On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings=
 (fluffy)
<fluffy@cisco.com> wrote:





I will need to be at the PerPass meeting which conflicts with the Wednesday=
 mmusic session but I will be at the monday session. I suspect that I am no=
t the only person with this conflict.



Anything that can be done to push the more controversial WebRTC related ite=
ms towards monday would be much appreciated.









_______________________________________________

mmusic mailing list

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






















--_000_dxbemu4b2h62dyagbnjqq87r1382598059689emailandroidcom_--

From magnus.westerlund@ericsson.com  Thu Oct 24 00:20: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 1572421E808D for ; Thu, 24 Oct 2013 00:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.305
X-Spam-Level: 
X-Spam-Status: No, score=-105.305 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmfsJjIbFH2F for ; Thu, 24 Oct 2013 00:20:58 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFB521E8089 for ; Thu, 24 Oct 2013 00:20:50 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-b5-5268ca511891
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 54.9D.16099.15AC8625; Thu, 24 Oct 2013 09:20:49 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Thu, 24 Oct 2013 09:20:48 +0200
Message-ID: <5268CA77.7090804@ericsson.com>
Date: Thu, 24 Oct 2013 09:21:27 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "mmusic (E-mail)" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvjW7gqYwgg+9H5CymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujB2tP1kLlvFVnGnYw9LA2MbTxcjJISFgIvFl5kxGCFtM4sK9 9WxdjFwcQgKHGSWmnpvLDOEsZ5RY+7GDCaSKV0Bb4n3rBTCbRUBVYu3dxcwgNpuAhcTNH41s ILaoQLDEjWWH2CDqBSVOznzCAmKLCKhLtG7uYwWxhQUMJBY9vwu0mQNos7hET2MQSJhZQE9i ytUWRghbXqJ562yw8UJAaxuaOlgnMPLPQjJ1FpKWWUhaFjAyr2Jkz03MzEkvN9zECAyng1t+ 6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYdcOCxLw/7W3d vaJC8tI2c8V/m04vyjklZ32k9f4awXKjnfl/uhx+ZAo2r00sNEx8KvQj6GLyq/g9dzR0Z+6t YFn3TCtJZuYt46nHl3J7u3mc+C964+Jm6daz3jb9a6vbN3fVz6u98Mb/5E17DtWtv6XVXeI5 mnbazHtiMnXebtcDlWcsH+/4oMRSnJFoqMVcVJwIAMqOoE31AQAA
Subject: [MMUSIC] RTP Simulcast proposal has been updated
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, 24 Oct 2013 07:20:59 -0000

WG,

My co-authors and I have updated the proposal for how to do Simulcast in
RTP so that it supports Unified Plan for SDP. Thus we can support single
media source per media description with multiple simulcast encodings.
It also support multiple sources per media description for
broadcast/simulcast as well as "legacy" usages where the simulcast
encoding versions are distributed across different media descriptions in
SDP. Thus simulcast within one as well as using multiple RTP sessions
(and thus transports) are supported.

This update also focuses the SRCNAME SDES item proposal to the need of
simulcast. SRCNAME is used to identify the relationship between an SSRC
and the media source and particular encoding carried. To speed up
acquisition we are proposing an generic SDES item RTP Header extension
to enable inclusion of the SRCNAME item in RTP headers at startup.

The proposal consists of three I-Ds and we will discuss the general
signalling and setup/negotiation in MMUSIC and the SRCNAME and the
header extension is requested to be presented in AVTEXT WG.

https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/
https://datatracker.ietf.org/doc/draft-westerlund-avtext-sdes-hdr-ext/
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/

Feedback much appreciated

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 christer.holmberg@ericsson.com  Thu Oct 24 06:01: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 E171211E8183 for ; Thu, 24 Oct 2013 06:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.795
X-Spam-Level: 
X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTESXS0d4Fet for ; Thu, 24 Oct 2013 06:01:35 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 966E711E8153 for ; Thu, 24 Oct 2013 06:01:34 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-25-52691a2df688
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0A.F8.09019.D2A19625; Thu, 24 Oct 2013 15:01:33 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 15:01:33 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54r//+FhgIAAIpUB///8bUCAAAAHAP/+8S7AgAIsaoD//9DwgAAJK5MA//6RbBA=
Date: Thu, 24 Oct 2013 13:01:32 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se> <5267E052.6020401@jitsi.org>
In-Reply-To: <5267E052.6020401@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja6uVGaQwZz54hZrdk5gsWi542Ux dfljFovJn/pYHVg8liz5yeTx/02gx4f5X9g9Ws71sgewRHHZpKTmZJalFunbJXBl7Djbzlpw RqBi3ZLlzA2MS3m7GDk5JARMJJb1XWaBsMUkLtxbz9bFyMUhJHCUUeLH7afMEM4SRol3xy4C ZTg42AQsJLr/aYM0iAjIS3S3LWICqWEW6GGUWPyjgRkkISyQKPHk519WiKIkifeLv7ODFIkI dDFK7Fl4lh0kwSKgKvFyzTdmkKG8Ar4SnbM0IZadZpFontsCVsMpoClx4OxcMJsR6Lzvp9Yw gdjMAuISt57MZ4I4W0BiyZ7zzBC2qMTLx/9YIWxFiavTl0PV60gs2P2JDcLWlli28DVYPa+A oMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMJoObvltsYPx8l+bQ4zS HCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDsV/WZWZ6joHuyRVXcY/uyP6yx qn+PPbtlH/j59MTrrIYlhVIuEq5Rd9h7ph/P2Gc3Y92s7w83lLvfsAplXLhqu9MugU/+/+fl 9koY/rG3PlN+6yfz3Kj3t/0+9Wq5KH7+GH6a5/zEkEN59ko3Nz56vi1X/mhL1uXLcw9VKjyL y+IQa2y8MWWPEktxRqKhFnNRcSIAqKKK1XQCAAA=
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Thu, 24 Oct 2013 13:01:42 -0000

Hi,

>>>> First, I completely messed up with the candidate types. Sorry for=20
>>>> the confusion :)
>>>>
>>>> Anyway, it doesn't really matter what type of candidates are=20
>>>> trickled
>>>> - it's about whether trickled candidates can be affected by=20
>>>> Offers/Answers.
>>>
>>> And by affected you really mean invalidated. OK, I think I understand n=
ow.
>>>
>>> I don't think there's anything in 5245 that defines semantics which wou=
ld invalidate existing candidates.
>>
>> Generally, in SDP Offer/Answer, when an SDP attribute is not present, it=
 means that it's invalidated, or the default value (if such has been specif=
ied) is assumed.
>
> What I meant was that 5245 explicitly states that all previously signalle=
d candidates MUST be signalled in updated Offers, so candidate removal in t=
he middle of ICE processing is not something that is defined for ICE.
>
> Also, non-signalled candidates, like peer reflexive, are not required to =
be signalled in update Offers, so their absence in an offer cannot in any w=
ay be construed as a request for their removal.

So, IF we can define the same for trickled candidates, then there might not=
 be an issue.

We have to remember, though, that a trickled candidate is not a new candida=
te "type". The candidate types you trickle are the same types you send in O=
ffer/Answer - tickle is simply an alternative candidate transport mechanism=
.

>> But, that really depends on whether the candidates are considered part=20
>> of the SDP state or not. IF so, trickled candidates would update that=20
>> state, in the same way SDP Offers/Answers do.
>
> Right, and I've already mentioned that I don't see any reason to consider=
 them as part of the SDP state, just as you wouldn't consider peer-reflexiv=
e candidates to be part of it.

If a trickled candidate is eventually selected, doesn't a "clean up" SDP Of=
fer have to be sent (as for any other non-default candidate), where the c- =
line is aligned with the candidate? In that case the candidate becomes part=
 of the SDP state :)

Regards,

Christer

From pkyzivat@alum.mit.edu  Thu Oct 24 06:59: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 0BF9121F99E9 for ; Thu, 24 Oct 2013 06:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGYic-y29N0L for ; Thu, 24 Oct 2013 06:59:08 -0700 (PDT)
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 10EFF11E83E6 for ; Thu, 24 Oct 2013 06:59:06 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta07.westchester.pa.mail.comcast.net with comcast id h1EV1m0090EZKEL571z6vK; Thu, 24 Oct 2013 13:59:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id h1z51m00w3ZTu2S3M1z5FH; Thu, 24 Oct 2013 13:59:06 +0000
Message-ID: <526927A9.9040505@alum.mit.edu>
Date: Thu, 24 Oct 2013 09:59:05 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: , 	<7594FB04B1934943A5C02806D1A2204B1C4EE3AE@ESESSMB209.ericsson.se>, <526878E0.4090501@cisco.com> 
In-Reply-To: 
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=1382623146; bh=CAHBmIAlq8itnHvKjr+X9R7fnI63xJBKz6DyWya1Aj4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hEtNUKvJQvzsQNu0fI6VTClYJLO/19S4movjDfGfSmQ1JTmC1UckJQ/GYESX32Gfj Yv7pyRlrwzpcAh8LGm/7MxBLAZmoeLR6H0k/ZPfH2eqILrORmzVFWeFkeIrsJd+Wih j6u2OP4lokEXVqIsl9vt2c9VdWcnKvbJ5KjDAPL0edYbuGcZvR3nzGhDaSr9YdkqLs l7pyY+56Qnk+QNB5KuPv5C1VaAOvLWYoS7vB3dw8XAwtwSG3u7Mi5iu2rNxs9hFPGz UdDtDpsomqNbShbQ8/HXWfueUTqmSTp+0cJ7CEXZpuNR2ONfflb5qt4u7FLzuqBwFi aPJyOADmutGuA==
Subject: Re: [MMUSIC] Agenda and conflict with PerPass
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, 24 Oct 2013 13:59:13 -0000

On 10/24/13 3:01 AM, Christer Holmberg wrote:
> Hi,
>
> I am in favor of such move.

+1

> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Flemming Andreasen  wrote:
>
> Seperately, the chairs have received a request to move the Wednesday
> MMUSIC session as follows:
>
> 	Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose, ccamp, l3vpn, homenet and tsvarea.  There are no listed conflicts that would result from this change
>
> This would seem to resolve conflicts for some of the WG participants on
> Wednesday, but the question is if it introduces new problems. If anybody
> has any concerns with such a move, please let us know ASAP. It would be
> good to hear from those in favor too.
>
> Thanks
>
> -- Ari & Flemming (MMUSIC co-chairs)
>
> On 10/23/13 4:37 PM, Christer Holmberg wrote:
>>
>> Hi,
>>
>> I requested BUNDLE to be handled on Wednesday, due to the ECRIT
>> conflict on monday (there are some topics I cover in ECRIT). However,
>> ECRIT has not published their agenda yet, so I don't know what/when
>> will be discussed.
>>
>> But, if peole can't attend the MMUSIC session on Wednesday, we'll
>> probably have to switch. Because, at the end of the day, my hope is to
>> actually close some BUNDLE issues.
>>
>> I understand Adam is also interested in PerPass, which means the
>> POF/PAN stuff would have to be switched.
>>
>> Regards,
>>
>> Christer
>>
>> ------------------------------------------------------------------------
>> *From:* mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of
>> Mary Barnes [mary.ietf.barnes@gmail.com]
>> *Sent:* Wednesday, 23 October 2013 9:30 PM
>> *To:* Cullen Jennings (fluffy)
>> *Cc:* Flemming Andreasen (fandreas); Ari Keränen; mmusic WG
>> *Subject:* Re: [MMUSIC] Agenda and conflict with PerPass
>>
>> I thought of that too as I think PerPass is of broad interest, but it
>> looked to me that there just isn't enough to fit all the RTCWEB topics
>> into one slot.  I'm wondering though since I haven't heard anything
>> from the ADs, if we couldn't use the extra time at the end of DISPATCH
>> on Tuesday for some of these topics?
>>
>> Mary.
>>
>>
>> On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (fluffy)
>> > wrote:
>>
>>
>>     I will need to be at the PerPass meeting which conflicts with the
>>     Wednesday mmusic session but I will be at the monday session. I
>>     suspect that I am not the only person with this conflict.
>>
>>     Anything that can be done to push the more controversial WebRTC
>>     related items towards monday would be much appreciated.
>>
>>
>>
>>
>>     _______________________________________________
>>     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 emil@sip-communicator.org  Thu Oct 24 07:28: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 77C8511E8327 for ; Thu, 24 Oct 2013 07:28:04 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na1zc51UTCl6 for ; Thu, 24 Oct 2013 07:27:59 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id AEAE111E82F0 for ; Thu, 24 Oct 2013 07:27:56 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t61so2435769wes.34 for ; Thu, 24 Oct 2013 07:27:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QMQ+O4B9zhDBpjqtZrflGHodgiMmx1cxi/lSS+hHDqY=; b=ZKBcA9+KxeGIXF5ifvUoDdkz2TceIl1YnCJhmj0lvejG8YxBQ2GgiPGCvUjB8TEbeT EmXtJoKWfO/jGkeaC4TWxHOCGx4hn8sX9mQBED5p8w4KKQiHULyvJMx3AFH8Qo0LswI+ kRlbmoXqz3EBVzxGzE3f3/Ld1yOOudd+aAzKQGl5FkE+7mDmTRl/ckaaESAEs4EUuG/5 exNTsxxqgA0x6TDQrxML6+wElErw3adSRSDZdFv2HR+8DxTmLo/vz/AcctcgnWd3Qr7a ooKkIN8tRAEtVicV7H9hTL0WGwV6e5rXmUI8+xgbIulg3aVoXGrZ4LlutCrxjxm4oECV MZiQ==
X-Gm-Message-State: ALoCoQm958kATXy7NBBaybvRvDK0UiksDCpvVt+l20a3mKcPVBCXC1Lkb/5n7bCQGG6vfPygKWpL
X-Received: by 10.180.187.202 with SMTP id fu10mr2488008wic.59.1382624875867;  Thu, 24 Oct 2013 07:27:55 -0700 (PDT)
Received: from camionet.local (neu67-4-88-160-65-79.fbx.proxad.net. [88.160.65.79]) by mx.google.com with ESMTPSA id d10sm1456731wic.2.2013.10.24.07.27.54 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Oct 2013 07:27:55 -0700 (PDT)
Message-ID: <52692E69.8020109@jitsi.org>
Date: Thu, 24 Oct 2013 16:27:53 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Christer Holmberg 
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se> <5267E052.6020401@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Thu, 24 Oct 2013 14:28:04 -0000

Hey Christer,

On 24.10.13, 15:01, Christer Holmberg wrote:
> Hi,
>
>>>>> First, I completely messed up with the candidate types. Sorry
>>>>> for the confusion :)
>>>>>
>>>>> Anyway, it doesn't really matter what type of candidates are
>>>>> trickled - it's about whether trickled candidates can be
>>>>> affected by Offers/Answers.
>>>>
>>>> And by affected you really mean invalidated. OK, I think I
>>>> understand now.
>>>>
>>>> I don't think there's anything in 5245 that defines semantics
>>>> which would invalidate existing candidates.
>>>
>>> Generally, in SDP Offer/Answer, when an SDP attribute is not
>>> present, it means that it's invalidated, or the default value (if
>>> such has been specified) is assumed.
>>
>> What I meant was that 5245 explicitly states that all previously
>> signalled candidates MUST be signalled in updated Offers, so
>> candidate removal in the middle of ICE processing is not something
>> that is defined for ICE.
>>
>> Also, non-signalled candidates, like peer reflexive, are not
>> required to be signalled in update Offers, so their absence in an
>> offer cannot in any way be construed as a request for their
>> removal.
>
> So, IF we can define the same for trickled candidates, then there
> might not be an issue.

That's also my thinking (without the IF ;) ).

> We have to remember, though, that a trickled candidate is not a new
> candidate "type". The candidate types you trickle are the same types
> you send in Offer/Answer - tickle is simply an alternative candidate
> transport mechanism.

Yes, that's right. I am not sure why you are saying it though.

>>> But, that really depends on whether the candidates are considered
>>> part of the SDP state or not. IF so, trickled candidates would
>>> update that state, in the same way SDP Offers/Answers do.
>>
>> Right, and I've already mentioned that I don't see any reason to
>> consider them as part of the SDP state, just as you wouldn't
>> consider peer-reflexive candidates to be part of it.
>
> If a trickled candidate is eventually selected, doesn't a "clean up"
> SDP Offer have to be sent (as for any other non-default candidate),
> where the c- line is aligned with the candidate? In that case the
> candidate becomes part of the SDP state :)

As a result of the update offer, not as a direct result of trickle (just 
as with peer-reflexive candidates, which I seem to like repeating :) )

Emil

-- 
https://jitsi.org

From christer.holmberg@ericsson.com  Thu Oct 24 07:34: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 DAA3B11E8155 for ; Thu, 24 Oct 2013 07:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.607
X-Spam-Level: 
X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[AWL=0.642,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgTauLV3xNmY for ; Thu, 24 Oct 2013 07:34:25 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6F911E8315 for ; Thu, 24 Oct 2013 07:34:19 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-96-52692feb6445
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CC.9A.03802.BEF29625; Thu, 24 Oct 2013 16:34:19 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 16:34:19 +0200
From: Christer Holmberg 
To: Emil Ivov 
Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: AQHO0MU7ZifHbTiyi0uI+R2fzkRZsZoD6XuQ
Date: Thu, 24 Oct 2013 14:34:17 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se> <5267E052.6020401@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se> <52692E69.8020109@jitsi.org>
In-Reply-To: <52692E69.8020109@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje5r/cwgg7YLQhZrdk5gsWi542Ux dfljFovJn/pYHVg8liz5yeTx/02gx4f5X9g9Ws71sgewRHHZpKTmZJalFunbJXBl/N+wm73g NWvFs38fWBoYT7B0MXJySAiYSDS3TmaGsMUkLtxbzwZiCwkcZpT425XXxcgFZC9hlHi/cwpj FyMHB5uAhUT3P22QGhEBeYnutkVMIDXMAj2MEot/NIANEhZIlHjy8y8rRFGSxPvF39khbCOJ d6dWgC1mEVCVOLppG9gyXgFfiSuHp7NCLFvHKvH4xioWkGWcApoSn56qgtQwAh33/dQaJhCb WUBc4taT+UwQRwtILNlzHuoBUYmXj/+xQtiKElenL4eq15FYsPsTG4StLbFs4WtmiL2CEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypG9tzEzJz0cqNNjMA4Orjlt+oOxjvnRA4xSnOwKInz fnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcQUfZ9DaK/cvX3e+zvL0iUw1b/Yy16D1 znNWci8/LMWgvvhhjdyrD6F32NzjBHZOatS8OPf0P/elJ+dZGH57cV8+u33tmVdz388+zrJs weE7LvXRk8SMw68d4lp1XNwt6oKe1LyK/J82rLdLXm+L1v1zUVxVTn51SFqtvdGSZ21NTz+y sPPv2q3EUpyRaKjFXFScCAD271PccQIAAA==
Cc: 'mmusic' 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Thu, 24 Oct 2013 14:34:33 -0000

Hi,

>> We have to remember, though, that a trickled candidate is not a new=20
>> candidate "type". The candidate types you trickle are the same types=20
>> you send in Offer/Answer - tickle is simply an alternative candidate=20
>> transport mechanism.
>
> Yes, that's right. I am not sure why you are saying it though.

Because when you say:

	"we treat trickle candidates in the same way as peer-reflexive candidates"=
=20

...it sounds like a trickle candidate is a new type of candidate (similar t=
o peer-reflexive candidate), which is not true.


You should say:

	"We treat candidates that were provided using the trickle ICE mechanism in=
 the same way as peer-reflexive candidates"

:)

Regards,

Christer



From jonathan@vidyo.com  Thu Oct 24 08:38:24 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 A12A911E8342 for ; Thu, 24 Oct 2013 08:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.809
X-Spam-Level: 
X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.171,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrDUedDRnzNx for ; Thu, 24 Oct 2013 08:38:02 -0700 (PDT)
Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id E482311E8355 for ; Thu, 24 Oct 2013 08:36:59 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/24/2013 11:36:54 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-104/SG:2 10/24/2013 11:36:01 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.884189 p=-0.971455 Source White
X-Signature-Violations: 0-0-0-5491-c
X-Note-419: 15.6002 ms. Fail:0 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:0-1349/SG:1 10/24/2013 11:36:52 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 42695020; Thu, 24 Oct 2013 11:36:54 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 24 Oct 2013 10:36:53 -0500
From: Jonathan Lennox 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01
Thread-Index: AQHO0MU7ZifHbTiyi0uI+R2fzkRZsZoD6XuQgABmhoA=
Date: Thu, 24 Oct 2013 15:36:53 +0000
Message-ID: <369B690E-2456-48AD-923E-93B88A620817@vidyo.com>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in>,<5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se> <5267E052.6020401@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se> <52692E69.8020109@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Thu, 24 Oct 2013 15:38:24 -0000

On Oct 24, 2013, at 10:34 AM, Christer Holmberg 
 wrote:

> Hi,
>=20
>>> We have to remember, though, that a trickled candidate is not a new=20
>>> candidate "type". The candidate types you trickle are the same types=20
>>> you send in Offer/Answer - tickle is simply an alternative candidate=20
>>> transport mechanism.
>>=20
>> Yes, that's right. I am not sure why you are saying it though.
>=20
> Because when you say:
>=20
> 	"we treat trickle candidates in the same way as peer-reflexive candidate=
s"=20
>=20
> ...it sounds like a trickle candidate is a new type of candidate (similar=
 to peer-reflexive candidate), which is not true.
>=20
>=20
> You should say:
>=20
> 	"We treat candidates that were provided using the trickle ICE mechanism =
in the same way as peer-reflexive candidates"

There's a problem with this.

RFC 5245 says:

   However, the peer reflexive candidate is not paired with other remote
   candidates.  This is not necessary; a valid pair will be generated
   from it momentarily based on the procedures in Section 7.1.3.2.2.  If
   an agent wishes to pair the peer reflexive candidate with other
   remote candidates besides the one in the valid pair that will be
   generated, the agent MAY generate an updated offer which includes the
   peer reflexive candidate.

In other words, peer-reflexive candidates aren't automatically paired with =
all remote candidates; they're only paired with the remote candidate you we=
re checking when you discovered them, unless you send them in an updated of=
fer.

Candidates provided over Trickle don't have a remote candidate to be automa=
tically paired with, so "treating them like peer-reflexive candidates" does=
n't make much sense.

--=20
Jonathan Lennox
jonathan@vidyo.com=

From pkyzivat@alum.mit.edu  Thu Oct 24 09:13: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 5D58411E83BF for ; Thu, 24 Oct 2013 09:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.3
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APy1hRCGg7kC for ; Thu, 24 Oct 2013 09:13:46 -0700 (PDT)
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 607E911E839E for ; Thu, 24 Oct 2013 09:08:20 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id gz971m0060Fqzac5448KU6; Thu, 24 Oct 2013 16:08:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id h48K1m00K3ZTu2S3U48KWK; Thu, 24 Oct 2013 16:08:19 +0000
Message-ID: <526945F3.1060205@alum.mit.edu>
Date: Thu, 24 Oct 2013 12:08:19 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <00a401cece8b$7b00f780$7102e680$@co.in>		<00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se>	<5266DAB0.7020001@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se>	<5267CA43.8020304@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se>	<5267E052.6020401@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se>	<52692E69.8020109@jitsi.org>	<7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se> <369B690E-2456-48AD-923E-93B88A620817@vidyo.com>
In-Reply-To: <369B690E-2456-48AD-923E-93B88A620817@vidyo.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=1382630899; bh=64Ak7musl6Ust+f0NY2F5jn/TFeKueNlR23UyF5vDTY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ICh5K1eOwU3Lpn3SxLskelmAbQzJ/sOMb62lR9RJZrN9kk+atwK/BD1QtCruphtE6 7DlF2GWeWbMS0XygjxccQ2JC/4YcSiTyQb3MVGObiT04bVz0rIkNsaRbnqCG2t7zrf zj7mUqVL4kUHpvEsyPnyNEXHpEQZge8xbY/dkgjSuv0mnVVX+nWcn4B5zoA7ylQQxE Xp+ch7e0DPi/qg/Yx2UKsyP+TdmRWuApHUNzGRuOJcwN8JbHAzUGuQdafvXYCWSSrx D50rhHwUmb7FNlWv9+TqnxQbVMhhZ+rkqWElNv+SPc47BL9eLmRbML+nZ0sjrAWRJZ F148sq33k5EaA==
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Thu, 24 Oct 2013 16:13:52 -0000

I'm far from an expert on ICE, so maybe this is covered and I just don't 
know it...

ISTM there is a need for some real clarity about the relationship 
between ICE state and SDP O/A state, and if/when pieces of state move or 
are synchronized between them. This isn't clear even for SDP O/A on its 
own, but with ICE, and now with trickle ICE, and with Partial O/A it is 
becoming even more of a problem.

RFC 6337 started to clarify SDP O/A itself, but it didn't deal with the 
sorts of issues that are coming up in this discussion.

	Thanks,
	Paul

On 10/24/13 11:36 AM, Jonathan Lennox wrote:
>
> On Oct 24, 2013, at 10:34 AM, Christer Holmberg 
>   wrote:
>
>> Hi,
>>
>>>> We have to remember, though, that a trickled candidate is not a new
>>>> candidate "type". The candidate types you trickle are the same types
>>>> you send in Offer/Answer - tickle is simply an alternative candidate
>>>> transport mechanism.
>>>
>>> Yes, that's right. I am not sure why you are saying it though.
>>
>> Because when you say:
>>
>> 	"we treat trickle candidates in the same way as peer-reflexive candidates"
>>
>> ...it sounds like a trickle candidate is a new type of candidate (similar to peer-reflexive candidate), which is not true.
>>
>>
>> You should say:
>>
>> 	"We treat candidates that were provided using the trickle ICE mechanism in the same way as peer-reflexive candidates"
>
> There's a problem with this.
>
> RFC 5245 says:
>
>     However, the peer reflexive candidate is not paired with other remote
>     candidates.  This is not necessary; a valid pair will be generated
>     from it momentarily based on the procedures in Section 7.1.3.2.2.  If
>     an agent wishes to pair the peer reflexive candidate with other
>     remote candidates besides the one in the valid pair that will be
>     generated, the agent MAY generate an updated offer which includes the
>     peer reflexive candidate.
>
> In other words, peer-reflexive candidates aren't automatically paired with all remote candidates; they're only paired with the remote candidate you were checking when you discovered them, unless you send them in an updated offer.
>
> Candidates provided over Trickle don't have a remote candidate to be automatically paired with, so "treating them like peer-reflexive candidates" doesn't make much sense.
>


From emcho@sip-communicator.org  Thu Oct 24 09:31: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 7ED3511E81B2 for ; Thu, 24 Oct 2013 09:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.735
X-Spam-Level: 
X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=0.242,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCObOiPmZIGo for ; Thu, 24 Oct 2013 09:31:50 -0700 (PDT)
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9564B11E835D for ; Thu, 24 Oct 2013 09:31:43 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id fa1so884437pad.13 for ; Thu, 24 Oct 2013 09:31:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kcTPnRrxelcBtlW9v/ZYaOZYXSHmrecW0eOAw28+Pmw=; b=mfn2EoryIfwja3ToVX/haQj/U0FcZx5e1S2XPUabY/k8CvIohiKkNkjgIBzXHf9dqt uxIiiSvTYXZdScFSYZ9ukNUNelTtR530haVKsqO4o7owVAIiy0hamM2/Ut+Nu++UivkL s1Zhl/RDD42ece3yb/2C6sDvhxnkXtgq3ICLDToFcTNqvyDkXs7mvZLkWsuRYUUdierS +IKE7s2nJXw4l5aNf0gP9ysz7RTSBdpnBScC4nSNbXXFc5CKU5dNCQn/SWSeZEfHWjuA cjeUWKVDGvphYizB5dIFKUeqakalvXrmMR0VKZm3TskfSxl7U7+oDMNFoGt76ms8A9QC fxSg==
X-Gm-Message-State: ALoCoQlOMEdhnDgrEL9Ugivxxcd1zRbUJVSJrWcNLe/vXK5uUB2f5Nc2f4CbKAETbT6P/SHgBc21
X-Received: by 10.68.253.67 with SMTP id zy3mr3668299pbc.137.1382632303096; Thu, 24 Oct 2013 09:31:43 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [2607:f8b0:400e:c01::235]) by mx.google.com with ESMTPSA id v4sm3646535pbq.31.2013.10.24.09.31.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Oct 2013 09:31:42 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up7so2317975pbc.26 for ; Thu, 24 Oct 2013 09:31:42 -0700 (PDT)
X-Received: by 10.66.216.129 with SMTP id oq1mr4149375pac.75.1382632302619; Thu, 24 Oct 2013 09:31:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.191.163 with HTTP; Thu, 24 Oct 2013 09:31:21 -0700 (PDT)
In-Reply-To: <369B690E-2456-48AD-923E-93B88A620817@vidyo.com>
References: <00a401cece8b$7b00f780$7102e680$@co.in>  <00ce01cecf48$6c0b5500$4421ff00$@co.in> <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se> <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se> <5267E052.6020401@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se> <52692E69.8020109@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se> <369B690E-2456-48AD-923E-93B88A620817@vidyo.com>
From: Emil Ivov 
Date: Thu, 24 Oct 2013 18:31:21 +0200
Message-ID: 
To: Jonathan Lennox 
Content-Type: text/plain; charset=ISO-8859-1
Cc: mmusic , Christer Holmberg 
Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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: Thu, 24 Oct 2013 16:31:58 -0000

On Thu, Oct 24, 2013 at 5:36 PM, Jonathan Lennox  wrote:
>
> On Oct 24, 2013, at 10:34 AM, Christer Holmberg 
>  wrote:
>
>> Hi,
>>
>>>> We have to remember, though, that a trickled candidate is not a new
>>>> candidate "type". The candidate types you trickle are the same types
>>>> you send in Offer/Answer - tickle is simply an alternative candidate
>>>> transport mechanism.
>>>
>>> Yes, that's right. I am not sure why you are saying it though.
>>
>> Because when you say:
>>
>>       "we treat trickle candidates in the same way as peer-reflexive candidates"
>>
>> ...it sounds like a trickle candidate is a new type of candidate (similar to peer-reflexive candidate), which is not true.
>>
>>
>> You should say:
>>
>>       "We treat candidates that were provided using the trickle ICE mechanism in the same way as peer-reflexive candidates"
>
> There's a problem with this.
>
> RFC 5245 says:
>
>    However, the peer reflexive candidate is not paired with other remote
>    candidates.  This is not necessary; a valid pair will be generated
>    from it momentarily based on the procedures in Section 7.1.3.2.2.  If
>    an agent wishes to pair the peer reflexive candidate with other
>    remote candidates besides the one in the valid pair that will be
>    generated, the agent MAY generate an updated offer which includes the
>    peer reflexive candidate.
>
> In other words, peer-reflexive candidates aren't automatically paired with all remote candidates; they're only paired with the remote candidate you were checking when you discovered them, unless you send them in an updated offer.
>
> Candidates provided over Trickle don't have a remote candidate to be automatically paired with, so "treating them like peer-reflexive candidates" doesn't make much sense.

No it doesn't. The idea is that "trickled candidates" being exchanged,
checked and selected entirely outside the context of Offer/Answer is
not a problem because we already have this with "peer-reflexive
candidates".

Trickled candidates obviously do need specific handling within the
*ice agents*, which is one of the reasons for the existence of the
trickle ICE drafts.

Cheers,
Emil

--
https://jitsi.org

From ted.ietf@gmail.com  Thu Oct 24 16:53:12 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 354DE11E8276 for ; Thu, 24 Oct 2013 16:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level: 
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aUwbW3f0bZr for ; Thu, 24 Oct 2013 16:53:11 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF8BD11E821F for ; Thu, 24 Oct 2013 16:53:09 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hn9so316846wib.5 for ; Thu, 24 Oct 2013 16:53:09 -0700 (PDT)
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=XD+XN5aN8l99As9LJW5CeIZ/UUmvIq+433gXD6sWsvo=; b=Wg7J/6ErAssOMx8irc5yjnhEQLHMbDZmaM1+lDN5X4NTKKKGiLWDMkqIsWfIlgP204 vT1IV7d1yigxwJwg9Sn9YtcvJQNwKJ0piIn/ezAghiMW/Nlwj9EJucA5PM29lZXnUXzx SNVm7asWp7sZu6EdGygY+zTQoTCpnhmbhaB/utlL8COpR/UGhPssoFLCCPjKsQIb5XGO wDVTU3Ka6QLDaV/uk529sZI3i2CMJtC++terpKqT8jGW3KoWnScCJgPwgXGX+vcbQdLk jL9MBFP4GmZx0vvNOHS+NR7357blaIKmyNMcseeXo0+RpS69gn3z/NBl0+ESf13RfKVw Cdxg==
MIME-Version: 1.0
X-Received: by 10.194.219.70 with SMTP id pm6mr4695454wjc.47.1382658789050; Thu, 24 Oct 2013 16:53:09 -0700 (PDT)
Received: by 10.227.204.200 with HTTP; Thu, 24 Oct 2013 16:53:08 -0700 (PDT)
In-Reply-To: <526878E0.4090501@cisco.com>
References:   <7594FB04B1934943A5C02806D1A2204B1C4EE3AE@ESESSMB209.ericsson.se> <526878E0.4090501@cisco.com>
Date: Thu, 24 Oct 2013 16:53:08 -0700
Message-ID: 
From: Ted Hardie 
To: Flemming Andreasen 
Content-Type: multipart/alternative; boundary=001a11c1b31cf78e6c04e9855574
Cc: "Cullen Jennings \(fluffy\)" , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] Agenda and conflict with PerPass
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, 24 Oct 2013 23:53:12 -0000

--001a11c1b31cf78e6c04e9855574
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 23, 2013 at 6:33 PM, Flemming Andreasen wro=
te:

>  Seperately, the chairs have received a request to move the Wednesday
> MMUSIC session as follows:
>
> 	Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose, ccamp,=
 l3vpn, homenet and tsvarea.  There are no listed conflicts that would resu=
lt from this change
>
> This would seem to resolve conflicts for some of the WG participants on
> Wednesday, but the question is if it introduces new problems. If anybody
> has any concerns with such a move, please let us know ASAP. It would be
> good to hear from those in favor too.
>
>
TSVAREA will have some discussion of QUIC.  That's not a hard-stop style
conflict for me, but I'd like to be there.  If we can look at their agenda
and avoid that slot for WebRTC-related topics, that would be good enough
for me.

Ted



> Thanks
>
> -- Ari & Flemming (MMUSIC co-chairs)
>
>
> On 10/23/13 4:37 PM, Christer Holmberg wrote:
>
>  Hi,
>
>
>
> I requested BUNDLE to be handled on Wednesday, due to the ECRIT conflict
> on monday (there are some topics I cover in ECRIT). However, ECRIT has no=
t
> published their agenda yet, so I don't know what/when will be discussed.
>
>
>
> But, if peole can't attend the MMUSIC session on Wednesday, we'll probabl=
y
> have to switch. Because, at the end of the day, my hope is to actually
> close some BUNDLE issues.
>
>
>
> I understand Adam is also interested in PerPass, which means the POF/PAN
> stuff would have to be switched.
>
>
>
> Regards,
>
>
>
> Christer
>
>
> ------------------------------
> *From:* mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of
> Mary Barnes [mary.ietf.barnes@gmail.com]
> *Sent:* Wednesday, 23 October 2013 9:30 PM
> *To:* Cullen Jennings (fluffy)
> *Cc:* Flemming Andreasen (fandreas); Ari Ker=E4nen; mmusic WG
> *Subject:* Re: [MMUSIC] Agenda and conflict with PerPass
>
>  I thought of that too as I think PerPass is of broad interest, but it
> looked to me that there just isn't enough to fit all the RTCWEB topics in=
to
> one slot.  I'm wondering though since I haven't heard anything from the
> ADs, if we couldn't use the extra time at the end of DISPATCH on Tuesday
> for some of these topics?
>
>  Mary.
>
>
> On Wed, Oct 23, 2013 at 1:17 PM, Cullen Jennings (fluffy) <
> fluffy@cisco.com> wrote:
>
>>
>> I will need to be at the PerPass meeting which conflicts with the
>> Wednesday mmusic session but I will be at the monday session. I suspect
>> that I am not the only person with this conflict.
>>
>> Anything that can be done to push the more controversial WebRTC related
>> items towards monday would be much appreciated.
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>

--001a11c1b31cf78e6c04e9855574
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Oct 23, 2013 at 6:33 PM, Flemming Andreasen <fan=
dreas@cisco.com> wrote:



 =20
   =20
 =20
  

    Seperately, the chairs have received a request to move the Wednesday
    MMUSIC session as follows:

    
	Move MMUSIC to Thursday at 0900 - 1130 against: dime, lisp, jose,=
 ccamp, l3vpn, homenet and tsvarea.  There are no listed conflicts that wou=
ld result from this change

    This would seem to resolve conflicts for some of the WG participants
    on Wednesday, but the question is if it introduces new problems. If
    anybody has any concerns with such a move, please let us know ASAP.
    It would be good to hear from those in favor too. 

    

TSVAREA will have some discu=
ssion of QUIC.=A0 That's not a hard-stop style conflict for me, but I&#=
39;d like to be there.=A0 If we can look at their agenda and avoid that slo=
t for WebRTC-related topics, that would be good enough for me.


Ted

=A0

    Thanks 

    

    -- Ari & Flemming (MMUSIC co-chairs)


    

    
On 10/23/13 4:37 PM, Christer Holmberg
      wrote:

    

    

     =20
     =20
      

        
Hi,

        
=A0

        
I requested BUNDLE to be handled on Wednesday, due to the
          ECRIT conflict on monday (there are some topics I cover in
          ECRIT). However, ECRIT has not published their agenda yet, so
          I don't know what/when will be discussed.

        
=A0

        
But, if peole can't attend the MMUSIC=A0session on Wednesday=
,
          we'll probably have to switch. Because, at the end of the day=
,
          my hope is to actually close some BUNDLE=A0issues.

        
=A0

        
I understand Adam is also interested in PerPass, which means
          the POF/PAN stuff would have to be switched.

        
=A0

        
Regards,

        
=A0

        
Christer

        
=A0

        

        
From:
            mm=
usic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf
            of Mary Barnes [mary.ietf.barnes@gmail.com]

            Sent: Wednesday, 23 October 2013 9:30 PM

            To: Cullen Jennings (fluffy)

            Cc: Flemming Andreasen (fandreas); Ari Ker=E4nen;
            mmusic WG

            Subject: Re: [MMUSIC] Agenda and conflict with
            PerPass

          

        

        

          
I thought of that too as I think PerPass is of
            broad interest, but it looked to me that there just isn't
            enough to fit all the RTCWEB topics into one slot. =A0I'm
            wondering though since I haven't heard anything from the
            ADs, if we couldn't use the extra time at the end of
            DISPATCH on Tuesday for some of these topics? =A0
            


            

            
Mary.=A0

          

          


            

            
On Wed, Oct 23, 2013 at 1:17 PM,
              Cullen Jennings (fluffy)
              <fluffy@cisco.com>
              wrote:

              

                

                I will need to be at the PerPass meeting which conflicts
                with the Wednesday mmusic session but I will be at the
                monday session. I suspect that I am not the only person
                with this conflict.

                

                Anything that can be done to push the more controversial
                WebRTC related items towards monday would be much
                appreciated.

                

                

                

                

                _______________________________________________

                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





--001a11c1b31cf78e6c04e9855574--

From pkyzivat@alum.mit.edu  Sun Oct 27 11:35:21 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 4A15D11E8153 for ; Sun, 27 Oct 2013 11:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.347
X-Spam-Level: 
X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[AWL=-0.416,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGT+Rr5ev0oT for ; Sun, 27 Oct 2013 11:35:15 -0700 (PDT)
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 6B47D11E81A1 for ; Sun, 27 Oct 2013 11:35:10 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id iJQk1m0030ldTLk54JbAhJ; Sun, 27 Oct 2013 18:35:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id iJb91m0083ZTu2S01Jb9B0; Sun, 27 Oct 2013 18:35:09 +0000
Message-ID: <526D5CDD.40805@alum.mit.edu>
Date: Sun, 27 Oct 2013 14:35:09 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: IETF MMUSIC WG 
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=1382898910; bh=fLxnSeoj+emv/3REpeRcWC0CH1Q2YmFzsyyA2SkwFJQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ppiheScpt5BQWRubyeR15N53wOL4GE9dyV0FqYnsPstw4aTAtoeuiEdfD5KQy4SyC nah3OnRQS0q7ljDePTuCJpet4V0cl+m2g6W/QArbxZfhIoUHchW2MexC553EI2QEqP fDWe0PabJ8ga+HJFcdps/Rh/RcDUNqzn3/B+4MoKOdaXfDIV7gX72sGbE1J2N5dFQc pJ9xEDdfM1IFw2I8QELlEJ95T4/VRaURrUDjcP9tUszAbdbJ+w3wcnzRvtGpt1Y9t6 bS2gwbh2QL7/lws4NmI7dIPUZSn3FeXsK3vPnL4472goDDUXH9ih8WLMOPpNZYl5RT l8DviejQIm63g==
Cc: Jonathan Lennox 
Subject: [MMUSIC] comments on draft-even-mmusic-application-token-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: Sun, 27 Oct 2013 18:35:21 -0000

Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it 
looks good to me.

Many examples use a=appid and a=recv-appid without the colon.

Section 3.1.3:

       appid-attribute = "recv-appID:" token

       ; The base definition of "attribute" is in [RFC4566].

       ; (It is the content of "a=" lines.)

The comments are spurious here - there is no attribute.

ISTM it would be helpful to have an explicit specification of how this 
relates to RTP. IIUC, its something like the following:

- an RTP session MAY have one or more appid tokens
- at any point in time each appid token maps to at most
   one stream (SSRC) within the session.
- *new* appid:ssrc mappings MAY be initialized via SDP
- new appid:ssrc mappings MAY be initialized via receipt
   of the new RTPC SDES message or header extension
- existing appid:ssrc mappings MAY be updated via
   receipt of the new RTCP SDES message or header extension.

I'm not sure about what is supposed to happen if a new O/A defines a 
mapping in conflict with an existing one. I *think* it probably is to be 
ignored.

	Thanks,
	Paul

From martin.thomson@gmail.com  Sun Oct 27 13:59: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 A4DFE21E805F for ; Sun, 27 Oct 2013 13:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level: 
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OoalHuADb7P for ; Sun, 27 Oct 2013 13:59:55 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id BB15311E82AA for ; Sun, 27 Oct 2013 13:59:54 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id b13so5705436wgh.3 for ; Sun, 27 Oct 2013 13:59:48 -0700 (PDT)
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=tdlnx3yebf7j6s7b8+qzfQILu5R/8j480DvRNMxFmL8=; b=t20rfe4w6Zm21kIfKKR55OZXmmVEVVCQqipKADYe/sL+QGITzWhr7QNWKE6QwZUK4U HCuOkHp4CCuzTDLmgfmcAAM+sNnsMDC19i/9AqTzNloig3FI+PT9AIP6KJ58rAb1De40 ndYYOnwsJvUmFv6IcflEqifPt7X80UqBq1I/0lm2sdb6YDGlIgqj0UW4Qysb0YOHD784 xPXMrPOTnXiLBb/ENo5+QMZcFvQp75ZvH2VrYkstBtYqd79snA2KfS37VgZWCNSmIT3K f5YvAgYuNzRWCJtdy8/rHN1x2ZubKS4MaKWR2VEcQnRiFr5N2mAFMNpLGdjBGsgHzUJz mtHg==
MIME-Version: 1.0
X-Received: by 10.180.37.114 with SMTP id x18mr531036wij.64.1382907587945; Sun, 27 Oct 2013 13:59:47 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Sun, 27 Oct 2013 13:59:47 -0700 (PDT)
In-Reply-To: <526D5CDD.40805@alum.mit.edu>
References: <526D5CDD.40805@alum.mit.edu>
Date: Sun, 27 Oct 2013 13:59:47 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Cc: Jonathan Lennox , IETF MMUSIC WG 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Sun, 27 Oct 2013 20:59:56 -0000

In addition to absent colons, the examples use a variety of uppercase
and lowercase characters.  Consistency would be helpful, unless the
intent is to highlight the fact that ABNF permits these to be in mixed
case.  (RFC 4566 is silent on the subject, so I assume that a=appid is
equivalent to a=ApPId, following RFC 5234; I'd rather that weren't the
case, but that seems to be the intent at least).

I'm not sure about the assertion regarding 1-1 correspondence between
appid and SSRC.  Putting the fact that SSRC can change aside, I
believe that the intent is to label the source, which can manifest as
multiple SSRCs.

Editorial: This document needs a serious proofread.  The spelling
seems right, but I'm continually being distracted by poor grammar as I
read through.  Doublespacing all the examples is annoying too.

On 27 October 2013 11:35, Paul Kyzivat  wrote:
> Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it looks
> good to me.
>
> Many examples use a=appid and a=recv-appid without the colon.
>
> Section 3.1.3:
>
>       appid-attribute = "recv-appID:" token
>
>       ; The base definition of "attribute" is in [RFC4566].
>
>       ; (It is the content of "a=" lines.)
>
> The comments are spurious here - there is no attribute.
>
> ISTM it would be helpful to have an explicit specification of how this
> relates to RTP. IIUC, its something like the following:
>
> - an RTP session MAY have one or more appid tokens
> - at any point in time each appid token maps to at most
>   one stream (SSRC) within the session.
> - *new* appid:ssrc mappings MAY be initialized via SDP
> - new appid:ssrc mappings MAY be initialized via receipt
>   of the new RTPC SDES message or header extension
> - existing appid:ssrc mappings MAY be updated via
>   receipt of the new RTCP SDES message or header extension.
>
> I'm not sure about what is supposed to happen if a new O/A defines a mapping
> in conflict with an existing one. I *think* it probably is to be ignored.
>
>         Thanks,
>         Paul
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From christer.holmberg@ericsson.com  Sun Oct 27 14:04: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 B34B311E82B4 for ; Sun, 27 Oct 2013 14:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.563
X-Spam-Level: 
X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=0.686,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzXdjlUyItUK for ; Sun, 27 Oct 2013 14:04:02 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8C11E81B3 for ; Sun, 27 Oct 2013 14:04:00 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-e0-526d7fc0b068
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4B.46.03802.0CF7D625; Sun, 27 Oct 2013 22:04:00 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Sun, 27 Oct 2013 22:03:59 +0100
From: Christer Holmberg 
To: Bo Burman , Jonathan Lennox 
Thread-Topic: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnwDfMHDAAAAR4DA=
Date: Sun, 27 Oct 2013 21:03:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6B+twgg9cLRCz2Lz7PbDF1+WMW ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJWxo2Uhc8Eur4rZL08yNzB22XQxcnJICJhI HN70ig3CFpO4cG89kM3FISRwiFFi1qYzYAkhgSWMEs1dFl2MHBxsAhYS3f+0QUwRAR+Jg/vS QCqYBWQkZpxtZAJpFRZYxiix7nQzC4gjIrCcUeLqgd+sIFUiAlYSq/bOAJvJIqAq8fzvfkYQ m1fAV+Lf+elMELv8JG5c+sAOYjMCHfT91BomiA3iEh8OXmeGOFRAYsme81C2qMTLx/9YIWwl iUW3P0PV60ncmDqFDcLWlli28DUzxC5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25i Zk56udEmRmAsHNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAqP9tLh/nVD8lc4uX0i9n3t7y6jbHPofnsidPTlO3/nfIsMQhm0tYfLla18GWybt/SUvH N554E+i4WXaS1Oyp5/O/3l6zNudGrNotvRdyUl/3NZ6qnDz9w+HJkb9NU7UzFp9ccXPdyhXV 7Spd57aqSHDqiM5pu/9k/c/um85r3q9IM3iQ2+y0aLkSS3FGoqEWc1FxIgBKlEqFUwIAAA==
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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, 27 Oct 2013 21:04:08 -0000

This time in non-HTML format.

L=E4hett=E4j=E4: Christer Holmberg=20
L=E4hetetty: 27. lokakuuta 2013 23:03
Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
Kopio: mmusic
Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage =
[WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec config=
uration)]

Hi,

It would be really great if those who have an opinion on this would indicat=
e whether they are ok with the approach below. Then we can focus on where t=
o document it :)

Regards,

Christer

L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P=
uolesta Christer Holmberg
L=E4hetetty: 23. lokakuuta 2013 13:37
Vastaanottaja: Bo Burman; Jonathan Lennox
Kopio: mmusic
Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS=
: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configurat=
ion)]

Hi,

Below is a copy of the current text in my Vancouver slide regarding the cri=
teria for PT value re-usage in multiple m- lines within a BUNDLE group.

It is based on the ideas provided by Jonathan L and Bo B.

As you can see, apart from the rtpmap and fmtp attributes, it is not possib=
le to define an exclusive list of attributes that must be identical. Such l=
ists may also be codec dependent. Instead, the text talks more generally ab=
out memory and buffer sizes.


> REQUIREMENTS
- Decoder agnostic
> It shall be possible to switch decoders between media flows using the sam=
e PT value
- Codec agnostic=20
> The criteria shall be applicable to any codec
> CRITERIA
- SDP rtpmap and fmtp attribute values must be equal (order of attribute pa=
rameters not significant)
> All parameters must be included
- Explictily
- Implicitly, if a default value is defined for the parameter=20
> Parameters not included are assigned their default values (if defined)
- Decoder maximum memory and buffer sizes shall be assumed to match

Regards,

Christer




From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Christer Holmberg
Sent: 16. lokakuuta 2013 12:12
To: Bo Burman; Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi Bo,

Thanks for your input!

I'd ask anyone who might have an opinion about this to take a look at the p=
roposal, comment on the list if needed, and hopefully we can agree on way f=
orward in Vancouver (or, even earlier :)

Regards,

Christer

From: Bo Burman=20
Sent: 16. lokakuuta 2013 11:44
To: Christer Holmberg; Jonathan Lennox
Cc: mmusic
Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

I agree with Jonathan that in order to make two PT values "equal", their rt=
pmap and fmtp lines must be equal, as a start.

I don't think there is any "correct" criterion that can be used to judge PT=
 for equality, but we just have to decide on a "reasonable" one that is as =
simple as possible without causing any major problems.

I have assumed a conceptual equality criterion where PT value A should be c=
onsidered equal to another PT value B if an RTP stream with PT A can be fed=
 into a decoder stack configured with PT B, and vice versa, without causing=
 either decoder stack to "break".

I don't think we should require the fmtp lines are textually equal, but onl=
y that the same parameters are present and have the same values. The order =
of the parameters on the fmtp line does not matter. There is also the case =
when a parameter is specified with the default value for one PT and omitted=
 for the other. To identify those as equal, which they semantically are, wo=
uld require an "equality parser" to know every default value of every fmtp =
parameter for all codecs. This seems unreasonable.

Regarding Jonathan's question on H.264 sprop-., I guess they don't strictly=
 need to be equal to make the PTs equal, but they may have to be. They effe=
ctively configure the decoder in some way and if there is a mismatch, the d=
ecoding process will likely break; like mis-interpretations or buffer overf=
lows. On the other hand, some sprop-. can be updated by in-band information=
, overriding what is specified on the fmtp line, and in this case the fmtp =
line sprop-. information is obsolete. Requiring that all fmtp of the line i=
s equal however makes a simple rule, which should be preferable and I don't=
 think it is too restrictive or excessive.

However, if the potentially equal PT values are defined as part of differen=
t media descriptions, other media level attributes also contribute to the d=
ecoder stack configuration. Some attributes, like maxptime, can clearly cau=
se problems (in this case buffer overflow) if it differs. Others, like ptim=
e, framerate and imageattr are more of a receiver preference within a more =
formal "conformance point" and would not "break" a decoder stack if they di=
ffer.

I agree it can be a good idea to add some text into the mux-attributes draf=
t about attributes that have to be the same to consider two PT in different=
 media descriptions to be "equal", of course given that rtpmap and fmtp are=
 also equal.

/Bo

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Christer Holmberg
Sent: den 11 september 2013 09:12
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

It would be so easy if we could define the PT mappings on the SDP session l=
evel, and then simply refer to them within the m- lines :)

Regards,

Christer

From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20
Sent: 10. syyskuuta 2013 22:18
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

My strawman proposal at the mic in Berlin was that a codec configuration is=
 defined by the top-level media type of the m=3D line and the content of a =
given PT value's rtpmap and fmtp lines. =A0I.e., the full media type, with =
all its parameters.

The questions I would have to this straw man are:

* Is this excessive? =A0E.g., should items like H.264's sprop- parameters b=
e allowed to differ across m=3D line blocks?

* Is this sufficient? =A0Should other items (sometimes) indexed by PT (e.g.=
, the imageattr, rtcp-fb, or extmap attributes) need to be the same across =
m-lines as well?

My suggestion would be that this work should be folded into the work being =
done in=A0draft-nandakumar-mmusic-sdp-mux-attributes (which really should b=
e integrated with BUNDLE). =A0Currently (I believe) the mux-attributes draf=
t assumes that PTs are unique across m-lines, so this work is going to impl=
y changes to the analysis of a number of attributes in that draft, regardle=
ss. =A0Probably a new category will need to be defined for attributes which=
 have to be consistent per payload type.

On Sep 10, 2013, at 5:56 AM, Christer Holmberg  wrote:

=A0
Hi,
=A0
Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q=
7 in Berlin.
=A0
Questions:
=A0
Q1: "Can we agree that, within a BUNDLE group (including all m- lines assoc=
iated with the group), any given PT value can only be used for a single cod=
ec configuration?"
Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there are=
 opinions that simply referencing RFC 3550 might not be clear enough?"
Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in m=
ultiple RTP m- lines, for the SAME codec configuration?"
=A0
Outcome:
=A0
Q1: Yes
Q2: Yes, Lennox will send suggested text to clarify the term "codec configu=
ration".
Q7: Yes.
=A0
So, again, we need definition text for "codec configuration". Jonathan prom=
ised to submit something, but anyone is of course welcome to do that.
=A0
The other alternative is to not say anything about PT value usages within t=
he scope of BUNDLE, but that is not what the meeting wanted.
=A0
Regards,
=A0
Christer
=A0
=A0
From:=A0mmusic-bounces@ietf.org=A0[mailto:mmusic-bounces@ietf.org]=A0On Beh=
alf Of=A0Christer Holmberg
Sent:=A023. elokuuta 2013 13:53
To:=A0mmusic
Subject:=A0[MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value =
for single codec configuration
=A0
Hi,
=A0
One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7=
 in my slides) was regarding the usage of any given PT value.
=A0
My take of the outcome was that:
=A0
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0We=A0agreed=A0that any given PT value can on=
ly be used for a single codec configuration (Q1)
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0We=A0agreed=A0that we need some definition t=
ext for "codec configuration" (Q2)
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0We=A0agreed=A0that, within a BUNDLE group, a=
ny given PT value can be used in multiple m- lines, as long as it is used f=
or a single codec configuration (Q7).
=A0
Jonathan Lennox promised to suggest some definition text for "codec configu=
ration", so let's wait for that until we go into those discussions.
=A0
But, if you have any issues with the agreements in general, please bring th=
em up :)
=A0
Regards,
=A0
Christer
=A0
=A0
=A0

--
Jonathan Lennox
jonathan@vidyo.com


From christer.holmberg@ericsson.com  Sun Oct 27 14:03: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 4AA6411E82BD for ; Sun, 27 Oct 2013 14:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.556
X-Spam-Level: 
X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.692,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AKFqHK5Ffhm for ; Sun, 27 Oct 2013 14:02:58 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9246F11E82AA for ; Sun, 27 Oct 2013 14:02:56 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-97-526d7f7eada4
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 42.46.03802.E7F7D625; Sun, 27 Oct 2013 22:02:54 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Sun, 27 Oct 2013 22:02:53 +0100
From: Christer Holmberg 
To: Christer Holmberg , Bo Burman , Jonathan Lennox 
Thread-Topic: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnwDfMHDA
Date: Sun, 27 Oct 2013 21:02:52 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F8A5E@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F8A5EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+JvjW5dfW6QwbIVxhb7F59ntpi6/DGL A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4Mq4cP0dU0HXDeaK83c7WBsY+5czdzFyckgI mEjse3gXyhaTuHBvPVsXIxeHkMAhRokJj+6xgiSEBJYwSrROketi5OBgE7CQ6P6nDVIjItDE KLHt1G92kBpmARmJGWcbmUASwgLLGCXWnW5mgahazihx9cBvsEkiAkYSVw9eZwGxWQRUJbq/ 3gbr5hXwlTjSdoQZZIMQkD1vbRhImFPAT2LFid1g1zECXff91BomiGXiEh8OXoe6WkBiyZ7z ULaoxMvH/1ghbCWJRbc/Q9XnS0xadI8RYpWgxMmZT1gmMIrOQjJqFpKyWUjKIOJ6EjemTmGD sLUlli18DVWvKzHj3yEWZPEFjOyrGNlzEzNz0suNNjECI+vglt+qOxjvnBM5xCjNwaIkzvvh rXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaJgRvKdu6xyHTaZethY3W6Zxo/38VFZlxh Co2q3wx1pq+UOffw3kuXNwe/xJmuvHJuZoSMbMivKZuedC3n8CxY0MRV1ySgM22T2p+9f/lu /e96Mquq/7eNxN3mvdx9v57u8/trzKQvbu52sWjpn2lPtMt9vBqPiMmxfbOJe1+q8+Titmt3 mTcqsRRnJBpqMRcVJwIAUrPC03oCAAA=
X-Mailman-Approved-At: Sun, 27 Oct 2013 14:12:27 -0700
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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, 27 Oct 2013 21:03:05 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4F8A5EESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

It would be really great if those who have an opinion on this would indicat=
e whether they are ok with the approach below. Then we can focus on where t=
o document it :)

Regards,

Christer

L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P=
uolesta Christer Holmberg
L=E4hetetty: 23. lokakuuta 2013 13:37
Vastaanottaja: Bo Burman; Jonathan Lennox
Kopio: mmusic
Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS=
: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configurat=
ion)]

Hi,

Below is a copy of the current text in my Vancouver slide regarding the cri=
teria for PT value re-usage in multiple m- lines within a BUNDLE group.

It is based on the ideas provided by Jonathan L and Bo B.

As you can see, apart from the rtpmap and fmtp attributes, it is not possib=
le to define an exclusive list of attributes that must be identical. Such l=
ists may also be codec dependent. Instead, the text talks more generally ab=
out memory and buffer sizes.


>       REQUIREMENTS
-        Decoder agnostic
>          It shall be possible to switch decoders between media flows usin=
g the same PT value
-        Codec agnostic
>          The criteria shall be applicable to any codec
>       CRITERIA
-        SDP rtpmap and fmtp attribute values must be equal (order of attri=
bute parameters not significant)
>          All parameters must be included
-          Explictily
-          Implicitly, if a default value is defined for the parameter
>          Parameters not included are assigned their default values (if de=
fined)
-        Decoder maximum memory and buffer sizes shall be assumed to match

Regards,

Christer




From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 16. lokakuuta 2013 12:12
To: Bo Burman; Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi Bo,

Thanks for your input!

I'd ask anyone who might have an opinion about this to take a look at the p=
roposal, comment on the list if needed, and hopefully we can agree on way f=
orward in Vancouver (or, even earlier :)

Regards,

Christer

From: Bo Burman
Sent: 16. lokakuuta 2013 11:44
To: Christer Holmberg; Jonathan Lennox
Cc: mmusic
Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

I agree with Jonathan that in order to make two PT values "equal", their rt=
pmap and fmtp lines must be equal, as a start.

I don't think there is any "correct" criterion that can be used to judge PT=
 for equality, but we just have to decide on a "reasonable" one that is as =
simple as possible without causing any major problems.

I have assumed a conceptual equality criterion where PT value A should be c=
onsidered equal to another PT value B if an RTP stream with PT A can be fed=
 into a decoder stack configured with PT B, and vice versa, without causing=
 either decoder stack to "break".

I don't think we should require the fmtp lines are textually equal, but onl=
y that the same parameters are present and have the same values. The order =
of the parameters on the fmtp line does not matter. There is also the case =
when a parameter is specified with the default value for one PT and omitted=
 for the other. To identify those as equal, which they semantically are, wo=
uld require an "equality parser" to know every default value of every fmtp =
parameter for all codecs. This seems unreasonable.

Regarding Jonathan's question on H.264 sprop-..., I guess they don't strict=
ly need to be equal to make the PTs equal, but they may have to be. They ef=
fectively configure the decoder in some way and if there is a mismatch, the=
 decoding process will likely break; like mis-interpretations or buffer ove=
rflows. On the other hand, some sprop-... can be updated by in-band informa=
tion, overriding what is specified on the fmtp line, and in this case the f=
mtp line sprop-... information is obsolete. Requiring that all fmtp of the =
line is equal however makes a simple rule, which should be preferable and I=
 don't think it is too restrictive or excessive.

However, if the potentially equal PT values are defined as part of differen=
t media descriptions, other media level attributes also contribute to the d=
ecoder stack configuration. Some attributes, like maxptime, can clearly cau=
se problems (in this case buffer overflow) if it differs. Others, like ptim=
e, framerate and imageattr are more of a receiver preference within a more =
formal "conformance point" and would not "break" a decoder stack if they di=
ffer.

I agree it can be a good idea to add some text into the mux-attributes draf=
t about attributes that have to be the same to consider two PT in different=
 media descriptions to be "equal", of course given that rtpmap and fmtp are=
 also equal.

/Bo

From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: den 11 september 2013 09:12
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

Hi,

It would be so easy if we could define the PT mappings on the SDP session l=
evel, and then simply refer to them within the m- lines :)

Regards,

Christer

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 10. syyskuuta 2013 22:18
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu=
e for single codec configuration

My strawman proposal at the mic in Berlin was that a codec configuration is=
 defined by the top-level media type of the m=3D line and the content of a =
given PT value's rtpmap and fmtp lines.  I.e., the full media type, with al=
l its parameters.

The questions I would have to this straw man are:

* Is this excessive?  E.g., should items like H.264's sprop- parameters be =
allowed to differ across m=3D line blocks?

* Is this sufficient?  Should other items (sometimes) indexed by PT (e.g., =
the imageattr, rtcp-fb, or extmap attributes) need to be the same across m-=
lines as well?

My suggestion would be that this work should be folded into the work being =
done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should be =
integrated with BUNDLE).  Currently (I believe) the mux-attributes draft as=
sumes that PTs are unique across m-lines, so this work is going to imply ch=
anges to the analysis of a number of attributes in that draft, regardless. =
 Probably a new category will need to be defined for attributes which have =
to be consistent per payload type.

On Sep 10, 2013, at 5:56 AM, Christer Holmberg > wrote:


Hi,

Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q=
7 in Berlin.

Questions:

Q1: "Can we agree that, within a BUNDLE group (including all m- lines assoc=
iated with the group), any given PT value can only be used for a single cod=
ec configuration?"
Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there are=
 opinions that simply referencing RFC 3550 might not be clear enough?"
Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in m=
ultiple RTP m- lines, for the SAME codec configuration?"

Outcome:

Q1: Yes
Q2: Yes, Lennox will send suggested text to clarify the term "codec configu=
ration".
Q7: Yes.

So, again, we need definition text for "codec configuration". Jonathan prom=
ised to submit something, but anyone is of course welcome to do that.

The other alternative is to not say anything about PT value usages within t=
he scope of BUNDLE, but that is not what the meeting wanted.

Regards,

Christer


From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 23. elokuuta 2013 13:53
To: mmusic
Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value fo=
r single codec configuration

Hi,

One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7=
 in my slides) was regarding the usage of any given PT value.

My take of the outcome was that:

-          We agreed that any given PT value can only be used for a single =
codec configuration (Q1)
-          We agreed that we need some definition text for "codec configura=
tion" (Q2)
-          We agreed that, within a BUNDLE group, any given PT value can be=
 used in multiple m- lines, as long as it is used for a single codec config=
uration (Q7).

Jonathan Lennox promised to suggest some definition text for "codec configu=
ration", so let's wait for that until we go into those discussions.

But, if you have any issues with the agreements in general, please bring th=
em up :)

Regards,

Christer




--
Jonathan Lennox
jonathan@vidyo.com


--_000_7594FB04B1934943A5C02806D1A2204B1C4F8A5EESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 =
;


It would b=
e really great if those who have an opinion on this would indicate whether =
they are ok with the approach below. Then we can focus on
 where to document it :)


 =
;


Regards,


 =
;


Christer


 =
;






L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Puolesta Christer Holmberg

L=E4hetetty: 23. lokakuuta 2013 13:37

Vastaanottaja: Bo Burman; Jonathan Lennox

Kopio: mmusic

Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usa=
ge [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec con=
figuration)]






 


Hi,


 =
;


Below is a=
 copy of the current text in my Vancouver slide regarding the criteria for =
PT value re-usage in multiple m- lines within a BUNDLE group.


 =
;


It is base=
d on the ideas provided by Jonathan L and Bo B.


 =
;


As you can=
 see, apart from the rtpmap and fmtp attributes, it is not possible to defi=
ne an exclusive list of attributes that must be identical.
 Such lists may also be codec dependent. Instead, the text talks more gener=
ally about memory and buffer sizes.


 =
;


 =
;



›      
REQ=
UIREMENTS



–&nbs=
p;      
Decoder agnostic



›&nbs=
p;        
It=
 shall be possible to switch decoders between media flows using the same PT=
 value



–&nbs=
p;      
Codec agnostic




›&nbs=
p;        
Th=
e criteria shall be applicable to any codec



›      
CRI=
TERIA


–&nbs=
p;      
SD=
P
rtpmap and fmtp attribute values must be equal (order =
of attribute parameters not significant)



›&nbs=
p;        
Al=
l parameters must be included



- &nbs=
p;       
Ex=
plictily



- &nbs=
p;       
Im=
plicitly, if a default value is defined for the parameter




›&nbs=
p;        
Pa=
rameters not included are assigned their default values (if defined)



–&nbs=
p;      
De=
coder maximum memory and buffer sizes shall be assumed to match<=
/span>


 =
;


Regards,


 =
;


Christer


 =
;


 =
;


 =
;


 =
;






From:
mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: 16. lokakuuta 2013 12:12

To: Bo Burman; Jonathan Lennox

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi Bo,


 =
;


Thanks for=
 your input!


 =
;


I’d =
ask anyone who might have an opinion about this to take a look at the propo=
sal, comment on the list if needed, and hopefully we can agree on
 way forward in Vancouver (or, even earlier :)


 =
;


Regards,


 =
;


Christer


 =
;






From: Bo Burman


Sent: 16. lokakuuta 2013 11:44

To: Christer Holmberg; Jonathan Lennox

Cc: mmusic

Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 =
;


I agree wi=
th Jonathan that in order to make two PT values “equal”, their =
rtpmap and fmtp lines must be equal, as a start.


 =
;


I don̵=
7;t think there is any “correct” criterion that can be used to =
judge PT for equality, but we just have to decide on a “reasonable=
221; one that
 is as simple as possible without causing any major problems.


 =
;


I have ass=
umed a conceptual equality criterion where PT value A should be considered =
equal to another PT value B if an RTP stream with PT A can
 be fed into a decoder stack configured with PT B, and vice versa, without =
causing either decoder stack to “break”.


 =
;


I don̵=
7;t think we should require the fmtp lines are textually equal, but only th=
at the same parameters are present and have the same values. The
 order of the parameters on the fmtp line does not matter. There is also th=
e case when a parameter is specified with the default value for one PT and =
omitted for the other. To identify those as equal, which they semantically =
are, would require an “equality
 parser” to know every default value of every fmtp parameter for all =
codecs. This seems unreasonable.


 =
;


Regarding =
Jonathan’s question on H.264 sprop-…, I guess they don’t =
strictly need to be equal to make the PTs equal, but they may have to be. T=
hey
 effectively configure the decoder in some way and if there is a mismatch, =
the decoding process will likely break; like mis-interpretations or buffer =
overflows. On the other hand, some sprop-… can be updated by in-band =
information, overriding what is specified
 on the fmtp line, and in this case the fmtp line sprop-… information=
 is obsolete. Requiring that all fmtp of the line is equal however makes a =
simple rule, which should be preferable and I don’t think it is too r=
estrictive or excessive.


 =
;


However, i=
f the potentially equal PT values are defined as part of different media de=
scriptions, other media level attributes also contribute to
 the decoder stack configuration. Some attributes, like maxptime, can clear=
ly cause problems (in this case buffer overflow) if it differs. Others, lik=
e ptime, framerate and imageattr are more of a receiver preference within a=
 more formal “conformance point”
 and would not “break” a decoder stack if they differ.


 =
;


I agree it=
 can be a good idea to add some text into the mux-attributes draft about at=
tributes that have to be the same to consider two PT in different
 media descriptions to be “equal”, of course given that rtpmap =
and fmtp are also equal.


 =
;


/Bo


 =
;








From:
mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: den 11 september 2013 09:12

To: Jonathan Lennox

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 


Hi,


 =
;


It would b=
e so easy if we could define the PT mappings on the SDP session level, and =
then simply refer to them within the m- lines :)


 =
;


Regards,


 =
;


Christer


 =
;






From: Jonathan Lennox [mailto:jonathan@vidyo.com]


Sent: 10. syyskuuta 2013 22:18

To: Christer Holmberg

Cc: mmusic

Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific =
PT value for single codec configuration






 




My strawman proposal at the mic=
 in Berlin was that a codec configuration is defined by the top-level media=
 type of the m=3D line and the content of a given PT value's rtpmap and fmt=
p lines.  I.e., the full media type, with
 all its parameters.






 






The questions I would have to t=
his straw man are:






 






* Is this excessive?  E.g.=
, should items like H.264's sprop- parameters be allowed to differ across m=
=3D line blocks?






 






* Is this sufficient?  Sho=
uld other items (sometimes) indexed by PT (e.g., the imageattr, rtcp-fb, or=
 extmap attributes) need to be the same across m-lines as well?<=
/span>






 






My suggestion would be that thi=
s work should be folded into the work being done in draft-nandakumar-m=
music-sdp-mux-attributes (which really should be integrated with BUNDLE). &=
nbsp;Currently (I believe) the mux-attributes
 draft assumes that PTs are unique across m-lines, so this work is going to=
 imply changes to the analysis of a number of attributes in that draft, reg=
ardless.  Probably a new category will need to be defined for attribut=
es which have to be consistent per payload
 type.




 






On Sep 10, 2013, at 5:56 AM, Ch=
rister Holmberg <chris=
ter.holmberg@ericsson.com> wrote:




=
 






 






Hi,=







 






Below is t=
he “official” (from the minutes) outcome of questions Q1,Q2 and=
 Q7 in Berlin.






 






Questio=
ns:






 






Q1: “=
;Can we agree that, within a BUNDLE group (including all m- lines associate=
d with the group), any given PT value can only be used for a single
 codec configuration?”<=
/span>






Q2: “=
;If Q1, do we agree that we need EXPLICIT text somewhere*, as there are opi=
nions that simply referencing RFC 3550 might not be clear enough?”






Q7: “=
;Within a BUNDLE group, do we allow the usage of the same PT value in multi=
ple RTP m- lines, for the SAME codec configuration?”






 






Outcome=
:






 






Q1: Yes






Q2: Yes, L=
ennox will send suggested text to clarify the term “codec configurati=
on”.






Q7: Yes.






 






So, again,=
 we need definition text for “codec configuration”. Jonathan pr=
omised to submit something, but anyone is of course welcome to do that.






 






The other =
alternative is to not say anything about PT value usages within the scope o=
f BUNDLE, but that is not what the meeting wanted.






 






Regards,






 






Christer






 






 










From: <=
span style=3D"color:purple">mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
 Behalf Of Christer H=
olmberg

Sent: 23. elokuuta=
 2013 13:53

To: mmusic

Subject: [MMUSIC] =
DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec con=
figuration










 =







Hi,





 =







One of the open issues r=
elated to BUNDLE presented in Berlin (Q1, Q2 and Q7 in my slides) was regar=
ding the usage of any given PT value.






 =







My take of the outcome w=
as that:






 =







-  &n=
bsp;       We agreed that
 any given PT value can only be used for a single codec configuration (Q1)<=
o:p>






-  &n=
bsp;       We agreed that
 we need some definition text for “codec configuration” (Q2)






-  &n=
bsp;       We agreed that,
 within a BUNDLE group, any given PT value can be used in multiple m- lines=
, as long as it is used for a single codec configuration (Q7).






 =







Jonathan Lennox promised=
 to suggest some definition text for “codec configuration”, so =
let’s wait for that until we go into those discussions.






 =







But, if you have any iss=
ues with the agreements in general, please bring them up :)






 =







Regards,






 =







Christer






 






 






 








 






--






Jonathan Lennox

jonathan@vidyo.com






 








--_000_7594FB04B1934943A5C02806D1A2204B1C4F8A5EESESSMB209erics_--

From pkyzivat@alum.mit.edu  Sun Oct 27 15:05: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 905F921E805F for ; Sun, 27 Oct 2013 15:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Level: 
X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=-0.111,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_56=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCkpUkjOqbID for ; Sun, 27 Oct 2013 15:05:12 -0700 (PDT)
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 D8B3A11E82B7 for ; Sun, 27 Oct 2013 15:05:10 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id iMbo1m0070QuhwU5CN5ASH; Sun, 27 Oct 2013 22:05:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id iN591m00n3ZTu2S3NN59u2; Sun, 27 Oct 2013 22:05:10 +0000
Message-ID: <526D8E15.9070800@alum.mit.edu>
Date: Sun, 27 Oct 2013 18:05:09 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Christer.Holmberg@ericsson.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=1382911510; bh=z0bDnOZ/pLbr0UnNk0ivI3LcIwjXhobOdWNoisbHrVI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kieftIbzNmGB8iP8xq8hXBsYTvEeL+IHfHoLb0b3V29X0jqPRvvUJNIvOR+O8X59g FisUbCuCea9XqhrxL7F8A52/faffGau6ILH3McO5QGHDHnM3Izvu/ErJwvHbRX3pm9 1dm7dkrGPUyeEXuxaCsoXcao3Q0JMB2ilQiFNuthdY55F45Wj/u+oiAD5mtlAzeb5y snSOz8+jlQ+8agrwcSbWfg22sDLTXv1xtojiultv3h2bS7rsuRrg1Y4WK0wpJzMWCN 79TGkMX8UGYVy7MhUNtJG/hYHw0tCyk0cHBzAfG3zjOciSh8zkDwV3cxZTXSQKRZiM C4q9edb+OvaVA==
Cc: IETF MMUSIC WG 
Subject: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05
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, 27 Oct 2013 22:05:49 -0000

I did a fairly careful read of this version.
The good news is that it keeps improving.
But I still found a number of things that I would like to see improved:

Regarding rtcp-mux:

The definition of Bundled media in section 2 implies that rtcp-mux is 
optional, but must be the same for all m-lines in the bundle.

Section 6.2.3 says m-lines in a bundle MUST have the rtcp-mux attribute.

Section 6.2.4 implies the use of the rtcp attribute is optional, but 
must be the same in all m-lines in the bundle.

IIRC there was discussion of what the rtcp attribute should be if 
rtcp-mux is in use. Either it shouldn't be used, or it should be the 
same port as for the rtp, or it doesn't matter. Seems like it would be 
best to say what to use in this case.

Section 6.2.6:

I'm not sure, but ISTM unique crypto attributes should be used for 
m-lines that have unique addresses, and should have identical values for 
m-lines that have identical addresses.

Section 6.4.1:

You talk about a "shared address" here and in later sections. But I 
can't find a statement anywhere that there can only be one shared 
address per bundle group. You might want to put this in the terminology 
section.

Section 6.4.3 says:

    When an Offerer receives an Answer, in which an offered BUNDLE group
    is accepted, if the Offerer in the associated Offer assigned an
    address (unique or shared), that does not represent the BUNDLE
    address selected for the Offerer, to an "m=" line within the BUNDLE
    group, the Offerer MUST send a subsequent Offer, in which it assigns
    the BUNDLE address selected for the Offerer to each "m=" line within
    the BUNDLE group.  This procedure is referred to as Bundle Address
    Synchronization (BAS), and the Offer is referred to as a BAS Offer.

I tried to parse it below. To do so, I had to move "that does not 
represent the BUNDLE address selected for the Offerer,".

   When an Offerer receives an Answer,
     in which an offered BUNDLE group is accepted,
        if the Offerer in the associated Offer assigned an address
        (unique or shared), to an "m=" line within the BUNDLE group,
           that does not represent the BUNDLE address selected for the
           Offerer,

    the Offerer MUST send a subsequent Offer, in which it assigns
    the BUNDLE address selected for the Offerer to each "m=" line within
    the BUNDLE group.  This procedure is referred to as Bundle Address
    Synchronization (BAS), and the Offer is referred to as a BAS Offer.

Even so, it still doesn't quite make sense to me. The problem is with 
"selected for the Offerer". IIUC it would state that as "selected by the 
Answerer".

And in any case I'm not sure if I then have the intended interpretation.

I *think* the condition you are trying to describe is:

- offer included bundle group
- answer accepted bundle group
- M is the first mid in the bundle group in the answer
- A is the media address of the m-line in the offer that
   has mid M
- some m-line in offered bundle group that was accepted in the answer
   doesn't have media address A

If that is what you are trying to say, then we just have to figure out 
how to say it intelligibly. I think trying to string it out into a 
sentence is not going to work, and so you need to break it down 
something like I did above.

Section 6.5.1

This section is titled "Offerer Bundle Address Selection", and starts out:

    When an Answerer generates an Answer that contains a BUNDLE group,
    the Answer MUST select the Offerer's BUNDLE address.

As I noted earlier, I find this terminology confusing about who is doing 
what. I think it would be clearer to say this as follows:

    6.5.1. Answerer Selection of Offerer's Bundle Address

    When an Answerer generates an Answer that contains a BUNDLE group,
    the Answer MUST select the m-line that will determine the BUNDLE
    address for offerer and answerer.  The first mid value in the SDP
    group:BUNDLE attribute mid list of the Offer represents the m-line
    which the Offerer wishes the Answer to select. (Section 6.4.2.)

    The Answerer SHOULD select the the first mid value from the offer,
    unless the Answerer in the associated Answer will reject the
    "m=" line associated with that mid value, or remove the "m=" line
    from the BUNDLE group.  In such case the Answerer MUST select
    the first unrejected mid value that remains in the SDP group:BUNDLE
    attribute mid list of the Offer.

Section 6.5.4:

What should be done if rejecting the m-line causes the bundle group to 
be empty?

Section 7.2:

    o  The dynamic payload type values used in the "m=" lines MUST NOT
       overlap.

What do you mean by overlap? I thought we were going to allow the same 
PT to be used in multiple bundled m-lines as long as the definition of 
that PT was the same.

Section 8.2:

Shouldn't it be sufficient to supply candidates for one of the m-lines 
that share an address?

	Thanks,
	Paul

From pkyzivat@alum.mit.edu  Sun Oct 27 15:11: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 1DD9611E82C4 for ; Sun, 27 Oct 2013 15:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.353
X-Spam-Level: 
X-Spam-Status: No, score=0.353 tagged_above=-999 required=5 tests=[AWL=-0.410,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3teaEb-jXZ5n for ; Sun, 27 Oct 2013 15:11:50 -0700 (PDT)
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 EB8D911E820F for ; Sun, 27 Oct 2013 15:11:47 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id iN8Y1m0031YDfWL53NBnc4; Sun, 27 Oct 2013 22:11:47 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id iNBn1m0093ZTu2S3gNBnYi; Sun, 27 Oct 2013 22:11:47 +0000
Message-ID: <526D8FA3.1030503@alum.mit.edu>
Date: Sun, 27 Oct 2013 18:11:47 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <526D5CDD.40805@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=1382911907; bh=Ewi8uizB+nlAUNX1SLSn5okZPScVosx1o/S9YYr7B6g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=epxo96E0d8wUoN5/uRBq6Pht7dbS5FB0pDgHeO2M5ve5YpNYOh+nO3VI+7m83Ezui 1VrsUHOsgcXimlzzQotevGKCxWFBW4KkN+QL52AlSB3Qtx6w424gGDIu/2KQ0CFzCZ n9EVD59uOL/PNftVBx2j2PCPwlU6QBKYPB5qdAVudIXP43zpNrW/ZDzvk2OCXc8bo6 7slr1wQoC64w/O3eJskIABNIVgKTOlLfX3vj3q+ZNu5pMJcR3Nv6oRD4/dQyyN1Y7V na581ChuXxLI1ZhyqaDJDuiIihk3aBb0pOTqr66EpPU0hDmFvveGynGYuVaQ8or8a0 6WyLIKM+PKDZQ==
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Sun, 27 Oct 2013 22:11:55 -0000

On 10/27/13 4:59 PM, Martin Thomson wrote:
> In addition to absent colons, the examples use a variety of uppercase
> and lowercase characters.  Consistency would be helpful, unless the
> intent is to highlight the fact that ABNF permits these to be in mixed
> case.  (RFC 4566 is silent on the subject, so I assume that a=appid is
> equivalent to a=ApPId, following RFC 5234; I'd rather that weren't the
> case, but that seems to be the intent at least).
>
> I'm not sure about the assertion regarding 1-1 correspondence between
> appid and SSRC.

Note that I said "at any point in time", and made provision for changing 
the mapping.

Even so, I am also not sure.

> Putting the fact that SSRC can change aside, I
> believe that the intent is to label the source, which can manifest as
> multiple SSRCs.

I *thought* that for instance in case of FEC, the original stream and 
the repair stream would have the same appid. But the example showed 
otherwise.

I'd like the model to be spelled out. Then we wouldn't be wondering.

	Thanks,
	Paul

> Editorial: This document needs a serious proofread.  The spelling
> seems right, but I'm continually being distracted by poor grammar as I
> read through.  Doublespacing all the examples is annoying too.
>
> On 27 October 2013 11:35, Paul Kyzivat  wrote:
>> Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it looks
>> good to me.
>>
>> Many examples use a=appid and a=recv-appid without the colon.
>>
>> Section 3.1.3:
>>
>>        appid-attribute = "recv-appID:" token
>>
>>        ; The base definition of "attribute" is in [RFC4566].
>>
>>        ; (It is the content of "a=" lines.)
>>
>> The comments are spurious here - there is no attribute.
>>
>> ISTM it would be helpful to have an explicit specification of how this
>> relates to RTP. IIUC, its something like the following:
>>
>> - an RTP session MAY have one or more appid tokens
>> - at any point in time each appid token maps to at most
>>    one stream (SSRC) within the session.
>> - *new* appid:ssrc mappings MAY be initialized via SDP
>> - new appid:ssrc mappings MAY be initialized via receipt
>>    of the new RTPC SDES message or header extension
>> - existing appid:ssrc mappings MAY be updated via
>>    receipt of the new RTCP SDES message or header extension.
>>
>> I'm not sure about what is supposed to happen if a new O/A defines a mapping
>> in conflict with an existing one. I *think* it probably is to be ignored.
>>
>>          Thanks,
>>          Paul
>> _______________________________________________
>> 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 martin.thomson@gmail.com  Sun Oct 27 19:46: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 2720611E82EF for ; Sun, 27 Oct 2013 19:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auOYwgBRCDLK for ; Sun, 27 Oct 2013 19:46:27 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 905D611E82EC for ; Sun, 27 Oct 2013 19:46:24 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id ey11so3315930wid.13 for ; Sun, 27 Oct 2013 19:46:23 -0700 (PDT)
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=KnBpBJAanUVRXezVVpci6govzj/F3YWmY+pCDs5ZB/w=; b=yo7jJGwDsAXontkRocSwV7M2xx64pPQvOqDq9tDUcv7b8+taWN5cso3sn2QWRpJP0R YTK5C4qkjt48ag5kmgBViIwFUSc+dB2CPnL4MYqsIF3MT3pPUXQPKIOi3Fe/vmtUlboG twYXvEdtIxmQAM5XO4sSPgl6rYJKUfknuhsNCb63K8PNUduXJctzzW+Adymi9hC/0s9c NudkcFJegzgvLwSrqBzEV3HIyfhDlysqAHyEvte9NP8IlsLHXNyV9JTP4szXjrqng5tr 1sIrAcpTbP7W25SFlXWIAIrc1utfcgEIAinSgn9XEaNBVNmOU8yn0dlwENb3y9GETOmq Y5OA==
MIME-Version: 1.0
X-Received: by 10.194.11.67 with SMTP id o3mr16779717wjb.0.1382928383682; Sun, 27 Oct 2013 19:46:23 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Sun, 27 Oct 2013 19:46:23 -0700 (PDT)
In-Reply-To: <526D8FA3.1030503@alum.mit.edu>
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>
Date: Sun, 27 Oct 2013 19:46:23 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Mon, 28 Oct 2013 02:46:29 -0000

On 27 October 2013 15:11, Paul Kyzivat  wrote:
> I *thought* that for instance in case of FEC, the original stream and the repair stream would have the same appid. But the example showed otherwise.

That's odd.  I'd have thought that too.

> I'd like the model to be spelled out. Then we wouldn't be wondering.

Yep.  Much better.  All it takes is something like 1 appid = 1 media source.

From christer.holmberg@ericsson.com  Mon Oct 28 06:46: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 31ED621F9EFB for ; Mon, 28 Oct 2013 06:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.269
X-Spam-Level: 
X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=0.380,  BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-WnC13UPkf0 for ; Mon, 28 Oct 2013 06:46:11 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 96BBC21F9D1E for ; Mon, 28 Oct 2013 06:46:00 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-8e-526e6a9425e0
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AD.69.16099.49A6E625; Mon, 28 Oct 2013 14:45:56 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 28 Oct 2013 14:45:56 +0100
From: Christer Holmberg 
To: Paul Kyzivat 
Thread-Topic: comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027
Thread-Index: Ac7T4BKr+1XNsrVQRkiwMzYimKZg9Q==
Date: Mon, 28 Oct 2013 13:45:55 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F9341@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvje6UrLwgg7NPNC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj37mLbAXvXSrartxkaWC8Y9rFyMkhIWAi MelIIzuELSZx4d56ti5GLg4hgUOMEve/H4dyljBKdK89A1TFwcEmYCHR/U8bxBQR0JCYtFUN pJdZQEXi1enLrCBhYYFEia6TSSBhEYEkiS2rD7FB2HoSf45vBrNZBFQlZt15BmbzCvhKzNh1 kRXEZgQ64fupNUwQI8UlPhy8zgxxmoDEkj3noWxRiZeP/7FC2EoSjUuesELU60gs2P2JDcLW lli28DUzxHxBiZMzn7BMYBSZhWTsLCQts5C0zELSsoCRZRUje25iZk56ueEmRmC4H9zyW3cH 46lzIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWGLzYp+rYberytrS JXyzz76cLv3i2Syra11/Sv1FHj52XPotf9MJq7CZv/ZJRCev13b3L+uL+DnfSenxyWntv/rW XXzr9WltYmbAjwQP40hJAc+8Bh1l9tDTeQULnpquua6f/+XD6nlsUx6d8e5XX9HOduPBrxWz oq1DtaceL734PZd5s8C5I0osxRmJhlrMRcWJAEtiIedFAgAA
Cc: IETF MMUSIC WG 
Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027
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 Oct 2013 13:46:46 -0000

Hi Paul,

As always, thank You for your detailed review and constructive feedback! :)

Comments inline.

> I did a fairly careful read of this version.
> The good news is that it keeps improving.
> But I still found a number of things that I would like to see improved:
>
> Regarding rtcp-mux:
>
> The definition of Bundled media in section 2 implies that rtcp-mux is opt=
ional, but must be the same for all m-lines in the bundle.
>
> Section 6.2.3 says m-lines in a bundle MUST have the rtcp-mux attribute.
>
> Section 6.2.4 implies the use of the rtcp attribute is optional, but must=
 be the same in all m-lines in the bundle.
>
> IIRC there was discussion of what the rtcp attribute should be if rtcp-mu=
x is in use. Either it shouldn't be used, or it should be the same port as =
for the rtp, or it doesn't matter. Seems like it would be best to say what =
to use in this case.

Yes.

I GUESS we should allow it, at least in the initial Offer, in case the Answ=
erer doesn't support BUNDLE. But, in the BAS Offer I guess we should either=
 say that it is not used, that the value MUST be identical to the RTP port,=
 or that the value doesn't matter.

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

> Section 6.2.6:
>
> I'm not sure, but ISTM unique crypto attributes should be used for m-line=
s that have unique addresses, and should have identical values for m-lines =
that have identical addresses.

I've left section 6.2 untouched on purpose for quite a while, as the SDP at=
tribute impacts on BUNDLE are described in draft-nandakumar-sdp-mux-attribu=
tes. At some point, we'll need to decide whether we are going to move text =
from there into the BUNDLE spec, or whether the BUNDLE spec is only going t=
o reference it.

There has been very little discussion on that draft, so I encourage people =
to take a look and give comments :)

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

> Section 6.4.1:
>
> You talk about a "shared address" here and in later sections. But I can't=
 find a statement anywhere that there can only be one shared address per bu=
ndle group. You might want to put this in the terminology section.

My assumption is that there doesn't have to be only one shared address with=
in a BUNDLE group. And, that is also the reason I separated the "BUNDLE add=
ress" and "shared address" terminology. "BUNDLE address" means the transpor=
t address used for a BUNDLE group, while "shared address" means an address =
shared by multiple m- lines. Of course, when the BAS Offer is sent, the val=
ue of those addresses are the same :)

But, some further clarification text about that is probably useful.

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

> Section 6.4.3 says:
>
>    When an Offerer receives an Answer, in which an offered BUNDLE group
>    is accepted, if the Offerer in the associated Offer assigned an
>    address (unique or shared), that does not represent the BUNDLE
>    address selected for the Offerer, to an "m=3D" line within the BUNDLE
>    group, the Offerer MUST send a subsequent Offer, in which it assigns
>    the BUNDLE address selected for the Offerer to each "m=3D" line within
>    the BUNDLE group.  This procedure is referred to as Bundle Address
>    Synchronization (BAS), and the Offer is referred to as a BAS Offer.
>
> I tried to parse it below. To do so, I had to move "that does not represe=
nt the BUNDLE address selected for the Offerer,".
>
>   When an Offerer receives an Answer,
>     in which an offered BUNDLE group is accepted,
>        if the Offerer in the associated Offer assigned an address
>        (unique or shared), to an "m=3D" line within the BUNDLE group,
>           that does not represent the BUNDLE address selected for the
>           Offerer,
>
>    the Offerer MUST send a subsequent Offer, in which it assigns
>    the BUNDLE address selected for the Offerer to each "m=3D" line within
>    the BUNDLE group.  This procedure is referred to as Bundle Address
>    Synchronization (BAS), and the Offer is referred to as a BAS Offer.
>
> Even so, it still doesn't quite make sense to me. The problem is with "se=
lected for the Offerer". IIUC it would state that as "selected by the Answe=
rer".
>
> And in any case I'm not sure if I then have the intended interpretation.
>
> I *think* the condition you are trying to describe is:
>
> - offer included bundle group
> - answer accepted bundle group
> - M is the first mid in the bundle group in the answer
> - A is the media address of the m-line in the offer that
>   has mid M
> - some m-line in offered bundle group that was accepted in the answer
>   doesn't have media address A
>
> If that is what you are trying to say, then we just have to figure out ho=
w to say it intelligibly. I think trying to string it out into a sentence i=
s not going to work, and so you need to break it down something like I did =
above.

What I am trying to say is: in the Offer, unless the BUNDLE address (determ=
ined by the Answerer) was assigned to each m=3D line in the BUNDLE group, a=
 new Offer must be sent.

Maybe the following text is easier to understand:

	"When an Offerer receives an Answer, in which an offered BUNDLE group is a=
ccepted,
	unless, in the Offer, the BUNDLE address (determined by the Answerer [ref-=
to-section-6.5.1])=20
	was assigned to each "m=3D" line within the BUNDLE group, the Offerer MUST=
 send a=20
	subsequent Offer, in which it assigns the BUNDLE address to each "m=3D" li=
ne  within=20
	the BUNDLE group.  This procedure is referred to as Bundle Address Synchro=
nization=20
	(BAS), and the Offer is referred to as a BAS Offer.

Perhaps it can be even further simplified, but hopefully it is at least eas=
ier to understand now :)

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

> Section 6.5.1
>
> This section is titled "Offerer Bundle Address Selection", and starts out=
:
>
>    When an Answerer generates an Answer that contains a BUNDLE group,
>    the Answer MUST select the Offerer's BUNDLE address.
>
> As I noted earlier, I find this terminology confusing about who is doing =
what. I think it would be clearer to say this as follows:
>
>    6.5.1. Answerer Selection of Offerer's Bundle Address
>
>    When an Answerer generates an Answer that contains a BUNDLE group,
>    the Answer MUST select the m-line that will determine the BUNDLE
>    address for offerer and answerer.  The first mid value in the SDP
>    group:BUNDLE attribute mid list of the Offer represents the m-line
>    which the Offerer wishes the Answer to select. (Section 6.4.2.)
>
>    The Answerer SHOULD select the the first mid value from the offer,
>    unless the Answerer in the associated Answer will reject the
>    "m=3D" line associated with that mid value, or remove the "m=3D" line
>    from the BUNDLE group.  In such case the Answerer MUST select
>    the first unrejected mid value that remains in the SDP group:BUNDLE
>    attribute mid list of the Offer.

Looks good. Maybe we should not use the word "Selection" in the subject, th=
ough, if we are going to use "determine" terminology.

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

> Section 6.5.4:
>
> What should be done if rejecting the m-line causes the bundle group to be=
 empty?

I've been thinking about that myself.

Either the Answer doesn't contain the SDP group:BUNDLE attribute, or it con=
tains an SDP group:BUNDLE attribute with an empty value list (we would need=
 to double check whether the group attribute ABNF allows that).

I think it would be a little strange to include an empty attribute, though.=
 The only advantage is that it could be used to indicate support of the BUN=
DLE mechanism. But, if we need to be able to do that even if there is no BU=
NDLE group we should probably define something else.

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

> Section 7.2:
>
>    o  The dynamic payload type values used in the "m=3D" lines MUST NOT
>       overlap.
>
> What do you mean by overlap? I thought we were going to allow the same PT=
 to be used in multiple bundled m-lines as long as the definition of that P=
T was the same.

This is another section that I haven't touched for a long time on purpose, =
as we are still discussing the criteria for PT value re-usage. There is an =
e-mail thread on that specific topic.

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

> Section 8.2:
>
> Shouldn't it be sufficient to supply candidates for one of the m-lines th=
at share an address?

Another section I've left untouched, since I assume it will be covered in d=
raft-nandakumar-sdp-mux-attributes.

I should probably add notes in places where we have the draft-nandakumar-sd=
p-mux-attributes dependency.

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

Regards,

Christer

From ron.even.tlv@gmail.com  Mon Oct 28 08: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 448E311E82BF for ; Mon, 28 Oct 2013 08:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MO6gNwSz0zb for ; Mon, 28 Oct 2013 08:01:04 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id EE9FD11E834B for ; Mon, 28 Oct 2013 08:00:16 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id ey11so4117735wid.1 for ; Mon, 28 Oct 2013 08:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=GvN1im88MjdAqsGaExtb0bsQXj+XPOVsf9OrkLIWp6k=; b=p49USMu1JYs7KGJ4VcQD2NAWNMVZg4wLw+d6a9QtQUZ3lScPZSe2OD0TUJzu3f5X96 pv5nf8k87ugUYayG3sMGmKoG7OVSCLBTEflC90UTH+n9af2kVzj4df/7XU4/VCeQNjDF 2gIRgyt65PkqZRuq1o7WXH7X7u0K6Unj1Uo3PW6eG0VwL+VePT+Fj0NBxZ7piHfYS/K0 kKQTpWnHyv2XQ9BhoHy+k8xYnrHYIF1vCx3oLHtso6GkG/sKcAFeHI0Gj20RJdS98Cot d/yMG2DoHyJhYqGl93wnJqyz8TLvb5vPmVc5Ko5zANEegPzMkTQCHxmLPoz5JRF6CHcx ibBg==
X-Received: by 10.180.12.14 with SMTP id u14mr9387146wib.63.1382972416077; Mon, 28 Oct 2013 08:00:16 -0700 (PDT)
Received: from RoniE (bzq-79-181-191-27.red.bezeqint.net. [79.181.191.27]) by mx.google.com with ESMTPSA id q3sm36600230wib.5.2013.10.28.08.00.14 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Oct 2013 08:00:15 -0700 (PDT)
From: "Roni Even" 
To: "'Martin Thomson'" , "'Paul Kyzivat'" 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu> 
In-Reply-To: 
Date: Mon, 28 Oct 2013 16:57:02 +0200
Message-ID: <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6iXv0c6W9apn1bzhH/0GpTiVp7gIEvfvRAp4w7t8B8NJj/ph+JtFA
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Mon, 28 Oct 2013 15:01:05 -0000

Hi,
The appId is used to map to an SSRC so in the unified plan there can be more
than one RTP stream from a source like simulcast (see the new avtcore
simulcast-03 draft) but there can be an m-line for RTP stream like the CLUE
signaling examples. 
So there should be a different appIDd to the source and repair streams and
the association  is done using SDP group (RFC5956), note that the
association is very flexibly and the example we give is the case when one
repair stream is repairing three source streams from different cameras which
are different sources. This is feasible for a TP system. 
Having this FEC repair stream raises
 The question what is the msid of the repair stream and my thought was that
there is none (or all three?)


Roni

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Martin Thomson
> Sent: 28 October, 2013 4:46 AM
> To: Paul Kyzivat
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
> 
> On 27 October 2013 15:11, Paul Kyzivat  wrote:
> > I *thought* that for instance in case of FEC, the original stream and
the
> repair stream would have the same appid. But the example showed otherwise.
> 
> That's odd.  I'd have thought that too.
> 
> > I'd like the model to be spelled out. Then we wouldn't be wondering.
> 
> Yep.  Much better.  All it takes is something like 1 appid = 1 media
source.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From martin.thomson@gmail.com  Mon Oct 28 10:17: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 9CDD611E8187 for ; Mon, 28 Oct 2013 10:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSWvPI5eiYOv for ; Mon, 28 Oct 2013 10:17:22 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 875B611E818E for ; Mon, 28 Oct 2013 10:17:16 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id n12so6790169wgh.11 for ; Mon, 28 Oct 2013 10:17:15 -0700 (PDT)
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=O9qYJo6v0cNX7u4lBc7FTOXPDU51Y7H+ec9Wd5Oh5hk=; b=wkJEF/X84K5SxMfFxgbMW660v8U5TaAsE4we0lHfbfQVP+D0f5M+5KqOW+oeY9rWv5 NQmR/Q3SBky6Ct+rUnUTtngkdvHebcWy3vNStkNDl80ES7g9VzHoBP+izrzHWye1D0zX IXQ1wEtw0dn1tKWdT2jqjhdUUnaJ8bVI63dSy+TQXn+BUZYn9hFsJD7bDRHHJSpsWTaB /7pfPV+9NzvkgHyyQ7DXRlDZC+JRGiSqd7WkI4/Dw/Zlhn8lujvMRTGwgesKkIAiDiFR VNy36joseZGkr+eXlCB2D6XuiOmd//NZlu2s4ODD5JgAkS7RbX7OTcMiHfTHNWfAtlc5 ebvw==
MIME-Version: 1.0
X-Received: by 10.180.37.114 with SMTP id x18mr4195715wij.64.1382980635670; Mon, 28 Oct 2013 10:17:15 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Mon, 28 Oct 2013 10:17:15 -0700 (PDT)
In-Reply-To: <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>
Date: Mon, 28 Oct 2013 10:17:15 -0700
Message-ID: 
From: Martin Thomson 
To: Roni Even 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Mon, 28 Oct 2013 17:17:22 -0000

On 28 October 2013 07:57, Roni Even  wrote:
> there can be an m-line for RTP stream

I have http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.3
bookmarked, strangely enough, and the third paragraph is fairly clear
about the desired configuration, which is that multiple SSRCs are
grouped into the same m-line.

The issues regarding the use of a single FEC repair stream for
multiple sources is where the "can" part comes in, but I wouldn't have
used that as the starting position for this appid work.

From pkyzivat@alum.mit.edu  Mon Oct 28 10:33: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 A75C811E833B for ; Mon, 28 Oct 2013 10:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.057
X-Spam-Level: 
X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=-0.106,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc-3HckcXbOX for ; Mon, 28 Oct 2013 10:32:59 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id F3A8511E833C for ; Mon, 28 Oct 2013 10:32:39 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id ibtN1m0061GhbT85DhYf3A; Mon, 28 Oct 2013 17:32:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id ihYf1m0063ZTu2S3ThYfs9; Mon, 28 Oct 2013 17:32:39 +0000
Message-ID: <526E9FB7.2060000@alum.mit.edu>
Date: Mon, 28 Oct 2013 13:32:39 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Roni Even ,  'Martin Thomson' 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>
In-Reply-To: <019f01ced3ed$f83e1090$e8ba31b0$@gmail.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=1382981559; bh=pZZquBZcU1U3FLP47mcFvttLoycWtN1cWZvx8+UAdiw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YoMhBvy0LAtsD13oFq2rN8rJwkBuB/vzeNLIN76jRH/x6U3n1+UTn09X6WDsUx70p Thz5zhbWVwjAEY4M3yLWCLtA7tOCS7D6c2KQBmKWRjrJoGa3DMMAaQx+LLtvmyRBnk 16cGWNegVtM1kUhbt9cTtzEPJ5i7r0lFSMVOvIsddF20W4zQ1wyB76RTshl2ubPXmu 0IjVY8Vb4tBflGLlwMe7dFI7kc5NQ2rrYX8sTYRrNGPz2zSGZDbIMIxGxNZOHFyvQ7 nTNFVAptFf3WXUSCegnu5Xbt75e0dfqp/zwlW0h9HDWGV2EawSEyEztYLEW03Ra/xk U9hoGJ60f+TnQ==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Mon, 28 Oct 2013 17:33:03 -0000

Roni,

On 10/28/13 10:57 AM, Roni Even wrote:
> Hi,
> The appId is used to map to an SSRC so in the unified plan there can be more
> than one RTP stream from a source like simulcast (see the new avtcore
> simulcast-03 draft) but there can be an m-line for RTP stream like the CLUE
> signaling examples.
> So there should be a different appIDd to the source and repair streams and
> the association  is done using SDP group (RFC5956), note that the
> association is very flexibly and the example we give is the case when one
> repair stream is repairing three source streams from different cameras which
> are different sources. This is feasible for a TP system.
> Having this FEC repair stream raises
>   The question what is the msid of the repair stream and my thought was that
> there is none (or all three?)

I *think* you are confirming what I wrote in my original comment:

> - an RTP session MAY have one or more appid tokens
> - at any point in time each appid token maps to at most
>   one stream (SSRC) within the session.
> - *new* appid:ssrc mappings MAY be initialized via SDP
> - new appid:ssrc mappings MAY be initialized via receipt
>   of the new RTPC SDES message or header extension
> - existing appid:ssrc mappings MAY be updated via
>   receipt of the new RTCP SDES message or header extension.

including the 2nd point above. Is that true?

	Thanks,
	Paul

> Roni
>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
>> Of Martin Thomson
>> Sent: 28 October, 2013 4:46 AM
>> To: Paul Kyzivat
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
>>
>> On 27 October 2013 15:11, Paul Kyzivat  wrote:
>>> I *thought* that for instance in case of FEC, the original stream and
> the
>> repair stream would have the same appid. But the example showed otherwise.
>>
>> That's odd.  I'd have thought that too.
>>
>>> I'd like the model to be spelled out. Then we wouldn't be wondering.
>>
>> Yep.  Much better.  All it takes is something like 1 appid = 1 media
> source.
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>


From ron.even.tlv@gmail.com  Mon Oct 28 10:57: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 62DCE21E80B7 for ; Mon, 28 Oct 2013 10:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_73=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYX1WJm1GYH1 for ; Mon, 28 Oct 2013 10:57:49 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3A21E8087 for ; Mon, 28 Oct 2013 10:57:37 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id q58so7097512wes.3 for ; Mon, 28 Oct 2013 10:57:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=ONE4edk88CJx3zgwsQQ/b809/Jl6PcD2/68e/HMsDTQ=; b=haaRnAW9q5uvslZWCG06ES1JGR0DjTl2BG7kwv91ILrgLafzoCt0rQCQ2OWqUD5oBV GOZfnMEZy8nhwcKK5Ijy75vSqSnwPox0lfLHX1xOI5Il7nHowbI6XJ8TAYFCB6yOrmlo QDcJU/xh+RXnPbKjihSQsycxgrR8bFlGG7eR0gTvuNdd9/buir8QSotnhnlNSkfewcFS JCeQwnKKeqY4nIa+NK5pHqlFBk3gT3FGVWEkJAy7oblKN/8Y+xes2xkMuYLUw03FZaHT 42NAaxGfdZTEjwHvdVhFKtmfQnVNbHh6emx+juQG8w4m6kMPPgyU0y6KQrqdrRsVI4JD ajrA==
X-Received: by 10.194.47.209 with SMTP id f17mr2735460wjn.55.1382983056988; Mon, 28 Oct 2013 10:57:36 -0700 (PDT)
Received: from RoniE (bzq-79-181-191-27.red.bezeqint.net. [79.181.191.27]) by mx.google.com with ESMTPSA id sg6sm866312wic.9.2013.10.28.10.57.33 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Oct 2013 10:57:36 -0700 (PDT)
From: "Roni Even" 
To: "'Paul Kyzivat'" , "'Martin Thomson'" 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com> <526E9FB7.2060000@alum.mit.edu>
In-Reply-To: <526E9FB7.2060000@alum.mit.edu>
Date: Mon, 28 Oct 2013 19:54:21 +0200
Message-ID: <01dc01ced406$be5ef6f0$3b1ce4d0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6iXv0c6W9apn1bzhH/0GpTiVp7gIEvfvRAp4w7t8B8NJj/gJe/nO0As2BkYKYVPcboA==
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Mon, 28 Oct 2013 17:57:55 -0000

Hi Paul,
One thing I am trying to look at is that we can use the appID to create the
binding to SSRC in the RTP header and RTCP SDES and have the binding to SSRC
in SDP as optional.
This will take way the need to do binding like a=ssrc:xxxx cname:yyyy
srcname:zzz which should be done in the RTCP SDES.
Roni

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: 28 October, 2013 7:33 PM
> To: Roni Even; 'Martin Thomson'
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
> 
> Roni,
> 
> On 10/28/13 10:57 AM, Roni Even wrote:
> > Hi,
> > The appId is used to map to an SSRC so in the unified plan there can
> > be more than one RTP stream from a source like simulcast (see the new
> > avtcore
> > simulcast-03 draft) but there can be an m-line for RTP stream like the
> > CLUE signaling examples.
> > So there should be a different appIDd to the source and repair streams
> > and the association  is done using SDP group (RFC5956), note that the
> > association is very flexibly and the example we give is the case when
> > one repair stream is repairing three source streams from different
> > cameras which are different sources. This is feasible for a TP system.
> > Having this FEC repair stream raises
> >   The question what is the msid of the repair stream and my thought
> > was that there is none (or all three?)
> 
> I *think* you are confirming what I wrote in my original comment:
> 
> > - an RTP session MAY have one or more appid tokens
> > - at any point in time each appid token maps to at most
> >   one stream (SSRC) within the session.
> > - *new* appid:ssrc mappings MAY be initialized via SDP
> > - new appid:ssrc mappings MAY be initialized via receipt
> >   of the new RTPC SDES message or header extension
> > - existing appid:ssrc mappings MAY be updated via
> >   receipt of the new RTCP SDES message or header extension.
> 
> including the 2nd point above. Is that true?
> 
> 	Thanks,
> 	Paul
> 
> > Roni
> >
> >> -----Original Message-----
> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> Behalf Of Martin Thomson
> >> Sent: 28 October, 2013 4:46 AM
> >> To: Paul Kyzivat
> >> Cc: mmusic@ietf.org
> >> Subject: Re: [MMUSIC] comments on
> >> draft-even-mmusic-application-token-01
> >>
> >> On 27 October 2013 15:11, Paul Kyzivat  wrote:
> >>> I *thought* that for instance in case of FEC, the original stream
> >>> and
> > the
> >> repair stream would have the same appid. But the example showed
> otherwise.
> >>
> >> That's odd.  I'd have thought that too.
> >>
> >>> I'd like the model to be spelled out. Then we wouldn't be wondering.
> >>
> >> Yep.  Much better.  All it takes is something like 1 appid = 1 media
> > source.
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> >


From ron.even.tlv@gmail.com  Mon Oct 28 22:09: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 75E3A11E8103 for ; Mon, 28 Oct 2013 22:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.393
X-Spam-Level: 
X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGhetQmu6def for ; Mon, 28 Oct 2013 22:09:17 -0700 (PDT)
Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id B563921E80D3 for ; Mon, 28 Oct 2013 22:09:15 -0700 (PDT)
Received: by mail-ee0-f54.google.com with SMTP id t10so3616602eei.41 for ; Mon, 28 Oct 2013 22:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=t83b7KPPKKpr5+yhX7EbCuO2IvzHFCbOv3Y6Gi8VUCk=; b=IW+bsnnfQaVo/kLUnnZOHrOoPFkT/oWnm43NMfeQlPSiARnseDjcj/IBGzEtasHZwJ 1jHFkJLQz4Mn3BRPC5dAJ722+cf5YriVADZKrRMh0XfeOMPTOXcD4Lp/YNNatcqsPD7T g/Sq5OF99hp2W9MCXqFpuowIF+XVKYvPLv4WQDiy+4OzE3t+k2VCGWe5cLMokLmBQYMe LcYVrwpvQii1aLP6pnGX8t7YCOVEvTysIv2GSCw3UCjiaPFhKT1ifmKquvuHG/AIaIJY MOk1KbP0zSTddfbjoKJ1roLhnCwn7qww1l6u1pfPfnenY7aIGNlvfpYJVSRb5Y7f+3CU 3alA==
X-Received: by 10.15.24.68 with SMTP id i44mr963527eeu.87.1383023354667; Mon, 28 Oct 2013 22:09:14 -0700 (PDT)
Received: from RoniE (bzq-79-181-191-27.red.bezeqint.net. [79.181.191.27]) by mx.google.com with ESMTPSA id u46sm65544773eep.17.2013.10.28.22.09.12 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Oct 2013 22:09:14 -0700 (PDT)
From: "Roni Even" 
To: "'Martin Thomson'" 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>		<019f01ced3ed$f83e1090$e8ba31b0$@gmail.com> 
In-Reply-To: 
Date: Tue, 29 Oct 2013 07:06:01 +0200
Message-ID: <023801ced464$91e97f60$b5bc7e20$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6iXv0c6W9apn1bzhH/0GpTiVp7gIEvfvRAp4w7t8B8NJj/gJe/nO0Al9VIzuYWSOwUA==
Content-Language: en-us
Cc: mmusic@ietf.org, 'Paul Kyzivat' 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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, 29 Oct 2013 05:09:17 -0000

Martin,
1. My understanding that unified is only applicable to RTCweb but not a =
general MMUSIC solution. A singe media stream per m-line that may be =
grouped  is also a case for MMUSIC.=20
2. The motivation for appID is also having multiple media streams (each =
with a different SSRC) in a single m-line representing a media source. =
(unified).
3. The FEC example is more a corner case and a question I had about msid =
and unified but not the motivation for appID
Roni

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: 28 October, 2013 7:17 PM
> To: Roni Even
> Cc: Paul Kyzivat; mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on =
draft-even-mmusic-application-token-01
>=20
> On 28 October 2013 07:57, Roni Even  wrote:
> > there can be an m-line for RTP stream
>=20
> I have =
http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-
> 3.3
> bookmarked, strangely enough, and the third paragraph is fairly clear =
about
> the desired configuration, which is that multiple SSRCs are grouped =
into the
> same m-line.
>=20
> The issues regarding the use of a single FEC repair stream for =
multiple sources
> is where the "can" part comes in, but I wouldn't have used that as the =
starting
> position for this appid work.


From ari.keranen@ericsson.com  Tue Oct 29 06:06: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 0C48911E815F for ; Tue, 29 Oct 2013 06:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.682
X-Spam-Level: 
X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnGQmTc4IKih for ; Tue, 29 Oct 2013 06:06:01 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0014F11E8239 for ; Tue, 29 Oct 2013 06:05:45 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-9c-526fb2a8cd6a
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.2E.03802.8A2BF625; Tue, 29 Oct 2013 14:05:44 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Tue, 29 Oct 2013 14:05:43 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 2D1431103D8; Tue, 29 Oct 2013 15:05:44 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 54E1F4EB5A; Tue, 29 Oct 2013 15:05:43 +0200 (EET)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0C9244EB59; Tue, 29 Oct 2013 15:05:43 +0200 (EET)
Message-ID: <526FB2A6.1060609@ericsson.com>
Date: Tue, 29 Oct 2013 15:05:42 +0200
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3RnfFpvwgg8d3dCzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAldE31atgK1PF6v0ODYx/GLsYOTkkBEwkHk9c wwRhi0lcuLeerYuRi0NI4BCjxPTGfcwQzgZGiZMX9oN1CAnsYZTY0qQGkVjLKHG77T4ThLOc UeL3y3VALRwcvALaEgf/qIM0sAioSsxtnsYMYrMJ2EvcnHCdHcQWFUiWeHT3FBuIzSsgKHFy 5hMWEFtEQEZi76bNYGOEBcwkljwtBwkzC9hKXJhznQXClpfY/nYOM8TVahJXz21ihrhNVeLq v1eMExiFZiGZOgtJ+ywk7QsYmVcxsucmZuaklxttYgSG6cEtv1V3MN45J3KIUZqDRUmc98Nb 5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjF0lj9TWye7/dris+vwmlpAcFrnOW0peZn1f DW32MP7/UvPMKTFre8buWdkVzx6/WHGQU4qpvW2T95GuA6t/eJgtvXqo4eM9gYaNp7bEv/g3 u/z6pdWv/qRfY5pT2PD8xi/Fs4J3Xp71MWXOT5k39dSpCM/ki6s+vt5xe3uMB2vL9/tM7a5s x7iUWIozEg21mIuKEwFI32cJIQIAAA==
Subject: [MMUSIC] Second MMUSIC session rescheduled to Thursday
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 Oct 2013 13:06:08 -0000

Hi all,

FYI, as discussed in the "Agenda and conflict with PerPass" thread, 
there were severe conflicts for our planned Wednesday slot so that slot 
has been now moved to Thursday morning, 9:00-11:30.

The updated agenda:
http://www.ietf.org/proceedings/88/agenda/agenda-88-mmusic


Cheers,
Ari

From pkyzivat@alum.mit.edu  Tue Oct 29 08:36: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 7AF4521E8151 for ; Tue, 29 Oct 2013 08:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.06
X-Spam-Level: 
X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=-0.103,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGIIvdNRLqZv for ; Tue, 29 Oct 2013 08:36:02 -0700 (PDT)
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 6DF2421E8160 for ; Tue, 29 Oct 2013 08:36:01 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id j0Jf1m0040QuhwU513c0oc; Tue, 29 Oct 2013 15:36:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id j3c01m00V3ZTu2S3N3c0WW; Tue, 29 Oct 2013 15:36:00 +0000
Message-ID: <526FD5E0.6010202@alum.mit.edu>
Date: Tue, 29 Oct 2013 11:36:00 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Roni Even ,  'Martin Thomson' 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>		<019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com>
In-Reply-To: <023801ced464$91e97f60$b5bc7e20$@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383060960; bh=FZA5DWUqMnW4Jf6gJlBUr3h+8eJTPWVFplSsUFT3GQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g7M3dEq3mdPTElkPj3YuwDbSMBKyPr5fndai+M3KimOxwID6wXURb8U6UWXuhC+jP 5lCpdx8akoACcQ37M3a4qZR14bmfht6S0gumvmO3Zi8ia44KSUA6+EIgbn1bhW//kW ZvII1cm6Orh/DSZvp8pgaSTNNBXDD//nIAo4YaSedBdVaBSgcgKkOTlDuTS5jHHQVS 7y+qjwMRiRMaPganR/z4Zm2MDO6NyuzDBvDETJiA48fiF/XttzJTB679dqpOW8QIvI FX8j5CZMnUMWvY6yGrZ8zM2gNGITDDMd/sjwR5veN2os9cIVhbH0TXO+TohUZ4Gr88 aNZ8s+9gE3ICQ==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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, 29 Oct 2013 15:36:07 -0000

Roni,

I'm still not sure I understand. I'm going to repeat my characterization 
about what I understand one more time:

- an RTP session MAY have one or more appid tokens
- at any point in time each appid token maps to at most
   one stream (SSRC) within the session.
- *new* appid:ssrc mappings MAY be initialized via SDP
- new appid:ssrc mappings MAY be initialized via receipt
   of the new RTPC SDES message or header extension
- existing appid:ssrc mappings MAY be updated via
   receipt of the new RTCP SDES message or header extension.

Can you either confirm the above is correct, or else update it so it is 
correct?

	Thanks,
	Paul


On 10/29/13 1:06 AM, Roni Even wrote:
> Martin,
> 1. My understanding that unified is only applicable to RTCweb but not a general MMUSIC solution. A singe media stream per m-line that may be grouped  is also a case for MMUSIC.
> 2. The motivation for appID is also having multiple media streams (each with a different SSRC) in a single m-line representing a media source. (unified).
> 3. The FEC example is more a corner case and a question I had about msid and unified but not the motivation for appID
> Roni
>
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: 28 October, 2013 7:17 PM
>> To: Roni Even
>> Cc: Paul Kyzivat; mmusic@ietf.org
>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
>>
>> On 28 October 2013 07:57, Roni Even  wrote:
>>> there can be an m-line for RTP stream
>>
>> I have http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-
>> 3.3
>> bookmarked, strangely enough, and the third paragraph is fairly clear about
>> the desired configuration, which is that multiple SSRCs are grouped into the
>> same m-line.
>>
>> The issues regarding the use of a single FEC repair stream for multiple sources
>> is where the "can" part comes in, but I wouldn't have used that as the starting
>> position for this appid work.
>
>


From jonathan@vidyo.com  Tue Oct 29 13:50: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 CA0D111E818D for ; Tue, 29 Oct 2013 13:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.831
X-Spam-Level: 
X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urkMN8j3Rpnm for ; Tue, 29 Oct 2013 13:50:33 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5203D11E814C for ; Tue, 29 Oct 2013 13:50:32 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/29/2013 4:50:28 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-96/SG:2 10/29/2013 4:49:55 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.915719 p=-0.973724 Source White
X-Signature-Violations: 0-0-0-20600-c
X-Note-419: 31.2112 ms. Fail:1 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:1-1349/SG:1 10/29/2013 4:50:16 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 68767631; Tue, 29 Oct 2013 16:50:28 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 29 Oct 2013 15:50:27 -0500
From: Jonathan Lennox 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnwDfMHDAAAAR4DAAbprzgA==
Date: Tue, 29 Oct 2013 20:50:26 +0000
Message-ID: <279CF29F-E822-41C7-B32E-3AB5B8403D48@vidyo.com>
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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 Oct 2013 20:50:39 -0000

This works as an outline, but I'm afraid it'll be too vague for solid inter=
operability.

I think it works as a set of principles to guide discussion of PT-specific =
definitions in the mux-attributes draft, though.

On Oct 27, 2013, at 5:03 PM, Christer Holmberg 
 wrote:

> This time in non-HTML format.
>=20
> L=E4hett=E4j=E4: Christer Holmberg=20
> L=E4hetetty: 27. lokakuuta 2013 23:03
> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
> Kopio: mmusic
> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usag=
e [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec conf=
iguration)]
>=20
> Hi,
>=20
> It would be really great if those who have an opinion on this would indic=
ate whether they are ok with the approach below. Then we can focus on where=
 to document it :)
>=20
> Regards,
>=20
> Christer
>=20
> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=
 Puolesta Christer Holmberg
> L=E4hetetty: 23. lokakuuta 2013 13:37
> Vastaanottaja: Bo Burman; Jonathan Lennox
> Kopio: mmusic
> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [W=
AS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configur=
ation)]
>=20
> Hi,
>=20
> Below is a copy of the current text in my Vancouver slide regarding the c=
riteria for PT value re-usage in multiple m- lines within a BUNDLE group.
>=20
> It is based on the ideas provided by Jonathan L and Bo B.
>=20
> As you can see, apart from the rtpmap and fmtp attributes, it is not poss=
ible to define an exclusive list of attributes that must be identical. Such=
 lists may also be codec dependent. Instead, the text talks more generally =
about memory and buffer sizes.
>=20
>=20
>> REQUIREMENTS
> - Decoder agnostic
>> It shall be possible to switch decoders between media flows using the sa=
me PT value
> - Codec agnostic=20
>> The criteria shall be applicable to any codec
>> CRITERIA
> - SDP rtpmap and fmtp attribute values must be equal (order of attribute =
parameters not significant)
>> All parameters must be included
> - Explictily
> - Implicitly, if a default value is defined for the parameter=20
>> Parameters not included are assigned their default values (if defined)
> - Decoder maximum memory and buffer sizes shall be assumed to match
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf =
Of Christer Holmberg
> Sent: 16. lokakuuta 2013 12:12
> To: Bo Burman; Jonathan Lennox
> Cc: mmusic
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT va=
lue for single codec configuration
>=20
> Hi Bo,
>=20
> Thanks for your input!
>=20
> I'd ask anyone who might have an opinion about this to take a look at the=
 proposal, comment on the list if needed, and hopefully we can agree on way=
 forward in Vancouver (or, even earlier :)
>=20
> Regards,
>=20
> Christer
>=20
> From: Bo Burman=20
> Sent: 16. lokakuuta 2013 11:44
> To: Christer Holmberg; Jonathan Lennox
> Cc: mmusic
> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT va=
lue for single codec configuration
>=20
> Hi,
>=20
> I agree with Jonathan that in order to make two PT values "equal", their =
rtpmap and fmtp lines must be equal, as a start.
>=20
> I don't think there is any "correct" criterion that can be used to judge =
PT for equality, but we just have to decide on a "reasonable" one that is a=
s simple as possible without causing any major problems.
>=20
> I have assumed a conceptual equality criterion where PT value A should be=
 considered equal to another PT value B if an RTP stream with PT A can be f=
ed into a decoder stack configured with PT B, and vice versa, without causi=
ng either decoder stack to "break".
>=20
> I don't think we should require the fmtp lines are textually equal, but o=
nly that the same parameters are present and have the same values. The orde=
r of the parameters on the fmtp line does not matter. There is also the cas=
e when a parameter is specified with the default value for one PT and omitt=
ed for the other. To identify those as equal, which they semantically are, =
would require an "equality parser" to know every default value of every fmt=
p parameter for all codecs. This seems unreasonable.
>=20
> Regarding Jonathan's question on H.264 sprop-., I guess they don't strict=
ly need to be equal to make the PTs equal, but they may have to be. They ef=
fectively configure the decoder in some way and if there is a mismatch, the=
 decoding process will likely break; like mis-interpretations or buffer ove=
rflows. On the other hand, some sprop-. can be updated by in-band informati=
on, overriding what is specified on the fmtp line, and in this case the fmt=
p line sprop-. information is obsolete. Requiring that all fmtp of the line=
 is equal however makes a simple rule, which should be preferable and I don=
't think it is too restrictive or excessive.
>=20
> However, if the potentially equal PT values are defined as part of differ=
ent media descriptions, other media level attributes also contribute to the=
 decoder stack configuration. Some attributes, like maxptime, can clearly c=
ause problems (in this case buffer overflow) if it differs. Others, like pt=
ime, framerate and imageattr are more of a receiver preference within a mor=
e formal "conformance point" and would not "break" a decoder stack if they =
differ.
>=20
> I agree it can be a good idea to add some text into the mux-attributes dr=
aft about attributes that have to be the same to consider two PT in differe=
nt media descriptions to be "equal", of course given that rtpmap and fmtp a=
re also equal.
>=20
> /Bo
>=20
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf =
Of Christer Holmberg
> Sent: den 11 september 2013 09:12
> To: Jonathan Lennox
> Cc: mmusic
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT va=
lue for single codec configuration
>=20
> Hi,
>=20
> It would be so easy if we could define the PT mappings on the SDP session=
 level, and then simply refer to them within the m- lines :)
>=20
> Regards,
>=20
> Christer
>=20
> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20
> Sent: 10. syyskuuta 2013 22:18
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT va=
lue for single codec configuration
>=20
> My strawman proposal at the mic in Berlin was that a codec configuration =
is defined by the top-level media type of the m=3D line and the content of =
a given PT value's rtpmap and fmtp lines.  I.e., the full media type, with =
all its parameters.
>=20
> The questions I would have to this straw man are:
>=20
> * Is this excessive?  E.g., should items like H.264's sprop- parameters b=
e allowed to differ across m=3D line blocks?
>=20
> * Is this sufficient?  Should other items (sometimes) indexed by PT (e.g.=
, the imageattr, rtcp-fb, or extmap attributes) need to be the same across =
m-lines as well?
>=20
> My suggestion would be that this work should be folded into the work bein=
g done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should b=
e integrated with BUNDLE).  Currently (I believe) the mux-attributes draft =
assumes that PTs are unique across m-lines, so this work is going to imply =
changes to the analysis of a number of attributes in that draft, regardless=
.  Probably a new category will need to be defined for attributes which hav=
e to be consistent per payload type.
>=20
> On Sep 10, 2013, at 5:56 AM, Christer Holmberg  wrote:
>=20
> =20
> Hi,
> =20
> Below is the "official" (from the minutes) outcome of questions Q1,Q2 and=
 Q7 in Berlin.
> =20
> Questions:
> =20
> Q1: "Can we agree that, within a BUNDLE group (including all m- lines ass=
ociated with the group), any given PT value can only be used for a single c=
odec configuration?"
> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there a=
re opinions that simply referencing RFC 3550 might not be clear enough?"
> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in=
 multiple RTP m- lines, for the SAME codec configuration?"
> =20
> Outcome:
> =20
> Q1: Yes
> Q2: Yes, Lennox will send suggested text to clarify the term "codec confi=
guration".
> Q7: Yes.
> =20
> So, again, we need definition text for "codec configuration". Jonathan pr=
omised to submit something, but anyone is of course welcome to do that.
> =20
> The other alternative is to not say anything about PT value usages within=
 the scope of BUNDLE, but that is not what the meeting wanted.
> =20
> Regards,
> =20
> Christer
> =20
> =20
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf =
Of Christer Holmberg
> Sent: 23. elokuuta 2013 13:53
> To: mmusic
> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value =
for single codec configuration
> =20
> Hi,
> =20
> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and =
Q7 in my slides) was regarding the usage of any given PT value.
> =20
> My take of the outcome was that:
> =20
> -          We agreed that any given PT value can only be used for a singl=
e codec configuration (Q1)
> -          We agreed that we need some definition text for "codec configu=
ration" (Q2)
> -          We agreed that, within a BUNDLE group, any given PT value can =
be used in multiple m- lines, as long as it is used for a single codec conf=
iguration (Q7).
> =20
> Jonathan Lennox promised to suggest some definition text for "codec confi=
guration", so let's wait for that until we go into those discussions.
> =20
> But, if you have any issues with the agreements in general, please bring =
them up :)
> =20
> Regards,
> =20
> Christer
> =20
> =20
> =20
>=20
> --
> Jonathan Lennox
> jonathan@vidyo.com
>=20


From jonathan@vidyo.com  Tue Oct 29 14:35: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 E4B2611E828D for ; Tue, 29 Oct 2013 14:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level: 
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUpYmygDgcpa for ; Tue, 29 Oct 2013 14:35:16 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F921F9F7F for ; Tue, 29 Oct 2013 14:34:56 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/29/2013 5:34:54 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-90/SG:2 10/29/2013 5:34:12 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.898123 p=-0.972441 Source White
X-Signature-Violations: 0-0-0-8973-c
X-Note-419: 31.2004 ms. Fail:0 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:0-1349/SG:1 10/29/2013 5:34:35 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 43884964; Tue, 29 Oct 2013 17:34:53 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 29 Oct 2013 16:34:52 -0500
From: Jonathan Lennox 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] comments on draft-even-mmusic-application-token-01
Thread-Index: AQHO1LyRHByVr0dAA0OEs67Y08GtvZoMh76A
Date: Tue, 29 Oct 2013 21:34:51 +0000
Message-ID: <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com>
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu>
In-Reply-To: <526FD5E0.6010202@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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, 29 Oct 2013 21:35:35 -0000

Hi, Paul --

On Oct 29, 2013, at 11:36 AM, Paul Kyzivat 
 wrote:

> Roni,
>=20
> I'm still not sure I understand. I'm going to repeat my characterization =
about what I understand one more time:
>=20
> - an RTP session MAY have one or more aphid tokens

Yes.

> - at any point in time each appid token maps to at most
>  one stream (SSRC) within the session.

This one isn't right.  An appid maps to at most one *source* -- but in situ=
ations where multiple streams (SSRCs) make up one source, in some cases we'=
ll want them to be associated by having them have the same appid.

In particular, I think, RTX and single-stream-repair FEC streams should pro=
bably be associated to their primary stream using appid.  (Multi-stream-rep=
air FEC is more complicated, as the draft discusses.  Yes, we probably shou=
ldn't have jumped to the more complicated case so quickly in the examples.)

However, it's not as simple as saying that the same appid applies to all th=
e streams of the source.

The important cases where a single source's streams will be split across mu=
ltiple appid values are simulcast and MST layered codecs.  An important use=
 case of appid is to disambiguate the various simulcast streams and layers;=
 however, in the taxonomy draft's terminology these are a single source, an=
d Unified puts them into a single m-line.  It's not clear to me yet how Uni=
fied is planning to signal these cases (I know Magnus has a proposal, but I=
 haven't read it in detail yet), but appid will need to be able to handle i=
t.


> - *new* appid:ssrc mappings MAY be initialized via SDP

Yes.

> - new appid:ssrc mappings MAY be initialized via receipt
>  of the new RTPC SDES message or header extension

Yes.  Only for appid values whose semantics are already specified (without =
an SSRC mapping) in SDP or elsewhere, however; otherwise there's no semanti=
cs to attach them to.  (Early media cases may need more thought here.)

> - existing appid:ssrc mappings MAY be updated via
>  receipt of the new RTCP SDES message or header extension.

Yes.

>=20
> Can you either confirm the above is correct, or else update it so it is c=
orrect?
>=20
> 	Thanks,
> 	Paul
>=20
>=20
> On 10/29/13 1:06 AM, Roni Even wrote:
>> Martin,
>> 1. My understanding that unified is only applicable to RTCweb but not a =
general MMUSIC solution. A singe media stream per m-line that may be groupe=
d  is also a case for MMUSIC.
>> 2. The motivation for appID is also having multiple media streams (each =
with a different SSRC) in a single m-line representing a media source. (uni=
fied).
>> 3. The FEC example is more a corner case and a question I had about msid=
 and unified but not the motivation for appID
>> Roni
>>=20
>>> -----Original Message-----
>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>> Sent: 28 October, 2013 7:17 PM
>>> To: Roni Even
>>> Cc: Paul Kyzivat; mmusic@ietf.org
>>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-0=
1
>>>=20
>>> On 28 October 2013 07:57, Roni Even  wrote:
>>>> there can be an m-line for RTP stream
>>>=20
>>> I have http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#se=
ction-
>>> 3.3
>>> bookmarked, strangely enough, and the third paragraph is fairly clear a=
bout
>>> the desired configuration, which is that multiple SSRCs are grouped int=
o the
>>> same m-line.
>>>=20
>>> The issues regarding the use of a single FEC repair stream for multiple=
 sources
>>> is where the "can" part comes in, but I wouldn't have used that as the =
starting
>>> position for this appid work.
>>=20
>>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20


From martin.thomson@gmail.com  Tue Oct 29 15:00:50 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 9DC2F21E8087 for ; Tue, 29 Oct 2013 15:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level: 
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdOGUgLzn+rc for ; Tue, 29 Oct 2013 15:00:50 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9860D21E8093 for ; Tue, 29 Oct 2013 15:00:48 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id ey11so568448wid.7 for ; Tue, 29 Oct 2013 15:00:47 -0700 (PDT)
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:content-transfer-encoding; bh=XYOuK0pNoprC52UPTuyY8ACpTUXvn0bP3tonwV94v9I=; b=gZiBZHagLCSfvzvADiY7C3j1O5XRvQty61vSy47aUpA7P9lr2dclzZBX4xI81atPFz gxPTb+l7iQEhSjRptlyw3gEqC59LmwWTKipNRtA6umpWGwAh/RudPAW5b4sbfb9i6en4 SmY9DyhFQ7h8gZPhqZnb7/vYWVVqF6tMQVkP3tyy0yTSJOs0KlN7qcUIh5tJAFBPp2ru OxZ0SP/veuC0J25SB0aA/CDRTJl5mze0G4EIYkNfZTlxiTHA3DSDZzM/k8w0hWvxqTgf O+Ot9M2WfuXVwQwNUjQsS8IXmC68Je1BxMMU4aK2AcEhTHvMLBv+YM0NdgbssBH46JQT Xcug==
MIME-Version: 1.0
X-Received: by 10.194.205.37 with SMTP id ld5mr1427242wjc.67.1383084047852; Tue, 29 Oct 2013 15:00:47 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 29 Oct 2013 15:00:47 -0700 (PDT)
In-Reply-To: <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com>
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com>
Date: Tue, 29 Oct 2013 15:00:47 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" , Paul Kyzivat 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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, 29 Oct 2013 22:00:50 -0000

On 29 October 2013 14:34, Jonathan Lennox  wrote:
>> - at any point in time each appid token maps to at most
>>  one stream (SSRC) within the session.
>
> This one isn't right.  An appid maps to at most one *source* -- but in si=
tuations where multiple streams (SSRCs) make up one source, in some cases w=
e'll want them to be associated by having them have the same appid.

Thanks Jonathan, I had hoped that this was the intended answer.  It's
the only one that makes any sense.

> In particular, I think, RTX and single-stream-repair FEC streams should p=
robably be associated to their primary stream using appid.  (Multi-stream-r=
epair FEC is more complicated, as the draft discusses.  Yes, we probably sh=
ouldn't have jumped to the more complicated case so quickly in the examples=
.)

The SDES extension or RTP extension could identify an SSRC as
contributing to multiple sources in those complicated scenarios.  The
simple case is where each SSRC contributes to just a single source.
Maybe that's too much information for an RTP extension, in which case
you could send the appid indications for each source a) when the
contribution commences - i.e., at the start of transmission; and b)
interleaved when there is more than one appid.  That assumes that the
SSRC can't ever stop contributing to a given source, which I think is
a safe assumption.

From pkyzivat@alum.mit.edu  Tue Oct 29 15:05: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 439EE21E809A for ; Tue, 29 Oct 2013 15:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.058
X-Spam-Level: 
X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.105,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7jZsBPQisKh for ; Tue, 29 Oct 2013 15:04:56 -0700 (PDT)
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 73E5821E8094 for ; Tue, 29 Oct 2013 15:04:41 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id izDB1m0071swQuc5FA4hUc; Tue, 29 Oct 2013 22:04:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id jA4g1m00w3ZTu2S3bA4ga1; Tue, 29 Oct 2013 22:04:41 +0000
Message-ID: <527030F8.80509@alum.mit.edu>
Date: Tue, 29 Oct 2013 18:04:40 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Jonathan Lennox 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>		<019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com>
In-Reply-To: <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.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=1383084281; bh=Nhr5sd5QEZCmiBjZSS9qqcXikLFEREoiIzYlvwS3gu4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SvTDtqtLn6+ssqr+1Y2EkmzrkoWoMUE3CuhAitK1WWrKixdrG+IFiySpr7RPeap9J TSmCZieGNNP7ItVFBv97KjrmvjjNWcJew8YNSQtEPJWM5edMgI2NndqEeEcAFAaFQV QPXBTjbxl9W4mQ7DONZfhFWCPaVaMdzk5gsUDSOl0rtiO5df8bJEDROo5cNwe494wW bu/wa/XvKWalhDLLyS+FDD8qKuow4LpXo7PFbPYCl2u+4sqGpsGUWvEQ9j/6drTs8S gv7gSkK96P8hu/5Thy98fWNFPVj0irBuKy2NRoTr9q49cV7IMDjVKi3YQd1n1r+sgm Nto+BaNu/LChg==
Cc: "" 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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, 29 Oct 2013 22:05:04 -0000

Jonathan,

Thanks for the clarifications. I have more questions.

On 10/29/13 5:34 PM, Jonathan Lennox wrote:
> Hi, Paul --
>
> On Oct 29, 2013, at 11:36 AM, Paul Kyzivat 
>   wrote:
>
>> Roni,
>>
>> I'm still not sure I understand. I'm going to repeat my characterization about what I understand one more time:
>>
>> - an RTP session MAY have one or more aphid tokens
>
> Yes.
>
>> - at any point in time each appid token maps to at most
>>   one stream (SSRC) within the session.
>
> This one isn't right.  An appid maps to at most one *source* -- but in situations where multiple streams (SSRCs) make up one source, in some cases we'll want them to be associated by having them have the same appid.

I thought that in RPT terms a source is equivalent to an SSRC.
Are you talking about a "Media Source" according to the taxonomy?

If an appid could only map to *one* ssrc, then changes are easy - when 
you get a new mapping then the old one goes away.

But if an appid can map to multiple SSRCs, then that complicates 
changing the mapping. Getting a mapping of the same appid to a new ssrc 
doesn't necessarily invalidate any old mappings. It might be necessary 
to explicitly unmap it. I don't see how you would do that.

> In particular, I think, RTX and single-stream-repair FEC streams should probably be associated to their primary stream using appid.  (Multi-stream-repair FEC is more complicated, as the draft discusses.  Yes, we probably shouldn't have jumped to the more complicated case so quickly in the examples.)

I presume it doesn't make sense to give two arbitrary SSRCs the same 
appid. Is there a way to revise/replace this statement with one that is 
correct and says something useful?

> However, it's not as simple as saying that the same appid applies to all the streams of the source.
>
> The important cases where a single source's streams will be split across multiple appid values are simulcast and MST layered codecs.  An important use case of appid is to disambiguate the various simulcast streams and layers; however, in the taxonomy draft's terminology these are a single source, and Unified puts them into a single m-line.  It's not clear to me yet how Unified is planning to signal these cases (I know Magnus has a proposal, but I haven't read it in detail yet), but appid will need to be able to handle it.

ISTM that it is important to distinguish valid mappings from invalid ones.

>> - *new* appid:ssrc mappings MAY be initialized via SDP
>
> Yes.
>
>> - new appid:ssrc mappings MAY be initialized via receipt
>>   of the new RTPC SDES message or header extension
>
> Yes.  Only for appid values whose semantics are already specified (without an SSRC mapping) in SDP or elsewhere, however; otherwise there's no semantics to attach them to.  (Early media cases may need more thought here.)

I'm not sure I follow this.

Suppose there was nothing in SDP. But a new appid shows up in RTCP SDES. 
It could (via a common value) tie together a raw stream with an RTX or 
FEC stream. It just doesn't say what it is used for. But putting it in 
SDP doesn't say what it is used for either.

In CLUE, the semantics could be in an Advertisement. (But, if we use an 
SDP label to reference an encoding, then I guess we would need the appid 
in the SDP too in order to tie those together.)

>> - existing appid:ssrc mappings MAY be updated via
>>   receipt of the new RTCP SDES message or header extension.
>
> Yes.

I'm still concerned about appid:ssrc mappings in subsequent 
offers/answers. If the first O/A defined one mapping, and a subsequent 
O/A revised that (different ssrc for the same appid) would that mapping 
change take effect?

Would the answer change depending on whether any media has been 
send/received with that ssrc?

Would the answer change depending on whether the mapping has been 
updated via RTCP SDES message or header extension?

	Thanks,
	Paul

From ron.even.tlv@gmail.com  Tue Oct 29 15:27: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 0225711E81B3 for ; Tue, 29 Oct 2013 15:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level: 
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ga75ehED1CG for ; Tue, 29 Oct 2013 15:27:04 -0700 (PDT)
Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3A30E11E8176 for ; Tue, 29 Oct 2013 15:27:04 -0700 (PDT)
Received: by mail-ea0-f177.google.com with SMTP id f15so238111eak.36 for ; Tue, 29 Oct 2013 15:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=yZLCRWM7NcfMnpV7BoMU8d56PjJWqpNRJknnEc4Qcr8=; b=vWB5uXtx4PFUHvmkCqwuMXeGUsJhtwK/+lRmX9iRyJ/HptZX3DigvahITvvF5WuYx7 wxuNKizbEbe3rJV4CK1/NjQkd2bnxWL9ygr861iIEEvVnGFw8ftSWetZ5YLlM7kCX3fI lh9uO2b/P2nNWoO+vw3zyr3DqvGsUsJiVAq6vyfPUl2ToljK8zNiRH5nynzWzLm9i98E GAlZbMaSftgMHLlaCyGb8eI3hkavRxO6138yDh6wXfiPYFeGB3BMJ1aHSp+BNMGI48W+ Knua44+wzkjTGbIa3/1RygTxP8VWEOhZkAtAUE87cJDAPATjZvQBCRZz7IXx9mLljPVk Wzxg==
X-Received: by 10.14.203.198 with SMTP id f46mr1592180eeo.111.1383085623365; Tue, 29 Oct 2013 15:27:03 -0700 (PDT)
Received: from RoniE (bzq-79-181-191-27.red.bezeqint.net. [79.181.191.27]) by mx.google.com with ESMTPSA id f49sm75544223eec.7.2013.10.29.15.27.01 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Oct 2013 15:27:02 -0700 (PDT)
From: "Roni Even" 
To: "'Paul Kyzivat'" , "'Martin Thomson'" 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>		<019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu>
In-Reply-To: <526FD5E0.6010202@alum.mit.edu>
Date: Wed, 30 Oct 2013 00:23:49 +0200
Message-ID: <032e01ced4f5$8cfab640$a6f022c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6iXv0c6W9apn1bzhH/0GpTiVp7gIEvfvRAp4w7t8B8NJj/gJe/nO0Al9VIzsCUToXgQLiKcF3mDCrKAA=
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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, 29 Oct 2013 22:27:05 -0000

Paul,
Inline
Roni

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: 29 October, 2013 5:36 PM
> To: Roni Even; 'Martin Thomson'
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on =
draft-even-mmusic-application-token-01
>=20
> Roni,
>=20
> I'm still not sure I understand. I'm going to repeat my =
characterization about
> what I understand one more time:
>=20
> - an RTP session MAY have one or more appid tokens
[Roni Even] This is correct but not important, an m-line can have one or =
more appIds toke
> - at any point in time each appid token maps to at most
>    one stream (SSRC) within the session.
[Roni Even] To one media stream - see the taxonomy draft
> - *new* appid:ssrc mappings MAY be initialized via SDP
[Roni Even] Yes
> - new appid:ssrc mappings MAY be initialized via receipt
>    of the new RTPC SDES message or header extension
[Roni Even] This is not a may but that is the MUST and we need both SDES =
and RTP header but the RTP header should have precedence in case of race =
condition. This is to allow the binding between a media stream in SDP to =
an SSRC to happen in the RTP when it is used.

> - existing appid:ssrc mappings MAY be updated via
>    receipt of the new RTCP SDES message or header extension.
[Roni Even] Yes, RTP header has precedence over SDES in case of race =
condition.
>=20
> Can you either confirm the above is correct, or else update it so it =
is correct?
>=20
> 	Thanks,
> 	Paul
>=20
>=20
> On 10/29/13 1:06 AM, Roni Even wrote:
> > Martin,
> > 1. My understanding that unified is only applicable to RTCweb but =
not a
> general MMUSIC solution. A singe media stream per m-line that may be
> grouped  is also a case for MMUSIC.
> > 2. The motivation for appID is also having multiple media streams =
(each with
> a different SSRC) in a single m-line representing a media source. =
(unified).
> > 3. The FEC example is more a corner case and a question I had about
> > msid and unified but not the motivation for appID Roni
> >
> >> -----Original Message-----
> >> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> >> Sent: 28 October, 2013 7:17 PM
> >> To: Roni Even
> >> Cc: Paul Kyzivat; mmusic@ietf.org
> >> Subject: Re: [MMUSIC] comments on
> >> draft-even-mmusic-application-token-01
> >>
> >> On 28 October 2013 07:57, Roni Even  wrote:
> >>> there can be an m-line for RTP stream
> >>
> >> I have
> >> =
http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section
> >> -
> >> 3.3
> >> bookmarked, strangely enough, and the third paragraph is fairly =
clear
> >> about the desired configuration, which is that multiple SSRCs are
> >> grouped into the same m-line.
> >>
> >> The issues regarding the use of a single FEC repair stream for
> >> multiple sources is where the "can" part comes in, but I wouldn't
> >> have used that as the starting position for this appid work.
> >
> >


From harald@alvestrand.no  Wed Oct 30 00:13: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 8C73311E8183 for ; Wed, 30 Oct 2013 00:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.149
X-Spam-Level: 
X-Spam-Status: No, score=-109.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5bW8E0JQm66 for ; Wed, 30 Oct 2013 00:13:34 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0038D11E8168 for ; Wed, 30 Oct 2013 00:13:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A77B639E270 for ; Wed, 30 Oct 2013 08:13:29 +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 SnhW+99OdBLs for ; Wed, 30 Oct 2013 08:13:26 +0100 (CET)
Received: from [172.16.39.182] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0DC5039E070 for ; Wed, 30 Oct 2013 08:13:25 +0100 (CET)
Message-ID: <5270B191.9030603@alvestrand.no>
Date: Wed, 30 Oct 2013 08:13:21 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: mmusic 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/mixed; boundary="------------070803080604000809080800"
Subject: [MMUSIC] Updated MSID 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 Oct 2013 07:13:39 -0000

This is a multi-part message in MIME format.
--------------070803080604000809080800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Roni and Flemming pointed out that I hadn't managed to submit the fixes
I made to -msid after the reviews of -01 before the deadline, and had
even managed to forget to send it to the list.

I had missed a number of occurences where "SSRC" needed to be changed to
"m-line" in the text (with some more adjustments to language around that).

Here it is. I'll submit it on Monday, when the I-D repository reopens.

-- 
Surveillance is pervasive. Go Dark.


--------------070803080604000809080800
Content-Type: text/plain; charset=UTF-8;
 name="rtcweb-msid.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="rtcweb-msid.txt"




Network Working Group                                      H. Alvestrand
Internet-Draft                                                    Google
Intended status: Standards Track                        October 30, 2013
Expires: May 3, 2014


Cross Session Stream Identification in the Session Description Protocol
                       draft-ietf-mmusic-msid-02a

Abstract

   This document specifies a grouping mechanism for RTP media streams
   that can be used to specify relations between media streams.

   This mechanism is used to signal the association between the SDP
   concept of "m-line" and the WebRTC concept of "MediaStream" /
   "MediaStreamTrack" using SDP signaling.

   This document is a work item of the MMUSIC WG, whose discussion list
   is mmusic@ietf.org.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 May 3, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Alvestrand                 Expires May 3, 2014                  [Page 1]

Internet-Draft                 MSID in SDP                  October 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
     1.1.  Structure Of This Document . . . . . . . . . . . . . . . .  3
     1.2.  Why A New Mechanism Is Needed  . . . . . . . . . . . . . .  3
     1.3.  Application to the WEBRTC MediaStream  . . . . . . . . . .  4
   2.  The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Msid-Semantic Attribute  . . . . . . . . . . . . . . . . .  5
   4.  Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . .  6
     4.1.  Handling of non-signalled tracks . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Design considerations, open questions and and
                alternatives  . . . . . . . . . . . . . . . . . . . . 11
   Appendix B.  Usage with multiple MediaStreams per M-line . . . . . 11
     B.1.  Mechanism design with multiple SSRCs . . . . . . . . . . . 12
     B.2.  Usage with the SSRC attribute  . . . . . . . . . . . . . . 13
   Appendix C.  Change log  . . . . . . . . . . . . . . . . . . . . . 13
     C.1.  Changes from alvestrand-rtcweb-msid-00 to -01  . . . . . . 13
     C.2.  Changes from alvestrand-rtcweb-msid-01 to -02  . . . . . . 13
     C.3.  Changes from alvestrand-rtcweb-msid-02 to
           mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13
     C.4.  Changes from alvestrand-mmusic-msid-00 to -01  . . . . . . 13
     C.5.  Changes from alvestrand-mmusic-msid-01 to -02  . . . . . . 14
     C.6.  Changes from alvestrand-mmusic-msid-02 to
           ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14
     C.7.  Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14
     C.8.  Changes from mmusic-msid-01 to -02b  . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14







Alvestrand                 Expires May 3, 2014                  [Page 2]

Internet-Draft                 MSID in SDP                  October 2013


1.  Introduction

1.1.  Structure Of This Document

   This document extends the SSRC grouping framework [RFC5888] by adding
   a new grouping relation that can cross RTP session boundaries if
   needed.

   Section 1.2 gives the background on why a new mechanism is needed.

   Section 2 gives the definition of the new mechanism.

   Section 4 gives the application of the new mechanism for providing
   necessary semantic information for the association of
   MediaStreamTracks to MediaStreams in the WebRTC API .

1.2.  Why A New Mechanism Is Needed

   When media is carried by RTP [RFC3550], each RTP media stream is
   distinguished inside an RTP session by its SSRC; each RTP session is
   distinguished from all other RTP sessions by being on a different
   transport association (strictly speaking, 2 transport associations,
   one used for RTP and one used for RTCP, unless RTCP multiplexing
   [RFC5761] is used).

   SDP gives a description based on m-lines.  According to the model
   used in [I-D.roach-mmusic-unified-plan], each m-line describes
   exactly one media source, and if mulitple media sources are carried
   in an RTP session, this is signalled using BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each
   media source is carried in its own RTP session.

   There exist cases where an application using RTP and SDP needs to
   signal some relationship between RTP media streams that may be
   carried in either the same RTP session or different RTP sessions.
   For instance, there may be a need to signal a relationship between a
   video track and an audio track, and where the generator of the SDP
   does not yet know if they will be carried in the same RTP session or
   different RTP sessions.

   The SDP grouping framework [RFC5888] can be used to group m-lines.
   However, there is sometimes the need for an application to specify
   some application-level information about the association between the
   SSRC and the group.  This is not possible using the SDP grouping
   framework.






Alvestrand                 Expires May 3, 2014                  [Page 3]

Internet-Draft                 MSID in SDP                  October 2013


1.3.  Application to the WEBRTC MediaStream

   The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies
   that communication between WebRTC entities is done via MediaStreams,
   which contain MediaStreamTracks.  A MediaStreamTrack is generally
   carried using a single SSRC in an RTP session (forming an RTP media
   stream.  The collision of terminology is unfortunate.)  There might
   possibly be additional SSRCs, possibly within additional RTP
   sessions, in order to support functionality like forward error
   correction or simulcast.  This complication is ignored below.

   In the RTP specification, media streams are identified using the SSRC
   field.  Streams are grouped into RTP Sessions, and also carry a
   CNAME.  Neither CNAME nor RTP session correspond to a MediaStream.
   Therefore, the association of an RTP media stream to MediaStreams
   need to be explicitly signaled.

   The WebRTC work has come to agreement (documented in
   [I-D.roach-mmusic-unified-plan]) that one M-line is used to describe
   each MediaStreamTrack, and that the BUNDLE mechanism
   [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group
   MediaStreamTracks into RTP sessions.  Therefore, the need is to
   specify the ID of a MediaStreamTrack and its containing MediaStream
   for each M-line, which can be accomplished with a media-level
   attribute.

   This usage is described in Section 4.


2.  The Msid Mechanism

   This document registers a new SDP [RFC4566] media-level "msid"
   attribute.  This new attribute allows endpoints to associate RTP
   media streams that are carried in the same or different m-lines, as
   well as allowing application-specific information to the association.

   The value of the "msid" attribute consists of an identifier and
   optional application-specific data, according to the following ABNF
   [RFC5234] grammar:


     ; "attribute" is defined in RFC 4566.
     attribute =/ msid-attr
     msid-attr = "msid:" identifier [ " " appdata ]
     identifier = token
     appdata = token





Alvestrand                 Expires May 3, 2014                  [Page 4]

Internet-Draft                 MSID in SDP                  October 2013


   An example MSID value for a group with the identifier "examplefoo"
   and application data "examplebar" might look like this:
     msid:examplefoo examplebar


   The identifier is a string of ASCII characters chosen from 0-9, a-z,
   A-Z and - (hyphen), consisting of between 1 and 64 characters.  It
   MUST be unique among the identifier values used in the same SDP
   session.  It is RECOMMENDED that is generated using a random-number
   generator.

   Application data is carried on the same line as the identifier,
   separated from the identifier by a space.

   The identifier uniquely identifies a group within the scope of an SDP
   description.

   There may be multiple msid attributes on a single m-line.  There may
   also be multiple m-lines that have the same value for identifier and
   application data.

   Endpoints can update the associations between SSRCs as expressed by
   msid attributes at any time; the semantics and restrictions of such
   grouping and ungrouping are application dependent.


3.  The Msid-Semantic Attribute

   In order to fully reproduce the semantics of the SDP and SSRC
   grouping frameworks, a session-level attribute is defined for
   signaling the semantics associated with an msid grouping.

   This OPTIONAL attribute gives the group identifier and its group
   semantic; it carries the same meaning as the ssrc-group-attr of RFC
   5576 section 4.2, but uses the identifier of the group rather than a
   list of SSRC values.

   An empty list of identifiers is an indication that the sender
   understands the indicated semantic, but has no msid groupings of the
   given type in the present SDP.

   The ABNF of msid-semantic is:

     attribute =/ msid-semantic-attr
     msid-semantic-attr = "msid-semantic:" token (" " identifier)*
     token = 

   The semantic field may hold values from the IANA registries



Alvestrand                 Expires May 3, 2014                  [Page 5]

Internet-Draft                 MSID in SDP                  October 2013


   "Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the
   "group" SDP Attribute".

   An example msid-semantic might look like this:
     a=msid-semantic:LS xyzzy forolow


   This means that the SDP description has two lip sync groups, with the
   group identifiers xyzzy and forolow, respectively.


4.  Applying Msid to WebRTC MediaStreams

   This section creates a new semantic for use with the framework
   defined in Section 2, to be used for associating SSRCs representing
   MediaStreamTracks within MediaStreams as defined in
   [W3C.WD-webrtc-20120209].

   The semantic token for this semantic is "WMS" (short for WebRTC Media
   Stream).

   The value of the msid corresponds to the "id" attribute of a
   MediaStream.

   In a WebRTC-compatible SDP description, all SSRCs intending to be
   sent from one peer will be identified in the SDP generated by that
   entity.

   The appdata for a WebRTC MediaStreamTrack consists of the "id"
   attribute of a MediaStreamTrack.

   If two different m-lines have MSID attributes with the same value for
   identifier and appdata, it means that these two m-lines are both
   intended for the same MediaStreamTrack.  So far, no semantic for such
   a mixture have been defined, but this specification does not forbid
   the practice.

   When an SDP description is updated, a specific msid continues to
   refer to the same MediaStream.  Once negotiation has completed on a
   session, there is no memory; an msid value that appears in a later
   negotiation will be taken to refer to a new MediaStream.

   The following are the rules for handling updates of the list of
   m-lines and their msid values.

   o  When a new msid value occurs in the description, the recipient can
      signal to its application that a new MediaStream has been added.




Alvestrand                 Expires May 3, 2014                  [Page 6]

Internet-Draft                 MSID in SDP                  October 2013


   o  When a description is updated to have more m-lines with the same
      msid value, but different appdata values, the recipient can signal
      to its application that new MediaStreamTracks have been added to
      the media stream.

   o  When a description is updated to no longer list the msid value on
      a specific m-line, the recipient can signal to its application
      that the corresponding media stream track has been closed.

   o  When a description is updated to no longer list the msid value on
      any m-line, the recipient can signal to its application that the
      media stream has been closed.

   In addition to signaling that the track is closed when it disappears
   from the SDP, the track will also be signaled as being closed when
   all associated SSRCs have disappeared by the rules of [RFC3550]
   section 6.3.4 (BYE packet received) and 6.3.5 (timeout).

   The association between SSRCs and m-lines is specified in
   [I-D.roach-mmusic-unified-plan].

4.1.  Handling of non-signalled tracks

   Pre-WebRTC entities will not send msid.  This means that there will
   be some incoming RTP packets that the recipient has no predefined
   MediaStream id value for.

   Handling will depend on whether or not any MSIDs are signaled in the
   relevant m-line(s).  There are two cases:

   o  No msid-semantic:WMS attribute is present.  The SDP session is
      assumed to be a backwards-compatible session.  All incoming media,
      on all m-lines that are part of the SDP session, are assumed to
      belong to independent media streams, each with one track.  The
      identifier of this media stream and of the media stream track is a
      randomly generated string; the label of this media stream will be
      set to "Non-WMS stream".

   o  An msid-semantic:WMS attribute is present.  In this case, the
      session is WebRTC compatible, and the packets are either caused by
      a bug or by timing skew between the arrival of the media packets
      and the SDP description.  These packets MAY be discarded, or they
      MAY be buffered for a while in order to allow immediate startup of
      the media stream when the SDP description is updated.  The arrival
      of media packets MUST NOT cause a new MediaStreamTrack to be
      signaled.

   If a WebRTC entity sends a description, it MUST include the msid-



Alvestrand                 Expires May 3, 2014                  [Page 7]

Internet-Draft                 MSID in SDP                  October 2013


   semantic:WMS attribute, even if no media streams are sent.  This
   allows us to distinguish between the case of no media streams at the
   moment and the case of legacy SDP generation.

   It follows from the above that the WebRTC entity must have the SDP of
   the other party before it can decide correctly whether or not a
   "default" MediaStream should be created.  RTP media packets that
   arrive before the remote party's SDP MUST be buffered or discarded,
   and MUST NOT cause a new MediaStreamTrack to be signalled.

   It follows from the above that media stream tracks in the "default"
   media stream cannot be closed by signaling; the application must
   instead signal these as closed when the SSRC disappears according to
   the rules of RFC 3550 section 6.3.4 and 6.3.5.

   NOTE IN DRAFT: Previous versions of this memo suggested adding all
   incoming SSRCs to a single MediaStream.  This is problematic because
   we do not know if the SSRCs are synchronized or not before we learn
   the CNAME of the SSRCs, which only happens when an RTCP packet
   arrives.  How to identify a non-WMS stream is still open for
   discussion - including whether it's necessary to do so.  Using the
   stream label seems like an easy thing to do for debuggability - it's
   not signalled, and is intended for human consumption anyway.


5.  IANA Considerations

   This document requests IANA to register the "msid" attribute in the
   "att-field (media level only)" registry within the SDP parameters
   registry, according to the procedures of [RFC4566]

   The required information is:

   o  Contact name, email: IETF, contacted via mmusic@ietf.org, or a
      successor address designated by IESG

   o  Attribute name: msid

   o  Long-form attribute name: Media stream group Identifier

   o  The attribute value contains only ASCII characters, and is
      therefore not subject to the charset attribute.

   o  The attribute gives an association over a set of m-lines.  It can
      be used to signal the relationship between a WebRTC MediaStream
      and a set of SSRCs.





Alvestrand                 Expires May 3, 2014                  [Page 8]

Internet-Draft                 MSID in SDP                  October 2013


   o  The details of appropriate values are given in RFC XXXX.

   This document requests IANA to create a new registry called
   "Semantics for the msid-semantic SDP attribute", which should have
   exactly the same rules as for the "Semantics for the ssrc-group SDP
   attribute" registry (Expert Review), and to register the "WMS"
   semantic within this new registry.

   The required information is:

   o  Description: WebRTC Media Stream, as given in RFC XXXX.

   o  Token: WMS

   o  Standards track reference: RFC XXXX

   IANA is requested to replace "RFC XXXX" with the RFC number of this
   document upon publication.


6.  Security Considerations

   An adversary with the ability to modify SDP descriptions has the
   ability to switch around tracks between media streams.  This is a
   special case of the general security consideration that modification
   of SDP descriptions needs to be confined to entities trusted by the
   application.

   If implementing buffering as mentioned in section Section 4.1, the
   amount of buffering should be limited to avoid memory exhaustion
   attacks.

   No other attacks that are relevant to the browser's security have
   been identified that depend on this mechanism.


7.  Acknowledgements

   This note is based on sketches from, among others, Justin Uberti and
   Cullen Jennings.

   Special thanks to Miguel Garcia and Paul Kyzivat for their work in
   reviewing this draft, with many specific language suggestions.


8.  References





Alvestrand                 Expires May 3, 2014                  [Page 9]

Internet-Draft                 MSID in SDP                  October 2013


8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [W3C.WD-webrtc-20120209]
              Bergkvist, A., Burnett, D., Jennings, C., and A.
              Narayanan, "WebRTC 1.0: Real-time Communication Between
              Browsers", World Wide Web Consortium WD WD-webrtc-
              20120209, February 2012,
              .

8.2.  Informative References

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Multiplexing Negotiation Using Session Description
              Protocol (SDP) Port Numbers",
              draft-ietf-mmusic-sdp-bundle-negotiation-04 (work in
              progress), June 2013.

   [I-D.roach-mmusic-unified-plan]
              Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for
              Using SDP with Large Numbers of Media Flows",
              draft-roach-mmusic-unified-plan-00 (work in progress),
              July 2013.

   [I-D.westerlund-avtcore-multiplex-architecture]
              Westerlund, M., Perkins, C., and H. Alvestrand,
              "Guidelines for using the Multiplexing Features of RTP",
              draft-westerlund-avtcore-multiplex-architecture-03 (work
              in progress), February 2013.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and



Alvestrand                 Expires May 3, 2014                 [Page 10]

Internet-Draft                 MSID in SDP                  October 2013


              Control Packets on a Single Port", RFC 5761, April 2010.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.


Appendix A.  Design considerations, open questions and and alternatives

   This appendix should be deleted before publication as an RFC.

   One suggested mechanism has been to use CNAME instead of a new
   attribute.  This was abandoned because CNAME identifies a
   synchronization context; one can imagine both wanting to have tracks
   from the same synchronization context in multiple MediaStreams and
   wanting to have tracks from multiple synchronization contexts within
   one MediaStream (but the latter is impossible, since a MediaStream is
   defined to impose synchronization on its members).

   Another suggestion has been to put the msid value within an attribute
   of RTCP SR (sender report) packets.  This doesn't offer the ability
   to know that you have seen all the tracks currently configured for a
   media stream.

   There has been a suggestion that this mechanism could be used to mute
   tracks too.  This is not done at the moment.

   Discarding of incoming data when the SDP description isn't updated
   yet (section 3) may cause clipping.  However, the same issue exists
   when crypto keys aren't available.  Input sought.

   There's been a suggestion that acceptable SSRCs should be signaled in
   a response, giving a recipient the ability to say "no" to certain
   SSRCs.  This is not supported in the current version of this
   document.


Appendix B.  Usage with multiple MediaStreams per M-line

   This appendix is included to document the usage of msid as a source-
   specific attribute.  Prior to the acceptance of the Unified Plan
   document, some implementations used this mechanism to distinguish
   between multiple MediaStreamTracks that were carried in the same
   M-line.

   It reproduces some of the original justification text for this
   mechanism that is not relevant when Unified Plan is used.





Alvestrand                 Expires May 3, 2014                 [Page 11]

Internet-Draft                 MSID in SDP                  October 2013


B.1.  Mechanism design with multiple SSRCs

   When media is carried by RTP [RFC3550], each RTP media stream is
   distinguished inside an RTP session by its SSRC; each RTP session is
   distinguished from all other RTP sessions by being on a different
   transport association (strictly speaking, 2 transport associations,
   one used for RTP and one used for RTCP, unless RTCP multiplexing
   [RFC5761] is used).

   There exist cases where an application using RTP and SDP needs to
   signal some relationship between RTP media streams that may be
   carried in either the same RTP session or different RTP sessions.
   For instance, there may be a need to signal a relationship between a
   video track in one RTP session and an audio track in another RTP
   session.  In traditional SDP, it is not possible to signal that these
   two tracks should be carried in one session, so they are carried in
   different RTP sessions.

   Traditionally, SDP was used to describe the RTP sessions, with one
   m-line being used to describe each RTP session.  With the advent of
   extensions like BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], this
   association may be more complex, with multiple m-lines being used to
   describe one RTP session; the rest of this document therefore talks
   about m-lines, not RTP sessions, when describing the signalling
   mechanism.

   The SSRC grouping mechanism ("a=ssrc-group") [RFC5576] can be used to
   associate RTP media streams when those RTP media streams are
   described by the same m-line.  The semantics of this mechanism
   prevent the association of RTP media streams that are spread across
   different m-lines.

   The SDP grouping framework [RFC5888] can be used to group m-lines.
   When an m-line describes one and only one RTP media stream, it is
   possible to associate RTP media streams across different m-lines.
   However, if an m-line has multiple RTP media streams, using multiple
   SSRCs, the SDP grouping framework cannot be used for this purpose.

   There are use cases (some of which are discussed in
   [I-D.westerlund-avtcore-multiplex-architecture] ) where neither of
   these approaches is appropriate; In those cases, a new mechanism is
   needed.

   In addition, there is sometimes the need for an application to
   specify some application-level information about the association
   between the SSRC and the group.  This is not possible using either of
   the frameworks above.




Alvestrand                 Expires May 3, 2014                 [Page 12]

Internet-Draft                 MSID in SDP                  October 2013


B.2.  Usage with the SSRC attribute

   When the MSID attribute was used with the SSRC attribute, it had to
   be registered in the "Attribute names (source level)" registry rather
   than the "Attribute names (media level only)" registry, and the msid
   line was prefixed with "a=ssrc: ".  Apart from that, usage of
   the attribute with SSRC-bound flows was identical with the current
   proposal.


Appendix C.  Change log

   This appendix should be deleted before publication as an RFC.

C.1.  Changes from alvestrand-rtcweb-msid-00 to -01

   Added track identifier.

   Added inclusion-by-reference of draft-lennox-mmusic-source-selection
   for track muting.

   Some rewording.

C.2.  Changes from alvestrand-rtcweb-msid-01 to -02

   Split document into sections describing a generic grouping mechanism
   and sections describing the application of this grouping mechanism to
   the WebRTC MediaStream concept.

   Removed the mechanism for muting tracks, since this is not central to
   the MSID mechanism.

C.3.  Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00

   Changed the draft name according to the wishes of the MMUSIC group
   chairs.

   Added text indicting cases where it's appropriate to have the same
   appdata for multiple SSRCs.

   Minor textual updates.

C.4.  Changes from alvestrand-mmusic-msid-00 to -01

   Increased the amount of explanatory text, much based on a review by
   Miguel Garcia.

   Removed references to BUNDLE, since that spec is under active



Alvestrand                 Expires May 3, 2014                 [Page 13]

Internet-Draft                 MSID in SDP                  October 2013


   discussion.

   Removed distinguished values of the MSID identifier.

C.5.  Changes from alvestrand-mmusic-msid-01 to -02

   Changed the order of the "msid-semantic: " attribute's value fields
   and allowed multiple identifiers.  This makes the attribute useful as
   a marker for "I understand this semantic".

   Changed the syntax for "identifier" and "appdata" to be "token".

   Changed the registry for the "msid-semantic" attribute values to be a
   new registry, based on advice given in Atlanta.

C.6.  Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00

   Updated terminology to refer to m-lines rather than RTP sessions when
   discussing SDP formats and the ability of other linking mechanisms to
   refer to SSRCs.

   Changed the "default" mechanism to return independent streams after
   considering the synchronization problem.

   Removed the space from between "msid-semantic" and its value, to be
   consistent with RFC 5576.

C.7.  Changes from mmusic-msid-00 to -01

   Reworked msid mechanism to be a per-m-line attribute, to align with
   [I-D.roach-mmusic-unified-plan]

C.8.  Changes from mmusic-msid-01 to -02b

   (the version number in the title will hcange to -02 on official
   submission)

   Corrected several missed cases where the word "ssrc" was not changed
   to "M-line".

   Added pointer to unified-plan (which should be moved to point to
   -jsep)









Alvestrand                 Expires May 3, 2014                 [Page 14]

Internet-Draft                 MSID in SDP                  October 2013


Author's Address

   Harald Alvestrand
   Google
   Kungsbron 2
   Stockholm,   11122
   Sweden

   Email: harald@alvestrand.no










































Alvestrand                 Expires May 3, 2014                 [Page 15]


--------------070803080604000809080800--

From christer.holmberg@ericsson.com  Wed Oct 30 01:12: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 51C1E21E80EB for ; Wed, 30 Oct 2013 01:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.57
X-Spam-Level: 
X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=0.679,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSmR40Ivu0tI for ; Wed, 30 Oct 2013 01:12:18 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAE21E80F8 for ; Wed, 30 Oct 2013 01:11:52 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-ec-5270bf46abe0
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 23.BC.16099.64FB0725; Wed, 30 Oct 2013 09:11:50 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 30 Oct 2013 09:11:50 +0100
From: Christer Holmberg 
To: Jonathan Lennox 
Thread-Topic: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnwDfMHDAAAAR4DAAbprzgAANPvgQ
Date: Wed, 30 Oct 2013 08:11:49 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FBA42@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se> <279CF29F-E822-41C7-B32E-3AB5B8403D48@vidyo.com>
In-Reply-To: <279CF29F-E822-41C7-B32E-3AB5B8403D48@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja7b/oIgg60PrCz2Lz7PbDF1+WMW ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJWx9o5bwfrgihlnNrI0MC526mLk5JAQMJE4 uXAlM4QtJnHh3nq2LkYuDiGBQ4wS3yY9ZIdwljBKtDYdYuxi5OBgE7CQ6P6nDdIgIqAhcfHZ BzYQm1nAQeLV+ttg9cICyxgl+l8vApskIrCcUeLqgd+sEB1uEn+3HmUEsVkEVCVmT3oGFucV 8JV4dfcZM8S2o4wSp5d+ZOpiZOfgFLCVeKkMUsIIdN33U2uYIJaJS9x6Mp8J4moBiSV7zkN9 ICrx8vE/VghbUeLjq32MEPV6EjemToE6VFti2cLXzBBrBSVOznzCMoFRbBaSsbOQtMxC0jIL ScsCRpZVjOy5iZk56eWGmxiBMXJwy2/dHYynzokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA6NGYRv3F+f1BedPXM2yYnztKu774DS/TcUqz58pe19oZGtvytjlVpH7 99reF59vOSSvjhdb/ro1zIWlW6Uujdk54ZVWeKzqLDvXY3pVtu7r2h5/cZAv3Mi6f9nLA8VL T1+In9xSO/cA5w55fQtdtfLw4Fj54vnrpiv/UDlf0ar56u+D5Ilhu5VYijMSDbWYi4oTAawU npFfAgAA
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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 Oct 2013 08:12:25 -0000

Hi Jonathan,

> This works as an outline, but I'm afraid it'll be too vague for solid int=
eroperability.

At the end of the day, it is the receiver that informs the remote party whi=
ch PT values it wants to receive, so if it chooses the same PT values it ha=
s to know that it is able to handle it.

We COULD go even more into detail, but then I'm afraid we would have to sta=
rt defining codec specific criteria etc, and I don't think we should go tha=
t way.

Regards,

Christer





I think it works as a set of principles to guide discussion of PT-specific =
definitions in the mux-attributes draft, though.

On Oct 27, 2013, at 5:03 PM, Christer Holmberg 
 wrote:

> This time in non-HTML format.
>=20
> L=E4hett=E4j=E4: Christer Holmberg
> L=E4hetetty: 27. lokakuuta 2013 23:03
> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
> Kopio: mmusic
> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value=20
> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for=20
> single codec configuration)]
>=20
> Hi,
>=20
> It would be really great if those who have an opinion on this would=20
> indicate whether they are ok with the approach below. Then we can=20
> focus on where to document it :)
>=20
> Regards,
>=20
> Christer
>=20
> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=
=20
> Puolesta Christer Holmberg
> L=E4hetetty: 23. lokakuuta 2013 13:37
> Vastaanottaja: Bo Burman; Jonathan Lennox
> Kopio: mmusic
> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage=20
> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec=20
> configuration)]
>=20
> Hi,
>=20
> Below is a copy of the current text in my Vancouver slide regarding the c=
riteria for PT value re-usage in multiple m- lines within a BUNDLE group.
>=20
> It is based on the ideas provided by Jonathan L and Bo B.
>=20
> As you can see, apart from the rtpmap and fmtp attributes, it is not poss=
ible to define an exclusive list of attributes that must be identical. Such=
 lists may also be codec dependent. Instead, the text talks more generally =
about memory and buffer sizes.
>=20
>=20
>> REQUIREMENTS
> - Decoder agnostic
>> It shall be possible to switch decoders between media flows using the=20
>> same PT value
> - Codec agnostic
>> The criteria shall be applicable to any codec CRITERIA
> - SDP rtpmap and fmtp attribute values must be equal (order of=20
> attribute parameters not significant)
>> All parameters must be included
> - Explictily
> - Implicitly, if a default value is defined for the parameter
>> Parameters not included are assigned their default values (if=20
>> defined)
> - Decoder maximum memory and buffer sizes shall be assumed to match
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
> Behalf Of Christer Holmberg
> Sent: 16. lokakuuta 2013 12:12
> To: Bo Burman; Jonathan Lennox
> Cc: mmusic
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
> value for single codec configuration
>=20
> Hi Bo,
>=20
> Thanks for your input!
>=20
> I'd ask anyone who might have an opinion about this to take a look at=20
> the proposal, comment on the list if needed, and hopefully we can=20
> agree on way forward in Vancouver (or, even earlier :)
>=20
> Regards,
>=20
> Christer
>=20
> From: Bo Burman
> Sent: 16. lokakuuta 2013 11:44
> To: Christer Holmberg; Jonathan Lennox
> Cc: mmusic
> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
> value for single codec configuration
>=20
> Hi,
>=20
> I agree with Jonathan that in order to make two PT values "equal", their =
rtpmap and fmtp lines must be equal, as a start.
>=20
> I don't think there is any "correct" criterion that can be used to judge =
PT for equality, but we just have to decide on a "reasonable" one that is a=
s simple as possible without causing any major problems.
>=20
> I have assumed a conceptual equality criterion where PT value A should be=
 considered equal to another PT value B if an RTP stream with PT A can be f=
ed into a decoder stack configured with PT B, and vice versa, without causi=
ng either decoder stack to "break".
>=20
> I don't think we should require the fmtp lines are textually equal, but o=
nly that the same parameters are present and have the same values. The orde=
r of the parameters on the fmtp line does not matter. There is also the cas=
e when a parameter is specified with the default value for one PT and omitt=
ed for the other. To identify those as equal, which they semantically are, =
would require an "equality parser" to know every default value of every fmt=
p parameter for all codecs. This seems unreasonable.
>=20
> Regarding Jonathan's question on H.264 sprop-., I guess they don't strict=
ly need to be equal to make the PTs equal, but they may have to be. They ef=
fectively configure the decoder in some way and if there is a mismatch, the=
 decoding process will likely break; like mis-interpretations or buffer ove=
rflows. On the other hand, some sprop-. can be updated by in-band informati=
on, overriding what is specified on the fmtp line, and in this case the fmt=
p line sprop-. information is obsolete. Requiring that all fmtp of the line=
 is equal however makes a simple rule, which should be preferable and I don=
't think it is too restrictive or excessive.
>=20
> However, if the potentially equal PT values are defined as part of differ=
ent media descriptions, other media level attributes also contribute to the=
 decoder stack configuration. Some attributes, like maxptime, can clearly c=
ause problems (in this case buffer overflow) if it differs. Others, like pt=
ime, framerate and imageattr are more of a receiver preference within a mor=
e formal "conformance point" and would not "break" a decoder stack if they =
differ.
>=20
> I agree it can be a good idea to add some text into the mux-attributes dr=
aft about attributes that have to be the same to consider two PT in differe=
nt media descriptions to be "equal", of course given that rtpmap and fmtp a=
re also equal.
>=20
> /Bo
>=20
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
> Behalf Of Christer Holmberg
> Sent: den 11 september 2013 09:12
> To: Jonathan Lennox
> Cc: mmusic
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
> value for single codec configuration
>=20
> Hi,
>=20
> It would be so easy if we could define the PT mappings on the SDP=20
> session level, and then simply refer to them within the m- lines :)
>=20
> Regards,
>=20
> Christer
>=20
> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
> Sent: 10. syyskuuta 2013 22:18
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
> value for single codec configuration
>=20
> My strawman proposal at the mic in Berlin was that a codec configuration =
is defined by the top-level media type of the m=3D line and the content of =
a given PT value's rtpmap and fmtp lines.  I.e., the full media type, with =
all its parameters.
>=20
> The questions I would have to this straw man are:
>=20
> * Is this excessive?  E.g., should items like H.264's sprop- parameters b=
e allowed to differ across m=3D line blocks?
>=20
> * Is this sufficient?  Should other items (sometimes) indexed by PT (e.g.=
, the imageattr, rtcp-fb, or extmap attributes) need to be the same across =
m-lines as well?
>=20
> My suggestion would be that this work should be folded into the work bein=
g done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should b=
e integrated with BUNDLE).  Currently (I believe) the mux-attributes draft =
assumes that PTs are unique across m-lines, so this work is going to imply =
changes to the analysis of a number of attributes in that draft, regardless=
.  Probably a new category will need to be defined for attributes which hav=
e to be consistent per payload type.
>=20
> On Sep 10, 2013, at 5:56 AM, Christer Holmberg  wrote:
>=20
> =20
> Hi,
> =20
> Below is the "official" (from the minutes) outcome of questions Q1,Q2 and=
 Q7 in Berlin.
> =20
> Questions:
> =20
> Q1: "Can we agree that, within a BUNDLE group (including all m- lines ass=
ociated with the group), any given PT value can only be used for a single c=
odec configuration?"
> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there a=
re opinions that simply referencing RFC 3550 might not be clear enough?"
> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in=
 multiple RTP m- lines, for the SAME codec configuration?"
> =20
> Outcome:
> =20
> Q1: Yes
> Q2: Yes, Lennox will send suggested text to clarify the term "codec confi=
guration".
> Q7: Yes.
> =20
> So, again, we need definition text for "codec configuration". Jonathan pr=
omised to submit something, but anyone is of course welcome to do that.
> =20
> The other alternative is to not say anything about PT value usages within=
 the scope of BUNDLE, but that is not what the meeting wanted.
> =20
> Regards,
> =20
> Christer
> =20
> =20
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
> Behalf Of Christer Holmberg
> Sent: 23. elokuuta 2013 13:53
> To: mmusic
> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
> value for single codec configuration
> =20
> Hi,
> =20
> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and =
Q7 in my slides) was regarding the usage of any given PT value.
> =20
> My take of the outcome was that:
> =20
> -          We agreed that any given PT value can only be used for a singl=
e codec configuration (Q1)
> -          We agreed that we need some definition text for "codec configu=
ration" (Q2)
> -          We agreed that, within a BUNDLE group, any given PT value can =
be used in multiple m- lines, as long as it is used for a single codec conf=
iguration (Q7).
> =20
> Jonathan Lennox promised to suggest some definition text for "codec confi=
guration", so let's wait for that until we go into those discussions.
> =20
> But, if you have any issues with the agreements in general, please=20
> bring them up :)
> =20
> Regards,
> =20
> Christer
> =20
> =20
> =20
>=20
> --
> Jonathan Lennox
> jonathan@vidyo.com
>=20


From iesg-secretary@ietf.org  Wed Oct 30 06:18: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 839F511E8175; Wed, 30 Oct 2013 06:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.467
X-Spam-Level: 
X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwrf+bvVt8+V; Wed, 30 Oct 2013 06:18:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DDA11E8162; Wed, 30 Oct 2013 06:17:48 -0700 (PDT)
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.81
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20131030131748.6987.86198.idtracker@ietfa.amsl.com>
Date: Wed, 30 Oct 2013 06:17:48 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] Last Call:  (Offer/Answer	Considerations for G723 Annex A and G729 Annex B) to Proposed Standard
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 30 Oct 2013 13:18:23 -0000

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B'
   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-11-27. 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


   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the Session Description
   protocol(SDP) offer and answer.  This document provides the offer/
   answer considerations for these parameters and updates RFC4856.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/ballot/


No IPR declarations have been submitted directly on this I-D.



From pkyzivat@alum.mit.edu  Wed Oct 30 07:39: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 45E9F21E8103 for ; Wed, 30 Oct 2013 07:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.243
X-Spam-Level: 
X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=0.194,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5ZLEgAN1VJ9 for ; Wed, 30 Oct 2013 07:38:56 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 171C711E8242 for ; Wed, 30 Oct 2013 07:38:34 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id jQ3Y1m0031c6gX85ASeaW9; Wed, 30 Oct 2013 14:38:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id jSea1m00W3ZTu2S3jSeaTW; Wed, 30 Oct 2013 14:38:34 +0000
Message-ID: <527119EA.2030005@alum.mit.edu>
Date: Wed, 30 Oct 2013 10:38:34 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5270B191.9030603@alvestrand.no>
In-Reply-To: <5270B191.9030603@alvestrand.no>
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=1383143914; bh=ZS49YUIkVpiNF62hbs714NuyFO+8mJMtR/qmSGA9SjQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e1vvZitJlUrSfS9RJmc/W7p/NW9mELqG5i95tBly/n4Sgll7ASflJhww7HKEfqzPB ejkvbdmxhlfnoRwiwVF3ZpD5NWC4ORpoSdhZl0OrrVvNL7LvDSINgtlo2ukcBg9yT5 6SrdpXdT0d5+NR2uXQa/WLPJBQvMH4b17X9L/NoLF7II++qwNZbKp0LpGgOYkgrcaF K288gnILSouNvCJDQGVkOndp9n1FecQLlCvxiaS3ZHzjQErAmg00xdTKA0uJGSFlfz ZzWWBc0DSZ2+AQ2rP0qktMQce4Ch8kWxAVPSgMQGRzPaRt7nnOj5sgbjE7hAdJAwiJ H9k+ps+vgSiTA==
Subject: Re: [MMUSIC] Updated MSID 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 Oct 2013 14:39:18 -0000

A few comments about this version. Actually the comments aren't specific 
to this revision, but they relate to things I didn't notice earlier.

Msid-Semantic syntax:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" token (" " identifier)*
      token = 

The usage of "*" is backward. (Following regex syntax rather than abnf 
syntax). This ought to be:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" token *(" " identifier)
      token = 

Just following that:

    The semantic field may hold values from the IANA registries
    "Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the
    "group" SDP Attribute".

I have a couple of issues with this:

Section 5 defines a new registry "Semantics for the msid-semantic SDP 
attribute", and defines a new semantic "WMS" in it. The text above 
doesn't even reference this registry.

Because the two mentioned registries are independent, AFAIK there is no 
guarantee that they couldn't someday contain different definitions for 
the same "semantic" name. Then, if that name were used with msid the 
proper definition to use would be ambiguous. (I realize this is 
implausible, but nothing prevents it.) IMO the *right* answer would be 
to merge all these grouping semantics into a single table. But that is a 
hassle right now. Perhaps it would be sufficient to say that only 
semantics that are uniquely defined across all of these tables may be 
used with msid. E.g.,

    The semantic field may hold any value that is uniquely defined
    in one and only one of the IANA registries "Semantics for the
    msid-semantic SDP attribute", "Semantics for the "ssrc-group"
    SDP Attribute" and "Semantics for the "group" SDP Attribute".

	Thanks,
	Paul

On 10/30/13 3:13 AM, Harald Alvestrand wrote:
> Roni and Flemming pointed out that I hadn't managed to submit the fixes
> I made to -msid after the reviews of -01 before the deadline, and had
> even managed to forget to send it to the list.
>
> I had missed a number of occurences where "SSRC" needed to be changed to
> "m-line" in the text (with some more adjustments to language around that).
>
> Here it is. I'll submit it on Monday, when the I-D repository reopens.
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From jonathan@vidyo.com  Wed Oct 30 07:59: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 5785A21E8123 for ; Wed, 30 Oct 2013 07:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.83
X-Spam-Level: 
X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmuogilJyykw for ; Wed, 30 Oct 2013 07:58:59 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id B84FE21E80FC for ; Wed, 30 Oct 2013 07:58:54 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/30/2013 10:58:51 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-80/SG:2 10/30/2013 10:58:14 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.936771 p=-0.972943 Source White
X-Signature-Violations: 0-0-0-22859-c
X-Note-419: 15.6003 ms. Fail:0 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:0-1349/SG:1 10/30/2013 10:58:51 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 68926854; Wed, 30 Oct 2013 10:58:51 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 30 Oct 2013 09:58:50 -0500
From: Jonathan Lennox 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnwDfMHDAAAAR4DAAbprzgAANPvgQABjEPAA=
Date: Wed, 30 Oct 2013 14:58:49 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se> <279CF29F-E822-41C7-B32E-3AB5B8403D48@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1C4FBA42@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4FBA42@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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 Oct 2013 14:59:05 -0000

On Oct 30, 2013, at 4:11 AM, Christer Holmberg 
 wrote:

> Hi Jonathan,
>=20
>> This works as an outline, but I'm afraid it'll be too vague for solid in=
teroperability.
>=20
> At the end of the day, it is the receiver that informs the remote party w=
hich PT values it wants to receive, so if it chooses the same PT values it =
has to know that it is able to handle it.
>=20
> We COULD go even more into detail, but then I'm afraid we would have to s=
tart defining codec specific criteria etc, and I don't think we should go t=
hat way.

I don't want codec-specific criteria -- but I do want to know, e.g., whethe=
r PT-specific a=3Drtcp-fb: attributes MUST be aligned across bundled m-line=
s, or if they're free to vary, or what.

There are a bunch of SDP attributes that have PT-scoped properties.  I thin=
k this analysis needs to be added to the mux-attributes draft.

>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
> I think it works as a set of principles to guide discussion of PT-specifi=
c definitions in the mux-attributes draft, though.
>=20
> On Oct 27, 2013, at 5:03 PM, Christer Holmberg 
> wrote:
>=20
>> This time in non-HTML format.
>>=20
>> L=E4hett=E4j=E4: Christer Holmberg
>> L=E4hetetty: 27. lokakuuta 2013 23:03
>> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
>> Kopio: mmusic
>> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value=20
>> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for=20
>> single codec configuration)]
>>=20
>> Hi,
>>=20
>> It would be really great if those who have an opinion on this would=20
>> indicate whether they are ok with the approach below. Then we can=20
>> focus on where to document it :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org=
]=20
>> Puolesta Christer Holmberg
>> L=E4hetetty: 23. lokakuuta 2013 13:37
>> Vastaanottaja: Bo Burman; Jonathan Lennox
>> Kopio: mmusic
>> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage=20
>> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec=20
>> configuration)]
>>=20
>> Hi,
>>=20
>> Below is a copy of the current text in my Vancouver slide regarding the =
criteria for PT value re-usage in multiple m- lines within a BUNDLE group.
>>=20
>> It is based on the ideas provided by Jonathan L and Bo B.
>>=20
>> As you can see, apart from the rtpmap and fmtp attributes, it is not pos=
sible to define an exclusive list of attributes that must be identical. Suc=
h lists may also be codec dependent. Instead, the text talks more generally=
 about memory and buffer sizes.
>>=20
>>=20
>>> REQUIREMENTS
>> - Decoder agnostic
>>> It shall be possible to switch decoders between media flows using the=20
>>> same PT value
>> - Codec agnostic
>>> The criteria shall be applicable to any codec CRITERIA
>> - SDP rtpmap and fmtp attribute values must be equal (order of=20
>> attribute parameters not significant)
>>> All parameters must be included
>> - Explictily
>> - Implicitly, if a default value is defined for the parameter
>>> Parameters not included are assigned their default values (if=20
>>> defined)
>> - Decoder maximum memory and buffer sizes shall be assumed to match
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>>=20
>>=20
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Christer Holmberg
>> Sent: 16. lokakuuta 2013 12:12
>> To: Bo Burman; Jonathan Lennox
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
>> value for single codec configuration
>>=20
>> Hi Bo,
>>=20
>> Thanks for your input!
>>=20
>> I'd ask anyone who might have an opinion about this to take a look at=20
>> the proposal, comment on the list if needed, and hopefully we can=20
>> agree on way forward in Vancouver (or, even earlier :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> From: Bo Burman
>> Sent: 16. lokakuuta 2013 11:44
>> To: Christer Holmberg; Jonathan Lennox
>> Cc: mmusic
>> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
>> value for single codec configuration
>>=20
>> Hi,
>>=20
>> I agree with Jonathan that in order to make two PT values "equal", their=
 rtpmap and fmtp lines must be equal, as a start.
>>=20
>> I don't think there is any "correct" criterion that can be used to judge=
 PT for equality, but we just have to decide on a "reasonable" one that is =
as simple as possible without causing any major problems.
>>=20
>> I have assumed a conceptual equality criterion where PT value A should b=
e considered equal to another PT value B if an RTP stream with PT A can be =
fed into a decoder stack configured with PT B, and vice versa, without caus=
ing either decoder stack to "break".
>>=20
>> I don't think we should require the fmtp lines are textually equal, but =
only that the same parameters are present and have the same values. The ord=
er of the parameters on the fmtp line does not matter. There is also the ca=
se when a parameter is specified with the default value for one PT and omit=
ted for the other. To identify those as equal, which they semantically are,=
 would require an "equality parser" to know every default value of every fm=
tp parameter for all codecs. This seems unreasonable.
>>=20
>> Regarding Jonathan's question on H.264 sprop-., I guess they don't stric=
tly need to be equal to make the PTs equal, but they may have to be. They e=
ffectively configure the decoder in some way and if there is a mismatch, th=
e decoding process will likely break; like mis-interpretations or buffer ov=
erflows. On the other hand, some sprop-. can be updated by in-band informat=
ion, overriding what is specified on the fmtp line, and in this case the fm=
tp line sprop-. information is obsolete. Requiring that all fmtp of the lin=
e is equal however makes a simple rule, which should be preferable and I do=
n't think it is too restrictive or excessive.
>>=20
>> However, if the potentially equal PT values are defined as part of diffe=
rent media descriptions, other media level attributes also contribute to th=
e decoder stack configuration. Some attributes, like maxptime, can clearly =
cause problems (in this case buffer overflow) if it differs. Others, like p=
time, framerate and imageattr are more of a receiver preference within a mo=
re formal "conformance point" and would not "break" a decoder stack if they=
 differ.
>>=20
>> I agree it can be a good idea to add some text into the mux-attributes d=
raft about attributes that have to be the same to consider two PT in differ=
ent media descriptions to be "equal", of course given that rtpmap and fmtp =
are also equal.
>>=20
>> /Bo
>>=20
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Christer Holmberg
>> Sent: den 11 september 2013 09:12
>> To: Jonathan Lennox
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
>> value for single codec configuration
>>=20
>> Hi,
>>=20
>> It would be so easy if we could define the PT mappings on the SDP=20
>> session level, and then simply refer to them within the m- lines :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
>> Sent: 10. syyskuuta 2013 22:18
>> To: Christer Holmberg
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
>> value for single codec configuration
>>=20
>> My strawman proposal at the mic in Berlin was that a codec configuration=
 is defined by the top-level media type of the m=3D line and the content of=
 a given PT value's rtpmap and fmtp lines.  I.e., the full media type, with=
 all its parameters.
>>=20
>> The questions I would have to this straw man are:
>>=20
>> * Is this excessive?  E.g., should items like H.264's sprop- parameters =
be allowed to differ across m=3D line blocks?
>>=20
>> * Is this sufficient?  Should other items (sometimes) indexed by PT (e.g=
., the imageattr, rtcp-fb, or extmap attributes) need to be the same across=
 m-lines as well?
>>=20
>> My suggestion would be that this work should be folded into the work bei=
ng done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should =
be integrated with BUNDLE).  Currently (I believe) the mux-attributes draft=
 assumes that PTs are unique across m-lines, so this work is going to imply=
 changes to the analysis of a number of attributes in that draft, regardles=
s.  Probably a new category will need to be defined for attributes which ha=
ve to be consistent per payload type.
>>=20
>> On Sep 10, 2013, at 5:56 AM, Christer Holmberg  wrote:
>>=20
>>=20
>> Hi,
>>=20
>> Below is the "official" (from the minutes) outcome of questions Q1,Q2 an=
d Q7 in Berlin.
>>=20
>> Questions:
>>=20
>> Q1: "Can we agree that, within a BUNDLE group (including all m- lines as=
sociated with the group), any given PT value can only be used for a single =
codec configuration?"
>> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there =
are opinions that simply referencing RFC 3550 might not be clear enough?"
>> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value i=
n multiple RTP m- lines, for the SAME codec configuration?"
>>=20
>> Outcome:
>>=20
>> Q1: Yes
>> Q2: Yes, Lennox will send suggested text to clarify the term "codec conf=
iguration".
>> Q7: Yes.
>>=20
>> So, again, we need definition text for "codec configuration". Jonathan p=
romised to submit something, but anyone is of course welcome to do that.
>>=20
>> The other alternative is to not say anything about PT value usages withi=
n the scope of BUNDLE, but that is not what the meeting wanted.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Christer Holmberg
>> Sent: 23. elokuuta 2013 13:53
>> To: mmusic
>> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
>> value for single codec configuration
>>=20
>> Hi,
>>=20
>> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and=
 Q7 in my slides) was regarding the usage of any given PT value.
>>=20
>> My take of the outcome was that:
>>=20
>> -          We agreed that any given PT value can only be used for a sing=
le codec configuration (Q1)
>> -          We agreed that we need some definition text for "codec config=
uration" (Q2)
>> -          We agreed that, within a BUNDLE group, any given PT value can=
 be used in multiple m- lines, as long as it is used for a single codec con=
figuration (Q7).
>>=20
>> Jonathan Lennox promised to suggest some definition text for "codec conf=
iguration", so let's wait for that until we go into those discussions.
>>=20
>> But, if you have any issues with the agreements in general, please=20
>> bring them up :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>>=20
>>=20
>> --
>> Jonathan Lennox
>> jonathan@vidyo.com
>>=20
>=20


From christer.holmberg@ericsson.com  Wed Oct 30 08:03: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 CAD7611E8143 for ; Wed, 30 Oct 2013 08:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.751
X-Spam-Level: 
X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnajY-IXOZOU for ; Wed, 30 Oct 2013 08:03:24 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F51211E8298 for ; Wed, 30 Oct 2013 08:03:13 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-9e-52711fb1d12f
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 45.DD.09019.1BF11725; Wed, 30 Oct 2013 16:03:13 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 30 Oct 2013 16:03:13 +0100
From: Christer Holmberg 
To: Jonathan Lennox 
Thread-Topic: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnwDfMHDAAAAR4DAAbprzgAANPvgQABjEPAAACmIL8A==
Date: Wed, 30 Oct 2013 15:03:11 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FD2F3@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se> <279CF29F-E822-41C7-B32E-3AB5B8403D48@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1C4FBA42@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvje5G+cIgg9OdYhb7F59ntpi6/DGL A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4Mr4/WgTU8GMyIo7VzrYGhjXuXcxcnJICJhI XOpYwgRhi0lcuLeerYuRi0NI4AijxIFd55khnCWMEl8/dLB0MXJwsAlYSHT/0wZpEBHQkLj4 7AMbiM0s4CDxav1tdpB6YYFljBL9rxeBTRIRWM4ocfXAb1aQZhGBMIkT28tAGlgEVCWmbp4G tplXwFdi3buVTBDLdjNJLN+1ixkkwSlgK7Hh5VZWEJsR6Lzvp9YwQWwTl7j1ZD7U2QISS/ac Z4awRSVePv7HCmErSnx8tY8Rol5P4sbUKVCXakssW/iaGWKxoMTJmU9YJjCKzUIydhaSlllI WmYhaVnAyLKKkaM4tTgpN93IYBMjMFIObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamBsE7gdFaq+t2/ByfvMwVN7/2v+n/DBevls103lvKJVm5ZwMm3e t3Fp0nbxZtvvDcJczn8U366OXbbUKotD033jpYYXMx6HPe5h6zhUMVHmzz9Dsd9Pdiw72sYp l7rtp+sK9dL6w3VPjI0UjNynr/zhbHLlSMSXmxt/rShk3RIo4ui/sHv/vweWSizFGYmGWsxF xYkAGEYAeGICAAA=
Cc: mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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 Oct 2013 15:03:30 -0000

Hi,

>>> This works as an outline, but I'm afraid it'll be too vague for solid i=
nteroperability.
>>=20
>> At the end of the day, it is the receiver that informs the remote party =
which PT values it wants to receive, so if it chooses the same PT values it=
 has to know that it is able to handle it.
>>=20
>> We COULD go even more into detail, but then I'm afraid we would have to =
start defining codec specific criteria etc, and I don't think we should go =
that way.
>
> I don't want codec-specific criteria -- but I do want to know, e.g., whet=
her PT-specific a=3Drtcp-fb: attributes MUST be aligned across bundled m-li=
nes, or if they're free to vary, or what.
>
> There are a bunch of SDP attributes that have PT-scoped properties.  I th=
ink this analysis needs to be added to the mux-attributes draft.

I am not so worried about where we'll document it - first I want us to agre=
e on some criteria :)

I DO agree, though, that we probably need to go through the PT-scoped attri=
butes.

Regards,

Christer



> I think it works as a set of principles to guide discussion of PT-specifi=
c definitions in the mux-attributes draft, though.
>=20
> On Oct 27, 2013, at 5:03 PM, Christer Holmberg=20
> 
> wrote:
>=20
>> This time in non-HTML format.
>>=20
>> L=E4hett=E4j=E4: Christer Holmberg
>> L=E4hetetty: 27. lokakuuta 2013 23:03
>> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
>> Kopio: mmusic
>> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value=20
>> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for=20
>> single codec configuration)]
>>=20
>> Hi,
>>=20
>> It would be really great if those who have an opinion on this would=20
>> indicate whether they are ok with the approach below. Then we can=20
>> focus on where to document it :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org=
]=20
>> Puolesta Christer Holmberg
>> L=E4hetetty: 23. lokakuuta 2013 13:37
>> Vastaanottaja: Bo Burman; Jonathan Lennox
>> Kopio: mmusic
>> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value=20
>> re-usage
>> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec=20
>> configuration)]
>>=20
>> Hi,
>>=20
>> Below is a copy of the current text in my Vancouver slide regarding the =
criteria for PT value re-usage in multiple m- lines within a BUNDLE group.
>>=20
>> It is based on the ideas provided by Jonathan L and Bo B.
>>=20
>> As you can see, apart from the rtpmap and fmtp attributes, it is not pos=
sible to define an exclusive list of attributes that must be identical. Suc=
h lists may also be codec dependent. Instead, the text talks more generally=
 about memory and buffer sizes.
>>=20
>>=20
>>> REQUIREMENTS
>> - Decoder agnostic
>>> It shall be possible to switch decoders between media flows using=20
>>> the same PT value
>> - Codec agnostic
>>> The criteria shall be applicable to any codec CRITERIA
>> - SDP rtpmap and fmtp attribute values must be equal (order of=20
>> attribute parameters not significant)
>>> All parameters must be included
>> - Explictily
>> - Implicitly, if a default value is defined for the parameter
>>> Parameters not included are assigned their default values (if
>>> defined)
>> - Decoder maximum memory and buffer sizes shall be assumed to match
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>>=20
>>=20
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Christer Holmberg
>> Sent: 16. lokakuuta 2013 12:12
>> To: Bo Burman; Jonathan Lennox
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific=20
>> PT value for single codec configuration
>>=20
>> Hi Bo,
>>=20
>> Thanks for your input!
>>=20
>> I'd ask anyone who might have an opinion about this to take a look at=20
>> the proposal, comment on the list if needed, and hopefully we can=20
>> agree on way forward in Vancouver (or, even earlier :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> From: Bo Burman
>> Sent: 16. lokakuuta 2013 11:44
>> To: Christer Holmberg; Jonathan Lennox
>> Cc: mmusic
>> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific=20
>> PT value for single codec configuration
>>=20
>> Hi,
>>=20
>> I agree with Jonathan that in order to make two PT values "equal", their=
 rtpmap and fmtp lines must be equal, as a start.
>>=20
>> I don't think there is any "correct" criterion that can be used to judge=
 PT for equality, but we just have to decide on a "reasonable" one that is =
as simple as possible without causing any major problems.
>>=20
>> I have assumed a conceptual equality criterion where PT value A should b=
e considered equal to another PT value B if an RTP stream with PT A can be =
fed into a decoder stack configured with PT B, and vice versa, without caus=
ing either decoder stack to "break".
>>=20
>> I don't think we should require the fmtp lines are textually equal, but =
only that the same parameters are present and have the same values. The ord=
er of the parameters on the fmtp line does not matter. There is also the ca=
se when a parameter is specified with the default value for one PT and omit=
ted for the other. To identify those as equal, which they semantically are,=
 would require an "equality parser" to know every default value of every fm=
tp parameter for all codecs. This seems unreasonable.
>>=20
>> Regarding Jonathan's question on H.264 sprop-., I guess they don't stric=
tly need to be equal to make the PTs equal, but they may have to be. They e=
ffectively configure the decoder in some way and if there is a mismatch, th=
e decoding process will likely break; like mis-interpretations or buffer ov=
erflows. On the other hand, some sprop-. can be updated by in-band informat=
ion, overriding what is specified on the fmtp line, and in this case the fm=
tp line sprop-. information is obsolete. Requiring that all fmtp of the lin=
e is equal however makes a simple rule, which should be preferable and I do=
n't think it is too restrictive or excessive.
>>=20
>> However, if the potentially equal PT values are defined as part of diffe=
rent media descriptions, other media level attributes also contribute to th=
e decoder stack configuration. Some attributes, like maxptime, can clearly =
cause problems (in this case buffer overflow) if it differs. Others, like p=
time, framerate and imageattr are more of a receiver preference within a mo=
re formal "conformance point" and would not "break" a decoder stack if they=
 differ.
>>=20
>> I agree it can be a good idea to add some text into the mux-attributes d=
raft about attributes that have to be the same to consider two PT in differ=
ent media descriptions to be "equal", of course given that rtpmap and fmtp =
are also equal.
>>=20
>> /Bo
>>=20
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Christer Holmberg
>> Sent: den 11 september 2013 09:12
>> To: Jonathan Lennox
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific=20
>> PT value for single codec configuration
>>=20
>> Hi,
>>=20
>> It would be so easy if we could define the PT mappings on the SDP=20
>> session level, and then simply refer to them within the m- lines :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
>> Sent: 10. syyskuuta 2013 22:18
>> To: Christer Holmberg
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific=20
>> PT value for single codec configuration
>>=20
>> My strawman proposal at the mic in Berlin was that a codec configuration=
 is defined by the top-level media type of the m=3D line and the content of=
 a given PT value's rtpmap and fmtp lines.  I.e., the full media type, with=
 all its parameters.
>>=20
>> The questions I would have to this straw man are:
>>=20
>> * Is this excessive?  E.g., should items like H.264's sprop- parameters =
be allowed to differ across m=3D line blocks?
>>=20
>> * Is this sufficient?  Should other items (sometimes) indexed by PT (e.g=
., the imageattr, rtcp-fb, or extmap attributes) need to be the same across=
 m-lines as well?
>>=20
>> My suggestion would be that this work should be folded into the work bei=
ng done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should =
be integrated with BUNDLE).  Currently (I believe) the mux-attributes draft=
 assumes that PTs are unique across m-lines, so this work is going to imply=
 changes to the analysis of a number of attributes in that draft, regardles=
s.  Probably a new category will need to be defined for attributes which ha=
ve to be consistent per payload type.
>>=20
>> On Sep 10, 2013, at 5:56 AM, Christer Holmberg  wrote:
>>=20
>>=20
>> Hi,
>>=20
>> Below is the "official" (from the minutes) outcome of questions Q1,Q2 an=
d Q7 in Berlin.
>>=20
>> Questions:
>>=20
>> Q1: "Can we agree that, within a BUNDLE group (including all m- lines as=
sociated with the group), any given PT value can only be used for a single =
codec configuration?"
>> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there =
are opinions that simply referencing RFC 3550 might not be clear enough?"
>> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value i=
n multiple RTP m- lines, for the SAME codec configuration?"
>>=20
>> Outcome:
>>=20
>> Q1: Yes
>> Q2: Yes, Lennox will send suggested text to clarify the term "codec conf=
iguration".
>> Q7: Yes.
>>=20
>> So, again, we need definition text for "codec configuration". Jonathan p=
romised to submit something, but anyone is of course welcome to do that.
>>=20
>> The other alternative is to not say anything about PT value usages withi=
n the scope of BUNDLE, but that is not what the meeting wanted.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20
>> Behalf Of Christer Holmberg
>> Sent: 23. elokuuta 2013 13:53
>> To: mmusic
>> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=20
>> value for single codec configuration
>>=20
>> Hi,
>>=20
>> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and=
 Q7 in my slides) was regarding the usage of any given PT value.
>>=20
>> My take of the outcome was that:
>>=20
>> -          We agreed that any given PT value can only be used for a sing=
le codec configuration (Q1)
>> -          We agreed that we need some definition text for "codec config=
uration" (Q2)
>> -          We agreed that, within a BUNDLE group, any given PT value can=
 be used in multiple m- lines, as long as it is used for a single codec con=
figuration (Q7).
>>=20
>> Jonathan Lennox promised to suggest some definition text for "codec conf=
iguration", so let's wait for that until we go into those discussions.
>>=20
>> But, if you have any issues with the agreements in general, please=20
>> bring them up :)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>>=20
>>=20
>> --
>> Jonathan Lennox
>> jonathan@vidyo.com
>>=20
>=20


From jonathan@vidyo.com  Wed Oct 30 12:27: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 9262511E8240 for ; Wed, 30 Oct 2013 12:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level: 
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1ApzvgN7POX for ; Wed, 30 Oct 2013 12:27:31 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9311E8254 for ; Wed, 30 Oct 2013 12:27:25 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/30/2013 3:27:25 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-52/SG:2 10/30/2013 3:27:20 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.944879 p=-0.974573 Source White
X-Signature-Violations: 0-0-0-5395-c
X-Note-419: 0 ms. Fail:0 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:0-1349/SG:1 10/30/2013 3:27:09 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 69052470; Wed, 30 Oct 2013 15:27:25 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 30 Oct 2013 14:27:24 -0500
From: Jonathan Lennox 
To: Martin Thomson 
Thread-Topic: [MMUSIC] comments on draft-even-mmusic-application-token-01
Thread-Index: AQHO1LyRHByVr0dAA0OEs67Y08GtvZoMh76AgAAHP4CAAWd5gA==
Date: Wed, 30 Oct 2013 19:27:23 +0000
Message-ID: 
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <74007CAAB573654D989CC5CDAA5D3916@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , Paul Kyzivat 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Wed, 30 Oct 2013 19:27:37 -0000

On Oct 29, 2013, at 6:00 PM, Martin Thomson 
 wrote:

> On 29 October 2013 14:34, Jonathan Lennox  wrote:
>=20
>> In particular, I think, RTX and single-stream-repair FEC streams should =
probably be associated to their primary stream using appid.  (Multi-stream-=
repair FEC is more complicated, as the draft discusses.  Yes, we probably s=
houldn't have jumped to the more complicated case so quickly in the example=
s.)
>=20
> The SDES extension or RTP extension could identify an SSRC as
> contributing to multiple sources in those complicated scenarios.  The
> simple case is where each SSRC contributes to just a single source.
> Maybe that's too much information for an RTP extension, in which case
> you could send the appid indications for each source a) when the
> contribution commences - i.e., at the start of transmission; and b)
> interleaved when there is more than one appid.  That assumes that the
> SSRC can't ever stop contributing to a given source, which I think is
> a safe assumption.

Hi, Martin -- there are several separate issues here, which it's good to ke=
ep separate.

One is that a set of streams can make up a single source, associated with a=
 single appid, as in RTX and FEC.  Each stream is associated to a single so=
urce in this sense, except in multi-stream-repair FEC cases.

However, which source corresponds to an appid can change dynamically.  The =
primary use case I personally see for this is loudest-speaker switching, wh=
ere the appid corresponds to a requested loudest speaker.

More controversially, I've also proposed that a single source can satisfy m=
ore than one appid at a time -- as in the case when you've requested both m=
y video, and the current loudest speaker video, and right now I'm the curre=
nt loudest speaker.=

From jonathan@vidyo.com  Wed Oct 30 12:47: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 C814111E81E4 for ; Wed, 30 Oct 2013 12:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.565
X-Spam-Level: 
X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3UsmBlrjbTe for ; Wed, 30 Oct 2013 12:47:32 -0700 (PDT)
Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id D470311E8110 for ; Wed, 30 Oct 2013 12:47:26 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/30/2013 3:47:24 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-108/SG:2 10/30/2013 3:46:35 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.859683 p=-0.973321 Source White
X-Signature-Violations: 0-0-0-12234-c
X-Note-419: 62.4008 ms. Fail:0 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:0-1349/SG:1 10/30/2013 3:47:24 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNKNOWN->LOCAL
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: 
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 44162981; Wed, 30 Oct 2013 15:47:24 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 30 Oct 2013 14:47:23 -0500
From: Jonathan Lennox 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] comments on draft-even-mmusic-application-token-01
Thread-Index: AQHO1LyRHByVr0dAA0OEs67Y08GtvZoMh76AgAAIVQCAAWv4AA==
Date: Wed, 30 Oct 2013 19:47:22 +0000
Message-ID: <134F9A0D-5C8C-43C8-B18F-5BE5F0C59BBE@vidyo.com>
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com> <527030F8.80509@alum.mit.edu>
In-Reply-To: <527030F8.80509@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Wed, 30 Oct 2013 19:47:41 -0000

On Oct 29, 2013, at 6:04 PM, Paul Kyzivat 
 wrote:

> Jonathan,
>=20
> Thanks for the clarifications. I have more questions.
>=20
> On 10/29/13 5:34 PM, Jonathan Lennox wrote:
>> Hi, Paul --
>>=20
>> On Oct 29, 2013, at 11:36 AM, Paul Kyzivat 
>>  wrote:
>>=20
>>> Roni,
>>>=20
>>> I'm still not sure I understand. I'm going to repeat my characterizatio=
n about what I understand one more time:
>>>=20
>>> - an RTP session MAY have one or more aphid tokens
>>=20
>> Yes.
>>=20
>>> - at any point in time each appid token maps to at most
>>>  one stream (SSRC) within the session.
>>=20
>> This one isn't right.  An appid maps to at most one *source* -- but in s=
ituations where multiple streams (SSRCs) make up one source, in some cases =
we'll want them to be associated by having them have the same appid.
>=20
> I thought that in RPT terms a source is equivalent to an SSRC.
> Are you talking about a "Media Source" according to the taxonomy?

Right, yes; I'm trying to follow the taxonomy's terminology distinction.

> If an appid could only map to *one* ssrc, then changes are easy - when yo=
u get a new mapping then the old one goes away.
>=20
> But if an appid can map to multiple SSRCs, then that complicates changing=
 the mapping. Getting a mapping of the same appid to a new ssrc doesn't nec=
essarily invalidate any old mappings. It might be necessary to explicitly u=
nmap it. I don't see how you would do that.


>> In particular, I think, RTX and single-stream-repair FEC streams should =
probably be associated to their primary stream using appid.  (Multi-stream-=
repair FEC is more complicated, as the draft discusses.  Yes, we probably s=
houldn't have jumped to the more complicated case so quickly in the example=
s.)
>=20
> I presume it doesn't make sense to give two arbitrary SSRCs the same appi=
d. Is there a way to revise/replace this statement with one that is correct=
 and says something useful?
>=20

Hm, that's a good point.

I think the right formulation is that, in the terminology of the latest tax=
onomy draft, an appid (at any given time) encompasses a single Source Packe=
t Stream and its associated Redundancy Packet Streams.

In all cases I know about, it's possible to differentiate Source Packet Str=
eams from Redundancy Packet Streams by payload type.

There is still an issue of getting the grouping of these streams correct wh=
en an appid changes sources, though; this will need a little bit of thought=
.

>> However, it's not as simple as saying that the same appid applies to all=
 the streams of the source.
>>=20
>> The important cases where a single source's streams will be split across=
 multiple appid values are simulcast and MST layered codecs.  An important =
use case of appid is to disambiguate the various simulcast streams and laye=
rs; however, in the taxonomy draft's terminology these are a single source,=
 and Unified puts them into a single m-line.  It's not clear to me yet how =
Unified is planning to signal these cases (I know Magnus has a proposal, bu=
t I haven't read it in detail yet), but appid will need to be able to handl=
e it.
>=20
> ISTM that it is important to distinguish valid mappings from invalid ones=
.

Right, I agree.

>>> - new appid:ssrc mappings MAY be initialized via receipt
>>>  of the new RTPC SDES message or header extension
>>=20
>> Yes.  Only for appid values whose semantics are already specified (witho=
ut an SSRC mapping) in SDP or elsewhere, however; otherwise there's no sema=
ntics to attach them to.  (Early media cases may need more thought here.)
>=20
> I'm not sure I follow this.
>=20
> Suppose there was nothing in SDP. But a new appid shows up in RTCP SDES. =
It could (via a common value) tie together a raw stream with an RTX or FEC =
stream. It just doesn't say what it is used for. But putting it in SDP does=
n't say what it is used for either.
>=20
> In CLUE, the semantics could be in an Advertisement. (But, if we use an S=
DP label to reference an encoding, then I guess we would need the appid in =
the SDP too in order to tie those together.)

My point is that if you receive an appid in RTP that you've never heard of =
in signaling (whichever signaling you're using), you don't know what it mea=
ns and can't do anything useful with it.  Thus my early-media analogy -- po=
ssibly you can assume that signaling describing the appid is forthcoming.

>>> - existing appid:ssrc mappings MAY be updated via
>>>  receipt of the new RTCP SDES message or header extension.
>>=20
>> Yes.
>=20
> I'm still concerned about appid:ssrc mappings in subsequent offers/answer=
s. If the first O/A defined one mapping, and a subsequent O/A revised that =
(different ssrc for the same appid) would that mapping change take effect?
>=20
> Would the answer change depending on whether any media has been send/rece=
ived with that ssrc?
>=20
> Would the answer change depending on whether the mapping has been updated=
 via RTCP SDES message or header extension?

My inclination would be to say that if you've ever sent a mapping for an ap=
pid in RTP/RTCP, don't put an appid:ssrc mapping into subsequent offer/answ=
er messages.  From a receiver point of view, this is equivalent to saying t=
hat appid:ssrc mappings in SDP are ignored if you've received mappings in R=
TP/RTCP.

I don't think RTP and RTCP should be distinguished in this respect.=

From martin.thomson@gmail.com  Wed Oct 30 15:25: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 37CA211E8287 for ; Wed, 30 Oct 2013 15:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMnSBsjaBYVX for ; Wed, 30 Oct 2013 15:24:58 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6FB21E8092 for ; Wed, 30 Oct 2013 15:24:49 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t61so1907905wes.20 for ; Wed, 30 Oct 2013 15:24:48 -0700 (PDT)
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=EFC5oWfntkwpdDbt6HIaNAaroDrGnrIrWqBNO77GAk4=; b=tqvVaa5cYapBFlhyduu4YW1qiq39HmnoYvC5ivJd+4lgOpdX+G8bvAKEJcpnRoHRwY r8KTYJfcb5oY8hixhzO9ZZ4aT+Cu494S0Xx3CkrfuJaLCPi0qAjVHmi4DKe66YJx6YVm CBW3d/FVBfECV5Rk8fD8+KuJ3R3hfBAoOUDgO7fufpxZwE3frBbUPpvfrVlf6ECBzLIq Jcf9pIRmlT5sF5oqGjyW4WdnNMH2bcJn/vJd+DjA24sIBY5z9CfBRnrZle2nQ3jouP1z iR7dTqKm/5O5jVlZzwGTJs3+yppIvADMCGiHl88ZP76AHiR08V6kWxz8vmI0DZNe89/S aPLA==
MIME-Version: 1.0
X-Received: by 10.180.9.139 with SMTP id z11mr4099614wia.22.1383171888381; Wed, 30 Oct 2013 15:24:48 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Wed, 30 Oct 2013 15:24:48 -0700 (PDT)
In-Reply-To: 
References: <526D5CDD.40805@alum.mit.edu>  <526D8FA3.1030503@alum.mit.edu>  <019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com>  
Date: Wed, 30 Oct 2013 15:24:48 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Cc: "" , Paul Kyzivat 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Wed, 30 Oct 2013 22:25:08 -0000

On 30 October 2013 12:27, Jonathan Lennox  wrote:
> However, which source corresponds to an appid can change dynamically.  The primary use case I personally see for this is loudest-speaker switching, where the appid corresponds to a requested loudest speaker.

This is the one that I didn't see as needing appid.  I'm comfortable
with the fact that a single appid can have multiple SSRCs.  That's
fairly easy.

I'm concerned now that this is conflating this other need, namely the
need to track a thing that migrates between SSRCs (or groups thereof)
over time.  Conflation like this complicates things.

From suhasietf@gmail.com  Wed Oct 30 21:46: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 ECDA611E81F3 for ; Wed, 30 Oct 2013 21:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level: 
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnNPocdp64EY for ; Wed, 30 Oct 2013 21:46:46 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8488911E81C7 for ; Wed, 30 Oct 2013 21:46:31 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so2198853wes.1 for ; Wed, 30 Oct 2013 21:46:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=u4wy7JMkLOpyJK81cVfOPjlsyUnc0TIOMZdODXWrIZU=; b=KtG7A0nxveVIjXd4m/v9obKoc7ORrji5OODNp/8k4w+I7Z2WaXQuufPUz1X/0fahzE cS9hLRn+zJssLjoYS87B4AQXmbBOH+AoNNpzGbOpOHlaHspielXw/UmDBzoUZGtrpCO9 iut0u6TbBACtQ/uVDtofoRcm9SsMrgIBX3JSFME7isYYxJrSHu39bx/2jv5k6xVK3HeG E1WSTkP7uZsZjxYKkfNyWFQy82Ho+mXkMt55Y0sVrBuyxtGRvNVt0If/ZhWn9sIgcjlD S8CDRv/cix6P4AeqYXbL0fVc6oFOBy4Ca7r00H3LCsLajRZ/PaQH22Uf6s2tT037uuSJ AiVw==
MIME-Version: 1.0
X-Received: by 10.180.99.99 with SMTP id ep3mr841486wib.11.1383194787165; Wed, 30 Oct 2013 21:46:27 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Wed, 30 Oct 2013 21:46:27 -0700 (PDT)
Date: Wed, 30 Oct 2013 21:46:27 -0700
Message-ID: 
From: Suhas Nandakumar 
To: mmusic WG 
Content-Type: multipart/alternative; boundary=f46d044283c0f1bdae04ea0221f2
Cc: Cullen Jennings , Harald Alvestrand , Christer Holmberg 
Subject: [MMUSIC] BUNDLE/SDP : ISSUE#2: Should BUNDLE allow/disallow SSRC Repetition ?
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 Oct 2013 04:46:48 -0000

--f46d044283c0f1bdae04ea0221f2
Content-Type: text/plain; charset=ISO-8859-1

Hello All

  Another issue or concern that was brought up is dealing with RFC5576 SSRC
attributes across the BUNDLED m=lines.

RFC5576 does allow SSRCs to be repeated across the m=lines given that each
m=line forms a separate RTP Session.

There were two options suggested in this regard (by Jonathan)

1. Don't allow SSRC values to be repeated across the bundled m-lines
    ==> Assign category NORMAL

2. Allow SSRC values to be repeated iff the media stream satisfies more
than one m=lines, in which case, the individual sources define the behavior
  ==> We have 3 options here
   2.1 Assign Category SPECIAL and add explanatory note on possible
scenarios

   2.2 Assign Category SPECIAL and propose an update to RFC5576 to explain
behavior of a=ssrc attributes when multiple m=lines are multiplexed

   2.3 Define a new category ??


I look forward for your inputs on how do we deal with this issue.


Cheers
Suhas

--f46d044283c0f1bdae04ea0221f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello All

=A0 Another issue or concern =
that was brought up is dealing with RFC5576 SSRC attributes across the BUND=
LED m=3Dlines.

RFC5576 does allow SSRCs to be repe=
ated across the m=3Dlines given that each m=3Dline forms a separate RTP Ses=
sion.




There were two options suggested in this regard (by Jon=
athan)

1. Don't allow SSRC values to be repeat=
ed across the bundled m-lines
=A0 =A0 =3D=3D> Assign category =
NORMAL



2. Allow SSRC values to be repeated iff the media strea=
m satisfies more than one m=3Dlines, in which case, the individual sources =
define the behavior
=A0 =3D=3D> We have 3 options here
=A0 =A02.1 Assign Category SPECIAL and add explanatory note on possible =
scenarios=A0



=A0 =A02.2 Assign Category SPECIAL and propose an updat=
e to RFC5576 to explain behavior of a=3Dssrc attributes when multiple m=3Dl=
ines are multiplexed

=A0 =A02.3 Define a new categ=
ory ??=A0




I look forward for your inputs on how do=
 we deal with this issue.


Cheers
Suhas


--f46d044283c0f1bdae04ea0221f2--

From suhasietf@gmail.com  Wed Oct 30 21:52: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 11FE811E8246 for ; Wed, 30 Oct 2013 21:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level: 
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WeSVjw9N-Qa for ; Wed, 30 Oct 2013 21:52:45 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21811E819C for ; Wed, 30 Oct 2013 21:52:45 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id b13so6864734wgh.2 for ; Wed, 30 Oct 2013 21:52:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oGkr85JcANk3f+WTs291xAtshf47JjDynfqHQIjo7HA=; b=tSmdoNwtwjBZSbsJtWDdwTsBcTf/+EImsMVeY731PF/vVIevOhmPmXCoBg4zkx28y8 LZ9AJDEZckSA9Tu+4czWn8dYeeTWG/pijIg+G5tPrGfnoFH2fK7x1gqa75JEENqnutdM 4o62ixkNRexiLHvzUa6FArhd3clP4qLS0loQ4NTbovGQz5O7FQvBUXYYXrh9Qt1zt75L yc75SYbPkiffpJggc7LFzhVxDsAfpWmYWTTwJAg8e5aASByiE1uQTYrKaXoBwkUfreUV c5rW1Vnahi6GbKVCF59Y0SqnsiMcbN3cFxmLX1XTldRSjhK0IfsQKjDIMrSW+9X2uxkF DUSw==
MIME-Version: 1.0
X-Received: by 10.194.20.170 with SMTP id o10mr984159wje.4.1383195163245; Wed, 30 Oct 2013 21:52:43 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Wed, 30 Oct 2013 21:52:43 -0700 (PDT)
Date: Wed, 30 Oct 2013 21:52:43 -0700
Message-ID: 
From: Suhas Nandakumar 
To: mmusic WG 
Content-Type: multipart/alternative; boundary=047d7b5d5c825c43f304ea023834
Cc: Cullen Jennings , Harald Alvestrand , Christer Holmberg 
Subject: [MMUSIC] BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
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 Oct 2013 04:52:46 -0000

--047d7b5d5c825c43f304ea023834
Content-Type: text/plain; charset=ISO-8859-1

Hello All

  Magnus raised an important question while analyzing  RFC6064 SDP
attributes related to RTSP SDP attributes for 3GPP.  Since these attributes
are declaratively used, SHOULD BUNDLE be dealing with specifying the
behavior in Non Offer/Answer Scenarios ?

If the answer is NO, we can assign category to be NOT IMPACTED for these
attributes,

If the answer is YES, i think there needs to be more discussions on
handling this scenario.

Please let me know your thoughts.


Cheers
Suhas

--047d7b5d5c825c43f304ea023834
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello All

=A0 Magnus raised an importan=
t question while analyzing =A0RFC6064 SDP attributes related to RTSP SDP at=
tributes for 3GPP. =A0Since these attributes are declaratively used, SHOULD=
 BUNDLE be dealing with specifying the behavior in Non Offer/Answer Scenari=
os ?



If the answer is NO, we can assign category to be NOT I=
MPACTED for these attributes,

If the answer is YES=
, i think there needs to be more discussions on handling this scenario.


Please let me know your thoughts.

<=
div>
Cheers
Suhas


--047d7b5d5c825c43f304ea023834--

From suhasietf@gmail.com  Wed Oct 30 22:14: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 366E411E82CB for ; Wed, 30 Oct 2013 22:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.183
X-Spam-Level: 
X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJFMQG5V1utz for ; Wed, 30 Oct 2013 22:14:24 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id AB80211E81C7 for ; Wed, 30 Oct 2013 22:14:23 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f4so2458498wiw.4 for ; Wed, 30 Oct 2013 22:14:22 -0700 (PDT)
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=OsIbErvyi16qk2Aw9WdD2YpFDMArgh1WTqM6yumut2I=; b=gRKLb8wTZdhMXQ+YlZfxp4b7bnIxjF63hauebPlmzkoEtGjHxjaORPVd1cnpLgqEnV 2pWFIEE3Iq9+f6BEUQS/WyvcHagRWMK+GhcZygl7dxmRwQdgHOZAFBTT2labWJa87c8Q REYYNFLS1D8toXBgkjOjh8+4BZDpSX/R37pRiKgxUBto3zngz4ztW0oFKJ4CHX3+Z0Od yCHRbLlpMxtOj6CoKXgcsZzN0ERRR+jUslRaqEbAKPemZrWw3PwMPel+uFYc6aahfsHJ ajnHEh3X3B/vcKQsE4L71DJqY5eilyMj5SwDix8GZm//fUakYv9uBldEzXzsJkTu4W8A zCAA==
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr545803wjt.64.1383196462804; Wed, 30 Oct 2013 22:14:22 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Wed, 30 Oct 2013 22:14:22 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4FD2F3@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F8A82@ESESSMB209.ericsson.se> <279CF29F-E822-41C7-B32E-3AB5B8403D48@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1C4FBA42@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1C4FD2F3@ESESSMB209.ericsson.se>
Date: Wed, 30 Oct 2013 22:14:22 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b3440dad1f4e404ea0285aa
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]
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 Oct 2013 05:14:26 -0000

--047d7b3440dad1f4e404ea0285aa
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 on  we need to add the analysis for dealing with this issue.  I had
raised similar issue as applied to Mux attributes draft here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg12572.html

I was wondering, given the above "Codec Configuration" definition, do we
have enough information to suggest on the category assignment for PT scoped
attributes from RFCs like RFC4585 (a=3Drtcpfb:PT),  RFC5583(a=3Ddepend:PT)


Thanks
Suhas


On Wed, Oct 30, 2013 at 8:03 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> >>> This works as an outline, but I'm afraid it'll be too vague for solid
> interoperability.
> >>
> >> At the end of the day, it is the receiver that informs the remote part=
y
> which PT values it wants to receive, so if it chooses the same PT values =
it
> has to know that it is able to handle it.
> >>
> >> We COULD go even more into detail, but then I'm afraid we would have t=
o
> start defining codec specific criteria etc, and I don't think we should g=
o
> that way.
> >
> > I don't want codec-specific criteria -- but I do want to know, e.g.,
> whether PT-specific a=3Drtcp-fb: attributes MUST be aligned across bundle=
d
> m-lines, or if they're free to vary, or what.
> >
> > There are a bunch of SDP attributes that have PT-scoped properties.  I
> think this analysis needs to be added to the mux-attributes draft.
>
> I am not so worried about where we'll document it - first I want us to
> agree on some criteria :)
>
> I DO agree, though, that we probably need to go through the PT-scoped
> attributes.
>
> Regards,
>
> Christer
>
>
>
> > I think it works as a set of principles to guide discussion of
> PT-specific definitions in the mux-attributes draft, though.
> >
> > On Oct 27, 2013, at 5:03 PM, Christer Holmberg
> > 
> > wrote:
> >
> >> This time in non-HTML format.
> >>
> >> L=E4hett=E4j=E4: Christer Holmberg
> >> L=E4hetetty: 27. lokakuuta 2013 23:03
> >> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
> >> Kopio: mmusic
> >> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value
> >> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for
> >> single codec configuration)]
> >>
> >> Hi,
> >>
> >> It would be really great if those who have an opinion on this would
> >> indicate whether they are ok with the approach below. Then we can
> >> focus on where to document it :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o=
rg]
> >> Puolesta Christer Holmberg
> >> L=E4hetetty: 23. lokakuuta 2013 13:37
> >> Vastaanottaja: Bo Burman; Jonathan Lennox
> >> Kopio: mmusic
> >> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value
> >> re-usage
> >> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec
> >> configuration)]
> >>
> >> Hi,
> >>
> >> Below is a copy of the current text in my Vancouver slide regarding th=
e
> criteria for PT value re-usage in multiple m- lines within a BUNDLE group=
.
> >>
> >> It is based on the ideas provided by Jonathan L and Bo B.
> >>
> >> As you can see, apart from the rtpmap and fmtp attributes, it is not
> possible to define an exclusive list of attributes that must be identical=
.
> Such lists may also be codec dependent. Instead, the text talks more
> generally about memory and buffer sizes.
> >>
> >>
> >>> REQUIREMENTS
> >> - Decoder agnostic
> >>> It shall be possible to switch decoders between media flows using
> >>> the same PT value
> >> - Codec agnostic
> >>> The criteria shall be applicable to any codec CRITERIA
> >> - SDP rtpmap and fmtp attribute values must be equal (order of
> >> attribute parameters not significant)
> >>> All parameters must be included
> >> - Explictily
> >> - Implicitly, if a default value is defined for the parameter
> >>> Parameters not included are assigned their default values (if
> >>> defined)
> >> - Decoder maximum memory and buffer sizes shall be assumed to match
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> Behalf Of Christer Holmberg
> >> Sent: 16. lokakuuta 2013 12:12
> >> To: Bo Burman; Jonathan Lennox
> >> Cc: mmusic
> >> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> Hi Bo,
> >>
> >> Thanks for your input!
> >>
> >> I'd ask anyone who might have an opinion about this to take a look at
> >> the proposal, comment on the list if needed, and hopefully we can
> >> agree on way forward in Vancouver (or, even earlier :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> From: Bo Burman
> >> Sent: 16. lokakuuta 2013 11:44
> >> To: Christer Holmberg; Jonathan Lennox
> >> Cc: mmusic
> >> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> Hi,
> >>
> >> I agree with Jonathan that in order to make two PT values "equal",
> their rtpmap and fmtp lines must be equal, as a start.
> >>
> >> I don't think there is any "correct" criterion that can be used to
> judge PT for equality, but we just have to decide on a "reasonable" one
> that is as simple as possible without causing any major problems.
> >>
> >> I have assumed a conceptual equality criterion where PT value A should
> be considered equal to another PT value B if an RTP stream with PT A can =
be
> fed into a decoder stack configured with PT B, and vice versa, without
> causing either decoder stack to "break".
> >>
> >> I don't think we should require the fmtp lines are textually equal, bu=
t
> only that the same parameters are present and have the same values. The
> order of the parameters on the fmtp line does not matter. There is also t=
he
> case when a parameter is specified with the default value for one PT and
> omitted for the other. To identify those as equal, which they semanticall=
y
> are, would require an "equality parser" to know every default value of
> every fmtp parameter for all codecs. This seems unreasonable.
> >>
> >> Regarding Jonathan's question on H.264 sprop-., I guess they don't
> strictly need to be equal to make the PTs equal, but they may have to be.
> They effectively configure the decoder in some way and if there is a
> mismatch, the decoding process will likely break; like mis-interpretation=
s
> or buffer overflows. On the other hand, some sprop-. can be updated by
> in-band information, overriding what is specified on the fmtp line, and i=
n
> this case the fmtp line sprop-. information is obsolete. Requiring that a=
ll
> fmtp of the line is equal however makes a simple rule, which should be
> preferable and I don't think it is too restrictive or excessive.
> >>
> >> However, if the potentially equal PT values are defined as part of
> different media descriptions, other media level attributes also contribut=
e
> to the decoder stack configuration. Some attributes, like maxptime, can
> clearly cause problems (in this case buffer overflow) if it differs.
> Others, like ptime, framerate and imageattr are more of a receiver
> preference within a more formal "conformance point" and would not "break"=
 a
> decoder stack if they differ.
> >>
> >> I agree it can be a good idea to add some text into the mux-attributes
> draft about attributes that have to be the same to consider two PT in
> different media descriptions to be "equal", of course given that rtpmap a=
nd
> fmtp are also equal.
> >>
> >> /Bo
> >>
> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> Behalf Of Christer Holmberg
> >> Sent: den 11 september 2013 09:12
> >> To: Jonathan Lennox
> >> Cc: mmusic
> >> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> Hi,
> >>
> >> It would be so easy if we could define the PT mappings on the SDP
> >> session level, and then simply refer to them within the m- lines :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
> >> Sent: 10. syyskuuta 2013 22:18
> >> To: Christer Holmberg
> >> Cc: mmusic
> >> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> My strawman proposal at the mic in Berlin was that a codec
> configuration is defined by the top-level media type of the m=3D line and=
 the
> content of a given PT value's rtpmap and fmtp lines.  I.e., the full medi=
a
> type, with all its parameters.
> >>
> >> The questions I would have to this straw man are:
> >>
> >> * Is this excessive?  E.g., should items like H.264's sprop- parameter=
s
> be allowed to differ across m=3D line blocks?
> >>
> >> * Is this sufficient?  Should other items (sometimes) indexed by PT
> (e.g., the imageattr, rtcp-fb, or extmap attributes) need to be the same
> across m-lines as well?
> >>
> >> My suggestion would be that this work should be folded into the work
> being done in draft-nandakumar-mmusic-sdp-mux-attributes (which really
> should be integrated with BUNDLE).  Currently (I believe) the
> mux-attributes draft assumes that PTs are unique across m-lines, so this
> work is going to imply changes to the analysis of a number of attributes =
in
> that draft, regardless.  Probably a new category will need to be defined
> for attributes which have to be consistent per payload type.
> >>
> >> On Sep 10, 2013, at 5:56 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Below is the "official" (from the minutes) outcome of questions Q1,Q2
> and Q7 in Berlin.
> >>
> >> Questions:
> >>
> >> Q1: "Can we agree that, within a BUNDLE group (including all m- lines
> associated with the group), any given PT value can only be used for a
> single codec configuration?"
> >> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as ther=
e
> are opinions that simply referencing RFC 3550 might not be clear enough?"
> >> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value
> in multiple RTP m- lines, for the SAME codec configuration?"
> >>
> >> Outcome:
> >>
> >> Q1: Yes
> >> Q2: Yes, Lennox will send suggested text to clarify the term "codec
> configuration".
> >> Q7: Yes.
> >>
> >> So, again, we need definition text for "codec configuration". Jonathan
> promised to submit something, but anyone is of course welcome to do that.
> >>
> >> The other alternative is to not say anything about PT value usages
> within the scope of BUNDLE, but that is not what the meeting wanted.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> Behalf Of Christer Holmberg
> >> Sent: 23. elokuuta 2013 13:53
> >> To: mmusic
> >> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT
> >> value for single codec configuration
> >>
> >> Hi,
> >>
> >> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2
> and Q7 in my slides) was regarding the usage of any given PT value.
> >>
> >> My take of the outcome was that:
> >>
> >> -          We agreed that any given PT value can only be used for a
> single codec configuration (Q1)
> >> -          We agreed that we need some definition text for "codec
> configuration" (Q2)
> >> -          We agreed that, within a BUNDLE group, any given PT value
> can be used in multiple m- lines, as long as it is used for a single code=
c
> configuration (Q7).
> >>
> >> Jonathan Lennox promised to suggest some definition text for "codec
> configuration", so let's wait for that until we go into those discussions=
.
> >>
> >> But, if you have any issues with the agreements in general, please
> >> bring them up :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >> --
> >> Jonathan Lennox
> >> jonathan@vidyo.com
> >>
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--047d7b3440dad1f4e404ea0285aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1 on =A0we need to add the analysis for dealing with this=
 issue. =A0I had raised similar issue as applied to Mux attributes draft he=
re:


I was wondering, given the above "Codec Conf=
iguration" definition, do we have enough information to suggest on the=
 category assignment for PT scoped attributes from RFCs like RFC4585 (a=3Dr=
tcpfb:PT), =A0RFC5583(a=3Ddepend:PT)=A0




Thanks
Suhas


On Wed, Oct 30, 201=
3 at 8:03 AM, Christer Holmberg <christer.holmberg@ericsson.c=
om> wrote:


Hi,




>>> This works as an outline, but I'm afraid it'll be too =
vague for solid interoperability.

>>

>> At the end of the day, it is the receiver that informs the remote =
party which PT values it wants to receive, so if it chooses the same PT val=
ues it has to know that it is able to handle it.

>>

>> We COULD go even more into detail, but then I'm afraid we woul=
d have to start defining codec specific criteria etc, and I don't think=
 we should go that way.

>

> I don't want codec-specific criteria -- but I do want to know, e.g=
., whether PT-specific a=3Drtcp-fb: attributes MUST be aligned across bundl=
ed m-lines, or if they're free to vary, or what.

>

> There are a bunch of SDP attributes that have PT-scoped properties. =
=A0I think this analysis needs to be added to the mux-attributes draft.




I am not so worried about where we'll document it - first I want =
us to agree on some criteria :)



I DO agree, though, that we probably need to go through the PT-scoped attri=
butes.




Regards,



Christer







> I think it works as a set of principles to guide discussion of PT-spec=
ific definitions in the mux-attributes draft, though.

>

> On Oct 27, 2013, at 5:03 PM, Christer Holmberg

> <christer.holmber=
g@ericsson.com>

> wrote:

>

>> This time in non-HTML format.

>>

>> L=E4hett=E4j=E4: Christer Holmberg

>> L=E4hetetty: 27. lokakuuta 2013 23:03

>> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox

>> Kopio: mmusic

>> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value<=
br>
>> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for
>> single codec configuration)]

>>

>> Hi,

>>

>> It would be really great if those who have an opinion on this woul=
d

>> indicate whether they are ok with the approach below. Then we can<=
br>
>> focus on where to document it :)

>>

>> Regards,

>>

>> Christer

>>

>> L=E4hett=E4j=E4: mmusic=
-bounces@ietf.org [mailto:mm=
usic-bounces@ietf.org]

>> Puolesta Christer Holmberg

>> L=E4hetetty: 23. lokakuuta 2013 13:37

>> Vastaanottaja: Bo Burman; Jonathan Lennox

>> Kopio: mmusic

>> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value

>> re-usage

>> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single cod=
ec

>> configuration)]

>>

>> Hi,

>>

>> Below is a copy of the current text in my Vancouver slide regardin=
g the criteria for PT value re-usage in multiple m- lines within a BUNDLE g=
roup.

>>

>> It is based on the ideas provided by Jonathan L and Bo B.

>>

>> As you can see, apart from the rtpmap and fmtp attributes, it is n=
ot possible to define an exclusive list of attributes that must be identica=
l. Such lists may also be codec dependent. Instead, the text talks more gen=
erally about memory and buffer sizes.


>>

>>

>>> REQUIREMENTS

>> - Decoder agnostic

>>> It shall be possible to switch decoders between media flows us=
ing

>>> the same PT value

>> - Codec agnostic

>>> The criteria shall be applicable to any codec CRITERIA

>> - SDP rtpmap and fmtp attribute values must be equal (order of

>> attribute parameters not significant)

>>> All parameters must be included

>> - Explictily

>> - Implicitly, if a default value is defined for the parameter

>>> Parameters not included are assigned their default values (if<=
br>
>>> defined)

>> - Decoder maximum memory and buffer sizes shall be assumed to matc=
h

>>

>> Regards,

>>

>> Christer

>>

>>

>>

>>

>> From: mmusic-bounces@ie=
tf.org [mailto:mmusic-bounce=
s@ietf.org] On

>> Behalf Of Christer Holmberg

>> Sent: 16. lokakuuta 2013 12:12

>> To: Bo Burman; Jonathan Lennox

>> Cc: mmusic

>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specifi=
c

>> PT value for single codec configuration

>>

>> Hi Bo,

>>

>> Thanks for your input!

>>

>> I'd ask anyone who might have an opinion about this to take a =
look at

>> the proposal, comment on the list if needed, and hopefully we can<=
br>
>> agree on way forward in Vancouver (or, even earlier :)

>>

>> Regards,

>>

>> Christer

>>

>> From: Bo Burman

>> Sent: 16. lokakuuta 2013 11:44

>> To: Christer Holmberg; Jonathan Lennox

>> Cc: mmusic

>> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specifi=
c

>> PT value for single codec configuration

>>

>> Hi,

>>

>> I agree with Jonathan that in order to make two PT values "eq=
ual", their rtpmap and fmtp lines must be equal, as a start.

>>

>> I don't think there is any "correct" criterion that =
can be used to judge PT for equality, but we just have to decide on a "=
;reasonable" one that is as simple as possible without causing any maj=
or problems.


>>

>> I have assumed a conceptual equality criterion where PT value A sh=
ould be considered equal to another PT value B if an RTP stream with PT A c=
an be fed into a decoder stack configured with PT B, and vice versa, withou=
t causing either decoder stack to "break".


>>

>> I don't think we should require the fmtp lines are textually e=
qual, but only that the same parameters are present and have the same value=
s. The order of the parameters on the fmtp line does not matter. There is a=
lso the case when a parameter is specified with the default value for one P=
T and omitted for the other. To identify those as equal, which they semanti=
cally are, would require an "equality parser" to know every defau=
lt value of every fmtp parameter for all codecs. This seems unreasonable.

>>

>> Regarding Jonathan's question on H.264 sprop-., I guess they d=
on't strictly need to be equal to make the PTs equal, but they may have=
 to be. They effectively configure the decoder in some way and if there is =
a mismatch, the decoding process will likely break; like mis-interpretation=
s or buffer overflows. On the other hand, some sprop-. can be updated by in=
-band information, overriding what is specified on the fmtp line, and in th=
is case the fmtp line sprop-. information is obsolete. Requiring that all f=
mtp of the line is equal however makes a simple rule, which should be prefe=
rable and I don't think it is too restrictive or excessive.


>>

>> However, if the potentially equal PT values are defined as part of=
 different media descriptions, other media level attributes also contribute=
 to the decoder stack configuration. Some attributes, like maxptime, can cl=
early cause problems (in this case buffer overflow) if it differs. Others, =
like ptime, framerate and imageattr are more of a receiver preference withi=
n a more formal "conformance point" and would not "break&quo=
t; a decoder stack if they differ.


>>

>> I agree it can be a good idea to add some text into the mux-attrib=
utes draft about attributes that have to be the same to consider two PT in =
different media descriptions to be "equal", of course given that =
rtpmap and fmtp are also equal.


>>

>> /Bo

>>

>> From: mmusic-bounces@ie=
tf.org [mailto:mmusic-bounce=
s@ietf.org] On

>> Behalf Of Christer Holmberg

>> Sent: den 11 september 2013 09:12

>> To: Jonathan Lennox

>> Cc: mmusic

>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specifi=
c

>> PT value for single codec configuration

>>

>> Hi,

>>

>> It would be so easy if we could define the PT mappings on the SDP<=
br>
>> session level, and then simply refer to them within the m- lines :=
)

>>

>> Regards,

>>

>> Christer

>>

>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]

>> Sent: 10. syyskuuta 2013 22:18

>> To: Christer Holmberg

>> Cc: mmusic

>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specifi=
c

>> PT value for single codec configuration

>>

>> My strawman proposal at the mic in Berlin was that a codec configu=
ration is defined by the top-level media type of the m=3D line and the cont=
ent of a given PT value's rtpmap and fmtp lines. =A0I.e., the full medi=
a type, with all its parameters.


>>

>> The questions I would have to this straw man are:

>>

>> * Is this excessive? =A0E.g., should items like H.264's sprop-=
 parameters be allowed to differ across m=3D line blocks?

>>

>> * Is this sufficient? =A0Should other items (sometimes) indexed by=
 PT (e.g., the imageattr, rtcp-fb, or extmap attributes) need to be the sam=
e across m-lines as well?

>>

>> My suggestion would be that this work should be folded into the wo=
rk being done in draft-nandakumar-mmusic-sdp-mux-attributes (which really s=
hould be integrated with BUNDLE). =A0Currently (I believe) the mux-attribut=
es draft assumes that PTs are unique across m-lines, so this work is going =
to imply changes to the analysis of a number of attributes in that draft, r=
egardless. =A0Probably a new category will need to be defined for attribute=
s which have to be consistent per payload type.


>>

>> On Sep 10, 2013, at 5:56 AM, Christer Holmberg <christer.holmberg@ericsson.com> w=
rote:

>>

>>

>> Hi,

>>

>> Below is the "official" (from the minutes) outcome of qu=
estions Q1,Q2 and Q7 in Berlin.

>>

>> Questions:

>>

>> Q1: "Can we agree that, within a BUNDLE group (including all =
m- lines associated with the group), any given PT value can only be used fo=
r a single codec configuration?"

>> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*=
, as there are opinions that simply referencing RFC 3550 might not be clear=
 enough?"

>> Q7: "Within a BUNDLE group, do we allow the usage of the same=
 PT value in multiple RTP m- lines, for the SAME codec configuration?"=


>>

>> Outcome:

>>

>> Q1: Yes

>> Q2: Yes, Lennox will send suggested text to clarify the term "=
;codec configuration".

>> Q7: Yes.

>>

>> So, again, we need definition text for "codec configuration&q=
uot;. Jonathan promised to submit something, but anyone is of course welcom=
e to do that.

>>

>> The other alternative is to not say anything about PT value usages=
 within the scope of BUNDLE, but that is not what the meeting wanted.

>>

>> Regards,

>>

>> Christer

>>

>>

>> From: mmusic-bounces@ie=
tf.org [mailto:mmusic-bounce=
s@ietf.org] On

>> Behalf Of Christer Holmberg

>> Sent: 23. elokuuta 2013 13:53

>> To: mmusic

>> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT=


>> value for single codec configuration

>>

>> Hi,

>>

>> One of the open issues related to BUNDLE presented in Berlin (Q1, =
Q2 and Q7 in my slides) was regarding the usage of any given PT value.

>>

>> My take of the outcome was that:

>>

>> - =A0 =A0 =A0 =A0 =A0We agreed that any given PT value can only be=
 used for a single codec configuration (Q1)

>> - =A0 =A0 =A0 =A0 =A0We agreed that we need some definition text f=
or "codec configuration" (Q2)

>> - =A0 =A0 =A0 =A0 =A0We agreed that, within a BUNDLE group, any gi=
ven PT value can be used in multiple m- lines, as long as it is used for a =
single codec configuration (Q7).

>>

>> Jonathan Lennox promised to suggest some definition text for "=
;codec configuration", so let's wait for that until we go into tho=
se discussions.

>>

>> But, if you have any issues with the agreements in general, please=


>> bring them up :)

>>

>> Regards,

>>

>> Christer

>>

>>

>>

>>

>> --

>> Jonathan Lennox

>> jonathan@vidyo.com

>>

>



_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic





--047d7b3440dad1f4e404ea0285aa--

From christer.holmberg@ericsson.com  Wed Oct 30 22:54: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 A4DAA11E80FE for ; Wed, 30 Oct 2013 22:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.741
X-Spam-Level: 
X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P4b7OCSY3FN for ; Wed, 30 Oct 2013 22:54:20 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 954DD11E8108 for ; Wed, 30 Oct 2013 22:54:19 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-bd-5271f08af7ac
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.84.09019.A80F1725; Thu, 31 Oct 2013 06:54:18 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 31 Oct 2013 06:54:18 +0100
From: Christer Holmberg 
To: Suhas Nandakumar , mmusic WG 
Thread-Topic: BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
Thread-Index: AQHO1fUJ59+8FRcGh0eroYzegkbjAJoOT1vc
Date: Thu, 31 Oct 2013 05:54:17 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_jhjnjh0mc198s8tna4qp7jqc1383198854397emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+JvjW7Xh8IggwMrjS06JrNZnLhxmtli 6vLHLBY753YwO7B4TPm9kdVj56y77B4LNpV6LFnykymAJYrLJiU1J7MstUjfLoEr4/jKJvaC f8IVS3d+Y2pgPCvQxcjBISFgItG2tKqLkRPIFJO4cG89WxcjF4eQwBFGiZXPmhkhnCWMEss6 vzCBNLAJWEh0/9MGaRARcJfYd/0zK4jNLOAlcfrsARYQW1jAR6L/+BxWkHIRAV+J1rM6EOVG Erd+/GQECbMIqEosX6YDYvIKuEms/lMAUiEkECCxYNleNhCbUyBQYnHDfmYQmxHosu+n1jBB LBKXuPVkPhPExQISS/acZ4awRSVePv4HdUyOxL7vS8GO4RUQlDg58wnLBEaRWUjaZyEpm4Wk DCKuJ3Fj6hQ2CFtbYtnC18wQtq7EjH+HWJDFFzCyr2LkKE4tTspNNzLYxAiMrINbflvsYLz8 1+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGJ0ebP20sKRqmaEQe+yR YoZPJ55xCMU8mveoIqlO+/IBewOepATRjTl1pVN6Zlx5upcpY6fQoabPTtqWohvCr3h28BQU 1l3//TDj/MTs/+uW7jr3YP7VKM0Ntz6/8Nw/++elfSurGAzuqDjYN7m6vXbbtfuB9y3/ZM7C yOj5DPFu/fob9n+ad0SJpTgj0VCLuag4EQCB1p0AegIAAA==
Cc: Cullen Jennings , Harald Alvestrand 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
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 Oct 2013 05:54:26 -0000

--_000_jhjnjh0mc198s8tna4qp7jqc1383198854397emailandroidcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

In general, without commenting on this specific attribute, the scope of BUN=
DLE is Offer/Answer, and personally I would not want to expand that - at le=
ast not in "version 1".

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Suhas Nandakumar  wrote:



Hello All

  Magnus raised an important question while analyzing  RFC6064 SDP attribut=
es related to RTSP SDP attributes for 3GPP.  Since these attributes are dec=
laratively used, SHOULD BUNDLE be dealing with specifying the behavior in N=
on Offer/Answer Scenarios ?

If the answer is NO, we can assign category to be NOT IMPACTED for these at=
tributes,

If the answer is YES, i think there needs to be more discussions on handlin=
g this scenario.

Please let me know your thoughts.


Cheers
Suhas

--_000_jhjnjh0mc198s8tna4qp7jqc1383198854397emailandroidcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi,=0A=
=0A=
In general, without commenting on this specific attribute, the scope of BUN=
DLE is Offer/Answer, and personally I would not want to expand that - at le=
ast not in "version 1".=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Suhas Nandakumar <suhasietf@gmail.com> wrote:=0A=
=0A=





Hello All






  Magnus raised an important question while analyzing  RFC60=
64 SDP attributes related to RTSP SDP attributes for 3GPP.  Since thes=
e attributes are declaratively used, SHOULD BUNDLE be dealing with specifyi=
ng the behavior in Non Offer/Answer Scenarios ?







If the answer is NO, we can assign category to be NOT IMPACTED for the=
se attributes,







If the answer is YES, i think there needs to be more discussions on ha=
ndling this scenario.







Please let me know your thoughts.












Cheers


Suhas








--_000_jhjnjh0mc198s8tna4qp7jqc1383198854397emailandroidcom_--

From sm@resistor.net  Wed Oct 30 22:18:15 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 E775911E819C for ; Wed, 30 Oct 2013 22:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-8+IbZZVaBZ for ; Wed, 30 Oct 2013 22:18:14 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7911E82B6 for ; Wed, 30 Oct 2013 22:18:11 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9V5I7IN016772 for ; Wed, 30 Oct 2013 22:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383196691; bh=VnM2WV7OSEDsmeDoXBUy0hFjQ/Smxv92HSV16tMAy8Y=; h=Date:To:From:Subject:In-Reply-To:References; b=LUb15v8SrYya75mLS09+8u2o43tDr5LVjRChdTUFIZpJKySHIaf2PKFw2ytOC0tw4 oBrvVcvzfBSyOPPNWfhv9FBbnvv1X+q5CYmDCnwKdtmHql9d93IglCot4RmvcfO0OD g8Af5FwlTbls6b/FSioPW/lripz5sWnBOTyeETKs=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1383196691; i=@resistor.net; bh=VnM2WV7OSEDsmeDoXBUy0hFjQ/Smxv92HSV16tMAy8Y=; h=Date:To:From:Subject:In-Reply-To:References; b=A7m0/r9DrTapnFCsUnmBOMvRcWYy2GTT4heuYgUQlWHeJLwGKugBXrsI9DUL7dAFC 53wa/NNtcBuAddjnVL8zhD48NsgvvWqJ7badsWpufnCTzDmv6nOIlzx3J/yCp34cLy euur88vDpuGmSlrHICbx2BFfOp5BIoOu9E6mHzL8=
Message-Id: <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 30 Oct 2013 20:36:34 -0700
To: mmusic@ietf.org
From: SM 
In-Reply-To: <20131030131748.6987.86198.idtracker@ietfa.amsl.com>
References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Thu, 31 Oct 2013 00:22:36 -0700
Subject: Re: [MMUSIC] Last Call:  (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard
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 Oct 2013 05:18:15 -0000

At 06:17 30-10-2013, The IESG wrote:
>The IESG has received a request from the Multiparty Multimedia Session
>Control WG (mmusic) to consider the following document:
>- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B'
>    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-11-27. Exceptionally, comments may be

I read this draft quickly.  According to the Abstract:

   "RFC4856 describes the annexa parameter for G723 and the annexb
    parameter for G729, G729D and G729E. However, the specification does
    not describe the offerer and answerer behavior when the value of the
    annexa or annexb parameter does not match in the Session Description
    protocol(SDP) offer and answer.  This document provides the offer/
    answer considerations for these parameters and updates RFC4856."

RFC 4856 is about media type registration of payload formats.  The 
IESG approval mentioned that the document "specify the procedure to 
register RTP payload formats as audio, video or other media subtype 
names".  The RFC does not specify the AnnexA parameter for G723.  I 
took a quick look at the RFCs being referenced.  They are about media 
type registrations.  It is doubtful whether they even qualify for 
Proposed Standard.

The premise on which the work in this draft is built is lacking.  The 
draft mentions
G723 Annex A without providing any reference to the 
specification.  In my opinion the draft needs more work for it to be 
a Proposed Standard.  It doesn't look like there has been any 
discussion about whether there are IPR issues affecting implementations.

Regards,
-sm  


From magnus.westerlund@ericsson.com  Thu Oct 31 00:31:50 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 CDA2A21E80B5 for ; Thu, 31 Oct 2013 00:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.74
X-Spam-Level: 
X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izn6NWQ-4DuB for ; Thu, 31 Oct 2013 00:31:44 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4325F21E80AC for ; Thu, 31 Oct 2013 00:31:34 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-95-527207568f5c
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 71.22.03802.65702725; Thu, 31 Oct 2013 08:31:34 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Thu, 31 Oct 2013 08:31:33 +0100
Message-ID: <52720794.9070101@ericsson.com>
Date: Thu, 31 Oct 2013 08:32:36 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Suhas Nandakumar , mmusic WG 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjW4Ye1GQwfdnYhYdk9ksTtw4zWwx dfljFoudczuYHVg8pvzeyOqxc9Zddo8Fm0o9liz5yRTAEsVlk5Kak1mWWqRvl8CVcW2bbsFO wYoTLR1sDYyveLsYOTgkBEwk/m/S6WLkBDLFJC7cW8/WxcjFISRwiFGidcYnJghnOaNEw5wL 7CBVvALaEscOrgKzWQRUJVbO6mYCsdkELCRu/mhkA7FFBYIlbiw7xAZRLyhxcuYTFhBbRMBd Yt/1z6wgQ5kFGhgldj5/zgySEBaIkZjWdxzMFhIIkGicuhBsKKdAoMS0ZytZIS4Vl+hpDAIJ MwvoSUy52sIIYctLNG+dDdWqLdHQ1ME6gVFoFpLVs5C0zELSsoCReRUje25iZk56udEmRmAw H9zyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuGqan5mL DWNk24nWAsa35q/e+W9/NqegtO6lzNGyWGGXqCU31zsmnru7ZddTDUXtZ5s905ivp3dcCWZO brr9XUPp6x+BlZ+MzpmcMLjIffjwhYtGQWGOgcd/Rp+S/SV1zc5irW9g6LeHytMv7WO3cpnJ 9d9oRX8mf73xPnnVyp0uR2ouFEo8VmIpzkg01GIuKk4EAE06lYk0AgAA
Cc: Cullen Jennings , Harald Alvestrand , Christer Holmberg 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#2: Should BUNDLE allow/disallow SSRC Repetition ?
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 Oct 2013 07:31:50 -0000

Hi,

See inline on my opinion and thinking around this subject.

On 2013-10-31 05:46, Suhas Nandakumar wrote:
> Hello All
> 
>   Another issue or concern that was brought up is dealing with RFC5576
> SSRC attributes across the BUNDLED m=lines.
> 
> RFC5576 does allow SSRCs to be repeated across the m=lines given that
> each m=line forms a separate RTP Session.
> 
> There were two options suggested in this regard (by Jonathan)
> 
> 1. Don't allow SSRC values to be repeated across the bundled m-lines
>     ==> Assign category NORMAL
> 

Although it will be normal that a specific SSRC value will only be
associated with a specific media description (m= block) there are
counter arguments for why this limitation can't be done.

For example an FEC encoding across multiple SSRCs i.e. RTP packet
streams can be sent in the same RTP session under its own SSRC. That
SSRC may be desirable to reference in all the m= blocks that contributes
to this particular encoding. Note, we really are talking about
referencing the same packet stream from multiple places.

There are likely more cases where this type of need will arise.

> 2. Allow SSRC values to be repeated iff the media stream satisfies more
> than one m=lines, in which case, the individual sources define the behavior
>   ==> We have 3 options here
>    2.1 Assign Category SPECIAL and add explanatory note on possible
> scenarios 
> 

I think this is likely sufficient to solve this case.

>    2.2 Assign Category SPECIAL and propose an update to RFC5576 to
> explain behavior of a=ssrc attributes when multiple m=lines are multiplexed
> 
>    2.3 Define a new category ?? 
> 
> 
> I look forward for your inputs on how do we deal with this issue.

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 hta@google.com  Thu Oct 31 00:49: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 E06D821F9EAE for ; Thu, 31 Oct 2013 00:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzhes506Dp9B for ; Thu, 31 Oct 2013 00:49:36 -0700 (PDT)
Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4299A11E80F6 for ; Thu, 31 Oct 2013 00:49:36 -0700 (PDT)
Received: by mail-vb0-f41.google.com with SMTP id w8so1686505vbj.28 for ; Thu, 31 Oct 2013 00:49:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tonFx5hCl9fvGpM/pqPfg+LT0GlZSo26N0B61tzbsxE=; b=MvSdnTu0VODAHprzEkrst6+i9O2IGmNa5ysAgk0cOvFy5C0XertI6L8aH2PPOMkEH9 NWQdncc4rJbLUVGOLzZqGENOKT/nbZqOGZV/8+oOIz23tg+WjexDc1Vo8GJA0AywDm5N 5GPW4uHFEmQU+UpfCCwzsYPszopf7lROfJvhqH4zARG1JPgL01iAp/Wf3RiSfLE9wXAt VuBRFzsgn0scyH18gJkhlPymkGWjcZ9/T19Zuf02GxPUrLiwOTbMf9iS+/ySUtEOue2Z Bz814QIGLKpU3JtTzG2rPp9kH0mr0ZvYpPFwGCU/HH3wGxc9zuj4QfsgShpacP2SDooc GsxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tonFx5hCl9fvGpM/pqPfg+LT0GlZSo26N0B61tzbsxE=; b=TaT8VIrjeiQAxMnslDsnHVkP5Q2q5qfr+Xgad7FQmmLBok4QFUe5ymphWoWqYn2Utx Seyoun06R/6wyE58sQ7b9zsik9PVJAb5LzFc/NVDjJMrNyhtKDNpcvelr5BsqSmrUSyy 56rnJ+ylBiVfj0fJgnJk3uTHVvQtCs+KpZaMNZfkq11AA9Mqnsgws8c1IIXv4ChIm9u0 +ktSFCR541o3Hy3uL/uwQMyEdVYbukq9rmjfII/c15zD/bKDEhbXRV2Hahn3/9BLOf8/ KIwZVS099KFMzaqvcV1EsrQv+Ltc/6JOMYovL8SIhq27P7JDUjGkvcn1Q5CyKkKnlumz aMkg==
X-Gm-Message-State: ALoCoQn5wT7WjyPReOdhnkmNdN6KBWeMrag/m/Lf/M+pxm2whp7kVymMXRXgthDpSt1cjMJB4AgyuTpBoN9DWbMUZ0ddOsEvNDGEhxue+3eqGm4zTlzflGywvUn2XOMutqG0iieIbczPyU6ZDuf1qDiTtcVxWdzZIaNd4Mcym2RLMtKiDDy5GB6gjrumhAp6k13+HwFMvGa8
MIME-Version: 1.0
X-Received: by 10.58.228.231 with SMTP id sl7mr319120vec.49.1383205775689; Thu, 31 Oct 2013 00:49:35 -0700 (PDT)
Received: by 10.52.176.8 with HTTP; Thu, 31 Oct 2013 00:49:35 -0700 (PDT)
Received: by 10.52.176.8 with HTTP; Thu, 31 Oct 2013 00:49:35 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 31 Oct 2013 08:49:35 +0100
Message-ID: 
From: Harald Alvestrand 
To: Suhas Nandakumar 
Content-Type: multipart/alternative; boundary=047d7bd6b4b2e997d904ea04b083
X-Mailman-Approved-At: Thu, 31 Oct 2013 00:53:01 -0700
Cc: Cullen Jennings , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
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 Oct 2013 07:49:37 -0000

--047d7bd6b4b2e997d904ea04b083
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Could you expand "declaratively" for me here? If it means "stated, not
negotiated", this is the same as for many attrs in the draft already. If it
means "never used in offer/answer", I agree with Christer.
31. okt. 2013 05:52 skrev "Suhas Nandakumar"  f=C3=B8l=
gende:

> Hello All
>
>   Magnus raised an important question while analyzing  RFC6064 SDP
> attributes related to RTSP SDP attributes for 3GPP.  Since these attribut=
es
> are declaratively used, SHOULD BUNDLE be dealing with specifying the
> behavior in Non Offer/Answer Scenarios ?
>
> If the answer is NO, we can assign category to be NOT IMPACTED for these
> attributes,
>
> If the answer is YES, i think there needs to be more discussions on
> handling this scenario.
>
> Please let me know your thoughts.
>
>
> Cheers
> Suhas
>

--047d7bd6b4b2e997d904ea04b083
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Could you expand "declaratively" for me here? If i=
t means "stated, not negotiated", this is the same as for many at=
trs in the draft already. If it means "never used in offer/answer"=
;, I agree with Christer.



31. okt. 2013 05:52 skrev "Suhas Nandakumar=
" <suhasietf@gmail.com&g=
t; f=C3=B8lgende:


Hello All

=C2=A0 Magnus raised an impor=
tant question while analyzing =C2=A0RFC6064 SDP attributes related to RTSP =
SDP attributes for 3GPP. =C2=A0Since these attributes are declaratively use=
d, SHOULD BUNDLE be dealing with specifying the behavior in Non Offer/Answe=
r Scenarios ?




If the answer is NO, we can assign category to be NOT I=
MPACTED for these attributes,

If the answer is YES=
, i think there needs to be more discussions on handling this scenario.



Please let me know your thoughts.

<=
div>
Cheers
Suhas




--047d7bd6b4b2e997d904ea04b083--

From hta@google.com  Thu Oct 31 00:54: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 15E8F11E8133 for ; Thu, 31 Oct 2013 00:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsvIcWjstF3j for ; Thu, 31 Oct 2013 00:54:09 -0700 (PDT)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F721F8E8E for ; Thu, 31 Oct 2013 00:54:09 -0700 (PDT)
Received: by mail-vb0-f48.google.com with SMTP id o19so1644039vbm.35 for ; Thu, 31 Oct 2013 00:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QXpbZ7kYbdMqBESTb/LUE0iojo5KXuXX+CDOfxtN4IM=; b=F1BWWutiwtWgMMHRmuRvpHg70tJ24qxif5kDoO1uwn6KbwbjaQvmdTva46XiuyNCCf HZ3ddrT9si6XMqIghZQ3k3sEvag149q5912ai5LaU59MQHrsvQCk5nj0NqfbQYNEkMe4 Qq3T8zP2MDX/88BAqyK2gmN4Jupig0KPr3qRzkmXgxm72WAn7nAnbZ1eEmjSXieXn0i5 +NC6tcTEX5gLZo8CAeE+8C69JOe63vbbyg7QL8AH0Ex/MqQbBq7OyHKoD7V7xC9vkuTu kV0kBsvDpGv2xepPkjEstw+2nweDvNSgg8rpFTsUexNN86ZTdMMooefxCh7hsY4JLqxQ YKuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QXpbZ7kYbdMqBESTb/LUE0iojo5KXuXX+CDOfxtN4IM=; b=HL5JGP8TzhC7cHlG1ve1eUyix+R9ZFkpjaQPreINeKvXrZ8WPc2DR5uU4KEm2CJ/yV IzTFa5N8920akdKdHjgDUONor+epBwHKKwcVwoEbAYSkEHBUXgFO7JeV2DPAgre+GjLr NtwniALPz9ENw7m2Ms7TPFxwSyhMYvxlm+5ULpxynyTc55qijx5SZdhAcA99PK6VHl1A v1cOuU5HO44eNmvpc8/N1Vf0z8FSfWk7V6YTTmdf6xtx0ipp+jPVCjqL91+Xb5W0QibP HsOElhN+4hRGeg9R8ftyLM2VtoabX6VNgchFm2t5A2dVneGTPXI6+5CRYh1JRdcIQghM WaTg==
X-Gm-Message-State: ALoCoQnpJXxwUWwNycdGhnPsqhKtR4f/wXX5Rm8npOuDTlv0N9F3+oPcESzKZSFSK95kSGZ9/Vf7Dtfg9tl5cbzqIWLVjXpdsRPlE/gCpCVX6M/xEsTVdaAX/pijcGM5/ysJNF5riXvpg1BHeqokFbdvPPLetEc+dflIymEYPxamGy7SpEGTbVSpTeg8BCp4hVrQbmhDPpWR
MIME-Version: 1.0
X-Received: by 10.52.105.195 with SMTP id go3mr839105vdb.24.1383206048756; Thu, 31 Oct 2013 00:54:08 -0700 (PDT)
Received: by 10.52.176.8 with HTTP; Thu, 31 Oct 2013 00:54:08 -0700 (PDT)
Received: by 10.52.176.8 with HTTP; Thu, 31 Oct 2013 00:54:08 -0700 (PDT)
In-Reply-To: <52720794.9070101@ericsson.com>
References:  <52720794.9070101@ericsson.com>
Date: Thu, 31 Oct 2013 08:54:08 +0100
Message-ID: 
From: Harald Alvestrand 
To: Magnus Westerlund 
Content-Type: multipart/alternative; boundary=001a1134c89230215b04ea04c169
Cc: Cullen Jennings , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#2: Should BUNDLE allow/disallow SSRC Repetition ?
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 Oct 2013 07:54:10 -0000

--001a1134c89230215b04ea04c169
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A=3Dssrc attributes are a class, so a single rule is likely not enough.
Suggest NORMAL as default with a note that individual attributes may be
designated SPECIAL or identical.
31. okt. 2013 08:31 skrev "Magnus Westerlund" <
magnus.westerlund@ericsson.com> f=C3=B8lgende:

> Hi,
>
> See inline on my opinion and thinking around this subject.
>
> On 2013-10-31 05:46, Suhas Nandakumar wrote:
> > Hello All
> >
> >   Another issue or concern that was brought up is dealing with RFC5576
> > SSRC attributes across the BUNDLED m=3Dlines.
> >
> > RFC5576 does allow SSRCs to be repeated across the m=3Dlines given that
> > each m=3Dline forms a separate RTP Session.
> >
> > There were two options suggested in this regard (by Jonathan)
> >
> > 1. Don't allow SSRC values to be repeated across the bundled m-lines
> >     =3D=3D> Assign category NORMAL
> >
>
> Although it will be normal that a specific SSRC value will only be
> associated with a specific media description (m=3D block) there are
> counter arguments for why this limitation can't be done.
>
> For example an FEC encoding across multiple SSRCs i.e. RTP packet
> streams can be sent in the same RTP session under its own SSRC. That
> SSRC may be desirable to reference in all the m=3D blocks that contribute=
s
> to this particular encoding. Note, we really are talking about
> referencing the same packet stream from multiple places.
>
> There are likely more cases where this type of need will arise.
>
> > 2. Allow SSRC values to be repeated iff the media stream satisfies more
> > than one m=3Dlines, in which case, the individual sources define the
> behavior
> >   =3D=3D> We have 3 options here
> >    2.1 Assign Category SPECIAL and add explanatory note on possible
> > scenarios
> >
>
> I think this is likely sufficient to solve this case.
>
> >    2.2 Assign Category SPECIAL and propose an update to RFC5576 to
> > explain behavior of a=3Dssrc attributes when multiple m=3Dlines are
> multiplexed
> >
> >    2.3 Define a new category ??
> >
> >
> > I look forward for your inputs on how do we deal with this issue.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=C3=A4r=C3=B6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>

--001a1134c89230215b04ea04c169
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


A=3Dssrc attributes are a class, so a single rule is likely =
not enough. Suggest NORMAL as default with a note that individual attribute=
s may be designated SPECIAL or identical.


31. okt. 2013 08:31 skrev "Magnus Westerlun=
d" <magnus.wester=
lund@ericsson.com> f=C3=B8lgende:

Hi,



See inline on my opinion and thinking around this subject.



On 2013-10-31 05:46, Suhas Nandakumar wrote:

> Hello All

>

> =C2=A0 Another issue or concern that was brought up is dealing with RF=
C5576

> SSRC attributes across the BUNDLED m=3Dlines.

>

> RFC5576 does allow SSRCs to be repeated across the m=3Dlines given tha=
t

> each m=3Dline forms a separate RTP Session.

>

> There were two options suggested in this regard (by Jonathan)

>

> 1. Don't allow SSRC values to be repeated across the bundled m-lin=
es

> =C2=A0 =C2=A0 =3D=3D> Assign category NORMAL

>



Although it will be normal that a specific SSRC value will only be

associated with a specific media description (m=3D block) there are

counter arguments for why this limitation can't be done.



For example an FEC encoding across multiple SSRCs i.e. RTP packet

streams can be sent in the same RTP session under its own SSRC. That

SSRC may be desirable to reference in all the m=3D blocks that contributes<=
br>
to this particular encoding. Note, we really are talking about

referencing the same packet stream from multiple places.



There are likely more cases where this type of need will arise.



> 2. Allow SSRC values to be repeated iff the media stream satisfies mor=
e

> than one m=3Dlines, in which case, the individual sources define the b=
ehavior

> =C2=A0 =3D=3D> We have 3 options here

> =C2=A0 =C2=A02.1 Assign Category SPECIAL and add explanatory note on p=
ossible

> scenarios

>



I think this is likely sufficient to solve this case.



> =C2=A0 =C2=A02.2 Assign Category SPECIAL and propose an update to RFC5=
576 to

> explain behavior of a=3Dssrc attributes when multiple m=3Dlines are mu=
ltiplexed

>

> =C2=A0 =C2=A02.3 Define a new category ??

>

>

> I look forward for your inputs on how do we deal with this issue.



Cheers



Magnus Westerlund



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

Multimedia Technologies, Ericsson Research EAB/TVM

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

Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone =
=C2=A0+46 10 7148287

F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0| Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

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






--001a1134c89230215b04ea04c169--

From pkyzivat@alum.mit.edu  Thu Oct 31 08:51: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 4364111E8226 for ; Thu, 31 Oct 2013 08:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.348
X-Spam-Level: 
X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=-0.415,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYTVXSwzEq7u for ; Thu, 31 Oct 2013 08:51:05 -0700 (PDT)
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 5540B11E8232 for ; Thu, 31 Oct 2013 08:51:04 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id jo951m0031wpRvQ53rr3b1; Thu, 31 Oct 2013 15:51:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id jrr31m00U3ZTu2S3err3Vo; Thu, 31 Oct 2013 15:51:03 +0000
Message-ID: <52727C67.5090907@alum.mit.edu>
Date: Thu, 31 Oct 2013 08:51:03 -0700
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Roni Even ,  'Martin Thomson' 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>		<019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>  <023801ced464$91e97f60$b5bc7e20$@gmail.com> <526FD5E0.6010202@alum.mit.edu> <032e01ced4f5$8cfab640$a6f022c0$@gmail.com>
In-Reply-To: <032e01ced4f5$8cfab640$a6f022c0$@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383234663; bh=q4wDiYZGzwMLUhlwH7urytjTjDjEuetoVB1/8whjEFc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=efa86OYgaS9D6Thx6pNmH6/2OGySFbB3BnBWXLjCSBYhLgz7u0Fx7dolpzMZGeaaI ShooDhCqI7rp1DY68/WOCViWcbsc1bgfZRpPEd3G+5tZSw5tno4LOLuCVouo9ncGPI fM3wPF88StSJy8hywzaJ4l2FJQRyWMCtA0NaLdEsFpMdZBcI/n8Sxnk69xJr/EVQ9R OCCF0H9J79L+wS4r4HpiMB/ZbDEfNpqUSFFpk2tSeli9IA1FnmuqC4GRUFukZNymy+ ZWNRRNduKlQF59+hSFg7Wh1uwVqv87lWEXiDM6XcWP4w9NA3XYPHPvRGpCGT5Z7UhT lQZ7cJPtc7Ihw==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Thu, 31 Oct 2013 15:51:10 -0000

On 10/29/13 3:23 PM, Roni Even wrote:
> Paul,
> Inline
> Roni
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: 29 October, 2013 5:36 PM
>> To: Roni Even; 'Martin Thomson'
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
>>
>> Roni,
>>
>> I'm still not sure I understand. I'm going to repeat my characterization about
>> what I understand one more time:
>>
>> - an RTP session MAY have one or more appid tokens
> [Roni Even] This is correct but not important, an m-line can have one or more appIds toke

Historically there was a 1:1 relationship between m-lines and RTP 
sessions. But now we have Bundle, which is changing that relationship. 
And I think AppId can be involved in understanding the relationship.

An RTP implementation will be looking at what arrives in RTP packets, 
and trying to do the correlation with information from SDP. I am trying 
to clarify the relationships.

So this statement, on its own may be somewhat simplistic, is a 
foundation for the following points. I think the "namespace" for AppIds 
must be an RTP session.

>> - at any point in time each appid token maps to at most
>>     one stream (SSRC) within the session.
> [Roni Even] To one media stream - see the taxonomy draft

OK, good. Everybody seems to be agreeing on this. I suggest being very 
explict, so no future reader is confused.

>> - *new* appid:ssrc mappings MAY be initialized via SDP
> [Roni Even] Yes
>> - new appid:ssrc mappings MAY be initialized via receipt
>>     of the new RTPC SDES message or header extension
> [Roni Even] This is not a may but that is the MUST and we need both SDES and RTP header but the RTP header should have precedence in case of race condition. This is to allow the binding between a media stream in SDP to an SSRC to happen in the RTP when it is used.

My point with the MAY was that the sender might not use this mechanism.
There are two mechanisms:
- SDP a=appid
- RTCP SDES & RTP header (IIUC these are two parts of one mechanism)

They are both optional to use.

At least that is what I understand.

>> - existing appid:ssrc mappings MAY be updated via
>>     receipt of the new RTCP SDES message or header extension.
> [Roni Even] Yes, RTP header has precedence over SDES in case of race condition.

I'm not sure what "precedence" means here. Doesn't each update the state 
when it is received?

	Thanks,
	Paul

>> Can you either confirm the above is correct, or else update it so it is correct?
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> On 10/29/13 1:06 AM, Roni Even wrote:
>>> Martin,
>>> 1. My understanding that unified is only applicable to RTCweb but not a
>> general MMUSIC solution. A singe media stream per m-line that may be
>> grouped  is also a case for MMUSIC.
>>> 2. The motivation for appID is also having multiple media streams (each with
>> a different SSRC) in a single m-line representing a media source. (unified).
>>> 3. The FEC example is more a corner case and a question I had about
>>> msid and unified but not the motivation for appID Roni
>>>
>>>> -----Original Message-----
>>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>>> Sent: 28 October, 2013 7:17 PM
>>>> To: Roni Even
>>>> Cc: Paul Kyzivat; mmusic@ietf.org
>>>> Subject: Re: [MMUSIC] comments on
>>>> draft-even-mmusic-application-token-01
>>>>
>>>> On 28 October 2013 07:57, Roni Even  wrote:
>>>>> there can be an m-line for RTP stream
>>>>
>>>> I have
>>>> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section
>>>> -
>>>> 3.3
>>>> bookmarked, strangely enough, and the third paragraph is fairly clear
>>>> about the desired configuration, which is that multiple SSRCs are
>>>> grouped into the same m-line.
>>>>
>>>> The issues regarding the use of a single FEC repair stream for
>>>> multiple sources is where the "can" part comes in, but I wouldn't
>>>> have used that as the starting position for this appid work.
>>>
>>>
>
>


From ron.even.tlv@gmail.com  Thu Oct 31 09:40: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 6DB3211E8117 for ; Thu, 31 Oct 2013 09:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWad9KlWE1xd for ; Thu, 31 Oct 2013 09:40:53 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1121F9DCF for ; Thu, 31 Oct 2013 09:40:52 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id c11so2959523wgh.2 for ; Thu, 31 Oct 2013 09:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=AKrM17EqjZjhWUOObfIZSTt/fZp+KU5+ceetjZfDZfo=; b=OsWqRcUEljZlTWoPEFJHsDvFMskDCyEfVx1LPceJYrXKYhlbIi4rujQuDKV4f0xC46 D6qO0zH4gscCWyLjHdopbrrFmyHNGBXSU9S+V3admN6UVSP2m+1XEi7qF3nq49xFZUJZ SuEADtQgPRnpjaz8F2ux4XARFqB38ku3VamlVU28vuqMgEsYr/hNrhFqEkc1LwIJmYXR JWQQmeNi6Fnj0ZQ+9Q+hCYzyAiNr9Gcl34iZUkO/I9Hi6p0TxRllw72aMA1gPAxw4tRS 9CiRXzk+GL9CMuSPUUfUQ0oy5rEwV6yspy2UhSBSJl7YzAuEk3zk/2dbQ0N/xN05aF1w uRzQ==
X-Received: by 10.180.90.177 with SMTP id bx17mr142321wib.55.1383237651756; Thu, 31 Oct 2013 09:40:51 -0700 (PDT)
Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id b7sm8425515wiz.8.2013.10.31.09.40.49 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Oct 2013 09:40:51 -0700 (PDT)
From: "Roni Even" 
To: "'Martin Thomson'" , "'Jonathan Lennox'" 
References: <526D5CDD.40805@alum.mit.edu>		<526D8FA3.1030503@alum.mit.edu>		<019f01ced3ed$f83e1090$e8ba31b0$@gmail.com>		<023801ced464$91e97f60$b5bc7e20$@gmail.com>	<526FD5E0.6010202@alum.mit.edu>	<30F39FA8-DE1C-47F1-9F1E-D03B020E6C1D@vidyo.com> 
In-Reply-To: 
Date: Thu, 31 Oct 2013 18:37:35 +0200
Message-ID: <00c901ced657$83b6fef0$8b24fcd0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6iXv0c6W9apn1bzhH/0GpTiVp7gIEvfvRAp4w7t8B8NJj/gJe/nO0Al9VIzsCUToXgQLiKcF3Aw7IiD4Bss3UqZgNXkLQ
Content-Language: en-us
Cc: mmusic@ietf.org, 'Paul Kyzivat' 
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-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: Thu, 31 Oct 2013 16:40:53 -0000

Hi guys,
I am not sure about having the same appId for multiple media streams
One example you gave is FEC. Assume that we have a "unified" offer with =
a simulcast source with two simulcast configuration (low res and high =
res) each will have a different appId and one repair stream for both. =
What appID to use.
Same applies for layered codec when you have a base layer enhancement =
layer and one repair stream (this is even more realistic than the =
simulcast case)
Roni

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: 30 October, 2013 12:01 AM
> To: Jonathan Lennox
> Cc: Paul Kyzivat; Roni Even; 
> Subject: Re: [MMUSIC] comments on =
draft-even-mmusic-application-token-01
>=20
> On 29 October 2013 14:34, Jonathan Lennox  wrote:
> >> - at any point in time each appid token maps to at most  one stream
> >> (SSRC) within the session.
> >
> > This one isn't right.  An appid maps to at most one *source* -- but =
in
> situations where multiple streams (SSRCs) make up one source, in some =
cases
> we'll want them to be associated by having them have the same appid.
>=20
> Thanks Jonathan, I had hoped that this was the intended answer.  It's =
the only
> one that makes any sense.
>=20
> > In particular, I think, RTX and single-stream-repair FEC streams
> > should probably be associated to their primary stream using appid.
> > (Multi-stream-repair FEC is more complicated, as the draft =
discusses.
> > Yes, we probably shouldn't have jumped to the more complicated case =
so
> > quickly in the examples.)
>=20
> The SDES extension or RTP extension could identify an SSRC as =
contributing to
> multiple sources in those complicated scenarios.  The simple case is =
where
> each SSRC contributes to just a single source.
> Maybe that's too much information for an RTP extension, in which case =
you
> could send the appid indications for each source a) when the =
contribution
> commences - i.e., at the start of transmission; and b) interleaved =
when there is
> more than one appid.  That assumes that the SSRC can't ever stop =
contributing
> to a given source, which I think is a safe assumption.


From suhasietf@gmail.com  Thu Oct 31 12:56: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 411F311E8195 for ; Thu, 31 Oct 2013 12:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level: 
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO+JyS6FIGnm for ; Thu, 31 Oct 2013 12:56:20 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id EBDF611E8192 for ; Thu, 31 Oct 2013 12:56:14 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id q59so3160273wes.37 for ; Thu, 31 Oct 2013 12:56:13 -0700 (PDT)
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=q62GJ22REbGN5qwv6AVfb8ouVchIHoUV75ySu9Iy320=; b=W44msCE5NmvTTbQGn8PGWS4l5RaDyMICMJMEOAqd33ZhSfaLpcUrwAVu06MBsGRKS+ c9KfVLd23GDEQcUf2fv/G89LvSTocDgqt+IJ9sjzJM2JHYGJp4bOOSLjDYugh+Fx6LZT mK4xWvjbfWljN29QDS5rQOF8bn57ub3oK8rPrtmTiloyeMv7YUgdIU7p+hmEXrZT5SfF 8kaEGUUo8lnGvq6FkTZ0Wc5G5ZMi26zGgOKKlcGcppl+3FLP9MXQMesAItxHjU1zTO59 h8gOeEFW/v7Lat4Att+ho2Ep8tjyHqlNcnmLs5koWv3rTV96fuRmXfFpnKa4FMu7UUn1 k+EA==
MIME-Version: 1.0
X-Received: by 10.180.185.101 with SMTP id fb5mr892017wic.11.1383249373831; Thu, 31 Oct 2013 12:56:13 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Thu, 31 Oct 2013 12:56:13 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 31 Oct 2013 12:56:13 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=001a11c2448e9028be04ea0ed759
Cc: Cullen Jennings , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
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 Oct 2013 19:56:22 -0000

--001a11c2448e9028be04ea0ed759
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good point Harald. Thinking of it , I feel this question applies to all the
declarative usages of SDP attributes in the context of BUNDLE.

>From Christer's and your point, I feel the BUNDLE specification should
state it explicitly that only O/A procedures are supported for this
version. That way, we handle all the attributes that has declarative
semantics along with O/A or otherwise.

please let me know your thoughts.

Thanks
Suhas




On Thu, Oct 31, 2013 at 12:49 AM, Harald Alvestrand  wrote:

> Could you expand "declaratively" for me here? If it means "stated, not
> negotiated", this is the same as for many attrs in the draft already. If =
it
> means "never used in offer/answer", I agree with Christer.
> 31. okt. 2013 05:52 skrev "Suhas Nandakumar" 
> f=F8lgende:
>
> Hello All
>>
>>   Magnus raised an important question while analyzing  RFC6064 SDP
>> attributes related to RTSP SDP attributes for 3GPP.  Since these attribu=
tes
>> are declaratively used, SHOULD BUNDLE be dealing with specifying the
>> behavior in Non Offer/Answer Scenarios ?
>>
>> If the answer is NO, we can assign category to be NOT IMPACTED for these
>> attributes,
>>
>> If the answer is YES, i think there needs to be more discussions on
>> handling this scenario.
>>
>> Please let me know your thoughts.
>>
>>
>> Cheers
>> Suhas
>>
>

--001a11c2448e9028be04ea0ed759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Good point Harald. Thinking of it , I feel this question a=
pplies to all the declarative usages of SDP attributes in the context of BU=
NDLE.

From Christer's and your point, I feel the BUN=
DLE specification should state it explicitly that only O/A procedures are s=
upported for this version. That way, we handle all the attributes that has =
declarative semantics along with O/A or otherwise.



please let me know your thoughts.

<=
div>Thanks
Suhas






On Thu,=
 Oct 31, 2013 at 12:49 AM, Harald Alvestrand <hta@google.com> =
wrote:


Could you expand "declar=
atively" for me here? If it means "stated, not negotiated", =
this is the same as for many attrs in the draft already. If it means "=
never used in offer/answer", I agree with Christer.




31. okt. 2013 05:52 skrev "Suhas Nandakumar=
" <suhasie=
tf@gmail.com> f=F8lgende:




Hello All

=A0 Magnus raised an importan=
t question while analyzing =A0RFC6064 SDP attributes related to RTSP SDP at=
tributes for 3GPP. =A0Since these attributes are declaratively used, SHOULD=
 BUNDLE be dealing with specifying the behavior in Non Offer/Answer Scenari=
os ?





If the answer is NO, we can assign category to be NOT I=
MPACTED for these attributes,

If the answer is YES=
, i think there needs to be more discussions on handling this scenario.




Please let me know your thoughts.

<=
div>
Cheers
Suhas







--001a11c2448e9028be04ea0ed759--

From christer.holmberg@ericsson.com  Thu Oct 31 13:12:21 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 58DFC11E8192 for ; Thu, 31 Oct 2013 13:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.557
X-Spam-Level: 
X-Spam-Status: No, score=-5.557 tagged_above=-999 required=5 tests=[AWL=0.691,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCmJ4ugNiivL for ; Thu, 31 Oct 2013 13:12:15 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6311E824D for ; Thu, 31 Oct 2013 13:12:10 -0700 (PDT)
X-AuditID: c1b4fb30-b7eff8e000006d14-4a-5272b9987a8c
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9B.E3.27924.899B2725; Thu, 31 Oct 2013 21:12:09 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 31 Oct 2013 21:12:08 +0100
From: Christer Holmberg 
To: Suhas Nandakumar , Harald Alvestrand 
Thread-Topic: BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
Thread-Index: AQHO1fUJ59+8FRcGh0eroYzegkbjAJoOXs6AgADLBYCAABTsVIAAAEzI
Date: Thu, 31 Oct 2013 20:12:08 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C50038E@ESESSMB209.ericsson.se>
References:  , 
In-Reply-To: 
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_7594FB04B1934943A5C02806D1A2204B1C50038EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RnfmzqIggz/7GS06JrNZnLhxmtli 6vLHLBY753YwO7B4TPm9kdVj56y77B4LNpV6LFnykymAJYrLJiU1J7MstUjfLoErY86S36wF N/Ur/rw4ydbA+Fa9i5GTQ0LARKJl2XQmCFtM4sK99WxdjFwcQgKHGCXeve5iBEkICSxhlPi8 M7OLkYODTcBCovufNogpIuAnMe9IHUgFs4CzxNG1S5hBbGEBH4nd37eyQpT4SrSe1QEJiwi4 SdzYtQashEVAVWLrlU9gNi9QyYubz5ggtt5hlFi48y07SIJTIFDi2IW9LCA2I9Bp30+tYYLY JS5x68l8qJMFJJbsOc8MYYtKvHz8jxXCVpTYebadGaI+X6J3cQsLxDJBiZMzn7BMYBSdhWTU LCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QVI21xJMdC5mQ1Sxg5FjFyJ6bmJmTXm6+ iREYiwe3/DbYwbjpvtghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MOpF bdUJ2fN5m8cts/S1K1jjbbg10w7duFMn6SHeIvXKfZEwq/CzzAInt1fdeyIj1/H+DZfnazwo GzHzdyoDa5XMxLNdoX2v4z+UfWJ4pfzXNTLn+q5HHYK7H2hPPT4xn8FC54ck1/11x5OXnA6+ d29KWNir/rnhumVK++PnzLT7aF9Q6rv9tBJLcUaioRZzUXEiALABGFiTAgAA
Cc: Cullen Jennings , mmusic WG 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
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 Oct 2013 20:12:21 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C50038EESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



I think the BUNDLE spec does say that it is a way to use O/A in order to ne=
gotiate multiplexing.



But, if people don't think it's not clear enough, we can for sure add more =
text :)



Regards,



Christer



________________________________
From: Suhas Nandakumar [suhasietf@gmail.com]
Sent: Thursday, 31 October 2013 9:56 PM
To: Harald Alvestrand
Cc: Cullen Jennings; Christer Holmberg; mmusic WG
Subject: Re: BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP =
?

Good point Harald. Thinking of it , I feel this question applies to all the=
 declarative usages of SDP attributes in the context of BUNDLE.

>From Christer's and your point, I feel the BUNDLE specification should stat=
e it explicitly that only O/A procedures are supported for this version. Th=
at way, we handle all the attributes that has declarative semantics along w=
ith O/A or otherwise.

please let me know your thoughts.

Thanks
Suhas




On Thu, Oct 31, 2013 at 12:49 AM, Harald Alvestrand > wrote:

Could you expand "declaratively" for me here? If it means "stated, not nego=
tiated", this is the same as for many attrs in the draft already. If it mea=
ns "never used in offer/answer", I agree with Christer.

31. okt. 2013 05:52 skrev "Suhas Nandakumar" > f=F8lgende:

Hello All

  Magnus raised an important question while analyzing  RFC6064 SDP attribut=
es related to RTSP SDP attributes for 3GPP.  Since these attributes are dec=
laratively used, SHOULD BUNDLE be dealing with specifying the behavior in N=
on Offer/Answer Scenarios ?

If the answer is NO, we can assign category to be NOT IMPACTED for these at=
tributes,

If the answer is YES, i think there needs to be more discussions on handlin=
g this scenario.

Please let me know your thoughts.


Cheers
Suhas


--_000_7594FB04B1934943A5C02806D1A2204B1C50038EESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










Hi,


 


I think the BUNDLE spec does say that it is a way to use O/A in order to=
 negotiate multiplexing.


 


But, if people don't think it's not clear enough, we can for sure add mo=
re text :)


 


Regards,


 


Christer


 




From: Suhas Nandakumar [suhasietf@gmail.c=
om]

Sent: Thursday, 31 October 2013 9:56 PM

To: Harald Alvestrand

Cc: Cullen Jennings; Christer Holmberg; mmusic WG

Subject: Re: BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATI=
VE SDP ?










Good point Harald. Thinking of it , I feel this question a=
pplies to all the declarative usages of SDP attributes in the context of BU=
NDLE.






From Christer's and your point, I feel the BUNDLE specification should=
 state it explicitly that only O/A procedures are supported for this versio=
n. That way, we handle all the attributes that has declarative semantics al=
ong with O/A or otherwise.







please let me know your thoughts.







Thanks


Suhas



















On Thu, Oct 31, 2013 at 12:49 AM, Harald Alvestr=
and 
<hta@google.com&=
gt; wrote:




Could you expand "declaratively" for me here? If i=
t means "stated, not negotiated", this is the same as for many at=
trs in the draft already. If it means "never used in offer/answer"=
;, I agree with Christer.


31. okt. 2013 05:52 skrev "Suhas Nandakumar=
" <suhasie=
tf@gmail.com> f=F8lgende:








Hello All






  Magnus raised an important question while analyzing  RFC60=
64 SDP attributes related to RTSP SDP attributes for 3GPP.  Since thes=
e attributes are declaratively used, SHOULD BUNDLE be dealing with specifyi=
ng the behavior in Non Offer/Answer Scenarios ?







If the answer is NO, we can assign category to be NOT IMPACTED for the=
se attributes,







If the answer is YES, i think there needs to be more discussions on ha=
ndling this scenario.







Please let me know your thoughts.












Cheers


Suhas


























--_000_7594FB04B1934943A5C02806D1A2204B1C50038EESESSMB209erics_--

From suhasietf@gmail.com  Thu Oct 31 13:26:56 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 B801911E8107 for ; Thu, 31 Oct 2013 13:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.238
X-Spam-Level: 
X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdh-v6Bejd8F for ; Thu, 31 Oct 2013 13:26:55 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0030B11E8195 for ; Thu, 31 Oct 2013 13:26:54 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t61so3162514wes.41 for ; Thu, 31 Oct 2013 13:26:52 -0700 (PDT)
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=/ACqI3JrnsJ7OGnw39Om/RluLtw7qSwDvPSvDFk0q8Q=; b=cL3QUR6eeF7oUtpUTVNx1qxDA4Fu2W6PzLXtNalULqDop89GACMFPHm3MenEmUQoDd HGKM+18iISWQstrFCYKtTI7mT/1ekS71bzefhX5LLdnm259dabq4nptbjwPtY2Vt0Vpt 6CR2BFHLWfNIQF5LP0tnzjsHq1vb1/0MdZ55WiE1MuwQUEGYs5W3XjB2DTiCj4685+gP ir4iD8stP2EAiQKK6KJhaxyFWQmOPatmwJFIiQrqxA344zv9J1XuS/qVm6kkon65a7uy EwO3l8XmASBl/6tuFAZvQOx1ffANDLm5Y7SnzhUAVj1ExN0KmhAkKBfJiYkCeBNg4tmF 5u/A==
MIME-Version: 1.0
X-Received: by 10.180.182.82 with SMTP id ec18mr978998wic.13.1383251212095; Thu, 31 Oct 2013 13:26:52 -0700 (PDT)
Received: by 10.194.178.231 with HTTP; Thu, 31 Oct 2013 13:26:52 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C50038E@ESESSMB209.ericsson.se>
References:    <7594FB04B1934943A5C02806D1A2204B1C50038E@ESESSMB209.ericsson.se>
Date: Thu, 31 Oct 2013 13:26:52 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=047d7b6250b821dd2904ea0f45ca
Cc: Cullen Jennings , Harald Alvestrand , mmusic WG 
Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE SDP ?
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 Oct 2013 20:26:56 -0000

--047d7b6250b821dd2904ea0f45ca
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Christer

   My bad, the very introduction is clear about it .

 This specification defines a new SDP Grouping Framework extension,

   "BUNDLE", that can be used with the Session Description Protocol
   (SDP) Offer/Answer mechanism to negotiate the usage of bundled media,
   which refers to the usage of a single 5-tuple for media associated
   with multiple SDP media descriptions ("m=3D" lines).



Above statement should suffice I believe. I should probably add a
requirement in the Mux Draft saying that the analysis applies only to
Offer/Answer usage of SDP.

If everyone is fine with add an explicit statement in the Mux draft, I
think we can close this issue

Cheers
Suhas


On Thu, Oct 31, 2013 at 1:12 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> I think the BUNDLE spec does say that it is a way to use O/A in order to
> negotiate multiplexing.
>
>
>
> But, if people don't think it's not clear enough, we can for sure add mor=
e
> text :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
> ------------------------------
> *From:* Suhas Nandakumar [suhasietf@gmail.com]
> *Sent:* Thursday, 31 October 2013 9:56 PM
> *To:* Harald Alvestrand
> *Cc:* Cullen Jennings; Christer Holmberg; mmusic WG
> *Subject:* Re: BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATIVE
> SDP ?
>
>   Good point Harald. Thinking of it , I feel this question applies to all
> the declarative usages of SDP attributes in the context of BUNDLE.
>
>  From Christer's and your point, I feel the BUNDLE specification should
> state it explicitly that only O/A procedures are supported for this
> version. That way, we handle all the attributes that has declarative
> semantics along with O/A or otherwise.
>
>  please let me know your thoughts.
>
>  Thanks
> Suhas
>
>
>
>
> On Thu, Oct 31, 2013 at 12:49 AM, Harald Alvestrand wrote=
:
>
>> Could you expand "declaratively" for me here? If it means "stated, not
>> negotiated", this is the same as for many attrs in the draft already. If=
 it
>> means "never used in offer/answer", I agree with Christer.
>> 31. okt. 2013 05:52 skrev "Suhas Nandakumar" 
>> f=F8lgende:
>>
>>  Hello All
>>>
>>>    Magnus raised an important question while analyzing  RFC6064 SDP
>>> attributes related to RTSP SDP attributes for 3GPP.  Since these attrib=
utes
>>> are declaratively used, SHOULD BUNDLE be dealing with specifying the
>>> behavior in Non Offer/Answer Scenarios ?
>>>
>>>  If the answer is NO, we can assign category to be NOT IMPACTED for
>>> these attributes,
>>>
>>>  If the answer is YES, i think there needs to be more discussions on
>>> handling this scenario.
>>>
>>>  Please let me know your thoughts.
>>>
>>>
>>>  Cheers
>>> Suhas
>>>
>>
>

--047d7b6250b821dd2904ea0f45ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Christer

=A0 =A0My bad, the very int=
roduction is clear about it .

=A0This specification defines a new SDP Grouping=
 Framework extension,


   "BUNDLE", that can be used with the Session Description Pr=
otocol
   (SDP) Offer/Answer mechanism to negotiate the usage of bundled media,
   which refers to the usage of a single 5-tuple for media associated
   with multiple SDP media descriptions ("m=3D" lines).
=


A=
bove statement should suffice I believe. I should probably add a requiremen=
t in the Mux Draft saying that the analysis applies only to Offer/Answer us=
age of SDP.



If everyone=
 is fine with add an explicit statement in the Mux draft, I think we can cl=
ose this issue


Cheers
Suhas


On Thu, Oct 31, 2013 at 1:12 PM, Chris=
ter Holmberg <christer.holmberg@ericsson.com> w=
rote:












Hi,


=A0


I think the BUNDLE spec does say that it is a way to use O/A in order to=
 negotiate multiplexing.


=A0


But, if people don't think it's not clear enough, we can for sur=
e add more text :)


=A0


Regards,


=A0


Christer


=A0




Fro=
m: Suhas Nandakumar [suhasietf@gmail.com]

Sent: Thursday, 31 October 2013 9:56 PM

To: Harald Alvestrand

Cc: Cullen Jennings; Christer Holmberg; mmusic WG

Subject: Re: BUNDLE/SDP : ISSUE#3: Should BUNDLE deal with DECLARATI=
VE SDP ?










Good point Harald. Thinking of it , I feel this question a=
pplies to all the declarative usages of SDP attributes in the context of BU=
NDLE.






From Christer's and your point, I feel the BUNDLE specification sh=
ould state it explicitly that only O/A procedures are supported for this ve=
rsion. That way, we handle all the attributes that has declarative semantic=
s along with O/A or otherwise.








please let me know your thoughts.







Thanks


Suhas



















On Thu, Oct 31, 2013 at 12:49 AM, Harald Alvestr=
and 
<hta@google.com&=
gt; wrote:




Could you expand "declaratively" for me here? If i=
t means "stated, not negotiated", this is the same as for many at=
trs in the draft already. If it means "never used in offer/answer"=
;, I agree with Christer.



31. okt. 2013 05:52 skrev "Suhas Nandakumar=
" <suhasie=
tf@gmail.com> f=F8lgende:








Hello All






=A0 Magnus raised an important question while analyzing =A0RFC6064 SDP=
 attributes related to RTSP SDP attributes for 3GPP. =A0Since these attribu=
tes are declaratively used, SHOULD BUNDLE be dealing with specifying the be=
havior in Non Offer/Answer Scenarios ?








If the answer is NO, we can assign category to be NOT IMPACTED for the=
se attributes,







If the answer is YES, i think there needs to be more discussions on ha=
ndling this scenario.







Please let me know your thoughts.












Cheers


Suhas






























--047d7b6250b821dd2904ea0f45ca--

From carl_klatsky@cable.comcast.com  Thu Oct 31 14: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 AA89A11E8231 for ; Thu, 31 Oct 2013 14:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.714
X-Spam-Level: 
X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[AWL=1.517,  BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001,  RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbiWGFtfnxM5 for ; Thu, 31 Oct 2013 14:03:47 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 593D811E8110 for ; Thu, 31 Oct 2013 14:03:47 -0700 (PDT)
Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.102443554; Thu, 31 Oct 2013 15:03:44 -0600
Received: from PACDCEXMB12.cable.comcast.com ([169.254.6.249]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Thu, 31 Oct 2013 17:03:44 -0400
From: "Klatsky, Carl" 
To: "'mmusic@ietf.org'" 
Thread-Topic: General SDP usage question
Thread-Index: Ac7WfKzcJfB0T+VqRzCDf8z6piEQ1g==
Date: Thu, 31 Oct 2013 21:03:41 +0000
Message-ID: <6C15A6B88541034E912E94C2D8BC3E87E8D22464@PACDCEXMB12.cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [24.40.56.178]
x-wiganss: 0100000001001EPACDCEXHUB02.cable.comcast.com ID0048<6C15A6B88541034E912E94C2D8BC3E87E8D22464@PACDCEXMB12.cable.comcast.com>
Content-Type: multipart/alternative; boundary="_000_6C15A6B88541034E912E94C2D8BC3E87E8D22464PACDCEXMB12cabl_"
MIME-Version: 1.0
Subject: [MMUSIC] General SDP usage question
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 Oct 2013 21:03:53 -0000

--_000_6C15A6B88541034E912E94C2D8BC3E87E8D22464PACDCEXMB12cabl_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

HI MMUSICers,

I have a general SDP usage question that could not confirm from the RFCs.

Party A sends an Offer with codecs 9,0
Party B does not support codec 9, so Party B Answer is just 0
Party A sends ACK to setup the call with codec 0

Later, Party A performs a flash hook to place Party B on-hold, and Party A =
sends an Offer again with codecs 9,0
Party B sends a 488 Not Acceptable Here error

Question: When Party A performs the flash hook, should it have only include=
d codec 0 since it has previous knowledge that Party B only supports codec =
0?  Or is what Party A sent acceptable within the definition of this protoc=
ol?

Thanks & Regards,

Carl Klatsky

--_000_6C15A6B88541034E912E94C2D8BC3E87E8D22464PACDCEXMB12cabl_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











HI MMUSICers,


 


I have a general SDP usage question that could not c=
onfirm from the RFCs.


 


Party A sends an Offer with codecs 9,0

Party B does not support codec 9, so Party B Answer =
is just 0


Party A sends ACK to setup the call with codec 0


 


Later, Party A performs a flash hook to place Party =
B on-hold, and Party A sends an Offer again with codecs 9,0


Party B sends a 488 Not Acceptable Here error


 


Question: When Party A performs the flash hook, shou=
ld it have only included codec 0 since it has previous knowledge that Party=
 B only supports codec 0?  Or is what Party A sent acceptable within t=
he definition of this protocol?


 


Thanks & Regards,

 


Carl Klatsky






--_000_6C15A6B88541034E912E94C2D8BC3E87E8D22464PACDCEXMB12cabl_--

From adam@nostrum.com  Thu Oct 31 14:10: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 2D17621E80CE for ; Thu, 31 Oct 2013 14:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.456
X-Spam-Level: 
X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXAbvwB0kmke for ; Thu, 31 Oct 2013 14:10:18 -0700 (PDT)
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 F343421E80A9 for ; Thu, 31 Oct 2013 14:10:17 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9VLAEx4006911 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 31 Oct 2013 16:10:15 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5272C731.9010205@nostrum.com>
Date: Thu, 31 Oct 2013 16:10:09 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Klatsky, Carl" , "'mmusic@ietf.org'" 
References: <6C15A6B88541034E912E94C2D8BC3E87E8D22464@PACDCEXMB12.cable.comcast.com>
In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E87E8D22464@PACDCEXMB12.cable.comcast.com>
Content-Type: multipart/alternative; boundary="------------080209040307050202060203"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [MMUSIC] General SDP usage question
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 Oct 2013 21:10:19 -0000

This is a multi-part message in MIME format.
--------------080209040307050202060203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/31/13 16:03, Klatsky, Carl wrote:
>
> HI MMUSICers,
>
> I have a general SDP usage question that could not confirm from the RFCs.
>
> Party A sends an Offer with codecs 9,0
>
> Party B does not support codec 9, so Party B Answer is just 0
>
> Party A sends ACK to setup the call with codec 0
>
> Later, Party A performs a flash hook to place Party B on-hold, and 
> Party A sends an Offer again with codecs 9,0
>
> Party B sends a 488 Not Acceptable Here error
>
> Question: When Party A performs the flash hook, should it have only 
> included codec 0 since it has previous knowledge that Party B only 
> supports codec 0?  Or is what Party A sent acceptable within the 
> definition of this protocol?
>
>

Yeah, party B is at fault here. It should be able to perform the same 
negotiations on a reinvite as it does on an initial invite.

/a

--------------080209040307050202060203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/31/13 16:03, Klatsky, Carl wrote:

    

    

      
      
      
      

        
HI MMUSICers,

        
 

        
I have a general SDP usage question that
          could not confirm from the RFCs.

        
 

        
Party A sends an Offer with codecs 9,0

        
Party B does not support codec 9, so Party
          B Answer is just 0

        
Party A sends ACK to setup the call with
          codec 0

        
 

        
Later, Party A performs a flash hook to
          place Party B on-hold, and Party A sends an Offer again with
          codecs 9,0

        
Party B sends a 488 Not Acceptable Here
          error

        
 

        
Question: When Party A performs the flash
          hook, should it have only included codec 0 since it has
          previous knowledge that Party B only supports codec 0?  Or is
          what Party A sent acceptable within the definition of this
          protocol?

        
 

        

      

    

    

    Yeah, party B is at fault here. It should be able to perform the
    same negotiations on a reinvite as it does on an initial invite.

    

    /a

  


--------------080209040307050202060203--