Hello Ari

=C2=A0 Many thanks for the re= view. Please see inline

Thanks

Suhas

On Wed, Dec 10,= 2014 at 8:27 PM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com>= ; wrote:

Hi Suhas,

Here are my review comments on the SDP mux draft. Technically I think the d= oc is in pretty good shape, so these are mostly editorial issues.

Cheers,
Ari

Abstract

=C2=A0 =C2=A0In the RTCWEB WG, there is a need to use a
=C2=A0 =C2=A0single 5-tuple for sending and receiving media associated with=
=C2=A0 =C2=A0multiple media descriptions ("m=3D" lines).

Bundling is not RTCWEB-only feature, so I would rather drop the RTCWEB refe= rence at least from the abstract, and write it in more general way (e.g., &= quot;in order to save resources and decrease connection setup times, these = is a need..." like in section 3)

=C2=A0 =C2=A0Such a requirement has
=C2=A0 =C2=A0raised concerns over the semantic implications of the SDP attr= ibutes
=C2=A0 =C2=A0associated with the RTP Media Streams multiplexed over a singl= e
=C2=A0 =C2=A0underlying transport layer flow.

I think we are beyond "raised concerns" and have actually found o= ut it was a real issue, so I would update the wording here.

[Suhas] - I will try to make it more g= eneral in the next version.

=C2=A0

=C2=A0 =C2=A0The scope of this specification is to provide a framework for<= br> =C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.<= br>
s/scope/purpose/

[Suhas] - Accepted=C2=A0

=C2=A0

1.=C2=A0 Introduction

=C2=A0 =C2=A0Real-Time Communication in WEB-browsers (Rtcweb) framework req= uires
=C2=A0 =C2=A0Real-time Transport Protocol (RTP) as the media transport prot= ocol
=C2=A0 =C2=A0and Session Description Protocol (SDP) [RFC4566] for describin= g and
=C2=A0 =C2=A0negotiating multi-media communication sessions.

This (and the following paragraph) should also be more general. Here perhap= s you can use RTCWEB as an example of where such feature is required, but a= dding an RTCWEB reference (e.g. the use case doc) would be good here for co= ntext.

I think it would make sense also to reference the bundle draft already here= and writing a sentence or two about the relationship with this draft.

also:
=C2=A0s/requires/uses/
=C2=A0s/multi-media/multimedia/

[Suhas] - Accpted=C2=A0

3.=C2=A0 Motivation

=C2=A0 =C2=A0This imposes further restrictions on applicability of
=C2=A0 =C2=A0these SDP attributes as they are defined today.

Not sure where "these" here refers to. I guess that word can eith= er be dropped, or clarify which attributes you mean.

[Suhas] - removed the word "these= " for clarity.

=C2=A0

4.=C2=A0 SDP Attribute Analysis Framework

Would it make sense to have "before" and "after" in all= the SDP examples (now there's only the "before" part)?

[Suhas] - I am not sure giving before = and after examples be less confusing. Since we are not defining new way of = doing things to contrast the approaches.=C2=A0

=C2=A0

4.2.=C2=A0 Category: NOT RECOMMENDED

Can/should we recommend here what to do in this case? Not multiplex? Not ad= d such attributes? Either way?

[Suhas] - the definition for the categ= ory already encompasses this as highlighted below.

"Attribut= es that are recommended against multiplexing since their usage under= multiplexing might lead to incorrect behavior."

=C2=A0

4.3.=C2=A0 Category: IDENTICAL

=C2=A0 =C2=A0Attributes that MUST be identical across all the media descrip= tions
=C2=A0 =C2=A0being multiplexed.

Maybe clarify that attributes and their *values* (if exist) must be identic= al.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <allOneLine>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a=3Dzrtp-hash:1.10 fe30efd02423cb054e50efd02487= 42ac7a52c8f91bc2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 df881ae642c371ba46df
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </allOneLine>

The draft uses now 3 different ways of presenting too long SDP lines (see e= .g., 4.5, 4.7 and 14.3.1.1). I guess they are from the defining RFCs, but I= would rather see uniform style across this document. Personally I prefer t= he style of section 4.5 (2 char indent).

=C2=A0

[Suhas] - Will move all the examples= to reflect the format in Section 4.5

=C2=A0

4.4.=C2=A0 Category: SUM

Should clarify where do you put the SUM'ed value.

[Suhas] .. Since the calculated SUM value is expected to be = consumed in the software processing SDP, the definition of this category al= ready captures this fact.

=C2=A0

4.5.=C2=A0 Category: TRANSPORT

=C2=A0 =C2=A0Attributes that can be set normally for multiple items in a =C2=A0 =C2=A0multiplexed group but the software MUST pick just one of the =C2=A0 =C2=A0attribute of the given type for use.=C2=A0 The one chosen is t= he attribute
=C2=A0 =C2=A0associated with the "m=3D" line that represents the = information being
=C2=A0 =C2=A0used for the transport of the RTP.

How do you "pick" the one; by repeating the same value for each b= undled "m=3D"-line?

Also, do we need to consider non-RTP cases too?

[S= uhas] - The expectation is to repeat as per the BUNDLE spec. Hence we have = just added the way such a value is chosen but not the way the chose value i= s represented in the SDP as it is defined in the BUNDLE spec.

=C2= =A0

4.8.=C2=A0 Category: SPECIAL

=C2=A0 =C2=A0Attributes where the text in the source draft must be consulte= d for
=C2=A0 =C2=A0further handling when multiplexed.

s/source draft/specification defining the attribute/

<= br>

[Suhas] - Accepted=C2=A0

5.9.=C2=A0 RFC6773 - DCCP-UDP Encapsulation

=C2=A0 =C2=A0Since RFC6773 is about tunneling DCCP in UDP, with the UDP por= t being
=C2=A0 =C2=A0the port of the DCCP en-/de-capsulation service.

Can't parse the sentence. Something missing here? Or extra "since&= quot;?

[Suhas] -Removed since since it clarifies t= he text better.

=C2=A0

=C2=A0 =C2=A0This MAY or MAY NOT work depending on the
=C2=A0 =C2=A0nature of DCCP encapsulations and ports choses thus rendering = it to
=C2=A0 =C2=A0be very application dependent.

Lower-case (non-RFC2119) "may" and "may not" would be a= ppropriate here. Also s/ports choses/port choices/?

[Suhas] - Done=C2=A0

5.12.=C2=A0 RFC5245 - Interactive Connectivity Establishment (ICE)

Since the ICE candidate behavior is already specified in the bundle draft a= t least reference there would be good? Also please make sure that these sta= y in sync with what bundle has until it's an RFC.

[Suhas] - BUNDLE spec provides O/A procedures for ICE= but does not provide the category assignments for the ICE attributes.

=C2=A0

5.21.=C2=A0 RFC6230 - Media Control Channel Framework

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| cfw-id=C2=A0 | Not Applicable=C2= =A0 | M=C2=A0 =C2=A0 =C2=A0| NORMAL=C2=A0 =C2=A0 =C2=A0 =C2=A0|

Should that be "Not Impacted" as in other NORMAL cases?

[Suhas] - Accepted=C2=A0

5.39.=C2=A0 RFC6189 - ZRTP

=C2=A0 =C2=A0| zrtp-hash=C2=A0 | Complicates if all the=C2=A0 =C2=A0 =C2=A0= =C2=A0 | M=C2=A0 =C2=A0 =C2=A0| NOT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | m=3Dlines are not= authenticated |=C2=A0 =C2=A0 =C2=A0 =C2=A0| RECOMMENDED=C2=A0 |
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | as given in the e= xample below |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |

Where's the example? You mean the one in section 4.2?

[Suhas] - The example SDP was removed from this secti= on to not duplicate but I had forgotten the delete the reference to the exa= mple in here. Hence, will remove the example refernce
=C2=A0

5.46.=C2=A0 RFC2326 - Real Time Streaming Protocol

Could mention here briefly why RTSP is not supported (similar to the next s= ection).

[Suhas] - Done=C2=A0

5.50.=C2=A0 3GPP TS 183.063

=C2=A0 =C2=A0| PSCid=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | Not Impacted | Not-Applicable | NORMAL=C2=A0 =C2=A0 =C2=A0 |

The "Not-Applicable" level is not defined. Could add that to sect= ion 5 or explain here and in 5.58.

[Suhas] - Will add appropriate SDP attribute levels t= o these sections=C2=A0

7.1.=C2=A0 RFC4585 - RTP/AVPF

Are the "Attr Name" here really attribute names or should one use= some other name in this case?

[Suhas] - Will clean up the column name for consisten= cy=C2=A0

7.3.=C2=A0 RFC6285 - Unicast-Based RAMS

This one was missing the "intro description". Could add something= brief for consistency with rest of the doc. Same for 7.6, 9.1, 9.2, 10.x (= I'll leave it up to you where you consider it worthwhile adding).

[Suhas] - Agreed, I will add the intro text for all t= hese sections. It helps readability as well.
=C2=A0
And is the "Attr Name" field here just "Name" intention= ally? Same in following two sections.

13.1.=C2=A0 RFC5109 - RTP Payload Format for Generic FEC

=C2=A0 =C2=A0Draft draft-lennox-payload-ulp-ssrc-mux proposes a simp= le fix to make

This is a bit tricky. This should be a proper reference, but referencing ex= pired drafts is not a good practice either. I would lean towards taking thi= s sentence away since (if?) the fix is not going forward at the IETF.

[Suhas] - Removed this reference.=C2=A0

14.2.1.=C2=A0 Recommendation - Procedures for Potential Configuration Pairi= ng

=C2=A0 =C2=A0that are consistent across all the bundled media descriptions.=

Could add "bundled media" to the terminology section.

[Suhas] removed bundled with multiplexed to keep it u= niform=C2=A0

15.=C2=A0 IANA Considerations

It would be great if someone double-checked that the "Mux Category&quo= t; entries here match to the text. Probably a simple script could do that t= oo.

[Suhas] =C2=A0- I can work on this to be sure=C2=A0

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

--047d7b3a8b1e43845d0509ebfc51-- From nobody Thu Dec 11 01:39:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016E71ACD92; Thu, 11 Dec 2014 01:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 963A_v-fp9nY; Thu, 11 Dec 2014 01:39:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF15C1ACD88; Thu, 11 Dec 2014 01:39:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211093949.21068.72428.idtracker@ietfa.amsl.com> Date: Thu, 11 Dec 2014 01:39:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eBk8dBcrWsroHeHNSdlM5XGQ2oI Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 09:39:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-06.txt Pages : 90 Date : 2014-12-11 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. [I-D.ietf-mmusic-sdp-bundle-negotiation] provides SDP extensions to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a mechanism has made it necessary to understand the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-06 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 nobody Thu Dec 11 01:44:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7941ACD83 for ; Thu, 11 Dec 2014 01:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX0RpZRwYTPY for ; Thu, 11 Dec 2014 01:44:33 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78191ACD79 for ; Thu, 11 Dec 2014 01:44:32 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id g10so2707837pdj.34 for ; Thu, 11 Dec 2014 01:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=I8pQYLP8uBbpQR702Ysa/OexPY4+JaRt0xlqfzjklrU=; b=Gdw8FPvl7M1ebzWgvXn60IouV6aMSZmcme+TOG1aMuwLA1o9kOOf10a1YWyI8L+TYG VUofMOpY2F+0cq2wACzcxlDNcR7T6G8C5bAm4JRRbWek5498BxuOZ7ReWiMngJA/xhgK Z5jahN4x6ZYYLA4MXS/qujltLZu1H1oKfU8D2Fa5RuOcoROIbdxZq7GAxYm/qkueXJeq J6L9CIsuDkTAY8f9G/2m3r6JywyA1K4sGeWxPL08sC2VFs6iAmXAPznKz9dgNP2vHbLk 8SAOLmmP9QmGKBYtqPrjd/WagDnfDizwcAnbC+9DzgDQkpdKATJ1W+0ML5hVB6QAxzBJ P8/A== MIME-Version: 1.0 X-Received: by 10.68.91.37 with SMTP id cb5mr15905119pbb.22.1418291072019; Thu, 11 Dec 2014 01:44:32 -0800 (PST) Received: by 10.70.60.201 with HTTP; Thu, 11 Dec 2014 01:44:31 -0800 (PST) In-Reply-To: <20141211093949.21068.72428.idtracker@ietfa.amsl.com> References: <20141211093949.21068.72428.idtracker@ietfa.amsl.com> Date: Thu, 11 Dec 2014 15:14:31 +0530 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=047d7b676e728932460509ed9f36 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/O8Fm3EaojwSH_um4gFAfRoU5-Hk Subject: [MMUSIC] Fwd: I-D Action: draft-ietf-mmusic-sdp-mux-attributes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 09:44:37 -0000 --047d7b676e728932460509ed9f36 Content-Type: text/plain; charset=UTF-8 Hello All This version incorporates review comments from Christian Grooves and Ari Keranen Cheers Suhas ---------- Forwarded message ---------- From: Date: Thu, Dec 11, 2014 at 3:09 PM Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-06.txt To: i-d-announce@ietf.org Cc: mmusic@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-06.txt Pages : 90 Date : 2014-12-11 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. [I-D.ietf-mmusic-sdp-bundle-negotiation] provides SDP extensions to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a mechanism has made it necessary to understand the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-06 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --047d7b676e728932460509ed9f36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello All

=C2=A0 This versio= n incorporates review comments from Christian Grooves and Ari Keranen

Cheers

Suhas

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Dec 11, 2014 at 3= :09 PM
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribute= s-06.txt
To: i-d-announce@ietf.= org
Cc: mmusic@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 90
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-12-11

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiat= ion]
=C2=A0 =C2=A0provides SDP extensions to negotiate the usage of single 5-tup= le for
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions ("m=3D" lines).=C2=A0 Such a mechanism = has made it necessary to
=C2=A0 =C2=A0understand the semantic implications of the SDP attributes ass= ociated
=C2=A0 =C2=A0with the RTP Media Streams multiplexed over a single underlyin= g
=C2=A0 =C2=A0transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-= attributes-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -mmusic-sdp-mux-attributes-06

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--047d7b676e728932460509ed9f36-- From nobody Thu Dec 11 10:37:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6340A1A87E2 for ; Thu, 11 Dec 2014 10:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gELPENdExEOl for ; Thu, 11 Dec 2014 10:37:54 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AF31A87B1 for ; Thu, 11 Dec 2014 10:37:54 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id h136so4062276oig.5 for ; Thu, 11 Dec 2014 10:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lu1T9haOJj2NfK0KJ2GcvFAMOfXyX5kHpjTYHc+ds6A=; b=jj+EqkC3Nryj9rfGDOtRuaOmNYyLLuEO93bP2Tqm1G+mNtK58rR1ju/Ia5s07jpCrt wcVz357L6Uf/e9vhPnfhUm/XIKr2Gh3gSUdUTpuqtCDVvUgWljdceUC6zOA9vPMXlen9 8TnK7ydTC8G2XzbFroj9Mh8Mb1+yzW2D3upWydNs/yWtj35m2NZLhX1bhiIaVARkGYJv v3UcLhKDORFegiL48hRzhErQb57fanPuK6oDjl94IZPA9jMKJlwkYo/VQUZLzqniODAe mZFa5VytGeV3oajgz2Zk1P0MxikA6Rjvg0hlhVH4KB7ggXLKxOw2kgljQFvZLxXhQ+Be HZ7g== MIME-Version: 1.0 X-Received: by 10.202.212.82 with SMTP id l79mr6988017oig.12.1418323073786; Thu, 11 Dec 2014 10:37:53 -0800 (PST) Received: by 10.202.107.19 with HTTP; Thu, 11 Dec 2014 10:37:53 -0800 (PST) Date: Thu, 11 Dec 2014 10:37:53 -0800 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" , Harald Tveit Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/42QIutWRDo0VgeOWDnNcWaEbFNQ Subject: [MMUSIC] msid and a=ssrc X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 18:37:55 -0000 Appendix B of the msid draft really equivocates about whether the "msid" attribute is valid for use in source specific attributes or not. The IANA section doesn't describe msid as a source specific attribute, but the existence of appendix B is very confusing. Is `a=ssrc:123 msid:blah blah` a valid SDP construct? If so, what does it mean? If not, can appendix B be deleted? From nobody Thu Dec 11 10:42:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D361A0636 for ; Thu, 11 Dec 2014 10:42:06 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlZpzGmC1hMN for ; Thu, 11 Dec 2014 10:42:05 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB001A6FC0 for ; Thu, 11 Dec 2014 10:42:05 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so4353124qcy.18 for ; Thu, 11 Dec 2014 10:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NX/Hb4xr5qqHp/iXUreymwqfxAbivgBtO3yYdwGEWa8=; b=ubPWoHySQKNQM4NiZSXub8U5J7dZlrVBBXdd5G2pP8LVzoUbANHFJWfznkbHUCTj3f szoJ5AMe6flRULIFYCV8lI0yp32bQCQq+gD3ElvjMDxE+ywDd1JpSTYjpiinObdfWj6C puh2cGMhyqTlhHpi/VmsVKnpR32YbQqCMrqAe/Snz6tGaC7bIYytXiavXmrEu6jEH77K D08ILxm7IyV5g8KJ5J/UIbGH63edgcENtQqNinYb80qXkVcahjqoEzuVqqgxb+XERIC3 33pVlGOUt8IYJUourbQB/LR12MVsUWJo/beUrh+gvrl6AIMi0US4an2cJKkmgF1GSQHs RKDw== MIME-Version: 1.0 X-Received: by 10.202.225.197 with SMTP id y188mr7032960oig.94.1418323324259; Thu, 11 Dec 2014 10:42:04 -0800 (PST) Received: by 10.202.107.19 with HTTP; Thu, 11 Dec 2014 10:42:04 -0800 (PST) Date: Thu, 11 Dec 2014 10:42:04 -0800 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/enyd3ozJXLaV5fJ3l2ugAnw-zpk Subject: [MMUSIC] MSID nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 18:42:06 -0000 If this were on github, I'd send a PR... Is this the right name for msid: "Media stream group Identifier" ? Even accounting for the strange capitalization, isn't it a "media stream identifier with optional group identifier" ? OLD: 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. NEW: This document requests IANA to create a new registry called "Semantics for the msid-semantic SDP attribute" in the "Session Description Protocol (SDP) Parameters" group. This registry operates on the Expert Review policy [RFC5226]. The "WMS" semantic is registered in this new registry. I'd also recommend section headings to separate the two new attributes from the creation of the semantic registry. From nobody Thu Dec 11 10:51:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD01A6F01 for ; Thu, 11 Dec 2014 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwG4KtpX7UIp for ; Thu, 11 Dec 2014 10:51:06 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFC01A701C for ; Thu, 11 Dec 2014 10:50:55 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id u20so4097208oif.41 for ; Thu, 11 Dec 2014 10:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SPAga5r5qEI33Rh80Z+ecj6Yixg2ZvrwU0ZuU8qAJGw=; b=B/9bulgXLRw8m3X5PcdOeWveJL67nWBeSxJdCx6xqGGyEqxljDFeRda2mlUz/2nZD1 LYzxoEFCnoViXPo2iT3zDC608u3GzCST3rnLdhSR2o9/gtvMqTY2uT0ZvHivcYi+wdOp ijSBZvHJMP1KzkiSZnlVATwGiK2hfTzyjZdy9G8FwVrgdAtzJGTEUEiT1iSDqH/LaucN K++qqYYoBUr4NYXNf2GOVNgkOAoDVXISrAiyMEfn9g+eTV+kh9Il8CHwd9iRFp9BEf5N ChMnErD5PXRX7NejgumwGUN+9yAeLZXi5Hujj/SXZTZaChDBcD1JCMxRbjaZQHaEu4mw f+vg== MIME-Version: 1.0 X-Received: by 10.182.97.66 with SMTP id dy2mr7393041obb.30.1418323854920; Thu, 11 Dec 2014 10:50:54 -0800 (PST) Received: by 10.202.107.19 with HTTP; Thu, 11 Dec 2014 10:50:54 -0800 (PST) Date: Thu, 11 Dec 2014 10:50:54 -0800 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8ruynsuWc8UZA2bC3WijlRE6vfo Subject: [MMUSIC] MSID and mapping to tracks and streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 18:51:08 -0000 The value of the "identifier" field in the msid consists of the "id" attribute of a MediaStream, as defined in its WebIDL specification. The value of the "appdata" field in the msid consists of the "id" attribute of a MediaStreamTrack, as defined in its WebIDL specification. I think that this is backwards. The media section (m=) corresponds to a track, not a stream. The MediaStream is the secondary identifier. I'd have thought that this was merely personal bias, until I read this: The identifier is a string of ASCII characters that are legal in a "token", 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 it is generated using a random-number generator. This rule, as specified and in combination with the aforementioned, would absolutely prevent the use of multiple tracks from the same stream (i.e., the most common case in existence). Also, this is mightly confusing to me: [...] Once negotiation has completed on a session, there is no memory apart from the currently valid SDP descriptions; an msid "identifier" value that appears in a later negotiation will be taken to refer to a new MediaStream. I have no idea what this might be saying. I can imagine a whole lot of things that might be said here: "a track (not stream) that is bound to a given media section is unaffected by changes in the msid values in that media section during renegotiation" or "a track on the sending side that is bound to a media section, then subsequently swapped out (see replaceTrack) for another, MAY cause the msid values to change in subsequent renegotiations, but this does not result in action from the receiving side". From nobody Thu Dec 11 15:48:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2B1A9042 for ; Thu, 11 Dec 2014 15:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dTCLWTm7-Md for ; Thu, 11 Dec 2014 15:48:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id DAA461A9040 for ; Thu, 11 Dec 2014 15:48:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 43681181CD8; Thu, 11 Dec 2014 15:48:07 -0800 (PST) To: schulzrinne@cs.columbia.edu, anup@netscape.com, robla@real.com, rlb@ipv.sx, alissa@cooperw.in, fandreas@cisco.com, ari.keranen@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141211234807.43681181CD8@rfc-editor.org> Date: Thu, 11 Dec 2014 15:48:07 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f7BsrOzgKD3Qq7hDDTWZFyR_hwc Cc: juliusfriedman@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Technical Errata Reported] RFC2326 (4199) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 23:48:12 -0000 The following errata report has been submitted for RFC2326, "Real Time Streaming Protocol (RTSP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2326&eid=4199 -------------------------------------- Type: Technical Reported by: Julius Friedman Section: 4 Original Text ------------- 4 RTSP Message RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but receivers should be prepared to also interpret CR and LF by themselves as line terminators. Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if done carefully, also allow easy implementation of research prototypes in scripting languages such as Tcl, Visual Basic and Perl. The 10646 character set avoids tricky character set switching, but is invisible to the application as long as US-ASCII is being used. This is also the encoding used for RTCP. ISO 8859-1 translates directly into Unicode with a high-order octet of zero. ISO 8859-1 characters with the most-significant bit set are represented as 1100001x 10xxxxxx. (See RFC 2279 [21]) RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean. Requests contain methods, the object the method is operating upon and parameters to further describe the method. Methods are idempotent, unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server. Corrected Text -------------- 4 RTSP Message RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but receivers should be prepared to also interpret CR and LF by themselves as line terminators. Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if done carefully, also allow easy implementation of research prototypes in scripting languages such as Tcl, Visual Basic and Perl. The 10646 character set avoids tricky character set switching, but is invisible to the application as long as US-ASCII is being used. This is also the encoding used for RTCP. ISO 8859-1 translates directly into Unicode with a high-order octet of zero. ISO 8859-1 characters with the most-significant bit set are represented as 1100001x 10xxxxxx. (See RFC 2279 [21]) RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean. Requests contain methods, the object the method is operating upon and parameters to further describe the method. Methods are idempotent, unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server. *Please note the hexadecimal octet 0x36 should not be included in any part of a RTSP message, if present it should be replaced with binary escaped sequence as defined in: *. Notes ----- Section [15.1 Base Syntax] makes the following definitions: .. safe = "$" | "-" | "_" | "." | "+" .. reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" extra = "!" | "*" | "$'$" | "(" | ")" | "," unreserved = alpha | digit | safe | extra xchar = unreserved | reserved | escape However it doesn't explicitly state the association of "$" [hexadecimal 0x24] Section [10.12 Embedded (Interleaved) Binary Data] specified a mechanism of transferring RTSP messages over a TCP connection with a application layer header consisting of the hexadecimal octet 0x24; followed by a single octet channel identifier and the RFC4571 length specifier of the frame. Due to the fact 0x24 violates section 4's requirements based on the fact it cannot be masked with the octet (AND 0xc3) to ensure it is a valid character I am filing this errata. The chosen octet may also be present, specifically in the types of RTSP messages which are interleaved during playback such as ANNOUNCE. E.g. 0x24 could be a part of the configuration specifying the bits per pixel or audio bit depth as part of the SDP inter alia. In such cases the underlying parser would interpret this octet as the start of the defined application header and cause framing errors which could cause data loss as allow for buffer overflow attacks of carefully crafted binary data. There are also definitions which need to be made in the stadard for what to do when less then the amount of bytes indicated by the application layer frame header are or are not present. (e.g. more or less bytes are required then are present during reception of the given the [$CXX] application header sequence). It is based on these considerations among others that I recommend that "$" [hexadecimal octet 0x24] be added to the reserved list and if necessary an escaping mechanism be defined where it is replaced with an escaped sequence which is agreed upon after consensus. Due to the fact that drafts also specify that RTSP can be extended with any type of message so long as the data is not "$" the first character it is ambiguous may also appear elsewhere in the status line. There are also issues with the ambiguous definition of pdu fragmentation defined in the latest draft, e.g. the mechanism defined as possibly required when pdu's larger then 65535 bytes are used however it specified no way to convey how this occurs or why. The same can also be said for "sink" and "source" however I will address those definitions et al when appropriate. Thank you for your time! Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2326 (no draft string recorded) -------------------------------------- Title : Real Time Streaming Protocol (RTSP) Publication Date : April 1998 Author(s) : H. Schulzrinne, A. Rao, R. Lanphier Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Dec 12 01:24:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367BD1A19E5 for ; Fri, 12 Dec 2014 01:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYodIuUqhzcj for ; Fri, 12 Dec 2014 01:24:42 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C561A90D3 for ; Fri, 12 Dec 2014 01:24:41 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-cc-548ab457cc8d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.82.24955.754BA845; Fri, 12 Dec 2014 10:24:40 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.195.1; Fri, 12 Dec 2014 10:24:39 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 53433110207; Fri, 12 Dec 2014 11:24:39 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C26B75F924; Fri, 12 Dec 2014 11:25:39 +0200 (EET) Received: from ip-193-234-217-42.guest.ericsson.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 483835F7AD; Fri, 12 Dec 2014 11:25:39 +0200 (EET) Message-ID: <548AB456.1020206@ericsson.com> Date: Fri, 12 Dec 2014 11:24:38 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Suhas Nandakumar References: <54885F3D.4040508@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+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW7Elq4Qg21ZFlOXP2axWHzgPqvF zrkdzA7MHlN+b2T12DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgyzq7ex1yw2b/ids9K9gbG GZZdjJwcEgImEm8uNrJC2GISF+6tZ+ti5OIQEjjCKLHv7EwoZwOjREfXS2YIZw+jxOvWr+wg LUICaxklTm3khEhsY5T4cK6LGSTBK6AtMeXaLEYQm0VAVWLX5x1MIDabgK3E6lc3WUBsUYFk ia6XD5kg6gUlTs58AhYXEdCSWL14LlicWSBI4uKJB2BxYQEXiRnr/0EtLpB4OHE3mM0pEChx 8/wmVoh6C4mZ888zQtjyEs1bZzND/KYmcfXcJmaIXlWJq/9eMU5gFJ2FZPUsJO2zkLQvYGRe xShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYJwe3/FbdwXj5jeMhRgEORiUe3oJJXSFCrIll xZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxQsVsk4Gihau5jtq5 rxH6Qm/7I3uMV66+xtB44WXzlZh/oqFXvRevqI356D79B+O8GV+NGDIOT3wdk96UdnFedphV kuXls2X3HL6qXLKIeWF8c/GZxxwZPDOrJE39dyQGPmo/4uatrTflcZnRzISgp5mT3Tfr2LOW 5cdEr7g0kyF9kurhheuUWIozEg21mIuKEwFsABa3dAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/94iUuGCa8CQ2OzkQommu7V6zAmI Cc: "Suhas Nandakumar $snandaku$" , mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes-05 review X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 09:24:45 -0000 Hi Suhas, The updates you propose below look good to me and thanks for the clarifications too. Cheers, Ari On 11/12/14 09:47, Suhas Nandakumar wrote: > Hello Ari > > Many thanks for the review. Please see inline > > Thanks > Suhas > > On Wed, Dec 10, 2014 at 8:27 PM, Ari KerÃ¤nen > wrote: > > Hi Suhas, > > Here are my review comments on the SDP mux draft. Technically I > think the doc is in pretty good shape, so these are mostly editorial > issues. > > > Cheers, > Ari > > > Abstract > > 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). > > Bundling is not RTCWEB-only feature, so I would rather drop the > RTCWEB reference at least from the abstract, and write it in more > general way (e.g., "in order to save resources and decrease > connection setup times, these is a need..." like in section 3) > > > Such a requirement has > raised concerns over the semantic implications of the SDP attributes > associated with the RTP Media Streams multiplexed over a single > underlying transport layer flow. > > I think we are beyond "raised concerns" and have actually found out > it was a real issue, so I would update the wording here. > > > [Suhas] - I will try to make it more general in the next version. > > > The scope of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. > > s/scope/purpose/ > > [Suhas] - Accepted > > 1. Introduction > > Real-Time Communication in WEB-browsers (Rtcweb) framework requires > Real-time Transport Protocol (RTP) as the media transport protocol > and Session Description Protocol (SDP) [RFC4566] for describing and > negotiating multi-media communication sessions. > > This (and the following paragraph) should also be more general. Here > perhaps you can use RTCWEB as an example of where such feature is > required, but adding an RTCWEB reference (e.g. the use case doc) > would be good here for context. > > I think it would make sense also to reference the bundle draft > already here and writing a sentence or two about the relationship > with this draft. > > also: > s/requires/uses/ > s/multi-media/multimedia/ > > [Suhas] - Accpted > > > 3. Motivation > > This imposes further restrictions on applicability of > these SDP attributes as they are defined today. > > Not sure where "these" here refers to. I guess that word can either > be dropped, or clarify which attributes you mean. > > > [Suhas] - removed the word "these" for clarity. > > > 4. SDP Attribute Analysis Framework > > Would it make sense to have "before" and "after" in all the SDP > examples (now there's only the "before" part)? > > > [Suhas] - I am not sure giving before and after examples be less > confusing. Since we are not defining new way of doing things to contrast > the approaches. > > > 4.2. Category: NOT RECOMMENDED > > Can/should we recommend here what to do in this case? Not multiplex? > Not add such attributes? Either way? > > > [Suhas] - the definition for the category already encompasses this as > highlighted below. > "Attributes that are *recommended against multiplexing* since their > usage under multiplexing might lead to incorrect behavior." > > > 4.3. Category: IDENTICAL > > Attributes that MUST be identical across all the media descriptions > being multiplexed. > > Maybe clarify that attributes and their *values* (if exist) must be > identical. > > > > a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742__ac7a52c8f91bc2 > df881ae642c371ba46df > > > The draft uses now 3 different ways of presenting too long SDP lines > (see e.g., 4.5, 4.7 and 14.3.1.1). I guess they are from the > defining RFCs, but I would rather see uniform style across this > document. Personally I prefer the style of section 4.5 (2 char indent). > > [Suhas] - Will move all the examples to reflect the format in Section 4.5 > > 4.4. Category: SUM > > Should clarify where do you put the SUM'ed value. > > > [Suhas] .. Since the calculated SUM value is expected to be consumed in > the software processing SDP, the definition of this category already > captures this fact. > > > > 4.5. Category: TRANSPORT > > Attributes that can be set normally for multiple items in a > multiplexed group but the software MUST pick just one of the > attribute of the given type for use. The one chosen is the > attribute > associated with the "m=" line that represents the information being > used for the transport of the RTP. > > How do you "pick" the one; by repeating the same value for each > bundled "m="-line? > > Also, do we need to consider non-RTP cases too? > > [Suhas] - The expectation is to repeat as per the BUNDLE spec. Hence we > have just added the way such a value is chosen but not the way the chose > value is represented in the SDP as it is defined in the BUNDLE spec. > > > 4.8. Category: SPECIAL > > Attributes where the text in the source draft must be consulted for > further handling when multiplexed. > > s/source draft/specification defining the attribute/ > > > [Suhas] - Accepted > > > > 5.9. RFC6773 - DCCP-UDP Encapsulation > > Since RFC6773 is about tunneling DCCP in UDP, with the UDP port > being > the port of the DCCP en-/de-capsulation service. > > Can't parse the sentence. Something missing here? Or extra "since"? > > [Suhas] -Removed since since it clarifies the text better. > > > This MAY or MAY NOT work depending on the > nature of DCCP encapsulations and ports choses thus rendering it to > be very application dependent. > > Lower-case (non-RFC2119) "may" and "may not" would be appropriate > here. Also s/ports choses/port choices/? > > > [Suhas] - Done > > > > 5.12. RFC5245 - Interactive Connectivity Establishment (ICE) > > Since the ICE candidate behavior is already specified in the bundle > draft at least reference there would be good? Also please make sure > that these stay in sync with what bundle has until it's an RFC. > > [Suhas] - BUNDLE spec provides O/A procedures for ICE but does not > provide the category assignments for the ICE attributes. > > > 5.21. RFC6230 - Media Control Channel Framework > > | cfw-id | Not Applicable | M | NORMAL | > > Should that be "Not Impacted" as in other NORMAL cases? > > > [Suhas] - Accepted > > > > 5.39. RFC6189 - ZRTP > > | zrtp-hash | Complicates if all the | M | NOT > | > | | m=lines are not authenticated | | > RECOMMENDED | > | | as given in the example below | | > | > > Where's the example? You mean the one in section 4.2? > > [Suhas] - The example SDP was removed from this section to not duplicate > but I had forgotten the delete the reference to the example in here. > Hence, will remove the example refernce > > > 5.46. RFC2326 - Real Time Streaming Protocol > > Could mention here briefly why RTSP is not supported (similar to the > next section). > > [Suhas] - Done > > > 5.50. 3GPP TS 183.063 > > | PSCid | Not Impacted | Not-Applicable | NORMAL > | > > The "Not-Applicable" level is not defined. Could add that to section > 5 or explain here and in 5.58. > > [Suhas] - Will add appropriate SDP attribute levels to these sections > > > 7.1. RFC4585 - RTP/AVPF > > Are the "Attr Name" here really attribute names or should one use > some other name in this case? > > [Suhas] - Will clean up the column name for consistency > > > 7.3. RFC6285 - Unicast-Based RAMS > > This one was missing the "intro description". Could add something > brief for consistency with rest of the doc. Same for 7.6, 9.1, 9.2, > 10.x (I'll leave it up to you where you consider it worthwhile adding). > > [Suhas] - Agreed, I will add the intro text for all these sections. It > helps readability as well. > > And is the "Attr Name" field here just "Name" intentionally? Same in > following two sections. > > > 13.1. RFC5109 - RTP Payload Format for Generic FEC > > Draft draft-lennox-payload-ulp-ssrc-__mux proposes a simple fix > to make > > This is a bit tricky. This should be a proper reference, but > referencing expired drafts is not a good practice either. I would > lean towards taking this sentence away since (if?) the fix is not > going forward at the IETF. > > [Suhas] - Removed this reference. > > > 14.2.1. Recommendation - Procedures for Potential Configuration Pairing > > that are consistent across all the bundled media descriptions. > > Could add "bundled media" to the terminology section. > > [Suhas] removed bundled with multiplexed to keep it uniform > > > 15. IANA Considerations > > It would be great if someone double-checked that the "Mux Category" > entries here match to the text. Probably a simple script could do > that too. > > [Suhas] - I can work on this to be sure > > _________________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/__listinfo/mmusic > > > From nobody Fri Dec 12 01:32:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15241AC529 for ; Fri, 12 Dec 2014 01:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHq_1hNGLFr1 for ; Fri, 12 Dec 2014 01:32:03 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB2B1A19E5 for ; Fri, 12 Dec 2014 01:32:03 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-d1-548ab6110225 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.78.04231.116BA845; Fri, 12 Dec 2014 10:32:01 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.195.1; Fri, 12 Dec 2014 10:32:01 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3CC6E1102B1; Fri, 12 Dec 2014 11:32:01 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AE2375F924; Fri, 12 Dec 2014 11:33:01 +0200 (EET) Received: from ip-193-234-217-42.guest.ericsson.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5659A5F7AD; Fri, 12 Dec 2014 11:33:01 +0200 (EET) Message-ID: <548AB610.40006@ericsson.com> Date: Fri, 12 Dec 2014 11:32:00 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvja7gtq4QgwMzdC3eXLSzmLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlXHl92HWgr3MFZ9W/WNrYLzI1MXIwSEhYCKx YxpXFyMnkCkmceHeerYuRi4OIYEjjBJ7Z/eyQjgbGCV23D3FCFIlJLCHUWLDXw+IxFpGie3n HrBAONuAqlY0MoNU8QpoSjw89R9sBYuAqsTE7fogYTYBW4nVr26ygNiiAskSXS8fMkGUC0qc nPkELC4iICOxd9NmZpBWZgFLiSvd1SBhYSDz6fyrYDcwC1hIzJx/HsqWl9j+dg4zxAdqElfP bWKGuFNV4uq/V4wTGIVnIdkwC0n7LCTtCxiZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIE BvfBLb91dzCufu14iFGAg1GJh7dgUleIEGtiWXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphak FsUXleakFh9iZOLglGpgtE+5EKu60EBDUfq+4v6X0wuXhsddFgt9KaD+0NtUXn1u1o5sR924 k3oFt7a6Xjl5d/vUI99EV1xP4PHvXHe1MmjNsnaRtAs7uKZGCVSb/91iEFTa9Ol8W2Te1qa7 Xx4YLpmQs5WNv7tvUr6M71MfHnWbx7ZRf7nuHXK49XaVlOfnF0L/3r1cpMRSnJFoqMVcVJwI AGuC3k1PAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7x9PZ53mChz9WFTGl_JwgHvUSCE Cc: draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-mux-attributes-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 09:32:05 -0000 Hi all, We are now starting a 4 week Working Group Last Call for draft-ietf-mmusic-sdp-mux-attributes-06 as Proposed Standard. Please review and provide any comments you may have on the document by Friday, January 9, 2015. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks, Ari From nobody Fri Dec 12 10:46:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839161A00B7 for ; Fri, 12 Dec 2014 10:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVPpPDj-jTzJ for ; Fri, 12 Dec 2014 10:46:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705F91A6FFD for ; Fri, 12 Dec 2014 10:46:09 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-9e-548b37ef1f7a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.0B.04076.FE73B845; Fri, 12 Dec 2014 19:46:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 19:46:07 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat Thread-Topic: bundle-13 - Paul's comments Thread-Index: AdAUTBbGQ9NZrkv1S3WttkWwhKcfqQAMbXWAACPMjwAAS2d2cA== Date: Fri, 12 Dec 2014 18:46:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D59298E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58DDD5@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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje578+4Qg0vPVCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj7MsjzAWTlCs+bNnG0sB4UrqLkZNDQsBE Yu3hZ8wQtpjEhXvr2boYuTiEBI4wSnROfcwO4SxhlJi7YCFrFyMHB5uAhUT3P22QBhGBOIlp J5+zgtjMAioSr05fBrOFBTQkrqxazgZRoykxfeFvJgjbSWJC72UWEJtFQFXi6b9uJpCRvAK+ EvNnOICEhQQ2M0r8aywGsTkF/CT6NmxnBLEZgW77fmoNE8QqcYlbT+YzQdwsILFkz3mo+0Ul Xj7+xwphK0ksuv0Zql5HYsHuT2wQtrbEsoWvwep5BQQlTs58wjKBUWwWkrGzkLTMQtIyC0nL AkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiB0XNwy2+rHYwHnzseYhTgYFTi4S2c1BUi xJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNdawVfJ33U5o PqN1Skay/+/SeVEvF4fWyM+83q/zztj39dWbApfEU5ZmaUR9/x1y69ScY+XR3+92XdjZqhat f+Lydqu5QftsnntvOzXJg3UycwxLkZZOseC57gbWe78/pYpfvWV3wOxZQkWYwIvjEWtyuNqX nVnzcOKO6EAHVcYfzxY1W87MVWIpzkg01GIuKk4EAF2OoEl/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2etMBq-pzN2ntM8okxa2nYMxdIk Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 18:46:14 -0000 Hi, ------------ >>>> Section 8.5.2: >>>> >>>> I want to check what is intended here. >>>> >>>> Suppose I have previously established a bundle group. It has several m= -lines. In the prior=20 >>>> O/A all of those m-lines had the same address:port. Now I want to chan= ge the bundle address. >>>> >>>> As I read the text in this section, I must change the address in *1* o= f the m-lines, and suggest it as=20 >>>> the offerer bundle address, but leave the old address in the other m-l= ines. >>>> >>>> That isn't what I had been thinking happened. I had been assuming that= the address would be changed in all the m-lines. >>>> >>>> The consequence of this is that if the answerer doesn't want the=20 >>>> change, it will have to reject the one changed m-line, and select the = old address as the bundle address. If I was making the change because I am = no longer capable of >>>> using the old address then this won't work for me= . >>>> It would be better for me to have the entire bundle rejected. >>> >>> The thinking has been that only an accepted BUNDLE address can be assig= ned to multiple m- lines. Your suggestion would change that, because the ne= w address (when >>> suggested in the offer) has not been accepted as a BUND= LE address yet. >> >> First I just wanted to verify that is what is intended. >> That is now settled. >> >> Next is whether that is the best way to handle this. >> >>> Also, even if the offerer assigns the new address to all m- lines, and = the answerer rejects the offer, the offerer still has to fall back to the p= revious offerer BUNDLE address >>>- no matter whether it can use it or not. >>> >>> The answerer could reject all the m-lines yet accept the offer. >>> >> But yes, if the offer itself is rejected then there is need to fall back= . >> >>> AND, assuming we go along with your suggestion, I guess that also=20 >>> means that if a new m- line is added (section 8.5.3), and if the=20 >>> offerer wants the address of that m- line to become the new offerer BUN= DLE address, the offerer must also assign the address of the new m- line al= so to the other m- >>> lines in the BUNDLE group. >>> >> True. That is an argument in favor of keeping things as they are. >> >> I guess you have convinced me. > > I wasn't trying to convince you - I just wanted to make sure we take all = the impacts into consideration. I=20 > have learned that, what first may look like a small and isolated > change= , may have big impacts throughout the document :) > > The advantage of assigning the suggested new offerer BUNDLE address to al= l "m=3D" lines is that you don't have=20 > to send a BAS offer afterwards - which is a big advantage. > > Of course, in the case of adding a new m- line to a BUNDLE group, if the = answerer does not accept it in the=20 > BUNDLE group, the answerer will have to reject it. In that case, the offe= rer could send a new offer, and keep=20 > the new "m=3D" line outside the BUNDLE group. But, IF the new "m=3D" line= IS accepted in the BUNDLE group, the=20 > BAS offer is not needed. > > So, personally I have no problem with your suggestion. Mandating a shared= address (whether it's a previously=20 > selected offerer BUNDLE address, or a new suggested offerer BUNDLE addres= s) makes things more clear. I just=20 > want to make sure others are ok too, because it would be a technical chan= ge. I wonder whether others have an opinion on this issue. The idea would be to, when a new offerer BUNDLE address is suggested, assig= n that suggested address to ALL bundle m- lines within the offer (instead o= f only assigning it to one m- line within the offer, and keep the previousl= y selected offerer BUNDLE address for the other m- lines). The advantage would be that no BAS offer is needed. The only disadvantage is that, if the answerer does not accept (which I thi= nk will be an extremely rare case) the new offerer BUNDLE address, it has t= o reject the offer in order to fallback to the previous offerer BUNDLE addr= ess. =20 Also, when a new m- line is added to a BUNDLE group, the idea would be to a= lways assign the current offerer BUNDLE address to that m- line. If the ans= werer does not accept the m- line in the BUNDLE group, it has to reject the= m- line. But, there would be no need for a BAS offer. Personally, the more I think about it, the more I like the suggestion :) Regards, Christer From nobody Fri Dec 12 17:03:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEABC1A1A5C for ; Fri, 12 Dec 2014 17:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzrRrdY6-Z7f for ; Fri, 12 Dec 2014 17:03:46 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240251A8732 for ; Fri, 12 Dec 2014 17:03:46 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id i50so6182728qgf.23 for ; Fri, 12 Dec 2014 17:03:45 -0800 (PST) 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=Kt12VcUVbancvMUQ2nBBqojMULE2qLXAZJnSEDODObk=; b=fmX8YbthMCm7e9+0M5LeWaRJ/1HCsytt6LC5ubPPn9NASuko/reGCM9llBGnupEdux Z+YOy/sPGF/FBeXyivBbOJSc6AWLqA95ws6TZenZujnUSxiVwCOdR2XA0YdHPsb+sK67 iHjq79HlGq4IIrmTX1Piw6v0m5t6W/jReQN+FI6cJcg1ztTKVi8IhRJtA6+DWSidDyV6 VXv0shxnchonKRz+Jc+c34JuGnCZ+DSo5yvawl2n1riM/MLLh4/ukrobbw+m8ow+3Pps jsCk8xqVwH4ueLVmC0uRPKdPWVmfrnzi2Ba8u7vSVlNXs+rm9wOKUB7Em7VOCyNxyVoa WTEQ== X-Gm-Message-State: ALoCoQl3k1gx4HoXOuTEVTJ6ddsXUw8hM8ZPldGLX+xmQ+mAM+8z/vtrW+jrUAJXOznDmlcpHqmB X-Received: by 10.224.29.134 with SMTP id q6mr35130997qac.73.1418432625331; Fri, 12 Dec 2014 17:03:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 17:03:25 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 13 Dec 2014 02:03:25 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eZRg8-VDGAl35LlW_DW4E3c4ZOk Cc: IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 01:03:47 -0000 2014-12-11 8:01 GMT+01:00 Christer Holmberg : > Of course, in the case of adding a new m- line to a BUNDLE group, if the answerer does not accept it in the BUNDLE group, the answerer will have to reject it. > In that case, the offerer could send a new offer, But you know it wont XD Why to try again by changing "something"? From nobody Fri Dec 12 22:57:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8023C1AC3E3 for ; Fri, 12 Dec 2014 22:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXOpUyRtHHeB for ; Fri, 12 Dec 2014 22:56:59 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486261AC3DF for ; Fri, 12 Dec 2014 22:56:58 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-4f-548be3388d0c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7E.F0.24955.833EB845; Sat, 13 Dec 2014 07:56:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 07:56:56 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] bundle-13 - Paul's comments Thread-Index: AdAUTBbGQ9NZrkv1S3WttkWwhKcfqQAMbXWAACPMjwAAVs4OgAAOcQBq Date: Sat, 13 Dec 2014 06:56:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5A0AE4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RtficXeIwZU2U4vp+2wspi5/zGKx YsMBVgdmj3MN79k9/r7/wOSxZMlPpgDmKC6blNSczLLUIn27BK6MiZfWMxXsU6849OsBUwPj CrUuRk4OCQETiYlHdjFD2GISF+6tZ+ti5OIQEjjCKDHtyBxGCGcxo8TLa8tYuxg5ONgELCS6 /2mDNIgI2Ej8u3CBHcRmFvCSWHRoBguILSxgKPHl0D5GiBojiedTVrJD2G4SLQ8+MYHYLAKq Ek2nDrCB2LwCvhITvv2FWvyDUeLaivNgCU6BQIkvV1aBXccIdN33U2uYIJaJSzR9WckKcbWA xJI956E+EJV4+fgf2J3MAvkSP09yQMwXlDg58wnLBEaRWUi6ZyFUzUJSBRHWlFi/Sx+iWlFi SvdDdghbQ6J1zlx2ZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj7OCW36o7GC+/ cTzEKMDBqMTDu2F1d4gQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamDs1qiTEr99j/NihPvTi3fXM5ocXRFf7nPp+PVpq/78y1Dd9uXy0+m8rvUnVCfezpCK 2bvxvPmp4GllqzY7LTp8qmrx/FyFf7cs//WtK3DdOt+zekb1bMflaWn8Ke9Tn2a8eev2SPAG 59m930J+uDMet51qYNkquj0htKH/ar7s7q+/Cz7GqWzwV2Ipzkg01GIuKk4EADpiVXqTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RCcKDmeHWwoaN7jYG98DPYgQVrk Cc: IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 06:57:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5A0AE4ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCllvdSBjYW4gdHJ5IGFnYWluIGJ5IG5vdCBhZGRpbmcgdGhlIG0tIGxpbmUgdG8gdGhl IEJVTkRMRSBncm91cC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdp bmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBJw7Fh a2kgQmF6IENhc3RpbGxvPG1haWx0bzppYmNAYWxpYXgubmV0Pg0KU2VudDog4oCOMTMv4oCOMTIv 4oCOMjAxNCAwMzowMw0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogSUVURiBNTVVTSUMgV0c8bWFpbHRvOm1tdXNpY0BpZXRm Lm9yZz47IFBhdWwgS3l6aXZhdDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KU3ViamVj dDogUmU6IFtNTVVTSUNdIGJ1bmRsZS0xMyAtIFBhdWwncyBjb21tZW50cw0KDQoyMDE0LTEyLTEx IDg6MDEgR01UKzAxOjAwIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+Og0KPiBPZiBjb3Vyc2UsIGluIHRoZSBjYXNlIG9mIGFkZGluZyBhIG5ldyBtLSBs aW5lIHRvIGEgQlVORExFIGdyb3VwLCBpZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgYWNjZXB0IGl0 IGluIHRoZSBCVU5ETEUgZ3JvdXAsIHRoZSBhbnN3ZXJlciB3aWxsIGhhdmUgdG8gcmVqZWN0IGl0 Lg0KDQo+IEluIHRoYXQgY2FzZSwgdGhlIG9mZmVyZXIgY291bGQgc2VuZCBhIG5ldyBvZmZlciwN Cg0KQnV0IHlvdSBrbm93IGl0IHdvbnQgWEQNCg0KV2h5IHRvIHRyeSBhZ2FpbiBieSBjaGFuZ2lu ZyAic29tZXRoaW5nIj8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D5A0AE4ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGksPGJyPg0KPGJyPg0KWW91IGNhbiB0 cnkgYWdhaW4gYnkgbm90IGFkZGluZyB0aGUgbS0gbGluZSB0byB0aGUgQlVORExFIGdyb3VwLjxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxocj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86 aWJjQGFsaWF4Lm5ldCI+ScOxYWtpIEJheiBDYXN0aWxsbzwvYT48L3NwYW4+PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZv bnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPuKAjjEzL+KAjjEyL+KAjjIwMTQgMDM6 MDM8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5DaHJpc3RlciBIb2xt YmVyZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 Ij48YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5JRVRGIE1NVVNJQyBXRzwvYT47DQo8 YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5QYXVsIEt5eml2YXQ8L2E+PC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5SZTog W01NVVNJQ10gYnVuZGxlLTEzIC0gUGF1bCdzIGNvbW1lbnRzPC9zcGFuPjxicj4NCjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7 Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+MjAxNC0xMi0xMSA4OjAxIEdNVCYjNDM7MDE6MDAg Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs6 PGJyPg0KJmd0OyBPZiBjb3Vyc2UsIGluIHRoZSBjYXNlIG9mIGFkZGluZyBhIG5ldyBtLSBsaW5l IHRvIGEgQlVORExFIGdyb3VwLCBpZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgYWNjZXB0IGl0IGlu IHRoZSBCVU5ETEUgZ3JvdXAsIHRoZSBhbnN3ZXJlciB3aWxsIGhhdmUgdG8gcmVqZWN0IGl0Ljxi cj4NCjxicj4NCiZndDsgSW4gdGhhdCBjYXNlLCB0aGUgb2ZmZXJlciBjb3VsZCBzZW5kIGEgbmV3 IG9mZmVyLDxicj4NCjxicj4NCkJ1dCB5b3Uga25vdyBpdCB3b250IFhEPGJyPg0KPGJyPg0KV2h5 IHRvIHRyeSBhZ2FpbiBieSBjaGFuZ2luZyAmcXVvdDtzb21ldGhpbmcmcXVvdDs/PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpt bXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KbW11c2ljQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwv Zm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D5A0AE4ESESSMB209erics_-- From nobody Sat Dec 13 01:40:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176671A8847 for ; Sat, 13 Dec 2014 01:40:01 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfdm1PBcMJAo for ; Sat, 13 Dec 2014 01:39:59 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6B11A87EE for ; Sat, 13 Dec 2014 01:39:59 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so6661613qcy.32 for ; Sat, 13 Dec 2014 01:39:58 -0800 (PST) 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=AJe9BKEr3GD0yx05V6+UDKafOefhQqK2RO8ZgZj26hc=; b=jalmOhoZeIqwjSjlhX88bIQfAY0y+CRnASk1AZgrqZlyxCdGbuWinTAJkiSiwu8MKU +CLdYRkgOVJuI1qHahsX/lQTEBkpmDFTXZ7myv6zShQqD7ghBerWFX866OLVb0ec5SsO VVLz8kLtzv5rAoWyap2cDu5SzIl1t8LLUHZsDIFSnnucB0wK80lgvLZYem0Q3sV+94wZ gkgjfnq1EsOyisV2RudODsGIkYS6RU+yY9a+qZLhgfD2907oJTQcVcl89iAW7DkW3ck+ Qn9BaH7kPUmlh+coZkcn+zvNfWd+dF9M641bxHDRzaLjH6lMZXGWNs8bdO3pOeijVL6G GAcA== X-Gm-Message-State: ALoCoQnFzjOFJiyBh08vr11aYhBYI72vGwTMfHvA8Z61Gh9e0FqTDR8wRH3L661FL/Q/y6GXzDfy MIME-Version: 1.0 X-Received: by 10.229.196.70 with SMTP id ef6mr38791700qcb.31.1418463598557; Sat, 13 Dec 2014 01:39:58 -0800 (PST) Received: by 10.96.26.135 with HTTP; Sat, 13 Dec 2014 01:39:58 -0800 (PST) Received: by 10.96.26.135 with HTTP; Sat, 13 Dec 2014 01:39:58 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@ESESSMB209.ericsson.se> Date: Sat, 13 Dec 2014 10:39:58 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c35e02eb6069050a15caf1 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PhrFvY6OjFqDilwDb-OepuRj3k8 Cc: mmusic@ietf.org, Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 09:40:01 -0000 --001a11c35e02eb6069050a15caf1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You don't know why the peer rejected it, so trying again (by randomly changing something) does not provide a determinist behavior/result. On 13 Dec 2014 07:56, "Christer Holmberg" wrote: > Hi, > > You can try again by not adding the m- line to the BUNDLE group. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: I=C3=B1aki Baz Castillo > Sent: =E2=80=8E13/=E2=80=8E12/=E2=80=8E2014 03:03 > To: Christer Holmberg > Cc: IETF MMUSIC WG ; Paul Kyzivat > Subject: Re: [MMUSIC] bundle-13 - Paul's comments > > 2014-12-11 8:01 GMT+01:00 Christer Holmberg < > christer.holmberg@ericsson.com>: > > Of course, in the case of adding a new m- line to a BUNDLE group, if th= e > answerer does not accept it in the BUNDLE group, the answerer will have t= o > reject it. > > > In that case, the offerer could send a new offer, > > But you know it wont XD > > Why to try again by changing "something"? > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c35e02eb6069050a15caf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You don't know why the peer rejected it, so trying again= (by randomly changing something) does not provide a determinist behavior/r= esult.

On 13 Dec 2014 07:56, "Christer Holmberg&qu= ot; <christer.holmberg= @ericsson.com> wrote:

Hi,

You can try again by not adding the m- line to the BUNDLE group.

Regards,

Christer

Sent from my Windows Phone

From: I=C3=B1aki Baz Castillo
Sent: =E2=80= =8E13/=E2=80=8E12/=E2=80=8E2014 03:03
To: Christer Holm= berg
Cc: IETF MMUSIC WG; Paul Kyzivat=
Subject: Re: [M= MUSIC] bundle-13 - Paul's comments

2014-12-11 8:01 GMT+01:00 Christer Holmberg <christer.holmberg@ericsson.co= m>:
> Of course, in the case of adding a new m- line to a BUNDLE group, if t= he answerer does not accept it in the BUNDLE group, the answerer will have = to reject it.

> In that case, the offerer could send a new offer,

But you know it wont XD

Why to try again by changing "something"?

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

--001a11c35e02eb6069050a15caf1-- From nobody Sat Dec 13 03:05:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E000F1A002A for ; Sat, 13 Dec 2014 03:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYuvwQPTwwDE for ; Sat, 13 Dec 2014 03:05:46 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E4D1A0026 for ; Sat, 13 Dec 2014 03:05:44 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-5f-548c1d86af40 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.85.04231.68D1C845; Sat, 13 Dec 2014 12:05:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 12:05:42 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] bundle-13 - Paul's comments Thread-Index: AdAUTBbGQ9NZrkv1S3WttkWwhKcfqQAMbXWAACPMjwAAVs4OgAAOcQBqAAOZUQAABFcCkA== Date: Sat, 13 Dec 2014 11:05:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5AB221@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5AB221ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RrddtifE4MZ5Fovp+2wspi5/zGKx YsMBVgdmj3MN79k9/r7/wOSxZMlPpgDmKC6blNSczLLUIn27BK6MLesTCuZVVbz7eJatgfFH WRcjJ4eEgInEtx1X2SBsMYkL99YD2VwcQgJHGCVeX+lkhHAWM0r0nfjE3sXIwcEmYCHR/U8b pEFEwEbi34UL7CA2s4CvxMsFX5hBbGEBQ4kvh/YxQtQYSTyfshKsVUQgTOLpM3cQk0VAVWLt WrC1vECd/d8+g9lCAq3MEq/vO4HYnAKBEv1vNrKA2IxAp30/tYYJYpO4xK0n85kgThaQWLLn PDOELSrx8vE/VghbSWLR7c9Q9fkSbydugNolKHFy5hOWCYyis5CMmoWkbBaSsllAlzILaEqs 36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBkXdw y2/dHYyrXzseYhTgYFTi4d2wujtEiDWxrLgy9xCjNAeLkjjvonPzgoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwpu6wiHqiG+670nnBla3mLrP1xM0Fkg+9vv6T83+Zj+etN8uTU2a96vba vjCv9lLIkSuRnQf2enRLL+6ZPeX2csGor018fywOvin8WnM1/ELRj6Y9M6Ks3zzQb9w0V+FR ycQYxW6xgIqPYTkys0KWy0S+3XYlpTh0XsZtuRWtM/fw6tX4uh3rVWIpzkg01GIuKk4EAHAS 8uqdAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MxX1d4Gtrcgh5I9JOm35c4tHsaI Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 11:05:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5AB221ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5Zb3UgZG9uJ3Qga25vdyB3aHkgdGhlIHBlZXIgcmVqZWN0ZWQgaXQsIHNvIHRyeWlu ZyBhZ2FpbiAoYnkgcmFuZG9tbHkgPmNoYW5naW5nIHNvbWV0aGluZykgZG9lcyBub3QgcHJvdmlk ZSBhIGRldGVybWluaXN0IGJlaGF2aW9yL3Jlc3VsdC4NCg0KV2VsbCwgdGhhdCBpcyB1bmZvcnR1 bmF0ZWx5IGEgZ2VuZXJhbCBwcm9ibGVtIGluIFNEUCBPL0EuIFlvdSBkb27igJl0IGFsd2F5cyBr bm93IGV4YWN0bHkgd2h5IHNvbWV0aGluZyBpcyByZWplY3RlZC4NCg0KQWxzbyBrZWVwIGluIG1p bmQgdGhhdCB0aGUgY3VycmVudCBkcmFmdCwgd2hlbiBhbiBtLSBsaW5lIGlzIGFkZGVkIHRvIGFu IEJVTkRMRSBncm91cCwgYWxyZWFkeSBhbGxvd3MgYXNzaWduaW5nIHRoZSBCVU5ETEUgYWRkcmVz cyB0byB0aGF0IG0tIGxpbmUuIFNvLCB0aGF0IGlzIG5vdGhpbmcgbmV3LiBXaGF0IGlzIG5ldyBp cyB0aGF0IHRoZSBvZmZlcmVyIHdvdWxkIGFsd2F5cyBhZGQgdGhlIEJVTkRMRSBhZGRyZXNzIHRv IHRoZSBhZGRlZCBtLSBsaW5lLCB3aGljaCBhbHNvIGhlbHBzIHNldHRpbmcgdGhlIGFzc29jaWF0 ZWQgU0RQIGF0dHJpYnV0ZSB2YWx1ZXMgZXRjICh0aGUgdmFsdWVzIG1heSBiZSBkaWZmZXJlbnQg ZGVwZW5kaW5nIG9uIHdoZXRoZXIgYW4gbS0gbGluZSBpcyB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAg b3Igbm90LCBhcyBkZXNjcmliZWQgaW4gdGhlIHNkcC1tdXggZHJhZnQpLg0KDQpUaGUgc2Vjb25k IG5ldyB0aGluZyAod2hpY2ggdHJpZ2dlcmVkIHRoaXMgZGlzY3Vzc2lvbikgaXMgdGhhdCwgd2hl biBhIG5ldyBCVU5ETEUgYWRkcmVzcyBpcyBzdWdnZXN0ZWQsIHRoYXQgQlVORExFIGFkZHJlc3Mg c2hvdWxkIGJlIGFzc2lnbmVkIHRvIGFsbCBtLSBsaW5lcyB3aXRoaW4gdGhlIEJVTkRMRSBncm91 cC4gSWYgdGhlIGFuc3dlcmVyIGFjY2VwdHMgaXQsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgQkFT IG9mZmVyLiBJZiB0aGUgYW5zd2VyZXIgcmVqZWN0cyBpdCwgdGhlcmUgd2lsbCBiZSBhIGZhbGxi YWNrIHRvIHRoZSBjdXJyZW50IEJVTkRMRSBhZGRyZXNzICh1c2luZyBub3JtYWwgMzI2NCBydWxl cykuIEkgYmVsaWV2ZSBhbiBhZGRyZXNzIGNoYW5nZSB3aWxsIGJlIGFjY2VwdGVkIGluIG1vc3Qg Y2FzZXMsIGFuZCBpZiBpdOKAmXMgbm90IHRoZW4gdGhlcmUgaXMgcHJvYmFibHkgZ29pbmcgdG8g YmUgcHJvYmxlbXMgYW55d2F54oCmDQoNClNvLCByZWdhcmRpbmcgdGhlIGZpcnN0IGNoYW5nZSAo YWx3YXlzIGFzc2lnbiB0aGUgYnVuZGxlIGFkZHJlc3MgdG8gYSBuZXcgbS0gbGluZSksIEkgc3Vw cG9ydCB0aGF0IG9uZS4gQnV0LCBJIGRvIHJlYWxpemUgcGVvcGxlIG1heSBoYXZlIG90aGVyIG9w aW5pb25zLCBzbyB0aGF04oCZcyB3aHkgSSBsaWtlIHRvIGhlYXIgdGhlbSA6KQ0KDQpSZWdhcmRp bmcgdGhlIHNlY29uZCBjaGFuZ2UgKGFzc2lnbiB0aGUgbmV3IGFkZHJlc3MgdG8gYWxsIG0tIGxp bmVzKSwgSSBwZXJzb25hbGx5IHN1cHBvcnQgYWxzbyB0aGF0IG9uZSwgYW5kIEkgY2Fu4oCZdCBz ZWUgYSByZWFzb24gbm90IHRvIGRvIGl0LiBCdXQsIGFnYWluLCBmZWVsIGZyZWUgdG8gcHJvdmUg bWUgd3JvbmcgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCg0KDQoNCg0K T24gMTMgRGVjIDIwMTQgMDc6NTYsICJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4g d3JvdGU6DQpIaSwNCg0KWW91IGNhbiB0cnkgYWdhaW4gYnkgbm90IGFkZGluZyB0aGUgbS0gbGlu ZSB0byB0aGUgQlVORExFIGdyb3VwLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IEnDsWFraSBCYXogQ2FzdGlsbG88bWFpbHRvOmliY0BhbGlheC5uZXQ+DQpTZW50OiDigI4x My/igI4xMi/igI4yMDE0IDAzOjAzDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBJRVRGIE1NVVNJQyBXRzxtYWlsdG86bW11 c2ljQGlldGYub3JnPjsgUGF1bCBLeXppdmF0PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+ DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gYnVuZGxlLTEzIC0gUGF1bCdzIGNvbW1lbnRzDQoyMDE0 LTEyLTExIDg6MDEgR01UKzAxOjAwIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+Og0K PiBPZiBjb3Vyc2UsIGluIHRoZSBjYXNlIG9mIGFkZGluZyBhIG5ldyBtLSBsaW5lIHRvIGEgQlVO RExFIGdyb3VwLCBpZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgYWNjZXB0IGl0IGluIHRoZSBCVU5E TEUgZ3JvdXAsIHRoZSBhbnN3ZXJlciB3aWxsIGhhdmUgdG8gcmVqZWN0IGl0Lg0KDQo+IEluIHRo YXQgY2FzZSwgdGhlIG9mZmVyZXIgY291bGQgc2VuZCBhIG5ldyBvZmZlciwNCg0KQnV0IHlvdSBr bm93IGl0IHdvbnQgWEQNCg0KV2h5IHRvIHRyeSBhZ2FpbiBieSBjaGFuZ2luZyAic29tZXRoaW5n Ij8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1t dXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D5AB221ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5Zb3UgZG9uJ3Qga25vdyB3aHkgdGhlIHBlZXIgcmVqZWN0 ZWQgaXQsIHNvIHRyeWluZyBhZ2FpbiAoYnkgcmFuZG9tbHkNCjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mZ3Q7PC9zcGFuPmNoYW5naW5nIHNvbWV0aGluZykgZG9lcyBub3QgcHJvdmlkZSBh IGRldGVybWluaXN0IGJlaGF2aW9yL3Jlc3VsdC48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PldlbGwsIHRoYXQgaXMgdW5mb3J0dW5hdGVseSBhIGdlbmVyYWwgcHJvYmxlbSBpbiBTRFAgTy9B LiBZb3UgZG9u4oCZdCBhbHdheXMga25vdyBleGFjdGx5IHdoeSBzb21ldGhpbmcgaXMgcmVqZWN0 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgdGhlIGN1cnJlbnQgZHJhZnQsIHdoZW4gYW4gbS0g bGluZSBpcyBhZGRlZCB0byBhbiBCVU5ETEUgZ3JvdXAsIGFscmVhZHkgYWxsb3dzIGFzc2lnbmlu ZyB0aGUgQlVORExFIGFkZHJlc3MgdG8gdGhhdCBtLSBsaW5lLiBTbywgdGhhdCBpcyBub3RoaW5n IG5ldy4gV2hhdA0KIGlzIG5ldyBpcyB0aGF0IHRoZSBvZmZlcmVyIHdvdWxkIGFsd2F5cyBhZGQg dGhlIEJVTkRMRSBhZGRyZXNzIHRvIHRoZSBhZGRlZCBtLSBsaW5lLCB3aGljaCBhbHNvIGhlbHBz IHNldHRpbmcgdGhlIGFzc29jaWF0ZWQgU0RQIGF0dHJpYnV0ZSB2YWx1ZXMgZXRjICh0aGUgdmFs dWVzIG1heSBiZSBkaWZmZXJlbnQgZGVwZW5kaW5nIG9uIHdoZXRoZXIgYW4gbS0gbGluZSBpcyB3 aXRoaW4gYSBCVU5ETEUgZ3JvdXAgb3Igbm90LCBhcyBkZXNjcmliZWQNCiBpbiB0aGUgc2RwLW11 eCBkcmFmdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoZSBzZWNvbmQgbmV3IHRoaW5nICh3aGljaCB0cmlnZ2VyZWQgdGhpcyBkaXNj dXNzaW9uKSBpcyB0aGF0LCB3aGVuIGEgbmV3IEJVTkRMRSBhZGRyZXNzIGlzIHN1Z2dlc3RlZCwg dGhhdCBCVU5ETEUgYWRkcmVzcyBzaG91bGQgYmUgYXNzaWduZWQgdG8gYWxsIG0tIGxpbmVzIHdp dGhpbiB0aGUgQlVORExFDQogZ3JvdXAuIElmIHRoZSBhbnN3ZXJlciBhY2NlcHRzIGl0LCB0aGVy ZSBpcyBubyBuZWVkIGZvciBhIEJBUyBvZmZlci4gSWYgdGhlIGFuc3dlcmVyIHJlamVjdHMgaXQs IHRoZXJlIHdpbGwgYmUgYSBmYWxsYmFjayB0byB0aGUgY3VycmVudCBCVU5ETEUgYWRkcmVzcyAo dXNpbmcgbm9ybWFsIDMyNjQgcnVsZXMpLiBJIGJlbGlldmUgYW4gYWRkcmVzcyBjaGFuZ2Ugd2ls bCBiZSBhY2NlcHRlZCBpbiBtb3N0IGNhc2VzLCBhbmQgaWYgaXTigJlzIG5vdCB0aGVuDQogdGhl cmUgaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgcHJvYmxlbXMgYW55d2F54oCmPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCByZWdhcmRp bmcgdGhlIGZpcnN0IGNoYW5nZSAoYWx3YXlzIGFzc2lnbiB0aGUgYnVuZGxlIGFkZHJlc3MgdG8g YSBuZXcgbS0gbGluZSksIEkgc3VwcG9ydCB0aGF0IG9uZS4gQnV0LCBJIGRvIHJlYWxpemUgcGVv cGxlIG1heSBoYXZlIG90aGVyIG9waW5pb25zLCBzbyB0aGF04oCZcyB3aHkgSSBsaWtlIHRvDQog aGVhciB0aGVtIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlJlZ2FyZGluZyB0aGUgc2Vjb25kIGNoYW5nZSAoYXNzaWduIHRoZSBuZXcg YWRkcmVzcyB0byBhbGwgbS0gbGluZXMpLCBJIHBlcnNvbmFsbHkgc3VwcG9ydCBhbHNvIHRoYXQg b25lLCBhbmQgSSBjYW7igJl0IHNlZSBhIHJlYXNvbiBub3QgdG8gZG8gaXQuIEJ1dCwgYWdhaW4s IGZlZWwgZnJlZSB0byBwcm92ZQ0KIG1lIHdyb25nIDopPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMyBEZWMgMjAx NCAwNzo1NiwgJnF1b3Q7Q2hyaXN0ZXIgSG9sbWJlcmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGksPGJyPg0KPGJyPg0KWW91 IGNhbiB0cnkgYWdhaW4gYnkgbm90IGFkZGluZyB0aGUgbS0gbGluZSB0byB0aGUgQlVORExFIGdy b3VwLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpT ZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiIHRhcmdldD0iX2JsYW5rIj5J w7Fha2kgQmF6IENhc3RpbGxvPC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNl bnQ6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igI4xMy/igI4xMi/igI4yMDE0IDAzOjAz PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SUVURiBNTVVTSUMgV0c8L2E+Ow0K PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPlBh dWwgS3l6aXZhdDwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0OiA8 L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZTogW01NVVNJQ10gYnVuZGxlLTEzIC0gUGF1 bCdzIGNvbW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+MjAx NC0xMi0xMSA4OjAxIEdNVCYjNDM7MDE6MDAgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7IE9mIGNvdXJz ZSwgaW4gdGhlIGNhc2Ugb2YgYWRkaW5nIGEgbmV3IG0tIGxpbmUgdG8gYSBCVU5ETEUgZ3JvdXAs IGlmIHRoZSBhbnN3ZXJlciBkb2VzIG5vdCBhY2NlcHQgaXQgaW4gdGhlIEJVTkRMRSBncm91cCwg dGhlIGFuc3dlcmVyIHdpbGwgaGF2ZSB0byByZWplY3QgaXQuPGJyPg0KPGJyPg0KJmd0OyBJbiB0 aGF0IGNhc2UsIHRoZSBvZmZlcmVyIGNvdWxkIHNlbmQgYSBuZXcgb2ZmZXIsPGJyPg0KPGJyPg0K QnV0IHlvdSBrbm93IGl0IHdvbnQgWEQ8YnI+DQo8YnI+DQpXaHkgdG8gdHJ5IGFnYWluIGJ5IGNo YW5naW5nICZxdW90O3NvbWV0aGluZyZxdW90Oz88YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11 c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D5AB221ESESSMB209erics_-- From nobody Sat Dec 13 03:34:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761DC1A0037 for ; Sat, 13 Dec 2014 03:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIAB31oudjVV for ; Sat, 13 Dec 2014 03:34:03 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED591A0030 for ; Sat, 13 Dec 2014 03:34:02 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-89-548c2428b492 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.E4.24955.8242C845; Sat, 13 Dec 2014 12:34:01 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.195.1; Sat, 13 Dec 2014 12:34:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 95EEB1102B1; Sat, 13 Dec 2014 13:34:00 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8A3565F8F8; Sat, 13 Dec 2014 13:35:02 +0200 (EET) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E49E75F816; Sat, 13 Dec 2014 13:35:01 +0200 (EET) Message-ID: <548C2428.3060809@ericsson.com> Date: Sat, 13 Dec 2014 11:34:00 +0000 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvja6mSk+IQe8uTov3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZdzuespcsI6p4tO1FvYGxveMXYwcHBICJhLb p6l0MXICmWISF+6tZ+ti5OIQEjjCKLHk9ztWkISQwAZGif47XhCJPYwSpyaeYIZw1jJKzHrR A+UsZ5S4cGUfI0gLr4C2xP8Hm5hBbBYBVYndv46D2WwCjhK3H74EGysqkCyxZuskdoh6QYmT M5+wgNgiAjISezdtBqtnBpoz+84sJhBbWMBIonX+ZGaQs5kF7CUebC2DKJGX2P52DjPEC2oS V89BrBUCWnv13yvGCYzCs5BsmIXQPQtJ9wJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsY gcF9cMtv1R2Ml984HmIU4GBU4uHdsLo7RIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MIZHJTO4vldcalmhOWtWSsGqQMbghpYv7OYca30TGUV27055H776 QPKHYqYjTl/vJKn6JP6/X/wyzPyks83637o+rB52Wta/jPQmylzWjXvqvbItnKkh18Ztexib /pEr3180q/46kPZaa3PHz7Kyz61W0gFKgoLHZlddKj/3m0Wpy6lwb8x3JZbijERDLeai4kQA R8+/U08CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QJuaF0AXBls5SFJNhKqtR5BFPIE Cc: Flemming Andreasen Subject: [MMUSIC] Draft MMUSIC Meeting Minutes from IETF 91 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 11:34:04 -0000 Hi all, The draft meeting minutes for the two MMUSIC sessions at IETF 91 in Honolulu are available at: http://www.ietf.org/proceedings/91/minutes/minutes-91-mmusic Please take a look and let us know if you have any questions or comments. Thanks, Ari & Flemming (MMUSIC co-chairs) From nobody Sat Dec 13 08:48:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF0F1A1A36 for ; Sat, 13 Dec 2014 08:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWuwbRv8fhab for ; Sat, 13 Dec 2014 08:48:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F021A1A07 for ; Sat, 13 Dec 2014 08:48:07 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 67C6D454DAE93; Sat, 13 Dec 2014 16:47:58 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sBDGm35h022906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Dec 2014 11:48:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 11:48:03 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] bundle-13 - Paul's comments Thread-Index: AQHQFIY1q3i7v5ypXUS+mvZc6iMtqZyMuEqNgAC2cYCAAC2OAIAAF/OAgAADSQA= Date: Sat, 13 Dec 2014 16:48:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AB221@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5AB221@ESESSMB209.ericsson.se> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/x33vnmOnD6rrlpyCL5rhlFdVsTE Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 16:48:09 -0000 DQoNCj5Gcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQo+U2VudDogU2F0dXJkYXksIERlY2VtYmVyIDEzLCAy MDE0IDU6MDYgQU0NCg0KPkhpLA0KPllvdSBkb24ndCBrbm93IHdoeSB0aGUgcGVlciByZWplY3Rl ZCBpdCwgc28gdHJ5aW5nIGFnYWluIChieSByYW5kb21seSA+Y2hhbmdpbmcgc29tZXRoaW5nKSBk b2VzIG5vdCBwcm92aWRlIGEgZGV0ZXJtaW5pc3QgYmVoYXZpb3IvcmVzdWx0Lg0KPldlbGwsIHRo YXQgaXMgdW5mb3J0dW5hdGVseSBhIGdlbmVyYWwgcHJvYmxlbSBpbiBTRFAgTy9BLiBZb3UgZG9u 4oCZdCBhbHdheXMgPmtub3cgZXhhY3RseSB3aHkgc29tZXRoaW5nIGlzIHJlamVjdGVkLg0KPkFs c28ga2VlcCBpbiBtaW5kIHRoYXQgdGhlIGN1cnJlbnQgZHJhZnQsIHdoZW4gYW4gbS0gbGluZSBp cyBhZGRlZCB0byBhbiA+QlVORExFIGdyb3VwLCBhbHJlYWR5IGFsbG93cyBhc3NpZ25pbmcgdGhl IEJVTkRMRSBhZGRyZXNzIHRvIHRoYXQgbS0gbGluZS4gPlNvLCB0aGF0IGlzIG5vdGhpbmcgbmV3 LiBXaGF0IGlzIG5ldyBpcyB0aGF0IHRoZSBvZmZlcmVyIHdvdWxkIGFsd2F5cyBhZGQgPnRoZSBC VU5ETEUgYWRkcmVzcyB0byB0aGUgYWRkZWQgbS0gbGluZSwgd2hpY2ggYWxzbyBoZWxwcyBzZXR0 aW5nIHRoZSA+YXNzb2NpYXRlZCBTRFAgYXR0cmlidXRlIHZhbHVlcyBldGMgKHRoZSB2YWx1ZXMg bWF5IGJlIGRpZmZlcmVudCBkZXBlbmRpbmcgPm9uIHdoZXRoZXIgYW4gbS0gbGluZSBpcyB3aXRo aW4gYSBCVU5ETEUgZ3JvdXAgb3Igbm90LCBhcyBkZXNjcmliZWQgaW4gdGhlID5zZHAtbXV4IGRy YWZ0KS4NCj5UaGUgc2Vjb25kIG5ldyB0aGluZyAod2hpY2ggdHJpZ2dlcmVkIHRoaXMgZGlzY3Vz c2lvbikgaXMgdGhhdCwgd2hlbiBhIG5ldyA+QlVORExFIGFkZHJlc3MgaXMgc3VnZ2VzdGVkLCB0 aGF0IEJVTkRMRSBhZGRyZXNzIHNob3VsZCBiZSBhc3NpZ25lZCB0byBhbGwgPm0tIGxpbmVzIHdp dGhpbiB0aGUgQlVORExFIGdyb3VwLiBJZiB0aGUgYW5zd2VyZXIgYWNjZXB0cyBpdCwgdGhlcmUg aXMgbm8gPm5lZWQgZm9yIGEgQkFTIG9mZmVyLiBJZiB0aGUgYW5zd2VyZXIgcmVqZWN0cyBpdCwg dGhlcmUgd2lsbCBiZSBhIGZhbGxiYWNrID50byB0aGUgY3VycmVudCBCVU5ETEUgYWRkcmVzcyAo dXNpbmcgbm9ybWFsIDMyNjQgcnVsZXMpLiBJIGJlbGlldmUgYW4gPmFkZHJlc3MgY2hhbmdlIHdp bGwgYmUgYWNjZXB0ZWQgaW4gbW9zdCBjYXNlcywgYW5kIGlmIGl04oCZcyBub3QgdGhlbiB0aGVy ZSBpcyA+cHJvYmFibHkgZ29pbmcgdG8gYmUgcHJvYmxlbXMgYW55d2F54oCmDQo+U28sIHJlZ2Fy ZGluZyB0aGUgZmlyc3QgY2hhbmdlIChhbHdheXMgYXNzaWduIHRoZSBidW5kbGUgYWRkcmVzcyB0 byBhIG5ldyBtLSA+bGluZSksIEkgc3VwcG9ydCB0aGF0IG9uZS4gQnV0LCBJIGRvIHJlYWxpemUg cGVvcGxlIG1heSBoYXZlIG90aGVyIG9waW5pb25zLCA+c28gdGhhdOKAmXMgd2h5IEkgbGlrZSB0 byBoZWFyIHRoZW0gOikNCg0KPFJhanU+DQpJZiBhbnN3ZXJlciByZWplY3RzIEJVTkRMRSBmb3Ig bmV3IG09IGxpbmUgdGhlbiBhIEJBUyBvZmZlciBpcyByZXF1aXJlZC4gU3VjaCBCQVMgaXMgcmVx dWlyZWQgZm9yIGluaXRpYWwgb2ZmZXIvYW5zd2VyIG9ubHkgaWYgQlVORExFIGlzIG5lZ290aWF0 ZWQuIEJ1dCBmb3Igc3ViLXNlcXVlbnQgb2ZmZXIvYW5zd2VyIG1ha2luZyBCQVMgcmVxdWlyZW1l bnQgZm9yIG5vbi1CVU5ETEUgY2FzZSBpcyBraW5kIG9mIGNvbmZ1c2luZyBhbmQgaW5jb25zaXN0 ZW50LiBJTUhPLCBoYXZpbmcgQkFTIHJlcXVpcmVtZW50IG9ubHkgZm9yIEJVTkRMRSBjYXNlIG9m IGluaXRpYWwgYW5kIHN1Yi1zZXF1ZW50IG9mZmVycyBpcyBjbGVhciBhbmQgc2ltcGxlLg0KDQpB bHNvLCBpZiB0aGUgb2ZmZXJlciB3YW50cyBuZXcgbT0gbGluZSBhcyAnYnVuZGxlLW9ubHknIHRo ZW4gd29uJ3QgaXQgc3RpbGwgc2V0IHBvcnQgdG8gMD8gQWdhaW4sIElNTywgbWFraW5nIHNlbWFu dGljcyBmb3IgdGhpcyBjb25zaXN0ZW50IHdpdGggaW5pdGlhbCBvZmZlciBpcyBhbHNvIGNsZWFy IGFuZCBzaW1wbGUuDQoNCkluaXRpYWwgb2ZmZXIvYW5zd2VyIG5lZ290aWF0aW5nIGEgQlVORExF IGlzIG5vIGd1YXJhbnRlZSB0aGF0IHN1Yi1zZXF1ZW50IG9mZmVyL2Fuc3dlcnMgYWxzbyBkbyBz by4gVGhpcyBpcyBiZWNhdXNlIG5ld2x5IGFkZGVkIG09IGxpbmUncyBkZXN0aW5hdGlvbiBjb3Vs ZCBiZSBkaWZmZXJlbnQgZnJvbSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgQlVORExFRCBkZXN0aW5h dGlvbiBhZGRyZXNzIGFzIGl0IG1heSB0cmF2ZXJzZSBkaWZmZXJlbnQgbWlkZGxlIGJveGVzIChl LmcuIHZpZGVvIHRyYW5zY29kaW5nIHJlcXVpcmVtZW50cyBmb3IgbmV3bHkgYWRkZWQgbT0gbGlu ZSkuIA0KDQo8L1JhanU+DQoNCj5SZWdhcmRpbmcgdGhlIHNlY29uZCBjaGFuZ2UgKGFzc2lnbiB0 aGUgbmV3IGFkZHJlc3MgdG8gYWxsIG0tIGxpbmVzKSwgSSA+cGVyc29uYWxseSBzdXBwb3J0IGFs c28gdGhhdCBvbmUsIGFuZCBJIGNhbuKAmXQgc2VlIGEgcmVhc29uIG5vdCB0byBkbyBpdC4gPkJ1 dCwgYWdhaW4sIGZlZWwgZnJlZSB0byBwcm92ZSBtZSB3cm9uZyA6KQ0KDQo8UmFqdT4NCldoZW4g YSBuZXcgQlVORExFIGFkZHJlc3MgaXMgc3VnZ2VzdGVkLCB0aGUgc2FtZSBTRFAgbWF5IGNoYW5n ZSBzb21lIG90aGVyIHBhcmFtZXRlcnMgKGxpa2UgdmlkZW8gY29kZWNzKS4gU3VjaCBjaGFuZ2Vz IG1heSByZXF1aXJlIGRpZmZlcmVudCBkZXN0aW5hdGlvbihzKSB0byBiZSBwcm92aWRlZCBpbiBT RFAgYW5zd2VyIGFuZCBhcyBhIHJlc3VsdCBwcmV2aW91cyBCVU5ETEUgYWRkcmVzcyBjYW4ndCBi ZSB1c2VkLiBTbywgZXZlbiBpbiB0aGlzIGNhc2UgaXQgaXMgYmV0dGVyIHRvIGJlIGNvbnNpc3Rl bnQgYW5kIGhhdmUgc2FtZSBydWxlcyBhcyBpbml0aWFsIG9mZmVyL2Fuc3dlciwgaS5lLiB0byBh c3NpZ24gdW5pcXVlIGFkZHJlc3MgZm9yIGVhY2ggbT0gbGluZSBhbmQgaWYgQlVORExFIGlzIG5l Z290aWF0ZWQgdGhlbiBmb2xsb3cgdXAgd2l0aCBCQVMgb2ZmZXIuDQoNCkV2ZW4gaWYgdGhlIFNE UCBqdXN0IGNoYW5nZXMgQlVORExFIGFkZHJlc3Mgb25seSwgSU1ITywgdG8gcHJlc2VydmUgY29u c2lzdGVuY3kgYW5kIGtlZXBpbmcgaXQgc2ltcGxlIGl0IGlzIGJldHRlciB0byBzdGljayB0byBp bml0aWFsIG9mZmVyL2Fuc3dlciBzZW1hbnRpY3MuDQoNCjwvUmFqdT4NCg0KQlINClJhanUNCg== From nobody Sat Dec 13 09:28:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC41A1A98 for ; Sat, 13 Dec 2014 09:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1flMo64RAKAs for ; Sat, 13 Dec 2014 09:28:25 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2469D1A1A19 for ; Sat, 13 Dec 2014 09:28:24 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-37-548c7737f1e8 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 18.BB.04231.7377C845; Sat, 13 Dec 2014 18:28:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 18:28:22 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] bundle-13 - Paul's comments Thread-Index: AdAUTBbGQ9NZrkv1S3WttkWwhKcfqQAMbXWAACPMjwAAVs4OgAAOcQBqAAOZUQAABFcCkAAKnDUAAALcZPA= Date: Sat, 13 Dec 2014 17:28:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5AC973@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AB221@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rte8vCfEoGuZqMX0fTYWU5c/ZrFY seEAq0XDxiusDiwerc/2snqca3jP7vH3/QcmjyVLfjIFsERx2aSk5mSWpRbp2yVwZRw5+pa9 YIZexc8/59gaGBt0uxg5OSQETCQer77MCGGLSVy4t56ti5GLQ0jgCKPE0omroJzFjBLvP/Wx dzFycLAJWEh0/9MGiYsINDJKLFkwjwWkm1nAV+L9z+nsILawgKHEl0P7wKaKCBhJPJ+ykh3C TpKYOPsuK4jNIqAqcfrEMrBeXqDeFVd7WCGWzWGRmLJ1MxNIglMgVmL95vlgDYxA530/tYYJ Ypm4xK0n85kgzhaQWLLnPDOELSrx8vE/VghbSWLt4e0sIEczC2hKrN+lD9GqKDGl+yE7xF5B iZMzn7BMYBSbhWTqLISOWUg6ZiHpWMDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMMoO bvmtu4Nx9WvHQ4wCHIxKPLwbVneHCLEmlhVX5h5ilOZgURLnXXRuXrCQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxrSoX2da5m9+eV5YWTHvpJy/3O43CVtD+D/uWcaX5xT+cM35NW90dnYd bJ7kvDq4scBnXai/a+K+1UXTfO8+cDghmBl36c7+8zdmldm3zfh6UfODSq9X80dWdqftZvp8 PxT0vverv1lY/b35Z5bA80q2KM9VH8TsPn2Zom3U51Pq1j39mEDYEiWW4oxEQy3mouJEAG/y f6mTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xIJh4AJmkIAeOgXtTD_AeecJC8U Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 17:28:28 -0000 SGksDQoNCj4+PllvdSBkb24ndCBrbm93IHdoeSB0aGUgcGVlciByZWplY3RlZCBpdCwgc28gdHJ5 aW5nIGFnYWluIChieSByYW5kb21seSANCj4+PmNoYW5naW5nIHNvbWV0aGluZykgZG9lcyBub3Qg cHJvdmlkZSBhIGRldGVybWluaXN0IGJlaGF2aW9yL3Jlc3VsdC4NCj4+Pg0KPj5XZWxsLCB0aGF0 IGlzIHVuZm9ydHVuYXRlbHkgYSBnZW5lcmFsIHByb2JsZW0gaW4gU0RQIE8vQS4gWW91IGRvbuKA mXQgYWx3YXlzIA0KPj5rbm93IGV4YWN0bHkgd2h5IHNvbWV0aGluZyBpcyByZWplY3RlZC4NCj4+ DQo+PkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgdGhlIGN1cnJlbnQgZHJhZnQsIHdoZW4gYW4gbS0g bGluZSBpcyBhZGRlZCB0byBhbiANCj4+QlVORExFIGdyb3VwLCBhbHJlYWR5IGFsbG93cyBhc3Np Z25pbmcgdGhlIEJVTkRMRSBhZGRyZXNzIHRvIHRoYXQgbS0gbGluZS4gDQo+PlNvLCB0aGF0IGlz IG5vdGhpbmcgbmV3LiBXaGF0IGlzIG5ldyBpcyB0aGF0IHRoZSBvZmZlcmVyIHdvdWxkIGFsd2F5 cyBhZGQgDQo+PnRoZSBCVU5ETEUgYWRkcmVzcyB0byB0aGUgYWRkZWQgbS0gbGluZSwgd2hpY2gg YWxzbyBoZWxwcyBzZXR0aW5nIHRoZSANCj4+YXNzb2NpYXRlZCBTRFAgYXR0cmlidXRlIHZhbHVl cyBldGMgKHRoZSB2YWx1ZXMgbWF5IGJlIGRpZmZlcmVudCBkZXBlbmRpbmcgDQo+Pm9uIHdoZXRo ZXIgYW4gbS0gbGluZSBpcyB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAgb3Igbm90LCBhcyBkZXNjcmli ZWQgaW4gdGhlIA0KPj5zZHAtbXV4IGRyYWZ0KS4NCj4+DQo+PlRoZSBzZWNvbmQgbmV3IHRoaW5n ICh3aGljaCB0cmlnZ2VyZWQgdGhpcyBkaXNjdXNzaW9uKSBpcyB0aGF0LCB3aGVuIGEgDQo+Pm5l dyBCVU5ETEUgYWRkcmVzcyBpcyBzdWdnZXN0ZWQsIHRoYXQgQlVORExFIGFkZHJlc3Mgc2hvdWxk IGJlIA0KPj5hc3NpZ25lZCB0byBhbGwgbS0gbGluZXMgd2l0aGluIHRoZSBCVU5ETEUgZ3JvdXAu IElmIHRoZSBhbnN3ZXJlciANCj4+YWNjZXB0cyBpdCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYSBC QVMgb2ZmZXIuIElmIHRoZSBhbnN3ZXJlciByZWplY3RzIA0KPj5pdCwgdGhlcmUgd2lsbCBiZSBh IGZhbGxiYWNrIHRvIHRoZSBjdXJyZW50IEJVTkRMRSBhZGRyZXNzICh1c2luZyANCj4+bm9ybWFs IDMyNjQgcnVsZXMpLiBJIGJlbGlldmUgYW4gYWRkcmVzcyBjaGFuZ2Ugd2lsbCBiZSBhY2NlcHRl ZCBpbiANCj4+bW9zdCBjYXNlcywgYW5kIGlmIGl04oCZcyBub3QgdGhlbiB0aGVyZSBpcyBwcm9i YWJseSBnb2luZyB0byBiZSANCj4+cHJvYmxlbXMgYW55d2F54oCmIFNvLCByZWdhcmRpbmcgdGhl IGZpcnN0IGNoYW5nZSAoYWx3YXlzIGFzc2lnbiB0aGUgDQo+PmJ1bmRsZSBhZGRyZXNzIHRvIGEg bmV3IG0tIGxpbmUpLCBJIHN1cHBvcnQgdGhhdCBvbmUuIEJ1dCwgSSBkbyANCj4+cmVhbGl6ZSBw ZW9wbGUgbWF5IGhhdmUgb3RoZXIgb3BpbmlvbnMsID5zbyB0aGF04oCZcyB3aHkgSSBsaWtlIHRv IGhlYXIgDQo+PnRoZW0gOikNCj4NCj5JZiBhbnN3ZXJlciByZWplY3RzIEJVTkRMRSBmb3IgbmV3 IG09IGxpbmUgdGhlbiBhIEJBUyBvZmZlciBpcyByZXF1aXJlZC4NCg0KV2h5Pw0KDQpBIEJBUyBv ZmZlciBpcyBvbmx5IG5lZWRlZCBpZiB0aGUgc2VsZWN0ZWQgb2ZmZXJlciBCVU5ETEUgYWRkcmVz cyBpcyBkaWZmZXJlbnQgZnJvbSBvbiBvciBtb3JlIG9mIHRoZSBhZGRyZXNzZXMgaW4gdGhlIG9m ZmVyLg0KDQo+U3VjaCBCQVMgaXMgcmVxdWlyZWQgZm9yIGluaXRpYWwgb2ZmZXIvYW5zd2VyIG9u bHkgaWYgQlVORExFIGlzIG5lZ290aWF0ZWQuIEJ1dCBmb3IgDQo+IHN1Yi1zZXF1ZW50IG9mZmVy L2Fuc3dlciBtYWtpbmcgQkFTIHJlcXVpcmVtZW50IGZvciBub24tQlVORExFIGNhc2UgaXMga2lu ZCBvZiA+Y29uZnVzaW5nIGFuZCBpbmNvbnNpc3RlbnQuDQoNCk5vbi1CVU5ETEUgY2FzZT8gSSBh bSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQuLi4NCg0KPklNSE8sIGhhdmluZyBCQVMgcmVxdWlyZW1l bnQgb25seSBmb3IgQlVORExFIGNhc2Ugb2YgaW5pdGlhbCBhbmQgc3ViLXNlcXVlbnQgPm9mZmVy cyBpcyBjbGVhciBhbmQgc2ltcGxlLg0KDQpXZWxsLCB0aGF0IGlzIHdoYXQgdGhlIGRyYWZ0IGN1 cnJlbnRseSBzYXlzLiBQYXVsJ3Mgc3VnZ2VzdGlvbiByZW1vdmVzIHRoZSBuZWVkIGZvciBhIEJB UyBpbiBzdWItc2VxdWVudCBvZmZlcnMsIHdoaWNoIGlzIGdvb2QuDQoNCj5BbHNvLCBpZiB0aGUg b2ZmZXJlciB3YW50cyBuZXcgbT0gbGluZSBhcyAnYnVuZGxlLW9ubHknIHRoZW4gd29uJ3QgaXQg c3RpbGwgc2V0IHBvcnQgdG8gPjA/IEFnYWluLCBJTU8sIG1ha2luZyBzZW1hbnRpY3MgZm9yIHRo aXMgY29uc2lzdGVudCB3aXRoIGluaXRpYWwgb2ZmZXIgaXMgYWxzbyBjbGVhciBhbmQgPnNpbXBs ZS4NCg0KUG9ydCB6ZXJvIGlzIG5vdCBuZWVkZWQgaW4gc3ViLXNlcXVlbnQgb2ZmZXJzLCBiZWNh dXNlIHlvdSBnZXQgdGhlIHNhbWUgZWZmZWN0IGJ5IGFzc2lnbmluZyB0aGUgQlVORExFIGFkZHJl c3MgdG8gdGhlIG5ldyBtLSBsaW5lOiBpZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgYWNjZXB0IGl0 IGludG8gdGhlIEJVTkRMRSBncm91cCwgaXQgTVVTVCByZWplY3QgaXQuIEFuZCwgaWYgdGhlIGFu c3dlcmVyIGFjY2VwdHMgdGhlIG5ldyBtLSBsaW5lIGludG8gdGhlIEJVTkRMRSBncm91cCwgYSBC QVMgb2ZmZXIgaXMgbm90IG5lZWRlZCAoYXMgdGhlIEJVTkRMRSBhZGRyZXNzIHdhcyBhc3NpZ25l ZCB0byB0aGUgbmV3IG0tIGxpbmUgaW4gdGhlIG9mZmVyKS4gDQoNCj5Jbml0aWFsIG9mZmVyL2Fu c3dlciBuZWdvdGlhdGluZyBhIEJVTkRMRSBpcyBubyBndWFyYW50ZWUgdGhhdCBzdWItc2VxdWVu dCA+b2ZmZXIvYW5zd2VycyBhbHNvIGRvIHNvLiBUaGlzIGlzIGJlY2F1c2UgbmV3bHkgYWRkZWQg bT0gbGluZSdzIGRlc3RpbmF0aW9uIGNvdWxkIGJlID5kaWZmZXJlbnQgZnJvbSBwcmV2aW91c2x5 IG5lZ290aWF0ZWQgQlVORExFRCBkZXN0aW5hdGlvbiBhZGRyZXNzIGFzIGl0IG1heSB0cmF2ZXJz ZSA+ZGlmZmVyZW50IG1pZGRsZSBib3hlcyAoZS5nLiB2aWRlbyB0cmFuc2NvZGluZyByZXF1aXJl bWVudHMgZm9yIG5ld2x5IGFkZGVkIG09ID5saW5lKS4NCg0KU3VyZS4gQnV0LCBpbiB0aGF0IGNh c2UgdGhlIG9mZmVyZXIgY2FuIHNlbmQgYSBuZXcgb2ZmZXIsIHdoZXJlIHRoZSBuZXcgbS0gbGlu ZSBpcyBub3QgYWRkZWQgdG8gdGhlIEJVTkRMRSBncm91cC4gVGhhdCBpcyB0aGUgY2FzZSBhbHJl YWR5IHRvZGF5LCBiZWNhdXNlIHRoZSBkcmFmdCBhbGxvd3MgYXNzaWduaW5nIHRoZSBCVU5ETEUg YWRkcmVzcyB0byB0aGUgbmV3IG0tIGxpbmUuDQoNCj4+UmVnYXJkaW5nIHRoZSBzZWNvbmQgY2hh bmdlIChhc3NpZ24gdGhlIG5ldyBhZGRyZXNzIHRvIGFsbCBtLSBsaW5lcyksIEkgDQo+PnBlcnNv bmFsbHkgc3VwcG9ydCBhbHNvIHRoYXQgb25lLCBhbmQgSSBjYW7igJl0IHNlZSBhIHJlYXNvbiBu b3QgdG8gZG8gDQo+Pml0LiBCdXQsIGFnYWluLCBmZWVsIGZyZWUgdG8gcHJvdmUgbWUgd3Jvbmcg OikNCj4NCj4NCj5XaGVuIGEgbmV3IEJVTkRMRSBhZGRyZXNzIGlzIHN1Z2dlc3RlZCwgdGhlIHNh bWUgU0RQIG1heSBjaGFuZ2Ugc29tZSBvdGhlciA+cGFyYW1ldGVycyAobGlrZSB2aWRlbyBjb2Rl Y3MpLiBTdWNoIGNoYW5nZXMgbWF5IHJlcXVpcmUgZGlmZmVyZW50IGRlc3RpbmF0aW9uKHMpIHRv ID5iZSBwcm92aWRlZCBpbiBTRFAgYW5zd2VyIGFuZCBhcyBhIHJlc3VsdCBwcmV2aW91cyBCVU5E TEUgYWRkcmVzcyBjYW4ndCBiZSB1c2VkLiA+U28sIGV2ZW4gaW4gdGhpcyBjYXNlIGl0IGlzIGJl dHRlciB0byBiZSBjb25zaXN0ZW50IGFuZCBoYXZlIHNhbWUgcnVsZXMgYXMgaW5pdGlhbCA+b2Zm ZXIvYW5zd2VyLCBpLmUuIHRvIGFzc2lnbiB1bmlxdWUgYWRkcmVzcyBmb3IgZWFjaCBtPSBsaW5l IGFuZCBpZiBCVU5ETEUgaXMgPm5lZ290aWF0ZWQgdGhlbiBmb2xsb3cgdXAgd2l0aCBCQVMgb2Zm ZXIuDQo+DQo+RXZlbiBpZiB0aGUgU0RQIGp1c3QgY2hhbmdlcyBCVU5ETEUgYWRkcmVzcyBvbmx5 LCBJTUhPLCB0byBwcmVzZXJ2ZSBjb25zaXN0ZW5jeSA+YW5kIGtlZXBpbmcgaXQgc2ltcGxlIGl0 IGlzIGJldHRlciB0byBzdGljayB0byBpbml0aWFsIG9mZmVyL2Fuc3dlciBzZW1hbnRpY3MuDQoN ClBlcmhhcHMgd2Ugc2hvdWxkIGFsbG93IGJvdGggYWx0ZXJuYXRpdmVzIHRoZW4uIEl0IGVuYWJs ZXMgdGhlIGNhc2Ugb2Ygbm90IGhhdmluZyB0byBzZW5kIHRoZSBCQVMgb2ZmZXIgaXMgdGhlIG9m ZmVyIGlzIGFjY2VwdGVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Sun Dec 14 06:55:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F881A6FBA for ; Sun, 14 Dec 2014 06:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7ODnWLTl4LB for ; Sun, 14 Dec 2014 06:55:37 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A624F1A6FB1 for ; Sun, 14 Dec 2014 06:55:36 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 3DF2EE0E4B3E6; Sun, 14 Dec 2014 14:55:31 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sBEEtWkc023175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Dec 2014 09:55:32 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sun, 14 Dec 2014 09:55:32 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] bundle-13 - Paul's comments Thread-Index: AQHQFIY1q3i7v5ypXUS+mvZc6iMtqZyMuEqNgAC2cYCAAC2OAIAAF/OAgAADSQCAAGehgIABCz7g Date: Sun, 14 Dec 2014 14:55:30 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D58B788@ESESSMB209.ericsson.se> <54885995.2060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58DDD5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5A0AE4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AB221@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AC973@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5AC973@ESESSMB209.ericsson.se> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ai9tvjYzpMRbNAsBJ338Dtsqjf8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] bundle-13 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Dec 2014 14:55:39 -0000 PiBIaSwNCj4gDQo+ID4+PllvdSBkb24ndCBrbm93IHdoeSB0aGUgcGVlciByZWplY3RlZCBpdCwg c28gdHJ5aW5nIGFnYWluIChieSByYW5kb21seQ0KPiA+Pj5jaGFuZ2luZyBzb21ldGhpbmcpIGRv ZXMgbm90IHByb3ZpZGUgYSBkZXRlcm1pbmlzdCBiZWhhdmlvci9yZXN1bHQuDQo+ID4+Pg0KPiA+ PldlbGwsIHRoYXQgaXMgdW5mb3J0dW5hdGVseSBhIGdlbmVyYWwgcHJvYmxlbSBpbiBTRFAgTy9B LiBZb3UgZG9u4oCZdCBhbHdheXMNCj4gPj5rbm93IGV4YWN0bHkgd2h5IHNvbWV0aGluZyBpcyBy ZWplY3RlZC4NCj4gPj4NCj4gPj5BbHNvIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBjdXJyZW50IGRy YWZ0LCB3aGVuIGFuIG0tIGxpbmUgaXMgYWRkZWQgdG8gYW4NCj4gPj5CVU5ETEUgZ3JvdXAsIGFs cmVhZHkgYWxsb3dzIGFzc2lnbmluZyB0aGUgQlVORExFIGFkZHJlc3MgdG8gdGhhdCBtLSBsaW5l Lg0KPiA+PlNvLCB0aGF0IGlzIG5vdGhpbmcgbmV3LiBXaGF0IGlzIG5ldyBpcyB0aGF0IHRoZSBv ZmZlcmVyIHdvdWxkIGFsd2F5cyBhZGQNCj4gPj50aGUgQlVORExFIGFkZHJlc3MgdG8gdGhlIGFk ZGVkIG0tIGxpbmUsIHdoaWNoIGFsc28gaGVscHMgc2V0dGluZyB0aGUNCj4gPj5hc3NvY2lhdGVk IFNEUCBhdHRyaWJ1dGUgdmFsdWVzIGV0YyAodGhlIHZhbHVlcyBtYXkgYmUgZGlmZmVyZW50IGRl cGVuZGluZw0KPiA+Pm9uIHdoZXRoZXIgYW4gbS0gbGluZSBpcyB3aXRoaW4gYSBCVU5ETEUgZ3Jv dXAgb3Igbm90LCBhcyBkZXNjcmliZWQgaW4gdGhlDQo+ID4+c2RwLW11eCBkcmFmdCkuDQo+ID4+ DQo+ID4+VGhlIHNlY29uZCBuZXcgdGhpbmcgKHdoaWNoIHRyaWdnZXJlZCB0aGlzIGRpc2N1c3Np b24pIGlzIHRoYXQsIHdoZW4gYQ0KPiA+Pm5ldyBCVU5ETEUgYWRkcmVzcyBpcyBzdWdnZXN0ZWQs IHRoYXQgQlVORExFIGFkZHJlc3Mgc2hvdWxkIGJlDQo+ID4+YXNzaWduZWQgdG8gYWxsIG0tIGxp bmVzIHdpdGhpbiB0aGUgQlVORExFIGdyb3VwLiBJZiB0aGUgYW5zd2VyZXINCj4gPj5hY2NlcHRz IGl0LCB0aGVyZSBpcyBubyBuZWVkIGZvciBhIEJBUyBvZmZlci4gSWYgdGhlIGFuc3dlcmVyIHJl amVjdHMNCj4gPj5pdCwgdGhlcmUgd2lsbCBiZSBhIGZhbGxiYWNrIHRvIHRoZSBjdXJyZW50IEJV TkRMRSBhZGRyZXNzICh1c2luZw0KPiA+Pm5vcm1hbCAzMjY0IHJ1bGVzKS4gSSBiZWxpZXZlIGFu IGFkZHJlc3MgY2hhbmdlIHdpbGwgYmUgYWNjZXB0ZWQgaW4NCj4gPj5tb3N0IGNhc2VzLCBhbmQg aWYgaXTigJlzIG5vdCB0aGVuIHRoZXJlIGlzIHByb2JhYmx5IGdvaW5nIHRvIGJlDQo+ID4+cHJv YmxlbXMgYW55d2F54oCmIFNvLCByZWdhcmRpbmcgdGhlIGZpcnN0IGNoYW5nZSAoYWx3YXlzIGFz c2lnbiB0aGUNCj4gPj5idW5kbGUgYWRkcmVzcyB0byBhIG5ldyBtLSBsaW5lKSwgSSBzdXBwb3J0 IHRoYXQgb25lLiBCdXQsIEkgZG8NCj4gPj5yZWFsaXplIHBlb3BsZSBtYXkgaGF2ZSBvdGhlciBv cGluaW9ucywgPnNvIHRoYXTigJlzIHdoeSBJIGxpa2UgdG8gaGVhcg0KPiA+PnRoZW0gOikNCj4g Pg0KPiA+SWYgYW5zd2VyZXIgcmVqZWN0cyBCVU5ETEUgZm9yIG5ldyBtPSBsaW5lIHRoZW4gYSBC QVMgb2ZmZXIgaXMgcmVxdWlyZWQuDQo+IA0KPiBXaHk/DQoNCjxSYWp1Pg0KSSBtZWFudCBhIG5l dyBvZmZlciwgbm90IEJBUyBvZmZlciwgdG8gdHJ5IG09IGxpbmUgd2l0aG91dCBCVU5ETEUuIFNv cnJ5IGZvciBzdGF0aW5nIGl0IHdyb25nLg0KDQo8L1JhanU+DQoNCj4gDQo+IEEgQkFTIG9mZmVy IGlzIG9ubHkgbmVlZGVkIGlmIHRoZSBzZWxlY3RlZCBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIGlz DQo+IGRpZmZlcmVudCBmcm9tIG9uIG9yIG1vcmUgb2YgdGhlIGFkZHJlc3NlcyBpbiB0aGUgb2Zm ZXIuDQo+IA0KPiA+U3VjaCBCQVMgaXMgcmVxdWlyZWQgZm9yIGluaXRpYWwgb2ZmZXIvYW5zd2Vy IG9ubHkgaWYgQlVORExFIGlzIG5lZ290aWF0ZWQuDQo+IEJ1dCBmb3INCj4gPiBzdWItc2VxdWVu dCBvZmZlci9hbnN3ZXIgbWFraW5nIEJBUyByZXF1aXJlbWVudCBmb3Igbm9uLUJVTkRMRSBjYXNl IGlzDQo+IGtpbmQgb2YgPmNvbmZ1c2luZyBhbmQgaW5jb25zaXN0ZW50Lg0KPiANCj4gTm9uLUJV TkRMRSBjYXNlPyBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZC4uLg0KDQo8UmFqdT4NCkZvciBp bml0aWFsIG9mZmVyLCBhIG5ldyBvZmZlciAoQkFTKSBpcyBuZWVkZWQgdG8gc3luYyB1cCB0aGUg YWRkcmVzc2VlcyBpbiBjYXNlIEJVTkRMRSBpcyBuZWdvdGlhdGVkLiBCdXQsIG1ha2luZyBzdWNo IGEgbmV3IG9mZmVyIHJlcXVpcmVtZW50IHdoZW4gQlVORExFIGlzIHJlamVjdGVkIGZvciBzdWIt c2VxdWVudCBvZmZlciBtYWtlcyB0aGUgaW5pdGlhbCBhbmQgc3ViLXNlcXVlbnQgb2ZmZXIgcHJv Y2VkdXJlcyBpbmNvbnNpc3RlbnQuICANCjwvUmFqdT4NCg0KPiANCj4gPklNSE8sIGhhdmluZyBC QVMgcmVxdWlyZW1lbnQgb25seSBmb3IgQlVORExFIGNhc2Ugb2YgaW5pdGlhbCBhbmQgc3ViLQ0K PiBzZXF1ZW50ID5vZmZlcnMgaXMgY2xlYXIgYW5kIHNpbXBsZS4NCj4gDQo+IFdlbGwsIHRoYXQg aXMgd2hhdCB0aGUgZHJhZnQgY3VycmVudGx5IHNheXMuIFBhdWwncyBzdWdnZXN0aW9uIHJlbW92 ZXMgdGhlDQo+IG5lZWQgZm9yIGEgQkFTIGluIHN1Yi1zZXF1ZW50IG9mZmVycywgd2hpY2ggaXMg Z29vZC4NCg0KPFJhanU+DQpJTU8sIEkgc3RpbGwgdGhpbmsgY3VycmVudCB0ZXh0IGlzIGNsZWFy IGFuZCBzaW1wbGUuIFRyeWluZyB0byBvcHRpbWl6ZSBzdWItc2VxdWVudCBvZmZlcnMgYmFzZWQg b24gcHJpb3IgbmVnb3RpYXRpb24gb2YgQlVORExFIG1heSBjb21wbGljYXRlIGFuZCBhZGRzIGV4 Y2VwdGlvbnMgdG8gdGhlIHJ1bGUgd2hpbGUgb3ZlcmFsbCBnYWlucyBtYXkgYmUgbWluaW1hbC4g SSBhbSBvayBlaXRoZXIgd2F5IHRob3VnaCwgYnV0IG15IHByZWZlcmVuY2Ugdm90ZSBpcyB0byBr ZWVwaW5nIGl0IHNpbXBsZSBpbiBzdWNoIHNjZW5hcmlvcy4NCjwvUmFqdT4NCg0KPiANCj4gPkFs c28sIGlmIHRoZSBvZmZlcmVyIHdhbnRzIG5ldyBtPSBsaW5lIGFzICdidW5kbGUtb25seScgdGhl biB3b24ndCBpdCBzdGlsbA0KPiBzZXQgcG9ydCB0byA+MD8gQWdhaW4sIElNTywgbWFraW5nIHNl bWFudGljcyBmb3IgdGhpcyBjb25zaXN0ZW50IHdpdGgNCj4gaW5pdGlhbCBvZmZlciBpcyBhbHNv IGNsZWFyIGFuZCA+c2ltcGxlLg0KPiANCj4gUG9ydCB6ZXJvIGlzIG5vdCBuZWVkZWQgaW4gc3Vi LXNlcXVlbnQgb2ZmZXJzLCBiZWNhdXNlIHlvdSBnZXQgdGhlIHNhbWUNCj4gZWZmZWN0IGJ5IGFz c2lnbmluZyB0aGUgQlVORExFIGFkZHJlc3MgdG8gdGhlIG5ldyBtLSBsaW5lOiBpZiB0aGUgYW5z d2VyZXINCj4gZG9lcyBub3QgYWNjZXB0IGl0IGludG8gdGhlIEJVTkRMRSBncm91cCwgaXQgTVVT VCByZWplY3QgaXQuIEFuZCwgaWYgdGhlDQo+IGFuc3dlcmVyIGFjY2VwdHMgdGhlIG5ldyBtLSBs aW5lIGludG8gdGhlIEJVTkRMRSBncm91cCwgYSBCQVMgb2ZmZXIgaXMgbm90DQo+IG5lZWRlZCAo YXMgdGhlIEJVTkRMRSBhZGRyZXNzIHdhcyBhc3NpZ25lZCB0byB0aGUgbmV3IG0tIGxpbmUgaW4g dGhlIG9mZmVyKS4NCg0KPFJhanU+DQpQb3J0IDAgaXMgdGhlbiBhbm90aGVyIGV4Y2VwdGlvbiB0 byB0aGUgcnVsZSB3aGljaCBpcyBkaWZmZXJlbnQgZm9yIGZpcnN0IG9mZmVyIHZzLiBzdWItc2Vx dWVudCBvZmZlcnMuIEFnYWluLCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGtlZXAgaXQgc2lt cGxlIGZvciB0aGlzIGFzIHdlbGwuIElmIHdlIGFsbG93IHN1Yi1zZXF1ZW50IG9mZmVycyB0byBi ZSBkaWZmZXJlbnQgdGhlbiB3ZSBuZWVkIHRvIGRlZmluZSBzdWItc2VxdWVudCBvZmZlcnMgYmVp bmcgb2ZmZXJzIHRoYXQgb2NjdXIgYWZ0ZXIgQlVORExFIG5lZ290aWF0aW9uIGlzIGRvbmUgYXMg Zmlyc3QgQlVORExFIGl0c2VsZiBjb3VsZCBiZSBuZWdvdGlhdGVkIGluIGEgc3ViLXNlcXVlbnQg b2ZmZXJzLg0KDQpSZWxhdGVkIHF1ZXN0aW9ucyBvbiA4LjQuMi4gIEJ1bmRsZSBBZGRyZXNzIFN5 bmNocm9uaXphdGlvbiAoQkFTKS4uLg0KYS4gQ2FuIGEgQkFTIG9mZmVyIGNvbnRhaW4gbmV3IG09 IGxpbmVzPyBJZiB5ZXMsIHdoYXQgYXJlIHRoZSBzZW1hbnRpY3M/DQogICBJIHdvdWxkIGFzc3Vt ZSBzYW1lIHNlbWFudGljcyBhcyBhIG5vbi1CQVMgb2ZmZXIuIEEgY2xhcmlmaWNhdGlvbg0KICAg d291bGQgYmUgZ29vZC4NCmIuIENhbiBhbnN3ZXJlciBvcmlnaW5hdGUgYW4gb2ZmZXIgYmVmb3Jl IHRoZSBCQVMgb2ZmZXIvYW5zd2VyIGlzIGRvbmU/IElmIGFuc3dlcmVyIHNlbmRzIGFub3RoZXIg b2ZmZXIgYmVmb3JlIEJBUyBvZmZlciB0aGVuIGNhbiBCQVMgc3luYyBiZSBkb25lIGluIHRoYXQg cm91bmQgb2YgU0RQIG9mZmVyL2Fuc3dlcj8NCg0KPC9SYWp1Pg0KDQo+IA0KPiA+SW5pdGlhbCBv ZmZlci9hbnN3ZXIgbmVnb3RpYXRpbmcgYSBCVU5ETEUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgc3Vi LXNlcXVlbnQNCj4gPm9mZmVyL2Fuc3dlcnMgYWxzbyBkbyBzby4gVGhpcyBpcyBiZWNhdXNlIG5l d2x5IGFkZGVkIG09IGxpbmUncyBkZXN0aW5hdGlvbg0KPiBjb3VsZCBiZSA+ZGlmZmVyZW50IGZy b20gcHJldmlvdXNseSBuZWdvdGlhdGVkIEJVTkRMRUQgZGVzdGluYXRpb24gYWRkcmVzcw0KPiBh cyBpdCBtYXkgdHJhdmVyc2UgPmRpZmZlcmVudCBtaWRkbGUgYm94ZXMgKGUuZy4gdmlkZW8gdHJh bnNjb2RpbmcNCj4gcmVxdWlyZW1lbnRzIGZvciBuZXdseSBhZGRlZCBtPSA+bGluZSkuDQo+IA0K PiBTdXJlLiBCdXQsIGluIHRoYXQgY2FzZSB0aGUgb2ZmZXJlciBjYW4gc2VuZCBhIG5ldyBvZmZl ciwgd2hlcmUgdGhlIG5ldyBtLQ0KPiBsaW5lIGlzIG5vdCBhZGRlZCB0byB0aGUgQlVORExFIGdy b3VwLiBUaGF0IGlzIHRoZSBjYXNlIGFscmVhZHkgdG9kYXksDQo+IGJlY2F1c2UgdGhlIGRyYWZ0 IGFsbG93cyBhc3NpZ25pbmcgdGhlIEJVTkRMRSBhZGRyZXNzIHRvIHRoZSBuZXcgbS0gbGluZS4N Cg0KPFJhanU+DQpZZXMsIGJ1dCBJTU8gc3RpY2tpbmcgdG8gaW5pdGlhbCBvZmZlci9zZW1hbnRp Y3MgbWFrZXMgaXQgc2ltcGxlIGFuZCBzdGlsbCBoYW5kbGUgYWxsIG9mZmVyL2Fuc3dlciBzY2Vu YXJpb3MuIEkgY29uc2lkZXIgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYXMgYW4gb3B0aW1pemF0aW9u LCB3aGljaCBtYXkgbm90IGhhdmUgbWFueSBiZW5lZml0cyBidXQgaW50cm9kdWNlcyBzb21lIHJp c2tzIChhcyBhbHJlYWR5IHBvaW50ZWQgYnkgScOxYWtpIEJheiBDYXN0aWxsbyBlYXJsaWVyLCBv ZiBzZWNvbmQgZ3Vlc3NpbmcgdGhlIHJlYXNvbiBmb3Igb2ZmZXIgcmVqZWN0aW9uKSBhbmQgbW9y ZSBpbXBsZW1lbnRhdGlvbiBsb2dpYy4NCjwvUmFqdT4NCg0KPiANCj4gPj5SZWdhcmRpbmcgdGhl IHNlY29uZCBjaGFuZ2UgKGFzc2lnbiB0aGUgbmV3IGFkZHJlc3MgdG8gYWxsIG0tIGxpbmVzKSwg SQ0KPiA+PnBlcnNvbmFsbHkgc3VwcG9ydCBhbHNvIHRoYXQgb25lLCBhbmQgSSBjYW7igJl0IHNl ZSBhIHJlYXNvbiBub3QgdG8gZG8NCj4gPj5pdC4gQnV0LCBhZ2FpbiwgZmVlbCBmcmVlIHRvIHBy b3ZlIG1lIHdyb25nIDopDQo+ID4NCj4gPg0KPiA+V2hlbiBhIG5ldyBCVU5ETEUgYWRkcmVzcyBp cyBzdWdnZXN0ZWQsIHRoZSBzYW1lIFNEUCBtYXkgY2hhbmdlIHNvbWUgb3RoZXINCj4gPnBhcmFt ZXRlcnMgKGxpa2UgdmlkZW8gY29kZWNzKS4gU3VjaCBjaGFuZ2VzIG1heSByZXF1aXJlIGRpZmZl cmVudA0KPiBkZXN0aW5hdGlvbihzKSB0byA+YmUgcHJvdmlkZWQgaW4gU0RQIGFuc3dlciBhbmQg YXMgYSByZXN1bHQgcHJldmlvdXMgQlVORExFDQo+IGFkZHJlc3MgY2FuJ3QgYmUgdXNlZC4gPlNv LCBldmVuIGluIHRoaXMgY2FzZSBpdCBpcyBiZXR0ZXIgdG8gYmUgY29uc2lzdGVudA0KPiBhbmQg aGF2ZSBzYW1lIHJ1bGVzIGFzIGluaXRpYWwgPm9mZmVyL2Fuc3dlciwgaS5lLiB0byBhc3NpZ24g dW5pcXVlIGFkZHJlc3MNCj4gZm9yIGVhY2ggbT0gbGluZSBhbmQgaWYgQlVORExFIGlzID5uZWdv dGlhdGVkIHRoZW4gZm9sbG93IHVwIHdpdGggQkFTIG9mZmVyLg0KPiA+DQo+ID5FdmVuIGlmIHRo ZSBTRFAganVzdCBjaGFuZ2VzIEJVTkRMRSBhZGRyZXNzIG9ubHksIElNSE8sIHRvIHByZXNlcnZl DQo+IGNvbnNpc3RlbmN5ID5hbmQga2VlcGluZyBpdCBzaW1wbGUgaXQgaXMgYmV0dGVyIHRvIHN0 aWNrIHRvIGluaXRpYWwNCj4gb2ZmZXIvYW5zd2VyIHNlbWFudGljcy4NCj4gDQo+IFBlcmhhcHMg d2Ugc2hvdWxkIGFsbG93IGJvdGggYWx0ZXJuYXRpdmVzIHRoZW4uIEl0IGVuYWJsZXMgdGhlIGNh c2Ugb2Ygbm90DQo+IGhhdmluZyB0byBzZW5kIHRoZSBCQVMgb2ZmZXIgaXMgdGhlIG9mZmVyIGlz IGFjY2VwdGVkLg0KDQo8UmFqdT4NCkkgYW0gb2sgdG8gYWxsb3cgYm90aCBhbHRlcm5hdGl2ZXMu DQo8L1JhanU+DQoNClRoYW5rcw0KUmFqdQ0K From nobody Wed Dec 17 11:14:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE401A1EFC for ; Wed, 17 Dec 2014 11:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA-d30ETQblK for ; Wed, 17 Dec 2014 11:14:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29AA01A1BC4 for ; Wed, 17 Dec 2014 11:14:30 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-8f-5491d6149347 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.36.04076.416D1945; Wed, 17 Dec 2014 20:14:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 20:14:28 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? Thread-Index: AdAZ+3RRvr7r/rTWQnCuYlntTHiCwQAMhfAw Date: Wed, 17 Dec 2014 19:14:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5FE30FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvja7ItYkhBosuq1tMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGV/2fGAq6LavOHX7DksD41ezLkZODgkBE4mm9VdZIWwxiQv3 1rN1MXJxCAkcYZT4N20CE4SzhFFi6Zm3QA4HB5uAhUT3P22QBhEBdYmve3uYQWqEBboYJQ7c a2GFSPQzSnw8KA1hG0n8a3jFDtLLIqAqca7PHSTMK+Ar0diykwXEFgKyz035BGZzCvhJzNuz mBnEZgQ66PupNUwgNrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP6gHlCTWHt7OAlGfL3Hz0z9m iF2CEidnPmGZwCgyC8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtT i4tz042M9FKLMpOLi/Pz9PJSSzYxAmPo4JbfVjsYDz53PMQowMGoxMO74eOEECHWxLLiytxD jNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBixegpLz+nfhZJX2lb4uVw9 eG5t4Qm384LPjvRvvGD2ka9a5OqunT+ysy+8DLq0v7qa5UNl7NXZp7+vPHCP20uqL3PTjs27 la8HyJydY7bx0h8N/zbHl2f1XJQk2HIO5Wc0HvjvPPtLFQ8v1zT3QzMzCkvfv60UWV64MmR5 89apRRXRs1e9eO+jxFKckWioxVxUnAgAgWrCQ4ICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mDDBdQQp3G9P-bHSHX99T4Nsfec Subject: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 19:14:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5FE30FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We currently have the following text in BUNDLE, when the answerer selects t= he offerer BUNDLE address: "If one or more of the criteria are not fulfilled, the answ= erer MUST select the next identification-tag in the identification-tag list, and perf= orm the same criteria check for the "m=3D" line associated with that identificati= on-tag. If there are no more identification-tags in the identification-tag list, th= e answerer MUST NOT create the BUNDLE group." Now, as the text says, if there is no bundled "m=3D" line address in the of= fer which fulfills the criteria for being selected as the offerer BUNDLE address, the answer M= UST NOT create the offerer BUNDLE group. So far so good. However, I think it would be good to have some text on what the answerer DO= ES with the "m=3D" lines (in case the answerer doesn't reject the whole offer, that= is). So, I suggested to append the following text to the paragraph: "Unless the answerer rejects the whole offer, the answerer MUST apply the = answerer procedures for moving an "m=3D" line out of a BUNDLE group to each bundled= "m=3D" line in the offer when creating the answer." This basically means that, if the "m=3D" line had a shared address, or a bu= ndle-only attribute, it will be rejected. If the "m=3D" line had a unique address, the answerer will assign= a unique address in the answer. Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D5FE30FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We currently have the following= text in BUNDLE, when the answerer selects the offerer BUNDLE address:=

&= nbsp; “If one o= r more of the criteria are not fulfilled, the answerer MUST select the next=

&= nbsp; identification-= tag in the identification-tag list, and perform the same criteria

&= nbsp; check for the &= quot;m=3D" line associated with that identification-tag. If there are = no

&= nbsp; more identifica= tion-tags in the identification-tag list, the answerer MUST NOT

&= nbsp; create the BUND= LE group.”

Now, as the text says, if there= is no bundled “m=3D” line address in the offer which fulfills

the criteria for being selected= as the offerer BUNDLE address, the answer MUST NOT

create the offerer BUNDLE group= . So far so good.

However, I think it would be go= od to have some text on what the answerer DOES with

the “m=3D” lines (i= n case the answerer doesn’t reject the whole offer, that is).

So, I suggested to append the f= ollowing text to the paragraph:

&#= 8220;Unless the answerer rejects the whole offer, the answerer MUST a= pply the answerer

pr= ocedures for moving an "m=3D" line out of a BUNDLE group to each = bundled "m=3D" line

in= the offer when creating the answer.”

This basically means that, if t= he “m=3D” line had a shared address, or a bundle-only attribute= , it will be

rejected. If the “m=3D= 221; line had a unique address, the answerer will assign a unique address i= n the answer.

Comments?

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D5FE30FESESSMB209erics_-- From nobody Wed Dec 17 13:11:14 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628BB1A87EC for ; Wed, 17 Dec 2014 13:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcB4GRR4-ans for ; Wed, 17 Dec 2014 13:11:10 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37521A7001 for ; Wed, 17 Dec 2014 13:11:09 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-12v.sys.comcast.net with comcast id UlAt1p00A2Bo0NV01lB8uE; Wed, 17 Dec 2014 21:11:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id UlB81p00B3Ge9ey01lB8a9; Wed, 17 Dec 2014 21:11:08 +0000 Message-ID: <5491F16C.7090901@alum.mit.edu> Date: Wed, 17 Dec 2014 16:11:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418850669; bh=3vjrmtMawFelsAhkXhA3f4/mIPrnOUfyAu1XVY0r/gw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LFSf631NhM+7doJKJLPhB1ycy+V4+2D7cZfJbLskpl3/13r3cIuM2DoFauLKmyedt TTu1AEB9EbXzfGkxVrouX5CE0ZyAIRVFBHlgQmREVGTgckZehigQzf2dQb6v9SWA2r kqHbV+377DzTXzUgmMun6VlcToNbiN9/aPGBYbnVrinM7+cbb0u08fERQ7tJAzx2Yq 2FLrcnyNBG24cVVoF0eJCvdeLsvIkFMYeSx1VnkWp5ZfMFTwzpKw84l8+0a8KInNm3 kkoMewWhEapW3t/tE8fRuX0tQqCYzeNKeMizKWMCpqntcWKMhj+7GWyfxSiH4R6gIA 8sIr4v4lVKdrg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ib7JsXZUa7iy7M8hDY7zxKVfaL0 Subject: Re: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 21:11:11 -0000 This sounds good to me. Thanks, Paul On 12/17/14 2:14 PM, Christer Holmberg wrote: > Hi, > > We currently have the following text in BUNDLE, when the answerer > selects the offerer BUNDLE address: > > “If one or more of the criteria are not fulfilled, the > answerer MUST select the next > > identification-tag in the identification-tag list, and > perform the same criteria > > check for the "m=" line associated with that > identification-tag. If there are no > > more identification-tags in the identification-tag > list, the answerer MUST NOT > > create the BUNDLE group.” > > Now, as the text says, if there is no bundled “m=” line address in the > offer which fulfills > > the criteria for being selected as the offerer BUNDLE address, the > answer MUST NOT > > create the offerer BUNDLE group. So far so good. > > However, I think it would be good to have some text on what the answerer > DOES with > > the “m=” lines (in case the answerer doesn’t reject the whole offer, > that is). > > So, I suggested to append the following text to the paragraph: > > “Unless the answerer rejects the whole offer, the answerer MUST apply > the answerer > > procedures for moving an "m=" line out of a BUNDLE group to each > bundled "m=" line > > in the offer when creating the answer.” > > This basically means that, if the “m=” line had a shared address, or a > bundle-only attribute, it will be > > rejected. If the “m=” line had a unique address, the answerer will > assign a unique address in the answer. > > Comments? > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Dec 17 14:16:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A181A8821 for ; Wed, 17 Dec 2014 14:16:09 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk3GOc6TJtDC for ; Wed, 17 Dec 2014 14:16:07 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE80C1A87EB for ; Wed, 17 Dec 2014 14:16:00 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id wp4so6505492obc.6 for ; Wed, 17 Dec 2014 14:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O1HKoXEZX3WpvXThXAW1S8uLe3Q3AXUbG9nj1nZ6vLo=; b=vayf0ooLKVhdAmkDiXWLj4ussFvX/l6OgeP5eHEM5PPf5sqEw832qeKVoiSH8cYyQk ERELEXeSUbUtIFm/7JefX0UVGPTPwOwdJPwEev/zMPXKM+i3fLvBt+fA+M8KphXNaTZI d067/XBzbHavQea/N21k+2L2z530lPI2ALl970kAWIzVV4Zc/S7ywbwruOvu+JO2+l7m PcAaq+dN3msYBmFMZRH5TSN8Lg5omMZAU95NfOEmdo6Xs4TPilHvDevemopyu3isGJ5S ChhXlcrlzaaoA9UPajGhFk6Xww7U2/M6bxM7fJ8YdnXiGq/YeBo0ivjR3QnUdhoBQo1/ lSVQ== MIME-Version: 1.0 X-Received: by 10.202.219.198 with SMTP id s189mr16389518oig.72.1418854560204; Wed, 17 Dec 2014 14:16:00 -0800 (PST) Received: by 10.202.49.203 with HTTP; Wed, 17 Dec 2014 14:16:00 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> Date: Wed, 17 Dec 2014 14:16:00 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uca_PR1AwQTJWl3sWskpXxqhkbM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 22:16:09 -0000 On 17 December 2014 at 11:14, Christer Holmberg wrote: > =E2=80=9CUnless the answerer rejects the whole offer, the answerer MUST = apply the > answerer > > procedures for moving an "m=3D" line out of a BUNDLE group to each bundl= ed > "m=3D" line > > in the offer when creating the answer.=E2=80=9D This statement, out of context, reads as "don't negotiate bundle". Though I guess that it is hard to get all the conditions right. After all, bundle-only sections don't get moved out either. From nobody Thu Dec 18 05:52:50 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27791A8997 for ; Thu, 18 Dec 2014 05:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C70HoT96tHmJ for ; Thu, 18 Dec 2014 05:52:47 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38021A899D for ; Thu, 18 Dec 2014 05:52:46 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-59-5492dc2c5879 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.FC.04231.C2CD2945; Thu, 18 Dec 2014 14:52:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 14:52:44 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? Thread-Index: AdAZ+3RRvr7r/rTWQnCuYlntTHiCwQAMhfAwAARG8QAAIr/5oA== Date: Thu, 18 Dec 2014 13:52:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D603518@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5FE30F@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja7unUkhBsfes1tcO/OP0WLq8scs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGq8O72ApesVcsnvKGpYHxAnsXIyeHhICJ xPXdu9kgbDGJC/fWg9lCAkcYJZavN4ewlzBK3Puf0sXIwcEmYCHR/U8bJCwioCux6OwDdpAw s4C6xNXFQV2MXBzCAjMZJd6vus8E4ogIzGKUeDB9OgtEg5PE+k9rwfayCKhKrHx0FCzOK+Ar cfnnBRaQBiGBG4wSOybsZAJJcAoESqw4vYAZxGYEOu77qTVgcWYBcYlbT+YzQRwtILFkz3lm CFtU4uXjf6wQtpJE45InrBDXaUqs36UP0aooMaX7ITvEXkGJkzOfsExgFJuFZOoshI5ZSDpm IelYwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwdg5u+a27g3H1a8dDjAIcjEo8vIbO k0KEWBPLiitzDzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjvICfG2fV GDbunCB/8y3jvE6tmx8PbDPfxZ0gl1m+Q3S+A5/hizk6127IMh5Zbfz8a/y7dfWJwv07GmYf PG8WGWz+Z6OseoJO+arr3pH5fgtb9vSXTGjcemGjQUTwAe3lMw/N+HDXpNl5t9kstb1ORYam EvunOocafn32/6ht0fY13aFqz7SOKbEUZyQaajEXFScCAGVm3ux+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ysmHnjj50IzFDMqTx11z0sKm7-k Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 13:52:48 -0000 SGkgTWFydGluLA0KDQo+PiDigJxVbmxlc3MgdGhlIGFuc3dlcmVyIHJlamVjdHMgdGhlIHdob2xl IG9mZmVyLCB0aGUgYW5zd2VyZXIgIE1VU1QgYXBwbHkgDQo+PiB0aGUgYW5zd2VyZXIgcHJvY2Vk dXJlcyBmb3IgbW92aW5nIGFuICJtPSIgbGluZSBvdXQgb2YgYSBCVU5ETEUgZ3JvdXAgdG8gZWFj aCAgDQo+PiBidW5kbGVkICJtPSIgbGluZSBpbiB0aGUgb2ZmZXIgd2hlbiBjcmVhdGluZyB0aGUg YW5zd2VyLuKAnQ0KPg0KPiBUaGlzIHN0YXRlbWVudCwgb3V0IG9mIGNvbnRleHQsIHJlYWRzIGFz ICJkb24ndCBuZWdvdGlhdGUgYnVuZGxlIi4NCj4gVGhvdWdoIEkgZ3Vlc3MgdGhhdCBpdCBpcyBo YXJkIHRvIGdldCBhbGwgdGhlIGNvbmRpdGlvbnMgcmlnaHQuICBBZnRlciBhbGwsIGJ1bmRsZS1v bmx5IHNlY3Rpb25zIGRvbid0IGdldCBtb3ZlZCBvdXQgZWl0aGVyLg0KDQpJIGd1ZXNzIEkgc2hv dWxkIGhhdmUgY29waWVkIG1vcmUgdGV4dCBpbnRvIHRoZSBvcmlnaW5hbCBlLW1haWwuDQoNClRo aXMgaXMgcmVsYXRlZCB0byB0aGUgY2FzZSB3aGVyZSB0aGUgb2ZmZXJlciBoYXMgb2ZmZXJlZCBC VU5ETEUsIGJ1dCBub25lIG9mIHRoZSBidW5kbGVkIG0tIGxpbmUgYWRkcmVzc2VzIGZ1bGZpbCB0 aGUgY3JpdGVyaWEgZm9yIGJlaW5nIHNlbGVjdGVkIGFzIHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRy ZXNzIGJ5IHRoZSBhbnN3ZXJlci4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Thu Dec 18 07:53:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEDD1A1A68 for ; Thu, 18 Dec 2014 07:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BinGaLUVuqEE for ; Thu, 18 Dec 2014 07:52:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AF61A90DB for ; Thu, 18 Dec 2014 07:52:46 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id D40321B278507; Thu, 18 Dec 2014 15:52:40 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sBIFqbY9027153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 10:52:42 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 10:52:37 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? Thread-Index: AdAZ+3RRvr7r/rTWQnCuYlntTHiCwQAMhfAwACsdwoA= Date: Thu, 18 Dec 2014 15:52:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5FE30F@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E66C70EUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/qFLNRaQY-sSJVQku5JIQAVvRAdE Subject: Re: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 15:52:53 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E66C70EUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have no objections. Please see a minor comment inline. From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Wednesday, December 17, 2014 1:14 PM Hi, We currently have the following text in BUNDLE, when the answerer selects t= he offerer BUNDLE address: "If one or more of the criteria are not fulfilled, the answ= erer MUST select the next identification-tag in the identification-tag list, and perf= orm the same criteria check for the "m=3D" line associated with that identificati= on-tag. If there are no more identification-tags in the identification-tag list, th= e answerer MUST NOT create the BUNDLE group." Now, as the text says, if there is no bundled "m=3D" line address in the of= fer which fulfills the criteria for being selected as the offerer BUNDLE address, the answer M= UST NOT create the offerer BUNDLE group. So far so good. However, I think it would be good to have some text on what the answerer DO= ES with the "m=3D" lines (in case the answerer doesn't reject the whole offer, that= is). So, I suggested to append the following text to the paragraph: "Unless the answerer rejects the whole offer, the answerer MUST apply the = answerer procedures for moving an "m=3D" line out of a BUNDLE group to each bundled= "m=3D" line in the offer when creating the answer." I believe ".. moving an "m=3D" line out of a BUNDLE group..." also includes= rejecting the m=3D line by setting port to 0. Do we need some text to clar= ify this? BR Raju --_000_E1FE4C082A89A246A11D7F32A95A17828E66C70EUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have no objections. =

Please see a minor com= ment inline.

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, December 17, 2014 1:14 PM

Hi,

We currently have the following text in BUNDLE, when= the answerer selects the offerer BUNDLE address:

&nbs= p; “If one or more of the criteri= a are not fulfilled, the answerer MUST select the next

&nbs= p; identification-tag in the identifica= tion-tag list, and perform the same criteria

&nbs= p; check for the "m=3D" line = associated with that identification-tag. If there are no

&nbs= p; more identification-tags in the iden= tification-tag list, the answerer MUST NOT

&nbs= p; create the BUNDLE group.”=

Now, as the text says, if there is no bundled “= ;m=3D” line address in the offer which fulfills

the criteria for being selected as the offerer BUNDL= E address, the answer MUST NOT

create the offerer BUNDLE group. So far so good.

However, I think it would be good to have some text = on what the answerer DOES with

the “m=3D” lines (in case the answerer d= oesn’t reject the whole offer, that is).

So, I suggested to append the following text to the = paragraph:

“Unless the answere= r rejects the whole offer, the answerer MUST apply the answerer

procedures for moving an = "m=3D" line out of a BUNDLE group to each bundled "m= =3D" line

in the offer when creatin= g the answer.”

<Raju>

I believe “= ;.. moving an "m=3D" line out of a BUNDLE group= 230;” also includes rejecting the m=3D line b= y setting port to 0. Do we need some text to clarify this?

</Raju>

Raju<= /b>

--_000_E1FE4C082A89A246A11D7F32A95A17828E66C70EUS70UWXCHMBA02z_-- From nobody Thu Dec 18 09:36:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA2C1A9103 for ; Thu, 18 Dec 2014 09:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMq8dbmKukBJ for ; Thu, 18 Dec 2014 09:36:46 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971391A9100 for ; Thu, 18 Dec 2014 09:36:45 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-b6-549310abd01e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.60.24955.BA013945; Thu, 18 Dec 2014 18:36:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 18:36:43 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" Thread-Topic: BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? Thread-Index: AdAZ+3RRvr7r/rTWQnCuYlntTHiCwQAMhfAwACsdwoAAA7aoMA== Date: Thu, 18 Dec 2014 17:36:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D604F34@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5FE30F@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D604F34ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje5qgckhBkvPaFtMXf6YxaJh4xVW ByaP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJWxtvkcS8FW94qdl/vZGxjX2XUxcnJICJhI zJjylwXCFpO4cG89WxcjF4eQwBFGiW03bzFDOEsYJf5+2cHexcjBwSZgIdH9TxukQUQgR+L3 rfesIDXCAn2MEsePtrFBJPoZJT4elIawnSRaf85iBbFZBFQl1tw/D2bzCvhKHNn3lBViwRNG iUtzmhlBEpwCsRLf9q0CK2IEOun7qTVMIDazgLjErSfzmSBOFZBYsuc8M4QtKvHy8T9WCFtJ onHJE1aQQ5kF8iXmb1WH2CUocXLmE5YJjCKzkEyahVA1C0kVRImOxILdn9ggbG2JZQtfM8PY Zw48ZkIWX8DIvopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMK4ObvmtuoPx8hvHQ4wCHIxK PLwGzpNChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo8V2 dY9E1ZPLLebUnrz7iNt92z0WqVLNjfabHy2P+yw1/YKs3VKVPTIWxeuqvyhVa0W9cqmxyF4f YiQZX35yf9WJBJXdK0KaxabmmZ3g65169fTcRQqKZ4TWzN86pbV81z39rYE5dqvbVm6Sf3zX r8av/ujh+QJTtY5xtwef0Qh79+KWf/+Pb0osxRmJhlrMRcWJAPhDePCMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/otbCDcP89RdXbvEbJYoWfska7OY Subject: Re: [MMUSIC] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 17:36:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D604F34ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We currently have the following text in BUNDLE, when the answerer selects t= he offerer BUNDLE address: "If one or more of the criteria are not fulfilled, the answ= erer MUST select the next identification-tag in the identification-tag list, and perf= orm the same criteria check for the "m=3D" line associated with that identificati= on-tag. If there are no more identification-tags in the identification-tag list, th= e answerer MUST NOT create the BUNDLE group." Now, as the text says, if there is no bundled "m=3D" line address in the of= fer which fulfills the criteria for being selected as the offerer BUNDLE address, the answer M= UST NOT create the offerer BUNDLE group. So far so good. However, I think it would be good to have some text on what the answerer DO= ES with the "m=3D" lines (in case the answerer doesn't reject the whole offer, that= is). So, I suggested to append the following text to the paragraph: "Unless the answerer rejects the whole offer, the answerer MUST apply the = answerer procedures for moving an "m=3D" line out of a BUNDLE group to each bundled= "m=3D" line in the offer when creating the answer." I believe ".. moving an "m=3D" line out of a BUNDLE group..." also includes= rejecting the m=3D line by setting port to 0. Do we need some text to clar= ify this? The section on moving an "m=3D" line out of a BUNDLE group describes the ca= se when the "m=3D" line must be rejected. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D604F34ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We currently have the following= text in BUNDLE, when the answerer selects the offerer BUNDLE address:=

     &= nbsp;          “If one o= r more of the criteria are not fulfilled, the answerer MUST select the next=

     &= nbsp;          identification-= tag in the identification-tag list, and perform the same criteria

     &= nbsp;          check for the &= quot;m=3D" line associated with that identification-tag. If there are = no

     &= nbsp;          more identifica= tion-tags in the identification-tag list, the answerer MUST NOT

     &= nbsp;          create the BUND= LE group.”

Now, as the text says, if there= is no bundled “m=3D” line address in the offer which fulfills

the criteria for being selected= as the offerer BUNDLE address, the answer MUST NOT

create the offerer BUNDLE group= . So far so good.

However, I think it would be go= od to have some text on what the answerer DOES with

the “m=3D” lines (i= n case the answerer doesn’t reject the whole offer, that is).

So, I suggested to append the f= ollowing text to the paragraph:

&#= 8220;Unless the answerer rejects the whole offer, the answerer MUST a= pply the answerer

pr= ocedures for moving an "m=3D" line out of a BUNDLE group to each = bundled "m=3D" line

in= the offer when creating the answer.”

&= lt;Raju>

I= believe “.. moving an "m=3D" line out of = a BUNDLE group…” also includes rejecting the m=3D line by s= etting port to 0. Do we need some text to clarify this?

</Raju>

<= /i>

The sect= ion on moving an “m=3D” line out of a BUNDLE group describes th= e case when the “m=3D” line must be rejected.=

&nb= sp;

Regards,=

&nb= sp;

Christer=

--_000_7594FB04B1934943A5C02806D1A2204B1D604F34ESESSMB209erics_-- From nobody Fri Dec 19 02:40:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE001A8783; Fri, 19 Dec 2014 02:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6aq_jm-iKmW; Fri, 19 Dec 2014 02:40:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E011A6F84; Fri, 19 Dec 2014 02:40:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219104006.11895.68642.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 02:40:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7jGzuysai0OrKOh5re59Isb3kmE Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:40:08 -0000 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 : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-10.txt Pages : 19 Date : 2014-12-19 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-10 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 nobody Fri Dec 19 02:42:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B7D1A87AF for ; Fri, 19 Dec 2014 02:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmqlygo8dki9 for ; Fri, 19 Dec 2014 02:42:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2641A8778 for ; Fri, 19 Dec 2014 02:42:42 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-17-54940120357b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.18.29772.02104945; Fri, 19 Dec 2014 11:42:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 11:42:36 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: SCTP-SDP-10 Thread-Index: AdAbeDBGXMaZOlLtTnuxmB64Tzqu/Q== Date: Fri, 19 Dec 2014 10:42:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60BCD8@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_7594FB04B1934943A5C02806D1A2204B1D60BCD8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja4C45QQg8VXBS3+7U2ymLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlTHxwU/Wgq0SFecn/WJtYDwt2sXIySEhYCLx 8FczC4QtJnHh3no2EFtI4AijxOXGtC5GLiB7CaPEjRlrGbsYOTjYBCwkuv9pg9SICKhLfN3b wwxiMws4Spy9tZ0JxBYGit8/uoIZokZHYvua20wQtp7E//cv2UFsFgFViRkfn4Pt4hXwlVjT eB4szgh0w/dTa5ggZopL3HoynwniNgGJJXvOM0PYohIvH/9jhbAVJa5OXw5Vny9xrPMgE8RM QYmTM5+wTGAUnoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIGxc3DLb4MdjC+fOx5iFOBgVOLh3TBlcogQa2JZcWXuIUZp DhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDc+m3RIpMTT1l76phu5krUPu42 31R3O0v3VcHkfPFVkvVPtl2oXtrHGn9U/1/N63QthZg7X9zis1kS/wqwRploSpl4xD2WX3aq 9+OxmS+YuafN+T/p0s/JRpVevXnLmPlsTSy2rp61r3i1RIZpbZ3m8iZ9SdEVy4Oc3k715DvG t4Xh3evpNXZKLMUZiYZazEXFiQBWxNtOfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LHw374IFba2JevWdPX9VDecM2S0 Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new version: SCTP-SDP-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 10:42:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D60BCD8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-10) of draft-ietf-mmusic-sctp-sdp. There are currently no open issues in the draft. Some examples will still have to be added, but other than that the authors = now think that the draft is in such shape that we should start moving towar= ds WGLC. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D60BCD8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I’ve submitted a new version (-10) of draft-ie= tf-mmusic-sctp-sdp.

There are currently no open issues in the draft.

Some examples will still have to be added, but other= than that the authors now think that the draft is in such shape that we sh= ould start moving towards WGLC.

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D60BCD8ESESSMB209erics_-- From nobody Fri Dec 19 05:02:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860431A8AD1; Fri, 19 Dec 2014 05:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y45Dxg0q-LfU; Fri, 19 Dec 2014 05:02:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BDB1A9140; Fri, 19 Dec 2014 05:02:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219130228.23142.64399.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 05:02:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1Jdom9Glp0l_8UMR42umvx2qJak Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 13:02:31 -0000 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 : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-14.txt Pages : 48 Date : 2014-12-19 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, associated with multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to allow an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new RTCP source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific media description. 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-14 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 nobody Fri Dec 19 05:05:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD5C1A914A for ; Fri, 19 Dec 2014 05:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAR9ZxDfWtlb for ; Fri, 19 Dec 2014 05:04:55 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BFD1AC3F5 for ; Fri, 19 Dec 2014 05:04:55 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-71-549422755b09 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 89.55.29772.57224945; Fri, 19 Dec 2014 14:04:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:04:52 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-14 Thread-Index: AdAbjFtetfDP6QSgQxCeekDl6XYOjQ== Date: Fri, 19 Dec 2014 13:04:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60C2ED@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_7594FB04B1934943A5C02806D1A2204B1D60C2EDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW6p0pQQgxcTFCz+7U2ymLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlXHuzlaWggNSFcsmdzE2MK4S72Lk4JAQMJG4 9a6qi5ETyBSTuHBvPVsXIxeHkMARRonPZ1ZAOUsYJVqnrmUCaWATsJDo/qcN0iAioC7xdW8P M4jNLOAocfbWdiYQW1hAVWLHr2UsEDVaEv2b5oO1igjoSaw/mgcSZgEqOd/yDayVV8BXYv+S PnYQmxHohu+n1jBBjBSXuPVkPhPEbQISS/acZ4awRSVePv7HCmErSlydvhxsPLNAvsSV31YQ IwUlTs58wjKBUXgWkkmzEKpmIamCKNGRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcW J+WmGxnppRZlJhcX5+fp5aWWbGIERs3BLb8NdjC+fO54iFGAg1GJh3fDlMkhQqyJZcWVuYcY pTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMVvDb4LarjcL2p0ss8Ok3Pel tBYGHJLlLGc4Iypvq1bWs5fnql3ghXcCRgWnhWvVF8iLG31+u8ZsW9W/KZtmGUifYzV+lq8b x9xYXxoy9XbQvlUhX0M0dB8d0U3QL7c9ZiN+Zg3n8pIekbi4jGsXpxbenyZs1fbP65bGnYbG 105uPd851biUWIozEg21mIuKEwEwKFbsewIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0b-W0jWRKEj5oea4SLTjl3co8Tg Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new version: BUNDLE-14 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 13:04:59 -0000 X-List-Received-Date: Fri, 19 Dec 2014 13:04:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D60C2EDESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-14) of BUNDLE. The main technical change is for suggesting a new offerer BUNDLE address, w= here it is now stated that the new suggested address can be assigned to eac= h bundled "m=3D" line. In addition, I added procedure text regarding the case where no bundled "m= =3D" line fulfills the criteria for being selected as the offerer BUNDLE ad= dress by the answerer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D60C2EDESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I’ve submitted a new version (-14) of BUNDLE.<= o:p>

The main technical change is for suggesting a new of= ferer BUNDLE address, where it is now stated that the new suggested address= can be assigned to each bundled “m=3D” line.

In addition, I added procedure text regarding the ca= se where no bundled “m=3D” line fulfills the criteria for being= selected as the offerer BUNDLE address by the answerer.

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D60C2EDESESSMB209erics_-- From nobody Fri Dec 19 08:45:33 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF7D1A89E1 for ; Fri, 19 Dec 2014 08:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9wRS1mTbGAX for ; Fri, 19 Dec 2014 08:45:28 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A14F1A89BB for ; Fri, 19 Dec 2014 08:45:27 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with comcast id VUlF1p0042Bo0NV01UlT0b; Fri, 19 Dec 2014 16:45:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id VUlS1p00R3Ge9ey01UlTzM; Fri, 19 Dec 2014 16:45:27 +0000 Message-ID: <54945626.8030501@alum.mit.edu> Date: Fri, 19 Dec 2014 11:45:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D60C2ED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D60C2ED@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419007527; bh=T+URoDvyMC95PrbhfPqEq+24S9YG59HRGjuPPed8x4o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RbMkjsOu+KmGh1daWsDSnjOmueBLXDCTMa57Cui4ET6NJpSQa/WWBhMzBbgS8Lpuw jpyJjeeqksbAtpHTjLdOgwR5JXtWFEio5lkzC2IIKKgqS++Z7DdFBm/FEM1MPryqLK 9YyPEPmPAT7nUuarcv6/5Kw8pyjYqtUe8vcV0UmvVsvQ8Dj3DzEazuFOoRenurL8bU td6OzfH9OoFz/bPbpfhnDZBfKPyBAv7bCGivjlLzejspgFibQyZPZuooUYh1bn4T7/ 6h3M+nz2TZjPITZp1b/vG01po7dJubvyhURxpPBJ429Z7SUVOazC8ncMwj5N0lR0kz 0C8xRxhSL8nbw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/djo2j1NlCLXb-4HhJX1Zx3NqT4A Subject: Re: [MMUSIC] Draft new version: BUNDLE-14 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 16:45:31 -0000 This change works for me, with the following minor issue: In 8.5.2, the following: In addition, the offerer MUST indicate that the offerer suggests address as the new offerer BUNDLE address [Section 8.2.2] doesn't read quite right. IIUC, the following would be clearer: In addition, the offerer MUST indicate that the offerer suggested address is the new offerer BUNDLE address [Section 8.2.2] Thanks, Paul On 12/19/14 8:04 AM, Christer Holmberg wrote: > Hi, > > I’ve submitted a new version (-14) of BUNDLE. > > The main technical change is for suggesting a new offerer BUNDLE > address, where it is now stated that the new suggested address can be > assigned to each bundled “m=” line. > > In addition, I added procedure text regarding the case where no bundled > “m=” line fulfills the criteria for being selected as the offerer BUNDLE > address by the answerer. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Dec 19 09:06:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973ED1A8A4A for ; Fri, 19 Dec 2014 09:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fveHlga5VQik for ; Fri, 19 Dec 2014 09:05:58 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FDC1A8A60 for ; Fri, 19 Dec 2014 09:05:50 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with comcast id VV5l1p00D2N9P4d01V5pYb; Fri, 19 Dec 2014 17:05:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id VV5o1p00i3Ge9ey01V5pAk; Fri, 19 Dec 2014 17:05:49 +0000 Message-ID: <54945AEC.3070706@alum.mit.edu> Date: Fri, 19 Dec 2014 12:05:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D60BCD8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D60BCD8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419008749; bh=BShpKqB12ho4DIBvmcF6231r25JiGIRbVDzUn6YtK4A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c3UAeM5tCu4xLpIcf1LGU4nvswApR8tnAFPU5WcyzAzAs4a8WMCoRt6OighlfeJ/Q LrlzAux16XulUY657l/zdQwKTY7QtQvyo63paSBhJZuKtwX1x1BhdS0cITEBVfTkRU dQgXjlg1RFe2RaQfEmasJKyq+34gj6sRxaACcZXZgQyabtcjd6IDmkwdhlXiNETZIt aW7tK/ycfs0fplQefySxJzb5KCwFONSryICDE4oh5ziQ6cDHlnpY8ot2CQFZ1cA5KD GGf+J5LSYYIXH4rsyqSK2E+CvrNlaaCQR9c0xmI2eU3DMNtlJFSzr/sxmwbrdQR0e+ oYJMBZBq36ixg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EJWMXs1ZEZhceqoDF8tYs0JvStc Subject: Re: [MMUSIC] Draft new version: SCTP-SDP-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 17:05:59 -0000 On 12/19/14 5:42 AM, Christer Holmberg wrote: > Hi, > > I’ve submitted a new version (-10) of draft-ietf-mmusic-sctp-sdp. > > There are currently no open issues in the draft. > > Some examples will still have to be added, but other than that the > authors now think that the draft is in such shape that we should start > moving towards WGLC. One major issue with this new version: Now that the new a=max-message-size attribute has been defined in section 6, section 7 now is quite broken. It is no longer used for defining max message size. So pretty much all of what is in section 7 can now be removed. The one exception is the default value of 64K, which should be moved into section 6. It may make sense to retain a section 7, but change it to simply note that a=fmtp provides a mechanism for specifying attributes that are specific to a particular association-usage, and that the detailed syntax of that must be defined as part of the definition of an association-usage. Thanks, Paul From nobody Fri Dec 19 12:17:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764121AC39C for ; Fri, 19 Dec 2014 12:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlIOZMj0vhlQ for ; Fri, 19 Dec 2014 12:17:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3681AC398 for ; Fri, 19 Dec 2014 12:17:17 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-80-549487cb2316 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0B.8B.04076.BC784945; Fri, 19 Dec 2014 21:17:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 21:17:15 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-14 - Paul's comment Thread-Index: AdAbyNbXRhP6ZF1vSBmSIpVOYTUS5Q== Date: Fri, 19 Dec 2014 20:17:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60E367@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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje6Z9ikhBos72CymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj++xTzAXtrBVPn89mbGD8ztzFyMkhIWAi MfnSTSYIW0ziwr31bF2MXBxCAkcYJVrPrIVyljBKHL1+g7GLkYODTcBCovufNkiDiICvxLPH t9lAbGEBZ4nmpm52iLiLxI+Lh8HKRQT0JObtLgMJswioSqz+s5QNJMwL1LrhNFgnI9Da76fW gJ3ALCAucevJfKhzBCSW7DkPdaaoxMvH/1ghbCWJRbc/Q9XrSCzY/YkNwtaWWLbwNVg9r4Cg xMmZT1gmMArPQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMOQP bvlttYPx4HPHQ4wCHIxKPLwbpkwOEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjEsNRBptp9tsfzO/KOP/U717k6faBDFsV46Z1dt2YT7PWha9un/8j48I V+wzWmxgf/fT2cyVOyWqZU9Uez1i0cn4abKW/ZW31u6oJ/dvvhY60Rp4NHvpn8nxPccO/XmX cK0natt0hfOzf7Gmnb46d8fZb4HNKUsEbxptlJm+6OLHOeHxYW6vJ11UYinOSDTUYi4qTgQA xqponFoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TKN973319IIH7yvkOztYQ2zK6Vs Subject: Re: [MMUSIC] Draft new version: BUNDLE-14 - Paul's comment X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 20:17:19 -0000 Hi, >This change works for me, with the following minor issue: > >In 8.5.2, the following: > > In addition, the offerer MUST indicate that the offerer suggests > address as the new offerer BUNDLE address [Section 8.2.2] > >doesn't read quite right. IIUC, the following would be clearer: > > In addition, the offerer MUST indicate that the offerer suggested > address is the new offerer BUNDLE address [Section 8.2.2] I think we could make it even simpler, by saying: "In addition, the offerer MUST indicate that the address is the new suggested offerer BUNDLE address [Section 8.2.2]." Regards, Christer From nobody Fri Dec 19 15:09:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925551A87B8 for ; Fri, 19 Dec 2014 15:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A_5MQgfzk8o for ; Fri, 19 Dec 2014 15:09:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734DC1A90A5 for ; Fri, 19 Dec 2014 15:09:08 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-b8-5494b012846f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.16.04076.210B4945; Sat, 20 Dec 2014 00:09:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 00:09:06 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: SCTP-SDP-10 - Paul's comments Thread-Index: AdAb4NioQW3X3ddwTNSbA/eAVd6gIg== Date: Fri, 19 Dec 2014 23:09:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60E9B2@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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7QhikhBmsWaltMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG/2czWAtucFQcOnCJvYHxGVsXIyeHhICJ xPRf95ggbDGJC/fWA8W5OIQEjjBKrDp5iRXCWcIo8fjURcYuRg4ONgELie5/2iANIgK+Es8e 3wYbJCzgJtHauoYdIu4ucaqvmRHC1pM4seo2C4jNIqAq0XF0OVg9L1Dv0mOzmEFsRqDF30+t ATuCWUBc4taT+VAHCUgs2XOeGcIWlXj5+B8rhK0ksfbwdhaIeh2JBbs/sUHY2hLLFr5mhpgv KHFy5hOWCYzCs5CMnYWkZRaSlllIWhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAz7 g1t+W+1gPPjc8RCjAAejEg/vhimTQ4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA2PGz4yttQql4QfOH5y0fkm2Y9SL/QkCcz0fXtr0ZNfUwJ/XnRZ+Nevq iEgVYnO+zrD/cHbmk+RyHotpPmySfzuyN7mYPbl17VJBXM+3lnVd+dNNhCYsNE/faKJc2T/1 f8ZK6a4uocTW2s0e3s8vX/jwbNPNpGSLlqd7D16PykpNY1tS8TM0OkSJpTgj0VCLuag4EQDq CnkNXAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XK7taN2fD97fLOXLjFnICZzUYn4 Subject: Re: [MMUSIC] Draft new version: SCTP-SDP-10 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 23:09:14 -0000 Hi, >> I've submitted a new version (-10) of draft-ietf-mmusic-sctp-sdp. >> >> There are currently no open issues in the draft. >> >> Some examples will still have to be added, but other than that the=20 >> authors now think that the draft is in such shape that we should start=20 >> moving towards WGLC. > > One major issue with this new version: > > Now that the new a=3Dmax-message-size attribute has been defined in secti= on 6, section 7 now is=20 > quite broken. It is no longer used for defining max message size.=20 Correct. I was supposed to remove that... > So pretty much all of what is in section 7 can now be removed. The one ex= ception is the default value of 64K, which should be=20 > moved into section 6. Yes. > It may make sense to retain a section 7, but change it to simply note tha= t a=3Dfmtp provides a=20 > mechanism for specifying attributes that are specific to a particular ass= ociation-usage, and=20 > that the detailed syntax of that must be defined as part of the definitio= n of an association-usage. Yes. Thanks! Regards, Christer From nobody Fri Dec 19 15:52:00 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5481A9168; Fri, 19 Dec 2014 15:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2nenBW0U6No; Fri, 19 Dec 2014 15:51:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A3C1A90F0; Fri, 19 Dec 2014 15:51:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219235136.30889.92547.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 15:51:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mDrcCCMP0LmzMMlBKeIOgB0P4yY Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 23:51:39 -0000 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 : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-11.txt Pages : 20 Date : 2014-12-19 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-11 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 nobody Fri Dec 19 15:53:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2D1A90AA for ; Fri, 19 Dec 2014 15:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07zV8wxso8j4 for ; Fri, 19 Dec 2014 15:53:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2401A8A3B for ; Fri, 19 Dec 2014 15:53:02 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-d8-5494ba5c992f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.2A.04231.C5AB4945; Sat, 20 Dec 2014 00:53:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 00:52:59 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: SCTP-SDP-11 Thread-Index: AdAb5toJ4o9v+/MaTd2XA4Ig5QQ1rQ== Date: Fri, 19 Dec 2014 23:52:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60EBA2@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D60EBA2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW7MrikhBv83yVj825tkMXX5YxYH Jo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2PRlUnMBZ/FKqau2s/YwLhYpIuRk0NCwERi 1aIDbBC2mMSFe+uBbC4OIYEjjBKt5x+yQzhLGCU2HPnB2MXIwcEmYCHR/U8bpEFEQF3i694e ZhCbWcBR4uyt7UwgJcJA8fcrAyFKdCR+tzeyQth6Eo+nzWIBsVkEVCWaLk0Fa+UV8JW4sayd CcRmBLrh+6k1TBAjxSVuPZnPBHGbgMSSPeeZIWxRiZeP/7FC2EoSaw9vZ4Goz5d48PcbI8RM QYmTM5+wTGAUnoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKLFqcXF uelGxnqpRZnJxcX5eXp5qSWbGIGxc3DLb90djKtfOx5iFOBgVOLh3TBlcogQa2JZcWXuIUZp DhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMEdC1n18baNxxMvdR2dtvb555 7vzyyuD07TBWzq+PDxR91ONfJTaFYf+qG8svcNevuvSmyJ5TVSWTv7pum4nmLT+GM4cn9nlr +JlLXq89cFGueuLeSVI9jR9bVH4dW3doU9MrLzu3u2tMDfcpM3Ev1mv/efDgVHaGiAy9fUw3 Dt26t+H8gtS7SizFGYmGWsxFxYkAyPV0834CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1SHdGgxHyU7yE0Nlvv90o7luLgQ Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new version: SCTP-SDP-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 23:53:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D60EBA2ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on Paul's comment on version-10, I fixed that and submitted version-1= 1. I also noted that the max-message-size was missing from the IANA considerat= ions, so I added it there. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D60EBA2ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Based on Paul’s comment on version-10, I fixed= that and submitted version-11.

I also noted that the max-message-size was missing f= rom the IANA considerations, so I added it there.

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D60EBA2ESESSMB209erics_-- From nobody Sat Dec 20 13:18:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534301AC3A8 for ; Sat, 20 Dec 2014 13:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnJUtG2HS5u3 for ; Sat, 20 Dec 2014 13:18:22 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4820B1A9075 for ; Sat, 20 Dec 2014 13:13:18 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-04v.sys.comcast.net with comcast id VxCM1p00D2LrikM01xDHqh; Sat, 20 Dec 2014 21:13:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id VxDG1p00N3Ge9ey01xDGro; Sat, 20 Dec 2014 21:13:17 +0000 Message-ID: <5495E66C.1090903@alum.mit.edu> Date: Sat, 20 Dec 2014 16:13:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D60EBA2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D60EBA2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419109997; bh=me1JzeLl6mWVslfa3fCEfxUkMj94Mi4JWo7+fAWB9bI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rgaTsASw0n24EcF8HsgTMIZtYOmjOCXeLOg5d10IYjhxzo1BTYnCZHhttfZgEsakl F4sPotkqZZQHeqKFOdP/Xb1ubmL+zRJUY0VyVren8No5Ql0sQoxsQ1JMW9AXKayi1u 11Eqi90sfeVK9GSNMgzkER7a9A9swa+lxQJFxs8S3SglPLoAfe6OkyhOwfDiPcCoxD LeISkg0rOT3QbFOSV3K0yI0IEZsVidLfTYX0dz7tuMFdJA94ufrsNuClQcPwN1/o7G splWitfOD67W+kLUyhnAjc9uYY1QdT50MQhYe22HuQNqVwrHK/koFop/AvrZfAzFIb Ynw3EIuXnwYkA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SqzqrJATirE6sGV87r95FtAI9ts Subject: Re: [MMUSIC] Draft new version: SCTP-SDP-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Dec 2014 21:18:25 -0000 WFM On 12/19/14 6:52 PM, Christer Holmberg wrote: > Hi, > > Based on Paul’s comment on version-10, I fixed that and submitted > version-11. > > I also noted that the max-message-size was missing from the IANA > considerations, so I added it there. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Dec 30 05:46:00 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEF51ACE9D; Sat, 27 Dec 2014 21:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkxlbTcMqTLt; Sat, 27 Dec 2014 21:24:19 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6F11A90BA; Sat, 27 Dec 2014 21:24:18 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id y13so15178216pdi.17; Sat, 27 Dec 2014 21:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KvlbBvufcLLvvSX4iTl47dUcOgP18DCuPoXfLLHidPU=; b=JS7XF1UZH+dFZZlT4IVkF6Md8HJ97ltJ414Oza0o+upiNGoV5F9bwHiew1tYHkJd/d ioNC1Kvt+KI5wrT+O8W0IlLES7CX0vcu4S8RpxXVeuPqz0MD4j2egMK0e4/vsKioXbEf wF7HnktHhfIEIhYdy+BIdeCSg1y3P8ZvO8hhLsiWnzwYh/jB6Usn0yG8ki6N2S9omf3l GWsGiihDNhE4BhcB9GBdR3AZxJJCdNQl08u0etwvcj5r1QILFjtW86ssmUyn4PKw0+x3 fhoYDgloFmcfTNT1JQZLvB+acoQ50fljNzbvvdU65XGzGCeiiqowQufIqfRM3ZZHrakg nodg== MIME-Version: 1.0 X-Received: by 10.70.22.227 with SMTP id h3mr80954255pdf.160.1419744258051; Sat, 27 Dec 2014 21:24:18 -0800 (PST) Received: by 10.70.117.99 with HTTP; Sat, 27 Dec 2014 21:24:18 -0800 (PST) Received: by 10.70.117.99 with HTTP; Sat, 27 Dec 2014 21:24:18 -0800 (PST) Date: Sun, 28 Dec 2014 00:24:18 -0500 Message-ID: From: Julius Friedman To: avt@ietf.org, mmusic@ietf.org Content-Type: multipart/alternative; boundary=047d7b6da18a2c5322050b3ff8e7 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IfTlzHee2floXlXCKJEbPBGYotk X-Mailman-Approved-At: Tue, 30 Dec 2014 05:45:55 -0800 Subject: [MMUSIC] Question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 28 Dec 2014 05:24:20 -0000 --047d7b6da18a2c5322050b3ff8e7 Content-Type: text/plain; charset=UTF-8 I hope everyone had a great holiday! I also hope the New Year is also as splendid for all of the members of the IETF as it has ever been. I am sorry to 'bother' again however while waiting for my responses on my previous summary email 'On the following Errata' I ran across something I had a question on which may need to be addressed further. Rfc 2326 explicitly states that seeking can be disabled by not including the end information in the range header. What if I want to have the end but I don't want to allow seeking? E.g. my clip is 10 minutes and I have already been playing for 3 and there are 7 remaining; why can't I convey that and not allow seeking? Obviously I can just return a BadRequest when a seek is performed or just an OKAY to pretend like it's honored; but how can I convey in a standards compliant manner that the stream is not seekable BEFORE the client attempts the seek operation when also indicating the current and end times of the media in question? Thanks in advance and best wishes again! Sincerely, Julius Friedman --047d7b6da18a2c5322050b3ff8e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hope everyone had a great holiday!

I also hope the New Year is also as splendid for all of the = members of the IETF as it has ever been.

I am sorry to 'bother' again however while waiting f= or my responses on my previous summary email 'On the following Errata&#= 39; I ran across something I had a question on which may need to be address= ed further.

Rfc 2326 explicitly states that seeking can be disabled by n= ot including the end information in the range header.

What if I want to have the end but I don't want to allow= seeking?

E.g. my clip is 10 minutes and I have already been playing f= or 3 and there are 7 remaining; why can't I convey that and not allow s= eeking?

Obviously I can just return a BadRequest when a seek is perf= ormed or just an OKAY to pretend like it's honored; but how can I conve= y in a standards compliant manner that the stream is not seekable BEFORE th= e client attempts the seek operation when also indicating the current and e= nd times of the media in question?

Thanks in advance and best wishes again!

Sincerely,
Julius Friedman
--047d7b6da18a2c5322050b3ff8e7-- From nobody Tue Dec 30 05:46:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0041AC3D5; Sun, 28 Dec 2014 16:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aqdxsON2p9q; Sun, 28 Dec 2014 16:43:43 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D58A1AC3C5; Sun, 28 Dec 2014 16:43:43 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id eu11so16377710pac.11; Sun, 28 Dec 2014 16:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yJ3Ux3xWmBHCMqxTpFNsG2GNC8fUeinpo1yeQOg16Ag=; b=Vc3lHPP/lFDTK9fLW8TQHgOvzPuvSuOS4xtv35nE1wsduu5ef0plbyRzJAT73SINio WZQ9DJ78CwlcFHu3Kh7rqTxwuXAavImVG+6fJ/U2ruWNnW2YIuo/EVudqHMpDk/qmYj6 EP5ncjWfd8dzH43xBYQfBo1fPE0+O16oG2Nj/SyhW1kJrOCWNtINOoHzwzlDnQXfHPLZ Q05/5BdYpSdIBNee3WC1NIPpowgJAdWGjbI5lGarO2/J8MKkG+bJNwN148TiKyY+biEu wPoFMUNKfbucu2a/7Ah3FXKylnsklLiNceoCIyT2S23DcFSXcLaKRifAeZ0tXFclKeV8 5vtQ== MIME-Version: 1.0 X-Received: by 10.70.140.130 with SMTP id rg2mr86563969pdb.49.1419813822521; Sun, 28 Dec 2014 16:43:42 -0800 (PST) Received: by 10.70.117.99 with HTTP; Sun, 28 Dec 2014 16:43:42 -0800 (PST) In-Reply-To: <874msfcna5.fsf@hobgoblin.ariadne.com> References: <874msfcna5.fsf@hobgoblin.ariadne.com> Date: Sun, 28 Dec 2014 19:43:42 -0500 Message-ID: From: Julius Friedman To: "Dale R. Worley" , avt@ietf.org, mmusic@ietf.org Content-Type: multipart/alternative; boundary=001a1134c7c889e8cd050b502aeb Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/F3ciPFdFCFzZIFRaeg_2lh_8QQE X-Mailman-Approved-At: Tue, 30 Dec 2014 05:45:55 -0800 Subject: Re: [MMUSIC] [AVTCORE] Question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Dec 2014 00:43:46 -0000 --001a1134c7c889e8cd050b502aeb Content-Type: text/plain; charset=UTF-8 Hello Dale, (et al) I would like to address your response: "In any case, why would we want to prevent seeking on a stored media object? I can see why if the media is an un-stored media stream, but in that case, the software likely doesn't know the total length that the media will have." I will justify how "likely" this is as follows: 1) A Live 10 minute `media` which has been playing for 3 minutes, leaving me 7 minutes in play but unable to seek. a) If the stream was stored or recorded this obviously wouldn't be an issue 2) I have a server which requires authorization to seek but not to play. 3) I am a client and I have started playing and 'PAUSE' is not supported 4) I am a server re-streaming from a server where "Range" is not supported "Perhaps referring to the mailing list discussion for this RFC would reveal the answer." Which mailing list is that? 'mmusic' they have also been addressed, several times. I never get a response from them. In any other case I hope all is well and that I haven't been marked as spam or WORSE that there is something wrong with the list and my messages are just not being received. Anyway , thank you for your prompt response! Sincerely, Julius On Sun, Dec 28, 2014 at 7:28 PM, Dale R. Worley wrote: > Julius Friedman writes: > > Rfc 2326 explicitly states that seeking can be disabled by not including > > the end information in the range header. > > > > What if I want to have the end but I don't want to allow seeking? > > > > E.g. my clip is 10 minutes and I have already been playing for 3 and > there > > are 7 remaining; why can't I convey that and not allow seeking? > > I'm no expert in RTSP, but reading the RFC, it appears that the server > indicates if seeking is allowed by the inclusion of the end-time: > > D.2.1 Basic Playback > > Client implementations may use the presence of length information > to determine if the clip is seekable, and visibly disable seeking > features for clips for which the length information is unavailable. > > Exactly why the server cannot indicate the total media length without > implicitly stating the media is seekable, I don't know. Perhaps it's > because any such media is theoretically seekable, since it must already > be instantiated as a stored data object. Or perhaps it is because if > seeking is not implemented, the user interface is expected to not > display the "slider bar", and so there is no way to tell the user how > much time remains in the media: > > Client implementations may use the presence of length information > to determine if the clip is seekable, and visibly disable seeking > features for clips for which the length information is unavailable. > A common use of the presentation length is to implement a "slider > bar" which serves as both a progress indicator and a timeline > positioning tool. > > Perhaps referring to the mailing list discussion for this RFC would > reveal the answer. > > In any case, why would we want to prevent seeking on a stored media > object? I can see why if the media is an un-stored media stream, but in > that case, the software likely doesn't know the total length that the > media will have. > > Dale > --001a1134c7c889e8cd050b502aeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Dale, (et al)

I would = like to address your response:

"In any case, why would we want to prevent seekin= g on a stored media
object?=C2=A0 I can see why if the m= edia is an un-stored media stream, but in
that case, the= software likely doesn't know the total length that the
media will have."

= I will justify how "likely" this is as follows:
<= div>
1) A Live 10 minute `media` which = has been playing for 3 minutes, leaving me 7 minutes in play but unable to = seek.
=C2=A0 = =C2=A0a) If the stream was stored or=C2=A0recorded=C2=A0this=C2=A0obviously= =C2=A0wouldn't be an issue

2) I have a server which requires authorization to seek but not t= o play.

3)=C2=A0I am = a client and I have started playing and 'PAUSE' is not supported

4)=C2=A0I am a server re-streaming from a serv= er where "Range" is not supported

"Perhaps referring to the mailing list discussi= on for this RFC would
reveal the answer."

<= div>Which mailing list is that= ? 'mmusic' they have also been addressed, several times. I never ge= t a response from them.

In any other case I hope all is well and that I haven't been marked = as spam or WORSE that there is something wrong with the list and my message= s are just not being received.

Anyway , thank you for your prompt response!

Sincerely,
Julius

On Sun, Dec 28, 2014 at 7:28 PM, = Dale R. Worley <worley@ariadne.com> wrote:
Julius Friedman <juliusfriedman@gmail.com> writes:
> Rfc 2326 explicitly states that seeking can be disabled by not includi= ng
> the end information in the range header.
>
> What if I want to have the end but I don't want to allow seeking?<= br> >
> E.g. my clip is 10 minutes and I have already been playing for 3 and t= here
> are 7 remaining; why can't I convey that and not allow seeking?
I'm no expert in RTSP, but reading the RFC, it appears that the = server
indicates if seeking is allowed by the inclusion of the end-time:

=C2=A0 =C2=A0 D.2.1 Basic Playback

=C2=A0 =C2=A0 =C2=A0Client implementations may use the presence of length i= nformation
=C2=A0 =C2=A0 =C2=A0to determine if the clip is seekable, and visibly disab= le seeking
=C2=A0 =C2=A0 =C2=A0features for clips for which the length information is = unavailable.

Exactly why the server cannot indicate the total media length without
implicitly stating the media is seekable, I don't know.=C2=A0 Perhaps i= t's
because any such media is theoretically seekable, since it must already
be instantiated as a stored data object.=C2=A0 Or perhaps it is because if<= br> seeking is not implemented, the user interface is expected to not
display the "slider bar", and so there is no way to tell the user= how
much time remains in the media:

=C2=A0 =C2=A0 =C2=A0Client implementations may use the presence of length i= nformation
=C2=A0 =C2=A0 =C2=A0to determine if the clip is seekable, and visibly disab= le seeking
=C2=A0 =C2=A0 =C2=A0features for clips for which the length information is = unavailable.
=C2=A0 =C2=A0 =C2=A0A common use of the presentation length is to implement= a "slider
=C2=A0 =C2=A0 =C2=A0bar" which serves as both a progress indicator and= a timeline
=C2=A0 =C2=A0 =C2=A0positioning tool.

Perhaps referring to the mailing list discussion for this RFC would
reveal the answer.

In any case, why would we want to prevent seeking on a stored media
object?=C2=A0 I can see why if the media is an un-stored media stream, but = in
that case, the software likely doesn't know the total length that the media will have.

Dale

--001a1134c7c889e8cd050b502aeb-- From nobody Tue Dec 30 05:46:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48141ACD6A; Sun, 28 Dec 2014 20:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZJV2u1WnE13; Sun, 28 Dec 2014 20:48:19 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F68E1ACD67; Sun, 28 Dec 2014 20:48:19 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so16739671pad.10; Sun, 28 Dec 2014 20:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iMQ5n4fa5ZenWcmkWdqVyRNFoh0YQjvrEZPZbhyT5CI=; b=DXQnquLbtxlhzduiqx3IapiU6tJ6MNRUX08tdy2qjkHHV0s4pcvGDvl0yGyvNIFYP0 YiQ/y19BRlvxa2DpfeptgOfd1/aB/l2xh0LxvNTdwlPQSOchz9qknSsOLE9wabuuD21H XoF4zmAIPZDdNj5qAbWfC6+xFTWXrp4aLe3lR0ADvBacFTA4Kd529jIfTvnzJw27iUiW IAc5six9Wa6JHWivrKmOr/m8gmuPQAvlaETw7mJBggZ8czg3wCmRT2nacm1tCBLwx+3J UmZxNIiZxP+f+Zyy9YPds+HRdYL+tOwCyv7tH6ixrAYV7tU6Bnr5D5Uc5gihma8nh/Q1 Q9EA== MIME-Version: 1.0 X-Received: by 10.68.211.193 with SMTP id ne1mr87802279pbc.49.1419828498691; Sun, 28 Dec 2014 20:48:18 -0800 (PST) Received: by 10.70.117.99 with HTTP; Sun, 28 Dec 2014 20:48:18 -0800 (PST) Date: Sun, 28 Dec 2014 23:48:18 -0500 Message-ID: From: Julius Friedman To: avt@ietf.org, mmusic@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb208e84e7d0c050b5395e1 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lkD9WkGqchUIr78vPiAG4RfYCR0 X-Mailman-Approved-At: Tue, 30 Dec 2014 05:45:55 -0800 Subject: [MMUSIC] Possible Erratta in RFC2326 relating to 'source' parameter. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Dec 2014 04:48:21 -0000 --e89a8fb208e84e7d0c050b5395e1 Content-Type: text/plain; charset=UTF-8 RFC2326 Specifies in Section [12.39 Transport] source: If the source address for the stream is different than can be derived from the RTSP endpoint address (the server in playback or the client in recording), the source MAY be specified. Then directly below in the same section Transport = "Transport" ":" 1\#transport-spec transport-spec = transport-protocol/profile[/lower-transport] *parameter transport-protocol = "RTP" profile = "AVP" lower-transport = "TCP" | "UDP" parameter = ( "unicast" | "multicast" ) | ";" "destination" [ "=" address ] | ";" "interleaved" "=" channel [ "-" channel ] | ";" "append" | ";" "ttl" "=" ttl | ";" "layers" "=" 1*DIGIT | ";" "port" "=" port [ "-" port ] | ";" "client_port" "=" port [ "-" port ] | ";" "server_port" "=" port [ "-" port ] | ";" "ssrc" "=" ssrc | ";" "mode" = <"> 1\#mode <"> ttl = 1*3(DIGIT) port = 1*5(DIGIT) ssrc = 8*8(HEX) channel = 1*3(DIGIT) address = host mode = <"> *Method <"> | Method Since 'source' is not listed I don't know the syntax, I assumed it to be an "IPAddress" however the text sates "address" so I imagine if I found a 'source=1.2.3.4:1554' that would be valid however I want to make sure since there isn't any syntax specified in the RFC. Also I would wonder is there any restriction on specifying a port or address range also ? e.g. 'source=1.2.3.4/321202/2' I believe there was a similar issue with Rtp-Info headers which was fixed in 'biz' however this among other issues were not addressed and I am wondering if any other updates will be made to this RFC before 2.0 Draft is finalized. Hopefully this won't have to be added to my list of `issues` but unless I am missing something I will also have to file errata for this. Thanks in advance! --e89a8fb208e84e7d0c050b5395e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC2326 Specifies in Section [12.39 Transport]

source: If the source address for the stream is different than can be derived from the RTSP endpoint address (the server in playback or the client in recording), the source MAY be specified.
Then directly below in the same section

Transport =3D "Transport" ":" 1\#transport-spec transport-spec =3D transport-protocol/profile[/lower-transport] *parameter transport-protocol =3D "RTP" profile =3D "AVP" lower-transport =3D "TCP" | "UDP" parameter =3D ( "unicast" | "multicast"= ) | ";" "destination" [ "= =3D" address ] | ";" "interleaved" "=3D= " channel [ "-" channel ] | ";" "append" | ";" "ttl" "=3D" t= tl | ";" "layers" "=3D"= ; 1*DIGIT | ";" "port" "=3D" = port [ "-" port ] | ";" "client_port" "=3D= " port [ "-" port ] | ";" "server_port" "=3D= " port [ "-" port ] | ";" "ssrc" "=3D" = ssrc | ";" "mode" =3D <"&g= t; 1\#mode <"> ttl =3D 1*3(DIGIT) port =3D 1*5(DIGIT) ssrc =3D 8*8(HEX) channel =3D 1*3(DIGIT) address =3D host mode =3D <"> *Method <"> | Metho= d

Since 'source' is not = listed I don't know the syntax, I assumed it to be an "IPAddress&q= uot; however the text sates "address" so I imagine if I found a &= #39;source=3D1.2.3.4:1554' that wou= ld be valid however I want to make sure since there isn't any syntax sp= ecified in the RFC.=C2=A0
A= lso I would wonder is there any restriction on specifying a port or address= range also ? e.g. 'source=3D1.2.3.= 4/321202/2'
= I belie= ve there was a similar issue with Rtp-Info headers which was fixed in '= biz' however this among other issues were not addressed and I am wonder= ing if any other updates will be made to this RFC before 2.0 Draft is final= ized.
Hopefully this won= 9;t have to be added to my list of `issues` but unless I am missing somethi= ng I will also have to file=C2=A0errata=C2=A0for this.
<= pre style=3D"word-wrap:break-word">Thanks in advance!
--e89a8fb208e84e7d0c050b5395e1-- From nobody Tue Dec 30 05:47:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B451AC3C6 for ; Sun, 28 Dec 2014 16:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhvgQHd3vxOX for ; Sun, 28 Dec 2014 16:30:28 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59E91AC3C5 for ; Sun, 28 Dec 2014 16:30:27 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-02v.sys.comcast.net with comcast id ZCWT1p0012Qkjl901CWTBo; Mon, 29 Dec 2014 00:30:27 +0000 Received: from hobgoblin.ariadne.com ([173.75.213.57]) by resomta-ch2-15v.sys.comcast.net with comcast id ZCTw1p00N1Es2At01CU2b7; Mon, 29 Dec 2014 00:28:22 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sBT0SJ3O026123; Sun, 28 Dec 2014 19:28:19 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBT0SII8026120; Sun, 28 Dec 2014 19:28:18 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Julius Friedman In-Reply-To: (juliusfriedman@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 28 Dec 2014 19:28:18 -0500 Message-ID: <874msfcna5.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419813027; bh=6ayPN+7fABe5J/tnd92g3UQxDYojIiQuLNTuU58cSEo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Vn1VVrFkQL1FS++zM6XsGZ+1UyhNDWV7ShAZ5AnqP3AxxqMHSDUPHWNAhOJbk26ug gJTNb1q8HusA213RzfA1kOOZnPJT+hWt29vBJcnwYVSJI4BWqBmik0HbL8Ev3eXQv3 dASq8kHhdvgdipxPjOCBafATySu6hJtFsvDFOkVhagHA9+yLRB//srv+6z5KCM4wCH 2s4e8o2Sqjl/61cgxHTUdSLf0HUqO4vxMGs5FPM/2ClWzA05fsmyPbP4PzZol4ymRA hP4INuZ6gL13SEiyL1PxW5oEeo6pUDo3dhL8Tzb1HT9EPmINH7saZACCCoSFteGIvL 3CO/KD/bJLvyw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/p1fIVpc-p93YemtIMYEm5gX4EuU X-Mailman-Approved-At: Tue, 30 Dec 2014 05:47:53 -0800 Cc: avt@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [AVTCORE] Question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Dec 2014 00:30:29 -0000 Julius Friedman writes: > Rfc 2326 explicitly states that seeking can be disabled by not including > the end information in the range header. > > What if I want to have the end but I don't want to allow seeking? > > E.g. my clip is 10 minutes and I have already been playing for 3 and there > are 7 remaining; why can't I convey that and not allow seeking? I'm no expert in RTSP, but reading the RFC, it appears that the server indicates if seeking is allowed by the inclusion of the end-time: D.2.1 Basic Playback Client implementations may use the presence of length information to determine if the clip is seekable, and visibly disable seeking features for clips for which the length information is unavailable. Exactly why the server cannot indicate the total media length without implicitly stating the media is seekable, I don't know. Perhaps it's because any such media is theoretically seekable, since it must already be instantiated as a stored data object. Or perhaps it is because if seeking is not implemented, the user interface is expected to not display the "slider bar", and so there is no way to tell the user how much time remains in the media: Client implementations may use the presence of length information to determine if the clip is seekable, and visibly disable seeking features for clips for which the length information is unavailable. A common use of the presentation length is to implement a "slider bar" which serves as both a progress indicator and a timeline positioning tool. Perhaps referring to the mailing list discussion for this RFC would reveal the answer. In any case, why would we want to prevent seeking on a stored media object? I can see why if the media is an un-stored media stream, but in that case, the software likely doesn't know the total length that the media will have. Dale