From ekr@rtfm.com Sat Jun 1 07:47:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6860C21F9DF9 for ; Sat, 1 Jun 2013 07:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.792 X-Spam-Level: X-Spam-Status: No, score=-96.792 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I2KGaKY2lfE for ; Sat, 1 Jun 2013 07:47:05 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41C21F9DFD for ; Sat, 1 Jun 2013 07:46:57 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l11so1362559qcy.37 for ; Sat, 01 Jun 2013 07:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=jE8uU4EezcWeqQFKXeDDo8Ns4vUD3SWsXcCJerR8GLQ=; b=lYVgOYQeZ223Yd466oLuV0TDie+LVe50UsNnfX8R4ZhdG7358nbrgKTbg1WA8Qtkui dd+mgt8pbOlWqrNMkxDPkB28XccnIJdFBN3/eo8kEoNz6eVAbsUct6bRYzUvJYSkWQ+F 6dF6/AXQ2LMu08KrrTWjpCVClw3PGzwmQhrAfETJgU9mc6vxLd6K3z+298ixDeUlPkfA IEW5CrXWDn8ltxo05RFL0SiJjGK1eH9oB+KgdMSKvjDbg0tcJIecQnG2SeZXuf/QD3Pc vY4F2/E82xa7QTYOeOzaKeP8ZwaxbAf51m291bI+BjyC0NudkG+optu5Cenm3S4OHckV RXug== X-Received: by 10.224.174.138 with SMTP id t10mr11932670qaz.99.1370098016477; Sat, 01 Jun 2013 07:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.41.131 with HTTP; Sat, 1 Jun 2013 07:46:16 -0700 (PDT) X-Originating-IP: [64.88.227.134] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sat, 1 Jun 2013 07:46:16 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=20cf30334e03947af704de18cd78 X-Gm-Message-State: ALoCoQm5NEpfQLYPRqAHPCYleCqeoJQ953MpDtQAQO+DrVQyFSm/fwvEGbSW5kVuimBxQo2UOcdk Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2013 14:47:09 -0000 --20cf30334e03947af704de18cd78 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 6.4. Answerer Procedures 6.4.1. General This section describes how an Answerer, when it receives an SDP Offer including a BUNDLE group, generates the associated SDP Answer. When an Answerer receives an SDP Offer which includes a BUNDLE group, and the Answerer accepts the offered BUNDLE group, the Answerer MUST generate an SDP Answer according to the procedures in Section 6.1 and this section. 6.4.2. RFC 5888 restrictions Based on the rules and procedures in RFC 5888, the following restrictions also apply to BUNDLE groups in SDP Answers: o 1) A BUNDLE group must not be added to an SDP Answer, unless the same BUNDLE group was included in the associated SDP Offer; and o 2) An SDP "m=3D" line must not be added to a BUNDLE group in the SDP Answer, unless it in the associated SDP Offer was included in the same BUNDLE group. 6.4.3. Offerer Bundle Address Selection In the SDP Answer, the Answerer selects the bundle address for the Offerer, based on the address information received in the associated SDP Offer, using the mid value. The mid value associated with the "m=3D" line in the SDP Offer that represents the bundle address MUST in the SDP Answer be located first in the mid value list added to SDP group:BUNDLE attribute associated with the BUNDLE group. I am having trouble reading this text. Is this supposed to say that the answerer should choose the transport parameters from one of the m-lines and put the mid associated with those parameters first in the group:BUNDLE attribute he sends? From the associated SDP Offer, the Answerer SHOULD choose the bundle address associated with the mid value located first in the mid value list included in the SDP group:BUNDLE attribute associated with the BUNDLE group, unless: Is there a reason to make this a SHOULD rather than MUST? The conditions below don't really seem to be judgement calls. I may have missed some discussion on this, but why not say MUST use the first mid associated with a non-zero m-line? o 1) The mid value represents an "m=3D" line with a port zero value in the SDP Offer; or o 2) The mid value represents an "m=3D" line with a port zero value in the SDP Answer. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. 6.4.4. Answerer Bundle Address Selection In the SDP Answer, the Answerer selects its local bundle address. Each "m=3D" line included in a BUNDLE group MUST contain identical address information. The only exception is the usage of a zero port value for an "m=3D" line, which is allowed eventhough another port value number is used for other "m=3D" lines in the BUNDLE group. A forward reference to 6.4.5 would be nice here. Or maybe just merge it in. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. In a subsequent SDP Answer, the Answerer MAY change its local bundle address, as long as each "m=3D" line included the BUNDLE group contain identical address information. For a given BUNDLE group, the Answerer MUST NOT assign the bundle address to "m=3D" lines that are not included the BUNDLE group, or to "m=3D" lines that are included in another BUNDLE group. 6.4.5. Rejecting A BUNDLE Media Description When generating the SDP Answer, if the Answerer wants to reject media associated with an "m=3D" line in the BUNDLE group, it will add a zero port number value to the "m=3D" line, according to the procedures defined in RFC 3264. OPEN ISSUE: It is FFS whether it is allowed to include a port zero media descriptions in a BUNDLE group. 6.4.6. Removing a media description from a BUNDLE group When generating the SDP Answer, if the Answerer wants to remove an "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),it MUST NOT include the "m=3D" line in a BUNDLE group. In addition, the SDP Answer MUST not add its local bundle address to the "m=3D" line. An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from a BUNDLE group, unless the "m=3D" line had unique address information in the associated SDP Offer. NOTE: The reason for the restriction above is that, if the "m=3D" line would be removed from the BUNDLE group, the address information would be identical to the "m=3D" lines remaining in the BUNDLE group. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. I thought we had agreed to no bundle splitting. On Thu, May 30, 2013 at 10:37 AM, Cullen Jennings (fluffy) wrote: > > Looks good to me > > On May 29, 2013, at 5:39 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > Based on the e-mail and interim discussions, I=92ve tried together some > =94Answerer Procedures=94 text for BUNDLE. > > > > For now, I would request that people mainly focus on the technical > stuff, and if some text is unclear. I WILL align the usage of =93m=3D=94 = line and > =93media description=94 :) > > > > Also note that examples will be added later. > > > > Regards, > > > > Christer > > > > ----------------------------------------------------- > > > > > > 6.4. Answerer Procedures > > > > 6.4.1. General > > > > This section describes how an Answerer, when it receives an SDP Offe= r > > including a BUNDLE group, generates the associated SDP Answer. > > > > When an Answerer receives an SDP Offer which includes a BUNDLE group= , > > and the Answerer accepts the offered BUNDLE group, the Answerer MUST > > generate an SDP Answer according to the procedures in Section 6.1 an= d > > this section. > > > > 6.4.2. RFC 5888 restrictions > > > > Based on the rules and procedures in RFC 5888, the following > > restrictions also apply to BUNDLE groups in SDP Answers: > > > > o 1) A BUNDLE group must not be added to an SDP Answer, unless the > > same BUNDLE group was included in the associated SDP Offer; and > > > > o 2) An SDP "m=3D" line must not be added to a BUNDLE group in the = SDP > > Answer, unless it in the associated SDP Offer was included in the > > same BUNDLE group. > > > > 6.4.3. Offerer Bundle Address Selection > > > > In the SDP Answer, the Answerer selects the bundle address for the > > Offerer, based on the address information received in the associated > > SDP Offer, using the mid value. The mid value associated with the > > "m=3D" line in the SDP Offer that represents the bundle address MUST= in > > the SDP Answer be located first in the mid value list added to SDP > > group:BUNDLE attribute associated with the BUNDLE group. > > > > From the associated SDP Offer, the Answerer SHOULD choose the bundle > > address associated with the mid value located first in the mid value > > list included in the SDP group:BUNDLE attribute associated with the > > BUNDLE group, unless: > > > > o 1) The mid value represents an "m=3D" line with a port zero value= in > > the SDP Offer; or > > > > o 2) The mid value represents an "m=3D" line with a port zero value= in > > the SDP Answer. > > > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > 6.4.4. Answerer Bundle Address Selection > > > > In the SDP Answer, the Answerer selects its local bundle address. > > Each "m=3D" line included in a BUNDLE group MUST contain identical > > address information. The only exception is the usage of a zero port > > value for an "m=3D" line, which is allowed eventhough another port > > value number is used for other "m=3D" lines in the BUNDLE group. > > > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > In a subsequent SDP Answer, the Answerer MAY change its local bundle > > address, as long as each "m=3D" line included the BUNDLE group conta= in > > identical address information. > > > > For a given BUNDLE group, the Answerer MUST NOT assign the bundle > > address to "m=3D" lines that are not included the BUNDLE group, or t= o > > "m=3D" lines that are included in another BUNDLE group. > > > > 6.4.5. Rejecting A BUNDLE Media Description > > > > When generating the SDP Answer, if the Answerer wants to reject medi= a > > associated with an "m=3D" line in the BUNDLE group, it will add a ze= ro > > port number value to the "m=3D" line, according to the procedures > > defined in RFC 3264. > > > > OPEN ISSUE: It is FFS whether it is allowed to include a port zero > > media descriptions in a BUNDLE group. > > > > 6.4.6. Removing a media description from a BUNDLE group > > > > When generating the SDP Answer, if the Answerer wants to remove an > > "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),= it > > MUST NOT include the "m=3D" line in a BUNDLE group. In addition, th= e > > SDP Answer MUST not add its local bundle address to the "m=3D" line. > > > > An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from = a > > BUNDLE group, unless the "m=3D" line had unique address information = in > > the associated SDP Offer. > > > > NOTE: The reason for the restriction above is that, if the "m=3D" li= ne > > would be removed from the BUNDLE group, the address information woul= d > > be identical to the "m=3D" lines remaining in the BUNDLE group. > > > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --20cf30334e03947af704de18cd78 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
6.4. =A0Answerer Procedures
=A0
6= .4.1. =A0General
=A0
=A0 =A0This section describes how = an Answerer, when it receives an SDP Offer
=A0 =A0including a BUN= DLE group, generates the associated SDP Answer.
=A0
=A0 =A0When an Answerer receives an SDP Offer which incl= udes a BUNDLE group,
=A0 =A0and the Answerer accepts the offered = BUNDLE group, the Answerer MUST
=A0 =A0generate an SDP Answer acc= ording to the procedures in Section 6.1 and
=A0 =A0this section.
=A0
6.4.2. =A0RFC 5888 restri= ctions
=A0
=A0 =A0Based on the rules and procedures in = RFC 5888, the following
=A0 =A0restrictions also apply to BUNDLE = groups in SDP Answers:
=A0
=A0 =A0o =A01) A BUNDLE group must not be added to an SD= P Answer, unless the
=A0 =A0 =A0 same BUNDLE group was included i= n the associated SDP Offer; and
=A0
=A0 =A0o =A02) An S= DP "m=3D" line must not be added to a BUNDLE group in the SDP
=A0 =A0 =A0 Answer, unless it in the associated SDP Offer was included= in the
=A0 =A0 =A0 same BUNDLE group.
=A0
6.= 4.3. =A0Offerer Bundle Address Selection
=A0
=A0 =A0In = the SDP Answer, the Answerer selects the bundle address for the
=A0 =A0Offerer, based on the address information received in the assoc= iated
=A0 =A0SDP Offer, using the mid value. =A0The mid value ass= ociated with the
=A0 =A0"m=3D" line in the SDP Offer th= at represents the bundle address MUST in
=A0 =A0the SDP Answer be located first in the mid value list added to = SDP
=A0 =A0group:BUNDLE attribute associated with the BUNDLE grou= p.

I am having trouble reading this text. Is this = supposed to say
that the answerer should choose the transport parameters from
one of the m-lines and put the mid associated with those parameters
=
first in the group:BUNDLE attribute he sends?


=A0 =A0From the associated SDP Offer, the Answerer SHOU= LD choose the bundle
=A0 =A0address associated with the mid value= located first in the mid value
=A0 =A0list included in the SDP g= roup:BUNDLE attribute associated with the
=A0 =A0BUNDLE group, unless:

Is there a reaso= n to make this a SHOULD rather than MUST? The
conditions below do= n't really seem to be judgement calls.
I may have missed some= discussion on this, but why not say
MUST use the first mid associated with a non-zero m-line?
= =A0

=A0 =A0o =A01) The mid value represents an &qu= ot;m=3D" line with a port zero value in
=A0 =A0 =A0 the SDP = Offer; or
=A0
=A0 =A0o =A02) The mid value represents an "m=3D&qu= ot; line with a port zero value in
=A0 =A0 =A0 the SDP Answer.
=A0
=A0 =A0OPEN: The decision for allowing a media descri= ption with port zero
=A0 =A0values inside a BUNDLE group is pending on update for RFC 5888.=


=A0
6.4.4. =A0Answerer B= undle Address Selection
=A0
=A0 =A0In the SDP Answer, t= he Answerer selects its local bundle address.
=A0 =A0Each "m=3D" line included in a BUNDLE group MUST cont= ain identical
=A0 =A0address information. =A0The only exception i= s the usage of a zero port
=A0 =A0value for an "m=3D" l= ine, which is allowed eventhough another port
=A0 =A0value number is used for other "m=3D" lines in the BU= NDLE group.
=A0
A forward reference to 6.4.5 would be n= ice here. Or maybe just merge
it in.

=A0 =A0OPEN: The decision for allowing a media description with port z= ero
=A0 =A0values inside a BUNDLE group is pending on update for = RFC 5888.
=A0
=A0 =A0In a subsequent SDP Answer, the An= swerer MAY change its local bundle
=A0 =A0address, as long as each "m=3D" line included the BUN= DLE group contain
=A0 =A0identical address information.
=A0
=A0 =A0For a given BUNDLE group, the Answerer MUST NOT assig= n the bundle
=A0 =A0address to "m=3D" lines that are not included the BUN= DLE group, or to
=A0 =A0"m=3D" lines that are included = in another BUNDLE group.
=A0
6.4.5. =A0Rejecting A BUND= LE Media Description
=A0
=A0 =A0When generating the SDP Answer, if the Answerer w= ants to reject media
=A0 =A0associated with an "m=3D" l= ine in the BUNDLE group, it will add a zero
=A0 =A0port number va= lue to the "m=3D" line, according to the procedures
=A0 =A0defined in RFC 3264.
=A0
=A0 =A0OPEN ISSUE:= It is FFS whether it is allowed to include a port zero
=A0 =A0me= dia descriptions in a BUNDLE group.
=A0
6.4.6. =A0Remov= ing a media description from a BUNDLE group
=A0
=A0 =A0When generating the SDP Answer, if the Answerer w= ants to remove an
=A0 =A0"m=3D" line from a BUNDLE grou= p (without rejecting the "m=3D" line),it
=A0 =A0MUST NO= T include the "m=3D" line in a BUNDLE group. =A0In addition, the<= /div>
=A0 =A0SDP Answer MUST not add its local bundle address to the "m= =3D" line.
=A0
=A0 =A0An Answerer MUST NOT, in the= SDP Answer, remove an "m=3D" line from a
=A0 =A0BUNDLE= group, unless the "m=3D" line had unique address information in<= /div>
=A0 =A0the associated SDP Offer.
=A0
=A0 =A0NOTE: = The reason for the restriction above is that, if the "m=3D" line<= /div>
=A0 =A0would be removed from the BUNDLE group, the address inform= ation would
=A0 =A0be identical to the "m=3D" lines remaining in the BUN= DLE group.
=A0
=A0 =A0OPEN: The decision for allowing a= media description with port zero
=A0 =A0values inside a BUNDLE g= roup is pending on update for RFC 5888.

I thought we had agreed to no bundle splitting.



On Thu, May 30, 2013 at 10:37 AM, Cullen Jennings (fluffy) <fluffy@c= isco.com> wrote:

Looks good to me

On May 29, 2013, at 5:39 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
>
> Based on the e-mail and interim discussions, I=92ve tried together som= e =94Answerer Procedures=94 text for BUNDLE.
>
> For now, I would request that people mainly focus on the technical stu= ff, and if some text is unclear. I WILL align the usage of =93m=3D=94 line = and =93media description=94 :)
>
> Also note that examples will be added later.
>
> Regards,
>
> Christer
>
> -----------------------------------------------------
>
>
> 6.4. =A0Answerer Procedures
>
> 6.4.1. =A0General
>
> =A0 =A0This section describes how an Answerer, when it receives an SDP= Offer
> =A0 =A0including a BUNDLE group, generates the associated SDP Answer.<= br> >
> =A0 =A0When an Answerer receives an SDP Offer which includes a BUNDLE = group,
> =A0 =A0and the Answerer accepts the offered BUNDLE group, the Answerer= MUST
> =A0 =A0generate an SDP Answer according to the procedures in Section 6= .1 and
> =A0 =A0this section.
>
> 6.4.2. =A0RFC 5888 restrictions
>
> =A0 =A0Based on the rules and procedures in RFC 5888, the following > =A0 =A0restrictions also apply to BUNDLE groups in SDP Answers:
>
> =A0 =A0o =A01) A BUNDLE group must not be added to an SDP Answer, unle= ss the
> =A0 =A0 =A0 same BUNDLE group was included in the associated SDP Offer= ; and
>
> =A0 =A0o =A02) An SDP "m=3D" line must not be added to a BUN= DLE group in the SDP
> =A0 =A0 =A0 Answer, unless it in the associated SDP Offer was included= in the
> =A0 =A0 =A0 same BUNDLE group.
>
> 6.4.3. =A0Offerer Bundle Address Selection
>
> =A0 =A0In the SDP Answer, the Answerer selects the bundle address for = the
> =A0 =A0Offerer, based on the address information received in the assoc= iated
> =A0 =A0SDP Offer, using the mid value. =A0The mid value associated wit= h the
> =A0 =A0"m=3D" line in the SDP Offer that represents the bund= le address MUST in
> =A0 =A0the SDP Answer be located first in the mid value list added to = SDP
> =A0 =A0group:BUNDLE attribute associated with the BUNDLE group.
>
> =A0 =A0From the associated SDP Offer, the Answerer SHOULD choose the b= undle
> =A0 =A0address associated with the mid value located first in the mid = value
> =A0 =A0list included in the SDP group:BUNDLE attribute associated with= the
> =A0 =A0BUNDLE group, unless:
>
> =A0 =A0o =A01) The mid value represents an "m=3D" line with = a port zero value in
> =A0 =A0 =A0 the SDP Offer; or
>
> =A0 =A0o =A02) The mid value represents an "m=3D" line with = a port zero value in
> =A0 =A0 =A0 the SDP Answer.
>
> =A0 =A0OPEN: The decision for allowing a media description with port z= ero
> =A0 =A0values inside a BUNDLE group is pending on update for RFC 5888.=
>
> 6.4.4. =A0Answerer Bundle Address Selection
>
> =A0 =A0In the SDP Answer, the Answerer selects its local bundle addres= s.
> =A0 =A0Each "m=3D" line included in a BUNDLE group MUST cont= ain identical
> =A0 =A0address information. =A0The only exception is the usage of a ze= ro port
> =A0 =A0value for an "m=3D" line, which is allowed eventhough= another port
> =A0 =A0value number is used for other "m=3D" lines in the BU= NDLE group.
>
> =A0 =A0OPEN: The decision for allowing a media description with port z= ero
> =A0 =A0values inside a BUNDLE group is pending on update for RFC 5888.=
>
> =A0 =A0In a subsequent SDP Answer, the Answerer MAY change its local b= undle
> =A0 =A0address, as long as each "m=3D" line included the BUN= DLE group contain
> =A0 =A0identical address information.
>
> =A0 =A0For a given BUNDLE group, the Answerer MUST NOT assign the bund= le
> =A0 =A0address to "m=3D" lines that are not included the BUN= DLE group, or to
> =A0 =A0"m=3D" lines that are included in another BUNDLE grou= p.
>
> 6.4.5. =A0Rejecting A BUNDLE Media Description
>
> =A0 =A0When generating the SDP Answer, if the Answerer wants to reject= media
> =A0 =A0associated with an "m=3D" line in the BUNDLE group, i= t will add a zero
> =A0 =A0port number value to the "m=3D" line, according to th= e procedures
> =A0 =A0defined in RFC 3264.
>
> =A0 =A0OPEN ISSUE: It is FFS whether it is allowed to include a port z= ero
> =A0 =A0media descriptions in a BUNDLE group.
>
> 6.4.6. =A0Removing a media description from a BUNDLE group
>
> =A0 =A0When generating the SDP Answer, if the Answerer wants to remove= an
> =A0 =A0"m=3D" line from a BUNDLE group (without rejecting th= e "m=3D" line),it
> =A0 =A0MUST NOT include the "m=3D" line in a BUNDLE group. = =A0In addition, the
> =A0 =A0SDP Answer MUST not add its local bundle address to the "m= =3D" line.
>
> =A0 =A0An Answerer MUST NOT, in the SDP Answer, remove an "m=3D&q= uot; line from a
> =A0 =A0BUNDLE group, unless the "m=3D" line had unique addre= ss information in
> =A0 =A0the associated SDP Offer.
>
> =A0 =A0NOTE: The reason for the restriction above is that, if the &quo= t;m=3D" line
> =A0 =A0would be removed from the BUNDLE group, the address information= would
> =A0 =A0be identical to the "m=3D" lines remaining in the BUN= DLE group.
>
> =A0 =A0OPEN: The decision for allowing a media description with port z= ero
> =A0 =A0values inside a BUNDLE group is pending on update for RFC 5888.=
>
>
> __________________= _____________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

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

--20cf30334e03947af704de18cd78-- From christer.holmberg@ericsson.com Sun Jun 2 11:33:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD2621F90EE for ; Sun, 2 Jun 2013 11:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.426 X-Spam-Level: X-Spam-Status: No, score=-5.426 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miP532Qxm121 for ; Sun, 2 Jun 2013 11:33:23 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D381221F90CD for ; Sun, 2 Jun 2013 11:33:18 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-48-51ab8fec2b9b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.37.18006.CEF8BA15; Sun, 2 Jun 2013 20:33:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 20:33:16 +0200 From: Christer Holmberg To: Eric Rescorla , "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) Thread-Index: Ac5cYL6Xjkqad1ozQWuoyGt6QctbSAA6uR4AAF6XlAAAPeC20A== Date: Sun, 2 Jun 2013 18:33:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3812FB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3812FBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre6b/tWBBks/m1iseH2O3aJjMpvF 1OWPWRyYPab83sjqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgyXr7rZi941M1YsXvWTJYG xomVXYwcHBICJhKnHkl2MXICmWISF+6tZwOxhQQOM0rM7U/tYuQCshczSmy53s0GUs8mYCHR /U8bpEZEIFBi6oTJLCBhZgF1iauLg0BMYQFHiYb3UBVOEk9/rWGHsdvuHAKbziKgIrFi0UEw m1fAV6LxyWMmiE3XGSUW3jwA1sAJNH7BgcMsIDYj0GnfT61hArGZBcQlPhy8zgxxsoDEkj3n oWxRiZeP/7FC2EoSjUuesELU50v8ePaTCWKZoMTJmU9YJjCKzkIyahaSsllIyiDiOhILdn9i g7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HKjTYzACDu45bfqDsY750QOMUpzsCiJ8+rx Lg4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJi64LjEs63WRw+n37sUf3xps4Dvz9QsKfc3 GrV2tUWL2OQjCyZu3hCh3P36fsziD+sk1uxk/MZ7cXEqg/Lm87y/a+vcFs7/tPDF31OvOH+b Mex99N1h0iyFlbdrf/zSuPK1xH+u8DvzvONnCubGn532dZPi6TnRDUdXtd1foHZPM0pw/kzh GRN3KbEUZyQaajEXFScCAA7Vf3p+AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2013 18:33:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3812FBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 6.4.3. Offerer Bundle Address Selection In the SDP Answer, the Answerer selects the bundle address for the Offerer, based on the address information received in the associated SDP Offer, using the mid value. The mid value associated with the "m=3D" line in the SDP Offer that represents the bundle address MUST in the SDP Answer be located first in the mid value list added to SDP group:BUNDLE attribute associated with the BUNDLE group. >I am having trouble reading this text. Is this supposed to say >that the answerer should choose the transport parameters from >one of the m-lines and put the mid associated with those parameters >first in the group:BUNDLE attribute he sends? Yes. ----------------------------------- From the associated SDP Offer, the Answerer SHOULD choose the bundle address associated with the mid value located first in the mid value list included in the SDP group:BUNDLE attribute associated with the BUNDLE group, unless: Is there a reason to make this a SHOULD rather than MUST? The conditions below don't really seem to be judgement calls. I may have missed some discussion on this, but why not say MUST use the first mid associated with a non-zero m-line? Actually, the text (and the conditions) probably needs some re-wording, be= cause I mostly had the initial offer in mind. But, assume an updated offer, where the first m- line is changed from zero = to a non-zero value ("taken back into use") - which is different from the c= urrent bundle address. The answerer may want to keep the current offerer bu= ndle address. However, this also depends on whether an m- line that is taken back into us= e is allowed to have another address than the current bundle address to beg= in with. I'll discuss that in the SDP Offer section. ----------------------------------- 6.4.4. Answerer Bundle Address Selection In the SDP Answer, the Answerer selects its local bundle address. Each "m=3D" line included in a BUNDLE group MUST contain identical address information. The only exception is the usage of a zero port value for an "m=3D" line, which is allowed eventhough another port value number is used for other "m=3D" lines in the BUNDLE group. A forward reference to 6.4.5 would be nice here. Or maybe just merge it in. I can add a forward reference for now. I think we should wait with the cosm= etics until we have the new version of the draft available. ----------------------------------- 6.4.6. Removing a media description from a BUNDLE group When generating the SDP Answer, if the Answerer wants to remove an "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),it MUST NOT include the "m=3D" line in a BUNDLE group. In addition, the SDP Answer MUST not add its local bundle address to the "m=3D" line. An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from a BUNDLE group, unless the "m=3D" line had unique address information in the associated SDP Offer. NOTE: The reason for the restriction above is that, if the "m=3D" line would be removed from the BUNDLE group, the address information would be identical to the "m=3D" lines remaining in the BUNDLE group. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. I thought we had agreed to no bundle splitting. I am not sure what you mean by "splitting", but this is not about moving an= m- line from one BUNDLE group to another BUNDLE group, but to move it outs= ide an BUNDLE group all together. People wanted to allow that in the case w= here the Offer contains different ports, but if you disagree we need to dis= cuss it further. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3812FBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

 

6.4.3.  Offerer Bundle Address Selection

 

   In the SDP Answer, the Answerer selects= the bundle address for the

   Offerer, based on the address informati= on received in the associated

   SDP Offer, using the mid value.  T= he mid value associated with the

   "m=3D" line in the SDP Offer = that represents the bundle address MUST in

   the SDP Answer be located first in the = mid value list added to SDP

   group:BUNDLE attribute associated with = the BUNDLE group.

 

>I am having trouble reading this text. Is this supposed to say

>that the answerer should choose the transport para= meters from

>one of the m-lines and put the mid associated with= those parameters

>first in the group:BUNDLE attribute he sends?=

&n= bsp;

Yes.<= /o:p>

 = ;

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

 

   From the as= sociated SDP Offer, the Answerer SHOULD choose the bundle

   address associated with the mid value l= ocated first in the mid value

   list included in the SDP group:BUNDLE a= ttribute associated with the

   BUNDLE group, unless:

 

Is there a reason to make this a SHOULD rather than = MUST? The

conditions below don't really seem to be judgement c= alls.

I may have missed some discussion on this, but why n= ot say

MUST use the first mid associated with a non-zero m-= line?

 

Actually, =  the text (and the conditions) probably needs some re-wording, because= I mostly had the initial offer in mind.

 = ;

But, assum= e an updated offer, where the first m- line is changed from zero to a non-z= ero value (“taken back into use”) – which is different fr= om the current bundle address. The answerer may want to keep the current offe= rer bundle address.

 = ;

However, t= his also depends on whether an m- line that is taken back into use is allow= ed to have another address than the current bundle address to begin with. I’ll discuss that in the SDP Offer section.

 = ;

 = ;

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

 

 

6.4.4.  Answerer Bundle Address Selection<= /o:p>

 

   In the SDP Answer, the Answerer selects= its local bundle address.

   Each "m=3D" line included in = a BUNDLE group MUST contain identical

   address information.  The only exc= eption is the usage of a zero port

   value for an "m=3D" line, whi= ch is allowed eventhough another port

   value number is used for other "m= =3D" lines in the BUNDLE group.

 

A forward reference to 6.4.5 would be nice here. Or = maybe just merge

it in.

 

I can add = a forward reference for now. I think we should wait with the cosmetics unti= l we have the new version of the draft available.

 = ;

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

 

6.4.6.  Removing a media description from a BUN= DLE group

 

   When generating the SDP Answer, if the = Answerer wants to remove an

   "m=3D" line from a BUNDLE gro= up (without rejecting the "m=3D" line),it

   MUST NOT include the "m=3D" l= ine in a BUNDLE group.  In addition, the

   SDP Answer MUST not add its local bundl= e address to the "m=3D" line.

 

   An Answerer MUST NOT, in the SDP Answer= , remove an "m=3D" line from a

   BUNDLE group, unless the "m=3D&quo= t; line had unique address information in

   the associated SDP Offer.

 

   NOTE: The reason for the restriction ab= ove is that, if the "m=3D" line

   would be removed from the BUNDLE group,= the address information would

   be identical to the "m=3D" li= nes remaining in the BUNDLE group.

 

   OPEN: The decision for allowing a media= description with port zero

   values inside a BUNDLE group is pending= on update for RFC 5888.

 

I thought we had agreed to no b= undle splitting.

 = ;

I am not s= ure what you mean by “splitting”, but this is not about moving = an m- line from one BUNDLE group to another BUNDLE group, but to move it outside an BUNDLE group all together. People wanted to allow that in th= e case where the Offer contains different ports, but if you disagree we nee= d to discuss it further.

 = ;

Regards,

 = ;

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3812FBESESSMB209erics_-- From christer.holmberg@ericsson.com Sun Jun 2 11:42:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122EB21F90F4 for ; Sun, 2 Jun 2013 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wopOfYegdfqI for ; Sun, 2 Jun 2013 11:42:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 57D8921F911B for ; Sun, 2 Jun 2013 11:42:04 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-8e-51ab91f996a0 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 41.87.18006.9F19BA15; Sun, 2 Jun 2013 20:42:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 20:42:01 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgio= Date: Sun, 2 Jun 2013 18:42:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> In-Reply-To: <51A8B059.7070705@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre6viasDDc795rCYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MjTe/MBXsFqr4dOk/YwPjbr4uRk4OCQET iVl39jFC2GISF+6tZ+ti5OIQEjjMKHH7601GCGcxo8TCbXuZuxg5ONgELCS6/2mDNIgI+Eo8 e3ybDcQWFtCVOLn7ERNEXE/i8637zBC2lUTb0YusIDaLgIrEyltX2UFsXqDe/4vvgdlCArkS d+40soGM5xTQkZizUgwkzAh0z/dTa8BGMguIS3w4eJ0Z4k4BiSV7zkPZohIvH/9jhbCVJBqX PGGFqNeRWLD7ExuErS2xbOFrZoi1ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc 9HKjTYzASDi45bfqDsY750QOMUpzsCiJ8+rxLg4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wLjw3eKTnksC0+d/Flzd3vrwrUECxzoxV8+ZEobhCxsaE93ebBJ7U+c+T8CveYa7zbNMk4sr j95b32e5MfT+YzfXZbdWT1nxU2XPyjM5Z5QuhnSYO02+m5mr5/RWNdfrzrr/q/v2bGdovXso 1tK3L7BHtaaQc1bXrtZ77ysPrPwmKqB2u/LEui1KLMUZiYZazEXFiQBwf0K8UgIAAA== Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2013 18:42:11 -0000 Hi, >> I'll throw the ball out with suggesting the following ones: >> >> -*Bundle restart offer* (different port value, currently referred to as >> "first offer") >> >> The reason I use "restart" wording is because this is used, no matter >> whether in the beginning of the session or mid-session, to >> (re-)negotiate the usage of BUNDLE, and the bundle address information >> selection. >> >> -*Bundle sync offer* (identical port value, currently referred to as >> "second offer") >> >> The reason I used "sync" wording is because this is used to ensure that >> intermediaries have correct address information for each m- line. >> >> Keep in mind that we may even need to split the sync offer into more sub >> types, when we get into the details of adding new m- lines etc, but I'd >> like to agree a base to start from :) > > Above seems like a good start, but I'm still grappling with some things > and don't know how to talk about concisely: > > I understand that the next offer after a Bundle Restart Offer will > typically be a Bundle Sync Offer. But if there is another offer after a > Bundle Sync Offer, and it doesn't change anything about the bundle, then > is it still a Bundle Sync Offer? Currently, yes.=20 > Also, I don't believe the above are mutually exclusive. If I send an > offer to add a new m-line to a bundle, and I give it distinct address > info so that the answerer may take it out of the bundle if needed, then > is that a Bundle Restart Offer or a Bundle Sync Offer? It seems to be a > bit of each. And of course there may be multiple bundles described by > the SDP, and these terms apply independently to each. > > Maybe we need a couple more terms for: > > - offer that adds a new m-line to bundle using the existing bundle > address info. Technically that is a Bundle Sync Offer, but I DO agree that the wording is= not good in this case - as it's not only about synchronization. > - offer that adds a new m-line to an existing bundle using unique > address info. I agree that doesn't fit the current definitions. However, we will have to agree on whether we allow that in the first place,= or whether the offerer will have to use 1) same address information or 2) = different address information for ALL m- lines (Bundle Restart Offer). Regards, Christer From albrecht.schwarz@alcatel-lucent.com Mon Jun 3 01:13:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256B921F935A; Mon, 3 Jun 2013 01:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBF0zWsSFp9l; Mon, 3 Jun 2013 01:12:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BD93B21F92F5; Mon, 3 Jun 2013 01:11:15 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r538AQDm021293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Jun 2013 03:10:26 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r538AHwO017294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 04:10:26 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 3 Jun 2013 04:10:22 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 3 Jun 2013 10:10:10 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: 3GPP RTP header extension Thread-Index: Ac5YY467f6iD3KE+RZKtUYPDcgGk6wHzLKGw Date: Mon, 3 Jun 2013 08:10:10 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC046CF5@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "megaco@ietf.org" , "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Subject: Re: [MMUSIC] 3GPP RTP header extension X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 08:13:09 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The subject was also on the agenda of 3GPP CT4 at last meeting. It may be noted that RFC 5285 is special with regards to the definition of = two capabilities of a) IP data path (RTP header extension; clause 4/RFC 5285) and b) IP signaling path (SDP signalling; ; clauses 5&6/RFC 5285) in a single RFC. Both capabilities could be also defined in separated RFCs. The tight coupling of both capabilities in a single RFC may be interpreted = in the following: the network should not forward RTP packets with extended = headers in case of missing SDP "a=3Dextmap:" signalling or/and failed SDP O= /A. E.g., an interim RTP translator (RTP transport translator or RTP media tran= slator) would block RTP packets with extension headers (dependent on above = SDP O/A ...). Conclusion: there seems to be some implicit semantics in RFC 5285 in my understanding. Regards, Albrecht From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Freitag, 24. Mai 2013 12:06 To: mmusic@ietf.org Subject: [MMUSIC] 3GPP RTP header extension Hi, In the virtual interim meeting yesterday, I was requested to look into the = RTP header extension(s) defined by 3GPP. 3GPP SA4 has defined a header extension for "Coordination of Video Orientat= ion" purpose (may be of interest for CLUE btw, but that's a separate story)= . The length of the extension is 1 byte. For more information, see section 7.4.5 of 3GPP TS 24.114 :) http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-c10.zip Regards, Christer --_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The subject was also on the a= genda of 3GPP CT4 at last meeting.

 

It may be noted that RFC 5285= is special with regards to the definition of two capabilities of

a) IP data path (RTP header e= xtension; clause 4/RFC 5285) and

b) IP signaling path (SDP sig= nalling; ; clauses 5&6/RFC 5285)

in a single RFC. Both capabil= ities could be also defined in separated RFCs.

 

The tight coupling of both ca= pabilities in a single RFC may be interpreted in the following: the network= should not forward RTP packets with extended headers in case of missing SDP “a=3Dextmap:” signalling or/and failed = SDP O/A.

 

E.g., an interim RTP translat= or (RTP transport translator or RTP media translator) would block RTP packe= ts with extension headers (dependent on above SDP O/A …).

 

Conclusion:=

there seems to be some implic= it semantics in RFC 5285 in my understanding.

 

Regards,

Albrecht

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg] On Behalf Of Christer Holmberg
Sent: Freitag, 24. Mai 2013 12:06
To: mmusic@ietf.org
Subject: [MMUSIC] 3GPP RTP header extension

 

Hi,

 

In the virtual interim meeting = yesterday, I was requested to look into the RTP header extension(s) defined= by 3GPP.

 

3GPP SA4 has defined a header e= xtension for “Coordination of Video Orientation” purpose (may b= e of interest for CLUE btw, but that’s a separate story). The length = of the extension is 1 byte.

 

For more information, see secti= on 7.4.5 of 3GPP TS 24.114 :)

 

http://www.3gpp.org/ftp/S= pecs/archive/26_series/26.114/26114-c10.zip

 

Regards,

 

Christer

--_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_-- From abegen@cisco.com Mon Jun 3 03:59:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8195321F9455 for ; Mon, 3 Jun 2013 03:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYaDnNFXdGfa for ; Mon, 3 Jun 2013 03:59:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0409621F93BA for ; Mon, 3 Jun 2013 03:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1370257157; x=1371466757; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=myWBsqCEYmKMsQ7itZornkwpE/RsVng13bubOP7S72s=; b=ku1Vlxvpce3+la4UvvtJCkuDwSMjpJTf5tSRCs988KpjSEVD71sC0mBH I2d7KZmwZf8JjttG3fvVqjuxkY971opJfx8jx83CxgvFG9vaJ/UQOaC5s 033Gjt3U/7gWkDM3qf3UlsWN5EMUEaRp8lQZG/Sga7R8uMpU7dCuAChbo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFAJV2rFGtJXHB/2dsb2JhbABZgmghML8EfxZtB4IlAQQ6PxIBKhRCJwQODQGIBAELrT2NLo52MQKCfGEDqH6DD4In X-IronPort-AV: E=Sophos;i="4.87,792,1363132800"; d="scan'208";a="218090379" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2013 10:58:59 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r53AwxmQ003819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 10:58:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 05:58:59 -0500 From: "Ali C. Begen (abegen)" To: "draft-ietf-xrblock-rtcp-xr-loss-conceal@tools.ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-loss-conceal-05 Thread-Index: AQHOYElZgyXNkt/U/0+WIwSPFpWz0g== Date: Mon, 3 Jun 2013 10:58:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <56803ABD1204DF4AB58427CE3A1CB8D7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: xrblock-chairs , mmusic Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-loss-conceal-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:59:25 -0000 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - The RTCP XR extension syntax seems to have an issue, see below - There are a few editorial issues Issues: 1) Section 1.4: Can I use these metrics for the audio component of A/V appl= ications? If yes, then section 1.4 sounds overly restrictive. 2) Capitalization of the block/metric names is inconsistent. 3) Section 5.1, first parag.: The document defines two blocks not one. 4) Section 5.1: Why are using=20 xr-format =3D/ xr-conceal-block xr-format =3D/ xr-conc-sec-block instead of xr-format =3D/ xr-conceal-block / xr-conc-sec-block 5) Section 6.1: Where do "NCS" and "NLC" come from? Why not choose more app= ropriate acronyms? Also use the correct registry name: "RTP Control Protoco= l Extended Reports (RTCP XR) Block Type Registry" 6) Section 6.2: Please use the correct registry name: "RTP Control Protocol= Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters R= egistry".= From internet-drafts@ietf.org Mon Jun 3 04:21:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9249721F93BA; Mon, 3 Jun 2013 04:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXbt5pbKV+jS; Mon, 3 Jun 2013 04:21:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6257821F9485; Mon, 3 Jun 2013 04:21:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603112055.14195.33589.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 04:20:55 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:21:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Audio and Video Media Streams Over Circuit-Switched Bearers In The Public = Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-19.txt Pages : 36 Date : 2013-06-03 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Mon Jun 3 05:25:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF70F21F843F for ; Mon, 3 Jun 2013 05:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdipyFOdQJos for ; Mon, 3 Jun 2013 05:25:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5447E21F9634 for ; Mon, 3 Jun 2013 05:25:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN32303; Mon, 03 Jun 2013 12:25:03 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 3 Jun 2013 13:24:13 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 3 Jun 2013 13:24:58 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Mon, 3 Jun 2013 20:24:51 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , "draft-ietf-xrblock-rtcp-xr-loss-conceal@tools.ietf.org" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-loss-conceal-05 Thread-Index: AQHOYElZgyXNkt/U/0+WIwSPFpWz0pkj55UA Date: Mon, 3 Jun 2013 12:24:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: xrblock-chairs , mmusic Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-loss-conceal-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:25:20 -0000 Hi, Ali: -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ali C. Begen (abegen) Sent: Monday, June 03, 2013 6:59 PM To: draft-ietf-xrblock-rtcp-xr-loss-conceal@tools.ietf.org Cc: xrblock-chairs; mmusic Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-los= s-conceal-05 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - The RTCP XR extension syntax seems to have an issue, see below - There are a few editorial issues Issues: 1) Section 1.4: Can I use these metrics for the audio component of A/V appl= ications? If yes, then section 1.4 sounds overly restrictive. [Qin]: Right, I propose the following change: OLD TEXT: " These metrics are only applicable to audio applications of RTP. " NEW TEXT: " These metrics are applicable to both audio applications of RTP and the audi= o component of A/V applications. " 2) Capitalization of the block/metric names is inconsistent. [Qin]: Okay, will fix this. 3) Section 5.1, first parag.: The document defines two blocks not one. [Qin]: Okay, will fix this. 4) Section 5.1: Why are using=20 xr-format =3D/ xr-conceal-block xr-format =3D/ xr-conc-sec-block instead of xr-format =3D/ xr-conceal-block / xr-conc-sec-block [Qin]: Agree to use the latter, thank for your proposed change. 5) Section 6.1: Where do "NCS" and "NLC" come from? Why not choose more app= ropriate acronyms?=20 [Qin]: Okay. Also use the correct registry name: "RTP Control Protocol Extended Reports = (RTCP XR) Block Type Registry" [Qin]: Okay. 6) Section 6.2: Please use the correct registry name: "RTP Control Protocol= Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters R= egistry". [Qin]: Okay. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From richard.ejzak@alcatel-lucent.com Mon Jun 3 12:29:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B0921E80B0 for ; Mon, 3 Jun 2013 12:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9fvpZF0fAqU for ; Mon, 3 Jun 2013 12:29:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 179F121E80A4 for ; Mon, 3 Jun 2013 12:23:07 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r53JMmpT018938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Jun 2013 14:22:49 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r53JMaKV008366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 15:22:48 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 3 Jun 2013 15:22:34 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" , "suhasietf@gmail.com" , =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Flemming Andreasen (fandreas@cisco.com)" Thread-Topic: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 Thread-Index: Ac5dzHO0Q+r/un2nR0ihy0dNOS7t9gCuMDzQ Date: Mon, 3 Jun 2013 19:22:33 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D7CDAF9@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C37E6A7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37E6A7@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.17] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D7CDAF9US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 19:29:51 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D7CDAF9US70UWXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for asking me to comment on 5.42. First of all, I agree with all yo= ur other comments. I would recommend that the category for all the items i= n 5.42 be listed as "SPECIAL" since more work would need to be done in 3GPP= to specify their potential use with BUNDLE. These attributes are all tran= sport related but not in a way that can be easily captured by the category = "TRANSPORT". There are two typos in the table: "visited realm" should be "visited-realm"= and the second occurrence of "omr-m-att" should be "omr-m-bw". Richard From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, May 31, 2013 2:33 AM To: mmusic@ietf.org; suhasietf@gmail.com; Ari Ker=E4nen; Flemming Andreasen= (fandreas@cisco.com) Cc: Ejzak, Richard P (Richard) Subject: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections = 5.22, 5.40, 5.41, 5.42 Hi, I was requested to review the attributes listed in sections 5.22, 5.40, 5.4= 1 and 5.42. However, first I have a general comment on the document: For some attributes (e.g. MSRP-CEMA), there is note text saying: "Not recommended due to legacy interop purposes" Making such statements is completely outside the scope of the document. The= document is about multiplexing, and how/if attributes are affected. There is also similar note text saying: "Not recommended due to interop purposes" Now, for the 3GPP defined attributes you could say "Usage only defined for = IMS", or something. But, again, it's not within the scope of this document = to recommend against using things. ...unless, of course, there from a multiplexing perspective is a reason to = do so, and they should be listed under the NOT RECOMMENDED category: 5.22 +------------+---------------------------------+---------+----------+ | Name | Notes | Current | Category | +------------+---------------------------------+---------+----------+ | msrp-cema | | M | NORMAL | | | | | | | | | | | +------------+---------------------------------+---------+----------+ 5.40 +-------------+--------------------------------+---------+----------+ | Name | Notes | Current | Category | +-------------+--------------------------------+---------+----------+ | g.3gpp.cat | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem [ref] | | | | | | | | +-------------+--------------------------------+---------+----------+ 5.41 +-------------+--------------------------------+---------+----------+ | Name | Notes | Current | Category | +-------------+--------------------------------+---------+----------+ | g.3gpp.crs | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem [ref] | | | | | | | | +-------------+--------------------------------+---------+----------+ 5.42 This is actually an interesting one, and needs a little more investigation.= So, I'll have to come back on that one. It would be good if Richard Ejzak,= who is the "architect" behind the attributes, could take a look :) +------------------+---------------------------+---------+----------+ | Name | Notes | Current | Category | +------------------+---------------------------+---------+----------+ | secondary-realm | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | visited realm | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-m-cksum | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-s-cksum | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-m-att | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-s-att | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-s-bw | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-m-att | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | | omr-codecs | Usage defined for the IP | M | TBD | | | Multimedia Subsystem [ref]| | | | | | | | +------------------+---------------------------+---------+----------+ Regards, Christer --_000_03FBA798AC24E3498B74F47FD082A92F3D7CDAF9US70UWXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Christer,

Thanks for asking me t= o comment on 5.42.  First of all, I agree with all your other comments= .  I would recommend that the category for all the items in 5.42 be li= sted as “SPECIAL” since more work would need to be done in 3GPP to specify their potential use with BUNDLE.  These at= tributes are all transport related but not in a way that can be easily capt= ured by the category “TRANSPORT”.

 

There are two typos in= the table: “visited realm” should be “visited-realm̶= 1; and the second occurrence of “omr-m-att” should be “om= r-m-bw”.

 

Richard

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, May 31, 2013 2:33 AM
To: mmusic@ietf.org; suhasietf@gmail.com; Ari Ker=E4nen; Flemming An= dreasen (fandreas@cisco.com)
Cc: Ejzak, Richard P (Richard)
Subject: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: se= ctions 5.22, 5.40, 5.41, 5.42

 

Hi,

 

I was requested to review the attributes listed in s= ections 5.22, 5.40, 5.41 and 5.42.

 

However, first I have a general comment on the docum= ent:

 

For some attributes (e.g. MSRP-CEMA), there is note = text saying:

 

“Not recommended due to legacy interop purpose= s”

 

Making such statements is completely outside the sco= pe of the document. The document is about multiplexing, and how/if attribut= es are affected.

 

There is also similar note text saying:

 

“Not recommended due to interop purposes”= ;

 

Now, for the 3GPP defined attributes you could say &= #8220;Usage only defined for IMS”, or something. But, again, it’= ;s not within the scope of this document to recommend against using things.=

 

…unless, of course, there from a multiplexing = perspective is a reason to do so, and they should be listed under the NOT R= ECOMMENDED category:

 

 

5.22

 

  +------------+-----------------------------= ----+---------+----------+

   | Name       | = Notes           &nbs= p;            &= nbsp;  | Current | Category |

   +------------+-----------------------= ----------+---------+----------+

   | msrp-cema  |    &n= bsp;            = ;             &= nbsp;  | M       | NORMAL &nbs= p; |

   |       &n= bsp;    |         &n= bsp;            = ;           | &= nbsp;       |     &n= bsp;    |

   |       &n= bsp;    |        &nb= sp;            =             | &= nbsp;       |     &n= bsp;    |

   +------------+-----------------------= ----------+---------+----------+

 

 

5.40

 

   +-------------+--------------------------------&#=
43;---------+----------+
   | Name        | Notes&=
nbsp;           &nbs=
p;             =
| Current | Category |
   +-------------+--------------------------------&#=
43;---------+----------+
   | g.3gpp.cat  | Usage defined for the IP  =
     | M       | NORMAL &=
nbsp; |
   |         &n=
bsp;   | Multimedia Subsystem [ref]     |&nbs=
p;        |     =
;     |
   |         &n=
bsp;   |         &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   +-------------+--------------------------------&#=
43;---------+----------+

 

 

5.41

 

   +-------------+--------------------------------&#=
43;---------+----------+
   | Name        | Notes&=
nbsp;           &nbs=
p;             =
| Current | Category |
   +-------------+--------------------------------&#=
43;---------+----------+
   | g.3gpp.crs  | Usage defined for the IP  =
     | M       | NORMAL &=
nbsp; |
   |         &n=
bsp;   | Multimedia Subsystem [ref]     |&nbs=
p;        |     =
;     |
   |         &n=
bsp;   |         &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   +-------------+--------------------------------&#=
43;---------+----------+

 

 

5.42

 

This is actually an interesting one, and needs a lit= tle more investigation. So, I’ll have to come back on that one. It wo= uld be good if Richard Ejzak, who is the “architect” behind the= attributes, could take a look :)

 

  +------------------+---------------------------+---=
------+----------+
   | Name        &nb=
sp;    | Notes       &nbs=
p;             =
| Current | Category |
   +------------------+---------------------------&#=
43;---------+----------+
   | secondary-realm  | Usage defined for the IP  =
| M       | TBD      =
;|
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | visited realm    | Usage defined for the=
 IP  | M       | TBD   &n=
bsp;  |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-m-cksum      | Usage defin=
ed for the IP  | M       | TBD &nbs=
p;    |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-s-cksum      | Usage defin=
ed for the IP  | M       | TBD &nbs=
p;    |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-m-att        | U=
sage defined for the IP  | M       | TBD=
      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-s-att        | U=
sage defined for the IP  | M       | TBD=
      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-s-bw        =
; | Usage defined for the IP  | M       =
| TBD      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   | omr-m-att        | U=
sage defined for the IP  | M       | TBD=
      |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |    =
     |       &n=
bsp;  |
   | omr-codecs       | Usage =
defined for the IP  | M       | TBD =
;     |
   |         &n=
bsp;        | Multimedia Subsystem [ref]=
|         |    =
      |
   |         &n=
bsp;        |    &nb=
sp;            =
          |   &=
nbsp;     |       &n=
bsp;  |
   +------------------+---------------------------&#=
43;---------+----------+

 

 

 

Regards,

 

Christer

 

--_000_03FBA798AC24E3498B74F47FD082A92F3D7CDAF9US70UWXCHMBA05z_-- From fluffy@iii.ca Mon Jun 3 13:12:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E08F21E8109 for ; Mon, 3 Jun 2013 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE8p3KfS9ZHE for ; Mon, 3 Jun 2013 13:12:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D40BF21E8098 for ; Mon, 3 Jun 2013 13:06:04 -0700 (PDT) Received: from sjc-vpn1-987.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A93CC22E200; Mon, 3 Jun 2013 16:06:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51ACD224.8080100@jitsi.org> Date: Mon, 3 Jun 2013 14:06:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D1E0FD6-9AC4-425E-8DC2-E22BC7040B61@iii.ca> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1503) Cc: mmusic WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 20:12:37 -0000 On Jun 3, 2013, at 11:28 AM, Emil Ivov wrote: > An offer generated by a "No Plan" browser in this case would look = something like this: >=20 > v=3D0 > o=3D- 20518 0 IN IP4 198.51.100.1 > s=3D > t=3D0 0 > c=3DIN IP4 203.0.113.1 > a=3Dice-ufrag:F7gI > a=3Dice-pwd:x9cml/YzichV2+XlhiMu8g > a=3Dfingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 > a=3Dgroup:BUNDLE m0 m1 >=20 > m=3Daudio 56600 RTP/SAVPF 96 0 > a=3Dmid:m0 > a=3Drtpmap:96 opus/48000 > a=3Drtpmap:0 PCMU/8000 > a=3Dptime:20 > a=3Dsendrecv > a=3Drtcp-mux > [ICE candidates] >=20 > m=3Dvideo 56602 RTP/SAVPF 97 98 > a=3Dmid:m1 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtpmap:98 VP8/90000 > a=3Dsendrecv > a=3Drtcp-mux > [ICE candidates] In no-plan, What would the answer look like if you were receiving 2 = video stream? From pkyzivat@alum.mit.edu Mon Jun 3 13:33:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5221E808B for ; Mon, 3 Jun 2013 13:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWwu9WeIvZXg for ; Mon, 3 Jun 2013 13:33:38 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id B861021E8099 for ; Mon, 3 Jun 2013 13:24:27 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id jn071l0050bG4ec5EwQSB8; Mon, 03 Jun 2013 20:24:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id jwQS1l00s3ZTu2S3PwQSvm; Mon, 03 Jun 2013 20:24:26 +0000 Message-ID: <51ACFB79.1080207@alum.mit.edu> Date: Mon, 03 Jun 2013 16:24:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370291066; bh=zb1xlpISYqahfUJMpKuR7VUrRk4rZfTAQ5gpd7fYNEE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=A2BERj1px+d/pXQEx06RLL7+Zf7vTkjVUxDsttU50IrixVVdggL8D1tZao90FPz5F AT+ob8098LTPjDw6SyYfu1nw7qFtDDvZ/OHDVtVFHkN5nF7sZpkPqN+KsrHb+Jd+jy q/s52Vtk6Rahk0okVuAWJU9C5AP/s8o8yWbJPSV3CRJEvXnKeg1Bej4tqulcs5zOVH pkUhylgm50m+nh+uXSRAY1Q8+ovS9YfA99JBcbqwZ9FDBc7sDj+dC51B4wuCgrL8oE aQpDIZj9DhlrrJSiAdBK/E+0XkH4J0IG6fIvgVvA2iyCgAkYNFNX+0T+Ih1+FDiunQ BqkJrF/XyhhKQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 20:33:54 -0000 On 6/2/13 2:42 PM, Christer Holmberg wrote: > > Hi, > >>> I'll throw the ball out with suggesting the following ones: >>> >>> -*Bundle restart offer* (different port value, currently referred to as >>> "first offer") >>> >>> The reason I use "restart" wording is because this is used, no matter >>> whether in the beginning of the session or mid-session, to >>> (re-)negotiate the usage of BUNDLE, and the bundle address information >>> selection. >>> >>> -*Bundle sync offer* (identical port value, currently referred to as >>> "second offer") >>> >>> The reason I used "sync" wording is because this is used to ensure that >>> intermediaries have correct address information for each m- line. >>> >>> Keep in mind that we may even need to split the sync offer into more sub >>> types, when we get into the details of adding new m- lines etc, but I'd >>> like to agree a base to start from :) >> >> Above seems like a good start, but I'm still grappling with some things >> and don't know how to talk about concisely: >> >> I understand that the next offer after a Bundle Restart Offer will >> typically be a Bundle Sync Offer. But if there is another offer after a >> Bundle Sync Offer, and it doesn't change anything about the bundle, then >> is it still a Bundle Sync Offer? > > Currently, yes. I agree that without adjusting the terminology this is the only right choice to make. But it is a little obscure. I'm not certain this needs to be improved, but I thought I would suggest that it might. >> Also, I don't believe the above are mutually exclusive. If I send an >> offer to add a new m-line to a bundle, and I give it distinct address >> info so that the answerer may take it out of the bundle if needed, then >> is that a Bundle Restart Offer or a Bundle Sync Offer? It seems to be a >> bit of each. And of course there may be multiple bundles described by >> the SDP, and these terms apply independently to each. >> >> Maybe we need a couple more terms for: >> >> - offer that adds a new m-line to bundle using the existing bundle >> address info. > > Technically that is a Bundle Sync Offer, but I DO agree that the wording is not good in this case - as it's not only about synchronization. > >> - offer that adds a new m-line to an existing bundle using unique >> address info. > > I agree that doesn't fit the current definitions. > > However, we will have to agree on whether we allow that in the first place, or whether the offerer will have to use 1) same address information or 2) different address information for ALL m- lines (Bundle Restart Offer). Yes, we need to settle on whether either or both of these are permitted. But I can think of reasons why I might wish to use either one, and no good reason not to allow both. So allowing both is my preference. Thanks, Paul From emil@sip-communicator.org Mon Jun 3 14:08:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2C211E80FA for ; Mon, 3 Jun 2013 14:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCP2YcbR+2Jd for ; Mon, 3 Jun 2013 14:08:20 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1F21E805E for ; Mon, 3 Jun 2013 14:01:38 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id c13so457398eek.3 for ; Mon, 03 Jun 2013 14:01:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1A++DhXKrhayEL5CHSUXjzahDAHFcTxBcra11H6YCEU=; b=nfbvxp+0BFLuv0UGF/ZQLZEPJxAYbSxkezG8ZmItMB8ftR/Cgpv54rD8sLFB+Fn6SX RQm85TR0F3y8w20gUXauoNWpqFwQGe6jMcuiIDCgfa3CS/yZpeS4esZLMz7hRgD8FBU2 s03uBmbZgEbnYUwNu+Ismj6WIY46V2lySrrcBYmBqP1Q5XelzmoR7FyQ6EavUImDYxhS DTlXsFXNUcujxlaU9iNtUmEhzZKoXIIvbhctBDB+sMNogSDOeyij+kI7l0xUlYfLZ3VD 5ujD1KfgeYVqZZB7XZ5AQBA0T4W/vI3qE83VokLbWUoy4RkWw4sWy1tCp9kpWPpDqnti IAKQ== X-Received: by 10.15.98.14 with SMTP id bi14mr24005004eeb.92.1370293297177; Mon, 03 Jun 2013 14:01:37 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id y2sm87051312eeu.2.2013.06.03.14.01.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:01:36 -0700 (PDT) Message-ID: <51AD042E.2090302@jitsi.org> Date: Tue, 04 Jun 2013 00:01:34 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkjBwWy6aIXGgEApGceMw7DD6dWPzAtEbKOlXeOQsCEI+JGZxZCyxMMZZ7Z+A7XfYbDWjK1 Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 21:08:30 -0000 (moving from rtcweb) Hey Eric, On 03.06.13, 21:33, Eric Rescorla wrote: > > On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov > wrote: > [...] > > III. Talking to other WebRTC applications > > This is the fun case and the one we should be most concerned with. > Let's imagine that the answerer needs to add a fourth video stream. > To make this work endpoints would need to do the following: > > a) with Plan A and draft-roach-rtcweb-glareless-__add: > - send application specific signalling to the offerer > - have a new O/A exchange > > b) with Plan A: > - have a new O/A exchange > - potentially risk glare with some impact on user experience > > c) with No Plan: > ... nothing > > > I'm really not following how this works in "No Plan". Ignoring Plan A > and Plan B, can you just > walk through a complete example of what happens in your plan? I.e., how > does browser > B learn learn that Browser A wants to send 3 streams instead of one? It just gets three streams instead of one. It sees three new SSRCs and it generates three new MediaStreams. If these streams are supposed to reach the application and be rendered as separate tracks then this is all that needs to happen. They may need to be rendered in a specific order from left to right. But this only concerns the application. There are of course cases where the browser does actually need to know about a relation between these three streams. This would be the case for various kinds of repair flows and layering. Exactly how the browser would learn about these relations would depend on the specific mechanism and there are various options. They may be some that are handled entirely by the codec, or they could use something like the RTP header extension from the draft, or something like Magnus's SRCNAME. They could even be specified in the SDP, but in that case they would be there only because the specific mechanism required it, not because RTCWEB did. Does this make things clearer? Cheers, Emil -- https://jitsi.org From ekr@rtfm.com Mon Jun 3 14:13:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0D21F8FE5 for ; Mon, 3 Jun 2013 14:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XbEQT0fOHzu for ; Mon, 3 Jun 2013 14:13:11 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 00C5321F9654 for ; Mon, 3 Jun 2013 14:07:42 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bv4so2119521qab.19 for ; Mon, 03 Jun 2013 14:07:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=lnF8ROKLkqNYg1v1RHUrCGO1m9h9Dql8eB7flHc050w=; b=iR3XzLrGS3+GNRZinh2CdQwh4bxdAkSQo/uozCBX89CNfp58X0bi521Zq3a1xSgtgH BwGgh4zs8gVaEoWLDYJW40H8z9q+awlrItx36l++X3b7FYYaF042ZlJn1q/9E1GgkqNF NbAOagVRHpTYw+YFIWeZIkps/W7U5guToGmAhJ0MiH3sPkMMClOP1LZ8ztChhjtYANNz bbnTsxyXI+KF8FqAMfulNf/KkYh07pP/OiBuRONfJjCE2b7LWjWwQ1MdIn8yutujJ3aJ NGFuRSD57ZrxUbvcN4DN+OuDbUtjhq6CSN7h119GsujXklSilpfA8De2+vli/damjwEg Xfjg== X-Received: by 10.224.71.145 with SMTP id h17mr21050191qaj.31.1370293662441; Mon, 03 Jun 2013 14:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Mon, 3 Jun 2013 14:07:02 -0700 (PDT) X-Originating-IP: [2620:101:8003:300:5a55:caff:fef1:5a11] In-Reply-To: <51AD042E.2090302@jitsi.org> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> From: Eric Rescorla Date: Mon, 3 Jun 2013 14:07:02 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7bea3174fcf3c604de465aee X-Gm-Message-State: ALoCoQn2rpkwB1jRAM3VLTlZV2uKyFPPB6ykXT4Bt4DWDi0nxpU/acdUnrxT6Boh6NoegJSpbu37 Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 21:13:21 -0000 --047d7bea3174fcf3c604de465aee Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 2:01 PM, Emil Ivov wrote: > (moving from rtcweb) > > Hey Eric, > > > On 03.06.13, 21:33, Eric Rescorla wrote: > >> >> On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov > > wrote: >> [...] >> >> III. Talking to other WebRTC applications >> >> This is the fun case and the one we should be most concerned with. >> Let's imagine that the answerer needs to add a fourth video stream. >> To make this work endpoints would need to do the following: >> >> a) with Plan A and draft-roach-rtcweb-glareless-_**_add: >> >> - send application specific signalling to the offerer >> - have a new O/A exchange >> >> b) with Plan A: >> - have a new O/A exchange >> - potentially risk glare with some impact on user experience >> >> c) with No Plan: >> ... nothing >> >> >> I'm really not following how this works in "No Plan". Ignoring Plan A >> and Plan B, can you just >> walk through a complete example of what happens in your plan? I.e., how >> does browser >> B learn learn that Browser A wants to send 3 streams instead of one? >> > > It just gets three streams instead of one. It sees three new SSRCs and it > generates three new MediaStreams. > So, just for clarity: you mean that A advertises one m-lin, B accepts, and then A sends some arbitrary number of media flows, identified by SSRC? If so, I've got some questions: - If B can only display one video stream, how does it say so? - How does B tell A not to send various streams? - How does B tell A to send one stream big and another stream small? -Ekr --047d7bea3174fcf3c604de465aee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 3, 2013 at 2:01 PM, Emil Ivov <emcho@jitsi.org> wrote:
(moving from rtcweb)

Hey Eric,


On 03.06.13, 21:33, Eric Rescorla wrote:

On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov <emcho@jitsi.org
<mailto:emcho@jitsi= .org>> wrote:
[...]

=A0 =A0 III. Talking to other WebRTC applications

=A0 =A0 This is the fun case and the one we should be most concerned with.<= br> =A0 =A0 Let's imagine that the answerer needs to add a fourth video str= eam.
=A0 =A0 To make this work endpoints would need to do the following:

=A0 =A0 a) with Plan A and draft-roach-rtcweb-glareless-__add:

=A0 =A0 =A0 =A0 - send application specific signalling to the offerer
=A0 =A0 =A0 =A0 - have a new O/A exchange

=A0 =A0 b) with Plan A:
=A0 =A0 =A0 =A0 - have a new O/A exchange
=A0 =A0 =A0 =A0 - potentially risk glare with some impact on user experienc= e

=A0 =A0 c) with No Plan:
=A0 =A0 =A0 =A0 ... nothing


I'm really not following how this works in "No Plan". Ignorin= g Plan A
and Plan B, can you just
walk through a complete example of what happens in your plan? I.e., how
does browser
B learn learn that Browser A wants to send 3 streams instead of one?

It just gets three streams instead of one. It sees three new SSRCs and it g= enerates three new MediaStreams.

= So, just for clarity: you mean that A advertises one m-lin, B accepts,
and then A sends some arbitrary number of media flows, identifie= d
by SSRC? If so, I've got some questions:

- If B can only display one video stream, how does= it say so?
- How does B tell A not to send various streams?
- How does B tell A to send one stream big and another stream small?
=

-Ekr

--047d7bea3174fcf3c604de465aee-- From csp@csperkins.org Mon Jun 3 14:25:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD621F8FBE for ; Mon, 3 Jun 2013 14:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zx7kvwnvjD0 for ; Mon, 3 Jun 2013 14:25:28 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id E811211E80F3 for ; Mon, 3 Jun 2013 14:20:52 -0700 (PDT) Received: from [81.187.2.149] (port=46473 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UjcBO-00020C-Fy; Mon, 03 Jun 2013 22:20:51 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Mon, 3 Jun 2013 18:48:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF59844-9B47-4D2D-87FD-D75F7A3E7CDF@csperkins.org> References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -12 X-Mythic-Debug: Threshold = On = Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 21:25:53 -0000 Cullen, On 30 May 2013, at 20:06, Cullen Jennings (fluffy) wrote: > I've been deliberately merging layers A, B, C all into one in my = discussion of this and focusing on the media stack code which has to = deal with all those layers. The reasons I have been doing that is people = just seemed to confused about what all the parts of RTP are such as RTP = sessions. But most people seemed to understand what bits in the various = packets they could look at what and what data had to end up at the right = spot in the end.=20 I agree that there is some confusion here. However, rather than conflate = the layers, I think it's important that we clearly identify the = different layers and their purposes. WebRTC is trying to use "advanced" = features of RTP, such as multiple simultaneous streams, FEC, layering, = simulcast, and RTCP-based feedback, within a single session. To make = that work, I think we need a clear understanding of what's done = (conceptually) where, else we're running the risk of the = misunderstandings causing non-interoperable behaviours. Conflating all the layers may work for a simple endpoint, with limited = functionality, but I think it will cause increasing problems for WebRTC. = I'd like to get agreement on what conceptual layers exist, and how they = are demultiplexed, to remove this confusion. > At a high level, I would draw the layers a little differently than you = in that many of the implementation I work with do the jitter buffer = after the data is decoded. This allows the implementations to do better = packet loss concealment and play rate games where they speed up or slow = down playback very slightly to smoothly adapt the jitter buffer depth.=20= >=20 > But regardless of the details of the order, the jitter buffer needs to = look at the SSRC and if the SSRC has changed, it probably needs to = retrain the jitter buffer.=20 Sure.=20 > Lets talk a bit more about your diagram and what happens when Alice = creates and Offer with that does not have use bundle and has two audio = codecs. When an RTP packets #1 gets sent to Alice and it arrives before = the answer, somewhere in layer B/C, something needs to look at the PT = value to decide what codec this goes to. Alice knows nothing about what = SSRC the other side is using. Now lets say that packet #2 arrives (again = before answer) and packet #2 is on the same port, same PT, but has a = different SSRC. None of the implementations I work with for audio would = allocate a new PB or CR. Instead they would pass packet #2 throughout = the same codec instance that packet #1 had used and expect things like = the jitter buffer to note the SSRC change and act accordingly. For DSP = based audio systems where the actual codec instances are loaded into the = DSP and have a reserved set or resources allocated for them, this is a = very common design.=20 >=20 > There is probably more variety in video applications but many = conferences bridges act this way.=20 >=20 > So I have no problem if things split on SSRC and whatever processing = that can be done knowing only that is done. That probably includes RTCP, = FEC, RTX , who knows. But before the packed can be decoded by the codec, = something needs to consider the PT and other things such as port when = not doing bundle to make this work. Keep in mind things like PLI are = much more likely to be sent at the layer near the codec than at layer B = so layers B and C are not as cleanly separated as one might wish.=20 Sure. A real implementation will have all sorts of links between the = layers. However, I still think there are separate conceptual stages in = the demultiplexing: a) separate by protocol (RTP, RTCP, STUN, SCTP, = etc.) and pass to that conceptual protocol instance; then for RTP and = RTCP packets b) find what RFC 3550 calls synchronisation sources, and do = the RTP and RTCP layer processing, FEC, RTX, etc; and c) relate those = synchronisation sources to higher-layer concepts in the application, = decode the media, and render. Finding the synchronisation sources at layer B is straight-forward. You = look at the SSRC field of the RTP and RTCP packets and group, following = RFC 3550. Mapping from synchronisation source to codec/rendering context at layer = C can be use any combination of the PT, a=3Dfmtp: parameters of the PT, = SSRC, RTCP SDES items, RTP header extensions, etc., that you care to = signal.=20 > That's a long way of saying, I was talking about the aggregate demux = in media stack that include whatever happened at layers B and C. If = layer B only used SSRC that's fine with me. I am trying to say what = happens in the combination of layer B/C put together. =20 >=20 > What terminology should I be using to not cause confusion ? While you can conflate layers B and C in your implementation, I think we = need to discuss them separately in the specifications to avoid = confusion. Demultiplexing at layer B finds the synchronisation sources = and is an RTP layer feature. I think you're talking about mapping from = synchronisation sources to codecs/rendering pipelines, which is an = operation at layer C of my diagram.=20 That is, I think you can do what you want entirely at conceptual layer C = by the considering the mapping from synchronisation sources to codec and = rendering context. I don't think you need to conceptually combine layers = B and C, and I don't think we should combine them in the specification = (of course, just because we specify the demultiplexing as happening in = three conceptual stages doesn't mean you can't implement it in whatever = way you like, provided it has functionally equivalent behaviour). Colin > On May 27, 2013, at 7:57 AM, Colin Perkins wrote: >=20 >> I don't agree with the phrasing about "packet processing pipelines", = but can't tell if this is a terminology disagreement or a more = fundamental disconnect. The way I see the demultiplexing logically = working is: >>=20 >> | >> | packets >> +-- v >> | +----------+ >> | |UDP socket| >> A | +----------+ >> | RTP || | | >> | and RTCP || | +------> SCTP >> | || +---------> STUN/ICE >> +-- || >> +-- || >> | split by SSRC >> | || || || >> | || || || >> B | +--+ +--+ +--+ >> | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. >> | +--+ +--+ +--+ >> +-- | | | >> +-- | / | >> | +---+ | >> | / | | >> C | +--+ +--+ +--+ >> | |CR| |CR| |CR| Codecs and rendering >> | +--+ +--+ +--+ >> +-- >>=20 >> If your algorithm is for demultiplexing at layer C, i.e., to figure = out what codec and rendering pipeline to use, then I think we're in = agreement apart from terminology.=20 >>=20 >> For layer B, I believe the SSRC is the right thing to use to = demultiplex, and fits with RTP and RTCP. This is where RTCP is = processed, playout de-jitter buffering happens, FEC is processed, NACKs = are sent, etc. It's logically independent of the decoding and rendering = process since you can start filling your de-jitter buffer for an SSRC = before you figure out if/how/where you're going to render that SSRC.=20 >>=20 >> For layer A, there was a clear-cut way of doing this with RTP, RTCP, = and STUN. I haven't looked at SCTP enough to know how that affects = things. I do think it's a logically separate issue, and should be = documented separately to BUNDLE though, since it the same issues arise = with non-bundled sessions. >>=20 >> An implementation might merge these together, of course, but to avoid = confusion the standards should be clear what level they're considering. >>=20 >> Colin >>=20 >>=20 >>=20 >> On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: >>> Great - sounds like we agree this algorithm will work. >>>=20 >>> On May 27, 2013, at 6:41 AM, Colin Perkins = wrote: >>>=20 >>>> I'm not sure I agree. >>>>=20 >>>> As I said in my previous message to the list, if we are agreed that = the m=3D lines in a BUNDLE group form a single RTP session, then I = believe we need unique payload types across all m=3D lines. In this = case, BUNDLE can simply say that regular RTP source demultiplexing based = on the SSRC has to be performed, then the payload type can be used to = match sources to m=3D lines for those applications that care about doing = so.=20 >>>>=20 >>>> If we're not agreed that the m=3D lines in a BUNDLE group form a = single RTP session, then we have a lot more to discuss... >>>>=20 >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>>>> Here's is my proposal for roughly what the bundle draft should say = about this demux topic=20 >>>>>=20 >>>>> Application will decide which packet processing pipeline to pass = an given RTP/RTCP packet to based on what the application knows: >>>>>=20 >>>>> 1) If future RFCs define new things (like RTP header extension), = that explicitly specify the mapping, check if that future RFC is in use = and if so then use that to form the mapping=20 >>>>>=20 >>>>> 2) If the PT type is uniquely identifies a mapping, use that to = form the mapping >>>>>=20 >>>>> 3) If application knows the SSRC the other side will use, use that = to form the mapping=20 >>>>>=20 >>>>> 4) if there is no way to know which pipeline to pass it too, the = packet MAY be discarded or the application MAY decide to buffer it until = the mapping is known=20 >>>>>=20 >>>>> This is trivial to implement. It meets the requirements for Plan = A, Plan B, UCIF, CLUE, and so on.=20 >>>>>=20 >>>>> We could swap the order of step 2 and 3, My thinking for this = order was the only time it made any difference the order was if the PT = were unique and indicated a different mapping than the SSRC. The only = way this could happen is with a SSRC collision so the PT is the one that = would be correct not the SSRC. If someone feels strongly the order of = steps 2 and 3 should be the opposite way around, I can live with that. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic ... --=20 Colin Perkins http://csperkins.org/ From emil@sip-communicator.org Mon Jun 3 14:35:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E88311E80F1 for ; Mon, 3 Jun 2013 14:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrlTfIrNUIlz for ; Mon, 3 Jun 2013 14:35:34 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F2CB011E8111 for ; Mon, 3 Jun 2013 14:29:41 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so3724658wgh.12 for ; Mon, 03 Jun 2013 14:29:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=+71+pZYcPfKIPJn90rkVjtKtibt/7y8Q4N3/y93KTsE=; b=PyM7VDGqk97S5VnbUYxVapESGWcr1/spX2vnRggMAmlrPVD2Yj8ivQhG/OqAgrMcGN 8kH4OpXWqAskqDo/pOczOvYWNhgLMD0saD66c7LAethIAt0oa89V0+C/FqD5sXRjGy2S fs/p4TIY8J2D9U8lECg1H1kj9ff068BpQDBNNx3CsPiXVg5EWU7W1biK9RQBX+95NR8Y kbGeffSnWtrHkHOXLtRYgGseaI87E0BQ3CNR1bBYxgGbXCm4dLF70zGtzdn7GDFXIcaE IA6LkR0Sz2k7C7ZKKConoCLmDpa83UIF6JgA+8xWZ9OtVjf78xdYcYXapqqmp49v8gfL fEaA== X-Received: by 10.180.211.197 with SMTP id ne5mr14434260wic.54.1370294981060; Mon, 03 Jun 2013 14:29:41 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id w8sm26631386wiz.0.2013.06.03.14.29.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:29:40 -0700 (PDT) Message-ID: <51AD0AC2.2080001@jitsi.org> Date: Tue, 04 Jun 2013 00:29:38 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkkpxDGxzzYk+omR3JONyL8gAhYyhwz1wlGRwprMLgZOdYB0IMdMjkGksg4KDGmgoSpwbAL Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 21:35:44 -0000 Hey Eric, On 04.06.13, 00:07, Eric Rescorla wrote: > > On Mon, Jun 3, 2013 at 2:01 PM, Emil Ivov > wrote: > > (moving from rtcweb) > > Hey Eric, > > > On 03.06.13, 21:33, Eric Rescorla wrote: > > > On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov > >> wrote: > [...] > > III. Talking to other WebRTC applications > > This is the fun case and the one we should be most > concerned with. > Let's imagine that the answerer needs to add a fourth video > stream. > To make this work endpoints would need to do the following: > > a) with Plan A and draft-roach-rtcweb-glareless-____add: > > - send application specific signalling to the offerer > - have a new O/A exchange > > b) with Plan A: > - have a new O/A exchange > - potentially risk glare with some impact on user > experience > > c) with No Plan: > ... nothing > > > I'm really not following how this works in "No Plan". Ignoring > Plan A > and Plan B, can you just > walk through a complete example of what happens in your plan? > I.e., how > does browser > B learn learn that Browser A wants to send 3 streams instead of one? > > > It just gets three streams instead of one. It sees three new SSRCs > and it generates three new MediaStreams. > > > So, just for clarity: you mean that A advertises one m-lin, B accepts, > and then A sends some arbitrary number of media flows, Yes. > identified > by SSRC? What does "identified" mean? > If so, I've got some questions: > > - If B can only display one video stream, how does it say so? This is something that one app needs to tell another app. They can do so however they wish. As far as browsers are concerned: the transmitter just sends whatever the application instructs. The receiver just handles whatever it can. > - How does B tell A not to send various streams? What does "various" streams mean? If what you have in mind is: How does B tell A: "don't send me SSRCs 1, 2, 3 and 5" but keep 4 going, then B would send the list of SSRCs in app-specific signalling and A would stop sending them. > - How does B tell A to send one stream big and another stream small? Same as above. Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Mon Jun 3 14:40:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2711E810D for ; Mon, 3 Jun 2013 14:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxpByWjFSu1Q for ; Mon, 3 Jun 2013 14:39:57 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B011E810A for ; Mon, 3 Jun 2013 14:36:21 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id jn0g1l0050SCNGk56xcMbC; Mon, 03 Jun 2013 21:36:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id jxcL1l00d3ZTu2S3VxcLfe; Mon, 03 Jun 2013 21:36:21 +0000 Message-ID: <51AD0C53.7030406@alum.mit.edu> Date: Mon, 03 Jun 2013 17:36:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> In-Reply-To: <51AD0616.5040008@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370295381; bh=mNLSg+33yMYcHHRC4F01N2JzTHm2a/TDVgHXD8qyGLw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GVUw8VNoOjMqxOhDIWttfLUmAE1ITrhAwXzjdLSBladysuxO0WvGsqZyxGUjj2F4s 3I4yhRvRuaYzYx8W3JYahMtcQzqCoKp7HdBgvfxTbTnQpql5vB13GMVNqNa4IPaEwL aG91y9zZj5bHOjgoEjH2aoRahkGtidJ+V4aUQotug82NKM09zbUJdhtzfXmWY0OsAz RpDg97n/9FuZ++9D7wkOEwjwMeDVfGkv7SVNDoDu9wf281KAQNjBNUeTLee7RNycmT 9UdzOf2Hgy852AtWeTirjmQywX+QJDvvsr/4dJT/yyOVnFfO9yslgFsV0b/3dHYDWq H0Q+Kox0DJaXg== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] No Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 21:40:12 -0000 On 6/3/13 5:09 PM, Emil Ivov wrote: > Hey Paul, > > On 03.06.13, 23:37, Paul Kyzivat wrote: >> On 6/1/13 1:40 AM, Emil Ivov wrote: >>> >>> >>> On 31.05.13, 22:11, Paul Kyzivat wrote: >>>> On 5/31/13 6:51 AM, Emil Ivov wrote: >>>>> Hey Paul, >>>>> >>>>> On 29.05.13, 22:57, Paul Kyzivat wrote: >>>>>> Emil, >>>>>> >>>>>> I'm going to reserve judgment on this pending further discussion. >>>>>> I think this *might* work for CLUE, but I want to be certain. >>>>> >>>>> Sure! >>>>> >>>>>> I'm concerned with decomposed endpoints that can't manage all the >>>>>> streams on the same address/port. They will need multiple independent >>>>>> m-lines and/or bundle groups. >>>>> >>>>> This is obviously open for debate but the general idea of No Plan is >>>>> that: Offer/Answer is used for configuring media and RTP stacks and >>>>> additional signalling is not the browser's concern. >>>>> >>>>> Having extra m= lines, particularly when using BUNDLE, is in many ways >>>>> just extra signalling. >>>> >>>> You may be able to argue that adding extra m-lines into an existing >>>> bundle is "just extra signaling". But introducing an additional 5-tuple >>>> is more substantial. It requires configuring a new RTP stack and media. >>> >>> Indeed, this would require BUNDLE to work. >> >> I don't understand what that means - what point you are trying to make. > > Sorry about this. What I was trying to say was: yes, you are right, > introducing a new 5-tuple is more substantial. Therefore adding a new m= > line to an SDP is a lot simpler if it didn't also imply adding a new > 5-tuple. This would only be possible when m= lines are bundled. No. The problem arises without bundle. It gets more complex in combination with bundle. > This is > why I said: "Indeed, this would require BUNDLE to work." > > Is this clearer? Maybe not. Still some disconnect here. >> You seem to have some criterion for what requires sdp and what does not. >> And AFAIK you are already assuming bundle works - you are simply using >> it less. > > No, not really. The assumption is only necessary when trying to talk to > Plan A devices and you want to have new m= lines added en route. I thought you were assuming bundle what there to combine audio and video on a single 5-tuple. I don't think this need have anything to do with Plan A. > No such assumption is necessary, for example, when talking to legacy SIP > phones that will only show one video and one audio stream. Of course, in such a degenerate case where there is only one m-line for each media type, and only one stream per m-line. >> As best I can tell, you acknowledge that you need SDP to: >> - negotiate a 5-tuple over which media will flow >> - specify which types of media can be carried and the codec info >> they may use. > > Yes. > >> I'm just pointing out that for decomposed endpoints one 5-tuple may not >> be enough. And the need for this might not be known a priori. One side >> may be ready to add another stream for some purpose, and be willing/able >> to use private signaling to negotiate that. But the other side may not >> be able to handle that stream on the same 5-tuple. That in turn may >> result in a need to negotiate SDP changes to establish an additional >> 5-tuple that can then be used for that new stream. > > I think I see ... but not completely. Could you please post an SDP offer > with BUNDLE and the corresponding answer? The issue can be discussed without bundle, and without detailing the O/A. Assume we have had an O/A already between X and Y, with a single (video) m-line, resulting in a single 5-tuple. Over this we have a single audio RTP stream and mediaStreamtrack. The user of X interacts with the app, indicating a desire to receive another video stream from Y. This causes the app to trigger the JS in Y to set up another mediaStreamTrack. But the camera on Y has a separate IP address. So it is necessary to first set up another video m-line with the new address on Y's end. (X's end can use its single IP address.) Once that is done the new mediaStreamTrack can be established on the new m-line. How does this fit into No Plan? > (This might be a good point to move this to mmusic) Done. Thanks, Paul > Thanks, > Emil > > >>> >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> If you'd like for that signalling to be in SDP, I >>>>> don't see any problem with it. However it would be best for this extra >>>>> layer of SDP signalling to appear at either the application layer >>>>> or in >>>>> a signalling gateway (that is going to be there anyway). >>>>> >>>>> Does this make sense? >>>>> >>>>> Emil >>>>> >>>>>> >>>>>> Further questions: >>>>>> >>>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>>> per-m-line, with application specific signaling for bandwidth at the >>>>>> per-RTP-stream level? >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>>> Hey all, >>>>>>> >>>>>>> Based on many of the discussions that we've had here, as well as >>>>>>> many >>>>>>> others that we've had offlist, it seemed like a good idea to >>>>>>> investigate >>>>>>> a negotiation alternative that relies on SDP and Offer/Answer just a >>>>>>> little bit less. >>>>>>> >>>>>>> The following "no plan" draft attempts to present one such approach: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>>> >>>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>>> intricacies of multi-source scenarios to application-specific >>>>>>> signalling, with potentially a little help from RTP. >>>>>>> >>>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>>> interoperability requirements that concerned them can still be met >>>>>>> with >>>>>>> "no plan". Of course they would have to be addressed by >>>>>>> application-specific signalling and/or signalling gateways. >>>>>>> >>>>>>> Comments are welcome! >>>>>>> >>>>>>> Cheers, >>>>>>> Emil >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> . >>>>>> >>>>> >>>> >>>> . >>>> >>> >> >> > From emil@sip-communicator.org Mon Jun 3 14:49:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB5211E812D for ; Mon, 3 Jun 2013 14:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6ZT7SUQVWA6 for ; Mon, 3 Jun 2013 14:49:13 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2B82211E80F9 for ; Mon, 3 Jun 2013 14:47:04 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c50so1070042eek.11 for ; Mon, 03 Jun 2013 14:47:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=b1C9JGHw13ERdsNVBtRMn45TGfwCemgHAmdN0ziV6zI=; b=mYMvez4QaWVvuDqmyO4ILDEUAmA1+GeBVjIAUmOGhM8mh2MSOtuSBhd1G3tPc+57yp ev7OtlyjihaZ8CCH6SUeEjKIqJQTSGeUNl/ynxqYbdjMca8VcFyoQy+F5HYswlSfg9OL UXRsqOr40c+T1zUPNep93ibeaSWmpE4Di9NbtsX0TDZYHk2xD+e7EYKcVHzez7A6IFG+ MGvsi+i1ibVPCSGOPL/zG/exBJ93L1ZCt5v4m3YI+llxKoP9O5HVV5cZee8Gli9jljVm VDFKAXoMvCEhEq/8F68euOAxziIs+MWrvUnCPfkptHG1ucYAmxeOdt4+D76ytUIoL749 EvXQ== X-Received: by 10.14.88.130 with SMTP id a2mr24384408eef.53.1370296023196; Mon, 03 Jun 2013 14:47:03 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id b14sm16672088ees.16.2013.06.03.14.47.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:47:02 -0700 (PDT) Message-ID: <51AD0ED4.1010208@jitsi.org> Date: Tue, 04 Jun 2013 00:47:00 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <9D1E0FD6-9AC4-425E-8DC2-E22BC7040B61@iii.ca> In-Reply-To: <9D1E0FD6-9AC4-425E-8DC2-E22BC7040B61@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm/HbXTYSPK4QtH6VW4C/tOB3ekeZ0MEaSElF9m1xTbARDtmi2+DrTT2CbcuEXWr+6i8iFB Cc: mmusic WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 21:49:23 -0000 On 03.06.13, 23:06, Cullen Jennings wrote: > > On Jun 3, 2013, at 11:28 AM, Emil Ivov wrote: > >> An offer generated by a "No Plan" browser in this case would look something like this: >> >> v=0 >> o=- 20518 0 IN IP4 198.51.100.1 >> s= >> t=0 0 >> c=IN IP4 203.0.113.1 >> a=ice-ufrag:F7gI >> a=ice-pwd:x9cml/YzichV2+XlhiMu8g >> a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >> a=group:BUNDLE m0 m1 >> >> m=audio 56600 RTP/SAVPF 96 0 >> a=mid:m0 >> a=rtpmap:96 opus/48000 >> a=rtpmap:0 PCMU/8000 >> a=ptime:20 >> a=sendrecv >> a=rtcp-mux >> [ICE candidates] >> >> m=video 56602 RTP/SAVPF 97 98 >> a=mid:m1 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=4d0028;packetization-mode=1 >> a=rtpmap:98 VP8/90000 >> a=sendrecv >> a=rtcp-mux >> [ICE candidates] > > In no-plan, What would the answer look like if you were receiving 2 video stream? It would look like the above. Additional application-specific signalling would also say something like this: { "firstStream": { "SSRC": "11111", "accept": "false" }, "secondStream": { "SSRC": "22222", "accept": "true" }, "thirdStream": { "SSRC": "333333", "accept": "true" }, } Emil -- https://jitsi.org From emil@sip-communicator.org Mon Jun 3 15:28:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E206011E8123 for ; Mon, 3 Jun 2013 15:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTQcgrYLEaQw for ; Mon, 3 Jun 2013 15:28:26 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9313A21E808D for ; Mon, 3 Jun 2013 15:18:03 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id h15so1741471eak.0 for ; Mon, 03 Jun 2013 15:18:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=yNS3OEPo4fw4nmVyI79Mu8VHkwWsty8J4fm0B3SeOKQ=; b=j3Rp0fSXuik8xAF2z5Jb6gHKzgF1WjhhAskxDDqwEg7PelQfIhuaVhehrwj1ODLlAd 4AuDW7YBD25BClinqIXYbKnelXKb+AFPcsSrrGBFl0UDUbRbfmo+73JsYu72MPEOznWr JU7uVXAiHpOdlJ3FhZbdqkV6Dnnux+EOALvFcUCYP1B7gXdBy0uUT18F/c6EE/MadA8G t010mblJDzOkWXbzgoDpUW1fsb94fIDYsRYr8D+R2BKTygupC8aGJZsqKfjxua4MRNR9 rcRN3mW/j1ujrDeXOry116lhiJgpyrcf9YYmNIMwAx0TFNPazqVd0mugreiWfteanq93 uJIg== X-Received: by 10.14.5.5 with SMTP id 5mr24740023eek.21.1370297882329; Mon, 03 Jun 2013 15:18:02 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id s43sm87486878eem.13.2013.06.03.15.18.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 15:18:01 -0700 (PDT) Message-ID: <51AD1617.9020501@jitsi.org> Date: Tue, 04 Jun 2013 01:17:59 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> <51AD0C53.7030406@alum.mit.edu> In-Reply-To: <51AD0C53.7030406@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmzFMqQDt6p3kVi1DJPQldEEXDGnMBn09sIgjaRCDWUo9YKQdihocx4TufczgGfxG2J7zVT Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] No Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2013 22:28:38 -0000 Hey Paul, On 04.06.13, 00:36, Paul Kyzivat wrote: > On 6/3/13 5:09 PM, Emil Ivov wrote: >> Hey Paul, >> >> On 03.06.13, 23:37, Paul Kyzivat wrote: >>> On 6/1/13 1:40 AM, Emil Ivov wrote: >>>> >>>> >>>> On 31.05.13, 22:11, Paul Kyzivat wrote: >>>>> On 5/31/13 6:51 AM, Emil Ivov wrote: >>>>>> Hey Paul, >>>>>> >>>>>> On 29.05.13, 22:57, Paul Kyzivat wrote: >>>>>>> Emil, >>>>>>> >>>>>>> I'm going to reserve judgment on this pending further discussion. >>>>>>> I think this *might* work for CLUE, but I want to be certain. >>>>>> >>>>>> Sure! >>>>>> >>>>>>> I'm concerned with decomposed endpoints that can't manage all the >>>>>>> streams on the same address/port. They will need multiple independent >>>>>>> m-lines and/or bundle groups. >>>>>> >>>>>> This is obviously open for debate but the general idea of No Plan is >>>>>> that: Offer/Answer is used for configuring media and RTP stacks and >>>>>> additional signalling is not the browser's concern. >>>>>> >>>>>> Having extra m= lines, particularly when using BUNDLE, is in many ways >>>>>> just extra signalling. >>>>> >>>>> You may be able to argue that adding extra m-lines into an existing >>>>> bundle is "just extra signaling". But introducing an additional 5-tuple >>>>> is more substantial. It requires configuring a new RTP stack and media. >>>> >>>> Indeed, this would require BUNDLE to work. >>> >>> I don't understand what that means - what point you are trying to make. >> >> Sorry about this. What I was trying to say was: yes, you are right, >> introducing a new 5-tuple is more substantial. Therefore adding a new m= >> line to an SDP is a lot simpler if it didn't also imply adding a new >> 5-tuple. This would only be possible when m= lines are bundled. > > No. The problem arises without bundle. It gets more complex in > combination with bundle. > >> This is >> why I said: "Indeed, this would require BUNDLE to work." >> >> Is this clearer? > > Maybe not. Still some disconnect here. > >>> You seem to have some criterion for what requires sdp and what does not. >>> And AFAIK you are already assuming bundle works - you are simply using >>> it less. >> >> No, not really. The assumption is only necessary when trying to talk to >> Plan A devices and you want to have new m= lines added en route. > > I thought you were assuming bundle what there to combine audio and video > on a single 5-tuple. I don't think this need have anything to do with > Plan A. > >> No such assumption is necessary, for example, when talking to legacy SIP >> phones that will only show one video and one audio stream. > > Of course, in such a degenerate case where there is only one m-line for > each media type, and only one stream per m-line. > >>> As best I can tell, you acknowledge that you need SDP to: >>> - negotiate a 5-tuple over which media will flow >>> - specify which types of media can be carried and the codec info >>> they may use. >> >> Yes. >> >>> I'm just pointing out that for decomposed endpoints one 5-tuple may not >>> be enough. And the need for this might not be known a priori. One side >>> may be ready to add another stream for some purpose, and be willing/able >>> to use private signaling to negotiate that. But the other side may not >>> be able to handle that stream on the same 5-tuple. That in turn may >>> result in a need to negotiate SDP changes to establish an additional >>> 5-tuple that can then be used for that new stream. >> >> I think I see ... but not completely. Could you please post an SDP offer >> with BUNDLE and the corresponding answer? > > The issue can be discussed without bundle, and without detailing the O/A. We can certainly try. I am not sure if I am following though. Let's see: > Assume we have had an O/A already between X and Y, with a single (video) > m-line, resulting in a single 5-tuple. Over this we have a single audio > RTP stream and mediaStreamtrack. > > The user of X interacts with the app, indicating a desire to receive > another video stream from Y. This causes the app to trigger the JS in Y > to set up another mediaStreamTrack. But the camera on Y has a separate > IP address. So it is necessary to first set up another video m-line with > the new address on Y's end. (X's end can use its single IP address.) This is the part that I can't quite picture. How can Y's camera be on a separate IP, but still appear as a regular device to Y's javascript and still generate a regular stream track? All this with a generic browser? Wouldn't it be much more likely that such a separate camera will be controlled by a proprietary interface that is not directly related to WebRTC? If so, then the additional signalling for this camera would obviously need to be generated by Y's javascript (i.e. not the browser). That additional signalling can then be merged into the one from Y's browser by Y's JS or a gateway. X would indeed need to handle an offer with two video m= lines at that point, but that's because they would negotiate different 5-tuples. So this is fine. Another option would be to handle the new camera with an independent Offer/Answer that would yield a new PeerConnection. I don't know if that works for your case but I thought I'd mention it. In this case any additional information required for the synchronization of the two peer connections would be exchanged in an app-specific way. Cheers, Emil > Once that is done the new mediaStreamTrack can be established on the new > m-line. > > How does this fit into No Plan? > >> (This might be a good point to move this to mmusic) > > Done. Thanks, Emil > > Thanks, > Paul > >> Thanks, >> Emil >> >> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> If you'd like for that signalling to be in SDP, I >>>>>> don't see any problem with it. However it would be best for this extra >>>>>> layer of SDP signalling to appear at either the application layer >>>>>> or in >>>>>> a signalling gateway (that is going to be there anyway). >>>>>> >>>>>> Does this make sense? >>>>>> >>>>>> Emil >>>>>> >>>>>>> >>>>>>> Further questions: >>>>>>> >>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>>>> per-m-line, with application specific signaling for bandwidth at the >>>>>>> per-RTP-stream level? >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>>>> Hey all, >>>>>>>> >>>>>>>> Based on many of the discussions that we've had here, as well as >>>>>>>> many >>>>>>>> others that we've had offlist, it seemed like a good idea to >>>>>>>> investigate >>>>>>>> a negotiation alternative that relies on SDP and Offer/Answer just a >>>>>>>> little bit less. >>>>>>>> >>>>>>>> The following "no plan" draft attempts to present one such approach: >>>>>>>> >>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>>>> >>>>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>>>> intricacies of multi-source scenarios to application-specific >>>>>>>> signalling, with potentially a little help from RTP. >>>>>>>> >>>>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>>>> interoperability requirements that concerned them can still be met >>>>>>>> with >>>>>>>> "no plan". Of course they would have to be addressed by >>>>>>>> application-specific signalling and/or signalling gateways. >>>>>>>> >>>>>>>> Comments are welcome! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Emil >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> . >>>>> >>>> >>> >>> >> > > -- https://jitsi.org From ekr@rtfm.com Mon Jun 3 18:30:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA021F9983 for ; Mon, 3 Jun 2013 18:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.811 X-Spam-Level: X-Spam-Status: No, score=-100.811 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoTSD8P3OdyG for ; Mon, 3 Jun 2013 18:30:22 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A421E80C7 for ; Mon, 3 Jun 2013 17:48:05 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id q19so2841904qeb.32 for ; Mon, 03 Jun 2013 17:48:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=dR5E2Gv1La/VzayboyisiPvJsbriW0PABFBoJDjQLHw=; b=j2eL1eAmm3sgsFlo3p/VbB9IUajUOmK7xMBgouvCcuJGlmFDmwtU6nm+wpsRudN5to W0JRUCmq2waVG2gKxGlZBC3LLh3jDJwskz/LIxg7ssWDHP2h2+FvattJfvAiL4wPYnfi rWrKu6Mk/Tht0JqRp89KvVnob4mGlOCACsKGwouo6cBMPDXEXcGiuTZhBpvN2zwdlJeU c6iBSxdlRh+gZEONagL10x79M1EvpDdjI8sUo2tyT9QqbMzx96Z9C2XyYHeNRJMts/D0 L4qmcFWoCoJ071dvw9+pjBv8egMAnLJz/AUT7LNHHexQC5EhFMtLGOAReFiJrSNAaIBp 1cew== X-Received: by 10.224.71.145 with SMTP id h17mr21614122qaj.31.1370306885406; Mon, 03 Jun 2013 17:48:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Mon, 3 Jun 2013 17:47:25 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <51AD0AC2.2080001@jitsi.org> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> <51AD0AC2.2080001@jitsi.org> From: Eric Rescorla Date: Mon, 3 Jun 2013 17:47:25 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7bea317423624f04de496fd4 X-Gm-Message-State: ALoCoQnF1giMlXo9wbD4LO+PcbKwUt3o/Xvd2p4B8J1NJzIE9POhcwQegY36WFKGYnQHdtMTlPgq Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:30:37 -0000 --047d7bea317423624f04de496fd4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov wrote: > Hey Eric, > > > On 04.06.13, 00:07, Eric Rescorla wrote: > >> >> On Mon, Jun 3, 2013 at 2:01 PM, Emil Ivov > > wrote: >> >> (moving from rtcweb) >> >> Hey Eric, >> >> >> On 03.06.13, 21:33, Eric Rescorla wrote: >> >> >> On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov > >> >> wrote: >> [...] >> >> III. Talking to other WebRTC applications >> >> This is the fun case and the one we should be most >> concerned with. >> Let's imagine that the answerer needs to add a fourth video >> stream. >> To make this work endpoints would need to do the following: >> >> a) with Plan A and draft-roach-rtcweb-glareless-_**___add: >> >> >> - send application specific signalling to the offerer >> - have a new O/A exchange >> >> b) with Plan A: >> - have a new O/A exchange >> - potentially risk glare with some impact on user >> experience >> >> c) with No Plan: >> ... nothing >> >> >> I'm really not following how this works in "No Plan". Ignoring >> Plan A >> and Plan B, can you just >> walk through a complete example of what happens in your plan? >> I.e., how >> does browser >> B learn learn that Browser A wants to send 3 streams instead of >> one? >> >> >> It just gets three streams instead of one. It sees three new SSRCs >> and it generates three new MediaStreams. >> >> >> So, just for clarity: you mean that A advertises one m-lin, B accepts, >> and then A sends some arbitrary number of media flows, >> > > Yes. > > identified >> by SSRC? >> > > What does "identified" mean? I mean demultiplexed by SSRC. If so, I've got some questions: >> >> - If B can only display one video stream, how does it say so? >> > > This is something that one app needs to tell another app. They can do so > however they wish. As far as browsers are concerned: the transmitter just > sends whatever the application instructs. The receiver just handles > whatever it can. But there needs to be a complete set of API surfaces that allow both sides to do the right thing. - How does B tell A not to send various streams? >> > > What does "various" streams mean? If what you have in mind is: How does B > tell A: "don't send me SSRCs 1, 2, 3 and 5" but keep 4 going, then B would > send the list of SSRCs in app-specific signalling and A would stop sending > them. Uh, how does that work? Is there some API that I'm unaware of that allows JS to get the SSRCs? And another one that allows the JS to say "don't send SSRC A"? It would be really helpful if you could provide a complete example of exactly what each side does. I'm find if you just invent some application-specific signaling for this purpose, but what I'd like to see is exactly what API calls each side makes. -Ekr --047d7bea317423624f04de496fd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey Eric,


On 04.06.13, 00:07, Eric Rescorla wrote:

On Mon, Jun 3, 2013 at 2:01 PM, Emil Ivov <emcho@jitsi.org
<mailto:emcho@jitsi= .org>> wrote:

=A0 =A0 (moving from rtcweb)

=A0 =A0 Hey Eric,


=A0 =A0 On 03.06.13, 21:33, Eric Rescorla wrote:


=A0 =A0 =A0 =A0 On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov <emcho@jitsi.org
=A0 =A0 =A0 =A0 <mailto:emcho@jitsi.org>
=A0 =A0 =A0 =A0 <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
=A0 =A0 =A0 =A0 [...]

=A0 =A0 =A0 =A0 =A0 =A0 =A0III. Talking to other WebRTC applications

=A0 =A0 =A0 =A0 =A0 =A0 =A0This is the fun case and the one we should be mo= st
=A0 =A0 =A0 =A0 concerned with.
=A0 =A0 =A0 =A0 =A0 =A0 =A0Let's imagine that the answerer needs to add= a fourth video
=A0 =A0 =A0 =A0 stream.
=A0 =A0 =A0 =A0 =A0 =A0 =A0To make this work endpoints would need to do the= following:

=A0 =A0 =A0 =A0 =A0 =A0 =A0a) with Plan A and draft-roach-rtcweb-glareless-= ____add:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- send application specific signalling t= o the offerer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- have a new O/A exchange

=A0 =A0 =A0 =A0 =A0 =A0 =A0b) with Plan A:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- have a new O/A exchange
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- potentially risk glare with some impac= t on user
=A0 =A0 =A0 =A0 experience

=A0 =A0 =A0 =A0 =A0 =A0 =A0c) with No Plan:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... nothing


=A0 =A0 =A0 =A0 I'm really not following how this works in "No Pla= n". Ignoring
=A0 =A0 =A0 =A0 Plan A
=A0 =A0 =A0 =A0 and Plan B, can you just
=A0 =A0 =A0 =A0 walk through a complete example of what happens in your pla= n?
=A0 =A0 =A0 =A0 I.e., how
=A0 =A0 =A0 =A0 does browser
=A0 =A0 =A0 =A0 B learn learn that Browser A wants to send 3 streams instea= d of one?


=A0 =A0 It just gets three streams instead of one. It sees three new SSRCs<= br> =A0 =A0 and it generates three new MediaStreams.


So, just for clarity: you mean that A advertises one m-lin, B accepts,
and then A sends some arbitrary number of media flows,

Yes.

identified
by SSRC?

What does "identified" mean?

I mean demultiplexed by SSRC.
=A0


If so, I've got some questions:

- If B can only display one video stream, how does it say so?

This is something that one app needs to tell another app. They can do so ho= wever they wish. As far as browsers are concerned: the transmitter just sen= ds whatever the application instructs. The receiver just handles whatever i= t can.

But there needs to be a complete set of API surfa= ces that allow
both sides to do the right thing.




- How does B tell A not to send various streams?

What does "various" streams mean? If what you have in mind is: Ho= w does B tell A: "don't send me SSRCs 1, 2, 3 and 5" but keep= 4 going, then B would send the list of SSRCs in app-specific signalling an= d A would stop sending them.

Uh, how does that work? Is there some API that I&= #39;m unaware of that
allows JS to get the SSRCs? And anoth= er one that allows the JS
to say "don't send SSRC = A"?

It would be really helpful if you could pro= vide a complete example of
exactly what each side does. I&#= 39;m find if you just invent some application-specific
signaling for this purpose, but what I'd like to see is exactly what AP= I
calls each side makes.

-Ekr



--047d7bea317423624f04de496fd4-- From christer.holmberg@ericsson.com Tue Jun 4 01:31:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0A821F9B5B for ; Tue, 4 Jun 2013 01:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTrItVwo+OPo for ; Tue, 4 Jun 2013 01:31:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0421E810B for ; Tue, 4 Jun 2013 00:28:07 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-2a-51ad9707c265 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.36.09795.7079DA15; Tue, 4 Jun 2013 09:28:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 09:28:06 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgioAlxfJgAAbOWHA Date: Tue, 4 Jun 2013 07:28:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> <51ACFB79.1080207@alum.mit.edu> In-Reply-To: <51ACFB79.1080207@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrS779LWBBrPP8VpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGqo2rmQvOSFRMv9LJ0sC4W7iLkZNDQsBE YuLmG8wQtpjEhXvr2boYuTiEBA4zSmzasoIdwlnMKHH96magKg4ONgELie5/2iCmiICGxKSt aiAms4C6xNXFQSBjhAV0JU7ufsQEYosI6El8vnWfGcJ2k5jcOYERxGYRUJFYN7cTrIZXwFfi 8YFNUGsvM0rMmveOFSTBKaAjcbTtFBuIzQh02/dTa8AamAXEJW49mc8EcbOAxJI956HuF5V4 +fgfK8g9EgKKEsv75SDKdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrNQjJ1FpKWWUhaZiFp WcDIsoqRPTcxMye93HwTIzA+Dm75bbCDcdN9sUOM0hwsSuK8+ryLA4UE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwll7t2qeh9leYszIg+sFktTW7o99N6/3MvcJpU1DzoqMC1qYJ1+eXtVW2 L2LKvPidY6Ff7F1PCU6951k/y7ut+CQZxRpsThsp6y8p6ZkhemSZsKHFoSXb35zRkyllsFkl 5xTy302lWyP1YWSwY77Nu0nmxhzTOZ/UmwSeuhl4ZkegJAPzhXtKLMUZiYZazEXFiQCyl+Kc XQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 08:31:35 -0000 Hi, >>>> I'll throw the ball out with suggesting the following ones: >>>> >>>> -*Bundle restart offer* (different port value, currently referred to=20 >>>> as "first offer") >>>> >>>> The reason I use "restart" wording is because this is used, no=20 >>>> matter whether in the beginning of the session or mid-session, to=20 >>>> (re-)negotiate the usage of BUNDLE, and the bundle address=20 >>>> information selection. >>>> >>>> -*Bundle sync offer* (identical port value, currently referred to as=20 >>>> "second offer") >>>> >>>> The reason I used "sync" wording is because this is used to ensure=20 >>>> that intermediaries have correct address information for each m- line. >>>> >>>> Keep in mind that we may even need to split the sync offer into more=20 >>>> sub types, when we get into the details of adding new m- lines etc,=20 >>>> but I'd like to agree a base to start from :) >>> >>> Above seems like a good start, but I'm still grappling with some=20 >>> things and don't know how to talk about concisely: >>> >>> I understand that the next offer after a Bundle Restart Offer will=20 >>> typically be a Bundle Sync Offer. But if there is another offer after=20 >>> a Bundle Sync Offer, and it doesn't change anything about the bundle,=20 >>> then is it still a Bundle Sync Offer? >> >> Currently, yes. > > I agree that without adjusting the terminology this is the only right cho= ice to make. But it is a little obscure. I'm not certain this needs to be i= mproved, but I thought I would suggest that it might. >> >>> Also, I don't believe the above are mutually exclusive. If I send an=20 >>> offer to add a new m-line to a bundle, and I give it distinct address=20 >>> info so that the answerer may take it out of the bundle if needed,=20 >>> then is that a Bundle Restart Offer or a Bundle Sync Offer? It seems=20 >>> to be a bit of each. And of course there may be multiple bundles=20 >>> described by the SDP, and these terms apply independently to each. >>> >>> Maybe we need a couple more terms for: >>> >>> - offer that adds a new m-line to bundle using the existing bundle >>> address info. >> >> Technically that is a Bundle Sync Offer, but I DO agree that the wording= is not good in this case - as it's not only about synchronization. >> >>> - offer that adds a new m-line to an existing bundle using unique >>> address info. >> >> I agree that doesn't fit the current definitions. >> >> However, we will have to agree on whether we allow that in the first pla= ce, or whether the offerer will have to use 1) same address information or = 2) different address information for ALL m- lines (Bundle Restart Offer). > > Yes, we need to settle on whether either or both of these are permitted. > > But I can think of reasons why I might wish to use either one, and no goo= d reason not to allow both. So allowing both is my preference. I personally think we should allow BOTH 1) and 2). The question is whether we should allow 3), which is new m- line with uniqu= e address, while the other m- lines use the bundle address. Regards, Christer From emil@sip-communicator.org Tue Jun 4 02:35:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F74321F9948 for ; Tue, 4 Jun 2013 02:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtTUyGvp3th9 for ; Tue, 4 Jun 2013 02:35:34 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16E21F854D for ; Tue, 4 Jun 2013 01:28:49 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c41so319017eek.12 for ; Tue, 04 Jun 2013 01:28:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ufoThziTFTKErx1Tx2+m4Gc7ygyoJoCY95p4NVdVPzQ=; b=YCllKQsWj7XcV2jtr6hxaBEPMoj8e/wZaNHK55leTIEbJFxuegDuSCmb+77RgoL+RF /Cb3JzXrYzajtmlQbhfidA4UgYajDeL+CU68vRhf9z25rg69RSVe1Lsjwoxgnsxwkqd1 MiCkkYtbyZJJTwiVlGgyEEgP7DRp6x+eME+h2z3D3k2excXhfzhHcEyID5JRenny46C8 MVvbmm/nsUEDrpbJVLyNdCcvasnFco363ymToxIecumC/Kq+kNx6O54nIgoYDow5QqDD Vxp8ZyImoSjT7I61JV9WLl3uEOlcU0oGWkjwYJaP03sU/qy7z9P7dYXx0ZvHwCbFBPYz oBIg== X-Received: by 10.15.99.66 with SMTP id bk42mr25653843eeb.60.1370334528337; Tue, 04 Jun 2013 01:28:48 -0700 (PDT) Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id z52sm90078982eea.1.2013.06.04.01.28.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 01:28:47 -0700 (PDT) Message-ID: <51ADA539.1020505@jitsi.org> Date: Tue, 04 Jun 2013 11:28:41 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> <51AD0AC2.2080001@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnpbj+wJyq2d/FEX/Ef7/LA66Uhy2H7IKNj5W1mvyXG7dZ3am7eDQGuy7HZuFmBEx2W/yAX Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 09:35:48 -0000 Hey Eric, On 04.06.13, 03:47, Eric Rescorla wrote: > On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov wrote: > So, just for clarity: you mean that A advertises one m-lin, B > accepts, > and then A sends some arbitrary number of media flows, > > > Yes. > > identified > by SSRC? > > > What does "identified" mean? > > > I mean demultiplexed by SSRC. Demuxing by SSRC, as in being able to distinguish one RTP stream from another is totally OK and there's no issue with this in No Plan. SSRCs will be different and packets will be assigned to different media streams. What isn't OK is the need to know specific SSRC values in order to perform the demuxing. This is not necessary for demuxing with No Plan. Do you agree? > If so, I've got some questions: > > - If B can only display one video stream, how does it say so? > > > This is something that one app needs to tell another app. They can > do so however they wish. As far as browsers are concerned: the > transmitter just sends whatever the application instructs. The > receiver just handles whatever it can. > > > But there needs to be a complete set of API surfaces that allow > both sides to do the right thing. Yes, hence section 7 in No Plan: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan-00#section-7 > - How does B tell A not to send various streams? > > > What does "various" streams mean? If what you have in mind is: How > does B tell A: "don't send me SSRCs 1, 2, 3 and 5" but keep 4 going, > then B would send the list of SSRCs in app-specific signalling and A > would stop sending them. > > > Uh, how does that work? Is there some API that I'm unaware of that > allows JS to get the SSRCs? I don't think there is. I believe you can get part of the information through the stats API but I don't think this is enough. Hence Section 7. > And another one that allows the JS > to say "don't send SSRC A"? As long as the JS knows the SSRC of a specific track it can just disable that specific track. There's no need to tell the browser "don't send SSRC A". > It would be really helpful if you could provide a complete example of > exactly what each side does. I'm find if you just invent some > application-specific > signaling for this purpose, but what I'd like to see is exactly what API > calls each side makes. Does the above answer your question, or would you like me to come up with an example of how these new APIs could look? Emil > > -Ekr > > > -- https://jitsi.org From christer.holmberg@ericsson.com Tue Jun 4 06:25:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2392721F9CB2 for ; Tue, 4 Jun 2013 06:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDtLWGcNawbl for ; Tue, 4 Jun 2013 06:24:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1D21F9C4A for ; Tue, 4 Jun 2013 04:53:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-d6-51add51e79fb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 76.D3.15700.E15DDA15; Tue, 4 Jun 2013 13:53:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 13:53:02 +0200 From: Christer Holmberg To: Paul Kyzivat , Emil Ivov Thread-Topic: [rtcweb] Translating Plan A into No Plan (Was: No Plan) Thread-Index: AQHOYKCLf/LJiFWy5UGn9OZbviAeCZkkYgWAgAAChQCAAQ10MA== Date: Tue, 4 Jun 2013 11:53:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3826F4@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD07B4.3070702@alum.mit.edu> <51AD0C5B.6080508@jitsi.org> <51AD0E78.8050100@alum.mit.edu> In-Reply-To: <51AD0E78.8050100@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvra7c1bWBBl2nLS3W7JzAYtExmc1i 6vLHLBYrNhxgdWDx+Pv+A5PHlN8bWT2WLPnJ5PH/TWAASxSXTUpqTmZZapG+XQJXxr+NFxkL XlhWPL+4hrGB8b92FyMnh4SAicTJq5+ZIGwxiQv31rN1MXJxCAkcZpQ4f3QLM4SzmFHi59St QFUcHGwCFhLd/7RBTBEBV4l5zxRBepkFIiTm797KDhIWFnCR2DcdbCRIxe6Px6BsJ4l1T34z gpSwCKhIfFnrChLmFfCVmHj5NNTWLmaJI/t62EESnAI6EruftLOB2IxAp30/tYYJYpW4xK0n 86FOFpBYsuc8M4QtKvHy8T9WkPkSAooSy/vlIMp1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYw is1CMnUWkpZZSFpmIWlZwMiyipE9NzEzJ73ccBMjMIIObvmtu4Px1DmRQ4zSHCxK4rx6vIsD hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBGqO3fqn+hfltkTOHeCb4xe09zpJrZO1VZ/qms rBfgWrdPJbRLhVc0g8VaTNSV5Yh2Str2ldXckgsP+2l/e8LZePFQ7qEZvbvrX7244WV1tWve I+0K8c+L+xtzvwTn3mKwm1wYoXJs3tx1wXsmbe67rT3bYVPS0XSGG/dkl29VltQpqt22KFOJ pTgj0VCLuag4EQC6M6kebgIAAA== Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:25:10 -0000 Hi, >>> I don't understand why we would be talking about translating from one=20 >>> of these plans to another. AFAIK they are *alternatives*, and that we=20 >>> will at some point agree on one, and that will be the only one implemen= ted. >> >> It has been pointed out that some existing non-WebRTC endpoints expect=20 >> to get SDP "the Plan A way". Cullen asked how such devices could be=20 >> made to communicate with "No Plan" browsers. This was my answer. >> >> Personally I haven't come across such devices so I can only speculate=20 >> about the reasons why they work the way they work. Still I don't see=20 >> why they shouldn't be able to talk to WebRTC browsers ... hence my answe= r. > > They clearly *don'* expect to get it the Plan A way (bundled). > > > I accept that there must be a variety of things that employ multiple > (unbundled) m-lines, each on its own 5-tuple with one RTP stream. I asked about that in a separate thread, but nobody replied, so I'll ask ag= ain :) If the JS app receives multiple unbundled m- lines on the wire, does the JS= app have to "convert" it into whatever Plan/Format supported by the API? Regards, Christer >> On 6/3/13 1:28 PM, Emil Ivov wrote: >>> Hey Cullen, Paul, all >>> >>> On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote: >>>> On 31.05.2013, at 12:23 PM, Emil Ivov wrote: >>>> >>>>> Certainly. Could you please post the SDP that you would like to=20 >>>>> see translated in a way that's compatible with "No Plan"? >>>>> >>>>> Emil >>>> >>>> We can start with the SDP in plan A >>> >>> The example in "7.3. Many Videos" looks like a good start: >>> >>> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3 >>> >>> Here it is: >>> >>> v=3D0 >>> o=3D- 20518 0 IN IP4 198.51.100.1 >>> s=3D >>> t=3D0 0 >>> c=3DIN IP4 203.0.113.1 >>> a=3Dice-ufrag:F7gI >>> a=3Dice-pwd:x9cml/YzichV2+XlhiMu8g >>> a=3Dfingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >>> a=3Dgroup:BUNDLE m0 m1 m2 m3 >>> >>> m=3Daudio 56600 RTP/SAVPF 0 96 >>> a=3Dmid:m0 >>> a=3Drtpmap:0 PCMU/8000 >>> a=3Drtpmap:96 opus/48000 >>> a=3Dptime:20 >>> a=3Dsendrecv >>> a=3Drtcp-mux >>> [ICE Candidates] >>> >>> m=3Dvideo 0 RTP/SAVPF 97 98 >>> a=3Dmid:m1 >>> a=3Drtpmap:97 H264/90000 >>> a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1 >>> a=3Drtpmap:98 VP8/90000 >>> a=3Dsendrecv >>> a=3Drtcp-mux >>> a=3Dbundle-only >>> a=3Dssrc:11111 cname:45:5f:fe:cb:81:e9 >>> >>> m=3Dvideo 0 RTP/SAVPF 97 98 >>> a=3Dmid:m2 >>> a=3Drtpmap:97 H264/90000 >>> a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1 >>> a=3Drtpmap:98 VP8/90000 >>> a=3Dsendrecv >>> a=3Drtcp-mux >>> a=3Dbundle-only >>> a=3Dssrc:22222 cname:45:5f:fe:cb:81:e9 >>> >>> m=3Dvideo 0 RTP/SAVPF 97 98 >>> a=3Dmid:m3 >>> a=3Drtpmap:97 H264/90000 >>> a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1 >>> a=3Drtpmap:98 VP8/90000 >>> a=3Dsendrecv >>> a=3Drtcp-mux >>> a=3Dbundle-only >>> a=3Dssrc:333333 cname:45:5f:fe:cb:81:e9 >>> >>> >>> An offer generated by a "No Plan" browser in this case would look=20 >>> something like this: >>> >>> v=3D0 >>> o=3D- 20518 0 IN IP4 198.51.100.1 >>> s=3D >>> t=3D0 0 >>> c=3DIN IP4 203.0.113.1 >>> a=3Dice-ufrag:F7gI >>> a=3Dice-pwd:x9cml/YzichV2+XlhiMu8g >>> a=3Dfingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7 >>> a=3Dgroup:BUNDLE m0 m1 >>> >>> m=3Daudio 56600 RTP/SAVPF 96 0 >>> a=3Dmid:m0 >>> a=3Drtpmap:96 opus/48000 >>> a=3Drtpmap:0 PCMU/8000 >>> a=3Dptime:20 >>> a=3Dsendrecv >>> a=3Drtcp-mux >>> [ICE candidates] >>> >>> m=3Dvideo 56602 RTP/SAVPF 97 98 >>> a=3Dmid:m1 >>> a=3Drtpmap:97 H264/90000 >>> a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1 >>> a=3Drtpmap:98 VP8/90000 >>> a=3Dsendrecv >>> a=3Drtcp-mux >>> [ICE candidates] >>> >>> I. Talking to legacy >>> >>> In case you need to talk to an actual legacy (as in widely deployed=20 >>> SIP) endpoint, the above would translate into a regular two-stream=20 >>> call. Both Plan A and No Plan would lead to essentially the same=20 >>> result (if we accept that older endpoints won't throw an exception=20 >>> at the sight of 4 m=3D lines) so not much to discuss here. >>> >>> II. Talking to Plan A style endpoints >>> >>> If you need to talk to a Plan A endpoint you basically have the=20 >>> following options: >>> >>> 1. You use JavaScript to prettify the "No Plan" SDP and turn it into=20 >>> something that looks like "Plan A". Not my favourite option, but I=20 >>> am sure some would like to use it. Maybe vendors of Plan A equipment=20 >>> would even distribute JS libs that do this. It would basically all=20 >>> come down to generating one ssrc attribute and two additional=20 >>> m=3Dlines and appending this to the existing SDP string. >>> >>> 2. The application retrieves SSRCs from the browser, adds additional=20 >>> application-specific signalling to it and then sends the whole thing=20 >>> to a signalling gateway. The gateway (which you would also have with=20 >>> Plan >>> A) would convert the SDP into what it needs it to be. >>> >>> The application specific signalling can look like this: >>> >>> { >>> "firstStream": >>> { >>> "SSRC": "11111", >>> "CNAME": "45:5f:fe:cb:81:e9" >>> }, >>> "secondStream": >>> { >>> "SSRC": "22222", >>> "CNAME": "45:5f:fe:cb:81:e9" >>> }, >>> "thirdStream": >>> { >>> "SSRC": "333333", >>> "CNAME": "45:5f:fe:cb:81:e9" >>> }, >>> } >>> >>> 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP=20 >>> with the help of .content properties. If browser vendors are willing=20 >>> to implement support for this then I suppose it would be a third option= . >>> >>> III. Talking to other WebRTC applications >>> >>> This is the fun case and the one we should be most concerned with.=20 >>> Let's imagine that the answerer needs to add a fourth video stream.=20 >>> To make this work endpoints would need to do the following: >>> >>> a) with Plan A and draft-roach-rtcweb-glareless-add: >>> - send application specific signalling to the offerer >>> - have a new O/A exchange >>> >>> b) with Plan A: >>> - have a new O/A exchange >>> - potentially risk glare with some impact on user experience >>> >>> c) with No Plan: >>> ... nothing >>> >>> I am intentionally not going into how all plans would require=20 >>> additional metadata that would place SSRC 1 left and 2 right as I=20 >>> don't think this conveys any meaningful differences. >>> >>> Comments on the above are welcome. We could also move to another=20 >>> scenario from the Plan A draft, if you believe that 7.3 is not=20 >>> representative enough. >>> >>> Emil >>> >>> >> >> > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Tue Jun 4 08:02:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4C821F9C59 for ; Tue, 4 Jun 2013 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.593 X-Spam-Level: X-Spam-Status: No, score=-101.593 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liG61SgC75Z9 for ; Tue, 4 Jun 2013 08:02:38 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 711C321F9C2D for ; Tue, 4 Jun 2013 06:14:15 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so129751qeb.13 for ; Tue, 04 Jun 2013 06:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=WgjsZFauJqBl9elP8ipyOSp2lWMBFdAuXHNEsRkd0oE=; b=dlLUzj+Ho7gbVytuTrArnUGZlYtW/s9voDpmFGjfH6ffzWNJPXpo8NFlBbpudLYjKV IMrBMGLIOsYolF7cQVCet8W3w5nub9OSCRSnim35gD1Fi4wsA7J4jY36p4NQxGSqApC8 UOkQvvcfGr8KRsj3uBpMkiEdUWfhI4j3Tg/n3jheNWcwrT0GfMidKtBJf9wCcc1b7Ul9 F92tD/sdS0xkwiU0MM3Cmlw6TfUXH7NptfLuy13o8/CnQy2LffnVTkq5MIaIsSfzTuOn ANtoIk7tKvw/6DM1K8th6P43uJXTHYETKgmyJPgHutre2O62eDf/VHJHxrFN7hrp0VZo FDcw== X-Received: by 10.224.68.10 with SMTP id t10mr23057590qai.24.1370351654739; Tue, 04 Jun 2013 06:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.0.163 with HTTP; Tue, 4 Jun 2013 06:13:34 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <51ADA539.1020505@jitsi.org> References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> <51AD0AC2.2080001@jitsi.org> <51ADA539.1020505@jitsi.org> From: Eric Rescorla Date: Tue, 4 Jun 2013 06:13:34 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c2e2dc994de004de53db2b X-Gm-Message-State: ALoCoQkOBX312sAsF+zhXQhCKbu3hwfsHOn1vu8R1sO8o2a1znXTFA1LHrvHu2LxkM4u/oESL2Gj Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:02:59 -0000 --001a11c2e2dc994de004de53db2b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 1:28 AM, Emil Ivov wrote: > Hey Eric, > > > On 04.06.13, 03:47, Eric Rescorla wrote: > >> On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov wrote: >> > > > So, just for clarity: you mean that A advertises one m-lin, B >> accepts, >> and then A sends some arbitrary number of media flows, >> >> >> Yes. >> >> identified >> by SSRC? >> >> >> What does "identified" mean? >> >> >> I mean demultiplexed by SSRC. >> > > Demuxing by SSRC, as in being able to distinguish one RTP stream from > another is totally OK and there's no issue with this in No Plan Well, maybe. So, your claim is that multiple SSRCs on the same m-line are to be rendered separately? I note that that's *not* the view Cullen has expressed. > er one that allows the JS >> to say "don't send SSRC A"? >> > > As long as the JS knows the SSRC of a specific track it can just disable > that specific track. There's no need to tell the browser "don't send SSRC > A". Well, given that the only mechanism you provide for addressing tracks is SSRC, it'a hardly an advantage to not have a "don't send SSRC A" API point, since that just means you need to go grovelling through the MSTs for their SSRC values. > It would be really helpful if you could provide a complete example of >> exactly what each side does. I'm find if you just invent some >> application-specific >> signaling for this purpose, but what I'd like to see is exactly what API >> calls each side makes. >> > > Does the above answer your question, or would you like me to come up with > an example of how these new APIs could look? > I would like to see a *complete* example with all the data flowing back and forth and the API calls (even if they are mocked up) that you think the sides will make. -Ekr --001a11c2e2dc994de004de53db2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 4, 2013 at 1:28 AM, Emil Ivov <emcho@jitsi.org> wrote:
Hey Eric,


On 04.06.13, 03:47, Eric Rescorla wrote:
On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov <emcho@jitsi.org> wrote:
<snip>

=A0 =A0 =A0 =A0 So, just for clarity: you mean that A advertises one m-lin,= B
=A0 =A0 =A0 =A0 accepts,
=A0 =A0 =A0 =A0 and then A sends some arbitrary number of media flows,


=A0 =A0 Yes.

=A0 =A0 =A0 =A0 identified
=A0 =A0 =A0 =A0 by SSRC?


=A0 =A0 What does "identified" mean?


I mean demultiplexed by SSRC.

Demuxing by SSRC, as in being able to distinguish one RTP stream from anoth= er is totally OK and there's no issue with this in No Plan
=

Well, maybe. So, your claim is that multiple SSRC= s on the same m-line are to be rendered
separately? I note that that's *not* the view Cullen has =A0= expressed.

=A0
er one that allows the JS
to say "don't send SSRC A"?

As long as the JS knows the SSRC of a specific track it can just disable th= at specific track. There's no need to tell the browser "don't = send SSRC A".

Well, given that t= he only mechanism you provide for addressing tracks
is SSRC, it'a hardly an advantage to not have a "don= 9;t send SSRC A"
API point, since that just means you = need to go grovelling through the
MSTs for their SSRC value= s.


It would be really helpful if you could provide a complete example of
exactly what each side does. I'm find if you just invent some
application-specific
signaling for this purpose, but what I'd like to see is exactly what AP= I
calls each side makes.

Does the above answer your question, or would you like me to come up with a= n example of how these new APIs could look?

=
I would like to see a *complete* example with all the data flowi= ng back and forth
and the API calls (even if they are mocked up) that you think th= e sides will
make.

-Ek= r

--001a11c2e2dc994de004de53db2b-- From pkyzivat@alum.mit.edu Tue Jun 4 10:35:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28F421F9C89 for ; Tue, 4 Jun 2013 10:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wxzp0ct8Bhl for ; Tue, 4 Jun 2013 10:35:34 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id CBDBE21F9622 for ; Tue, 4 Jun 2013 09:07:31 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id kG3Q1l0071vXlb85AG7XPm; Tue, 04 Jun 2013 16:07:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id kG7X1l0023ZTu2S3dG7XFl; Tue, 04 Jun 2013 16:07:31 +0000 Message-ID: <51AE10C2.5010807@alum.mit.edu> Date: Tue, 04 Jun 2013 12:07:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> <51AD0C53.7030406@alum.mit.edu> <51AD1617.9020501@jitsi.org> In-Reply-To: <51AD1617.9020501@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370362051; bh=/bhvWQxUg6osN/yspy69zHQJWEgT9A4Kw9kV0wHDLTw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sQGW9OsxyBO/mkla3P9TiMXQcoO76HB6yx2x1LBNymS/WwHM1Z1d1ExDMvLpWMt6E oeDWK0JGrH+oCSWh+m6nfVLwL61tcyerfr3rC65CIfS1JxRoh4b71hor/msylj5d/n HmM+kRrzi+VCkCEJU3v2Rpk9f5T8zC5dA+Clv8T5Wgl8i7Z9b+hmElumjmkdHynuPM KsS0C5i/1EawZ3Vdr03WS5Mb4fNd/k80kkRIXDDwTPqTh5j5fm4NDLcrKEuTd15lDN IZRPFZUHq82S2Q94Y5Fx7yuufheFHbVm3BmRfNSSTPis7466ju9o3EQX/DfvQcxVLn sc6Gd+qZSey0g== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] No Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:35:39 -0000 On 6/3/13 6:17 PM, Emil Ivov wrote: [snip] >>>> I'm just pointing out that for decomposed endpoints one 5-tuple may not >>>> be enough. And the need for this might not be known a priori. One side >>>> may be ready to add another stream for some purpose, and be >>>> willing/able >>>> to use private signaling to negotiate that. But the other side may not >>>> be able to handle that stream on the same 5-tuple. That in turn may >>>> result in a need to negotiate SDP changes to establish an additional >>>> 5-tuple that can then be used for that new stream. >>> >>> I think I see ... but not completely. Could you please post an SDP offer >>> with BUNDLE and the corresponding answer? >> >> The issue can be discussed without bundle, and without detailing the O/A. > > We can certainly try. I am not sure if I am following though. Let's see: > >> Assume we have had an O/A already between X and Y, with a single (video) >> m-line, resulting in a single 5-tuple. Over this we have a single audio >> RTP stream and mediaStreamtrack. >> >> The user of X interacts with the app, indicating a desire to receive >> another video stream from Y. This causes the app to trigger the JS in Y >> to set up another mediaStreamTrack. But the camera on Y has a separate >> IP address. So it is necessary to first set up another video m-line with >> the new address on Y's end. (X's end can use its single IP address.) > > This is the part that I can't quite picture. How can Y's camera be on a > separate IP, but still appear as a regular device to Y's javascript and > still generate a regular stream track? All this with a generic browser? I'm not a browser guy, so maybe I am imagining things that are out of scope for webrtc, but maybe not. At the very least you can have an app that gateways between a browser and some non-browser device. So assume that X is a browser and Y is not. What does the app tell the browser to do so that the new stream is on a different 5-tuple? > Wouldn't it be much more likely that such a separate camera will be > controlled by a proprietary interface that is not directly related to > WebRTC? Can somebody who knows more about these things comment if this is entirely impossible for two devices accessible to the browser to be accessible only via distinct IP address/port, or if it might occur for a sufficiently sophisticated device? Thanks, Paul > If so, then the additional signalling for this camera would obviously > need to be generated by Y's javascript (i.e. not the browser). That > additional signalling can then be merged into the one from Y's browser > by Y's JS or a gateway. > > X would indeed need to handle an offer with two video m= lines at that > point, but that's because they would negotiate different 5-tuples. So > this is fine. > > Another option would be to handle the new camera with an independent > Offer/Answer that would yield a new PeerConnection. I don't know if that > works for your case but I thought I'd mention it. In this case any > additional information required for the synchronization of the two peer > connections would be exchanged in an app-specific way. > > Cheers, > Emil > > >> Once that is done the new mediaStreamTrack can be established on the new >> m-line. >> >> How does this fit into No Plan? >> >>> (This might be a good point to move this to mmusic) >> >> Done. > > Thanks, > Emil > >> >> Thanks, >> Paul >> >>> Thanks, >>> Emil >>> >>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> If you'd like for that signalling to be in SDP, I >>>>>>> don't see any problem with it. However it would be best for this >>>>>>> extra >>>>>>> layer of SDP signalling to appear at either the application layer >>>>>>> or in >>>>>>> a signalling gateway (that is going to be there anyway). >>>>>>> >>>>>>> Does this make sense? >>>>>>> >>>>>>> Emil >>>>>>> >>>>>>>> >>>>>>>> Further questions: >>>>>>>> >>>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>>>>> per-m-line, with application specific signaling for bandwidth at >>>>>>>> the >>>>>>>> per-RTP-stream level? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> Based on many of the discussions that we've had here, as well as >>>>>>>>> many >>>>>>>>> others that we've had offlist, it seemed like a good idea to >>>>>>>>> investigate >>>>>>>>> a negotiation alternative that relies on SDP and Offer/Answer >>>>>>>>> just a >>>>>>>>> little bit less. >>>>>>>>> >>>>>>>>> The following "no plan" draft attempts to present one such >>>>>>>>> approach: >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>>>>> >>>>>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>>>>> intricacies of multi-source scenarios to application-specific >>>>>>>>> signalling, with potentially a little help from RTP. >>>>>>>>> >>>>>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>>>>> interoperability requirements that concerned them can still be met >>>>>>>>> with >>>>>>>>> "no plan". Of course they would have to be addressed by >>>>>>>>> application-specific signalling and/or signalling gateways. >>>>>>>>> >>>>>>>>> Comments are welcome! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Emil >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>> . >>>>>>>> >>>>>>> >>>>>> >>>>>> . >>>>>> >>>>> >>>> >>>> >>> >> >> > From pkyzivat@alum.mit.edu Tue Jun 4 10:39:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D3E21F960D for ; Tue, 4 Jun 2013 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiEYPinlizbD for ; Tue, 4 Jun 2013 10:39:00 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2CC21F96A9 for ; Tue, 4 Jun 2013 09:16:10 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id kBPB1l0030cZkys5CGG9nr; Tue, 04 Jun 2013 16:16:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id kGG91l00g3ZTu2S3WGG9De; Tue, 04 Jun 2013 16:16:09 +0000 Message-ID: <51AE12C8.3090501@alum.mit.edu> Date: Tue, 04 Jun 2013 12:16:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> <51AD0AC2.2080001@jitsi.org> <51ADA539.1020505@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370362569; bh=v2XssIOod/dahDl4HwJ/MyzwtA9oI9uBW60nFSVnZAM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bBRuf5XaRxUJCG1A3P+JgESfuY3xyna4Yg0czZsXhBksrG+1bu0cBiNcVyaqYjhL/ MXeBpIcAD7ECXfEW36Zt7WptSXJEL2lTf2Bz09DBHaXrCv9xTFsyI6+ex9Ue97nCrn 0rTD2ztT5ukumSFF6bdbJiqe2STOYC6owmqzP1qrttdtr4aT+evSp5FcakEr1l7cYt gZYC6h48ui0WYWv8Zplu8dN4fdtekOA8E098HE0mmo7/DIvq6BFzXQ/2x0CorQeODQ TewoWtjufVtueKKQUqsk7tU37cznKMEAgAI4Dn+wTwYYIpj/lniAJ2IjYLkWL7PPhi nDyOwnxi1J9ww== Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:39:05 -0000 On 6/4/13 9:13 AM, Eric Rescorla wrote: > Demuxing by SSRC, as in being able to distinguish one RTP stream > from another is totally OK and there's no issue with this in No Plan > > > Well, maybe. So, your claim is that multiple SSRCs on the same m-line > are to be rendered > separately? I note that that's *not* the view Cullen has expressed. If we fold in *Colin's* comments, then demuxing by SSRC is separate from determining if/how/where to render that stream. Is there a need for an API to associate multiple SSRCs with a single mediaStreamTrack? Or should it be up to the app to accept multiple mediaStreamTracks to render them to the same place? Thanks, Paul > er one that allows the JS > to say "don't send SSRC A"? > > As long as the JS knows the SSRC of a specific track it can just > disable that specific track. There's no need to tell the browser > "don't send SSRC A". > > > Well, given that the only mechanism you provide for addressing tracks > is SSRC, it'a hardly an advantage to not have a "don't send SSRC A" > API point, since that just means you need to go grovelling through the > MSTs for their SSRC values. > It would be really helpful if you could provide a complete > example of > exactly what each side does. I'm find if you just invent some > application-specific > signaling for this purpose, but what I'd like to see is exactly > what API > calls each side makes. > > > Does the above answer your question, or would you like me to come up > with an example of how these new APIs could look? > > > I would like to see a *complete* example with all the data flowing back > and forth > and the API calls (even if they are mocked up) that you think the sides will > make. > > -Ekr > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Tue Jun 4 10:40:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E3221E80F1 for ; Tue, 4 Jun 2013 10:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1+Z7LBPjOsH for ; Tue, 4 Jun 2013 10:40:13 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D79E821F9A4B for ; Tue, 4 Jun 2013 09:24:38 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id kBAi1l0021YDfWL59GQeXn; Tue, 04 Jun 2013 16:24:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id kGQe1l00K3ZTu2S3gGQeVR; Tue, 04 Jun 2013 16:24:38 +0000 Message-ID: <51AE14C5.6000701@alum.mit.edu> Date: Tue, 04 Jun 2013 12:24:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> <51ACFB79.1080207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370363078; bh=jW91VkBc9qcgB+Sbk+CYG2EwnDsaJKuHKI3Hf4ePW3k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V2vpO2H55koci7AAczp3kvQb2XTHUM9lZoo+6d9uJVWl7/ANVGhS1LgGMYOU0Gl+P ksYWbE5qa4VtMuk9Aih0DpqtPiaxuWj7mzpb3G2ZShCD/uoJEktY7uoAOPTVU16jsF W2rkMX6rl9o+/u4gDoe1jHWiLXW0ykI32jih2WcKSa7IKEFjrzvwZeAC9BQHpydlFi 0AIPGaBciHx7OR12Gs/nAscyTMOHKIyyQy6kQNsMYMgFyKb7RxVqIyN/QibEJwqTm0 VCtxMVxRuoxcy3goAx02HSxcazxAI/7euKiQF9jaNQL7KxUUAbraWxdfDTSHHYnjh2 X2EUYLj7qyqGQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:40:19 -0000 On 6/4/13 3:28 AM, Christer Holmberg wrote: > Hi, > >>>>> I'll throw the ball out with suggesting the following ones: >>>>> >>>>> -*Bundle restart offer* (different port value, currently referred to >>>>> as "first offer") >>>>> >>>>> The reason I use "restart" wording is because this is used, no >>>>> matter whether in the beginning of the session or mid-session, to >>>>> (re-)negotiate the usage of BUNDLE, and the bundle address >>>>> information selection. >>>>> >>>>> -*Bundle sync offer* (identical port value, currently referred to as >>>>> "second offer") >>>>> >>>>> The reason I used "sync" wording is because this is used to ensure >>>>> that intermediaries have correct address information for each m- line. >>>>> >>>>> Keep in mind that we may even need to split the sync offer into more >>>>> sub types, when we get into the details of adding new m- lines etc, >>>>> but I'd like to agree a base to start from :) >>>> >>>> Above seems like a good start, but I'm still grappling with some >>>> things and don't know how to talk about concisely: >>>> >>>> I understand that the next offer after a Bundle Restart Offer will >>>> typically be a Bundle Sync Offer. But if there is another offer after >>>> a Bundle Sync Offer, and it doesn't change anything about the bundle, >>>> then is it still a Bundle Sync Offer? >>> >>> Currently, yes. >> >> I agree that without adjusting the terminology this is the only right choice to make. But it is a little obscure. I'm not certain this needs to be improved, but I thought I would suggest that it might. >>> >>>> Also, I don't believe the above are mutually exclusive. If I send an >>>> offer to add a new m-line to a bundle, and I give it distinct address >>>> info so that the answerer may take it out of the bundle if needed, >>>> then is that a Bundle Restart Offer or a Bundle Sync Offer? It seems >>>> to be a bit of each. And of course there may be multiple bundles >>>> described by the SDP, and these terms apply independently to each. >>>> >>>> Maybe we need a couple more terms for: >>>> >>>> - offer that adds a new m-line to bundle using the existing bundle >>>> address info. >>> >>> Technically that is a Bundle Sync Offer, but I DO agree that the wording is not good in this case - as it's not only about synchronization. >>> >>>> - offer that adds a new m-line to an existing bundle using unique >>>> address info. >>> >>> I agree that doesn't fit the current definitions. >>> >>> However, we will have to agree on whether we allow that in the first place, or whether the offerer will have to use 1) same address information or 2) different address information for ALL m- lines (Bundle Restart Offer). >> >> Yes, we need to settle on whether either or both of these are permitted. >> >> But I can think of reasons why I might wish to use either one, and no good reason not to allow both. So allowing both is my preference. > > I personally think we should allow BOTH 1) and 2). > > The question is whether we should allow 3), which is new m- line with unique address, while the other m- lines use the bundle address. I agree it is a valid question to ask. Again, I can see how it might be useful sometimes, and I can see no reason not to allow it. Its just a special case of the bundle restart offer. (Note, IMO it should be ok for the very first offer to propose a bundle with address info already shared among m-lines in the proposed bundle. Using that trades off potential interop issues for speed in establishing the session.) Thanks, Paul From internet-drafts@ietf.org Tue Jun 4 11:32:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1390721F9B62; Tue, 4 Jun 2013 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gakJRfd1ibRq; Tue, 4 Jun 2013 11:32:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 971F921F9B3F; Tue, 4 Jun 2013 11:07:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604180754.18072.7115.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 11:07:54 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:32:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Offer/Answer Considerations for G.723 Annex A and G.729 = Annex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-02.txt Pages : 8 Date : 2013-06-04 Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the SDP offer and answer. This document provides the offer/answer considerations for these parameters and updates RFC4856. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fluffy@iii.ca Tue Jun 4 17:01:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8410B21F9A23 for ; Tue, 4 Jun 2013 17:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZaaccf0xnyf for ; Tue, 4 Jun 2013 17:01:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A95321F9A21 for ; Tue, 4 Jun 2013 17:01:48 -0700 (PDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C297422E253; Tue, 4 Jun 2013 20:01:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <63BA9030-983D-4426-A378-C6634F77D4DA@csperkins.org> Date: Mon, 3 Jun 2013 16:50:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3BCCF310-7FC5-4590-987E-32A7AB7A82BD@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <6D94E7F9-1AB2-4B39-8750-434FFFC5293A@cisco.com> <63BA9030-983D-4426-A378-C6634F77D4DA@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:01:52 -0000 On May 27, 2013, at 8:05 AM, Colin Perkins wrote: > The SSRC identifies the source in RTP: that's fundamental to the = design of the protocol.=20 >=20 > If Plan A wants to use unique PT values to determine how and where a = source is rendered, that's fine, subject to the limited number of PT = values. I don't think it's fine to redefine the PT as identifying the = source. >=20 > Colin Again we might have confusions on the word source. In the sense Colin = means source in which RTP speaking computer (or application on that = computer), I agree with Colin. My defines in above sentence is pretty = fluffy but the key thing is source seems pretty well defined in RTP and = it's identified by the SSRC information (which might show up in a CSRC = field).=20 But I think some people use source sometimes to mean if the media = originated from the microphone or the camera - that's not how RTP uses = the word source but if people mean camera or microphone, then some of = that might be learned from the PT. >=20 >=20 >=20 > On 27 May 2013, at 14:47, Mo Zanaty (mzanaty) wrote: >> The gist of Christer's question is: unique payload types just for = unique payload formats, or also for unique sources? I think we all agree = the former is true, and this seems to be Colin's point below. But Plan A = proposes the latter and extends PT uniqueness to identify sources not = just payloads. >>=20 >> Mo >>=20 >>=20 >> On May 27, 2013, at 9:05 AM, "Colin Perkins" = wrote: >>=20 >> On 27 May 2013, at 14:02, Christer Holmberg wrote: >>>>>>> There were a number of comments in the call last week, and on = the list, about unique payload types in BUNDLE. I'd like to explore this = further. >>>>>>>=20 >>>>>>> Case A: Within a single RTP session, I think we'd all agree that = an offer that uses the same RTP payload type for two payload formats on = a single m=3D line is problematic:=20 >>>>>>>=20 >>>>>>> v=3D0 >>>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D = c=3DIN=20 >>>>>>> IP4 host.anywhere.com >>>>>>> t=3D0 0 >>>>>>> m=3Daudio 49170 RTP/AVP 96 >>>>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>>>> a=3Drtpmap:96 G7291/16000 >>>>>>>=20 >>>>>>> If this were done the receiver would have no way of = distinguishing what payload format is meant by payload type 96. = Accordingly, unique payload formats need to be used for each payload = format. >>>>>>=20 >>>>>> That should be "...unique payload types need to be used for each = payload format" of course. >>>>>=20 >>>>> What if you have two m- lines, with identical encoding in both? = Both=20 >>>>> represent the same payload format, don't they? :) >>>>>=20 >>>>> v=3D0 >>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN= IP4=20 >>>>> host.anywhere.com >>>>> t=3D0 0 >>>>> m=3Daudio 49170 RTP/AVP 96 >>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>> m=3Daudio 49170 RTP/AVP ??? >>>>> a=3Drtpmap:??? AMR-WB/16000 >>>>=20 >>>> Not sure I get your point. You can have two different payload types = that map to the same payload format in a single RTP session, since >>>> you can always distinguish what payload format is intended. You = can't have the same payload type mapping to two different payload=20 >>>> formats in a single RTP session, since you can't then infer what = payload format was meant.=20 >>>=20 >>> Please not that both PTs map to the SAME payload format :) >>=20 >>=20 >> I thought I addressed that in my reply. >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@iii.ca Tue Jun 4 17:01:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8390B21F9A21 for ; Tue, 4 Jun 2013 17:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9--gUOkz4AI for ; Tue, 4 Jun 2013 17:01:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9632021F9A1F for ; Tue, 4 Jun 2013 17:01:47 -0700 (PDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 841A922E200; Tue, 4 Jun 2013 20:01:38 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A859D4.7030201@alvestrand.no> Date: Mon, 3 Jun 2013 16:49:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5FC23AD9-69DA-45E2-8F54-646CEB578115@iii.ca> References: <51A3C6C9.6050606@alvestrand.no> <51A859D4.7030201@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1503) Cc: mmusic Subject: Re: [MMUSIC] The pick-a-config debate - perhaps an useful example X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:01:53 -0000 On May 31, 2013, at 2:05 AM, Harald Alvestrand = wrote: > On 05/30/2013 07:47 PM, Cullen Jennings (fluffy) wrote: >> On May 27, 2013, at 2:49 PM, Harald Alvestrand = wrote: >>=20 >>> a=3Dgroup:BUNDLE foo bar >>>=20 >>> m=3Dvideo >>> a=3Dmid:foo >>> a=3Dimageattr:* [x=3D160,y=3D100] >>> a=3Drtpmap:96:vp8 >>>=20 >>> m=3Dvideo >>> a=3Dmid:bar >>> a=3Dimageattr:* [x=3D640,y=3D480] >>> a=3Drtpmap:96:vp8 >>>=20 >>> Now, the video is the same. >> Small nit =85 as far as I am concerned, if the above is a 3264 based = offer, the video could be from two different cameras. You need some = other signaling to indicate it is simulcast. >>=20 > I did not intend it to say whether it was simulcast or not - I wasn't = thinking of simulcast when I wrote it, just about "one of the parties = says he wants two different, incompatible resolutions". "The video is = the same" was badly formulated; I meant "The video codec is the same". Ah - make sense. Thanks.=20 From fluffy@iii.ca Tue Jun 4 17:01:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7533521F9A2B for ; Tue, 4 Jun 2013 17:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.93 X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcYO5orgFSRk for ; Tue, 4 Jun 2013 17:01:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A58721F9A20 for ; Tue, 4 Jun 2013 17:01:48 -0700 (PDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CFBF22E257; Tue, 4 Jun 2013 20:01:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A3B070.1090006@alum.mit.edu> Date: Mon, 3 Jun 2013 16:49:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:01:58 -0000 On May 27, 2013, at 1:13 PM, Paul Kyzivat wrote: > On 5/27/13 2:52 PM, Colin Perkins wrote: >=20 >>>>> In the example above the same payload format, within the same RTP = session, is used in two separate m- lines. But, I still can't use the = same PT value for both m- lines, even if the payload format is the same, = can I? >>>=20 >>>> Why not? I don't see any problem mapping the same payload type to = the exact same payload format in two different m=3D lines. >>>=20 >>> But, when I receive media with that payload format, how do I know to = which m- line it "belongs", as the same PT value is used for both m- = lines? >>=20 >> You don't. If you care about that, you need to either use distinct PT = values for each m=3D line, or signal SSRCs. >=20 > I assert that if you don't care about associating a packet to a = particular m-line in a bundle that you don't need to use bundle. I'm not sure this makes a huge difference to your argument but I don't = think I agree with the above.=20 It seems that even if you don't care which m-line the media get = associated with, if you want to use a single port for all the m-line, = you still need bundle.=20 >=20 > So if you used bundle, you must care, and so there must be a way to = achieve that association. >=20 > The reason you care is because doing so allows you to discover all the = other things in that media section of the SDP that may be pertinent to = this packet. >=20 > Thanks, > Paul From fluffy@iii.ca Tue Jun 4 17:02:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F021F9A2E for ; Tue, 4 Jun 2013 17:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OemYahwHf-4U for ; Tue, 4 Jun 2013 17:01:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4C21F9A22 for ; Tue, 4 Jun 2013 17:01:46 -0700 (PDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C9FA22E1FA; Tue, 4 Jun 2013 20:01:31 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3812FB@ESESSMB209.ericsson.se> Date: Mon, 3 Jun 2013 16:49:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5CDDB46C-4F09-4812-BF85-24970E466EE5@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3812FB@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:02:00 -0000 On Jun 2, 2013, at 12:33 PM, Christer Holmberg = wrote: >=20 > 6.4.6. Removing a media description from a BUNDLE group >=20 > When generating the SDP Answer, if the Answerer wants to remove an > "m=3D" line from a BUNDLE group (without rejecting the "m=3D" = line),it > MUST NOT include the "m=3D" line in a BUNDLE group. In addition, = the > SDP Answer MUST not add its local bundle address to the "m=3D" line. >=20 > An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from = a > BUNDLE group, unless the "m=3D" line had unique address information = in > the associated SDP Offer. >=20 > NOTE: The reason for the restriction above is that, if the "m=3D" = line > would be removed from the BUNDLE group, the address information = would > be identical to the "m=3D" lines remaining in the BUNDLE group. >=20 > OPEN: The decision for allowing a media description with port zero > values inside a BUNDLE group is pending on update for RFC 5888. >=20 > I thought we had agreed to no bundle splitting. >=20 > I am not sure what you mean by =93splitting=94, but this is not about = moving an m- line from one BUNDLE group to another BUNDLE group, but to = move it outside an BUNDLE group all together. People wanted to allow = that in the case where the Offer contains different ports, but if you = disagree we need to discuss it further. >=20 > Regards, One case that is brought up for this is a conference bridge where the = voice and video go to different IP addresses. The browser makes a offer = to the conference bridge and can offer all the voice and video in one = bundle, but the answer from the bridge keeps all the video in the bundle = but puts the audio outside of any bundle. It did not split a bundle into = two bundles but for all the things offered in the bundle, the answer = said yes to some and no to others about them being in the bundle.=20 I don't think Christer or I was thinking of that as splitting but agree = we never really sorted out what the term means=20 From fluffy@iii.ca Tue Jun 4 17:02:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34CA21F9A21 for ; Tue, 4 Jun 2013 17:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00ykFGmybFxf for ; Tue, 4 Jun 2013 17:01:58 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 877CB21F9A2C for ; Tue, 4 Jun 2013 17:01:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id D55102FD7BF for ; Tue, 4 Jun 2013 20:01:51 -0400 (EDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A55F922E255; Tue, 4 Jun 2013 20:01:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Mon, 3 Jun 2013 16:51:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> To: Colin Perkins X-Mailer: Apple Mail (2.1503) Cc: mmusic@ietf.org, Paul Kyzivat Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:02:08 -0000 On May 27, 2013, at 1:24 PM, Colin Perkins wrote: >=20 > But, again, let's keep the discussion of mapping RTP/RTCP packets onto = RTP sources separate from the discussion of how to map the RTP sources = onto m=3D lines. The former is well-defined by RTP, the latter is not = yet defined. Proposals for solving the latter shouldn't start with "when = a packet arrives, first do this", because that's the domain of the RTP = source de-multiplexing process; rather they should consider "how do we = map this RTP-level source (i.e., a sequence of RTP and RTCP packets = identified by SSRC, whether signalled or not) onto an m=3D line".=20 I think this thread has convinced me that it was a mistake for my = original proposal merged what was happening at what Colin had layer B = and C in his digram. I'm roughly talking about how this gets connected = up with the right m line at the application layer (layer C).=20 I agree with the fact that RTCP and such is reported by SSRC as the = layer B.=20 From fluffy@iii.ca Tue Jun 4 17:02:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5880721F9A34 for ; Tue, 4 Jun 2013 17:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxMQ-zFWH+2r for ; Tue, 4 Jun 2013 17:02:00 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 1B22D21F9A20 for ; Tue, 4 Jun 2013 17:01:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 360152FD7D3 for ; Tue, 4 Jun 2013 20:01:58 -0400 (EDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 290BA22E1FA; Tue, 4 Jun 2013 20:01:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> Date: Mon, 3 Jun 2013 16:51:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8867CBCB-33B8-413B-A1BC-3BEAEB04A5D1@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org WG" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:02:08 -0000 On May 27, 2013, at 12:52 PM, Colin Perkins wrote: > On 27 May 2013, at 19:43, Christer Holmberg wrote: >>>>>>>> v=3D0 >>>>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D = c=3DIN IP4 >>>>>>>> host.anywhere.com >>>>>>>> t=3D0 0 >>>>>>>> m=3Daudio 49170 RTP/AVP 96 >>>>>>>> a=3Drtpmap:96 AMR-WB/16000 >>>>>>>> m=3Daudio 49170 RTP/AVP ??? >>>>>>>> a=3Drtpmap:??? AMR-WB/16000 >>>>>>>=20 >>>>>>> Not sure I get your point. You can have two different payload = types that map to the same payload format in a single RTP session, since >>>>>>> you can always distinguish what payload format is intended. You = can't have the same payload type mapping to two different payload >>>>>>> formats in a single RTP session, since you can't then infer what = payload format was meant. >>>>>>=20 >>>>>> Please not that both PTs map to the SAME payload format :) >>>>>=20 >>>>> I thought I addressed that in my reply. >>>>=20 >>>> I am not sure you did - at least I didn't get it :) >>>>=20 >>>> Again, my understanding of what you said is that, for any payload = format within an RTP session, the PT value has to be unique. >>>=20 >>> Correct. >>>=20 >>>> In the example above the same payload format, within the same RTP = session, is used in two separate m- lines. But, I still can't use the = same PT value for both m- lines, even if the payload format is the same, = can I? >>=20 >>> Why not? I don't see any problem mapping the same payload type to = the exact same payload format in two different m=3D lines. >>=20 >> But, when I receive media with that payload format, how do I know to = which m- line it "belongs", as the same PT value is used for both m- = lines? >=20 >=20 > You don't. If you care about that, you need to either use distinct PT = values for each m=3D line, or signal SSRCs.=20 >=20 +1=20 I think this pretty much nails it so if we could come up some text that = said this, and did not have the terminology confusing I had introduced = about what happens at layer B, I think that would be excellent.=20 From fluffy@iii.ca Tue Jun 4 17:02:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1421F9A3A for ; Tue, 4 Jun 2013 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+pRWi049eTn for ; Tue, 4 Jun 2013 17:02:07 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 2129D21F9A2B for ; Tue, 4 Jun 2013 17:01:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id D76302FD7CD for ; Tue, 4 Jun 2013 20:01:54 -0400 (EDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5F17A22E256; Tue, 4 Jun 2013 20:01:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A39023.1070605@alum.mit.edu> Date: Mon, 3 Jun 2013 16:51:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:02:19 -0000 Imagine Alice sends an offer containing=20 On May 27, 2013, at 10:56 AM, Paul Kyzivat = wrote: > m=3Daudio 49172 RTP/AVP 96 > a=3Dssrc:2222 cname:alice@example.com > a=3Drtpmap:96 G7291/16000 Let say that an offer sent like the above. That means nothing about the = SSRC for the packets that Alice will receive. And it is likely to = receive RTP packets before it receives an answer in some important = scenarios.=20 So a RTP packet SSRC 3333 arrives. There's no information from the SSRC = about what m-line it matches too (but RTCP for it can be sent).=20 Now an answer from Bob arrives with=20 m=3Daudio 55555 RTP/AVP 96 a=3Dssrc:4444 cname:bob@example.com a=3Drtpmap:96 G7291/16000 Now a packet with SSRC 4444 arrives. That might be from Bob, but here's = the rub. It might be from Charlie. If there was an SSRC collisions = between Bob and Charlie, it will be awhile before some SDP shows up that = says that there was a collisions and now Bob is using SSRC 5555.=20 This is all a disaster and the best solutions to it IMHO would be to = define a new RTP Header extension that carries and identifier and that = Alice can tell Bob in the SDP offer what value to put in the identifier = for the RTP from Bob to Alice.=20 I've see more than one system that have stuffed that identifier in the = existing CSRC field which is sort of an awful hack and sort of very = cool.=20 From fluffy@iii.ca Tue Jun 4 17:02:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B821F9A3B for ; Tue, 4 Jun 2013 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TORYYBPMUMm8 for ; Tue, 4 Jun 2013 17:02:09 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 860F621F9A20 for ; Tue, 4 Jun 2013 17:02:08 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 62D9D2FD7D8 for ; Tue, 4 Jun 2013 20:02:07 -0400 (EDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 710DC22E253; Tue, 4 Jun 2013 20:02:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51A3B3BD.4010004@alum.mit.edu> Date: Mon, 3 Jun 2013 16:51:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82E05787-1B9A-4DF6-BFF0-3FFD53B04DD4@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <51A3AAC3.9030905@alum.mit.edu> <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@csperkins.org> <51A3B3BD.4010004@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: Colin Perkins , mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:02:20 -0000 On May 27, 2013, at 1:27 PM, Paul Kyzivat wrote: >=20 > I think what I am talking about can be tweaked to fit with what you = are suggesting. (This is where my limited understanding of RTP causes me = trouble.) I've been viewing B & C as a single black box. I've no problem = with decomposing it. +1 From fluffy@cisco.com Tue Jun 4 17:22:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B26A21F9A28 for ; Tue, 4 Jun 2013 17:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtMDE2mQtCXQ for ; Tue, 4 Jun 2013 17:22:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A447A21F9A26 for ; Tue, 4 Jun 2013 17:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2593; q=dns/txt; s=iport; t=1370391723; x=1371601323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gH//XCVVZbb1fUZkPbO6flL/V2mmnUCTkqz32TPVc48=; b=CkA5QLupLaFGiz34zxz70QE1PUsvWUC/k/wOd0RwNovgK8eWicQl0uKz OdrdZT6xtc/uBS2klxmEDDIjhd6S8WberzK1TjH8fsu11unUWi2yK4Oom XqM0o8eNK1cvzsH1i1VQkKisKBtQe7nPpS/guzfNxOmN0tCIv9tNXSqVy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOKDrlGtJXHA/2dsb2JhbABaDoJ7ML8qfhZ0giMBAQEDAQEBATc0CwULAgEIDgoKFBAnCyUCBA4FCId/Bgy9cwSOcQIxB4J6YQOof4JRPoIn X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="218810858" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2013 00:21:52 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r550LqNY008058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 00:21:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 19:21:52 -0500 From: "Cullen Jennings (fluffy)" To: Paul Kyzivat Thread-Topic: [MMUSIC] When a bundle offer is forked Thread-Index: AQHOYYKtP/NHv6FjPEKQrwlk8Mwd/A== Date: Wed, 5 Jun 2013 00:20:30 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> In-Reply-To: <519E530C.60705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.232.182] Content-Type: text/plain; charset="us-ascii" Content-ID: <54B9165676F06F4181BD4041A195E401@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] When a bundle offer is forked X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:22:09 -0000 I don't think dealing with forking with bundle is any different that dealin= g with forking without bundle. The key thing is we are not using bundle wit= h multicast.=20 On May 23, 2013, at 11:34 AM, Paul Kyzivat wrote: > On 5/23/13 6:35 AM, Emil Ivov wrote: >=20 >> In case a bundle offer gets forked and various answers ... >=20 > I trimmed everything else out of Emil's reply, and changed to subject, be= cause this is a whole different can of worms! >=20 > I think we must acknowledge that this *can* happen, though it is a low pr= obability event. It raises all sorts of ugly issues. A few: >=20 > * if the bundle is accepted by multiple forks, does this form > one RTP session or several? If so, same as if your were not doing bundle in O/A without multicast - they are d= ifferent=20 >=20 > - if so, then if each fork accepts a different set of m-lines from > the bundle, how can that work with a single RTP session? so they are not a single session but again, it's pretty much the same as if= you were not using bundle and things the forks accepted different sets of = m lines.=20 >=20 > * How does ICE work in this case? (Is that already covered by ICE, > since it mostly isn't specific to bundle? exactly the same as if you were not doing bundle but there are less ports t= o set up=20 >=20 > * If one fork adds/removes an m-line from the bundle, should that > be mirrored to the other forks? huh - no. I can't even imagine what this means. Think about this in a non f= orking case. A sends an offer with audio and video that forks to B and C. B= replies accepting only the audio, C replies accepting both. A is likely to= end up ending one of the forks all together but it's not like A tires to u= ntil the media from B and C.=20 >=20 > * ... >=20 > ISTM that the simplest thing we could do about this is put a statement in= the draft that this draft does not specify behavior in the case of forking= - that conforming devices are constrained to a single fork, and that behav= ior in forking cases could be a subject of future standardization. Sorry but that won't work. I don't see any actual problem identified where = bundle complicates the existing forking issues.=20 When the devices creating the offer and offer bundle, it has no idea if tha= t offer will end up being forked or not.=20 >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@iii.ca Tue Jun 4 17:33:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E795A21F9A2A for ; Tue, 4 Jun 2013 17:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTnXMFmvqYGa for ; Tue, 4 Jun 2013 17:33:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEB621F9A3C for ; Tue, 4 Jun 2013 17:33:47 -0700 (PDT) Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E377722E200; Tue, 4 Jun 2013 20:33:40 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D7CDAF9@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Wed, 5 Jun 2013 07:33:36 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16B6138A-21A7-46B5-BDA4-FE61380DB7CF@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B1C37E6A7@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F3D7CDAF9@US70UWXCHMBA05.zam.alcatel-lucent.com> To: Richard X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 00:33:58 -0000 Richard,=20 Could things like "visited realm" just need to be the same if using = Bundle? What I mean is that if two m-lines had different "visited realm" = values, then they could not be bundled? It seems unlikely to me they = would have a different "visited realm" but I don't really understand all = of this.=20 Any advice you could give on what the values should be would be great. = If more work is needed TBD may be the correct values but SECIAL would = imply that there was text in some draft that said what to do and it was = not one of the default actions.=20 Thanks, Cullen On Jun 3, 2013, at 1:22 PM, "Ejzak, Richard P (Richard)" = wrote: > Hi Christer, > Thanks for asking me to comment on 5.42. First of all, I agree with = all your other comments. I would recommend that the category for all = the items in 5.42 be listed as =93SPECIAL=94 since more work would need = to be done in 3GPP to specify their potential use with BUNDLE. These = attributes are all transport related but not in a way that can be easily = captured by the category =93TRANSPORT=94. > =20 > There are two typos in the table: =93visited realm=94 should be = =93visited-realm=94 and the second occurrence of =93omr-m-att=94 should = be =93omr-m-bw=94. > =20 > Richard > =20 > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, May 31, 2013 2:33 AM > To: mmusic@ietf.org; suhasietf@gmail.com; Ari Ker=E4nen; Flemming = Andreasen (fandreas@cisco.com) > Cc: Ejzak, Richard P (Richard) > Subject: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: = sections 5.22, 5.40, 5.41, 5.42 > =20 > Hi, > =20 > I was requested to review the attributes listed in sections 5.22, = 5.40, 5.41 and 5.42. > =20 > However, first I have a general comment on the document: > =20 > For some attributes (e.g. MSRP-CEMA), there is note text saying: > =20 > =93Not recommended due to legacy interop purposes=94 > =20 > Making such statements is completely outside the scope of the = document. The document is about multiplexing, and how/if attributes are = affected. > =20 > There is also similar note text saying: > =20 > =93Not recommended due to interop purposes=94 > =20 > Now, for the 3GPP defined attributes you could say =93Usage only = defined for IMS=94, or something. But, again, it=92s not within the = scope of this document to recommend against using things. > =20 > =85unless, of course, there from a multiplexing perspective is a = reason to do so, and they should be listed under the NOT RECOMMENDED = category: > =20 > =20 > 5.22 > =20 > = +------------+---------------------------------+---------+----------+ > | Name | Notes | Current | Category = | > = +------------+---------------------------------+---------+----------+ > | msrp-cema | | M | NORMAL = | > | | | | = | > | | | | = | > = +------------+---------------------------------+---------+----------+ > =20 > =20 > 5.40 > =20 > = +-------------+--------------------------------+---------+----------+ > | Name | Notes | Current | Category = | > = +-------------+--------------------------------+---------+----------+ > | g.3gpp.cat | Usage defined for the IP | M | NORMAL = | > | | Multimedia Subsystem [ref] | | = | > | | | | = | > = +-------------+--------------------------------+---------+----------+ > =20 > =20 > 5.41 > =20 > = +-------------+--------------------------------+---------+----------+ > | Name | Notes | Current | Category = | > = +-------------+--------------------------------+---------+----------+ > | g.3gpp.crs | Usage defined for the IP | M | NORMAL = | > | | Multimedia Subsystem [ref] | | = | > | | | | = | > = +-------------+--------------------------------+---------+----------+ > =20 > =20 > 5.42 > =20 > This is actually an interesting one, and needs a little more = investigation. So, I=92ll have to come back on that one. It would be = good if Richard Ejzak, who is the =93architect=94 behind the attributes, = could take a look :) > =20 > = +------------------+---------------------------+---------+----------+ > | Name | Notes | Current | Category = | > = +------------------+---------------------------+---------+----------+ > | secondary-realm | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | visited realm | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-m-cksum | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-s-cksum | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-m-att | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-s-att | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-s-bw | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-m-att | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > | omr-codecs | Usage defined for the IP | M | TBD = | > | | Multimedia Subsystem [ref]| | = | > | | | | = | > = +------------------+---------------------------+---------+----------+ > =20 > =20 > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Tue Jun 4 19:10:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FC921F96FE for ; Tue, 4 Jun 2013 19:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.574 X-Spam-Level: X-Spam-Status: No, score=-101.574 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lhVs34eF3Ly for ; Tue, 4 Jun 2013 19:10:33 -0700 (PDT) Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCC21F93E0 for ; Tue, 4 Jun 2013 19:10:33 -0700 (PDT) Received: from BLU169-W137 ([65.55.116.72]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jun 2013 19:09:34 -0700 X-TMN: [4SZh+N3ixlqv+0HDHzqIc0E4aqbhiCow7p3O/TloOT0=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d7fce800-06cb-4036-af6c-bdf6e1ce9114_" From: Bernard Aboba To: Cullen Jennings Date: Tue, 4 Jun 2013 19:09:33 -0700 Importance: Normal In-Reply-To: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2013 02:09:34.0074 (UTC) FILETIME=[B8E8CDA0:01CE6191] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 02:10:45 -0000 --_d7fce800-06cb-4036-af6c-bdf6e1ce9114_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said:=20 > Imagine Alice sends an offer containing=20 >=20 > On May 27=2C 2013=2C at 10:56 AM=2C Paul Kyzivat = wrote: >=20 > > m=3Daudio 49172 RTP/AVP 96 > > a=3Dssrc:2222 cname:alice@example.com > > a=3Drtpmap:96 G7291/16000 >=20 > Let say that an offer sent like the above. That means nothing about the S= SRC for the packets that Alice will receive. And it is likely to receive RT= P packets before it receives an answer in some important scenarios.=20 >=20 > So a RTP packet SSRC 3333 arrives. There's no information from the SSRC a= bout what m-line it matches too (but RTCP for it can be sent).=20 =20 [BA] Yes=2C there is no SSRC info but you do have the PT. Assuming that th= e RTP packet has a PT of 96 and that PT value is unique among all m lines (= with BUNDLE)=2C then you know what m line the RTP packet is referring to=2C= and that it represents an audio packet.=20 > Now an answer from Bob arrives with=20 >=20 > m=3Daudio 55555 RTP/AVP 96 > a=3Dssrc:4444 cname:bob@example.com > a=3Drtpmap:96 G7291/16000 >=20 > Now a packet with SSRC 4444 arrives. That might be from Bob=2C but here's= the rub. It might be from Charlie. If there was an SSRC collisions between= Bob and Charlie=2C it will be awhile before some SDP shows up that says th= at there was a collisions and now Bob is using SSRC 5555.=20 =20 [BA] I understand why this can happen if Bob is an RTP translator=2C but if= Bob is another browser=2C why would packets from Charlie be received on a = peerConnection between Alice and Bob?=20 > This is all a disaster and the best solutions to it IMHO would be to defi= ne a new RTP Header extension that carries and identifier and that Alice ca= n tell Bob in the SDP offer what value to put in the identifier for the RTP= from Bob to Alice.=20 =20 [BA] RTP extensions are optional=2C so even if you define one=2C you've go= t to be prepared to handle SSRCs that aren't pre-declared anyway=2C at leas= t according to the RTP usage document.=20 = --_d7fce800-06cb-4036-af6c-bdf6e1ce9114_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said:

>=3B Imag= ine Alice sends an offer containing
>=3B
>=3B On May 27=2C 201= 3=2C at 10:56 AM=2C Paul Kyzivat <=3Bpkyzivat@alum.mit.edu>=3B wrote:>=3B
>=3B >=3B m=3Daudio 49172 RTP/AVP 96
>=3B >=3B a= =3Dssrc:2222 cname:alice@example.com
>=3B >=3B a=3Drtpmap:96 G7291/= 16000
>=3B
>=3B Let say that an offer sent like the above. That = means nothing about the SSRC for the packets that Alice will receive. And i= t is likely to receive RTP packets before it receives an answer in some imp= ortant scenarios.
>=3B
>=3B So a RTP packet SSRC 3333 arrives. = There's no information from the SSRC about what m-line it matches too (but = RTCP for it can be sent).
 =3B
[BA] Yes=2C there is no SSRC info= but you do have the PT. =3B Assuming that the RTP packet has a PT of 9= 6 and that PT value is unique among all m lines (with BUNDLE)=2C then you k= now what m line the RTP packet is referring to=2C and that it represents an= audio packet.

>=3B Now an answer from Bob arrives with
>= =3B
>=3B m=3Daudio 55555 RTP/AVP 96
>=3B a=3Dssrc:4444 cname:bo= b@example.com
>=3B a=3Drtpmap:96 G7291/16000
>=3B
>=3B Now= a packet with SSRC 4444 arrives. That might be from Bob=2C but here's the = rub. It might be from Charlie. If there was an SSRC collisions between Bob = and Charlie=2C it will be awhile before some SDP shows up that says that th= ere was a collisions and now Bob is using SSRC 5555.
 =3B
[BA] I= understand why this can happen if Bob is an RTP translator=2C but if Bob i= s another browser=2C why would packets from Charlie be received on =3Ba=  =3BpeerConnection between Alice and Bob? =3B

>=3B This is= all a disaster and the best solutions to it IMHO would be to define a new = RTP Header extension that carries and identifier and that Alice can tell Bo= b in the SDP offer what value to put in the identifier for the RTP from Bob= to Alice.
 =3B
[BA] =3B RTP extensions are optional=2C so e= ven if you define one=2C you've got to be prepared to handle SSRCs that are= n't pre-declared anyway=2C at least according to the RTP usage document.
= --_d7fce800-06cb-4036-af6c-bdf6e1ce9114_-- From fandreas@cisco.com Tue Jun 4 19:29:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6384D21F9B20 for ; Tue, 4 Jun 2013 19:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spw2ALCzE4vB for ; Tue, 4 Jun 2013 19:29:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4530021F9B33 for ; Tue, 4 Jun 2013 19:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2701; q=dns/txt; s=iport; t=1370398882; x=1371608482; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hBEPERZZuXsT6gmKcZ+0+y89kdwcFeVSYDmeVzHwJrg=; b=JjoDR7kZzxOKLzdk3ORS2VsDaf6KiWYLHYlPRzdpSxH0sf5/1TWZZbJA CtHlAR0CrNhMnZuQ7PAsHHCI5u2PZG+LIH8B6IfV6nXCBvZF01toSdERG 3TQAulTKVoCe1KAhq//vsrulVJPGCcl/MSeTmshl+EiZ9+04GE8j3Uehd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAASgrlGrRDoJ/2dsb2JhbABagwkwvyqBABZ0giMBAQEDAQEBATU2CgEFCwsOCgkWDwkDAgECARUwBg0BBQIBAQWHfgUNvUyPJAeDWwOXP4EpkBeDKyA X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="79759467" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 05 Jun 2013 02:21:02 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.16.115]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r552L1UT025943; Wed, 5 Jun 2013 02:21:01 GMT Message-ID: <51AEA08D.8090103@cisco.com> Date: Tue, 04 Jun 2013 22:21:01 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> In-Reply-To: <51A87F91.2080500@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , mmusic@ietf.org Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:29:09 -0000 On 5/31/13 6:46 AM, Emil Ivov wrote: > Dear chairs, > > Could you please also consider the following draft for the interim > meeting agenda: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > Sure, however I could use some clarification here. On one hand, the draft falls squarely in the middle of the overall "Plan" discussion we have and hence is highly relevant, but at the same time, if I understand correctly, the draft is not asking MMUSIC to do anything in terms of protocol development. Rather, if this approach is adopted, it would be more of an RTCWeb usage document specifying how one could use several different mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't seem to be a "mandatory to implement" mechanism for guaranteeing interoperability (in contrast to Plan A/B), but rather there are references to "app specific signalling" mechanisms, etc. Am I missing something here ? > I apologise if not stating this earlier has introduced any confusion. > No worries. Thanks -- Flemming > Regards, > Emil > > On 30.05.13, 21:56, IESG Secretary wrote: >> Greetings, >> >> This is to announce a(nother) virtual interim meeting for the MMUSIC >> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am >> Pacific Time. The goal of this meeting is to come to a resolution on the >> so-called "Plan A" or "Plan B" approach related to SDP signaling needed >> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or >> very few "m=" lines and to what extent is there sub-negotation and >> signaling at the SSRC level). >> >> A more detailed agenda and logistics will be sent out separately on the >> MMUSIC mailing list. For now, people should take a close look at the >> following two drafts: >> >> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >> >> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >> >> You may also want to look at >> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >> >> >> Thanks >> >> -- Ari & Flemming (MMUSIC co-chairs) >> >> >> PS: Per our previous interim meeting announcement, we tried to schedule >> a longer and in-person physical interim meeting, however it has proven >> impossible to find a set of dates where we could get critical mass for >> such a meeting. Scheduling even a virtual interim before the Berlin IETF >> has been surprisingly difficult with the above date being the only >> viable option at this point. >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From bernard_aboba@hotmail.com Tue Jun 4 19:41:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7790021F9A9F for ; Tue, 4 Jun 2013 19:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.261 X-Spam-Level: X-Spam-Status: No, score=-101.261 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKoQXYrjEG7m for ; Tue, 4 Jun 2013 19:41:22 -0700 (PDT) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by ietfa.amsl.com (Postfix) with ESMTP id BD16721F9A63 for ; Tue, 4 Jun 2013 19:41:22 -0700 (PDT) Received: from BLU403-EAS336 ([65.55.116.73]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jun 2013 19:41:22 -0700 X-EIP: [rhS7lUt3VEkUSay2R4QJ0NIoso0Uekrj] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51AEA08D.8090103@cisco.com> Date: Tue, 4 Jun 2013 19:41:17 -0700 To: Flemming Andreasen X-OriginalArrivalTime: 05 Jun 2013 02:41:22.0598 (UTC) FILETIME=[2A7A7460:01CE6196] Cc: Ari Keranen , "mmusic@ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:41:27 -0000 Yes, you are missing something. No plan analyzes issues with both Plan A and= Plan B and describes how to fix them. As they stand, both Plan A nor Plan B= result in O/A exchanges that aren't needed and will break congestion contro= l. Also, neither satisfies the requirements of the RTP usage doc or is compa= tible with a number of legacy implementations. No plan offers a solution to= these and other issues.=20 On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" wrote:= >=20 > On 5/31/13 6:46 AM, Emil Ivov wrote: >> Dear chairs, >>=20 >> Could you please also consider the following draft for the interim meetin= g agenda: >>=20 >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > Sure, however I could use some clarification here. On one hand, the draft f= alls squarely in the middle of the overall "Plan" discussion we have and hen= ce is highly relevant, but at the same time, if I understand correctly, the d= raft is not asking MMUSIC to do anything in terms of protocol development. R= ather, if this approach is adopted, it would be more of an RTCWeb usage docu= ment specifying how one could use several different mechanisms (and possibly= WebRTC APIs) to implement signaling. There doesn't seem to be a "mandatory t= o implement" mechanism for guaranteeing interoperability (in contrast to Pla= n A/B), but rather there are references to "app specific signalling" mechani= sms, etc. Am I missing something here ? >=20 >=20 >> I apologise if not stating this earlier has introduced any confusion. > No worries. >=20 > Thanks >=20 > -- Flemming >=20 >> Regards, >> Emil >>=20 >> On 30.05.13, 21:56, IESG Secretary wrote: >>> Greetings, >>>=20 >>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am >>> Pacific Time. The goal of this meeting is to come to a resolution on the= >>> so-called "Plan A" or "Plan B" approach related to SDP signaling needed >>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=3D" lines o= r >>> very few "m=3D" lines and to what extent is there sub-negotation and >>> signaling at the SSRC level). >>>=20 >>> A more detailed agenda and logistics will be sent out separately on the >>> MMUSIC mailing list. For now, people should take a close look at the >>> following two drafts: >>>=20 >>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>=20 >>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>=20 >>> You may also want to look at >>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>=20 >>>=20 >>> Thanks >>>=20 >>> -- Ari & Flemming (MMUSIC co-chairs) >>>=20 >>>=20 >>> PS: Per our previous interim meeting announcement, we tried to schedule >>> a longer and in-person physical interim meeting, however it has proven >>> impossible to find a set of dates where we could get critical mass for >>> such a meeting. Scheduling even a virtual interim before the Berlin IETF >>> has been surprisingly difficult with the above date being the only >>> viable option at this point. >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Tue Jun 4 21:44:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4F321F85E0 for ; Tue, 4 Jun 2013 21:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc37bEW8af0E for ; Tue, 4 Jun 2013 21:44:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5821F9A3C for ; Tue, 4 Jun 2013 21:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3955; q=dns/txt; s=iport; t=1370407486; x=1371617086; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T5p9FTntbKTVU0fiPpU4ywArT5HlpUKy1tyOfzYTs90=; b=P5gDwjrAgUse9gIjODljVJ8vV9HswBgeouR3bHl1LetID8i4AI0iWahs TkqZPBBPkrB8LbltivHxucNu7dUZwipUnm7AzZVeCnB7j8Sza3HKTniz2 idHc0wAJ5B3PW+W1CIcG5xomYjjl3/ge9SA9kvCqa81YOyiMoeEPVI0w5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAC7BrlGtJV2Y/2dsb2JhbABagwkwvyqBARZ0giMBAQEDAQEBATU2CgEFCwsYCRYPCQMCAQIBFTAGDQEFAgEBBRKHbAYMvG2PJAeDWwOXP4EpkBeDKyA X-IronPort-AV: E=Sophos;i="4.87,804,1363132800"; d="scan'208";a="218975472" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jun 2013 04:44:45 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.252.185]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r554ihAG011480; Wed, 5 Jun 2013 04:44:44 GMT Message-ID: <51AEC23B.1010509@cisco.com> Date: Wed, 05 Jun 2013 00:44:43 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "mmusic@ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 04:44:51 -0000 On 6/4/13 10:41 PM, Bernard Aboba wrote: > Yes, you are missing something. No plan analyzes issues with both Plan A and Plan B and describes how to fix them. As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed and will break congestion control. Also, neither satisfies the requirements of the RTP usage doc or is compatible with a number of legacy implementations. No plan offers a solution to these and other issues. I understand that "no plan" sees issues with Plan A and Plan B as currently defined. What I don't understand is what extensions or updates to SDP signaling mechanism are being proposed here and hence which part of this discussion belongs in MMUSIC as opposed to RTCWeb simply specifying how it wants to use a set of current/developing mechanisms (or rely on app specific mechanisms, etc.) ? In other words, what does "no plan" seek from MMUSIC ? Thanks -- Flemming > On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" wrote: > >> On 5/31/13 6:46 AM, Emil Ivov wrote: >>> Dear chairs, >>> >>> Could you please also consider the following draft for the interim meeting agenda: >>> >>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> Sure, however I could use some clarification here. On one hand, the draft falls squarely in the middle of the overall "Plan" discussion we have and hence is highly relevant, but at the same time, if I understand correctly, the draft is not asking MMUSIC to do anything in terms of protocol development. Rather, if this approach is adopted, it would be more of an RTCWeb usage document specifying how one could use several different mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't seem to be a "mandatory to implement" mechanism for guaranteeing interoperability (in contrast to Plan A/B), but rather there are references to "app specific signalling" mechanisms, etc. Am I missing something here ? >> >> >>> I apologise if not stating this earlier has introduced any confusion. >> No worries. >> >> Thanks >> >> -- Flemming >> >>> Regards, >>> Emil >>> >>> On 30.05.13, 21:56, IESG Secretary wrote: >>>> Greetings, >>>> >>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am >>>> Pacific Time. The goal of this meeting is to come to a resolution on the >>>> so-called "Plan A" or "Plan B" approach related to SDP signaling needed >>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or >>>> very few "m=" lines and to what extent is there sub-negotation and >>>> signaling at the SSRC level). >>>> >>>> A more detailed agenda and logistics will be sent out separately on the >>>> MMUSIC mailing list. For now, people should take a close look at the >>>> following two drafts: >>>> >>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>> >>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>> >>>> You may also want to look at >>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>> >>>> >>>> Thanks >>>> >>>> -- Ari & Flemming (MMUSIC co-chairs) >>>> >>>> >>>> PS: Per our previous interim meeting announcement, we tried to schedule >>>> a longer and in-person physical interim meeting, however it has proven >>>> impossible to find a set of dates where we could get critical mass for >>>> such a meeting. Scheduling even a virtual interim before the Berlin IETF >>>> has been surprisingly difficult with the above date being the only >>>> viable option at this point. >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > . > From christer.holmberg@ericsson.com Tue Jun 4 22:56:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6121F997B for ; Tue, 4 Jun 2013 22:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcktcAvx4ZDP for ; Tue, 4 Jun 2013 22:56:11 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ACC5121F997A for ; Tue, 4 Jun 2013 22:56:10 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-f9-51aed2f8f138 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9C.F5.09795.8F2DEA15; Wed, 5 Jun 2013 07:56:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 07:56:08 +0200 From: Christer Holmberg To: Cullen Jennings Thread-Topic: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) Thread-Index: Ac5cYL6Xjkqad1ozQWuoyGt6QctbSAA6uR4AAF6XlAAAPeC20AA3lFgAAEVSgPA= Date: Wed, 5 Jun 2013 05:56:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C382E9A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3812FB@ESESSMB209.ericsson.se> <5CDDB46C-4F09-4812-BF85-24970E466EE5@iii.ca> In-Reply-To: <5CDDB46C-4F09-4812-BF85-24970E466EE5@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre7PS+sCDX7eZrJY8focu8WH9T8Y LaYuf8ziwOyxZMlPJo/L5z8yekx+3MYcwBzFZZOSmpNZllqkb5fAlXFizVz2gl7+isNL17A2 MD7i7mLk4JAQMJGYftKgi5ETyBSTuHBvPVsXIxeHkMBhRokf9xuZIZzFjBI/fxxhA2lgE7CQ 6P6nDdIgIqAscW7HXWYQm1nAVaLl0xcWEFtYwFFi99UzTBA1ThJPf61hh7D9JHb0/mUEsVkE VCQunH4LVsMr4CtxZ24P1K7TTBKLu06A7eIUsJJY+McOpIYR6Ljvp9YwQewSl7j1ZD4TxNEC Ekv2nGeGsEUlXj7+xwrxl6LE8n45iHIdiQW7P7FB2NoSyxa+ZoZYKyhxcuYTlgmMYrOQTJ2F pGUWkpZZSFoWMLKsYmTPTczMSS8338QIjJmDW34b7GDcdF/sEKM0B4uSOK8+7+JAIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYzW3V3+F/mfx51s+scRK5Sq65b98NTEuyKySTVut1YV7n4t GHJzP/OjHwfk1e6s3jZHt/af3OqvZ2sXbe9J+nU7xzPn073XAbZqW0WZ+LwbGrbWHglRylh1 yLogfcFxYZ0tBQt3W8g8r75pcyxARW+/fdmt/andW+Wnda3krpl9rGi6ufPJzFdKLMUZiYZa zEXFiQCDE0aNZwIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 05:56:17 -0000 Hi, >> 6.4.6. Removing a media description from a BUNDLE group >>=20 >> When generating the SDP Answer, if the Answerer wants to remove an >> "m=3D" line from a BUNDLE group (without rejecting the "m=3D" line),it >> MUST NOT include the "m=3D" line in a BUNDLE group. In addition, the >> SDP Answer MUST not add its local bundle address to the "m=3D" line. >>=20 >> An Answerer MUST NOT, in the SDP Answer, remove an "m=3D" line from a >> BUNDLE group, unless the "m=3D" line had unique address information in >> the associated SDP Offer. >>=20 >> NOTE: The reason for the restriction above is that, if the "m=3D" line >> would be removed from the BUNDLE group, the address information would >> be identical to the "m=3D" lines remaining in the BUNDLE group. >>=20 >> OPEN: The decision for allowing a media description with port zero >> values inside a BUNDLE group is pending on update for RFC 5888. >>=20 >> I thought we had agreed to no bundle splitting. >>=20 >> I am not sure what you mean by "splitting", but this is not about moving= an m- line from one BUNDLE group to another=20 >> BUNDLE group, but to move it outside an BUNDLE group all together. Peopl= e wanted to allow that in the case where the=20 >> Offer contains different ports, but if you disagree we need to discuss i= t further. >=20 > One case that is brought up for this is a conference bridge where the voi= ce and video go to different IP addresses. The=20 > browser makes a offer to the conference bridge and can offer all the voic= e and video in one bundle, but the answer from=20 > the bridge keeps all the video in the bundle but puts the audio outside o= f any bundle. It did not split a bundle into two=20 > bundles but for all the things offered in the bundle, the answer said yes= to some and no to others about them being in the bundle.=20 Correct. Regards, Christer From christer.holmberg@ericsson.com Tue Jun 4 23:03:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED9E21F9A0A for ; Tue, 4 Jun 2013 23:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw+hz+4uSToj for ; Tue, 4 Jun 2013 23:03:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A04BB21F99FC for ; Tue, 4 Jun 2013 23:02:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-ac-51aed48e5588 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 69.41.15700.E84DEA15; Wed, 5 Jun 2013 08:02:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 08:02:54 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgioAlxfJgAAbOWHAAA6xPoAAII/SwA== Date: Wed, 5 Jun 2013 06:02:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C382EB7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> <51ACFB79.1080207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se> <51AE14C5.6000701@alum.mit.edu> In-Reply-To: <51AE14C5.6000701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvrW7flXWBBtfadCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj0O+X7AV/lSq+7DrP2sD4WLqLkYNDQsBE YsenzC5GTiBTTOLCvfVsXYxcHEIChxkljjb2QzmLGSUutOxgB2lgE7CQ6P6nDWKKCGhITNqq BmIyC6hLXF0cBDJGWEBX4uTuR0wgtoiAnsTnW/eZIewwiS03L7OBlLMIqEgsuRkJYvIK+Eqc OSAGsWcnk8SMnxuZQeKcAjoSC64ag3QyAh32/dQasInMAuISt57MZ4I4WEBiyZ7zzBC2qMTL x/9YIX5SlFjeLwdRDjRl9yc2CFtbYtnC12DlvAKCEidnPmGZwCg2C8nUWUhaZiFpmYWkZQEj yypG9tzEzJz0csNNjMC4OLjlt+4OxlPnRA4xSnOwKInz6vEuDhQSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAqLFVzipow/W3rwIOKtROPettcOfXT/00w0e220J7nHsDPH3kkieptzY1aB08 7sPIx/5k+czW2qXLRN+5zMr9WXTortzp+kOic7Mm6TEZPWPs/jujX11+i4Du+lqr1ZyeAm2F 6568uBclb2J/i4PN4vjxj3nnU+Lq+BZaZH/N3hjF9CtboTdTiaU4I9FQi7moOBEAhmIiH1kC AAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 06:03:09 -0000 Hi, >>>>>> I'll throw the ball out with suggesting the following ones: >>>>>> >>>>>> -*Bundle restart offer* (different port value, currently referred=20 >>>>>> to as "first offer") >>>>>> >>>>>> The reason I use "restart" wording is because this is used, no=20 >>>>>> matter whether in the beginning of the session or mid-session, to=20 >>>>>> (re-)negotiate the usage of BUNDLE, and the bundle address=20 >>>>>> information selection. >>>>>> >>>>>> -*Bundle sync offer* (identical port value, currently referred to=20 >>>>>> as "second offer") >>>>>> >>>>>> The reason I used "sync" wording is because this is used to ensure=20 >>>>>> that intermediaries have correct address information for each m- lin= e. >>>>>> >>>>>> Keep in mind that we may even need to split the sync offer into=20 >>>>>> more sub types, when we get into the details of adding new m-=20 >>>>>> lines etc, but I'd like to agree a base to start from :) >>>>> >>>>> Above seems like a good start, but I'm still grappling with some=20 >>>>> things and don't know how to talk about concisely: >>>>> >>>>> I understand that the next offer after a Bundle Restart Offer will=20 >>>>> typically be a Bundle Sync Offer. But if there is another offer=20 >>>>> after a Bundle Sync Offer, and it doesn't change anything about the=20 >>>>> bundle, then is it still a Bundle Sync Offer? >>>> >>>> Currently, yes. >>> >>> I agree that without adjusting the terminology this is the only right c= hoice to make. But it is a little obscure. I'm not certain this needs to be= improved, but I thought I would suggest that it might. >>>> >>>>> Also, I don't believe the above are mutually exclusive. If I send=20 >>>>> an offer to add a new m-line to a bundle, and I give it distinct=20 >>>>> address info so that the answerer may take it out of the bundle if=20 >>>>> needed, then is that a Bundle Restart Offer or a Bundle Sync Offer?=20 >>>>> It seems to be a bit of each. And of course there may be multiple=20 >>>>> bundles described by the SDP, and these terms apply independently to = each. >>>>> >>>>> Maybe we need a couple more terms for: >>>>> >>>>> - offer that adds a new m-line to bundle using the existing bundle >>>>> address info. >>>> >>>> Technically that is a Bundle Sync Offer, but I DO agree that the wordi= ng is not good in this case - as it's not only about synchronization. >>>> >>>>> - offer that adds a new m-line to an existing bundle using unique >>>>> address info. >>>> >>>> I agree that doesn't fit the current definitions. >>>> >>>> However, we will have to agree on whether we allow that in the first p= lace, or whether the offerer will have to use 1) same address information o= r 2) different address information for ALL m- lines (Bundle Restart Offer). >>> >>> Yes, we need to settle on whether either or both of these are permitted= . >>> >>> But I can think of reasons why I might wish to use either one, and no g= ood reason not to allow both. So allowing both is my preference. >> >> I personally think we should allow BOTH 1) and 2). >> >> The question is whether we should allow 3), which is new m- line with un= ique address, while the other m- lines use the bundle address. > > I agree it is a valid question to ask. > Again, I can see how it might be useful sometimes, and I can see no reaso= n not to allow it. Its just a special case of the bundle restart offer. We could modify the definition of bundle restart offer, to allow that some = m- lines may use the same address information. It needs to be very clear, though, that such m- lines cannot be moved out o= f the BUNDLE group by the Answerer, as they don't have a unique address to = fallback to. However, the Answerer MAY still change the address for such m- lines to the= address of the added m- line - especially if the Offerer puts the mid valu= e associated with the new m- line first in the SDP group:BUNDLE attribute m= id value list. > (Note, IMO it should be ok for the very first offer to propose a bundle w= ith address info already shared among m-lines in the proposed bundle.=20 > Using that trades off potential interop issues for speed in establishing = the session.) My intention (and, that's why I appreciate all feedback I can get :) is to = make the procedures very generic, and not separate between initial and subs= equent offers (other than in examples). Regards, Christer From magnus.westerlund@ericsson.com Wed Jun 5 00:02:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A9421F9A43 for ; Wed, 5 Jun 2013 00:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbn+8scoT6Qy for ; Wed, 5 Jun 2013 00:02:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2853621F9A3C for ; Wed, 5 Jun 2013 00:02:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-1a-51aee29343d8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 12.2A.15700.392EEA15; Wed, 5 Jun 2013 09:02:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Jun 2013 09:02:43 +0200 Message-ID: <51AEE2C6.9010809@ericsson.com> Date: Wed, 5 Jun 2013 09:03:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> In-Reply-To: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre6UR+sCDT4sYrf4sP4Ho8XU5Y9Z LFZsOMDqwOzx9/0HJo8lS34yeVw+/5ExgDmKyyYlNSezLLVI3y6BK2P+s4tMBS0KFWv+P2Rs YNwj2cXIySEhYCLxubOPGcIWk7hwbz1bFyMXh5DAKUaJWzv3QznLGCXefbgHVsUroC1xfuUF NhCbRUBF4nbPCiYQm03AQuLmj0awuKhAsMSR7ZtZIOoFJU7OfAJmiwgoS5zbcRdsDrOApcSK rkawuLCAtcSzhidQy/oYJfpXXQEbxClgJfHx5iYmiPMkJba8aGeHaNaTmHK1hRHClpdo3job bKgQ0HENTR2sExiFZiHZPQtJyywkLQsYmVcxsucmZuaklxtuYgSG8MEtv3V3MJ46J3KIUZqD RUmcV493caCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRmaBj3v/nv2pueLK04dFT4OPFUaH p/HnOPfxveQXzj13+/znHRaPPkfk33YX++CZYOsc/UDiRvvl3Iemody/nWqUVXNv79u2Otvt eatkRd2CRWInExZM6Q46zrrrx/13MuFO9UcfrPhZ1S+w8O78OWIfxdUXL6j9Xrp5+qdrUv3L nyh4K3Ten6jEUpyRaKjFXFScCAAg1KW1LwIAAA== Cc: mmusic@ietf.org, Paul Kyzivat Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 07:02:57 -0000 Hi, Jumping into this late. But, I do Share almost all Colin Perkins has written on this. And I think this discussion has gotten down to the gist of things. First of all, with Bundle you will have multiple m= blocks describing the same RTP session, that combination must offer a consistent RTP session definition. Thus, each used PT number must map to a unique payload format and payload format configuration. However, I believe it is important that we do allow the same PT == codec + payload format configuration to be reused over multiple m= blocks, otherwise we will shortly run into a scarcity issue with PT numbers. On 2013-06-04 00:51, Cullen Jennings wrote: > > > Imagine Alice sends an offer containing > > On May 27, 2013, at 10:56 AM, Paul Kyzivat wrote: > >> m=audio 49172 RTP/AVP 96 >> a=ssrc:2222 cname:alice@example.com >> a=rtpmap:96 G7291/16000 > > Let say that an offer sent like the above. That means nothing about the SSRC for the packets that Alice will receive. And it is likely to receive RTP packets before it receives an answer in some important scenarios. > > So a RTP packet SSRC 3333 arrives. There's no information from the SSRC about what m-line it matches too (but RTCP for it can be sent). Not only can RTCP be sent, the packets are identified to be a new stream (due to new SSRC) and you know how to decode them. It is the binding between the m= line and any application logic on how you intended to use a stream that is missing. This is a general problem and should be solved in a general way. Yes, we could rely on requiring explicit SSRC signaling to bind it to a m= block, or we can look at solutions that include the necessary information somewhere where we are not having an issue with what arrives first, i.e. we need something that can be included in the media plane, i.e. RTP/RTCP and which can be bound to the signaling information providing the application with the intended usage of a particular set of streams. > > Now an answer from Bob arrives with > > m=audio 55555 RTP/AVP 96 > a=ssrc:4444 cname:bob@example.com > a=rtpmap:96 G7291/16000 > > Now a packet with SSRC 4444 arrives. That might be from Bob, but here's the rub. It might be from Charlie. If there was an SSRC collisions between Bob and Charlie, it will be awhile before some SDP shows up that says that there was a collisions and now Bob is using SSRC 5555. Yes, there can be a SSRC collision. However, the RTP/RTCP layer will be able to detect this, at the latest when two differnet CNAMEs claim to use SSRC 4444. > > This is all a disaster and the best solutions to it IMHO would be to define a new RTP Header extension that carries and identifier and that Alice can tell Bob in the SDP offer what value to put in the identifier for the RTP from Bob to Alice. I don't know if it is a disaster, as SSRC collision may occur but can be sorted out and offers a glitch. I think a more likely glitch is due to the general mismatch between relying on timely signaling of O/A and dynamic behaviors among the media stream. I think I am supporting the general idea of providing the "this is what this stream is used for" in RTP/RTCP. My current thinking makes me prefer a RTCP Source Description Item (SDES Item) which can also be stuck in an RTP header extension to speed up acquiring the binding when introducing a new stream and you can't really know that RTCP has made it yet. That way each m= block, can have a short "usage tag" that is sent as the SDES item for all RTP streams. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From enrico.marocco@telecomitalia.it Wed Jun 5 02:11:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7D021F880F for ; Wed, 5 Jun 2013 02:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkYqNTL4uRg5 for ; Wed, 5 Jun 2013 02:11:25 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3F621F89FF for ; Wed, 5 Jun 2013 02:11:22 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 11:11:20 +0200 Received: from MacLab.local (10.229.8.40) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 11:11:19 +0200 Message-ID: <51AF00B7.8070402@telecomitalia.it> Date: Wed, 5 Jun 2013 11:11:19 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> <51AD0AC2.2080001@jitsi.org> <51ADA539.1020505@jitsi.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050701070304070001050205" X-TI-Disclaimer: Disclaimer1 Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 09:11:38 -0000 --------------ms050701070304070001050205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/4/13 3:13 PM, Eric Rescorla wrote: > I would like to see a *complete* example with all the data flowing back= > and forth > and the API calls (even if they are mocked up) that you think the sides= will > make. Not trying to steal Emil's job, here's a rough example of how I (from a web developer PoV) would like to be allowed to do it. Required API extensions are in 5. and 8. (i.e. the .ssrc MST attributes). Regular PC setup (this already well known): http://goo.gl/cKfNf Stream add: http://goo.gl/ZNSdZ Again, this is a *rough* example. The clear advantage (from my PoV of course) is that, once the peer connection is established, the app does not have to care about additional renegotiations, but in exceptional cases (i.e. the new stream needs a new PT): no need to handle O/As crossing on the wire, nor rollbacks. The clear drawback is that, as it is now, it looks awfully ugly: tracks are attached to the existing stream for transmission, but rendered on a new stream on the receiving side. This is because the focus was on minimizing the impact on the API. It could be probably improved with more substantial changes, e.g. for allowing the instantiation of the remote stream on the receiving side before the RTP packets actually start flowing. Kind of what plan B does, but without the additional, painful, O/A+O/A exchange. Enrico --------------ms050701070304070001050205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDUw OTExMTlaMCMGCSqGSIb3DQEJBDEWBBRqKy6M1lBcO8/qxpqJP8pwIwDBLzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAPozqFZg2ffUZAF3k3hOA7bSU99e/0zm1NsBaW8c9 VlcUyGQtS5DA0XOjnjgi0b3gK9bZYO5iuB9TwwRsuzfyyoRy+xvZrnjrwWvet3pyZbN5L2Vi KioaVvOVOJxIUEVRTtSNaAxdn2OOE/eQRpL1DUkD95DOF9gF8N6WtQGekAe0l1L0X9UL81ym ip9pnptQzsxiBHxGpL9Lq4cg+NcxnzIo8mtzgVGDw6fGyPFZLA11RTshQy/7jEgU7K/Cr2zF fW5bDrnscf1r2YSVDDETZjP+QwEzCRcn9+vjBW02Du1ofgK7mvUVoJY5Y4hv08amCY5w+6Ze 6sKaUHOoi8PjXAAAAAAAAA== --------------ms050701070304070001050205-- From magnus.westerlund@ericsson.com Wed Jun 5 02:40:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA121F99F0 for ; Wed, 5 Jun 2013 02:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQuFLN1s1hIg for ; Wed, 5 Jun 2013 02:40:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7021F941F for ; Wed, 5 Jun 2013 02:40:34 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-10-51af0790ef99 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 61.EB.18006.0970FA15; Wed, 5 Jun 2013 11:40:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Jun 2013 11:40:32 +0200 Message-ID: <51AF07C5.2010907@ericsson.com> Date: Wed, 5 Jun 2013 11:41:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvre4E9vWBBjsWmVlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGU9v32Qu2CNecfbfO9YGxnbhLkZODgkBE4mtr/awQ9hiEhfu rWfrYuTiEBI4xSjxcvcjRghnGaPE+obTjCBVvALaEvee9IB1sAioSGzZv5sVxGYTsJC4+aOR DcQWFQiWOLJ9MwtEvaDEyZlPwGwRAXWJ1s19YPXCAgYS/a/mQm2WlNjyoh3MZhbQk5hytYUR wpaXaN46mxnEFgLa29DUwTqBkX8WkrGzkLTMQtKygJF5FSN7bmJmTnq50SZGYEAd3PJbdQfj nXMihxilOViUxHn1eBcHCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCccex6gklUQ8WVUJHz e8KmhB7Y2BNokxf3T8tP9MujeF5frp+V/peCpDL2TDqmeuON26SQ+l9LJzBfZsm0Vdmne9F/ T7npFwfdvK8PP776d8t+15HXnLsOzec4mi2srNsiVOi65LOgmeiNC/VbD7NntzGmsi6LMpuj Lez+7/+tedxXM+ZtVjigxFKckWioxVxUnAgAGvCKqvYBAAA= Subject: [MMUSIC] A High level view of multiple m= blocks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 09:40:41 -0000 MMUSIC WG, I wanted to share my personal view of how I look at the problems around SDP that has arisen due to bundle and multi-stream (multiple SSRCs) usage of RTP that is coming from use cases not only in WebRTC but also in CLUE. Bundle introduces multiple m= blocks that configures a single RTP session. So without killing Bundle we have to sort this out. Preferably this can be done in a reasonably timely manner. A really important aspect of using multiple m= blocks for a single RTP session is that we need to decide when one should use multiple m= blocks and when not. There are multiple different reasons listed in the contributions and from my perspective we need to decide in each case if that warrants to use different m= blocks or not. This is really a scale, a scale between two extremes. A) Different media types (audio, video, text) are the only reason to use different m= blocks. B) Each individual RTP stream (SSRC) shall have its own m= block to describe it. Considering the arguments I have heard so far, I think we are ending up somewhere in the middle between these extremes. That requires us to write rules and guidance on when it is expected to create different m= block and when it is not. I am proposing that people consider what reasons exist to create different m= blocks. Also when different m= blocks cannot be applied. By looking at individual reasons, the issue can be split up into individual questions. That way we might get individual questions we actually can discuss and agree on one after one. Not requiring people to accept the grand plans, this only results in people wanting a slight variation. Divide and conquer the problem into something we can make progress on. Some individual questions that I believe needs to be considered are: - Different sets of acceptable resolutions for video - Different allowed bandwidth spans between media streams - Different usages in application, i.e. main video, thumbnails, document camera - Simulcast versions - Layered encoding versions - Different rendering screens - Retransmission or FEC usage I would also note that there are questions that are separable from this general question if one should apply different m= lines to the issue or not. These questions and issues must also be identified and treated separately. Such a question for example is how to deal with dynamic behaviors from media streams, where stream is frequently coming and going, or changes role in the application. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Wed Jun 5 03:07:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58A21F9AB2; Wed, 5 Jun 2013 03:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ujeqOALYx15; Wed, 5 Jun 2013 03:07:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A72A021F9AA6; Wed, 5 Jun 2013 03:07:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130605100739.23272.30996.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 03:07:39 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 10:07:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-06.txt Pages : 21 Date : 2013-06-05 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From emil@sip-communicator.org Wed Jun 5 03:37:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC31121F99AA for ; Wed, 5 Jun 2013 03:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz4Q-83speH8 for ; Wed, 5 Jun 2013 03:37:20 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8305121F9996 for ; Wed, 5 Jun 2013 03:37:19 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so1191862wgh.24 for ; Wed, 05 Jun 2013 03:37:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=DLsorpt4oCkn/ovTm8umEuBt+fJ95sygBKe99Wi82l4=; b=fFsrB3LCRdmXc13cb9l+rZwASwMdsIi8OZspI+BhS+83+uSuoQbcqXY95xB7HZMmB2 qDysdaMNIslbGxN/F3JLa4jiTC/T/F34fZgLIrp+oGhZP/MRdag+tI7CnI5mqZHYSHMF kZRME92jx9zT+m1r5wKVns9p53AjWUf22T44uArDl9KfEwyUdiqZaJtAFGD4mAXPY1M0 3+x18I6CRDw1rl0IbdtWfjR7gP5gWyDZ3UsIsz4859ErT+o5tifgcB6hqZO1C4YY8WFZ heYGeifJQfOHa6iZNTPy56xfh3uZ2PPvLX7OUmplZJ4pExtxvOIDr4FGSC0fPZIckbMW GzrQ== X-Received: by 10.180.90.70 with SMTP id bu6mr5851708wib.34.1370428638333; Wed, 05 Jun 2013 03:37:18 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id q13sm9422256wie.8.2013.06.05.03.37.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 03:37:17 -0700 (PDT) Message-ID: <51AF14DB.5020009@jitsi.org> Date: Wed, 05 Jun 2013 12:37:15 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Flemming Andreasen References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> In-Reply-To: <51AEC23B.1010509@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkxES6Ao6qvCty/FQGO4kI4ai25NQZXIz1JweT1+C4l020XjxDawZZbzq1GcfoS4M8nHuWG Cc: Ari Keranen , "mmusic@ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 10:37:21 -0000 Hey Flemming, You are right, there are no specific SDP updates that "No Plan" is asking from mmusic. That said however, the same is pretty much true about Plan A and Plan B. They both discuss ways of using SDP and the extensions that might be implied to these ways are considered mostly collateral: Plan A: This document describes a *modest* set of extensions to SDP which allow it to cleanly handle arbitrary numbers of flows while still retaining a large degree of backward compatibility with *existing* and non-RTCWEB endpoints. Plan B: Plan B mostly uses *existing* IETF standards, introducing a single new draft [I-D.lennox-mmusic-sdp-source-selection] to specify how individual media sources can be accepted/rejected at the SSRC level via SDP. I might be off, but it was my understanding that the interim meeting was not going to be about these specific extensions (which could possibly be specified regardless of which Plan we go for) but mostly about the best ways to use SDP with multiple sources. The choices we make could have an impact on multiple working groups, which, I assumed, was the main reason for having the discussion mmmusic. In that sense I see "No Plan" as quite related to this discussion. Am I right in assuming this and if so does the above answer your question? Emil On 05.06.13, 06:44, Flemming Andreasen wrote: > > On 6/4/13 10:41 PM, Bernard Aboba wrote: >> Yes, you are missing something. No plan analyzes issues with both Plan A and Plan B and describes how to fix them. As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed and will break congestion control. Also, neither satisfies the requirements of the RTP usage doc or is compatible with a number of legacy implementations. No plan offers a solution to these and other issues. > I understand that "no plan" sees issues with Plan A and Plan B as > currently defined. What I don't understand is what extensions or updates > to SDP signaling mechanism are being proposed here and hence which part > of this discussion belongs in MMUSIC as opposed to RTCWeb simply > specifying how it wants to use a set of current/developing mechanisms > (or rely on app specific mechanisms, etc.) ? In other words, what does > "no plan" seek from MMUSIC ? > > Thanks > > -- Flemming > >> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" wrote: >> >>> On 5/31/13 6:46 AM, Emil Ivov wrote: >>>> Dear chairs, >>>> >>>> Could you please also consider the following draft for the interim meeting agenda: >>>> >>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>> Sure, however I could use some clarification here. On one hand, the draft falls squarely in the middle of the overall "Plan" discussion we have and hence is highly relevant, but at the same time, if I understand correctly, the draft is not asking MMUSIC to do anything in terms of protocol development. Rather, if this approach is adopted, it would be more of an RTCWeb usage document specifying how one could use several different mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't seem to be a "mandatory to implement" mechanism for guaranteeing interoperability (in contrast to Plan A/B), but rather there are references to "app specific signalling" mechanisms, etc. Am I missing something here ? >>> >>> >>>> I apologise if not stating this earlier has introduced any confusion. >>> No worries. >>> >>> Thanks >>> >>> -- Flemming >>> >>>> Regards, >>>> Emil >>>> >>>> On 30.05.13, 21:56, IESG Secretary wrote: >>>>> Greetings, >>>>> >>>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>>> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am >>>>> Pacific Time. The goal of this meeting is to come to a resolution on the >>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling needed >>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or >>>>> very few "m=" lines and to what extent is there sub-negotation and >>>>> signaling at the SSRC level). >>>>> >>>>> A more detailed agenda and logistics will be sent out separately on the >>>>> MMUSIC mailing list. For now, people should take a close look at the >>>>> following two drafts: >>>>> >>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>>> >>>>> You may also want to look at >>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>>> >>>>> >>>>> Thanks >>>>> >>>>> -- Ari & Flemming (MMUSIC co-chairs) >>>>> >>>>> >>>>> PS: Per our previous interim meeting announcement, we tried to schedule >>>>> a longer and in-person physical interim meeting, however it has proven >>>>> impossible to find a set of dates where we could get critical mass for >>>>> such a meeting. Scheduling even a virtual interim before the Berlin IETF >>>>> has been surprisingly difficult with the above date being the only >>>>> viable option at this point. >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > -- https://jitsi.org From emil@sip-communicator.org Wed Jun 5 03:48:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B82821F9A01 for ; Wed, 5 Jun 2013 03:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqssAhdDuG1m for ; Wed, 5 Jun 2013 03:48:49 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3570E21F99ED for ; Wed, 5 Jun 2013 03:48:48 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hj6so1138006wib.11 for ; Wed, 05 Jun 2013 03:48:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ZJ6+v/4FAEeus9zRhfxfZo3Bh174CJ/uFMN0oh+XyXU=; b=Nhhxv03MtPwJxjgqnDfkiSfjw0i3pwRwu5OeRdCKqrkV/j+qzA0G2ZSuYo7KKSQkjC OUqbdOvvCn+QEOnVAFe92vVJPLJtT8Nq396jWCx/qFJf4t/kkUR1t+brXcymY8fL5x9M jMW/831IxDM+jKOYKlIm3e/LXL3Y1SxNeO3mqJLdTYZ3EfxTzgw74y3lDjqLN4xCMci1 r+HTlUlv2pMoZiQHHvu3YV8bprlZjKEbX05eCif+qu07PCIILJejl+meR/rO86HZuk4o kiNoYF/cX6VxtlW2mFSF9eMCqstj77Wy6rMY73Hhs4ZhudI6FGuCo1Bwi3Uu23k2h4rN pxCg== X-Received: by 10.180.87.162 with SMTP id az2mr6069814wib.10.1370429327992; Wed, 05 Jun 2013 03:48:47 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id cw8sm9470085wib.7.2013.06.05.03.48.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 03:48:47 -0700 (PDT) Message-ID: <51AF178D.2040406@jitsi.org> Date: Wed, 05 Jun 2013 12:48:45 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Enrico Marocco References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8EAB7.8080206@jitsi.org> <51ACD224.8080100@jitsi.org> <51AD042E.2090302@jitsi.org> <51AD0AC2.2080001@jitsi.org> <51ADA539.1020505@jitsi.org> <51AF00B7.8070402@telecomitalia.it> In-Reply-To: <51AF00B7.8070402@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkISisE95jNE1RVp1fj5+R4TD3YfrqiRUZzTxNkdngNG2eB/ES5pxJZwkcEp+baKQw0cyOF Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 10:48:50 -0000 On 05.06.13, 11:11, Enrico Marocco wrote: > On 6/4/13 3:13 PM, Eric Rescorla wrote: >> I would like to see a *complete* example with all the data flowing back >> and forth >> and the API calls (even if they are mocked up) that you think the sides will >> make. > > Not trying to steal Emil's job, Steal away! The JS API part of this is something that we haven't even started designing yet so any feedback is welcome. > here's a rough example of how I (from a > web developer PoV) would like to be allowed to do it. Required API > extensions are in 5. and 8. (i.e. the .ssrc MST attributes). > > Regular PC setup (this already well known): > http://goo.gl/cKfNf > > Stream add: > http://goo.gl/ZNSdZ This is indeed along the lines of what I also had in mind. Stefan already made a comment on rtcweb about how obtaining SSRCs directly from a stream doesn't really fit right now as a stream may be attached to many, one or no peer connections. So I suppose the actual API would have to take this into account and get the SSRC from some object that represents a relation between a track and a specific peer connection. Some sort of a PeerTrackDescriptor ... or something like that. Looking at the example itself I see it ends at bob asking Alice to stop sending a specific SSRC. I believe Eric's questions were also about that part, so here are a couple of more lines at the side of Alice: onSigna(action, ssrc) { if(action == 'stopTrack') stopTrack(ssrc); } stopStream(ssrc) { localTracks[ssrc].stop(); } In the above localTracks is a locally maintained array/map of the tracks Alice is currently sending. Obviously you could also just loop a "for" over the tracks in your streams but since you didn't want to "grovel" ... Of course there's work to be done on the APIs but on the whole, Eric, does this answer your question? Emil > Again, this is a *rough* example. The clear advantage (from my PoV of > course) is that, once the peer connection is established, the app does > not have to care about additional renegotiations, but in exceptional > cases (i.e. the new stream needs a new PT): no need to handle O/As > crossing on the wire, nor rollbacks. > > The clear drawback is that, as it is now, it looks awfully ugly: tracks > are attached to the existing stream for transmission, but rendered on a > new stream on the receiving side. This is because the focus was on > minimizing the impact on the API. It could be probably improved with > more substantial changes, e.g. for allowing the instantiation of the > remote stream on the receiving side before the RTP packets actually > start flowing. Kind of what plan B does, but without the additional, > painful, O/A+O/A exchange. > > Enrico > > > -- https://jitsi.org From richard.ejzak@alcatel-lucent.com Wed Jun 5 06:42:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF0921F9AFB for ; Wed, 5 Jun 2013 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMktGdQa3pR7 for ; Wed, 5 Jun 2013 06:42:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7A21F9B09 for ; Wed, 5 Jun 2013 06:42:14 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r55DgCtZ026280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jun 2013 08:42:12 -0500 (CDT) 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 r55Dg8LG020400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 09:42:12 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.148]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 09:42:08 -0400 From: "Ejzak, Richard P (Richard)" To: Cullen Jennings Thread-Topic: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 Thread-Index: Ac5dzHO0Q+r/un2nR0ihy0dNOS7t9gCuMDzQAEgo0AAAEXdZEA== Date: Wed, 5 Jun 2013 13:42:08 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D7D668A@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C37E6A7@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F3D7CDAF9@US70UWXCHMBA05.zam.alcatel-lucent.com> <16B6138A-21A7-46B5-BDA4-FE61380DB7CF@iii.ca> In-Reply-To: <16B6138A-21A7-46B5-BDA4-FE61380DB7CF@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 13:42:21 -0000 Hi Cullen, Having looked into it further, I would suggest that the "visited-realm" and= "alternate-realm" attributes be assigned the TRANSPORT category. They rep= resent information similar to the candidate attribute and can be different = across m lines as a result of various 3pcc scenarios. IDENTICAL would not = be appropriate. The remaining attributes in 5.42 should be assigned the NO= RMAL category. Thanks, Richard > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca] > Sent: Tuesday, June 04, 2013 7:34 PM > To: Ejzak, Richard P (Richard) > Cc: mmusic@ietf.org WG; suhasietf@gmail.com > Subject: Re: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux- > attributes-02: sections 5.22, 5.40, 5.41, 5.42 >=20 >=20 > Richard, >=20 > Could things like "visited realm" just need to be the same if using > Bundle? What I mean is that if two m-lines had different "visited > realm" values, then they could not be bundled? It seems unlikely to me > they would have a different "visited realm" but I don't really > understand all of this. >=20 > Any advice you could give on what the values should be would be great. > If more work is needed TBD may be the correct values but SECIAL would > imply that there was text in some draft that said what to do and it was > not one of the default actions. >=20 > Thanks, Cullen >=20 >=20 >=20 >=20 > On Jun 3, 2013, at 1:22 PM, "Ejzak, Richard P (Richard)" > wrote: >=20 > > Hi Christer, > > Thanks for asking me to comment on 5.42. First of all, I agree with > all your other comments. I would recommend that the category for all > the items in 5.42 be listed as "SPECIAL" since more work would need to > be done in 3GPP to specify their potential use with BUNDLE. These > attributes are all transport related but not in a way that can be > easily captured by the category "TRANSPORT". > > > > There are two typos in the table: "visited realm" should be "visited- > realm" and the second occurrence of "omr-m-att" should be "omr-m-bw". > > > > Richard > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, May 31, 2013 2:33 AM > > To: mmusic@ietf.org; suhasietf@gmail.com; Ari Ker=E4nen; Flemming > Andreasen (fandreas@cisco.com) > > Cc: Ejzak, Richard P (Richard) > > Subject: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: > sections 5.22, 5.40, 5.41, 5.42 > > > > Hi, > > > > I was requested to review the attributes listed in sections 5.22, > 5.40, 5.41 and 5.42. > > > > However, first I have a general comment on the document: > > > > For some attributes (e.g. MSRP-CEMA), there is note text saying: > > > > "Not recommended due to legacy interop purposes" > > > > Making such statements is completely outside the scope of the > document. The document is about multiplexing, and how/if attributes are > affected. > > > > There is also similar note text saying: > > > > "Not recommended due to interop purposes" > > > > Now, for the 3GPP defined attributes you could say "Usage only > defined for IMS", or something. But, again, it's not within the scope > of this document to recommend against using things. > > > > .unless, of course, there from a multiplexing perspective is a reason > to do so, and they should be listed under the NOT RECOMMENDED category: > > > > > > 5.22 > > > > +------------+---------------------------------+---------+--------- > -+ > > | Name | Notes | Current | > Category | > > +------------+---------------------------------+---------+-------- > --+ > > | msrp-cema | | M | NORMAL > | > > | | | | > | > > | | | | > | > > +------------+---------------------------------+---------+-------- > --+ > > > > > > 5.40 > > > > +-------------+--------------------------------+---------+-------- > --+ > > | Name | Notes | Current | > Category | > > +-------------+--------------------------------+---------+-------- > --+ > > | g.3gpp.cat | Usage defined for the IP | M | NORMAL > | > > | | Multimedia Subsystem [ref] | | > | > > | | | | > | > > +-------------+--------------------------------+---------+-------- > --+ > > > > > > 5.41 > > > > +-------------+--------------------------------+---------+-------- > --+ > > | Name | Notes | Current | > Category | > > +-------------+--------------------------------+---------+-------- > --+ > > | g.3gpp.crs | Usage defined for the IP | M | NORMAL > | > > | | Multimedia Subsystem [ref] | | > | > > | | | | > | > > +-------------+--------------------------------+---------+-------- > --+ > > > > > > 5.42 > > > > This is actually an interesting one, and needs a little more > investigation. So, I'll have to come back on that one. It would be good > if Richard Ejzak, who is the "architect" behind the attributes, could > take a look :) > > > > +------------------+---------------------------+---------+--------- > -+ > > | Name | Notes | Current | > Category | > > +------------------+---------------------------+---------+-------- > --+ > > | secondary-realm | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | visited realm | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-m-cksum | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-s-cksum | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-m-att | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-s-att | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-s-bw | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-m-att | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > | omr-codecs | Usage defined for the IP | M | TBD > | > > | | Multimedia Subsystem [ref]| | > | > > | | | | > | > > +------------------+---------------------------+---------+-------- > --+ > > > > > > > > Regards, > > > > Christer > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Wed Jun 5 08:53:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7873A21F9B2B for ; Wed, 5 Jun 2013 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4HrT1XBGBDh for ; Wed, 5 Jun 2013 08:53:21 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A921F9AED for ; Wed, 5 Jun 2013 08:53:20 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id kb2R1l00327AodY58ftL6e; Wed, 05 Jun 2013 15:53:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id kftK1l01D3ZTu2S3fftK4k; Wed, 05 Jun 2013 15:53:20 +0000 Message-ID: <51AF5EEE.8080904@alum.mit.edu> Date: Wed, 05 Jun 2013 11:53:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370447600; bh=+9sS19E8Ugx7/PGMeIP4HrAVr7xbbhp/U9N0smJeWI8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HtghmHXgpJIW/qCHwbEiDd4XiIERjIBi0RKZ8yf8ASi8delsPmZVTMnpWtNTbK3UW c/XFMTlawK5zrUlzi4qd/2K5RxEwAnFUPgHXLhlp+2Ec3X5b9gVqmcrc+l0txf2INt OpovXZOI1fSWIERUwMyYjksSQ4BfGQ3YoXfenwViuFrtJ3hJ9OImUSjZBpt20tV0XU dPZWiWV1mOzm/+2xfyo8KkiAhBLLpxTZNE6za13PFWLdb14RR7iCWnFKPTOjOVJuXH BwgITG0f8KQkpsX2qO6sTbQeoMpRJalE/au2yKe8Oc0+0HBnxdNd7cBKNgJVhNBrzv WLWJs1N8gaKtQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 15:53:29 -0000 On 6/3/13 6:49 PM, Cullen Jennings wrote: > > On May 27, 2013, at 1:13 PM, Paul Kyzivat wrote: > >> On 5/27/13 2:52 PM, Colin Perkins wrote: >> >>>>>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I? >>>> >>>>> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines. >>>> >>>> But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines? >>> >>> You don't. If you care about that, you need to either use distinct PT values for each m= line, or signal SSRCs. >> >> I assert that if you don't care about associating a packet to a particular m-line in a bundle that you don't need to use bundle. > > I'm not sure this makes a huge difference to your argument but I don't think I agree with the above. > > It seems that even if you don't care which m-line the media get associated with, if you want to use a single port for all the m-line, you still need bundle. I don't understand. Why do you want to use multiple m-lines on one port? If you don't need to associate the packets with a particular one of those m-lines, then why didn't you use a single m-line? E.g., if your reason is because one is audio and another is video then you certainly want to associate the packets with one or the other. ISTM that the whole point of Plan A is that each m-line is associated with a specific use/rendering, and so it is essential to associate incoming packets with a particular one of the m-lines. Thanks, Paul >> So if you used bundle, you must care, and so there must be a way to achieve that association. >> >> The reason you care is because doing so allows you to discover all the other things in that media section of the SDP that may be pertinent to this packet. >> >> Thanks, >> Paul > > From pkyzivat@alum.mit.edu Wed Jun 5 09:17:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDCB21F9B2A for ; Wed, 5 Jun 2013 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F-1d9p7AMs6 for ; Wed, 5 Jun 2013 09:17:22 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8439721F9987 for ; Wed, 5 Jun 2013 09:17:22 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id kbUL1l0020mv7h059gHMM1; Wed, 05 Jun 2013 16:17:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id kgHM1l00n3ZTu2S3XgHMwJ; Wed, 05 Jun 2013 16:17:21 +0000 Message-ID: <51AF6490.1040409@alum.mit.edu> Date: Wed, 05 Jun 2013 12:17:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> In-Reply-To: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370449041; bh=s10lsHXjV55Lssfc87WLenn0KE/LpOAc7Bu6Vwux374=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GivhvwD/vE8l8Qb8qRab9lBQlAV2U9gYO/d2iqm5SblKwuT3mjATuqTf+doqxPIOV LGr5Xanh1uLG3wVZhEBdL9W2ZKjaF3THklmn4OXErHoFcnG2mkzI6H96vMv8H9dTAK P6ujyDHo0ohMxg+bLfvFH5DX3zm2LIsZ6hpvJpXt1i1+NU/SsBBhE4L03/HAqt08UD Pkh5CPXVFm8QjqLieyaC+oqnj4Nc6Ld59F76+EcuqkNLR2JL2ofqXP9Ai0RGx0E0+1 IFbSfRkfzqTNYTpJq16YQgmfzUPunOYvdoKaWGgkE2WFkV0mHDRUIGBqFQ6Hg6HM2M wBGMHZd376cUQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:17:28 -0000 On 6/3/13 6:51 PM, Cullen Jennings wrote: > > > Imagine Alice sends an offer containing > > On May 27, 2013, at 10:56 AM, Paul Kyzivat wrote: > >> m=audio 49172 RTP/AVP 96 >> a=ssrc:2222 cname:alice@example.com >> a=rtpmap:96 G7291/16000 > > Let say that an offer sent like the above. That means nothing about the SSRC for the packets that Alice will receive. And it is likely to receive RTP packets before it receives an answer in some important scenarios. You keep saying that. But is it really true when ICE is used? Need it be true even without ICE? After all, bundle is new usage, so we can demand new behavior when using it. So requiring a reliable provisional with an answer before sending media doesn't seem so unreasonable. > So a RTP packet SSRC 3333 arrives. There's no information from the SSRC about what m-line it matches too (but RTCP for it can be sent). My point is that if you choose to bundle, then there must be *some* mechanism to associate packets with m-lines. If you don't find the use of SSRC to be an acceptable solution, then feel free to construct your offer so that PTs are sufficient to do that association. But I don't see why the mechanism we specify must require that. > Now an answer from Bob arrives with > > m=audio 55555 RTP/AVP 96 > a=ssrc:4444 cname:bob@example.com > a=rtpmap:96 G7291/16000 > > Now a packet with SSRC 4444 arrives. That might be from Bob, but here's the rub. It might be from Charlie. If there was an SSRC collisions between Bob and Charlie, it will be awhile before some SDP shows up that says that there was a collisions and now Bob is using SSRC 5555. Here you are assuming that the invite was forked, and that both forked endpoints send early media, and they manage to have an SSRC collision on the early media? (And both Bob and Charlie had the winning ticket on last night's Power Ball???) We are supposed to worry about that case??? > This is all a disaster and the best solutions to it IMHO would be to define a new RTP Header extension that carries and identifier and that Alice can tell Bob in the SDP offer what value to put in the identifier for the RTP from Bob to Alice. That is another solution. But do we want to require that all media providers do this? Wouldn't it be less onerous to simply require an early answer? I'm concerned with requiring the sender to insert something in the media that is specified by the receiver. That makes it harder to distribute the same media to multiple destinations. I do think we want a header extension that contains something independent of SSRC that may be used to associate related packets. (That can be used by clue to carry capture-id.) But I don't think it needs to be defined by the receiver. Thanks, Paul > I've see more than one system that have stuffed that identifier in the existing CSRC field which is sort of an awful hack and sort of very cool. > > > From christer.holmberg@ericsson.com Wed Jun 5 09:24:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D172121F9BA7 for ; Wed, 5 Jun 2013 09:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIgIvd3cuMsw for ; Wed, 5 Jun 2013 09:24:00 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D806221F9BA6 for ; Wed, 5 Jun 2013 09:23:59 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-23-51af661e68b5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 94.E3.09795.E166FA15; Wed, 5 Jun 2013 18:23:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 18:23:58 +0200 From: Christer Holmberg To: Paul Kyzivat , Cullen Jennings Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXocH/Y1zQW/EWt7TkWSefrJ5kY2NQAgAAiw8D//+EkAIAAIgyA///fnwCAAHHXZv//45cAAAVIH3j//+FfgIAABf8AgAs8oQCAArBQAP//1o7w Date: Wed, 5 Jun 2013 16:23:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> In-Reply-To: <51AF5EEE.8080904@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra5c2vpAg43HzCw+rP/BaDF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHpfPf2QMYI7isklJzcksSy3St0vgymi4O4W9oFu84sCfdtYG xhVCXYycHBICJhIvPt5hhrDFJC7cW8/WxcjFISRwmFHiwLXbrCAJIYHFjBLvmvS7GDk42AQs JLr/aYOERQQ8JZb++MkCEmYWUJe4ujgIJCwsYC3RfKKRHaLERqJh+n8WkJEiAk2MEguO/wTb xSKgItG88A0biM0r4CvxYWEnE8Te66wSM3susIIM5RTQkWi96ApSwwh02/dTa5hAbGYBcYkP B69D3SwgsWTPeShbVOLl43+sELaSROOSJ6wQ9XoSN6ZOYYOwtSWWLXzNDLFXUOLkzCcsExjF ZiEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm6+iREYNQe3/DbYwbjpvtghRmkOFiVxXn3exYFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKVdZcptv5u+OLHcePkE061N3Fw7Pc0qGPt4plxb Nnu9xPlVzK5HI2fe71hh1vj9UTebM4sv36q0Qgm1n4ktwoWHuKfEKe5eJeUya0UNb+vshNvz F006YsOxeIcNg074rlMTT+y4cTSyn/lX18buuHVz1zJaXWRICTz9v+H7AQnlTu1CJT4/ayWW 4oxEQy3mouJEAJfkDhhoAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:24:07 -0000 Hi, I think there are many reasons why one would want to use different m- lines= . Eventhough the transport characteristics are the same (if you use BUNDLE,= that is), there other things that may be different. Just to give a simple = example: the direction attribute value, content attribute value, and anythi= ng related to the "scope"/"context" of the m- line. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Paul Kyzivat L=E4hetetty: 5. kes=E4kuuta 2013 18:53 Vastaanottaja: Cullen Jennings Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? On 6/3/13 6:49 PM, Cullen Jennings wrote: > > On May 27, 2013, at 1:13 PM, Paul Kyzivat wrote: > >> On 5/27/13 2:52 PM, Colin Perkins wrote: >> >>>>>> In the example above the same payload format, within the same RTP se= ssion, is used in two separate m- lines. But, I still can't use the same PT= value for both m- lines, even if the payload format is the same, can I? >>>> >>>>> Why not? I don't see any problem mapping the same payload type to the= exact same payload format in two different m=3D lines. >>>> >>>> But, when I receive media with that payload format, how do I know to w= hich m- line it "belongs", as the same PT value is used for both m- lines? >>> >>> You don't. If you care about that, you need to either use distinct PT v= alues for each m=3D line, or signal SSRCs. >> >> I assert that if you don't care about associating a packet to a particul= ar m-line in a bundle that you don't need to use bundle. > > I'm not sure this makes a huge difference to your argument but I don't th= ink I agree with the above. > > It seems that even if you don't care which m-line the media get associate= d with, if you want to use a single port for all the m-line, you still need= bundle. I don't understand. Why do you want to use multiple m-lines on one port?=20 If you don't need to associate the packets with a particular one of those m= -lines, then why didn't you use a single m-line? E.g., if your reason is because one is audio and another is video then you = certainly want to associate the packets with one or the other. ISTM that the whole point of Plan A is that each m-line is associated with = a specific use/rendering, and so it is essential to associate incoming pack= ets with a particular one of the m-lines. Thanks, Paul >> So if you used bundle, you must care, and so there must be a way to achi= eve that association. >> >> The reason you care is because doing so allows you to discover all the o= ther things in that media section of the SDP that may be pertinent to this = packet. >> >> Thanks, >> Paul > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Wed Jun 5 09:29:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120CE21F9BD1 for ; Wed, 5 Jun 2013 09:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb3Ho1SgULoS for ; Wed, 5 Jun 2013 09:29:20 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 1831E21F9BC0 for ; Wed, 5 Jun 2013 09:29:19 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id kalB1l0030vyq2s51gVKLY; Wed, 05 Jun 2013 16:29:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id kgVK1l0083ZTu2S3RgVKnK; Wed, 05 Jun 2013 16:29:19 +0000 Message-ID: <51AF675E.5010605@alum.mit.edu> Date: Wed, 05 Jun 2013 12:29:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> <51ACFB79.1080207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se> <51AE14C5.6000701@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C382EB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C382EB7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370449759; bh=ZMTn7f+uxQjvThUgi0u/Jf8OVx2ZdtG4T87keEKCPHE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cTKNpvxIZ+M5iHGXui6TlxHWwTv0A6hjOkq95kwJ8SO9BguVnIJoxdkMXlyoQIpmR xo9LGzHD1yjqE2V+dgxViGPiqepm+mxX/oUMFkCG5lEkQTHtxIQIr1+wWGIW2KrV5Q kFkf4TsUDiIMQvbOPxqmPKGD+9XPSMvzmdpceUNPJGKPOQVa688YxJHPycP/FMT9kG 7F8rENA7PKx+77tFpdHJYxBLos3R1NCu/0DyHi9fSQ/hh4mpC3guL6Uv3ShFCQc9lO 6eNHGXdG1V8VpNqPZlMmgv2zbRHRw7ajWmbt+zLsC5tebrJAN/qdV2owy2nKELh6y8 MLhVtABTXA/DQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:29:26 -0000 I think we are now in full agreement. (Just need the text to say this.) Thanks, Paul On 6/5/13 2:02 AM, Christer Holmberg wrote: > Hi, > >>>>>>> I'll throw the ball out with suggesting the following ones: >>>>>>> >>>>>>> -*Bundle restart offer* (different port value, currently referred >>>>>>> to as "first offer") >>>>>>> >>>>>>> The reason I use "restart" wording is because this is used, no >>>>>>> matter whether in the beginning of the session or mid-session, to >>>>>>> (re-)negotiate the usage of BUNDLE, and the bundle address >>>>>>> information selection. >>>>>>> >>>>>>> -*Bundle sync offer* (identical port value, currently referred to >>>>>>> as "second offer") >>>>>>> >>>>>>> The reason I used "sync" wording is because this is used to ensure >>>>>>> that intermediaries have correct address information for each m- line. >>>>>>> >>>>>>> Keep in mind that we may even need to split the sync offer into >>>>>>> more sub types, when we get into the details of adding new m- >>>>>>> lines etc, but I'd like to agree a base to start from :) >>>>>> >>>>>> Above seems like a good start, but I'm still grappling with some >>>>>> things and don't know how to talk about concisely: >>>>>> >>>>>> I understand that the next offer after a Bundle Restart Offer will >>>>>> typically be a Bundle Sync Offer. But if there is another offer >>>>>> after a Bundle Sync Offer, and it doesn't change anything about the >>>>>> bundle, then is it still a Bundle Sync Offer? >>>>> >>>>> Currently, yes. >>>> >>>> I agree that without adjusting the terminology this is the only right choice to make. But it is a little obscure. I'm not certain this needs to be improved, but I thought I would suggest that it might. >>>>> >>>>>> Also, I don't believe the above are mutually exclusive. If I send >>>>>> an offer to add a new m-line to a bundle, and I give it distinct >>>>>> address info so that the answerer may take it out of the bundle if >>>>>> needed, then is that a Bundle Restart Offer or a Bundle Sync Offer? >>>>>> It seems to be a bit of each. And of course there may be multiple >>>>>> bundles described by the SDP, and these terms apply independently to each. >>>>>> >>>>>> Maybe we need a couple more terms for: >>>>>> >>>>>> - offer that adds a new m-line to bundle using the existing bundle >>>>>> address info. >>>>> >>>>> Technically that is a Bundle Sync Offer, but I DO agree that the wording is not good in this case - as it's not only about synchronization. >>>>> >>>>>> - offer that adds a new m-line to an existing bundle using unique >>>>>> address info. >>>>> >>>>> I agree that doesn't fit the current definitions. >>>>> >>>>> However, we will have to agree on whether we allow that in the first place, or whether the offerer will have to use 1) same address information or 2) different address information for ALL m- lines (Bundle Restart Offer). >>>> >>>> Yes, we need to settle on whether either or both of these are permitted. >>>> >>>> But I can think of reasons why I might wish to use either one, and no good reason not to allow both. So allowing both is my preference. >>> >>> I personally think we should allow BOTH 1) and 2). >>> >>> The question is whether we should allow 3), which is new m- line with unique address, while the other m- lines use the bundle address. >> >> I agree it is a valid question to ask. >> Again, I can see how it might be useful sometimes, and I can see no reason not to allow it. Its just a special case of the bundle restart offer. > > We could modify the definition of bundle restart offer, to allow that some m- lines may use the same address information. > > It needs to be very clear, though, that such m- lines cannot be moved out of the BUNDLE group by the Answerer, as they don't have a unique address to fallback to. > > However, the Answerer MAY still change the address for such m- lines to the address of the added m- line - especially if the Offerer puts the mid value associated with the new m- line first in the SDP group:BUNDLE attribute mid value list. > >> (Note, IMO it should be ok for the very first offer to propose a bundle with address info already shared among m-lines in the proposed bundle. >> Using that trades off potential interop issues for speed in establishing the session.) > > My intention (and, that's why I appreciate all feedback I can get :) is to make the procedures very generic, and not separate between initial and subsequent offers (other than in examples). > > Regards, > > Christer > > From emil@sip-communicator.org Wed Jun 5 09:30:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB421F8AE8 for ; Wed, 5 Jun 2013 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKsakptMjzwQ for ; Wed, 5 Jun 2013 09:30:04 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB021F8AE6 for ; Wed, 5 Jun 2013 09:30:03 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so1530558wes.12 for ; Wed, 05 Jun 2013 09:30:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=nSrvYfoeP46oq4jbNisnzmZZFa7WgT7/MT6QwmKBrdY=; b=ANN+ERALsRTVFINhhzFp+YapxA4eim8jz41+jGUrrUR2pyhLVjwLGPu0qkwZl0BzY2 r32T37mW0eTQ7i3gzwIELe3GKMOl/glXBt0WhqlZ4EDDbnI/TLSTCaIW/EtzZC8PbV6o vEVD/Fa2JvtEN0+ejI+FQXD0Ao8DvcEcmiXOCc56/3YNCEbZmX98IwjfWhddRInAqJUl Z4QEZszHqT+3kckqzRyKDJoiTnEflS9/jWM037BOgimbOnli9jmh/ffd2TaBmabu7mBf cyebcQFet0KyGFNl8x6mtjccLU4gHLaY37hPX25coaPeVUbyrU8MF2jXBq+uSjGOtoat ++fA== X-Received: by 10.180.183.67 with SMTP id ek3mr7449705wic.44.1370449802750; Wed, 05 Jun 2013 09:30:02 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:e8e0:6906:8f54:99d8]) by mx.google.com with ESMTPSA id fv11sm11502471wic.11.2013.06.05.09.30.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 09:30:01 -0700 (PDT) Message-ID: <51AF6789.40500@jitsi.org> Date: Wed, 05 Jun 2013 18:30:01 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> <51AD0C53.7030406@alum.mit.edu> <51AD1617.9020501@jitsi.org> <51AE10C2.5010807@alum.mit.edu> In-Reply-To: <51AE10C2.5010807@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmoansxsM1O7rNBTDNaR/w6/H6Qx7y4wpdq3URhZgRJwf0TKLxhG8U7knFQY9qRhV0xQqBv Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] No Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:30:05 -0000 Hey Paul, On 04.06.13, 18:07, Paul Kyzivat wrote: > On 6/3/13 6:17 PM, Emil Ivov wrote: > > [snip] >>>>> I'm just pointing out that for decomposed endpoints one 5-tuple may not >>>>> be enough. And the need for this might not be known a priori. One side >>>>> may be ready to add another stream for some purpose, and be >>>>> willing/able >>>>> to use private signaling to negotiate that. But the other side may not >>>>> be able to handle that stream on the same 5-tuple. That in turn may >>>>> result in a need to negotiate SDP changes to establish an additional >>>>> 5-tuple that can then be used for that new stream. >>>> >>>> I think I see ... but not completely. Could you please post an SDP offer >>>> with BUNDLE and the corresponding answer? >>> >>> The issue can be discussed without bundle, and without detailing the O/A. >> >> We can certainly try. I am not sure if I am following though. Let's see: >> >>> Assume we have had an O/A already between X and Y, with a single (video) >>> m-line, resulting in a single 5-tuple. Over this we have a single audio >>> RTP stream and mediaStreamtrack. >>> >>> The user of X interacts with the app, indicating a desire to receive >>> another video stream from Y. This causes the app to trigger the JS in Y >>> to set up another mediaStreamTrack. But the camera on Y has a separate >>> IP address. So it is necessary to first set up another video m-line with >>> the new address on Y's end. (X's end can use its single IP address.) >> >> This is the part that I can't quite picture. How can Y's camera be on a >> separate IP, but still appear as a regular device to Y's javascript and >> still generate a regular stream track? All this with a generic browser? > > I'm not a browser guy, so maybe I am imagining things that are out of > scope for webrtc, but maybe not. Well I suppose a browser could always support a decoupled device if it were made available as local through some driver. Something like a virtual local device. In that case however, this driver would still have to bring the media to the local host so that it can be placed within a track, a stream and a peer connection. At this point it wouldn't matter to WebRTC that the device is actually decoupled, would it? There is still the other option where this device is controlled by proprietary JS and for this you'd need to have your own signalling and your own control interfaces. > At the very least you can have an app that gateways between a browser > and some non-browser device. Let me make sure I understand this. This gateway app, is it running on X, is it on a box between X and Y, or is it a controlling entity of the decoupled Y? > So assume that X is a browser and Y is not. > What does the app tell the browser to do so that the new stream is on a > different 5-tuple? Without knowing the specifics of your scenario I'd say that you have the following options: 1) Y relays RTP from its decoupled camera toward X. In this case X is getting everything on the same 5-tuple, so no extra m= lines are necessary. (You'd have a similar situation in the case above where the camera is somehow presented as a virtual local device on Y) 2) Y just wants to handle signalling and it would like that video from the decoupled camera reaches X directly from there. Y also wants to have everything handled within the same Offer/Answer dialog. In this case: 2.1) When Y calls X, it would add a second video m= line in a second bundle (or with no bundle at all) when sending its offer to X 2.2) When X calls Y with a single lined offer, Y would also answer with a single m= line and would then re-Offer with two lines. In both 2.1 and 2.2 the browser on X would see two independent, unbundled streams and handle them appropriately. Is any of the above close to what you have in mind? Or is it completely off? Emil > >> Wouldn't it be much more likely that such a separate camera will be >> controlled by a proprietary interface that is not directly related to >> WebRTC? > > Can somebody who knows more about these things comment if this is > entirely impossible for two devices accessible to the browser to be > accessible only via distinct IP address/port, or if it might occur for a > sufficiently sophisticated device? > > Thanks, > Paul > >> If so, then the additional signalling for this camera would obviously >> need to be generated by Y's javascript (i.e. not the browser). That >> additional signalling can then be merged into the one from Y's browser >> by Y's JS or a gateway. >> >> X would indeed need to handle an offer with two video m= lines at that >> point, but that's because they would negotiate different 5-tuples. So >> this is fine. >> >> Another option would be to handle the new camera with an independent >> Offer/Answer that would yield a new PeerConnection. I don't know if that >> works for your case but I thought I'd mention it. In this case any >> additional information required for the synchronization of the two peer >> connections would be exchanged in an app-specific way. >> >> Cheers, >> Emil >> >> >>> Once that is done the new mediaStreamTrack can be established on the new >>> m-line. >>> >>> How does this fit into No Plan? >>> >>>> (This might be a good point to move this to mmusic) >>> >>> Done. >> >> Thanks, >> Emil >> >>> >>> Thanks, >>> Paul >>> >>>> Thanks, >>>> Emil >>>> >>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> If you'd like for that signalling to be in SDP, I >>>>>>>> don't see any problem with it. However it would be best for this >>>>>>>> extra >>>>>>>> layer of SDP signalling to appear at either the application layer >>>>>>>> or in >>>>>>>> a signalling gateway (that is going to be there anyway). >>>>>>>> >>>>>>>> Does this make sense? >>>>>>>> >>>>>>>> Emil >>>>>>>> >>>>>>>>> >>>>>>>>> Further questions: >>>>>>>>> >>>>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>>>>>> per-m-line, with application specific signaling for bandwidth at >>>>>>>>> the >>>>>>>>> per-RTP-stream level? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>>>>>> Hey all, >>>>>>>>>> >>>>>>>>>> Based on many of the discussions that we've had here, as well as >>>>>>>>>> many >>>>>>>>>> others that we've had offlist, it seemed like a good idea to >>>>>>>>>> investigate >>>>>>>>>> a negotiation alternative that relies on SDP and Offer/Answer >>>>>>>>>> just a >>>>>>>>>> little bit less. >>>>>>>>>> >>>>>>>>>> The following "no plan" draft attempts to present one such >>>>>>>>>> approach: >>>>>>>>>> >>>>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>>>>>> >>>>>>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>>>>>> intricacies of multi-source scenarios to application-specific >>>>>>>>>> signalling, with potentially a little help from RTP. >>>>>>>>>> >>>>>>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>>>>>> interoperability requirements that concerned them can still be met >>>>>>>>>> with >>>>>>>>>> "no plan". Of course they would have to be addressed by >>>>>>>>>> application-specific signalling and/or signalling gateways. >>>>>>>>>> >>>>>>>>>> Comments are welcome! >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Emil >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> rtcweb mailing list >>>>>>>>> rtcweb@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > . > -- https://jitsi.org From pkyzivat@alum.mit.edu Wed Jun 5 09:41:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18E121F9B34 for ; Wed, 5 Jun 2013 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFGWPvmblqB for ; Wed, 5 Jun 2013 09:41:34 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 84EE521F9B79 for ; Wed, 5 Jun 2013 09:41:25 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id kaaX1l0020bG4ec5CghLtR; Wed, 05 Jun 2013 16:41:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id kghL1l00Q3ZTu2S3PghLsY; Wed, 05 Jun 2013 16:41:20 +0000 Message-ID: <51AF6A2F.7000601@alum.mit.edu> Date: Wed, 05 Jun 2013 12:41:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> In-Reply-To: <51AF14DB.5020009@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370450480; bh=WzR+4Fm/sT1OUBx1PBoWqEfPKrjReUWMqKzDCpLrqOQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UOHqaXmP3C6U7B3e/d8tdM7TwTtuXqIHKbD7xuU+yP/Hhyj192vVFV7NlYN0YggvM wqj+cpfsOj0A/A8zdzE27j9+B5INx3S1V9j1K8tstysB6uOELU09dtRzEbAxXwQXrR 2LvHYjtM2JJbQwkPVBxNN6KO8kt01zimfA8lyPWjz4kaIdTqyJoj9Oflo+1j/L6BRM hpZ2J3rZsLCrK4Pm8mVV5FuFsHXQ3heK0nWR2/434DvIm/OcgwP1eJ62hiduCW5gr8 5gc2GqTMdnqsvhuCgUbtjj+uKvMdenmkq3C3lWyF9uYhsw9gHrgNmVDz+h+mWkUVmM qgMVzUnr/zTyw== Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:41:38 -0000 On 6/5/13 6:37 AM, Emil Ivov wrote: > Hey Flemming, > > You are right, there are no specific SDP updates that "No Plan" is > asking from mmusic. > > That said however, the same is pretty much true about Plan A and Plan B. > They both discuss ways of using SDP and the extensions that might be > implied to these ways are considered mostly collateral: ??? AFAIK plans A and B both assume BUNDLE, and use it, and by implication impose restrictions on its use. Similarly I think No Plan has the same characteristics. I guess No Plan and Plan B *could* be used without BUNDLE. Is that your point? At least I don't see that as the expectation for typical use. In any case I think these discussions are important context for the BUNDLE discussions. Thanks, Paul > Plan A: > > This document describes a *modest* > set of extensions to SDP which allow it to cleanly handle arbitrary > numbers of flows while still retaining a large degree of backward > compatibility with *existing* and non-RTCWEB endpoints. > > Plan B: > > Plan B mostly uses *existing* IETF standards, introducing a single new > draft [I-D.lennox-mmusic-sdp-source-selection] to specify how > individual media sources can be accepted/rejected at the SSRC level > via SDP. > > I might be off, but it was my understanding that the interim meeting was > not going to be about these specific extensions (which could possibly be > specified regardless of which Plan we go for) but mostly about the best > ways to use SDP with multiple sources. The choices we make could have an > impact on multiple working groups, which, I assumed, was the main reason > for having the discussion mmmusic. > > In that sense I see "No Plan" as quite related to this discussion. > > Am I right in assuming this and if so does the above answer your question? > > Emil > > On 05.06.13, 06:44, Flemming Andreasen wrote: >> >> On 6/4/13 10:41 PM, Bernard Aboba wrote: >>> Yes, you are missing something. No plan analyzes issues with both >>> Plan A and Plan B and describes how to fix them. As they stand, both >>> Plan A nor Plan B result in O/A exchanges that aren't needed and will >>> break congestion control. Also, neither satisfies the requirements of >>> the RTP usage doc or is compatible with a number of legacy >>> implementations. No plan offers a solution to these and other issues. >> I understand that "no plan" sees issues with Plan A and Plan B as >> currently defined. What I don't understand is what extensions or updates >> to SDP signaling mechanism are being proposed here and hence which part >> of this discussion belongs in MMUSIC as opposed to RTCWeb simply >> specifying how it wants to use a set of current/developing mechanisms >> (or rely on app specific mechanisms, etc.) ? In other words, what does >> "no plan" seek from MMUSIC ? >> >> Thanks >> >> -- Flemming >> >>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" >>> wrote: >>> >>>> On 5/31/13 6:46 AM, Emil Ivov wrote: >>>>> Dear chairs, >>>>> >>>>> Could you please also consider the following draft for the interim >>>>> meeting agenda: >>>>> >>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>> Sure, however I could use some clarification here. On one hand, the >>>> draft falls squarely in the middle of the overall "Plan" discussion >>>> we have and hence is highly relevant, but at the same time, if I >>>> understand correctly, the draft is not asking MMUSIC to do anything >>>> in terms of protocol development. Rather, if this approach is >>>> adopted, it would be more of an RTCWeb usage document specifying how >>>> one could use several different mechanisms (and possibly WebRTC >>>> APIs) to implement signaling. There doesn't seem to be a "mandatory >>>> to implement" mechanism for guaranteeing interoperability (in >>>> contrast to Plan A/B), but rather there are references to "app >>>> specific signalling" mechanisms, etc. Am I missing something here ? >>>> >>>> >>>>> I apologise if not stating this earlier has introduced any confusion. >>>> No worries. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>>> Regards, >>>>> Emil >>>>> >>>>> On 30.05.13, 21:56, IESG Secretary wrote: >>>>>> Greetings, >>>>>> >>>>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>>>> Working Group to take place on Monday, June 17, from 7:00 am - >>>>>> 10:00 am >>>>>> Pacific Time. The goal of this meeting is to come to a resolution >>>>>> on the >>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling >>>>>> needed >>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" >>>>>> lines or >>>>>> very few "m=" lines and to what extent is there sub-negotation and >>>>>> signaling at the SSRC level). >>>>>> >>>>>> A more detailed agenda and logistics will be sent out separately >>>>>> on the >>>>>> MMUSIC mailing list. For now, people should take a close look at the >>>>>> following two drafts: >>>>>> >>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>>>> >>>>>> You may also want to look at >>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Ari & Flemming (MMUSIC co-chairs) >>>>>> >>>>>> >>>>>> PS: Per our previous interim meeting announcement, we tried to >>>>>> schedule >>>>>> a longer and in-person physical interim meeting, however it has >>>>>> proven >>>>>> impossible to find a set of dates where we could get critical mass >>>>>> for >>>>>> such a meeting. Scheduling even a virtual interim before the >>>>>> Berlin IETF >>>>>> has been surprisingly difficult with the above date being the only >>>>>> viable option at this point. >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> > From pkyzivat@alum.mit.edu Wed Jun 5 09:48:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696DB21F9BD8 for ; Wed, 5 Jun 2013 09:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5wrMxjSGoVi for ; Wed, 5 Jun 2013 09:47:55 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9695721F9BD2 for ; Wed, 5 Jun 2013 09:47:55 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id kgMQ1l0051HzFnQ51gnvUD; Wed, 05 Jun 2013 16:47:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id kgnu1l00U3ZTu2S3agnvge; Wed, 05 Jun 2013 16:47:55 +0000 Message-ID: <51AF6BB9.3010807@alum.mit.edu> Date: Wed, 05 Jun 2013 12:47:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370450875; bh=rVmXuABfraRWi1mJKFVLupJ4KOMNgS8He9EnuemYHQI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Yx4/2LXP09OdnThHoeiM9AjJxVcu7wvHEfqO3ZgEzKkoURBQtrCjTGerxSEhe9T1R 6kfYbvuVlkedlWQZT1eWO7rYDXXHNDdO0TKPxiOQMnaCsT311Rirj8OE2Ni4R4w1jU MzIu8r6hLFYj8f3msnc9ZE02vHaiPVzhrMgzY7Anq7EQ1NKsfTLkO3wCEASFLAwL/v MPhTnl/bg0447gUEuSk+tHiCu6qaeyajUKwdid9OvFJdUErmoeh5bqUsAsQbnCVUEL czHtxKiQKZ7gIyqpOv1toTSrKZQ688v7HCJdh3JpxPGYPZ1Je35PMNN+0KGddWODiV FsRrDArd7vJ/g== Cc: "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:48:00 -0000 On 6/5/13 12:23 PM, Christer Holmberg wrote: > Hi, > > I think there are many reasons why one would want to use different m- lines. Eventhough the transport characteristics are the same (if you use BUNDLE, that is), there other things that may be different. Just to give a simple example: the direction attribute value, content attribute value, and anything related to the "scope"/"context" of the m- line. Christer - I suspect we are on the same page. I agree there are many reasons one might want to bundle m-lines. But I assert that every one of those reasons will also require that you be able to associate incoming packets with a particular one of those m-lines. I don't understand why this is in question. I originally stated it as a truism because I thought it was self evident. Thanks, Paul > Regards, > > Christer > > > > > -----Alkuperäinen viesti----- > Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Paul Kyzivat > Lähetetty: 5. kesäkuuta 2013 18:53 > Vastaanottaja: Cullen Jennings > Kopio: mmusic@ietf.org > Aihe: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? > > On 6/3/13 6:49 PM, Cullen Jennings wrote: >> >> On May 27, 2013, at 1:13 PM, Paul Kyzivat wrote: >> >>> On 5/27/13 2:52 PM, Colin Perkins wrote: >>> >>>>>>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I? >>>>> >>>>>> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines. >>>>> >>>>> But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines? >>>> >>>> You don't. If you care about that, you need to either use distinct PT values for each m= line, or signal SSRCs. >>> >>> I assert that if you don't care about associating a packet to a particular m-line in a bundle that you don't need to use bundle. >> >> I'm not sure this makes a huge difference to your argument but I don't think I agree with the above. >> >> It seems that even if you don't care which m-line the media get associated with, if you want to use a single port for all the m-line, you still need bundle. > > I don't understand. Why do you want to use multiple m-lines on one port? > If you don't need to associate the packets with a particular one of those m-lines, then why didn't you use a single m-line? > > E.g., if your reason is because one is audio and another is video then you certainly want to associate the packets with one or the other. > > ISTM that the whole point of Plan A is that each m-line is associated with a specific use/rendering, and so it is essential to associate incoming packets with a particular one of the m-lines. > > Thanks, > Paul > >>> So if you used bundle, you must care, and so there must be a way to achieve that association. >>> >>> The reason you care is because doing so allows you to discover all the other things in that media section of the SDP that may be pertinent to this packet. >>> >>> Thanks, >>> Paul >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Jun 5 09:53:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414E521F9C15 for ; Wed, 5 Jun 2013 09:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9gSgGniHfhR for ; Wed, 5 Jun 2013 09:53:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0D21F9C0C for ; Wed, 5 Jun 2013 09:53:10 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-e5-51af6cf5225f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FF.46.09795.5FC6FA15; Wed, 5 Jun 2013 18:53:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 18:53:09 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgioAlxfJgAAbOWHAAA6xPoAAII/SwAAR5KgAAAT9WbA= Date: Wed, 5 Jun 2013 16:53:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C383732@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> <51ACFB79.1080207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se> <51AE14C5.6000701@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C382EB7@ESESSMB209.ericsson.se> <51AF675E.5010605@alum.mit.edu> In-Reply-To: <51AF675E.5010605@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre7XnPWBBitWmFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG08tbzAUX1St6tj1ka2A8It/FyMkhIWAi sfDSJTYIW0ziwr31QDYXh5DAYUaJCT87WCCcxYwSm15NBXI4ONgELCS6/2mDmCICGhKTtqqB mMwC6hJXFweBjBEW0JXo2LCTBcQWEdCT+HzrPjOEnSRx+scOJhCbRUBFYmHfPkYQm1fAV+Jq 33ywuJDAfGaJx/c4QGxOAR2JY/MWgNUwAp32/dQasBpmAXGJDwevM0OcLCCxZM95KFtU4uXj f6wQtpJE45InrBD1ehI3pk5hg7C1JZYtfM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcXInpuYmZNebr6JERgfB7f8NtjBuOm+2CFGaQ4WJXFefd7FgUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYd9w6EtJyOOTdUa030v9KphVtcPZ4OjHyomV/04IbL65WbDw97TfPte0xbxZ3 9XkVOpy+xeJ0/fulrY+zPzim6YeFxCqLdDM/nLNF8Ki5eEto5QHHRasfLOs4Im1c8UFC71HT n80RTE7zz4vN7i59OUt8Xp2lkMjPmZdvTTw7z+B7+m1hO+bou0osxRmJhlrMRcWJAAgXMO9d AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 16:53:23 -0000 Hi, I'll post a SDP Section tomorrow, so we have something concrete to work on = :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 L=E4hetetty: 5. kes=E4kuuta 2013 19:29 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] BUNDLE: SDP Offer Types I think we are now in full agreement. (Just need the text to say this.) Thanks, Paul On 6/5/13 2:02 AM, Christer Holmberg wrote: > Hi, > >>>>>>> I'll throw the ball out with suggesting the following ones: >>>>>>> >>>>>>> -*Bundle restart offer* (different port value, currently=20 >>>>>>> referred to as "first offer") >>>>>>> >>>>>>> The reason I use "restart" wording is because this is used, no=20 >>>>>>> matter whether in the beginning of the session or mid-session,=20 >>>>>>> to (re-)negotiate the usage of BUNDLE, and the bundle address=20 >>>>>>> information selection. >>>>>>> >>>>>>> -*Bundle sync offer* (identical port value, currently referred=20 >>>>>>> to as "second offer") >>>>>>> >>>>>>> The reason I used "sync" wording is because this is used to=20 >>>>>>> ensure that intermediaries have correct address information for eac= h m- line. >>>>>>> >>>>>>> Keep in mind that we may even need to split the sync offer into=20 >>>>>>> more sub types, when we get into the details of adding new m-=20 >>>>>>> lines etc, but I'd like to agree a base to start from :) >>>>>> >>>>>> Above seems like a good start, but I'm still grappling with some=20 >>>>>> things and don't know how to talk about concisely: >>>>>> >>>>>> I understand that the next offer after a Bundle Restart Offer=20 >>>>>> will typically be a Bundle Sync Offer. But if there is another=20 >>>>>> offer after a Bundle Sync Offer, and it doesn't change anything=20 >>>>>> about the bundle, then is it still a Bundle Sync Offer? >>>>> >>>>> Currently, yes. >>>> >>>> I agree that without adjusting the terminology this is the only right = choice to make. But it is a little obscure. I'm not certain this needs to b= e improved, but I thought I would suggest that it might. >>>>> >>>>>> Also, I don't believe the above are mutually exclusive. If I send=20 >>>>>> an offer to add a new m-line to a bundle, and I give it distinct=20 >>>>>> address info so that the answerer may take it out of the bundle=20 >>>>>> if needed, then is that a Bundle Restart Offer or a Bundle Sync Offe= r? >>>>>> It seems to be a bit of each. And of course there may be multiple=20 >>>>>> bundles described by the SDP, and these terms apply independently to= each. >>>>>> >>>>>> Maybe we need a couple more terms for: >>>>>> >>>>>> - offer that adds a new m-line to bundle using the existing bundle >>>>>> address info. >>>>> >>>>> Technically that is a Bundle Sync Offer, but I DO agree that the word= ing is not good in this case - as it's not only about synchronization. >>>>> >>>>>> - offer that adds a new m-line to an existing bundle using unique >>>>>> address info. >>>>> >>>>> I agree that doesn't fit the current definitions. >>>>> >>>>> However, we will have to agree on whether we allow that in the first = place, or whether the offerer will have to use 1) same address information = or 2) different address information for ALL m- lines (Bundle Restart Offer)= . >>>> >>>> Yes, we need to settle on whether either or both of these are permitte= d. >>>> >>>> But I can think of reasons why I might wish to use either one, and no = good reason not to allow both. So allowing both is my preference. >>> >>> I personally think we should allow BOTH 1) and 2). >>> >>> The question is whether we should allow 3), which is new m- line with u= nique address, while the other m- lines use the bundle address. >> >> I agree it is a valid question to ask. >> Again, I can see how it might be useful sometimes, and I can see no reas= on not to allow it. Its just a special case of the bundle restart offer. > > We could modify the definition of bundle restart offer, to allow that som= e m- lines may use the same address information. > > It needs to be very clear, though, that such m- lines cannot be moved out= of the BUNDLE group by the Answerer, as they don't have a unique address t= o fallback to. > > However, the Answerer MAY still change the address for such m- lines to t= he address of the added m- line - especially if the Offerer puts the mid va= lue associated with the new m- line first in the SDP group:BUNDLE attribute= mid value list. > >> (Note, IMO it should be ok for the very first offer to propose a bundle = with address info already shared among m-lines in the proposed bundle. >> Using that trades off potential interop issues for speed in=20 >> establishing the session.) > > My intention (and, that's why I appreciate all feedback I can get :) is t= o make the procedures very generic, and not separate between initial and su= bsequent offers (other than in examples). > > Regards, > > Christer > > From emil@sip-communicator.org Wed Jun 5 09:57:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545D221F9C27 for ; Wed, 5 Jun 2013 09:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAKlShVFeFnE for ; Wed, 5 Jun 2013 09:57:41 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE421F9C0D for ; Wed, 5 Jun 2013 09:57:40 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id w58so1532917wes.13 for ; Wed, 05 Jun 2013 09:57:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=zVKO0bI606Tewurk8DD0oS5f8wGNCpWRZPOwtN/I0vg=; b=OnDJR/UL3vdRZw/DdUFevRDFFnpvaAi7yhfkO/fmIJ5cOfQD4bMRPycJwl0eMNT0VI zXYI3VUrG4J4CxncLzYiWKs8u/+Ts32wY7tU7LnS0ZH9SSpNAIdhuOYuwmLZ+zRi8qGk TOPAJM4u64GxjX5xwKZK9gOLKizklqJg9jJgTWqRuPMjgAbGCA0TfvY4GOl010G1AGjh RrqzTzms2H/0P8ebO6thoU8K8qg6AiFTFnr9EXAbibN1WyyLNg6+IvkQvpaRKif/MJqF Peu72q28QIFA9y/9P0sMZwpkH1d598Y4tUcQf7bj9ufGYgz5WiRvHdg9ruJXo9wpPW2o 01vA== X-Received: by 10.180.126.101 with SMTP id mx5mr7591664wib.48.1370451460011; Wed, 05 Jun 2013 09:57:40 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:e8e0:6906:8f54:99d8]) by mx.google.com with ESMTPSA id fb9sm4661594wid.2.2013.06.05.09.57.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 09:57:39 -0700 (PDT) Message-ID: <51AF6E02.1090902@jitsi.org> Date: Wed, 05 Jun 2013 18:57:38 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> <51AF6A2F.7000601@alum.mit.edu> In-Reply-To: <51AF6A2F.7000601@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkC475dHsvYte22jdrzYs+5Qiww8DFJ5dXsyAdAo8geR7zjvBuJm7XHc1op9G8YT7+0M/SD Cc: mmusic@ietf.org Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:57:42 -0000 Hey Paul, On 05.06.13, 18:41, Paul Kyzivat wrote: > On 6/5/13 6:37 AM, Emil Ivov wrote: >> Hey Flemming, >> >> You are right, there are no specific SDP updates that "No Plan" is >> asking from mmusic. >> >> That said however, the same is pretty much true about Plan A and Plan B. >> They both discuss ways of using SDP and the extensions that might be >> implied to these ways are considered mostly collateral: > > ??? > > AFAIK plans A and B both assume BUNDLE, and use it, and by implication > impose restrictions on its use. Similarly I think No Plan has the same > characteristics. > > I guess No Plan and Plan B *could* be used without BUNDLE. Is that your > point? At least I don't see that as the expectation for typical use. > > In any case I think these discussions are important context for the > BUNDLE discussions. Bringing this back into context: * I made a request that No Plan be considered for the agenda of the MMUSIC virtual interim. * Flemming responded to my request asking exactly what it was that No Plan was seeking from MMUSIC. * I responded that while No Plan is mostly a user of MMUSIC products (such as SDP and BUNDLE) and while it is unlikely to have major impact on these products, on that point it was pretty much in the same boat as Plan A and Plan B. So, my main point was that No Plan should be considered a legitimate citizen of the pending virtual interim. Emil > > Thanks, > Paul > >> Plan A: >> >> This document describes a *modest* >> set of extensions to SDP which allow it to cleanly handle arbitrary >> numbers of flows while still retaining a large degree of backward >> compatibility with *existing* and non-RTCWEB endpoints. >> >> Plan B: >> >> Plan B mostly uses *existing* IETF standards, introducing a single new >> draft [I-D.lennox-mmusic-sdp-source-selection] to specify how >> individual media sources can be accepted/rejected at the SSRC level >> via SDP. >> >> I might be off, but it was my understanding that the interim meeting was >> not going to be about these specific extensions (which could possibly be >> specified regardless of which Plan we go for) but mostly about the best >> ways to use SDP with multiple sources. The choices we make could have an >> impact on multiple working groups, which, I assumed, was the main reason >> for having the discussion mmmusic. >> >> In that sense I see "No Plan" as quite related to this discussion. >> >> Am I right in assuming this and if so does the above answer your question? >> >> Emil >> >> On 05.06.13, 06:44, Flemming Andreasen wrote: >>> >>> On 6/4/13 10:41 PM, Bernard Aboba wrote: >>>> Yes, you are missing something. No plan analyzes issues with both >>>> Plan A and Plan B and describes how to fix them. As they stand, both >>>> Plan A nor Plan B result in O/A exchanges that aren't needed and will >>>> break congestion control. Also, neither satisfies the requirements of >>>> the RTP usage doc or is compatible with a number of legacy >>>> implementations. No plan offers a solution to these and other issues. >>> I understand that "no plan" sees issues with Plan A and Plan B as >>> currently defined. What I don't understand is what extensions or updates >>> to SDP signaling mechanism are being proposed here and hence which part >>> of this discussion belongs in MMUSIC as opposed to RTCWeb simply >>> specifying how it wants to use a set of current/developing mechanisms >>> (or rely on app specific mechanisms, etc.) ? In other words, what does >>> "no plan" seek from MMUSIC ? >>> >>> Thanks >>> >>> -- Flemming >>> >>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" >>>> wrote: >>>> >>>>> On 5/31/13 6:46 AM, Emil Ivov wrote: >>>>>> Dear chairs, >>>>>> >>>>>> Could you please also consider the following draft for the interim >>>>>> meeting agenda: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>> Sure, however I could use some clarification here. On one hand, the >>>>> draft falls squarely in the middle of the overall "Plan" discussion >>>>> we have and hence is highly relevant, but at the same time, if I >>>>> understand correctly, the draft is not asking MMUSIC to do anything >>>>> in terms of protocol development. Rather, if this approach is >>>>> adopted, it would be more of an RTCWeb usage document specifying how >>>>> one could use several different mechanisms (and possibly WebRTC >>>>> APIs) to implement signaling. There doesn't seem to be a "mandatory >>>>> to implement" mechanism for guaranteeing interoperability (in >>>>> contrast to Plan A/B), but rather there are references to "app >>>>> specific signalling" mechanisms, etc. Am I missing something here ? >>>>> >>>>> >>>>>> I apologise if not stating this earlier has introduced any confusion. >>>>> No worries. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>>> Regards, >>>>>> Emil >>>>>> >>>>>> On 30.05.13, 21:56, IESG Secretary wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>>>>> Working Group to take place on Monday, June 17, from 7:00 am - >>>>>>> 10:00 am >>>>>>> Pacific Time. The goal of this meeting is to come to a resolution >>>>>>> on the >>>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling >>>>>>> needed >>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" >>>>>>> lines or >>>>>>> very few "m=" lines and to what extent is there sub-negotation and >>>>>>> signaling at the SSRC level). >>>>>>> >>>>>>> A more detailed agenda and logistics will be sent out separately >>>>>>> on the >>>>>>> MMUSIC mailing list. For now, people should take a close look at the >>>>>>> following two drafts: >>>>>>> >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>>>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>>>>> >>>>>>> You may also want to look at >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Ari & Flemming (MMUSIC co-chairs) >>>>>>> >>>>>>> >>>>>>> PS: Per our previous interim meeting announcement, we tried to >>>>>>> schedule >>>>>>> a longer and in-person physical interim meeting, however it has >>>>>>> proven >>>>>>> impossible to find a set of dates where we could get critical mass >>>>>>> for >>>>>>> such a meeting. Scheduling even a virtual interim before the >>>>>>> Berlin IETF >>>>>>> has been surprisingly difficult with the above date being the only >>>>>>> viable option at this point. >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >>> >>> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From christer.holmberg@ericsson.com Wed Jun 5 10:01:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0B021F9C32 for ; Wed, 5 Jun 2013 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhbUWTqumLg9 for ; Wed, 5 Jun 2013 10:01:39 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2C27D21F9C2F for ; Wed, 5 Jun 2013 10:01:28 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-12-51af6ee666da Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5A.F6.09795.6EE6FA15; Wed, 5 Jun 2013 19:01:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 19:01:26 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: VS: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOWtXocH/Y1zQW/EWt7TkWSefrJ5kY2NQAgAAiw8D//+EkAIAAIgyA///fnwCAAHHXZv//45cAAAVIH3j//+FfgIAABf8AgAs8oQCAArBQAP//1o7wgAA4soD//9ybAA== Date: Wed, 5 Jun 2013 17:01:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> In-Reply-To: <51AF6BB9.3010807@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre6zvPWBBl82GFl8WP+D0WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPC6f/8gYwBzFZZOSmpNZllqkb5fAldHU+ZCp4I9Cxe/XnUwN jH1SXYycHBICJhL7Di1kgrDFJC7cW8/WxcjFISRwmFHi7rrrrCAJIYHFjBJ7Jgd2MXJwsAlY SHT/0wYxRQQ0JCZtVQOpYBbwkPj+eRoziC0sYC9xYNtMNhBbRMBB4uuU4+wgI0UEJjFKnHw0 jQWkl0VARaLjez1IDa+Ar8Tvzt1Qa/ezSSxa+hBsEKeAjsTLza1ggxiBbvt+ag0TxDJxiQ8H rzND3CwgsWTPeShbVOLl43+sELaSROOSJ6wQ9XoSN6ZOYYOwtSWWLXzNDLFYUOLkzCcsExjF ZiEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm6+iREYNQe3/DbYwbjpvtghRmkOFiVxXn3exYFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGE9ZbHH4cG/17SZNG/ufNxelWL/1MLF7lcEvzuDr 3/ytu/lLSkv8KSbVxLjVzjl7vgp8jYp9q3Y+w3Pj3ZiiycIWSqzsaz0z0l8dEJA90x5+IMT4 x7K5gUzaB39KJ5gzfz2TVlGoXeqw/8KpU1cdcj09bt5q+7djZRrfV1+hMx/XTf9o0fDAXoml OCPRUIu5qDgRAHGq0T9oAgAA Cc: "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:01:45 -0000 Hi, >> I think there are many reasons why one would want to use different m- li= nes. Eventhough the transport characteristics are the=20 >> same (if you use BUNDLE, that is), there other things that may be differ= ent. Just to give a simple example: the direction attribute value, content = attribute value, and anything related to the "scope"/"context" of the m- li= ne. > > Christer - I suspect we are on the same page. > > I agree there are many reasons one might want to bundle m-lines. > But I assert that every one of those reasons will also require that you b= e able to associate incoming packets with a particular one of those m-lines= . > > I don't understand why this is in question. I originally stated it as a t= ruism because I thought it was self evident. Me too. My assumption has from the start been that we need *A* mechanism to= associate media with m- lines, as there might be m- line specific characte= ristics (I haven't gone through all SDP attributes etc with that in mind, t= hough, so I can't give concrete examples at this point) that are needed in = order to properly process the media. I thought that relying on PT and/or SS= RC/CNAME would cover all cases, but obviously it doesn't.=20 For example, I PERSONALLY think one can assume to receive an SDP Answer (in= cluding SSRC/CNAME information etc) before media is received. But, as Culle= n has another opinion I don't want to waste time on arguing about that - an= d I am fully aware what 3264 says about receiving media before the SDP answ= er :) Regards, Christer > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]= =20 > Puolesta Paul Kyzivat > L=E4hetetty: 5. kes=E4kuuta 2013 18:53 > Vastaanottaja: Cullen Jennings > Kopio: mmusic@ietf.org > Aihe: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? > > On 6/3/13 6:49 PM, Cullen Jennings wrote: >> >> On May 27, 2013, at 1:13 PM, Paul Kyzivat wrote: >> >>> On 5/27/13 2:52 PM, Colin Perkins wrote: >>> >>>>>>> In the example above the same payload format, within the same RTP s= ession, is used in two separate m- lines. But, I still can't use the same P= T value for both m- lines, even if the payload format is the same, can I? >>>>> >>>>>> Why not? I don't see any problem mapping the same payload type to th= e exact same payload format in two different m=3D lines. >>>>> >>>>> But, when I receive media with that payload format, how do I know to = which m- line it "belongs", as the same PT value is used for both m- lines? >>>> >>>> You don't. If you care about that, you need to either use distinct PT = values for each m=3D line, or signal SSRCs. >>> >>> I assert that if you don't care about associating a packet to a particu= lar m-line in a bundle that you don't need to use bundle. >> >> I'm not sure this makes a huge difference to your argument but I don't t= hink I agree with the above. >> >> It seems that even if you don't care which m-line the media get associat= ed with, if you want to use a single port for all the m-line, you still nee= d bundle. > > I don't understand. Why do you want to use multiple m-lines on one port? > If you don't need to associate the packets with a particular one of those= m-lines, then why didn't you use a single m-line? > > E.g., if your reason is because one is audio and another is video then yo= u certainly want to associate the packets with one or the other. > > ISTM that the whole point of Plan A is that each m-line is associated wit= h a specific use/rendering, and so it is essential to associate incoming pa= ckets with a particular one of the m-lines. > > Thanks, > Paul > >>> So if you used bundle, you must care, and so there must be a way to ach= ieve that association. >>> >>> The reason you care is because doing so allows you to discover all the = other things in that media section of the SDP that may be pertinent to this= packet. >>> >>> Thanks, >>> Paul >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Wed Jun 5 10:37:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3AC21F9AF5 for ; Wed, 5 Jun 2013 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmTq+a176Y0c for ; Wed, 5 Jun 2013 10:37:38 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A286321F8E37 for ; Wed, 5 Jun 2013 10:37:37 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z12so946398wgg.19 for ; Wed, 05 Jun 2013 10:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oYzzYwiaVDGRVWkCelmRgh6jKuCgr22v49GlNmxar4E=; b=m5TSddPDltaLlYXGE7mRWiqoeGCoEHWRb5TfFg2b9YHAWvsgfreCnQuVLppiI6IW6H 29YljlWaettiZqjAD1cbjFdms+f+t0Zwk4+riQDzfX5OFecIV0mDerlFpCUrxFio8A0G 8DMxHBj+awN4u2eXunUDJcwvOGEgVX+gZSuY2MhjgEY5SYLdpUNFvyZTlkWPQ3OEdx8b dRFp7mZaGv5GS3l1hV0OiTwecAwio+HuFYWpatsXUvdJ24ZVdSTTTHGM75qFdRPyjJaV FObzBjiB92l3+aXTOAL7NyMuC222sNwLSALjNSy0WrzTu3QcpyRgO/jULPdntT4aFYDJ ksYg== MIME-Version: 1.0 X-Received: by 10.180.188.97 with SMTP id fz1mr12006wic.34.1370453856774; Wed, 05 Jun 2013 10:37:36 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Wed, 5 Jun 2013 10:37:36 -0700 (PDT) Date: Wed, 5 Jun 2013 10:37:36 -0700 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] The role of signaling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 17:37:39 -0000 I actually think that noplan bears serious consideration, but only with respect to what it says about the role of signaling. Plan A/B assume some things about these questions that we clearly haven't reached consensus on. The questions that I think we've been working towards are: - What role does signaling play in session establishment? - What information does signaling convey vs. what information is conveyed in the signaled medium? - Does SDP represent ALL signaling? (Clearly not.) What parts of signaling is SDP responsible for? I don't think that we resolve anything on A/B until we agree on what SDP is and does. Of course, once we agree on principles, we are always free to choose expediency over those principles. I think that Emil was right to recognize that SDP O/A doesn't need to be the only signaling mechanism. The fact that WebRTC is using a signaling protocol as part of an API surface is, in my opinion, the reason for this affliction. It appears as though SDP is the carpet to sweep all the muck under when it doesn't fit anywhere else, simply because we took the other options (read: SIP) away. That puts a lot of pressure on SDP. For instance, to pick an easy example, adding identity assertions to SDP could be the wrong choice. In SIP, identity is the domain of the SIP part of signaling. From rjsparks@nostrum.com Wed Jun 5 14:56:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DBC21F9193; Wed, 5 Jun 2013 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c5i+IL92bII; Wed, 5 Jun 2013 14:56:24 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4170021F8B35; Wed, 5 Jun 2013 14:56:24 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-071-187.mycingular.net [166.147.71.187]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r55LuLOW065539 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 5 Jun 2013 16:56:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51AFB3FF.7000009@nostrum.com> Date: Wed, 05 Jun 2013 16:56:15 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "ietf@ietf.org" , General Area Review Team , mmusic@ietf.org, draft-ietf-mmusic-rfc2326bis@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 166.147.71.187 is authenticated by a trusted mechanism) Subject: [MMUSIC] Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 21:56:26 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-rfc2326bis-34 Reviewer: Robert Sparks Review Date: 05-Jun-2013 IETF LC End Date: 04-Jun-2013 IESG Telechat date: not yet on a telechat Summary: This draft is on the right track but has open issues, described in the review. I have not reviewed this document at the level of detail I prefer for Gen-art reviews, but have tried to be thorough in the sections I have reviewed. In particular, I didn't verify the tables and the text agree I didn't carefully check the ABNF I haven't thought about possible edge cases and race conditions as much as I would have liked I didn't closely review the security mechanisms in section 19 or the specialized MIKEY keying mechanism in the appendix - both need careful review from security experts. One observation I would like to make before calling out issues and nits: The document is very long, and the structure is unusual - much of the definition of the protocol itself is in the appendices. You are missing an opportunity to make this document much shorter (thereby likely increasing its effectiveness). Much of the jump in from RFC2326 was importing the description of headers and responses from HTTP, tailoring them to RTSP. That was a good exercise in that it highlights some issues that would otherwise be non-obvious (and raises a few questions below). But you followed the style from HTTP perhaps too closely - much shorter descriptions without examples might have done the job better. Overall, separating exposition and examples from the protocol definition would make it much easier for an implementer to find the definition of the protocol, and use the document as a reference when diagnosing a failure to interoperate. Major Issues I'm not seeing what instructs an RTSP element on how to find the server it would try to open a connection to given an rtsp or rtsps URI? Are you assuming it would be doing A or AAAA DNS lookups? Should this protocol use NAPTR/SRV? The document should be explicit. On a related note, (and maybe I missed this), but where do you talk about what an element should check in the server's certificate when connecting over TLS? Are you assuming a common name match? Or are you expecting some SubjectAltName processing? The document should say more about when connection reuse is appropriate, particularly when the connections happened because of an rtsps uri. Two different names might resolve to the same IP address - reusing a connection formed when looking at the first name (and verifying the server's cert) is dangerous. A new connection needs to be formed (and verified) instead. The text talks about the option to queue S->C requests if there isn't a connection to the client available. Ostensibly, this means the request can go down some future connection. It's not clear how the server can tell the right client connected. In particular, when using rtsps, how do you prevent a malicious client from getting such a queued message that wasn't meant for him? Given that the text talks about queuing S-C requests, it should explicitly call out whether a server can queue a response if the connection the associated request arrived on is no longer available. I think what you want to say is that such a response must not be queued, and must be dropped. There are several places in the text that talk about using a 503 response with a Retry-After header to push back on traffic from an element (the first is section 10.7). * It's not clear what the subject of a 503 is. Is it intended to be scoped to requests to the resource in the RURI of the associated request? Is it intended to be scoped to the domain in that resource? Or is it, like in SIP, intended to be scoped to the server issuing the response, independent of what the RURI contained? * If the intent is that the 503 talks about the server, then you should clarify that a proxy doesn't simply forward 503 responses (after rewriting CSeqs), and should probably have a response of its own. Otherwise, clients that might be talking to two different servers through one proxy would lose access to both of them when one of the servers 503ed. Section 4.9.1 lists values the Seek-Style header can take, but 18.45 lists a completely different set (which most of the rest of the document uses). Should 4.9.1 be changed to use the values in 18.45? Are the right strings being used in sections 13.4.4 through 13.4.6? Those appear to be using strings from 4.9.1. The document will not stand if you delete some of the appendices. They aren't supplementary material. Please consider restructuring the normative sections back into the main document, or clearly identifying which ones define protocol and which are background information. Section 15 talks about a "transparent' proxy, but there is no description in this document of what protocol such a thing should follow. What bad thing happens if you remove all mention of "transparent" proxies from the document? As far as I can tell, that won't affect the protocol definition at all. The list of steps for establishing an SRTP cryptographic context in C.1.4.1 says "This specification does not specify an explicit method for indicating this SRTP cryptographic context establishment method, but future specifications may." in the context of looking at the SDP. SDP _has_ methods of indicating what keying mechanism is used with SRTP - are you talking about something different? Why doesn't this section say something like "the use of SRTP with RTSP is only defined with MIKEY with keys established as defined in this section. Future documents may talk about how an RTSP implementation might treat SDP that indicates some other key mechanism be used"? Could you provide an example in the document of an RTSP message carrying SDP reflecting the use of SRTP as defined in this document? Minor Issues The document uses the notion of a "control connection" (it appears first in section 2.5) without defining what that is, or what kind of connections you might have that aren't control connections. The update to the registration of the rtsp and rtsps schema call out that there are changes that can result in interoperability issues. It doesn't say what the issues are, or who might encounter them. I can infer that the point is that there might be problems if a URI following this updated registration were to be processed by an RTSP 1.0 implementation (or any other application that relied on the previous definition). It would be better to say that explicitly, and talk about how a previous implementation is likely to act when presented with a URI that exercised these new changes. (It's not clear to me that all of the thread at www.ietf.org—msg01567.html concluded - I see how the fragments question ended, but what about things like the addition of IPV6 literals? In particular, I'm not finding a response where Ted Hardie agreed that the potential for interoperability failure had been adequately addressed). I think you've said something different than you mean in 5.4 item 1. I think you mean to say that an RTSP implementation would ignore any body that happened to come in message that MUST NOT contain one. What you've said is that the part of the parser that's doing framing has to stop framing at the end of the headers, and that such an errant body would be parsed as a separate message. As written this would keep someone from using an Internet Message Format parser since it would have to ignore any Content-Length that might have appeared, even though it wasn't supposed to. In section 10.4, it looks like a server can keep an RTSP transaction pending forever if it sends 100 responses often enough. I assume the client's recourse if it doesn't want to remain involved is to close the connection. If that's right, it's worth calling it out explicitly in this section. Somewhere, probably in section 15.2, you should be explicit that a proxy that is multiplexing requests MUST keep the requests in the same order as they are folded together. You can infer that, or things simply break, but saying it explicitly would be better. Both GET_PARAMETER and SET_PARAMETER are listed as keep-alive methods in 10.5, but the note in section 13 on table 7 only uses that as a reason for requiring SET_PARAMETER. Why doesn't it also apply to GET_PARAMETER? And why is this only required at servers? "Required" in this section means Mandatory to Implement, I think. If that's right, it should be made explicit. If that's not right, what does it mean? Section 13.8 makes a good argument for always putting parameters to be retrieved in a body. Why are you keeping the complexity of also allowing them in headers? Section 13.10: "That should not provide any benefit." is not clear - can you expand it a little? In Section 13.10 you talk about clients _sending_ media (search for "send or receive media"). Do you mean anything more than possibly RTCP? Can you make that clear in the section? Section 15.2's second paragraph appears to be the only place the proxy rewriting of CSeq in order to multiplex requests is defined, and it is very loose. It would be easy for a reader to fail to recognize this as an interoperability requirement. Please consider expanding how this is specified when addressing the comment about above about keeping requests in relative order when multiplexing. You follow the principle of saying a client should treat a response with an unknown response code, the same as it would treat the x00 of that class (e.g. 400 for an unknown 4xx). However, you do not define what a response code of 300 means. How is a client supposed to handle an unknown 3xx response? As written, a client and server can use HTTP Basic authentication over TCP that is not protected with TLS. Consider restricting it's use to TLS only. Are you sure you don't need to say anything RTSP specific about DIGEST computations (I don't think you need to go as far as SIP did talking about DIGEST, but I'm surprised you haven't run into issues relying only on 2617 literally. How does 411 Length Required for this protocol make sense? Given that you've restricted the protocol to TCP and require the Content-Length header to be present if there is a body, in what circumstance would a server need to send a 411? Section 18.19 requires senders to increment CSeq by 1. We have a reliable transport with no request retransmission, so there should never be gaps at the receiver. Should the receiver check and react some way if there are gaps? I think you should explicitly tell them not to even look. If you agree, why is incrementing by one important as long as you are always strictly increasing? You call out several places where RTCP is essential to allow RTSP using RTP to work correctly, yet section C.1.2 sets up conditions where RTCP MUST NOT be sent. Why are you allowing those instead of treating the conditions you describe as errors? Nits The definition of Message still talks about connectionless transports 22.14 says "These URI schemes are defined in existing registries which are not created by RTSP." Should it say that they are _registered_ rather than defined, and "not created by this document" instead of by RTSP? In section 4.2 in the paragraph discussing ports 554 and 322, why is the language different for rtsp and rtsps? "MUST be used" vs "is registered and MUST be assumed"? Consider a reference in 4.4 to where SMPTE 30 drop is defined, particularly for where the 1/100th frame measurement comes from. Section 4.5 introduces NPT as indicating "the absolute position" and then defines something that can carry a point or a range. I suggest adjusting the first sentence to allow for a range. Section 4.9.1's description of Conditional Random Access contains some ambiguity. It would help be more explicit. I think it's trying to say "would move the client's play point further away from the requested play point than it's play point currently is."? Section 5 : what do you mean by "tricky" switching? Section 7: consider octets instead of bytes Section 10.3: what is "take appropriate action" trying to say? The document mixes using "3rr" and "3xx" to talk about redirect responses. Why are there two ways to say the same thing? (Total nit, but) The examples show dates in 1997, when there could be no RTSP/2.0. Are there other aspects of the examples that might not have been updated? Is "will need to use" at the bottom of page 85 in section 13.5.2 trying to say something that should be said with 2119? Consider saying that a client must not put a Terminate-Reason in a C->S Teardown request, or tweak the definition of Terminate-Reason to discuss client use and the possibility of C->S specific values. These two sentences in 13.7.1 are particularly hard to parse together: "The time period is considered extended when it is 10 times the Session Timeout period. Consideration of the application of the server and its content should be performed when configuring what is considered as extended period of time." I suspect they were not written at the same time? Can you simplify what they are trying to say, noting that the suggested "10 times" is a default, and that if you want to change that default, you need to consider the context? Section 14: "Interleaved binary data SHOULD only be used if RTSP is carried over TCP". Is this leftover from when UDP was an option? (small nit) Section 14, you mention an ASCII dollar sign - maybe you should just say an octet with value 0x24? It's not clear how far up to go with "upper-layer protocol headers" in section 14, given that you are trying to speak generally about carrying things in interleaved data. Your example for RTP may cover the only case that matters. Consider speaking more normatively (instead of with an example) for RTP and provide some guidelines about where to cut the prefixes for other things you might want to carry (lest you end up with the v6 headers too when tunneling some new foo protocol?) In section 17, you say "Status codes that have the same meaning are not repeated here." But you did repeat them (see 200 OK). Should that sentence be deleted? 304 (section 17.3.4) probably should have been a different class response, maybe even a 2xx. The text does call it out as "unusual" for the 3xx, but it would be better to say why this ended up in this response class. I might be confused, but I'm not sure the redirection semantics defined in this document lead to the "black hole" case discussed in 17.4.14. If I'm confused, could you send me an example of such a redirection black hole happening? Section 18.11 first paragraph should be split into two sentences. Is "MUST be transported over TCP" in C.2.1 stale now that no connectionless transport is defined? The end of Appendix G still implies that CSeq was primarily for unreliable transports. There are other places that out and point to proxy multiplexing. All of them should acknowledge that CSeq is necessary for associating responses with requests. From pkyzivat@alum.mit.edu Wed Jun 5 15:18:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9D421E804C for ; Wed, 5 Jun 2013 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfJqaG61oLtD for ; Wed, 5 Jun 2013 15:18:44 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 7423F21E8051 for ; Wed, 5 Jun 2013 15:18:14 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta04.westchester.pa.mail.comcast.net with comcast id kcTl1l0020EZKEL54mJD6u; Wed, 05 Jun 2013 22:18:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id kmJD1l00L3ZTu2S3MmJDDA; Wed, 05 Jun 2013 22:18:13 +0000 Message-ID: <51AFB924.4040508@alum.mit.edu> Date: Wed, 05 Jun 2013 18:18:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370470693; bh=98SinwJCzkRMvq/qqxgHhAyjwu99X5/Su+P6w1fYXbU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sHOXNchtn2SWIquxiuE00F7L6GWGd4yuzOt3OHK8WSzq11Pf0XcjTrLbC1iViF/hv ZVM4FkU3Xlq3sV8+LWrxf+lWQg1hSkAGapN1jtDXjzEMH2Rj4YvnKm2ntwosFZZpTX GZ2XB8h/cXHrn1LS/4TxPVKP1zfejuYh/pVY81JbZydh/ij4xccMHSjs+tJUVAmCwf ai803i95SEyLoFIe2ndBakxmgZGimZ2VXZoZw7Sqh7aLrW5MXta9o4Rj3bc3Cyrtxa NHHEMPsQdgAWOBOVv/Pn30Hh8OfowQwmcl7ENe7QTudZcXBxzNmHicO6gaRNW/oO99 ikxCfSMZbc7WA== Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2013 22:18:49 -0000 On 6/5/13 1:01 PM, Christer Holmberg wrote: > Hi, > >>> I think there are many reasons why one would want to use different m- lines. Eventhough the transport characteristics are the >>> same (if you use BUNDLE, that is), there other things that may be different. Just to give a simple example: the direction attribute value, content attribute value, and anything related to the "scope"/"context" of the m- line. >> >> Christer - I suspect we are on the same page. >> >> I agree there are many reasons one might want to bundle m-lines. >> But I assert that every one of those reasons will also require that you be able to associate incoming packets with a particular one of those m-lines. >> >> I don't understand why this is in question. I originally stated it as a truism because I thought it was self evident. > > Me too. My assumption has from the start been that we need *A* mechanism to associate media with m- lines, as there might be m- line specific characteristics (I haven't gone through all SDP attributes etc with that in mind, though, so I can't give concrete examples at this point) that are needed in order to properly process the media. I thought that relying on PT and/or SSRC/CNAME would cover all cases, but obviously it doesn't. > > For example, I PERSONALLY think one can assume to receive an SDP Answer (including SSRC/CNAME information etc) before media is received. But, as Cullen has another opinion I don't want to waste time on arguing about that - and I am fully aware what 3264 says about receiving media before the SDP answer :) My understanding of this has been evolving as the discussion has continued. That is why I was eventually motivated to start the thread "Associating packets with m-lines in a bundle" because I thought it was a way to crystalize that issue without having to initially agree on *how*. But it turns out that apparently it still isn't universally agreed that its necessary to do that association! The "Plan" discussions make clear that how you intend to use bundling impacts how hard the association will be and what mechanisms for doing it might be sufficient. For instance, if you never bundle more than one m-line of each top level media type (one audio, one video, ...) then PT will probably be sufficient to get the job done. If you use Plan A with a separate m-line for each of 64 video thumbnails, then maybe not. If you use Plan A with CLUE, dynamic switched captures will need something else. So I'm now thinking that BUNDLE with have to be defined without agreement on how the association is done. Rather, it will be up to uses of bundle to specify that. Thanks, Paul > Regards, > > Christer > > >> -----Alkuperäinen viesti----- >> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Puolesta Paul Kyzivat >> Lähetetty: 5. kesäkuuta 2013 18:53 >> Vastaanottaja: Cullen Jennings >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? >> >> On 6/3/13 6:49 PM, Cullen Jennings wrote: >>> >>> On May 27, 2013, at 1:13 PM, Paul Kyzivat wrote: >>> >>>> On 5/27/13 2:52 PM, Colin Perkins wrote: >>>> >>>>>>>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I? >>>>>> >>>>>>> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines. >>>>>> >>>>>> But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines? >>>>> >>>>> You don't. If you care about that, you need to either use distinct PT values for each m= line, or signal SSRCs. >>>> >>>> I assert that if you don't care about associating a packet to a particular m-line in a bundle that you don't need to use bundle. >>> >>> I'm not sure this makes a huge difference to your argument but I don't think I agree with the above. >>> >>> It seems that even if you don't care which m-line the media get associated with, if you want to use a single port for all the m-line, you still need bundle. >> >> I don't understand. Why do you want to use multiple m-lines on one port? >> If you don't need to associate the packets with a particular one of those m-lines, then why didn't you use a single m-line? >> >> E.g., if your reason is because one is audio and another is video then you certainly want to associate the packets with one or the other. >> >> ISTM that the whole point of Plan A is that each m-line is associated with a specific use/rendering, and so it is essential to associate incoming packets with a particular one of the m-lines. >> >> Thanks, >> Paul >> >>>> So if you used bundle, you must care, and so there must be a way to achieve that association. >>>> >>>> The reason you care is because doing so allows you to discover all the other things in that media section of the SDP that may be pertinent to this packet. >>>> >>>> Thanks, >>>> Paul >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fandreas@cisco.com Wed Jun 5 18:03:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42F821F944C for ; Wed, 5 Jun 2013 18:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcVl5MXaZv47 for ; Wed, 5 Jun 2013 18:03:35 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1444521F9425 for ; Wed, 5 Jun 2013 18:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8302; q=dns/txt; s=iport; t=1370480605; x=1371690205; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Xe0RPFWSZvd/AxUTV3dy6RflDin3TocBiAuyYRix2Ao=; b=aYCqOPu1vIfWv0JyKwL03YungapOSyST0NpAA/oDZ1a2u/hKaZCKdlPh LEVbrngzB5FBJafB+vj9bAJ4yNZKDNMALI2eUtUuJE2A6NOSq+mLoxmmY KUO1zadsvEdI+LrWHMPS2Kszm0V6bOCqL4M6skc0e+jyvQv58lLaLql1N Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAOHer1GrRDoI/2dsb2JhbABZgwkwv0J/FnSCIwEBAQMBAQEBNTAGCwULCw4KCSUPAhYwBg0BBQIBAQUSh2wFDbw6jXOBOAeDWwOXP4EpkBeDKyCBLA X-IronPort-AV: E=Sophos;i="4.87,810,1363132800"; d="scan'208";a="79832264" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Jun 2013 01:03:24 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.18.6]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5613NjP003139; Thu, 6 Jun 2013 01:03:23 GMT Message-ID: <51AFDFDB.40500@cisco.com> Date: Wed, 05 Jun 2013 21:03:23 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> In-Reply-To: <51AF14DB.5020009@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "mmusic@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 01:03:40 -0000 On 6/5/13 6:37 AM, Emil Ivov wrote: > Hey Flemming, > > You are right, there are no specific SDP updates that "No Plan" is > asking from mmusic. > > That said however, the same is pretty much true about Plan A and Plan > B. They both discuss ways of using SDP and the extensions that might > be implied to these ways are considered mostly collateral: > > Plan A: > > This document describes a *modest* > set of extensions to SDP which allow it to cleanly handle arbitrary > numbers of flows while still retaining a large degree of backward > compatibility with *existing* and non-RTCWEB endpoints. > > Plan B: > > Plan B mostly uses *existing* IETF standards, introducing a single new > draft [I-D.lennox-mmusic-sdp-source-selection] to specify how > individual media sources can be accepted/rejected at the SSRC level > via SDP. > > I might be off, but it was my understanding that the interim meeting > was not going to be about these specific extensions (which could > possibly be specified regardless of which Plan we go for) but mostly > about the best ways to use SDP with multiple sources. The choices we > make could have an impact on multiple working groups, which, I > assumed, was the main reason for having the discussion mmmusic. > Agree with the latter part. In terms of approaches however, we previously had 2 (A and B), each of which seemed reasonably self-contained, and while clearly driven by RTCWeb, have broader scope than RTCWeb. > In that sense I see "No Plan" as quite related to this discussion. > I agree it's related, but at the same time, the mechanism proposed seems to be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot of the machinery unspecified. Examples from the document: The actual Offer/Answer semantics presented here do not differ fundamentally from those proposed by Plan A and Plan B. The main differentiation point of this approach is the fact that the exact protocol mechanism is left to WebRTC applications. Such applications or lightweight signalling gateways can then implement either Plan A, or Plan B, or an entirely different signalling protocol, depending on what best matches their use cases and topology. and All of the above semantics are best handled and hence should be left to applications. There are numerous existing or emerging solutions, some of them developed by the IETF, that already cover this. This includes CLUE channels [CLUE], the SIP Event Package For Conference State [RFC4575] and its XMPP variant [COIN]. Additional mechanisms, undoubtedly many based on JSON, are very likely to emerge in the future as WebRTC applications address varying use cases, scenarios and topologies. The above may be perfectly reasonable from an RTCWeb point of view, but I don't see MMUSIC as the place to make that decision. On the other hand, if it's more a matter of coming up with a general framework for how to establish/signal sessions that support a multitude of multimedia participants in a session subject to certain requirements (port-efficient, large number of participants can come and go dynamically, per source control of media parameters, etc.) via SDP signaling, then MMUSIC probably is the right place. The document should probably change a bit in some places then. > Am I right in assuming this and if so does the above answer your > question? > I think it's clearly related, however I want to make sure that the scope is not limited to RTCWeb and hence does not assume anything RTCWeb specific (e.g. APIs, etc. which should not be the subject of MMUSIC discussions/documents). I'd like to hear what other people think about this though (incl. the RTCWeb chairs). Thanks -- Flemming > Emil > > On 05.06.13, 06:44, Flemming Andreasen wrote: >> >> On 6/4/13 10:41 PM, Bernard Aboba wrote: >>> Yes, you are missing something. No plan analyzes issues with both >>> Plan A and Plan B and describes how to fix them. As they stand, both >>> Plan A nor Plan B result in O/A exchanges that aren't needed and >>> will break congestion control. Also, neither satisfies the >>> requirements of the RTP usage doc or is compatible with a number of >>> legacy implementations. No plan offers a solution to these and >>> other issues. >> I understand that "no plan" sees issues with Plan A and Plan B as >> currently defined. What I don't understand is what extensions or updates >> to SDP signaling mechanism are being proposed here and hence which part >> of this discussion belongs in MMUSIC as opposed to RTCWeb simply >> specifying how it wants to use a set of current/developing mechanisms >> (or rely on app specific mechanisms, etc.) ? In other words, what does >> "no plan" seek from MMUSIC ? >> >> Thanks >> >> -- Flemming >> >>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" >>> wrote: >>> >>>> On 5/31/13 6:46 AM, Emil Ivov wrote: >>>>> Dear chairs, >>>>> >>>>> Could you please also consider the following draft for the interim >>>>> meeting agenda: >>>>> >>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>> Sure, however I could use some clarification here. On one hand, the >>>> draft falls squarely in the middle of the overall "Plan" discussion >>>> we have and hence is highly relevant, but at the same time, if I >>>> understand correctly, the draft is not asking MMUSIC to do anything >>>> in terms of protocol development. Rather, if this approach is >>>> adopted, it would be more of an RTCWeb usage document specifying >>>> how one could use several different mechanisms (and possibly WebRTC >>>> APIs) to implement signaling. There doesn't seem to be a "mandatory >>>> to implement" mechanism for guaranteeing interoperability (in >>>> contrast to Plan A/B), but rather there are references to "app >>>> specific signalling" mechanisms, etc. Am I missing something here ? >>>> >>>> >>>>> I apologise if not stating this earlier has introduced any confusion. >>>> No worries. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>>> Regards, >>>>> Emil >>>>> >>>>> On 30.05.13, 21:56, IESG Secretary wrote: >>>>>> Greetings, >>>>>> >>>>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>>>> Working Group to take place on Monday, June 17, from 7:00 am - >>>>>> 10:00 am >>>>>> Pacific Time. The goal of this meeting is to come to a resolution >>>>>> on the >>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling >>>>>> needed >>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" >>>>>> lines or >>>>>> very few "m=" lines and to what extent is there sub-negotation and >>>>>> signaling at the SSRC level). >>>>>> >>>>>> A more detailed agenda and logistics will be sent out separately >>>>>> on the >>>>>> MMUSIC mailing list. For now, people should take a close look at the >>>>>> following two drafts: >>>>>> >>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>>>> >>>>>> You may also want to look at >>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Ari & Flemming (MMUSIC co-chairs) >>>>>> >>>>>> >>>>>> PS: Per our previous interim meeting announcement, we tried to >>>>>> schedule >>>>>> a longer and in-person physical interim meeting, however it has >>>>>> proven >>>>>> impossible to find a set of dates where we could get critical >>>>>> mass for >>>>>> such a meeting. Scheduling even a virtual interim before the >>>>>> Berlin IETF >>>>>> has been surprisingly difficult with the above date being the only >>>>>> viable option at this point. >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> > From fluffy@iii.ca Wed Jun 5 22:41:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C3521F84FD for ; Wed, 5 Jun 2013 22:41:42 -0700 (PDT) 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=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-xu5-AieMHs for ; Wed, 5 Jun 2013 22:41:28 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A3EAB21F9651 for ; Wed, 5 Jun 2013 22:41:28 -0700 (PDT) Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6BAFA22E256; Thu, 6 Jun 2013 01:41:25 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Thu, 6 Jun 2013 12:41:28 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <92D69433-78A7-4E90-8088-C8AAD10FB31D@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> To: Bernard Aboba X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:41:42 -0000 inline but I agree On Jun 5, 2013, at 9:09 AM, Bernard Aboba = wrote: > Cullen said:=20 >=20 > > Imagine Alice sends an offer containing=20 > >=20 > > On May 27, 2013, at 10:56 AM, Paul Kyzivat = wrote: > >=20 > > > m=3Daudio 49172 RTP/AVP 96 > > > a=3Dssrc:2222 cname:alice@example.com > > > a=3Drtpmap:96 G7291/16000 > >=20 > > Let say that an offer sent like the above. That means nothing about = the SSRC for the packets that Alice will receive. And it is likely to = receive RTP packets before it receives an answer in some important = scenarios.=20 > >=20 > > So a RTP packet SSRC 3333 arrives. There's no information from the = SSRC about what m-line it matches too (but RTCP for it can be sent).=20 > =20 > [BA] Yes, there is no SSRC info but you do have the PT. Assuming that = the RTP packet has a PT of 96 and that PT value is unique among all m = lines (with BUNDLE), then you know what m line the RTP packet is = referring to, and that it represents an audio packet.=20 yes - so for the layer C or sorting out the which m-line it goes to, I = like the PT if it's unique and if you need more than that then PT + SSRC = info you know.=20 >=20 > > Now an answer from Bob arrives with=20 > >=20 > > m=3Daudio 55555 RTP/AVP 96 > > a=3Dssrc:4444 cname:bob@example.com > > a=3Drtpmap:96 G7291/16000 > >=20 > > Now a packet with SSRC 4444 arrives. That might be from Bob, but = here's the rub. It might be from Charlie. If there was an SSRC = collisions between Bob and Charlie, it will be awhile before some SDP = shows up that says that there was a collisions and now Bob is using SSRC = 5555.=20 > =20 > [BA] I understand why this can happen if Bob is an RTP translator, but = if Bob is another browser, why would packets from Charlie be received on = a peerConnection between Alice and Bob?=20 agree - I should have said it but I was thanking about the hangout type = situation with perhaps 1000s of clients >=20 > > This is all a disaster and the best solutions to it IMHO would be to = define a new RTP Header extension that carries and identifier and that = Alice can tell Bob in the SDP offer what value to put in the identifier = for the RTP from Bob to Alice.=20 > =20 > [BA] RTP extensions are optional, so even if you define one, you've = got to be prepared to handle SSRCs that aren't pre-declared anyway, at = least according to the RTP usage document.=20 agree=20 From fluffy@iii.ca Wed Jun 5 22:41:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2421F96FF for ; Wed, 5 Jun 2013 22:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urWTWBkFhQys for ; Wed, 5 Jun 2013 22:41:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F321F9690 for ; Wed, 5 Jun 2013 22:41:48 -0700 (PDT) Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 56A7F22E259; Thu, 6 Jun 2013 01:41:38 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51AF6490.1040409@alum.mit.edu> Date: Thu, 6 Jun 2013 12:41:41 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> <51AF6490.1040409@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:41:54 -0000 On Jun 5, 2013, at 11:17 PM, Paul Kyzivat wrote: >> And it is likely to receive RTP packets before it receives an answer = in some important scenarios. >=20 > You keep saying that. But is it really true when ICE is used? > Need it be true even without ICE? After all, bundle is new usage, so = we can demand new behavior when using it. So requiring a reliable = provisional with an answer before sending media doesn't seem so = unreasonable. I'm assuming that some applications will bring up a data channel (using = ICE), as soon as the far end starts alerting the user so this will be = done by the time the far end users agrees to send media. At that point = it would be nice to start sending media with no clipping. That allows = all the ICE setup time to disappear from the media clipping latency = problem.=20 I realize lots of applications will not work this way.=20 =20= From fluffy@iii.ca Wed Jun 5 22:42:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374F21F8887 for ; Wed, 5 Jun 2013 22:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3rc7i0nz64A for ; Wed, 5 Jun 2013 22:42:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B900421F96FE for ; Wed, 5 Jun 2013 22:41:57 -0700 (PDT) Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C2A322E25B; Thu, 6 Jun 2013 01:41:51 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> Date: Thu, 6 Jun 2013 12:41:53 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:42:06 -0000 On Jun 6, 2013, at 12:01 AM, Christer Holmberg = wrote: > For example, I PERSONALLY think one can assume to receive an SDP = Answer (including SSRC/CNAME information etc) before media is received. = But, as Cullen has another opinion I don't want to waste time on arguing = about that - and I am fully aware what 3264 says about receiving media = before the SDP answer :) In fairness here we have some different type of deployments = environments. Christer is often concerned about an environment where = using SIP, things like PRACK are used which allows one to get an answer = before media. IN fact media is probably gated and won't work if there is = not an answer before the media. I am often concerned about deployments = environments where PRACK is not supported but media is not gated.=20= From fluffy@iii.ca Wed Jun 5 22:46:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6209C21F9691 for ; Wed, 5 Jun 2013 22:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChLsuyJh9mRS for ; Wed, 5 Jun 2013 22:46:24 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6671921F88EA for ; Wed, 5 Jun 2013 22:46:24 -0700 (PDT) Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E8E5A22E255; Thu, 6 Jun 2013 01:46:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Thu, 6 Jun 2013 12:46:20 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1503) Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" Subject: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:46:30 -0000 On Jun 5, 2013, at 9:41 AM, Bernard Aboba = wrote: > As they stand, both Plan A nor Plan B result in O/A exchanges that = aren't needed and will break congestion control Bernard - that's a pretty strong statement. Uh, you want to explain how = either plan A or B break congestion control? From fluffy@iii.ca Wed Jun 5 22:56:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A5821F96E8 for ; Wed, 5 Jun 2013 22:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj6Wj9+EHV8I for ; Wed, 5 Jun 2013 22:56:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AFB8221F96E7 for ; Wed, 5 Jun 2013 22:56:31 -0700 (PDT) Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C669722E253; Thu, 6 Jun 2013 01:56:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <7AF59844-9B47-4D2D-87FD-D75F7A3E7CDF@csperkins.org> Date: Thu, 6 Jun 2013 12:56:28 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39E31871-187D-4A58-9E3A-F32C894F78D0@iii.ca> References: <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org> <7AF59844-9B47-4D2D-87FD-D75F7A3E7CDF@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1503) Cc: mmusic WG Subject: Re: [MMUSIC] Proposal for what bundle should say about demux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 05:56:36 -0000 Yah - I agree. Nothing inline :-) On Jun 4, 2013, at 12:48 AM, Colin Perkins wrote: > Cullen, >=20 > On 30 May 2013, at 20:06, Cullen Jennings (fluffy) wrote: >> I've been deliberately merging layers A, B, C all into one in my = discussion of this and focusing on the media stack code which has to = deal with all those layers. The reasons I have been doing that is people = just seemed to confused about what all the parts of RTP are such as RTP = sessions. But most people seemed to understand what bits in the various = packets they could look at what and what data had to end up at the right = spot in the end.=20 >=20 > I agree that there is some confusion here. However, rather than = conflate the layers, I think it's important that we clearly identify the = different layers and their purposes. WebRTC is trying to use "advanced" = features of RTP, such as multiple simultaneous streams, FEC, layering, = simulcast, and RTCP-based feedback, within a single session. To make = that work, I think we need a clear understanding of what's done = (conceptually) where, else we're running the risk of the = misunderstandings causing non-interoperable behaviours. >=20 > Conflating all the layers may work for a simple endpoint, with limited = functionality, but I think it will cause increasing problems for WebRTC. = I'd like to get agreement on what conceptual layers exist, and how they = are demultiplexed, to remove this confusion. >=20 >> At a high level, I would draw the layers a little differently than = you in that many of the implementation I work with do the jitter buffer = after the data is decoded. This allows the implementations to do better = packet loss concealment and play rate games where they speed up or slow = down playback very slightly to smoothly adapt the jitter buffer depth.=20= >>=20 >> But regardless of the details of the order, the jitter buffer needs = to look at the SSRC and if the SSRC has changed, it probably needs to = retrain the jitter buffer.=20 >=20 > Sure.=20 >=20 >> Lets talk a bit more about your diagram and what happens when Alice = creates and Offer with that does not have use bundle and has two audio = codecs. When an RTP packets #1 gets sent to Alice and it arrives before = the answer, somewhere in layer B/C, something needs to look at the PT = value to decide what codec this goes to. Alice knows nothing about what = SSRC the other side is using. Now lets say that packet #2 arrives (again = before answer) and packet #2 is on the same port, same PT, but has a = different SSRC. None of the implementations I work with for audio would = allocate a new PB or CR. Instead they would pass packet #2 throughout = the same codec instance that packet #1 had used and expect things like = the jitter buffer to note the SSRC change and act accordingly. For DSP = based audio systems where the actual codec instances are loaded into the = DSP and have a reserved set or resources allocated for them, this is a = very common design.=20 >>=20 >> There is probably more variety in video applications but many = conferences bridges act this way.=20 >>=20 >> So I have no problem if things split on SSRC and whatever processing = that can be done knowing only that is done. That probably includes RTCP, = FEC, RTX , who knows. But before the packed can be decoded by the codec, = something needs to consider the PT and other things such as port when = not doing bundle to make this work. Keep in mind things like PLI are = much more likely to be sent at the layer near the codec than at layer B = so layers B and C are not as cleanly separated as one might wish.=20 >=20 > Sure. A real implementation will have all sorts of links between the = layers. However, I still think there are separate conceptual stages in = the demultiplexing: a) separate by protocol (RTP, RTCP, STUN, SCTP, = etc.) and pass to that conceptual protocol instance; then for RTP and = RTCP packets b) find what RFC 3550 calls synchronisation sources, and do = the RTP and RTCP layer processing, FEC, RTX, etc; and c) relate those = synchronisation sources to higher-layer concepts in the application, = decode the media, and render. >=20 > Finding the synchronisation sources at layer B is straight-forward. = You look at the SSRC field of the RTP and RTCP packets and group, = following RFC 3550. >=20 > Mapping from synchronisation source to codec/rendering context at = layer C can be use any combination of the PT, a=3Dfmtp: parameters of = the PT, SSRC, RTCP SDES items, RTP header extensions, etc., that you = care to signal.=20 >=20 >> That's a long way of saying, I was talking about the aggregate demux = in media stack that include whatever happened at layers B and C. If = layer B only used SSRC that's fine with me. I am trying to say what = happens in the combination of layer B/C put together. =20 >>=20 >> What terminology should I be using to not cause confusion ? >=20 > While you can conflate layers B and C in your implementation, I think = we need to discuss them separately in the specifications to avoid = confusion. Demultiplexing at layer B finds the synchronisation sources = and is an RTP layer feature. I think you're talking about mapping from = synchronisation sources to codecs/rendering pipelines, which is an = operation at layer C of my diagram.=20 >=20 > That is, I think you can do what you want entirely at conceptual layer = C by the considering the mapping from synchronisation sources to codec = and rendering context. I don't think you need to conceptually combine = layers B and C, and I don't think we should combine them in the = specification (of course, just because we specify the demultiplexing as = happening in three conceptual stages doesn't mean you can't implement it = in whatever way you like, provided it has functionally equivalent = behaviour). >=20 > Colin >=20 >=20 >=20 >=20 >=20 >> On May 27, 2013, at 7:57 AM, Colin Perkins wrote: >>=20 >>> I don't agree with the phrasing about "packet processing pipelines", = but can't tell if this is a terminology disagreement or a more = fundamental disconnect. The way I see the demultiplexing logically = working is: >>>=20 >>> | >>> | packets >>> +-- v >>> | +----------+ >>> | |UDP socket| >>> A | +----------+ >>> | RTP || | | >>> | and RTCP || | +------> SCTP >>> | || +---------> STUN/ICE >>> +-- || >>> +-- || >>> | split by SSRC >>> | || || || >>> | || || || >>> B | +--+ +--+ +--+ >>> | |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc. >>> | +--+ +--+ +--+ >>> +-- | | | >>> +-- | / | >>> | +---+ | >>> | / | | >>> C | +--+ +--+ +--+ >>> | |CR| |CR| |CR| Codecs and rendering >>> | +--+ +--+ +--+ >>> +-- >>>=20 >>> If your algorithm is for demultiplexing at layer C, i.e., to figure = out what codec and rendering pipeline to use, then I think we're in = agreement apart from terminology.=20 >>>=20 >>> For layer B, I believe the SSRC is the right thing to use to = demultiplex, and fits with RTP and RTCP. This is where RTCP is = processed, playout de-jitter buffering happens, FEC is processed, NACKs = are sent, etc. It's logically independent of the decoding and rendering = process since you can start filling your de-jitter buffer for an SSRC = before you figure out if/how/where you're going to render that SSRC.=20 >>>=20 >>> For layer A, there was a clear-cut way of doing this with RTP, RTCP, = and STUN. I haven't looked at SCTP enough to know how that affects = things. I do think it's a logically separate issue, and should be = documented separately to BUNDLE though, since it the same issues arise = with non-bundled sessions. >>>=20 >>> An implementation might merge these together, of course, but to = avoid confusion the standards should be clear what level they're = considering. >>>=20 >>> Colin >>>=20 >>>=20 >>>=20 >>> On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote: >>>> Great - sounds like we agree this algorithm will work. >>>>=20 >>>> On May 27, 2013, at 6:41 AM, Colin Perkins = wrote: >>>>=20 >>>>> I'm not sure I agree. >>>>>=20 >>>>> As I said in my previous message to the list, if we are agreed = that the m=3D lines in a BUNDLE group form a single RTP session, then I = believe we need unique payload types across all m=3D lines. In this = case, BUNDLE can simply say that regular RTP source demultiplexing based = on the SSRC has to be performed, then the payload type can be used to = match sources to m=3D lines for those applications that care about doing = so.=20 >>>>>=20 >>>>> If we're not agreed that the m=3D lines in a BUNDLE group form a = single RTP session, then we have a lot more to discuss... >>>>>=20 >>>>> Colin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote: >>>>>> Here's is my proposal for roughly what the bundle draft should = say about this demux topic=20 >>>>>>=20 >>>>>> Application will decide which packet processing pipeline to pass = an given RTP/RTCP packet to based on what the application knows: >>>>>>=20 >>>>>> 1) If future RFCs define new things (like RTP header extension), = that explicitly specify the mapping, check if that future RFC is in use = and if so then use that to form the mapping=20 >>>>>>=20 >>>>>> 2) If the PT type is uniquely identifies a mapping, use that to = form the mapping >>>>>>=20 >>>>>> 3) If application knows the SSRC the other side will use, use = that to form the mapping=20 >>>>>>=20 >>>>>> 4) if there is no way to know which pipeline to pass it too, the = packet MAY be discarded or the application MAY decide to buffer it until = the mapping is known=20 >>>>>>=20 >>>>>> This is trivial to implement. It meets the requirements for Plan = A, Plan B, UCIF, CLUE, and so on.=20 >>>>>>=20 >>>>>> We could swap the order of step 2 and 3, My thinking for this = order was the only time it made any difference the order was if the PT = were unique and indicated a different mapping than the SSRC. The only = way this could happen is with a SSRC collision so the PT is the one that = would be correct not the SSRC. If someone feels strongly the order of = steps 2 and 3 should be the opposite way around, I can live with that. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >=20 > ... >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emcho@sip-communicator.org Thu Jun 6 00:06:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89F021F8F9E for ; Thu, 6 Jun 2013 00:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+uZNx0f4HMd for ; Thu, 6 Jun 2013 00:06:43 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0A021F8EDF for ; Thu, 6 Jun 2013 00:06:43 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so2843818pbb.8 for ; Thu, 06 Jun 2013 00:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=iPenRUGiZ/zcMBGh2NaTo1de9hesUxGRB7wURXOOOxM=; b=HXh2h+XUw5U7zJkYEiUiseDXlKV32RRJbezPyrh46iCQ/pcgVzRTuD/NMsj/iUp79U S9h/9Z6e7PAkLtkTBe3RZV8iXYe4klLw0AmTdmxPimfs1zad5Nki1MyLfZIJcTV2TGAZ 9qa8LB9F7lLGRvnymgcPFv8y4/RUg1tnu1Hi3BCOEKVmioXvSBUV7vA+zaGIPHko3l89 VAqoLDszAFZuSExx6/OggVdXePpIE+8+E1czhMAuJwgTFaumB+ifydbY6r5q8ZsVoe0e bS6WUTII0FyINqo1GstlpjVnYI6LewjhEqGboBjzYct9R0r6TldfOl6PWp5jd+tTXXRz Rnmw== X-Received: by 10.67.21.226 with SMTP id hn2mr35921853pad.135.1370502402988; Thu, 06 Jun 2013 00:06:42 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by mx.google.com with ESMTPSA id ya4sm71571684pbb.24.2013.06.06.00.06.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 00:06:42 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so2935912pdd.6 for ; Thu, 06 Jun 2013 00:06:42 -0700 (PDT) X-Received: by 10.66.232.69 with SMTP id tm5mr37731780pac.120.1370502402022; Thu, 06 Jun 2013 00:06:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.192.65 with HTTP; Thu, 6 Jun 2013 00:06:20 -0700 (PDT) In-Reply-To: <51AFDFDB.40500@cisco.com> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> <51AFDFDB.40500@cisco.com> From: Emil Ivov Date: Thu, 6 Jun 2013 09:06:20 +0200 Message-ID: To: Flemming Andreasen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk4rhzOlVizrPNwBvfjtpRROcVy+gKyaEJA7J7+EMpUUaszfqoXTa0qYWijOeWbFapdjPJ2 Cc: Ari Keranen , "mmusic@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 07:06:44 -0000 Hey Flemming, Just to be clear, are you saying all this because you believe No Plan should NOT be on the agenda of the mmusic interim meeting? Emil On Thu, Jun 6, 2013 at 3:03 AM, Flemming Andreasen wrote: > > On 6/5/13 6:37 AM, Emil Ivov wrote: >> >> Hey Flemming, >> >> You are right, there are no specific SDP updates that "No Plan" is asking >> from mmusic. >> >> That said however, the same is pretty much true about Plan A and Plan B. >> They both discuss ways of using SDP and the extensions that might be implied >> to these ways are considered mostly collateral: >> >> Plan A: >> >> This document describes a *modest* >> set of extensions to SDP which allow it to cleanly handle arbitrary >> numbers of flows while still retaining a large degree of backward >> compatibility with *existing* and non-RTCWEB endpoints. >> >> Plan B: >> >> Plan B mostly uses *existing* IETF standards, introducing a single new >> draft [I-D.lennox-mmusic-sdp-source-selection] to specify how >> individual media sources can be accepted/rejected at the SSRC level >> via SDP. >> >> I might be off, but it was my understanding that the interim meeting was >> not going to be about these specific extensions (which could possibly be >> specified regardless of which Plan we go for) but mostly about the best ways >> to use SDP with multiple sources. The choices we make could have an impact >> on multiple working groups, which, I assumed, was the main reason for having >> the discussion mmmusic. >> > Agree with the latter part. In terms of approaches however, we previously > had 2 (A and B), each of which seemed reasonably self-contained, and while > clearly driven by RTCWeb, have broader scope than RTCWeb. > > >> In that sense I see "No Plan" as quite related to this discussion. >> > I agree it's related, but at the same time, the mechanism proposed seems to > be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot of > the machinery unspecified. Examples from the document: > > The actual Offer/Answer semantics presented here do not differ > fundamentally from those proposed by Plan A and Plan B. The main > differentiation point of this approach is the fact that the exact > protocol mechanism is left to WebRTC applications. Such applications > or lightweight signalling gateways can then implement either Plan A, > or Plan B, or an entirely different signalling protocol, depending on > what best matches their use cases and topology. > > > and > > > All of the above semantics are best handled and hence should be left > to applications. There are numerous existing or emerging solutions, > some of them developed by the IETF, that already cover this. This > includes CLUE channels [CLUE], the SIP Event Package For Conference > State [RFC4575] and its XMPP variant [COIN]. Additional mechanisms, > undoubtedly many based on JSON, are very likely to emerge in the > future as WebRTC applications address varying use cases, scenarios > and topologies. > > > The above may be perfectly reasonable from an RTCWeb point of view, but I > don't see MMUSIC as the place to make that decision. On the other hand, if > it's more a matter of coming up with a general framework for how to > establish/signal sessions that support a multitude of multimedia > participants in a session subject to certain requirements (port-efficient, > large number of participants can come and go dynamically, per source control > of media parameters, etc.) via SDP signaling, then MMUSIC probably is the > right place. The document should probably change a bit in some places then. > > >> Am I right in assuming this and if so does the above answer your question? >> > I think it's clearly related, however I want to make sure that the scope is > not limited to RTCWeb and hence does not assume anything RTCWeb specific > (e.g. APIs, etc. which should not be the subject of MMUSIC > discussions/documents). > > I'd like to hear what other people think about this though (incl. the RTCWeb > chairs). > > Thanks > > -- Flemming > > >> Emil >> >> On 05.06.13, 06:44, Flemming Andreasen wrote: >>> >>> >>> On 6/4/13 10:41 PM, Bernard Aboba wrote: >>>> >>>> Yes, you are missing something. No plan analyzes issues with both Plan A >>>> and Plan B and describes how to fix them. As they stand, both Plan A nor >>>> Plan B result in O/A exchanges that aren't needed and will break congestion >>>> control. Also, neither satisfies the requirements of the RTP usage doc or is >>>> compatible with a number of legacy implementations. No plan offers a >>>> solution to these and other issues. >>> >>> I understand that "no plan" sees issues with Plan A and Plan B as >>> currently defined. What I don't understand is what extensions or updates >>> to SDP signaling mechanism are being proposed here and hence which part >>> of this discussion belongs in MMUSIC as opposed to RTCWeb simply >>> specifying how it wants to use a set of current/developing mechanisms >>> (or rely on app specific mechanisms, etc.) ? In other words, what does >>> "no plan" seek from MMUSIC ? >>> >>> Thanks >>> >>> -- Flemming >>> >>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" >>>> wrote: >>>> >>>>> On 5/31/13 6:46 AM, Emil Ivov wrote: >>>>>> >>>>>> Dear chairs, >>>>>> >>>>>> Could you please also consider the following draft for the interim >>>>>> meeting agenda: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>> >>>>> Sure, however I could use some clarification here. On one hand, the >>>>> draft falls squarely in the middle of the overall "Plan" discussion we have >>>>> and hence is highly relevant, but at the same time, if I understand >>>>> correctly, the draft is not asking MMUSIC to do anything in terms of >>>>> protocol development. Rather, if this approach is adopted, it would be more >>>>> of an RTCWeb usage document specifying how one could use several different >>>>> mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't >>>>> seem to be a "mandatory to implement" mechanism for guaranteeing >>>>> interoperability (in contrast to Plan A/B), but rather there are references >>>>> to "app specific signalling" mechanisms, etc. Am I missing something here ? >>>>> >>>>> >>>>>> I apologise if not stating this earlier has introduced any confusion. >>>>> >>>>> No worries. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>>> Regards, >>>>>> Emil >>>>>> >>>>>> On 30.05.13, 21:56, IESG Secretary wrote: >>>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>>>>> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 >>>>>>> am >>>>>>> Pacific Time. The goal of this meeting is to come to a resolution on >>>>>>> the >>>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling >>>>>>> needed >>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines >>>>>>> or >>>>>>> very few "m=" lines and to what extent is there sub-negotation and >>>>>>> signaling at the SSRC level). >>>>>>> >>>>>>> A more detailed agenda and logistics will be sent out separately on >>>>>>> the >>>>>>> MMUSIC mailing list. For now, people should take a close look at the >>>>>>> following two drafts: >>>>>>> >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>>>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>>>>> >>>>>>> You may also want to look at >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Ari & Flemming (MMUSIC co-chairs) >>>>>>> >>>>>>> >>>>>>> PS: Per our previous interim meeting announcement, we tried to >>>>>>> schedule >>>>>>> a longer and in-person physical interim meeting, however it has >>>>>>> proven >>>>>>> impossible to find a set of dates where we could get critical mass >>>>>>> for >>>>>>> such a meeting. Scheduling even a virtual interim before the Berlin >>>>>>> IETF >>>>>>> has been surprisingly difficult with the above date being the only >>>>>>> viable option at this point. >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> . >>>> >>> >>> >> > -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From bernard_aboba@hotmail.com Thu Jun 6 04:04:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8426221F995C for ; Thu, 6 Jun 2013 04:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVVzXjHrdbPx for ; Thu, 6 Jun 2013 04:04:44 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by ietfa.amsl.com (Postfix) with ESMTP id CB39A21F9955 for ; Thu, 6 Jun 2013 04:04:38 -0700 (PDT) Received: from BLU402-EAS92 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jun 2013 04:04:34 -0700 X-TMN: [F3ips0GhOh7FkXIwdHftZhYG9dlLBrOV] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se> <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se> <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51AF6BB9.3010807@alum.mit.edu> Date: Thu, 6 Jun 2013 04:04:32 -0700 To: Paul Kyzivat X-OriginalArrivalTime: 06 Jun 2013 11:04:34.0046 (UTC) FILETIME=[A06591E0:01CE62A5] Cc: "mmusic@ietf.org" , Cullen Jennings , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 11:04:50 -0000 On Jun 5, 2013, at 9:48 AM, "Paul Kyzivat" wrote: >> ISTM that the whole point of Plan A is that each m-line is associated wit= h a specific use/rendering, and so it is essential to associate incoming pac= kets with a particular one of the m-lines. [BA] The above implies some interesting interactions with BUNDLE. For exampl= e, in H.264/SVC, in the unicast case, multiple layers are transported in the= same RTP session, with or without BUNDLE. Therefore if each layer has its o= wn m line, both sides MUST support BUNDLE to enable negotiation of layered c= oding even if there is no interest in bundling multiple media on the same RT= P port. This is not true of Plan B ( or No Plan). From internet-drafts@ietf.org Thu Jun 6 04:16:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AC121F997B; Thu, 6 Jun 2013 04:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgyRE0+z42po; Thu, 6 Jun 2013 04:16:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9421F938E; Thu, 6 Jun 2013 04:15:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606111553.4425.57323.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 04:15:53 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:16:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Audio and Video Media Streams Over Circuit-Switched Bearers In The Public = Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-20.txt Pages : 36 Date : 2013-06-06 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=586938eb54=christer.holmberg@ericsson.com Thu Jun 6 04:18:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF03E21F994F for ; Thu, 6 Jun 2013 04:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqVzAC2NV7zo for ; Thu, 6 Jun 2013 04:18:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92C21F995A for ; Thu, 6 Jun 2013 04:17:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-a3-51b06fe5a038 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 62.9B.15700.5EF60B15; Thu, 6 Jun 2013 13:17:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 13:17:57 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+Kg== Date: Thu, 6 Jun 2013 11:17:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C383F1EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre7T/A2BBqf+2Vh0TGazONbXxWYx dfljFgdmjysTrrB6TPm9kdVjyZKfTAHMUdw2SYklZcGZ6Xn6dgncGW3HH7IWHNjBUtG78Rxr A+PRH8xdjJwcEgImEl3H5rFC2GISF+6tZwOxhQQOM0r8WqXdxcgFZC9mlLhwfBpQgoODTcBC ovufNkiNiIC6xNe9PcwgNcwCDYwSf261s4MkhAWMJWYvfcMIUWQhsenLEhYIW0/izv+JYMtY BFQkns3cBRbnFfCVWPfnJ1icEeiI76fWMIHYzALiEreezGeCOE5AYsme81BHi0q8fPyPFeQe CQFFieX9ciAms0C+RP+KYoiJghInZz5hmcAoPAvJoFkIVbOQVEGU6Egs2P2JDcLWlli28DUz jH3mwGMmZPEFjOyrGNlzEzNz0ssNNzECo+bglt+6OxhPnRM5xCjNwaIkzqvHuzhQSCA9sSQ1 OzW1ILUovqg0J7X4ECMTByeI4JJqYCxK0ik2z55j8+eX5W7XLvfHH/Ni11+weKC3OUjlk43U Ja3kCK/dHkfeZ266sUhmb+nns9OOvdjfYWIxcffRD1f9t5nNFy/mrljgduzVb73QLaGFUin/ v+Ydf61Ydrk4U9A1LiwudyEj44SbnpGq766db3v4eu0fSa2Vn+4mfjj2/vxy0/X13Q1KLMUZ iYZazEXFiQD+UT7VbQIAAA== X-Mailman-Approved-At: Thu, 06 Jun 2013 04:19:04 -0700 Cc: "Cullen Jennings \(fluffy@cisco.com\)" Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 11:18:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C383F1EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok folks, Below is some Offerer text for BUNDLE. I've also included some examples. As we have discussed, Bundle Sync Offer may not be good terminology, but ag= ain I'd like to focus more on the technical content, and the "understandabi= lity" of the text, for now :) Also note that the text currently assumes that a port zero m=3D line CANNOT= be inside a BUNDLE group. That may change (depending on how we move forwar= d with the plans etc), but should not have a huge impact on the text, apart from the section talking a= bout disabling an "m=3D" line in a BUNDLE group. Also, the definition of "bundle address" WILL be defined, but it's more or = less the IP port, address and ICE information associated with the transport= plane. Happy reading! Regards, Christer ---------------------------------- 6.2. SDP Offerer Procedures 6.2.1. General This section describes how an Offerer creates an SDP Offer which includes a BUNDLE group. An SDP Offer that includes a BUNDLE group can be categorized either as a Bundle Restart Offer (BRO) Section 6.2.2.1 or as a Bundle Sync Offer (BSO) Section 6.2.2.2. 6.2.2. SDP Offer Types 6.2.2.1. Bundle Restart Offer (BRO) A Bundle Restart Offer (BRO) is used to negotiate (or re-negotiate) the usage of the BUNDLE mechanism, and/or the bundle address used by the "m=3D" lines in a BUNDLE group. In a BRO, the Offerer assigns a unique address to at least one "m=3D" line in a BUNDLE group. Such "m=3D" lines can be removed from the BUNDLE group by the Answerer (see [xxx]), as the unique address can be used outside the BUNDLE group. In a BRO, the Offerer assigns, for each "m=3D" line in the BUNDLE group, either a unique address, or a previously negotiated bundle address, as long as a unique address is assigned to at least one "m=3D" line in the BUNDLE group (if the bundle address is assigned to each "m=3D" line in the BUNDLE group, the SDP Offer is by definition a Bundle Sync Offer (BSO) Section 6.2.2.2. When a session is initiated, if the Offerer does not know whether the Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a BRO, and the Offerer MUST assign a unique address to each "m=3D" line in the BUNDLE group. If, in the SDP Answer associated with the BRO, the offered BUNDLE group is accepted [ref-to-be-added], the Offerer MUST, for each "m=3D" line in the BUNDLE group, start to use its local bundle address, and the remote bundle address, both selected by the Answerer [ref-to-be- added]. In addition, the Offerer MUST send a Bundle Sync Offer (BSO) Section 6.2.2.2, in which the bundle address is assigned to each "m=3D" line in the BUNDLE group. NOTE: The Offerer needs to send the BSO as soon as possible, in order to make sure intermediaries are aware that the bundle address will be used for each "m=3D" line in the BUNDLE group. However, the exact moment for sending the BSO might depend on other features and extensions (e.g. ICE) also used by the Offerer, that also require the sending of subsequent SDP Offers. Example: The example shows a BRO, where a unique address is assigned to each "m=3D" line in the BUNDLE group. The Offerer requests the address associated with the audio "m=3D" line to be selected as its bundle address, by placing the mid value associated with the "m=3D" line first in the SDP group:BUNDLE attribute mid list. SDP Offer (Bundle Restart Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 20000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 6.2.2.2. Bundle Sync Offer (BSO) A Bundle Sync Offer (BSO) is used when the Offerer does not want to re-negotiate the usage of the BUNDLE mechanism, and/or the bundle address. The Offerer can, using a BSO, re-negotiate other parameters associated with the BUNDLE group, however. In a BSO, the Offerer MUST assign the bundle address to each "m=3D" line in a BUNDLE group. Such "m=3D" lines can not be removed from the BUNDLE group by the Answerer [ref-to-be-added], as the bundle address can not be used outside the BUNDLE group. Example: The example shows a BSO, where the bundle address is assigned to each "m=3D" line in the BUNDLE group. SDP Offer (Bundle Sync Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 6.2.3. Use Cases 6.2.3.1. Offerer Bundle Address Request In order to negotiate (or re-negotiate) the bundle address, the Offerer MUST send a BRO. In the BRO, as the Offerer assigns a unique address to some (or all) "m=3D" lines in the BUNDLE group, the Offerer needs to indicate to the Answerer which address, associated with one of the "m=3D" lines in the BUNDLE group, it wishes to use as its local bundle address. The first mid value in the SDP group:BUNDLE attribute mid value list represents the "m=3D" line address with the highest preference. The Answerer will select the local bundle address for the Offerer, as described in Section 6.3.3. The Offerer MUST use the bundle address selected by the Answerer. If the Offerer is not able to use that bundle address, it MUST either terminate the session, or send a new BRO. Example: The example shows a BRO, where a unique address is assigned to each "m=3D" line in the BUNDLE group. The Offerer requests the address associated with the audio "m=3D" line to be selected as its bundle address, by placing the mid value associated with the "m=3D" line first in the SDP group:BUNDLE attribute mid list. SDP Offer (Bundle Restart Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 20000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 6.2.3.2. Adding a media description to a BUNDLE group When adding an "m=3D" line to a BUNDLE group, the Offerer generates either a BRO or BSO. In case of a BSO, the Offerer assigns the bundle address to each "m=3D" line (including the new one) in the BUNDLE group. In case of a BRO, the Offerer assigns, for each "m=3D" line (including the new one), either a unique address, or the bundle address (only the bundle address can be assigned to more than one "m=3D" line in the BUNDLE group). Example: The example shows a BRO, where a new "m=3D" line, identified by the "zen" mid value, is added to a BUNDLE group. The bundle address is assigned to each of the current "m=3D" lines in the BUNDLE group, while a unique address is assigned to the new "m=3D" line. The Offerer requests that the bundle address is not changed, by placing the mid value associated with the audio "m=3D" line, for which the previously negotiated bundle address is assigned, first in the SDP group:BUNDLE attribute mid list. SDP Offer (Bundle Restart Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar zen m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 30000 RTP/AVP 60 a=3Dmid:zen b=3DAS:1000 a=3Drtpmap:60 H261/90000 Example: The example shows a BSO, where a new "m=3D" line, identified by the "zen" mid value, is added to a BUNDLE group. The previously negotiated bundle address assigned to each "m=3D" line (the current ones and the new one) in the BUNDLE group. SDP Offer (Bundle Sync Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar zen m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 10000 RTP/AVP 60 a=3Dmid:zen b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.3.3. Removing A Media Description From A BUNDLE Group In order to remove an "m=3D" line from a BUNDLE group, the Offerer generates either a BRO or BSO. The Offerer MUST remove the "m=3D" line, and its associated mid value, from the BUNDLE group, and the Offerer MUST assign a unique address to the removed "m=3D" line. Example: The example shows a BSO, where an "m=3D" line is removed from a BUNDLE group. The Offerer removes the mid ("zen") associated with the "m=3D" line from the SDP group:BUNDLE attribute mid value list, and assigns a unique address to the removed "m=3D" line. SDP Offer (Bundle Sync Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 40000 RTP/AVP 60 b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.3.4. Disabling A Media Description In A BUNDLE Group In order to disable an "m=3D" line in a BUNDLE group, the Offerer generates either a BRO or BSO. The Offerer MUST remove the disabled "m=3D" line, and its associated mid value, from the BUNDLE group. In addition, the Offerer assigns a zero port value to the "m=3D" line, according to the procedures in RFC 3264. Example: The example shows a BSO, where an "m=3D" line is disabled in (and removed from) a BUNDLE group. The Offerer removes the mid ("zen") associated with the disabled "m=3D" line from the SDP group:BUNDLE attribute mid value list, and assigns a port zero value to the "m=3D" line. SDP Offer (Bundle Sync Offer) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 0 RTP/AVP 60 a=3Drtpmap:60 H261/90000 OPEN ISSUE: It is FFS whether it is allowed to include a port zero media descriptions in a BUNDLE group. --_000_7594FB04B1934943A5C02806D1A2204B1C383F1EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok folks,

 

Below is some Offerer text for BUNDLE. I’ve al= so included some examples.

 

As we have discussed, Bundle Sync Offer may not be g= ood terminology, but again I’d like to focus more on the technical co= ntent, and the “understandability” of the text, for now :)=

 

Also note that the text currently assumes that a por= t zero m=3D line CANNOT be inside a BUNDLE group. That may change (dependin= g on how we move forward with the plans etc), but

should not have a huge impact on the text, apart fro= m the section talking about disabling an “m=3D” line in a BUNDL= E group.

 

Also, the definition of “bundle address”= WILL be defined, but it’s more or less the IP port, address and ICE = information associated with the transport plane.

 

Happy reading!

 

Regards,

 

Christer

 

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

 

 

6.2.  SDP Offerer Procedures

 

6.2.1.  General

 

   This section describes how an Offerer creates= an SDP Offer which

   includes a BUNDLE group.

 

   An SDP Offer that includes a BUNDLE group can= be categorized either

   as a Bundle Restart Offer (BRO) Section 6.2.2= .1 or as a Bundle Sync

   Offer (BSO) Section 6.2.2.2.

 

6.2.2.  SDP Offer Types

 

6.2.2.1.  Bundle Restart Offer (BRO)

 

   A Bundle Restart Offer (BRO) is used to negot= iate (or re-negotiate)

   the usage of the BUNDLE mechanism, and/or the= bundle address used by

   the "m=3D" lines in a BUNDLE group.=

 

   In a BRO, the Offerer assigns a unique addres= s to at least one "m=3D"

   line in a BUNDLE group.  Such "m=3D= " lines can be removed from the

   BUNDLE group by the Answerer (see [xxx]), as = the unique address can

   be used outside the BUNDLE group.<= /span>

 

   In a BRO, the Offerer assigns, for each "= ;m=3D" line in the BUNDLE

   group, either a unique address, or a previous= ly negotiated bundle

   address, as long as a unique address is assig= ned to at least one "m=3D"

   line in the BUNDLE group (if the bundle addre= ss is assigned to each

   "m=3D" line in the BUNDLE group, th= e SDP Offer is by definition a

   Bundle Sync Offer (BSO) Section 6.2.2.2.=

 

   When a session is initiated, if the Offerer d= oes not know whether the

   Answerer supports the BUNDLE mechanism, the O= fferer MUST initiate a

   BRO, and the Offerer MUST assign a unique add= ress to each "m=3D" line

   in the BUNDLE group.

 

   If, in the SDP Answer associated with the BRO= , the offered BUNDLE

   group is accepted [ref-to-be-added], the Offe= rer MUST, for each "m=3D"

   line in the BUNDLE group, start to use its lo= cal bundle address, and

   the remote bundle address, both selected by t= he Answerer [ref-to-be-

   added].  In addition, the Offerer MUST s= end a Bundle Sync Offer (BSO)

   Section 6.2.2.2, in which the bundle address = is assigned to each "m=3D"

   line in the BUNDLE group.

 

   NOTE: The Offerer needs to send the BSO as so= on as possible, in order

   to make sure intermediaries are aware that th= e bundle address will be

   used for each "m=3D" line in the BU= NDLE group.  However, the exact

   moment for sending the BSO might depend on ot= her features and

   extensions (e.g. ICE) also used by the Offere= r, that also require the

   sending of subsequent SDP Offers.<= /span>

 

   Example: The example shows a BRO, where a uni= que address is assigned

   to each "m=3D" line in the BUNDLE g= roup.  The Offerer requests the

   address associated with the audio "m=3D&= quot; line to be selected as its

   bundle address, by placing the mid value asso= ciated with the "m=3D"

   line first in the SDP group:BUNDLE attribute = mid list.

 

 

   SDP Offer (Bundle Restart Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 20000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

 

 

 

6.2.2.2.  Bundle Sync Offer (BSO)

 

   A Bundle Sync Offer (BSO) is used when the Of= ferer does not want to

   re-negotiate the usage of the BUNDLE mechanis= m, and/or the bundle

   address.  The Offerer can, using a BSO, = re-negotiate other parameters

   associated with the BUNDLE group, however.

 

   In a BSO, the Offerer MUST assign the bundle = address to each "m=3D"

   line in a BUNDLE group.  Such "m=3D= " lines can not be removed from the

   BUNDLE group by the Answerer [ref-to-be-added= ], as the bundle address

   can not be used outside the BUNDLE group.

 

   Example: The example shows a BSO, where the b= undle address is

   assigned to each "m=3D" line in the= BUNDLE group.

 

 

   SDP Offer (Bundle Sync Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

 

 

 

6.2.3.  Use Cases

 

6.2.3.1.  Offerer Bundle Address Request

 

   In order to negotiate (or re-negotiate) the b= undle address, the

   Offerer MUST send a BRO.  In the BRO, as= the Offerer assigns a unique

   address to some (or all) "m=3D" lin= es in the BUNDLE group, the Offerer

   needs to indicate to the Answerer which addre= ss, associated with one

   of the "m=3D" lines in the BUNDLE g= roup, it wishes to use as its local

   bundle address.  The first mid value in = the SDP group:BUNDLE

   attribute mid value list represents the "= ;m=3D" line address with the

   highest preference.

 

   The Answerer will select the local bundle add= ress for the Offerer, as

   described in Section 6.3.3.  The Offerer= MUST use the bundle address

   selected by the Answerer.  If the Offere= r is not able to use that

   bundle address, it MUST either terminate the = session, or send a new

   BRO.

 

   Example: The example shows a BRO, where a uni= que address is assigned

   to each "m=3D" line in the BUNDLE g= roup.  The Offerer requests the

   address associated with the audio "m=3D&= quot; line to be selected as its

   bundle address, by placing the mid value asso= ciated with the "m=3D"

   line first in the SDP group:BUNDLE attribute = mid list.

 

 

   SDP Offer (Bundle Restart Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 20000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

 

 

 

6.2.3.2.  Adding a media description to a BUNDLE grou= p

 

   When adding an "m=3D" line to a BUN= DLE group, the Offerer generates

   either a BRO or BSO.  In case of a BSO, = the Offerer assigns the

   bundle address to each "m=3D" line = (including the new one) in the

   BUNDLE group.  In case of a BRO, the Off= erer assigns, for each "m=3D"

   line (including the new one), either a unique= address, or the bundle

   address (only the bundle address can be assig= ned to more than one

   "m=3D" line in the BUNDLE group).

 

   Example: The example shows a BRO, where a new= "m=3D" line, identified

   by the "zen" mid value, is added to= a BUNDLE group.  The bundle

   address is assigned to each of the current &q= uot;m=3D" lines in the BUNDLE

   group, while a unique address is assigned to = the new "m=3D" line.  The

   Offerer requests that the bundle address is n= ot changed, by placing

   the mid value associated with the audio "= ;m=3D" line, for which the

   previously negotiated bundle address is assig= ned, first in the SDP

   group:BUNDLE attribute mid list.

 

 

   SDP Offer (Bundle Restart Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar zen

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 30000 RTP/A= VP 60

       a=3Dmid:zen

       b=3DAS:1000

       a=3Drtpmap:60 H261/90= 000

 

 

 

   Example: The example shows a BSO, where a new= "m=3D" line, identified

   by the "zen" mid value, is added to= a BUNDLE group.  The previously

   negotiated bundle address assigned to each &q= uot;m=3D" line (the current

   ones and the new one) in the BUNDLE group.

 

 

   SDP Offer (Bundle Sync Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar zen

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 10000 RTP/A= VP 60

       a=3Dmid:zen

       b=3DAS:1000

       a=3Drtpmap:60 H261/90= 000

 

 

 

6.2.3.3.  Removing A Media Description From A BUNDLE = Group

 

   In order to remove an "m=3D" line f= rom a BUNDLE group, the Offerer

   generates either a BRO or BSO.  The Offe= rer MUST remove the "m=3D"

   line, and its associated mid value, from the = BUNDLE group, and the

   Offerer MUST assign a unique address to the r= emoved "m=3D" line.

 

   Example: The example shows a BSO, where an &q= uot;m=3D" line is removed from

   a BUNDLE group.  The Offerer removes the= mid ("zen") associated with

   the "m=3D" line from the SDP group:= BUNDLE attribute mid value list, and

   assigns a unique address to the removed "= ;m=3D" line.

 

 

   SDP Offer (Bundle Sync Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 40000 RTP/A= VP 60

       b=3DAS:1000

       a=3Drtpmap:60 H261/90= 000

 

 

 

6.2.3.4.  Disabling A Media Description In A BUNDLE G= roup

 

   In order to disable an "m=3D" line = in a BUNDLE group, the Offerer

   generates either a BRO or BSO.  The Offe= rer MUST remove the disabled

   "m=3D" line, and its associated mid= value, from the BUNDLE group.  In

   addition, the Offerer assigns a zero port val= ue to the "m=3D" line,

   according to the procedures in RFC 3264.=

 

   Example: The example shows a BSO, where an &q= uot;m=3D" line is disabled in

   (and removed from) a BUNDLE group.  The = Offerer removes the mid

   ("zen") associated with the disable= d "m=3D" line from the SDP

   group:BUNDLE attribute mid value list, and as= signs a port zero value

   to the "m=3D" line.

 

 

   SDP Offer (Bundle Sync Offer)

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 0 RTP/AVP 6= 0

       a=3Drtpmap:60 H261/90= 000

 

 

 

   OPEN ISSUE: It is FFS whether it is allowed t= o include a port zero

   media descriptions in a BUNDLE group.

 

--_000_7594FB04B1934943A5C02806D1A2204B1C383F1EESESSMB209erics_-- From Simo.Veikkolainen@nokia.com Thu Jun 6 04:28:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C23721F99D0; Thu, 6 Jun 2013 04:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4XheVgyGCpA; Thu, 6 Jun 2013 04:28:50 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8D61D21F9961; Thu, 6 Jun 2013 04:28:50 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r56BRw9G005213; Thu, 6 Jun 2013 14:28:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jun 2013 14:28:22 +0300 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.171]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0328.011; Thu, 6 Jun 2013 11:28:21 +0000 From: To: , Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-20.txt Thread-Index: AQHOYqdknR7ZXCYr60uOImKmbF3g+JkoiZ4Q Date: Thu, 6 Jun 2013 11:29:37 +0000 Message-ID: References: <20130606111553.4425.57323.idtracker@ietfa.amsl.com> In-Reply-To: <20130606111553.4425.57323.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYmJIQs9KGFmJZTy8NRFkCzQOOhYjJ8HyZtX9yhqX0Bn4hauB8bX/i9REJk/lDBwIth9wG+8bGGZ4CdhExSyG9i4Tw9g0voZ5Zz5s61vy4WfUT0DlqMRr5WBuUcwkEbuDOv/RqK5YFB0uoBikytLwY25f7vXvLsT9V8ZudskDww2V4KlGt69D39SiUEGJQQZV/g== x-originating-ip: [172.21.82.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2013 11:28:22.0557 (UTC) FILETIME=[F3DB0CD0:01CE62A8] X-Nokia-AV: Clean Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:28:55 -0000 Hi, One more update due to IESG review: - clarified the text in Section 5.2.3 Correlating the PSTN Circuit-Switched= Bearer and Section 5.6.1 Generating the Initial Offer so that all three c= orrelation mechanisms are mandatory to implement - added text Section 5.3.3. Considerations on correlations that endpoints s= hould offer all supported correlation mechanisms, unless there is a priori = knowledge that some of the correlation mechanisms will not work, or there i= s policy enforced by an endpoint which restricts the use of a specific corr= elation mechanism (like in the case of DTMF based mechanism, which require = answering the CS call before DTMF tones can be sent; some endpoints may not= be willing to answer a call due to costs related to answered CS call). Regards, Simo https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs=20 http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-20=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 6. kes=E4kuuta 2013 14:16 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-20.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Audio and Video Media Streams Over Circuit-Switched Bearers In The Public = Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-20.txt Pages : 36 Date : 2013-06-06 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=8869b5063b=stefan.lk.hakansson@ericsson.com Thu Jun 6 05:34:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75F021F94DC for ; Thu, 6 Jun 2013 05:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geFSr2e2wvmP for ; Thu, 6 Jun 2013 05:34:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16DEC21F965B for ; Thu, 6 Jun 2013 05:34:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-94-51b081c28e0f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3D.86.15700.2C180B15; Thu, 6 Jun 2013 14:34:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 14:34:09 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] The role of signaling Thread-Index: Ac5isaGCGkXROJtETJa1hyIKXHiOHw== Date: Thu, 6 Jun 2013 12:34:08 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2E0DAC@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C2E0D3C@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.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvre6hxg2BBjtuC1lMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BlfFq9lKTjMUfHs813GBsaXbF2MnBwSAiYSGyZcY4awxSQu 3FsPFOfiEBI4zCixZM82RpCEkMBiRonf/XIgNptAoMTWfQvAmkUE1CW+7u0BaxYW0JZ4/vsX M0RcR6Jj9T4WCFtPYsHXjWBzWARUJGaeAZnJwcEr4Cvx9bcVxHhfiVtXr4ONZAS64fupNUwg NrOAuMStJ/OZIG4TADrnPNSdohIvH/9jhbCVJH5suMQCUa8ncWPqFDYIW1ti2cLXYPW8AoIS J2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkb23MTMnPRyw02MwPA+uOW37g7GU+dEDjFKc7Ao ifPq8S4OFBJITyxJzU5NLUgtii8qzUktPsTIxMEJIrikGhj7f0580M183EBi+sqiEGmFpbs3 V579ffbdZ0XBZUla6pLOnNd31yrcCeg9uObeyU9Tp1WYlvY0hLnXqa5IWx336vDHhm2PmivZ n+urF4l63f50af3PmVdsbu23WfxJyTuIrbBca+5Og9vzZqV5hN835ryz7eWCU/d3SM+6z6Wr uOXIzplL3/G7KbEUZyQaajEXFScCADPVz6dCAgAA Subject: Re: [MMUSIC] The role of signaling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 12:34:17 -0000 On 6/6/13 2:30 PM, Stefan H=E5kansson LK wrote:=0A= > I actually think that noplan bears serious consideration, but only=0A= > with respect to what it says about the role of signaling.=0A= >=0A= > Plan A/B assume some things about these questions that we clearly=0A= > haven't reached consensus on. The questions that I think we've been=0A= > working towards are:=0A= >=0A= > - What role does signaling play in session establishment?=0A= > - What information does signaling convey vs. what information is=0A= > conveyed in the signaled medium?=0A= > - Does SDP represent ALL signaling? (Clearly not.) What parts of=0A= > signaling is SDP responsible for?=0A= >=0A= > I don't think that we resolve anything on A/B until we agree on what=0A= > SDP is and does. Of course, once we agree on principles, we are=0A= > always free to choose expediency over those principles.=0A= =0A= I agree to the above, I think we should sort out those questions. And, =0A= as I have said before, I think we should avoid putting more than we have = =0A= to into SDP.=0A= =0A= From kevindempsey70@gmail.com Thu Jun 6 05:40:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F63721F994D for ; Thu, 6 Jun 2013 05:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwmODXShB9ZC for ; Thu, 6 Jun 2013 05:40:52 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 77BE821F96E8 for ; Thu, 6 Jun 2013 05:40:51 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w20so3026419lbh.10 for ; Thu, 06 Jun 2013 05:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oEdNIhLeXID2zLt+e6ZZh8V94U3xhajtpt+S/GUwVg0=; b=J5pEikWR3HcSa3IrKTpWM2qukIPwQikeHaHOSh7G3bUOBuDd/9qv52frBOljiphE9r q7uYdjRKxz6iOg9E0Fd9CqVhGLtLQHYzuWxDvGRnV8EscA0jagsqTmnZYefMhu83oLyK R7yMRDqMLU8XZzL50CS1mFkgrydDlg5V/q+rMFCgIpl/95nhycyqGUCzYps2gf7OTB7K O14n7bcVOxM92A7p60oYWerWeDhL3vwvLOiyaT6e5Ay/gPYR4nuwYXgscO1f9zPncN42 FUWu4WfCyCigYPV+363HxYn42/2VVFYjX9uAbVickmTl9d44exrDF7j9Pe1XwzuOSWB9 jt6g== MIME-Version: 1.0 X-Received: by 10.112.185.104 with SMTP id fb8mr9530861lbc.96.1370522450280; Thu, 06 Jun 2013 05:40:50 -0700 (PDT) Received: by 10.114.80.161 with HTTP; Thu, 6 Jun 2013 05:40:50 -0700 (PDT) In-Reply-To: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> <51AFDFDB.40500@cisco.com> Date: Thu, 6 Jun 2013 13:40:50 +0100 Message-ID: From: Kevin Dempsey To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c3c9a4ce490f04de7b9f6f Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:40:56 -0000 --001a11c3c9a4ce490f04de7b9f6f Content-Type: text/plain; charset=ISO-8859-1 Am i right in saying that what No Plan needs MMUSIC to say is that for BUNDLE to be usable the applications must use some method to determine which m- line a RTP stream is to be matched to? That method can be anything the applications at both ends can agree upon. That can include SSRC signalling within the SDP, unique PTs across m- lines, or even custom SIP headers etc. In the RTCWEB case, the signalling is already application specific. So that signalling path could be used by such application. On 6 June 2013 08:06, Emil Ivov wrote: > Hey Flemming, > > Just to be clear, are you saying all this because you believe No Plan > should NOT be on the agenda of the mmusic interim meeting? > > Emil > > On Thu, Jun 6, 2013 at 3:03 AM, Flemming Andreasen > wrote: > > > > On 6/5/13 6:37 AM, Emil Ivov wrote: > >> > >> Hey Flemming, > >> > >> You are right, there are no specific SDP updates that "No Plan" is > asking > >> from mmusic. > >> > >> That said however, the same is pretty much true about Plan A and Plan B. > >> They both discuss ways of using SDP and the extensions that might be > implied > >> to these ways are considered mostly collateral: > >> > >> Plan A: > >> > >> This document describes a *modest* > >> set of extensions to SDP which allow it to cleanly handle arbitrary > >> numbers of flows while still retaining a large degree of backward > >> compatibility with *existing* and non-RTCWEB endpoints. > >> > >> Plan B: > >> > >> Plan B mostly uses *existing* IETF standards, introducing a single new > >> draft [I-D.lennox-mmusic-sdp-source-selection] to specify how > >> individual media sources can be accepted/rejected at the SSRC level > >> via SDP. > >> > >> I might be off, but it was my understanding that the interim meeting was > >> not going to be about these specific extensions (which could possibly be > >> specified regardless of which Plan we go for) but mostly about the best > ways > >> to use SDP with multiple sources. The choices we make could have an > impact > >> on multiple working groups, which, I assumed, was the main reason for > having > >> the discussion mmmusic. > >> > > Agree with the latter part. In terms of approaches however, we previously > > had 2 (A and B), each of which seemed reasonably self-contained, and > while > > clearly driven by RTCWeb, have broader scope than RTCWeb. > > > > > >> In that sense I see "No Plan" as quite related to this discussion. > >> > > I agree it's related, but at the same time, the mechanism proposed seems > to > > be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot of > > the machinery unspecified. Examples from the document: > > > > The actual Offer/Answer semantics presented here do not differ > > fundamentally from those proposed by Plan A and Plan B. The main > > differentiation point of this approach is the fact that the exact > > protocol mechanism is left to WebRTC applications. Such applications > > or lightweight signalling gateways can then implement either Plan A, > > or Plan B, or an entirely different signalling protocol, depending on > > what best matches their use cases and topology. > > > > > > and > > > > > > All of the above semantics are best handled and hence should be left > > to applications. There are numerous existing or emerging solutions, > > some of them developed by the IETF, that already cover this. This > > includes CLUE channels [CLUE], the SIP Event Package For Conference > > State [RFC4575] and its XMPP variant [COIN]. Additional mechanisms, > > undoubtedly many based on JSON, are very likely to emerge in the > > future as WebRTC applications address varying use cases, scenarios > > and topologies. > > > > > > The above may be perfectly reasonable from an RTCWeb point of view, but I > > don't see MMUSIC as the place to make that decision. On the other hand, > if > > it's more a matter of coming up with a general framework for how to > > establish/signal sessions that support a multitude of multimedia > > participants in a session subject to certain requirements > (port-efficient, > > large number of participants can come and go dynamically, per source > control > > of media parameters, etc.) via SDP signaling, then MMUSIC probably is the > > right place. The document should probably change a bit in some places > then. > > > > > >> Am I right in assuming this and if so does the above answer your > question? > >> > > I think it's clearly related, however I want to make sure that the scope > is > > not limited to RTCWeb and hence does not assume anything RTCWeb specific > > (e.g. APIs, etc. which should not be the subject of MMUSIC > > discussions/documents). > > > > I'd like to hear what other people think about this though (incl. the > RTCWeb > > chairs). > > > > Thanks > > > > -- Flemming > > > > > >> Emil > >> > >> On 05.06.13, 06:44, Flemming Andreasen wrote: > >>> > >>> > >>> On 6/4/13 10:41 PM, Bernard Aboba wrote: > >>>> > >>>> Yes, you are missing something. No plan analyzes issues with both > Plan A > >>>> and Plan B and describes how to fix them. As they stand, both Plan A > nor > >>>> Plan B result in O/A exchanges that aren't needed and will break > congestion > >>>> control. Also, neither satisfies the requirements of the RTP usage > doc or is > >>>> compatible with a number of legacy implementations. No plan offers a > >>>> solution to these and other issues. > >>> > >>> I understand that "no plan" sees issues with Plan A and Plan B as > >>> currently defined. What I don't understand is what extensions or > updates > >>> to SDP signaling mechanism are being proposed here and hence which part > >>> of this discussion belongs in MMUSIC as opposed to RTCWeb simply > >>> specifying how it wants to use a set of current/developing mechanisms > >>> (or rely on app specific mechanisms, etc.) ? In other words, what does > >>> "no plan" seek from MMUSIC ? > >>> > >>> Thanks > >>> > >>> -- Flemming > >>> > >>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" > >>>> wrote: > >>>> > >>>>> On 5/31/13 6:46 AM, Emil Ivov wrote: > >>>>>> > >>>>>> Dear chairs, > >>>>>> > >>>>>> Could you please also consider the following draft for the interim > >>>>>> meeting agenda: > >>>>>> > >>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > >>>>> > >>>>> Sure, however I could use some clarification here. On one hand, the > >>>>> draft falls squarely in the middle of the overall "Plan" discussion > we have > >>>>> and hence is highly relevant, but at the same time, if I understand > >>>>> correctly, the draft is not asking MMUSIC to do anything in terms of > >>>>> protocol development. Rather, if this approach is adopted, it would > be more > >>>>> of an RTCWeb usage document specifying how one could use several > different > >>>>> mechanisms (and possibly WebRTC APIs) to implement signaling. There > doesn't > >>>>> seem to be a "mandatory to implement" mechanism for guaranteeing > >>>>> interoperability (in contrast to Plan A/B), but rather there are > references > >>>>> to "app specific signalling" mechanisms, etc. Am I missing something > here ? > >>>>> > >>>>> > >>>>>> I apologise if not stating this earlier has introduced any > confusion. > >>>>> > >>>>> No worries. > >>>>> > >>>>> Thanks > >>>>> > >>>>> -- Flemming > >>>>> > >>>>>> Regards, > >>>>>> Emil > >>>>>> > >>>>>> On 30.05.13, 21:56, IESG Secretary wrote: > >>>>>>> > >>>>>>> Greetings, > >>>>>>> > >>>>>>> This is to announce a(nother) virtual interim meeting for the > MMUSIC > >>>>>>> Working Group to take place on Monday, June 17, from 7:00 am - > 10:00 > >>>>>>> am > >>>>>>> Pacific Time. The goal of this meeting is to come to a resolution > on > >>>>>>> the > >>>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling > >>>>>>> needed > >>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" > lines > >>>>>>> or > >>>>>>> very few "m=" lines and to what extent is there sub-negotation and > >>>>>>> signaling at the SSRC level). > >>>>>>> > >>>>>>> A more detailed agenda and logistics will be sent out separately on > >>>>>>> the > >>>>>>> MMUSIC mailing list. For now, people should take a close look at > the > >>>>>>> following two drafts: > >>>>>>> > >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > >>>>>>> > >>>>>>> > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > >>>>>>> > >>>>>>> You may also want to look at > >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > >>>>>>> > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> -- Ari & Flemming (MMUSIC co-chairs) > >>>>>>> > >>>>>>> > >>>>>>> PS: Per our previous interim meeting announcement, we tried to > >>>>>>> schedule > >>>>>>> a longer and in-person physical interim meeting, however it has > >>>>>>> proven > >>>>>>> impossible to find a set of dates where we could get critical mass > >>>>>>> for > >>>>>>> such a meeting. Scheduling even a virtual interim before the Berlin > >>>>>>> IETF > >>>>>>> has been surprisingly difficult with the above date being the only > >>>>>>> viable option at this point. > >>>>>>> _______________________________________________ > >>>>>>> mmusic mailing list > >>>>>>> mmusic@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic > >>>>> > >>>>> _______________________________________________ > >>>>> mmusic mailing list > >>>>> mmusic@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mmusic > >>>> > >>>> . > >>>> > >>> > >>> > >> > > > > > > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > http://jitsi.org FAX: +33.1.77.62.47.31 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c3c9a4ce490f04de7b9f6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Am i right in saying that what No Plan needs MMUSIC to say= is that for BUNDLE to be usable the applications must use some method to d= etermine which m- line a RTP stream is to be matched to? That method can be= anything the applications at both ends can agree upon. That can include SS= RC signalling within the SDP, unique PTs across m- lines, or even custom SI= P headers etc.=A0

In the RTCWEB case, the signalling is already application sp= ecific. So that signalling path could be used by such application.


On 6 June = 2013 08:06, Emil Ivov <emcho@jitsi.org> wrote:
Hey Flemming,

Just to be clear, are you saying all this because you believe No Plan
should NOT be on the agenda of the mmusic interim meeting?

Emil

On Thu, Jun 6, 2013 at 3:03 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
>
> On 6/5/13 6:37 AM, Emil Ivov wrote:
>>
>> Hey Flemming,
>>
>> You are right, there are no specific SDP updates that "No Pla= n" is asking
>> from mmusic.
>>
>> That said however, the same is pretty much true about Plan A and P= lan B.
>> They both discuss ways of using SDP and the extensions that might = be implied
>> to these ways are considered mostly collateral:
>>
>> Plan A:
>>
>> =A0 This document describes a *modest*
>> =A0 set of extensions to SDP which allow it to cleanly handle arbi= trary
>> =A0 numbers of flows while still retaining a large degree of backw= ard
>> =A0 compatibility with *existing* and non-RTCWEB endpoints.
>>
>> Plan B:
>>
>> =A0 Plan B mostly uses *existing* IETF standards, introducing a si= ngle new
>> =A0 draft [I-D.lennox-mmusic-sdp-source-selection] to specify how<= br> >> =A0 individual media sources can be accepted/rejected at the SSRC = level
>> =A0 via SDP.
>>
>> I might be off, but it was my understanding that the interim meeti= ng was
>> not going to be about these specific extensions (which could possi= bly be
>> specified regardless of which Plan we go for) but mostly about the= best ways
>> to use SDP with multiple sources. The choices we make could have a= n impact
>> on multiple working groups, which, I assumed, was the main reason = for having
>> the discussion mmmusic.
>>
> Agree with the latter part. In terms of approaches however, we previou= sly
> had 2 (A and B), each of which seemed reasonably self-contained, and w= hile
> clearly driven by RTCWeb, have broader scope than RTCWeb.
>
>
>> In that sense I see "No Plan" as quite related to this d= iscussion.
>>
> I agree it's related, but at the same time, the mechanism proposed= seems to
> be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot= of
> the machinery unspecified. Examples from the document:
> <quote>
> =A0 =A0The actual Offer/Answer semantics presented here do not differ<= br> > =A0 =A0fundamentally from those proposed by Plan A and Plan B. =A0The = main
> =A0 =A0differentiation point of this approach is the fact that the exa= ct
> =A0 =A0protocol mechanism is left to WebRTC applications. =A0Such appl= ications
> =A0 =A0or lightweight signalling gateways can then implement either Pl= an A,
> =A0 =A0or Plan B, or an entirely different signalling protocol, depend= ing on
> =A0 =A0what best matches their use cases and topology.
> </quote>
>
> and
>
> <quote>
> =A0 =A0All of the above semantics are best handled and hence should be= left
> =A0 =A0to applications. =A0There are numerous existing or emerging sol= utions,
> =A0 =A0some of them developed by the IETF, that already cover this. Th= is
> =A0 =A0includes CLUE channels [CLUE], the SIP Event Package For Confer= ence
> =A0 =A0State [RFC4575] and its XMPP variant [COIN]. =A0Additional mech= anisms,
> =A0 =A0undoubtedly many based on JSON, are very likely to emerge in th= e
> =A0 =A0future as WebRTC applications address varying use cases, scenar= ios
> =A0 =A0and topologies.
> </quote>
>
> The above may be perfectly reasonable from an RTCWeb point of view, bu= t I
> don't see MMUSIC as the place to make that decision. On the other = hand, if
> it's more a matter of coming up with a general framework for how t= o
> establish/signal sessions that support a multitude of multimedia
> participants in a session subject to certain requirements (port-effici= ent,
> large number of participants can come and go dynamically, per source c= ontrol
> of media parameters, etc.) via SDP signaling, then MMUSIC probably is = the
> right place. The document should probably change a bit in some places = then.
>
>
>> Am I right in assuming this and if so does the above answer your q= uestion?
>>
> I think it's clearly related, however I want to make sure that the= scope is
> not limited to RTCWeb and hence does not assume anything RTCWeb specif= ic
> (e.g. APIs, etc. which should not be the subject of MMUSIC
> discussions/documents).
>
> I'd like to hear what other people think about this though (incl. = the RTCWeb
> chairs).
>
> Thanks
>
> -- Flemming
>
>
>> Emil
>>
>> On 05.06.13, 06:44, Flemming Andreasen wrote:
>>>
>>>
>>> On 6/4/13 10:41 PM, Bernard Aboba wrote:
>>>>
>>>> Yes, you are missing something. No plan analyzes issues wi= th both Plan A
>>>> and Plan B and describes how to fix them. As they stand, b= oth Plan A nor
>>>> Plan B result in O/A exchanges that aren't needed and = will break congestion
>>>> control. Also, neither satisfies the requirements of the R= TP usage doc or is
>>>> compatible with a number of legacy implementations. No =A0= plan offers a
>>>> solution to these and other issues.
>>>
>>> I understand that "no plan" sees issues with Plan A = and Plan B as
>>> currently defined. What I don't understand is what extensi= ons or updates
>>> to SDP signaling mechanism are being proposed here and hence w= hich part
>>> of this discussion belongs in MMUSIC as opposed to RTCWeb simp= ly
>>> specifying how it wants to use a set of current/developing mec= hanisms
>>> (or rely on app specific mechanisms, etc.) ? In other words, w= hat does
>>> "no plan" seek from MMUSIC ?
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen"= <fandreas@cisco.com>
>>>> wrote:
>>>>
>>>>> On 5/31/13 6:46 AM, Emil Ivov wrote:
>>>>>>
>>>>>> Dear chairs,
>>>>>>
>>>>>> Could you please also consider the following draft= for the interim
>>>>>> meeting agenda:
>>>>>>
>>>>>> http://tools.ietf.org/html/draft-ivov-rtcwe= b-noplan
>>>>>
>>>>> Sure, however I could use some clarification here. On = one hand, the
>>>>> draft falls squarely in the middle of the overall &quo= t;Plan" discussion we have
>>>>> and hence is highly relevant, but at the same time, if= I understand
>>>>> correctly, the draft is not asking MMUSIC to do anythi= ng in terms of
>>>>> protocol development. Rather, if this approach is adop= ted, it would be more
>>>>> of an RTCWeb usage document specifying how one could u= se several different
>>>>> mechanisms (and possibly WebRTC APIs) to implement sig= naling. There doesn't
>>>>> seem to be a "mandatory to implement" mechan= ism for guaranteeing
>>>>> interoperability (in contrast to Plan A/B), but rather= there are references
>>>>> to "app specific signalling" mechanisms, etc= . Am I missing something here ?
>>>>>
>>>>>
>>>>>> I apologise if not stating this earlier has introd= uced any confusion.
>>>>>
>>>>> No worries.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Flemming
>>>>>
>>>>>> Regards,
>>>>>> Emil
>>>>>>
>>>>>> On 30.05.13, 21:56, IESG Secretary wrote:
>>>>>>>
>>>>>>> Greetings,
>>>>>>>
>>>>>>> This is to announce a(nother) virtual interim = meeting for the MMUSIC
>>>>>>> Working Group to take place on Monday, June 17= , from 7:00 am - 10:00
>>>>>>> am
>>>>>>> Pacific Time. The goal of this meeting is to c= ome to a resolution on
>>>>>>> the
>>>>>>> so-called "Plan A" or "Plan B&q= uot; approach related to SDP signaling
>>>>>>> needed
>>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potenti= ally lots of "m=3D" lines
>>>>>>> or
>>>>>>> very few "m=3D" lines and to what ex= tent is there sub-negotation and
>>>>>>> signaling at the SSRC level).
>>>>>>>
>>>>>>> A more detailed agenda and logistics will be s= ent out separately on
>>>>>>> the
>>>>>>> MMUSIC mailing list. For now, people should ta= ke a close look at the
>>>>>>> following two drafts:
>>>>>>>
>>>>>>> http://www.ietf.org/id/draft-roach-= rtcweb-plan-a-00.txt
>>>>>>>
>>>>>>> http://www.ietf.org/int= ernet-drafts/draft-uberti-rtcweb-plan-00.txt
>>>>>>>
>>>>>>> You may also want to look at
>>>>>>> http://www.ietf.org/id/draft= -roach-rtcweb-glareless-add-00.txt
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- Ari & Flemming (MMUSIC co-chairs)
>>>>>>>
>>>>>>>
>>>>>>> PS: Per our previous interim meeting announcem= ent, we tried to
>>>>>>> schedule
>>>>>>> a longer and in-person physical interim meetin= g, however it has
>>>>>>> proven
>>>>>>> impossible to find a set of dates where we cou= ld get critical mass
>>>>>>> for
>>>>>>> such a meeting. Scheduling even a virtual inte= rim before the Berlin
>>>>>>> IETF
>>>>>>> has been surprisingly difficult with the above= date being the only
>>>>>>> viable option at this point.
>>>>>>> ______________________________________________= _
>>>>>>> mmusic mailing list
>>>>>>> mmusic@ietf= .org
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> mmusic@ietf.org=
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>> .
>>>>
>>>
>>>
>>
>



--
Emil Ivov, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 67000 Strasbou= rg,
Project Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 France
Jitsi
emcho@jitsi.org =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0PHONE: +33.1.77.62.43.30
http://jitsi.org =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FAX: =A0 +33.1.77.62.47.31
_____________________= __________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--001a11c3c9a4ce490f04de7b9f6f-- From fandreas@cisco.com Thu Jun 6 05:58:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7764A21F93E0 for ; Thu, 6 Jun 2013 05:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAMrnphjTwA9 for ; Thu, 6 Jun 2013 05:58:11 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D11EC21F89A6 for ; Thu, 6 Jun 2013 05:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9181; q=dns/txt; s=iport; t=1370523491; x=1371733091; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s2IuzyF0PWj5C8P5kpYal730IDZ0k+1mbSyXyfKB6qo=; b=MUkooPkLMcatF/QTHT/pZBnC7lJwtGe1Ztkpe+XnILSoCAOTuH34kEV/ 2GIYZ4Rz53CvsmP9p8TQtIZhaJIlRWdJCGseR6S2G0JuuV9R6KNAZTSUU jbJhHsxrk8bBTb8FONIsnDxpSuiXJkzjbuzIYuJsVGkdw8QgFVScupdet I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABuGsFGtJXG//2dsb2JhbABZgwkwv0Z4FnSCIwEBAQMBAQEBNTAGCgEFCwsOCgkWDwkDAgECARUwBg0BBQIBAQUSh2wGDLsjjXqBOAeDWwOXP4EpkBeDKyCBLA X-IronPort-AV: E=Sophos;i="4.87,814,1363132800"; d="scan'208";a="219542250" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2013 12:58:10 +0000 Received: from Flemmings-MacBook-Pro.local (che-vpn-cluster-1-463.cisco.com [10.86.241.208]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56Cw7K9008144; Thu, 6 Jun 2013 12:58:08 GMT Message-ID: <51B0875F.9010909@cisco.com> Date: Thu, 06 Jun 2013 08:58:07 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> <51AFDFDB.40500@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "mmusic@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:58:15 -0000 On 6/6/13 3:06 AM, Emil Ivov wrote: > Hey Flemming, > > Just to be clear, are you saying all this because you believe No Plan > should NOT be on the agenda of the mmusic interim meeting? No. I think it should, but I'm trying to get some clarity around what decisions and discussions belong to and should be handled by the RTCWeb group versus what belongs in the MMUSIC group. -- Flemming > Emil > > On Thu, Jun 6, 2013 at 3:03 AM, Flemming Andreasen wrote: >> On 6/5/13 6:37 AM, Emil Ivov wrote: >>> Hey Flemming, >>> >>> You are right, there are no specific SDP updates that "No Plan" is asking >>> from mmusic. >>> >>> That said however, the same is pretty much true about Plan A and Plan B. >>> They both discuss ways of using SDP and the extensions that might be implied >>> to these ways are considered mostly collateral: >>> >>> Plan A: >>> >>> This document describes a *modest* >>> set of extensions to SDP which allow it to cleanly handle arbitrary >>> numbers of flows while still retaining a large degree of backward >>> compatibility with *existing* and non-RTCWEB endpoints. >>> >>> Plan B: >>> >>> Plan B mostly uses *existing* IETF standards, introducing a single new >>> draft [I-D.lennox-mmusic-sdp-source-selection] to specify how >>> individual media sources can be accepted/rejected at the SSRC level >>> via SDP. >>> >>> I might be off, but it was my understanding that the interim meeting was >>> not going to be about these specific extensions (which could possibly be >>> specified regardless of which Plan we go for) but mostly about the best ways >>> to use SDP with multiple sources. The choices we make could have an impact >>> on multiple working groups, which, I assumed, was the main reason for having >>> the discussion mmmusic. >>> >> Agree with the latter part. In terms of approaches however, we previously >> had 2 (A and B), each of which seemed reasonably self-contained, and while >> clearly driven by RTCWeb, have broader scope than RTCWeb. >> >> >>> In that sense I see "No Plan" as quite related to this discussion. >>> >> I agree it's related, but at the same time, the mechanism proposed seems to >> be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot of >> the machinery unspecified. Examples from the document: >> >> The actual Offer/Answer semantics presented here do not differ >> fundamentally from those proposed by Plan A and Plan B. The main >> differentiation point of this approach is the fact that the exact >> protocol mechanism is left to WebRTC applications. Such applications >> or lightweight signalling gateways can then implement either Plan A, >> or Plan B, or an entirely different signalling protocol, depending on >> what best matches their use cases and topology. >> >> >> and >> >> >> All of the above semantics are best handled and hence should be left >> to applications. There are numerous existing or emerging solutions, >> some of them developed by the IETF, that already cover this. This >> includes CLUE channels [CLUE], the SIP Event Package For Conference >> State [RFC4575] and its XMPP variant [COIN]. Additional mechanisms, >> undoubtedly many based on JSON, are very likely to emerge in the >> future as WebRTC applications address varying use cases, scenarios >> and topologies. >> >> >> The above may be perfectly reasonable from an RTCWeb point of view, but I >> don't see MMUSIC as the place to make that decision. On the other hand, if >> it's more a matter of coming up with a general framework for how to >> establish/signal sessions that support a multitude of multimedia >> participants in a session subject to certain requirements (port-efficient, >> large number of participants can come and go dynamically, per source control >> of media parameters, etc.) via SDP signaling, then MMUSIC probably is the >> right place. The document should probably change a bit in some places then. >> >> >>> Am I right in assuming this and if so does the above answer your question? >>> >> I think it's clearly related, however I want to make sure that the scope is >> not limited to RTCWeb and hence does not assume anything RTCWeb specific >> (e.g. APIs, etc. which should not be the subject of MMUSIC >> discussions/documents). >> >> I'd like to hear what other people think about this though (incl. the RTCWeb >> chairs). >> >> Thanks >> >> -- Flemming >> >> >>> Emil >>> >>> On 05.06.13, 06:44, Flemming Andreasen wrote: >>>> >>>> On 6/4/13 10:41 PM, Bernard Aboba wrote: >>>>> Yes, you are missing something. No plan analyzes issues with both Plan A >>>>> and Plan B and describes how to fix them. As they stand, both Plan A nor >>>>> Plan B result in O/A exchanges that aren't needed and will break congestion >>>>> control. Also, neither satisfies the requirements of the RTP usage doc or is >>>>> compatible with a number of legacy implementations. No plan offers a >>>>> solution to these and other issues. >>>> I understand that "no plan" sees issues with Plan A and Plan B as >>>> currently defined. What I don't understand is what extensions or updates >>>> to SDP signaling mechanism are being proposed here and hence which part >>>> of this discussion belongs in MMUSIC as opposed to RTCWeb simply >>>> specifying how it wants to use a set of current/developing mechanisms >>>> (or rely on app specific mechanisms, etc.) ? In other words, what does >>>> "no plan" seek from MMUSIC ? >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" >>>>> wrote: >>>>> >>>>>> On 5/31/13 6:46 AM, Emil Ivov wrote: >>>>>>> Dear chairs, >>>>>>> >>>>>>> Could you please also consider the following draft for the interim >>>>>>> meeting agenda: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>> Sure, however I could use some clarification here. On one hand, the >>>>>> draft falls squarely in the middle of the overall "Plan" discussion we have >>>>>> and hence is highly relevant, but at the same time, if I understand >>>>>> correctly, the draft is not asking MMUSIC to do anything in terms of >>>>>> protocol development. Rather, if this approach is adopted, it would be more >>>>>> of an RTCWeb usage document specifying how one could use several different >>>>>> mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't >>>>>> seem to be a "mandatory to implement" mechanism for guaranteeing >>>>>> interoperability (in contrast to Plan A/B), but rather there are references >>>>>> to "app specific signalling" mechanisms, etc. Am I missing something here ? >>>>>> >>>>>> >>>>>>> I apologise if not stating this earlier has introduced any confusion. >>>>>> No worries. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>>> Regards, >>>>>>> Emil >>>>>>> >>>>>>> On 30.05.13, 21:56, IESG Secretary wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> This is to announce a(nother) virtual interim meeting for the MMUSIC >>>>>>>> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 >>>>>>>> am >>>>>>>> Pacific Time. The goal of this meeting is to come to a resolution on >>>>>>>> the >>>>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling >>>>>>>> needed >>>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines >>>>>>>> or >>>>>>>> very few "m=" lines and to what extent is there sub-negotation and >>>>>>>> signaling at the SSRC level). >>>>>>>> >>>>>>>> A more detailed agenda and logistics will be sent out separately on >>>>>>>> the >>>>>>>> MMUSIC mailing list. For now, people should take a close look at the >>>>>>>> following two drafts: >>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >>>>>>>> >>>>>>>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >>>>>>>> >>>>>>>> You may also want to look at >>>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Ari & Flemming (MMUSIC co-chairs) >>>>>>>> >>>>>>>> >>>>>>>> PS: Per our previous interim meeting announcement, we tried to >>>>>>>> schedule >>>>>>>> a longer and in-person physical interim meeting, however it has >>>>>>>> proven >>>>>>>> impossible to find a set of dates where we could get critical mass >>>>>>>> for >>>>>>>> such a meeting. Scheduling even a virtual interim before the Berlin >>>>>>>> IETF >>>>>>>> has been surprisingly difficult with the above date being the only >>>>>>>> viable option at this point. >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> . >>>>> >>>> > > From pkyzivat@alum.mit.edu Thu Jun 6 07:41:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0521F99CA for ; Thu, 6 Jun 2013 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMqdLckTfe-U for ; Thu, 6 Jun 2013 07:41:06 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE5721F93E0 for ; Thu, 6 Jun 2013 07:41:04 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id kziq1l0051uE5Es582h47l; Thu, 06 Jun 2013 14:41:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id l2h31l01K3ZTu2S3c2h47c; Thu, 06 Jun 2013 14:41:04 +0000 Message-ID: <51B09F7E.7040709@alum.mit.edu> Date: Thu, 06 Jun 2013 10:41:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> <51AD0C53.7030406@alum.mit.edu> <51AD1617.9020501@jitsi.org> <51AE10C2.5010807@alum.mit.edu> <51AF6789.40500@jitsi.org> In-Reply-To: <51AF6789.40500@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370529664; bh=s1511xQwRAhBOjOlmFeGgkronDls+1dJxJnV6b39ENk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qvQK8mkjoLl369x/ypKFsfhhc+/zMcAefGOLQN2hh1S+r7jMBmdUzKEJPDzrz9vO3 oMsTMD12SFK0cdvExj+/3rc3ZX7BJg3rzPmnnphPKHLJdIkuxcxvuqhdd/wZXNvrZ3 g6WohKHDbcx4K0fZKHoQF4IrcgJsjwLd30LsJMogmG7qZUCOCsrUkSTAKygzHb4v0c 8Q5zZaqUilEBSdTWUjrnlqppwbcSCyrMP54gNM/fNsEyw/voPpqGHN6pcZqARtW1p4 IdC9f+454bKIC05pnYuSnw1X8LcYu2Lz2Ml8MvS3gbrxDVDUiG/aUkQd3uUlQDKAwB 60sqOJ/8sW6sg== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] No Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 14:41:11 -0000 Hi Emil - more inline. On 6/5/13 12:30 PM, Emil Ivov wrote: > Hey Paul, > > On 04.06.13, 18:07, Paul Kyzivat wrote: >> On 6/3/13 6:17 PM, Emil Ivov wrote: >> >> [snip] >>>>>> I'm just pointing out that for decomposed endpoints one 5-tuple >>>>>> may not >>>>>> be enough. And the need for this might not be known a priori. One >>>>>> side >>>>>> may be ready to add another stream for some purpose, and be >>>>>> willing/able >>>>>> to use private signaling to negotiate that. But the other side may >>>>>> not >>>>>> be able to handle that stream on the same 5-tuple. That in turn may >>>>>> result in a need to negotiate SDP changes to establish an additional >>>>>> 5-tuple that can then be used for that new stream. >>>>> >>>>> I think I see ... but not completely. Could you please post an SDP >>>>> offer >>>>> with BUNDLE and the corresponding answer? >>>> >>>> The issue can be discussed without bundle, and without detailing the >>>> O/A. >>> >>> We can certainly try. I am not sure if I am following though. Let's see: >>> >>>> Assume we have had an O/A already between X and Y, with a single >>>> (video) >>>> m-line, resulting in a single 5-tuple. Over this we have a single audio >>>> RTP stream and mediaStreamtrack. >>>> >>>> The user of X interacts with the app, indicating a desire to receive >>>> another video stream from Y. This causes the app to trigger the JS in Y >>>> to set up another mediaStreamTrack. But the camera on Y has a separate >>>> IP address. So it is necessary to first set up another video m-line >>>> with >>>> the new address on Y's end. (X's end can use its single IP address.) >>> >>> This is the part that I can't quite picture. How can Y's camera be on a >>> separate IP, but still appear as a regular device to Y's javascript and >>> still generate a regular stream track? All this with a generic browser? >> >> I'm not a browser guy, so maybe I am imagining things that are out of >> scope for webrtc, but maybe not. > > Well I suppose a browser could always support a decoupled device if it > were made available as local through some driver. Something like a > virtual local device. In that case however, this driver would still have > to bring the media to the local host so that it can be placed within a > track, a stream and a peer connection. At this point it wouldn't matter > to WebRTC that the device is actually decoupled, would it? > > There is still the other option where this device is controlled by > proprietary JS and for this you'd need to have your own signalling and > your own control interfaces. > >> At the very least you can have an app that gateways between a browser >> and some non-browser device. > > Let me make sure I understand this. This gateway app, is it running on > X, is it on a box between X and Y, or is it a controlling entity of the > decoupled Y? Consider it to be a web server coupled to a sip GW. So in the webrtc "triangle" view, X is a browser, Y is a SIP device, and the GW is the web server driving the broswer. For the moment lets assume that Y supports ICE, and bundle, and DTLS/SRTP, so that the GW need only be a signaling gw, not a media gw. >> So assume that X is a browser and Y is not. >> What does the app tell the browser to do so that the new stream is on a >> different 5-tuple? > > Without knowing the specifics of your scenario I'd say that you have the > following options: > > 1) Y relays RTP from its decoupled camera toward X. In this case X is > getting everything on the same 5-tuple, so no extra m= lines are > necessary. (You'd have a similar situation in the case above where the > camera is somehow presented as a virtual local device on Y) (1) doesn't fit what I'm concerned with. > 2) Y just wants to handle signalling and it would like that video from > the decoupled camera reaches X directly from there. Y also wants to have > everything handled within the same Offer/Answer dialog. In this case: > 2.1) When Y calls X, it would add a second video m= line in a second > bundle (or with no bundle at all) when sending its offer to X This is more what I had in mind. So at least you are ok with two separate video m-lines on different 5-tuples in this case, where it is initiated from the sip device. It wasn't evident to me if this fit into your model. > 2.2) When X calls Y with a single lined offer, Y would also answer with > a single m= line and would then re-Offer with two lines. Lets consider a more complex variant of this scenario: - the initial o/a is just for audio. That gets set up in obvious way. There is only an audio m-line. (Maybe in a degenerate bundle, maybe not.) I guess there is no data channel, because the gw doesn't expect sip devices to support one. - then X (or the app in the gw driving X) decides to add video. So it creates second offer, including a video m-line bundled with the audio m-line. - that offer goes to Y. But Y can't handle the audio and video as a bundle. In this case it can simply refuse the bundle while accepting the video unbundled. If that is ok with No Plan then I think I am ok with it. Thanks, Paul > In both 2.1 and 2.2 the browser on X would see two independent, > unbundled streams and handle them appropriately. > > Is any of the above close to what you have in mind? Or is it completely > off? > > Emil >> >>> Wouldn't it be much more likely that such a separate camera will be >>> controlled by a proprietary interface that is not directly related to >>> WebRTC? >> >> Can somebody who knows more about these things comment if this is >> entirely impossible for two devices accessible to the browser to be >> accessible only via distinct IP address/port, or if it might occur for a >> sufficiently sophisticated device? >> >> Thanks, >> Paul >> >>> If so, then the additional signalling for this camera would obviously >>> need to be generated by Y's javascript (i.e. not the browser). That >>> additional signalling can then be merged into the one from Y's browser >>> by Y's JS or a gateway. >>> >>> X would indeed need to handle an offer with two video m= lines at that >>> point, but that's because they would negotiate different 5-tuples. So >>> this is fine. >>> >>> Another option would be to handle the new camera with an independent >>> Offer/Answer that would yield a new PeerConnection. I don't know if that >>> works for your case but I thought I'd mention it. In this case any >>> additional information required for the synchronization of the two peer >>> connections would be exchanged in an app-specific way. >>> >>> Cheers, >>> Emil >>> >>> >>>> Once that is done the new mediaStreamTrack can be established on the >>>> new >>>> m-line. >>>> >>>> How does this fit into No Plan? >>>> >>>>> (This might be a good point to move this to mmusic) >>>> >>>> Done. >>> >>> Thanks, >>> Emil >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Thanks, >>>>> Emil >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> If you'd like for that signalling to be in SDP, I >>>>>>>>> don't see any problem with it. However it would be best for this >>>>>>>>> extra >>>>>>>>> layer of SDP signalling to appear at either the application layer >>>>>>>>> or in >>>>>>>>> a signalling gateway (that is going to be there anyway). >>>>>>>>> >>>>>>>>> Does this make sense? >>>>>>>>> >>>>>>>>> Emil >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Further questions: >>>>>>>>>> >>>>>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>>>>>>> per-m-line, with application specific signaling for bandwidth at >>>>>>>>>> the >>>>>>>>>> per-RTP-stream level? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>>>>>>> Hey all, >>>>>>>>>>> >>>>>>>>>>> Based on many of the discussions that we've had here, as well as >>>>>>>>>>> many >>>>>>>>>>> others that we've had offlist, it seemed like a good idea to >>>>>>>>>>> investigate >>>>>>>>>>> a negotiation alternative that relies on SDP and Offer/Answer >>>>>>>>>>> just a >>>>>>>>>>> little bit less. >>>>>>>>>>> >>>>>>>>>>> The following "no plan" draft attempts to present one such >>>>>>>>>>> approach: >>>>>>>>>>> >>>>>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>>>>>>> >>>>>>>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>>>>>>> intricacies of multi-source scenarios to application-specific >>>>>>>>>>> signalling, with potentially a little help from RTP. >>>>>>>>>>> >>>>>>>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>>>>>>> interoperability requirements that concerned them can still >>>>>>>>>>> be met >>>>>>>>>>> with >>>>>>>>>>> "no plan". Of course they would have to be addressed by >>>>>>>>>>> application-specific signalling and/or signalling gateways. >>>>>>>>>>> >>>>>>>>>>> Comments are welcome! >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Emil >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> rtcweb mailing list >>>>>>>>>> rtcweb@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> . >> > From emil@sip-communicator.org Thu Jun 6 08:30:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0621F999E for ; Thu, 6 Jun 2013 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DOm9DKrDsFT for ; Thu, 6 Jun 2013 08:30:40 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6721F997A for ; Thu, 6 Jun 2013 08:30:39 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so2111812wes.26 for ; Thu, 06 Jun 2013 08:30:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=YeGAD1cKzM6ustrZmD70mJpm2bzV2kRiZwc1c2LGg+w=; b=S93tR7qu9ESoqsWsPK4goWZWOmmmPy1+7EYlQTDr7xvKfVh5RyS96DldiCL2ymnQyS RNPo4XRquGM+zABIdQuuz7hSUCEnitG94Ku/Gm3dn52CfhbYvr3tmy/nAPJETx7YvKtS 1xtj7lwfY4wfCSsUUhbYcs7bbNIa9XsGwg8biSqVgGq0DzKR4ixP39qbM0DhLcKbYza1 C5MNHWEXPpuqoiRV0NENpAUHwpFmKD2G17AjjyaBN05zguCU9cFP0C5vQHJ6rnya92Hn Xnk+60BQB7HUQGYpsZ+B+DUEcmIcblhODelyvuSVERJsYz3BXZSxtZJglIa7amLB9+oq I29g== X-Received: by 10.180.88.231 with SMTP id bj7mr10516684wib.5.1370532638592; Thu, 06 Jun 2013 08:30:38 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:e0d6:b52f:9f43:4c3f]) by mx.google.com with ESMTPSA id m3sm16525700wij.5.2013.06.06.08.30.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 08:30:37 -0700 (PDT) Message-ID: <51B0AB1C.9050606@jitsi.org> Date: Thu, 06 Jun 2013 17:30:36 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> <51AD0C53.7030406@alum.mit.edu> <51AD1617.9020501@jitsi.org> <51AE10C2.5010807@alum.mit.edu> <51AF6789.40500@jitsi.org> <51B09F7E.7040709@alum.mit.edu> In-Reply-To: <51B09F7E.7040709@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn4aYIQ6peUNWG3L8m3aPdMu8XD1K1aJDx77kKPB2edlZAnOV88KT6iGWT9Ylrbhvexq3T6 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] [rtcweb] No Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 15:30:44 -0000 Hey Paul, On 06.06.13, 16:41, Paul Kyzivat wrote: > Hi Emil - more inline. > > On 6/5/13 12:30 PM, Emil Ivov wrote: >> Hey Paul, >> >> On 04.06.13, 18:07, Paul Kyzivat wrote: >>> On 6/3/13 6:17 PM, Emil Ivov wrote: >>> >>> [snip] >>>>>>> I'm just pointing out that for decomposed endpoints one 5-tuple >>>>>>> may not >>>>>>> be enough. And the need for this might not be known a priori. One >>>>>>> side >>>>>>> may be ready to add another stream for some purpose, and be >>>>>>> willing/able >>>>>>> to use private signaling to negotiate that. But the other side may >>>>>>> not >>>>>>> be able to handle that stream on the same 5-tuple. That in turn may >>>>>>> result in a need to negotiate SDP changes to establish an additional >>>>>>> 5-tuple that can then be used for that new stream. >>>>>> >>>>>> I think I see ... but not completely. Could you please post an SDP >>>>>> offer >>>>>> with BUNDLE and the corresponding answer? >>>>> >>>>> The issue can be discussed without bundle, and without detailing the >>>>> O/A. >>>> >>>> We can certainly try. I am not sure if I am following though. Let's see: >>>> >>>>> Assume we have had an O/A already between X and Y, with a single >>>>> (video) >>>>> m-line, resulting in a single 5-tuple. Over this we have a single audio >>>>> RTP stream and mediaStreamtrack. >>>>> >>>>> The user of X interacts with the app, indicating a desire to receive >>>>> another video stream from Y. This causes the app to trigger the JS in Y >>>>> to set up another mediaStreamTrack. But the camera on Y has a separate >>>>> IP address. So it is necessary to first set up another video m-line >>>>> with >>>>> the new address on Y's end. (X's end can use its single IP address.) >>>> >>>> This is the part that I can't quite picture. How can Y's camera be on a >>>> separate IP, but still appear as a regular device to Y's javascript and >>>> still generate a regular stream track? All this with a generic browser? >>> >>> I'm not a browser guy, so maybe I am imagining things that are out of >>> scope for webrtc, but maybe not. >> >> Well I suppose a browser could always support a decoupled device if it >> were made available as local through some driver. Something like a >> virtual local device. In that case however, this driver would still have >> to bring the media to the local host so that it can be placed within a >> track, a stream and a peer connection. At this point it wouldn't matter >> to WebRTC that the device is actually decoupled, would it? >> >> There is still the other option where this device is controlled by >> proprietary JS and for this you'd need to have your own signalling and >> your own control interfaces. >> >>> At the very least you can have an app that gateways between a browser >>> and some non-browser device. >> >> Let me make sure I understand this. This gateway app, is it running on >> X, is it on a box between X and Y, or is it a controlling entity of the >> decoupled Y? > > Consider it to be a web server coupled to a sip GW. So in the webrtc > "triangle" view, X is a browser, Y is a SIP device, and the GW is the > web server driving the broswer. For the moment lets assume that Y > supports ICE, and bundle, and DTLS/SRTP, so that the GW need only be a > signaling gw, not a media gw. OK. >>> So assume that X is a browser and Y is not. >>> What does the app tell the browser to do so that the new stream is on a >>> different 5-tuple? >> >> Without knowing the specifics of your scenario I'd say that you have the >> following options: >> >> 1) Y relays RTP from its decoupled camera toward X. In this case X is >> getting everything on the same 5-tuple, so no extra m= lines are >> necessary. (You'd have a similar situation in the case above where the >> camera is somehow presented as a virtual local device on Y) > > (1) doesn't fit what I'm concerned with. > >> 2) Y just wants to handle signalling and it would like that video from >> the decoupled camera reaches X directly from there. Y also wants to have >> everything handled within the same Offer/Answer dialog. In this case: >> 2.1) When Y calls X, it would add a second video m= line in a second >> bundle (or with no bundle at all) when sending its offer to X > > This is more what I had in mind. > So at least you are ok with two separate video m-lines on different > 5-tuples in this case, where it is initiated from the sip device. > It wasn't evident to me if this fit into your model. OK, I'll make sure it's clarified. The basic idea of No Plan is to use SDP for setting up transport channels and codec chains. The SDP way of setting up two transport channels is by having 2 m= lines so this has to be and *is* OK with No Plan. >> 2.2) When X calls Y with a single lined offer, Y would also answer with >> a single m= line and would then re-Offer with two lines. > > Lets consider a more complex variant of this scenario: > > - the initial o/a is just for audio. That gets set up in obvious way. > There is only an audio m-line. (Maybe in a degenerate bundle, > maybe not.) I guess there is no data channel, because the gw doesn't > expect sip devices to support one. OK > - then X (or the app in the gw driving X) decides to add video. > So it creates second offer, including a video m-line bundled with > the audio m-line. OK. > - that offer goes to Y. But Y can't handle the audio and video as > a bundle. In this case it can simply refuse the bundle while > accepting the video unbundled. Yes, this is OK. Obviously, if the offer originated at the GW (and not X) then the session update has to reach X at some point because we are adding a new m= line. > If that is ok with No Plan then I think I am ok with it. Great! Emil > > Thanks, > Paul > >> In both 2.1 and 2.2 the browser on X would see two independent, >> unbundled streams and handle them appropriately. >> >> Is any of the above close to what you have in mind? Or is it completely >> off? >> >> Emil >>> >>>> Wouldn't it be much more likely that such a separate camera will be >>>> controlled by a proprietary interface that is not directly related to >>>> WebRTC? >>> >>> Can somebody who knows more about these things comment if this is >>> entirely impossible for two devices accessible to the browser to be >>> accessible only via distinct IP address/port, or if it might occur for a >>> sufficiently sophisticated device? >>> >>> Thanks, >>> Paul >>> >>>> If so, then the additional signalling for this camera would obviously >>>> need to be generated by Y's javascript (i.e. not the browser). That >>>> additional signalling can then be merged into the one from Y's browser >>>> by Y's JS or a gateway. >>>> >>>> X would indeed need to handle an offer with two video m= lines at that >>>> point, but that's because they would negotiate different 5-tuples. So >>>> this is fine. >>>> >>>> Another option would be to handle the new camera with an independent >>>> Offer/Answer that would yield a new PeerConnection. I don't know if that >>>> works for your case but I thought I'd mention it. In this case any >>>> additional information required for the synchronization of the two peer >>>> connections would be exchanged in an app-specific way. >>>> >>>> Cheers, >>>> Emil >>>> >>>> >>>>> Once that is done the new mediaStreamTrack can be established on the >>>>> new >>>>> m-line. >>>>> >>>>> How does this fit into No Plan? >>>>> >>>>>> (This might be a good point to move this to mmusic) >>>>> >>>>> Done. >>>> >>>> Thanks, >>>> Emil >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Thanks, >>>>>> Emil >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> If you'd like for that signalling to be in SDP, I >>>>>>>>>> don't see any problem with it. However it would be best for this >>>>>>>>>> extra >>>>>>>>>> layer of SDP signalling to appear at either the application layer >>>>>>>>>> or in >>>>>>>>>> a signalling gateway (that is going to be there anyway). >>>>>>>>>> >>>>>>>>>> Does this make sense? >>>>>>>>>> >>>>>>>>>> Emil >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Further questions: >>>>>>>>>>> >>>>>>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate >>>>>>>>>>> per-m-line, with application specific signaling for bandwidth at >>>>>>>>>>> the >>>>>>>>>>> per-RTP-stream level? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote: >>>>>>>>>>>> Hey all, >>>>>>>>>>>> >>>>>>>>>>>> Based on many of the discussions that we've had here, as well as >>>>>>>>>>>> many >>>>>>>>>>>> others that we've had offlist, it seemed like a good idea to >>>>>>>>>>>> investigate >>>>>>>>>>>> a negotiation alternative that relies on SDP and Offer/Answer >>>>>>>>>>>> just a >>>>>>>>>>>> little bit less. >>>>>>>>>>>> >>>>>>>>>>>> The following "no plan" draft attempts to present one such >>>>>>>>>>>> approach: >>>>>>>>>>>> >>>>>>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >>>>>>>>>>>> >>>>>>>>>>>> The draft relies on conventional use of SDP O/A but leaves the >>>>>>>>>>>> intricacies of multi-source scenarios to application-specific >>>>>>>>>>>> signalling, with potentially a little help from RTP. >>>>>>>>>>>> >>>>>>>>>>>> Hopefully, proponents of Plans A and B would find that the >>>>>>>>>>>> interoperability requirements that concerned them can still >>>>>>>>>>>> be met >>>>>>>>>>>> with >>>>>>>>>>>> "no plan". Of course they would have to be addressed by >>>>>>>>>>>> application-specific signalling and/or signalling gateways. >>>>>>>>>>>> >>>>>>>>>>>> Comments are welcome! >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Emil >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> rtcweb mailing list >>>>>>>>>>> rtcweb@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> . >>> >> > > -- https://jitsi.org From martin.thomson@gmail.com Thu Jun 6 09:42:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC24F21F9967 for ; Thu, 6 Jun 2013 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw9T1RVyawaA for ; Thu, 6 Jun 2013 09:42:24 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8655B21F9640 for ; Thu, 6 Jun 2013 09:42:23 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so439493wiv.13 for ; Thu, 06 Jun 2013 09:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EqQ1/OryRb7jCU3fy4Zyl1i50KW/Q4psI/LsGAppReY=; b=sDPJTHbVRtAWELFq5qyCh2gkE6/UPaWQAvXjNX4iV7KNfaZ95d0QTSMIiaBFrwdfl+ iLtynJzWXDXTi5xakUycoPvOf+UCdMRVJFqo4rZnCQwF8hrEq5+yRpTcGV0eLvaBlaxg QOoAckCXbSSg79j9Y+lhUeAGehJlLBWgrvNvdAVYRQbdOKxjW3dSb0PsBExDSek+OJrh /iXQi4KCx2ICu1Q7HYcEG+m3vcbvk41XOYk52KFN3F8H9lmASZNkm5b65gHkA0bRvmTh 6LJitXzkaU/ZVcXNYzS+fc0JBvI7YME1Fdl0iqCt5/1L9+//D93PqMWBMD1rsMYeQHGq 89mQ== MIME-Version: 1.0 X-Received: by 10.194.158.102 with SMTP id wt6mr33032658wjb.5.1370536940478; Thu, 06 Jun 2013 09:42:20 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Thu, 6 Jun 2013 09:42:20 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> Date: Thu, 6 Jun 2013 09:42:20 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: multipart/mixed; boundary=089e013c63e87d310704de7eff5a Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:42:25 -0000 --089e013c63e87d310704de7eff5a Content-Type: text/plain; charset=UTF-8 Nice work. I had too many comments to do an email reply properly, so I've done the whole nasty Word doc thing. The only big item is that I think that you need to more tightly control the conditions for a BSO - in most cases, you could label those BSO as BRO without causing any problems. Given that limitation, you could probably eliminate the BRO/BSO labels, which might help with readability a little. --089e013c63e87d310704de7eff5a Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="BundleOffer.docx" Content-Disposition: attachment; filename="BundleOffer.docx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hhm69kmb0 UEsDBBQABgAIAAAAIQBFjx8opQEAAEIJAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM lk1Lw0AQhu+C/yHsVZptVUSkaQ9+HFWwgtd1M2kX94vdqdp/7yRpg0htqm3ESyCZmfd9dhhmMxy/ G528QojK2YwN0j5LwEqXKzvN2OPkpnfOkojC5kI7CxlbQGTj0eHBcLLwEBOqtjFjM0R/wXmUMzAi ps6DpUjhghFIr2HKvZAvYgr8uN8/49JZBIs9LDXYaHgFhZhrTK7f6XNNEkBHllzWiaVXxoT3WkmB FOevNv/i0ls6pFRZ5cSZ8vGIEhhf61BGvjdY1t1Ra4LKIbkXAW+FoSz+5kLOcyfnhirTzTJrOF1R KAlNfanmg5MQI/Xc6LSJGKHsin8dh5xHdObJaK4QzH1wPg52xmlESz0IqKDp4ZYMx/+A4eQfMJz+ NUM1lxEXGuL+p7LWbbcHRCroAmCp3IrwBs8PnVF8Em8Fkc6UIh1QrJS3RqjWXg55dygrh1akgswn 4lnD/lka6VYID853QVDrttojXZNQP3ff2JXMJkvKrBYSTUP4xZlX92pZ3fNbbaLGkaR3Ph8sJ+un 3vX23NMSXmPOqz+g0QcAAAD//wMAUEsDBBQABgAIAAAAIQCZVX4F/gAAAOECAAALAAgCX3JlbHMv LnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArJJNSwMxEIbvgv8hzL072yoi0t1eROhNZP0BQzL7gZsPkqm2/94oii7UtYce M3nnyTND1pu9HdUrxzR4V8GyKEGx094MrqvguXlY3IJKQs7Q6B1XcOAEm/ryYv3EI0luSv0QksoU lyroRcIdYtI9W0qFD+zyTeujJcnH2GEg/UId46osbzD+ZkA9YaqtqSBuzRWo5hD4FLZv20Hzvdc7 y06OPIG8F3aGzSLE3B9lyNOohmLHUoHx+jGXE1IIRUYDHjdanW7097RoWciQEGofed7nIzEntDzn iqaJH5s3Hw2ar/KczfU5bfQuibf/rOcz862Ek49ZvwMAAP//AwBQSwMEFAAGAAgAAAAhAN3CLG3F AQAA+w8AABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA1JfLTsMwEEX3SPxD5D1xk5byUNNuAKkLNlAktm4yeaiJHdlTaP8e 90VCaa0KORVZepzMnMz1HTmD0aLInQ+QKhM8IJ7bIQ7wUEQZTwLyNnm6uiWOQsYjlgsOAVmCIqPh 5cXgBXKG+iWVZqVydBauApIilveUqjCFgilXlMD1TixkwVAvZUJLFs5YAtTvdPpU1nOQ4Y+czjgK iBxHuv5kWcIpuUUcZyE8iHBeAMcDJWgoitWW0jmZTAADsou4OhehhxG8rk2GVGeSecZnFcQ2bSoU ugxzxpG5Gmz3wLOIdO3HBYLk7Dil1U41Ren3bVKifhcqwvVyE/RMglrVM5wrFMW7rvbN4bpVlGYI RddE43ttEO7GJuQnTF8BUQ+ZmhVrQaMb/Va40Wq/GnPj9RHKIgulUCLGVc4toAbzvD2wEkSZ1xy4 WRtP+7m95xsPk9Vx1JhMnVYc+XMra5zxVoVVv4bVLmI8XK0Y7H7PJmUsOE7YtD4TvkOmXh0bRH+T C5c51MVar41SWa3fmFTtuIi2Y1rdtYHSqjdPmak9k0uOtezU28LuZ2v11TyCqOLY3zF61WpTGvPq v7um0jqmGn4BAAD//wMAUEsDBBQABgAIAAAAIQBVPKwP5DUAAAUCBQARAAAAd29yZC9kb2N1bWVu dC54bWzsfe1u4ziW9v8X2Hsg8qsKSDmSSH0F6yz0OR2gqytIUj3ADgYDWWZibdmSW5LjyvyaC9kF 9lr2UuZKlqQkx1Zkm05qX5St09XdlciJJJLPec4HD8/513/7PpuiJ5oXSZYOz9SBcoZoGmfjJH0c nn29Dz9ZZ6goo3QcTbOUDs+eaXH2b1f/8v/+dXk5zuLFjKYlYrdIi8vlPB6eTcpyfnlxUcQTOouK wSyJ86zIHspBnM0usoeHJKYXyywfX2iKqoiv5nkW06Jgz/Oi9CkqzurbzV7fLZvTlH34kOWzqGTf 5o8Xsyj/tph/YnefR2UySqZJ+czurRjNbbLh2SJPL+tbfFq9EP+Vy+qF6r+a38hlnlv9il/PgHji RU6n7B2ytJgk85dhvPVu7MNJc5OnXYN4mk2bn1vOVfK+NfDzaMn+ermhzOuPq1+aTas3331HVZFY EX6L1W/IvMLmM5s3mUVJ+vLgN03N2uSq+mE30No3mD++b3H+lGeL+cvdkvfd7Tr9troXl+wD7lUv 8vrQive9zN0kmjMJnMWX149plkejKXsjtmSIzTrisD67YowzysbP/O85u0wu51EeXY+HZ6bhuVbg amfiakm/l+Jq/Q+7esnYbXw7PFMUx8BBgFeXbvKOiz59iBbT8vUnN/yS6eu2pYm3md/k/K9iHsVs BOyHpgmfR40o/Df4N7cLPoxoUWZnF/xH8+o38jBLy4L9TFTECVvF+2RGC/QbXaLbbBal/LdpVJRO kUSdH06ctOj+tbh4fVk8ufg7+/QpmvLXa654/BXWrl3UL3ixGlreOVE7RuJlizyhOX+67Chav8JH sH6p/fZKx9uLa83bLy/LK2OgDfiFsrosFivPsocg5yMqn+dsVR7zaHZXRnlZL82RDvV//hvd+Tcy gw3S8VEPlVONEDY2nnlOC5o/0bMrtG/oxZxOpyew0F8eHmhOc6nhnuhS33B1MV6wCxuzwPlKzMWm VnC0gJgWaAXQCiuqlICN7pkOsQy+WAAbgE1tTKg9Mif+RFOaR9MDTIotkuRg07R0CyQJJKkBlwQB q76quArRATYAGwGbbmPwf/6bUdX9JClQQWMedUNjWsR5MmIvNsmWKErBM+iPZxDnNCrZW7BVZ94w EjOClpMknkgwjkaIqTqBA4wDjLOPcXpiBiZpPF2MW352v+JKEXK//ub/GqBHHnXftP+3GLxGoBCF eMAjwCOVGEkZvCZRQht7BsAGYNPAhmkaZ92UKSdRiRpSblETipnVM6Lsr5I+ZnnydzpGNCknLYuw G3wqcXQlBNsHwAe2Ty19Uc+tnkU6nlJ0Swu+lDX/fHBvv3xEd7WnzSOi2kBFWY4iwUbVr9w9p7EM 5biGgg0b9B1Qzrq+a4B29wporb38Lca3zlx4DGFDQNVBxreCLd/VLB9gA7CpYFNxTk9snd5nD1Va 554NUyanxAgU0wjAdKnXBNhCTslogeYYhqUCbAA2FWxqD6pHaqbyEXusaVoOdWsm4mzGj37cRukj FQvObp9w+/S4F969/bJjoGylW8NcH9Fd+Tylza29+tco3+pOY7r5oOamzafrd20efKxT+FFGwbiO SxQFkhZBwawYV8acxR5WVT0E2ABsGtjwnaddMeCkQIuCjlGZoZQ+ZmUSlRR9yHKU00+rCzKcRXwz IL5BAHwAPgE+2HkqJ302kBdF9EhR9oDYNDQb3DMaT6I0KWbnKErHFxnfCadoVNFTNB6z3675aPQs wTmKarg+UVzgHOAc4BzgHHQ2G54hLn8FStI3pPxpiqsRPwAjBgillie5lD9saL5pcYAAbAA2O/XQ teCl2y/nwvTZx9VwpuVkdFNUFMljyvOrFmnyx+LV2m8LGavVI8d0Wl/gR+AvmUhPMjYtn9kPMlV3 P8lmRSYGNmYOO38rFX9SDPbvvWJdEnKpKP9eTV3npNYXfTo9oplmU3LPuLZ7vhtvgv98/YNrJM6u 8DskKb85n1QxBW+f1J9fAgtaCmcsj9JinjF0ceU1oyXN2/mRpyV2bfXNlrwtbS/7FrWsvcCCW4KH wkLvhsX79z/E27UHcqwaocxQVKIpfzzKUipMdwlTC6shJpYKMW4wtXaJfZ9cfg4+maGeqF312tF/ vfQvhM4Tig8idPtSw6+NpxY7HOG83TPvY4dNUB1RepeLckxz9E4H5fjhgNiXD2LdMx6ARw+t2HzO /ivLKJ5Ue4X8o3/+4z9nw3/+479EwK3CSzSf04jd5CHJC37AbT32X8kmknV7jJObYmc6RRk/x7fN Jn1hKWHIHMhSHS7e8c/ZBsZEULeNKPT56919fUBSIJf/QMFYrJvWIs5sSYNQftdzce6pccp3UOJu 7L44EZLIfb8/IB7UBtFLnIBXaoI4QTUl2+MEd4t4IhsksN83o8fKWw8M/UKsKqHZZTVsYbZuMB3p fKxtMm01M1XhFv6YwMERTc2S0XDDpD3Ax1V9VD+ns+yJGUYPeTbjgtIeZdf5Rl/THFvxziCOAXGM 7QIl4hgb5s7oWVAxe48ld1h2UBA/n9JPCsoWzBWZFhkTzP/gR48Z0F87LCdGRR8KStFfvn///teP 55WVSxsmbrZCGFtJMJOqu54aeFBoGZhpLzO1yOdUI6yjfudxMsuGMSobUOVcH5pUZXghcbEJxyWB UGp5aiVVbVgtB2c32Jeqddyhr2hUf/9ih3RLkqLZJCQGqGaQpL2qGfLM9g33tPPMzsUWDo3iyUtW 9Gb8XEJ1a6apqIoDUQognL2EI2MinwDDCLNXZqynSS/nzVbbtjTWl/0n9S05lWsBqM5pqy8e5QZU k5PKP5HYbVJ/YPLhzylLsjmpjVV8vKxRbzIzOXpKskUxfX45bT2ucywk1LGqYo+4cMa6XhVQx6CO 1yi1rwo5KtA0Y2IpavfuVcoHJ0AypWLA6ZE9qpqXEHzHrP78cgbHR6qlP3I7JOEZcDw+UKVxvuUE hq5qJLCgaGa9JGCEgBECJzBeZeW2pmPr4VbzBCfkQ1IVvWnNwZq58JbUXPPoU3NEVvYWhbpmob4l y3ZtcjqRVF88IQu1VTSpNkv3GaraW/JSjx95h+Sirh20f0sG3SkjkZmPsjh7S5GCY8LZVZS/itid YrL7hrvQUmhrkvKWUP8pRxWu+MarrKy8Jc5/VMED+kTzV/X8duW5hKFrqxgO+YOLWSNIeJNb8hgq j6PKc3lpsZgUPFV+TB+SNBHNp6I2ALuK2DLkeb4LqYoAvHXgrTXEk+9rtkHx74y6//zz9KpE9O46 O7XbvzZDb4mgbzEYf0ClHfF+MqoKK5bmEw8ypIAxVowhoWg0Q3N0TEDRAGwq2MgH0de8LgEU8Lpe vKw/TyhPey4oc1qZXk54xYikyrI5Rwn/BRl/7C3R2aNS1tdblPVJyU5nDB4S30838X2csVdIsxJ9 S7MlWk6oyFOVO45PFM9yFBM6CYA+3quPnebofbGY8z2F6qz16w4XQD+9oh9Rh6oxN6SiTYbrqYZv OUA6QDr7SEec5IvSMbBKD1ml2oN7ye5tNv13bsm9JY2if4m+4oAk/2EJxxC/JXnimBzDLbnQ0+mp pcGudpJa4rO21m/J/TiujO7ONe22VEzDJkR3YEMWLJVdTNGnnN8klRnoiVolbykDhFWiEc2HcwPA IbUISe2U6Ybi+NgF1QOwOVT1bDt0gLXjVj3XD+dNBhTPd6rikdxJzOLqQLkowys4uqn/kwlPeixf +cW0DAfrNhw1B7E7VOyg8suJHvMqUBTHdM4Z5i85ffhUZp9G9FM0HtPxX2G7o4eByVaNMQm1ovq2 ofuC/kGtgFoBtQKHh7tS+QthrdetqJKSFziJo+mqGVW1/SH2wyQ4R/Nszwp1MGWBc4BzKs5pJ0X1 i3J4u5bypbVdwyajjHnNBZ3SWBRla/XZWLN4JThH8THWDYMf+wDOAc4BzhGV2uimuu4V6/y1oy1t 9+GoVXhyfaTvP9NU3bZ59EnNLa91Ph6LY57n0kFgfIIggxhM/5LDCsqYI9p2RlWOcRpZ+MGMI267 00zSLUPTVO8MzCQwk4RUC4uoda5a7HYtJ0lcbWq1Kh+1ShoeEo1UdN/UQhwA/AB+O3gWopF9jkYO JIhEc7GnqsQHIgEiqeRIKrcJO6ZiBuK8McAGYLNT//z25T64RPfg4PXJwUspHYtjPsLJE5rp7gsv 9F9kvKJVgeYZM31HUypM5Cwft6Zri9lrOcTyoSFnvXZAO2D2llmPjd5Z9I2iYpHzunolzWd0nETs OcyvZpeiJf9/OYnKLud7mUynqNUeeZuJ7Gu+asBhZyAdIJ2KdBZFnzfE9vYnrd1vhodfsiUvIVvl mNLvUVxKEI6uupblaxBbBsIBwqkIZ5bxbZqeUw53pbhgNt7ULHmclGhM59zFYl5VJspGPdCoZBYR s4Gkcgyxoniu70BndiAbIJuKbJgM0JSXYexxc0b0gQ4eB+jaCz6iaFqIfOZVauG+aYE43hEOltuo zFUWi53TPxaJcJ5lHGQT+9hVfbBXQYWACqmEqTbVeqw/sgdULEYFIxJmuL90tygGEoSiurpLDBUi bkAotTxJbUqrpu0rng1JUQCbFWyYygm+R7P5lFZb0LT6BhWTbMm7jos6E0vmN9PXRQrX8vNkrKAg tH1sc5QA+gB9YAX1fG9SboMA0mJ6lRbDHWtalKLwuoRO0VVsOCZ41vWigE4BnVIbZz1WLF3l0qLF OMnWtE2ZoRF9ORIeFbwWhQThYMvXLN+F3SAgHCCcinCqvLE+882qzMQzmk8rAeWcM0vGiN2IO8wd jCR7kE2xNdcmEOoDwgHCqQin5wfZHpK8KNerxO6bi1Nxj0VM4LKjzm3PfOSoLPNktCgrDTNNinIg oUhU03dCQqBIOyiSWp6k9oyI7tu+iiHCArA5BDa6gj3P9cBsBdisYMPLfzRpDuhDXdXmllYVQcXV zZo2WwjJNLTQgG1EQNZBhIQd28GWzlvnAWwANjUhNX/Q01CR4R7bVCxXhaoOAKIuEGXDDQxJuOIn uwk1TeK9MZpNH71PIRzNshWLEF0z1r+8/g1d35B2OGfCJiNnIv4N5aL0Xn49VoXYl49lyKaI3flv o2mUfhMjSYoyy5+Zt1/NzU8ya3E2zfi7iElS2D9hKD+dy8tFc6Fg7DdtVSgsryZZUQ6iks1BGQ3i bNYm8tUMbqN107dJ4Nng4wKtd9F6sUnr3RjSdWKoOhR8AgztpP4NYMVDecoXTYuB8n8Y5XuOYXo6 lPUDce2i/HKoIBmHULVDPwwUCEYBjLpgFB3sEB7rsKU7KJ7AWN+0Bd2vWhwZGkUy9QqJohiWCWW6 6/UA/tzkz9mwyttVuQGJbu9vLpzfb5CCLGSbEujSdTNUHQLoAnR1a+dZIlWl7RR0FuNkmaHWGqlb nhRLU1XLA6cJ5KlLnkZD564v4qQpm+7hW8TJtDxVc2wQJxCnbvWUl/NZ1Buv6hCBOtphbvGYbrzP Xy8spUUq3bSh6ZbnmVDjvV4RoI1+04bVb9pwpGmDeC6EqoE2gDYEbbQCSP3ijX1DP5VdieRX15Ma 69EXJ5XVAkTxPcsmoAVAC3RpgdnwKRnTDGkbAXesIqxJgMswLcc1fL6kAC4AV6/j7e39z7cECElo E4J9yCkEeeqSpz7F2/kO8LvlSdFD11Hg+A7I0xb91C8XGKsHSNTRjnOLC/yLZqgXNjdzJQxbTcW2 GRicIoA4gDh6TxybzmC/iOPzze/SvIF1FyueAYfOgTdWvCEDGyUIA9+GOArA5hDYmKFpWzaECwA2 h8GGOA5WNMiSBtjUsDEGmvjTE3uWWfBVMaoeW7V3z2m8qsx190WqEBeTZt12deAN4I1GkGTUja7Y emBCZUCAzS5GEoEVpybmV/TEW4+JhrvLCa0KIe/jbugRdDK6apyxV0izEi2jtEStHlrdpKNg09Ex kE69MEA6UEU/p59S+piVvC1Fjw1frjsWRfRIeUPetQZ0MxpPojQpZucoSttZK3E2m9G0vI3SRyqg wJ6a8MBdLTjHiomLrK1Y1kfKELBtnHyUoa6YmrsxyrvymSnv+nFefSvKFVgat2r6NA9qPt14UvM2 pwe9juY5WzSYEaiai+HUD2gw0GAVW/W+090A+qNuHe6JmitxlJ4ze4VTcYSYJ3yO1u04lDGdkiOu M2a0pLlMR0PFJJoTEjiFDooFFEvFMy/t+vqrW14aFa535G7Nx5hOUW2n822ASyark4wN/jODQJIy 3ZTNiky8/pjNJn+2ij8pBvv3XrEudftSUf69mqDOqasv+nS6xb/4GeeTzck9I9GrczTJlvSpUlfN xRcmZleOWUQGEppFI8T1AigXVM85aBa5DSLFJbahEA9gA7ARsNlhkFynjRkMe0C98oM+f727522V k8fO7b8k5XcUhglvePkDDJMjskC2zFnBfMLNeboQE8V/Zc2QEwwLhtzKZuuezCpu27T+FtO61cZb AyPPzQQwsvkr8ygt5llergUrtoHzpJirzNpctSZ7/KAAyN4+2aNRPJGVuMp4A4k7u4qm0xMTsKuz 2fCsPaTOJg2KohDoGFpPOzgUEOHk4GsNdY0zRa+hfnHm1autkpob+xTyTYQ3vRbu5RuMW60Voh0K E46R3lkrd4sDrBUxAe+f0uO3VpyCQZF9xxTt+SmaLYgzcMG3c7fLFwH5kpCv3bJ1rBjh6c0jyiRg lj3RMXrIsxmPc7UlofPwsOsR1QBrF6zdGkvCsF1X62j0LIKm7JFLHkhGf8npw6cy+zSin6LxmI7/ ut02PHif91Q1lNggzxYliqZFxgT1P2hccuDziRXkPtiittYY/uDY9Ikz/NX5KZK5XBHeNVgIlgZY 7FH8kXTYnRwcdj9V0vpzw1mooNxgKCn7ohRHHzoC8vzoA/rnP/5zNvznP/5LkNr+/SNycAz71Dnt Jc2/2S7aAdtum46omo5DEyp7gE23S7r7FMF87TnvjtS9MJR+8JYQ+NWnYoo1frU4O84UIRsBfZXk +spw72Jknw0aW5x7gZGBkYWXLQEbzbMCXVF5ZA9gA7DZqciD79FsPqWX4ogXrb5BxSRb8tC4yHlc Tmhe0VdLFa4pu4P38piyUyGdS8qv1N+yA9YxucfvV4rcws6criiXcBr1t+x7nTJKr5LDnUTDcbTA BJOkXgjQLeAkVgnivT7GtyvfVH/LDnP/jIND8k31t+yPHblJwFNLWxjrGsdJidUWk+ZYiXKVktJa xzVgv2Wv8tiBvS0p8LRURFIdoTo0BKYYtq3pGBJNwN6sxUWuuYGHia/pIcAGYHMAbHTVNInnQ5V6 gM0KNsyRvfNvVnWB26WCZYqYG5bneWEINSoAVoewkUp0otohJGQAbNbYaNUQ7mmoSIDItE0SWg4Y 0ACiLhBlww0MdYQt2/VMTjaMO03ivTWqN6ud9CnEq1m2YhGia8b6l9e/oesb0g7+Tthk5EzEv6Fc hHXy67EqdjHLxzLkm3bDs7+NplH6TYwkKcosf2bqrpqbn2TW4mya8XcRk8Q7MYah/HQuLxfNBV5F c9oqQ11eTbKiHEQlm4MyGsTZrE3kqxncahuYJjY1DCYl0HoXrRebtN6NIaKFGvFc6FcBGNpF/RvA iofylC8AAJT/oyjfIKZBLBdimiCuXZRfDhUk4xBqlq86xAHLAWDUBaPoYIfwWIfdVWv6VJ3by2rf VWppe+nePmQZGkWb1U67+VPxHRPbngf8CfxZCdcGf86G0WKcZEjlBiS6vb+5cH6/QQqykG1KoMvA hhJ6Bo+WALoAXa+18yyRSjQ9BZ3FOFlmqLVG6pYn1XFD1VU5ikGeQJ7a8jQaOnd9ESdN2XQP3yJO mGE8tBSepgniBOL0Wj3l5XwW9carOkSgjnaYWzymG+/z1wtLaZHKFqvWdRRfN/ixBaANoI2+04bV b9pwZGlDJZppBArQBtAG0MbVZSuA1C/e2Df0U9mVSH51PamxHvs6X8lqAWK6RA9dKGcDWqBLC8yG T8mYtgPuWEVYkwCX4XsWIVD0EMC1xcToUby9vf/5pgChEZqO7sH+FchTlzz1Kd7OFdK75UnX7cCz NEj6A3nq1k/9coGxeoBEHe04t7jAv2iGesHbDMp5TabmaDavzAjEAcTRe+LYdAb7RRyfb36X5g0V +9i0CRgcwBsr3pCADdYC1fQVUDcAm0Ngo4SWrhse5BMBbA6Cja0HjmoA2/xw2MTZbEbT8jZKH6mw +1BdmdE8asPoyhhoAzzoibXL7Puvxd5aFids8HpRQTfLam4imw17G65bEt+M/q58ntLmNbz6VvSB 5jSNW0d9mwc1n248aSerBYbq2TacxwdleIgy1C0z9E3XA9gAbCrYVMpO7Ym621a1ojcpQ6IOJd27 d9vfw7110U6nbrxzS/9Y0KKUoFbsWkSzwc+olweoVVYjY4JDjTepBdj8/3FPreOmcLEnc52iLB+z 25QZSuljVia8dfKHLEc5/bS68FHU0d/sJXbOr0kA0zANM7B0DiAAJvDZu7o39dp6OqnlRp+/3t2j gqZj3vPx9kvbb9gSOWlTLp+IjqYrPyByIp7UvM2JSRpnfdEY5fbLOYqKrkabIHqnK3pV8zjebHWR JswtkVDiqkUsJ7S5ugYlDkocWjCWV7UZLDPa0+3AWGSzyluIptOPaNVsrehqvSUcBtAz2/VMN/Vi 0yKh60PtTKBeoN5KtlJKxz0n3iQdJzEP1bCvOa2yV1hyvkHLSRJPXmI0zNbLYh7CYS5UUk5Q1uqE 2c05CnZD1VAhIRM4Bzin4pzsoc+Ewxhmn3GXlIxhign7mFHSoqA8sJCwEU6zONrsotzNOTrxFKI7 4GIC5wDnVJxTbbj0mHdqM2bAlvyeEc5DkhclmiVjxO6yoA0P8VaZ+yYJCsgf31h/eAH5bsVjhJg3 SoWEC1A8oHgqyYvKMk9Gi7LPuudFzUwTpnVyKj7j779hDTc6qnKv5VIiVE0LAhVDSgQwDjBOxTiT 5HHSzo/sF9+wL+sUhIEEhWiupWmmBhQCFFJLkNyRaVcj2HZhMwlgs1fzcI/7ZVshmU5RQac0LoX9 I6J6rYxQ9JDlsMd7orlEV3wvSYJhTNMzmW0LxfiAYfYyTE9s2zEtYuZOU6minidq3SYpumO6I8lS ZAww+1MrGFAV/cr45huDr8+SSOgV4qgm9l1oqgZ6BfRKxSmVOd5rtTJ63sh+4lrl+gF8kH4plqRA aVaiaDQV6XCViolkzlqblmOYWgjNfkCpgFKp+ARyTprU2dYcbD0Gbh/3gidlZZnThKnNHJU0nyWp yCxmWrRgM8F8tnOU5c1hzZQuJZhVI7auaQr0OAFmrXEmSNS9/bJDrNYO+raFqrXMzVB/wEFf8aTm bY51cgcSIqlYxNQDB0QSRHIlkhKwwbpiKr7CAQKwAdg0TB58j2bzKb0UUVxafYOKSbbk58pFYYEl Myfo6pD5apOQeWvVAfRW4KIbfYZjuVbogIcG6KvQBx5amckM9ES9MxrFk7Xky46TSLCztH24JwqK vCquKDJzZQxhU9Xs0IStJNApoFMqEoFiJu2D8lytRItxkq1pmzJDIx4Tq7bd6gOuEoRjKqar+R64 UEA4QDgV4cA2Q7PNMHpG82kloJxzXo4ddTES5yIJwiGKbal+APU7gHCAcCrC4eDrMd1UR+f7emD+ TSfJTwsAqyO9QsPwI60DCUWiGZ6KFT04A0UCikTIk1wzAs+wdUsF2ABsDoKNYhiGBz0sADYvsGEW KjdXRJQbfai76tzSQmRgiasfJZClEJ3/CzVeAFmHEJJqmNgPCMAGYLNGSM0f9DRUJEBkGpqmqRZs NwGIukCUDTcwJOGKn+wm1DSJ98Zo+ttRULNsxSJE14z1L69/Q9c3pB3OmbDJyJmIf0O5yHLNr8cq 4e9XPpYhmyJ257+NplH6TYwkKcosf2bqrpqbn2TW4mya8XcRk6Swf8JQfjqXl4vmQsHYb9pKBi6v JllRDqKSzUEZDeJs1iby1Qxutw2Yq+Ir4OMCrXfRerFJ690YIqFia6YH+zSAoV3UvwGseChP+Txt Fij/h1G+5hNbxaoL4griWkFqQzLLoYJkHELDNAIPQ6V7gFEnjKKDHcJjHTYUMwf39iVDIcvQKNrM Y+/mTzXUie+bYDUDf3bx52xY5e2q3IBEt/c3F87vN0hBFrJNGXTpnqYZOpw4A3R1a+dZIlVx6RR0 FuNkmaHubK+hE6LrmgUFQUGeuuRpNHTu+iJOmrLpHr5FnBTNdLEZgjiBOLXECfH/RcO8nM+i3nhV hwjU0Q5zi8d0433+emEpLVLppg3iqX6oB5BaB7TRpYX7RhtWv2nDkaUNTIzQVwPoFwK0AbRxddkK IPWLN/YN/VR2JZJfXU9qrEff0kXaeFR8HduQBl3PO2iBdsD9KRnTDGkbAXesIqzJgCtUNGIbAC4A Vxe4ehVvb+9/viVAqOmeHupw9hLkqVOe+hRv5zvA75YnbOg20aBaHMjTFv3ULxcYqwdI1NGOc4sL /ItmqBc2N3MlDFvV1g1LtUARA3EAcTDi2HQG+0Ucn29+l+YNzXBJYBIDeAN4o+ENCdgoumpjHXsA G4DNAbDBWHVDG4OVArA5BDY6xrrlq3x5ATYAGwYXY6ANMPuvJ/Yss+Cd8ZhhsMdWbYRmdJxEqGpw Pxfd3cuM9/9Z68chQSbEMtXAdeBcLZDJQTpINxzP9kEHAWx20ZSItvx5QlNec50vWJRu9nTY5Ktz aB/er8rIjzSleVRSqU4enudbKlQorVcEKAcK61d9o3ttBbu3X9qrva1buFE/6FhXO8uReyfXw/nV UFuc1gz0/T2cqyc1b3NS6OLdDK9TFEcFRdkDx9rdF7BQemahVP1yZdsbmlqghAZUqarXBGwUsFGg 21jdfJt5u60Ouh+SNJ4uhF/MtUrKXjNL6ce6VZAE3WCXBHpowXY10M1eumn3ad60bHjTeLBs+mjZ nKMH5lismEmCdYjlYt0K4dQIsM5e1umJkcPB12MTZ4shc46qABVTMIs0+YP3VW06rzLK4T/ZYRx2 c46GDTM0DQj+AucA51ScA33jP7TGvjXwqx33Smfp9HmNLlceZRylaCSaVTNDjo65hznLcsp+lH2Q tTRSN68aBjPmMGyq1UsFvFpR6EuMom5bvDWraOsORFvm+CTgABsK2ZiEH7ADIZ7UvM2xTvvHgYS0 Kjo2bMuFAoQgrStplYCN6lieFYjFAtgAbBqSD75Hs/mUXqJ7RvC0+gYVk2xZNBHBJXPemH0hHLqV SjhHyZjRcPKQ0M3iEFvA52M7DCFTEMC305jv1ZbYs8xAT9Rp49bkZpT5hLcZ/k5TqaEefTmzMzRL xoh9uOD6oeAuauWQbib48o0nrm2k4366rpqha4PFC9oDtEclahD34/yyFvMSe5fZg9As8SLPmXH6 Yq0WmxEMGYOVqE7IvGygHKAcoBxBOdLN4o7ejuE+b8JD7K0dyzbnNNucK56pLRsJfjHsAIcYim7W Swb88g5+gXSskzFqcsropih5pnlUdu32MQZKsxLFE77RMj5Ho2c0nwpZliEdK/TcwIFSI0A67yad EzFq2inW/fKhVuEabtZkcRKVzLBZJuVEUE/VxXMt5M9zRJllFIuPJfiGYM1TQh36xALfAN9UfMNG /ZRki2La5+h/Sh+zsiKb1+ZN42AxuknyomwiN3f+jQTjKJ5u2I4F+4zAOO9mnLZbddJxncs+0NFV R/i3Zw5mVJZ5MlqUVNh+06QoBxK0aqqmpuse5A4BrdaSJJVyRhxdsUILYAOwOQQ2Smj7oQUdtgE2 L7Bh9hrzAJAIEaMPbuU13NJCHPAQVz9KIAs7BlECA3Z1AVmHEJLmWnagORDHAtisEdKqkcjTUKar hIE9R9U9ABGAqAtE2XADQz2OR0TTJN67KbPpo/cpeKpZtmIRomvG+pfXv6HrG9KOaU3YZORMxL+h XJySy6/HKq8TdFk+liGbInbnv42mUfpNjCQpyix/Hp6p1dz8JLMWZ1O+7VRNEu/gE4by07m8XDQX CsZ+09ZhwvJqkhXlICrZHJTRIM5mbSJfzeA2WtcdF9t64ACtA61XkNqg9WKT1rsxhA3LZTYmuCWA oV3UvwGseChP+QJCQPk/ivJVomo48HwQVxDXClIbklkOFSTjEKouQ7apQAowwKgLRtHBDuGxDlv6 YMEpdGF9yxZ0n9zbhyxDoyjvTdL7gYeDu1WJ4aq2RWxwIECVdKmS2bBK5VW5LY1u728unN9vkIIs ZJsShgrxFVUzoNQroGuLoTJLNmvAnLD6ZupJZqg72ZooOPQNE8rtgTx1ydNo6Nz1RZw0ZdNTfos4 GZ6KPRVyvkGctqinvJzPot44mIcI1NEOc4vzeON9/nphKS1S2aKFvRA7rgltU4A2gDauLq1+04Yj SxvYVXSH+B7QBtAG0MZlK4DUL97YN/RTiVEnv7qe1FiP/oCgrBYwNFszVJ3zPWgB0AKvA+5PyZi2 A+5YRViTAJdGHF/Dmg7gAnB1gKtX8fZRdEhn+y3ypGqOohlw8gLkqUue+hRv5wrp3fJkYMdTiQnn c0GeuvVTv1xgrB4gUUc7zi0u8C/MDbqwuZkrYdjqrm1jXYN6EEAcQByMODadwX4Rx+eb36V5Qw1t M8QK1K0F3ujijSbagjeiLYYMsjSsEzXU4CgPIKtbI/Uo1CKRib7fNfSx51shWHggT13yBKGWA+VJ 13RX10PQTyBP3fqpXx5Ty6aDUEsN6dfEoZIwcJgqBuIA4miIQwI2io1t2zdh6xlgcxBsNN3RsQ87 QgCbQ2CjByQgNoaNeYDNCjbMqg2+R7P5lF6KJtG0+gYVk2xZ8EbSd194e0aa8/aMKV1rvniOkjFN y+QhoZsxm27wmZ7uBS7xAHwAPgE+aE406nNTIt5k6Gzf+HtadeR4B3r20uPuXHSXGo+r3r1R3Qsc iepDg6pxL9rSnqtbg6jYdT3XAR8bNAhokErcXjq79ViTtHrarXcMp1E8ebFY0QeudOJFnjO7VYJw NMNSHEuB3QAgHCCcinCylBY9ppooHQvDNWVvwabiY9Mtc8O2kWAWrDBTRtXAlAFmqQVLrjGOH/iB a0LdQYDNIbBRXSN0FALbBQCbFWw6G7zdPaexfHc3jRjY9QOo6AOwOkiJqaYVYBfKmwJs1tholWMl 190N6x7PfAXXHEDUBSLo7tZMC3R3qybi/6i7G/fgodVPA7Z3t/rBzC4wNAInz4DWu2hdrrubqeqq o/G1BgwBhn54dzdeRx4o/8dRfmhbpq5DdX4Q1y7Kl+3uphu+44Y+hMYBRl0wgu5uJ3lADbq77bRx oLvbbjB0qxKNWUiqr8OhelAlXarknd3dTEMl2IAj5oCuLYYKdHc7qGSDoliBaWM4Qgvy1CVP0N3t MHEyiedZLjQfBXHaop6gu1tfnMdDursZhqZaxOAEAbQBtNF32oDubnK0oQWBikMdovZAG0Ab0N2t FzFq6O7W1gKqRizdVeA0HGiBLi3wvu5uJi+QTBwIaAC4usAF3d0ODBBqjuZ72AZ5AnnqkicoOX6g PGHLJYYfOCBPIE8d8gTd3XrkAh9Uctz0AtskpgfEAcQBxAHd3WR5Q8Oa4VgKJMwAb3TxRne0Raq7 m+orlum6UF8ckNWtkaC720GuoWGbYegzTIA8gTy9licItRwqT4EaYl2FUAvIU7d+gu5uEGrpjNEG RFd9AhvUQBwr4pCAjelZKlYI6BuAzSGwUbBmmIENbjTA5iC2MXyis/8BbAA2FWyMgTbA7E9PDFpm wt/SWfbEUNhjw9ZBn+k4iZBPizhP5mWSpSjMsxn7oO5S8KdXFUK6CYW4muP70C6yXi8gFDk9RAzT sLUQrF6AzS6iEiGX6xRl+Zjdu8xQzrmboihda9j0wIlrs3XcuWi4so/gT+WwgCjGT/dmbe4vakP8 UGWiAmX2QCr3SmVP7MVHmtI8Knvd0IomjE1zTrG3X9rrHmezGU3L2yh9pGK52c0Tvo2Cj3vds5x3 td4xWLbW24bKB4oDbChkY6B35fOUNk/06ltRTt1p3CqZ2jyo+XTjSc3bnBTIBnWzV9DZp3fGb1s+ 2te7+8agE42emUW3MR/dRgoOFeLaCjSqAiNlF7z6ZKRw8PXBPrk6R7y5ZlKKBr5ZLJoarzcTF65g u9dm9Uvsqgy5YOwQDwrF1QsG5PIOcgFT5bRMlapnOHODFmnyx+Kll3iZCcqpLJnxS2BqIME3emA5 uu57wDfAN5W0SSaNKJ6LNbCBATYr2DCNFHyPZvMpvRSeNK2+QcUkWxY8eHP35RwtJ4zK0Ub4PClW 1MXNJwn0KQFRVexDAy5A3y6t2ScPLJIZ54kaR+u+FoTxtg/3RJe/Uh6FsIG5K/5hM4h3wot/YCOR 4x3o2cf1eMsyKScyNqrq4FCxoAYQWAm7+KNPVkI7BtkvO6GVscP1xZ1/0xtTQdhHb2pGdlowiMoy T0aLsrIWnnjgnqGiKEWYXkKvYJsElkagHDToFdArFbVUkek+pyj90KC8igNbxx6kQQLD1AImF5S3 iaIYCjg8AJtDYKNZGOs25gAB2ABsmr0c7hqJ6CL64C7S8ZQ5S89pXF36KAErnYQasaDZEsDqIDYy fF+xiM8XC2ADsKnZaFX+5mkoVXUWW8wUCqAmGYCoC0TZcANDEjG/k3Xcp0m8NyS8GQzsk1evWTZT RkTXjPUvr39D1zekHduZsMnImYh/Q7k4K5NfjzUh9uVjGbIpYnf+22gapd/ESJKizPJn5upXc/OT zFqcTTP+LmKSeNmpMJSfzuXlorlQMPabto4UlVeTrCgHUcnmoIwG8etMn9UMbvVUHA1rNvZ+Klr/ XwEAAAD//+xd227buBb9FcJPU6BIJFJX4ziArjMBJq0Rt30dKBJjC5UlQ6Ljpl8z33K+7JD0JbYq J3RnBmds7fShNiVL3OTaa194GxZ5Se+XBR0NkiWrBtc3/1kN63Et/4urkjVoNUyaNM9Hg0/5nDbo A12h+2qelAN+hSYN85o86bw488qm+2dp82OxfHPznV99SorRABvbkkBUYa/selNB/v9iU1F+Q93k 2f24Hg00zbNIFJHBK5IE1bLOaS3eripF6ydCgv2idu21jtrLsm3tV0N2898/X/6hZiSusfUda+nE XQu00o3hIqmT24w/Q491zwrwQJYy+o2JUnvzJyom22GvFTqbZlsY0sdkWbAfr4xFkR2aroNlO24a ulkkaV5O+U0CNqJDNPELwND/DUPo27yQ3cIbf1HThtZPdHAIrHR0+wHdjg10gC9eqecFrXnXfUX1 MOcoqm8zrIt6sSmL62TOn/jHQ5GUX6UEecOq+nk00Ndt8i9prbQqKlEX2Tga/4tj9WZcDZfbgoaj uqBt/ZxVDbtKGG8Dllyl1bytoLsWPKauRuTahLcOqCuo6xpSB5rJRhrSFFhfdwkmduACjABGHTBK Dj0HLlxdVY9RLYRjnKI4vS1oUUxYUrNNN52p2NO6Wi7eEnbKbdcFyDr0P38If4+UujYqs/UjOxtj d/VMm6Lbx0GPVYUeklqBP4nl4sB2DeBP4M+1ch3w53yULLO8QrpwINH9p/G192WMNOQg11ZBlx3H JNQEjgBdgK4frfM8z/piszgnq4i6sUjd+mSaoRH7xAN9An3q0KeHkTfpizph7TA8/Bl1sizf8m0t BnUCdepQp2RUs8U86U1UdYpCna2YRyKmcXD3+drRWqTSTRua57q+RQKgDaANoI2h02/a8FRpwzBj LdRjB2gDaANoY9hKIPWLN94S/VJGJfLf/UBJ1nPv5xtlK4B9Eoc2TFMBK9BlBeajpzyj7YQ70RHB CuDSIi0Kg0jACMAF4Op1vr09/vlTCUKfhCQ2YHQU9KlLn/qUbxcG6S/rE7Z9LfYwOD+gT932qV8h MNFP0KizlfNICPwbtvRrV7i5Co6t4duO5zpgiIE4gDg4cRwGg/0ijrvxF2XesGIt0HxH6DfwBvDG sWyLcZBtsVSQRQKMHWKYgCxAVgeyIDQ8MTTUiY5DzQamBn3q0qe+eXgtGwSh4VFDbJKQuJjAQlIg jh1xKMDGttwg1l3RWQAbgI0ybMIo0D0SAWwANifAxjJ9OyCm2EMCYAOw4XCxrvAVuTKu+uHQHtuL pT0RLq3mc1qy+6ScUik1f2Iu9GeDiHPt7TBvkgeublOV7u7HnMf9ruYSH+toITiJiKUZB4JP2HNB tzUINo+ij7SmZdrarGb7ou3Vgzdta3OuwPLQHc3yBIW0Set8wfKqRLcl8tB6iwT06w/bQnQbKNMM uDscwVI4MFAbZCn5NQRbnkkwLEgG2LzG/TKFx2mpqjP+bFahTNpDipISDeajARI9hvISJVvektvZ vEdsRnszV/7jozBQb05a3J8uf0QpDc0kFiw0AqV8WylV/NFL2B2LlrROGG167H/TnLNpLSj2/qNy 3GWed79XNfInH18Rdi/yaIv6z0Ue8k3b2lwUyK44pXwCm32RS9xOD+sPmMS6QOHvPk8+KeY12uL/ c+wi33Tm7HJT03n1RKX/v4kVDhcuCZ9MqtrhNGFb91ydwG6w4Pm+prbS893Fne9RwtVUxTG8hAXZ rM8ucNI0VZrzOCBD8zxD/LdL3v2PdTWXTLOfexCezG2pwDmWbmA9MGH+CXDOm5zTE5JJsiwXIxH9 ZRrIXPYsCuKWJZ+WDUrQd1pXaFHxwEeaF5HtFlh4cTdU/FjNMCMrAj8WbArYlDXHJGla1Vm/Z1Bs qISLnNJsycvFkNl9HCCCrdZMom5eMQ3fMTQtBF4BXlmrldoov29HuuaAOQLY7GDDLU/0LZkvCjqU GX+6/oKaWbUSbpA/+fgerWbcL0SHg/zNLqHH2UsBfFZkhLovj18D8AH4tuD7pS9+T6m0Y9eFejzr YYBMpujetWYHwVjjcXEvGg6N9ILbW9l1Ww891i3PwrBMH6zHgfUYnMoal2pfvtNDJ+xNRrlI83Mz eLc/OLTK2exg7HnPgd2NFk3CsQIBGTjWXNOAifVAQK+ZNqVUXl84Sbp3wz64vTc/c5LpRQEfJYzV +cOSSY9uM2ZS5A1bT8t4GVeRQypycEXeo0C9GLtBaMES/03/AfXCKAo75QzKS2Oag2HYKwUCsc1I 0wwsFB0IBAhEdbgER5rveXAKA8DmJNjomudgLYLN0QE2O9hwz2QSjpFM/aJf/GWZFRRNnst0XfRO BVahhg1Dh/mpAKtT2Mj2Yi8IbNjoCmCzx0a7/TifRip7M2rYIZGrgwMNIOoCUTU6wNCxxFcPMp5J kaeHKa1jjXHZ4zBHInfsuJpjGCa29j/efkC3Y6Odupnxxqi5in9FtVwPWd9m8sChIZuymDcRf/If D0VSfpWS5A2r6mfuJa3b5l/SamlVVKIuspHEPrhxrN6cq+FyW9Bw9itay0bZzaxq2FXCeBuw5Cqt 5m0i37XgUZfS5ZxuunAaC9B6F603h7R+xL/EgY41zwcMAYYkho4n53fASkfqlC8BAJT/d1G+bWkx jmFFEqhrJ+WzkYZUAkISe2EcYUhGAYy6YJScHBCeq9hyistbwl7KYSY/M8mlT+HtY1Wh9nHV3fyp a7HvxzoshgH+7OLP+ShZZnmFxIlcL+fZachBrq2ALmyEoev4MGEK0NVtndtrLi7YZnFOVhH11Y14 LYPYFnFgd2zQpy596tMZkfhvOCKS+DF2XFAnUKcj5qlfR0SeolBnK+aRiGkc3H2+dhTPAMcuIWYE o1VAG0AbN0On37ThqdKGYTi2ZcaQqgbaANq4GbYSSP3ijbdEv5RRifx3P1CS9ezX3apaAd3lJsDX YBo0WIEuKzAfPeUZbSfciY4IVgCXHbheYGmw4gfA1QWuXuXb2+OfP5MgNB3PJ7YJmz2BPnXpU5/y 7cIg/WV9Ir5tuYYFCXfQp2771K8QmOgnaNTZynkkBP4NW/q1K9xcBcfWiLHjBGEAxAHEAcQxbAWD /SKOu/EXZd6wdF/zsQUnVwNvdPHGNtvykmmxVFBlYt/VfdjKAFAF1ohbo5bOgBt7lDgwtjTXJjBz BIhjRxwqXkzkmpYRQ9oEYHMKbGzDiAMngAknAJtTYENIaBEvgA3mATY72HCv9uM4+oBuJ5PP0RDd MnHsVhxPxIFcbMafncuSpCiqFc3EuYJ5mRbLjO7vs62CvcD1QjeEBWOAvTX2YIftOc3yREXWCw2w Mtqkdb4Qx3/L40lbZ3YpkIrueziwLBU/KLawbYps4Q/8QSJiaSJwe+GP2NRs7G8koykb7xp+71Gy OtOJaIoVrwreUMqMfzYdY9Mui+ldIjuzWvByY31LnU9n7OXrQ8VYNX/5XtDHvaszmmS0Frsgya+P VcX2vk6XTH7dvC6tCtENm7YW98jirEp/rfNMPJsT3jhnKa8ll3rTT2sR5ceHKnuWH/hPlnNaspv/ AQAA//8DAFBLAwQUAAYACAAAACEALmgozJwKAADsMQAAEQAAAHdvcmQvY29tbWVudHMueG1s3Fpb b9s4Fn5fYP8D4acZIBffYxtNiji2OwGmzSJJsZh9WTASbXEikaoo2fVb/8M+LbD7uj+sv2S/Q0q+ JHEipe1MmyJ1HJE8PDyX71yoV68/RiGbi8RIrY5rjYN6jQnlaV+q2XHt/fVkv1djJuXK56FW4ri2 FKb2+uSvf3m1GHg6ioRKDQMJZQaL2DuuBWkaDw4PjReIiJuDSHqJNnqaHmDyoZ5OpScOFzrxD5v1 Rt1+ixPtCWOw3xlXc25qObnoPjUdC4XBqU4inuLPZHYY8eQ2i/dBPeapvJGhTJegXe8WZPRxLUvU ICexv2KIlgwcQ/mvYkVSZl+3ZKS9jERgdzxMRAgetDKBjNfHeC41DAYFkfljh5hHYTFvETfaX6aD UcIX+LUmWIZ93y2KQsf54xQb9RIaIRKrFWVY2N6z4CTiUq03fpZoNoTb6FQj0LxLIJ59mXLeJDqL 19Tkl1E7V7crWuTZFWjlSt48mvkyZq4CHsMDI29wPlM64TchOILKGKTOyKxrJ2vEYYuB9I9rgKrF gGdpoOGyb3mSSsWuAx0ZrWjE5yloYK/Wfr2Ln+t6b9BuD+r1f9CoVDKVPATbb68t7RhbtQcxT/g5 aDf6k+bR6bBTs09T8TGlp0f5PyIAxPQvwUT9tNsaj1urRyMx5VmYboxY6n9L7K+rdBkKTJ3z8Lh2 5o5zDeq1w5NXh6tp7iP//tCSSzEVCXBa5OvyuVwpnVoMwoR8ZEUvPbkUPAyXr+lxWgzSpvePX+92 Tlv1s26J4x+NOv1e86Hj5yNVj/8wR+1RfXTWbZHO/3COVgI8Z2kg1S0+ecqGmfKx9J2YaVgSCZ1d TKEWJg3j7EakKb7jf3TA2JWErthSZ4wnggmZBhhTxUo1A0XBMiOYnrLh+3ejX8dMb09YBNILWCiV APU4Fhz7KNrHcnFQQqfN9lG/ftoZlZBga9zq1tsPSTAf+To67TR7k/bZ5PTP4GilUyBGNgvYOYPr CKdZ0o6wmkoXmqXLGDKHYrTVLo0NGHIhqISmkVJ9rT5/+nfKbpVeMLlSIQzBZHGsk1T4eww51J1l drrdUeLHwE5+0QuBZGyPGWswZBVahUvmSwMr8KyRgSo99zjMxRfGS+SN8MkY6OlUZ0kaMJLwLOFx sEdPaWLOoRKYm2qYJzMxkiWms/Qh4zlcge193G08A3c7JXG3M+71JpMhbfFycPe9ChHlrMoDPiet TeHHPvv86T/c9xOMff70X8Z98SGD7MIlKY2MwlTVDOF1Jc30B82yEbHdO+vC23p/IgB/fc38BpXQ avIrQLuBX4R6sQdUJZ+ExxiW2KBJJdKSyYicmUPecCGrSvLlyv5jpVXRgY5Kqqk7qbdazbPhi3Kg 64CcZiaUSCAbB31QlkNSC5AErEakBNNpwpUhPVkUjARCsKHZSDbn0hc+YBb0lHXHSM6ClHFjUHix 4dXFHgP8KoJwQOOCGxoSEZJRn9EfbHh5UVXbLesIFbXdL6vt3ln9qNslvb4kbVPgFCIiiSNGpaBr SKszsYdI6DvNCa7ICw1fbikEzCVaT8dJAl4odB/XEAijqxSCJy5WuwzKLBsrf2PRTWK/p1T0DEzM PcyKAd8imYvaCdCc7PQpsiYWYXifHZs6iqTU6m2udrDD3r6/umYx8k9pMxp2qsyCtrBSE6HwYPhq +ajX2DBEi5BeeGHmr/OMPMOZUUXqHOo7Ozh8Rhenp2NCO9ExhVlKod3BArh0puSHTOw4vU2TEhHp OQ4+TXR07+g2qUPeTnLxRSzwodJweYCNqsKEdc1qMNFploSJ1mlv2Gr1zkrAxKRTP2pS9PiOYWKT 3430f4c9XGdJHtxDblLYu0ppL2gMCubIiBd3TTe3zFUS/ccCzBYXBeQQuvydohYvqsxEeELOqRqk h+Tazqq554k4tcFqw1DvnrCaCNnpu5ErRhI5k4qHeS3kaZVym8pGmqqlALw8GYkdgDg2sfIxLh9h yRY23xnmwLR8krtrDFwtlZfr6iekFj/v0dFdGU+sPyicKap+pJvbaGVsKUoyhcHSUvhORg8IwyHB m6WTaI7v2wnKHV3n7v3YUZ4H5rs2eaasK/Lsk/giK6sdsnXyy6v7dSzcFGJGjUg7/ECwcD0XaEgm ABFqvRx/PRk9ZPxPosxOagPnUtUk/gQ6VdQHye2eHRZAth0ad4PRNho+NonIkdVCb0AqUpytDAD5 mxWbxvi/8uYOhhTyA40gYN2WNM+pAqDcfwufXJwPOEI8BXfpAf0eA7ZtiCzrjLvPenfSTqFfk5lu h7iyqH9CpU4kbScedZKYS52Z8G5ivdvitk95+HSyYzt5FZOdbslkp95vd9rDozItpN3Jzsbxvoua 6CJ5zdiVLpoSK1M9Rx6w74LxQqYBBiDpOBTURrKpzSOhGBTPQS2iziczGbU8b3TmUBI5/Xazm7Yz 7OLdr7+5fBehyAtRg+3DOeBEQF/hS55IYR6zmo3+zy7o+MmeA3/HVKFgmzxBuFuWSLNnC0EPOQfk mbfKyf9gVTNNHkj8z8zPD+MQnXC62YbdjAqua2vyvW2u4RoGtFsR5i8vnMxXDYi8mWdlE1C5aqm6 Dn0x+JCr3LXgdrM7HE/OqCL4Tjr17caoP2k0y1yHfbtO/aUwaSK9e/clME1I/PcMyMcRnz/CJPdy b1CUTekFJzDEVPjK6k5FK3qSKXtrTwZtjYVF/NYmEfYSJ4RjCG6kK5p9AZsiujCdt9o4v8r5oJaU Yb62vpSID5kkd8pbSh8plLgGkhHImX0Wo/as3DfsVO4b9gfNsiVit1Fvj5uNl9XevbZ3H+IjJ0g0 bKGz0KeaPsqQhNuSRQA6YVFzkcf95brT4fJps24JQu6mSLONa4tYo4MWAJv3U54SGiVxV9RovaxG G61u87RxRq74YuLgwzFjK1JZ18VPQq3dopNPleo0BHaYR3OizfB0YhGE/NtdssUFZNge0FXlPnCn /wzvLXtt1u6P2/0jeuvpBXnv50//c1W+K6JNQO7rrjHt3QuluQTxLv1ZZwrFVait1OIQxlJVV93K r5ZAV6VvaBq9Zm/YKhNLfxxdna9umHe5IoLmG0lI6srpdfpEujJI7XZe3Ejlrr9nmTQBvRnkerF5 dLWbFPc4QOUwdKh8Y+Pv5QX2pa1sHuAaLI9uuG0qqLm0vqWXDG3lXZiHvQFXWHFc++cbPeTerSuT i8mom9dTc/E/YXGVb4lgcb3St0TNVmdY6m2eb5W9faNbIpul5Te061I/KRJFe6vL3VsPRT8/gKmE ZC4blxmwD0NpgFZUFcCMgS4R98mCSFqoB2Yz0HT0RPUb327l5j60W/YOsDnptU9Ho8mL0u7pjEu1 t12DFnCSZ/rOt0c57Oi5SCgRf0Zk7lbuRvQHrbKRuYEcqj4Zl7mP/3G0cyl+J3dRM2ohMPfaCjXf gNOEz9SAc/XXsVTcpteVdULhsapOynaImmfjZmc0LnMd9gN5jKH2zVzsOf94xpsK3We8PlRa5vVW qz+Z2Mj5gmJQsqSowuda+qj86XV0KiVtzIDsisITMEUvGt19B89wurihEKaWC77cK5p7WNnp9Xru jcFQ3lIrz8YuqIuuLcG3pPKUFj2l4/V3c/J/AAAA//8DAFBLAwQUAAYACAAAACEAqlIl3yMGAACL GgAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZTYsbNxi+F/ofxNwdf834Y4k32GM7abObhOwm JUd5Rp5RrBkZSd5dEwIlORYKpWnpoYHeeihtAwn0kv6abVPaFPIXqtF4bMmWWdpsYClZw1ofz/vq 0ftKjzSey1dOEgKOEOOYph2neqniAJQGNMRp1HHuHA5LLQdwAdMQEpqijjNH3Lmy++EHl+GOiFGC gLRP+Q7sOLEQ051ymQeyGfJLdIpS2TemLIFCVllUDhk8ln4TUq5VKo1yAnHqgBQm0u3N8RgHCBxm Lp3dwvmAyH+p4FlDQNhB5hoZFgobTqrZF59znzBwBEnHkeOE9PgQnQgHEMiF7Og4FfXnlHcvl5dG RGyx1eyG6m9htzAIJzVlx6LR0tB1PbfRXfpXACI2cYPmoDFoLP0pAAwCOdOci471eu1e31tgNVBe tPjuN/v1qoHX/Nc38F0v+xh4BcqL7gZ+OPRXMdRAedGzxKRZ810Dr0B5sbGBb1a6fbdp4BUoJjid bKArXqPuF7NdQsaUXLPC2547bNYW8BWqrK2u3D4V29ZaAu9TNpQAlVwocArEfIrGMJA4HxI8Yhjs 4SiWC28KU8plc6VWGVbq8n/2cVVJRQTuIKhZ500B32jK+AAeMDwVHedj6dXRIG9e/vjm5XNw+ujF 6aNfTh8/Pn30s8XqGkwj3er191/8/fRT8Nfz714/+cqO5zr+958+++3XL+1AoQNfff3sjxfPXn3z +Z8/PLHAuwyOdPghThAHN9AxuE0TOTHLAGjE/p3FYQyxbtFNIw5TmNlY0AMRG+gbc0igBddDZgTv MikTNuDV2X2D8EHMZgJbgNfjxADuU0p6lFnndD0bS4/CLI3sg7OZjrsN4ZFtbH8tv4PZVK53bHPp x8igeYvIlMMIpUiArI9OELKY3cPYiOs+DhjldCzAPQx6EFtDcohHxmpaGV3DiczL3EZQ5tuIzf5d 0KPE5r6Pjkyk3BWQ2FwiYoTxKpwJmFgZw4ToyD0oYhvJgzkLjIBzITMdIULBIESc22xusrlB97qU F3va98k8MZFM4IkNuQcp1ZF9OvFjmEytnHEa69iP+EQuUQhuUWElQc0dktVlHmC6Nd13MTLSffbe viOV1b5Asp4Zs20JRM39OCdjiJTz8pqeJzg9U9zXZN17t7IuhfTVt0/tunshBb3LsHVHrcv4Nty6 ePuUhfjia3cfztJbSG4XC/S9dL+X7v+9dG/bz+cv2CuNVpf44qqu3CRb7+1jTMiBmBO0x5W6czm9 cCgbVUUZLR8TprEsLoYzcBGDqgwYFZ9gER/EcCqHqaoRIr5wHXEwpVyeD6rZ6jvrILNkn4Z5a7Va PJlKAyhW7fJ8KdrlaSTy1kZz9Qi2dK9qkXpULghktv+GhDaYSaJuIdEsGs8goWZ2LizaFhatzP1W FuprkRW5/wDMftTw3JyRXG+QoDDLU25fZPfcM70tmOa0a5bptTOu55Npg4S23EwS2jKMYYjWm885 1+1VSg16WSg2aTRb7yLXmYisaQNJzRo4lnuu7kk3AZx2nLG8GcpiMpX+eKabkERpxwnEItD/RVmm jIs+5HEOU135/BMsEAMEJ3Kt62kg6YpbtdbM5nhBybUrFy9y6ktPMhqPUSC2tKyqsi93Yu19S3BW oTNJ+iAOj8GIzNhtKAPlNatZAEPMxTKaIWba4l5FcU2uFlvR+MVstUUhmcZwcaLoYp7DVXlJR5uH Yro+K7O+mMwoypL01qfu2UZZhyaaWw6Q7NS068e7O+Q1VivdN1jl0r2ude1C67adEm9/IGjUVoMZ 1DLGFmqrVpPaOV4ItOGWS3PbGXHep8H6qs0OiOJeqWobrybo6L5c+X15XZ0RwRVVdCKfEfziR+Vc CVRroS4nAswY7jgPKl7X9WueX6q0vEHJrbuVUsvr1ktdz6tXB1610u/VHsqgiDipevnYQ/k8Q+aL Ny+qfePtS1Jcsy8FNClTdQ8uK2P19qVa2/72BWAZmQeN2rBdb/capXa9Oyy5/V6r1PYbvVK/4Tf7 w77vtdrDhw44UmC3W/fdxqBValR9v+Q2Khn9VrvUdGu1rtvstgZu9+Ei1nLmxXcRXsVr9x8AAAD/ /wMAUEsDBBQABgAIAAAAIQCkAwgd6AMAAGEKAAARAAAAd29yZC9zZXR0aW5ncy54bWy0Vutu2zYU /j9g72Do9xxLsnypUKdwYntNEa9D5D4AJVE2Ed5AUnbcYe++Q0qM7NQrvBUFDJg837mS3znU+w8v jPb2WGki+CyIbsKgh3khSsK3s+DLZtWfBj1tEC8RFRzPgiPWwYfbX395f0g1NgbUdA9ccJ2yYhbs jJHpYKCLHWZI3wiJOYCVUAwZ2KrtgCH1XMt+IZhEhuSEEnMcxGE4Dlo3YhbUiqetiz4jhRJaVMaa pKKqSIHbP2+hronbmCxEUTPMjYs4UJhCDoLrHZHae2P/1xuAO+9k/70i9ox6vUMUXlHuQajy1eKa 9KyBVKLAWsMFMeoTJLwLnHzj6DX2DcRuS3SuwDwK3eo089F/cxC/caDpNZU00CPJFVINT9oyWJE+ bLlQKKfASiinBxkFt0DLr0Kw3iGVWBVwN8DpMAwGFoATEVVmkMEAa4kpdSQvKEbg8JBuFWJATy9x Nkah4vkJ74ntD+1EJa5QTc0G5ZkREuz2CEqZxG2UYofAxmCVSVRAgHvBjRLU65XiD2Hugf0KLqe1 cL3QrbKmr8CCIwbFnfXKWpTYJlsrcv35WwMXHY7oJOTbQALmgCIl3thDzcyR4hUkn5GveM7LT7U2 BDy6jvmBDL6XAOY28megweYo8QojU8Mx/aRg7iZWlMg1UUqoB14CXX5aMFJVWEEAAvRbA32IEgd3 zh8xKmH8/mDcwSmNYJiX2i+ehDBeNQzn4+FyOWwytWiHhPPJfNXS4xwZLofjMLmETBajd9P4EvLv cRZ3UXK3uoQsl2EUXURWo3AS37V1ttWx1A7cP5VfWar2WGNxj1iuCOqt7UgeWI1cPd8R7vEcw4zB p0hW5x7s9xtAM0TpCnrZA67BWVoSLRe4cmu6Rmrb+W011EUpzI1Pr77saMLqdyVq2aAHhWRDQa8S JUlrSbh5JMzLdZ1n3orDVDyBal5+3it3Tt3xwBADKrlWfkSOkk4X8/6XrKUsVZmlG14jKRvW5tto FlCy3ZnIEs3AroSX223ybdxiscPiBnMbVNjKQLtddLLYy070hl427GSJlyWdbORlo0429rKxle1g XiiY58/QQH5p5ZWgVBxw+bHDvxE1h6B3SOJFM9uBXqIRtMNe9/YpfoHHBJfEwAeRJCVDL/ZticfW vNWm6Chqc6ZrMasszz2UyCDfumfGjuJvcrFvTkGAjtmR5d1TctMkTomGcSPh1TFCeew3h0VJWori AToJVg0XV1EyXYybzoxG7rUyG/vIwb0/4eoOaVy2mDcdNaZ/Dacx/N6F/dV0ct9PRgl8HI4WYX+Z DEfz+XQaJ8vp322T+m/D238AAAD//wMAUEsDBBQABgAIAAAAIQBcliciwgAAACgBAAAeAAgBY3Vz dG9tWG1sL19yZWxzL2l0ZW0yLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjM/BisIwEAbg+4LvEOZuUz2ILE29LII3kS54Dem0DdtkQmYUfXuDpxU8eJwZ/u9nmt0t zOqKmT1FA6uqBoXRUe/jaOC32y+3oFhs7O1MEQ3ckWHXLr6aE85WSognn1gVJbKBSSR9a81uwmC5 ooSxXAbKwUoZ86iTdX92RL2u643O/w1oX0x16A3kQ78C1d0TfmLTMHiHP+QuAaO8qdDuwkLhHOZj ptKoOptHFANeMDxX66qYoNtGv/zXPgAAAP//AwBQSwMEFAAGAAgAAAAhANFOLyh0AQAA8wIAABEA CAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyS z0+DMBSA7yb+D6R3KAxdDAGWqNnJJSbOaLzV9m2roz/SdmP77y0wmGQ7mHB4r+/rx+tr89lBVMEe jOVKFiiJYhSApIpxuS7Q+3IePqDAOiIZqZSEAh3Boll5e5NTnVFl4NUoDcZxsIE3SZtRXaCNczrD 2NINCGIjT0hfXCkjiPOpWWNN6JasAU/ieIoFOMKII7gRhnowopOS0UGpd6ZqBYxiqECAdBYnUYLP rAMj7NUNbeUPKbg7ariK9sWBPlg+gHVdR3Xaor7/BH8uXt7ao4ZcNrOigMqc0cxxV0GZ43PoI7v7 /gHquuUh8TE1QJwy5YL4w8tguVHCKtlifakZ+haOtTLMesEo8xgDSw3Xzl9lpx8teLoi1i383a44 sMfjxZ8uiWaTgT1vXkeZtMSQ5qdRd90BC/yIsm6gfeUjfXpezlE5iZM0jKf+Wyb32d0ki+OvpsHR /rNQnBr4p3GapQ9jYy/oZjR+puUvAAAA//8DAFBLAwQUAAYACAAAACEAcEI++OMBAADkAwAAEAAI AWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu 2zAMvQ/YPxi6N7KzpssKRcWQYuhhWwPEbc+aTCfCZEmQ2KDZ14+yG8/ZeppPj4/00xNJiZuXzhYH iMl4t2LVrGQFOO0b43Yr9lB/uViyIqFyjbLewYodIbEb+f6d2EQfIKKBVJCESyu2RwzXnCe9h06l GaUdZVofO4UUxh33bWs03Hr93IFDPi/LKw4vCK6B5iKMgmxQvD7g/4o2Xmd/6bE+BtKTooYuWIUg v+c/7azx2Ak+sqL2qGxtOpCLK+LHSGzUDpIkbgDiyccmyWq5mAs+YLHeq6g0Ug9lVS4WnwSfMOJz CNZohdRf+c3o6JNvsbjvTRdZQfBpiaCLbEE/R4NHWQo+DcVX48jD8qPgAyJ3Ue2iCvsk55fZ4xiK rVYW1tQE2SqbQPA/hLgDlQe8USY7POD1ATT6WCTzi0Y8Z8UPlSC3bsUOKhrlkA1lQ9BjGxJGWRu0 pD3GPZyWTbG5lFVfQOC8sA96D4TP3fUnpPuW7oZvmK2mZnsPg9WJnamz0xl/qa59F5SjDvMRUYd/ podQ+9u8IK89PCcnk38yuN8GpWko1fxDntCbObElFhoa6jiVkRB3dIdo8wn0r9tBc6r5N5G36nF4 tLJazEr6+jU6cbQK42uSvwEAAP//AwBQSwMEFAAGAAgAAAAhAAbnD5MNAQAAkgEAABMACAFkb2NQ cm9wcy9jdXN0b20ueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnNA7b4Mw EADgvVL/g+XdsXGgBQREPKVuHdLuyJgECT9kOzSo6n+vUR/ZM51PZ3++u+xwFTNYuLGTkjkMdgQC LpkaJnnK4duxQzEE1vVy6GcleQ5XbuGheHzIXo3S3LiJW+AJaXN4dk6nGFt25qK3O1+WvjIqI3rn U3PCahwnxhvFLoJLhykhT5hdrFMC6X8O/njp4u4lB8W27uz7cdXeK7JffAWjcNOQw88mqpsmIhGi bVKjgAQVSvbJMyIxIbSidZeU7RcEertMIZC98KPXSjr/x4a+DF5dXDrrD+tMQa7EG8QzZdU1QRfG cd0GYe0D2bddFcYhbcuwyvDtTYb/uvLH2zKLbwAAAP//AwBQSwMEFAAGAAgAAAAhACbgWZTzAAAA TwEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMi54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAZJDBasMwEETvhf6D0d2WHDtpG2wHHEeQa2khVyGvY4GlNdI6tJT+e2V6 SntaZoedN2x1+LBTcgMfDLqa5ZlgCTiNvXHXmr2/yfSZJYGU69WEDmrmkB2ax4eqD/tekQqEHs4E NokLE+e5q9nX8SnPd1sp02157NLyVG7SVsg2PRVdWxZSnF6E/GZJRLsYE2o2Es17zoMewaqQ4Qwu mgN6qyhKf+U4DEZDh3qx4IhvhNhxvUS8vdiJNWuf3+tXGMK9XKst3vyjWKM9Bhwo02h5GJWHGU0M vxVco6PIoc8Z+FojMN5U/A9k1XdPaH4AAAD//wMAUEsDBBQABgAIAAAAIQC9hGIjkAAAANsAAAAT ACgAY3VzdG9tWG1sL2l0ZW0yLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABszj0OwjAMhuGroO7UAxsy6VKYEFMvEEKqRqrjKDY/uT0pggGp82O9n7Ej4a3jqD7qUJLv DJ440+ApzVa9bF40Rzk0k2raA4ibPFlpKbjMwqO2jglkstknDlHhsYNvTWsNxtqSxmAfpPaK6dnd qeI5XLPNZZlC+CEeb0HXTz6CF/9c5wUQ/h43bwAAAP//AwBQSwMEFAAGAAgAAAAhAAzEGpLDAAAA KAEAAB4ACAFjdXN0b21YbWwvX3JlbHMvaXRlbTQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACMz8GKwjAQBuD7gu8Q5m5TRRZZmnpZBG8iXfAa0mkbtsmEzCj69oY9 reDB48zwfz/T7G5hVlfM7CkaWFU1KIyOeh9HAz/dfrkFxWJjb2eKaOCODLt28dGccLZSQjz5xKoo kQ1MIulLa3YTBssVJYzlMlAOVsqYR52s+7Uj6nVdf+r834D2yVSH3kA+9CtQ3T3hOzYNg3f4Te4S MMqLCu0uLBTOYT5mKo2qs3lEMeAFw99qUxUTdNvop//aBwAAAP//AwBQSwMEFAAGAAgAAAAhAB8E fJhnAQAAqQMAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAtFPfT8IwEH438X9Y+r51Y4BIGGTyIyHRxCgmvJbuBo1ru7Q3 0Rj/d7vhC0ICRn1q7tr7vu++uw5Gr7LwXsBYoVVCoiAkHiiuM6HWCXlazPwe8SwylbFCK0iI0mQ0 vLwYZLafMWQWtYE5gvRcQrhzPknIezjrxu12mPrXs2nHb4etjn8z7aV+2onjbhy202jc+SCeo1YO xiZkg1j2KbV8A5LZQJeg3GWujWToQrOmOs8Fh4nmlQSFtBWGXcorRy+XsiDDWs+u+gFyux/W0ioj Dlik4EZbnWPAtfwi2AFLQFZ3R7lW6OgWbyUQ+meopXENGhRgm1yKaMSqQrCnOLbbbbCNGz8cYkSX d7ePzdt/EXcu6JFplYw/s/Whmwb88/HLyhQNWsYpFFDP3dIoiOhPChGMtCcrjvsj3PCNYgXVq+xX DguV65Lhpvbjit4zgwrM2O2W0UVjA/22vnW8972GnwAAAP//AwBQSwMEFAAGAAgAAAAhAHQ/OXrC AAAAKAEAAB4ACAFjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMz7GKwzAMBuD94N7BaG+c3FDKEadLKXQ7Sg66GkdJTGPLWGpp 377mpit06CiJ//tRu72FRV0xs6dooKlqUBgdDT5OBn77/WoDisXGwS4U0cAdGbbd50d7xMVKCfHs E6uiRDYwi6RvrdnNGCxXlDCWy0g5WCljnnSy7mwn1F91vdb5vwHdk6kOg4F8GBpQ/T3hOzaNo3e4 I3cJGOVFhXYXFgqnsPxkKo2qt3lCMeAFw9+qqYoJumv103/dAwAA//8DAFBLAwQUAAYACAAAACEA e/MCo8MAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMy54bWwucmVscyCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIzPwYrCMBAG4PuC7xDmblMVFlmaelkEbyJd8BrSaRu2 yYTMKPr2hj2t4MHjzPB/P9PsbmFWV8zsKRpYVTUojI56H0cDP91+uQXFYmNvZ4po4I4Mu3bx0Zxw tlJCPPnEqiiRDUwi6UtrdhMGyxUljOUyUA5WyphHnaz7tSPqdV1/6vzfgPbJVIfeQD70K1DdPeE7 Ng2Dd/hN7hIwyosK7S4sFM5hPmYqjaqzeUQx4AXD32pTFRN02+in/9oHAAAA//8DAFBLAwQUAAYA CAAAACEAKszlHL8BAABRBQAADwAAAHdvcmQvcGVvcGxlLnhtbKSUUW+bMBDH3yftOyC/O8Y0tAGF VNOiTXnYU9sP4BoTrGKfZRtYv/1MgNBtUpU2T8a+u9/9fYdve/9bNVEnrJOgC0RXMYqE5lBKfSzQ 0+MPvEGR80yXrAEtCvQqHLrfff2y7WmaGwGmEVFAaJf3hheo9t7khDheC8XcSkluwUHlVxwUgaqS XJAebEmSmManL2OBC+dCvu9Md8yhCaf+p4EROhgrsIr5sLVHoph9aQ0OdMO8fJaN9K+BHd/OGChQ a3U+IfBZ0BCSj4KmZY6wl+QdQ/bAWyW0P2UkVjRBA2hXS7Nc47O0YKxnSPfeJTrVzH69oevrerC3 rA/LArxEfjkGqWZU/j6Rxhd0ZECcIy6R8HfOWYliUi+JP1WaN8Wl6ccAyb8Ac7yuOT8ttGahyeto B/1yZg0v+wOsqclvr+auE/NQMxNeoOL54ajBsucmKAoti0LVo+G3Rrtp4lgHejjNWetrCI/1F7Ne 6uixBhVMs58VLswxcdAVnLxDqk6Wwh7KAn3bo9NZ68b9A6Y4xQnFNFmnSRpnKb6LN0ma3d7cYZqu byjN4sFMN1maJYjstmQRc94Ms3D3BwAA//8DAFBLAwQUAAYACAAAACEAymMmnQoCAAAEBwAAEgAA AHdvcmQvZm9udFRhYmxlLnhtbMyU326bMBTG7yftHZDvGwwhTROVVGmWSJWmXWztAziOAWvYRj5O aN5+x4Zkf7JoiaZOA4HgO/aH/ePTuX94VXW0Exak0TlJBpREQnOzkbrMycvz6uaOROCY3rDaaJGT vQDyMHv/7r6dFkY7iHC+hqniOamca6ZxDLwSisHANEJjsTBWMYevtowVs1+3zQ03qmFOrmUt3T5O Kb0lvY29xMUUheTig+FbJbQL82MranQ0GirZwMGtvcStNXbTWMMFAO5Z1Z2fYlIfbZLsxEhJbg2Y wg1wM/2KghVOT2h4UvV3g9F1BunRQPHpU6mNZesa4eNKIjQjs55+1E41U1hYsFqurQyFhmkDIsHa jtU5oSld0RHe/ZnRob+T2A/kFbMgvEk3kHZywZSs9wcVWgnQFRrpeHXQd8xKv6iuBLLEwhbWNCdL ike6WpFOSXKSoTBfHJXUfyscSa8Mjwr1Cg8+3YhJmMWDz3EMfjPuCJyQeJZKQPRJtNFno5g+QySl t0hihDw8meFVRGzwvZZIOv+RyAKV8V02PCEy+TORzudyIl9EaUT08nQGxWNAkPUXwnjbcGAW0uWv KJbZ+DQcb4BiYbZWCuvjcYbGGMMwCRw6KtcEQ5mNsL9LRiFfxeZ/i0XfMqKPsqzc2cbh28W/ahxz v2QMx8+NA//J4wmPsPu/bBz9A8y+AQAA//8DAFBLAwQUAAYACAAAACEAf4tDw8AAAAAiAQAAEwAo AGN1c3RvbVhtbC9pdGVtMy54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAjM8/a8NADIfhr2Juz8lpoC3GdoauCRS6dBVnnX2Qk46TUufjty79N3bT8j4/1B9v+dK8UdUk PLi9b11DHGRKPA/uanH36I5jX7pSpVC1RNp8FKxdGdxiVjoADQtlVJ9TqKISzQfJIDGmQHDXtveQ yXBCQ/hV3Bdz0/QDrevq14OXOm/ZHl7Pp5dPe5dYDTnQd1XC/9YTRyloy+Y9wDNWY6pPwlblom7s JwnXTGxnZJxpu2Ds4e+34zsAAAD//wMAUEsDBBQABgAIAAAAIQBpzMfVZQEAAEADAAAYACgAY3Vz dG9tWG1sL2l0ZW1Qcm9wczMueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJSSX0vDMBTF3wW/Q8l7m7Wb3TrWjdU5GCiIKOw1pLdbsElKcmsV8bubdkOc/zafwk1yfufe k0xmz7L0nsBYoVVKwqBHPFBc50JtUvJwv/RHxLPIVM5KrSAlSpPZ9PxskttxzpBZ1AZWCNJzG8Kt q0VKXqMwGsRJlPmLi2XiD8Ks58/jeORfzeNFls2z/jCJ3ojnrJXD2JRsEasxpZZvQTIb6AqUOyy0 kQxdaTZUF4XgsNC8lqCQRr1eTHnt7OValmTa9rNT30FhD8u2tdqIby5ScKOtLjDgWu4NduB8b3PD FNtAZ4gvFVhCTyP/0H/F+KNj7fgSkLXpUe7S8yvj7hsUx/lN0wRNv+Otb65pmCQjqpgE6+hwTFzV puykOadQdlNZGgYh/Y8QwUh7VPFnwkIVumK4baMY0ltmUIG51AqNLk9O+Pe3+8j29Fg/D5hzKdq3 7makX35VWx/8+uk7AAAA//8DAFBLAwQUAAYACAAAACEAeJttP5wAAADzAAAAEwAoAGN1c3RvbVht bC9pdGVtNC54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArIxBCoMw EEX3hd5BcgAjXbiQWhC6loLQVTdJHM1AkgnJCHr7pniFLj//vXfX3URbMpCr3buQO90Lyxw7KbOx 4FWuKUIo30LJKy4zrZKWBQ08yWweAstb07RSo3ZIa1LRHuKM/Sc1gQPDME98OOjFR0WVcWcLMzJS OAMUHAao9+yK8ANH5Qs8vAZRvSHlAvaiFfJxvXwBAAD//wMAUEsDBBQABgAIAAAAIQCegs8J4QAA AFUBAAAYACgAY3VzdG9tWG1sL2l0ZW1Qcm9wczQueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJyQwWrDMAyG74O9g9E9dZrWzVrilLRZoNexwa6uoySG2A62UzbG3n0O O3XHncQnIX0/Ko4feiQ3dF5Zw2G9SoGgkbZVpufw9tokT0B8EKYVozXIwVg4lo8PResPrQjCB+vw ElCT2FCxXmoOX1l+bp4zxpJ8w87Jtmqy5LTd7CPuWVXt1qzO628gUW3iGc9hCGE6UOrlgFr4lZ3Q xGFnnRYhouup7TolsbZy1mgCzdJ0R+Uc9fpdj1AueX63X7Dz97hEm536r+WqrqOyvRPT8Am0LOgf 1cJ3ryh/AAAA//8DAFBLAwQUAAYACAAAACEAkpmY3nAMAACeegAADwAAAHdvcmQvc3R5bGVzLnht bMydW3PbuhHH3zvT78DRU/uQ2PI1yRznjO3Ytae5+ERO8wyRkMWaJFRe4rifvgAISqCWoLjgxj1P tkjujyD+uwssr7/9/jNNgh88L2KRnU2mr/cnAc9CEcXZw9nk2/31qzeToChZFrFEZPxs8syLye/v //qX357eFeVzwotAArLiXRqeTZZluXq3t1eES56y4rVY8UyuXIg8ZaX8mT/spSx/rFavQpGuWBnP 4yQun/cO9vdPJgaTD6GIxSIO+QcRVinPSm2/l/NEEkVWLONV0dCehtCeRB6tchHyopAHnSY1L2Vx tsZMjwAojcNcFGJRvpYHY1qkUdJ8uq//S5MN4BgHOFgD0vDd7UMmcjZPZO/LlgQSNnkvuz8S4Qe+ YFVSFupnfpebn+aX/nMtsrIInt6xIozje7lnCUljybs5z4p4ItdwVpTnRcw6Vy7VP51rwqK0Fl/E UTzZU3ss/itX/mDJ2eTgoFlyqVrQWpaw7KFZxrNX32Z2S6xFc8k9m7D81excGe6ZA6v/Woe72v6l d7xiYaz3wxYll541PdlX0CRWjnxw/Lb58bVSfcuqUpidaED9d43dAz0uHU6636yOArmWLz6K8JFH s1KuOJvofcmF327v8ljk0tPPJm/1PuXCGU/jmziKeGZtmC3jiH9f8uxbwaPN8j+utbeaBaGoMvn/ 4elUe0FSRFc/Q75Svi/XZkxp8lkZJGrrKt7sXJv/p4FNjRJd9kvOVAIIptsI3XwU4kBZFNbRdjOr rWPXW6F2dPhSOzp6qR0dv9SOTl5qR6cvtaM3L7UjjfmVO4qziP+sAxHuBlB3cRzRiOY4gg3NccQS muMIFTTHEQlojsPR0RyHH6M5DjdFcEoRurzQcvZDh7f3c3ePEX7c3UOCH3f3CODH3Z3w/bi787sf d3c69+Puzt5+3N3JGs+tp1rBrQyzrBwdZQshykyUPCj5z/E0lkmWropoeGrQ4znJQRJg6sxmBuLR tJDp37s9RAep/3heqkIuEItgET9UuSymxzacZz94IsvagEWR5BECc15WuaNHfHw65wue8yzklI5N B1WVYJBV6ZzAN1fsgYzFs4i4+xoiSVJYO7Ssn5cqSGICp05ZmIvxTROMLD98jIvxfaUgwUWVJJyI 9ZnGxTRrfG2gMeNLA40ZXxlozPjCwNKMqosMjainDI2owwyNqN9q/6TqN0Mj6jdDI+o3Qxvfb/dx megUb886psPP3V0mQp3HHt2OWfyQMTkBGD/cmHOmwR3L2UPOVstAnZXuxtrHjN3PhYieg3uKMW1N oprXaxe5lEcdZ9X4Dm3RqIJrzSMKrzWPKMDWvPEh9klOk9UE7YamnplV87IzaDVpUNDOWFLVE9rx 0cbK8R62CYDrOC/IwqAbS+DBn9V0VslJkfk2rRzfsA1rfFhtZyXS5hkkQSsTET7SpOGb5xXPZVn2 OJp0LZJEPPGIjjgrc1H7mh3yB1qSQSF/la6WrIh1rdRCDB/qmyvgwSe2Gn1AdwmLMxrdrl6lLE4C uhnEzf2nj8G9WKkyU3UMDfBClKVIyZjmTODfvvP532kaeC6L4OyZ6GjPiU4PadhlTDDI1CQREZHk NDPOYpIxVPP+yZ/nguURDe0u5/VNJyUnIs5YuqonHQSxJfPik8w/BLMhzfsXy2N1XogqqO5JYNZp w6Ka/5uH41PdZxGQnBn6UpX6/KOe6mprOtz4aUILN36KoNWUw4PyX4KDbeHGH2wLR3Wwlwkrith5 CdWbR3W4DY/6eMcXf4YnEpEvqoSuAxsgWQ82QLIuFEmVZgXlEWse4QFrHvXxErqM5hGcktO8f+Rx RCaGhlEpoWFUMmgYlQYaRirA+Dt0LNj423Qs2Ph7dWoY0RTAglH5GenwT3SVx4JR+ZmGUfmZhlH5 mYZR+dnhh4AvFnISTDfEWEgqn7OQdANNVvJ0JXKWPxMhrxL+wAhOkNa0u1ws1NMIIqtv4iZAqnPU CeFku8ZRifydz8mapliU7SI4I8qSRAiic2ubAUdbtu9d22Wmn+QY3YS7hIV8KZKI545jctvKenlW P5ax3XzdjEGnPT/GD8symC3XZ/ttzMn+TsumYG+Z7d5hV5+fNM+zdJl94lFcpU1D4cMUJ4fDjbVH t4yPdhtvZhIty+OBlnCfJ7stN7PkluXpQEu4zzcDLXWctiz74uEDyx87HeG0z3/WNZ7D+U77vGht 3LnbPkdaW3a54GmfF7VCJTgPQ3W1AKozLGbc9sOCx22PiSI3BRNObsrguHIj+gLsK/8Rq5EdkzT1 /tZ3T4C8ryfRgzLnH5Woz9u3LjgNf6jrVk6csoIHnZzD4ReuWlnG3Y+D040bMTjvuBGDE5AbMSgT Oc1RKclNGZyb3IjBScqNQGcrOCLgshW0x2UraO+TrSDFJ1uNmAW4EYOnA24EOlAhAh2oI2YKbgQq UIG5V6BCCjpQIQIdqBCBDlQ4AcMFKrTHBSq09wlUSPEJVEhBBypEoAMVItCBChHoQIUIdKB6zu2d 5l6BCinoQIUIdKBCBDpQ9XxxRKBCe1ygQnufQIUUn0CFFHSgQgQ6UCECHagQgQ5UiEAHKkSgAhWY ewUqpKADFSLQgQoR6ECtHzX0D1RojwtUaO8TqJDiE6iQgg5UiEAHKkSgAxUi0IEKEehAhQhUoAJz r0CFFHSgQgQ6UCECHaj6YuGIQIX2uECF9j6BCik+gQop6ECFCHSgQgQ6UCECHagQgQ5UiEAFKjD3 ClRIQQcqRKADFSL6/NNconTdZj/Fn/V03rE//NKVadRX+1FuG3U4HNW0ys0a/izChRCPQeeDh4e6 3hgGiedJLPQpasdldZurb4lAXfj8ctn/hI9NH/nSJfMshL5mCuBHQy3BOZWjPpe3LUGRd9Tn6bYl mHUe9WVf2xIMg0d9SVfHZXNTihyOgHFfmrGMpw7zvmxtmcMu7svRliHs4b7MbBnCDu7Lx5bhcaCS 87b18cB+OlnfXwoIfe5oEU7dhD63hFo16RgGxlDR3ISh6rkJQ2V0E1B6OjF4Yd0otMJulJ/UMMyw UvsHqpuAlRoSvKQGGH+pIcpbaojykxomRqzUkICV2j85uwleUgOMv9QQ5S01RPlJDYcyrNSQgJUa ErBSjxyQnRh/qSHKW2qI8pMaTu6wUkMCVmpIwEoNCV5SA4y/1BDlLTVE+UkNqmS01JCAlRoSsFJD gpfUAOMvNUR5Sw1RfVLrsygtqVEKW+a4SZhliBuQLUNccrYMPaoly9qzWrIIntUS1KrRHFct2aK5 CUPVcxOGyugmoPR0YvDCulFohd0oP6lx1VKX1P6B6iZgpcZVS06pcdVSr9S4aqlXaly15JYaVy11 SY2rlrqk9k/OboKX1LhqqVdqXLXUKzWuWnJLjauWuqTGVUtdUuOqpS6pRw7IToy/1LhqqVdqXLXk lhpXLXVJjauWuqTGVUtdUuOqJafUuGqpV2pctdQrNa5ackuNq5a6pMZVS11S46qlLqlx1ZJTaly1 1Cs1rlrqldpRLe09tT7ApNj6g2Ry4/J5xdU7uK0HZqL6HaTmIqDe8DZafyhJGauWBOaTVGaxbrC5 YKj/zwtZ1Zlt9vevj/dPDy7qrVyfnNIdaH1RSu8ZtjVcysaG5vVLjraa16iunwPSL1HdbrnjXau6 jZs+bLY2mmyupdbbta6b1u13tLtUmvW0WWva28m17K4GvjV+vKuFsj3zpJZA/nObKZWezBev6pZG P1mNkusveZJ8YvXWYuXeNOGLsl473ddP3W+tn9cvkHPa5zrTOAF77cbUP/v9pH6lvLkE7vRpFU4d 3a3vxxjb0wN9eN2azRsXtxu0WVN3JpM7+KJygu3IbW8f7SXtAD4/Oby6MlfWzQfzQpV8NlvIIL82 e20Wqpcr1w5rfY0O1SWXIlVvbdzcuLHdM52fN/gTddLmG39TM1ra3/irl+3unFZ+3u4c/Vx5T7/o Txd0dYmdupVzNcst7qVU5Vf2EhgLzAcHj9ZfH+z+4GBH/x6YAbj1DcVmTME4X1gVMlXpoXI7X2z3 zHavm/X1a2I3fTfYFR0qIBVAOOWYTut1ypl5aWCPXzbvFezqInDwmepR18qObjP7/9X+azp0Xh/D ZfErvM0+FJfDmW3cPtcZ0+5+o/Y4u4N+rf+ZN4h0JsXW20W6esmVES3onz4jtr9jezaZ8QfBg2+3 ylx/o7a9KCys31vqTE1x1Rqy9DI6J9/u2j7NxqZU2zeIHfz/1OvNf8X7/wEAAP//AwBQSwMEFAAG AAgAAAAhAF57xkp9AQAAkgMAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbJSTb0/CMBDG35v4HZa+ hw0UxIVBQgjGxBij+AG6rhuNba9pCxM+vbeNf4ov2Kten7vn17vcNp5+KxlsuHUCdEJ63YgEXDPI hC4S8rlcdEYkcJ7qjErQPCFb7sh0cnszLuOSpx/ce6x0AVK0ixVLyMp7E4ehYyuuqOuC4RqTOVhF PV5tESpqv9amw0AZ6kUqpPDbsB9FQ7LH2GsokOeC8TmwteLa1/7QcolE0G4ljDvQymtoJdjMWGDc OZxHyYanqNBHTO/+AqQEs+Ag910cZt9RjUJ7L6ojJU+AQTtA/whQLH4uNFiaSlwBdhIgjExwB5nY uP0ZlLHIcIWj6O5hOOg/DuuCFLLtvE5uqMQsCSsVV/DCc39Qo6P6LorVP/ISzKU4A+9B/dGxkVlm q8ifPBo/HYIXt6vqqsBQxvcxAwm4cbr20CDkWWftnOmvjtp57fnkbazhaegmPJz1YsB4ocSOL8DO LJSO2/o1KiWUb69Pjf/sT5r8AAAA//8DAFBLAwQUAAYACAAAACEAci5T2vgBAADwBwAAGQAAAHdv cmQvY29tbWVudHNFeHRlbmRlZC54bWykldtuozAQhu9X2ndAvk+wzSEOKqkSwFWut/sALpCAig+y SdK+fU3Ou5WiuLkyYP/f/DNjm6fnD95521qbVooUoDEEXi1KWbVinYK/r3REgGd6JirWSVGn4LM2 4Hn2+9fTDkVJKTmvRW+KD89ihEl2qkxB0/cq8X1TNjVnZszbUksjV/3YLvflatWWtb+TuvIxRHD/ pLQsa2NszIyJLTPgiOPfaVLVwk6upOast6967XOm3zdqZOmK9e1b27X9p2XD+ISRKdhokRwRo7Oh QZIcDB2Hk0LfE/cgyWW5GYqwj+jrurMepDBNqy5p/JRmJ5sTZHsriS3vTut2CoWP9SDXbGeHC/Ae +9VBxLuD89tEBO/oyIA4K+6x8G/MkxPOWnEJ/KPSXBUXRW4A/D9ArR9rzouWG3WhtY/RluL9zBpO twPr2OTr1MxjZv40TNkTyMtkuRZSs7fOOrIt82zVvWFbg9n1rWMvneFNMc2WVQoiTGiY0TnYf632 lxUE/k1JQQilC+QgCUkWQxgQB0lMYRDgbOEiIRmcxPHEQRLMySIISOaSC8qnFOHIxRiCYYGRS/oo iPEcZaGLsWkRTifD/e1gjGBbAKdcCA6iReYSBVMSzvOcuqQPIYW0cOk+zgoc5YVLK+0Om1Iaf9/J /pXG/qZnXwAAAP//AwBQSwMEFAAGAAgAAAAhAFpTvoz7BAAALhkAABMAKABjdXN0b21YbWwvaXRl bTEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALxZW2/iOBh9X2n/ Q5R9LkkgdACVjgq0UqXpbrVFq30bOY4D3iZ2ajsF/v18zo0QoECCduahje1zvvtlNHff11FofBIh KWdj0+nYpkEY5j5li7GZqOBmYH6/v8NqhDlThKn5JiZveEkiZMDhz7FpGhEqf1Ye/YkiMjZnHCcR nNRvn2dj017bDvy1ncnD5GnmPLmDwfTRcafww+49Pk3cgdt9fHAndew/hbZ2/WZGJBY0VuntVBCk iIEMRlaGn+vRqUPeMI9Jrn3uBq2bF9jd3hD1HNsdkMD1yHDgIh8Nh/aQoH7fNw3wG5MjrMbmUql4 ZFky9YrsRBQLLnmgOphHFg8CionVte1bKyIKOBSyKvILogg1IYoFaC8UJTI9e1BKUC9RRJr3v/92 t5b+KCMzFBILonRMZIwwaScrdZbgHGxXIiHpZ0BJ6Evtul7f7vm9/iDwhr4zdG17CFH2urf94W3w zSVOYTFoV6qxWq06q16Hi4UW6lj/vvzIkmz7+Py3cUvrCteRkOiUMViayQceAFkckrUOY+lu8pFA /ZTfuxxFFr4ghhbpxVdcKAwt/bt14D49y8nL76rw80Gpjy5MF3AFA2cHXERIyTQW8O4djNrLdEFu qpmTi38C5IwEKAkhiT4SFFJIIKgqVGTwzoOEVZ54Icfv5dUf4KU88FfUslGG0tOPbyiTCkGICpSP S1CciDCF+NjKvSQtp+NY27eKiGhrZhWQ3pQvOSTaiSKg0IEEQ6HFPb9MQhrFXGTJuhv3L3TL6H9w jLK2myP8xAsp045NcbkSFugnrQ9gAb/0LNu17C5wdkC4meb62VoUBl9DfMq1q8Nu3Wqe10p6qI2e GdP5z9pFCa8UXk6x/7hS5nWpggTQLPAI6xHGBTRYyv7COBEyH3rr4svZVzkHp0ZlDLpqGjCMqA9f uuou1KBwWmXIfQHPvZl2Hyh+tkjnCWU+WRcj3qcyDtEmWymmGa+REh/VXVEVnpC7leLuS5mn+KP0 MvH+I1ivNQ386m/XlCaOfSebFRe+HsOXePWoOiFiiwSaYqMgQ3YtuNi01SVjyxew65AJ8kkbsJVl yRhXaVMpTorpXRwaR/7Ml1QanyhMiAH5RbWLpKGW0AmSyCPC4IEh0SeccWEUSsoOwGBZjeNQA+DE ABIBDRDuqBcSA6aYkcQwrkBJYCtFoAAq3SAIL0uyzmHdsnlftyI73bW2vijsOzdEUr3AvxL0SJ60 jv5Oy4py2hY95w1MSRrVR+aMrCMfXaGqK1OrBZuygMdILfU4+ma9IqEYEbq/CR5eZVfKF+JTy8B5 6lywiee+2Q3OK1Q3lGN+t7fw1nbn3eSI8Wi2bc+1yN7rsOzm6x76AWOeMPVcT6sLsAcm2R5af9bW 8AMpdERe5qYdO4ssLbvTSXjF0MbgzNLL4ZPZ9EFKjqneOR5hd1CbxuEGrpzheBknzAN1fcj0k4GA z7JeShmZgLJoc5by3Rm4syFvG6lI9Jyv/xdBC5dCcz6GOyvNtsxZtOrWHwn4cQXrNE0ZDvimIVPd VWfS7GVxy9zN4O0aVsZROOVvEhChJTZn8vXK2xTbbYHttcDqzbwptv8/NOsDkb68bR4NdWMqHevm 4G4bcK8N2G0D7jcBz/XO2bjQNfoZtqbrzKgG+Vcq0MaChh0qlX1yn7qSkU1rq1DyJDLVs1zsrUP/ 43H/CwAA//8DAFBLAQItABQABgAIAAAAIQBFjx8opQEAAEIJAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJlVfgX+AAAA4QIAAAsAAAAAAAAAAAAA AAAA3gMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAN3CLG3FAQAA+w8AABwAAAAAAAAAAAAA AAAADQcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAVTysD+Q1 AAAFAgUAEQAAAAAAAAAAAAAAAAAUCgAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEA LmgozJwKAADsMQAAEQAAAAAAAAAAAAAAAAAnQAAAd29yZC9jb21tZW50cy54bWxQSwECLQAUAAYA CAAAACEAqlIl3yMGAACLGgAAFQAAAAAAAAAAAAAAAADySgAAd29yZC90aGVtZS90aGVtZTEueG1s UEsBAi0AFAAGAAgAAAAhAKQDCB3oAwAAYQoAABEAAAAAAAAAAAAAAAAASFEAAHdvcmQvc2V0dGlu Z3MueG1sUEsBAi0AFAAGAAgAAAAhAFyWJyLCAAAAKAEAAB4AAAAAAAAAAAAAAAAAX1UAAGN1c3Rv bVhtbC9fcmVscy9pdGVtMi54bWwucmVsc1BLAQItABQABgAIAAAAIQDRTi8odAEAAPMCAAARAAAA AAAAAAAAAAAAAGVXAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQBwQj744wEAAOQD AAAQAAAAAAAAAAAAAAAAABBaAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhAAbnD5MN AQAAkgEAABMAAAAAAAAAAAAAAAAAKV0AAGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAA ACEAJuBZlPMAAABPAQAAGAAAAAAAAAAAAAAAAABvXwAAY3VzdG9tWG1sL2l0ZW1Qcm9wczIueG1s UEsBAi0AFAAGAAgAAAAhAL2EYiOQAAAA2wAAABMAAAAAAAAAAAAAAAAAwGAAAGN1c3RvbVhtbC9p dGVtMi54bWxQSwECLQAUAAYACAAAACEADMQaksMAAAAoAQAAHgAAAAAAAAAAAAAAAACpYQAAY3Vz dG9tWG1sL19yZWxzL2l0ZW00LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAB8EfJhnAQAAqQMAABgA AAAAAAAAAAAAAAAAsGMAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAIAAAAIQB0 Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAAHVlAABjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJl bHNQSwECLQAUAAYACAAAACEAe/MCo8MAAAAoAQAAHgAAAAAAAAAAAAAAAAB7ZwAAY3VzdG9tWG1s L19yZWxzL2l0ZW0zLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhACrM5Ry/AQAAUQUAAA8AAAAAAAAA AAAAAAAAgmkAAHdvcmQvcGVvcGxlLnhtbFBLAQItABQABgAIAAAAIQDKYyadCgIAAAQHAAASAAAA AAAAAAAAAAAAAG5rAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAf4tDw8AAAAAi AQAAEwAAAAAAAAAAAAAAAACobQAAY3VzdG9tWG1sL2l0ZW0zLnhtbFBLAQItABQABgAIAAAAIQBp zMfVZQEAAEADAAAYAAAAAAAAAAAAAAAAAMFuAABjdXN0b21YbWwvaXRlbVByb3BzMy54bWxQSwEC LQAUAAYACAAAACEAeJttP5wAAADzAAAAEwAAAAAAAAAAAAAAAACEcAAAY3VzdG9tWG1sL2l0ZW00 LnhtbFBLAQItABQABgAIAAAAIQCegs8J4QAAAFUBAAAYAAAAAAAAAAAAAAAAAHlxAABjdXN0b21Y bWwvaXRlbVByb3BzNC54bWxQSwECLQAUAAYACAAAACEAkpmY3nAMAACeegAADwAAAAAAAAAAAAAA AAC4cgAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAF57xkp9AQAAkgMAABQAAAAAAAAA AAAAAAAAVX8AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHIuU9r4AQAA8AcA ABkAAAAAAAAAAAAAAAAABIEAAHdvcmQvY29tbWVudHNFeHRlbmRlZC54bWxQSwECLQAUAAYACAAA ACEAWlO+jPsEAAAuGQAAEwAAAAAAAAAAAAAAAAAzgwAAY3VzdG9tWG1sL2l0ZW0xLnhtbFBLBQYA AAAAGwAbABEHAACHiAAAAAA= --089e013c63e87d310704de7eff5a-- From pkyzivat@alum.mit.edu Thu Jun 6 09:45:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9221F9A06 for ; Thu, 6 Jun 2013 09:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i81VNqnsmOKy for ; Thu, 6 Jun 2013 09:45:31 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id A851421F9640 for ; Thu, 6 Jun 2013 09:45:30 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id kzyC1l0050Fqzac564lVqN; Thu, 06 Jun 2013 16:45:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id l4lV1l00i3ZTu2S3U4lVDR; Thu, 06 Jun 2013 16:45:29 +0000 Message-ID: <51B0BCA8.6050304@alum.mit.edu> Date: Thu, 06 Jun 2013 12:45:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370537129; bh=lYX5hXluIRNdHXIVTBgQzrUlhprT2Qbe2fwf3uSJRUc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bLZMdrRvHJpHWaL2b75yJ8wnTOgmaCHvmTAa9LzaE9Nsm16dxcuhiSqlCrKzMVYdW zxT/CES43GiEARxaZqNEwnpv3FOnUq+XZ88xocXZh0PL+RgJDkHsAnwt+np+TInrFx JtbXtUttHL1kS/gWYdjK6ycQrMiA8lm0ivjU6xImrazPgVHJT3qIT8XO0cpMEQ9AkQ kQCIb90cx2sOAZUOKFGA8mu6dW3HZ3bDGym4H1j7J6RdIALx5a2F7SL/TiB35RyhmE +5ogJjPkZTltugGNiD+NntISjrVikXJXD58RITySUnEDPEpeozV4o7/koDTiWjhoN3 hv5X+ClJcUG+A== Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 16:45:36 -0000 Hi Christer, I'm still finding problems when I read this, in spite of all the discussions. It feels to me like the problem is that the distinction between BRO and BSO isn't quite right, and it isn't just the names. Clearly there are a couple of different kinds of things. While reading and writing this I've been trying to figure out exactly what the problem is and how to fix it. First, I'll comment inline where I see issues. Then at the end I'll suggest something that might help. On 6/6/13 7:17 AM, Christer Holmberg wrote: > Ok folks, > > Below is some Offerer text for BUNDLE. I’ve also included some examples. > > As we have discussed, Bundle Sync Offer may not be good terminology, but > again I’d like to focus more on the technical content, and the > “understandability” of the text, for now :) > > Also note that the text currently assumes that a port zero m= line > CANNOT be inside a BUNDLE group. That may change (depending on how we > move forward with the plans etc), but > > should not have a huge impact on the text, apart from the section > talking about disabling an “m=” line in a BUNDLE group. > > Also, the definition of “bundle address” WILL be defined, but it’s more > or less the IP port, address and ICE information associated with the > transport plane. > > Happy reading! > > Regards, > > Christer > > ---------------------------------- > > 6.2. SDP Offerer Procedures > > 6.2.1. General > > This section describes how an Offerer creates an SDP Offer which > > includes a BUNDLE group. > > An SDP Offer that includes a BUNDLE group can be categorized either > > as a Bundle Restart Offer (BRO) Section 6.2.2.1 or as a Bundle Sync > > Offer (BSO) Section 6.2.2.2. > > 6.2.2. SDP Offer Types > > 6.2.2.1. Bundle Restart Offer (BRO) > > A Bundle Restart Offer (BRO) is used to negotiate (or re-negotiate) > > the usage of the BUNDLE mechanism, and/or the bundle address used by > > the "m=" lines in a BUNDLE group. > > In a BRO, the Offerer assigns a unique address to at least one "m=" > > line in a BUNDLE group. Such "m=" lines can be removed from the > > BUNDLE group by the Answerer (see [xxx]), as the unique address can > > be used outside the BUNDLE group. > > In a BRO, the Offerer assigns, for each "m=" line in the BUNDLE > > group, either a unique address, or a previously negotiated bundle > > address, as long as a unique address is assigned to at least one "m=" > > line in the BUNDLE group (if the bundle address is assigned to each > > "m=" line in the BUNDLE group, the SDP Offer is by definition a > > Bundle Sync Offer (BSO) Section 6.2.2.2. The above excludes the possibility of both proposing to change the previously negotiated bundle address and add a new m-line with a unique address. > > When a session is initiated, if the Offerer does not know whether the > > Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a > > BRO, and the Offerer MUST assign a unique address to each "m=" line > > in the BUNDLE group. The MUST above bothers me. I could go with SHOULD. IOW, even if the offerer doesn't know whether the answerer supports bundle, it could take a chance, on the assumption that the odds are good that it will be successful. Then it can deal with the consequences if the answer indicates that bundle wasn't supported. > If, in the SDP Answer associated with the BRO, the offered BUNDLE > > group is accepted [ref-to-be-added], the Offerer MUST, for each "m=" > > line in the BUNDLE group, start to use its local bundle address, and > > the remote bundle address, both selected by the Answerer [ref-to-be- > > added]. In addition, the Offerer MUST send a Bundle Sync Offer (BSO) > > Section 6.2.2.2, in which the bundle address is assigned to each "m=" > > line in the BUNDLE group. In some cases things could be done with one O/A rather than two, and whether a 2nd one is needed may depend on what was in the answer. What is proposed seems to *require* two O/As when bundling is used. [snip] > 6.2.2.2. Bundle Sync Offer (BSO) > > A Bundle Sync Offer (BSO) is used when the Offerer does not want to > > re-negotiate the usage of the BUNDLE mechanism, and/or the bundle > > address. The Offerer can, using a BSO, re-negotiate other parameters > > associated with the BUNDLE group, however. If all I want to do is change the bundle address, I should be able to send an offer that does that. And after the answer all is done. I shouldn't be required to offer unique addresses for each (or any) m-line in the bundle to do this. > In a BSO, the Offerer MUST assign the bundle address to each "m=" > > line in a BUNDLE group. Such "m=" lines can not be removed from the > > BUNDLE group by the Answerer [ref-to-be-added], as the bundle address > > can not be used outside the BUNDLE group. Some of the m-lines in the bundle can be rejected (port zero), and then be removed from the bundle. And if there is then only one m-line left in the bundle, then I guess it can either be left in the bundle or else the bundle can be removed. [snip] > 6.2.3. Use Cases > > 6.2.3.1. Offerer Bundle Address Request > > In order to negotiate (or re-negotiate) the bundle address, the > > Offerer MUST send a BRO. In the BRO, as the Offerer assigns a unique > > address to some (or all) "m=" lines in the BUNDLE group, the Offerer > > needs to indicate to the Answerer which address, associated with one > > of the "m=" lines in the BUNDLE group, it wishes to use as its local > > bundle address. The first mid value in the SDP group:BUNDLE > > attribute mid value list represents the "m=" line address with the > > highest preference. Again, you say a BRO MUST be used to to change the bundle address. But the key defining feature of a BRO over a BSO is that it has at least one m-line with a unique address. This doesn't suit the case well. But I can't use a BSO for this, because, by your definition it must have the previously negotiated bundle address. [snip] ISTM that all bundle offers must meet some constraints: - some of the m-lines may have *unique* addresses - all the rest, if any, must have a single *common* address. - if any share a common address, then the first mid in the bundle group must identify one of them All answers to a bundle offer must also meet some constraints: - all the standard grouping constraints on answers - all m-lines in the bundle in the answer must have a single common address. - m-lines bundled in the offer but unbundled in the answer must have either a zero port or a unique address in the answer. (Unique from each other and from the common address of the lines bundled in the answer.) - An m-line that had a common address in the offer may only be removed from the bundle in the answer if: - it is given a zero port in the answer - all the other m-lines that had the same common address in the offer have been given a zero port in the answer Then, a bundle offer where *all* the addresses are common is "stable". (It doesn't need to be "fixed up".) Maybe we can call that a BSO. :-) That distinction is independent of whether it is used to initially establish a bundle, to change the address of a bundle, add or remove m-lines, etc. A bundle offer that meets the general constraints but isn't a BSO is an "unstable" bundle offer, in that it will (probably) need to be followed up with another, stable, bundle offer. One open issue I have here is that I think some answers might eliminate the need for an unstable bundle offer to be followed up by a stable offer. (IOW, the answer may stabilize an unstable offer.) Some examples where I think this may be so: - if the bundling is entirely rejected, (no bundle group in answer), then no stable bundle offer is required - if the offer would be stable if it only contained the m-lines in the answer bundle group, then a stable bundle offer *may* not be required. (IOW the answer removed everything from the bundle that made it unstable.) This needs further discussion. So the bottom line is that you can do whatever you want (add, remove, reject m-lines, move them out of bundles, change addresses, etc.) in an offer or answer if and only if you meet the stated constraints for an offer or answer. So the focus becomes one of making certain the constraints are specified precisely and clearly. Thanks, Paul From pkyzivat@alum.mit.edu Thu Jun 6 10:24:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD5621F99D5 for ; Thu, 6 Jun 2013 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkA0FZYU5aLT for ; Thu, 6 Jun 2013 10:24:22 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id CECD621F99F0 for ; Thu, 6 Jun 2013 10:24:08 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id kzgG1l0020cZkys5C5Pqu8; Thu, 06 Jun 2013 17:23:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id l5Pq1l0063ZTu2S3W5Pqrf; Thu, 06 Jun 2013 17:23:50 +0000 Message-ID: <51B0C5A5.7080506@alum.mit.edu> Date: Thu, 06 Jun 2013 13:23:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370539430; bh=7F2Ch7LZnOiW97Vzrz5IOHN8P5yIvFDIq28BWkpoVd8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GXl75Etv24KT5XjQ0Oc4rIzZ9FEu3KsvMhZDEve9deBhnwx/bwEnMSfDKqpO3GdkP lKRTK2sF3swZMJBH8oXaWwEoq4xBtEh7gUGLUPrhwt3WIQvQfZp27oFnUH0I39ozxb P8jCu5X8gZRbMXE/lvg6wFyaeUTvBgfwouKrtxt3p+U0e7A6PDU//WpH7UgL6P9xKo i3NMqUIa5F9Y5sc1R/XYGK2/SjtByE138nqXgsM5IsLCpftUA4WDP7oQATdYvTflAi lE/CXvpTi4RhmaXmN/rsJMaKUDL9CeahWaidQjbhXvxtAnJMs02nQFVjyfLd2FPfo6 A/30qlaACEipw== Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 17:24:27 -0000 Hi Martin, I see we had some of the same issues, but I think we have formed different ideas of how the proposal was intended to work and how to improve it. My conclusion is that trying to characterize full offers into different types and impose rules on them breaks down, and that it is better to impose constraints that must apply. I sketched out some proposed constraints in my reply. But if that approach seems acceptable then those need some refinement. For instance, in general the constraints don't apply to an entire offer or answer, but instead apply to a set of m-lines in a bundle group. (If there is more than one bundle group then each can be considered separately.) But some of the constraints are global - e.g. uniqueness. Thanks, Paul On 6/6/13 12:42 PM, Martin Thomson wrote: > Nice work. I had too many comments to do an email reply properly, so > I've done the whole nasty Word doc thing. > > The only big item is that I think that you need to more tightly > control the conditions for a BSO - in most cases, you could label > those BSO as BRO without causing any problems. Given that limitation, > you could probably eliminate the BRO/BSO labels, which might help with > readability a little. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Thu Jun 6 11:17:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E287421F9294 for ; Thu, 6 Jun 2013 11:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFTL-uAwUdfb for ; Thu, 6 Jun 2013 11:17:06 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88521F9289 for ; Thu, 6 Jun 2013 11:17:05 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so2396602wgh.30 for ; Thu, 06 Jun 2013 11:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NSWGiGWZT2/AS16DMRxkaaZtGnBeWtXy/a0oWiN0Now=; b=ODQcSrEeklD90w1e+11p29YQtAR2zl1bc1kaxcsv+sFf4OryJcvOqIMQJ0lFsd4Xl2 W+6hVMgQ2NgsD9uZ1WOufYxeutrjEJXgfbTy7TIKi6F/SFPt8NBCoTzLrv/JnmECF9+o ynLOGyWLxOtlYvyd1CWefgeqZ36osL3oKpwGL4ExjwygX2jrAL8G+E+mx8fy+466peN1 Ug1cUcjE4Yab8rjL9s3M+ys23uVe0UkWp+g7RXAVBXoiWgItZcsMELBZdsf3o35dKlAF SPqnUv6Uizx50AeqCDWlonXn9rfxxjcf/8pjMzf790LZ+z/wZmswo8qauIhE1iWK1Yqy Aq9A== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr10846794wix.14.1370542625136; Thu, 06 Jun 2013 11:17:05 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Thu, 6 Jun 2013 11:17:05 -0700 (PDT) In-Reply-To: <51B0C5A5.7080506@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0C5A5.7080506@alum.mit.edu> Date: Thu, 6 Jun 2013 11:17:05 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 18:17:07 -0000 On 6 June 2013 10:23, Paul Kyzivat wrote: > I see we had some of the same issues, but I think we have formed different > ideas of how the proposal was intended to work and how to improve it. I'm not sure that we differ in conclusions, just in our approach :) Your constraints look good and are (to my eye) exactly what I sketched out. From bernard_aboba@hotmail.com Thu Jun 6 12:31:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F64821F947C for ; Thu, 6 Jun 2013 12:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8pe-maWWr8k for ; Thu, 6 Jun 2013 12:31:40 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id 05CC521F93F8 for ; Thu, 6 Jun 2013 12:31:39 -0700 (PDT) Received: from BLU169-W60 ([65.55.116.72]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jun 2013 12:31:40 -0700 X-TMN: [xZMKq0xKbT8ga6v1sz670sBA4UvxU+B+] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_5457cab5-e4e8-4998-98a7-d4399ebf3eaa_" From: Bernard Aboba To: Cullen Jennings Date: Thu, 6 Jun 2013 12:31:39 -0700 Importance: Normal In-Reply-To: <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> , <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2013 19:31:40.0187 (UTC) FILETIME=[77CA3EB0:01CE62EC] Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2013 19:31:48 -0000 --_5457cab5-e4e8-4998-98a7-d4399ebf3eaa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In a highly congested environment=2C signaling will also be likely to be di= srupted. Therefore if signaling is necessary for a sender to reduce the s= ending rate (e.g. for example=2C in order to reduce resolution or framerate= )=2C then that rate reduction would itself be disrupted by congestion=2C pr= eventing the sender from reducing rate=2C and thereby potentially resulting= in congestive collapse.=20 =20 The solution to this=2C which has been widely implemented=2C is to enable r= ate reductions (such as removal of simulcast or layered streams) without a = dependency on signaling. This is possible because the initial O/A exchange= focuses on negotiating the *envelope* of acceptable resolutions=2C frame r= ates=2C streams=2C etc. rather than attempting to control what is actually = being sent in realtime. As a result=2C the sender can reduce rate very qui= ckly by dropping streams=2C with no signaling dependency. =20 It would appear to me that both Plan A and Plan B use signaling not just to= control the envelope of acceptable configurations=2C but to determine what= is actually being sent at a given moment. If an O/A exchange is required= for a sender to drop a stream=2C rapid adaptation (including congestion co= ntrol) is hampered.=20 =20 =20 =20 > Subject: Congestion controll=20 > From: fluffy@iii.ca > Date: Thu=2C 6 Jun 2013 12:46:20 +0700 > CC: fandreas@cisco.com=3B ari.keranen@ericsson.com=3B mmusic@ietf.org > To: bernard_aboba@hotmail.com >=20 >=20 > On Jun 5=2C 2013=2C at 9:41 AM=2C Bernard Aboba wrote: >=20 > > As they stand=2C both Plan A nor Plan B result in O/A exchanges that ar= en't needed and will break congestion control >=20 > Bernard - that's a pretty strong statement. Uh=2C you want to explain how= either plan A or B break congestion control? >=20 >=20 = --_5457cab5-e4e8-4998-98a7-d4399ebf3eaa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In a highly congested environmen= t=2C signaling will also be likely to be disrupted. =3B =3B Therefo= re if signaling is necessary for a =3Bsender to reduce the sending rate= (e.g. for example=2C in order to reduce resolution or framerate)=2C then t= hat rate reduction =3Bwould itself be disrupted by congestion=2C preven= ting the sender from reducing rate=2C and thereby potentially resulting in = congestive collapse.
 =3B
The solution to this=2C which has been= widely implemented=2C is to enable rate reductions (such as removal of sim= ulcast or layered streams) without a dependency on signaling. =3B This = is possible because the initial O/A exchange focuses on negotiating the *en= velope* of acceptable resolutions=2C frame rates=2C streams=2C etc. rather = than =3Battempting to control what is actually being sent in realtime.&= nbsp=3B As a result=2C the sender can reduce rate very quickly by dropping = streams=2C with no signaling dependency.
 =3B
It would appear to = me that both Plan A and Plan B use signaling not just to control the envelo= pe of acceptable configurations=2C but to determine what is actually being = sent at a given moment. =3B =3B If an O/A exchange is required for = a sender to drop a stream=2C rapid adaptation (including congestion control= ) is hampered.
 =3B
 =3B

 =3B
>=3B Subj= ect: Congestion controll
>=3B From: fluffy@iii.ca
>=3B Date: Thu= =2C 6 Jun 2013 12:46:20 +0700
>=3B CC: fandreas@cisco.com=3B ari.keran= en@ericsson.com=3B mmusic@ietf.org
>=3B To: bernard_aboba@hotmail.com<= br>>=3B
>=3B
>=3B On Jun 5=2C 2013=2C at 9:41 AM=2C Bernard A= boba <=3Bbernard_aboba@hotmail.com>=3B wrote:
>=3B
>=3B >= =3B As they stand=2C both Plan A nor Plan B result in O/A exchanges that ar= en't needed and will break congestion control
>=3B
>=3B Bernard = - that's a pretty strong statement. Uh=2C you want to explain how either pl= an A or B break congestion control?
>=3B
>=3B
=
= --_5457cab5-e4e8-4998-98a7-d4399ebf3eaa_-- From prvs=68700c9eae=christer.holmberg@ericsson.com Thu Jun 6 22:40:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AAA21F8FAF for ; Thu, 6 Jun 2013 22:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfNsBbeEV-mG for ; Thu, 6 Jun 2013 22:40:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DC21121F8F85 for ; Thu, 6 Jun 2013 22:40:25 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-76-51b17245d664 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5E.B5.18006.54271B15; Fri, 7 Jun 2013 07:40:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 07:40:21 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHVX0AAAFy5IAAAdw+gAAb9ZEA Date: Fri, 7 Jun 2013 05:40:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C384A81@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0C5A5.7080506@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvra5b0cZAg92TWCyunfnHaDF1+WMW ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7itklKLCkLzkzP07dL4M54dPYZa8Eh9opzX44y NzBOY+ti5OSQEDCRuHfwLjOELSZx4d56oDgXh5DAYUaJLV/aGSGcxYwSb880MHUxcnCwCVhI dP/TBmkQEQiVaLu4jxEkzCygLnF1cRBIWFjAQWLLhkmsECWOEgd+bWGDsN0kXi7+DGazCKhI vFg0mxHE5hXwlehZdYodYtVfRonma7/BEpwCgRJLLu8HsxmBjvt+ag0TiM0sIC5x68l8Joij BSSW7DkP9YCoxMvH/1hB7pEQUJRY3i8HUa4ncWPqFDYIW1ti2cLXzBB7BSVOznzCMoFRbBaS qbOQtMxC0jILScsCRpZVjOy5iZk56eVGmxiBcXNwy2/VHYx3zokcYpTmYFES59XjXRwoJJCe WJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MJZkfs265BfKLaKXtaC7XirDJ/Fj9y+dv6q2nxe/ nXffYeq59Itn9ewFAlQPeTMJ3PLg2CKQEK/V/V7JvvRujgEDU5XVxUVndzRn3Ps4YekmRcef Ie6zdPxZBFyjRGcWS4hZX1a3kzB8ftwl3HVuXQvLk9WHFz9bO3XzkjeX5blb7/Pp2HzqUWIp zkg01GIuKk4EAGavwhhuAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 05:40:31 -0000 Hi Martin & Paul, Thank You very much for your detailed review! I will go through your commen= ts, and suggestions, reply and try to come up with modified text. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Martin Thomson Sent: 6. kes=E4kuuta 2013 21:17 To: Paul Kyzivat Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) On 6 June 2013 10:23, Paul Kyzivat wrote: > I see we had some of the same issues, but I think we have formed=20 > different ideas of how the proposal was intended to work and how to impro= ve it. I'm not sure that we differ in conclusions, just in our approach :) Your co= nstraints look good and are (to my eye) exactly what I sketched out. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=5870ac8b49=magnus.westerlund@ericsson.com Fri Jun 7 02:35:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC27021F9648; Fri, 7 Jun 2013 02:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8FLhUvFF6Sf; Fri, 7 Jun 2013 02:35:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 272E321F9371; Fri, 7 Jun 2013 02:35:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-94-51b1a958c107 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DE.D5.15700.859A1B15; Fri, 7 Jun 2013 11:35:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Jun 2013 11:35:20 +0200 Message-ID: <51B1A95B.2030208@ericsson.com> Date: Fri, 7 Jun 2013 11:35:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Elwyn Davies References: <1370477514.4596.9052.camel@mightyatom> In-Reply-To: <1370477514.4596.9052.camel@mightyatom> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+JvrW7Eyo2BBnM+2lhc/HKE3eL4gR3s FldffWaxeLZxPovF1OWPWRxYPb6ebGfxWLLkJ5PHl8uf2QKYo7htkhJLyoIz0/P07RK4Mx7/ ncFccN2kouPldOYGxnOaXYwcHBICJhKNq4BMTiBTTOLCvfVsXYxcHEICpxgl7m26zwjhLGOU OHB2MQtIFa+AtsTNyccZQWwWARWJX8f6wWw2AQuJmz8a2UBsUYFgiSPbN0PVC0qcnPkEzBYR UJPY/PUB2FBmgXWMEidnPwJrFhbwkdgyYTVYkZCAscTjr+9ZQWxOoOvutnaxQpwnKbHlRTs7 iM0soCcx5WoLI4QtL9G8dTYzRK+2RENTB+sERqFZSHbPQtIyC0nLAkbmVYzsuYmZOenlhpsY gWF9cMtv3R2Mp86JHGKU5mBREufV410cKCSQnliSmp2aWpBaFF9UmpNafIiRiYMTRHBJNTBm Njw9vXtNjUSWqHffHf6XIhdnHWQqOXH7tfbLwsgXdjn1jrV8DCI6Oey3tmjcFJDc/Trm/qna ur78ph9FVukpx5KmPdX9LeBY19627evxW3cXyOr3VT+WMRG5YP1/RexpIY41ey3Xf92z4ffL Kfwfr/U/FPzHIuo/RU8mv0p0eV339/f6E62VWIozEg21mIuKEwF2n0SPPgIAAA== Cc: General Area Review Team , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" , IETF discussion Subject: Re: [MMUSIC] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 09:35:29 -0000 Hi Elwyn, Many thanks for the detailed review. We will address the nits you have raised, but I cut them out of this reply to focus on the more substantial issues you have brought up. See inline below. On 2013-06-06 02:11, Elwyn Davies wrote: > I am an additional Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-mmusic-rfc2326bis > Reviewer: Elwyn Davies > Review Date: 5 June 2013 > IETF LC End Date: 5 JUne 2013 > IESG Telechat date: (if known) - > > Summary: > Almost ready. Generally this is an excellent and well written document, > particularly given its size. There are a few minor issues to sort out > mainly at the nit level and some consistency issues to fix up. The two > issues that I have brought out below are really at what the IESG would > call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may > well have already been cleared by the URI expert - the draft does not do > itself any favours here by failing to explain what the syntax changes > are in s4.2; this raises immediate red flags that only start to fade a > couple of hundred pages later. The rudimentary nature of the pipeline > mechanism is carried over from RTSP 1.0. I'd like to be sure that this > has been properly discussed in the WG as it looks pretty flaky to an > outsider. There are several inconsistencies between various lists of > headers that need sorting out and there is no definition of > Proxy-Authorization in the ABNF. > > There are also a fairly large number of editorial nits but these are all > localized and trivial to fix. Finally I have't had time to review the > appendices (maybe there will be a follow up). > > Robert Sparks is the main gen-art reviewer for the document; he asked > for additional eyes on the document given the size and his RAI > background. Having (just) seen his review, I think we have both picked > up on the URI scheme and pipeline issues. I am not sure that I concur > with his view that there is significant normative material in the > appendices - AFAICS the main protocol definition *is* in the main body > of the document and the bits especiially in Appendices B and C are not > the core of the protocol. However this is based on a very cursory > glance through something like 75 pages of the document. However, I do > concur with Robert's view that it needs a security expert to check the > security stories. > > Major(ish) issues: > s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The > last sentence of para 1 states that the 'details of the syntax' of the > URIs 'have been changed'. Is this a reasonable thing to do? Has this > been cleared with the URI expert reviewer? I am not entirely clear what > the change involves and the draft doesn't explain exactly how the syntax > has been altered and its consequences (if any) in s4.2. Some details > are finally given in s22.14. These syntax changes where discussed in the reviews I got on the URI list. That resulted in the explicitness in the template, but I forgot about adding anything into Section 4.2. I see no issue with adding the following clarification to Section 4.2: The details of the syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0. These changes are: o Support for IPV6 literal in host part and future IP literals through RFC 3986 defined mechanism. o A new relative format to use in the RTSP protocol elements that is not required to start with "/". Neither should have any significant impact on interoperability. If one is required to use IPv6 literals to reach an RTSP server, then that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol. Thus, RTSP 2.0 support will be needed anyway. The second change will only occur in RTSP messages, that are explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0 only agent will not be required to parse this variant. I hope this makes it clear that these syntax changes is unlikely to hurt the interoperability. > > > Minor issues: > s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0 > model of sending requests and worrying about success of prior prior > pipelined requests was the right answer. I would have thought that it > might have been helpful to provide qualifiers on the Pipelined-Requests > header that allowed subsequent requests to be suppressed unless the > previous command resulted in one of a given set of status codes with a > 'reset' option to 'restart' the pipeline. It strikes me that this would > avoid some irritating need to work out how to recover from arbitrary > failures in a command chain in a client. > I assume you mean this Section 12 paragraph: If a pipelined request builds on the successful completion of one or more prior requests the requester must verify that all requests were executed as expected. A common example will be two SETUP requests and a PLAY request. In case one of the SETUP fails unexpectedly, the PLAY request can still be successfully executed. However, the resulting presentation will not be as expected by the requesting client, as only a single media instead of two will be played. In this case the client can send a PAUSE request, correct the failing SETUP request and then request it to be played. I think I agree with your assessment, that it would have been nice. However, we should have thought of that when we introduced this type of pipelining 7 years ago. Making any changes to this at this stage is counter productive. The reality is that all the "nice" features and necessary clarifications has been retrofitted into RTSP 1.0 by the ones that have been using RTSP 1.0. So changing anything will separate the RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't remember any substantial complaints about this issue. I hope this resolves your comments. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From prvs=58703c4c02=christer.holmberg@ericsson.com Fri Jun 7 05:19:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA7B21F8ECB for ; Fri, 7 Jun 2013 05:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v7pIXMKIV4y for ; Fri, 7 Jun 2013 05:19:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D6DBB21F8B07 for ; Fri, 7 Jun 2013 05:19:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-43-51b1cfe279f0 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D3.61.09795.2EFC1B15; Fri, 7 Jun 2013 14:19:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 14:19:45 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAACvn8mA= Date: Fri, 7 Jun 2013 12:19:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> In-Reply-To: <51B0BCA8.6050304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre6j8xsDDW68FrWYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKG6bpMSSsuDM9Dx9uwTujP19nWwFb8wrJtzsYGlg/KnVxcjJISFg InH70hZmCFtM4sK99WxdjFwcQgKHGSVetJ5lhHAWM0pcm/KTvYuRg4NNwEKi+582SIOIgK/E s8e32UBsYQEHiS0bJrFCxB0lDvzawgZhW0k8XDGNEaSVRUBFYu80fZAwL1Dr099fwPYKCeRL zJn7kgXE5hTQkfh/fzFYnBHonu+n1jCB2MwC4hK3nsxngrhTQGLJnvNQN4tKvHz8jxVkvISA osTyfjmIch2JBbs/sUHY2hLLFr5mhlgrKHFy5hOWCYyis5BMnYWkZRaSlllIWhYwsqxiZM9N zMxJLzffxAiMhINbfhvsYNx0X+wQozQHi5I4rz7v4kAhgfTEktTs1NSC1KL4otKc1OJDjEwc nCCCS6qB0ePVmZ8JL3Zs8lvu+PGEff7eBUemH53Wr2C/rej4011KJj6Xgu2rldVSVyUWCU4t NfG0j17psjS1U+XF+ZXq5XsaMjffTJpasao+x2/5qmsT2xZzyHySX2r+2k8ktKkldNfj4Gv6 ltcMLA0+LDG56brXLetfXozr4g0FIa+y/hYf2H4kOkJLWYmlOCPRUIu5qDgRAFfgFgxXAgAA Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 12:19:54 -0000 Hi, After reading Paul's and Martin's comments, I am suggesting a change to the= separation between BSO and BRO.=20 Again, the names will be changed, but I'll leave that for now - but I DO li= ke the Bundle Negotiation Offer (BNO) suggestion made by Martin :) In the current text, I separate between BSO and BRO pretty much based on th= e type address information in the "m=3D" lines of the SDP Offer. I have rea= lized that it doesn't work very well. So, a new suggestion is that the separation is done based on the PURPOSE of= the SDP Offer, NOT the type of address information in the "m=3D" lines (of= course, in many cases they go hand-in-hand). A BSO would be used ONLY for synchronization purpose, or making the SDP "st= able". A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify = "m=3D" lines and/or the bundle address. So, even an with the same address i= nformation in each "m=3D" line could be an BRO, if the purpose is to modify= the SDP in one way or another. So, please keep the assumptions above in mind when reading my reply to the = individual comments below :) ---------------------------------- >> 6.2.2.1. Bundle Restart Offer (BRO) >> >> A Bundle Restart Offer (BRO) is used to negotiate (or=20 >> re-negotiate) the usage of the BUNDLE mechanism, and/or the bundle a= ddress used=20 >> by the "m=3D" lines in a BUNDLE group. >> >> In a BRO, the Offerer assigns a unique address to at least one "m=3D" >> line in a BUNDLE group. Such "m=3D" lines can be removed from the >> >> BUNDLE group by the Answerer (see [xxx]), as the unique address can >> be used outside the BUNDLE group. >> >> In a BRO, the Offerer assigns, for each "m=3D" line in the BUNDLE >> group, either a unique address, or a previously negotiated bundle >> address, as long as a unique address is assigned to at least one "m= =3D" >> line in the BUNDLE group (if the bundle address is assigned to each >> "m=3D" line in the BUNDLE group, the SDP Offer is by definition a >> Bundle Sync Offer (BSO) Section 6.2.2.2. > The above excludes the possibility of both proposing to change the previo= usly negotiated bundle address and add a new m-line with a unique address. Correct. But, with the suggested change in the beginning of the mail it sho= uld now be possible. >> When a session is initiated, if the Offerer does not know whether th= e >> Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a >> BRO, and the Offerer MUST assign a unique address to each "m=3D" lin= e >> in the BUNDLE group. > > The MUST above bothers me. I could go with SHOULD. > IOW, even if the offerer doesn't know whether the answerer supports=20 > bundle, it could take a chance, on the assumption that the odds are good= =20 > that it will be successful. Then it can deal with the consequences if=20 > the answer indicates that bundle wasn't supported. Ok. >> If, in the SDP Answer associated with the BRO, the offered BUNDLE >> group is accepted [ref-to-be-added], the Offerer MUST, for each "m= =3D" >> line in the BUNDLE group, start to use its local bundle address, and >> the remote bundle address, both selected by the Answerer [ref-to-be- >> added]. In addition, the Offerer MUST send a Bundle Sync Offer (BSO= ) >> Section 6.2.2.2, in which the bundle address is assigned to each "m= =3D" >> line in the BUNDLE group. > > In some cases things could be done with one O/A rather than two, and=20 > whether a 2nd one is needed may depend on what was in the answer. What=20 > is proposed seems to *require* two O/As when bundling is used. I will make it more clear that the 2nd O/A (BSO) is required ONLY when a BR= O was sent, AND each "m=3D" line did NOT have the same address information. -------------------------------- > 6.2.2.2. Bundle Sync Offer (BSO) > > A Bundle Sync Offer (BSO) is used when the Offerer does not want to > re-negotiate the usage of the BUNDLE mechanism, and/or the bundle > address. The Offerer can, using a BSO, re-negotiate other parameters > associated with the BUNDLE group, however. > If all I want to do is change the bundle address, I should be able to=20 > send an offer that does that. > And after the answer all is done. I shouldn't be required to offer unique= addresses for each (or any) m-line=20 > in the bundle to do this. The new BRO definition will allow you to do that, as you can now assign the= same address (i.e. your suggested new bundle address) to each "m=3D" line. >> In a BSO, the Offerer MUST assign the bundle address to each "m=3D" >> line in a BUNDLE group. Such "m=3D" lines can not be removed from t= he >> BUNDLE group by the Answerer [ref-to-be-added], as the bundle addres= s >> can not be used outside the BUNDLE group. > > Some of the m-lines in the bundle can be rejected (port zero), and then=20 > be removed from the bundle. I thought I had some text clarifying that, but if it's not there I will add= it. > And if there is then only one m-line left in the bundle, then I guess it = can either=20 > be left in the bundle or else the bundle can be removed. I did have some text about BUNDLE groups with only one "m=3D" line, but it = seems it got lost somewhere. Personally I don't think we would need to forbid BUNDLE groups with only on= e "m=3D" line (unless it goes against RFC 5888), but it doesn't really give= you anything. -------------------------------- >> 6.2.3.1. Offerer Bundle Address Request >> >> In order to negotiate (or re-negotiate) the bundle address, the >> Offerer MUST send a BRO. In the BRO, as the Offerer assigns a uniqu= e >> address to some (or all) "m=3D" lines in the BUNDLE group, the Offer= er >> needs to indicate to the Answerer which address, associated with one >> of the "m=3D" lines in the BUNDLE group, it wishes to use as its loc= al >> bundle address. The first mid value in the SDP group:BUNDLE >> attribute mid value list represents the "m=3D" line address with the >> highest preference. > > Again, you say a BRO MUST be used to to change the bundle address. > But the key defining feature of a BRO over a BSO is that it has at least= =20 > one m-line with a unique address. This doesn't suit the case well. > But I can't use a BSO for this, because, by your definition it must have= =20 > the previously negotiated bundle address. Correct. My suggestion in the beginning of the reply would change that. You would still use a BRO for this, but you can assign the same=20 address (previously negotiated bundle address OR suggested new bundle addre= ss) to each "m=3D" line if you want. -------------------------------- You had some more comments, but I'll leave them for now, because I *THINK* = my new suggestion would solve most of them. But, I'll go through them when I put together a proposal for new text. Regards, Christer From prvs=6870181dd3=magnus.westerlund@ericsson.com Fri Jun 7 07:05:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FD921F8756; Fri, 7 Jun 2013 07:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfQrbF2j5QHu; Fri, 7 Jun 2013 07:05:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 202DC21F84F5; Fri, 7 Jun 2013 07:05:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-ce-51b1e8b94b16 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A2.82.18006.9B8E1B15; Fri, 7 Jun 2013 16:05:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Jun 2013 16:05:45 +0200 Message-ID: <51B1E8BD.80901@ericsson.com> Date: Fri, 7 Jun 2013 16:05:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Elwyn Davies References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> <1370607960.4596.9114.camel@mightyatom> In-Reply-To: <1370607960.4596.9114.camel@mightyatom> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvre7uFxsDDX6eYrG4+OUIu8XxAzvY La6++sxi8WzjfBaLqcsfsziwenw92c7isWTJTyaPL5c/swUwR3HbJCWWlAVnpufp2yVwZ7xY cp+toEuuYtPRWSwNjBMkuhg5OSQETCTuzzzKAmGLSVy4t56ti5GLQ0jgFKPE1NfNrBDOMkaJ 7U9OsYJU8QpoSkze8IEZxGYRUJG4+6WfEcRmE7CQuPmjkQ3EFhUIljiyfTMLRL2gxMmZT8Bs EQE1ic1fHzCCDGUWWMco8ay3GWyosECYxLwt3UwgtpBAjcThZ6/AbE6g83Z3/maCOE9SYsuL dnYQm1lAT2LK1RZGCFteonnrbGaIXm2JhqYO1gmMQrOQ7J6FpGUWkpYFjMyrGNlzEzNz0suN NjECA/vglt+qOxjvnBM5xCjNwaIkzqvHuzhQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJq YAxRMMrVvRF/XOGI73/rjKO/9zSa3rPYkBx1WW75tSRuMUOvP5o7tyZunZ4wR+qV0OyyFAaz k+8/WtaXuineTgUGmOnO74emb+ELnfphSUX6aodPB+69E8lkvtma/XPCZea0xPjrGw/t7vxb cc1CyE8ySuCq6d6CPW+FY87uPLX17Qbn81umLlNiKc5INNRiLipOBACdPXC5PwIAAA== Cc: General Area Review Team , IETF discussion , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 14:05:58 -0000 Hi Elwyn, On 2013-06-07 14:26, Elwyn Davies wrote: > On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote: >> Hi Elwyn, >> >> Many thanks for the detailed review. We will address the nits you have >> raised, but I cut them out of this reply to focus on the more >> substantial issues you have brought up. > .. and thanks for the quick response. > >> >> See inline below. > OK. I think the responses clear those issues. > > I have done a little bit more on the Appendices and liaised a bit with > Robert Sparks. 'Highlights': > > Appendix F: I missed that the text/parameter format appeared in the > examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the > definitions of these methods what encodings are acceptable for the > message bodies that may go with these methods and their responses. Exactly, that is intentional. These methods can use anything that has a MIME type. Also it has HTTP's mechanisms for determining what formats one supports. > Clearly the new text/parameter MIME format is one. Is it the only one? It is the only one defined by IETF for this purpose. That is why it is in the appendix so that RTSP users shall have something to define the parameters they want in. However, they have to accept the limitations of a basic text format. > I guess you could use a application/json or an XML format but I guess > these would also either have to be called out explicitly in the method > descriptions or put in as feature extensions. This needs to be > clarified in the method descriptions (s13). The upshot of all this is > that I think Appendix F needs to be pulled back into Section 20 as > currently it is the only way to encode the message bodies. I can agree that the format negotiation for the bodies of GET/SET_PARAMETER is not clear. I will look at proposing some improvements of the text related to the handling of method bodies and their format negotiation. However, I am not pulling in Appendix F. It is an optional to use format for parameter value pairs that can be used in these methods, it is not required. Nor, does the specification define any parameters that are transferred using this interface. The things that are in the appendix are not core protocol, they represent either informational things, like the examples and the state machine. The other appendices are normative definitions of particular choices for things that can be combined or used with RTSP, like RTP as media transport. > > Appendix B: I appreciate that the state machine is illustrative and to > an extent 'abstract'. However, the tables are really written to > describe the state machine in the server: the action column mostly > describes the events that come into the server (apart from the notify > actions) - sending these 'events' are actions in the client. The 'real' > state machine in the both the server and the client has a somewhat more > complex form: I'd think that there was a STOPPED state in the server > when the media has reached an end point and not been explictly paused > and STARTING/PAUSING states in the client while the client waits for > response to PLAY/PAUSE respectively. I think a little bit more > explanation about the dual nature of the columns would solve the > problem. There shouldn't be an issue to clarify this nature. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From martin.thomson@gmail.com Fri Jun 7 09:12:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664DA21F918F for ; Fri, 7 Jun 2013 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb06fFT3WYmY for ; Fri, 7 Jun 2013 09:12:41 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A02E321F90CC for ; Fri, 7 Jun 2013 09:12:40 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id cb5so1392674wib.9 for ; Fri, 07 Jun 2013 09:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U9CbtvKVfcBuAwk9M30bac8CMyiEMKx2R8CSAEreQw0=; b=iAy0i/PmeqF26ebhjs+swIOMK+ziXQsEsmuNSd0RbaSp0pKM4f3aKbIHwQeux+7svE fNkSexW8dq8nalezxjPlJ+8M03a1k/sfpKohCQ7WQBaFD63WmBgOWYaXKpPm30UcafmS Da4JhH1hl+cwV1WrN3cPH0KoVPeYY0+dGw+h8gRYjQ7RbVGR1DGV4GfDhH4sT6fdfqIP wr4ZQQoYsliCcCJF4yiY+j2Jt12S0jdjCFoMmPsUXMIDrUPUVyTCp8OXaz6zBbuM+5t7 ll2gQX8la9OSSXU6dY/Vh2eQwujzt1/B9wPvXjRUOaG78LrsJXv2xTgtKpjQP+qwUeNw JUcg== MIME-Version: 1.0 X-Received: by 10.180.210.207 with SMTP id mw15mr2304093wic.10.1370621559793; Fri, 07 Jun 2013 09:12:39 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Fri, 7 Jun 2013 09:12:39 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> Date: Fri, 7 Jun 2013 09:12:39 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:12:41 -0000 Great stuff Christer. I think that we have reached some sort of agreement. Only one thing to comment on: On 7 June 2013 05:19, Christer Holmberg wrote: >> The MUST above bothers me. I could go with SHOULD. >> IOW, even if the offerer doesn't know whether the answerer supports >> bundle, it could take a chance, on the assumption that the odds are good >> that it will be successful. Then it can deal with the consequences if >> the answer indicates that bundle wasn't supported. > > Ok. So I don't have a problem with going with SHOULD here rather than MUST. If the Offerer wants to take that chance, then that is OK with me. It might still work even if the Answerer didn't support BUNDLE. The only thing that would make me reluctant to do so is that you then need to follow the SHOULD with some additional information. Guidance on what could go wrong if the SHOULD is ignored. Were it me, I'd want to dredge through the archives to uncover all those nasty corner cases we discussed in order to get the right text, so my natural laziness would lead to choosing MUST :) --Martin From pkyzivat@alum.mit.edu Fri Jun 7 09:40:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3821F96FB for ; Fri, 7 Jun 2013 09:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDz-ClWc5UWJ for ; Fri, 7 Jun 2013 09:39:56 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id BF2C021F965B for ; Fri, 7 Jun 2013 09:39:47 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id lPFm1l0040EZKEL5BUfmhd; Fri, 07 Jun 2013 16:39:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id lUfm1l00A3ZTu2S3MUfmvu; Fri, 07 Jun 2013 16:39:46 +0000 Message-ID: <51B20CD1.5090002@alum.mit.edu> Date: Fri, 07 Jun 2013 12:39:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> <51AF6490.1040409@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370623186; bh=Dey51hnbKefs1OPIHPJhbugFcpjPuPjBsSqSw/RgLik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CPNoBy5QNSwZmBQKJm7x1cT5x4apJ33x7F0Cflr8wtNIJJFtkfApPQYeJGA/pgxt5 B9W1HzTbBq5jEnT/5MmKLLW9OcNdneeXd464OJcy42JHaTXRIx5Czn7fQKz2/eQm2h dPtUfypU35FPt5Z487N2+M7iN6DjK0e5fyHzjDrY5PvbBMJ+WxuTxbdxAMDjQKUEJY 5i2UB9ozZDEQ17mXOwbndSyoQfDLoy6MTR5RUV/ZoHvtHDgYZYkpl8MT+Lsf/ofgud flwJ08CPR6nAZVVquP/gXU+fDleztUwxzR2Wu4MKnLnAGaF+azZdNhB7HU1DnC645K Jhswzehs5qARA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:40:08 -0000 On 6/6/13 1:41 AM, Cullen Jennings wrote: > > On Jun 5, 2013, at 11:17 PM, Paul Kyzivat wrote: > >>> And it is likely to receive RTP packets before it receives an answer in some important scenarios. >> >> You keep saying that. But is it really true when ICE is used? >> Need it be true even without ICE? After all, bundle is new usage, so we can demand new behavior when using it. So requiring a reliable provisional with an answer before sending media doesn't seem so unreasonable. > > I'm assuming that some applications will bring up a data channel (using ICE), as soon as the far end starts alerting the user so this will be done by the time the far end users agrees to send media. At that point it would be nice to start sending media with no clipping. That allows all the ICE setup time to disappear from the media clipping latency problem. > > I realize lots of applications will not work this way. We're mixing apples and oranges here I think. In a pure sip environment there probably won't be a data channel, except for CLUE. But perhaps CLUE is what we should be considering when we are talking about bundle in a pure sip environment. Even webrtc won't always be using a data channel. In cases where there is a data channel, I don't know how much data will be exchanged over it before the "alerting" is done and the connection acknowledged. I certainly want that to be very constrained. So I'm not sure what the relevance of the data channel is to this discussion. Reliable provisionals only apply when SIP is involved, on at least half of the call. But it doesn't matter, because for RTCWEB the equivalent thing exists - simply sending an answer early on. Once that has happened, the UAC can know what SSRCs to expect from the other end and use that as part of the process of associating packets with m-lines. So my question is still: is it unreasonable to expect an answer to be returned and confirmed before the UAS starts sending media? This can happen as early as the commencement of alerting at the UAS. That means requiring 1.5 round trips over the signaling channel before starting to send. It will very likely require more round trips than that over the media channel (because of ICE) before media can flow in any case. Also, until the UAC receives an answer it can't do ICE. So when ICE is in use aren't you guaranteed to have had a chance to get those SSRCs from the UAS? Thanks, Paul From pkyzivat@alum.mit.edu Fri Jun 7 09:42:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E094921F8425 for ; Fri, 7 Jun 2013 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnTzuH4f+Sxw for ; Fri, 7 Jun 2013 09:42:13 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id DF14E21F842E for ; Fri, 7 Jun 2013 09:42:12 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id lPBB1l0021vXlb85BUiCEZ; Fri, 07 Jun 2013 16:42:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id lUiC1l0063ZTu2S3dUiCSG; Fri, 07 Jun 2013 16:42:12 +0000 Message-ID: <51B20D64.7050600@alum.mit.edu> Date: Fri, 07 Jun 2013 12:42:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> In-Reply-To: <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370623332; bh=sLmvUfpuwmKkC9Wed+BRB5g9TxHXsfoEBTtD/PgobBw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cwYQDLER5OBmpywW/bfq3MaK+shpEeUrUDw+ZBc4SG8Vgx1+vAjE3kthYkT0fhZQk EBQy7oxAY4EeqeBtYqXAf21lUBi0ttRfZGMwC69SQFBwjmSJ0T0RTfnrY0qkQfdknI dW1w/SPQwuhfRxd7v2HbWIrfIGj3/QdxH3jPXfK77zOWO3hnjQGXVRdoFOOHHJohbj ezRT9ALpWhXqV3VbaTDLtCqpo0BZG5/rmprH+xh/w9E49KocoF+NTN3Lbm6JD1WSm8 wcC7aL64Z603kNE/IvcdjjFb/0IBi6JnIT1oPd8UhYNumJVvFxY/sdedOBFWEBQvYq YGnDhg/Qf+yfg== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:42:19 -0000 On 6/6/13 1:41 AM, Cullen Jennings wrote: > > On Jun 6, 2013, at 12:01 AM, Christer Holmberg wrote: > >> For example, I PERSONALLY think one can assume to receive an SDP Answer (including SSRC/CNAME information etc) before media is received. But, as Cullen has another opinion I don't want to waste time on arguing about that - and I am fully aware what 3264 says about receiving media before the SDP answer :) > > In fairness here we have some different type of deployments environments. Christer is often concerned about an environment where using SIP, things like PRACK are used which allows one to get an answer before media. IN fact media is probably gated and won't work if there is not an answer before the media. I am often concerned about deployments environments where PRACK is not supported but media is not gated. There are still environments where PRACK is not *supported*??? (As opposed to being supported but not being used.) If so, I'll bet those environments also don't support BUNDLE. :-) And then can't we demand that to support BUNDLE you must also support PRACK? Thanks, Paul From pkyzivat@alum.mit.edu Fri Jun 7 10:23:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F157721F9452 for ; Fri, 7 Jun 2013 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcbZMzv8bNKf for ; Fri, 7 Jun 2013 10:23:25 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5F221F925A for ; Fri, 7 Jun 2013 10:23:13 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id lQFx1l0091ZXKqc5CVPDAW; Fri, 07 Jun 2013 17:23:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id lVPD1l00K3ZTu2S3hVPDoe; Fri, 07 Jun 2013 17:23:13 +0000 Message-ID: <51B21700.1020709@alum.mit.edu> Date: Fri, 07 Jun 2013 13:23:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370625793; bh=H/FJEesWU34+K4qMeLmn6XBt0O3tdc2iOfeCTan/fek=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mxGi8t8Uy+3Rvn5ogRDOEj5zo0CbxPk1cgRmDOELPHriHJydWiYelrW/Cejutumc3 5DTUnU+U3/CaCyCX9I0FJAjaRA/qbHL+78t5WITp1RkBscHGxbFe2SyrA+puNdqiO3 nDoHBbuVE9kTJNLtRchD5tKE6MI1vK5uFcD/SMi1BDALfsoC8/daxgmRkcXLihZHar Tfe7WoaBvaMcnZEIXxGLAk1O+ALUco+gmWIc0Ousgk1DZz1ylBZgMXZ2xpcVrR2y9t t8KZU8U0N+0oiyIhzzuSq/ohR3oM2JYW+1rxUwjLCwlLyjZz/o9ZPYr2reJozqr7rz g6ZIUjCgcHwKQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 17:23:31 -0000 Christer, On 6/7/13 8:19 AM, Christer Holmberg wrote: > Hi, > > After reading Paul's and Martin's comments, I am suggesting a change to the separation between BSO and BRO. > > Again, the names will be changed, but I'll leave that for now - but I DO like the Bundle Negotiation Offer (BNO) suggestion made by Martin :) > > In the current text, I separate between BSO and BRO pretty much based on the type address information in the "m=" lines of the SDP Offer. I have realized that it doesn't work very well. > > So, a new suggestion is that the separation is done based on the PURPOSE of the SDP Offer, NOT the type of address information in the "m=" lines (of course, in many cases they go hand-in-hand). Note that offers and answers may contain more than just one set of bundled m-lines. They may contain unbundled m-lines, and multiple bundles. So the purpose of a particular offer may be complex, trying to satisfy different needs for various parts of the SDP. That complicates making such a distinction. > A BSO would be used ONLY for synchronization purpose, or making the SDP "stable". So this is just intended to describe the case where both ends have reached agreement on what they want to do, and don't want to change that, but the agreed pair of SDPs doesn't describe that agreement in the standard way? This additional O/A is used *solely* to put things into the standardized representation? And if things end up in the standardized form without a BSO then one is not sent? If so, then the receiver of the offer can tell that it is a BSO by analyzing it in the context of what the prior O/A had been. But there is no particular reason to do so, because it doesn't affect the behavior of the answerer. The value of the term must be simply to facilitate the description of offerer behavior. Following an O/A exchange that has left things in a non-canonical form, the offerer in that exchange is required to send a BSO. And I think the need for a BSO can indeed only be determined after receiving the answer. It is largly driven by the structure of the offer, but even so, certain answers may eliminate the need for the BSO. > A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify "m=" lines and/or the bundle address. So, even an with the same address information in each "m=" line could be an BRO, if the purpose is to modify the SDP in one way or another. So an offer that *changes* *anything* is a BRO, while one that changes nothing but puts things in the correct form is called a BSO. That definition might work from the point of view of the offer. But note that even with a BSO the answer might change something. E.g. the answerer could change its bundle address, or it could reject some m-lines. (But I don't think it is possible for the answer to do anything valid that will prevent the intent of the BSO from being achieved.) > So, please keep the assumptions above in mind when reading my reply to the individual comments below :) I don't have any further comments on what follows. Thanks, Paul > ---------------------------------- > > >>> 6.2.2.1. Bundle Restart Offer (BRO) >>> >>> A Bundle Restart Offer (BRO) is used to negotiate (or >>> re-negotiate) the usage of the BUNDLE mechanism, and/or the bundle address used >>> by the "m=" lines in a BUNDLE group. >>> >>> In a BRO, the Offerer assigns a unique address to at least one "m=" >>> line in a BUNDLE group. Such "m=" lines can be removed from the >>> >>> BUNDLE group by the Answerer (see [xxx]), as the unique address can >>> be used outside the BUNDLE group. >>> >>> In a BRO, the Offerer assigns, for each "m=" line in the BUNDLE >>> group, either a unique address, or a previously negotiated bundle >>> address, as long as a unique address is assigned to at least one "m=" >>> line in the BUNDLE group (if the bundle address is assigned to each >>> "m=" line in the BUNDLE group, the SDP Offer is by definition a >>> Bundle Sync Offer (BSO) Section 6.2.2.2. > >> The above excludes the possibility of both proposing to change the previously negotiated bundle address and add a new m-line with a unique address. > > Correct. But, with the suggested change in the beginning of the mail it should now be possible. > > >>> When a session is initiated, if the Offerer does not know whether the >>> Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a >>> BRO, and the Offerer MUST assign a unique address to each "m=" line >>> in the BUNDLE group. >> >> The MUST above bothers me. I could go with SHOULD. >> IOW, even if the offerer doesn't know whether the answerer supports >> bundle, it could take a chance, on the assumption that the odds are good >> that it will be successful. Then it can deal with the consequences if >> the answer indicates that bundle wasn't supported. > > Ok. > > >>> If, in the SDP Answer associated with the BRO, the offered BUNDLE >>> group is accepted [ref-to-be-added], the Offerer MUST, for each "m=" >>> line in the BUNDLE group, start to use its local bundle address, and >>> the remote bundle address, both selected by the Answerer [ref-to-be- >>> added]. In addition, the Offerer MUST send a Bundle Sync Offer (BSO) >>> Section 6.2.2.2, in which the bundle address is assigned to each "m=" >>> line in the BUNDLE group. >> >> In some cases things could be done with one O/A rather than two, and >> whether a 2nd one is needed may depend on what was in the answer. What >> is proposed seems to *require* two O/As when bundling is used. > > I will make it more clear that the 2nd O/A (BSO) is required ONLY when a BRO was sent, AND each "m=" line did NOT have the same address information. > > > -------------------------------- > > >> 6.2.2.2. Bundle Sync Offer (BSO) >> >> A Bundle Sync Offer (BSO) is used when the Offerer does not want to >> re-negotiate the usage of the BUNDLE mechanism, and/or the bundle >> address. The Offerer can, using a BSO, re-negotiate other parameters >> associated with the BUNDLE group, however. > >> If all I want to do is change the bundle address, I should be able to >> send an offer that does that. >> And after the answer all is done. I shouldn't be required to offer unique addresses for each (or any) m-line >> in the bundle to do this. > > The new BRO definition will allow you to do that, as you can now assign the same address (i.e. your suggested new bundle address) to each "m=" line. > > >>> In a BSO, the Offerer MUST assign the bundle address to each "m=" >>> line in a BUNDLE group. Such "m=" lines can not be removed from the >>> BUNDLE group by the Answerer [ref-to-be-added], as the bundle address >>> can not be used outside the BUNDLE group. >> >> Some of the m-lines in the bundle can be rejected (port zero), and then >> be removed from the bundle. > > I thought I had some text clarifying that, but if it's not there I will add it. > > >> And if there is then only one m-line left in the bundle, then I guess it can either >> be left in the bundle or else the bundle can be removed. > > I did have some text about BUNDLE groups with only one "m=" line, but it seems it got lost somewhere. > > Personally I don't think we would need to forbid BUNDLE groups with only one "m=" line (unless it goes against RFC 5888), but it doesn't really give you anything. > > > -------------------------------- > > >>> 6.2.3.1. Offerer Bundle Address Request >>> >>> In order to negotiate (or re-negotiate) the bundle address, the >>> Offerer MUST send a BRO. In the BRO, as the Offerer assigns a unique >>> address to some (or all) "m=" lines in the BUNDLE group, the Offerer >>> needs to indicate to the Answerer which address, associated with one >>> of the "m=" lines in the BUNDLE group, it wishes to use as its local >>> bundle address. The first mid value in the SDP group:BUNDLE >>> attribute mid value list represents the "m=" line address with the >>> highest preference. >> >> Again, you say a BRO MUST be used to to change the bundle address. >> But the key defining feature of a BRO over a BSO is that it has at least >> one m-line with a unique address. This doesn't suit the case well. >> But I can't use a BSO for this, because, by your definition it must have >> the previously negotiated bundle address. > > Correct. My suggestion in the beginning of the reply would change that. > > You would still use a BRO for this, but you can assign the same > address (previously negotiated bundle address OR suggested new bundle address) > to each "m=" line if you want. > > -------------------------------- > > You had some more comments, but I'll leave them for now, because I *THINK* my new suggestion would solve most of them. > > But, I'll go through them when I put together a proposal for new text. > > Regards, > > Christer > From prvs=88707f6981=christer.holmberg@ericsson.com Fri Jun 7 11:55:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FF621F96EC for ; Fri, 7 Jun 2013 11:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snxeOvaL1buo for ; Fri, 7 Jun 2013 11:55:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4D21F95DD for ; Fri, 7 Jun 2013 11:55:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-38-51b22caef556 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FD.58.09795.EAC22B15; Fri, 7 Jun 2013 20:55:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 20:55:42 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAACvn8mAAB7QFAAAHB7kk Date: Fri, 7 Jun 2013 18:55:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se>, <51B21700.1020709@alum.mit.edu> In-Reply-To: <51B21700.1020709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre46nU2BBju/qltMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xucrO9gKtshVXDz/l6mBsVmii5GTQ0LA RKJ/43p2CFtM4sK99WxdjFwcQgKHGSVuLfzDApIQEljMKHFjV20XIwcHm4CFRPc/bRBTREBD YtJWNRCTWUBd4uriIJBiYQEHiS0bJrGC2CICjhIHfm1hg7DdJJqOtINtYhFQkVi/6BojiM0r 4CtxY+4tVoitlxklFj28wwyS4BTQkTj+7RRYESPQad9PrWECsZkFxCVuPZnPBHGygMSSPeeZ IWxRiZeP/7FC2IoSO8+2M0PU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQts5C0 zELSsoCRZRUje25iZk56ufkmRmCEHNzy22AH46b7YocYpTlYlMR59XkXBwoJpCeWpGanphak FsUXleakFh9iZOLgBBFcUg2MPAyTNW9Ev7g0N81iQ8yCNtEvRdoaVfll/TO19mcmL1vBJNR5 eMIE9y27sk8sMW23OJT95erCYzOKmq/y/X2qUnxn2e0rM6ZxO6ekhU3WYi/sljtuXf/22eRn G1d8cvlf+kGlddpcbi6JY/qd0y1MFpi/O7Vgp8uzhcsfvO6ez1Jvr3DBLrlwixJLcUaioRZz UXEiAOqg3eljAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 18:55:50 -0000 Hi, >> After reading Paul's and Martin's comments, I am suggesting a change to = the separation between BSO and BRO. >> >> Again, the names will be changed, but I'll leave that for now - but I DO= like the Bundle Negotiation Offer (BNO) suggestion made by Martin :) >> >> In the current text, I separate between BSO and BRO pretty much based on= the type address information in the "m=3D" lines of the SDP Offer. I have = realized that it doesn't work very well. >> >> So, a new suggestion is that the separation is done based on the PURPOSE= of the SDP Offer, NOT the type of address information in the "m=3D" lines = (of course, in many cases they go hand-in-hand). > > Note that offers and answers may contain more than just one set of > bundled m-lines. They may contain unbundled m-lines, and multiple > bundles. So the purpose of a particular offer may be complex, trying to > satisfy different needs for various parts of the SDP. That complicates > making such a distinction. I guess it should be more clear that the definition is per bundle group wit= hin an SDP Offer, not necessairly the whole SDP body.=20 >> A BSO would be used ONLY for synchronization purpose, or making the SDP = "stable". > > So this is just intended to describe the case where both ends have > reached agreement on what they want to do, and don't want to change > that, but the agreed pair of SDPs doesn't describe that agreement in the > standard way? This additional O/A is used *solely* to put things into > the standardized representation? Correct. > And if things end up in the standardized form without a BSO then one is > not sent? Correct. > If so, then the receiver of the offer can tell that it is a BSO by > analyzing it in the context of what the prior O/A had been. But there is > no particular reason to do so, because it doesn't affect the behavior of > the answerer. > > The value of the term must be simply to facilitate the description of > offerer behavior. Following an O/A exchange that has left things in a > non-canonical form, the offerer in that exchange is required to send a BS= O. > > And I think the need for a BSO can indeed only be determined after > receiving the answer. It is largly driven by the structure of the offer, > but even so, certain answers may eliminate the need for the BSO. The reason for sending the BSO is not the Answerer - it is because of inter= mediaries that don't understand BUNDLE. >> A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modi= fy "m=3D" lines and/or the bundle address. So, even an with=20 >> the same address information in each "m=3D" line could be an BRO, if the= purpose is to modify the SDP in one way or another. > > So an offer that *changes* *anything* is a BRO, while one that changes > nothing but puts things in the correct form is called a BSO. Correct. > That definition might work from the point of view of the offer. > But note that even with a BSO the answer might change something. > > E.g. the answerer could change its bundle address, or it could reject > some m-lines. (But I don't think it is possible for the answer to do > anything valid that will prevent the intent of the BSO from being achieve= d.) I think that's ok. Because, even without BUNDLE, if an Offerer sends a SIP re-INVITE/UPDATE wi= th an unmodified SDP Offer (e.g. because of session-timer usage), the SDP A= nswer may still change. One question, though, is whether the SDP o=3D line version number should be= incremented when sending a BSO (assuming everything, including the non-BUN= DLE stuff, in the SDP body is unmodified). From a pure SDP perspective, the= address information for certain "m=3D" lines may have changed, eventhough = from a BUNDLE perspective it is just about synchronization. Regards, Christer= From martin.thomson@gmail.com Fri Jun 7 12:06:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC5821F997B for ; Fri, 7 Jun 2013 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nAcuIrRP8Ri for ; Fri, 7 Jun 2013 12:06:09 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B30D221F995C for ; Fri, 7 Jun 2013 12:06:08 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id e11so3331080wgh.26 for ; Fri, 07 Jun 2013 12:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mHHeDpA881CPeQn4oMq6TWxANQLisraYFfUjH0w/GyQ=; b=k/uLF63Fmh7eigy6iQRc9mZDrNDytXRn5oNZlkcMkTNeBm6+rG0X9N95u20DhVRUZs s+8LOgu1tEm5wmb1XRpUpp4xWw+8UH7Efrnz4spV3z8bcMOcbggiP/08rv79tsfr5omn ASo3fSLsoOOoS8ORnpfX0kEaLFqRHPHoMUGV9rOkvzfty0KqKRQbO7mZuXPLsY7JEfMc 2BqpaA4vp7bIoKd5m2pu6rHq/MR1jGcN3CRzrfBKfVmX/Agw7ASKhlOtMHnUwkbthSsP ggbnUbBmS4MrVk4eBjHz/C6Gm37ME3q//n4r93EM/3K+mlnBYEO2eBq2DObSekxNeo2S RsmQ== MIME-Version: 1.0 X-Received: by 10.194.158.102 with SMTP id wt6mr90491wjb.5.1370631967822; Fri, 07 Jun 2013 12:06:07 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Fri, 7 Jun 2013 12:06:07 -0700 (PDT) In-Reply-To: <51B21700.1020709@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> <51B21700.1020709@alum.mit.edu> Date: Fri, 7 Jun 2013 12:06:07 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 19:06:09 -0000 On 7 June 2013 10:23, Paul Kyzivat wrote: > Note that offers and answers may contain more than just one set of bundled > m-lines. They may contain unbundled m-lines, and multiple bundles. So the > purpose of a particular offer may be complex, trying to satisfy different > needs for various parts of the SDP. That complicates making such a > distinction. I thought about this, but forgot to followup. I think that it could be possible for a single request to be a BSO for one group, which a BRO for another. The labels are a convenience only, and provide a way to provide guidance about how to handle offer/answer creation...scoped only to the affected m-lines. I think that the complication is only a complication insofar as it requires some text that highlights this. From elwynd@folly.org.uk Fri Jun 7 05:26:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF0721F8B35; Fri, 7 Jun 2013 05:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyqxrcKbqLXM; Fri, 7 Jun 2013 05:26:06 -0700 (PDT) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id B629421F8ADC; Fri, 7 Jun 2013 05:26:05 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1Ukvk2-00081p-C1; Fri, 07 Jun 2013 13:26:02 +0100 From: Elwyn Davies To: Magnus Westerlund In-Reply-To: <51B1A95B.2030208@ericsson.com> References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Folly Consulting Date: Fri, 07 Jun 2013 13:26:00 +0100 Message-Id: <1370607960.4596.9114.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 07 Jun 2013 12:06:50 -0700 Cc: General Area Review Team , IETF discussion , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 12:26:10 -0000 On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote: > Hi Elwyn, >=20 > Many thanks for the detailed review. We will address the nits you have > raised, but I cut them out of this reply to focus on the more > substantial issues you have brought up. .. and thanks for the quick response. >=20 > See inline below. OK. I think the responses clear those issues. I have done a little bit more on the Appendices and liaised a bit with Robert Sparks. 'Highlights': Appendix F: I missed that the text/parameter format appeared in the examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the definitions of these methods what encodings are acceptable for the message bodies that may go with these methods and their responses. Clearly the new text/parameter MIME format is one. Is it the only one? I guess you could use a application/json or an XML format but I guess these would also either have to be called out explicitly in the method descriptions or put in as feature extensions. This needs to be clarified in the method descriptions (s13). The upshot of all this is that I think Appendix F needs to be pulled back into Section 20 as currently it is the only way to encode the message bodies. Appendix B: I appreciate that the state machine is illustrative and to an extent 'abstract'. However, the tables are really written to describe the state machine in the server: the action column mostly describes the events that come into the server (apart from the notify actions) - sending these 'events' are actions in the client. The 'real' state machine in the both the server and the client has a somewhat more complex form: I'd think that there was a STOPPED state in the server when the media has reached an end point and not been explictly paused and STARTING/PAUSING states in the client while the client waits for response to PLAY/PAUSE respectively. I think a little bit more explanation about the dual nature of the columns would solve the problem. Appendix C: Pending. Regards, Elwyn >=20 > On 2013-06-06 02:11, Elwyn Davies wrote: > > I am an additional Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > >=20 > > . > >=20 > > Please resolve these comments along with any other Last Call comments > > you may receive. > >=20 > > Document: draft-ietf-mmusic-rfc2326bis > > Reviewer: Elwyn Davies > > Review Date: 5 June 2013 > > IETF LC End Date: 5 JUne 2013 > > IESG Telechat date: (if known) - > >=20 > > Summary: > > Almost ready. Generally this is an excellent and well written document= , > > particularly given its size. There are a few minor issues to sort out > > mainly at the nit level and some consistency issues to fix up. The two > > issues that I have brought out below are really at what the IESG would > > call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may > > well have already been cleared by the URI expert - the draft does not d= o > > itself any favours here by failing to explain what the syntax changes > > are in s4.2; this raises immediate red flags that only start to fade a > > couple of hundred pages later. The rudimentary nature of the pipeline > > mechanism is carried over from RTSP 1.0. I'd like to be sure that this > > has been properly discussed in the WG as it looks pretty flaky to an > > outsider. There are several inconsistencies between various lists of > > headers that need sorting out and there is no definition of > > Proxy-Authorization in the ABNF. > >=20 > > There are also a fairly large number of editorial nits but these are al= l > > localized and trivial to fix. Finally I have't had time to review the > > appendices (maybe there will be a follow up). > >=20 > > Robert Sparks is the main gen-art reviewer for the document; he asked > > for additional eyes on the document given the size and his RAI > > background. Having (just) seen his review, I think we have both picked > > up on the URI scheme and pipeline issues. I am not sure that I concur > > with his view that there is significant normative material in the > > appendices - AFAICS the main protocol definition *is* in the main body > > of the document and the bits especiially in Appendices B and C are not > > the core of the protocol. However this is based on a very cursory > > glance through something like 75 pages of the document. However, I do > > concur with Robert's view that it needs a security expert to check the > > security stories. > >=20 > > Major(ish) issues: > > s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The= =20 > > last sentence of para 1 states that the 'details of the syntax' of the=20 > > URIs 'have been changed'. Is this a reasonable thing to do? Has this=20 > > been cleared with the URI expert reviewer? I am not entirely clear wha= t=20 > > the change involves and the draft doesn't explain exactly how the synta= x=20 > > has been altered and its consequences (if any) in s4.2. Some details > > are finally given in s22.14. >=20 > These syntax changes where discussed in the reviews I got on the URI > list. That resulted in the explicitness in the template, but I forgot > about adding anything into Section 4.2. I see no issue with adding the > following clarification to Section 4.2: >=20 > The details of the syntax of "rtsp" and "rtsps" URIs has been changed > from RTSP 1.0. These changes are: >=20 > o Support for IPV6 literal in host part and future IP literals > through RFC 3986 defined mechanism. >=20 > o A new relative format to use in the RTSP protocol elements that is > not required to start with "/". >=20 > Neither should have any significant impact on interoperability. If > one is required to use IPv6 literals to reach an RTSP server, then > that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully > IPv6 capable protocol. Thus, RTSP 2.0 support will be needed anyway. > The second change will only occur in RTSP messages, that are > explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0 > only agent will not be required to parse this variant. >=20 > I hope this makes it clear that these syntax changes is unlikely to hurt > the interoperability. >=20 > >=20 > >=20 > > Minor issues: > > s11, para 3: I guess that the WG decided that sticking with the RTSP 1.= 0 > > model of sending requests and worrying about success of prior prior > > pipelined requests was the right answer. I would have thought that it > > might have been helpful to provide qualifiers on the Pipelined-Requests > > header that allowed subsequent requests to be suppressed unless the > > previous command resulted in one of a given set of status codes with a > > 'reset' option to 'restart' the pipeline. It strikes me that this woul= d > > avoid some irritating need to work out how to recover from arbitrary > > failures in a command chain in a client. > >=20 >=20 > I assume you mean this Section 12 paragraph: >=20 > If a pipelined request builds on the successful completion of one or > more prior requests the requester must verify that all requests were > executed as expected. A common example will be two SETUP requests > and a PLAY request. In case one of the SETUP fails unexpectedly, the > PLAY request can still be successfully executed. However, the > resulting presentation will not be as expected by the requesting > client, as only a single media instead of two will be played. In > this case the client can send a PAUSE request, correct the failing > SETUP request and then request it to be played. >=20 > I think I agree with your assessment, that it would have been nice. > However, we should have thought of that when we introduced this type of > pipelining 7 years ago. Making any changes to this at this stage is > counter productive. The reality is that all the "nice" features and > necessary clarifications has been retrofitted into RTSP 1.0 by the ones > that have been using RTSP 1.0. So changing anything will separate the > RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't > remember any substantial complaints about this issue. >=20 > I hope this resolves your comments. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From elwynd@folly.org.uk Fri Jun 7 08:40:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586AB21F9798; Fri, 7 Jun 2013 08:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBguRDe8Pqk6; Fri, 7 Jun 2013 08:40:14 -0700 (PDT) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id C662021F9732; Fri, 7 Jun 2013 08:40:07 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1Ukylo-0003mK-T1; Fri, 07 Jun 2013 16:40:05 +0100 From: Elwyn Davies To: Magnus Westerlund In-Reply-To: <51B1E8BD.80901@ericsson.com> References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> <1370607960.4596.9114.camel@mightyatom> <51B1E8BD.80901@ericsson.com> Content-Type: text/plain Organization: Folly Consulting Date: Fri, 07 Jun 2013 16:40:02 +0100 Message-Id: <1370619602.4596.9175.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Jun 2013 12:06:50 -0700 Cc: General Area Review Team , IETF discussion , "mmusic \(E-mail\)" , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 15:40:19 -0000 On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: > > Appendix F: I missed that the text/parameter format appeared in the > > examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the > > definitions of these methods what encodings are acceptable for the > > message bodies that may go with these methods and their responses. > > Exactly, that is intentional. These methods can use anything that has a > MIME type. Also it has HTTP's mechanisms for determining what formats > one supports. > > > Clearly the new text/parameter MIME format is one. Is it the only one? > > It is the only one defined by IETF for this purpose. That is why it is > in the appendix so that RTSP users shall have something to define the > parameters they want in. However, they have to accept the limitations of > a basic text format. > > > I guess you could use a application/json or an XML format but I guess > > these would also either have to be called out explicitly in the method > > descriptions or put in as feature extensions. This needs to be > > clarified in the method descriptions (s13). The upshot of all this is > > that I think Appendix F needs to be pulled back into Section 20 as > > currently it is the only way to encode the message bodies. > > I can agree that the format negotiation for the bodies of > GET/SET_PARAMETER is not clear. I will look at proposing some > improvements of the text related to the handling of method bodies and > their format negotiation. Good. I don't see where the server tells what formats it accepts for either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say anything about SET_PARAMETER. AFAICS the client could tell the server what formats it accepts as a side-effect of DESCRIBE but that's a bit arcane - and it is not clear how you would separate the formats for DESCRIBE from those for GET_PARAM and SET_PARAM. > > However, I am not pulling in Appendix F. It is an optional to use format > for parameter value pairs that can be used in these methods, it is not > required. Nor, does the specification define any parameters that are > transferred using this interface. The things that are in the appendix > are not core protocol, they represent either informational things, like > the examples and the state machine. The other appendices are normative > definitions of particular choices for things that can be combined or > used with RTSP, like RTP as media transport. > OK, it is possible to use GET_PARAM for basic requirements without using message bodies, so you can get away without defining a lowest common denominator format. However, the use of message bodies for SET_PARAM is RECOMMENDED so it seems a little odd not to ensure that server and client will have at least one format in common. (And its not as if we are dealing with a hugely complicated bit of spec for text/parameters! :-) ). Then, given the example in GET_PARAMETER it seems sensible to advise implementing text/parameters as the default for GET_PARAM also. /Elwyn From prvs=58703c4c02=christer.holmberg@ericsson.com Fri Jun 7 12:16:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7E21F9712 for ; Fri, 7 Jun 2013 12:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYiFRYy3XJt5 for ; Fri, 7 Jun 2013 12:16:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 43F8721F96ED for ; Fri, 7 Jun 2013 12:16:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-4a-51b2318c136c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0B.69.09795.C8132B15; Fri, 7 Jun 2013 21:16:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 21:16:28 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAACvn8mAAB7QFAAADmCWAAASCFY4= Date: Fri, 7 Jun 2013 19:16:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38501C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se> <51B21700.1020709@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvrW6P4aZAgyXrjC2unfnHaDF1+WMW ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7itklKLCkLzkzP07dL4M64N+svc8E89oqzhz+z NDDeYO1i5OSQEDCRWN6/ix3CFpO4cG89WxcjF4eQwGFGiV+/mxkhnMWMEktP7mXpYuTgYBOw kOj+pw3SICIQKtF2cR8jSJhZQF3i6uIgkLCwgIPElg2TWCFKHCUO/NrCBmH7SXw62c4CYrMI qEhs27MTzOYV8JW4dug3K8SqWUwSyxdOAktwCgRKHP40hxnEZgQ67vupNUwgNrOAuMStJ/OZ II4WkFiy5zwzhC0q8fLxP6jHFCV2nm1nhqjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYL ydhZSFpmIWmZhaRlASPLKkb23MTMnPRy802MwMg5uOW3wQ7GTffFDjFKc7AoifPq8y4OFBJI TyxJzU5NLUgtii8qzUktPsTIxMEJIrikGhh3SP3fkn7mk+Wms1vulyr3qCdyHpD5l9doKyf+ veXm5bX8l3cUlocnrwu9+GPtok+suwxD19lcFky4ttE9P3K1g7tUqOn36wfuPXU+8Ort75Jn etPCvNqdA6u+hUno96/qun5jz/rVHlGa7PYWmfFFgj7qaisYmxYelyxQffvz9Xmnn6evnNBW YinOSDTUYi4qTgQATku+8G8CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 19:16:39 -0000 Hi, >> Note that offers and answers may contain more than just one set of bundl= ed >> m-lines. They may contain unbundled m-lines, and multiple bundles. So th= e >> purpose of a particular offer may be complex, trying to satisfy differen= t >> needs for various parts of the SDP. That complicates making such a >> distinction. > > I thought about this, but forgot to followup. I think that it could > be possible for a single request to be a BSO for one group, which a > BRO for another. The labels are a convenience only, and provide a way > to provide guidance about how to handle offer/answer creation...scoped > only to the affected m-lines. I think that the complication is only a > complication insofar as it requires some text that highlights this. I agree. The scope of a BRO or BSO is only per individual BUNDLE group with= in an SDP Offer - not the whole SDP Offer. Regards, Christer From pkyzivat@alum.mit.edu Fri Jun 7 12:23:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4056721F964C for ; Fri, 7 Jun 2013 12:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnNdshFy3SrH for ; Fri, 7 Jun 2013 12:23:01 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1944A21F9412 for ; Fri, 7 Jun 2013 12:22:59 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id lP7J1l0021ZXKqc58XNzWM; Fri, 07 Jun 2013 19:22:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id lXNz1l0053ZTu2S3hXNzZL; Fri, 07 Jun 2013 19:22:59 +0000 Message-ID: <51B23312.4040902@alum.mit.edu> Date: Fri, 07 Jun 2013 15:22:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se>, <51B21700.1020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370632979; bh=PDQjkiODW1+BZ5ASsZrXRashwGSd8WVWuphTJNLi0LU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qgdWEc0LtqbBvPWsfPQTnd+5+dNEm/4TdXcacZ0/WpNaU+H3Ptlx5b+RdEMBx43T+ YeUqQQTdNa39C4zRFHC5Sckag178be/41UAyQc+n4Ym31PFmy5+JmBfOcv4CugtwS6 8t4eDC2156VIc84gImciVyCaXDzgRee7YdEaKbN6kiA3Luejo0bykJTAE84hEgcep2 j/OvpgqFvvNBc84BN4OPvcdlTKWK7U81CM/t9nIGxpwVtWK9Bq9tymeV5sS0AoJ0sN v1/9nrDpM2kC25vZJVpS7TEMeU85DSNK5Q2P4ZJ8Y5KZK+IBzpD+sLyIG2WjEjAvO8 MZ/grwYoBd8YQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 19:23:07 -0000 On 6/7/13 2:55 PM, Christer Holmberg wrote: > > Hi, > >>> After reading Paul's and Martin's comments, I am suggesting a change to the separation between BSO and BRO. >>> >>> Again, the names will be changed, but I'll leave that for now - but I DO like the Bundle Negotiation Offer (BNO) suggestion made by Martin :) >>> >>> In the current text, I separate between BSO and BRO pretty much based on the type address information in the "m=" lines of the SDP Offer. I have realized that it doesn't work very well. >>> >>> So, a new suggestion is that the separation is done based on the PURPOSE of the SDP Offer, NOT the type of address information in the "m=" lines (of course, in many cases they go hand-in-hand). >> >> Note that offers and answers may contain more than just one set of >> bundled m-lines. They may contain unbundled m-lines, and multiple >> bundles. So the purpose of a particular offer may be complex, trying to >> satisfy different needs for various parts of the SDP. That complicates >> making such a distinction. > > I guess it should be more clear that the definition is per bundle group within an SDP Offer, not necessairly the whole SDP body. I think the BSO must be determined over the entire O/A, not on a per-bundle basis. Otherwise the new offer is being sent with the intent to change *something* in it. >>> A BSO would be used ONLY for synchronization purpose, or making the SDP "stable". >> >> So this is just intended to describe the case where both ends have >> reached agreement on what they want to do, and don't want to change >> that, but the agreed pair of SDPs doesn't describe that agreement in the >> standard way? This additional O/A is used *solely* to put things into >> the standardized representation? > > Correct. > >> And if things end up in the standardized form without a BSO then one is >> not sent? > > Correct. > >> If so, then the receiver of the offer can tell that it is a BSO by >> analyzing it in the context of what the prior O/A had been. But there is >> no particular reason to do so, because it doesn't affect the behavior of >> the answerer. >> >> The value of the term must be simply to facilitate the description of >> offerer behavior. Following an O/A exchange that has left things in a >> non-canonical form, the offerer in that exchange is required to send a BSO. >> >> And I think the need for a BSO can indeed only be determined after >> receiving the answer. It is largly driven by the structure of the offer, >> but even so, certain answers may eliminate the need for the BSO. > > The reason for sending the BSO is not the Answerer - it is because of intermediaries that don't understand BUNDLE. I realize that the BSO is not being sent for the benefit of the answerer. My point was that the need to send the BSO is determined by the offerer, but cannot be determined until the answer has been received. >>> A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify "m=" lines and/or the bundle address. So, even an with >>> the same address information in each "m=" line could be an BRO, if the purpose is to modify the SDP in one way or another. >> >> So an offer that *changes* *anything* is a BRO, while one that changes >> nothing but puts things in the correct form is called a BSO. > > Correct. > >> That definition might work from the point of view of the offer. >> But note that even with a BSO the answer might change something. >> >> E.g. the answerer could change its bundle address, or it could reject >> some m-lines. (But I don't think it is possible for the answer to do >> anything valid that will prevent the intent of the BSO from being achieved.) > > I think that's ok. > > Because, even without BUNDLE, if an Offerer sends a SIP re-INVITE/UPDATE with an unmodified SDP Offer (e.g. because of session-timer usage), the SDP Answer may still change. > > One question, though, is whether the SDP o= line version number should be incremented when sending a BSO (assuming everything, including the non-BUNDLE stuff, in the SDP body is unmodified). From a pure SDP perspective, the address information for certain "m=" lines may have changed, eventhough from a BUNDLE perspective it is just about synchronization. I've always had a problem with o-lines. AFAICT the only value they bring (at least in the context of O/A) is as an optimization: if the new one says via the o-line that it is identical to the prior one then perhaps you can simply not process it. But I think an implementation would be insane to trust this. There is too much of a chance that there will be a changed SDP with an unchanged o-line. So I think a reasonable implementation will at least do a comparison of the whole body before optimizing for an unchanged one. (Or else it will do any optimization on an element by element basis.) BUT, on the off chance that anybody does use the o-line that way, then I think it must be marked as changed. It isn't identical, and the reason its not, and is being sent, is because of the changes it contains. Those changes may have different significance to intermediaries than to the UAS, but its important that the difference be recognized. If *nothing* is changed, then there is no reason to send the BSO. Of course the *answer* to the BSO most likely will be unchanged from the prior answer, so the o-line for that ought to reflect that. Thanks, Paul From bernard_aboba@hotmail.com Fri Jun 7 15:51:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08A621F99DB for ; Fri, 7 Jun 2013 15:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2CCIuBr9Ihl for ; Fri, 7 Jun 2013 15:51:35 -0700 (PDT) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id 6121421F99D3 for ; Fri, 7 Jun 2013 15:51:35 -0700 (PDT) Received: from BLU169-W68 ([65.55.116.74]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jun 2013 15:51:34 -0700 X-TMN: [EJ7tNNkKuf2iTTe/XIHsJ1uQXHWcy+5g] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_965dafed-8448-485c-bfd6-94c995446c3b_" From: Bernard Aboba To: Paul Kyzivat Date: Fri, 7 Jun 2013 15:51:34 -0700 Importance: Normal In-Reply-To: <51B20CD1.5090002@alum.mit.edu> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, , <51B20CD1.5090002@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2013 22:51:34.0694 (UTC) FILETIME=[8F7C8460:01CE63D1] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 22:51:41 -0000 --_965dafed-8448-485c-bfd6-94c995446c3b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:=20 =20 > So my question is still: is it unreasonable to expect an answer to be=20 > returned and confirmed before the UAS starts sending media? This can=20 > happen as early as the commencement of alerting at the UAS. That means=20 > requiring 1.5 round trips over the signaling channel before starting to=20 > send. It will very likely require more round trips than that over the=20 > media channel (because of ICE) before media can flow in any case. >=20 > Also=2C until the UAC receives an answer it can't do ICE. So when ICE is= =20 > in use aren't you guaranteed to have had a chance to get those SSRCs=20 > from the UAS? =20 [BA] I think we need to distinguish the browser-browser use case from brows= er-gateway. By "can't do ICE" you mean "can't start connectivity checks". = However=2C connectivity checks only restrict the ability to send=2C not re= ceive. In the browser-browser use case=2C this should restrict either side= from sending until the Answer is received.=20 =20 However=2C in the browser-gateway case the gateway may only support ICE lit= e=2C so it will not send connectivity checks=2C only respond to them. As a= result=2C the gateway can send media once it receives the Offer=3B it is n= ot restricted from doing so by having to send and receive a response to a c= onnectivity check. Of course=2C it will not have media to send until it ac= tually gets some=2C but in the event that it receives early media=2C it doe= s seem possible that it could forward that media on to the browser before t= he Answer were to arrive.=20 =20 I guess the question is how much we care about preventing clipping in a cas= e like this. Note that Section 4.3.2 of the use case document does hint at= this=2C although it (and the requirements) don't explicitly point to a nee= d to support of "early media".=20 4.3.2.1. Description =20 =0A= =0A= Alice uses her web browser with a service something like Skype to be=0A= able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should=0A= be able to hear the initial prompts from the fedex IVR and when the=0A= IVR says press 1=2C there should be a way for Alice to navigate the=0A= IVR.=0A= =0A= =20 =20 = --_965dafed-8448-485c-bfd6-94c995446c3b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul said:
 =3B
>= =3B So my question is still: is it unreasonable to expect an answer to be <= br>>=3B returned and confirmed before the UAS starts sending media? This = can
>=3B happen as early as the commencement of alerting at the UAS. = That means
>=3B requiring 1.5 round trips over the signaling channel = before starting to
>=3B send. It will very likely require more round = trips than that over the
>=3B media channel (because of ICE) before m= edia can flow in any case.
>=3B
>=3B Also=2C until the UAC recei= ves an answer it can't do ICE. So when ICE is
>=3B in use aren't you = guaranteed to have had a chance to get those SSRCs
>=3B from the UAS?=
 =3B
[BA] I think we need to distinguish the browser-browser use= case from browser-gateway. =3B By "can't do ICE" you mean "can't start= connectivity checks". =3B However=2C connectivity checks only restrict= the ability to send=2C not receive. =3B In the browser-browser use cas= e=2C this should restrict either side from sending until the Answer is rece= ived.
 =3B
However=2C in the browser-gateway case the gateway ma= y only support ICE lite=2C so it will not send connectivity checks=2C only = respond to them. =3B As a result=2C the gateway can send media once it = receives the Offer=3B it is not restricted from doing so by having to send = and receive a response to a connectivity check. =3B Of course=2C it wil= l not have media to send until it actually gets some=2C but in the event th= at it receives early media=2C it does seem possible that it could forward t= hat media on to =3Bthe browser before the Answer were to arrive.
&n= bsp=3B
I guess the question is how much we care about preventing clippin= g in =3Ba case like this. =3B Note that Section 4.3.2 of the use ca= se document does hint at this=2C although it (and the requirements) don't e= xplicitly point to a need to support of "early media".

 =3B

4.3.2.1. Description =3B
=0A= =0A= Alice uses her web browser with a service something like Skype to be=0A= able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should=0A= be able to hear the initial prompts from the fedex IVR and when the=0A= IVR says press 1=2C there should be a way for Alice to navigate the=0A= IVR.=0A= =0A=
 =3B

 =3B
= --_965dafed-8448-485c-bfd6-94c995446c3b_-- From pkyzivat@alum.mit.edu Fri Jun 7 16:15:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C752B21F99A9 for ; Fri, 7 Jun 2013 16:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9-Jg49Dz7A8 for ; Fri, 7 Jun 2013 16:15:37 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id E967B21F9936 for ; Fri, 7 Jun 2013 16:15:36 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id lbDr1l0031vXlb856bFbfG; Fri, 07 Jun 2013 23:15:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id lbFb1l00i3ZTu2S3dbFbDg; Fri, 07 Jun 2013 23:15:35 +0000 Message-ID: <51B26996.1090006@alum.mit.edu> Date: Fri, 07 Jun 2013 19:15:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, , <51B20CD1.5090002@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370646935; bh=JDx6KOzSD35i7o04U2akRelQNSRdLiZc0LAnY33Q9FM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hCiUZ5w5OmBpXbG0kxbg10kmczfDPWzMhPD55JJmdCxcCJIfeMwp2QgUUpfifUymz 4ky/sT8bryr6VgLhUSzM81hwHBFvfswThXjDN+2M+bcNoWwAxsm3FvSInMPK0unfor +e365hv2ieViae33Tbr5qajP2sg8ls5+F2Zrc+xY58pfYPCiu6//kgoeQL2C5bDVmx elNHiSLmIPbYG6LjrkAhosTnpkH08yLfaXtvmRHysjVFL1OxNofWlvE3+RK2jhS61I pOx9hC0v1prqK/Cb3gE4mzC25I4lzgPMkBG36MweEWpq2Nn6P1d/mJH1n9RAu3gJ41 otVsrhGlI9XnA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 23:15:41 -0000 On 6/7/13 6:51 PM, Bernard Aboba wrote: > Paul said: > > > So my question is still: is it unreasonable to expect an answer to be > > returned and confirmed before the UAS starts sending media? This can > > happen as early as the commencement of alerting at the UAS. That means > > requiring 1.5 round trips over the signaling channel before starting to > > send. It will very likely require more round trips than that over the > > media channel (because of ICE) before media can flow in any case. > > > > Also, until the UAC receives an answer it can't do ICE. So when ICE is > > in use aren't you guaranteed to have had a chance to get those SSRCs > > from the UAS? > > [BA] I think we need to distinguish the browser-browser use case from > browser-gateway. By "can't do ICE" you mean "can't start connectivity > checks". However, connectivity checks only restrict the ability to > send, not receive. In the browser-browser use case, this should > restrict either side from sending until the Answer is received. > > However, in the browser-gateway case the gateway may only support ICE > lite, so it will not send connectivity checks, only respond to them. As > a result, the gateway can send media once it receives the Offer; it is > not restricted from doing so by having to send and receive a response to > a connectivity check. Of course, it will not have media to send until > it actually gets some, but in the event that it receives early media, it > does seem possible that it could forward that media on to the browser > before the Answer were to arrive. > > I guess the question is how much we care about preventing clipping in a > case like this. Note that Section 4.3.2 of the use case document does > hint at this, although it (and the requirements) don't explicitly point > to a need to support of "early media". There is a big difference between clipping for one second until the 183 is received, and clipping until the phone is answered and a 200 received. But I was suggesting that we couple a requirement for PRACK with BUNDLE, and say that media should not be sent until the PRACK is received. So then there won't be clipping at all. (According to a formal definition of clipping. In practice it doesn't matter whether the audio was dropped by the receiver or dropped by the sender.) Thanks, Paul > 4.3.2.1 > . > Description > > Alice uses her web browser with a service something like Skype to be > able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should be > able to hear the initial prompts from the fedex IVR and when the IVR > says press 1, there should be a way for Alice to navigate the IVR. > > > From fluffy@iii.ca Fri Jun 7 21:11:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDAF21E804B for ; Fri, 7 Jun 2013 21:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd4b6nEFlH0Z for ; Fri, 7 Jun 2013 21:11:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3021F93D2 for ; Fri, 7 Jun 2013 21:11:38 -0700 (PDT) Received: from [10.70.232.148] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9891922E1FA; Sat, 8 Jun 2013 00:11:31 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51B20CD1.5090002@alum.mit.edu> Date: Sat, 8 Jun 2013 11:11:28 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B1A3343-65B7-40B0-B863-04B92440CCDB@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> <51AF6490.1040409@alum.mit.edu> <51B20CD1.5090002@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 04:11:54 -0000 On Jun 7, 2013, at 11:39 PM, Paul Kyzivat wrote: > On 6/6/13 1:41 AM, Cullen Jennings wrote: >>=20 >> On Jun 5, 2013, at 11:17 PM, Paul Kyzivat = wrote: >>=20 >>>> And it is likely to receive RTP packets before it receives an = answer in some important scenarios. >>>=20 >>> You keep saying that. But is it really true when ICE is used? >>> Need it be true even without ICE? After all, bundle is new usage, so = we can demand new behavior when using it. So requiring a reliable = provisional with an answer before sending media doesn't seem so = unreasonable. >>=20 >> I'm assuming that some applications will bring up a data channel = (using ICE), as soon as the far end starts alerting the user so this = will be done by the time the far end users agrees to send media. At that = point it would be nice to start sending media with no clipping. That = allows all the ICE setup time to disappear from the media clipping = latency problem. >>=20 >> I realize lots of applications will not work this way. >=20 > We're mixing apples and oranges here I think. >=20 > In a pure sip environment there probably won't be a data channel, = except for CLUE. But perhaps CLUE is what we should be considering when = we are talking about bundle in a pure sip environment. >=20 > Even webrtc won't always be using a data channel. >=20 > In cases where there is a data channel, I don't know how much data = will be exchanged over it before the "alerting" is done and the = connection acknowledged. I certainly want that to be very constrained. = So I'm not sure what the relevance of the data channel is to this = discussion. I don't think it is constrained. A JS app can bring up the data channel = and never alert or get any consent from the end user if there is no = camera or microphone involved. People are thinking of using this to do = P2PLive style video distribution among other things. If you go back to = my high / mid / low path slides from a way back, you can see I want to = bring up a data channel than use that data channel to pass back and = forth any updated offer / answers so that they are direct and don't add = extra load to the web server. All of this could happen before any = alerting even started.=20 From fluffy@iii.ca Fri Jun 7 21:11:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A185621F84B4 for ; Fri, 7 Jun 2013 21:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLELcxB20+VK for ; Fri, 7 Jun 2013 21:11:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD421F944F for ; Fri, 7 Jun 2013 21:11:41 -0700 (PDT) Received: from [10.70.232.148] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B110C22E253; Sat, 8 Jun 2013 00:11:37 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51B20D64.7050600@alum.mit.edu> Date: Sat, 8 Jun 2013 11:11:33 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 04:11:57 -0000 On Jun 7, 2013, at 11:42 PM, Paul Kyzivat wrote: > And then can't we demand that to support BUNDLE you must also support = PRACK? I think you will find the people that have not implemented PRACK still = don't want to implement PRACK. I know there is no way I would want to = mandate the complexity of PRACK just to do bundle. =20 From fluffy@iii.ca Fri Jun 7 21:44:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644B821F8F6E for ; Fri, 7 Jun 2013 21:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1H0mMAWpSEw for ; Fri, 7 Jun 2013 21:44:22 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3036C21F8F6D for ; Fri, 7 Jun 2013 21:44:21 -0700 (PDT) Received: from [10.70.232.148] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 15CC922E253; Sat, 8 Jun 2013 00:44:12 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Sat, 8 Jun 2013 11:44:10 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> , <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> To: Bernard Aboba X-Mailer: Apple Mail (2.1503) Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2013 04:44:28 -0000 I think everyone is on board with the fact that RTP represents what you = would call an envelope from a congestion point of view. Exactly what can = be changed inside that envelope and how might be a question and but that = seems a very different one than the plan A / plan B discussion. = Regardless of what happens with envelopes and congestion control, both = plan A and B don't change and work with that answer.=20 more inline =85=20 On Jun 7, 2013, at 2:31 AM, Bernard Aboba = wrote: > In a highly congested environment, signaling will also be likely to be = disrupted. Therefore if signaling is necessary for a sender to reduce = the sending rate (e.g. for example, in order to reduce resolution or = framerate), then that rate reduction would itself be disrupted by = congestion, preventing the sender from reducing rate, and thereby = potentially resulting in congestive collapse.=20 Sure, I agree. I would say it as when we need to reduce the sending rate = rapidly due to significant congestion, relying on round trips of = signaling to do this may be too slow.=20 > =20 > The solution to this, which has been widely implemented, is to enable = rate reductions (such as removal of simulcast or layered streams) = without a dependency on signaling. This is possible because the initial = O/A exchange focuses on negotiating the *envelope* of acceptable = resolutions, frame rates, streams, etc. rather than attempting to = control what is actually being sent in realtime. As a result, the = sender can reduce rate very quickly by dropping streams, with no = signaling dependency. Of course. Agree > =20 > It would appear to me that both Plan A and Plan B use signaling not = just to control the envelope of acceptable configurations, but to = determine what is actually being sent at a given moment. This is the part I strongly disagree with. I think both plan A and B = allow any type of control that is acceptable in RTP / SDP for this = including the use of RTCP. I can't see how plan A / B have anything to = do with this.=20 > If an O/A exchange is required for a sender to drop a stream, rapid = adaptation (including congestion control) is hampered.=20 No O/A is request to stop sending RTP packets on a given stream. Plan A = / B have nothing to do with that one way or another. > =20 > =20 >=20 > =20 > > Subject: Congestion controll=20 > > From: fluffy@iii.ca > > Date: Thu, 6 Jun 2013 12:46:20 +0700 > > CC: fandreas@cisco.com; ari.keranen@ericsson.com; mmusic@ietf.org > > To: bernard_aboba@hotmail.com > >=20 > >=20 > > On Jun 5, 2013, at 9:41 AM, Bernard Aboba = wrote: > >=20 > > > As they stand, both Plan A nor Plan B result in O/A exchanges that = aren't needed and will break congestion control > >=20 > > Bernard - that's a pretty strong statement. Uh, you want to explain = how either plan A or B break congestion control? > >=20 > >=20 From pkyzivat@alum.mit.edu Sun Jun 9 10:03:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C026121F826B for ; Sun, 9 Jun 2013 10:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShKkORnwACIs for ; Sun, 9 Jun 2013 10:03:35 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6576E21F8613 for ; Sun, 9 Jun 2013 10:03:33 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id mGyQ1l0030vyq2s55H3ZC6; Sun, 09 Jun 2013 17:03:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id mH3Y1l0143ZTu2S3RH3Y72; Sun, 09 Jun 2013 17:03:33 +0000 Message-ID: <51B4B564.5050503@alum.mit.edu> Date: Sun, 09 Jun 2013 13:03:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> <51AF6490.1040409@alum.mit.edu> <51B20CD1.5090002@alum.mit.edu> <9B1A3343-65B7-40B0-B863-04B92440CCDB@iii.ca> In-Reply-To: <9B1A3343-65B7-40B0-B863-04B92440CCDB@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370797413; bh=F/MF6aNity7Led8tSVNW/MnIdXF0CHsBdPbo7cE2wyo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NyY8sXT4e/ZVHoCnP/uh9PZ9TWvF8Ix4zReDkiGSAhpPWASN8OcgkNthPW1ezVIES txWJcydX9wdJMAC04DBoKevlxI23rthrY+okkCXbU8o7w3p9My0gj4zgKdjUwcyWOJ NHo5KBMYfpQfLrzfMqB/O7beYuLZGVgDX9QgtKkrO0hVnH2Mx1GUooNFyfprxf/41e ko1KZVNds92VApgqn3cn3aP7nE3EnkIehkcS6P+AXfYk3RoEDF0VjF7Eh5OW62DXsW qbA67cEzwyhFu9JOJfSELRRdrw4nhLVtGIeWuUv9+l5cbrUFocz9xiNOFEEm6n+GsM QdeD1vaIwT91A== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 17:03:40 -0000 On 6/8/13 12:11 AM, Cullen Jennings wrote: > > On Jun 7, 2013, at 11:39 PM, Paul Kyzivat wrote: > >> On 6/6/13 1:41 AM, Cullen Jennings wrote: >>> >>> On Jun 5, 2013, at 11:17 PM, Paul Kyzivat wrote: >>> >>>>> And it is likely to receive RTP packets before it receives an answer in some important scenarios. >>>> >>>> You keep saying that. But is it really true when ICE is used? >>>> Need it be true even without ICE? After all, bundle is new usage, so we can demand new behavior when using it. So requiring a reliable provisional with an answer before sending media doesn't seem so unreasonable. >>> >>> I'm assuming that some applications will bring up a data channel (using ICE), as soon as the far end starts alerting the user so this will be done by the time the far end users agrees to send media. At that point it would be nice to start sending media with no clipping. That allows all the ICE setup time to disappear from the media clipping latency problem. >>> >>> I realize lots of applications will not work this way. >> >> We're mixing apples and oranges here I think. >> >> In a pure sip environment there probably won't be a data channel, except for CLUE. But perhaps CLUE is what we should be considering when we are talking about bundle in a pure sip environment. >> >> Even webrtc won't always be using a data channel. >> >> In cases where there is a data channel, I don't know how much data will be exchanged over it before the "alerting" is done and the connection acknowledged. I certainly want that to be very constrained. So I'm not sure what the relevance of the data channel is to this discussion. > > I don't think it is constrained. A JS app can bring up the data channel and never alert or get any consent from the end user if there is no camera or microphone involved. People are thinking of using this to do P2PLive style video distribution among other things. If you go back to my high / mid / low path slides from a way back, you can see I want to bring up a data channel than use that data channel to pass back and forth any updated offer / answers so that they are direct and don't add extra load to the web server. All of this could happen before any alerting even started. I agree its not technically constrained. But still I think the app needs to be circumspect in the sort of data it passes prior to getting some sort of confirmation from the user. Stuff that is just used to finish setup of communication is probably innocuous. But even that ought to be subject to policy control. I may wish to appear unavailable until I answer the alert. Thanks, Paul From pkyzivat@alum.mit.edu Sun Jun 9 10:07:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902A721F8916 for ; Sun, 9 Jun 2013 10:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUqEbucn0ktm for ; Sun, 9 Jun 2013 10:07:25 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 9268021F8A68 for ; Sun, 9 Jun 2013 10:07:25 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id mGZm1l0010mv7h057H7Rvc; Sun, 09 Jun 2013 17:07:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id mH7Q1l01Z3ZTu2S3XH7Q8A; Sun, 09 Jun 2013 17:07:25 +0000 Message-ID: <51B4B64B.1050101@alum.mit.edu> Date: Sun, 09 Jun 2013 13:07:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370797645; bh=vhUKnqaDMnp8ywYRgLRurycq2ApkUC/uJnLoEUxN1Ys=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UWZF7vsETN0EKHg+vRpfO4KyQsnUsQAEw7B4nZ/HWoc5Diq1Nf6izfAHwqrTzhL+k 2XOaIvk6whlEeoxFKJeMlVrZNCCj95BRxi8hn2DpyDkQunF/uefvetpJgsmScLlPxA GAC4kd2yrb8yi75omi6/9u/wwcc45xCZdwKkSu6C/jI7H/KyOfAxjc+l98k0FpiwnW Ko1p2NCDbuKSWKnZC5ZjteqlH7xFe7ZQoqQ/MNTD7z2+5d5mKCdDU59Z/1DMtmf2h2 b3h/PW/7Npn8hftw5WU9pvawRVVwpRaHn3YZp9O5xfFX4PLj+J+tE86kUVrNZWRT/P lwKhxTQoUHdhA== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 17:07:31 -0000 On 6/8/13 12:11 AM, Cullen Jennings wrote: > > On Jun 7, 2013, at 11:42 PM, Paul Kyzivat wrote: > >> And then can't we demand that to support BUNDLE you must also support PRACK? > > I think you will find the people that have not implemented PRACK still don't want to implement PRACK. I know there is no way I would want to mandate the complexity of PRACK just to do bundle. They are willing to implement BUNDLE, and probably ICE and DTLS/SRTP, and perhaps RTCWEB, but they find PRACK undesirable to implement??? I have no sympathy! Its time to join the 21st century. I see no reason to struggle for ways to work around that if mandating PRACK would solve the problem. Thanks, Paul From bernard_aboba@hotmail.com Sun Jun 9 10:32:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C64A21F85B8 for ; Sun, 9 Jun 2013 10:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWWG16pCr2K6 for ; Sun, 9 Jun 2013 10:32:31 -0700 (PDT) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0B21F85F7 for ; Sun, 9 Jun 2013 10:32:31 -0700 (PDT) Received: from BLU169-W17 ([65.55.116.74]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Jun 2013 10:32:31 -0700 X-TMN: [A7RBcDAr+XX0M41XPHhrnO5W3s9aHt6P] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ce757001-6943-4093-bba7-0f76dcfa8945_" From: Bernard Aboba To: Paul Kyzivat , Cullen Jennings Date: Sun, 9 Jun 2013 10:32:30 -0700 Importance: Normal In-Reply-To: <51B4B64B.1050101@alum.mit.edu> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se>, <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, , <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, , <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se>, <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org>, <51A3B070.1090006@alum.mit.edu>, , <51AF5EEE.8080904@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>, <51AF6BB9.3010807@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se>, <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca>, <51B20D64.7050600@alum.mit.edu>, ,<51B4B64B.1050101@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jun 2013 17:32:31.0270 (UTC) FILETIME=[51F15460:01CE6537] Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 17:32:37 -0000 --_ce757001-6943-4093-bba7-0f76dcfa8945_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:=20 > I see no reason to struggle for ways to work around that if mandating=20 > PRACK would solve the problem. [BA] "solving the problem" requires more than just PRACK. In a WebRTC imp= lementation=2C I believe that the requirement is to be able to receive medi= a before setRemoteDescription is called. Unless that functionality (whic= h is not specifically called out in the use case document) is implemented= =2C it doesn't matter whether PRACK is supported or not. =20 = --_ce757001-6943-4093-bba7-0f76dcfa8945_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul said:

>=3B I= see no reason to struggle for ways to work around that if mandating
&g= t=3B PRACK would solve the problem.

[BA] =3B "solving the proble= m" requires more than just PRACK. =3B In a WebRTC implementation=2C I b= elieve that the requirement is to be able to receive media before setRemote= Description is called.  =3B Unless that =3B functionality (which is= not specifically called out in the use case document) is implemented=2C it= doesn't matter whether PRACK is supported or not. =3B
=
= --_ce757001-6943-4093-bba7-0f76dcfa8945_-- From bernard_aboba@hotmail.com Sun Jun 9 10:49:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423DF21F947C for ; Sun, 9 Jun 2013 10:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTt5-iKMWYRl for ; Sun, 9 Jun 2013 10:49:01 -0700 (PDT) Received: from blu0-omc3-s26.blu0.hotmail.com (blu0-omc3-s26.blu0.hotmail.com [65.55.116.101]) by ietfa.amsl.com (Postfix) with ESMTP id D712C21F93FB for ; Sun, 9 Jun 2013 10:48:53 -0700 (PDT) Received: from BLU169-W64 ([65.55.116.73]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Jun 2013 10:48:53 -0700 X-TMN: [2RFdc7QK2AW+2jF2SoO+5mM/LXkwstxn] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_15ff316e-ee5d-45ec-b3e9-8a0bf3070e65_" From: Bernard Aboba To: Paul Kyzivat Date: Sun, 9 Jun 2013 10:48:53 -0700 Importance: Normal In-Reply-To: <51B26996.1090006@alum.mit.edu> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, , <51B20CD1.5090002@alum.mit.edu> , <51B26996.1090006@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jun 2013 17:48:53.0926 (UTC) FILETIME=[9BA6BC60:01CE6539] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 17:49:07 -0000 --_15ff316e-ee5d-45ec-b3e9-8a0bf3070e65_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:=20 > There is a big difference between clipping for one second until the 183=20 > is received=2C and clipping until the phone is answered and a 200 receive= d. [BA] So you're saying it is sufficient to enable media once a 183 is receiv= ed=2C but not before? I believe that is consistent with the current WebRTC= API. The use case document isn't clear that this is the bar that is bein= g set=2C though. =20 One issue is what the WebRTC gateway will do if it gets media before the 18= 3. If it just forwards it on=2C then it will be dropped by the browser u= ntil the 183 shows up and setRemoteDescription is called. Should it buffer= it until the 183 arrives? > But I was suggesting that we couple a requirement for PRACK with BUNDLE= =2C=20 > and say that media should not be sent until the PRACK is received. So=20 > then there won't be clipping at all. [BA] Personally=2C I don't see PRACK as being required for BUNDLE=2C at lea= st in WebRTC uses. However=2C a WebRTC/SIP gateway probably should support = PRACK. =20 = --_15ff316e-ee5d-45ec-b3e9-8a0bf3070e65_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul said:

>=3B T= here is a big difference between clipping for one second until the 183
= >=3B is received=2C and clipping until the phone is answered and a 200 re= ceived.

[BA] So you're saying it is sufficient to enable media once = a 183 is received=2C but not before? =3B I believe that is consistent w= ith the current WebRTC API. =3B =3B The use case document isn't cle= ar that this is the bar that is being set=2C though. =3B

One is= sue is what the WebRTC gateway will do if it gets media before the 183.&nbs= p=3B =3B =3B If it just forwards it on=2C then it will be dropped b= y the browser until the 183 shows up and setRemoteDescription is called.&nb= sp=3B Should it buffer it until the 183 arrives?

>=3B But I was su= ggesting that we couple a requirement for PRACK with BUNDLE=2C
>=3B a= nd say that media should not be sent until the PRACK is received. So
&g= t=3B then there won't be clipping at all.

[BA] Personally=2C I don't= see PRACK as being required for BUNDLE=2C at least in WebRTC uses. However= =2C a WebRTC/SIP gateway probably should support PRACK. =3B

= --_15ff316e-ee5d-45ec-b3e9-8a0bf3070e65_-- From prvs=78725593e0=christer.holmberg@ericsson.com Sun Jun 9 11:13:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E373821F8A0B for ; Sun, 9 Jun 2013 11:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4eXiyYodSDt for ; Sun, 9 Jun 2013 11:13:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D921921F89FF for ; Sun, 9 Jun 2013 11:13:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-ef-51b4c5d2c184 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 37.BF.09795.2D5C4B15; Sun, 9 Jun 2013 20:13:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Sun, 9 Jun 2013 20:13:38 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAACvn8mAAB7QFAAAHB7kk///pOACAAzE39w== Date: Sun, 9 Jun 2013 18:13:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38693D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se>, <51B21700.1020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se>, <51B23312.4040902@alum.mit.edu> In-Reply-To: <51B23312.4040902@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6lo1sCDXYsMLKYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKG6bpMSSsuDM9Dx9uwTujCmftzAW7NKvuNe7grWBca9qFyMnh4SA icSdlhdMELaYxIV769m6GLk4hAQOM0ocbLvGAuEsZpT49WY2excjBwebgIVE9z9tEFNEQENi 0lY1EJNZQF3i6uIgkDHCAg4SWzZMYgWxRQQcJQ782sIGYYdJnHy6lhnEZhFQkdh8uwkszivg K7H42VWoTduZJI58u84CkuAU0JFYeuUMmM0IdNv3U2vA7mQWEJe49WQ+1M0CEkv2nGeGsEUl Xj7+xwphK0q0P21ghKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkb23MTMnPRy802MwBg5uOW3wQ7GTffFDjFKc7AoifPq8y4OFBJITyxJzU5NLUgtii8q zUktPsTIxMEJIrikGhgdbe2Xp1gdD7mcGxzp/pL9lN7p0w+q99aFL4rkkvTWjt5n/Y3JLy6h f80eywqO9lkmLcG7m/UzNJj3CqzfpV7zvmBftPUK9aOCX0/5qcmlpZytbWlL/H3svbakxyF1 vaOHXDau+OEffOXN7reuf0rvdh7j23/fySpp7Q2NOW0fv+T8fH40Tl6JpTgj0VCLuag4EQA7 ogEdZAIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 18:13:47 -0000 Hi, >>>> After reading Paul's and Martin's comments, I am suggesting a change t= o the separation between BSO and BRO. >>>> >>>> Again, the names will be changed, but I'll leave that for now - but I = DO like the Bundle Negotiation Offer (BNO) suggestion made by Martin :) >>>> >>>> In the current text, I separate between BSO and BRO pretty much based = on the type address information in the "m=3D" lines of the SDP Offer. I hav= e realized that it doesn't work very well. >>>> >>>> So, a new suggestion is that the separation is done based on the PURPO= SE of the SDP Offer, NOT the type of address information in the "m=3D" line= s (of course, in many cases they go hand-in-hand). >>> >>> Note that offers and answers may contain more than just one set of >>> bundled m-lines. They may contain unbundled m-lines, and multiple >>> bundles. So the purpose of a particular offer may be complex, trying to >>> satisfy different needs for various parts of the SDP. That complicates >>> making such a distinction. >> >> I guess it should be more clear that the definition is per bundle group = within an SDP Offer, not necessairly the whole SDP body. > > I think the BSO must be determined over the entire O/A, not on a > per-bundle basis. Otherwise the new offer is being sent with the intent > to change *something* in it. Sure, but you could change things which are non-BUNDLE related. For example, if you use ICE, you could combine the BUNDLE BSO with the ICE = Offer which informs the other endpoint of the selected candidates (sorry, I= don't remember all ICE terminology at the moment :) >>>> A BSO would be used ONLY for synchronization purpose, or making the SD= P "stable". >>> >>> So this is just intended to describe the case where both ends have >>> reached agreement on what they want to do, and don't want to change >>> that, but the agreed pair of SDPs doesn't describe that agreement in th= e >>> standard way? This additional O/A is used *solely* to put things into >>> the standardized representation? >> >> Correct. >> >>> And if things end up in the standardized form without a BSO then one is >>> not sent? >> >> Correct. >> >>> If so, then the receiver of the offer can tell that it is a BSO by >>> analyzing it in the context of what the prior O/A had been. But there i= s >>> no particular reason to do so, because it doesn't affect the behavior o= f >>> the answerer. >>> >>> The value of the term must be simply to facilitate the description of >>> offerer behavior. Following an O/A exchange that has left things in a >>> non-canonical form, the offerer in that exchange is required to send a = BSO. >>> >>> And I think the need for a BSO can indeed only be determined after >>> receiving the answer. It is largly driven by the structure of the offer= , >> but even so, certain answers may eliminate the need for the BSO. >> >> The reason for sending the BSO is not the Answerer - it is because of in= termediaries that don't understand BUNDLE. > > I realize that the BSO is not being sent for the benefit of the > answerer. My point was that the need to send the BSO is determined by > the offerer, but cannot be determined until the answer has been received. Correct. >>>>> A BRO would be used to negotiate the usage of BUNDLE, to add/remove/m= odify "m=3D" lines and/or the bundle address. So, even an with >>>>> the same address information in each "m=3D" line could be an BRO, if = the purpose is to modify the SDP in one way or another. >>>> >>> So an offer that *changes* *anything* is a BRO, while one that changes >>> nothing but puts things in the correct form is called a BSO. >> >> Correct. >> >>> That definition might work from the point of view of the offer. >>> But note that even with a BSO the answer might change something. >>> >>> E.g. the answerer could change its bundle address, or it could reject >>> some m-lines. (But I don't think it is possible for the answer to do >>> anything valid that will prevent the intent of the BSO from being achie= ved.) >> >> I think that's ok. >> >> Because, even without BUNDLE, if an Offerer sends a SIP re-INVITE/UPDATE= with an unmodified SDP Offer (e.g. because of session-timer usage), the SD= P Answer may still change. >> >> One question, though, is whether the SDP o=3D line version number should= be incremented when sending a BSO (assuming everything, including the non-= BUNDLE=20 >> stuff, in the SDP body is unmodified). From a pure SDP perspective, the = address information for certain "m=3D" lines may have changed, eventhough f= rom a BUNDLE perspective it is just about synchronization. > > I've always had a problem with o-lines. > AFAICT the only value they bring (at least in the context of O/A) is as > an optimization: if the new one says via the o-line that it is identical > to the prior one then perhaps you can simply not process it. > > But I think an implementation would be insane to trust this. There is > too much of a chance that there will be a changed SDP with an unchanged > o-line. So I think a reasonable implementation will at least do a > comparison of the whole body before optimizing for an unchanged one. (Or > else it will do any optimization on an element by element basis.) Actually, I have seen entities that do NOT perform any check if the o-line = value is unchanged :) > BUT, on the off chance that anybody does use the o-line that way, then I > think it must be marked as changed. It isn't identical, and the reason > its not, and is being sent, is because of the changes it contains. Those > changes may have different significance to intermediaries than to the > UAS, but its important that the difference be recognized. I agree. > If *nothing* is changed, then there is no reason to send the BSO. Correct. > Of course the *answer* to the BSO most likely will be unchanged from the > prior answer, so the o-line for that ought to reflect that. Correct. Regards, Christer From pkyzivat@alum.mit.edu Sun Jun 9 14:48:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8E21F898B for ; Sun, 9 Jun 2013 14:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpMWJb52TU4T for ; Sun, 9 Jun 2013 14:48:07 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 2747A21F8916 for ; Sun, 9 Jun 2013 14:48:06 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id mMKp1l0031ap0As5AMo68Z; Sun, 09 Jun 2013 21:48:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id mMo51l00K3ZTu2S3iMo5qY; Sun, 09 Jun 2013 21:48:06 +0000 Message-ID: <51B4F814.1050607@alum.mit.edu> Date: Sun, 09 Jun 2013 17:48:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, , <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, , <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se>, <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org>, <51A3B070.1090006@alum.mit.edu>, , <51AF5EEE.8080904@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>, <51AF6BB9.3010807@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se>, <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca>, <51B20D64.7050600@alum.mit.edu>, , <51B4B64B.1050101@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370814486; bh=0SECy0ayFTopx7LPpGWFPMn/aovLKN29LKoxM66nW9Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m4+TsH0N8wpAUD5kos7m0Zz6Ahmc6X1+aTNtVJPfvTB7J612lN+i9QFuEdErnF4CB QccNdjY+O+4xHpIYygdz7+Ge46Cgrp6WqJfoEHUaw51pOc2HymObdiV0so5jNnptv4 CnDPLz216dNmIPe7QZrSQrX1mdshkSFUoS+zhwXcmsRdLvCgrfhw/LZx804NXvbb8s fIoMlbl25sqol86EDOu1hognIxMptF7v7FIbQCqvo23561QPVty6shUOtGdeq8pdC7 Qora0xqj4qJI0AAzAX0bm9CU3OdOy3srSg/V20Gys3nRoDx1qMuMPeQDassTPu7G1L qgwLqbxkGse4w== Cc: "mmusic@ietf.org" , Cullen Jennings , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 21:48:13 -0000 On 6/9/13 1:32 PM, Bernard Aboba wrote: > Paul said: > > > I see no reason to struggle for ways to work around that if mandating > > PRACK would solve the problem. > > [BA] "solving the problem" requires more than just PRACK. In a WebRTC > implementation, I believe that the requirement is to be able to receive > media before setRemoteDescription is called. Unless that > functionality (which is not specifically called out in the use case > document) is implemented, it doesn't matter whether PRACK is supported > or not. I don't think it means that at all. The PRACK means a reliable provisional has been sent, and so SDP carried is a true answer rather than a hint about a future answer. If gatewaying between SIP and RTCWEB, that means that an ANSWER can be delivered rather than a PRANSWER. So AFAIK that means setRemoteDescription can be called. Thanks, Paul From pkyzivat@alum.mit.edu Sun Jun 9 15:02:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7FE21F9050 for ; Sun, 9 Jun 2013 15:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djaH5nOc8rGT for ; Sun, 9 Jun 2013 15:02:17 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 611FD21F9017 for ; Sun, 9 Jun 2013 15:02:17 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id mN1J1l0031vXlb858N2Gir; Sun, 09 Jun 2013 22:02:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id mN2G1l00T3ZTu2S3dN2GHk; Sun, 09 Jun 2013 22:02:16 +0000 Message-ID: <51B4FB67.7000600@alum.mit.edu> Date: Sun, 09 Jun 2013 18:02:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, , <51B20CD1.5090002@alum.mit.edu> , <51B26996.1090006@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370815336; bh=ThFTHFhLlNJwYTNKi0ROIRI4qgNO7eArGyL95IRc5cw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TYvoeQ2oXSrfaoZ4ZQ/TnFXyTOd4T8mMywV0AnOfiNNqb8zk4822Xr5rd+MIquGam Q6ydx+5Kkzqp+ju+EgBhW9BnXMPMnnFzhHUqoKyvj0HlDU68UQYXFSslqXTP3tFNA+ 3utUJ8tkiyeAms335XQAg+28SwfuBVARbTYEwu/2htJZz2Qt3NaxYQQjb+jcvGYc0e UlHb52t7BX5mgga160Lv1t7wjAFZF3gNXjUx1FlfahoFEpRg0yDuJiCufDE3IPMVAp j/KW9+hH/SZWXxs4iJW7p2orB8biJoLnLLDIFpwCgzS8XhlJP31kgbcVSHueXr9ETS m0hEPGFfefdew== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jun 2013 22:02:23 -0000 On 6/9/13 1:48 PM, Bernard Aboba wrote: > Paul said: > > > There is a big difference between clipping for one second until the 183 > > is received, and clipping until the phone is answered and a 200 received. > > [BA] So you're saying it is sufficient to enable media once a 183 is > received, but not before? I believe that is consistent with the current > WebRTC API. The use case document isn't clear that this is the bar > that is being set, though. I'm suggesting that in the case of BUNDLE, there be a requirement that media not be sent until an answer is known to have been received by the other end. Sending a reliable 183 and awaiting the PRACK before sending media would satisfy that. Presumably something similar can serve in a pure WebRTC environment. That will ensure no clipping. The objection I hear to this is that some don't implement PRACK. I'm just saying that we could require support for PRACK with support for BUNDLE. Then that argument becomes bogus. Then we can say that it is ok if something in the answer is needed for the offerer to demux incoming media. > One issue is what the WebRTC gateway will do if it gets media before the > 183. If it just forwards it on, then it will be dropped by the > browser until the 183 shows up and setRemoteDescription is called. > Should it buffer it until the 183 arrives? My proposal is that it should not transmit media until it knows the answer has been received. I don't care how it achieves that, but I imagine dropping it would be a good choice. Or, if people prefer, we could allow it to be sent, but allow the other end to drop it. But still expect the early answer so that the period when media is lost is brief. > > But I was suggesting that we couple a requirement for PRACK with BUNDLE, > > and say that media should not be sent until the PRACK is received. So > > then there won't be clipping at all. > > [BA] Personally, I don't see PRACK as being required for BUNDLE, at > least in WebRTC uses. However, a WebRTC/SIP gateway probably should > support PRACK. PRACK wouldn't be required in JSEP. But the equivalent would be expected - a quick ANSWER, before media is sent. Thanks, Paul From fluffy@iii.ca Sun Jun 9 20:48:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097521F8FA3 for ; Sun, 9 Jun 2013 20:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuECRzTiUpoY for ; Sun, 9 Jun 2013 20:48:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6076421F85C0 for ; Sun, 9 Jun 2013 20:48:25 -0700 (PDT) Received: from tky-vpn-client-231-131.cisco.com (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 451B122E253; Sun, 9 Jun 2013 23:48:19 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Mon, 10 Jun 2013 12:48:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <635C2BBF-DA79-430D-9911-A2001D171002@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se>, <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, , <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, , <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se>, <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org>, <51A3B070.1090006@alum.mit.edu>, , <51AF5EEE.8080904@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>, <51AF6BB9.3010807@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se>, <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca>, <51B20D64.7050600@alum.mit.edu>, , <51B4B64B.1050101@alum.mit.edu> To: Bernard Aboba X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 03:48:31 -0000 On Jun 10, 2013, at 2:32 AM, Bernard Aboba = wrote: > Paul said:=20 >=20 > > I see no reason to struggle for ways to work around that if = mandating=20 > > PRACK would solve the problem. >=20 > [BA] "solving the problem" requires more than just PRACK. In a = WebRTC implementation, I believe that the requirement is to be able to = receive media before setRemoteDescription is called. Unless that = functionality (which is not specifically called out in the use case = document) is implemented, it doesn't matter whether PRACK is supported = or not. =20 +1=20 and "work with 1-800-gofedex" is a deliberate wording so we can make = sure we work with at least one of the key use cases but at the same time = not drag in every weird corner case that has been imagined for early = media.=20 From fluffy@iii.ca Sun Jun 9 20:48:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622B321F85C0 for ; Sun, 9 Jun 2013 20:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhH+F3WiqqmG for ; Sun, 9 Jun 2013 20:48:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00221F8AF7 for ; Sun, 9 Jun 2013 20:48:25 -0700 (PDT) Received: from tky-vpn-client-231-131.cisco.com (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EB19C22E255; Sun, 9 Jun 2013 23:48:20 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <51B4B64B.1050101@alum.mit.edu> Date: Mon, 10 Jun 2013 12:48:19 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> <51B4B64B.1050101@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 03:48:31 -0000 On Jun 10, 2013, at 2:07 AM, Paul Kyzivat wrote: > On 6/8/13 12:11 AM, Cullen Jennings wrote: >>=20 >> On Jun 7, 2013, at 11:42 PM, Paul Kyzivat = wrote: >>=20 >>> And then can't we demand that to support BUNDLE you must also = support PRACK? >>=20 >> I think you will find the people that have not implemented PRACK = still don't want to implement PRACK. I know there is no way I would want = to mandate the complexity of PRACK just to do bundle. >=20 > They are willing to implement BUNDLE, and probably ICE and DTLS/SRTP, = and perhaps RTCWEB, but they find PRACK undesirable to implement??? >=20 > I have no sympathy! > Its time to join the 21st century. The other point of of vies is that PRACK is very complicated, has had = many interoperable issues, and for many deployments, unnecessary, we = should join the 21 century and deprecate it.=20 Now you are unlikely to chance your opinion, I am unlikely to change = mine, and there are many people in both camps. I will note a huge = percentage of SIP equipment does not support it or has an implantation = that does not meet the requirements of the RFC - particularly in the = many unspecified corner cases. I will also note that this discussion if = not new. There is a reason PRACK is an extension to SIP and not part of = 3261. It's optional - and lots of people don't need or want the option.=20= My proposed way to move forward is that we admit there are large use = bases in both camps and make sure we can do something that works for = both theses camps. So far we have managed to do that just fine.=20 From prvs=1873a61d1e=magnus.westerlund@ericsson.com Mon Jun 10 00:51:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2DD21F854D; Mon, 10 Jun 2013 00:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcjtc2IIixWP; Mon, 10 Jun 2013 00:51:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC721F8519; Mon, 10 Jun 2013 00:51:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-9c-51b58595c4b0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8A.1F.15700.59585B15; Mon, 10 Jun 2013 09:51:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Jun 2013 09:51:49 +0200 Message-ID: <51B585A7.7060109@ericsson.com> Date: Mon, 10 Jun 2013 09:52:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Elwyn Davies References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> <1370607960.4596.9114.camel@mightyatom> <51B1E8BD.80901@ericsson.com> <1370619602.4596.9175.camel@mightyatom> In-Reply-To: <1370619602.4596.9175.camel@mightyatom> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvre7U1q2BBstarCwufjnCbnH8wA52 i6uvPrNYPNs4n8Vi6vLHLA6sHl9PtrN4LFnyk8njy+XPbAHMUdw2SYklZcGZ6Xn6dgncGbN3 9jEWXJCrmPbfu4HxiUQXIyeHhICJxJ1Jn9khbDGJC/fWs3UxcnEICZxilFh+ZgsrhLOcUWL2 61csIFW8AtoSZ+csB7NZBFQlvu/5xApiswlYSNz80cgGYosKBEsc2b4Zql5Q4uTMJ2C2iICa xOavDxhBhjILrGOU+LGsCaxBWCBMYt6WbiaIbYcZJSZt2Ad2EyfQfe/7Glkg7pOU2PKiHSzO LKAnMeVqCyOELS/RvHU2M4gtBHRdQ1MH6wRGoVlIls9C0jILScsCRuZVjOy5iZk56eWGmxiB gX1wy2/dHYynzokcYpTmYFES59XjXRwoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MIqq VfHFeD+1rMxKDxN78chSxLnK+Pq289Hik4MWPGyK0NvMWSva9eun0smTgsWZkRsKxPL8UvPm n/BgdL2QsTH/h8jtlpsBO7VjWsW1BcxPXIjlMchftWa9Ws8vlsZXM9WfvvO6uvL7SeZQNgbb QyIeYdci7KbnPYpcNbHsskBBul/lG/X5SizFGYmGWsxFxYkA7ohWYD8CAAA= Cc: General Area Review Team , IETF discussion , "mmusic \(E-mail\)" , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 07:51:59 -0000 On 2013-06-07 17:40, Elwyn Davies wrote: > On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: > >>> Appendix F: I missed that the text/parameter format appeared in the >>> examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the >>> definitions of these methods what encodings are acceptable for the >>> message bodies that may go with these methods and their responses. >> >> Exactly, that is intentional. These methods can use anything that has a >> MIME type. Also it has HTTP's mechanisms for determining what formats >> one supports. >> >>> Clearly the new text/parameter MIME format is one. Is it the only one? >> >> It is the only one defined by IETF for this purpose. That is why it is >> in the appendix so that RTSP users shall have something to define the >> parameters they want in. However, they have to accept the limitations of >> a basic text format. >> >>> I guess you could use a application/json or an XML format but I guess >>> these would also either have to be called out explicitly in the method >>> descriptions or put in as feature extensions. This needs to be >>> clarified in the method descriptions (s13). The upshot of all this is >>> that I think Appendix F needs to be pulled back into Section 20 as >>> currently it is the only way to encode the message bodies. >> >> I can agree that the format negotiation for the bodies of >> GET/SET_PARAMETER is not clear. I will look at proposing some >> improvements of the text related to the handling of method bodies and >> their format negotiation. > Good. I don't see where the server tells what formats it accepts for > either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say > anything about SET_PARAMETER. AFAICS the client could tell the server > what formats it accepts as a side-effect of DESCRIBE but that's a bit > arcane - and it is not clear how you would separate the formats for > DESCRIBE from those for GET_PARAM and SET_PARAM. Yes, I think this negotiation should happen on per methods basis. >> >> However, I am not pulling in Appendix F. It is an optional to use format >> for parameter value pairs that can be used in these methods, it is not >> required. Nor, does the specification define any parameters that are >> transferred using this interface. The things that are in the appendix >> are not core protocol, they represent either informational things, like >> the examples and the state machine. The other appendices are normative >> definitions of particular choices for things that can be combined or >> used with RTSP, like RTP as media transport. >> > OK, it is possible to use GET_PARAM for basic requirements without using > message bodies, so you can get away without defining a lowest common > denominator format. However, the use of message bodies for SET_PARAM is > RECOMMENDED so it seems a little odd not to ensure that server and > client will have at least one format in common. (And its not as if we > are dealing with a hugely complicated bit of spec for > text/parameters! :-) ). Then, given the example in GET_PARAMETER it > seems sensible to advise implementing text/parameters as the default for > GET_PARAM also. Sure, I personally don't have any issue with making it at least SHOULD implement text/parameters. But from my horizon a forward pointer with the normative requirements is sufficient to accomplish that. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Mon Jun 10 03:48:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5314021F8551 for ; Mon, 10 Jun 2013 03:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2tSMIUok3ur for ; Mon, 10 Jun 2013 03:47:54 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C99FA21F8E93 for ; Mon, 10 Jun 2013 03:47:28 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5AAlLgu018055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Jun 2013 05:47:21 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5AAlEPY013349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 06:47:20 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 10 Jun 2013 06:47:12 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 12:47:06 +0200 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , Paul Kyzivat Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOZY1YOIhY09e1NUmwzjffFLQEKpkuxGgg Date: Mon, 10 Jun 2013 10:47:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B049607@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> <51B4B64B.1050101@alum.mit.edu> <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca> In-Reply-To: <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 10:48:03 -0000 "has an implantation that does not meet the requirements of the RFC - parti= cularly in the many unspecified corner cases" Does not make sense! Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: 10 June 2013 04:48 > To: Paul Kyzivat > Cc: mmusic@ietf.org WG > Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? >=20 >=20 > On Jun 10, 2013, at 2:07 AM, Paul Kyzivat wrote: >=20 > > On 6/8/13 12:11 AM, Cullen Jennings wrote: > >> > >> On Jun 7, 2013, at 11:42 PM, Paul Kyzivat > wrote: > >> > >>> And then can't we demand that to support BUNDLE you must also support > PRACK? > >> > >> I think you will find the people that have not implemented PRACK still > don't want to implement PRACK. I know there is no way I would want to > mandate the complexity of PRACK just to do bundle. > > > > They are willing to implement BUNDLE, and probably ICE and DTLS/SRTP, > and perhaps RTCWEB, but they find PRACK undesirable to implement??? > > > > I have no sympathy! > > Its time to join the 21st century. >=20 > The other point of of vies is that PRACK is very complicated, has had man= y > interoperable issues, and for many deployments, unnecessary, we should > join the 21 century and deprecate it. >=20 > Now you are unlikely to chance your opinion, I am unlikely to change mine= , > and there are many people in both camps. I will note a huge percentage of > SIP equipment does not support it or has an implantation that does not > meet the requirements of the RFC - particularly in the many unspecified > corner cases. I will also note that this discussion if not new. There is = a > reason PRACK is an extension to SIP and not part of 3261. It's optional - > and lots of people don't need or want the option. >=20 > My proposed way to move forward is that we admit there are large use base= s > in both camps and make sure we can do something that works for both these= s > camps. So far we have managed to do that just fine. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@siemens-enterprise.com Mon Jun 10 05:48:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF1B21F86D3 for ; Mon, 10 Jun 2013 05:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrkCcnE9sMUr for ; Mon, 10 Jun 2013 05:48:47 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 423BE21F84F5 for ; Mon, 10 Jun 2013 05:47:08 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B78D11EB8513; Mon, 10 Jun 2013 14:40:45 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 10 Jun 2013 14:40:42 +0200 From: "Stach, Thomas" To: Paul Kyzivat Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOY52wb18zsuOxAkCqqvPaFYXQyJkqulsAgAAGtQCAAsljgIAARsqAgAEU25A= Date: Mon, 10 Jun 2013 12:40:41 +0000 Message-ID: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, , <51B20CD1.5090002@alum.mit.edu> , <51B26996.1090006@alum.mit.edu> <51B4FB67.7000600@alum.mit.edu> In-Reply-To: <51B4FB67.7000600@alum.mit.edu> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 12:48:53 -0000 > -----Urspr=FCngliche Nachricht----- > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > Im Auftrag von Paul Kyzivat > Gesendet: Montag, 10. Juni 2013 00:02 > An: Bernard Aboba > Cc: mmusic@ietf.org > Betreff: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? >=20 > On 6/9/13 1:48 PM, Bernard Aboba wrote: > > Paul said: > > > > > There is a big difference between clipping for one=20 > second until the 183 > > > is received, and clipping until the phone is answered=20 > and a 200 received. > > > > [BA] So you're saying it is sufficient to enable media once a 183 is > > received, but not before? I believe that is consistent=20 > with the current > > WebRTC API. The use case document isn't clear that this is the bar > > that is being set, though. >=20 > I'm suggesting that in the case of BUNDLE, there be a=20 > requirement that=20 > media not be sent until an answer is known to have been=20 > received by the=20 > other end. Sending a reliable 183 and awaiting the PRACK=20 > before sending=20 > media would satisfy that. Presumably something similar can serve in a=20 > pure WebRTC environment. >=20 > That will ensure no clipping. >=20 > The objection I hear to this is that some don't implement PRACK. I'm=20 > just saying that we could require support for PRACK with support for=20 > BUNDLE. Then that argument becomes bogus. Just as well, we could require ICE together with BUNDLE and=20 re-use how ICE deals with reliability of provisional reponses. In the RTCWEB this would be a non-issue.=20 Environments that don't support ICE could still require PRACK. Regards Thomas >=20 > Then we can say that it is ok if something in the answer is=20 > needed for=20 > the offerer to demux incoming media. >=20 > > One issue is what the WebRTC gateway will do if it gets=20 > media before the > > 183. If it just forwards it on, then it will be dropped by the > > browser until the 183 shows up and setRemoteDescription is called. > > Should it buffer it until the 183 arrives? >=20 > My proposal is that it should not transmit media until it knows the=20 > answer has been received. I don't care how it achieves that, but I=20 > imagine dropping it would be a good choice. >=20 > Or, if people prefer, we could allow it to be sent, but allow=20 > the other=20 > end to drop it. But still expect the early answer so that the period=20 > when media is lost is brief. >=20 > > > But I was suggesting that we couple a requirement for=20 > PRACK with BUNDLE, > > > and say that media should not be sent until the PRACK is=20 > received. So > > > then there won't be clipping at all. > > > > [BA] Personally, I don't see PRACK as being required for BUNDLE, at > > least in WebRTC uses. However, a WebRTC/SIP gateway probably should > > support PRACK. >=20 > PRACK wouldn't be required in JSEP. But the equivalent would=20 > be expected=20 > - a quick ANSWER, before media is sent. >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From thomas.stach@siemens-enterprise.com Mon Jun 10 05:48:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD73C21F86C0 for ; Mon, 10 Jun 2013 05:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS+oc7-aViJL for ; Mon, 10 Jun 2013 05:48:47 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4261B21F90E4 for ; Mon, 10 Jun 2013 05:47:08 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9A28B1EB8532; Mon, 10 Jun 2013 14:20:50 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 10 Jun 2013 14:20:50 +0200 From: "Stach, Thomas" To: Paul Kyzivat , Cullen Jennings Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE? Thread-Index: AQHOY531b18zsuOxAkCqqvPaFYXQyJkrE8KAgAJrGICAAWOjYA== Date: Mon, 10 Jun 2013 12:20:49 +0000 Message-ID: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> <51B4B64B.1050101@alum.mit.edu> In-Reply-To: <51B4B64B.1050101@alum.mit.edu> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 12:48:53 -0000 > -----Urspr=FCngliche Nachricht----- > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > Im Auftrag von Paul Kyzivat > Gesendet: Sonntag, 09. Juni 2013 19:07 > An: Cullen Jennings > Cc: mmusic@ietf.org; Christer Holmberg > Betreff: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? >=20 > On 6/8/13 12:11 AM, Cullen Jennings wrote: > > > > On Jun 7, 2013, at 11:42 PM, Paul Kyzivat=20 > wrote: > > > >> And then can't we demand that to support BUNDLE you must=20 > also support PRACK? > > > > I think you will find the people that have not implemented=20 > PRACK still don't want to implement PRACK. I know there is no=20 > way I would want to mandate the complexity of PRACK just to do bundle. >=20 > They are willing to implement BUNDLE, and probably ICE and DTLS/SRTP,=20 > and perhaps RTCWEB, but they find PRACK undesirable to implement??? >=20 > I have no sympathy! > Its time to join the 21st century. >=20 > I see no reason to struggle for ways to work around that if mandating=20 > PRACK would solve the problem. When ICE development there were similar arguments with respect to PRACK. The consensus was the PRACK is recommended to be used. If PRACK was not supported the answer is repeated until the first connectiv= ity checks arrived at the answerer, meaning that the answer was received at= the offerer. Regards=20 Thomas >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From prvs=78731f4a8f=christer.holmberg@ericsson.com Mon Jun 10 05:49:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86B821F88AC for ; Mon, 10 Jun 2013 05:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crtL4O-kgJP7 for ; Mon, 10 Jun 2013 05:49:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6421F9349 for ; Mon, 10 Jun 2013 05:47:57 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-9c-51b5cafc6331 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 86.B5.18006.CFAC5B15; Mon, 10 Jun 2013 14:47:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 14:47:56 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAAMTTumA= Date: Mon, 10 Jun 2013 12:47:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3872B7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> In-Reply-To: <51B0BCA8.6050304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre6fU1sDDc4/1bWYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKG6bpMSSsuDM9Dx9uwTujF+H1jAWPOKouNTzjLGB8QlbFyMnh4SA icSO/nnsELaYxIV764HiXBxCAocZJVbv/MoO4SxhlLg7rYmli5GDg03AQqL7nzZIg4iAr8Sz x7fBBgkLOEhs2TCJFSLuKHHg1xY2kHIRASuJ/3czQMIsAqoSqy58YQaxeYFap247A1YuJJAv MWfuSxYQm1NAR+L//cVgNYxA93w/tYYJxGYWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/scKskpC QFFieb8cRLmOxILdn9ggbG2JZQtfQ60VlDg58wnLBEbRWUimzkLSMgtJyywkLQsYWVYxsucm ZuaklxttYgRGwsEtv1V3MN45J3KIUZqDRUmcV493caCQQHpiSWp2ampBalF8UWlOavEhRiYO ThDBJdXAuO1CwpldVU6R7/996I82u1LB82DH1ujctjv5XV9cp/4sD/iwwHvxgpZvuorhUy5M OeBa6p/nLcWwZ0eKY7yVeOLe/mvLLQ2nTm8TKjOptdn6QvOpxiWJq/2B6ybMqL/+xk7shtfF Kfe31+/sU7gvbbHg28YpExUCwi2F0yZNeXXgyq/Z7NtdliqxFGckGmoxFxUnAgCwpdpeVwIA AA== Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 12:49:39 -0000 Hi Paul, A comment on some of the stuff you sent earlier. > ISTM that all bundle offers must meet some constraints: > - some of the m-lines may have *unique* addresses > - all the rest, if any, must have a single *common* address. > - if any share a common address, then the first mid in the bundle group must identify one of them What is the reason for the third bullet? For example, assume I am adding a new "m=3D" line, with a unique address, a= nd I would like that address to become the new bundle address. In the existing "m=3D" lines, I couldn't keep the previously negotiated bun= dle address, because based on the third bullet the first mid would have to = identity one of those. So, I would have to either: 1) Assign a unique address to each of the existing "m=3D" lines, which woul= d then allow me to request the address of the new "m=3D" line to become the= new bundle address; or 2) I would have to assign the suggested new bundle address to ALL "m=3D" li= nes (the existing ones and the new one). Note that both 1) and 2) are allowed today. Regards, Christer From internet-drafts@ietf.org Mon Jun 10 08:07:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C457821E805E; Mon, 10 Jun 2013 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhmzVuxqL8ZO; Mon, 10 Jun 2013 08:07:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4721E8083; Mon, 10 Jun 2013 08:07:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130610150718.22749.59103.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2013 08:07:18 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:07:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Latching: Hosted NAT Traversal (HNT) for Media in Real-T= ime Communication Author(s) : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-02.txt Pages : 15 Date : 2013-06-10 Abstract: This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-latching-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From emil@sip-communicator.org Mon Jun 10 08:16:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8542921F9643 for ; Mon, 10 Jun 2013 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrHu4TGW87+p for ; Mon, 10 Jun 2013 08:16:15 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6421F9636 for ; Mon, 10 Jun 2013 08:16:13 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so1489803wgh.2 for ; Mon, 10 Jun 2013 08:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=FlHcEJxedcv9Z4ZZ2r0qVZarfmwrAez+D+wpkliweGU=; b=CZ9Rmp3tNTdg5dkNb+LA90Mcy6xJPyZDy0WgzbKoNOvSRwyurPkR5z+QB38S5PkyTL +dfqxh7B1qfft9UdTFzD++r5P6jMwBryKVUpxAhfbuGVRens9EtvP8S1OaanxgVFbwx+ tlHRyA85DZZvsB7+5hB+1H/a1XBE/CmmP3xb23W337QYZfO0g0y2MxovVZr5KkrI43FZ cV4J9WynouRAicOMNThg2dSwyIc0JbiwSjsDwTwP1gN0/9xftXeLX0qhWqkRu7tcVrfG ve2zCekPQ2y5EGtfhP/8udK2JCAK7kLtzqGjJGQ6OfICcEahxt2qiyWYmgiu+fNauEgF Ym1A== X-Received: by 10.194.119.195 with SMTP id kw3mr5812146wjb.64.1370877372976; Mon, 10 Jun 2013 08:16:12 -0700 (PDT) Received: from camionet.local (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id h8sm11956160wiz.9.2013.06.10.08.16.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 08:16:12 -0700 (PDT) Message-ID: <51B5EDB9.9030109@jitsi.org> Date: Mon, 10 Jun 2013 17:16:09 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnCn8aFXl+AyrY6G7JUN2U7JCVtJ3YC6qXfp8gpLNF0nSmknZmohOcVS7qs+48pMIRaGXcQ Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:16:16 -0000 Hey Cullen, On 30.05.13, 16:22, Cullen Jennings (fluffy) wrote: > > I think you need to start by putting in a reference to > > http://tools.ietf.org/html/rfc3424 Indeed. While the issues do not apply to hosted NAT traversal, the document does describe many of the reasons why people resorted to latching rather than using UNSAF. This is now mentioned and ref-ed in the introduction. > and discussing the issues it raises with relation to this draft. > > Next I think you need to add a specific attack where two people are > both behind the same CGN. This exact case was already described in the security considerations section: tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11 (last paragraph on the page) Cheers, Emil > CGN is becoming increasingly common and > will result in a large number of people having the same IP address. > Unless you have a solutions that secures this type of environment, I > think you should put harmful in the title and make the abstract very > clear that the IETF does not recommend this and this document > explains why. > > > > On May 11, 2013, at 3:59 AM, Emil Ivov wrote: > >> Hey Cullen, >> >> On 10.05.13, 23:53, Cullen Jennings (fluffy) wrote: >>> >>> I think the security section series underestimates the security >>> vulnerabilities this introduces. >> >> If you think we've missed any specific attacks we'd be happy to add >> them. >> >>> I'm very sad to see the IETF publishing this at all with anything >>> other than "This is not the recommended way to solve this >>> problem" and why. >> >> Well that's pretty much what we say: >> >> In no way does this document try to make a case for HNT or present >> it as a solution that is somehow better than alternatives such as >> ICE. The mechanisms described here, popular as they may be, are not >> necessarily considered best practice or recommended operation. >> >> The security considerations section also specifically outlines >> cases where DoS attacks can be performed even with the use of >> SRTP: >> >> For example, in cases where end-to-end encryption is used it would >> still be possible for an attacker to hijack a session despite the >> use of SRTP and perform a denial of service attack. >> >> The point was to show that in spite of all the threat mitigating >> techniques users of latching are still left vulnerable to those. >> >> I certainly don't understand IETF processes as well as you do, but >> it is my understanding that as an informational document the draft >> can only do so much and that making explicit recommendations for or >> against technologies was for Standards Track documents only. Am I >> wrong about this? >> >> My recollection of the Paris and Vancouver meetings (and a quick >> skim through the notes) is that this was also the direction chosen >> by the WG. >> >> Again, if you believe that additional text would make things >> clearer we are wide open to suggestions. >> >> Cheers, Emil >> >> >>> >>> >>> >>> >>> On May 7, 2013, at 12:29 PM, internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> Multiparty Multimedia Session Control Working Group of the >>>> IETF. >>>> >>>> Title : Latching: Hosted NAT Traversal (HNT) for >>>> Media in Real-Time Communication Author(s) : Emil Ivov >>>> Hadriel Kaplan Dan Wing Filename : >>>> draft-ietf-mmusic-latching-01.txt Pages : 14 Date : >>>> 2013-05-07 >>>> >>>> Abstract: This document describes behavior of signalling >>>> intermediaries in Real-Time Communication (RTC) deployments, >>>> sometimes referred to as Session Border Controllers (SBCs), >>>> when performing Hosted NAT Traversal (HNT). HNT is a set of >>>> mechanisms, such as media relaying and latching, that such >>>> intermediaries use to enable other RTC devices behind NATs to >>>> communicate with each other. This document is non-normative, >>>> and is only written to explain HNT in order to provide a >>>> reference to the IETF community, as well as an informative >>>> description to manufacturers, and users. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-mmusic-latching-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-01 >>>> >>>> >>>> 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 >>> >>> _______________________________________________ mmusic mailing >>> list mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- https://jitsi.org > > -- https://jitsi.org From pkyzivat@alum.mit.edu Mon Jun 10 09:43:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E027621F9948 for ; Mon, 10 Jun 2013 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tSY1WXBUaTx for ; Mon, 10 Jun 2013 09:43:00 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id F052621F9942 for ; Mon, 10 Jun 2013 09:42:56 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id mc8y1l0011c6gX853givGK; Mon, 10 Jun 2013 16:42:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id mgiv1l0083ZTu2S3jgivKK; Mon, 10 Jun 2013 16:42:55 +0000 Message-ID: <51B6020E.4010103@alum.mit.edu> Date: Mon, 10 Jun 2013 12:42:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, , <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, , <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se>, <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org>, <51A3B070.1090006@alum.mit.edu>, , <51AF5EEE.8080904@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>, <51AF6BB9.3010807@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se>, <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca>, <51B20D64.7050600@alum.mit.edu>, , <51B4B64B.1050101@alum.mit.edu> <635C2BBF-DA79-430D-9911-A2001D171002@iii.ca> In-Reply-To: <635C2BBF-DA79-430D-9911-A2001D171002@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370882575; bh=oXdxIZb1KO6zCERZBV7njKanGWQNUMqzQGWKZeuaCB8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ULEdP6lzdSoN3EHqWAZwnfQdS6yteXnM3kc+DkOBRsN17cVhAMM6aQqqvElIHxh5h ru9Exyb6oACy6yo2uJ3tFO4s4k8nImexJZsbX/LuxtYYodTpFZ7COV0M+8MXKLOYME nK1s1teZPsQ0hu3mPoQ9W0NTaHlSInyexN/66r97C/N+4JMRoBoQHazoX1S6mzxPFo yRVEOGB/cZrrOlLUX0HwpgeGJyB8D74ReJOqhPYItEs+slguuGAPVetg0giBf6d0Qf IoA/ylNwtXKx0M8VJ8chjil8AXGnT1nzT2o7aaWu6soFibOd0oEnzvaP9cFP8nvrhz FPswIcSUJOtlA== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 16:43:06 -0000 On 6/9/13 11:48 PM, Cullen Jennings wrote: > > On Jun 10, 2013, at 2:32 AM, Bernard Aboba wrote: > >> Paul said: >> >>> I see no reason to struggle for ways to work around that if mandating >>> PRACK would solve the problem. >> >> [BA] "solving the problem" requires more than just PRACK. In a WebRTC implementation, I believe that the requirement is to be able to receive media before setRemoteDescription is called. Unless that functionality (which is not specifically called out in the use case document) is implemented, it doesn't matter whether PRACK is supported or not. > > +1 > > and "work with 1-800-gofedex" is a deliberate wording so we can make sure we work with at least one of the key use cases but at the same time not drag in every weird corner case that has been imagined for early media. Here I guess you mean WebRTC work with 1-800-gofedex, right? That will either require the fedex web site to directly support WebRTC, or else somebody to deploy a WebRTC-pstn GW. I would expect that fedex would be one of the first to want to support WebRTC. And then they can make it work directly. I don't know who will deploy a general WebRTC-pstn GW, but probably some will. Then there are sub-cases for that: - would the GW be able to directly access 1-800-gofedex via a sip trunk that supports DTLS/SRTP and ICE, so that it need not process the media itself, and is dependent on it being processed downstream? - or will the WebRTC-pstn GW be processing media, so it can do the ICE and DTLS/SRTP and then transition to a "normal" SIP trunk or pstn GW? The main thing is to get a quick answer so that early media processing is not delayed. I don't see why 1-800-fedex presents any special problems. Thanks, Paul From pkyzivat@alum.mit.edu Mon Jun 10 09:45:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9AC21F88D8 for ; Mon, 10 Jun 2013 09:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jwt4oAa-C9qe for ; Mon, 10 Jun 2013 09:45:03 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id C0B0E21F9452 for ; Mon, 10 Jun 2013 09:45:01 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id mcDR1l0020mv7h056gl1R9; Mon, 10 Jun 2013 16:45:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id mgl11l0033ZTu2S3Xgl1Wh; Mon, 10 Jun 2013 16:45:01 +0000 Message-ID: <51B6028C.20606@alum.mit.edu> Date: Mon, 10 Jun 2013 12:45:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Stach, Thomas" References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, , <51B20CD1.5090002@alum.mit.edu> , <51B26996.1090006@alum.mit.edu> <51B4FB67.7000600@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370882701; bh=YPYymbHYc84NybN5vr8mPYSllL0z49KxmChutT4GxK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I9vRVx1qW3HdBaWdR7M7Qq3at5hGtENylfYZ8BuZK/r/BZmVqIGtreM+zkkTHDlC0 ZG0IW1EYtL5PkqcGFD6JbSKH1HxorJvyrpv0I+np7gdKdG0zMiNe1AhrYz19oo1ksb nRdkJX6ypXbrFFIgAQqwqmS+o3BoldhyDKlGL3kNtQoEcWgT/1S/y+jrw04T7xoL4O WJc9tfJEdi3kvtJi3tAPo30hkrPuS+0DVGERnS5eDinGlhy+Lwl0YHkgQsRDzMwnG8 T0LgTdXsrUZlxCgg9YBYVeHavxYr3kJDkk2GiqhgLju/4T3eYNUNpPGoVUSeh0OglJ 0fokc2mHispfg== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 16:45:09 -0000 On 6/10/13 8:40 AM, Stach, Thomas wrote: >> -----Ursprüngliche Nachricht----- >> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Im Auftrag von Paul Kyzivat >> Gesendet: Montag, 10. Juni 2013 00:02 >> An: Bernard Aboba >> Cc: mmusic@ietf.org >> Betreff: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? >> >> On 6/9/13 1:48 PM, Bernard Aboba wrote: >>> Paul said: >>> >>> > There is a big difference between clipping for one >> second until the 183 >>> > is received, and clipping until the phone is answered >> and a 200 received. >>> >>> [BA] So you're saying it is sufficient to enable media once a 183 is >>> received, but not before? I believe that is consistent >> with the current >>> WebRTC API. The use case document isn't clear that this is the bar >>> that is being set, though. >> >> I'm suggesting that in the case of BUNDLE, there be a >> requirement that >> media not be sent until an answer is known to have been >> received by the >> other end. Sending a reliable 183 and awaiting the PRACK >> before sending >> media would satisfy that. Presumably something similar can serve in a >> pure WebRTC environment. >> >> That will ensure no clipping. >> >> The objection I hear to this is that some don't implement PRACK. I'm >> just saying that we could require support for PRACK with support for >> BUNDLE. Then that argument becomes bogus. > Just as well, we could require ICE together with BUNDLE and > re-use how ICE deals with reliability of provisional reponses. > In the RTCWEB this would be a non-issue. > Environments that don't support ICE could still require PRACK. The key is to ensure that the offerer gets an answer in a timely way to avoid clipping. PRACK is one way. ICE is another. We could require either/or. Thanks, Paul > Regards > Thomas > >> >> Then we can say that it is ok if something in the answer is >> needed for >> the offerer to demux incoming media. >> >>> One issue is what the WebRTC gateway will do if it gets >> media before the >>> 183. If it just forwards it on, then it will be dropped by the >>> browser until the 183 shows up and setRemoteDescription is called. >>> Should it buffer it until the 183 arrives? >> >> My proposal is that it should not transmit media until it knows the >> answer has been received. I don't care how it achieves that, but I >> imagine dropping it would be a good choice. >> >> Or, if people prefer, we could allow it to be sent, but allow >> the other >> end to drop it. But still expect the early answer so that the period >> when media is lost is brief. >> >>> > But I was suggesting that we couple a requirement for >> PRACK with BUNDLE, >>> > and say that media should not be sent until the PRACK is >> received. So >>> > then there won't be clipping at all. >>> >>> [BA] Personally, I don't see PRACK as being required for BUNDLE, at >>> least in WebRTC uses. However, a WebRTC/SIP gateway probably should >>> support PRACK. >> >> PRACK wouldn't be required in JSEP. But the equivalent would >> be expected >> - a quick ANSWER, before media is sent. >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> From pkyzivat@alum.mit.edu Mon Jun 10 09:50:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA27721F96C2 for ; Mon, 10 Jun 2013 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pr+7bVuqESJ for ; Mon, 10 Jun 2013 09:50:46 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74F21F96C6 for ; Mon, 10 Jun 2013 09:50:44 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id mam31l00A1c6gX857gqjNT; Mon, 10 Jun 2013 16:50:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id mgqj1l00u3ZTu2S3jgqjXf; Mon, 10 Jun 2013 16:50:43 +0000 Message-ID: <51B603E2.6030306@alum.mit.edu> Date: Mon, 10 Jun 2013 12:50:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3872B7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3872B7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370883043; bh=m/RhkFi7j1nRAS9Rgo74VwT5CYUCU85hbQI9gtcSPbQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fWpdzpEBaltnAT8dDff78Hk3faFoEUXYhcsvs1XWUbCtlclowoBI02R8OCYa/mCb6 fdwRY/bVu/gDH8TYIKsiixt/Ql4yiA4DzqbCnGUeUVN8Dc05JXCSx5dfJ8R5poOiLi 9JKKveyZnANsCAk3AbQj9sszjQHFntgWSVDVTwmhE+bPoyDTHsRLXGhj9rGqoaLX9q YhaTqk8M+6USy06eelmapF7svGRrW8xjSIGRw6vFiSeHNaNQLWoKxvKvmKd0oiWsop RpUsb7VJGhot9ojGRy5Tf3f8HTD930JuOhdmdCQTfefcFrXNqpjFpN6vrXxXhMunxe 7PDzCth2Dz3lA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 16:50:52 -0000 On 6/10/13 8:47 AM, Christer Holmberg wrote: > Hi Paul, > > A comment on some of the stuff you sent earlier. > >> ISTM that all bundle offers must meet some constraints: >> - some of the m-lines may have *unique* addresses >> - all the rest, if any, must have a single *common* address. >> - if any share a common address, then the first mid in the > bundle group must identify one of them > > What is the reason for the third bullet? > > For example, assume I am adding a new "m=" line, with a unique address, and I would like that address to become the new bundle address. > > In the existing "m=" lines, I couldn't keep the previously negotiated bundle address, because based on the third bullet the first mid would have to identity one of those. So, I would have to either: > > 1) Assign a unique address to each of the existing "m=" lines, which would then allow me to request the address of the new "m=" line to become the new bundle address; or > > 2) I would have to assign the suggested new bundle address to ALL "m=" lines (the existing ones and the new one). > > Note that both 1) and 2) are allowed today. OK, I didn't think of that case. So I guess that constraint should be removed. Thanks, Paul From martin.thomson@gmail.com Mon Jun 10 09:52:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB721F972C for ; Mon, 10 Jun 2013 09:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CQFl43LR7RW for ; Mon, 10 Jun 2013 09:52:36 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DE54321F96C6 for ; Mon, 10 Jun 2013 09:52:35 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so3415899wid.5 for ; Mon, 10 Jun 2013 09:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e/TirEaZ4Wy7k5kj9uq4xOkvueYfPJoQEBRn1ucY98M=; b=eiBf5iFqOqyO8abJw3qbVD9VZ1UI+G3eyBMGueRXKlB/rp8YhGrcY1cFmzGZ97HAzG bE7i+/MQvq/yB2pfj3u+3hOU6n4vavLbZ18a0mzx/qr2VJis80VuS7PIBikxOYYl2QSo IhnnYQClltpoowZm1/Au5AAsAHJnGzH7P4g72RenKoNSdBqemGiMaPh85k3+V8hzetzb oQcd+n+bd6zMBo/+uxlozJAMRmjpPl/r9Q6VhC9X5QrRF4yPmUuKBrh0Fkrpw4kFXEe1 nkbYWA3z0rWVAdjhHD8WPShJAQMC0RvXY9dTvyALYhCYUHdPEi/kJjMGpxyHLpZdhy7m Nk+g== MIME-Version: 1.0 X-Received: by 10.180.36.12 with SMTP id m12mr1566428wij.10.1370883154990; Mon, 10 Jun 2013 09:52:34 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 09:52:34 -0700 (PDT) In-Reply-To: <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> Date: Mon, 10 Jun 2013 09:52:34 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 16:52:36 -0000 On 7 June 2013 21:44, Cullen Jennings wrote: >> It would appear to me that both Plan A and Plan B use signaling not just to control the envelope of acceptable configurations, but to determine what is actually being sent at a given moment. > > This is the part I strongly disagree with. I think both plan A and B allow any type of control that is acceptable in RTP / SDP for this including the use of RTCP. I can't see how plan A / B have anything to do with this. I think that this is the part that is getting confused. This is not a complaint against plan A or B. I suspect that this is instead a (wholly valid) concern with the the idea of using a=imageattr for *setting* resolutions, which limits the ability of a sender to react to congestion signals. I agree with Cullen that this is separable from A/B discussions. From martin.thomson@gmail.com Mon Jun 10 10:07:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077FC21F8FB3 for ; Mon, 10 Jun 2013 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUh0bud2Si5M for ; Mon, 10 Jun 2013 10:07:40 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6817921F941F for ; Mon, 10 Jun 2013 10:07:32 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so965682wgh.18 for ; Mon, 10 Jun 2013 10:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wTcahKBv661jBwAjwUlb2oKG9CXrq6kOuBqqqo9MPmQ=; b=veyRT+rae0YAm0TsWKsHFSy5MDX1/AwMSlYg21FKhqjhS5wpzi1DXaopZjCdNoDHVm FOfnGLUOnxYgIrfOqSF/TY/NFrrOjCQWdrPqFquRcHPpQYQVHyh2YkDB1XJXGFcCiJ4+ 8pjy+YrwOw1V6np/0JMWbhPrheocmfZGy615b251owUYGVgoagoh7XpA5BDhJtgk9dgW zS3K02cXlVgjrPXYfYXEHMC4hcqYp6U8E88c8VwaMbSYqozqT7z/ZIXRh//OMFZ8+NOH J57B2hd9an62df8vWyDxhNMijSs3TiTnx+jU5wFXVPHugaQ7Qe3wEecFx9/JuUD11veI bNag== MIME-Version: 1.0 X-Received: by 10.194.158.69 with SMTP id ws5mr5015974wjb.84.1370884049068; Mon, 10 Jun 2013 10:07:29 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 10:07:28 -0700 (PDT) In-Reply-To: <51B603E2.6030306@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3872B7@ESESSMB209.ericsson.se> <51B603E2.6030306@alum.mit.edu> Date: Mon, 10 Jun 2013 10:07:28 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:07:42 -0000 Christer wrote: > For example, assume I am adding a new "m=" line, with a unique address, and > I would like that address to become the new bundle address. That's two things: 1. Add a new m-line, but allow it to be accepted and unbundled. 2. Change the transport parameters of the existing bundle, but permit the change to be rejected. I would be perfectly happy to require that this take two rounds of offer/answer to perform. I understand how that might be useful in theory, but I don't think that you can make this change without accepting a lot of additional complexity in the rest of the solution. I liked the constraint because it simplifies the rules around creation and acceptance significantly. Remove that constraint and I don't know where we are any more. From emil@sip-communicator.org Mon Jun 10 10:10:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5130721F9473 for ; Mon, 10 Jun 2013 10:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K7rWvjemF+g for ; Mon, 10 Jun 2013 10:10:10 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 419D921F9648 for ; Mon, 10 Jun 2013 10:10:09 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so4176528wes.4 for ; Mon, 10 Jun 2013 10:10:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=jfXVLI2frj41O4GAiAjEymMEoXnSrIfU2TVqvL7RsDU=; b=dAdTJI7w/WWcQHcZNfYUhnMRUzOGvwjFapiCRUVWNEvr4Yq3FoJsTYE8l/l5q41tkh bYE74tB+vFiBYZwxK0W0GkG4Z5D59dRRfckTk0rzDXmIdM4abr3nei4RD22AN6WwlksO Jsv447wNzb0IX0DttCEDDJVdbrF/CTUgqXqkU1+SFAJD015pPcCBZoV8EgtayKWgvyVx mdWuSnwI3jT0cgvmu6T4VGecfti9If/5SCv5v3ghpAHTRKE8zdc0mNvEeWtRqRQexLhs SZ0wP8aCWzL7LBGl6dwIFy45FW+Izv+jYGrEmR+ey8kOT59D4V+y7On55qEHIMpjwQUI /1Iw== X-Received: by 10.180.87.162 with SMTP id az2mr1355666wib.10.1370884209303; Mon, 10 Jun 2013 10:10:09 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:1fd:ec91:e41a:f5b8]) by mx.google.com with ESMTPSA id f8sm12328682wiv.0.2013.06.10.10.10.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 10:10:08 -0700 (PDT) Message-ID: <51B6086E.5020802@jitsi.org> Date: Mon, 10 Jun 2013 19:10:06 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Martin Thomson References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl4LDgYPpyzfSBco93J08VpQDa45W6csrpHHvHi1b9pT3WKXYBI25ff9G4Yn7Ts0NUumbe8 Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:10:11 -0000 On 10.06.13, 18:52, Martin Thomson wrote: > On 7 June 2013 21:44, Cullen Jennings wrote: >>> It would appear to me that both Plan A and Plan B use signaling not just to control the envelope of acceptable configurations, but to determine what is actually being sent at a given moment. >> >> This is the part I strongly disagree with. I think both plan A and B allow any type of control that is acceptable in RTP / SDP for this including the use of RTCP. I can't see how plan A / B have anything to do with this. > > I think that this is the part that is getting confused. This is not a > complaint against plan A or B. It is indeed a problem with both of them and it is also mentioned in the No Plan draft. Emil > I suspect that this is instead a > (wholly valid) concern with the the idea of using a=imageattr for > *setting* resolutions, which limits the ability of a sender to react > to congestion signals. I agree with Cullen that this is separable > from A/B discussions. -- https://jitsi.org From martin.thomson@gmail.com Mon Jun 10 10:19:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C715121F9385 for ; Mon, 10 Jun 2013 10:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOlxgp6M2b5R for ; Mon, 10 Jun 2013 10:19:23 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2780C21F8F61 for ; Mon, 10 Jun 2013 10:19:22 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so1126465wib.6 for ; Mon, 10 Jun 2013 10:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dHRp9raMlSTQJ1IbOUAIVvy5IaVRliBWEFnfz2Of4PE=; b=HsfzPPdg/MPW3FaU0i85Dmn+dAfE53NM4RmxHYkmRtVSyyEKCNxW7Aycj8M1XOYTN6 KJNwdZoyTIB5vodrbw8hhh67NjeBYfccRFrXQi7O9xzqG/+QbmqVVaBHOdYq6fyDMsOU EwSgkt7cqZh7+rASTI73MeodGfvF/gUoV7zlbcPKiHJa24EAhKXwDJ0YP1S3vUQiGuIq skDxf2HYRCZ9AKm7czTupykInmN5fCzsYXIVpFn1qc3aLlGhLSkR47Oza25qdaWCodLL 8txSEDlSczrxBchroDE2uNj2w3UQP/5T37xKzxmtyGDwlPCLBi4bsLIRkjMDoY2kn7Xk KYJQ== MIME-Version: 1.0 X-Received: by 10.180.87.162 with SMTP id az2mr1373566wib.10.1370884762239; Mon, 10 Jun 2013 10:19:22 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 10:19:22 -0700 (PDT) In-Reply-To: <51B6086E.5020802@jitsi.org> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> <51B6086E.5020802@jitsi.org> Date: Mon, 10 Jun 2013 10:19:22 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 17:19:23 -0000 On 10 June 2013 10:10, Emil Ivov wrote: >> I think that this is the part that is getting confused. This is not a >> complaint against plan A or B. > > It is indeed a problem with both of them and it is also mentioned in the No > Plan draft. Well then you've assumed something about Plan A/B that is incorrect. Neither plan constrains usage in a way that would prevent senders from responding to congestion signals. The fine-grained control that you report as being problematic doesn't prevent senders from sending fewer bits. Is it possible that you have assumed that the existence of an m-line or a=ssrc implies that the sender is obligated to send? It doesn't. The only possible problem is the use of a=imageattr in the examples of Plan B, which might (might) overconstrain a sender, but Plan B doesn't mandate anything regarding that in text. Assuming anything there would be a real stretch. From emcho@sip-communicator.org Mon Jun 10 11:12:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC3711E80A3 for ; Mon, 10 Jun 2013 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj+yvd9LEzuF for ; Mon, 10 Jun 2013 11:12:23 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BC2DE11E80A2 for ; Mon, 10 Jun 2013 11:12:23 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so4855550pbb.6 for ; Mon, 10 Jun 2013 11:12:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=bLw/gDIN09bjzoXm9TJIo/14rAPHNHs05o/SrJluEWo=; b=gc81cRuDX2wx8Kv34sVraJA8cDBOWLhdkybeQQx0S4bYstvoOtTDubtB6R44h9zQKD bla5LXb7xo6fQ1nu+HFDEHvcMwt6sKCqRy0rFj1pglbgG1oFLo2XZKrNnKDb2OLVetFD QiikDbMS/Vs2nuZfB5fUTi5qUhJuOXn7rLzoyh6878YZ4I2PLLVcRZo1nMvXoGRr9CY8 pfF0r7Z1gmJZeecMet8OuqusckG/kB35MFw9oVzM3XGGufSF4NWXIteY1HcLnNYsNeEP kFW3FmifKQMcO3gYlLM4GiFw0sUQnYXVoXETFq3XR/2naRicPm+0Kudqft/IrlcCEdZj GvzA== X-Received: by 10.68.211.199 with SMTP id ne7mr10900044pbc.56.1370887943351; Mon, 10 Jun 2013 11:12:23 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [2607:f8b0:400e:c01::234]) by mx.google.com with ESMTPSA id yj2sm11190143pbb.40.2013.06.10.11.12.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 11:12:23 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so7544145pbc.39 for ; Mon, 10 Jun 2013 11:12:22 -0700 (PDT) X-Received: by 10.68.190.104 with SMTP id gp8mr11059388pbc.120.1370887942645; Mon, 10 Jun 2013 11:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.192.65 with HTTP; Mon, 10 Jun 2013 11:12:02 -0700 (PDT) In-Reply-To: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> <51B6086E.5020802@jitsi.org> From: Emil Ivov Date: Mon, 10 Jun 2013 20:12:02 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkBqzVo7dFPbkQded6QuFLObbKnxLe5Su5Y1LQUR2L1rx7xAWOTld7CRR0KdMmIgGxodB6u Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 18:12:24 -0000 On Mon, Jun 10, 2013 at 7:19 PM, Martin Thomson wrote: > On 10 June 2013 10:10, Emil Ivov wrote: >>> I think that this is the part that is getting confused. This is not a >>> complaint against plan A or B. >> >> It is indeed a problem with both of them and it is also mentioned in the No >> Plan draft. > > Well then you've assumed something about Plan A/B that is incorrect. I am not following. Could you please point me to the specific assumption that you have in mind? > Neither plan constrains usage in a way that would prevent senders from > responding to congestion signals. The fine-grained control that you > report as being problematic doesn't prevent senders from sending fewer > bits. No, not explicitly at least. However, the more senders respond to congestion signals the more they end up with inconsistencies between what's been requested from the remote SDP, what the local application would like to happen and what is actually happening. Such situations would be much harder to control when all you've got is the remote SDP. > Is it possible that you have assumed that the existence of an m-line > or a=ssrc implies that the sender is obligated to send? Nope. Emil > It doesn't. > > The only possible problem is the use of a=imageattr in the examples of > Plan B, which might (might) overconstrain a sender, but Plan B doesn't > mandate anything regarding that in text. Assuming anything there > would be a real stretch. From bernard_aboba@hotmail.com Mon Jun 10 12:17:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED721F9A6D for ; Mon, 10 Jun 2013 12:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF-0n+Ze+GDE for ; Mon, 10 Jun 2013 12:17:18 -0700 (PDT) Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id 08CC221F9ACC for ; Mon, 10 Jun 2013 12:16:39 -0700 (PDT) Received: from BLU169-W35 ([65.55.116.73]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jun 2013 12:16:38 -0700 X-TMN: [po8f/CqVek4DEizi0WJ/f1fv59eY89O3RoCgte5ikHI=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c481e80d-3364-4083-b906-09982e657eee_" From: Bernard Aboba To: Cullen Jennings Date: Mon, 10 Jun 2013 12:16:37 -0700 Importance: Normal In-Reply-To: <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> , <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> , <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jun 2013 19:16:38.0526 (UTC) FILETIME=[0802B1E0:01CE660F] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion control X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 19:17:24 -0000 --_c481e80d-3364-4083-b906-09982e657eee_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said:=20 " No O/A is request to stop sending RTP packets on a given stream. " [BA] = So you're saying that you don't expect a=3Dsendrecv/recvonly/sendonly to b= e used in Plan A to control streams described by individual m lines? I h= ad assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1= would apply in Plan A. = --_c481e80d-3364-4083-b906-09982e657eee_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said: =3B

 =3B
" =3BNo O/A is request to stop sending RTP packets = on a given stream. "
 =3B
[BA] =3B So you're sa= ying that you don't =3Bexpect a=3Dsendrecv/recvonly/sendonly to be used= in Plan A to control streams described by individual m lines? =3B = =3B =3B I had assumed that the O/A behavior described in RFC 3264 Secti= ons 5.1 and 6.1 would apply in Plan A. =3B =3B
 =3B
= --_c481e80d-3364-4083-b906-09982e657eee_-- From martin.thomson@gmail.com Mon Jun 10 13:17:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41F021F9A13 for ; Mon, 10 Jun 2013 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es5tmjVHpm5N for ; Mon, 10 Jun 2013 13:17:00 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B432121F9A12 for ; Mon, 10 Jun 2013 13:16:59 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3389669wgh.4 for ; Mon, 10 Jun 2013 13:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2DPlzaoIQaijfo18IseXS24PsZ3m4yXY5Lbd2tdRKrg=; b=b8Ecw+EB9LpfcL4pjfDo2U8dtiP37gUqX9Q5r/yXCwstyawi8MyMX3QW53zNv/L3Iy U9GsG6yeXfvsgTp6vKE/Ge0oXnEWnvCVO23C1onI4y/RSHcgA5yBcxaQBjEpr0sUaGth JSS+fJSt4g1h5Yi/81IlvCoPVyl4lZk9XMLlFufsrcJ8okoZ4kdZGCpWJnt4g0DMX+Nj fHwhFYWSCuEM56bjNB5Vzq8cNXt5C+0OpuIpq4Eug6Dk8HXDm3sFfoLe1zsum7syaRuL Ukedblojk7DpTHti4iS+GXjt1tjX58Y7JeJjqb++iwlSk6L71AQJiwh3+uWlW+uKMxo+ AXkw== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr1513306wik.14.1370895418922; Mon, 10 Jun 2013 13:16:58 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 13:16:58 -0700 (PDT) In-Reply-To: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> <51B6086E.5020802@jitsi.org> Date: Mon, 10 Jun 2013 13:16:58 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: Flemming Andreasen , Ari Keranen , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Congestion controll X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:17:00 -0000 On 10 June 2013 11:12, Emil Ivov wrote: > On Mon, Jun 10, 2013 at 7:19 PM, Martin Thomson > wrote: >> Well then you've assumed something about Plan A/B that is incorrect. > > I am not following. Could you please point me to the specific > assumption that you have in mind? Um, your argument in this thread? Also, Section 1: Finally, both Plan A and Plan B, also create expectations that fine grained control of FEC, layering and RTX flows will always be implemented through Offer/Answer, which would not necessarily the best way to handle this in congested situations. That draws a line from control of FEC/layering, etc... with O/A to congestion control. >> Neither plan constrains usage in a way that would prevent senders from >> responding to congestion signals. The fine-grained control that you >> report as being problematic doesn't prevent senders from sending fewer >> bits. > > No, not explicitly at least. However, the more senders respond to > congestion signals the more they end up with inconsistencies between > what's been requested from the remote SDP, what the local application > would like to happen and what is actually happening. Such situations > would be much harder to control when all you've got is the remote SDP. I really don't think that is a valid argument. As you observe congestion, you alter what you send. Preferably toward sending fewer bits. That might result in sending nothing at all for some streams (which would be one value for "fewer bits"). SDP describes the envelope within which you operate, that's all. Neither plan A nor plan B expressly state that SDP is expressing constraints on how a sender might alter their behavior in response to congestion signals. Think of it this way: I will simulate 100% packet loss to satisfy a need to alleviate congestion, if there are no other options available. After all, that's what happens if I let congestion worsen. There is nothing an API, or SDP, can do to stop me from doing that. From martin.thomson@gmail.com Mon Jun 10 13:26:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5008721E8056 for ; Mon, 10 Jun 2013 13:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Q6Nt5sMhuW for ; Mon, 10 Jun 2013 13:26:35 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6021E804B for ; Mon, 10 Jun 2013 13:26:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so3408957wiv.7 for ; Mon, 10 Jun 2013 13:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=75dvZ0H0EOIPFUcyKX/crNDOHTq77i963+yMQDnkvn0=; b=pMExjudZ72klRbM6ymNvBxXLOc8k2SaCzwm7TziPtsmwxGN1z89li0vuURRqZQgIM1 nN73d6KQ6BpNC9tsNpkZdh5/GiSWazwA/YUrQx4uTH2u1EJlleSnkvULY0ZYiNUUx9V/ wwgrj1xBZLrFx1Z2iKo8u1a3RElH6+lKzJabWt5AR5s7zarRhSLt7zsvQXH7TPeSJljI DPSN9JlSCLUpIaWcMOUTivtPiXQhAnOGWxH9LI5ot5wbSucWN9+2hxaUOruWtzJL07/o m2823g6v/kHeEfdvsoOah6QCKSLEoj+bko8/Zl4a+W4QsEcl8QX+6Szq/Qzr3dvfXxEX u9LA== MIME-Version: 1.0 X-Received: by 10.180.81.103 with SMTP id z7mr5556335wix.65.1370895984562; Mon, 10 Jun 2013 13:26:24 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 10 Jun 2013 13:26:24 -0700 (PDT) In-Reply-To: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> Date: Mon, 10 Jun 2013 13:26:24 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Congestion control X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2013 20:26:36 -0000 On 10 June 2013 12:16, Bernard Aboba wrote: > " No O/A is request to stop sending RTP packets on a given stream. " With my Fluffy-filter on, I read that as saying: "No O/A is *required* to stop sending RTP packets..." > [BA] So you're saying that you don't expect a=sendrecv/recvonly/sendonly to > be used in Plan A to control streams described by individual m lines? I > had assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1 > would apply in Plan A. I didn't infer anything like that. I think that there is a distinct difference between negotiating the possible existence of a stream and requiring the existence of a stream. When you use a=sendonly/etc... you open the possibility of receiving the stream, which in most cases will be fulfilled. In a congestion scenario, the sender can (and should) stop sending. After all, the envelope established by SDP never excludes the possibility that zero packets arrive. From fluffy@cisco.com Mon Jun 10 19:56:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699D421E80A8 for ; Mon, 10 Jun 2013 19:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.733 X-Spam-Level: X-Spam-Status: No, score=-109.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHTh-jZi8Pa0 for ; Mon, 10 Jun 2013 19:56:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 943B121E804E for ; Mon, 10 Jun 2013 19:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1370919364; x=1372128964; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FEIq2NEVXxVSr5E1x7gV9/WajEXoP53/IiGtGigI6/0=; b=YPQc5e9PSiFxygW1d/d9LizWcgjhm3D1s2/5sw2T2ZwSV8JyDGOmu26D Py4r8uye6Ic4A0sRsYpg7+fwHhboYPZzc0LtnIrDouF8aRygruue/5Ukx N3rwwKQumSUEUfOQmdMoTLDRjGcqXPelWSRscG89kIZ4ceaKUZFtmbRhN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMLAPWQtlGtJV2b/2dsb2JhbABZgwkwSYItvBQBAwEDAXsWdIIjAQEBAwFyBxACAQgOFCQyJQIEDg2Hfwa6GY8EAjEHgn9hA4hokAGQGYMPgic X-IronPort-AV: E=Sophos;i="4.87,841,1363132800"; d="scan'208";a="221251098" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jun 2013 02:56:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5B2u2wP029891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 02:56:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 21:56:02 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt Thread-Index: AQHOZe11EXDGbTPi/kGsN0Ab2PGjGpkwJl+A Date: Tue, 11 Jun 2013 02:55:11 +0000 Message-ID: References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> <51B5EDB9.9030109@jitsi.org> In-Reply-To: <51B5EDB9.9030109@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.230.50] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <57EEE4822FB2BD4C915C56650877290E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:56:09 -0000 >=20 >> and discussing the issues it raises with relation to this draft. >>=20 >> Next I think you need to add a specific attack where two people are >> both behind the same CGN. >=20 > This exact case was already described in the security considerations sect= ion: >=20 > tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11 >=20 > (last paragraph on the page) It was exactly this paragraph that I thought was pretty misleading. When I = read " SBCs have various mechanisms to prevent this as well." I really wond= er what they when both end points are behind a CGN.=20 I think this paragraph should make it very clear that in the CGN case, thi= s technic allows interception of the media. If there are specific ways to s= top that from happening, the draft should say it and if there are not it sh= ould be very explicitly clear about that.=20 From fluffy@iii.ca Mon Jun 10 23:00:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5243921F998B for ; Mon, 10 Jun 2013 23:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s97VeEAoiDgu for ; Mon, 10 Jun 2013 23:00:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5221F9050 for ; Mon, 10 Jun 2013 23:00:45 -0700 (PDT) Received: from sjc-vpn5-291.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0D41F22E256; Tue, 11 Jun 2013 02:00:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B049607@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 11 Jun 2013 15:00:35 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> <51B4B64B.1050101@alum.mit.edu> <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca> <949EF20990823C4C85C18D59AA11AD8B049607@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org WG" , Paul Kyzivat Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 06:00:54 -0000 Sorry - trying to say=20 Several of the implementations of 100rel have bugs in the case of where = there is an outstanding transaction and they get an event that might = cause them to want to start a second transaction before the first = transaction completes.=20 On Jun 10, 2013, at 7:47 PM, "DRAGE, Keith (Keith)" = wrote: > "has an implantation that does not meet the requirements of the RFC - = particularly in the many unspecified corner cases" >=20 > Does not make sense! From fluffy@iii.ca Mon Jun 10 23:00:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019E521F9A9F for ; Mon, 10 Jun 2013 23:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OFTWfb15fgU for ; Mon, 10 Jun 2013 23:00:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C48E021F8F5C for ; Mon, 10 Jun 2013 23:00:45 -0700 (PDT) Received: from sjc-vpn5-291.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB2BF22E257; Tue, 11 Jun 2013 02:00:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Tue, 11 Jun 2013 15:00:37 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> To: Martin Thomson X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion control X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 06:00:54 -0000 On Jun 11, 2013, at 5:26 AM, Martin Thomson wrote: > On 10 June 2013 12:16, Bernard Aboba wrote: >> " No O/A is request to stop sending RTP packets on a given stream. " > > With my Fluffy-filter on, I read that as saying: "No O/A is *required* > to stop sending RTP packets..." yes, that is what I meant - sorry From emil@sip-communicator.org Mon Jun 10 23:03:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3F121F998B for ; Mon, 10 Jun 2013 23:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LY06wMAuBxK for ; Mon, 10 Jun 2013 23:03:26 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58D21F9050 for ; Mon, 10 Jun 2013 23:03:26 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so5518099wes.35 for ; Mon, 10 Jun 2013 23:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=73TaXKt647FQH72U8ml1vsjecYRIyvPDZoi9mOIMsDE=; b=L2E3BGTdiw+G0O0XOMl21GqiBDxbgW8W1wrujfdfmSB65YGRSjxWbKlLsXtVyMebwA IXiaqU5GQyrpK94m6ShXOQ3tQJZ2UlLBLqEuax+PBidGkftr4W0sr6bLJ6QkMb5zxall NJcGZILT7CjI+MnLr8I0G5G8cqDheXpyQr5o12/U+OapdZRB+xmm/fJkww2cXjtIiA9C Blot1sRYuhnLcGPn9lUESoASeFRh9m4ZlRdibGrbPrqJ50JJpLXAYH9gaKdYk4/zuRR2 LwkOshBUF9LfVgnYLu2L47Q9lxzYHn40WCL75a9k3cCYN9qrML9SWlZZ+nIEMAk/9oai WzrQ== X-Received: by 10.194.21.138 with SMTP id v10mr7440906wje.16.1370930605263; Mon, 10 Jun 2013 23:03:25 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:8d48:fb46:b976:405a]) by mx.google.com with ESMTPSA id fu14sm15311072wic.8.2013.06.10.23.03.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 23:03:24 -0700 (PDT) Message-ID: <51B6BDA9.2000902@jitsi.org> Date: Tue, 11 Jun 2013 08:03:21 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> <51B5EDB9.9030109@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlNrd0Y2VzcBciPOfVxoue5ZG9BP7W58wJoRIMA1rC7Y/dQdl1d3BcMp8mTCrbW2boV803+ Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 06:03:27 -0000 Hey Cullen, On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote: >> >>> and discussing the issues it raises with relation to this draft. >>> >>> Next I think you need to add a specific attack where two people >>> are both behind the same CGN. >> >> This exact case was already described in the security >> considerations section: >> >> tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11 >> >> (last paragraph on the page) > > It was exactly this paragraph that I thought was pretty misleading. > When I read " SBCs have various mechanisms to prevent this as well." > I really wonder what they when both end points are behind a CGN. > > I think this paragraph should make it very clear that in the CGN > case, this technic allows interception of the media. If there are > specific ways to stop that from happening, the draft should say it > and if there are not it should be very explicitly clear about that. I was actually referring to text that came later in that same paragraph: The attacker could also redirect all media to the real SIP UA after receiving it, in which case the attack would likely remain undetected and succeed. Again, this would be of particular concern with larger scale NATs serving many different endpoints such as carrier grade NATs. The larger the number of devices fronted by a NAT is, the more use cases would vary and the more the number of possible attack vectors would grow. Naturally, SRTP [RFC3711] would help mitigate such threats and should be used independently of HNT. For example, in cases where end-to-end encryption is used it would still be possible for an attacker to hijack a session despite the use of SRTP and perform a denial of service attack. However, media integrity would not be compromised. Additionally if the SBC that performs the latching is actually participating in the SRTP key exchange then it would simply refuse to latch onto a source unless it can authenticate it. Cheers, Emil -- https://jitsi.org From fluffy@iii.ca Mon Jun 10 23:11:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D13621F9A72 for ; Mon, 10 Jun 2013 23:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLHdfK3Hi8qy for ; Mon, 10 Jun 2013 23:10:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 92C6D21F8EB3 for ; Mon, 10 Jun 2013 23:10:55 -0700 (PDT) Received: from sjc-vpn5-291.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C067722E253; Tue, 11 Jun 2013 02:10:51 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Tue, 11 Jun 2013 15:10:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> , <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> , <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> To: Bernard Aboba X-Mailer: Apple Mail (2.1503) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion control X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 06:11:02 -0000 On Jun 11, 2013, at 4:16 AM, Bernard Aboba = wrote: > Cullen said:=20 >=20 > =20 > " No O/A is request to stop sending RTP packets on a given stream. " > =20 > [BA] So you're saying that you don't expect = a=3Dsendrecv/recvonly/sendonly to be used in Plan A to control streams = described by individual m lines? I had assumed that the O/A behavior = described in RFC 3264 Sections 5.1 and 6.1 would apply in Plan A. =20 > =20 Bernard - do you really think the "a=3Dsendrecv/recvonly/sendonly " is = how we do congestion control for VoIP? I don't think that is the = approach that WeRTC will take to congestion control. Of course = "a=3Dsendrecv/recvonly/sendonly are part of SDP but they are not how = anyone other than you has proposed to do congestion control. I think you = would agree they would be a pretty non optimal way to do congestion = control.=20 From fluffy@cisco.com Mon Jun 10 23:16:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C9021F9A7F for ; Mon, 10 Jun 2013 23:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+rinFq7OVnA for ; Mon, 10 Jun 2013 23:16:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6E21F9A79 for ; Mon, 10 Jun 2013 23:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2574; q=dns/txt; s=iport; t=1370931378; x=1372140978; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rgnuj8YrFplLkFQJYOIp+1bxRDiWqwfEfUE2Guy4eKs=; b=g8xCIC/NXvEMtHTb1+wyjqjM3IWkqzrd0k3z1DkCs8MymT40T1mM15o1 jZ6P6KLYJnSS8cDlBs8Dz+lN+Qibse9lHWL7fXxpvQcv2D6JJSKONPIyA AXtTStXulISmZVToMS5vC/ynwZXPfEKGmtWkbXArrV0eAT7wl6iRuczmK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAADAtlGtJV2d/2dsb2JhbABZgwkwSb5JexZ0giMBAQEDAQEBATctBwQHBQsCAQgOCgoUECcLJQIEDgUIh38GDLoJjwQCMQeCf2EDmGmQGYMPgic X-IronPort-AV: E=Sophos;i="4.87,843,1363132800"; d="scan'208";a="221233204" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2013 06:16:17 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5B6GHsQ024576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 06:16:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 01:16:17 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt Thread-Index: AQHOZe11EXDGbTPi/kGsN0Ab2PGjGpkwBu1ogABXZQA= Date: Tue, 11 Jun 2013 06:15:26 +0000 Message-ID: References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> <51B5EDB9.9030109@jitsi.org> <51B6BDA9.2000902@jitsi.org> In-Reply-To: <51B6BDA9.2000902@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.89.35] Content-Type: text/plain; charset="us-ascii" Content-ID: <4BEE345C05BC6043B171F8C05EFD8F41@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 06:16:23 -0000 Well, do you think the draft should say that this approach MUST NOT be used= with uncarpeted media because it allows and attacker behind the same CGN c= an intercept the media ? =20 On Jun 11, 2013, at 3:03 PM, Emil Ivov wrote: > Hey Cullen, >=20 > On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote: >>>=20 >>>> and discussing the issues it raises with relation to this draft. >>>>=20 >>>> Next I think you need to add a specific attack where two people >>>> are both behind the same CGN. >>>=20 >>> This exact case was already described in the security >>> considerations section: >>>=20 >>> tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11 >>>=20 >>> (last paragraph on the page) >>=20 >> It was exactly this paragraph that I thought was pretty misleading. >> When I read " SBCs have various mechanisms to prevent this as well." >> I really wonder what they when both end points are behind a CGN. >>=20 >> I think this paragraph should make it very clear that in the CGN >> case, this technic allows interception of the media. If there are >> specific ways to stop that from happening, the draft should say it >> and if there are not it should be very explicitly clear about that. >=20 > I was actually referring to text that came later in that same paragraph: >=20 > The attacker could also redirect all media to > the real SIP UA after receiving it, in which case the attack would > likely remain undetected and succeed. Again, this would be of > particular concern with larger scale NATs serving many different > endpoints such as carrier grade NATs. The larger the number of > devices fronted by a NAT is, the more use cases would vary and the > more the number of possible attack vectors would grow. >=20 > Naturally, SRTP [RFC3711] would help mitigate such threats and should > be used independently of HNT. For example, in cases where end-to-end > encryption is used it would still be possible for an attacker to > hijack a session despite the use of SRTP and perform a denial of > service attack. However, media integrity would not be compromised. > Additionally if the SBC that performs the latching is actually > participating in the SRTP key exchange then it would simply refuse to > latch onto a source unless it can authenticate it. >=20 > Cheers, > Emil >=20 >=20 > --=20 > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Tue Jun 11 00:52:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8504C21F9A82 for ; Tue, 11 Jun 2013 00:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkZXZgeak8JQ for ; Tue, 11 Jun 2013 00:52:35 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4321F9A93 for ; Tue, 11 Jun 2013 00:52:28 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3727375wgh.4 for ; Tue, 11 Jun 2013 00:52:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=FFIf6u6scGCwOGkuE8wL1RjPGvd1SBqQKMA2Pru+bYQ=; b=TIcn3Hh51NRIpm9ZhAgRqnImxBiXI/ww7tbr7zSXPM25fC8Ej/2IgcdZwL/baFxM4r mBLM+/zjX2e9cOe7udOaEf0l9hiFRN7/yq5q8lBzDSXD40/bJ5ZiNQfoYnIqzIQgO76y EJkJvDD2s7gCmAXFRthtIX/k0n7Sbmx4sg5/iHoEsSvRH2TLEPgEaZYAPa/VCvdcx4Ok B8OwMbnNnUAsUIpkN3B7HGF9Sb0Mu0i64QqX+nXsbfzSYFlJNea0UMfjR2vOyDyj+z/7 xwRXWuxJp/d6+q/IEN2kY/nyou5WQbhcR5sFfyogwGOAu4w7dMerEDNrJr/jWb5EbfMZ yhEQ== X-Received: by 10.194.87.71 with SMTP id v7mr7501598wjz.33.1370937147328; Tue, 11 Jun 2013 00:52:27 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id b11sm15917807wiv.10.2013.06.11.00.52.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 00:52:26 -0700 (PDT) Message-ID: <51B6D738.3000507@jitsi.org> Date: Tue, 11 Jun 2013 09:52:24 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> <51B5EDB9.9030109@jitsi.org> <51B6BDA9.2000902@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlTQu40fh1zavRZDron1df2S6RoPsYqFdZtiqmJjtJRZVMPOwgX0eImrjM4zkTN6Rmdd5XO Cc: "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 07:52:38 -0000 On 11.06.13, 08:15, Cullen Jennings (fluffy) wrote: > > Well, do you think the draft should say that this approach MUST NOT > be used with uncarpeted media because it allows and attacker behind > the same CGN can intercept the media ? I am assuming uncarpeted means unprotected here. Is this right? If so, then I think we shouldn't be doing any kind of (non-S) RTP=20 because, regardless of whether or not we are using latching, our media=20 would be exposed to eavesdropping from our ISP, hotspot provider, VoIP=20 service provider, potentially people on the same link as us, MiTM=20 attackers that have fooled us into using them as a default gateway,=20 Wi-Fi monitors and possibly many others. As for the draft saying "MUST NOT", I wouldn't mind at all, however we=20 don't even have a 2119 section. Also, we are not specifying a NAT=20 traversal mechanism, we are just describing one that people are using=20 overwhelmingly so that we can have something to point to as a=20 descriptive reference. I agree that this point can be stressed upon however so, what if we=20 added the following: =2E.. actually participating in the SRTP key exchange then it would simply refuse to latch onto a source unless it can authenticate it. *Failing to implement this would represent =D0=B0 serious threat to users connecting from behind CGNs and is considered a harmful practice.* Would this work? Emil > On Jun 11, 2013, at 3:03 PM, Emil Ivov wrote: > >> Hey Cullen, >> >> On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote: >>>> >>>>> and discussing the issues it raises with relation to this >>>>> draft. >>>>> >>>>> Next I think you need to add a specific attack where two >>>>> people are both behind the same CGN. >>>> >>>> This exact case was already described in the security >>>> considerations section: >>>> >>>> tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11 >>>> >>>> (last paragraph on the page) >>> >>> It was exactly this paragraph that I thought was pretty >>> misleading. When I read " SBCs have various mechanisms to prevent >>> this as well." I really wonder what they when both end points are >>> behind a CGN. >>> >>> I think this paragraph should make it very clear that in the >>> CGN case, this technic allows interception of the media. If there >>> are specific ways to stop that from happening, the draft should >>> say it and if there are not it should be very explicitly clear >>> about that. >> >> I was actually referring to text that came later in that same >> paragraph: >> >> The attacker could also redirect all media to the real SIP UA after >> receiving it, in which case the attack would likely remain >> undetected and succeed. Again, this would be of particular concern >> with larger scale NATs serving many different endpoints such as >> carrier grade NATs. The larger the number of devices fronted by a >> NAT is, the more use cases would vary and the more the number of >> possible attack vectors would grow. >> >> Naturally, SRTP [RFC3711] would help mitigate such threats and >> should be used independently of HNT. For example, in cases where >> end-to-end encryption is used it would still be possible for an >> attacker to hijack a session despite the use of SRTP and perform a >> denial of service attack. However, media integrity would not be >> compromised. Additionally if the SBC that performs the latching is >> actually participating in the SRTP key exchange then it would >> simply refuse to latch onto a source unless it can authenticate >> it. >> >> Cheers, Emil >> >> >> -- https://jitsi.org >> _______________________________________________ mmusic mailing >> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > > --=20 https://jitsi.org From prvs=987488563a=christer.holmberg@ericsson.com Tue Jun 11 02:15:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603F521F8F24 for ; Tue, 11 Jun 2013 02:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrhTSjfznPP8 for ; Tue, 11 Jun 2013 02:15:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E5AE321F8EC6 for ; Tue, 11 Jun 2013 02:15:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-90-51b6eaa847b6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C7.B0.15700.8AAE6B15; Tue, 11 Jun 2013 11:15:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 11:15:20 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAAMTTumAABIV6AAAAlecAACJhoQA= Date: Tue, 11 Jun 2013 09:15:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C387D2D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3872B7@ESESSMB209.ericsson.se> <51B603E2.6030306@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre6KV9sCDZ5Mlbe4duYfo8XU5Y9Z LFZsOMDqwOzx9/0HJo+ds+6yeyxZ8pMpgDmK2yYpsaQsODM9T98ugTvj1tM9TAU/uCrWNho2 MF7h6mLk5JAQMJE4vOYEE4QtJnHh3nq2LkYuDiGBw4wSfdMaWSCcJYwSl/bvZu5i5OBgE7CQ 6P6nDdIgIhAq0XZxHyNImFlAXeLq4iCQsLCAg8SWDZNYIUocJQ782sIGYftJHN08jQXEZhFQ ldj0awcjiM0r4CvxaU8jE8SqOUwS0xdeYQZJcAoESpzYvQjMZgQ67vupNWCHMguIS9x6Mh/q aAGJJXvOM0PYohIvH/9jBblHQkBRYnm/HMRpmhLrd+lDdCpKTOl+yA6xVlDi5MwnLBMYxWYh GToLoWMWko5ZSDoWMLKsYmTPTczMSS833MQIjJiDW37r7mA8dU7kEKM0B4uSOK8e7+JAIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJwggkuqgdF59/qInSU8rfpNu0vPrZx8svaO+/yvXO0qxh99 W2df2vaEI3Wrsmt+vsvq68FGh3bvvqdv5pTodTNUSEFP443FrLS/nQmiNXHJjy1PL9BevGNN 094KTuYHDbPuz51urLVAVSX54TPbXNEX9qpTbbTMFz/yKt0Rvera4rK4iv/T0iwdJdmUZymx FGckGmoxFxUnAgBfRf5VawIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:15:29 -0000 SGksDQoNCj4+IEZvciBleGFtcGxlLCBhc3N1bWUgSSBhbSBhZGRpbmcgYSBuZXcgIm09IiBsaW5l LCB3aXRoIGEgdW5pcXVlIA0KPj4gYWRkcmVzcywgYW5kIEkgd291bGQgbGlrZSB0aGF0IGFkZHJl c3MgdG8gYmVjb21lIHRoZSBuZXcgYnVuZGxlIGFkZHJlc3MuDQo+DQo+VGhhdCdzIHR3byB0aGlu Z3M6DQo+DQo+MS4gQWRkIGEgbmV3IG0tbGluZSwgYnV0IGFsbG93IGl0IHRvIGJlIGFjY2VwdGVk IGFuZCB1bmJ1bmRsZWQuDQo+Mi4gQ2hhbmdlIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBvZiB0 aGUgZXhpc3RpbmcgYnVuZGxlLCBidXQgcGVybWl0IHRoZSBjaGFuZ2UgdG8gYmUgcmVqZWN0ZWQu DQo+DQo+SSB3b3VsZCBiZSBwZXJmZWN0bHkgaGFwcHkgdG8gcmVxdWlyZSB0aGF0IHRoaXMgdGFr ZSB0d28gcm91bmRzIG9mIG9mZmVyL2Fuc3dlciB0byBwZXJmb3JtLg0KPg0KPkkgdW5kZXJzdGFu ZCBob3cgdGhhdCBtaWdodCBiZSB1c2VmdWwgaW4gdGhlb3J5LCBidXQgSSBkb24ndCB0aGluayB0 aGF0IHlvdSBjYW4gbWFrZSB0aGlzIGNoYW5nZSB3aXRob3V0IGFjY2VwdGluZyBhIGxvdCBvZiBh ZGRpdGlvbmFsIA0KPmNvbXBsZXhpdHkgaW4gdGhlIHJlc3Qgb2YgdGhlIHNvbHV0aW9uLiAgSSBs aWtlZCB0aGUgY29uc3RyYWludCBiZWNhdXNlIGl0IHNpbXBsaWZpZXMgdGhlIHJ1bGVzIGFyb3Vu ZCBjcmVhdGlvbiBhbmQgYWNjZXB0YW5jZSBzaWduaWZpY2FudGx5LiAgDQo+UmVtb3ZlIHRoYXQg Y29uc3RyYWludCBhbmQgSSBkb24ndCBrbm93IHdoZXJlIHdlIGFyZSBhbnkgbW9yZS4NCg0KUGVy c29uYWxseSwgSSB0aGluayB0aGUgY2FzZSB3aGVyZSB0aGUgT2ZmZXJlciB3YW50cyB0byByZS1u ZWdvdGlhdGUgdGhlIGJ1bmRsZSBhZGRyZXNzIHdpbGwgYmUgdmVyeSByYXJlLiBJbiBwcmFjdGlj ZSwgSSB0aGluayBpdCB3aWxsIG9ubHkgaGFwcGVuIGlmIHRoZSBPZmZlcmVyIHVzZXMgYSByZS1J TlZJVEUgdG8gcGVyZm9ybSBhIHRyYW5zZmVyLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From bernard_aboba@hotmail.com Tue Jun 11 03:05:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC29D21F88EA for ; Tue, 11 Jun 2013 03:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.854 X-Spam-Level: X-Spam-Status: No, score=-101.854 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec74HkJ2GcW1 for ; Tue, 11 Jun 2013 03:05:32 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id F243E21F8C4C for ; Tue, 11 Jun 2013 03:05:31 -0700 (PDT) Received: from BLU404-EAS235 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jun 2013 03:05:31 -0700 X-TMN: [A/yAF0Y+oZR4N0LtzPxoTs70LdLwoCnR] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 11 Jun 2013 03:05:28 -0700 To: Cullen Jennings X-OriginalArrivalTime: 11 Jun 2013 10:05:31.0870 (UTC) FILETIME=[352927E0:01CE668B] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Congestion control X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 10:05:38 -0000 VoIP typically doesn't use layered coding or simulcast. Also, earlier there w= as a discussion of using signaling vs. Magnus' codec operation point to cont= rol resolution, which in the case of spatial scaling would involve addition o= r removal of layers - and as I recall, signaling won.=20 On Jun 10, 2013, at 11:10 PM, "Cullen Jennings" wrote: >=20 > On Jun 11, 2013, at 4:16 AM, Bernard Aboba wro= te: >=20 >> Cullen said:=20 >>=20 >>=20 >> " No O/A is request to stop sending RTP packets on a given stream. " >>=20 >> [BA] So you're saying that you don't expect a=3Dsendrecv/recvonly/sendon= ly to be used in Plan A to control streams described by individual m lines? = I had assumed that the O/A behavior described in RFC 3264 Sections 5.1 an= d 6.1 would apply in Plan A. =20 >=20 > Bernard - do you really think the "a=3Dsendrecv/recvonly/sendonly " is how= we do congestion control for VoIP? I don't think that is the approach that W= eRTC will take to congestion control. Of course "a=3Dsendrecv/recvonly/sendo= nly are part of SDP but they are not how anyone other than you has proposed= to do congestion control. I think you would agree they would be a pretty no= n optimal way to do congestion control.=20 >=20 >=20 >=20 >=20 >=20 >=20 From kevin.gross@avanw.com Tue Jun 11 06:30:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81921F8EBE for ; Tue, 11 Jun 2013 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.508 X-Spam-Level: X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ua+cvrSRDjv for ; Tue, 11 Jun 2013 06:30:16 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id A3A9021F8FA3 for ; Tue, 11 Jun 2013 06:30:16 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta02.emeryville.ca.mail.comcast.net with comcast id n02k1l00116AWCUA21WG8F; Tue, 11 Jun 2013 13:30:16 +0000 Received: from mail-ie0-x230.google.com ([IPv6:2607:f8b0:4001:c03::230]) by omta06.emeryville.ca.mail.comcast.net with comcast id n1WF1l0094xlzhT8S1WF92; Tue, 11 Jun 2013 13:30:16 +0000 Received: by mail-ie0-f176.google.com with SMTP id ar20so17194206iec.21 for ; Tue, 11 Jun 2013 06:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sydfQlGbnylY3z5dug8+qnSNBlMPjdCwbFV2g9il4C8=; b=IzsERq/z7u1vsPkNmZN69f/7JyFMVmghkHdwct7ehSqEvL4eCMOc7JD28C8ip8voP/ SJhsK9nxfSAp+h565v+zSpWeOEXfWyz63VdaG3ZHsVbXkT/HOjSBzTM6QBMMV7S65Tor 6RGYTkXcJfcGLE6ZvE7LF/YFZbGyDtfze+TaKvIppnoIHDwQBVGMoGq1i1jwwlBAkerg iCYWNCgJfqVEEomxb6osiyeiDw1jqTuAWcOGTT/A5rgdHzD9KKyVsOR5PcWgyW5HqWIx I+bWMrRViIPFOydErgQ1P9LF3fJcJJJzSLKGWY7wZILDNzJGOAlV8emb9KtPGDp+htkc scgw== MIME-Version: 1.0 X-Received: by 10.50.136.168 with SMTP id qb8mr971624igb.5.1370957415385; Tue, 11 Jun 2013 06:30:15 -0700 (PDT) Received: by 10.50.149.199 with HTTP; Tue, 11 Jun 2013 06:30:15 -0700 (PDT) In-Reply-To: References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> Date: Tue, 11 Jun 2013 07:30:15 -0600 Message-ID: From: Kevin Gross To: Colin Perkins Content-Type: multipart/alternative; boundary=089e0149495ebf11ca04dee0e527 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370957416; bh=sydfQlGbnylY3z5dug8+qnSNBlMPjdCwbFV2g9il4C8=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=VzNfn5DGAQCbiyTu8/O7mfMgnMJZFmHmrOrXCUxD085e5RnXygTYjNz8mVq+OlZ0p F8dw3zlMDq25FjNUhoNuNfWr2syHn4CkvbNzNUjv7fUDsxZf72Am9cM+n0814mD5za 62L/7fMX6yAbqBs1yLIL3mVbQGE2YzYu2JeLNgHP1KLL6TBdUZhAZYQdIeSSiBwsnD FG00l82F7o0/kwcB46LGcbwg5E4OiWR4WX9CnaYBx5CvFtUxpLldidY/z1fUaTuue7 hP/Gmw5qv5wWwG6FptwXVdTZws+NoQMnLVGyFWVJDUHOrPN4NFeAkqVphNFtaX/mZ7 QR4WBDEh2eRvg== Cc: mmusic , "avt@ietf.org" , "draft-ietf-avtcore-clksrc@tools.ietf.org" Subject: Re: [MMUSIC] [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:30:20 -0000 --089e0149495ebf11ca04dee0e527 Content-Type: text/plain; charset=ISO-8859-1 I've read section 12.2 of RFC 5576 and it is unclear to me whether a properly-registered attribute also requires a separate registration to be used as a source-level attribute. I gather there's some uncertainty on Colin's part. Can anyone help clarify these requirements for us? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Fri, May 3, 2013 at 10:26 AM, Colin Perkins wrote: > On 21 Apr 2013, at 07:39, Roni Even wrote: > > I would like to start a WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock > Source Signalling. > > > > The WGLC will end on May 12th , 2013 > > > > Please review the draft and send comments to the list. > > This generally looks good, and I had only one comment: if I'm reading RFC > 5576 correctly, this draft needs to include IANA registrations for > "att-field (source level)" for the SDP attributes, to allow them to be used > in the a=ssrc: lines. Making this change will probably also requires > changes to the ABNF, to cleanly separate the syntax for "a=..." and > "a=ssrc: ..." forms so they can be separately referenced. > > -- > Colin Perkins > http://csperkins.org/ > > > > --089e0149495ebf11ca04dee0e527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've read section 12.2 of RFC 5576 and it is unclear t= o me whether a properly-registered attribute also requires a separate regis= tration to be used as a source-level attribute. I gather there's some u= ncertainty on Colin's part. Can anyone help clarify these requirements = for us?

Kevin Gross
+1-30= 3-447-0517
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Fri, May 3, 2013 at 10:26 AM, Colin P= erkins <csp@csperkins.org> wrote:
On 21 Apr 2013, at 07:39, Roni Even wrote:
> I would like to start a WGLC on http://tools.ietf.org/html/= draft-ietf-avtcore-clksrc-03 =A0, RTP Clock Source Signalling.
>
> The WGLC will end on May 12th , 2013
>
> Please review the draft and send comments to the list.

This generally looks good, and I had only one comment: if I'm rea= ding RFC 5576 correctly, this draft needs to include IANA registrations for= "att-field (source level)" for the SDP attributes, to allow them= to be used in the a=3Dssrc: lines. Making this change will probably also r= equires changes to the ABNF, to cleanly separate the syntax for "a=3D.= .." and "a=3Dssrc: ..." forms so they can be separately refe= renced.

--
Colin Perkins
http://csperkins.org/




--089e0149495ebf11ca04dee0e527-- From pkyzivat@alum.mit.edu Tue Jun 11 07:46:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3700121F9925 for ; Tue, 11 Jun 2013 07:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E25w3ax2iYO7 for ; Tue, 11 Jun 2013 07:46:17 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 98B5721F999A for ; Tue, 11 Jun 2013 07:46:14 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id myhA1l00F0vyq2s5F2mDBv; Tue, 11 Jun 2013 14:46:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id n2mD1l00z3ZTu2S3R2mDtc; Tue, 11 Jun 2013 14:46:13 +0000 Message-ID: <51B73834.3090209@alum.mit.edu> Date: Tue, 11 Jun 2013 10:46:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> <51B4B64B.1050101@alum.mit.edu> <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca> <949EF20990823C4C85C18D59AA11AD8B049607@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370961973; bh=+214PhgTQGB7N9KukxSNxwFfIaE8A6xm1PHPJ3jDiso=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DeMwsk4T3+1xOqv8nIE/KWk7aMhgmDfOGWTMT2LL+6VtZCHZnXGslLSRQTXK2P6st 8ioVCPHhamW6ChnwY6h+ZWXjKmrPVtzNQFG6z9U26/hrjYGEaJb9ReLo73CAUAcGBq ApaWcZQvh6N/iuYxJwsDQrEhuUZ+hJBrBtHcfCAJp5mH5TPNqBgMuWj/ecUoNT7Nit 8tqcSAxVK71uL+bfgRJMRK4A6PQ5Ul79ypFuZXP/ptW+B6VSa3+/+h4Ebxb3XnixHJ eNL+5VYdLXT1JvDL8LOGyFoxAyu9Zm5iNbDr2BHPs/NtG0LUcZdskElmJWVFMlQ2+Z X94UEcPt1NbVg== Cc: "DRAGE, Keith \(Keith\)" , "mmusic@ietf.org WG" Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 14:46:23 -0000 On 6/11/13 2:00 AM, Cullen Jennings wrote: > > Sorry - trying to say > > Several of the implementations of 100rel have bugs in the case of where there is an outstanding transaction and they get an event that might cause them to want to start a second transaction before the first transaction completes. We are in real trouble if we say a feature can't be used because some implementations of it are buggy. We might as well all go home. (It's a different story if nobody is able to construct a working implementation.) Thanks, Paul > On Jun 10, 2013, at 7:47 PM, "DRAGE, Keith (Keith)" wrote: > >> "has an implantation that does not meet the requirements of the RFC - particularly in the many unspecified corner cases" >> >> Does not make sense! > > From pkyzivat@alum.mit.edu Tue Jun 11 07:59:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FED221F8D79 for ; Tue, 11 Jun 2013 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.238 X-Spam-Level: X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU7CtQd1v-Cl for ; Tue, 11 Jun 2013 07:59:44 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9282921F8C20 for ; Tue, 11 Jun 2013 07:59:43 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id n1LP1l0041wpRvQ532ziiZ; Tue, 11 Jun 2013 14:59:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id n2zi1l00n3ZTu2S3e2zin4; Tue, 11 Jun 2013 14:59:42 +0000 Message-ID: <51B73B5D.6010704@alum.mit.edu> Date: Tue, 11 Jun 2013 10:59:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370962782; bh=ofDMmvOnnU3jSGoAf2TnyudRCnuCzSE24Sd2ddW5F94=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TafceGYZchuH+yLrSbxt1i4dznpG8UcJTudg3UiYefprH0DMrmk+P8Sxe3KhAU3Bz xHk3tG/0TAG3ASSU8NwaJa8g9pdZMsivaRK9JaC5D84+Uedb8ptzMg1LJxpF872PbI SGJkFgis+tdSmEaXXvrUIhXiRe5wpk5y5VDTjonbMveoEdS5ZegNj7Gljwmp6RACTK VSwLTXl6KCxoOVC52uT20g/rLu3Tpo29iGiP91O/Q1+Ka7WyEFHuUq/H/UhepGnNsu Laca98n/B5TtacZ56YGRqP4+LqC4MsXfP36Kj+BU1gKWcJOTN14huFoFiguLkgEVk+ 3aQ3hyKJEhM8w== Subject: Re: [MMUSIC] [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 14:59:48 -0000 On 6/11/13 9:30 AM, Kevin Gross wrote: > I've read section 12.2 of RFC 5576 and it is unclear to me whether a > properly-registered attribute also requires a separate registration to > be used as a source-level attribute. I gather there's some uncertainty > on Colin's part. Can anyone help clarify these requirements for us? IMO this is a bit of a mess. We can ask the authors what they intended, but in the end it was a wg document, so maybe its up to the wg to decide. I'm also unclear whether the IANA registry structure that got built for this is exactly what was intended. IMO the collective IANA registry structures for registering SDP attributes is far from ideal. As the registry is currently constructed there is definitely a need for a separate entry for source level attributes. Perhaps a single registration request can be for multiple entries - that comes down to details of what a "request" is. IMO the registry should be restructured, so that there is a single table for all SDP attributes, with a column indicating in which context(s) it may be used: session level, media level, and/or source level. If that were so, then a single registration could define as many of those as made sense for an attribute. Thanks, Paul > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > On Fri, May 3, 2013 at 10:26 AM, Colin Perkins > wrote: > > On 21 Apr 2013, at 07:39, Roni Even wrote: > > I would like to start a WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock > Source Signalling. > > > > The WGLC will end on May 12th , 2013 > > > > Please review the draft and send comments to the list. > > This generally looks good, and I had only one comment: if I'm > reading RFC 5576 correctly, this draft needs to include IANA > registrations for "att-field (source level)" for the SDP attributes, > to allow them to be used in the a=ssrc: lines. Making this change > will probably also requires changes to the ABNF, to cleanly separate > the syntax for "a=..." and "a=ssrc: ..." forms so they can be > separately referenced. > > -- > Colin Perkins > http://csperkins.org/ > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Tue Jun 11 11:09:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8B621F8628 for ; Tue, 11 Jun 2013 11:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsOh0Y-ieckT for ; Tue, 11 Jun 2013 11:09:36 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8621F8617 for ; Tue, 11 Jun 2013 11:09:36 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so2184629wib.8 for ; Tue, 11 Jun 2013 11:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wWz8DSRv0Cdg+irIY3+fSJficn3Oz0IcytS53gU7z0s=; b=tVDFdw30vqVdNN9Gk/E9Cl6BFQlFRh57ZaMId7NZOkCQVw66uuo5p4jsTYb5DDxfqX R0M6mvunSExhggyWFNlR6KWXbXBh+qzo2KonpXQvbpZHwwZ/oYxcKdaC+xkVW6/vBSpb EliZ99mtCKCokei6X7Xi3QiB2YfrGoTGClKBpPhUT9IZNGvOJLmoo9PrLU1XCP87kuaT kpvWlu6vT8UiAqlgVs7APdrVtgDNBuG3PMhm9oPFwI7F3oEfq/rOefOI0sDqiwHzGf+4 STI8tpx1JomRUBbF0JJPMjb475e8rPMdIyNBJJ5vga/Xnbj90+cEWult0unzXU/zg6sj REKA== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr2160872wik.14.1370974175492; Tue, 11 Jun 2013 11:09:35 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 11 Jun 2013 11:09:35 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C387D2D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3872B7@ESESSMB209.ericsson.se> <51B603E2.6030306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C387D2D@ESESSMB209.ericsson.se> Date: Tue, 11 Jun 2013 11:09:35 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:09:37 -0000 On 11 June 2013 02:15, Christer Holmberg wrote: > Personally, I think the case where the Offerer wants to re-negotiate the bundle address will be very rare. In practice, I think it will only happen if the Offerer uses a re-INVITE to perform a transfer. I can see this happening on ICE restart. I can't see that happening at the same O/A exchange as a stream addition. From martin.thomson@gmail.com Tue Jun 11 11:16:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55D21F991F for ; Tue, 11 Jun 2013 11:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBiad+rfvqdH for ; Tue, 11 Jun 2013 11:16:13 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 649E621F98C3 for ; Tue, 11 Jun 2013 11:16:12 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so1171223wiv.11 for ; Tue, 11 Jun 2013 11:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vMhUwTdXb6rLKHmKKClLRS8e6RgEGPxIZO3NT7J6Pm0=; b=nrQhRq+t+OY5p1BJw8w+SRCRemVJWT4eO4/mDjZ5S3BCoP3qACZ4vDuKhOPtWZqhAL ECu6xXMEb7lv11GHC/RWtbPOjvZ7fbw7axEc7GogMlwXAi91vCoUL46d1jetMawpa/YT fO02IckohTcV5nHmind2bXV9FV1GuQdn0vkj4N0adkS0FtwZ/4/Q6gUXN0q1ka4P3dcE 0oM5V6ZgQZRSrd4fUTILYzUAW0ALge+rBc93r0n95RiMe9zaIKOra42mry/k0KZ30Cx6 Z8ZejfcPM4SK0/W7r/pS58rX8/n2KRbwxyTrhmDd7FncFvvYKLGQKyfthu+v8opDLMQ1 k6ig== MIME-Version: 1.0 X-Received: by 10.180.36.12 with SMTP id m12mr2195313wij.10.1370974571998; Tue, 11 Jun 2013 11:16:11 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 11 Jun 2013 11:16:11 -0700 (PDT) In-Reply-To: References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> Date: Tue, 11 Jun 2013 11:16:11 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] Congestion control X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:16:14 -0000 On 11 June 2013 03:05, Bernard Aboba wrote: > Also, earlier there was a discussion of using signaling vs. Magnus' codec operation point to control resolution, which in the case of spatial scaling would involve addition or removal of layers - and as I recall, signaling won. I wasn't there for that discussion, but I can imagine that that conclusion might have been not representative for a number of reasons. When you talk about "addition", then I believe that signaling is necessary (unless that was already allowed in the session description somehow). However, removal isn't so clear cut. "Removal" might be a permanent thing, in which case, an argument could be made for signaling. Where "removal" is just stopping transmission due to congestion (or other transient conditions), then I don't think that that signaling is appropriate. The objections to COP might also have been influenced by the IPR declarations on the document. From ron.even.tlv@gmail.com Tue Jun 11 15:07:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA5421F9A61 for ; Tue, 11 Jun 2013 15:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRfGtut+gL17 for ; Tue, 11 Jun 2013 15:07:09 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 039AE21F9A5F for ; Tue, 11 Jun 2013 15:07:08 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so6510116eaj.15 for ; Tue, 11 Jun 2013 15:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=dNLG0iIYZZd38k8nRoCl2mjSYuZezOJVJSYvk2MOMz8=; b=yaiN19VYmKxwZ6YiUhULrMbSACweGlFuEYzPxzK/ZzLHqIbWTCi6hTmcdf8b34XW0h j4KC/qz2lU+pkNPwQRtsXSPPPJk36w8YuQD6n2O7bbgQ8tnVdrZDHAaj9IQkwsLF2TbH thlBg0kfPpUxk7nIOVtueSUcWgjeY1ZEdvgCuiZOuAKN0CUBwQ7B5d2q4KP/qswiuEwE 3+rD/Spz3lhOcqngrL9BRy2HiupuZxlJ3yUGBQFgxUkaPcksj2PgPC0b559es7B4HmuQ d1RQNtEnEEhj0DsvdE0vFu0CDzNHaeC6JVOp9mOcln+3kyMnwZa8y2krXpQ3V/HyfnSJ Hl7g== X-Received: by 10.15.26.199 with SMTP id n47mr18669430eeu.88.1370988427887; Tue, 11 Jun 2013 15:07:07 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id bk1sm33026354eeb.5.2013.06.11.15.07.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Jun 2013 15:07:07 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , Date: Wed, 12 Jun 2013 01:05:45 +0300 Message-ID: <068401ce66ef$d43a71e0$7caf55a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5m74knfiPxq7QxRnCpVCeE5c2dRw== Content-Language: en-us Subject: [MMUSIC] RFC5576 ssrc attributes registeration was WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:07:10 -0000 Hi, I agree with Paul that it is not clear what need to be registered as SSRC attribute. What makes it unclear to me is that the ABNF in RFC5576 ssrc-attr = "ssrc:" ssrc-id SP attribute ; The base definition of "attribute" is in RFC 4566. ; (It is the content of "a=" lines.) ssrc-id = integer ; 0 .. 2**32 - 1 attribute =/ ssrc-attr make it look like you only need to register specific ssrc-attr while any existing session or media level attribute are covered. I assume that it will make sense only for media level attributes. I think this will relate also to the usage of the SSRC attribute for the multi-stream support Roni > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 11 June, 2013 6:00 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 > > On 6/11/13 9:30 AM, Kevin Gross wrote: > > I've read section 12.2 of RFC 5576 and it is unclear to me whether a > > properly-registered attribute also requires a separate registration to > > be used as a source-level attribute. I gather there's some uncertainty > > on Colin's part. Can anyone help clarify these requirements for us? > > IMO this is a bit of a mess. We can ask the authors what they intended, but in > the end it was a wg document, so maybe its up to the wg to decide. I'm also > unclear whether the IANA registry structure that got built for this is exactly > what was intended. IMO the collective IANA registry structures for > registering SDP attributes is far from ideal. > > As the registry is currently constructed there is definitely a need for a > separate entry for source level attributes. Perhaps a single registration > request can be for multiple entries - that comes down to details of what a > "request" is. > > IMO the registry should be restructured, so that there is a single table for all > SDP attributes, with a column indicating in which context(s) it may be used: > session level, media level, and/or source level. If that were so, then a single > registration could define as many of those as made sense for an attribute. > > Thanks, > Paul > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com , > www.X192.org > > > > > > > > On Fri, May 3, 2013 at 10:26 AM, Colin Perkins > > wrote: > > > > On 21 Apr 2013, at 07:39, Roni Even wrote: > > > I would like to start a WGLC on > > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock > > Source Signalling. > > > > > > The WGLC will end on May 12th , 2013 > > > > > > Please review the draft and send comments to the list. > > > > This generally looks good, and I had only one comment: if I'm > > reading RFC 5576 correctly, this draft needs to include IANA > > registrations for "att-field (source level)" for the SDP attributes, > > to allow them to be used in the a=ssrc: lines. Making this change > > will probably also requires changes to the ABNF, to cleanly separate > > the syntax for "a=..." and "a=ssrc: ..." forms so they can be > > separately referenced. > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ron.even.tlv@gmail.com Tue Jun 11 15:21:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E7B21F9A31 for ; Tue, 11 Jun 2013 15:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqRvWfVIAkDT for ; Tue, 11 Jun 2013 15:21:19 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C568721F9A64 for ; Tue, 11 Jun 2013 15:21:18 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id d41so2902958eek.5 for ; Tue, 11 Jun 2013 15:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=9Yid/6Swb38FFnS9YwacBKSp0P6cUE3MStpv/9k+gFE=; b=Mdua/Ui9hER2y74SvRTWac9iubvaKYhx0SZMDmN/z4f3xNnhDILAxnoV07p9PqOQhK R9g5zFqzXb/edkyZnkr99b5ornc1qUT7/+cwy0K10c/7fVzcIoPsUEVWCoTo68/PVwbz Iz1Xj9lCAhmKUwtX+vTVE8wfHubEZH5zm0D2rTjAUakCMAmfohyLGWSMz7koE4Y1c7ra z87m+WI/AA3M9nZ/TgtYn0OBCmfM3bS3bqEZbYGfjjLcoJpNYdA2Mtjt2NoKhAG+RVpk oqn2osohjG5AHQCbtVmQD6o0PN/yv+1by1QgizqLli1FXB0dIqdGhXyZbujXQ/aaa97x SO4A== X-Received: by 10.15.22.3 with SMTP id e3mr997166eeu.27.1370989272561; Tue, 11 Jun 2013 15:21:12 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id p43sm33026896eem.11.2013.06.11.15.21.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Jun 2013 15:21:11 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: In-Reply-To: Date: Wed, 12 Jun 2013 01:19:49 +0300 Message-ID: <068b01ce66f1$cbacbd10$63063730$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5m74knfiPxq7QxRnCpVCeE5c2dRwAAW9rA Content-Language: en-us Cc: mmusic-chairs@tools.ietf.org Subject: Re: [MMUSIC] RFC5576 ssrc attributes registeration was WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:21:21 -0000 Hi, Looking at the IANA registry, http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml , I can see that IANA puts the attribute in a table based on the registration template for media level, session level or both. So the question is what will happen if you want to register anew attribute using the template SDP Attribute ("att-field"): Attribute name: ts-refclk Long form: Timestamp reference clock source Type of name: att-field Type of attribute: Session, media and source level Subject to charset: No Purpose: See section 4 of this document Reference: This document Values: See this document and registrations below It is clear that it should go to the both session and media level table but what about source level. Currently I assume that it implies that it will be registered in two tables the both session and media table and the source level table. Roni > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 12 June, 2013 1:06 AM > To: 'Paul Kyzivat'; 'mmusic@ietf.org' > Subject: RFC5576 ssrc attributes registeration was WGLC on draft-ietf- > avtcore-clksrc-03 > > Hi, > I agree with Paul that it is not clear what need to be registered as SSRC > attribute. What makes it unclear to me is that the ABNF in RFC5576 > > ssrc-attr = "ssrc:" ssrc-id SP attribute > ; The base definition of "attribute" is in RFC 4566. > ; (It is the content of "a=" lines.) > > ssrc-id = integer ; 0 .. 2**32 - 1 > > attribute =/ ssrc-attr > > make it look like you only need to register specific ssrc-attr while any existing > session or media level attribute are covered. I assume that it will make sense > only for media level attributes. > I think this will relate also to the usage of the SSRC attribute for the multi- > stream support Roni > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 11 June, 2013 6:00 PM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 > > > > On 6/11/13 9:30 AM, Kevin Gross wrote: > > > I've read section 12.2 of RFC 5576 and it is unclear to me whether a > > > properly-registered attribute also requires a separate registration > > > to be used as a source-level attribute. I gather there's some > > > uncertainty on Colin's part. Can anyone help clarify these requirements > for us? > > > > IMO this is a bit of a mess. We can ask the authors what they > > intended, but in the end it was a wg document, so maybe its up to the > > wg to decide. I'm also unclear whether the IANA registry structure > > that got built for this is exactly what was intended. IMO the > > collective IANA registry structures for registering SDP attributes is far from > ideal. > > > > As the registry is currently constructed there is definitely a need > > for a separate entry for source level attributes. Perhaps a single > > registration request can be for multiple entries - that comes down to > > details of what a "request" is. > > > > IMO the registry should be restructured, so that there is a single > > table for all SDP attributes, with a column indicating in which context(s) it > may be used: > > session level, media level, and/or source level. If that were so, then > > a single registration could define as many of those as made sense for an > attribute. > > > > Thanks, > > Paul > > > > > Kevin Gross > > > +1-303-447-0517 > > > Media Network Consultant > > > AVA Networks - www.AVAnw.com , > > www.X192.org > > > > > > > > > > > > On Fri, May 3, 2013 at 10:26 AM, Colin Perkins > > > wrote: > > > > > > On 21 Apr 2013, at 07:39, Roni Even wrote: > > > > I would like to start a WGLC on > > > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock > > > Source Signalling. > > > > > > > > The WGLC will end on May 12th , 2013 > > > > > > > > Please review the draft and send comments to the list. > > > > > > This generally looks good, and I had only one comment: if I'm > > > reading RFC 5576 correctly, this draft needs to include IANA > > > registrations for "att-field (source level)" for the SDP attributes, > > > to allow them to be used in the a=ssrc: lines. Making this change > > > will probably also requires changes to the ABNF, to cleanly separate > > > the syntax for "a=..." and "a=ssrc: ..." forms so they can be > > > separately referenced. > > > > > > -- > > > Colin Perkins > > > http://csperkins.org/ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic From prvs=68754efaf8=christer.holmberg@ericsson.com Wed Jun 12 07:12:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800AD21F9BEB for ; Wed, 12 Jun 2013 07:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=-2.605, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJp4iN-BaHKH for ; Wed, 12 Jun 2013 07:12:29 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2521021F9BFE for ; Wed, 12 Jun 2013 07:12:27 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-60-51b881cad5f6 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 43.CE.10205.AC188B15; Wed, 12 Jun 2013 16:12:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 16:12:26 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9A== Date: Wed, 12 Jun 2013 14:12:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C388BD8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre6pxh2BBv2fdSymLn/M4sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7owP5/cyFXx+y1LRteUpcwPjiqUsXYycHBICJhKHJm1jg7DF JC7cWw9kc3EICRxllHi8fS6Us4RR4tHsz8xdjBwcbAIWEt3/tEEaRATUJb7u7WEGsYWBBv2d 8Y8dIm4pMefiTShbT2Lvk/dgy1gEVCU+NC5gBLF5BXwlHs+czwRiMwIt/n5qDZjNLCAucesJ RFxCQEBiyZ7zzBC2qMTLx/9YQU6QEFCUWN4vB1GeLzHtbzcbxEhBiZMzn7BMYBSahWTSLCRl s5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHMWpxUm56UYGmxiBwX9wy2+LHYyX /9ocYpTmYFES501U3REoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MMrvPmcx/ciqrbFF 5WLLbivMO9V+Xlp14+W7ggfXCczJFzYNZNOS27lQ8y/zopq9pSuXnvptzGHS2GPnIblxd0Rh /KkrPr0vuDP85m7Y5xizee0XJS6/hoN1ISf35BZPOnNt50QFnqjj8VpTX7jbSXLMfbppY0M2 +3KGawJH/z44tN2No9zIa7cSS3FGoqEWc1FxIgDCyRtdUQIAAA== X-Mailman-Approved-At: Wed, 12 Jun 2013 07:13:30 -0700 Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 14:12:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C388BD8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've gone through the comments received, and made some conclusions. First, defining Offer "types" was probably not a good idea. It caused confu= sion, and it was unclear whether it refers to the whole SDP body, or only i= ndividual BUNDLE groups within it. So, I've removed the BSO and BRO. I HAVE= defined a procedure called 'Bundle Address Synchronization (BAS)', which = is basically what the BSO was previously used for. But, it is not a new Off= er type, it is simply a procedure that an Offerer does (using an SDP Offer,= though). Also, we probably DO need more text on when a BAS is needed, but I hope you= understand what the intention of it is :) Second, there were different opinions on how flexible the mechanism should = be when it comes to re-negotiating the bundle address, and whether it shoul= d be allowed to do it in the same Offer used to e.g. adding an m=3D line. I= tried to come up with a compromise: What Paul wanted, but didn't get: - Paul wanted to be able to assign a new bundle address to multipl= e m- line, even if the bundle address hasn't been negotiated yet. What Paul got: - In order to negotiate/re-negotiate a bundle address, the Offerer= MUST assign unique addresses to each m- line. There Offerer CANNOT simply = add a new bundle address to multiple m- lines, until it has been negotiated= . What Martin wanted, but didn't get: - Martin wanted to use separate O/A transactions for negotiating t= he bundle address, and for adding m- lines to a BUNDLE group. What Martin got: - It IS allowed to add an m- line, and re-negotiate the bundle add= ress, in the same SDP Offer. However, as described above, in that case the = Offerer needs to assign unique addresses to each m- line. I am not saying we can't change what you got, and didn't get, but just keep= the assumptions above in mind when you read the text :) Third, I removed "Use Cases" section naming. The procedures contains lots o= f normative text, while Use Cases are normally informative, and used to pro= vide background information. Fourth, I know the especially Martin suggested some terminology changes. I = didn't forget those, but as many of those are no more valid, I thought it's= better to work based on the new text. Fifth, in section 6.1, please do not spend too much time on the numbered li= st at this point. It is still something we need to discuss, but I believe w= e need to make some progress on the Plan A vs B stuff first. At least I personally think the text is more clear, and easier to understan= d, now :) Regards, Christer ----------------------------------------------- 6. SDP Offer/Answer Procedures 6.1. General This section describes the usage of the SDP Offer/Answer mechanism [RFC3264] to negotiate the usage of the BUNDLE mechanism, to negotiate the bundle address, and to add, remove and reject SDP Media Descriptions ("m=3D" lines) associated with a BUNDLE group. The generic rules and procedures defined in [RFC3264] and [RFC5888] apply when the SDP Offer/Answer mechanism is used for BUNDLE. For example, if an SDP Offer is rejected, the previously negotiated SDP parameters and characteristics (including those associated with BUNDLE groups) apply. When an endpoint generates an SDP Offer, or an SDP Answer, which contains a BUNDLE group, the endpoint MUST assign SDP media-level mid value for each "m=3D" line in the BUNDLE group. In addition, the endpoint MUST insert an SDP session-level group:BUNDLE attribute, and place each mid value associated with the BUNDLE group in the attribute mid value list. Until the Offerer knows whether the Answerer supports the BUNDLE mechanism, the Offerer MUST, for each "m=3D" line in a BUNDLE group: o 1. Insert a unique address. o 2. Insert different SDP 'rtcp' attribute value, when used. o 3. Insert an SDP 'rtpc-mux' attribute. o 4. Insert identical DTLS-SRTP fingerprint attribute, when used o 5. Insert different SDES crypto attribute, when used Once it is known that both endpoints support the BUNDLE grouping extension, the SDP Offerer and Answerer MUST, for each "m=3D" line associated with a BUNDLE group: o 1. Insert either a unique address, or the bundle address associated with the BUNDLE group (see sections below for details). o 2. Insert identical SDP 'rtcp' attribute value, when used. o 3. Insert an SDP 'rtpc-mux' attribute. o 4. Insert identical DTLS-SRTP fingerprint attribute, when used o 5. Insert different SDES crypto attribute, when used READER'S HELP: The detailed definition of the 'Unique Address' and 'Bundle Address' terminology will be elsewhere in the document, but is basically contains the IP address, IP port and ICE candidates. Perhaps also media security parameters? 6.2. SDP Offerer Procedures 6.2.1. SDP Offerer Bundle Address Request and Usage An Offerer can assign an address to multiple "m=3D" lines in a BUNDLE group, once the address has been selected as the Offerer's local bundle address. An Offerer MUST NOT assign an address to multiple "m=3D" lines until the address has been selected as a bundle address for that BUNDLE group. In order to negotiate (or, to re-negotiate) the bundle address associated with a BUNDLE group, the Offerer, in the SDP Offer, assigns a unique address to each "m=3D" line in the BUNDLE group. In addition, the Offerer indicates which unique address it wishes to use as its local bundle address. There Offerer places the mid value, associated with the "m=3D" line that contains the preferred address first in the SDP group:BUNDLE attribute mid list. The Answerer then selects the local bundle address for the Offerer ([ref-to-be-added]). If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the bundle address associated with a BUNDLE group, it MAY assign the previously negotiated bundle address as a unique address to one of the "m=3D" lines in the BUNDLE group. If the Offerer assigns the bundle address to more than one "m=3D" line in a BUNDLE group, the first mid value in the SDP group:BUNDLE attribute mid value list MUST represent an "m=3D" line to which the bundle address is assigned. Hence, in order to re-negotiate the bundle address, the Offerer needs to assign a unique address to each "m=3D" line in the BUNDLE group, as described above. An Offerer MUST NOT assign a bundle address to an "m=3D" line that is not associated with a BUNDLE group. An Offerer MUST NOT assign a bundle address, that has been negotiated for a BUNDLE group, to an "m=3D" line that is associated with another BUNDLE group. Example: The example shows an SDP Offer, where a unique address is assigned to each "m=3D" line in the BUNDLE group. The Offerer requests the address associated with the audio "m=3D" line to be selected as its local bundle address, by placing the mid value associated with the "m=3D" line first in the SDP group:BUNDLE attribute mid value list. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 20000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 6.2.2. Bundle Address Synchronization (BAS) When an Offerer has sent an SDP Offer, a bundle address has been selected by the Answerer, and the bundle address was in the SDP Offer not assigned to each "m=3D" line in the BUNDLE group, the Offerer MUST send a new SDP Offer, in which it assigns the negotiated bundle address to each "m=3D" line in the BUNDLE group. This procedure is referred to as Bundle Address Synchronization (BAS). The Offerer MUST NOT modify any parameters associated with the BUNDLE group when it performs a BAS. NOTE: Eventhough the Offerer is not allowed to modify parameters associated with a BUNDLE group when it performs a BAS, the Answerer might modify parameters in the associated SDP Answer. For example, the Answerer can in the SDP Answer reject an "m=3D" line, by removing the rejected "m=3D" line from the BUNDLE group and assigning a zero port value to the rejected "m=3D" line ([ref-to-be-added]). Example: The example shows an SDP Offer, where the Offerer assigns the bundle address to each "m=3D" line in the BUNDLE group, in order to perform a Bundle Address Synchronization. SDP Offer (BAS) v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 6.2.3. Adding a media description to a BUNDLE group When an Offerer adds an "m=3D" line to a BUNDLE group, the Offerer MUST assign either a unique address, or the bundle address associated with the BUNDLE group, to the "m=3D" line that is added. In addition, the Offerer MUST assign a mid value for the "m=3D" line, and place it in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. NOTE: If the Offerer assigns a unique address to the "m=3D" line that is added to the BUNDLE group, it allows the Answerer to remove the "m=3D" line from the BUNDLE group without having to reject the "m=3D" line ([ref-to-be-added]). To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where a new "m=3D" line, identified by the "zen" mid value, is added to a BUNDLE group. The Offerer assigns a unique address to the "m=3D" line, and the bundle address to each of the other "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar zen m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 30000 RTP/AVP 60 a=3Dmid:zen b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.4. Removing A Media Description From A BUNDLE Group When an Offerer removes an "m=3D" line from a BUNDLE group, the Offerer MUST assign a unique address to the "m=3D" line that is removed. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows a BRO, where an "m=3D" line is removed from a BUNDLE group. The Offerer removes the mid ("zen") associated with the "m=3D" line from the SDP group:BUNDLE attribute mid value list, and assigns a unique address to the removed "m=3D" line. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is removed from a BUNDLE group. The Offerer assigns a unique address to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 40000 RTP/AVP 60 b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.5. Rejecting A Media Description In A BUNDLE Group When an Offerer rejects an "m=3D" line in a BUNDLE group, the Offerer MUST assign a unique address, with a zero port value [RFC3264], to the "m=3D" line that is rejected. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is rejected, and removed from a BUNDLE group. The Offerer assigns a unique address, with a zero port value, to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 0 RTP/AVP 60 a=3Drtpmap:60 H261/90000 --_000_7594FB04B1934943A5C02806D1A2204B1C388BD8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve gone through the comments received, and m= ade some conclusions.

 

First, defining Offer “types” was= probably not a good idea. It caused confusion, and it was unclear whether = it refers to the whole SDP body, or only individual BUNDLE groups within it= . So, I’ve removed the BSO and BRO. I HAVE defined a procedure called  ‘Bundle Address Synchronization (BAS)’= ;, which is basically what the BSO was previously used for. But, it is not = a new Offer type, it is simply a procedure that an Offerer does (using an S= DP Offer, though).

 

Also, we probably DO need more text on when a BAS is= needed, but I hope you understand what the intention of it is :)

 

 

Second, there were different opinions on how = flexible the mechanism should be when it comes to re-negotiating the bundle= address, and whether it should be allowed to do it in the same Offer used = to e.g. adding an m=3D line. I tried to come up with a compromise:

 

What Paul wanted, but didn’t get:

 

-     &= nbsp;    Paul wanted to be able to assign a new bundle addre= ss to multiple m- line, even if the bundle address hasn’t been negoti= ated yet.

 

What Paul got:

 

-     &= nbsp;    In order to negotiate/re-negotiate a bundle address= , the Offerer MUST assign unique addresses to each m- line. There Offerer C= ANNOT simply add a new bundle address to multiple m- lines, until it has be= en negotiated.

 

What Martin wanted, but didn’t get:=

 

-     &= nbsp;    Martin wanted to use separate O/A transactions for = negotiating the bundle address, and for adding m- lines to a BUNDLE group.<= o:p>

 

What Martin got:

 

-     &= nbsp;    It IS allowed to add an m- line, and re-negotiate t= he bundle address, in the same SDP Offer. However, as described above, in t= hat case the Offerer needs to assign unique addresses to each m- line.

 

 

I am not saying we can’t change what you got, = and didn’t get, but just keep the assumptions above in mind when you = read the text :)

 

 

Third, I removed “Use Cases” sect= ion naming. The procedures contains lots of normative text, while Use Cases= are normally informative, and used to provide background information.=

 

Fourth, I know the especially Martin suggeste= d some terminology changes. I didn’t forget those, but as many of tho= se are no more valid, I thought it’s better to work based on the new = text.

 

Fifth, in section 6.1, please do not spend to= o much time on the numbered list at this point. It is still something we ne= ed to discuss, but I believe we need to make some progress on the Plan A vs= B stuff first.

 

At least I personally think the text is more clear, = and easier to understand, now :)

 

Regards,

 

Christer

 

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

 

 

 

 

6.  SDP Offer/Answer Procedures

 

6.1.  General

 

   This section describes the usage of the SDP O= ffer/Answer mechanism

   [RFC3264] to negotiate the usage of the BUNDL= E mechanism, to

   negotiate the bundle address, and to add, rem= ove and reject SDP Media

   Descriptions ("m=3D" lines) associa= ted with a BUNDLE group.

 

   The generic rules and procedures defined in [= RFC3264] and [RFC5888]

   apply when the SDP Offer/Answer mechanism is = used for BUNDLE.  For

   example, if an SDP Offer is rejected, the pre= viously negotiated SDP

   parameters and characteristics (including tho= se associated with

   BUNDLE groups) apply.

 

   When an endpoint generates an SDP Offer, or a= n SDP Answer, which

   contains a BUNDLE group, the endpoint MUST as= sign SDP media-level mid

   value for each "m=3D" line in the B= UNDLE group.  In addition, the

   endpoint MUST insert an SDP session-level gro= up:BUNDLE attribute, and

   place each mid value associated with the BUND= LE group in the

   attribute mid value list.

 

   Until the Offerer knows whether the Answerer = supports the BUNDLE

   mechanism, the Offerer MUST, for each "m= =3D" line in a BUNDLE group:

 

   o  1.  Insert a unique address.

 

   o  2.  Insert different SDP 'rtcp' = attribute value, when used.

 

   o  3.  Insert an SDP 'rtpc-mux' att= ribute.

 

   o  4.  Insert identical DTLS-SRTP f= ingerprint attribute, when used

 

   o  5.  Insert different SDES crypto= attribute, when used

 

   Once it is known that both endpoints support = the BUNDLE grouping

   extension, the SDP Offerer and Answerer MUST,= for each "m=3D" line

   associated with a BUNDLE group:

 

   o  1.  Insert either a unique addre= ss, or the bundle address

      associated with the BUNDLE = group (see sections below for details).

 

   o  2.  Insert identical SDP 'rtcp' = attribute value, when used.

 

   o  3.  Insert an SDP 'rtpc-mux' att= ribute.

 

   o  4.  Insert identical DTLS-SRTP f= ingerprint attribute, when used

 

   o  5.  Insert different SDES crypto= attribute, when used

 

   READER'S HELP: The detailed definition of the= 'Unique Address' and

   'Bundle Address' terminology will be elsewher= e in the document, but

   is basically contains the IP address, IP port= and ICE candidates.

   Perhaps also media security parameters?<= /o:p>

 

6.2.  SDP Offerer Procedures

 

6.2.1.  SDP Offerer Bundle Address Request and Usage<= o:p>

 

   An Offerer can assign an address to multiple = "m=3D" lines in a BUNDLE

   group, once the address has been selected as = the Offerer's local

   bundle address.  An Offerer MUST NOT ass= ign an address to multiple

   "m=3D" lines until the address has = been selected as a bundle address

   for that BUNDLE group.

 

   In order to negotiate (or, to re-negotiate) t= he bundle address

   associated with a BUNDLE group, the Offerer, = in the SDP Offer,

   assigns a unique address to each "m=3D&q= uot; line in the BUNDLE group.  In

   addition, the Offerer indicates which unique = address it wishes to use

   as its local bundle address.  There Offe= rer places the mid value,

   associated with the "m=3D" line tha= t contains the preferred address

   first in the SDP group:BUNDLE attribute mid l= ist.  The Answerer then

   selects the local bundle address for the Offe= rer ([ref-to-be-added]).

 

   If the Offerer, in a subsequent SDP Offer, wa= nts to re-negotiate the

   bundle address associated with a BUNDLE group= , it MAY assign the

   previously negotiated bundle address as a uni= que address to one of

   the "m=3D" lines in the BUNDLE grou= p.

 

   If the Offerer assigns the bundle address to = more than one "m=3D" line

   in a BUNDLE group, the first mid value in the= SDP group:BUNDLE

   attribute mid value list MUST represent an &q= uot;m=3D" line to which the

   bundle address is assigned.  Hence, in o= rder to re-negotiate the

   bundle address, the Offerer needs to assign a= unique address to each

   "m=3D" line in the BUNDLE group, as= described above.

 

   An Offerer MUST NOT assign a bundle address t= o an "m=3D" line that is

   not associated with a BUNDLE group.  An = Offerer MUST NOT assign a

   bundle address, that has been negotiated for = a BUNDLE group, to an

   "m=3D" line that is associated with= another BUNDLE group.

 

   Example: The example shows an SDP Offer, wher= e a unique address is

   assigned to each "m=3D" line in the= BUNDLE group.  The Offerer requests

   the address associated with the audio "m= =3D" line to be selected as its

   local bundle address, by placing the mid valu= e associated with the

   "m=3D" line first in the SDP group:= BUNDLE attribute mid value list.

 

 

   SDP Offer

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 20000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

 

 

 

6.2.2.  Bundle Address Synchronization (BAS)

 

   When an Offerer has sent an SDP Offer, a bund= le address has been

   selected by the Answerer, and the bundle addr= ess was in the SDP Offer

   not assigned to each "m=3D" line in= the BUNDLE group, the Offerer MUST

   send a new SDP Offer, in which it assigns the= negotiated bundle

   address to each "m=3D" line in the = BUNDLE group.  This procedure is

   referred to as Bundle Address Synchronization= (BAS).

 

   The Offerer MUST NOT modify any parameters as= sociated with the BUNDLE

   group when it performs a BAS.

 

   NOTE: Eventhough the Offerer is not allowed t= o modify parameters

   associated with a BUNDLE group when it perfor= ms a BAS, the Answerer

   might modify parameters in the associated SDP= Answer.  For example,

   the Answerer can in the SDP Answer reject an = "m=3D" line, by removing

   the rejected "m=3D" line from the B= UNDLE group and assigning a zero

   port value to the rejected "m=3D" l= ine ([ref-to-be-added]).

 

   Example: The example shows an SDP Offer, wher= e the Offerer assigns

   the bundle address to each "m=3D" l= ine in the BUNDLE group, in order to

   perform a Bundle Address Synchronization.

 

 

   SDP Offer (BAS)

 

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

 

 

 

6.2.3.  Adding a media description to a BUNDLE group<= o:p>

 

   When an Offerer adds an "m=3D" line= to a BUNDLE group, the Offerer MUST

   assign either a unique address, or the bundle= address associated with

   the BUNDLE group, to the "m=3D" lin= e that is added.  In addition, the

   Offerer MUST assign a mid value for the "= ;m=3D" line, and place it in

   the SDP group:BUNDLE attribute mid value list= associated with the

   BUNDLE group.

 

   NOTE: If the Offerer assigns a unique address= to the "m=3D" line that

   is added to the BUNDLE group, it allows the A= nswerer to remove the

   "m=3D" line from the BUNDLE group w= ithout having to reject the "m=3D"

   line ([ref-to-be-added]).

 

   To the other "m=3D" lines (that pre= viously have been added to the

   BUNDLE group), the Offerer assigns addresses = according to the

   procedures in Section 6.2.1.

 

   Example: The example shows an SDP Offer, wher= e a new "m=3D" line,

   identified by the "zen" mid value, = is added to a BUNDLE group.  The

   Offerer assigns a unique address to the "= ;m=3D" line, and the bundle

   address to each of the other "m=3D"= lines in the BUNDLE group.

 

 

   SDP Offer

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar zen

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 30000 RTP/A= VP 60

       a=3Dmid:zen

       b=3DAS:1000

       a=3Drtpmap:60 H261/90= 000

 

 

 

6.2.4.  Removing A Media Description From A BUNDLE Gr= oup

 

   When an Offerer removes an "m=3D" l= ine from a BUNDLE group, the Offerer

   MUST assign a unique address to the "m= =3D" line that is removed.  In

   addition, the Offerer MUST NOT place the mid = value that was

   previously defined for the "m=3D" l= ine in the SDP group:BUNDLE

   attribute mid value list associated with the = BUNDLE group.

 

   To the other "m=3D" lines (that pre= viously have been added to the

   BUNDLE group), the Offerer assigns addresses = according to the

   procedures in Section 6.2.1.

 

   Example: The example shows a BRO, where an &q= uot;m=3D" line is removed from

   a BUNDLE group.  The Offerer removes the= mid ("zen") associated with

   the "m=3D" line from the SDP group:= BUNDLE attribute mid value list, and

   assigns a unique address to the removed "= ;m=3D" line.

 

   Example: The example shows an SDP Offer, wher= e an "video" "m=3D" line

   (previously identified by the "zen"= mid value), is removed from a

   BUNDLE group.  The Offerer assigns a uni= que address to the "m=3D" line,

   and the bundle address to each of the remaini= ng "m=3D" lines in the

   BUNDLE group.

 

 

   SDP Offer

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 40000 RTP/A= VP 60

       b=3DAS:1000

       a=3Drtpmap:60 H261/90= 000

 

 

 

6.2.5.  Rejecting A Media Description In A BUNDLE Gro= up

 

   When an Offerer rejects an "m=3D" l= ine in a BUNDLE group, the Offerer

   MUST assign a unique address, with a zero por= t value [RFC3264], to

   the "m=3D" line that is rejected.&n= bsp; In addition, the Offerer MUST NOT

   place the mid value that was previously defin= ed for the "m=3D" line in

   the SDP group:BUNDLE attribute mid value list= associated with the

   BUNDLE group.

 

   To the other "m=3D" lines (that pre= viously have been added to the

   BUNDLE group), the Offerer assigns addresses = according to the

   procedures in Section 6.2.1.

 

   Example: The example shows an SDP Offer, wher= e an "video" "m=3D" line

   (previously identified by the "zen"= mid value), is rejected, and

   removed from a BUNDLE group.  The Offere= r assigns a unique address,

   with a zero port value, to the "m=3D&quo= t; line, and the bundle address to

   each of the remaining "m=3D" lines = in the BUNDLE group.

 

 

   SDP Offer

 

       v=3D0

       o=3Dalice 2890844526 = 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN IP4 host.atlan= ta.com

       t=3D0 0

       a=3Dgroup:BUNDLE foo = bar

       m=3Daudio 10000 RTP/A= VP 0 8 97

       a=3Dmid:foo

       b=3DAS:200=

       a=3Drtpmap:0 PCMU/800= 0

       a=3Drtpmap:8 PCMA/800= 0

       a=3Drtpmap:97 iLBC/80= 00

       m=3Dvideo 10000 RTP/A= VP 31 32

       a=3Dmid:bar

       b=3DAS:1000

       a=3Drtpmap:31 H261/90= 000

       a=3Drtpmap:32 MPV/900= 00

       m=3Dvideo 0 RTP/AVP 6= 0

       a=3Drtpmap:60 H261/90= 000

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C388BD8ESESSMB209erics_-- From mary.ietf.barnes@gmail.com Wed Jun 12 08:51:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C47421F9A35 for ; Wed, 12 Jun 2013 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYIkHQ0blo4K for ; Wed, 12 Jun 2013 08:51:07 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F341721F9A1C for ; Wed, 12 Jun 2013 08:51:06 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so2496885qcw.29 for ; Wed, 12 Jun 2013 08:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D4Pw+Sqkp/U00YwDgt9oKULps+zmBA79BBhEbNaP800=; b=BfSYwwFY7ws50pZJrtDK9jsj9QrdmtJpGO/9bX/T+zHl+g0jpbSa+hG/jTnXgk3Tx+ r3AZY9vUT2RMRC1bRng6Nkhxs/EHtwejiLvBbgq/RDbshpeoNeVWIEe5yUI8D1MtaZNf lMfzhKu+KMIdjeKoU1DGxrrUmx08ail6Hwm42kd1OrXPNAOB1Bij5xC8E+oJcy1PLzds 0pvTQgyzUOOC9l7VKhep+UwiwlG34EtWzDoGXQu8iknjFbdiQKVKp4SfwjfEyjcz/Fpo koUNf3FHx5uVhKwVBiLwYwI2Q0br1Z5aRhcUVrgPRgx3mya2MfrHZnB9q6yO1WOWVUoz +LNw== MIME-Version: 1.0 X-Received: by 10.229.177.10 with SMTP id bg10mr2104178qcb.135.1371052265204; Wed, 12 Jun 2013 08:51:05 -0700 (PDT) Received: by 10.49.117.130 with HTTP; Wed, 12 Jun 2013 08:51:05 -0700 (PDT) In-Reply-To: <51A6700B.40108@cisco.com> References: <51A6700B.40108@cisco.com> Date: Wed, 12 Jun 2013 10:51:05 -0500 Message-ID: From: Mary Barnes To: Flemming Andreasen Content-Type: text/plain; charset=ISO-8859-1 Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:51:08 -0000 I apologize if the Webex info has already been posted, but I can't seem to find it (again). I have found it helpful for CLUE to post the info on the WG wiki so it's easier to find. Thanks, Mary. On Wed, May 29, 2013 at 4:15 PM, Flemming Andreasen wrote: > Greetings > > This is to announce a(nother) virtual interim meeting for the MMUSIC Working > Group to take place on Monday, June 17, from 7:00 am - 10:00 am > Pacific Time. The goal of this meeting is to come to a resolution on the > so-called "Plan A" or "Plan B" approach related to SDP signaling needed > by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or > very few "m=" lines and to what extent is there sub-negotation and > signaling at the SSRC level). > > A more detailed agenda and logistics will be sent out separately. For now, > people should take a close look at the following two drafts: > > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > > You may also want to look at > http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > > Thanks > > -- Ari & Flemming (MMUSIC co-chairs) > > > PS: Per our previous interim meeting announcement, we tried to schedule a > longer and in-person physical interim meeting, however it has proven > impossible to find a set of dates where we could get critical mass for such > a meeting. Scheduling even a virtual interim before the Berlin IETF has been > surprisingly difficult with the above date being the only viable option at > this point. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.belling@nsn.com Wed Jun 12 09:33:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC221F998A for ; Wed, 12 Jun 2013 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex21V8NmyQhX for ; Wed, 12 Jun 2013 09:33:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E97FB21F9989 for ; Wed, 12 Jun 2013 09:32:58 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5CGWv9s002996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 18:32:57 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5CGWuOC030602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 18:32:56 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Jun 2013 18:32:56 +0200 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.137]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 12 Jun 2013 18:32:56 +0200 From: "Belling, Thomas (NSN - DE/Munich)" To: ext Christer Holmberg , "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AAFMMPQ Date: Wed, 12 Jun 2013 16:32:54 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.103] Content-Type: multipart/alternative; boundary="_000_BDBE1A97E84675488F72A48C23811F350F2FABDEMUMBX001nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 30095 X-purgate-ID: 151667::1371054777-000017BA-A0B57C67/0-0/0-0 Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 16:33:11 -0000 --_000_BDBE1A97E84675488F72A48C23811F350F2FABDEMUMBX001nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Christer, only some comments on the terminology: "When an Offerer rejects an "m=3D" line in a BUNDLE group ..." I am used to terminology where an answerer "rejects" something that is bein= g offered, but is unclear what this means for an offerer. I assume what you are after is "disabling" an m-line. Perhaps this terminol= ogy would be clearer? You also speak about "Removing A Media Description From A BUNDLE Group". I see a certain risk that people misunderstand this to also mean "disabling= " an m-line. I assume what you are after is rather "Moving A Media Description out of a = BUNDLE Group". Perhaps this terminology would be clearer? Regards, Thomas From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Christer Holmberg Sent: Wednesday, June 12, 2013 4:12 PM To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) 6.2.4. Removing A Media Description From A BUNDLE Group When an Offerer removes an "m=3D" line from a BUNDLE group, the Offerer MUST assign a unique address to the "m=3D" line that is removed. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows a BRO, where an "m=3D" line is removed from a BUNDLE group. The Offerer removes the mid ("zen") associated with the "m=3D" line from the SDP group:BUNDLE attribute mid value list, and assigns a unique address to the removed "m=3D" line. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is removed from a BUNDLE group. The Offerer assigns a unique address to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 40000 RTP/AVP 60 b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.5. Rejecting A Media Description In A BUNDLE Group When an Offerer rejects an "m=3D" line in a BUNDLE group, the Offerer MUST assign a unique address, with a zero port value [RFC3264], to the "m=3D" line that is rejected. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is rejected, and removed from a BUNDLE group. The Offerer assigns a unique address, with a zero port value, to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 0 RTP/AVP 60 a=3Drtpmap:60 H261/90000 --_000_BDBE1A97E84675488F72A48C23811F350F2FABDEMUMBX001nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Ch= rister,

&n= bsp;

only so= me comments on the terminology:

&n= bsp;

“= When an Offerer rejects an "m=3D" line in a BUNDLE group …&= #8221;

I am us= ed to terminology where an answerer “rejects” something that is= being offered, but is unclear what this means for an offerer.

I assum= e what you are after is “disabling” an m-line. Perhaps this ter= minology would be clearer?

&n= bsp;

You als= o speak about “Removing A Media Description From A BUNDLE Group”= ;.

I see a= certain risk that people misunderstand this to also mean “disabling&= #8221; an m-line.

I assum= e what you are after is rather ”Moving A Media Description out of a B= UNDLE Group”. Perhaps this terminology would be clearer?

&n= bsp;

Regards= , Thomas

&n= bsp;

&n= bsp;

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg] On Behalf Of ext Christer Holmberg
Sent: Wednesday, June 12, 2013 4:12 PM
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

 

 

 

 

6.2.4.  Removing A Media Description F= rom A BUNDLE Group

 

   When an Offerer removes an &qu= ot;m=3D" line from a BUNDLE group, the Offerer

   MUST assign a unique address t= o the "m=3D" line that is removed.  In

   addition, the Offerer MUST NOT= place the mid value that was

   previously defined for the &qu= ot;m=3D" line in the SDP group:BUNDLE

   attribute mid value list assoc= iated with the BUNDLE group.

 

   To the other "m=3D" = lines (that previously have been added to the

   BUNDLE group), the Offerer ass= igns addresses according to the

   procedures in Section 6.2.1.

 

   Example: The example shows a B= RO, where an "m=3D" line is removed from

   a BUNDLE group.  The Offe= rer removes the mid ("zen") associated with

   the "m=3D" line from= the SDP group:BUNDLE attribute mid value list, and

   assigns a unique address to th= e removed "m=3D" line.

 

   Example: The example shows an = SDP Offer, where an "video" "m=3D" line

   (previously identified by the = "zen" mid value), is removed from a

   BUNDLE group.  The Offere= r assigns a unique address to the "m=3D" line,<= /p>

   and the bundle address to each= of the remaining "m=3D" lines in the

   BUNDLE group.

 

 

   SDP Offer

 

       v=3D0<= o:p>

       o=3Dal= ice 2890844526 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN= IP4 host.atlanta.com

       t=3D0 = 0

       a=3Dgr= oup:BUNDLE foo bar

       m=3Dau= dio 10000 RTP/AVP 0 8 97

       a=3Dmi= d:foo

       b=3DAS= :200

       a=3Drt= pmap:0 PCMU/8000

       a=3Drt= pmap:8 PCMA/8000

       a=3Drt= pmap:97 iLBC/8000

       m=3Dvi= deo 10000 RTP/AVP 31 32

       a=3Dmi= d:bar

       b=3DAS= :1000

       a=3Drt= pmap:31 H261/90000

       a=3Drt= pmap:32 MPV/90000

       m=3Dvi= deo 40000 RTP/AVP 60

       b=3DAS= :1000

       a=3Drt= pmap:60 H261/90000

 

 

 

6.2.5.  Rejecting A Media Description = In A BUNDLE Group

 

   When an Offerer rejects an &qu= ot;m=3D" line in a BUNDLE group, the Offerer

   MUST assign a unique address, = with a zero port value [RFC3264], to

   the "m=3D" line that= is rejected.  In addition, the Offerer MUST NOT

   place the mid value that was p= reviously defined for the "m=3D" line in

   the SDP group:BUNDLE attribute= mid value list associated with the

   BUNDLE group.

 

   To the other "m=3D" = lines (that previously have been added to the

   BUNDLE group), the Offerer ass= igns addresses according to the

   procedures in Section 6.2.1.

 

   Example: The example shows an = SDP Offer, where an "video" "m=3D" line

   (previously identified by the = "zen" mid value), is rejected, and

   removed from a BUNDLE group.&n= bsp; The Offerer assigns a unique address,

   with a zero port value, to the= "m=3D" line, and the bundle address to

   each of the remaining "m= =3D" lines in the BUNDLE group.

 

 

   SDP Offer

 

       v=3D0<= o:p>

       o=3Dal= ice 2890844526 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN= IP4 host.atlanta.com

       t=3D0 = 0

       a=3Dgr= oup:BUNDLE foo bar

       m=3Dau= dio 10000 RTP/AVP 0 8 97

       a=3Dmi= d:foo

       b=3DAS= :200

       a=3Drt= pmap:0 PCMU/8000

       a=3Drt= pmap:8 PCMA/8000

       a=3Drt= pmap:97 iLBC/8000

       m=3Dvi= deo 10000 RTP/AVP 31 32

       a=3Dmi= d:bar

       b=3DAS= :1000

       a=3Drt= pmap:31 H261/90000

       a=3Drt= pmap:32 MPV/90000

       m=3Dvi= deo 0 RTP/AVP 60

       a=3Drt= pmap:60 H261/90000

 

 

 

--_000_BDBE1A97E84675488F72A48C23811F350F2FABDEMUMBX001nsnintr_-- From prvs=68754efaf8=christer.holmberg@ericsson.com Wed Jun 12 10:29:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49221F9A13 for ; Wed, 12 Jun 2013 10:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=-2.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vy6BTgd6apg for ; Wed, 12 Jun 2013 10:29:23 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2408621F96C6 for ; Wed, 12 Jun 2013 10:28:40 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-b1-51b8afc77f2a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id BF.2E.10205.7CFA8B15; Wed, 12 Jun 2013 19:28:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 19:28:38 +0200 From: Christer Holmberg To: "Belling, Thomas (NSN - DE/Munich)" , mmusic_ietf.org Thread-Topic: BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AAFMMPQAAJ2veI= Date: Wed, 12 Jun 2013 17:28:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C389149@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C389149ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre7x9TsCDVaekbeYuvwxi0Xbrn2M DkweS5b8ZPL4uf4qewBTFLdNUmJJWXBmep6+XQJ3xqwFT5kK7l9jrLi06glTA+OUvYxdjJwc EgImEo0re1khbDGJC/fWs3UxcnEICRxllDi6/DorhLOEUeLGoXcsXYwcHGwCFhLd/7RBGkQE UiVmtf4EaxYGCr+fcoUFIm4pMefiTXYI20piQUMzG0gri4CqxPt77iAmr4CvxKItFRDT+xkl Dj45BHYPp4CfxNa/f5hBbEage76fWsMEYjMLiEvcejKfCeJOAYkle84zQ9iiEi8f/2OFqMmX eDjvDNgJvAKCEidnPmGZwCg8C0n7LCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjsvgC RvZVjBzFqcVJuelGBpsYgZFycMtvix2Ml//aHGKU5mBREudNVN0RKCSQnliSmp2aWpBaFF9U mpNafIiRiYMTRHBJNTD2y5ul/ufg0pyhZBoz01NmuWj17JD3DXd1Tm300HqfF25xpJJdMUEh ZMWpNU1Hr+WWMLY49F9g3XtMXGyT1o1zrw443Mqa0zbprcqC1YsYPyyPjrt1+MH8BSYlM7k2 hn94WOurK/QlxXVile+mG06ZN15XHjxUwrdPIOHfptATP7Z+fPV+0y5+JZbijERDLeai4kQA QDeRYmcCAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2013 17:29:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C389149ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, I used to have 'disable' for the Offerer, but there was a comment suggestin= g to use 'reject'. We can discuss it. I am ok to use 'move out of' terminology, as you suggest. Thanks! Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Belling, Thomas (NSN - DE/Munich) [thomas.belling@nsn.com] To: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic@ietf.org [mm= usic@ietf.org] Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th) Dear Christer, only some comments on the terminology: =93When an Offerer rejects an "m=3D" line in a BUNDLE group =85=94 I am used to terminology where an answerer =93rejects=94 something that is = being offered, but is unclear what this means for an offerer. I assume what you are after is =93disabling=94 an m-line. Perhaps this term= inology would be clearer? You also speak about =93Removing A Media Description From A BUNDLE Group=94= . I see a certain risk that people misunderstand this to also mean =93disabli= ng=94 an m-line. I assume what you are after is rather =94Moving A Media Description out of = a BUNDLE Group=94. Perhaps this terminology would be clearer? Regards, Thomas From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Christer Holmberg Sent: Wednesday, June 12, 2013 4:12 PM To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) 6.2.4. Removing A Media Description From A BUNDLE Group When an Offerer removes an "m=3D" line from a BUNDLE group, the Offerer MUST assign a unique address to the "m=3D" line that is removed. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows a BRO, where an "m=3D" line is removed from a BUNDLE group. The Offerer removes the mid ("zen") associated with the "m=3D" line from the SDP group:BUNDLE attribute mid value list, and assigns a unique address to the removed "m=3D" line. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is removed from a BUNDLE group. The Offerer assigns a unique address to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 40000 RTP/AVP 60 b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.5. Rejecting A Media Description In A BUNDLE Group When an Offerer rejects an "m=3D" line in a BUNDLE group, the Offerer MUST assign a unique address, with a zero port value [RFC3264], to the "m=3D" line that is rejected. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is rejected, and removed from a BUNDLE group. The Offerer assigns a unique address, with a zero port value, to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 0 RTP/AVP 60 a=3Drtpmap:60 H261/90000 --_000_7594FB04B1934943A5C02806D1A2204B1C389149ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Thomas,
 
I used to have 'disable' for the Offerer, but t= here was a comment suggesting to use 'reject'. We can discuss it.
 
I am ok to use 'move out of' terminology, as you suggest.
 
Thanks!
 
Regards,
 
Christer
 
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) [thomas.belling@nsn.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic@ietf.= org [mmusic@ietf.org]
Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th)

Dear Ch= rister,

 <= /span>

only so= me comments on the terminology:

 <= /span>

=93When= an Offerer rejects an "m=3D" line in a BUNDLE group =85=94

I am us= ed to terminology where an answerer =93rejects=94 something that is being o= ffered, but is unclear what this means for an offerer.

I assum= e what you are after is =93disabling=94 an m-line. Perhaps this terminology= would be clearer?

 <= /span>

You als= o speak about =93Removing A Media Description From A BUNDLE Group=94.

I see a= certain risk that people misunderstand this to also mean =93disabling=94 a= n m-line.

I assum= e what you are after is rather =94Moving A Media Description out of a BUNDL= E Group=94. Perhaps this terminology would be clearer?

 <= /span>

Regards= , Thomas

 <= /span>

 <= /span>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf= .org] On Behalf Of ext Christer Holmberg
Sent: Wednesday, June 12, 2013 4:12 PM
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)=

 

 

 

 

6.2.4.  Removing A Media Description = >From A BUNDLE Group

 

   When an Offerer removes an &q= uot;m=3D" line from a BUNDLE group, the Offerer

   MUST assign a unique address = to the "m=3D" line that is removed.  In

   addition, the Offerer MUST NO= T place the mid value that was

   previously defined for the &q= uot;m=3D" line in the SDP group:BUNDLE

   attribute mid value list asso= ciated with the BUNDLE group.

 

   To the other "m=3D"= lines (that previously have been added to the

   BUNDLE group), the Offerer as= signs addresses according to the

   procedures in Section 6.2.1.<= /span>

 

   Example: The example shows a = BRO, where an "m=3D" line is removed from

   a BUNDLE group.  The Off= erer removes the mid ("zen") associated with

   the "m=3D" line fro= m the SDP group:BUNDLE attribute mid value list, and

   assigns a unique address to t= he removed "m=3D" line.

 

   Example: The example shows an= SDP Offer, where an "video" "m=3D" line

   (previously identified by the= "zen" mid value), is removed from a

   BUNDLE group.  The Offer= er assigns a unique address to the "m=3D" line,

   and the bundle address to eac= h of the remaining "m=3D" lines in the

   BUNDLE group.

 

 

   SDP Offer

 

       v=3D0=

       o=3Da= lice 2890844526 2890844526 IN IP4 host.atlanta.com

       s=3D<= /span>

       c=3DI= N IP4 host.atlanta.com

       t=3D0= 0

       a=3Dg= roup:BUNDLE foo bar

       m=3Da= udio 10000 RTP/AVP 0 8 97

       a=3Dm= id:foo

       b=3DA= S:200

       a=3Dr= tpmap:0 PCMU/8000

       a=3Dr= tpmap:8 PCMA/8000

       a=3Dr= tpmap:97 iLBC/8000

       m=3Dv= ideo 10000 RTP/AVP 31 32

       a=3Dm= id:bar

       b=3DA= S:1000

       a=3Dr= tpmap:31 H261/90000

       a=3Dr= tpmap:32 MPV/90000

       m=3Dv= ideo 40000 RTP/AVP 60

       b=3DA= S:1000

       a=3Dr= tpmap:60 H261/90000

 

 

 

6.2.5.  Rejecting A Media Description= In A BUNDLE Group

 

   When an Offerer rejects an &q= uot;m=3D" line in a BUNDLE group, the Offerer

   MUST assign a unique address,= with a zero port value [RFC3264], to

   the "m=3D" line tha= t is rejected.  In addition, the Offerer MUST NOT

   place the mid value that was = previously defined for the "m=3D" line in

   the SDP group:BUNDLE attribut= e mid value list associated with the

   BUNDLE group.

 

   To the other "m=3D"= lines (that previously have been added to the

   BUNDLE group), the Offerer as= signs addresses according to the

   procedures in Section 6.2.1.<= /span>

 

   Example: The example shows an= SDP Offer, where an "video" "m=3D" line

   (previously identified by the= "zen" mid value), is rejected, and

   removed from a BUNDLE group.&= nbsp; The Offerer assigns a unique address,

   with a zero port value, to th= e "m=3D" line, and the bundle address to

   each of the remaining "m= =3D" lines in the BUNDLE group.

 

 

   SDP Offer

 

       v=3D0=

       o=3Da= lice 2890844526 2890844526 IN IP4 host.atlanta.com

       s=3D<= /span>

       c=3DI= N IP4 host.atlanta.com

       t=3D0= 0

       a=3Dg= roup:BUNDLE foo bar

       m=3Da= udio 10000 RTP/AVP 0 8 97

       a=3Dm= id:foo

       b=3DA= S:200

       a=3Dr= tpmap:0 PCMU/8000

       a=3Dr= tpmap:8 PCMA/8000

       a=3Dr= tpmap:97 iLBC/8000

       m=3Dv= ideo 10000 RTP/AVP 31 32

       a=3Dm= id:bar

       b=3DA= S:1000

       a=3Dr= tpmap:31 H261/90000

       a=3Dr= tpmap:32 MPV/90000

       m=3Dv= ideo 0 RTP/AVP 60

       a=3Dr= tpmap:60 H261/90000

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C389149ESESSMB209erics_-- From fandreas@cisco.com Wed Jun 12 15:00:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D423521E812F for ; Wed, 12 Jun 2013 15:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rctsEyD8AKO5 for ; Wed, 12 Jun 2013 15:00:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3FF21E8111 for ; Wed, 12 Jun 2013 15:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10663; q=dns/txt; s=iport; t=1371074434; x=1372284034; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=4UA+JcaIGMshkxe8uJn4Ib2BMelTFG/fhdyLbewX+No=; b=X38V+L74/97Kkw/go7RQQIPcrCvA0/F4jJ6Wc3pmu0t4BN1HDoP9AxZO FCyeasZvP0oQO0iajjdn8eQC7+88KH6Apm+z+mxyvJagIPNdJTgl6TA9I F7y5WYeRv79P21gHiivVkF7TUwFrqkhW5xfD+wbru648ZCZvIdC71k4SV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFANDuuFGtJXG9/2dsb2JhbABAFwODCTCDPYVetXiBARZ0giMBAQECAiNDAgYKDQQcAwECCgsEBwUGAgIJAwIBAgE0CQcBAwMNBgIBAQWIBQwzqSuEFo0rjgEbgQURARcGCweCNIEUA5dAiiqHGII/bCCBNQ X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208,217";a="222114738" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jun 2013 22:00:33 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5CM0WJU019387 for ; Wed, 12 Jun 2013 22:00:33 GMT Message-ID: <51B8EF80.7010002@cisco.com> Date: Wed, 12 Jun 2013 18:00:32 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> In-Reply-To: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000102040408050505050009" Subject: [MMUSIC] WebEx info for MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:00:39 -0000 This is a multi-part message in MIME format. --------------000102040408050505050009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Greetings Below you will find the WebEx information for joining the MMUSIC Virtual Interim meeting on June 17, 2013 from 7 am to 10 am Pacific Time. If you have not used WebEx before, you may want to join 5 minutes early. Thanks -- Flemming Topic: MMUSIC Virtual Interim Date: Monday, June 17, 2013 Time: 10:00 am, Eastern Daylight Time (New York, GMT-04:00) Meeting Number: 201 541 762 Password: mmusic ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=229251857&UID=2458&PW=NMDA5Mzg5NzVj&RT=MiMxMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: mmusic 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that appear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Global call-in numbers: https://ciscosales.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=229251857&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:201 541 762 CCP:+14085256800x201541762# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -------- Original Message -------- Subject: MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 Date: Thu, 30 May 2013 11:56:19 -0700 From: IESG Secretary Reply-To: To: IETF Announcement List CC: Greetings, This is to announce a(nother) virtual interim meeting for the MMUSIC Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately on the MMUSIC mailing list. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: Per our previous interim meeting announcement, we tried to schedule a longer and in-person physical interim meeting, however it has proven impossible to find a set of dates where we could get critical mass for such a meeting. Scheduling even a virtual interim before the Berlin IETF has been surprisingly difficult with the above date being the only viable option at this point. . --------------000102040408050505050009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Greetings

Below you will find the WebEx information for joining the MMUSIC Virtual Interim meeting on June 17, 2013 from 7 am to 10 am Pacific Time. If you have not used WebEx before, you may want to join 5 minutes early.

Thanks

-- Flemming

Topic: MMUSIC Virtual Interim
Date: Monday, June 17, 2013
Time: 10:00 am, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 201 541 762
Password: mmusic

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=229251857&UID=2458&PW=NMDA5Mzg5NzVj&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: mmusic
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that appear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800
Global call-in numbers: https://ciscosales.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=229251857&tollFree=1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:201 541 762




CCP:+14085256800x201541762#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.


-------- Original Message --------
Subject: MMUSIC Working Group Virtual Interim Meeting, June 17, 2013
Date: Thu, 30 May 2013 11:56:19 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: <ietf@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: <mmusic@ietf.org> 


Greetings,

This is to announce a(nother) virtual interim meeting for the MMUSIC 
Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am
Pacific Time. The goal of this meeting is to come to a resolution on the 
so-called "Plan A" or "Plan B" approach related to SDP signaling needed
by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or 
very few "m=" lines and to what extent is there sub-negotation and
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately on the 
MMUSIC mailing list. For now, people should take a close look at the 
following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt

You may also want to look at
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt


Thanks

-- Ari & Flemming (MMUSIC co-chairs)


PS: Per our previous interim meeting announcement, we tried to schedule 
a longer and in-person physical interim meeting, however it has proven 
impossible to find a set of dates where we could get critical mass for 
such a meeting. Scheduling even a virtual interim before the Berlin IETF 
has been surprisingly difficult with the above date being the only 
viable option at this point.
.


--------------000102040408050505050009-- From fandreas@cisco.com Wed Jun 12 15:02:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5076C21E812E for ; Wed, 12 Jun 2013 15:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p1cXcyjBoL8 for ; Wed, 12 Jun 2013 15:02:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6621E8134 for ; Wed, 12 Jun 2013 15:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2079; q=dns/txt; s=iport; t=1371074526; x=1372284126; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vFNd6EAAy7Gpi3SUiYCPqIgwSX42IM5UUTbg+Hiz5fg=; b=ZjvjUhTBkQM9pU9N9V9ZxSrJvjHvrPOOIbbIAT+Z2nGZgXra34iUxbfO cUNO7zhSHaaIWyqw4/npxlym3DefxRbJFwKCGWcUAsEDqcfWL1G3lwCgX PnwDiNXZHr7dEOV3J9RKm1kshsNf8y9agkWN6Tnyv4ckvUPSD9+8CUqsm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANDuuFGtJXG8/2dsb2JhbABagwkwvxOBARZ0giMBAQEEAQEBNTYKARALGAkWDwkDAgECARUwBg0BBQIBAQWIBQy7H49DB4NgA5dAkUKDKyA X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="219118147" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jun 2013 22:02:04 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5CM23kP030835; Wed, 12 Jun 2013 22:02:03 GMT Message-ID: <51B8EFDB.1010504@cisco.com> Date: Wed, 12 Jun 2013 18:02:03 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mary Barnes References: <51A6700B.40108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:02:18 -0000 Hi Mary I just posted the WebEx info to the MMUSIC list. We haven't been using the WG Wiki so far, but I agree it's a good idea, so we'll look into that in the future. Thanks -- Flemming On 6/12/13 11:51 AM, Mary Barnes wrote: > I apologize if the Webex info has already been posted, but I can't > seem to find it (again). I have found it helpful for CLUE to post the > info on the > WG wiki so it's easier to find. > > Thanks, > Mary. > > On Wed, May 29, 2013 at 4:15 PM, Flemming Andreasen wrote: >> Greetings >> >> This is to announce a(nother) virtual interim meeting for the MMUSIC Working >> Group to take place on Monday, June 17, from 7:00 am - 10:00 am >> Pacific Time. The goal of this meeting is to come to a resolution on the >> so-called "Plan A" or "Plan B" approach related to SDP signaling needed >> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or >> very few "m=" lines and to what extent is there sub-negotation and >> signaling at the SSRC level). >> >> A more detailed agenda and logistics will be sent out separately. For now, >> people should take a close look at the following two drafts: >> >> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt >> >> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt >> >> You may also want to look at >> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt >> >> >> Thanks >> >> -- Ari & Flemming (MMUSIC co-chairs) >> >> >> PS: Per our previous interim meeting announcement, we tried to schedule a >> longer and in-person physical interim meeting, however it has proven >> impossible to find a set of dates where we could get critical mass for such >> a meeting. Scheduling even a virtual interim before the Berlin IETF has been >> surprisingly difficult with the above date being the only viable option at >> this point. >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > . > From thomas.belling@nsn.com Thu Jun 13 01:43:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66121F99B2 for ; Thu, 13 Jun 2013 01:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNFfL4AotK3M for ; Thu, 13 Jun 2013 01:43:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 14D5721F9A97 for ; Thu, 13 Jun 2013 01:42:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5D8gpdp010969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 10:42:53 +0200 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5D8gmRV029538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 10:42:51 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Jun 2013 10:41:56 +0200 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.137]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Thu, 13 Jun 2013 10:41:56 +0200 From: "Belling, Thomas (NSN - DE/Munich)" To: ext Christer Holmberg , "mmusic_ietf.org" Thread-Topic: BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AAFMMPQAAJ2veIAH8VioA== Date: Thu, 13 Jun 2013 08:41:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C389149@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C389149@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.103] Content-Type: multipart/alternative; boundary="_000_BDBE1A97E84675488F72A48C23811F350F40BBDEMUMBX001nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 35437 X-purgate-ID: 151667::1371112974-000017BA-E2E6A2BB/0-0/0-0 Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 08:43:07 -0000 --_000_BDBE1A97E84675488F72A48C23811F350F40BBDEMUMBX001nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Christer, I would clearly prefer "disable", as "reject" in my view only fits for some= thing that is being offered. What was the reasoning brought forward to use "reject"? Thomas From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, June 12, 2013 7:29 PM To: Belling, Thomas (NSN - DE/Munich); mmusic_ietf.org Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th) Hi Thomas, I used to have 'disable' for the Offerer, but there was a comment suggestin= g to use 'reject'. We can discuss it. I am ok to use 'move out of' terminology, as you suggest. Thanks! Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Belling, Thomas (NSN - DE/Munich) [thomas.belling@nsn.com] To: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic@ietf.org [mmusic@ietf.org] Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th) Dear Christer, only some comments on the terminology: "When an Offerer rejects an "m=3D" line in a BUNDLE group ..." I am used to terminology where an answerer "rejects" something that is bein= g offered, but is unclear what this means for an offerer. I assume what you are after is "disabling" an m-line. Perhaps this terminol= ogy would be clearer? You also speak about "Removing A Media Description From A BUNDLE Group". I see a certain risk that people misunderstand this to also mean "disabling= " an m-line. I assume what you are after is rather "Moving A Media Description out of a = BUNDLE Group". Perhaps this terminology would be clearer? Regards, Thomas From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of ext Christer Holmberg Sent: Wednesday, June 12, 2013 4:12 PM To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) 6.2.4. Removing A Media Description From A BUNDLE Group When an Offerer removes an "m=3D" line from a BUNDLE group, the Offerer MUST assign a unique address to the "m=3D" line that is removed. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows a BRO, where an "m=3D" line is removed from a BUNDLE group. The Offerer removes the mid ("zen") associated with the "m=3D" line from the SDP group:BUNDLE attribute mid value list, and assigns a unique address to the removed "m=3D" line. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is removed from a BUNDLE group. The Offerer assigns a unique address to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 40000 RTP/AVP 60 b=3DAS:1000 a=3Drtpmap:60 H261/90000 6.2.5. Rejecting A Media Description In A BUNDLE Group When an Offerer rejects an "m=3D" line in a BUNDLE group, the Offerer MUST assign a unique address, with a zero port value [RFC3264], to the "m=3D" line that is rejected. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=3D" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=3D" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where an "video" "m=3D" line (previously identified by the "zen" mid value), is rejected, and removed from a BUNDLE group. The Offerer assigns a unique address, with a zero port value, to the "m=3D" line, and the bundle address to each of the remaining "m=3D" lines in the BUNDLE group. SDP Offer v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 m=3Dvideo 0 RTP/AVP 60 a=3Drtpmap:60 H261/90000 --_000_BDBE1A97E84675488F72A48C23811F350F40BBDEMUMBX001nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks = Christer,

&n= bsp;

I would= clearly prefer „disable”, as “reject” in my view o= nly fits for something that is being offered.

What wa= s the reasoning brought forward to use “reject”?

&n= bsp;

Thomas<= o:p>

&n= bsp;

From: ext Christer Holmberg [mailto:christer.holmberg@erics= son.com]
Sent: Wednesday, June 12, 2013 7:29 PM
To: Belling, Thomas (NSN - DE/Munich); mmusic_ietf.org
Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th)<= /span>

 

Hi Thomas,

 

I used to have 'dis= able' for the Offerer, but there was a comment suggesting to use 'reject'. = We can discuss it.

 

I am ok to use 'move out of' termino= logy, as you suggest.

 

Thanks!

 

Regards,

 

Christer

 =

 =



Sent from Windows using TouchDown (www.nitrodesk.c= om)=


-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) [thomas.belling@nsn.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic@ietf.org [mmusic@ietf.org]
Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th)

Dear Ch= rister,

 <= /span>

only so= me comments on the terminology:

 <= /span>

“= When an Offerer rejects an "m=3D" line in a BUNDLE group …&= #8221;

I am us= ed to terminology where an answerer “rejects” something that is= being offered, but is unclear what this means for an offerer.<= /o:p>

I assum= e what you are after is “disabling” an m-line. Perhaps this ter= minology would be clearer?

 <= /span>

You als= o speak about “Removing A Media Description From A BUNDLE Group”= ;.

I see a= certain risk that people misunderstand this to also mean “disabling&= #8221; an m-line.

I assum= e what you are after is rather ”Moving A Media Description out of a B= UNDLE Group”. Perhaps this terminology would be clearer?<= /o:p>

 <= /span>

Regards= , Thomas

 <= /span>

 <= /span>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Christer Holmberg
Sent: Wednesday, June 12, 2013 4:12 PM
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)=

 

 

 

 

6.2.4.  Removing A Media Description F= rom A BUNDLE Group

 

   When an Offerer removes an &qu= ot;m=3D" line from a BUNDLE group, the Offerer

   MUST assign a unique address t= o the "m=3D" line that is removed.  In

   addition, the Offerer MUST NOT= place the mid value that was

   previously defined for the &qu= ot;m=3D" line in the SDP group:BUNDLE

   attribute mid value list assoc= iated with the BUNDLE group.

 

   To the other "m=3D" = lines (that previously have been added to the

   BUNDLE group), the Offerer ass= igns addresses according to the

   procedures in Section 6.2.1.

 

   Example: The example shows a B= RO, where an "m=3D" line is removed from

   a BUNDLE group.  The Offe= rer removes the mid ("zen") associated with

   the "m=3D" line from= the SDP group:BUNDLE attribute mid value list, and

   assigns a unique address to th= e removed "m=3D" line.

 

   Example: The example shows an = SDP Offer, where an "video" "m=3D" line

   (previously identified by the = "zen" mid value), is removed from a

   BUNDLE group.  The Offere= r assigns a unique address to the "m=3D" line,<= /p>

   and the bundle address to each= of the remaining "m=3D" lines in the

   BUNDLE group.

 

 

   SDP Offer

 

       v=3D0<= /span>

       o=3Dal= ice 2890844526 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN= IP4 host.atlanta.com

       t=3D0 = 0

       a=3Dgr= oup:BUNDLE foo bar

       m=3Dau= dio 10000 RTP/AVP 0 8 97

       a=3Dmi= d:foo

       b=3DAS= :200

       a=3Drt= pmap:0 PCMU/8000

       a=3Drt= pmap:8 PCMA/8000

       a=3Drt= pmap:97 iLBC/8000

       m=3Dvi= deo 10000 RTP/AVP 31 32

       a=3Dmi= d:bar

       b=3DAS= :1000

       a=3Drt= pmap:31 H261/90000

       a=3Drt= pmap:32 MPV/90000

       m=3Dvi= deo 40000 RTP/AVP 60

       b=3DAS= :1000

       a=3Drt= pmap:60 H261/90000

 

 

 

6.2.5.  Rejecting A Media Description = In A BUNDLE Group

 

   When an Offerer rejects an &qu= ot;m=3D" line in a BUNDLE group, the Offerer

   MUST assign a unique address, = with a zero port value [RFC3264], to

   the "m=3D" line that= is rejected.  In addition, the Offerer MUST NOT

   place the mid value that was p= reviously defined for the "m=3D" line in

   the SDP group:BUNDLE attribute= mid value list associated with the

   BUNDLE group.

 

   To the other "m=3D" = lines (that previously have been added to the

   BUNDLE group), the Offerer ass= igns addresses according to the

   procedures in Section 6.2.1.

 

   Example: The example shows an = SDP Offer, where an "video" "m=3D" line

   (previously identified by the = "zen" mid value), is rejected, and

   removed from a BUNDLE group.&n= bsp; The Offerer assigns a unique address,

   with a zero port value, to the= "m=3D" line, and the bundle address to

   each of the remaining "m= =3D" lines in the BUNDLE group.

 

 

   SDP Offer

 

       v=3D0<= /span>

       o=3Dal= ice 2890844526 2890844526 IN IP4 host.atlanta.com

       s=3D

       c=3DIN= IP4 host.atlanta.com

       t=3D0 = 0

       a=3Dgr= oup:BUNDLE foo bar

       m=3Dau= dio 10000 RTP/AVP 0 8 97

       a=3Dmi= d:foo

       b=3DAS= :200

       a=3Drt= pmap:0 PCMU/8000

       a=3Drt= pmap:8 PCMA/8000

       a=3Drt= pmap:97 iLBC/8000

       m=3Dvi= deo 10000 RTP/AVP 31 32

       a=3Dmi= d:bar

       b=3DAS= :1000

       a=3Drt= pmap:31 H261/90000

       a=3Drt= pmap:32 MPV/90000

       m=3Dvi= deo 0 RTP/AVP 60

       a=3Drt= pmap:60 H261/90000

 

 

 

--_000_BDBE1A97E84675488F72A48C23811F350F40BBDEMUMBX001nsnintr_-- From abegen@cisco.com Thu Jun 13 02:14:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814E721F8F7B for ; Thu, 13 Jun 2013 02:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu5geQkx5lBC for ; Thu, 13 Jun 2013 02:14:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5B85F21F9703 for ; Thu, 13 Jun 2013 02:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7337; q=dns/txt; s=iport; t=1371114873; x=1372324473; h=from:to:cc:subject:date:message-id:mime-version; bh=tGHY8TWMF6nTOm2JcGDhcgVKrFKXN/3XNnx8YzFPdHY=; b=bW+veTaenE4wAKBduLwQL4PBqKMjWwEKTWZkvLr3EVTZKV89FWd8lN9D QydgLayPpAdryxgPoYvCdYFtR1vhYbd1lumLpL6LNJMkAZdPpVbzLs/vo r5j6W2a6Wd+JigjTPiG21sfLHF7kNAzAg/g2oWZYGjoZ53CaRD+vmI0uA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFABSMuVGtJV2a/2dsb2JhbABbgkUjITBJvmd/Fm0HgiUBBHkSASpWJwQODQGIBQELrVKNQI4LgQcxgwZhA6kCgw+BaD8 X-IronPort-AV: E=Sophos;i="4.87,857,1363132800"; d="scan'208,217";a="222306689" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jun 2013 09:14:33 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5D9EWXG017974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 09:14:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 04:14:32 -0500 From: "Ali C. Begen (abegen)" To: "draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 Thread-Index: AQHOZ2ssXcGF3Gxm8Ues0m/5fP6WJQ== Date: Thu, 13 Jun 2013 09:14:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.86.241.161] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940D1411C0xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: xrblock-chairs , mmusic Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 09:14:38 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940D1411C0xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - I have a serious concern about the definition of QoE and usage of MOS in = this draft. - The RTCP XR extension syntax seems to have an issue. - There are quite a few grammatical/capitalization/spelling errors. Please = proofread the document. Issues: - Section 1.3: s/guideline/guidelines, s/XR Block/XR block types - Section 1.4: s/"Audio/Video"/"audio/video", s/transport-dependent/transpo= rt-specific - Section 1.4: I don't understand what the following sentence means: The factors in the second category are application-specific factors that af= fect real time application (e.g., video) quality and are sensitivity to net= work errors. - Section 1.4: s/but not limited/but are not limited - Section 1.4: I don't generally like the term "subscriber". Use more a mor= e generic term like end-user, client, etc. - Section 2.1: s/8:8/S8:8 - Section 3, first paragraph: The use of "recommended". These specific (211= 9) keywords are not supposed to be used in lower case. - I don't agree with the following statement: Information is recorded about QoE metric which provides a measure that is indicative of the user's view of a service. The application cannot possibly know a user's view of service unless the us= er explicitly enters that info in some fashion to the application. - Section 3.1: I think you should replace: The fields corresponding to unreported parameters MUST be present, but are = set to zero. With: The fields corresponding to unreported parameters MUST be present, and MUST= be set to zero. - Section 4.1: "extmap" attribute was defined in 5285 not 4566. - Section 4.1/4.2: Do not use "may/should/etc." in lower case. There are mu= ltiple occurrences of this. - Section 4.1: "extmap" is already a registered attribute name. I did not u= nderstand why and in what way you want to use it. - Section 4.2: s/indicates/indicate - Section 4.1/4.2: Extra spaces in the SDP examples. Replace a =3D rtcp-xr:qoe-metrics =3D calg:1=3DG107,calg:2=3DP1202.1 With a=3Drtcp-xr:qoe-metrics=3Dcalg:1=3DG107,calg:2=3DP1202.1 - Section 5.1: Use the correct registry name: "RTP Control Protocol Extende= d Reports (RTCP XR) Block Type Registry" 6) Section 5.2: Use the correct registry name: "RTP Control Protocol Extend= ed Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry= ". --_000_C15918F2FCDA0243A7C919DA7C4BE9940D1411C0xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I am the assigned SDP directorate reviewer for this draft. For backgro= und on the SDP directorate, please see the FAQ at

http://www.ietf.o= rg/iesg/directorate/sdp.html

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

Summary:
- I have a serious concern about the definition of QoE and usage of MO= S in this draft.
- The RTCP XR extension syntax seems to have an issue.
- There are quite a few grammatical/capitalization/spelling errors. Please = proofread the document.

Issues:

- Section 1.3: s/guideline/guidelines, s/XR Block/XR block types

- Section 1.4: s/"Audio/Video"/"audio/video", s/tr= ansport-dependent/transport-specific

- Section 1.4: I don't understand what the following sentence means:

The factors in the second category are application-specific facto= rs that affect real time application (e.g., video) quality and are&nbs= p;sensitivity to network errors.

- Section 1.4: s/but not limited/but are not limited

- Section 1.4: I don't generally like the term "subscriber".= Use more a more generic term like end-user, client, etc.

- Section 2.1: s/8:8/S8:8

- Section 3, first paragraph: The use of "recommended". Thes= e specific (2119) keywords are not supposed to be used in lower case.

- I don't agree with the following statement:

   Information is recorded about QoE metric which provides a=
   measure that is indicative of the user's view of a servic= e.

The application cannot possibly know a user's view of service unless t= he user explicitly enters that info in some fashion to the application.

- Section 3.1:

I think you should replace:

The fields corresponding to unreported parameters MUST be present= , but are set to zero.

With:

The fields corresponding to unreported parameters MUST be present= , and MUST be set to zero.

- Section 4.1: "extmap" attribute was defined in 5285 not 45= 66.

- Section 4.1/4.2: Do not use "may/should/etc." in lower cas= e. There are multiple occurrences of this.

- Section 4.1: "extmap" is already a registered attribute na= me. I did not understand why and in what way you want to use it.

- Section 4.2: s/indicates/indicate

- Section 4.1/4.2: Extra spaces in the SDP examples. 

Replace

a =3D rtcp-xr:qoe-metrics =3D calg:1=3DG107,calg:2=3DP1202.1

With 

a=3Drtcp-xr:qoe-metrics=3Dcalg:1=3DG107,calg:2=3DP1202.1 

- Section 5.1: Use the correct registry name: "RTP Control P= rotocol Extended Reports (RTCP XR) Block Type Registry"

6) Section 5.2: Use the correct registry name: "RTP Control Protocol E= xtended Reports (RTCP XR) Session Description Protocol (SDP) Parameter= s Registry".
--_000_C15918F2FCDA0243A7C919DA7C4BE9940D1411C0xmbalnx01ciscoc_-- From bill.wu@huawei.com Thu Jun 13 04:45:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054F21F8F61; Thu, 13 Jun 2013 04:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.66 X-Spam-Level: X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reKW1UotHPvm; Thu, 13 Jun 2013 04:44:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84C9A21F8528; Thu, 13 Jun 2013 04:44:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASK58399; Thu, 13 Jun 2013 11:44:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 12:44:34 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 12:44:47 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 19:44:44 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , "draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 Thread-Index: AQHOZ2ssXcGF3Gxm8Ues0m/5fP6WJZkzfjEQ Date: Thu, 13 Jun 2013 11:44:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43B40FE2nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: xrblock-chairs , mmusic , 'xrblock' Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 11:45:00 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43B40FE2nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,Ali: Thank for your valuable review. Please see my reply inline below. Regards! -Qin From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Thursday, June 13, 2013 5:14 PM To: draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org Cc: xrblock-chairs; mmusic Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe= -08 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - I have a serious concern about the definition of QoE and usage of MOS in = this draft. - The RTCP XR extension syntax seems to have an issue. - There are quite a few grammatical/capitalization/spelling errors. Please = proofread the document. [Qin]: Thanks, See below. Issues: - Section 1.3: s/guideline/guidelines, s/XR Block/XR block types [Qin]: Okay. - Section 1.4: s/"Audio/Video"/"audio/video", s/transport-dependent/transpo= rt-specific [Qin]: Okay. - Section 1.4: I don't understand what the following sentence means: The factors in the second category are application-specific factors that af= fect real time application (e.g., video) quality and are sensitivity to net= work errors. [Qin]: What I am saying here is video is sensitive to transport impairment.= So I believe I should remove the second part of this sentence to avoid con= fusion. OLD TEXT: " The factors in the second category are application-specific factors that af= fect real time application (e.g., video) quality and are sensitivity to net= work errors. " NEW TEXT: " The factors in the second category are application-specific factors that af= fect real time application (e.g., video) quality. " - Section 1.4: s/but not limited/but are not limited [Qin]: Okay. - Section 1.4: I don't generally like the term "subscriber". Use more a mor= e generic term like end-user, client, etc. [Qin]: Okay, will use end user instead. - Section 2.1: s/8:8/S8:8 [Qin]: In section 2.1, 8:8 is referred to 8:8 an unsigned number in the ran= ge 0.0 to 255.996 with a granularity of 0.0039. We are intending to use S8:8 as = an example. Instead, we use S7:8 to give the example. - Section 3, first paragraph: The use of "recommended". These specific (211= 9) keywords are not supposed to be used in lower case. [Qin]: Okay. - I don't agree with the following statement: Information is recorded about QoE metric which provides a measure that is indicative of the user's view of a service. The application cannot possibly know a user's view of service unless the us= er explicitly enters that info in some fashion to the application. [Qin]: The application can rely on QoE evaluation model to calculate MoS v= alue and use such MoS value to reflect how end user feel or experience the = media quality. That's what this statement want to convey. - Section 3.1: I think you should replace: The fields corresponding to unreported parameters MUST be present, but are = set to zero. With: The fields corresponding to unreported parameters MUST be present, and MUST= be set to zero. [Qin]: Okay. - Section 4.1: "extmap" attribute was defined in 5285 not 4566. [Qin]: Okay. - Section 4.1/4.2: Do not use "may/should/etc." in lower case. There are mu= ltiple occurrences of this. [Qin]: Okay. - Section 4.1: "extmap" is already a registered attribute name. I did not u= nderstand why and in what way you want to use it. [Qin]: We need a new attribute defining the mapping from the different para= meter names (i.e., the different calculation-algorithm parameter names) to = the numeric values used in the packets Unlike RFC5285 extmap usage, we map = name rather than URI to the numeric values used in the packet. So I assume "extmap" can be reused, however if not, I believe we should def= ine new attribute similar to "extmap" in this document. - Section 4.2: s/indicates/indicate [Qin]: Okay. - Section 4.1/4.2: Extra spaces in the SDP examples. Replace a =3D rtcp-xr:qoe-metrics =3D calg:1=3DG107,calg:2=3DP1202.1 With a=3Drtcp-xr:qoe-metrics=3Dcalg:1=3DG107,calg:2=3DP1202.1 [Qin]: Okay. - Section 5.1: Use the correct registry name: "RTP Control Protocol Extende= d Reports (RTCP XR) Block Type Registry" [Qin]: Okay. 6) Section 5.2: Use the correct registry name: "RTP Control Protocol Extend= ed Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry= ". [Qin]: Okay. --_000_B8F9A780D330094D99AF023C5877DABA43B40FE2nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,Ali:=

Thank for your valuable r= eview. Please see my reply inline below.

 <= /p>

Regards!

-Qin

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen)
Sent: Thursday, June 13, 2013 5:14 PM
To: draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org
Cc: xrblock-chairs; mmusic
Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp= -xr-qoe-08

 

I am the assigned SDP directorate reviewer for this draft. Fo= r background on the SDP directorate, please see the FAQ at


http://www.ietf.o= rg/iesg/directorate/sdp.html

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

Summary:

- I have a serious concern about the definition of QoE and us= age of MOS in this draft.
- The RTCP XR extension syntax seems to have an issue.
- There are quite a few grammatical/capitalization/spelling errors. Please = proofread the document.

[Qin]: Thanks, See below.


Issues:

 

- Section 1.3: s/guideline/guidelines, s/XR Block/XR block ty= pes

 <= /p>

[Qin]: Okay.

 

- Section 1.4: s/"Audio/Video"/"audio/video&qu= ot;, s/transport-dependent/transport-specific

 <= /p>

[Qin]: Okay.

 

- Section 1.4: I don't understand what the following sentence= means:

 

The factors in the second category are application-speci= fic factors that affect real time application (e.g., video) quality an= d are sensitivity to network errors.

 <= /p>

[Qin]: What I am saying h= ere is video is sensitive to transport impairment. So I believe I should re= move the second part of this sentence to avoid confusion.

OLD TEXT:

“=

The factors in the second category are application-speci= fic factors that affect real time application (e.g., video) quality an= d are sensitivity to network errors.

”=

NEW TEXT:

“=

The factors in the second category are application-speci= fic factors that affect real time application (e.g., video) quality.

 <= /p>

”=

 

- Section 1.4: s/but not limited/but are not limited=

 <= /p>

[Qin]: Okay.

 

- Section 1.4: I don't generally like the term "subscrib= er". Use more a more generic term like end-user, client, etc.=

 <= /p>

[Qin]: Okay, will use end= user instead.

 

- Section 2.1: s/8:8/S8:8

 <= /p>

[Qin]: In section 2.1, 8:= 8 is referred to 8:8 an unsigned number in the range 0.0 to

     255.996 with a granularity of 0.0039. We are intending to use S8:8 as an example. Instead, we use S7:8 to give the example.

 

- Section 3, first paragraph: The use of "recommended&qu= ot;. These specific (2119) keywords are not supposed to be used in lower ca= se.

 <= /p>

[Qin]: Okay.

 

- I don't agree with the following statement:

 

   Information is recorded about QoE metric which p= rovides a

   measure that is indicative of the user's view of= a service.

 

The application cannot possibly know a user's view of service= unless the user explicitly enters that info in some fashion to the applica= tion.

 

[Qin]:  The applicat= ion can rely on QoE evaluation model to calculate MoS value and use such Mo= S value to reflect how end user feel or experience the media quality. That’s what this statement want

to convey.

 <= /p>

- Section 3.1:

 

I think you should replace:

 

The fields corresponding to unreported parameters MUST b= e present, but are set to zero.

 

With:

 

The fields corresponding to unreported parameters MUST b= e present, and MUST be set to zero.

 <= /p>

[Qin]: Okay.

 <= /p>

 

- Section 4.1: "extmap" attribute was defined in 52= 85 not 4566.

 <= /p>

[Qin]: Okay.

 <= /p>

 

- Section 4.1/4.2: Do not use "may/should/etc." in = lower case. There are multiple occurrences of this.

 <= /p>

[Qin]: Okay.

 <= /p>

 

- Section 4.1: "extmap" is already a registered att= ribute name. I did not understand why and in what way you want to use it.

 

[Qin]: We need a new attribute defining the mapping from th= e different parameter names (i.e., the different calculation-algorithm para= meter names) to the numeric values used in the packets Unlike RFC5285 extmap usage, we map name rather than URI to= the numeric values used in the packet.

So I assume “extmap” can be reused, however if = not, I believe we should define new attribute similar to “extmap̶= 1; in this document.

- Section 4.2: s/indicates/indicate

 <= /p>

[Qin]: Okay.

 

- Section 4.1/4.2: Extra spaces in the SDP examples. 

 

Replace

 

a =3D rtcp-xr:qoe-metrics =3D calg:1=3DG107,calg:2=3DP1202.1<= o:p>

 

With 

 

a=3Drtcp-xr:qoe-metrics=3Dcalg:1=3DG107,calg:2=3DP1202.1 = ;<= o:p>

 <= /p>

[Qin]: Okay.

 

- Section 5.1: Use the correct registry name: "RTP = Control Protocol Extended Reports (RTCP XR) Block Type Registry"<= /o:p>

 <= /p>

[Qin]: Okay.



6) Section 5.2: Use the correct registry name: "RTP Control Protocol E= xtended Reports (RTCP XR) Session Description Protocol (SDP) Parameter= s Registry".

 <= /p>

[Qin]: Okay.

--_000_B8F9A780D330094D99AF023C5877DABA43B40FE2nkgeml501mbschi_-- From abegen@cisco.com Thu Jun 13 04:59:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84BB21F9A3D; Thu, 13 Jun 2013 04:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SydgPd1d5i1x; Thu, 13 Jun 2013 04:58:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0F34621F9A76; Thu, 13 Jun 2013 04:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11571; q=dns/txt; s=iport; t=1371124736; x=1372334336; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0w5UL5EYas5pvdqTUKG3SiITyrqC8Tnwi1kGL+5HVPw=; b=cT2JMzmGjnyiMx45rw1SqR5TeCAE0Yp/Xmslflq9ufTmdIJh5wPM1B98 yEUGEaKbtplNX6DEteP2uaCVTfh1TnJGeffUxoi3QNtYUQeMJdjqfPsIL l0rEkPI+ipbT5knhONKW4A6b7Mq278eInbVMI5Nct0dQDn8ozV6JuxYUk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAKCzuVGtJXHB/2dsb2JhbABbgkUjITBJgnS7dg1zFnSCJQEEI0gOEgEIDhQgAgQwJQIEAQ0NiAYBqU+RY48SMQeCTDNhA6kDgw+CJw X-IronPort-AV: E=Sophos;i="4.87,858,1363132800"; d="scan'208,217";a="222418984" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 13 Jun 2013 11:58:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5DBwpba022447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 11:58:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 06:58:51 -0500 From: "Ali C. Begen (abegen)" To: Qin Wu , "draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 Thread-Index: AQHOaC1e8zLHZgmgvUyxnoUMR5FcUQ== Date: Thu, 13 Jun 2013 11:58:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.86.241.161] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940D1421DExmbalnx01ciscoc_" MIME-Version: 1.0 Cc: xrblock-chairs , mmusic , 'xrblock' Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 11:59:02 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940D1421DExmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCi0gSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50Og0KDQogICBJ bmZvcm1hdGlvbiBpcyByZWNvcmRlZCBhYm91dCBRb0UgbWV0cmljIHdoaWNoIHByb3ZpZGVzIGEN CiAgIG1lYXN1cmUgdGhhdCBpcyBpbmRpY2F0aXZlIG9mIHRoZSB1c2VyJ3MgdmlldyBvZiBhIHNl cnZpY2UuDQoNClRoZSBhcHBsaWNhdGlvbiBjYW5ub3QgcG9zc2libHkga25vdyBhIHVzZXIncyB2 aWV3IG9mIHNlcnZpY2UgdW5sZXNzIHRoZSB1c2VyIGV4cGxpY2l0bHkgZW50ZXJzIHRoYXQgaW5m byBpbiBzb21lIGZhc2hpb24gdG8gdGhlIGFwcGxpY2F0aW9uLg0KDQpbUWluXTogIFRoZSBhcHBs aWNhdGlvbiBjYW4gcmVseSBvbiBRb0UgZXZhbHVhdGlvbiBtb2RlbCB0byBjYWxjdWxhdGUgTW9T IHZhbHVlIGFuZCB1c2Ugc3VjaCBNb1MgdmFsdWUgdG8gcmVmbGVjdCBob3cgZW5kIHVzZXIgZmVl bCBvciBleHBlcmllbmNlIHRoZSBtZWRpYSBxdWFsaXR5LiBUaGF04oCZcyB3aGF0IHRoaXMgc3Rh dGVtZW50IHdhbnQNCnRvIGNvbnZleS4NCg0KVGhhdCBpcyBub3Qgd2hhdCB0aGUgc2VudGVuY2Ug c2F5cywgdGhvdWdoLCBhdCBsZWFzdCB0byBtZS4gVGhlICJ1c2VyJ3MgdmlldyBvZiBhIHNlcnZp Y2UiIGlzIHRoZSB0cm91YmxpbmcgcGFydCB0byBtZS4gV2hhdCB5b3UgZG8gaXMgdGhhdCB5b3Ug YXBwbHkgYW4gYWxnb3JpdGhtIHdpdGggc29tZSBvYnNlcnZlZCB2YWx1ZXMgYW5kIHlvdSB0cnkg dG8gZXN0aW1hdGUgc29tZSBzb3J0IG9mIGEgbWVhbiBvcGluaW9uIHNjb3JlLiBUaGF0IG1heSBv ciBtYXkgbm90IGJlIGluZGljYXRpdmUgb2YgdGhlIGVuZC11c2VyJ3MgUW9FLg0KDQoNCi0gU2Vj dGlvbiA0LjE6ICJleHRtYXAiIGlzIGFscmVhZHkgYSByZWdpc3RlcmVkIGF0dHJpYnV0ZSBuYW1l LiBJIGRpZCBub3QgdW5kZXJzdGFuZCB3aHkgYW5kIGluIHdoYXQgd2F5IHlvdSB3YW50IHRvIHVz ZSBpdC4NCg0KW1Fpbl06IFdlIG5lZWQgYSBuZXcgYXR0cmlidXRlIGRlZmluaW5nIHRoZSBtYXBw aW5nIGZyb20gdGhlIGRpZmZlcmVudCBwYXJhbWV0ZXIgbmFtZXMgKGkuZS4sIHRoZSBkaWZmZXJl bnQgY2FsY3VsYXRpb24tYWxnb3JpdGhtIHBhcmFtZXRlciBuYW1lcykgdG8gdGhlIG51bWVyaWMg dmFsdWVzIHVzZWQgaW4gdGhlIHBhY2tldHMgVW5saWtlIFJGQzUyODUgZXh0bWFwIHVzYWdlLCB3 ZSBtYXAgbmFtZSByYXRoZXIgdGhhbiBVUkkgdG8gdGhlIG51bWVyaWMgdmFsdWVzIHVzZWQgaW4g dGhlIHBhY2tldC4NClNvIEkgYXNzdW1lIOKAnGV4dG1hcOKAnSBjYW4gYmUgcmV1c2VkLCBob3dl dmVyIGlmIG5vdCwgSSBiZWxpZXZlIHdlIHNob3VsZCBkZWZpbmUgbmV3IGF0dHJpYnV0ZSBzaW1p bGFyIHRvIOKAnGV4dG1hcOKAnSBpbiB0aGlzIGRvY3VtZW50Lg0KDQpJJ2QgcmVmZXIgdG8gc29t ZSBTRFAgZXhwZXJ0cyBoZXJlIGFzIEkgY291bGQgbm90IHVuZGVyc3RhbmQgd2hhdCB5b3Ugd2Fu bmEgZG8gYW5kIGhvdyB5b3Ugd2FubmEgZG8gaXQuDQo= --_000_C15918F2FCDA0243A7C919DA7C4BE9940D1421DExmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7ICI+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndv cmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIv b21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+LSBJIGRvbid0IGFncmVlIHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0luZm9ybWF0aW9uIGlzIHJlY29y ZGVkIGFib3V0IFFvRSBtZXRyaWMgd2hpY2ggcHJvdmlkZXMgYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5i c3A7bWVhc3VyZSB0aGF0IGlzIGluZGljYXRpdmUgb2YgdGhlIHVzZXIncyB2aWV3IG9mIGEgc2Vy dmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+VGhlIGFwcGxpY2F0aW9uIGNh bm5vdCBwb3NzaWJseSBrbm93IGEgdXNlcidzIHZpZXcgb2Ygc2VydmljZSB1bmxlc3MgdGhlIHVz ZXIgZXhwbGljaXRseSBlbnRlcnMgdGhhdCBpbmZvIGluIHNvbWUgZmFzaGlvbiB0byB0aGUgYXBw bGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPltRaW5dOiZu YnNwOyBUaGUgYXBwbGljYXRpb24gY2FuIHJlbHkgb24gUW9FIGV2YWx1YXRpb24gbW9kZWwgdG8g Y2FsY3VsYXRlIE1vUyB2YWx1ZSBhbmQgdXNlIHN1Y2ggTW9TIHZhbHVlIHRvIHJlZmxlY3QgaG93 IGVuZCB1c2VyIGZlZWwgb3IgZXhwZXJpZW5jZQ0KIHRoZSBtZWRpYSBxdWFsaXR5LiBUaGF04oCZ cyB3aGF0IHRoaXMgc3RhdGVtZW50IHdhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+dG8gY29udmV5 Ljwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYXQgaXMgbm90IHdoYXQgdGhl IHNlbnRlbmNlIHNheXMsIHRob3VnaCwgYXQgbGVhc3QgdG8gbWUuIFRoZSAmcXVvdDt1c2VyJ3Mg dmlldyBvZiBhIHNlcnZpY2UmcXVvdDsgaXMgdGhlIHRyb3VibGluZyBwYXJ0IHRvIG1lLiBXaGF0 IHlvdSBkbyBpcyB0aGF0IHlvdSBhcHBseSBhbiBhbGdvcml0aG0gd2l0aCBzb21lIG9ic2VydmVk IHZhbHVlcyBhbmQgeW91IHRyeSB0byBlc3RpbWF0ZSBzb21lIHNvcnQgb2YgYSBtZWFuIG9waW5p b24gc2NvcmUuIFRoYXQNCiBtYXkgb3IgbWF5IG5vdCBiZSBpbmRpY2F0aXZlIG9mIHRoZSBlbmQt dXNlcidzIFFvRS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JM T0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAg MCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpv ZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHht bG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIg eG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog Q29uc29sYXM7IGZvbnQtc2l6ZTogMTAuNXB0OyAiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPi0gU2VjdGlvbiA0LjE6 ICZxdW90O2V4dG1hcCZxdW90OyBpcyBhbHJlYWR5IGEgcmVnaXN0ZXJlZCBhdHRyaWJ1dGUgbmFt ZS4gSSBkaWQgbm90IHVuZGVyc3RhbmQgd2h5IGFuZCBpbiB3aGF0IHdheSB5b3Ugd2FudCB0byB1 c2UgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFdlIG5lZWQgYSBuZXcgYXR0cmlidXRlIGRlZmlu aW5nIHRoZSBtYXBwaW5nIGZyb20gdGhlIGRpZmZlcmVudCBwYXJhbWV0ZXIgbmFtZXMgKGkuZS4s IHRoZSBkaWZmZXJlbnQgY2FsY3VsYXRpb24tYWxnb3JpdGhtIHBhcmFtZXRlciBuYW1lcykgdG8g dGhlIG51bWVyaWMgdmFsdWVzIHVzZWQNCiBpbiB0aGUgcGFja2V0cyBVbmxpa2UgUkZDNTI4NSBl eHRtYXAgdXNhZ2UsIHdlIG1hcCBuYW1lIHJhdGhlciB0aGFuIFVSSSB0byB0aGUgbnVtZXJpYyB2 YWx1ZXMgdXNlZCBpbiB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlNvIEkgYXNzdW1lIOKAnGV4dG1hcOKAnSBjYW4gYmUgcmV1 c2VkLCBob3dldmVyIGlmIG5vdCwgSSBiZWxpZXZlIHdlIHNob3VsZCBkZWZpbmUgbmV3IGF0dHJp YnV0ZSBzaW1pbGFyIHRvIOKAnGV4dG1hcOKAnSBpbiB0aGlzIGRvY3VtZW50Ljwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSdkIHJlZmVyIHRvIHNvbWUgU0RQIGV4 cGVydHMgaGVyZSBhcyBJIGNvdWxkIG5vdCB1bmRlcnN0YW5kIHdoYXQgeW91IHdhbm5hIGRvIGFu ZCBob3cgeW91IHdhbm5hIGRvIGl0LjwvZGl2Pg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJcNjI3OVw2Q0U4XDY4NDZc NjU4N1w2NzJDIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5DaGFyDQoJe21z by1zdHlsZS1uYW1lOiJcNjI3OVw2Q0U4XDY4NDZcNjU4N1w2NzJDIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazpcNjI3OVw2Q0U4XDY4NDZcNjU4N1w2NzJD Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_C15918F2FCDA0243A7C919DA7C4BE9940D1421DExmbalnx01ciscoc_-- From pkyzivat@alum.mit.edu Thu Jun 13 11:00:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E42221F9A43 for ; Thu, 13 Jun 2013 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3X2a53B0+gs for ; Thu, 13 Jun 2013 11:00:51 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id EEE0E21F9A33 for ; Thu, 13 Jun 2013 11:00:50 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id nn3f1l0061ei1Bg59u0qZF; Thu, 13 Jun 2013 18:00:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id nu0q1l00Q3ZTu2S3ku0q5G; Thu, 13 Jun 2013 18:00:50 +0000 Message-ID: <51BA08D0.3030301@alum.mit.edu> Date: Thu, 13 Jun 2013 14:00:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371146450; bh=QWtcyxN7u/RN7+C0EOW918S1im2/hDNtRCvxA3Bj5jc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J3x5VgmwgiUBY+l2OsD5s/bbtMDLzYa8my4ETQQrBcsoRwl4Zh4ZKyBcv/cEGCfTD 2KLw6ncDYPmrI6zLyHB2oWNr5g7bLJjEATF5v1q0bPVMS2myjDGrsGwN1aPkZcdsFS ESxaRFdxD22ppxv3IIp9M/MItrDlIbv+aDxr46/pokDkwMSrZ8xuJ4o42CQEbXLCPO uBToVuaBVG468gpPVPRtTqhV9GoIrrUuArSgpnxQiwPQDOe9GWkYCfqijZQ2LiTROk QrTiM3r/xiw8qXXigFvvTHzt+Sh85tLxAjbYp1+JF6yLy01uuaGwvkc7OxVoF6sH0X uotSz/XsXO+dg== Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 18:00:55 -0000 Christer, We seem to be getting there. I have more comments inline. Thanks, Paul BTW: sorry that Thunderbird has double spaced all the included draft text. (Presumably because lines end with and it treats each of those as a .) On 6/12/13 10:12 AM, Christer Holmberg wrote: > Hi, > > I’ve gone through the comments received, and made some conclusions. > > *First*, defining Offer “types” was probably not a good idea. It caused > confusion, and it was unclear whether it refers to the whole SDP body, > or only individual BUNDLE groups within it. So, I’ve removed the BSO and > BRO. I HAVE defined a procedure called ‘Bundle Address Synchronization > (BAS)’, which is basically what the BSO was previously used for. But, it > is not a new Offer type, it is simply a procedure that an Offerer does > (using an SDP Offer, though). > > Also, we probably DO need more text on when a BAS is needed, but I hope > you understand what the intention of it is :) > > *Second*, there were different opinions on how flexible the mechanism > should be when it comes to re-negotiating the bundle address, and > whether it should be allowed to do it in the same Offer used to e.g. > adding an m= line. I tried to come up with a compromise: > > What Paul wanted, but didn’t get: > > -Paul wanted to be able to assign a new bundle address to multiple m- > line, even if the bundle address hasn’t been negotiated yet. > > What Paul got: > > -In order to negotiate/re-negotiate a bundle address, the Offerer MUST > assign unique addresses to each m- line. There Offerer CANNOT simply add > a new bundle address to multiple m- lines, until it has been negotiated. I still disagree with this. More on it inline below. > What Martin wanted, but didn’t get: > > -Martin wanted to use separate O/A transactions for negotiating the > bundle address, and for adding m- lines to a BUNDLE group. > > What Martin got: > > -It IS allowed to add an m- line, and re-negotiate the bundle address, > in the same SDP Offer. However, as described above, in that case the > Offerer needs to assign unique addresses to each m- line. > > I am not saying we can’t change what you got, and didn’t get, but just > keep the assumptions above in mind when you read the text :) > > *Third*, I removed “Use Cases” section naming. The procedures contains > lots of normative text, while Use Cases are normally informative, and > used to provide background information. > > *Fourth*, I know the especially Martin suggested some terminology > changes. I didn’t forget those, but as many of those are no more valid, > I thought it’s better to work based on the new text. > > *Fifth*, in section 6.1, please do not spend too much time on the > numbered list at this point. It is still something we need to discuss, > but I believe we need to make some progress on the Plan A vs B stuff first. > > At least I personally think the text is more clear, and easier to > understand, now :) > > Regards, > > Christer > > ----------------------------------------------- > > 6. SDP Offer/Answer Procedures > > 6.1. General > > This section describes the usage of the SDP Offer/Answer mechanism > > [RFC3264] to negotiate the usage of the BUNDLE mechanism, to > > negotiate the bundle address, and to add, remove and reject SDP Media > > Descriptions ("m=" lines) associated with a BUNDLE group. > > The generic rules and procedures defined in [RFC3264] and [RFC5888] > > apply when the SDP Offer/Answer mechanism is used for BUNDLE. For > > example, if an SDP Offer is rejected, the previously negotiated SDP > > parameters and characteristics (including those associated with > > BUNDLE groups) apply. > > When an endpoint generates an SDP Offer, or an SDP Answer, which > > contains a BUNDLE group, the endpoint MUST assign SDP media-level mid > > value for each "m=" line in the BUNDLE group. In addition, the > > endpoint MUST insert an SDP session-level group:BUNDLE attribute, and > > place each mid value associated with the BUNDLE group in the > > attribute mid value list. > > Until the Offerer knows whether the Answerer supports the BUNDLE > > mechanism, the Offerer MUST, for each "m=" line in a BUNDLE group: Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE? The minimal answer is that if an offer included a bundle group, and the answer also contains a corresponding bundle group, then the answerer supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer. But we want to assume more - at least that if *a* bundle was supported by both sides in one O/A exchange, then both sides can be presumed to *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session. Is, or should there be, a way to go back on that presumption - to stop supporting bundle? I guess if an end wanted to stop supporting bundle while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because it doesn't currently need a bundle though it still supports them. Perhaps we should say that an offerer or answerer who supports bundle should *always* include an a=group:bundle in its offers and answers. If it doesn't currently want a bundle it can simply include "a=group:bundle" without any mid values. > o 1. Insert a unique address. > > o 2. Insert different SDP 'rtcp' attribute value, when used. > > o 3. Insert an SDP 'rtpc-mux' attribute. > > o 4. Insert identical DTLS-SRTP fingerprint attribute, when used > > o 5. Insert different SDES crypto attribute, when used > > Once it is known that both endpoints support the BUNDLE grouping > > extension, the SDP Offerer and Answerer MUST, for each "m=" line > > associated with a BUNDLE group: > > o 1. Insert either a unique address, or the bundle address > > associated with the BUNDLE group (see sections below for details). > > o 2. Insert identical SDP 'rtcp' attribute value, when used. > > o 3. Insert an SDP 'rtpc-mux' attribute. > > o 4. Insert identical DTLS-SRTP fingerprint attribute, when used > > o 5. Insert different SDES crypto attribute, when used > > READER'S HELP: The detailed definition of the 'Unique Address' and > > 'Bundle Address' terminology will be elsewhere in the document, but > > is basically contains the IP address, IP port and ICE candidates. > > Perhaps also media security parameters? > > 6.2. SDP Offerer Procedures > > 6.2.1. SDP Offerer Bundle Address Request and Usage > > An Offerer can assign an address to multiple "m=" lines in a BUNDLE > > group, once the address has been selected as the Offerer's local > > bundle address. An Offerer MUST NOT assign an address to multiple > > "m=" lines until the address has been selected as a bundle address > > for that BUNDLE group. > > In order to negotiate (or, to re-negotiate) the bundle address > > associated with a BUNDLE group, the Offerer, in the SDP Offer, > > assigns a unique address to each "m=" line in the BUNDLE group. In > > addition, the Offerer indicates which unique address it wishes to use > > as its local bundle address. There Offerer places the mid value, > > associated with the "m=" line that contains the preferred address > > first in the SDP group:BUNDLE attribute mid list. The Answerer then > > selects the local bundle address for the Offerer ([ref-to-be-added]). I don't understand what the last sentence above is trying to tell me. > > If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the > > bundle address associated with a BUNDLE group, it MAY assign the > > previously negotiated bundle address as a unique address to one of > > the "m=" lines in the BUNDLE group. > > If the Offerer assigns the bundle address to more than one "m=" line > > in a BUNDLE group, the first mid value in the SDP group:BUNDLE > > attribute mid value list MUST represent an "m=" line to which the > > bundle address is assigned. Hence, in order to re-negotiate the > > bundle address, the Offerer needs to assign a unique address to each > > "m=" line in the BUNDLE group, as described above. I still object to this. It is a significant cost, and I don't understand how it adds any value over simply assigning a new address to all the bundled m-lines. > An Offerer MUST NOT assign a bundle address to an "m=" line that is > > not associated with a BUNDLE group. An Offerer MUST NOT assign a > > bundle address, that has been negotiated for a BUNDLE group, to an > > "m=" line that is associated with another BUNDLE group. > > Example: The example shows an SDP Offer, where a unique address is > > assigned to each "m=" line in the BUNDLE group. The Offerer requests > > the address associated with the audio "m=" line to be selected as its > > local bundle address, by placing the mid value associated with the > > "m=" line first in the SDP group:BUNDLE attribute mid value list. > > SDP Offer > > v=0 > > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > > s= > > c=IN IP4 host.atlanta.com > > t=0 0 > > a=group:BUNDLE foo bar > > m=audio 10000 RTP/AVP 0 8 97 > > a=mid:foo > > b=AS:200 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:97 iLBC/8000 > > m=video 20000 RTP/AVP 31 32 > > a=mid:bar > > b=AS:1000 > > a=rtpmap:31 H261/90000 > > a=rtpmap:32 MPV/90000 > > 6.2.2. Bundle Address Synchronization (BAS) > > When an Offerer has sent an SDP Offer, a bundle address has been > > selected by the Answerer, and the bundle address was in the SDP Offer > > not assigned to each "m=" line in the BUNDLE group, the Offerer MUST > > send a new SDP Offer, in which it assigns the negotiated bundle > > address to each "m=" line in the BUNDLE group. This procedure is > > referred to as Bundle Address Synchronization (BAS). > > The Offerer MUST NOT modify any parameters associated with the BUNDLE > > group when it performs a BAS. I still don't understand the point of this restriction. What value does it add? Suppose that a need to make another change arises after the offer that proposed the bundle, but before the answer has been received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait? ISTM that it would be better to say that after receiving an answer, if there is at that moment no need to send another offer, if the corresponding offer had bundled m-lines with different addresses, then a BAS must be sent. > NOTE: Eventhough the Offerer is not allowed to modify parameters > > associated with a BUNDLE group when it performs a BAS, the Answerer > > might modify parameters in the associated SDP Answer. For example, > > the Answerer can in the SDP Answer reject an "m=" line, by removing > > the rejected "m=" line from the BUNDLE group and assigning a zero > > port value to the rejected "m=" line ([ref-to-be-added]). > > Example: The example shows an SDP Offer, where the Offerer assigns > > the bundle address to each "m=" line in the BUNDLE group, in order to > > perform a Bundle Address Synchronization. > > SDP Offer (BAS) > > v=0 > > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > > s= > > c=IN IP4 host.atlanta.com > > t=0 0 > > a=group:BUNDLE foo bar > > m=audio 10000 RTP/AVP 0 8 97 > > a=mid:foo > > b=AS:200 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:97 iLBC/8000 > > m=video 10000 RTP/AVP 31 32 > > a=mid:bar > > b=AS:1000 > > a=rtpmap:31 H261/90000 > > a=rtpmap:32 MPV/90000 > > 6.2.3. Adding a media description to a BUNDLE group > > When an Offerer adds an "m=" line to a BUNDLE group, the Offerer MUST > > assign either a unique address, or the bundle address associated with > > the BUNDLE group, to the "m=" line that is added. In addition, the > > Offerer MUST assign a mid value for the "m=" line, and place it in > > the SDP group:BUNDLE attribute mid value list associated with the > > BUNDLE group. > > NOTE: If the Offerer assigns a unique address to the "m=" line that > > is added to the BUNDLE group, it allows the Answerer to remove the > > "m=" line from the BUNDLE group without having to reject the "m=" > > line ([ref-to-be-added]). > > To the other "m=" lines (that previously have been added to the > > BUNDLE group), the Offerer assigns addresses according to the > > procedures in Section 6.2.1. > > Example: The example shows an SDP Offer, where a new "m=" line, > > identified by the "zen" mid value, is added to a BUNDLE group. The > > Offerer assigns a unique address to the "m=" line, and the bundle > > address to each of the other "m=" lines in the BUNDLE group. > > SDP Offer > > v=0 > > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > > s= > > c=IN IP4 host.atlanta.com > > t=0 0 > > a=group:BUNDLE foo bar zen > > m=audio 10000 RTP/AVP 0 8 97 > > a=mid:foo > > b=AS:200 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:97 iLBC/8000 > > m=video 10000 RTP/AVP 31 32 > > a=mid:bar > > b=AS:1000 > > a=rtpmap:31 H261/90000 > > a=rtpmap:32 MPV/90000 > > m=video 30000 RTP/AVP 60 > > a=mid:zen > > b=AS:1000 > > a=rtpmap:60 H261/90000 > > 6.2.4. Removing A Media Description From A BUNDLE Group > > When an Offerer removes an "m=" line from a BUNDLE group, the Offerer > > MUST assign a unique address to the "m=" line that is removed. In > > addition, the Offerer MUST NOT place the mid value that was > > previously defined for the "m=" line in the SDP group:BUNDLE > > attribute mid value list associated with the BUNDLE group. nit: I don't think this should say anything about the mid value that was previously defined for the m-line. That implies that mid values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required. If I want, I should be able to "relabel" the m-lines with new mid values. This reduces the amount of state that is required to be preserved from one o/a to the next. The statement "remove an m-line from a bundle group" already implies that the group does not contain a mid-value identifying that m-line (in *this* offer or answer). > To the other "m=" lines (that previously have been added to the > > BUNDLE group), the Offerer assigns addresses according to the > > procedures in Section 6.2.1. > > Example: The example shows a BRO, where an "m=" line is removed from The term "BRO" is no longer defined. > a BUNDLE group. The Offerer removes the mid ("zen") associated with > > the "m=" line from the SDP group:BUNDLE attribute mid value list, and > > assigns a unique address to the removed "m=" line. > > Example: The example shows an SDP Offer, where an "video" "m=" line > > (previously identified by the "zen" mid value), is removed from a > > BUNDLE group. The Offerer assigns a unique address to the "m=" line, > > and the bundle address to each of the remaining "m=" lines in the > > BUNDLE group. > > SDP Offer > > v=0 > > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > > s= > > c=IN IP4 host.atlanta.com > > t=0 0 > > a=group:BUNDLE foo bar > > m=audio 10000 RTP/AVP 0 8 97 > > a=mid:foo > > b=AS:200 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:97 iLBC/8000 > > m=video 10000 RTP/AVP 31 32 > > a=mid:bar > > b=AS:1000 > > a=rtpmap:31 H261/90000 > > a=rtpmap:32 MPV/90000 > > m=video 40000 RTP/AVP 60 > > b=AS:1000 > > a=rtpmap:60 H261/90000 > > 6.2.5. Rejecting A Media Description In A BUNDLE Group I agree with prior comment that using "Rejecting" here is weird and confusing. I agree that "disabling" is probably more appropriate. But then "disabling a media description in a bundle group" is still a little confusing, because it is then no longer "in" the bundle group. It might be clearer to just incorporate this into the prior section on removing a media description from a bundle group. E.g., in 6.2.4: When an Offerer removes an "m=" line from a BUNDLE group, the Offerer MUST assign either a unique address *or a zero port* to the "m=" line that is removed. > When an Offerer rejects an "m=" line in a BUNDLE group, the Offerer > > MUST assign a unique address, with a zero port value [RFC3264], to as long as the port is zero the address need not be otherwise unique. > the "m=" line that is rejected. In addition, the Offerer MUST NOT > > place the mid value that was previously defined for the "m=" line in > > the SDP group:BUNDLE attribute mid value list associated with the > > BUNDLE group. > > To the other "m=" lines (that previously have been added to the > > BUNDLE group), the Offerer assigns addresses according to the > > procedures in Section 6.2.1. > > Example: The example shows an SDP Offer, where an "video" "m=" line > > (previously identified by the "zen" mid value), is rejected, and > > removed from a BUNDLE group. The Offerer assigns a unique address, > > with a zero port value, to the "m=" line, and the bundle address to > > each of the remaining "m=" lines in the BUNDLE group. > > SDP Offer > > v=0 > > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > > s= > > c=IN IP4 host.atlanta.com > > t=0 0 > > a=group:BUNDLE foo bar > > m=audio 10000 RTP/AVP 0 8 97 > > a=mid:foo > > b=AS:200 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:97 iLBC/8000 > > m=video 10000 RTP/AVP 31 32 > > a=mid:bar > > b=AS:1000 > > a=rtpmap:31 H261/90000 > > a=rtpmap:32 MPV/90000 > > m=video 0 RTP/AVP 60 > > a=rtpmap:60 H261/90000 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From fandreas@cisco.com Thu Jun 13 15:16:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14A221F9B1D for ; Thu, 13 Jun 2013 15:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzRO07pJi6XA for ; Thu, 13 Jun 2013 15:16:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7321F9B1C for ; Thu, 13 Jun 2013 15:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4909; q=dns/txt; s=iport; t=1371161810; x=1372371410; h=message-id:date:from:mime-version:to:cc:subject; bh=jCM/utwsFfo8PhQYXXvkqu4y8erB7DpnWS2wi70UnYU=; b=Y0zhWtPYJUTGo3RSLx19HzXZHaXxSo9/fOYFw54kZbhyaDFAtJhRhvDR Kn/9SC9qRevJ3ugacdc8fps417VRJfcZFqGDTRCfcB/LB0n1euNKhd0/m o5k1SdK0qfhPFzjn/Rw1c6gNReVxW3bnlK2MGc35NUAZ6mcrNfZnOMm+q I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAL5DulGtJXHB/2dsb2JhbABagkVEMIkbtXCBAhZ0gyIBHx0WGAMCAQIBSw0BBwEBBYgFDLsMjhUFgS2DZwOXQYEpkBmBWIFTIIEuBxc X-IronPort-AV: E=Sophos;i="4.87,861,1363132800"; d="scan'208,217";a="222557929" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 13 Jun 2013 22:16:46 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5DMGjBJ021173; Thu, 13 Jun 2013 22:16:46 GMT Message-ID: <51BA44CC.6000607@cisco.com> Date: Thu, 13 Jun 2013 18:16:44 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------070505070402040806050106" Cc: Ari Keranen , Hadriel Kaplan , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 22:16:54 -0000 This is a multi-part message in MIME format. --------------070505070402040806050106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings MMUSIC As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and we have a WG draft for that in the form of http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/ When we polled for interest in this work about 1 year ago (per the above thread), there was some indication of continued interest in the work, however there were also some (significant) concerns expressed with the draft itself (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). These concerns have existed for well over a year and we have seen very little discussion or active work trying to resolve them. In lieu of the above, the chairs would like to ask the WG participants to 1) Indicate if you are in favor of continuing this work. 2) If you are willing to actively contribute to the work by either a) Sign on as co-author, drive the open issues to resolution, and update the document accordingly b) Actively contribute to discussion and resolution of open issues in the draft. Please note, that if you answer "yes" to 2a or 2b, then you should assume that you *will* get called upon to deliver on that. Also please note, that if we do not get sufficient positive responses to both 1 and 2 above, then our plan is to remove the milestone and abandon the WG draft. Thanks -- Ari & Flemming (MMUSIC co-chairs) --------------070505070402040806050106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings MMUSIC

As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and we have a WG draft for that in the form of

    http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/

When we polled for interest in this work about 1 year ago (per the above thread), there was some indication of continued interest in the work, however there were also some (significant) concerns expressed with the draft itself (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). These concerns have existed for well over a year and we have seen very little discussion or active work trying to resolve them.

In lieu of the above, the chairs would like to ask the WG participants to

1) Indicate if you are in favor of continuing this work.

2) If you are willing to actively contribute to the work by either
a) Sign on as co-author, drive the open issues to resolution, and update the document accordingly
b) Actively contribute to discussion and resolution of open issues in the draft.

Please note, that if you answer "yes" to 2a or 2b, then you should assume that you *will* get called upon to deliver on that.

Also please note, that if we do not get sufficient positive responses to both 1 and 2 above, then our plan is to remove the milestone and abandon the WG draft.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)













--------------070505070402040806050106-- From mperumal@cisco.com Thu Jun 13 17:55:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFFA21F9B41 for ; Thu, 13 Jun 2013 17:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0qDtYWwcj64 for ; Thu, 13 Jun 2013 17:55:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E90B421F9AE1 for ; Thu, 13 Jun 2013 17:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10070; q=dns/txt; s=iport; t=1371171314; x=1372380914; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zf7E0SMuWxoMnk8LMm/L3O7tgUvb6qLbCaNlm86WLqs=; b=jubzIjKl7gS/X/r4m9fdeBzF11a83JuR0+0Tv/nBsRJvyO5KJWVTT6X+ BOCTJ8DzQ74Kd8lkQMtFrbe7lS2Qa8ia5yxZNgD67rSQILktknwm+ARJJ RSELRiU1c7nww1CmLqW/9OsAm7AZc9XcvelYx7IOiYW9+vxbnVq7cxP7v Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIFANFoulGtJXG9/2dsb2JhbABagkVEMEmrNYEUiTWIUIEFFnSCIwEBAQQtTBACAQgRBAEBCxkEBzIUCQgCBAENBQgBiAUMum2OFQV8MQYBgn9hA5hqkBmBWIE3gWoHFx8 X-IronPort-AV: E=Sophos;i="4.87,862,1363132800"; d="scan'208,217";a="222630219" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jun 2013 00:55:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5E0tDGZ025030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Jun 2013 00:55:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.110]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 19:55:13 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Flemming Andreasen (fandreas)" , mmusic Thread-Topic: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ? Thread-Index: AQHOaIPK9c8MlcQHmEqhQOA1j4RvYpk0YMvA Date: Fri, 14 Jun 2013 00:55:12 +0000 Message-ID: References: <51BA44CC.6000607@cisco.com> In-Reply-To: <51BA44CC.6000607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.49.162] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22413EC9Exmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: Ari Keranen , Hadriel Kaplan , "draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org" Subject: Re: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 00:55:24 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE22413EC9Exmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable |1) Indicate if you are in favor of continuing this work. I don't have any opinion on this. |2) If you are willing to actively contribute to the work by either |a) Sign on as co-author, drive the open issues to resolution, and update t= he | document accordingly |b) Actively contribute to discussion and resolution of open issues in the = draft. I've contributed some text to this draft and I am willing to contribute to = the discussions and resolution of the open issues if the WG decides to fini= sh this work. Muthu From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen (fandreas) Sent: Friday, June 14, 2013 3:47 AM To: mmusic Cc: Ari Keranen; Hadriel Kaplan; draft-ietf-mmusic-media-path-middleboxes@t= ools.ietf.org Subject: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-= mmusic-media-path-middleboxes) ? Greetings MMUSIC As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/ms= g09368.html), we currently have a milestone for " Considerations for using = SDP offer/answer with middleboxes" and we have a WG draft for that in the f= orm of http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxe= s/ When we polled for interest in this work about 1 year ago (per the above th= read), there was some indication of continued interest in the work, however= there were also some (significant) concerns expressed with the draft itsel= f (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmus= ic/current/msg10163.html). These concerns have existed for well over a year= and we have seen very little discussion or active work trying to resolve t= hem. In lieu of the above, the chairs would like to ask the WG participants to 1) Indicate if you are in favor of continuing this work. 2) If you are willing to actively contribute to the work by either a) Sign on as co-author, drive the open issues to resolution, and update th= e document accordingly b) Actively contribute to discussion and resolution of open issues in the d= raft. Please note, that if you answer "yes" to 2a or 2b, then you should assume t= hat you *will* get called upon to deliver on that. Also please note, that if we do not get sufficient positive responses to bo= th 1 and 2 above, then our plan is to remove the milestone and abandon the = WG draft. Thanks -- Ari & Flemming (MMUSIC co-chairs) --_000_E721D8C6A2E1544DB2DEBC313AF54DE22413EC9Exmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

|1) Indicate if you are in favor of conti= nuing this work.

 

I don't have any opinion on this.

 

|2) If you are willing to actively contri= bute to the work by either

|a) Sign on as co-author, drive the open = issues to resolution, and update the

|   document accordingly

|b) Actively contribute to discussion and= resolution of open issues in the draft.

 

I've contributed some text to this draft = and I am willing to contribute to the discussions and resolution of the ope= n issues if the WG decides to finish this work.

 

Muthu

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Flemming Andreasen (fandreas)
Sent: Friday, June 14, 2013 3:47 AM
To: mmusic
Cc: Ari Keranen; Hadriel Kaplan; draft-ietf-mmusic-media-path-middle= boxes@tools.ietf.org
Subject: [MMUSIC] What should we do with the middleboxes draft (draf= t-ietf-mmusic-media-path-middleboxes) ?

 

Greetings MMUSIC

As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current= /msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and= we have a WG draft for that in the form of

    http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/

When we polled for interest in this work about 1 year ago (per the above th= read), there was some indication of continued interest in the work, however= there were also some (significant) concerns expressed with the draft itsel= f (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). = These concerns have existed for well over a year and we have seen very litt= le discussion or active work trying to resolve them.

In lieu of the above, the chairs would like to ask the WG participants to <= br>
1) Indicate if you are in favor of continuing this work.

2) If you are willing to actively contribute to the work by either
a) Sign on as co-author, drive the open issues to resolution, and update th= e document accordingly
b) Actively contribute to discussion and resolution of open issues in the d= raft.

Please note, that if you answer "yes" to 2a or 2b, then you shoul= d assume that you *will* get called upon to deliver on that.

Also please note, that if we do not get sufficient positive responses to bo= th 1 and 2 above, then our plan is to remove the milestone and abandon the = WG draft.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)












--_000_E721D8C6A2E1544DB2DEBC313AF54DE22413EC9Exmbrcdx02ciscoc_-- From prvs=5877648596=christer.holmberg@ericsson.com Fri Jun 14 04:36:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFE621F9BCD for ; Fri, 14 Jun 2013 04:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1d57SsmtMB5 for ; Fri, 14 Jun 2013 04:36:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3E521F9BEB for ; Fri, 14 Jun 2013 04:36:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-05-51bb001e9320 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 72.D7.15700.E100BB15; Fri, 14 Jun 2013 13:35:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 13:35:58 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AA24L0AABt8NdA= Date: Fri, 14 Jun 2013 11:35:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> In-Reply-To: <51BA08D0.3030301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvra48w+5Ag93/eCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApitsmKbGkLDgzPU/fLoE7Y0bzB/aCxtCKyQ/b2RsYNzl1MXJySAiY SGzf/pkJwhaTuHBvPVsXIxeHkMBhRokX8z9BOUsYJXZvegbkcHCwCVhIdP/TBmkQEfCVePb4 NlhYWMBR4sN/HYiwk8THc1uZIGwrid+PzrOD2CwCqhIfZlxkBLF5QVqPzAKzhQTyJb503GUC GcMpoCPx+nwYSJgR6Jzvp9aAjWEWEJe49WQ+1JkCEkv2nGeGsEUlXj7+xwrSKiGgKLG8Xw6i XEdiwW6Q40FsbYllC18zQ2wVlDg58wnLBEbRWUimzkLSMgtJyywkLQsYWVYxsucmZuaklxtu YgTGwcEtv3V3MJ46J3KIUZqDRUmc98OpXYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QD o/uZdf9PG7rOUbDovZD7UWq55qTEbdeyLKStfcMYDwTPyuYt3aUdv0e5Ks6vrstiB2deQdbc +OhmqbQfimziVxmelzV51Vl5vQsU1gvkKNbZ+vXv1KatzlYqKnMVLoSvdD97buuXmXw/G/YL issxSm2tXyE70ZF9osspjvrH3D9uWRpsFTuuxFKckWioxVxUnAgA+hFq0VYCAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 11:36:07 -0000 Hi, >> 6.1. General >> >> This section describes the usage of the SDP Offer/Answer mechanism >> [RFC3264] to negotiate the usage of the BUNDLE mechanism, to >> negotiate the bundle address, and to add, remove and reject SDP=20 >> Media Descriptions ("m=3D" lines) associated with a BUNDLE group. >> >> The generic rules and procedures defined in [RFC3264] and=20 >> [RFC5888]apply when the SDP Offer/Answer mechanism is used for BUNDL= E. For >> example, if an SDP Offer is rejected, the previously negotiated SDP >> parameters and characteristics (including those associated with BUND= LE groups) apply. >> >> When an endpoint generates an SDP Offer, or an SDP Answer, which >> contains a BUNDLE group, the endpoint MUST assign SDP media-level=20 >> mid value for each "m=3D" line in the BUNDLE group. In addition, th= e >> endpoint MUST insert an SDP session-level group:BUNDLE attribute,=20 >> and place each mid value associated with the BUNDLE group in the >> attribute mid value list. >> >> Until the Offerer knows whether the Answerer supports the BUNDLE >> mechanism, the Offerer MUST, for each "m=3D" line in a BUNDLE group: > > Under what circumstances may the offerer presume to *know* whether the an= swerer supports BUNDLE? > > The minimal answer is that if an offer included a bundle group, and the a= nswer also contains a corresponding bundle group, then the answerer=20 > supported *that* bundle at the time of *that* answer, and continues to do= so at least until there is another offer. Yes. I was actually thinking about removing the "until the Offerer knows" text, = and simply generally say that the bundle address is negotiated by assigning= a unique address to each "m=3D" line. But, as you want to be able to assign a bundle address to multiple "m=3D" l= ines before it has been negotiated, it would not work. > But we want to assume more - at least that if *a* bundle was supported by= both sides in one O/A exchange, then both sides can be presumed to > *understand* bundle, including the use of the same address info for multi= ple m-lines in a bundle offer, in future offers within the same signaling s= ession. I would rather say SDP session, to keep it independent from the signaling p= rotocol. That is the same as for any other parameter you negotiate using SD= P O/A - it's valid until re-negotiated. > Is, or should there be, a way to go back on that presumption - to stop su= pporting bundle? I guess if an end wanted to stop supporting bundle=20 > while a bundle was in effect it would need to send an offer that didn't i= nclude any bundles. But it might want to send such an offer just because > it doesn't currently need a bundle though it still supports them. Sure, but if anyone then wants to start using BUNDLE again, it will send an= Offer and suggest the usage. > Perhaps we should say that an offerer or answerer who supports bundle sho= uld *always* include an a=3Dgroup:bundle in its offers and=20 > answers. If it doesn't currently want a bundle it can simply include "a= =3Dgroup:bundle" without any mid values. Or, we could leave it up to the signaling protocol. For SIP, one could defi= ne a media feature tag. That would also allow SIP entities to request that = INVITEs are sent to entities to support BUNDLE (and have indicated so durin= g registration). -------------------------------------- >> 6.2.1. SDP Offerer Bundle Address Request and Usage >> >> An Offerer can assign an address to multiple "m=3D" lines in a=20 >> BUNDLE group, once the address has been selected as the Offerer's lo= cal >> bundle address. An Offerer MUST NOT assign an address to multiple >> "m=3D" lines until the address has been selected as a bundle address >> for that BUNDLE group. >> >> In order to negotiate (or, to re-negotiate) the bundle address >> associated with a BUNDLE group, the Offerer, in the SDP Offer, >> assigns a unique address to each "m=3D" line in the BUNDLE group. =20 >> In addition, the Offerer indicates which unique address it wishes to= =20 >> use as its local bundle address. There Offerer places the mid value= , >> associated with the "m=3D" line that contains the preferred address >> first in the SDP group:BUNDLE attribute mid list. The Answerer=20 >> then selects the local bundle address for the Offerer ([ref-to-be-ad= ded]). > > I don't understand what the last sentence above is trying to tell me. The intention is to say that the Answerer selects the Offerer's bundle addr= ess. -------------------------------------- >> If the Offerer, in a subsequent SDP Offer, wants to re-negotiate=20 >> the bundle address associated with a BUNDLE group, it MAY assign the >> previously negotiated bundle address as a unique address to one of >> the "m=3D" lines in the BUNDLE group. >> >> If the Offerer assigns the bundle address to more than one "m=3D"=20 >> line in a BUNDLE group, the first mid value in the SDP group:BUNDLE >> attribute mid value list MUST represent an "m=3D" line to which the >> bundle address is assigned. Hence, in order to re-negotiate the >> bundle address, the Offerer needs to assign a unique address to=20 >> each "m=3D" line in the BUNDLE group, as described above. > > I still object to this. It is a significant cost, and I don't understand = how it adds any value over simply assigning a new address to all the bundle= d m-lines. The problem is not assigning a new address to all m- lines. >From a specification perspective, it becomes a little more tricky when you = add a new bundle address to some m- lines, and unique addresses to others.= =20 Also, the Answerer will have check and figure out that the suggested new BU= NDLE address has been assigned to multiple "m=3D" lines, and that it theref= ore cannot move it out of the BUNDLE group without rejecting it, etc. I guess one alternative could be to say that a suggested new BUNDLE address= would have to be assigned to each "m=3D" line in the BUNDLE group. I.e. th= e Offerer would not be allowed to assign both a new BUNDLE address and uniq= ue addresses (e.g. for "m=3D" lines being added to the BUNDLE group). -------------------------------------- >> 6.2.2. Bundle Address Synchronization (BAS) >> >> When an Offerer has sent an SDP Offer, a bundle address has been >> selected by the Answerer, and the bundle address was in the SDP=20 >> Offer not assigned to each "m=3D" line in the BUNDLE group, the Offe= rer=20 >> MUST send a new SDP Offer, in which it assigns the negotiated bundle >> address to each "m=3D" line in the BUNDLE group. This procedure is >> referred to as Bundle Address Synchronization (BAS). >> >> The Offerer MUST NOT modify any parameters associated with the=20 >> BUNDLE group when it performs a BAS. > > I still don't understand the point of this restriction. > What value does it add? > > Suppose that a need to make another change arises after the offer that pr= oposed the bundle, but before the answer has been=20 > received. Then, when the answer is received it will be necessary to send = a BAS before sending another offer to make the new change. Why wait? > > ISTM that it would be better to say that after receiving an answer, if th= ere is at that moment no need to send another offer, if the corresponding=20 > offer had bundled m-lines with different addresses, then a BAS must be se= nt. The main reason for not allowing any parameter modifications in the BAS was= to decrease the likelihood that the Answerer would reject the BAS (because= it doesn't accept the suggested parameter changes). So, we can for sure allow parameter modifications in a BAS, but I think we = need some text saying that an Offerer must perform a BAS until it is accept= ed. -------------------------------------- >> 6.2.4. Removing A Media Description From A BUNDLE Group >> >> When an Offerer removes an "m=3D" line from a BUNDLE group, the=20 >> Offerer MUST assign a unique address to the "m=3D" line that is remo= ved. In >> addition, the Offerer MUST NOT place the mid value that was >> previously defined for the "m=3D" line in the SDP group:BUNDLE >> attribute mid value list associated with the BUNDLE group. > > nit: I don't think this should say anything about the mid value that was = previously defined for the m-line. That implies that mid=20 > values must be preserved from one o/a to another. While they probably wil= l in most cases I don't think that should be required.=20 > If I want, I should be able to "relabel" the m-lines with new mid values.= This reduces the amount of state that is required to be=20 > preserved from one o/a to the next. > > The statement "remove an m-line from a bundle group" already implies that= the group does not contain a mid-value identifying that m-line (in > *this* offer or answer). Maybe I could say that the mid value that was previously defined is no more= valid, and must not be present in any Offer or Answer. -------------------------------------- >> 6.2.5. Rejecting A Media Description In A BUNDLE Group >> >> I agree with prior comment that using "Rejecting" here is weird and conf= using. I agree that "disabling" is probably more appropriate. >> But then "disabling a media description in a bundle group" is still a li= ttle confusing, because it is then no longer "in" the bundle group. >> >> It might be clearer to just incorporate this into the prior section on r= emoving a media description from a bundle group. E.g., in 6.2.4: >> >> When an Offerer removes an "m=3D" line from a BUNDLE group, the Offer= er >> MUST assign either a unique address *or a zero port* to the "m=3D" li= ne >> that is removed. I at least intend to put back "disabling". I was also thinking about combin= ing the sections, as you suggest, as the only difference is that the port value is set to zero in the reject/disable case. >> When an Offerer rejects an "m=3D" line in a BUNDLE group, the=20 >> Offerer MUST assign a unique address, with a zero port value [RFC326= 4], to > > as long as the port is zero the address need not be otherwise unique. True. I guess your suggested text above ("unique address or a zero port") w= ill fix that. As a side note, I intend to replace "unique address" and "bundle address" w= ith "unique transport parameters" and "bundle transport parameters", as sug= gested by Martin. ...except in cases where the text actually talks about the IP address, that= is :) Regards, Christer From prvs=3877b5c150=christer.holmberg@ericsson.com Fri Jun 14 06:30:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C5921F91BF for ; Fri, 14 Jun 2013 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.259 X-Spam-Level: X-Spam-Status: No, score=-4.259 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mAxEvs5zPLM for ; Fri, 14 Jun 2013 06:30:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 695D521F9953 for ; Fri, 14 Jun 2013 06:30:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-d3-51bb1ade5403 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FA.A4.15700.EDA1BB15; Fri, 14 Jun 2013 15:30:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 15:30:06 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AA24L0AABt8NdAAEWuM8A== Date: Fri, 14 Jun 2013 13:30:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38ABEE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre49qd2BBpOmGVlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xrGJl1gKdsZUTPy1i7GBcb9HFyMnh4SA icSdo6tYIGwxiQv31rOB2EIChxklZu6t6WLkArKXMEos/vCasYuRg4NNwEKi+582SI2IgK/E s8e32UDCwgKOEh/+60CEnSQ+ntvKBGM/+3UezGYRUJXYcrqLFcTmBWo9eP0HG8T4zYwSzVem g93AKeAncWDPG7AGRqB7vp9aA2YzC4hL3HoynwniTgGJJXvOM0PYohIvH/9jBblBQkBRYnm/ HES5nsSNqVPYIGxtiWULXzND7BWUODnzCcsERtFZSKbOQtIyC0nLLCQtCxhZVjGy5yZm5qSX G25iBEbCwS2/dXcwnjoncohRmoNFSZz3w6ldgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4QQSX VANjoLPekQdOPM/cfrT2z5HwDqwV/Fdn86bm8q5LqXNX7j256e66L3La6dEsLSbiX+v3Xuy0 tKj52LliLjffN4WF0jNfXnk3i5PDubxDZZfX7qjSjRwn4u1lpD4Fqaxb9t3wUO5OmbKSfr+2 DVrHnjTEp308u2LLm96Pooeu7z544r69pbod2+yDSizFGYmGWsxFxYkA0CQsTFcCAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 13:30:20 -0000 Hi Paul, I will try to submit a new version of the BUNDLE draft today, or at latest = during the weekend. I have done quite much re-structuring/re-wording, and I also try to impleme= nt most of your suggestions. Allowing the Offerer to assign a new BUNDLE address to multiple "m=3D" line= s will require some editorial work, though, so I would like to have some mo= re discussions about it before I change the text. Just to make sure you don= 't think that I don't care about your opinion :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 14. kes=E4kuuta 2013 14:36 To: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) Hi, >> 6.1. General >> >> This section describes the usage of the SDP Offer/Answer mechanism >> [RFC3264] to negotiate the usage of the BUNDLE mechanism, to >> negotiate the bundle address, and to add, remove and reject SDP=20 >> Media Descriptions ("m=3D" lines) associated with a BUNDLE group. >> >> The generic rules and procedures defined in [RFC3264] and=20 >> [RFC5888]apply when the SDP Offer/Answer mechanism is used for BUNDL= E. For >> example, if an SDP Offer is rejected, the previously negotiated SDP >> parameters and characteristics (including those associated with BUND= LE groups) apply. >> >> When an endpoint generates an SDP Offer, or an SDP Answer, which >> contains a BUNDLE group, the endpoint MUST assign SDP media-level=20 >> mid value for each "m=3D" line in the BUNDLE group. In addition, th= e >> endpoint MUST insert an SDP session-level group:BUNDLE attribute,=20 >> and place each mid value associated with the BUNDLE group in the >> attribute mid value list. >> >> Until the Offerer knows whether the Answerer supports the BUNDLE >> mechanism, the Offerer MUST, for each "m=3D" line in a BUNDLE group: > > Under what circumstances may the offerer presume to *know* whether the an= swerer supports BUNDLE? > > The minimal answer is that if an offer included a bundle group, and=20 > the answer also contains a corresponding bundle group, then the answerer = supported *that* bundle at the time of *that* answer, and continues to do s= o at least until there is another offer. Yes. I was actually thinking about removing the "until the Offerer knows" text, = and simply generally say that the bundle address is negotiated by assigning= a unique address to each "m=3D" line. But, as you want to be able to assign a bundle address to multiple "m=3D" l= ines before it has been negotiated, it would not work. > But we want to assume more - at least that if *a* bundle was supported=20 > by both sides in one O/A exchange, then both sides can be presumed to > *understand* bundle, including the use of the same address info for multi= ple m-lines in a bundle offer, in future offers within the same signaling s= ession. I would rather say SDP session, to keep it independent from the signaling p= rotocol. That is the same as for any other parameter you negotiate using SD= P O/A - it's valid until re-negotiated. > Is, or should there be, a way to go back on that presumption - to stop=20 > supporting bundle? I guess if an end wanted to stop supporting bundle=20 > while a bundle was in effect it would need to send an offer that didn't i= nclude any bundles. But it might want to send such an offer just because it= doesn't currently need a bundle though it still supports them. Sure, but if anyone then wants to start using BUNDLE again, it will send an= Offer and suggest the usage. > Perhaps we should say that an offerer or answerer who supports bundle=20 > should *always* include an a=3Dgroup:bundle in its offers and answers. If= it doesn't currently want a bundle it can simply include "a=3Dgroup:bundle= " without any mid values. Or, we could leave it up to the signaling protocol. For SIP, one could defi= ne a media feature tag. That would also allow SIP entities to request that = INVITEs are sent to entities to support BUNDLE (and have indicated so durin= g registration). -------------------------------------- >> 6.2.1. SDP Offerer Bundle Address Request and Usage >> >> An Offerer can assign an address to multiple "m=3D" lines in a=20 >> BUNDLE group, once the address has been selected as the Offerer's lo= cal >> bundle address. An Offerer MUST NOT assign an address to multiple >> "m=3D" lines until the address has been selected as a bundle address >> for that BUNDLE group. >> >> In order to negotiate (or, to re-negotiate) the bundle address >> associated with a BUNDLE group, the Offerer, in the SDP Offer, >> assigns a unique address to each "m=3D" line in the BUNDLE group. =20 >> In addition, the Offerer indicates which unique address it wishes to= =20 >> use as its local bundle address. There Offerer places the mid value= , >> associated with the "m=3D" line that contains the preferred address >> first in the SDP group:BUNDLE attribute mid list. The Answerer=20 >> then selects the local bundle address for the Offerer ([ref-to-be-ad= ded]). > > I don't understand what the last sentence above is trying to tell me. The intention is to say that the Answerer selects the Offerer's bundle addr= ess. -------------------------------------- >> If the Offerer, in a subsequent SDP Offer, wants to re-negotiate=20 >> the bundle address associated with a BUNDLE group, it MAY assign the >> previously negotiated bundle address as a unique address to one of >> the "m=3D" lines in the BUNDLE group. >> >> If the Offerer assigns the bundle address to more than one "m=3D"=20 >> line in a BUNDLE group, the first mid value in the SDP group:BUNDLE >> attribute mid value list MUST represent an "m=3D" line to which the >> bundle address is assigned. Hence, in order to re-negotiate the >> bundle address, the Offerer needs to assign a unique address to=20 >> each "m=3D" line in the BUNDLE group, as described above. > > I still object to this. It is a significant cost, and I don't understand = how it adds any value over simply assigning a new address to all the bundle= d m-lines. The problem is not assigning a new address to all m- lines. >From a specification perspective, it becomes a little more tricky when you = add a new bundle address to some m- lines, and unique addresses to others.= =20 Also, the Answerer will have check and figure out that the suggested new BU= NDLE address has been assigned to multiple "m=3D" lines, and that it theref= ore cannot move it out of the BUNDLE group without rejecting it, etc. I guess one alternative could be to say that a suggested new BUNDLE address= would have to be assigned to each "m=3D" line in the BUNDLE group. I.e. th= e Offerer would not be allowed to assign both a new BUNDLE address and uniq= ue addresses (e.g. for "m=3D" lines being added to the BUNDLE group). -------------------------------------- >> 6.2.2. Bundle Address Synchronization (BAS) >> >> When an Offerer has sent an SDP Offer, a bundle address has been >> selected by the Answerer, and the bundle address was in the SDP=20 >> Offer not assigned to each "m=3D" line in the BUNDLE group, the Offe= rer=20 >> MUST send a new SDP Offer, in which it assigns the negotiated bundle >> address to each "m=3D" line in the BUNDLE group. This procedure is >> referred to as Bundle Address Synchronization (BAS). >> >> The Offerer MUST NOT modify any parameters associated with the=20 >> BUNDLE group when it performs a BAS. > > I still don't understand the point of this restriction. > What value does it add? > > Suppose that a need to make another change arises after the offer that=20 > proposed the bundle, but before the answer has been received. Then, when = the answer is received it will be necessary to send a BAS before sending an= other offer to make the new change. Why wait? > > ISTM that it would be better to say that after receiving an answer, if=20 > there is at that moment no need to send another offer, if the correspondi= ng offer had bundled m-lines with different addresses, then a BAS must be s= ent. The main reason for not allowing any parameter modifications in the BAS was= to decrease the likelihood that the Answerer would reject the BAS (because= it doesn't accept the suggested parameter changes). So, we can for sure allow parameter modifications in a BAS, but I think we = need some text saying that an Offerer must perform a BAS until it is accept= ed. -------------------------------------- >> 6.2.4. Removing A Media Description From A BUNDLE Group >> >> When an Offerer removes an "m=3D" line from a BUNDLE group, the=20 >> Offerer MUST assign a unique address to the "m=3D" line that is remo= ved. In >> addition, the Offerer MUST NOT place the mid value that was >> previously defined for the "m=3D" line in the SDP group:BUNDLE >> attribute mid value list associated with the BUNDLE group. > > nit: I don't think this should say anything about the mid value that=20 > was previously defined for the m-line. That implies that mid values must = be preserved from one o/a to another. While they probably will in most case= s I don't think that should be required. > If I want, I should be able to "relabel" the m-lines with new mid=20 > values. This reduces the amount of state that is required to be preserved= from one o/a to the next. > > The statement "remove an m-line from a bundle group" already implies=20 > that the group does not contain a mid-value identifying that m-line=20 > (in > *this* offer or answer). Maybe I could say that the mid value that was previously defined is no more= valid, and must not be present in any Offer or Answer. -------------------------------------- >> 6.2.5. Rejecting A Media Description In A BUNDLE Group >> >> I agree with prior comment that using "Rejecting" here is weird and conf= using. I agree that "disabling" is probably more appropriate. >> But then "disabling a media description in a bundle group" is still a li= ttle confusing, because it is then no longer "in" the bundle group. >> >> It might be clearer to just incorporate this into the prior section on r= emoving a media description from a bundle group. E.g., in 6.2.4: >> >> When an Offerer removes an "m=3D" line from a BUNDLE group, the Offer= er >> MUST assign either a unique address *or a zero port* to the "m=3D" li= ne >> that is removed. I at least intend to put back "disabling". I was also thinking about combin= ing the sections, as you suggest, as the only difference is that the port v= alue is set to zero in the reject/disable case. >> When an Offerer rejects an "m=3D" line in a BUNDLE group, the=20 >> Offerer MUST assign a unique address, with a zero port value=20 >> [RFC3264], to > > as long as the port is zero the address need not be otherwise unique. True. I guess your suggested text above ("unique address or a zero port") w= ill fix that. As a side note, I intend to replace "unique address" and "bundle address" w= ith "unique transport parameters" and "bundle transport parameters", as sug= gested by Martin. ...except in cases where the text actually talks about the IP address, that= is :) Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=9877866442=ari.keranen@ericsson.com Fri Jun 14 07:44:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9593521F9C9F for ; Fri, 14 Jun 2013 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v-IVuZCpZVy for ; Fri, 14 Jun 2013 07:44:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1423F21F9CBA for ; Fri, 14 Jun 2013 07:44:05 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-76-51bb2c3495d2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B2.FC.09795.43C2BB15; Fri, 14 Jun 2013 16:44:04 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Jun 2013 16:44:03 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D98322AB5 for ; Fri, 14 Jun 2013 17:44:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 86468552E5 for ; Fri, 14 Jun 2013 17:44:01 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 44AC55444F for ; Fri, 14 Jun 2013 17:44:01 +0300 (EEST) Message-ID: <51BB2C33.9010203@ericsson.com> Date: Fri, 14 Jun 2013 17:44:03 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VtdEZ3egQeNuUYupyx+zODB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+Pt9m1sBSeYKt5PfsDYwNjP1MXIwSEhYCLxc4lsFyMnkCkm ceHeerYuRi4OIYFTjBKPvnSyQjgbGCUW/p3MCOFcZJT49v4BlHOEUeLQ6Q/MEM4+RokZOy8x ggzjFdCW+PvjPxOIzSKgKrHxfA9YnE3AXuLmhOvsILaoQLLE5KkrWCDqBSVOznwCZosIyEjs 3bSZGcQWFnCSuDL3CNgcZgFbiQtzrrNA2PIS29/OYYY4XE3i6rlNYLYQ0K6r/14xTmAUmoVk 7Cwk7bOQtC9gZF7FyJ6bmJmTXm6+iREYnge3/DbYwbjpvtghRmkOFiVx3k+ndgUKCaQnlqRm p6YWpBbFF5XmpBYfYmTi4AQRXFINjGFi3Q+yq9drzA/KVeh01gzU9tt7qmyK7dbI37om+19l vq8t/eHEtDVsxZo9cwR+pFhxOXKl5bsLbch57HHrldf9R/3L+7c+9bnFL2PsKL3bhUV951se tW9BjK9zTqzJ/C/WJvzT5Hn+quN/VmVU6Zq27+a5f/8nZ6fCjcpfluy8wg5+PA7VSizFGYmG WsxFxYkAisXCbyICAAA= Subject: [MMUSIC] Minutes of the MMUSIC WG May 23rd virtual interim meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:44:13 -0000 Hi all, The draft minutes of the MMUSIC WG May 23rd virtual interim meeting have been posted at: http://www.ietf.org/proceedings/interim/2013/05/23/mmusic/minutes/minutes-interim-2013-mmusic-2 Please review the minutes and let us know of any comments or corrections. Thanks, Ari & Flemming (MMUSIC co-chairs) From prvs=3877eb4cab=ari.keranen@ericsson.com Fri Jun 14 09:04:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF421F9D0A for ; Fri, 14 Jun 2013 09:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.037 X-Spam-Level: X-Spam-Status: No, score=-5.037 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-7GUbyPXj24 for ; Fri, 14 Jun 2013 09:04:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9453221F9C81 for ; Fri, 14 Jun 2013 09:04:23 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-98-51bb3f050319 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.F5.18006.50F3BB15; Fri, 14 Jun 2013 18:04:21 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Jun 2013 18:04:21 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5A6352AC6; Fri, 14 Jun 2013 19:04:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 11425552A1; Fri, 14 Jun 2013 19:04:19 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B5BEA55089; Fri, 14 Jun 2013 19:04:18 +0300 (EEST) Message-ID: <51BB3F04.7050504@ericsson.com> Date: Fri, 14 Jun 2013 19:04:20 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <518E169E.4050006@jitsi.org> <51B5EDB9.9030109@jitsi.org> <51B6BDA9.2000902@jitsi.org> <51B6D738.3000507@jitsi.org> In-Reply-To: <51B6D738.3000507@jitsi.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvrS6r/e5Ag9+XLS3W7JzAYtExmc1i 6vLHLA7MHlN+b2T1WLLkJ5PH/zeBAcxR3DZJiSVlwZnpefp2CdwZ02YeZiqYrFyx/NUl9gbG v9JdjJwcEgImEsd7TrJD2GISF+6tZ+ti5OIQEjjFKLGy4yATSEJIYAOjxJsffBCJ3YwSc9f9 ZYRw1jFK7Fi/hAnCWcEocX7ZNrAWXgFtiY0tuxlBbBYBVYnFjxeBxdkEbCVWv7rJAmKLCiRL TJ66ggWiXlDi5MwnYLaIgLxEdxtEPbNAjETPtQYwW1jAWeL4jHcsEMt2Mks83b8e7HBOAU2J GxcnM0I0WEgsfnOQHcKWl2jeOpsZ4jk1iavnNjFD/KMqcfXfK8YJjKKzkOyehaR9FpL2BYzM qxjZcxMzc9LLjTYxAqPh4JbfqjsY75wTOcQozcGiJM778dSuQCGB9MSS1OzU1ILUovii0pzU 4kOMTBycIIJLqoGRh7lv5WXeyG2GqY4/+/9/uSHwZMraAkO1ODHT8zKJJSEzJWJuLC78wJxY 5Wv0lYXZo+fE6vO+oaxGadM2Ga/jSWwMPGveqHSrTVbZO8T0sbvB5wkPLLZxzd75JL9untGk azMzfzmpneJ56TL/v4XJXBtWLQMvncUsBx+1qK06dOa22V/DlJlKLMUZiYZazEXFiQCUCFFl WQIAAA== Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org WG" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:04:29 -0000 Hi, The proposed text looks good to me (just need to expand the CGN acronym since it seems to be the first instance; and check if you can find good reference of CGN). Regarding the RFC3424 UNSAF considerations, I discussed this together with our co-chair and AD, and we agreed that a full 3424 treatment is unnecessary considering that this is documenting existing behavior, not a new mechanism. If this clears the remaining WGLC comments, we could move forward with the document. Cheers, Ari On 6/11/13 10:52 AM, Emil Ivov wrote: > > > On 11.06.13, 08:15, Cullen Jennings (fluffy) wrote: >> >> Well, do you think the draft should say that this approach MUST NOT >> be used with uncarpeted media because it allows and attacker behind >> the same CGN can intercept the media ? > > I am assuming uncarpeted means unprotected here. Is this right? > > If so, then I think we shouldn't be doing any kind of (non-S) RTP > because, regardless of whether or not we are using latching, our media > would be exposed to eavesdropping from our ISP, hotspot provider, VoIP > service provider, potentially people on the same link as us, MiTM > attackers that have fooled us into using them as a default gateway, > Wi-Fi monitors and possibly many others. > > As for the draft saying "MUST NOT", I wouldn't mind at all, however we > don't even have a 2119 section. Also, we are not specifying a NAT > traversal mechanism, we are just describing one that people are using > overwhelmingly so that we can have something to point to as a > descriptive reference. > > I agree that this point can be stressed upon however so, what if we > added the following: > > ... actually participating in the SRTP key exchange then it would > simply refuse to latch onto a source unless it can authenticate > it. > > *Failing to implement this would represent а serious threat to > users connecting from behind CGNs and is considered a harmful > practice.* > > Would this work? > > Emil > > > >> On Jun 11, 2013, at 3:03 PM, Emil Ivov wrote: >> >>> Hey Cullen, >>> >>> On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote: >>>>> >>>>>> and discussing the issues it raises with relation to this >>>>>> draft. >>>>>> >>>>>> Next I think you need to add a specific attack where two >>>>>> people are both behind the same CGN. >>>>> >>>>> This exact case was already described in the security >>>>> considerations section: >>>>> >>>>> tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11 >>>>> >>>>> (last paragraph on the page) >>>> >>>> It was exactly this paragraph that I thought was pretty >>>> misleading. When I read " SBCs have various mechanisms to prevent >>>> this as well." I really wonder what they when both end points are >>>> behind a CGN. >>>> >>>> I think this paragraph should make it very clear that in the >>>> CGN case, this technic allows interception of the media. If there >>>> are specific ways to stop that from happening, the draft should >>>> say it and if there are not it should be very explicitly clear >>>> about that. >>> >>> I was actually referring to text that came later in that same >>> paragraph: >>> >>> The attacker could also redirect all media to the real SIP UA after >>> receiving it, in which case the attack would likely remain >>> undetected and succeed. Again, this would be of particular concern >>> with larger scale NATs serving many different endpoints such as >>> carrier grade NATs. The larger the number of devices fronted by a >>> NAT is, the more use cases would vary and the more the number of >>> possible attack vectors would grow. >>> >>> Naturally, SRTP [RFC3711] would help mitigate such threats and >>> should be used independently of HNT. For example, in cases where >>> end-to-end encryption is used it would still be possible for an >>> attacker to hijack a session despite the use of SRTP and perform a >>> denial of service attack. However, media integrity would not be >>> compromised. Additionally if the SBC that performs the latching is >>> actually participating in the SRTP key exchange then it would >>> simply refuse to latch onto a source unless it can authenticate >>> it. >>> >>> Cheers, Emil >>> >>> >>> -- https://jitsi.org >>> _______________________________________________ mmusic mailing >>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >> >> > From prvs=4877294406=ari.keranen@ericsson.com Fri Jun 14 11:20:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D83521F9CB1 for ; Fri, 14 Jun 2013 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.219 X-Spam-Level: X-Spam-Status: No, score=-5.219 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACRDzPODg75K for ; Fri, 14 Jun 2013 11:20:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D7F1B21F9C26 for ; Fri, 14 Jun 2013 11:20:44 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-3f-51bb5efb3331 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 01.39.09795.BFE5BB15; Fri, 14 Jun 2013 20:20:43 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Jun 2013 20:20:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 187292AB5; Fri, 14 Jun 2013 21:20:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BDB2955287; Fri, 14 Jun 2013 21:20:40 +0300 (EEST) Received: from as-macbook-air.elisa (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 597B155280; Fri, 14 Jun 2013 21:20:40 +0300 (EEST) Message-ID: <51BB5EFE.5090903@ericsson.com> Date: Fri, 14 Jun 2013 21:20:46 +0300 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvre7vuN2BBgdWyVq8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmK2yYpsaQsODM9T98ugTtj8+sDbAVNHBV9by6xNjCeYuti5OSQEDCR eNw+B8oWk7hwbz2QzcUhJHCKUaL37VxWCGcDo8T/+7+hMrsZJdofnWGEcNYxSsxaNo8JwlnB KPHk4xGwYbwC2hIT/91m6WLk4GARUJU40ZcGEmYTcJS4/fAlK4gtKpAscaC/nRWiXFDi5Mwn LCC2iICMxN5Nm5lBbGagMbPvzGICsYUFjCUmt0wBG8ksYC/xYGsZRIm8RPPW2cwQL6hJXD23 CcwWAtp69d8rxgmMwrOQbJiF0D0LSfcCRuZVjOy5iZk56eXmmxiBQXxwy2+DHYyb7osdYpTm YFES5/10alegkEB6YklqdmpqQWpRfFFpTmrxIUYmDk4QwSXVwCidJFKYUPfu3af3U403vt/j fEz32vwonm1OPGY2Sox7p0/K8TPIWr5uZYZO4Z2K2suV2xuixaX6eJLcHb4mPDpWqJTnMfH2 o9M+9du32W30VrYy2SLAdXvdwa3XdwYvPG4R+GF9873cRzXdRdb1Rgl1r6ZNXtEaPu2ZDGv1 yjrNl0yzy6qyPJRYijMSDbWYi4oTATZeg2g1AgAA Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:20:54 -0000 Hi all, Given the guidance from the RTCWEB WG chairs that the "no-plan" discussion should essentially happen at the RTCWEB WG, the MMUSIC interim meeting on June 17th will be focused on Plan A and Plan B. The goal of the meeting is to clarify what are the two different plans, what are their key differences and merits, and how can we select one to move forward with. Here's the draft agenda: 7:00 – 7:10 Agenda bash & Note takers 7:10 – 8:10 Plan A Presentation http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00 (also http://tools.ietf.org/html/draft-roach-rtcweb-glareless-add-00) 8:10 – 9:10 Plan B Presentation http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 9:10 – 9:50 Discussion on preferred approach 9:50 – 10:00 Wrap-Up & Next Steps Note: All Times are Pacific Daylight Time (PDT) The WebEx information for joining the meeting is available here: http://www.ietf.org/mail-archive/web/mmusic/current/msg11488.html Regards, Ari & Flemming (MMUSIC co-chairs) From pkyzivat@alum.mit.edu Fri Jun 14 11:34:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF3921F90E4 for ; Fri, 14 Jun 2013 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.062 X-Spam-Level: * X-Spam-Status: No, score=1.062 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, MANGLED_FORM=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJzVl-tZ0s1r for ; Fri, 14 Jun 2013 11:34:27 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id A435521F9AF9 for ; Fri, 14 Jun 2013 11:34:26 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id oGuQ1l0091uE5Es5EJaRnU; Fri, 14 Jun 2013 18:34:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id oJaR1l00W3ZTu2S3cJaRSA; Fri, 14 Jun 2013 18:34:25 +0000 Message-ID: <51BB622F.60007@alum.mit.edu> Date: Fri, 14 Jun 2013 14:34:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371234865; bh=LPZU6xsaJ8i5XM2wnKxcmSME6tVwilZVRQvACLsOQUo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ux8r9wYujM8AesCRvil6SXdIjndU64CxIYI7Tu+THkgcdPAABQ5vR/xXLdGZVKHcl 9bvSsByZMLOHilUsFp1/4odhaH8abfNzuNO6vLtTokGU0xD6K1XXRDRy6VrSDLo07K uXiEpogos1SVmv9Y4Wto5o4rNE4PjrNHjivGlzl3+v1al+KL6YD5Ke7RhmERc5V8lQ W86XDC+8Xpjuk0KcWvuXW/Ioer8M1dolPM8j2rHsK2sZzG8r50nqim6pEddYF4YYiT QAePNZsyen4ThmVvoHSBZYLXrUgDzDrXG+BACCzIj1YC3lU6Uh2Mai6vEm4FH0vHyW qH1Y6QxKI4YZA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 18:34:39 -0000 Hi Christer, More discussion inline. On 6/14/13 7:35 AM, Christer Holmberg wrote: > Hi, > >>> 6.1. General >>> >>> This section describes the usage of the SDP Offer/Answer mechanism >>> [RFC3264] to negotiate the usage of the BUNDLE mechanism, to >>> negotiate the bundle address, and to add, remove and reject SDP >>> Media Descriptions ("m=" lines) associated with a BUNDLE group. >>> >>> The generic rules and procedures defined in [RFC3264] and >>> [RFC5888]apply when the SDP Offer/Answer mechanism is used for BUNDLE. For >>> example, if an SDP Offer is rejected, the previously negotiated SDP >>> parameters and characteristics (including those associated with BUNDLE groups) apply. >>> >>> When an endpoint generates an SDP Offer, or an SDP Answer, which >>> contains a BUNDLE group, the endpoint MUST assign SDP media-level >>> mid value for each "m=" line in the BUNDLE group. In addition, the >>> endpoint MUST insert an SDP session-level group:BUNDLE attribute, >>> and place each mid value associated with the BUNDLE group in the >>> attribute mid value list. >>> >>> Until the Offerer knows whether the Answerer supports the BUNDLE >>> mechanism, the Offerer MUST, for each "m=" line in a BUNDLE group: >> >> Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE? >> >> The minimal answer is that if an offer included a bundle group, and the answer also contains a corresponding bundle group, then the answerer >> supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer. > > Yes. > > I was actually thinking about removing the "until the Offerer knows" text, and simply generally say that the bundle address is negotiated by assigning a unique address to each "m=" line. > > But, as you want to be able to assign a bundle address to multiple "m=" lines before it has been negotiated, it would not work. > >> But we want to assume more - at least that if *a* bundle was supported by both sides in one O/A exchange, then both sides can be presumed to >> *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session. > > I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated. Sure, I think "SDP session" will work. >> Is, or should there be, a way to go back on that presumption - to stop supporting bundle? I guess if an end wanted to stop supporting bundle >> while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because >> it doesn't currently need a bundle though it still supports them. > > Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage. My point was that if support for bundle can be presumed, then it no longer is necessary to offer unique address info for each m-line when adding to bundles or proposing new bundles. In particular, this becomes significant for the bundle splitting case: 1) X sends offer to Y proposing a bundle, uses unique address info 2) Y sends answer to x accepting the bundle, but rejecting some of the m-lines in it 3) X sends a BAS to Y to finalize the initial bundle. 4) Y sends answer to X accepting the BAS 5) Y sends offer to X keeping the existing bundle, and proposing a new bundle for the previously rejected m-lines. Because it knows X supports bundle, and it knows that X was willing to have the m-lines in question bundled, this offer is in the form of a BAS, with all the m-lines in the new bundle having common address info. 6) X sends answer to Y, presumably accepting both bundles. In this case it is quite wasteful if Y has to provide separate address info for each of the m-lines in the new bundle, and then yet another BAS has to be exchanged to fix that up. Of course being able to presume support also is useful in cases where no bundle splitting is needed. E.g., Y was able to accept the initial bundle from X in full. Then later it wanted to offer an additional separate bundle. And it could also cover the case where an initial O/A is done when no bundle is yet needed, but *support* for bundle is negotiated. Then later, when a bundle is needed, it may be offered in BAS form, so only a single O/A is required. The above also points out another issue: (3) & (4) are quite a waste. It would be nice to be able to avoid them in this case. One way to achieve that would be to put the burden on the answerer that accepts a bundle where the address info is not all the same to send the BAS. In this case that would mean that (5) would also serve as a substitute for (3), and (6) would then substitute for (4). >> Perhaps we should say that an offerer or answerer who supports bundle should *always* include an a=group:bundle in its offers and >> answers. If it doesn't currently want a bundle it can simply include "a=group:bundle" without any mid values. > > Or, we could leave it up to the signaling protocol. For SIP, one could define a media feature tag. That would also allow SIP entities to request that INVITEs are sent to entities to support BUNDLE (and have indicated so during registration). Yes, we could. I don't have a strong preference one way or the other. > -------------------------------------- > > >>> 6.2.1. SDP Offerer Bundle Address Request and Usage >>> >>> An Offerer can assign an address to multiple "m=" lines in a >>> BUNDLE group, once the address has been selected as the Offerer's local >>> bundle address. An Offerer MUST NOT assign an address to multiple >>> "m=" lines until the address has been selected as a bundle address >>> for that BUNDLE group. >>> >>> In order to negotiate (or, to re-negotiate) the bundle address >>> associated with a BUNDLE group, the Offerer, in the SDP Offer, >>> assigns a unique address to each "m=" line in the BUNDLE group. >>> In addition, the Offerer indicates which unique address it wishes to >>> use as its local bundle address. There Offerer places the mid value, >>> associated with the "m=" line that contains the preferred address >>> first in the SDP group:BUNDLE attribute mid list. The Answerer >>> then selects the local bundle address for the Offerer ([ref-to-be-added]). >> >> I don't understand what the last sentence above is trying to tell me. > > The intention is to say that the Answerer selects the Offerer's bundle address. I'm still having trouble making sense of this. Let me break out some things to try and understand. (I'm trying to state what I think you mean, not as it ought to be written in a draft, just for maximal clarity.) It is the *answer* that selects the m-line that defines the bundle addresses for both offerer and answerer. Until then it isn't known. Only after the bundle addresses are known may an offer be sent that has a common address for multiple m-lines in the bundle, and if so it must be the one that was previously defined as the bundle address. As a consequence, on the initial offer that proposes a bundle, every m-line must have unique address info. When sending an subsequent offer, after a bundle has previously been defined, (so the bundle addresses are known), multiple m-lines in that bundle *may* be offered with the same address info, but that address info must be the previously agreed bundle address. As a consequence, to *change* a previously agreed bundle address, an offer must be sent where every m-line in the bundle has unique address info. Does that accurately restate what you meant above? (If so, you know that I don't agree - I find it much more prescriptive than it needs to be, with negative consequences. But lets be certain we agree what you are intending to say first.) > -------------------------------------- > > >>> If the Offerer, in a subsequent SDP Offer, wants to re-negotiate >>> the bundle address associated with a BUNDLE group, it MAY assign the >>> previously negotiated bundle address as a unique address to one of >>> the "m=" lines in the BUNDLE group. >>> >>> If the Offerer assigns the bundle address to more than one "m=" >>> line in a BUNDLE group, the first mid value in the SDP group:BUNDLE >>> attribute mid value list MUST represent an "m=" line to which the >>> bundle address is assigned. Hence, in order to re-negotiate the >>> bundle address, the Offerer needs to assign a unique address to >>> each "m=" line in the BUNDLE group, as described above. >> >> I still object to this. It is a significant cost, and I don't understand how it adds any value over simply assigning a new address to all the bundled m-lines. > > The problem is not assigning a new address to all m- lines. Then what is the problem? >>From a specification perspective, it becomes a little more tricky when you add a new bundle address to some m- lines, and unique addresses to others. > > Also, the Answerer will have check and figure out that the suggested new BUNDLE address has been assigned to multiple "m=" lines, and that it therefore cannot move it out of the BUNDLE group without rejecting it, etc. Yes. That doesn't seem to be any great burden. > I guess one alternative could be to say that a suggested new BUNDLE address would have to be assigned to each "m=" line in the BUNDLE group. I.e. the Offerer would not be allowed to assign both a new BUNDLE address and unique addresses (e.g. for "m=" lines being added to the BUNDLE group). Even that seems over prescriptive. ISTM that the problem is being driven by what is easy to describe, rather than what is useful to do, even though the actual implementation effort would probably be the same or even less difficult. While I do agree that clarity of explanation is important, that tells me we need to continue to work to find a clear way to express constraints without being over restrictive. I previously tried - offering a set of constraints on offers and answers that I thought covered the cases. I still think that could work. > -------------------------------------- > > >>> 6.2.2. Bundle Address Synchronization (BAS) >>> >>> When an Offerer has sent an SDP Offer, a bundle address has been >>> selected by the Answerer, and the bundle address was in the SDP >>> Offer not assigned to each "m=" line in the BUNDLE group, the Offerer >>> MUST send a new SDP Offer, in which it assigns the negotiated bundle >>> address to each "m=" line in the BUNDLE group. This procedure is >>> referred to as Bundle Address Synchronization (BAS). >>> >>> The Offerer MUST NOT modify any parameters associated with the >>> BUNDLE group when it performs a BAS. >> >> I still don't understand the point of this restriction. >> What value does it add? >> >> Suppose that a need to make another change arises after the offer that proposed the bundle, but before the answer has been >> received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait? >> >> ISTM that it would be better to say that after receiving an answer, if there is at that moment no need to send another offer, if the corresponding >> offer had bundled m-lines with different addresses, then a BAS must be sent. > > The main reason for not allowing any parameter modifications in the BAS was to decrease the likelihood that the Answerer would reject the BAS (because it doesn't accept the suggested parameter changes). You mean in the sense that the entire offer would be rejected at the signaling level - e.g., a sip 488? The trouble is that this also disallows reasonable and non-risky changes, such as dropping an m-line, or reducing the set of codecs offered to a subset of what had been agreed. > So, we can for sure allow parameter modifications in a BAS, but I think we need some text saying that an Offerer must perform a BAS until it is accepted. Sure, that would be ok. And there could be a note that the offerer should try to construct the BAS to minimize the possibility that it will be rejected. > -------------------------------------- > > >>> 6.2.4. Removing A Media Description From A BUNDLE Group >>> >>> When an Offerer removes an "m=" line from a BUNDLE group, the >>> Offerer MUST assign a unique address to the "m=" line that is removed. In >>> addition, the Offerer MUST NOT place the mid value that was >>> previously defined for the "m=" line in the SDP group:BUNDLE >>> attribute mid value list associated with the BUNDLE group. >> >> nit: I don't think this should say anything about the mid value that was previously defined for the m-line. That implies that mid >> values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required. >> If I want, I should be able to "relabel" the m-lines with new mid values. This reduces the amount of state that is required to be >> preserved from one o/a to the next. >> >> The statement "remove an m-line from a bundle group" already implies that the group does not contain a mid-value identifying that m-line (in >> *this* offer or answer). > > Maybe I could say that the mid value that was previously defined is no more valid, and must not be present in any Offer or Answer. The mid values from the previous o/a have *no* relevance to the new o/a. It is *possible* (though not likely) that some of the same values may be used in the new offer to identify *different* m-lines. So saying that a value from a previous o/a must not be present is also not correct. I don't think you need to say anything about this. Possibly you could say that the bundle group identifies the m-lines that are to be in the bundle, and so must not mention m-lines that are no longer in the bundle. But this is so obvious that stating it is likely to confuse people more than not stating it. > -------------------------------------- > > >>> 6.2.5. Rejecting A Media Description In A BUNDLE Group >>> >>> I agree with prior comment that using "Rejecting" here is weird and confusing. I agree that "disabling" is probably more appropriate. >>> But then "disabling a media description in a bundle group" is still a little confusing, because it is then no longer "in" the bundle group. >>> >>> It might be clearer to just incorporate this into the prior section on removing a media description from a bundle group. E.g., in 6.2.4: >>> >>> When an Offerer removes an "m=" line from a BUNDLE group, the Offerer >>> MUST assign either a unique address *or a zero port* to the "m=" line >>> that is removed. > > I at least intend to put back "disabling". I was also thinking about combining the sections, as you suggest, as the only difference is that > the port value is set to zero in the reject/disable case. > >>> When an Offerer rejects an "m=" line in a BUNDLE group, the >>> Offerer MUST assign a unique address, with a zero port value [RFC3264], to >> >> as long as the port is zero the address need not be otherwise unique. > > True. I guess your suggested text above ("unique address or a zero port") will fix that. > > As a side note, I intend to replace "unique address" and "bundle address" with "unique transport parameters" and "bundle transport parameters", as suggested by Martin. > > ...except in cases where the text actually talks about the IP address, that is :) WFM. Thanks, Paul > Regards, > > Christer > From pkyzivat@alum.mit.edu Fri Jun 14 11:35:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7521F9BD1 for ; Fri, 14 Jun 2013 11:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, MANGLED_FORM=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QujckyuOuG7H for ; Fri, 14 Jun 2013 11:35:12 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 071A321F9BA5 for ; Fri, 14 Jun 2013 11:35:11 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id oHsk1l0020bG4ec5AJbBqE; Fri, 14 Jun 2013 18:35:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id oJbB1l00G3ZTu2S3PJbBhx; Fri, 14 Jun 2013 18:35:11 +0000 Message-ID: <51BB625F.5020000@alum.mit.edu> Date: Fri, 14 Jun 2013 14:35:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C38ABEE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38ABEE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371234911; bh=tjzaUlgPHAAtkegu1W4NtEy0ly1tth9eziWe9NwxInE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E1RVUw5tjOxSyHPZDKm2YiVstGgct2Hv5/1CVPELewKpMWK/eRaD+j5YK1lQBw2/F aMoM8vW7/FJVgkPgXhN0V9J+LNumm1ZxaTi+0E5rcHumB2qniPR0kY4l825iX0xsq/ ildMK0eIi54mREfcuED0gHUYI4Ym3sn9dhz5VqbtA7ZJ+u51ThvCaeE+tHP9s9Xdoq YdWRYv5XtDbaljKTOVknMUU5qYe6AUclXeA6scqXTqQsTDK4HN1z4S0xE16Cf57AP5 RuJtwhhwJSsjT6LS9Qrx6br75RGTPaSRHeyMhn9pDdvcy7ORcVyWizBa25lZIPiOIQ PwjGNuDGlo6PQ== Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 18:35:17 -0000 Sure, this is all good. On 6/14/13 9:30 AM, Christer Holmberg wrote: > > Hi Paul, > > I will try to submit a new version of the BUNDLE draft today, or at latest during the weekend. > > I have done quite much re-structuring/re-wording, and I also try to implement most of your suggestions. > > Allowing the Offerer to assign a new BUNDLE address to multiple "m=" lines will require some editorial work, though, so I would like to have some more discussions about it before I change the text. Just to make sure you don't think that I don't care about your opinion :) > > Regards, > > Christer > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 14. kesäkuuta 2013 14:36 > To: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) > > Hi, > >>> 6.1. General >>> >>> This section describes the usage of the SDP Offer/Answer mechanism >>> [RFC3264] to negotiate the usage of the BUNDLE mechanism, to >>> negotiate the bundle address, and to add, remove and reject SDP >>> Media Descriptions ("m=" lines) associated with a BUNDLE group. >>> >>> The generic rules and procedures defined in [RFC3264] and >>> [RFC5888]apply when the SDP Offer/Answer mechanism is used for BUNDLE. For >>> example, if an SDP Offer is rejected, the previously negotiated SDP >>> parameters and characteristics (including those associated with BUNDLE groups) apply. >>> >>> When an endpoint generates an SDP Offer, or an SDP Answer, which >>> contains a BUNDLE group, the endpoint MUST assign SDP media-level >>> mid value for each "m=" line in the BUNDLE group. In addition, the >>> endpoint MUST insert an SDP session-level group:BUNDLE attribute, >>> and place each mid value associated with the BUNDLE group in the >>> attribute mid value list. >>> >>> Until the Offerer knows whether the Answerer supports the BUNDLE >>> mechanism, the Offerer MUST, for each "m=" line in a BUNDLE group: >> >> Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE? >> >> The minimal answer is that if an offer included a bundle group, and >> the answer also contains a corresponding bundle group, then the answerer supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer. > > Yes. > > I was actually thinking about removing the "until the Offerer knows" text, and simply generally say that the bundle address is negotiated by assigning a unique address to each "m=" line. > > But, as you want to be able to assign a bundle address to multiple "m=" lines before it has been negotiated, it would not work. > >> But we want to assume more - at least that if *a* bundle was supported >> by both sides in one O/A exchange, then both sides can be presumed to >> *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session. > > I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated. > >> Is, or should there be, a way to go back on that presumption - to stop >> supporting bundle? I guess if an end wanted to stop supporting bundle >> while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because it doesn't currently need a bundle though it still supports them. > > Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage. > >> Perhaps we should say that an offerer or answerer who supports bundle >> should *always* include an a=group:bundle in its offers and answers. If it doesn't currently want a bundle it can simply include "a=group:bundle" without any mid values. > > Or, we could leave it up to the signaling protocol. For SIP, one could define a media feature tag. That would also allow SIP entities to request that INVITEs are sent to entities to support BUNDLE (and have indicated so during registration). > > > -------------------------------------- > > >>> 6.2.1. SDP Offerer Bundle Address Request and Usage >>> >>> An Offerer can assign an address to multiple "m=" lines in a >>> BUNDLE group, once the address has been selected as the Offerer's local >>> bundle address. An Offerer MUST NOT assign an address to multiple >>> "m=" lines until the address has been selected as a bundle address >>> for that BUNDLE group. >>> >>> In order to negotiate (or, to re-negotiate) the bundle address >>> associated with a BUNDLE group, the Offerer, in the SDP Offer, >>> assigns a unique address to each "m=" line in the BUNDLE group. >>> In addition, the Offerer indicates which unique address it wishes to >>> use as its local bundle address. There Offerer places the mid value, >>> associated with the "m=" line that contains the preferred address >>> first in the SDP group:BUNDLE attribute mid list. The Answerer >>> then selects the local bundle address for the Offerer ([ref-to-be-added]). >> >> I don't understand what the last sentence above is trying to tell me. > > The intention is to say that the Answerer selects the Offerer's bundle address. > > > -------------------------------------- > > >>> If the Offerer, in a subsequent SDP Offer, wants to re-negotiate >>> the bundle address associated with a BUNDLE group, it MAY assign the >>> previously negotiated bundle address as a unique address to one of >>> the "m=" lines in the BUNDLE group. >>> >>> If the Offerer assigns the bundle address to more than one "m=" >>> line in a BUNDLE group, the first mid value in the SDP group:BUNDLE >>> attribute mid value list MUST represent an "m=" line to which the >>> bundle address is assigned. Hence, in order to re-negotiate the >>> bundle address, the Offerer needs to assign a unique address to >>> each "m=" line in the BUNDLE group, as described above. >> >> I still object to this. It is a significant cost, and I don't understand how it adds any value over simply assigning a new address to all the bundled m-lines. > > The problem is not assigning a new address to all m- lines. > >>From a specification perspective, it becomes a little more tricky when you add a new bundle address to some m- lines, and unique addresses to others. > > Also, the Answerer will have check and figure out that the suggested new BUNDLE address has been assigned to multiple "m=" lines, and that it therefore cannot move it out of the BUNDLE group without rejecting it, etc. > > I guess one alternative could be to say that a suggested new BUNDLE address would have to be assigned to each "m=" line in the BUNDLE group. I.e. the Offerer would not be allowed to assign both a new BUNDLE address and unique addresses (e.g. for "m=" lines being added to the BUNDLE group). > > -------------------------------------- > > >>> 6.2.2. Bundle Address Synchronization (BAS) >>> >>> When an Offerer has sent an SDP Offer, a bundle address has been >>> selected by the Answerer, and the bundle address was in the SDP >>> Offer not assigned to each "m=" line in the BUNDLE group, the Offerer >>> MUST send a new SDP Offer, in which it assigns the negotiated bundle >>> address to each "m=" line in the BUNDLE group. This procedure is >>> referred to as Bundle Address Synchronization (BAS). >>> >>> The Offerer MUST NOT modify any parameters associated with the >>> BUNDLE group when it performs a BAS. >> >> I still don't understand the point of this restriction. >> What value does it add? >> >> Suppose that a need to make another change arises after the offer that >> proposed the bundle, but before the answer has been received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait? >> >> ISTM that it would be better to say that after receiving an answer, if >> there is at that moment no need to send another offer, if the corresponding offer had bundled m-lines with different addresses, then a BAS must be sent. > > The main reason for not allowing any parameter modifications in the BAS was to decrease the likelihood that the Answerer would reject the BAS (because it doesn't accept the suggested parameter changes). > > So, we can for sure allow parameter modifications in a BAS, but I think we need some text saying that an Offerer must perform a BAS until it is accepted. > > > -------------------------------------- > > >>> 6.2.4. Removing A Media Description From A BUNDLE Group >>> >>> When an Offerer removes an "m=" line from a BUNDLE group, the >>> Offerer MUST assign a unique address to the "m=" line that is removed. In >>> addition, the Offerer MUST NOT place the mid value that was >>> previously defined for the "m=" line in the SDP group:BUNDLE >>> attribute mid value list associated with the BUNDLE group. >> >> nit: I don't think this should say anything about the mid value that >> was previously defined for the m-line. That implies that mid values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required. >> If I want, I should be able to "relabel" the m-lines with new mid >> values. This reduces the amount of state that is required to be preserved from one o/a to the next. >> >> The statement "remove an m-line from a bundle group" already implies >> that the group does not contain a mid-value identifying that m-line >> (in >> *this* offer or answer). > > Maybe I could say that the mid value that was previously defined is no more valid, and must not be present in any Offer or Answer. > > > -------------------------------------- > > >>> 6.2.5. Rejecting A Media Description In A BUNDLE Group >>> >>> I agree with prior comment that using "Rejecting" here is weird and confusing. I agree that "disabling" is probably more appropriate. >>> But then "disabling a media description in a bundle group" is still a little confusing, because it is then no longer "in" the bundle group. >>> >>> It might be clearer to just incorporate this into the prior section on removing a media description from a bundle group. E.g., in 6.2.4: >>> >>> When an Offerer removes an "m=" line from a BUNDLE group, the Offerer >>> MUST assign either a unique address *or a zero port* to the "m=" line >>> that is removed. > > I at least intend to put back "disabling". I was also thinking about combining the sections, as you suggest, as the only difference is that the port value is set to zero in the reject/disable case. > >>> When an Offerer rejects an "m=" line in a BUNDLE group, the >>> Offerer MUST assign a unique address, with a zero port value >>> [RFC3264], to >> >> as long as the port is zero the address need not be otherwise unique. > > True. I guess your suggested text above ("unique address or a zero port") will fix that. > > As a side note, I intend to replace "unique address" and "bundle address" with "unique transport parameters" and "bundle transport parameters", as suggested by Martin. > > ...except in cases where the text actually talks about the IP address, that is :) > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From emil@sip-communicator.org Fri Jun 14 12:02:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42521F9D1E for ; Fri, 14 Jun 2013 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaeRK-+ylJWf for ; Fri, 14 Jun 2013 12:02:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 791F321F9D2B for ; Fri, 14 Jun 2013 12:02:14 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so606201wid.4 for ; Fri, 14 Jun 2013 12:02:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=6Bd61IbfpQVOIoIW+QunHT7qDNpsn7XyYwSrW2saxto=; b=pOWBlOf33K3dHVLb77Al1t68Hez4Rnn61O7/mXV4B/EVGqM7fkVrj3E4r0LthJav54 uQEzgGk3az963nT1K9ED2ys75Ux7ekw6TeBHzO1kaho+Z8Zs/7EzNktH9d6EPNRrE1HU NKMnV3lRGgK2dKCbWpYGu+6wwnv+rgd/tkraVPfkieK1RLpWHeEZcfzXi+49COeKd3mQ eeIWv78oOzpcJ9W8HhAv1PYCQvW3A2mL6xO5ES5rCcQfwyZ48EKap0MDh/ULb7d4vnqH +sGue/v3LkDWSwR/HKaEBkE8kOU5RU+qfmPac9o91pMgGqo7a4419wPl0bfg8Myy2Qsi 06fA== X-Received: by 10.194.158.130 with SMTP id wu2mr2286028wjb.12.1371236533492; Fri, 14 Jun 2013 12:02:13 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:e430:a96d:e634:6a80]) by mx.google.com with ESMTPSA id r9sm5251056wik.1.2013.06.14.12.02.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 12:02:12 -0700 (PDT) Message-ID: <51BB68B2.3060104@jitsi.org> Date: Fri, 14 Jun 2013 21:02:10 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?windows-1252?Q?Ari_Ker=E4nen?= References: <51BB5EFE.5090903@ericsson.com> In-Reply-To: <51BB5EFE.5090903@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkfm8/eb9NBt08IUqwOjP2BS46VMqTnw3c1M1WbzMMvT8Jfv5wkVs7uMRhjRwbEIQPA4zag Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:02:42 -0000 On 14.06.13, 20:20, Ari Ker=E4nen wrote: > Hi all, > > Given the guidance from the RTCWEB WG chairs that the "no-plan" > discussion should essentially happen at the RTCWEB WG, the MMUSIC > interim meeting on June 17th will be focused on Plan A and Plan B. I assume this implies that MMUSIC considers it entirely appropriate to=20 use SDP for signalling multiple streams the way No Plan suggests (i.e.=20 one m=3D line can carry as many RTP flows as it likes). So much so, that = no further discussion is necessary on the subject. Could you please confirm that I am reading this properly? Emil --=20 https://jitsi.org From prvs=4877294406=ari.keranen@ericsson.com Fri Jun 14 12:10:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F8521F901F for ; Fri, 14 Jun 2013 12:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.341 X-Spam-Level: X-Spam-Status: No, score=-5.341 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dtDUTdTJzzo for ; Fri, 14 Jun 2013 12:10:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4550421F8CB4 for ; Fri, 14 Jun 2013 12:10:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-9e-51bb6a89f01e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E8.D9.15700.98A6BB15; Fri, 14 Jun 2013 21:10:01 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Jun 2013 21:10:01 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5CF792AB5; Fri, 14 Jun 2013 22:10:01 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1C89B55287; Fri, 14 Jun 2013 22:09:59 +0300 (EEST) Received: from as-macbook-air.elisa (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A2DD055280; Fri, 14 Jun 2013 22:09:58 +0300 (EEST) Message-ID: <51BB6A8C.6090400@ericsson.com> Date: Fri, 14 Jun 2013 22:10:04 +0300 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> In-Reply-To: <51BB68B2.3060104@jitsi.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvrW5n1u5Ag+tLjS3W7JzAYvH+gq7F 1OWPWRyYPab83sjqsWTJTyaP/28CA5ijuG2SEkvKgjPT8/TtErgzrt6Zylawhq3i2737LA2M f1m6GDk5JARMJDafeMoOYYtJXLi3nq2LkYtDSOAUo8SzO0uZIJwNjBLLvq9lh3B2M0r0TLoN VbYOyJnXyALhrGCU2PG3hRlkGK+AtkTD/qlsIDaLgKrEjh9rweJsAo4Stx++ZAWxRQWSJQ70 t7NC1AtKnJz5BOwoEQF5ie62RUwgNrOAq8SqXbPBeoUFHCSaGn6AxYUEPCSazl4GszkFNCVu /50NtIsDqN5e4sHWMohWeYnmrRCtEgJqElfPbWKGaFWVuPrvFeMERtFZSDbPQuiehaR7ASPz Kkb23MTMnPRyw02MwEg4uOW37g7GU+dEDjFKc7AoifN+OLUrUEggPbEkNTs1tSC1KL6oNCe1 +BAjEwcniOCSamAMY4nOvHlV4OLTwxV1L8xmHZh6+6yuXNjs/rch6Z/fnHhtPrfSLGROr2RX I3N0YoseS3ztVmH3+SFhlZLih8KEWFVYf6zjnjdF+8TZL0ILRD44lXxadqprY56ZlbJE+aq/ tUdaHjaoyGqEJWjWpEhcVorek39OakaY5SEdn0lvVXh1MyUEmJVYijMSDbWYi4oTAdKdJpNX AgAA Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:10:10 -0000 On 6/14/13 10:02 PM, Emil Ivov wrote: > On 14.06.13, 20:20, Ari Keränen wrote: >> Hi all, >> >> Given the guidance from the RTCWEB WG chairs that the "no-plan" >> discussion should essentially happen at the RTCWEB WG, the MMUSIC >> interim meeting on June 17th will be focused on Plan A and Plan B. > > I assume this implies that MMUSIC considers it entirely appropriate to > use SDP for signalling multiple streams the way No Plan suggests (i.e. > one m= line can carry as many RTP flows as it likes). So much so, that > no further discussion is necessary on the subject. > > Could you please confirm that I am reading this properly? This means that the interim time should be used mainly to discuss plan A vs plan B merits, not whether RTCWEB should use A/B, or no-plan. Cheers, Ari From emil@sip-communicator.org Fri Jun 14 12:33:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63A821F9936 for ; Fri, 14 Jun 2013 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1fyvlXpz9AV for ; Fri, 14 Jun 2013 12:33:42 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64321F9930 for ; Fri, 14 Jun 2013 12:33:41 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so681427wid.3 for ; Fri, 14 Jun 2013 12:33:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ORgXbHE3GlKOal7i1lQfRmRzW3BTdrgY9uxPMgAh5Y8=; b=FJFcHJTrG9F21ke5nmWwV3Hzi2KBw3PsD99Op4UNpwNLZ9dYR3Z5qi9WLFv97A8ofj 4E02zdYeCCKClE1XYUFS2Kk6U/IA+R5xY1XaBVuDlTIMSbNZ3HS8rQOKLXdwvDhlU0GQ chn0POZQboMxb9+YaY82kCHdwq964FQ9//eSKVidQsxfWA92djqy34LUM2mqjoki1vah ubu9qlSQgZALmec+FA8Ec1G8eGHtD6WiZR9N3+V2UaJhFzr9I4L0cdzcBCFpm3rz1u58 G3YhQG2TGI7fsrzeyWM3lRNTcHcz3tiDNMp5EXH87djGHeXSWXLdldrGiVMK5VXaHhBl e2tA== X-Received: by 10.194.158.69 with SMTP id ws5mr2328827wjb.84.1371238421088; Fri, 14 Jun 2013 12:33:41 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id ay7sm5390239wib.9.2013.06.14.12.33.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 12:33:39 -0700 (PDT) Message-ID: <51BB7012.10208@jitsi.org> Date: Fri, 14 Jun 2013 21:33:38 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?windows-1252?Q?Ari_Ker=E4nen?= References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> In-Reply-To: <51BB6A8C.6090400@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQni7S0k9htC7ODcxeurkS0+IlM+blxDVDmBkpxNrLPNDkHS78/5Kl8K5KsImuqT1OT/yFWl Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:33:43 -0000 On 14.06.13, 21:10, Ari Ker=E4nen wrote: > On 6/14/13 10:02 PM, Emil Ivov wrote: >> On 14.06.13, 20:20, Ari Ker=E4nen wrote: >>> Hi all, >>> >>> Given the guidance from the RTCWEB WG chairs that the "no-plan" >>> discussion should essentially happen at the RTCWEB WG, the MMUSIC >>> interim meeting on June 17th will be focused on Plan A and Plan B. >> >> I assume this implies that MMUSIC considers it entirely appropriate to= >> use SDP for signalling multiple streams the way No Plan suggests (i.e.= >> one m=3D line can carry as many RTP flows as it likes). So much so, th= at >> no further discussion is necessary on the subject. >> >> Could you please confirm that I am reading this properly? > > This means that the interim time should be used mainly to discuss plan = A > vs plan B merits, not whether RTCWEB should use A/B, or no-plan. Sure. I get this and I find it very reasonable. However, just as Plans A and B, No Plan says: here's an SDP that you can = use when doing multiple streams. So, I just want to confirm that we will not be discussing the SDP sides=20 of the proposal in No Plan because they make perfect sense from an=20 MMUSIC point of view and no discussion is really necessary. It'll be up=20 to other working groups to decide whether they'd like to use that=20 particular (and valid) approach. Emil --=20 https://jitsi.org From mary.ietf.barnes@gmail.com Fri Jun 14 12:51:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0821F9D17 for ; Fri, 14 Jun 2013 12:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.074 X-Spam-Level: X-Spam-Status: No, score=-103.074 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6EFvA4xYexT for ; Fri, 14 Jun 2013 12:51:39 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7D21F9D19 for ; Fri, 14 Jun 2013 12:51:37 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so568234qea.7 for ; Fri, 14 Jun 2013 12:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Yw6vEZvV9GRZDZI5+hYMqtF+RwhpnZ9Ji47etUz4XwU=; b=D/30sVBvh9UX2LwI3+g2rETumKD8M2NA2Cww8ff0tsDuqhmhTdV35XeXxXauTruJrW kKomj+QHeFJAGG3jwnXSeCdjS3/0QYHiQhVTGoM7FTM4oW7+M6+rxQLOr5BgRwZV00my uRCrjRM4WyE8FpJRzP4kj+Nho+Qbl8mmEXJS77TUvmk9lNnspr6XaQRW6SmnrqZ64Kh7 p0Zk9nDn/URiC0h5wvcxlW+vqPD4zgdToVmD4watCxRrYlfhOUUF9owHstNEzrv4e14v c3KWhthZLWviLcU8lNebnkYYLPjtZ0sNoCrSYpbdB0cGh3pvQKYLVoaU6tE8HKBauojv yjmQ== MIME-Version: 1.0 X-Received: by 10.49.0.145 with SMTP id 17mr4614032qee.26.1371239497481; Fri, 14 Jun 2013 12:51:37 -0700 (PDT) Received: by 10.49.117.130 with HTTP; Fri, 14 Jun 2013 12:51:37 -0700 (PDT) In-Reply-To: <51BB6A8C.6090400@ericsson.com> References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> Date: Fri, 14 Jun 2013 14:51:37 -0500 Message-ID: From: Mary Barnes To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:51:43 -0000 On Fri, Jun 14, 2013 at 2:10 PM, Ari Ker=E4nen w= rote: > On 6/14/13 10:02 PM, Emil Ivov wrote: >> >> On 14.06.13, 20:20, Ari Ker=E4nen wrote: >>> >>> Hi all, >>> >>> Given the guidance from the RTCWEB WG chairs that the "no-plan" >>> discussion should essentially happen at the RTCWEB WG, the MMUSIC >>> interim meeting on June 17th will be focused on Plan A and Plan B. >> >> >> I assume this implies that MMUSIC considers it entirely appropriate to >> use SDP for signalling multiple streams the way No Plan suggests (i.e. >> one m=3D line can carry as many RTP flows as it likes). So much so, that >> no further discussion is necessary on the subject. >> >> Could you please confirm that I am reading this properly? > > > This means that the interim time should be used mainly to discuss plan A = vs > plan B merits, not whether RTCWEB should use A/B, or no-plan. [MB] So what happens if RTCWEB decides that they prefer "no-plan"? In that case, MMUSIC will have wasted their time deciding A versus B since there aren't hard requirements from other potential users of this SDP based multi-stream signaling mechanism. CLUE isn't quite there yet. Now, it's possible either A or B would be okay, but that's not a given right now. I certainly understand the frustration of the chairs in trying to manage this work since a lot of relevant discussion has been on the RTCWEB WG mailing list. And, I do certainly agree that you all do have a milestone for this work, I just think this meeting is premature until there is indeed consensus in the RTCWEB WG that no plan is off the table and the CLUE WG is a point that it's clear how A versus B fit into their solution and whether possibly a plan C might be more optimal. [/MB] > > > Cheers, > Ari > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Fri Jun 14 13:00:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED0A21F9BA5 for ; Fri, 14 Jun 2013 13:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfdAy0PqNz8F for ; Fri, 14 Jun 2013 13:00:47 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2821F9C95 for ; Fri, 14 Jun 2013 13:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2253; q=dns/txt; s=iport; t=1371240047; x=1372449647; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LFjtJa1aMGSOB//WOJlupt3/nOINmsKnOnpYvbTUyYc=; b=fHRzRFpkZ29ntvHFQugrYyMJBBhN8TgIkFzoIMnJtmV48WAJixokrCVc +QYrjaTVxiTUjkL+/BCTy34UsfyadZSuHD0vli6kdZAN8sHpUDKKzYHWa bCqRK3JItJA+11xmE0xepqePIZYb6fpfOzukH7mNg5RZHzsapyk6li9gX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIHAB12u1GtJXG9/2dsb2JhbABbgwkwqxuTc4EKFnSCIwEBAQQyAQVAARALDgoJFg8JAwIBAgFFBg0BBwEBBYgFDLlwjhaBMgeDYAOXQZFCgysggTU X-IronPort-AV: E=Sophos;i="4.87,868,1363132800"; d="scan'208";a="223030394" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jun 2013 20:00:46 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5EK0jAQ017991; Fri, 14 Jun 2013 20:00:45 GMT Message-ID: <51BB766D.2030301@cisco.com> Date: Fri, 14 Jun 2013 16:00:45 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> <51BB7012.10208@jitsi.org> In-Reply-To: <51BB7012.10208@jitsi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: =?windows-1252?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:00:52 -0000 Hi Emil Per some of the previous discussion threads (see e.g. http://www.ietf.org/mail-archive/web/mmusic/current/msg11019.html), there is clearly some ambiguity around exactly what an m-line conveys, both with and without bundle. This lack of clarity potentially affects all of the different plan proposals as well as as 4566bis, and as such is an entirely reasonable discussion to have in MMUSIC. To the extent that resolution of this impacts progress on the Plan A versus Plan B discussion, it is also an appropropriate discussion to have next week. What is not appropriate at this time however is to turn that into a discussion of choosing "no plan" for RTCWeb since MMUSIC cannot (and should not) make that decision (as clarified by the RTCWeb chairs as well). Thanks -- Flemming On 6/14/13 3:33 PM, Emil Ivov wrote: > > > On 14.06.13, 21:10, Ari Keränen wrote: >> On 6/14/13 10:02 PM, Emil Ivov wrote: >>> On 14.06.13, 20:20, Ari Keränen wrote: >>>> Hi all, >>>> >>>> Given the guidance from the RTCWEB WG chairs that the "no-plan" >>>> discussion should essentially happen at the RTCWEB WG, the MMUSIC >>>> interim meeting on June 17th will be focused on Plan A and Plan B. >>> >>> I assume this implies that MMUSIC considers it entirely appropriate to >>> use SDP for signalling multiple streams the way No Plan suggests (i.e. >>> one m= line can carry as many RTP flows as it likes). So much so, that >>> no further discussion is necessary on the subject. >>> >>> Could you please confirm that I am reading this properly? >> >> This means that the interim time should be used mainly to discuss plan A >> vs plan B merits, not whether RTCWEB should use A/B, or no-plan. > > Sure. I get this and I find it very reasonable. > > However, just as Plans A and B, No Plan says: here's an SDP that you > can use when doing multiple streams. > > So, I just want to confirm that we will not be discussing the SDP > sides of the proposal in No Plan because they make perfect sense from > an MMUSIC point of view and no discussion is really necessary. It'll > be up to other working groups to decide whether they'd like to use > that particular (and valid) approach. > > Emil > > From fandreas@cisco.com Fri Jun 14 13:08:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA92821F9A59 for ; Fri, 14 Jun 2013 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhtQXLfNZmJC for ; Fri, 14 Jun 2013 13:07:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB8921F8437 for ; Fri, 14 Jun 2013 13:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2453; q=dns/txt; s=iport; t=1371240476; x=1372450076; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3K+z+kGln3fzwHhCxb6Bf8AuDhvX5PrR0v+GUs0uOV4=; b=bn3cQnJrTl+iWD2KEMbGG1LShzRAP7hRp4Ne6/llZB9xF2QKHaHhmXs1 zaFcpsrhcOnVr444huPYFeMeOza8EoSxTCLroh4SssiDKpDyExjtfIcZJ eDZ31ua30N/xc3+83NNKaiNBkBxT6jYDqWRokNWVJ2IGDiGrPwZkq7nVx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANJ2u1GtJV2Z/2dsb2JhbABbgwkwvw6BChZ0giMBAQEDAQEBAS8BBTAGCgEFCwsYCRYPCQMCAQIBFTAGDQEFAgEBF4dtBgy5cASOEAaBMgeDYAOXQZFCgysggSwJFw X-IronPort-AV: E=Sophos;i="4.87,868,1363132800"; d="scan'208";a="220035624" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jun 2013 20:07:55 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5EK7s9l013113; Fri, 14 Jun 2013 20:07:55 GMT Message-ID: <51BB781A.6020608@cisco.com> Date: Fri, 14 Jun 2013 16:07:54 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mary Barnes References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:08:00 -0000 On 6/14/13 3:51 PM, Mary Barnes wrote: > On Fri, Jun 14, 2013 at 2:10 PM, Ari Keränen wrote: >> On 6/14/13 10:02 PM, Emil Ivov wrote: >>> On 14.06.13, 20:20, Ari Keränen wrote: >>>> Hi all, >>>> >>>> Given the guidance from the RTCWEB WG chairs that the "no-plan" >>>> discussion should essentially happen at the RTCWEB WG, the MMUSIC >>>> interim meeting on June 17th will be focused on Plan A and Plan B. >>> >>> I assume this implies that MMUSIC considers it entirely appropriate to >>> use SDP for signalling multiple streams the way No Plan suggests (i.e. >>> one m= line can carry as many RTP flows as it likes). So much so, that >>> no further discussion is necessary on the subject. >>> >>> Could you please confirm that I am reading this properly? >> >> This means that the interim time should be used mainly to discuss plan A vs >> plan B merits, not whether RTCWEB should use A/B, or no-plan. > [MB] So what happens if RTCWEB decides that they prefer "no-plan"? In > that case, MMUSIC will have wasted their time deciding A versus B > since there aren't hard requirements from other potential users of > this SDP based multi-stream signaling mechanism. We are knee-deep in here already, so an extra 3 hour conference call seems like a small price to pay for potentially making progress (and at the very least get more clarity on the Plan A and Plan B proposals based on "higher than e-mail bandwidth" presentation and discussion) > CLUE isn't quite > there yet. Now, it's possible either A or B would be okay, but that's > not a given right now. > > I certainly understand the frustration of the chairs in trying to > manage this work since a lot of relevant discussion has been on the > RTCWEB WG mailing list. And, I do certainly agree that you all do > have a milestone for this work, I just think this meeting is premature > until there is indeed consensus in the RTCWEB WG that no plan is off > the table and the CLUE WG is a point that it's clear how A versus B > fit into their solution and whether possibly a plan C might be more > optimal. [/MB] The downside seems limited, and we know there is a lot of interest in trying to make progress. Thanks -- Flemming >> >> Cheers, >> Ari >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > . > From ted.ietf@gmail.com Fri Jun 14 13:24:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9CB21E8087 for ; Fri, 14 Jun 2013 13:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3heiGKefgDhP for ; Fri, 14 Jun 2013 13:24:11 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A8AFC11E80DC for ; Fri, 14 Jun 2013 13:24:09 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so2399911iej.1 for ; Fri, 14 Jun 2013 13:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LgtjrVMmk9ch4Gsc1p53jiNgyJdrHeQHuaNnMi5toKc=; b=eCKcr7gG+tEW/J75n/TZs6k9pMXfsFT5noaY0olBpCWrafscZLydN3EEUcnBUPuOQz hiSfyKJMbL1nWThMwr6Mz+diAz08D3v15EW+kl4oblB/cCEwLHBFs0QENJ+zqAK+HZQ5 kYyVXqnATV76ZIJyp+QoQkYSmHFzu+gmrYKDYZ8HMkTPO7K3d8dAWnNdso7ShiR3nchf WyQHI1w0slmMlN5EATso/om5nPn5iv/uyAVdJO+IN1MCVgekVVTcCVGBJX8xcXpPKDuR 29Wqj6OqNxwqCKs2Y/cB+17D9ebDdsEIy0cXNjy+rTeJvygcnJM6xoVGQoJjZw6GZrau +o9g== MIME-Version: 1.0 X-Received: by 10.50.60.3 with SMTP id d3mr1984869igr.24.1371241449340; Fri, 14 Jun 2013 13:24:09 -0700 (PDT) Received: by 10.42.49.7 with HTTP; Fri, 14 Jun 2013 13:24:09 -0700 (PDT) In-Reply-To: References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> Date: Fri, 14 Jun 2013 13:24:09 -0700 Message-ID: From: Ted Hardie To: Mary Barnes Content-Type: multipart/alternative; boundary=047d7b10cbfb7d472f04df2307d9 Cc: Flemming Andreasen , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:24:12 -0000 --047d7b10cbfb7d472f04df2307d9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 14, 2013 at 12:51 PM, Mary Barnes wrote: > O > [MB] So what happens if RTCWEB decides that they prefer "no-plan"? In > that case, MMUSIC will have wasted their time deciding A versus B > since there aren't hard requirements from other potential users of > this SDP based multi-stream signaling mechanism. > > So, RTCWEB has made a request to MMUSIC and the choice of plan A or plan B is part of the effort to resolve that request. RTCWEB has not withdrawn that request. It is always possible that work coming into one IETF working group from another may be overcome by events, but that's not our current state. Please, let's move forward with the effort to resolve this, rather than borrowing trouble. thanks, Ted --047d7b10cbfb7d472f04df2307d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 14, 2013 at 12:51 PM, Mary Barnes <mary.ietf.barnes@g= mail.com> wrote:
O
[MB] So what happens if RTCWEB decides that they prefer "no-plan= "? =A0In
that case, MMUSIC will have wasted their time deciding A versus B
since there aren't hard requirements from other potential users of
this SDP based multi-stream signaling mechanism.=A0


So, RTCWEB has made a request to MMUSIC and the c= hoice of plan A or plan B is part of the effort to resolve that request.=A0= RTCWEB has not withdrawn that request.=A0 It is always possible that work = coming into one IETF working group from another may be overcome by events, = but that's not our current state.

Please, let's move forward with the effort to resolve this, rather = than borrowing trouble.

thanks,

Ted
=A0
--047d7b10cbfb7d472f04df2307d9-- From prvs=5877648596=christer.holmberg@ericsson.com Fri Jun 14 13:45:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2011E80AE for ; Fri, 14 Jun 2013 13:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.237 X-Spam-Level: X-Spam-Status: No, score=-4.237 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kcS5IKt+ALT for ; Fri, 14 Jun 2013 13:45:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 34E0F11E80D5 for ; Fri, 14 Jun 2013 13:45:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-cd-51bb80e971e4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5C.4E.09795.9E08BB15; Fri, 14 Jun 2013 22:45:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 22:45:29 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AA24L0AABt8NdAAF/qngAAH50mw Date: Fri, 14 Jun 2013 20:45:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38AF86@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> <51BB622F.60007@alum.mit.edu> In-Reply-To: <51BB622F.60007@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6rht2BBl8Ws1tMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xsUVJ9gKlvUzVqz8ktbAeCO/i5GTQ0LA ROL+9c+MELaYxIV769m6GLk4hAQOM0qsPPCVEcJZwiixreUecxcjBwebgIVE9z9tEFNEQENi 0lY1EJNZQF3i6uIgkDHCAo4S954/ABspIuAk8fHcViYI203iy9fZbCA2i4CqxIPXb1lAbF4B X4kNb++wQmy6zCjR3XqdFSTBKaAlcez4PbAiRqDbvp9aAzaIWUBc4sPB68wQNwtILNlzHsoW lXj5+B8rhK0k0bjkCStEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywk LQsYWVYxsucmZuakl5tvYgTGyMEtvw12MG66L3aIUZqDRUmc99OpXYFCAumJJanZqakFqUXx RaU5qcWHGJk4OEEEl1QDo8hsSw61Z0Xcv+Lc16472Sm+clnRtY6w+ETR7bssz5Xpui83dGnO SFzrdOEo7yG36T8X7WxKY8zI2bDqbl5dzLwlSepsrbOzXu3bqeny894FqTOlPGo65qaGEx+d K3/EF1D6P/KYIbMQ+44XseauN2ysM+9EBpyZqPNlzdLtV1VWahzwv5X2QomlOCPRUIu5qDgR AKD8sAxkAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 20:45:41 -0000 Hi, >>>> 6.1. General >>>> >>>> This section describes the usage of the SDP Offer/Answer mechanis= m >>>> [RFC3264] to negotiate the usage of the BUNDLE mechanism, to >>>> negotiate the bundle address, and to add, remove and reject SDP >>>> Media Descriptions ("m=3D" lines) associated with a BUNDLE group. >>>> >>>> The generic rules and procedures defined in [RFC3264] and >>>> [RFC5888]apply when the SDP Offer/Answer mechanism is used for BU= NDLE. For >>>> example, if an SDP Offer is rejected, the previously negotiated = SDP >>>> parameters and characteristics (including those associated with B= UNDLE groups) apply. >>>> >>>> When an endpoint generates an SDP Offer, or an SDP Answer, which >>>> contains a BUNDLE group, the endpoint MUST assign SDP media-level >>>> mid value for each "m=3D" line in the BUNDLE group. In addition,= the >>>> endpoint MUST insert an SDP session-level group:BUNDLE attribute, >>>> and place each mid value associated with the BUNDLE group in the >>>> attribute mid value list. >>>> >>>> Until the Offerer knows whether the Answerer supports the BUNDLE >>>> mechanism, the Offerer MUST, for each "m=3D" line in a BUNDLE gro= up: >>> >>> Under what circumstances may the offerer presume to *know* whether the = answerer supports BUNDLE? >>> >>> The minimal answer is that if an offer included a bundle group, and=20 >>> the answer also contains a corresponding bundle group, then the answere= r supported *that* bundle at the time of *that* answer, and continues to do= so at least until there is another offer. >> >> Yes. >> >> I was actually thinking about removing the "until the Offerer knows" tex= t, and simply generally say that the bundle address is negotiated by assign= ing a unique address to each "m=3D" line. >> >> But, as you want to be able to assign a bundle address to multiple "m=3D= " lines before it has been negotiated, it would not work. >> >>> But we want to assume more - at least that if *a* bundle was=20 >>> supported by both sides in one O/A exchange, then both sides can be=20 >>> presumed to >>> *understand* bundle, including the use of the same address info for mul= tiple m-lines in a bundle offer, in future offers within the same signaling= session. >> >> I would rather say SDP session, to keep it independent from the signalin= g protocol. That is the same as for any other parameter you negotiate using= SDP O/A - it's valid until re-negotiated. > > Sure, I think "SDP session" will work. > >>> Is, or should there be, a way to go back on that presumption - to=20 >>> stop supporting bundle? I guess if an end wanted to stop supporting=20 >>> bundle while a bundle was in effect it would need to send an offer that= didn't include any bundles. But it might want to send such an offer just b= ecause it doesn't currently need a bundle though it still supports them. >> >> Sure, but if anyone then wants to start using BUNDLE again, it will send= an Offer and suggest the usage. > > My point was that if support for bundle can be presumed, then it no longe= r is necessary to offer unique address info for each m-line when adding to = bundles or proposing new bundles. Ok, I hear you. Yes, IF we allow that it is important that it is clear when= one can assume that the Answerer supports BUNDLE. > In particular, this becomes significant for the bundle splitting case: > > 1) X sends offer to Y proposing a bundle, uses unique address info > 2) Y sends answer to x accepting the bundle, > but rejecting some of the m-lines in it > 3) X sends a BAS to Y to finalize the initial bundle. > 4) Y sends answer to X accepting the BAS > 5) Y sends offer to X keeping the existing bundle, > and proposing a new bundle for the previously rejected > m-lines. Because it knows X supports bundle, and it knows > that X was willing to have the m-lines in question bundled, > this offer is in the form of a BAS, with all the m-lines > in the new bundle having common address info. > 6) X sends answer to Y, presumably accepting both bundles. > > In this case it is quite wasteful if Y has to provide separate address in= fo for each of the m-lines in the new bundle, and then yet another BAS has = to be exchanged to fix that up. > > Of course being able to presume support also is useful in cases where no = bundle splitting is needed. E.g., Y was able to accept the initial bundle f= rom X in full. Then later=20 > it wanted to offer an additional separate bundle. And it could also cover= the case where an initial O/A is done when no bundle is yet needed, but *s= upport* for bundle is=20 > negotiated. Then later, when a bundle is needed, it may be offered in BAS= form, so only a single O/A is required. > > The above also points out another issue: (3) & (4) are quite a waste. It = would be nice to be able to avoid them in this case. One way to achieve tha= t would be to put the burden > on the answerer that accepts a bundle where the address info is not all t= he same to send the BAS. In this case that would mean that (5) would also s= erve as a substitute for (3), and > (6) would then substitute for (4). I understand what you're saying, and I'll dig more into it once I get -04 s= ubmitted :)=20 I have added it as an Open Issue in -04, though. >> Perhaps we should say that an offerer or answerer who supports bundle=20 >> should *always* include an a=3Dgroup:bundle in its offers and answers. I= f it doesn't currently want a bundle it can simply include "a=3Dgroup:bundl= e" without any mid values. > > Or, we could leave it up to the signaling protocol. For SIP, one could de= fine a media feature tag. That would also allow SIP entities to request tha= t INVITEs are sent to entities to support BUNDLE (and have indicated so dur= ing registration). Yes, we could. I don't have a strong preference one way or the other. -------------------------------------- >>>> 6.2.1. SDP Offerer Bundle Address Request and Usage >>>> >>>> An Offerer can assign an address to multiple "m=3D" lines in a >>>> BUNDLE group, once the address has been selected as the Offerer's= local >>>> bundle address. An Offerer MUST NOT assign an address to multipl= e >>>> "m=3D" lines until the address has been selected as a bundle addr= ess >>>> for that BUNDLE group. >>>> >>>> In order to negotiate (or, to re-negotiate) the bundle address >>>> associated with a BUNDLE group, the Offerer, in the SDP Offer, >>>> assigns a unique address to each "m=3D" line in the BUNDLE group. >>>> In addition, the Offerer indicates which unique address it wishes= to >>>> use as its local bundle address. There Offerer places the mid va= lue, >>>> associated with the "m=3D" line that contains the preferred addre= ss >>>> first in the SDP group:BUNDLE attribute mid list. The Answerer >>>> then selects the local bundle address for the Offerer ([ref-to-be= -added]). >>> >>> I don't understand what the last sentence above is trying to tell me. >> >> The intention is to say that the Answerer selects the Offerer's bundle a= ddress. > > I'm still having trouble making sense of this. Let me break out some thin= gs to try and understand. (I'm trying to state what I think you mean, not a= s it ought to be written in a draft, just for maximal clarity.) > > It is the *answer* that selects the m-line that defines the bundle addres= ses for both offerer and answerer. Until then it isn't known. Correct.=20 > Only after the bundle addresses are known may an offer be sent that has a= common address for multiple m-lines in the bundle, and if so it must be th= e one that was previously defined as the bundle address. Correct. > As a consequence, on the initial offer that proposes a bundle, every m-li= ne must have unique address info. Correct. > When sending an subsequent offer, after a bundle has previously been defi= ned, (so the bundle addresses are known), multiple m-lines in that bundle *= may* be offered with the same address info, but that address info must be t= he previously agreed bundle address. Correct. > As a consequence, to *change* a previously agreed bundle address, an offe= r must be sent where every m-line in the bundle has unique address info. Correct.=20 > Does that accurately restate what you meant above? Yes. > (If so, you know that I don't agree - I find it much more prescriptive th= an it needs to be, with negative consequences. But lets be certain we agree= what you are intending to say first.) It seems we have a common understanding of what is currently specified :) And, even with your suggestion, the answerer would still select the bundle = addresses for both the offerer and the answerer. But, there might of course not be too many addresses to choose from in the offer (e.g. if each m- lin= e in the offer has the suggested new bundle address). Also, even with your suggestion I guess that at least the initial offer wou= ld need to have unique addresses for each m- line, as it is yet not known whether BUNDLE is supported within that particular SDP session. -------------------------------------- >>>> If the Offerer, in a subsequent SDP Offer, wants to re-negotiate >>>> the bundle address associated with a BUNDLE group, it MAY assign = the >>>> previously negotiated bundle address as a unique address to one o= f >>>> the "m=3D" lines in the BUNDLE group. >>>> >>>> If the Offerer assigns the bundle address to more than one "m=3D" >>>> line in a BUNDLE group, the first mid value in the SDP group:BUND= LE >>>> attribute mid value list MUST represent an "m=3D" line to which t= he >>>> bundle address is assigned. Hence, in order to re-negotiate the >>>> bundle address, the Offerer needs to assign a unique address to >>>> each "m=3D" line in the BUNDLE group, as described above. >>> >>> I still object to this. It is a significant cost, and I don't understan= d how it adds any value over simply assigning a new address to all the bund= led m-lines. >> >> The problem is not assigning a new address to all m- lines. > > Then what is the problem? > >>>From a specification perspective, it becomes a little more tricky when y= ou add a new bundle address to some m- lines, and unique addresses to other= s. >> >> Also, the Answerer will have check and figure out that the suggested new= BUNDLE address has been assigned to multiple "m=3D" lines, and that it >> therefore cannot move it out of the BUNDLE group without rejecting it, e= tc. > > > Yes. That doesn't seem to be any great burden. > >> I guess one alternative could be to say that a suggested new BUNDLE addr= ess would have to be assigned to each "m=3D" line in the BUNDLE group. I.e.= the Offerer >> would not be allowed to assign both a new BUNDLE address and unique addr= esses (e.g. for "m=3D" lines being added to the BUNDLE group). >> >> Even that seems over prescriptive. > > ISTM that the problem is being driven by what is easy to describe, rather= than what is useful to do, even though the actual implementation effort wo= uld probably be the same or even less difficult. > > While I do agree that clarity of explanation is important, that tells me = we need to continue to work to find a clear way to express constraints with= out being over restrictive. > > I previously tried - offering a set of constraints on offers and answers = that I thought covered the cases. I still think that could work. Ok, once I've submitted -04, I'll continue to work on text for that, while = allowing people to review the rest of the procedures. -------------------------------------- >>>> 6.2.2. Bundle Address Synchronization (BAS) >>>> >>>> When an Offerer has sent an SDP Offer, a bundle address has been >>>> selected by the Answerer, and the bundle address was in the SDP >>>> Offer not assigned to each "m=3D" line in the BUNDLE group, the O= fferer >>>> MUST send a new SDP Offer, in which it assigns the negotiated bun= dle >>>> address to each "m=3D" line in the BUNDLE group. This procedure = is >>>> referred to as Bundle Address Synchronization (BAS). >>>> >>>> The Offerer MUST NOT modify any parameters associated with the >>>> BUNDLE group when it performs a BAS. >>> >>> I still don't understand the point of this restriction. >>> What value does it add? >>> >>> Suppose that a need to make another change arises after the offer=20 >>> that proposed the bundle, but before the answer has been received. Then= , when the answer is received it will be necessary to send a BAS before sen= ding another offer to make the new change. Why wait? >>> >>> ISTM that it would be better to say that after receiving an answer,=20 >>> if there is at that moment no need to send another offer, if the corres= ponding offer had bundled m-lines with different addresses, then a BAS must= be sent. >> >> The main reason for not allowing any parameter modifications in the BAS = was to decrease the likelihood that the Answerer would reject the BAS (beca= use it doesn't accept the suggested parameter changes). > > You mean in the sense that the entire offer would be rejected at the sign= aling level - e.g., a sip 488? Yes. > The trouble is that this also disallows reasonable and non-risky changes,= such as dropping an m-line, or reducing the set of codecs offered to a sub= set of what had been agreed. True. >> So, we can for sure allow parameter modifications in a BAS, but I think = we need some text saying that an Offerer must perform a BAS until it is acc= epted. > > Sure, that would be ok. And there could be a note that the offerer should= try to construct the BAS to minimize the possibility that it will be rejec= ted. In the draft that I intend to submit soon I have removed the restriction, b= ut I'll try to add a note before submitting. -------------------------------------- >>>> 6.2.4. Removing A Media Description From A BUNDLE Group >>>> >>>> When an Offerer removes an "m=3D" line from a BUNDLE group, the >>>> Offerer MUST assign a unique address to the "m=3D" line that is r= emoved. In >>>> addition, the Offerer MUST NOT place the mid value that was >>>> previously defined for the "m=3D" line in the SDP group:BUNDLE >>>> attribute mid value list associated with the BUNDLE group. >>> >>> nit: I don't think this should say anything about the mid value that=20 >>> was previously defined for the m-line. That implies that mid values mus= t be preserved from one o/a to another. While they probably will in most ca= ses I don't think that should be required. >>> If I want, I should be able to "relabel" the m-lines with new mid=20 >>> values. This reduces the amount of state that is required to be preserv= ed from one o/a to the next. >>> >>> The statement "remove an m-line from a bundle group" already implies=20 >>> that the group does not contain a mid-value identifying that m-line=20 >>> (in >>> *this* offer or answer). >> >> Maybe I could say that the mid value that was previously defined is no m= ore valid, and must not be present in any Offer or Answer. > > The mid values from the previous o/a have *no* relevance to the new o/a. > It is *possible* (though not likely) that some of the same values may be = used in the new offer to identify *different* m-lines. So saying that a val= ue from a previous o/a must not be present is also not correct. > > I don't think you need to say anything about this. Possibly you could say= that the bundle group identifies the m-lines that are to be in the bundle,= and so must=20 > not mention m-lines that are no longer in the bundle. But this is so obvi= ous that stating it is likely to confuse people more than not stating it. The to-be-submitted text basically only says that the mid must no longer be= used to associate the removed/rejected/disabled m- line with the BUNDLE gr= oup. -------------------------------------- >>>> 6.2.5. Rejecting A Media Description In A BUNDLE Group >>>> >>>> I agree with prior comment that using "Rejecting" here is weird and co= nfusing. I agree that "disabling" is probably more appropriate. >>>> But then "disabling a media description in a bundle group" is still a = little confusing, because it is then no longer "in" the bundle group. >>>> >>>> It might be clearer to just incorporate this into the prior section on= removing a media description from a bundle group. E.g., in 6.2.4: >>>> >>>> When an Offerer removes an "m=3D" line from a BUNDLE group, the Of= ferer >>>> MUST assign either a unique address *or a zero port* to the "m=3D"= line >>>> that is removed. >> >> I at least intend to put back "disabling". I was also thinking about=20 >> combining the sections, as you suggest, as the only difference is that t= he port value is set to zero in the reject/disable case. >> >>>> When an Offerer rejects an "m=3D" line in a BUNDLE group, the >>>> Offerer MUST assign a unique address, with a zero port value=20 >>>> [RFC3264], to >>> >>> as long as the port is zero the address need not be otherwise unique. >> >> True. I guess your suggested text above ("unique address or a zero port"= ) will fix that. >> >> As a side note, I intend to replace "unique address" and "bundle address= " with "unique transport parameters" and "bundle transport parameters", as = suggested by Martin. >> >> ...except in cases where the text actually talks about the IP address,=20 >> that is :) > > WFM. It wasn't as easy to change as I first thought, so for now I keep "unique a= ddress" and "bundle address". But, I have added a definition, saying that i= t refers to the IP address and port. In a separate chapter I talk about ICE candidates, and other parameters, th= at have to be identical in bundled m- lines. Regards, Christer From emil@sip-communicator.org Fri Jun 14 13:53:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4521F9A15 for ; Fri, 14 Jun 2013 13:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqy2vcMOt5+M for ; Fri, 14 Jun 2013 13:53:29 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id B56A021F99D4 for ; Fri, 14 Jun 2013 13:53:28 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so678809wiv.3 for ; Fri, 14 Jun 2013 13:53:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=4XacaDhvvVUjuBVPQDVSZRUUvkY5UVs+t5WuDn9eOIo=; b=BEJLaxeYLwzAtb1rKun/tnbWzlKLwARQs6xueNcPQiF7sae700rFDRvXmmSpRq7Yfz m5e0dAT5iBePrezgvPFbT8WZ2x6R9eZ95zC2cw78xZ1+asqmp9V91AaicwCC1DP1e9Jl jlpH+vUEd/uewgRTXuLVk+osob9z34/4+iWEkw4Ke188QN7LxEYF0GXRMkFQwKw/X0YY 31BfkRvSht5wyPc3Cdg+2A6Phnz6yWnVgkVeQoNotVB+uJ3HAj/XNnBqoGmVJbvJwKt5 gvo+Fxn3ayuy0WgVRKi0n7g1Sas9LpZmRI3E7LrpeYu180mOuvcyXCPNcFP/0xPTbmo1 jHBA== X-Received: by 10.194.9.101 with SMTP id y5mr2454040wja.86.1371243207636; Fri, 14 Jun 2013 13:53:27 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:4d80:ba75:137c:dc46]) by mx.google.com with ESMTPSA id b19sm5804869wik.10.2013.06.14.13.53.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 13:53:26 -0700 (PDT) Message-ID: <51BB82C5.3020400@jitsi.org> Date: Fri, 14 Jun 2013 22:53:25 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Flemming Andreasen References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> <51BB7012.10208@jitsi.org> <51BB766D.2030301@cisco.com> In-Reply-To: <51BB766D.2030301@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQniEq+xyiBAa/t0GrfFIfq1aH/QozUrRn0HrFIfOsnHNwTP4VgovN5gt9Q2qqevCABQXfPT Cc: =?windows-1252?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:53:30 -0000 Hey Flemming, On 14.06.13, 22:00, Flemming Andreasen wrote: > Hi Emil > > Per some of the previous discussion threads (see e.g. > http://www.ietf.org/mail-archive/web/mmusic/current/msg11019.html), > there is clearly some ambiguity around exactly what an m-line conveys, > both with and without bundle. This lack of clarity potentially affects > all of the different plan proposals as well as as 4566bis, and as such= > is an entirely reasonable discussion to have in MMUSIC. OK, so doesn't this mean all plans should be given equal time to discuss = their take on this issue? > To the extent > that resolution of this impacts progress on the Plan A versus Plan B > discussion, it is also an appropropriate discussion to have next week. Sorry, I am confused again. No Plan, Plan A and Plan B demonstrate=20 versions of SDP that can be used in multi-stream scenarios. Yet, for=20 some reason we will only be discussing the validity of Plan A and Plan=20 B's approaches. Could you please explain why that is? The only explanation I could find was that No Plan's SDP usage was too=20 obvious and valid and there wasn't anything to discuss about it. Just to be clear: we have been using a No Plan-like approach for Jitsi=20 video conferencing for quite a long time now. I believe other popular=20 vendors of conferencing solutions have been doing the same. Cheers, Emil > What is not appropriate at this time however is to turn that into a > discussion of choosing "no plan" for RTCWeb since MMUSIC cannot (and > should not) make that decision (as clarified by the RTCWeb chairs as we= ll). > Thanks > > -- Flemming > > > On 6/14/13 3:33 PM, Emil Ivov wrote: >> >> >> On 14.06.13, 21:10, Ari Ker=E4nen wrote: >>> On 6/14/13 10:02 PM, Emil Ivov wrote: >>>> On 14.06.13, 20:20, Ari Ker=E4nen wrote: >>>>> Hi all, >>>>> >>>>> Given the guidance from the RTCWEB WG chairs that the "no-plan" >>>>> discussion should essentially happen at the RTCWEB WG, the MMUSIC >>>>> interim meeting on June 17th will be focused on Plan A and Plan B. >>>> >>>> I assume this implies that MMUSIC considers it entirely appropriate = to >>>> use SDP for signalling multiple streams the way No Plan suggests (i.= e. >>>> one m=3D line can carry as many RTP flows as it likes). So much so, = that >>>> no further discussion is necessary on the subject. >>>> >>>> Could you please confirm that I am reading this properly? >>> >>> This means that the interim time should be used mainly to discuss pla= n A >>> vs plan B merits, not whether RTCWEB should use A/B, or no-plan. >> >> Sure. I get this and I find it very reasonable. >> >> However, just as Plans A and B, No Plan says: here's an SDP that you >> can use when doing multiple streams. >> >> So, I just want to confirm that we will not be discussing the SDP >> sides of the proposal in No Plan because they make perfect sense from >> an MMUSIC point of view and no discussion is really necessary. It'll >> be up to other working groups to decide whether they'd like to use >> that particular (and valid) approach. >> >> Emil >> >> > > --=20 https://jitsi.org From internet-drafts@ietf.org Fri Jun 14 14:13:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD0621F9AD5; Fri, 14 Jun 2013 14:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyZHgzTvq8Fp; Fri, 14 Jun 2013 14:13:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 813B721F9AC5; Fri, 14 Jun 2013 14:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614211351.25088.66345.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 14:13:51 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:13:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-04.txt Pages : 26 Date : 2013-06-14 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-bundle-negotiation= -04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fandreas@cisco.com Fri Jun 14 14:16:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBED921E805E for ; Fri, 14 Jun 2013 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4-gW0ub9dsz for ; Fri, 14 Jun 2013 14:15:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 641FD21E805A for ; Fri, 14 Jun 2013 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4108; q=dns/txt; s=iport; t=1371244557; x=1372454157; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qHvFUszhUgM4X3KOUfU6XgrDr+YFwhn+B+vpmpvoCfA=; b=m5os/KTbG/Q2OFkIdHIS4T51PZDu1LgCQPnbHyNKPGMvnUxqa6HfYhx1 bKx8B99/FXTg7OIbOugfAnIpzBgBfy+av/sEqrv+FD9gQWhkDoBxwX4VC 32YA1psaZxwBaByg2OxdorKnKTTe2+CKQ013vVpwyhV5bnoaaEn2Fuiux o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIHAKmHu1GtJXG8/2dsb2JhbABbgwkwqxuTc4EKFnSCIwEBAQMBMgEFNgoBBQsLDgoJFg8JAwIBAgFFBg0BBwEBBRKHbQYMuX2OFoEyB4NgA5dBkUKDKyCBNQ X-IronPort-AV: E=Sophos;i="4.87,868,1363132800"; d="scan'208";a="223040658" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jun 2013 21:15:57 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5ELFu20018476; Fri, 14 Jun 2013 21:15:56 GMT Message-ID: <51BB880B.1010502@cisco.com> Date: Fri, 14 Jun 2013 17:15:55 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> <51BB7012.10208@jitsi.org> <51BB766D.2030301@cisco.com> <51BB82C5.3020400@jitsi.org> In-Reply-To: <51BB82C5.3020400@jitsi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: =?windows-1252?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:16:02 -0000 On 6/14/13 4:53 PM, Emil Ivov wrote: > Hey Flemming, > > On 14.06.13, 22:00, Flemming Andreasen wrote: >> Hi Emil >> >> Per some of the previous discussion threads (see e.g. >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11019.html), >> there is clearly some ambiguity around exactly what an m-line conveys, >> both with and without bundle. This lack of clarity potentially affects >> all of the different plan proposals as well as as 4566bis, and as such >> is an entirely reasonable discussion to have in MMUSIC. > > OK, so doesn't this mean all plans should be given equal time to > discuss their take on this issue? > I don't believe it is or should be a plan-specific discussion, so no. >> To the extent >> that resolution of this impacts progress on the Plan A versus Plan B >> discussion, it is also an appropropriate discussion to have next week. > > Sorry, I am confused again. No Plan, Plan A and Plan B demonstrate > versions of SDP that can be used in multi-stream scenarios. Yet, for > some reason we will only be discussing the validity of Plan A and Plan > B's approaches. > > Could you please explain why that is? > Because "no plan" doesn't seem to be asking MMUSIC to do anything and when we clarified with the RTCWeb chairs whether "no plan" should be in scope for the MMUSIC interim meeting discussion the answer was no; that part of the discussion belongs in RTCWeb. If you want to argue against that, you need to do so on the RTCWeb list with the RTCWeb chairs. > The only explanation I could find was that No Plan's SDP usage was too > obvious and valid and there wasn't anything to discuss about it. > > Just to be clear: we have been using a No Plan-like approach for Jitsi > video conferencing for quite a long time now. I believe other popular > vendors of conferencing solutions have been doing the same. > Ok. This is all part of an entirely reasonable discussion to have, but currently, it should be taking place on the RTCWeb mailing list. As noted previously (by Ted I believe) it may also be helpful to split the "no plan" draft in two; an MMUSIC specific portion with asks/clarifications for MMUSIC and an RTCWeb specific part. Thanks -- Flemming > Cheers, > Emil > >> What is not appropriate at this time however is to turn that into a >> discussion of choosing "no plan" for RTCWeb since MMUSIC cannot (and >> should not) make that decision (as clarified by the RTCWeb chairs as >> well). > >> Thanks >> >> -- Flemming >> >> >> On 6/14/13 3:33 PM, Emil Ivov wrote: >>> >>> >>> On 14.06.13, 21:10, Ari Keränen wrote: >>>> On 6/14/13 10:02 PM, Emil Ivov wrote: >>>>> On 14.06.13, 20:20, Ari Keränen wrote: >>>>>> Hi all, >>>>>> >>>>>> Given the guidance from the RTCWEB WG chairs that the "no-plan" >>>>>> discussion should essentially happen at the RTCWEB WG, the MMUSIC >>>>>> interim meeting on June 17th will be focused on Plan A and Plan B. >>>>> >>>>> I assume this implies that MMUSIC considers it entirely >>>>> appropriate to >>>>> use SDP for signalling multiple streams the way No Plan suggests >>>>> (i.e. >>>>> one m= line can carry as many RTP flows as it likes). So much so, >>>>> that >>>>> no further discussion is necessary on the subject. >>>>> >>>>> Could you please confirm that I am reading this properly? >>>> >>>> This means that the interim time should be used mainly to discuss >>>> plan A >>>> vs plan B merits, not whether RTCWEB should use A/B, or no-plan. >>> >>> Sure. I get this and I find it very reasonable. >>> >>> However, just as Plans A and B, No Plan says: here's an SDP that you >>> can use when doing multiple streams. >>> >>> So, I just want to confirm that we will not be discussing the SDP >>> sides of the proposal in No Plan because they make perfect sense from >>> an MMUSIC point of view and no discussion is really necessary. It'll >>> be up to other working groups to decide whether they'd like to use >>> that particular (and valid) approach. >>> >>> Emil >>> >>> >> >> > From prvs=0877423fe8=christer.holmberg@ericsson.com Fri Jun 14 14:18:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578F721F9B4A for ; Fri, 14 Jun 2013 14:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.812 X-Spam-Level: X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTQFAez0acRb for ; Fri, 14 Jun 2013 14:18:39 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A77A521F9B13 for ; Fri, 14 Jun 2013 14:18:38 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-55-51bb88ad5eb1 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 72.AF.10205.DA88BB15; Fri, 14 Jun 2013 23:18:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 23:18:36 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-04 Thread-Index: Ac5pRGWjIkGbqyLZQ6GzkfaL60uzCA== Date: Fri, 14 Jun 2013 21:18:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38B16B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C38B16BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre7ajt2BBpsbxCymLn/M4sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7ozPk/pZC75LV8x+95W1gfGJRBcjJ4eEgInEno0TWCBsMYkL 99azdTFycQgJHGWUmHrvGiOEs4RRYtL1S0xdjBwcbAIWEt3/tEEaRATUJb7u7WEGsYUF3CVO 3/rJAhH3kTi9fCYbSLmIgJ7EiUexIGEWAVWJg39/sIPYvAK+ElP+/GUCsRmB9n4/tQbMZhYQ l/hw8DozxD0CEkv2nIeyRSVePv7HCmErSTQuecIKUZ8vsf77HFaImYISJ2c+YZnAKDQLyahZ SMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5ilOLk3LTjQw2MQID/+CW3xY7 GC//tTnEKM3BoiTO++nUrkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBsfzma+5OtzN5 HwLTdDnlQuOfWW59PHWK7BQ2Ww8xaUmWTccmZN3I7T7hcuT8z8v312xQ+2u2KluZk9uT+84/ 6+3cqe+cAhJUj9YdnPYh75DUC46Ve/Z+1DOof+l+2+B9+OYy5mubP1ZdcOSu+FL5x3+lbNuE 2vDU3Y9fPHjsK1Rnd7Bs5lGbl0osxRmJhlrMRcWJAA0FSNJPAgAA Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:18:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C38B16BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Bundle Fans, I've submitted a new version (-04) of BUNDLE. Compared with the previous version, there are some rather big editorial cha= nges, especially in the SDP Offer/Answer sections, mostly based on the mail= discussions. I have not touched the "ICE Usage" section at all. That is one of the next = things we need to deal with. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C38B16BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Bundle Fans,

 

I’ve submitted a new vers= ion (-04) of BUNDLE.

 

Compared with the previous vers= ion, there are some rather big editorial changes, especially in the SDP Off= er/Answer sections, mostly based on the mail discussions.=

 

I have not touched the “I= CE Usage” section at all. That is one of the next things we need to d= eal with.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C38B16BESESSMB209erics_-- From emil@sip-communicator.org Fri Jun 14 14:54:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ED821F9A41 for ; Fri, 14 Jun 2013 14:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuOnoRFJm2yp for ; Fri, 14 Jun 2013 14:54:28 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0631E21F9A24 for ; Fri, 14 Jun 2013 14:54:27 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so892173wes.5 for ; Fri, 14 Jun 2013 14:54:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=0p2IB1P6cKzGPaHMYZLmFb+5TiyOKHN978PvqFtDbs4=; b=PaFD6zu1aF2E6AxAvZbbEusdiDmgGhWvBiRn62YnhsZ/Kj5emciqSlc8kob2v//jCJ 4xvNU8Bre9jh6NwcWnOZyUaMlSwskiLFa6gGVXJzHYh+nh3T/l799vyxZmXLN8iVUWht 2tEykhJWxXn0p6u0k4AdAUCBaowMYCuFRpIodVqk8GHz+DUyCQfryTLYvc38ZYbcFKnE NzMLtu5LBnHuUAiUUJdK+yfFmoyF7fbiDfnVH5BNE6vpsH7x9UzXyYN/HGRhUQheDVth ZPB9GFEaB8vSk3toO7M/CB4bGxOhVxY5f/3cRaxEHuKpS3gzTBcZfmicz5ExpPZJEq/p /N6Q== X-Received: by 10.180.83.166 with SMTP id r6mr35726wiy.60.1371246867069; Fri, 14 Jun 2013 14:54:27 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:4d80:ba75:137c:dc46]) by mx.google.com with ESMTPSA id ft10sm6087279wib.7.2013.06.14.14.54.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 14:54:26 -0700 (PDT) Message-ID: <51BB910F.404@jitsi.org> Date: Fri, 14 Jun 2013 23:54:23 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Flemming Andreasen References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> <51BB7012.10208@jitsi.org> <51BB766D.2030301@cisco.com> <51BB82C5.3020400@jitsi.org> <51BB880B.1010502@cisco.com> In-Reply-To: <51BB880B.1010502@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkgJ1OZvzEgqsbCrykZeO0wjHRWx+Kt29uercSHyUrtWnK2ikRWmuRql9BvKlxXDbs59HXY Cc: =?windows-1252?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:54:28 -0000 On 14.06.13, 23:15, Flemming Andreasen wrote: >>> Per some of the previous discussion threads (see e.g. >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11019.html), >>> there is clearly some ambiguity around exactly what an m-line conveys, >>> both with and without bundle. This lack of clarity potentially affects >>> all of the different plan proposals as well as as 4566bis, and as such >>> is an entirely reasonable discussion to have in MMUSIC. >> >> OK, so doesn't this mean all plans should be given equal time to >> discuss their take on this issue? >> > I don't believe it is or should be a plan-specific discussion, so no. Could we then maybe have that discussion scheduled in the agenda, please? Right now it seems to only contain points specific to Plan A or Plan B. >>> To the extent >>> that resolution of this impacts progress on the Plan A versus Plan B >>> discussion, it is also an appropropriate discussion to have next week. >> >> Sorry, I am confused again. No Plan, Plan A and Plan B demonstrate >> versions of SDP that can be used in multi-stream scenarios. Yet, for >> some reason we will only be discussing the validity of Plan A and Plan >> B's approaches. >> >> Could you please explain why that is? >> > Because "no plan" doesn't seem to be asking MMUSIC to do anything The thing that No Plan really needs from MMUSIC is to validate the way it uses m= lines for multiple RTP flows. If we can make sure that this is discussed (independently of how streams will be accepted and rejected) then I am fine. Thanks, Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Fri Jun 14 15:53:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3CA21E805E for ; Fri, 14 Jun 2013 15:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Famrj6JJzDkF for ; Fri, 14 Jun 2013 15:53:32 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5B521E805D for ; Fri, 14 Jun 2013 15:53:32 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id oGz61l0041vXlb859NtXvN; Fri, 14 Jun 2013 22:53:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id oNtX1l00Q3ZTu2S3dNtXec; Fri, 14 Jun 2013 22:53:31 +0000 Message-ID: <51BB9EEA.7050009@alum.mit.edu> Date: Fri, 14 Jun 2013 18:53:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> <51BB622F.60007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AF86@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38AF86@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371250411; bh=lPRufsDLpVes+x8jot/scKam1v4BAJ0paRmH6A2ypIg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mt/r9MHQvRW0bDTDDBlpM2ciV5tgxXDSdpUx8gCVdmp+v1eFOr9T8Ne/qM+BPN9a4 33aH6kuDgqP3eOdg7cepMSbjD0CsmFK4ySHjQvE/OcBuTRxHCM8APFfHoc8kt93lUX cbIEwERpHe2LYHX8oNkn6vcRYUMF65+MJ8dGBMl+Dv2HCPRqwGT8TiDjlj07GSsbuG gSDAXKIixTELUKiUJ1BVOS67IzOw5RNDQlac+zxmPR/nWnYYUMpeO237/1CzvPhsN3 GiBDiSxrRT7dTDc3twr0f8x52tdyw2/B4ybAG/quwoUAYRKlpfZ976mJLASaTpsL/+ pIA4EvYzeweSw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 22:53:38 -0000 (The quoting here is getting rather unmanageable. I'm trimming, but maybe we need to start over fresh.) On 6/14/13 4:45 PM, Christer Holmberg wrote: >>>> Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE? >>>> >>>> The minimal answer is that if an offer included a bundle group, and >>>> the answer also contains a corresponding bundle group, then the answerer supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer. >>> >>> Yes. >>> >>> I was actually thinking about removing the "until the Offerer knows" text, and simply generally say that the bundle address is negotiated by assigning a unique address to each "m=" line. >>> >>> But, as you want to be able to assign a bundle address to multiple "m=" lines before it has been negotiated, it would not work. >>> >>>> But we want to assume more - at least that if *a* bundle was >>>> supported by both sides in one O/A exchange, then both sides can be >>>> presumed to >>>> *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session. >>> >>> I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated. >> >> Sure, I think "SDP session" will work. >> >>>> Is, or should there be, a way to go back on that presumption - to >>>> stop supporting bundle? I guess if an end wanted to stop supporting >>>> bundle while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because it doesn't currently need a bundle though it still supports them. >>> >>> Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage. >> >> My point was that if support for bundle can be presumed, then it no longer is necessary to offer unique address info for each m-line when adding to bundles or proposing new bundles. > > Ok, I hear you. Yes, IF we allow that it is important that it is clear when one can assume that the Answerer supports BUNDLE. In prior reply I sketched out my thoughts about what constitute reasonable evidence. But IMO an offerer MAY presume support without any explicit evidence in the signaling if it wishes. This may be because it knows the relevant deployment environment guarantees it, or because it has some other signaling mechanism to learn it. Or it may simply want to play the odds. I don't think we should forbid guessing. It is a judgement call, and in such a case the offerer must be prepared to cope with the consequences if the guess turns out to be wrong. >> In particular, this becomes significant for the bundle splitting case: >> >> 1) X sends offer to Y proposing a bundle, uses unique address info >> 2) Y sends answer to x accepting the bundle, >> but rejecting some of the m-lines in it >> 3) X sends a BAS to Y to finalize the initial bundle. >> 4) Y sends answer to X accepting the BAS >> 5) Y sends offer to X keeping the existing bundle, >> and proposing a new bundle for the previously rejected >> m-lines. Because it knows X supports bundle, and it knows >> that X was willing to have the m-lines in question bundled, >> this offer is in the form of a BAS, with all the m-lines >> in the new bundle having common address info. >> 6) X sends answer to Y, presumably accepting both bundles. >> >> In this case it is quite wasteful if Y has to provide separate address info for each of the m-lines in the new bundle, and then yet another BAS has to be exchanged to fix that up. >> >> Of course being able to presume support also is useful in cases where no bundle splitting is needed. E.g., Y was able to accept the initial bundle from X in full. Then later >> it wanted to offer an additional separate bundle. And it could also cover the case where an initial O/A is done when no bundle is yet needed, but *support* for bundle is >> negotiated. Then later, when a bundle is needed, it may be offered in BAS form, so only a single O/A is required. >> >> The above also points out another issue: (3) & (4) are quite a waste. It would be nice to be able to avoid them in this case. One way to achieve that would be to put the burden >> on the answerer that accepts a bundle where the address info is not all the same to send the BAS. In this case that would mean that (5) would also serve as a substitute for (3), and >> (6) would then substitute for (4). > > I understand what you're saying, and I'll dig more into it once I get -04 submitted :) Sure! > I have added it as an Open Issue in -04, though. Thanks. >> I'm still having trouble making sense of this. Let me break out some things to try and understand. (I'm trying to state what I think you mean, not as it ought to be written in a draft, just for maximal clarity.) >> >> It is the *answer* that selects the m-line that defines the bundle addresses for both offerer and answerer. Until then it isn't known. > > Correct. > >> Only after the bundle addresses are known may an offer be sent that has a common address for multiple m-lines in the bundle, and if so it must be the one that was previously defined as the bundle address. > > Correct. > >> As a consequence, on the initial offer that proposes a bundle, every m-line must have unique address info. > > Correct. > >> When sending an subsequent offer, after a bundle has previously been defined, (so the bundle addresses are known), multiple m-lines in that bundle *may* be offered with the same address info, but that address info must be the previously agreed bundle address. > > Correct. > >> As a consequence, to *change* a previously agreed bundle address, an offer must be sent where every m-line in the bundle has unique address info. > > Correct. > >> Does that accurately restate what you meant above? > > Yes. > >> (If so, you know that I don't agree - I find it much more prescriptive than it needs to be, with negative consequences. But lets be certain we agree what you are intending to say first.) > > It seems we have a common understanding of what is currently specified :) Good. That is a start! > And, even with your suggestion, the answerer would still select the bundle addresses for both the offerer and the answerer. But, there might of course > not be too many addresses to choose from in the offer (e.g. if each m- line in the offer has the suggested new bundle address). Yes. > Also, even with your suggestion I guess that at least the initial offer would need to have unique addresses for each m- line, as it is yet not known > whether BUNDLE is supported within that particular SDP session. Not necessarily. I discussed this above. >> ISTM that the problem is being driven by what is easy to describe, rather than what is useful to do, even though the actual implementation effort would probably be the same or even less difficult. >> >> While I do agree that clarity of explanation is important, that tells me we need to continue to work to find a clear way to express constraints without being over restrictive. >> >> I previously tried - offering a set of constraints on offers and answers that I thought covered the cases. I still think that could work. > > Ok, once I've submitted -04, I'll continue to work on text for that, while allowing people to review the rest of the procedures. OK. >>>> nit: I don't think this should say anything about the mid value that >>>> was previously defined for the m-line. That implies that mid values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required. >>>> If I want, I should be able to "relabel" the m-lines with new mid >>>> values. This reduces the amount of state that is required to be preserved from one o/a to the next. >>>> >>>> The statement "remove an m-line from a bundle group" already implies >>>> that the group does not contain a mid-value identifying that m-line >>>> (in >>>> *this* offer or answer). >>> >>> Maybe I could say that the mid value that was previously defined is no more valid, and must not be present in any Offer or Answer. >> >> The mid values from the previous o/a have *no* relevance to the new o/a. >> It is *possible* (though not likely) that some of the same values may be used in the new offer to identify *different* m-lines. So saying that a value from a previous o/a must not be present is also not correct. >> >> I don't think you need to say anything about this. Possibly you could say that the bundle group identifies the m-lines that are to be in the bundle, and so must >> not mention m-lines that are no longer in the bundle. But this is so obvious that stating it is likely to confuse people more than not stating it. > > The to-be-submitted text basically only says that the mid must no longer be used to associate the removed/rejected/disabled m- line with the BUNDLE group. OK. >>> As a side note, I intend to replace "unique address" and "bundle address" with "unique transport parameters" and "bundle transport parameters", as suggested by Martin. >>> >>> ...except in cases where the text actually talks about the IP address, >>> that is :) >> >> WFM. > > It wasn't as easy to change as I first thought, so for now I keep "unique address" and "bundle address". But, I have added a definition, saying that it refers to the IP address and port. > > In a separate chapter I talk about ICE candidates, and other parameters, that have to be identical in bundled m- lines. Sounds reasonable. Thanks, Paul From prvs=78786d6c08=christer.holmberg@ericsson.com Sat Jun 15 01:55:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284F721F9B17 for ; Sat, 15 Jun 2013 01:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIMQw926El8a for ; Sat, 15 Jun 2013 01:55:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 767ED21F9ACC for ; Sat, 15 Jun 2013 01:55:21 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-c6-51bc2bf5a925 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8F.C6.18006.5FB2CB15; Sat, 15 Jun 2013 10:55:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Sat, 15 Jun 2013 10:55:17 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AA24L0AABt8NdAAF/qngAAH50mwAAElZgAAGOPAkA== Date: Sat, 15 Jun 2013 08:55:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C393AFA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se> <51BB622F.60007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AF86@ESESSMB209.ericsson.se> <51BB9EEA.7050009@alum.mit.edu> In-Reply-To: <51BB9EEA.7050009@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre5X7T2BBhcW6FtMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xo45j5kLZrBX7Nw5kb2B8TJrFyMnh4SA icS6F9cYIWwxiQv31rN1MXJxCAkcZpT41/qaCcJZxChxasEhoCoODjYBC4nuf9ogpoiAhsSk rWogJrOAusTVxUEgY4QFXCUmvTjJAmKLCLhJPH/9nhXCDpN4Ma0XzGYRUJU48PooG4jNK+Ar 8frRZhaITTuZJHYeXwJ2D6eAjsTzDZ1ggxiBbvt+ag0TiM0sIC7x4eB1ZoibBSSW7DkPZYtK vHz8D+ovJYnGJU9YIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZ wMiyipE9NzEzJ73caBMjMEYObvmtuoPxzjmRQ4zSHCxK4rwfT+0KFBJITyxJzU5NLUgtii8q zUktPsTIxMEJIrikGhjDjr2XesvOIZvd8fxQX98xp7sGq27yl/N+unm6SDT0Q726QtH9ggMz U1vv3zRyOLw9o7u3x+r43u4Xnuzv29wX5p/9vdYyYU7HNuO3OyK5t9yZ5H0sdgqPsV7kBLkd 4Qx7/0k/2PymPOzrYxHeR/1RP12TVI6k78hKblz+KeJp0tLLD+uVjfcosRRnJBpqMRcVJwIA IUekpmQCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 08:55:28 -0000 Hi, > (The quoting here is getting rather unmanageable. > I'm trimming, but maybe we need to start over fresh.) I think the only technical issue is whether it's allowed to: 1) Assign an address to multiple m- line before it has been selected as a b= undle address; and 2) Whether it's allowed to assign an address to multiple m- line before the= Answerer has indicated *in the SDP Answer* whether it supports BUNDLE. The two are of course related, because in order to allow 2) we also need to= allow 1) :) I personally don't have any problems with you suggestion (it will require s= ome editorial work, but technically there should be no issues).=20 However, it does sound very much like my original BUNDLE proposal (where th= e Offerer ALWAYS assigned the bundle address to all m- lines), so I'd like = to hear what others - especially Cullen - thinks about it. Regards, Christer From prvs=887851b1cb=christer.holmberg@ericsson.com Sat Jun 15 01:58:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B31221F9B97 for ; Sat, 15 Jun 2013 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.638 X-Spam-Level: X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWk4bJ9F-LvA for ; Sat, 15 Jun 2013 01:58:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E864921F9B82 for ; Sat, 15 Jun 2013 01:58:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-86-51bc2ca48ad6 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B6.E6.18006.4AC2CB15; Sat, 15 Jun 2013 10:58:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Sat, 15 Jun 2013 10:58:12 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: When commenting on BUNDLE-04 Thread-Index: Ac5ppn30Ycy1Gi8LQ+eT4OlhnaCsbw== Date: Sat, 15 Jun 2013 08:58:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C395B0E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C395B0EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvre5SnT2BBns+cllMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BnPVr9nKTgkUzFr62G2BsaZkl2MnBwSAiYS2x9vY4awxSQu 3FvP1sXIxSEkcJhRovfrcmYIZxGjxM7vd9i7GDk42AQsJLr/aYM0iAioS3zd2wPWLCygKrFl zVI2iLiWxKnL/xkhbD2JB0ufg9ksQDXLGtcxgYzhFfCVaNspBxJmBNr7/dQaJhCbWUBc4sPB 61D3CEgs2XMeyhaVePn4HyuErSTRuOQJK8gYZoF8iUmzikHCvAKCEidnPmGZwCg0C8mkWQhV s5BUQZToSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsY2XMTM3PSy402MQJD/uCW36o7GO+c EznEKM3BoiTO+/HUrkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBUXqLwsaveQ7BbO5+ qTGWsqlXF73KTXWM38HmZmcWHnxktdyqGVNEo35Y/VeftOfT64P9LNIWPAe8LUr6pXo35EtP Lchg4XE7dvz4jduXjbWUyz8syKz7eeDUE4PUd+Y2O37nSHdv0GhyDnDRVwg9siP18I0n4vkh LBHvy49tk81LCl/NlH5diaU4I9FQi7moOBEAOcfcmEwCAAA= Subject: [MMUSIC] When commenting on BUNDLE-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 08:58:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C395B0EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When giving comments on BUNDLE-04, I would appreciate if you could separate= your comments into different e-mails, e.g. one mail per main topic (SDP O/= A procedures, ICE usage, SDP Attribute procedures, etc etc etc). It will be much easier to follow the discussion, and we'll avoid ultralong = e-mails :) It would also be good if you could indicate whether any given comment is ed= itorial or technical. Thanks! Christer --_000_7594FB04B1934943A5C02806D1A2204B1C395B0EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When giving comments on BUNDLE-= 04, I would appreciate if you could separate your comments into different e= -mails, e.g. one mail per main topic (SDP O/A procedures, ICE usage, SDP At= tribute procedures, etc etc etc).

 

It will be much easier to follo= w the discussion, and we’ll avoid ultralong e-mails :)

 

It would also be good if you co= uld indicate whether any given comment is editorial or technical.

 

Thanks!

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C395B0EESESSMB209erics_-- From harald@alvestrand.no Sat Jun 15 02:39:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859DE21F8C20 for ; Sat, 15 Jun 2013 02:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-cVwapj0ytK for ; Sat, 15 Jun 2013 02:39:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 68CAC21F896D for ; Sat, 15 Jun 2013 02:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 318E339E0F0 for ; Sat, 15 Jun 2013 11:39:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrVm3VmhRzg0 for ; Sat, 15 Jun 2013 11:39:46 +0200 (CEST) Received: from [172.30.42.116] (c-e2fee555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.254.226]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0E57E39E029 for ; Sat, 15 Jun 2013 11:39:46 +0200 (CEST) Message-ID: <51BC3661.6050603@alvestrand.no> Date: Sat, 15 Jun 2013 11:39:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <51BB5EFE.5090903@ericsson.com> In-Reply-To: <51BB5EFE.5090903@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 09:39:53 -0000 Not on A vs B, but on the agenda: This time allocation is: - 20 mins administrativia - 120 mins presentation - 40 mins discussion I do not think this is a wise allocation. It maximizes the time given to plan "owners" to present their viewpoints, and minimizes the time avaliable for people who do not "own a plan" to present a viewpoint. People who come to the meeting SHOULD have read the drafts beforehand. If not, listening to 60 mins of presentation won't make them understand the issues. I would suggest instead: - 10 min administrativia (agenda bash) - 15 min Plan A presentation - 15 min Plan A clarification questions - 15 min Plan B presentation - 15 min Plan B clarification questions - 10 min presentaton on "what questions do we need to answer" (by the chairs) - 90 min discussion on answering the questions (structured by the chairs) - 10 min administrativia (wrapup) (and yes, this is enough time that one could fit in a slot for "no plan" too) (I'm HOPING that the draft agenda is intended to show "presentation and discussion" for each draft, not what the words on the agenda currently say. But if not, I'm considering whether calling in 2 hours late is a reasonable option.) On 06/14/2013 08:20 PM, Ari Keränen wrote: > Hi all, > > Given the guidance from the RTCWEB WG chairs that the "no-plan" > discussion should essentially happen at the RTCWEB WG, the MMUSIC > interim meeting on June 17th will be focused on Plan A and Plan B. The > goal of the meeting is to clarify what are the two different plans, > what are their key differences and merits, and how can we select one > to move forward with. > > Here's the draft agenda: > > 7:00 – 7:10 Agenda bash & Note takers > 7:10 – 8:10 Plan A Presentation > http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00 > (also http://tools.ietf.org/html/draft-roach-rtcweb-glareless-add-00) > 8:10 – 9:10 Plan B Presentation > http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 > 9:10 – 9:50 Discussion on preferred approach > 9:50 – 10:00 Wrap-Up & Next Steps > > Note: All Times are Pacific Daylight Time (PDT) > > > The WebEx information for joining the meeting is available here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg11488.html > > > Regards, > Ari & Flemming (MMUSIC co-chairs) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Sat Jun 15 07:11:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B4A21F9C11 for ; Sat, 15 Jun 2013 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBKLEnAr6DUT for ; Sat, 15 Jun 2013 07:11:13 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 4868421F9C37 for ; Sat, 15 Jun 2013 07:11:12 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta07.westchester.pa.mail.comcast.net with comcast id odVg1l0041HzFnQ57eBBkA; Sat, 15 Jun 2013 14:11:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id oeBB1l00R3ZTu2S3aeBB1d; Sat, 15 Jun 2013 14:11:11 +0000 Message-ID: <51BC75FD.50504@alum.mit.edu> Date: Sat, 15 Jun 2013 10:11:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> In-Reply-To: <51BC3661.6050603@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371305471; bh=l2t4G845yTfqk76gLOen0dq7z36KIm3BC7NuY5hKrZc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hrhi9Fdn04sIZZQ/Yqc+IMs+avKDePKXtvO9gKlKPI6/ykAB2JEIwwqdBTPvSdOt7 kBUemcIPGBx/G8J7GZqU2mE9tszwZCbTOHGCJbF3ee0Ah9XFBe5bsrc7D0QLRsJTAh ugKdj3Cea2Tq9etVsSuD4GfPfMiLDHIR1Jk8abzZcbIJveDU7IhhbLv57wBBqR5HWZ 5S9mZj503FGE3PMwQk0C9iirg4m2QaybYGCRMC8bjaxraeogI6FbxNZdz9OJiCCBSF xaWhHIn7GgWXibYHYWc0tDkJ1oUqihcZcRDqKuw6gV/IuKe8A6Iy4/H971UOMn8BqS QStYpS4ZBiZLA== Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 14:11:18 -0000 +1 On 6/15/13 5:39 AM, Harald Alvestrand wrote: > Not on A vs B, but on the agenda: > > This time allocation is: > > - 20 mins administrativia > - 120 mins presentation > - 40 mins discussion > > I do not think this is a wise allocation. It maximizes the time given to > plan "owners" to present their viewpoints, and minimizes the time > avaliable for people who do not "own a plan" to present a viewpoint. > People who come to the meeting SHOULD have read the drafts beforehand. > If not, listening to 60 mins of presentation won't make them understand > the issues. > > I would suggest instead: > > - 10 min administrativia (agenda bash) > - 15 min Plan A presentation > - 15 min Plan A clarification questions > - 15 min Plan B presentation > - 15 min Plan B clarification questions > - 10 min presentaton on "what questions do we need to answer" (by the > chairs) > - 90 min discussion on answering the questions (structured by the chairs) > - 10 min administrativia (wrapup) > > (and yes, this is enough time that one could fit in a slot for "no plan" > too) > > (I'm HOPING that the draft agenda is intended to show "presentation and > discussion" for each draft, not what the words on the agenda currently > say. But if not, I'm considering whether calling in 2 hours late is a > reasonable option.) > > > On 06/14/2013 08:20 PM, Ari Keränen wrote: >> Hi all, >> >> Given the guidance from the RTCWEB WG chairs that the "no-plan" >> discussion should essentially happen at the RTCWEB WG, the MMUSIC >> interim meeting on June 17th will be focused on Plan A and Plan B. The >> goal of the meeting is to clarify what are the two different plans, >> what are their key differences and merits, and how can we select one >> to move forward with. >> >> Here's the draft agenda: >> >> 7:00 – 7:10 Agenda bash & Note takers >> 7:10 – 8:10 Plan A Presentation >> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00 >> (also http://tools.ietf.org/html/draft-roach-rtcweb-glareless-add-00) >> 8:10 – 9:10 Plan B Presentation >> http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 >> 9:10 – 9:50 Discussion on preferred approach >> 9:50 – 10:00 Wrap-Up & Next Steps >> >> Note: All Times are Pacific Daylight Time (PDT) >> >> >> The WebEx information for joining the meeting is available here: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11488.html >> >> >> Regards, >> Ari & Flemming (MMUSIC co-chairs) >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Sat Jun 15 08:16:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811821F9DB0 for ; Sat, 15 Jun 2013 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atG18kP11J2o for ; Sat, 15 Jun 2013 08:16:48 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1C821F9DA9 for ; Sat, 15 Jun 2013 08:16:48 -0700 (PDT) Received: from BLU404-EAS270 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 15 Jun 2013 08:16:47 -0700 X-TMN: [fQoYbtrrOjsWpUtrRYu+WnqPRaJd3m2U] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> <51BC75FD.50504@alum.mit.edu> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51BC75FD.50504@alum.mit.edu> Date: Sat, 15 Jun 2013 08:16:43 -0700 To: Paul Kyzivat X-OriginalArrivalTime: 15 Jun 2013 15:16:47.0663 (UTC) FILETIME=[5A7403F0:01CE69DB] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 15:16:53 -0000 KzENCg0KT24gSnVuIDE1LCAyMDEzLCBhdCA3OjExIEFNLCAiUGF1bCBLeXppdmF0IiA8cGt5eml2 YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCg0KPiArMQ0KPiANCj4gT24gNi8xNS8xMyA1OjM5IEFN LCBIYXJhbGQgQWx2ZXN0cmFuZCB3cm90ZToNCj4+IE5vdCBvbiBBIHZzIEIsIGJ1dCBvbiB0aGUg YWdlbmRhOg0KPj4gDQo+PiBUaGlzIHRpbWUgYWxsb2NhdGlvbiBpczoNCj4+IA0KPj4gLSAyMCBt aW5zIGFkbWluaXN0cmF0aXZpYQ0KPj4gLSAxMjAgbWlucyBwcmVzZW50YXRpb24NCj4+IC0gNDAg bWlucyBkaXNjdXNzaW9uDQo+PiANCj4+IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgYSB3aXNlIGFs bG9jYXRpb24uIEl0IG1heGltaXplcyB0aGUgdGltZSBnaXZlbiB0bw0KPj4gcGxhbiAib3duZXJz IiB0byBwcmVzZW50IHRoZWlyIHZpZXdwb2ludHMsIGFuZCBtaW5pbWl6ZXMgdGhlIHRpbWUNCj4+ IGF2YWxpYWJsZSBmb3IgcGVvcGxlIHdobyBkbyBub3QgIm93biBhIHBsYW4iIHRvIHByZXNlbnQg YSB2aWV3cG9pbnQuDQo+PiBQZW9wbGUgd2hvIGNvbWUgdG8gdGhlIG1lZXRpbmcgU0hPVUxEIGhh dmUgcmVhZCB0aGUgZHJhZnRzIGJlZm9yZWhhbmQuDQo+PiBJZiBub3QsIGxpc3RlbmluZyB0byA2 MCBtaW5zIG9mIHByZXNlbnRhdGlvbiB3b24ndCBtYWtlIHRoZW0gdW5kZXJzdGFuZA0KPj4gdGhl IGlzc3Vlcy4NCj4+IA0KPj4gSSB3b3VsZCBzdWdnZXN0IGluc3RlYWQ6DQo+PiANCj4+IC0gMTAg bWluIGFkbWluaXN0cmF0aXZpYSAoYWdlbmRhIGJhc2gpDQo+PiAtIDE1IG1pbiBQbGFuIEEgcHJl c2VudGF0aW9uDQo+PiAtIDE1IG1pbiBQbGFuIEEgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMNCj4+ IC0gMTUgbWluIFBsYW4gQiBwcmVzZW50YXRpb24NCj4+IC0gMTUgbWluIFBsYW4gQiBjbGFyaWZp Y2F0aW9uIHF1ZXN0aW9ucw0KPj4gLSAxMCBtaW4gcHJlc2VudGF0b24gb24gIndoYXQgcXVlc3Rp b25zIGRvIHdlIG5lZWQgdG8gYW5zd2VyIiAoYnkgdGhlDQo+PiBjaGFpcnMpDQo+PiAtIDkwIG1p biBkaXNjdXNzaW9uIG9uIGFuc3dlcmluZyB0aGUgcXVlc3Rpb25zIChzdHJ1Y3R1cmVkIGJ5IHRo ZSBjaGFpcnMpDQo+PiAtIDEwIG1pbiBhZG1pbmlzdHJhdGl2aWEgKHdyYXB1cCkNCj4+IA0KPj4g KGFuZCB5ZXMsIHRoaXMgaXMgZW5vdWdoIHRpbWUgdGhhdCBvbmUgY291bGQgZml0IGluIGEgc2xv dCBmb3IgIm5vIHBsYW4iDQo+PiB0b28pDQo+PiANCj4+IChJJ20gSE9QSU5HIHRoYXQgdGhlIGRy YWZ0IGFnZW5kYSBpcyBpbnRlbmRlZCB0byBzaG93ICJwcmVzZW50YXRpb24gYW5kDQo+PiBkaXNj dXNzaW9uIiBmb3IgZWFjaCBkcmFmdCwgbm90IHdoYXQgdGhlIHdvcmRzIG9uIHRoZSBhZ2VuZGEg Y3VycmVudGx5DQo+PiBzYXkuIEJ1dCBpZiBub3QsIEknbSBjb25zaWRlcmluZyB3aGV0aGVyIGNh bGxpbmcgaW4gMiBob3VycyBsYXRlIGlzIGENCj4+IHJlYXNvbmFibGUgb3B0aW9uLikNCj4+IA0K Pj4gDQo+PiBPbiAwNi8xNC8yMDEzIDA4OjIwIFBNLCBBcmkgS2Vyw6RuZW4gd3JvdGU6DQo+Pj4g SGkgYWxsLA0KPj4+IA0KPj4+IEdpdmVuIHRoZSBndWlkYW5jZSBmcm9tIHRoZSBSVENXRUIgV0cg Y2hhaXJzIHRoYXQgdGhlICJuby1wbGFuIg0KPj4+IGRpc2N1c3Npb24gc2hvdWxkIGVzc2VudGlh bGx5IGhhcHBlbiBhdCB0aGUgUlRDV0VCIFdHLCB0aGUgTU1VU0lDDQo+Pj4gaW50ZXJpbSBtZWV0 aW5nIG9uIEp1bmUgMTd0aCB3aWxsIGJlIGZvY3VzZWQgb24gUGxhbiBBIGFuZCBQbGFuIEIuIFRo ZQ0KPj4+IGdvYWwgb2YgdGhlIG1lZXRpbmcgaXMgdG8gY2xhcmlmeSB3aGF0IGFyZSB0aGUgdHdv IGRpZmZlcmVudCBwbGFucywNCj4+PiB3aGF0IGFyZSB0aGVpciBrZXkgZGlmZmVyZW5jZXMgYW5k IG1lcml0cywgYW5kIGhvdyBjYW4gd2Ugc2VsZWN0IG9uZQ0KPj4+IHRvIG1vdmUgZm9yd2FyZCB3 aXRoLg0KPj4+IA0KPj4+IEhlcmUncyB0aGUgZHJhZnQgYWdlbmRhOg0KPj4+IA0KPj4+IDc6MDAg 4oCTIDc6MTAgQWdlbmRhIGJhc2ggJiBOb3RlIHRha2Vycw0KPj4+IDc6MTAg4oCTIDg6MTAgUGxh biBBIFByZXNlbnRhdGlvbg0KPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJv YWNoLXJ0Y3dlYi1wbGFuLWEtMDANCj4+PiAoYWxzbyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yb2FjaC1ydGN3ZWItZ2xhcmVsZXNzLWFkZC0wMCkNCj4+PiA4OjEwIOKAkyA5OjEw IFBsYW4gQiBQcmVzZW50YXRpb24NCj4+PiAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdWJlcnRpLXJ0Y3dlYi1wbGFuLTAwDQo+Pj4gOToxMCDigJMgOTo1MCBEaXNjdXNzaW9uIG9u IHByZWZlcnJlZCBhcHByb2FjaA0KPj4+IDk6NTAg4oCTIDEwOjAwIFdyYXAtVXAgJiBOZXh0IFN0 ZXBzDQo+Pj4gDQo+Pj4gTm90ZTogQWxsIFRpbWVzIGFyZSBQYWNpZmljIERheWxpZ2h0IFRpbWUg KFBEVCkNCj4+PiANCj4+PiANCj4+PiBUaGUgV2ViRXggaW5mb3JtYXRpb24gZm9yIGpvaW5pbmcg dGhlIG1lZXRpbmcgaXMgYXZhaWxhYmxlIGhlcmU6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzExNDg4Lmh0bWwNCj4+PiANCj4+PiAN Cj4+PiBSZWdhcmRzLA0KPj4+IEFyaSAmIEZsZW1taW5nIChNTVVTSUMgY28tY2hhaXJzKQ0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbW11 c2ljIG1haWxpbmcgbGlzdA0KPj4+IG1tdXNpY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW11c2ljDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From prvs=3878851d91=stefan.lk.hakansson@ericsson.com Sat Jun 15 09:51:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CBF21F99ED for ; Sat, 15 Jun 2013 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRM0lSTKC50Y for ; Sat, 15 Jun 2013 09:51:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4E82921F9A03 for ; Sat, 15 Jun 2013 09:51:27 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-ed-51bc9b8e52c7 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 93.15.18006.E8B9CB15; Sat, 15 Jun 2013 18:51:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Sat, 15 Jun 2013 18:51:26 +0200 From: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= To: Bernard Aboba , Paul Kyzivat Thread-Topic: [MMUSIC] MMUSIC WG June 17th virtual interim agenda Thread-Index: AQHOaSvslurQYidO0ECXtAPMQAoxxJk2ZKqAgABL1ICAABJSgIAAO+bQ Date: Sat, 15 Jun 2013 16:51:26 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2F1E57@ESESSMB209.ericsson.se> References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> <51BC75FD.50504@alum.mit.edu> 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+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvrW7/7D2BBvOPsVjsX3KZ2WLq8scs Fis2HGB1YPb4+/4Dk8fjnjNsHkuW/GQKYI7itklKLCkLzkzP07dL4M64umI2U8E7lYr+97MY Gxi/KHcxcnJICJhIfFi9lAnCFpO4cG89G4gtJHCYUWLuBP0uRi4gexGjxIozU1hAEmwCwRIX ZraBNYgIhEoc3TWBtYuRg4NZQF3i6uIgkLCwgIPEnLMvmEDCIgKOElsvaEBUu0l8Xv+IEcRm EVCV2HLnATOIzSvgK7Gts4MNYtV8Rom+9jZ2kF5OAVuJWSsiQGoYgU77fmoN2FZmAXGJW0/m Q50sILFkz3lmCFtU4uXjf6wQtpJE45InUJdpSqzfpQ/RqigxpfshO8RaQYmTM5+wTGAUm4Vk 6iyEjllIOmYh6VjAyLKKkT03MTMnvdxoEyMwYg5u+a26g/HOOZFDjNIcLErivB9P7QoUEkhP LEnNTk0tSC2KLyrNSS0+xMjEwQkiuKQaGGdt6dt7x2BF2HsTtsp410yhCv87p/QeuKwUXRll MHNlTe3WpF6XUxWlkydtffrsXe4HLoMJ0/w8WVfrdCy8VZnhcVCyYm6avsMcO/WPv+51aZ6O 0e17/u9PxlEVwYOZ1y8c2l0TZbEq62i9uKWiRvdyi8hjVo+n/99uu4kl3nWn/PsXJqIfriux FGckGmoxFxUnAgAUM9b5awIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 16:51:34 -0000 DQoNCisxDQoNCj4gDQo+ICsxDQo+IA0KPiBPbiBKdW4gMTUsIDIwMTMsIGF0IDc6MTEgQU0sICJQ YXVsIEt5eml2YXQiIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPiANCj4gPiArMQ0K PiA+DQo+ID4gT24gNi8xNS8xMyA1OjM5IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZCB3cm90ZToNCj4g Pj4gTm90IG9uIEEgdnMgQiwgYnV0IG9uIHRoZSBhZ2VuZGE6DQo+ID4+DQo+ID4+IFRoaXMgdGlt ZSBhbGxvY2F0aW9uIGlzOg0KPiA+Pg0KPiA+PiAtIDIwIG1pbnMgYWRtaW5pc3RyYXRpdmlhDQo+ ID4+IC0gMTIwIG1pbnMgcHJlc2VudGF0aW9uDQo+ID4+IC0gNDAgbWlucyBkaXNjdXNzaW9uDQo+ ID4+DQo+ID4+IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgYSB3aXNlIGFsbG9jYXRpb24uIEl0IG1h eGltaXplcyB0aGUgdGltZSBnaXZlbg0KPiA+PiB0byBwbGFuICJvd25lcnMiIHRvIHByZXNlbnQg dGhlaXIgdmlld3BvaW50cywgYW5kIG1pbmltaXplcyB0aGUgdGltZQ0KPiA+PiBhdmFsaWFibGUg Zm9yIHBlb3BsZSB3aG8gZG8gbm90ICJvd24gYSBwbGFuIiB0byBwcmVzZW50IGEgdmlld3BvaW50 Lg0KPiA+PiBQZW9wbGUgd2hvIGNvbWUgdG8gdGhlIG1lZXRpbmcgU0hPVUxEIGhhdmUgcmVhZCB0 aGUgZHJhZnRzDQo+IGJlZm9yZWhhbmQuDQo+ID4+IElmIG5vdCwgbGlzdGVuaW5nIHRvIDYwIG1p bnMgb2YgcHJlc2VudGF0aW9uIHdvbid0IG1ha2UgdGhlbQ0KPiA+PiB1bmRlcnN0YW5kIHRoZSBp c3N1ZXMuDQo+ID4+DQo+ID4+IEkgd291bGQgc3VnZ2VzdCBpbnN0ZWFkOg0KPiA+Pg0KPiA+PiAt IDEwIG1pbiBhZG1pbmlzdHJhdGl2aWEgKGFnZW5kYSBiYXNoKQ0KPiA+PiAtIDE1IG1pbiBQbGFu IEEgcHJlc2VudGF0aW9uDQo+ID4+IC0gMTUgbWluIFBsYW4gQSBjbGFyaWZpY2F0aW9uIHF1ZXN0 aW9ucw0KPiA+PiAtIDE1IG1pbiBQbGFuIEIgcHJlc2VudGF0aW9uDQo+ID4+IC0gMTUgbWluIFBs YW4gQiBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9ucw0KPiA+PiAtIDEwIG1pbiBwcmVzZW50YXRvbiBv biAid2hhdCBxdWVzdGlvbnMgZG8gd2UgbmVlZCB0byBhbnN3ZXIiIChieSB0aGUNCj4gPj4gY2hh aXJzKQ0KPiA+PiAtIDkwIG1pbiBkaXNjdXNzaW9uIG9uIGFuc3dlcmluZyB0aGUgcXVlc3Rpb25z IChzdHJ1Y3R1cmVkIGJ5IHRoZQ0KPiA+PiBjaGFpcnMpDQo+ID4+IC0gMTAgbWluIGFkbWluaXN0 cmF0aXZpYSAod3JhcHVwKQ0KPiA+Pg0KPiA+PiAoYW5kIHllcywgdGhpcyBpcyBlbm91Z2ggdGlt ZSB0aGF0IG9uZSBjb3VsZCBmaXQgaW4gYSBzbG90IGZvciAibm8gcGxhbiINCj4gPj4gdG9vKQ0K PiA+Pg0KPiA+PiAoSSdtIEhPUElORyB0aGF0IHRoZSBkcmFmdCBhZ2VuZGEgaXMgaW50ZW5kZWQg dG8gc2hvdyAicHJlc2VudGF0aW9uDQo+ID4+IGFuZCBkaXNjdXNzaW9uIiBmb3IgZWFjaCBkcmFm dCwgbm90IHdoYXQgdGhlIHdvcmRzIG9uIHRoZSBhZ2VuZGENCj4gPj4gY3VycmVudGx5IHNheS4g QnV0IGlmIG5vdCwgSSdtIGNvbnNpZGVyaW5nIHdoZXRoZXIgY2FsbGluZyBpbiAyIGhvdXJzDQo+ ID4+IGxhdGUgaXMgYSByZWFzb25hYmxlIG9wdGlvbi4pDQo+ID4+DQo+ID4+DQo+ID4+IE9uIDA2 LzE0LzIwMTMgMDg6MjAgUE0sIEFyaSBLZXLDpG5lbiB3cm90ZToNCj4gPj4+IEhpIGFsbCwNCj4g Pj4+DQo+ID4+PiBHaXZlbiB0aGUgZ3VpZGFuY2UgZnJvbSB0aGUgUlRDV0VCIFdHIGNoYWlycyB0 aGF0IHRoZSAibm8tcGxhbiINCj4gPj4+IGRpc2N1c3Npb24gc2hvdWxkIGVzc2VudGlhbGx5IGhh cHBlbiBhdCB0aGUgUlRDV0VCIFdHLCB0aGUgTU1VU0lDDQo+ID4+PiBpbnRlcmltIG1lZXRpbmcg b24gSnVuZSAxN3RoIHdpbGwgYmUgZm9jdXNlZCBvbiBQbGFuIEEgYW5kIFBsYW4gQi4NCj4gPj4+ IFRoZSBnb2FsIG9mIHRoZSBtZWV0aW5nIGlzIHRvIGNsYXJpZnkgd2hhdCBhcmUgdGhlIHR3byBk aWZmZXJlbnQNCj4gPj4+IHBsYW5zLCB3aGF0IGFyZSB0aGVpciBrZXkgZGlmZmVyZW5jZXMgYW5k IG1lcml0cywgYW5kIGhvdyBjYW4gd2UNCj4gPj4+IHNlbGVjdCBvbmUgdG8gbW92ZSBmb3J3YXJk IHdpdGguDQo+ID4+Pg0KPiA+Pj4gSGVyZSdzIHRoZSBkcmFmdCBhZ2VuZGE6DQo+ID4+Pg0KPiA+ Pj4gNzowMCDigJMgNzoxMCBBZ2VuZGEgYmFzaCAmIE5vdGUgdGFrZXJzDQo+ID4+PiA3OjEwIOKA kyA4OjEwIFBsYW4gQSBQcmVzZW50YXRpb24NCj4gPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJvYWNoLXJ0Y3dlYi1wbGFuLWEtMDANCj4gPj4+IChhbHNvDQo+ID4+PiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb2FjaC1ydGN3ZWItZ2xhcmVsZXNzLWFkZC0w MCkNCj4gPj4+IDg6MTAg4oCTIDk6MTAgUGxhbiBCIFByZXNlbnRhdGlvbg0KPiA+Pj4gIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXViZXJ0aS1ydGN3ZWItcGxhbi0wMA0KPiA+Pj4g OToxMCDigJMgOTo1MCBEaXNjdXNzaW9uIG9uIHByZWZlcnJlZCBhcHByb2FjaA0KPiA+Pj4gOTo1 MCDigJMgMTA6MDAgV3JhcC1VcCAmIE5leHQgU3RlcHMNCj4gPj4+DQo+ID4+PiBOb3RlOiBBbGwg VGltZXMgYXJlIFBhY2lmaWMgRGF5bGlnaHQgVGltZSAoUERUKQ0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiBUaGUgV2ViRXggaW5mb3JtYXRpb24gZm9yIGpvaW5pbmcgdGhlIG1lZXRpbmcgaXMgYXZhaWxh YmxlIGhlcmU6DQo+ID4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW11 c2ljL2N1cnJlbnQvbXNnMTE0ODguaHRtbA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzLA0K PiA+Pj4gQXJpICYgRmxlbW1pbmcgKE1NVVNJQyBjby1jaGFpcnMpDQo+ID4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gbW11c2ljIG1haWxp bmcgbGlzdA0KPiA+Pj4gbW11c2ljQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ ID4+IG1tdXNpY0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21tdXNpYw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ID4gbW11c2ljQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2lj IG1haWxpbmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg== From mary.ietf.barnes@gmail.com Sat Jun 15 11:22:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492A621F9E02 for ; Sat, 15 Jun 2013 11:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.269 X-Spam-Level: X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXF8xLgJ3WcD for ; Sat, 15 Jun 2013 11:22:44 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 099BB21F9E00 for ; Sat, 15 Jun 2013 11:22:43 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so961735qeb.36 for ; Sat, 15 Jun 2013 11:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0tOTs9q8m1MOObGIp0je/kp/Two5MLcODdM7kV+NykY=; b=zpJLnqvE6SQSerwWYj9WLRK4/9ON+gTYhvvbNVkjwNCaSgzlPiZjf4dA/QsHxd9aZv EnM3We/DJYOoLGdMnLQ92FZgdlBXs9eo/VV+xTKLkUhkNWi9FDo20XVW0eajMxa1X6Az y6vRuReO6jb/RWJv0xCFiS2QVsoR1a3rHIlpkZXsBCwRcde0tSrwcX/QZpyReSHYM+Mj rxWIOq+jZ6XJYO0whmFDF9Eu0E0kcISg0AALOaPQDtdUvEThkm6EPp1D9hCEStg4vVY4 PBX1eBO9wZ9l9DI73Ko67gajn+B1vcaBAvLY806cC/R0eACl8gFRVYDT0MXs3cAdVTmP T8gg== MIME-Version: 1.0 X-Received: by 10.229.106.18 with SMTP id v18mr3205083qco.49.1371320563360; Sat, 15 Jun 2013 11:22:43 -0700 (PDT) Received: by 10.49.117.130 with HTTP; Sat, 15 Jun 2013 11:22:43 -0700 (PDT) In-Reply-To: <51BC3661.6050603@alvestrand.no> References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> Date: Sat, 15 Jun 2013 13:22:43 -0500 Message-ID: From: Mary Barnes To: Harald Alvestrand Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 18:22:48 -0000 An excellent suggestion. I had been putting together an email on just this topic as it wasn't all clear to me what the objectives were and who was really leading the meeting and discussions. Mary. On Sat, Jun 15, 2013 at 4:39 AM, Harald Alvestrand w= rote: > Not on A vs B, but on the agenda: > > This time allocation is: > > - 20 mins administrativia > - 120 mins presentation > - 40 mins discussion > > I do not think this is a wise allocation. It maximizes the time given to > plan "owners" to present their viewpoints, and minimizes the time avaliab= le > for people who do not "own a plan" to present a viewpoint. > People who come to the meeting SHOULD have read the drafts beforehand. If > not, listening to 60 mins of presentation won't make them understand the > issues. > > I would suggest instead: > > - 10 min administrativia (agenda bash) > - 15 min Plan A presentation > - 15 min Plan A clarification questions > - 15 min Plan B presentation > - 15 min Plan B clarification questions > - 10 min presentaton on "what questions do we need to answer" (by the > chairs) > - 90 min discussion on answering the questions (structured by the chairs) > - 10 min administrativia (wrapup) > > (and yes, this is enough time that one could fit in a slot for "no plan" > too) > > (I'm HOPING that the draft agenda is intended to show "presentation and > discussion" for each draft, not what the words on the agenda currently sa= y. > But if not, I'm considering whether calling in 2 hours late is a reasonab= le > option.) > > > > On 06/14/2013 08:20 PM, Ari Ker=E4nen wrote: >> >> Hi all, >> >> Given the guidance from the RTCWEB WG chairs that the "no-plan" discussi= on >> should essentially happen at the RTCWEB WG, the MMUSIC interim meeting o= n >> June 17th will be focused on Plan A and Plan B. The goal of the meeting = is >> to clarify what are the two different plans, what are their key differen= ces >> and merits, and how can we select one to move forward with. >> >> Here's the draft agenda: >> >> 7:00 =96 7:10 Agenda bash & Note takers >> 7:10 =96 8:10 Plan A Presentation >> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00 >> (also http://tools.ietf.org/html/draft-roach-rtcweb-glareless-add-00) >> 8:10 =96 9:10 Plan B Presentation >> http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 >> 9:10 =96 9:50 Discussion on preferred approach >> 9:50 =96 10:00 Wrap-Up & Next Steps >> >> Note: All Times are Pacific Daylight Time (PDT) >> >> >> The WebEx information for joining the meeting is available here: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11488.html >> >> >> Regards, >> Ari & Flemming (MMUSIC co-chairs) >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Sun Jun 16 22:00:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BF921F972E for ; Sun, 16 Jun 2013 22:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDmIDkAUbr8b for ; Sun, 16 Jun 2013 22:00:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AE0B121F96D9 for ; Sun, 16 Jun 2013 22:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3341; q=dns/txt; s=iport; t=1371445230; x=1372654830; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FhmTjxBCJNzzB0Kod37f6qGiiFAqQPMKL3aEOx8aTUA=; b=hotqn2oFgOaN/IEsRHeEqiUiWZW3Q8uYgDcXL3igdRJ4PmP8khtxQ6Om W9+jVChvqO1sqHRyvMI5vVfaKFelCEKXkHatetsFFJiebOTQTmWTtv3v3 Mcbf/dZuy4s+o2y4jtzPe7lvcz/BQOia6rD6cIVJ6okuFazV/pjFtNEif g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAOAIGXvlGtJV2Z/2dsb2JhbABagwkxqyuTcAMBgQQWdIIjAQEBBAEBAS8BBTYKARALGAkWDwkDAgECARUwBg0BBQIBAQWIBQy3YI4VP3MHg2ADl0GBKZAagysggTU X-IronPort-AV: E=Sophos;i="4.87,878,1363132800"; d="scan'208";a="223535009" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jun 2013 05:00:18 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.244.239]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5H50Gg1001414; Mon, 17 Jun 2013 05:00:17 GMT Message-ID: <51BE78A7.4010203@cisco.com> Date: Sun, 16 Jun 2013 22:47:03 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Harald Alvestrand References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> In-Reply-To: <51BC3661.6050603@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 05:00:35 -0000 Our expectation is that there will be many questions and comments on each of the plan presentations as we go through them, hence the 1 hour allocation for each suggested. Furthermore, we wanted to ensure that each plan got it's fair share of time allocated to discussion. The remaining 40 mins were intended to be more open-ended discussion based on what we have heard and discussed for each plan by then. Based on the above, please let us know if folks still feel the agenda should be modified. Thanks -- Flemming On 6/15/13 5:39 AM, Harald Alvestrand wrote: > Not on A vs B, but on the agenda: > > This time allocation is: > > - 20 mins administrativia > - 120 mins presentation > - 40 mins discussion > > I do not think this is a wise allocation. It maximizes the time given > to plan "owners" to present their viewpoints, and minimizes the time > avaliable for people who do not "own a plan" to present a viewpoint. > People who come to the meeting SHOULD have read the drafts beforehand. > If not, listening to 60 mins of presentation won't make them > understand the issues. > > I would suggest instead: > > - 10 min administrativia (agenda bash) > - 15 min Plan A presentation > - 15 min Plan A clarification questions > - 15 min Plan B presentation > - 15 min Plan B clarification questions > - 10 min presentaton on "what questions do we need to answer" (by the > chairs) > - 90 min discussion on answering the questions (structured by the chairs) > - 10 min administrativia (wrapup) > > (and yes, this is enough time that one could fit in a slot for "no > plan" too) > > (I'm HOPING that the draft agenda is intended to show "presentation > and discussion" for each draft, not what the words on the agenda > currently say. But if not, I'm considering whether calling in 2 hours > late is a reasonable option.) > > > On 06/14/2013 08:20 PM, Ari Keränen wrote: >> Hi all, >> >> Given the guidance from the RTCWEB WG chairs that the "no-plan" >> discussion should essentially happen at the RTCWEB WG, the MMUSIC >> interim meeting on June 17th will be focused on Plan A and Plan B. >> The goal of the meeting is to clarify what are the two different >> plans, what are their key differences and merits, and how can we >> select one to move forward with. >> >> Here's the draft agenda: >> >> 7:00 – 7:10 Agenda bash & Note takers >> 7:10 – 8:10 Plan A Presentation >> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00 >> (also http://tools.ietf.org/html/draft-roach-rtcweb-glareless-add-00) >> 8:10 – 9:10 Plan B Presentation >> http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 >> 9:10 – 9:50 Discussion on preferred approach >> 9:50 – 10:00 Wrap-Up & Next Steps >> >> Note: All Times are Pacific Daylight Time (PDT) >> >> >> The WebEx information for joining the meeting is available here: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11488.html >> >> >> Regards, >> Ari & Flemming (MMUSIC co-chairs) >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From prvs=0880946589=christer.holmberg@ericsson.com Mon Jun 17 00:20:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8421F9AA9 for ; Mon, 17 Jun 2013 00:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.691 X-Spam-Level: X-Spam-Status: No, score=-5.691 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+wm4H5FhQAk for ; Mon, 17 Jun 2013 00:20:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7F21F9AA8 for ; Mon, 17 Jun 2013 00:20:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-ec-51beb8b0769f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FF.4C.15700.0B8BEB15; Mon, 17 Jun 2013 09:20:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 09:20:16 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: SDP O/A Open Issue: Allowed for Offerer to assign same address to multiple m- lines before Answerer has indicated BUNDLE support in SDP Answer? Thread-Index: Ac5rKvU4HJIKEKnPSluTdQKw8NKY/Q== Date: Mon, 17 Jun 2013 07:20:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C39EBE8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C39EBE8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre7GHfsCDZruclpMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BnPOk6yFyxTqLgy/Rl7A2OPTBcjJ4eEgIlEy85tTBC2mMSF e+vZuhi5OIQEDjNKXOnbygzhLGKUWLB9PmsXIwcHm4CFRPc/bZAGEQF1ia97e5hBbGGBJYwS t2/XgNSLCKxklHhz9BYjRJGexLUNr8CKWARUJT6vvQC2jVfAV2LOl1ZWEJsRaPP3U2vA4swC 4hK3nsyHukhAYsme88wQtqjEy8f/wG6QEFCUWN4vB1GeL9H8fDErxEhBiZMzn7BMYBSahWTS LCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM7LmJmTnp5YabGIGBf3DLb90d jKfOiRxilOZgURLn/XBqV6CQQHpiSWp2ampBalF8UWlOavEhRiYOThDBJdXA2GjcEBMY/S/A rWvbBbXJ7Vejfi59v0v3xt06U8WFcx0n/Sgt1O1dfrh2qXPpqd1tMQtf9/ZMVft/POfIzQMB stapf2tOTZvufSr4e1X79Wm7YuYlfV26O2FZm8RXJuHlC5xtI6NfPAm6unFG+yU9Ztn9sT6y X4UeyTkveb1+y4w9/SsPPYm04FZiKc5INNRiLipOBAAq33MeTwIAAA== Subject: [MMUSIC] BUNDLE: SDP O/A Open Issue: Allowed for Offerer to assign same address to multiple m- lines before Answerer has indicated BUNDLE support in SDP Answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 07:20:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C39EBE8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In BUNDLE-04, there are a couple of open issues associated with assigning t= he same address to multiple m=3D lines in a BUNDLE group. The main technical issue is whether it should be allowed to do it *before* = the Answerer has, in the SDP Answer, indicated support of BUNDLE. I.e. should it be allowed to, in the *initial* SDP Offer, assign the same a= ddress to multiple m=3D lines in a BUNDLE group? Paul has indicated that it should be allowed, if the Offerer e.g. "knows" t= hat the environment where it is operating in supports BUNDLE. Now, as that is very similar to my original BUNDLE proposal, I would like t= o hear what others (especially Cullen) thinks about it. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C39EBE8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In BUNDLE-04, there are a couple of open issues asso= ciated with assigning the same address to multiple m=3D lines in a BUNDLE g= roup.

 

The main technical issue is whether it should be all= owed to do it *before* the Answerer has, in the SDP Answer, indicate= d support of BUNDLE.

 

I.e. should it be allowed to, in the *initial= * SDP Offer, assign the same address to multiple m=3D lines in a BUNDLE gro= up?

 

Paul has indicated that it should be allowed, if the= Offerer e.g. “knows” that the environment where it is operatin= g in supports BUNDLE.

 

Now, as that is very similar to my original BUNDLE p= roposal, I would like to hear what others (especially Cullen) thinks about = it.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C39EBE8ESESSMB209erics_-- From harald@alvestrand.no Mon Jun 17 00:40:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EEB21F9AC2 for ; Mon, 17 Jun 2013 00:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IDByEoKYav5 for ; Mon, 17 Jun 2013 00:40:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E76BD21F9AA3 for ; Mon, 17 Jun 2013 00:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4AB9D39E0F0; Mon, 17 Jun 2013 09:40:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHrt4jktGiQE; Mon, 17 Jun 2013 09:40:33 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 880E939E05D; Mon, 17 Jun 2013 09:40:33 +0200 (CEST) Message-ID: <51BEBD70.7010300@alvestrand.no> Date: Mon, 17 Jun 2013 09:40:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Flemming Andreasen References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> <51BE78A7.4010203@cisco.com> In-Reply-To: <51BE78A7.4010203@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 07:40:43 -0000 On 06/17/2013 04:47 AM, Flemming Andreasen wrote: > Our expectation is that there will be many questions and comments on > each of the plan presentations as we go through them, hence the 1 hour > allocation for each suggested. Furthermore, we wanted to ensure that > each plan got it's fair share of time allocated to discussion. The > remaining 40 mins were intended to be more open-ended discussion based > on what we have heard and discussed for each plan by then. > > Based on the above, please let us know if folks still feel the agenda > should be modified. If the purpose is to inform people about the plans, that's a fine agenda. If the purpose is to find out whether there's a chance we can find consensus around one plan, another plan or a third plan, I think the agenda is not suited for that purpose. Since the point of having an IETF process is to get to decisions, and the point of having interims is to further the IETF process, I still think we could allocate more time to what's important. This issue's been festering for a year at least. We need to stop informing ourselves and find a consensus. From randell-ietf@jesup.org Mon Jun 17 04:32:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290EA21F9BE5 for ; Mon, 17 Jun 2013 04:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxHoch5upHLT for ; Mon, 17 Jun 2013 04:32:12 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 60C2821F9BBD for ; Mon, 17 Jun 2013 04:31:58 -0700 (PDT) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2672 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UoXf7-00023b-I0 for mmusic@ietf.org; Mon, 17 Jun 2013 06:31:53 -0500 Message-ID: <51BEF348.8000603@jesup.org> Date: Mon, 17 Jun 2013 07:30:16 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <51BB5EFE.5090903@ericsson.com> <51BC3661.6050603@alvestrand.no> <51BE78A7.4010203@cisco.com> <51BEBD70.7010300@alvestrand.no> In-Reply-To: <51BEBD70.7010300@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 11:32:23 -0000 +1 Try to make progress towards a decision (or, gasp, an actual decision) On 6/17/2013 3:40 AM, Harald Alvestrand wrote: > On 06/17/2013 04:47 AM, Flemming Andreasen wrote: >> Our expectation is that there will be many questions and comments on >> each of the plan presentations as we go through them, hence the 1 >> hour allocation for each suggested. Furthermore, we wanted to ensure >> that each plan got it's fair share of time allocated to discussion. >> The remaining 40 mins were intended to be more open-ended discussion >> based on what we have heard and discussed for each plan by then. >> >> Based on the above, please let us know if folks still feel the agenda >> should be modified. > > If the purpose is to inform people about the plans, that's a fine agenda. > > If the purpose is to find out whether there's a chance we can find > consensus around one plan, another plan or a third plan, I think the > agenda is not suited for that purpose. > > Since the point of having an IETF process is to get to decisions, and > the point of having interims is to further the IETF process, I still > think we could allocate more time to what's important. > > This issue's been festering for a year at least. We need to stop > informing ourselves and find a consensus. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Randell Jesup randell-ietf@jesup.org From prvs=88805484a4=ari.keranen@ericsson.com Mon Jun 17 07:18:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476721F9C92 for ; Mon, 17 Jun 2013 07:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfdwJ6ojIaqf for ; Mon, 17 Jun 2013 07:18:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF3EE21F9C1B for ; Mon, 17 Jun 2013 07:18:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-f2-51bf1aaae5e1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7B.72.15700.AAA1FB15; Mon, 17 Jun 2013 16:18:18 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 17 Jun 2013 16:18:18 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 638B211041D; Mon, 17 Jun 2013 17:18:18 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 071D0552F5; Mon, 17 Jun 2013 17:18:16 +0300 (EEST) Received: from as-macbook-air.elisa (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 97BCB53000; Mon, 17 Jun 2013 17:18:15 +0300 (EEST) Message-ID: <51BF1AA8.2020902@ericsson.com> Date: Mon, 17 Jun 2013 17:18:16 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvre4qqf2BBk9vGlu8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmK2yYpsaQsODM9T98ugTtj4vsZTAXzmSqunJJrYGxm6mLk5JAQMJH4 vXkOK4QtJnHh3nq2LkYuDiGBU4wS/ZdgnA2MEp2981lAqoQE9jJKNL4KhUisY5TYfWsiE4Sz glFi25V9YLN4BbQlrtw5xNzFyMHBIqAq0fBPHiTMJmAvcXPCdXYQW1QgWeJAfztUuaDEyZlP wBaICMhI7N20mRnEZgYaM/vOLCaQMcICmhJf5hVAhG0lLsy5zgJhy0tsfzuHGeIDNYmr5zYx Q9ypKnH13yvGCYzCs5BsmIWkfRaS9gWMzKsY2XMTM3PSyw03MQJD+OCW37o7GE+dEznEKM3B oiTO++HUrkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBcaZpZ3eo/+5gz2dfP69be7A9 bqW/zFPt1oSWAFaGZftvp2g83ue7dAXTWvaT++5GvShN/bf0Bu+n1F1xQcblpd4iE1bxm+Xv aLSz1RN97hvho+lZLfB8ze8ksbTT3w5nHq53Pa960k1M4/mmLbEKGx6kRa+PcFS60vFBVHhX Jk/+F98V0/rVlViKMxINtZiLihMB0ElpsjQCAAA= Cc: Flemming Andreasen Subject: [MMUSIC] Virtual interim meeting material X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 14:18:29 -0000 Virtual interim meeting material available here: http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/proceedings.html Chair slides with agenda proposal(s): http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt Cheers, Ari From martin.thomson@gmail.com Mon Jun 17 09:27:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5391121F9B64 for ; Mon, 17 Jun 2013 09:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x92oUGA2p1V2 for ; Mon, 17 Jun 2013 09:26:59 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 06FDD21F9BB5 for ; Mon, 17 Jun 2013 09:26:56 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so2552894wgh.33 for ; Mon, 17 Jun 2013 09:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vL4yQDMbs+7da+Owc2HNqvaU2jWn0cqXNWaJZmO7ISc=; b=j4eqswFvfIL7eYCaoEZ7ryIb+4sQ3M964/FSrM53oJKbpLhMOv/uMBahMfbbywD+RG HjTPUhjk04Q0HLDJH/gqJVx5BjrolpAKgTbpzrZjv6d54PkeWSF15DoSAIfRVJGXVhHu ipqMhYDL3jxjh5DsTgxRdOQI885izIUyebaZnOAlt06W71IPcMX/VKdEA1vGK2Tn7WSd 9SSkT7aYjTGsMhBkaipS0y6E0oENGtKEqyp8be8mYb3IxThEwHNAvm0MMsX1Xc/0QsZB on4gfKqiz5XYDEFj/Y56/tplsvtVxLEh/kmyfOMLwef0RRQ5ZZOs6JYp8I1+3A0gyT7P WyQQ== MIME-Version: 1.0 X-Received: by 10.180.78.35 with SMTP id y3mr5276986wiw.65.1371486409463; Mon, 17 Jun 2013 09:26:49 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 17 Jun 2013 09:26:49 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C39EBE8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C39EBE8@ESESSMB209.ericsson.se> Date: Mon, 17 Jun 2013 09:26:49 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: SDP O/A Open Issue: Allowed for Offerer to assign same address to multiple m- lines before Answerer has indicated BUNDLE support in SDP Answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 16:27:02 -0000 On 17 June 2013 00:20, Christer Holmberg wrote: > whether it should be allowed to do it *before* the Answerer has, in the SDP > Answer, indicated support of BUNDLE. I have no problem with allowing this, though I think that it requires a reasonable amount of text to ensure that the risks are known. From bernard_aboba@hotmail.com Mon Jun 17 10:20:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE921F8904 for ; Mon, 17 Jun 2013 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8usWyuTAjz2T for ; Mon, 17 Jun 2013 10:20:22 -0700 (PDT) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfa.amsl.com (Postfix) with ESMTP id E3C4121F9D7C for ; Mon, 17 Jun 2013 10:20:21 -0700 (PDT) Received: from BLU169-W63 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 10:20:22 -0700 X-TMN: [DlFIs4K8SUd9J5UOOuxhrBPEJuvgmoPC] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_8822d53b-3182-4b19-a318-79dba360d801_" From: Bernard Aboba To: "mmusic@ietf.org" Date: Mon, 17 Jun 2013 10:20:21 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2013 17:20:22.0024 (UTC) FILETIME=[F2953880:01CE6B7E] Subject: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 17:20:28 -0000 --_8822d53b-3182-4b19-a318-79dba360d801_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the virtual interim=2C a question arose about RFC 6190 Single Session Tr= ansport.=20 Here is what RFC 6190 Section 1 says: This memo defines two basic modes for transmission of SVC data=2C=0A= single-session transmission (SST) and multi-session transmission=0A= (MST). In SST=2C a single RTP session is used for the transmission of= =0A= all scalability layers comprising an SVC bitstream=3B in MST=2C the=0A= scalability layers are transported on different RTP sessions. Section 1.= 2.2 clarifies the usage scenarios of SST and MST: =0A= SST should be used in point-to-point unicast applications and=2C in=0A= general=2C whenever the potential benefit of using multiple RTP=0A= sessions does not justify the added complexity... =0A= =0A= MST should be used in a multicast session when different receivers=0A= may request different layers of the scalable bitstream. Since SST impli= es (by definition)=2C use of a single RTP session to transport multiple lay= ers=2C were plan A to be used for signaling=2C negotiation of SST would onl= y be possible if both peers support BUNDLE=2C since otherwise distinct RTP = ports would be required for each layer=2C which is incompatible with SST. = Today=2C existing SST implementations typically utilize a single m line. = As Jonathan noted=2C some implementations utilize the same SSRC for multip= le layers=2C while others utilize distinct SSRCs. Utilization of the same = SSRC is possible=2C since separation of the layers can be handled within th= e H.264/SVC implementation. = --_8822d53b-3182-4b19-a318-79dba360d801_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At the virtual interim=2C a ques= tion arose about RFC 6190 Single Session Transport. =3B

<= div>Here is what RFC 6190 Section 1 says:

   This memo defi=
nes two basic modes for transmission of SVC data=2C=0A=
   single-session transmission (SST) and multi-session transmission=0A=
   (MST).  In SST=2C a single RTP session is used for the transmission of=
=0A=
   all scalability layers comprising an SVC bitstream=3B in MST=2C the=0A=
   scalability layers are transported on different RTP sessions.
Section 1.2.= 2 clarifies the usage scenarios of SST and MST: 
=0A=
   SST should be used in point-to-point unicast applications and=2C in=0A=
   general=2C whenever the potential benefit of using multiple RTP=0A=
   sessions does not justify the added complexity...  =0A=
=0A=
   MST should be used in a multicast session when different receivers=0A=
   may request different layers of the scalable bitstream.  
Since SST implies =
(by definition)=2C use of a single RTP session to transport multiple layers=
=2C were plan A to be used for signaling=2C negotiation of SST would only b=
e possible if both peers support BUNDLE=2C since otherwise distinct RTP por=
ts would be required for each layer=2C which is incompatible with SST.    <=
/pre>
Toda=
y=2C existing SST implementations typically utilize a single m line.  As Jo=
nathan noted=2C some implementations utilize the same SSRC for multiple lay=
ers=2C while others utilize distinct SSRCs. =3B Utilization of the same=
 SSRC is possible=2C since separation of the layers can be handled within t=
he H.264/SVC implementation.

= --_8822d53b-3182-4b19-a318-79dba360d801_-- From internet-drafts@ietf.org Mon Jun 17 10:30:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E68221F9DAB; Mon, 17 Jun 2013 10:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcS2dxcbE3Uy; Mon, 17 Jun 2013 10:30:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6571121F9D8B; Mon, 17 Jun 2013 10:29:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130617172952.5261.30154.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 10:29:52 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:30:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Offer/Answer Considerations for G723 Annex A and G729 An= nex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-03.txt Pages : 8 Date : 2013-06-17 Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adam@nostrum.com Mon Jun 17 10:32:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7F21F9B5D for ; Mon, 17 Jun 2013 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZk6SIFvtmS3 for ; Mon, 17 Jun 2013 10:32:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20821F96D9 for ; Mon, 17 Jun 2013 10:32:51 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5HHWluF081470 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 12:32:47 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51BF483E.3080606@nostrum.com> Date: Mon, 17 Jun 2013 12:32:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 17:32:52 -0000 On 6/17/13 12:20, Bernard Aboba wrote: > Since SST implies (by definition), use of a single RTP session to transport multiple layers, were plan A to be used for signaling, negotiation of SST would only be possible if both peers support BUNDLE, since otherwise distinct RTP ports would be required for each layer, which is incompatible with SST. I don't think that assertion has a basis in reality, but I could simply be misunderstanding what you're trying to say. English is imprecise, and it's clear that we're not having a meeting of minds here. Let's try a different language. You send an e-mail to the list containing the SDP currently exchanged by SIP endpoints for SST. I'll send SDP in an e-mail reply that shows how it works under Plan A. Sound good? /a From mzanaty@cisco.com Mon Jun 17 11:39:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C778A21F9D8D for ; Mon, 17 Jun 2013 11:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezhO0N3XOR-H for ; Mon, 17 Jun 2013 11:38:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6D21F9D88 for ; Mon, 17 Jun 2013 11:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11048; q=dns/txt; s=iport; t=1371494336; x=1372703936; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+07TEalJFideO0sQjENhrpQHrenQaQeHQvJKJSikcZs=; b=L+rnFJIXAimGpzbCgXPLObrzRXc2BJySmJNi5Ta1CRPBKrEG5KzkVl81 HlutX59rQNUB87BwihUslOM5MbdaqIbifVxwOzkkiNbziqjmzRIt2D1tz KHQG+myawXOjbdUb/IQYHKLwCLEeVzbA/WXFHh0GXMq19IhKRNDjWMMOi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFACVXv1GtJXHB/2dsb2JhbABbgkVEMUm+fX4WdIIjAQEBBC1cAgEIEQQBAQsdBzIUCQgCBAESCIgGuhWPFjcBgn9hA5NvlRWDD4Io X-IronPort-AV: E=Sophos;i="4.87,882,1363132800"; d="scan'208,217";a="220876576" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jun 2013 18:38:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5HIcsMw030440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 18:38:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 13:38:54 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 6190 Single Session Transport Thread-Index: AQHOa38I8DtzGW8/TUuvjDTdB8v21Jk6MqQw Date: Mon, 17 Jun 2013 18:38:54 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.46] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D487E63xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 18:39:01 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D487E63xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My understanding of 6190 SST is a single SSRC for all layers, not multiple = SSRCs (one per layer) within one RTP session. 6190 doesn't state this clear= ly, but otherwise SST would need all the same mst-mode stuff as MST, since = mst-mode defines how receivers put packets into decoding order from multipl= e streams based on timestamps or Cross-Session Decoding Order Numbers (CS-D= ON). I think you may be referring to the common industry practice of MST using t= he same port and thus the same RTP session, i.e. Multi-SSRC (rather than Se= ssion) Transmission. That is not standardized in 6190, but often used in pr= actice. This often uses a single m-line, so it has no BUNDLE dependency. If= it used multiple m-lines, your argument would be true for that case. BUNDL= E (or some similar mechanism to mux m-lines onto one port) would be require= d for that type of MST to use the same port. But that does not seem to be a= limitation of Plan A, since some mux mechanism is always required to do th= at type of MST regardless of Plan A. Mo From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Monday, June 17, 2013 1:20 PM To: mmusic@ietf.org Subject: [MMUSIC] RFC 6190 Single Session Transport At the virtual interim, a question arose about RFC 6190 Single Session Tran= sport. Here is what RFC 6190 Section 1 says: This memo defines two basic modes for transmission of SVC data, single-session transmission (SST) and multi-session transmission (MST). In SST, a single RTP session is used for the transmission of all scalability layers comprising an SVC bitstream; in MST, the scalability layers are transported on different RTP sessions. Section 1.2.2 clarifies the usage scenarios of SST and MST: SST should be used in point-to-point unicast applications and, in general, whenever the potential benefit of using multiple RTP sessions does not justify the added complexity... MST should be used in a multicast session when different receivers may request different layers of the scalable bitstream. Since SST implies (by definition), use of a single RTP session to transport= multiple layers, were plan A to be used for signaling, negotiation of SST = would only be possible if both peers support BUNDLE, since otherwise distin= ct RTP ports would be required for each layer, which is incompatible with S= ST. Today, existing SST implementations typically utilize a single m line. As = Jonathan noted, some implementations utilize the same SSRC for multiple lay= ers, while others utilize distinct SSRCs. Utilization of the same SSRC is = possible, since separation of the layers can be handled within the H.264/SV= C implementation. --_000_3879D71E758A7E4AA99A35DD8D41D3D91D487E63xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My understanding of 6190 SST is a singl= e SSRC for all layers, not multiple SSRCs (one per layer) within one RTP se= ssion. 6190 doesn’t state this clearly, but otherwise SST would need all the same mst-mode stuff as MST, since mst-mode defines how = receivers put packets into decoding order from multiple streams based on ti= mestamps or Cross-Session Decoding Order Numbers (CS-DON).

 

I think you may be referring to the com= mon industry practice of MST using the same port and thus the same RTP sess= ion, i.e. Multi-SSRC (rather than Session) Transmission. That is not standardized in 6190, but often used in practice. This often u= ses a single m-line, so it has no BUNDLE dependency. If it used multiple m-= lines, your argument would be true for that case. BUNDLE (or some similar m= echanism to mux m-lines onto one port) would be required for that type of MST to use the same port. But tha= t does not seem to be a limitation of Plan A, since some mux mechanism is a= lways required to do that type of MST regardless of Plan A.

 

Mo

 

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, June 17, 2013 1:20 PM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 6190 Single Session Transport

 

At the virtual interim, a question arose about RFC 6190 = Single Session Transport. 

 

Here is what RFC 6190 Section 1 says:<= /p>

 

   This=
 memo defines two basic modes for transmission of SVC data,

   single-session transmission (SST) and multi-session trans=
mission


   (MST).  In SST, a single RTP session is used for the=
 transmission of


   all scalability layers comprising an SVC bitstream; in MS=
T, the


   scalability layers are transported on different RTP sessi=
ons. 


Sect=
ion 1.2.2 clarifies the usage scenarios of SST and MST: <=
/pre>

 =



   SST should be used in point-to-point unicast applications=
 and, in


   general, whenever the potential benefit of using multiple=
 RTP


   sessions does not justify the added complexity...  <=
o:p>


 


   MST should be used in a multicast session when different =
receivers


   may request different layers of the scalable bitstream.&n=
bsp; 


Since SST implies=
 (by definition), use of a single RTP session to transport multiple layers,=
 were plan A to be used for signaling, negotiation of SST would only be pos=
sible if both peers support BUNDLE, since otherwise distinct RTP ports woul=
d be required for each layer, which is incompatible with SST.  &n=
bsp; 


Today, existing S=
ST implementations typically utilize a single m line.  As Jonathan not=
ed, some implementations utilize the same SSRC for multiple layers, while o=
thers utilize distinct SSRCs.  Utilization of the same SSRC is possibl=
e, since separation of the layers can be handled within the H.264/SVC imple=
mentation.


 =
--_000_3879D71E758A7E4AA99A35DD8D41D3D91D487E63xmbrcdx14ciscoc_-- From bernard_aboba@hotmail.com Mon Jun 17 11:40:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1F921F9D8E for ; Mon, 17 Jun 2013 11:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXRs3tTH+Sxm for ; Mon, 17 Jun 2013 11:40:11 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by ietfa.amsl.com (Postfix) with ESMTP id BBBB321F9D88 for ; Mon, 17 Jun 2013 11:40:11 -0700 (PDT) Received: from BLU169-W73 ([65.55.111.73]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 11:40:10 -0700 X-TMN: [fZOKAW8Bu5kgbTLcKt6OWKkFZ2W3e3AN] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_829beca7-0664-4917-9b0c-807c5b1601cd_" From: Bernard Aboba To: Adam Roach Date: Mon, 17 Jun 2013 11:40:10 -0700 Importance: Normal In-Reply-To: <51BF483E.3080606@nostrum.com> References: , <51BF483E.3080606@nostrum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2013 18:40:10.0945 (UTC) FILETIME=[19009310:01CE6B8A] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 18:40:17 -0000 --_829beca7-0664-4917-9b0c-807c5b1601cd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > English is imprecise=2C and it's clear that we're not having a meeting of= =20 > minds here. Let's try a different language. You send an e-mail to the=20 > list containing the SDP currently exchanged by SIP endpoints for SST.=20 [BA] Several examples are provided in RFC 6190 Section 7.3.=20 Section 7.3.1: Offer of both H.264/AVC and H.264/SVC on the same m-line.Se= ction 7.3.2: Offer of H.264/SVC with a single payload type. Section 7.3.5:= Offer of H.264/SVC with multiple payload types=2C supporting differing le= vels and packetization modes.=20 Note that none of the examples use either a=3Dssrc or multiple m lines to d= escribe the layers.=20 > I'll send SDP in an e-mail reply that shows how it works under Plan A. >=20 > Sound good? [BA] OK. = --_829beca7-0664-4917-9b0c-807c5b1601cd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B English is imprecise=2C and it's clear that we're not having a= meeting of =3B
>=3B minds here. Let's try a different= language. You send an e-mail to the
>=3B list containing the SDP cur= rently exchanged by SIP endpoints for SST. =3B

[BA] Several examples are provided in RFC 6190 Section 7.3. =3B
<= div>
Section 7.3.1:  =3BOffer of both H.264/AVC and H.264= /SVC on the same m-line.
Section 7.3.2:  =3BOffer of H.264/SV= C with a single payload type. =3B
Section 7.3.5: =3B =3BOffer of H.264/SVC with multiple pay= load types=2C supporting differing levels and packetization modes. =3B<= /span>

= Note that none of the examples use either a=3Dssrc or multiple m lines to d= escribe the layers. =3B

>=3B I'll send SDP in an e-mail reply that= shows how it works under Plan A.
>=3B
>=3B Sound good?

<= /div>
[BA] OK. =3B
= --_829beca7-0664-4917-9b0c-807c5b1601cd_-- From jonathan@vidyo.com Mon Jun 17 12:34:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46CC21E8053 for ; Mon, 17 Jun 2013 12:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHFAmdjy68jT for ; Mon, 17 Jun 2013 12:34:15 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 6D11B21F9BAA for ; Mon, 17 Jun 2013 12:34:15 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id ACF538BE42F; Mon, 17 Jun 2013 15:34:07 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 5E5F58BE297; Mon, 17 Jun 2013 15:34:06 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Mon, 17 Jun 2013 15:34:13 -0400 From: Jonathan Lennox To: "Mo Zanaty (mzanaty)" Date: Mon, 17 Jun 2013 15:34:12 -0400 Thread-Topic: [MMUSIC] RFC 6190 Single Session Transport Thread-Index: Ac5rkY1Ghe+vY6dOSiCfbnJvNVbV/w== Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EE556E4654C14AABB03A56FB8971D8A2vidyocom_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 19:34:19 -0000 --_000_EE556E4654C14AABB03A56FB8971D8A2vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This was certainly my understanding of RFC 6190 as well, from heavy partici= pation in its standardization in AVT. I don't understand how single-session multi-source transmission will work w= ithout either a) signaling "a=3Dssrc-group DDP" decoding dependencies, or b= ) making various implementation-specific assumptions about the structure of= the SVC streams. On Jun 17, 2013, at 2:38 PM, Mo Zanaty (mzanaty) > wrote: My understanding of 6190 SST is a single SSRC for all layers, not multiple = SSRCs (one per layer) within one RTP session. 6190 doesn=92t state this cle= arly, but otherwise SST would need all the same mst-mode stuff as MST, sinc= e mst-mode defines how receivers put packets into decoding order from multi= ple streams based on timestamps or Cross-Session Decoding Order Numbers (CS= -DON). I think you may be referring to the common industry practice of MST using t= he same port and thus the same RTP session, i.e. Multi-SSRC (rather than Se= ssion) Transmission. That is not standardized in 6190, but often used in pr= actice. This often uses a single m-line, so it has no BUNDLE dependency. If= it used multiple m-lines, your argument would be true for that case. BUNDL= E (or some similar mechanism to mux m-lines onto one port) would be require= d for that type of MST to use the same port. But that does not seem to be a= limitation of Plan A, since some mux mechanism is always required to do th= at type of MST regardless of Plan A. Mo From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Monday, June 17, 2013 1:20 PM To: mmusic@ietf.org Subject: [MMUSIC] RFC 6190 Single Session Transport At the virtual interim, a question arose about RFC 6190 Single Session Tran= sport. Here is what RFC 6190 Section 1 says: This memo defines two basic modes for transmission of SVC data, single-session transmission (SST) and multi-session transmission (MST). In SST, a single RTP session is used for the transmission of all scalability layers comprising an SVC bitstream; in MST, the scalability layers are transported on different RTP sessions. Section 1.2.2 clarifies the usage scenarios of SST and MST: SST should be used in point-to-point unicast applications and, in general, whenever the potential benefit of using multiple RTP sessions does not justify the added complexity... MST should be used in a multicast session when different receivers may request different layers of the scalable bitstream. Since SST implies (by definition), use of a single RTP session to transport= multiple layers, were plan A to be used for signaling, negotiation of SST = would only be possible if both peers support BUNDLE, since otherwise distin= ct RTP ports would be required for each layer, which is incompatible with S= ST. Today, existing SST implementations typically utilize a single m line. As = Jonathan noted, some implementations utilize the same SSRC for multiple lay= ers, while others utilize distinct SSRCs. Utilization of the same SSRC is = possible, since separation of the layers can be handled within the H.264/SV= C implementation. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic -- Jonathan Lennox jonathan@vidyo.com --_000_EE556E4654C14AABB03A56FB8971D8A2vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This was certainly my understanding of RFC 6190 as well, from he= avy participation in its standardization in AVT.

I= don't understand how single-session multi-source transmission will work wi= thout either a) signaling "a=3Dssrc-group DDP" decoding dependencies, or b)= making various implementation-specific assumptions about the structure of = the SVC streams. 

On Jun 17, 2013, at 2:38 PM, Mo Z= anaty (mzanaty) <mzanaty@cisco.com<= /a>> wrote:

My understanding of 6190 SST is a= single SSRC for all layers, not multiple SSRCs (one per layer) within one = RTP session. 6190 doesn=92t state this clearly, but otherwise SST would nee= d all the same mst-mode stuff as MST, since mst-mode defines how receivers = put packets into decoding order from multiple streams based on timestamps o= r Cross-Session Decoding Order Numbers (CS-DON).
 
I think you may be referrin= g to the common industry practice of MST using the same port and thus the s= ame RTP session, i.e. Multi-SSRC (rather than Session) Transmission. That i= s not standardized in 6190, but often used in practice. This often uses a s= ingle m-line, so it has no BUNDLE dependency. If it used multiple m-lines, = your argument would be true for that case. BUNDLE (or some similar mechanis= m to mux m-lines onto one port) would be required for that type of MST to u= se the same port. But that does not seem to be a limitation of Plan A, sinc= e some mux mechanism is always required to do that type of MST regardless o= f Plan A.
 
Mo
 
=
Fr= om: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, June 17, 2013 1:20 PM
To: mmusic@i= etf.org
Subject: <= /span>[MMUSIC] RFC 6190 Single Session Transport
 
At the virtual i= nterim, a question arose about RFC 6190 Single Session Transport. 
 
Here is what RFC 6190 = Section 1 says:
 
<= div>
   =
This memo defines two basic modes for transmission of SVC data,<=
/pre>
   single-session transmission (SST) and multi-s=
ession transmission
   (MST).  I=
n SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstrea=
m; in MST, the
   scalability layers =
are transported on different RTP sessions. 
Section 1.2.2 clarifies the usage scena=
rios of SST and MST: 
 
  =
 SST should be used in point-to-point unicast applications and, in
   general, whenever the potential benefit of=
 using multiple RTP
   sessions does =
not justify the added complexity...  
 
   MST should be used in a multica=
st session when different receivers
  =
; may request different layers of the scalable bitstream.  =

Since SST i=
mplies (by definition), use of a single RTP session to transport multiple l=
ayers, were plan A to be used for signaling, negotiation of SST would only =
be possible if both peers support BUNDLE, since otherwise distinct RTP port=
s would be required for each layer, which is incompatible with SST. &n=
bsp;  
Today, existing SST implementations typically utilize a single m=
 line.  As Jonathan noted, some implementations utilize the same SSRC =
for multiple layers, while others utilize distinct SSRCs.  Utilization=
 of the same SSRC is possible, since separation of the layers can be handle=
d within the H.264/SVC implementation.
 
_______________________________________________
mmusic mailing list<= br>mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_EE556E4654C14AABB03A56FB8971D8A2vidyocom_-- From prvs=7880b06e38=ari.keranen@ericsson.com Mon Jun 17 16:01:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5A921F9E75 for ; Mon, 17 Jun 2013 16:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.493 X-Spam-Level: X-Spam-Status: No, score=-5.493 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHFJ19Bf+FZx for ; Mon, 17 Jun 2013 16:01:44 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C760F21F9C78 for ; Mon, 17 Jun 2013 16:01:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-21-51bf9555a794 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 35.A5.18006.5559FB15; Tue, 18 Jun 2013 01:01:42 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 18 Jun 2013 01:01:41 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CC3531103EE; Tue, 18 Jun 2013 02:01:41 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 66D745530B; Tue, 18 Jun 2013 02:01:39 +0300 (EEST) Received: from as-macbook-air.elisa (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0399F5522E; Tue, 18 Jun 2013 02:01:38 +0300 (EEST) Message-ID: <51BF9554.9050907@ericsson.com> Date: Tue, 18 Jun 2013 02:01:40 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvrW7Y1P2BBvt7eS16TyxgtJi6/DGL A5PHkiU/mTy+XP7MFsAUxW2TlFhSFpyZnqdvl8Cd8X7FZ/aCY8wVHU9vsDUwvmXqYuTkkBAw kfjx7SkLhC0mceHeerYuRi4OIYFTjBI7py5ghnA2MErcuvyYHcLZyygx4WgvE4SzjlFi4vwn jBDOCkaJTWvPM4IM4xXQlrjwsIsVxGYRUJXYsPMl2EI2AXuJmxOus4PYogLJEgf621kh6gUl Ts58AnaIiIC6xNe9PcwgNrOAkcSvB+vAaoSBjt07swUqbitxYc51FghbXmL72znMEE+oSVw9 twnMFgLae/XfK8YJjMKzkKyYhaR9FpL2BYzMqxjZcxMzc9LLjTYxAoP54JbfqjsY75wTOcQo zcGiJM778dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoFRYfKG1czHd7KrHUhQdEyz z9i8g7N+T2HKgqYrbM0WE9el93IstFZXP+MaF2WdoVUq92vulhdKezYsmrV8U23b7pxjm3fv MPwm+p8hQygusPj35lsmzZE3kq41P7JlZ054mvQtwXTpoZ2J87ZtiUw+cPVyS9ZC1XO5nCJG /Je2rTm3sfXLliwmJZbijERDLeai4kQAq6SdqzkCAAA= Cc: draft-ietf-mmusic-sdp-g723-g729@tools.ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-g723-g729-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 23:01:49 -0000 This is to start a 2-week Working Group Last Call for draft-ietf-mmusic-sdp-g723-g729-03 The WGLC ends on July 2nd, 2013. Please review the document and send your comments both to the authors and to the MMUSIC mailing list. If you review the document but do not have any comments, please send a note to that effect as well. The document is available here: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-03 Thanks, Ari From bill.wu@huawei.com Mon Jun 17 21:00:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DB421F934B; Mon, 17 Jun 2013 21:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBwhgnJyPU4h; Mon, 17 Jun 2013 21:00:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3C4621F8BC0; Mon, 17 Jun 2013 21:00:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASO00947; Tue, 18 Jun 2013 04:00:32 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 18 Jun 2013 04:59:33 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 18 Jun 2013 05:00:01 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Tue, 18 Jun 2013 11:59:57 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , "draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 Thread-Index: AQHOaC1ph9U9h2APCkePCuLeXl6Adpk63U2w Date: Tue, 18 Jun 2013 03:59:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43B4200Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: xrblock-chairs , mmusic , 'xrblock' Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 04:00:49 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43B4200Ankgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikgW21haWx0bzphYmVnZW5AY2lzY28uY29tXQ0K U2VudDogVGh1cnNkYXksIEp1bmUgMTMsIDIwMTMgNzo1OCBQTQ0KVG86IFFpbiBXdTsgZHJhZnQt aWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xzLmlldGYub3JnDQpDYzogeHJibG9jay1jaGFp cnM7IG1tdXNpYzsgJ3hyYmxvY2snDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gU0RQIERpcmVjdG9y YXRlOiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTA4DQoNCg0KDQot IEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudDoNCg0KICAgSW5mb3Jt YXRpb24gaXMgcmVjb3JkZWQgYWJvdXQgUW9FIG1ldHJpYyB3aGljaCBwcm92aWRlcyBhDQogICBt ZWFzdXJlIHRoYXQgaXMgaW5kaWNhdGl2ZSBvZiB0aGUgdXNlcidzIHZpZXcgb2YgYSBzZXJ2aWNl Lg0KDQpUaGUgYXBwbGljYXRpb24gY2Fubm90IHBvc3NpYmx5IGtub3cgYSB1c2VyJ3MgdmlldyBv ZiBzZXJ2aWNlIHVubGVzcyB0aGUgdXNlciBleHBsaWNpdGx5IGVudGVycyB0aGF0IGluZm8gaW4g c29tZSBmYXNoaW9uIHRvIHRoZSBhcHBsaWNhdGlvbi4NCg0KW1Fpbl06ICBUaGUgYXBwbGljYXRp b24gY2FuIHJlbHkgb24gUW9FIGV2YWx1YXRpb24gbW9kZWwgdG8gY2FsY3VsYXRlIE1vUyB2YWx1 ZSBhbmQgdXNlIHN1Y2ggTW9TIHZhbHVlIHRvIHJlZmxlY3QgaG93IGVuZCB1c2VyIGZlZWwgb3Ig ZXhwZXJpZW5jZSB0aGUgbWVkaWEgcXVhbGl0eS4gVGhhdOKAmXMgd2hhdCB0aGlzIHN0YXRlbWVu dCB3YW50DQp0byBjb252ZXkuDQoNClRoYXQgaXMgbm90IHdoYXQgdGhlIHNlbnRlbmNlIHNheXMs IHRob3VnaCwgYXQgbGVhc3QgdG8gbWUuIFRoZSAidXNlcidzIHZpZXcgb2YgYSBzZXJ2aWNlIiBp cyB0aGUgdHJvdWJsaW5nIHBhcnQgdG8gbWUuIFdoYXQgeW91IGRvIGlzIHRoYXQgeW91IGFwcGx5 IGFuIGFsZ29yaXRobSB3aXRoIHNvbWUgb2JzZXJ2ZWQgdmFsdWVzIGFuZCB5b3UgdHJ5IHRvIGVz dGltYXRlIHNvbWUgc29ydCBvZiBhIG1lYW4gb3BpbmlvbiBzY29yZS4gVGhhdCBtYXkgb3IgbWF5 IG5vdCBiZSBpbmRpY2F0aXZlIG9mIHRoZSBlbmQtdXNlcidzIFFvRS4NCg0KW1Fpbl06IEkgZ2V0 IHlvdXIgcG9pbnQuIE1heWJlIHdlIGNhbiByZXBocmFzZSB0aGlzIHNlbnRlbmNlIGFzIGZvbGxv d3M6DQpPTEQgVEVYVDoNCuKAnA0KSW5mb3JtYXRpb24gaXMgcmVjb3JkZWQgYWJvdXQgUW9FIG1l dHJpYyB3aGljaCBwcm92aWRlcyBhDQptZWFzdXJlIHRoYXQgaXMgaW5kaWNhdGl2ZSBvZiB0aGUg dXNlcidzIHZpZXcgb2YgYSBzZXJ2aWNlLg0K4oCdDQpORVcgVEVYVDoNCuKAnA0KSW5mb3JtYXRp b24gaXMgcmVjb3JkZWQgYWJvdXQgUW9FIG1ldHJpYyB3aGljaCBwcm92aWRlcyBhDQptZWFzdXJl IHRoYXQgZ2l2ZXMgYSBudW1lcmljYWwgaW5kaWNhdGlvbiBvZiB0aGUgcGVyY2VpdmVkDQpxdWFs aXR5IG9mIHRoZSBtZWRpYSByZWNlaXZlZC4NCuKAnQ0KDQotIFNlY3Rpb24gNC4xOiAiZXh0bWFw IiBpcyBhbHJlYWR5IGEgcmVnaXN0ZXJlZCBhdHRyaWJ1dGUgbmFtZS4gSSBkaWQgbm90IHVuZGVy c3RhbmQgd2h5IGFuZCBpbiB3aGF0IHdheSB5b3Ugd2FudCB0byB1c2UgaXQuDQoNCltRaW5dOiBX ZSBuZWVkIGEgbmV3IGF0dHJpYnV0ZSBkZWZpbmluZyB0aGUgbWFwcGluZyBmcm9tIHRoZSBkaWZm ZXJlbnQgcGFyYW1ldGVyIG5hbWVzIChpLmUuLCB0aGUgZGlmZmVyZW50IGNhbGN1bGF0aW9uLWFs Z29yaXRobSBwYXJhbWV0ZXIgbmFtZXMpIHRvIHRoZSBudW1lcmljIHZhbHVlcyB1c2VkIGluIHRo ZSBwYWNrZXRzIFVubGlrZSBSRkM1Mjg1IGV4dG1hcCB1c2FnZSwgd2UgbWFwIG5hbWUgcmF0aGVy IHRoYW4gVVJJIHRvIHRoZSBudW1lcmljIHZhbHVlcyB1c2VkIGluIHRoZSBwYWNrZXQuDQpTbyBJ IGFzc3VtZSDigJxleHRtYXDigJ0gY2FuIGJlIHJldXNlZCwgaG93ZXZlciBpZiBub3QsIEkgYmVs aWV2ZSB3ZSBzaG91bGQgZGVmaW5lIG5ldyBhdHRyaWJ1dGUgc2ltaWxhciB0byDigJxleHRtYXDi gJ0gaW4gdGhpcyBkb2N1bWVudC4NCg0KSSdkIHJlZmVyIHRvIHNvbWUgU0RQIGV4cGVydHMgaGVy ZSBhcyBJIGNvdWxkIG5vdCB1bmRlcnN0YW5kIHdoYXQgeW91IHdhbm5hIGRvIGFuZCBob3cgeW91 IHdhbm5hIGRvIGl0Lg0KDQpbUWluXTogVGhhbmsgZm9yIHlvdXIgc3VnZ2VzdGlvbi4gSSB0aGlu ayAgaW5zdGVhZCBvZiB1c2luZyDigJxleHRtYXDigJ0sIHdlIHdpbGwgdXNlIGEgbmV3IGF0dHJp YnV0ZSB3aXRoIGEgbmV3IGF0dHJpYnV0ZSBuYW1lIOKAnGNhbGdleHRtYXDigJ0uDQo= --_000_B8F9A780D330094D99AF023C5877DABA43B4200Ankgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH 5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWxpIEMuIEJlZ2VuIChh YmVnZW4pIFttYWlsdG86YWJlZ2VuQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVuZSAxMywgMjAxMyA3OjU4IFBNPGJyPg0KPGI+VG86PC9iPiBRaW4gV3U7IGRyYWZ0 LWlldGYteHJibG9jay1ydGNwLXhyLXFvZUB0b29scy5pZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4g eHJibG9jay1jaGFpcnM7IG1tdXNpYzsgJ3hyYmxvY2snPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbTU1VU0lDXSBTRFAgRGlyZWN0b3JhdGU6IFJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2st cnRjcC14ci1xb2UtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJp Z2h0OjBjbSIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPi0gSSBkb24ndCBh Z3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50Ojwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7SW5mb3JtYXRpb24gaXMgcmVjb3Jk ZWQgYWJvdXQgUW9FIG1ldHJpYyB3aGljaCBwcm92aWRlcyBhPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO21lYXN1cmUgdGhhdCBpcyBpbmRp Y2F0aXZlIG9mIHRoZSB1c2VyJ3MgdmlldyBvZiBhIHNlcnZpY2UuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGUgYXBwbGljYXRpb24gY2Fubm90IHBvc3Np Ymx5IGtub3cgYSB1c2VyJ3MgdmlldyBvZiBzZXJ2aWNlIHVubGVzcyB0aGUgdXNlciBleHBsaWNp dGx5IGVudGVycyB0aGF0IGluZm8gaW4gc29tZQ0KIGZhc2hpb24gdG8gdGhlIGFwcGxpY2F0aW9u Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+W1Fpbl06Jm5ic3A7IFRoZSBhcHBsaWNhdGlvbiBjYW4gcmVseSBvbiBRb0UgZXZhbHVh dGlvbiBtb2RlbCB0byBjYWxjdWxhdGUgTW9TIHZhbHVlIGFuZCB1c2Ugc3VjaCBNb1MNCiB2YWx1 ZSB0byByZWZsZWN0IGhvdyBlbmQgdXNlciBmZWVsIG9yIGV4cGVyaWVuY2UgdGhlIG1lZGlhIHF1 YWxpdHkuIFRoYXTigJlzIHdoYXQgdGhpcyBzdGF0ZW1lbnQgd2FudDwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRvIGNvbnZl eS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYXQgaXMgbm90IHdo YXQgdGhlIHNlbnRlbmNlIHNheXMsIHRob3VnaCwgYXQgbGVhc3QgdG8gbWUuIFRoZSAmcXVvdDt1 c2VyJ3MgdmlldyBvZiBhIHNlcnZpY2UmcXVvdDsgaXMgdGhlIHRyb3VibGluZyBwYXJ0IHRvIG1l LiBXaGF0IHlvdSBkbyBpcyB0aGF0IHlvdSBhcHBseSBhbiBhbGdvcml0aG0gd2l0aCBzb21lDQog b2JzZXJ2ZWQgdmFsdWVzIGFuZCB5b3UgdHJ5IHRvIGVzdGltYXRlIHNvbWUgc29ydCBvZiBhIG1l YW4gb3BpbmlvbiBzY29yZS4gVGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBpbmRpY2F0aXZlIG9mIHRo ZSBlbmQtdXNlcidzIFFvRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1Fpbl06IEkgZ2V0IHlvdXIgcG9pbnQuIE1heWJlIHdlIGNhbiByZXBocmFzZSB0 aGlzIHNlbnRlbmNlIGFzIGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9M RCBURVhUOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SW5mb3JtYXRpb24gaXMgcmVj b3JkZWQgYWJvdXQgUW9FIG1ldHJpYyB3aGljaCBwcm92aWRlcyBhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm1lYXN1cmUgdGhhdCBpcyBpbmRp Y2F0aXZlIG9mIHRoZSB1c2VyJ3MgdmlldyBvZiBhIHNlcnZpY2UuJm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TkVXIFRFWFQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbmZvcm1hdGlvbiBpcyByZWNvcmRlZCBh Ym91dCBRb0UgbWV0cmljIHdoaWNoIHByb3ZpZGVzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bWVhc3VyZSB0aGF0DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPmdpdmVzIGEgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5udW1lcmljYWwgaW5kaWNhdGlvbiBvZiB0aGUg cGVyY2VpdmVkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cXVhbGl0eSBvZiB0aGUgbWVkaWEgcmVjZWl2ZWQ8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGNtIiBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPi0gU2VjdGlvbiA0LjE6ICZxdW90O2V4dG1hcCZxdW90OyBp cyBhbHJlYWR5IGEgcmVnaXN0ZXJlZCBhdHRyaWJ1dGUgbmFtZS4gSSBkaWQgbm90IHVuZGVyc3Rh bmQgd2h5IGFuZCBpbiB3aGF0IHdheSB5b3Ugd2FudA0KIHRvIHVzZSBpdC48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFdlIG5lZWQgYSBuZXcgYXR0cmlidXRlIGRlZmluaW5nIHRo ZSBtYXBwaW5nIGZyb20gdGhlIGRpZmZlcmVudCBwYXJhbWV0ZXIgbmFtZXMgKGkuZS4sIHRoZSBk aWZmZXJlbnQgY2FsY3VsYXRpb24tYWxnb3JpdGhtDQogcGFyYW1ldGVyIG5hbWVzKSB0byB0aGUg bnVtZXJpYyB2YWx1ZXMgdXNlZCBpbiB0aGUgcGFja2V0cyBVbmxpa2UgUkZDNTI4NSBleHRtYXAg dXNhZ2UsIHdlIG1hcCBuYW1lIHJhdGhlciB0aGFuIFVSSSB0byB0aGUgbnVtZXJpYyB2YWx1ZXMg dXNlZCBpbiB0aGUgcGFja2V0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+U28gSSBh c3N1bWUg4oCcZXh0bWFw4oCdIGNhbiBiZSByZXVzZWQsIGhvd2V2ZXIgaWYgbm90LCBJIGJlbGll dmUgd2Ugc2hvdWxkIGRlZmluZSBuZXcgYXR0cmlidXRlIHNpbWlsYXIgdG8g4oCcZXh0bWFw4oCd DQogaW4gdGhpcyBkb2N1bWVudC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+SSdkIHJlZmVyIHRvIHNvbWUgU0RQIGV4cGVydHMgaGVyZSBhcyBJIGNvdWxk IG5vdCB1bmRlcnN0YW5kIHdoYXQgeW91IHdhbm5hIGRvIGFuZCBob3cgeW91IHdhbm5hIGRvIGl0 Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUWluXTogVGhhbmsgZm9yIHlvdXIgc3VnZ2VzdGlv bi4gSSB0aGluayZuYnNwOyBpbnN0ZWFkIG9mIHVzaW5nIOKAnGV4dG1hcOKAnSwgd2Ugd2lsbCB1 c2UgYSBuZXcgYXR0cmlidXRlIHdpdGggYSBuZXcgYXR0cmlidXRlIG5hbWUg4oCcY2FsZ2V4dG1h cOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA43B4200Ankgeml501mbschi_-- From prvs=78816e9fb4=christer.holmberg@ericsson.com Mon Jun 17 23:56:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A021F9CD0 for ; Mon, 17 Jun 2013 23:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.934 X-Spam-Level: X-Spam-Status: No, score=-3.934 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY7u6yn-Mcft for ; Mon, 17 Jun 2013 23:56:41 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EF6EC21F9CFD for ; Mon, 17 Jun 2013 23:56:40 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-75-51c004a77a69 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A7.31.10205.7A400C15; Tue, 18 Jun 2013 08:56:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 08:56:39 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: ICE Procedures (18.6) Thread-Index: Ac5r8MLs2/1wsMbEQBKrXv9BXgwcUQ== Date: Tue, 18 Jun 2013 06:56:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3AADE0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvre5ylgOBBid/WFlMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BkvHi5mKXjqWjFt1gr2Bsb1Nl2MnBwSAiYSZ9buZYGwxSQu 3FvP1sXIxSEkcJRR4vaJR6wgCSGBRYwSD5bqdDFycLAJWEh0/9MGCYsIqEt83dvDDGILC2hL vJuxnhUibiDR9XwvO4StJ7G3v48JxGYRUJWYffohmM0r4Cvxbsl+NhCbEWjv91NrwOLMAuIS t57MZ4K4R0BiyZ7zzBC2qMTLx/9YQU6QEFCUWN4vB1GeL/GiawozxEhBiZMzn7BMYBSahWTS LCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHMWpxUm56UYGmxiBYX9wy2+L HYyX/9ocYpTmYFES5/10alegkEB6YklqdmpqQWpRfFFpTmrxIUYmDk4QwSXVwHj2xMIrB2wL 5Vt6LjeoXfXy5lq4cdLcrk8GlV9FLN5vKv3EVZZqF122a8qpQ3fap/emJmibimj98Dswafbt kx6vmJ67Mb9ZvqhYRfBmfGVEyIkXPIa/GAyO7o3UKVn+Ps/e5IftSUY9Hb4niopWPW/m1hXo TY19395w3MLjrW1Vt3jK+pIl65VYijMSDbWYi4oTAcP5Zn1OAgAA Subject: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:56:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3AADE0ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I did some updates (mostly editorial) to the BUNDLE ICE Procedures section. So, when reviewing BUNDLE-04, for the ICE parts, please use the text below = as base :) Regards, Christer ---------------------------------- 8. Usage With ICE 8.1. General This section describes how to use the BUNDLE mechanism together with the Interactive Connectivity Establishment (ICE) mechanism [RFC5245]. 8.2. ICE Candidates 8.2.1. Offerer Procedures When an ICE-enabled Offerer generates an SDP Offer, with a BUNDLE group, the Offerer MUST assign ICE candidates [RFC5245] to each "m=3D" line in the BUNDLE group. If the Offerer assigns unique addresses to each "m=3D" line in the BUNDLE group, the Offerer MUST assign assign unique ICE candidate values to each "m=3D" line in the BUNDLE group. The Offerer MUST NOT assign the same ICE candidate values to "m=3D" lines outside the BUNDLE group, or to "m=3D" lines in another BUNDLE group. If the Offerer assigns the BUNDLE address to each "m=3D" line in the BUNDLE group, the Offerer MUST assign assign identical ICE candidate values to each "m=3D" line in the BUNDLE group. The Offerer MUST NOT assign the same ICE candidate values to "m=3D" lines outside the BUNDLE group, or to "m=3D" lines in another BUNDLE group. 8.2.2. Answerer Procedures When an ICE-enabled Answerer generates an SDP Answer, with a BUNDLE group, the Answerer MUST assign ICE candidates to each "m=3D" line in the BUNDLE group. The Answerer MUST assign identical ICE candidate values to each "m=3D" line in the BUNDLE group. The Answerer MUST NOT assign the same ICE candidate values to "m=3D" lines outside the BUNDLE group, or to "m=3D" lines in another BUNDLE group. 8.3. ICE Connectivity Checks Once a BUNDLE address has been selected for the Offerer and the Answerer, it is RECOMMENDED to perform ICE connectivity checks and keep-alives [RFC5245] for the whole BUNDLE group, rather than for each individual "m=3D" line in the BUNDLE group. --_000_7594FB04B1934943A5C02806D1A2204B1C3AADE0ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I did some updates (mostly editorial) to the BUNDLE = ICE Procedures section.

 

So, when reviewing BUNDLE-04, for the ICE parts, ple= ase use the text below as base :)

 

Regards,

 

Christer

 

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

 

 

8.  Usage With ICE

 

8.1.  General

 

   This section describes how to use the B= UNDLE mechanism together with

   the Interactive Connectivity Establishm= ent (ICE) mechanism [RFC5245].

 

8.2.  ICE Candidates

 

8.2.1.  Offerer Procedures

 

   When an ICE-enabled Offerer generates a= n SDP Offer, with a BUNDLE

   group, the Offerer MUST assign ICE cand= idates [RFC5245] to each "m=3D"

   line in the BUNDLE group.

 

   If the Offerer assigns unique addresses= to each "m=3D" line in the

   BUNDLE group, the Offerer MUST assign a= ssign unique ICE candidate

   values to each "m=3D" line in= the BUNDLE group.  The Offerer MUST NOT

   assign the same ICE candidate values to= "m=3D" lines outside the BUNDLE

   group, or to "m=3D" lines in = another BUNDLE group.

 

   If the Offerer assigns the BUNDLE addre= ss to each "m=3D" line in the

   BUNDLE group, the Offerer MUST assign a= ssign identical ICE candidate

   values to each "m=3D" line in= the BUNDLE group.  The Offerer MUST NOT

   assign the same ICE candidate values to= "m=3D" lines outside the BUNDLE

   group, or to "m=3D" lines in = another BUNDLE group.

 

8.2.2.  Answerer Procedures

 

   When an ICE-enabled Answerer generates = an SDP Answer, with a BUNDLE

   group, the Answerer MUST assign ICE can= didates to each "m=3D" line in

   the BUNDLE group.  The Answerer MU= ST assign identical ICE candidate

   values to each "m=3D" line in= the BUNDLE group.  The Answerer MUST NOT

   assign the same ICE candidate values to= "m=3D" lines outside the BUNDLE

   group, or to "m=3D" lines in = another BUNDLE group.

 

8.3.  ICE Connectivity Checks

 

   Once a BUNDLE address has been selected= for the Offerer and the

   Answerer, it is RECOMMENDED to perform = ICE connectivity checks and

   keep-alives [RFC5245] for the whole BUN= DLE group, rather than for

   each individual "m=3D" line i= n the BUNDLE group.

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3AADE0ESESSMB209erics_-- From harald@alvestrand.no Tue Jun 18 01:52:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AA121F9A84 for ; Tue, 18 Jun 2013 01:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODNL6fbGBeYe for ; Tue, 18 Jun 2013 01:52:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0586521F9A8F for ; Tue, 18 Jun 2013 01:52:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04B3039E0FA for ; Tue, 18 Jun 2013 10:52:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2bT5TIAm2Ao for ; Tue, 18 Jun 2013 10:52:04 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0F3B139E04C for ; Tue, 18 Jun 2013 10:52:04 +0200 (CEST) Message-ID: <51C01FB3.2040808@alvestrand.no> Date: Tue, 18 Jun 2013 10:52:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------020108030908070202030205" Subject: Re: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:52:25 -0000 This is a multi-part message in MIME format. --------------020108030908070202030205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/18/2013 08:56 AM, Christer Holmberg wrote: > > Hi, > > I did some updates (mostly editorial) to the BUNDLE ICE Procedures > section. > > So, when reviewing BUNDLE-04, for the ICE parts, please use the text > below as base :) > > Regards, > > Christer > > ---------------------------------- > > .... snipped stuff I have no issues with .... > 8.3. ICE Connectivity Checks > > Once a BUNDLE address has been selected for the Offerer and the > > Answerer, it is RECOMMENDED to perform ICE connectivity checks and > > keep-alives [RFC5245] for the whole BUNDLE group, rather than for > > each individual "m=" line in the BUNDLE group. > I have a bit of trouble parsing this last paragraph. There are two possibilities: - The offer/answer is incomplete, so we don't know whether BUNDLE will be turned on or not. (This can happen only in updates - you can't do ICE checks before choosing the BUNDLE address in the initial exchange, since you don't know the remote candidates) - The offer/answer is complete, and both parties know the BUNDLE address In the last state, it's impossible to do anything BUT check connectivity for the whole BUNDLE group; there is nothing else to check for. So RECOMMENDED doesn't make sense; it's not even a MUST, it's just the way things work. In the first state, I think it should be RECOMMENDED to delay checking until you have completed the exchange, so that you know what the BUNDLE address is. But that's not what the words seem to say. Could you clarify? Harald --------------020108030908070202030205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/18/2013 08:56 AM, Christer Holmberg wrote:

Hi,

 

I did some updates (mostly editorial) to the BUNDLE ICE Procedures section.

 

So, when reviewing BUNDLE-04, for the ICE parts, please use the text below as base :)

 

Regards,

 

Christer

 

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


.... snipped stuff I have no issues with ....

8.3.  ICE Connectivity Checks

 

   Once a BUNDLE address has been selected for the Offerer and the

   Answerer, it is RECOMMENDED to perform ICE connectivity checks and

   keep-alives [RFC5245] for the whole BUNDLE group, rather than for

   each individual "m=" line in the BUNDLE group.


I have a bit of trouble parsing this last paragraph.

There are two possibilities:

- The offer/answer is incomplete, so we don't know whether BUNDLE will be turned on or not. (This can happen only in updates - you can't do ICE checks before choosing the BUNDLE address in the initial exchange, since you don't know the remote candidates)

- The offer/answer is complete, and both parties know the BUNDLE address

In the last state, it's impossible to do anything BUT check connectivity for the whole BUNDLE group; there is nothing else to check for. So RECOMMENDED doesn't make sense; it's not even a MUST, it's just the way things work.

In the first state, I think it should be RECOMMENDED to delay checking until you have completed the exchange, so that you know what the BUNDLE address is. But that's not what the words seem to say.

Could you clarify?

           Harald



--------------020108030908070202030205-- From prvs=9881e4a889=christer.holmberg@ericsson.com Tue Jun 18 03:17:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DDE21F9CCA for ; Tue, 18 Jun 2013 03:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.712 X-Spam-Level: X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6SZysS5bnRK for ; Tue, 18 Jun 2013 03:17:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 68DEF21F9C13 for ; Tue, 18 Jun 2013 03:17:44 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-2f-51c033c7831b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 25.CA.09795.7C330C15; Tue, 18 Jun 2013 12:17:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 12:17:43 +0200 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6) Thread-Index: Ac5r8MLs2/1wsMbEQBKrXv9BXgwcUf///yeA///HsdA= Date: Tue, 18 Jun 2013 10:17:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AB246@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se> <51C01FB3.2040808@alvestrand.no> In-Reply-To: <51C01FB3.2040808@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre5x4wOBBg9fm1kc6+tis5i6/DGL A5PHlQlXWD2WLPnJFMAUxW2TlFhSFpyZnqdvl8Cd0fNpGnPBQe6KXx3vWBsYezi7GDk4JARM JNoexHYxcgKZYhIX7q1n62Lk4hASOMwocfrHGVYIZxGjxOErXSwgDWwCFhLd/7RBGkQEgiWW f9rOBGILA4X7Zy5lgYhbSlyc2csOYVtJdLZcZgSxWQRUJQ79fsEKYvMK+Eps3DQLzBYSKJDY +XgKWA2ngK7E7x9zwHoZgQ76fmoN2HxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sEL8oSizv l4Mo15O4MXUKG4StLbFs4WtmiLWCEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEjyypG9tzEzJz0 cvNNjMBIOLjlt8EOxk33xQ4xSnOwKInzfjq1K1BIID2xJDU7NbUgtSi+qDQntfgQIxMHJ4jg kmpg9G1TZYn9F/Hsw/22L29fSXK9vFL2p+S+i3vOenGJhb+bdrmmFRY/ajpwNNPaY/etq8Z5 86c2q96zOytX7fnqLdfav2d6L31+8zWi0t7i/z4djVN2h7kvMaZ7Nft9e7TNO4nNRvn89kXe Yee6v+/nEnbp8pMpZNC5Zm03ZWfhrAOquTb/MrMElFiKMxINtZiLihMBZ92+j1cCAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:17:55 -0000 Hi Harald, 8.3.=A0 ICE Connectivity Checks =A0 =A0=A0 Once a BUNDLE address has been selected for the Offerer and the =A0=A0 Answerer, it is RECOMMENDED to perform ICE connectivity checks and =A0=A0 keep-alives [RFC5245] for the whole BUNDLE group, rather than for =A0=A0 each individual "m=3D" line in the BUNDLE group. > I have a bit of trouble parsing this last paragraph. > > There are two possibilities: > > - The offer/answer is incomplete, so we don't know whether BUNDLE will be= turned on or not. (This can happen only in updates - you can't=20 > do ICE checks before choosing the BUNDLE address in the initial exchange,= since you don't know the remote candidates) > > - The offer/answer is complete, and both parties know the BUNDLE address > > In the last state, it's impossible to do anything BUT check connectivity = for the whole BUNDLE group; there is nothing else to check for. So RECOMMEN= DED doesn't make sense; it's not even a MUST, it's just the way things work= . I have no problem with adding MUST. > In the first state, I think it should be RECOMMENDED to delay checking un= til you have completed the exchange, so that you know what the BUNDLE addre= ss is. But that's not what the words seem to say. > > Could you clarify? Isn't that covered with the "Once a BUNDLE address has been selected"? Or, = should I say "negotiated" instead? Or, did I misunderstand your comment? Regards, Christer From harald@alvestrand.no Tue Jun 18 04:03:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C8821F9E85 for ; Tue, 18 Jun 2013 04:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCWnuayDTeNO for ; Tue, 18 Jun 2013 04:02:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA88421F9E7D for ; Tue, 18 Jun 2013 04:02:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEB6739E170; Tue, 18 Jun 2013 13:02:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb0RdP9pGOed; Tue, 18 Jun 2013 13:02:29 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9736839E12F; Tue, 18 Jun 2013 13:02:29 +0200 (CEST) Message-ID: <51C03E45.6000801@alvestrand.no> Date: Tue, 18 Jun 2013 13:02:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se> <51C01FB3.2040808@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AB246@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AB246@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:03:01 -0000 On 06/18/2013 12:17 PM, Christer Holmberg wrote: > Hi Harald, > > 8.3. ICE Connectivity Checks > > Once a BUNDLE address has been selected for the Offerer and the > Answerer, it is RECOMMENDED to perform ICE connectivity checks and > keep-alives [RFC5245] for the whole BUNDLE group, rather than for > each individual "m=" line in the BUNDLE group. > >> I have a bit of trouble parsing this last paragraph. >> >> There are two possibilities: >> >> - The offer/answer is incomplete, so we don't know whether BUNDLE will be turned on or not. (This can happen only in updates - you can't >> do ICE checks before choosing the BUNDLE address in the initial exchange, since you don't know the remote candidates) >> >> - The offer/answer is complete, and both parties know the BUNDLE address >> >> In the last state, it's impossible to do anything BUT check connectivity for the whole BUNDLE group; there is nothing else to check for. So RECOMMENDED doesn't make sense; it's not even a MUST, it's just the way things work. > I have no problem with adding MUST. I'd prefer that. Or even change "it is RECOMMENDED to perform ICE connectivity checks" to "ICE connectivity checks are performed". If there's only one possible way to do it, it seems superfluous to use words that look like there's an alternative. > >> In the first state, I think it should be RECOMMENDED to delay checking until you have completed the exchange, so that you know what the BUNDLE address is. But that's not what the words seem to say. >> >> Could you clarify? > Isn't that covered with the "Once a BUNDLE address has been selected"? Or, should I say "negotiated" instead? Yes, on second reading, that's implied - you talk about my second state, not the first one. > > Or, did I misunderstand your comment? > > Regards, > > Christer > > From prvs=3881e1e3e5=magnus.westerlund@ericsson.com Tue Jun 18 04:41:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCA221F9BFF; Tue, 18 Jun 2013 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.083 X-Spam-Level: X-Spam-Status: No, score=-106.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQo9H494EDTZ; Tue, 18 Jun 2013 04:41:51 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF4F21F9BD9; Tue, 18 Jun 2013 04:41:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-10-51c0477cc1fc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F5.63.15700.C7740C15; Tue, 18 Jun 2013 13:41:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 18 Jun 2013 13:41:49 +0200 Message-ID: <51C047BC.1050207@ericsson.com> Date: Tue, 18 Jun 2013 13:42:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robert Sparks References: <51AFB3FF.7000009@nostrum.com> In-Reply-To: <51AFB3FF.7000009@nostrum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvrW6t+4FAg/NfOC2u7Z7CZHH11WcW i2cb57NYTF3+mMXi2pxGNgdWjyVLfjJ5zNr5hMXjy+XPbAHMUdw2SYklZcGZ6Xn6dgncGV+n TGUqeLOXseLCs2fsDYxPpjF2MXJySAiYSFx4dYwJwhaTuHBvPVsXIxeHkMApRom172YyQjjL GSXe71rNClLFK6Atsf5BD1g3i4CqxJEdE8G62QQsJG7+aGQDsUUFgiWObN/MAlEvKHFy5hMw W0RAQ+LakiXsIEOZBSYzSszbcAmsQVjATWLGsY3sILaQgJbEww/nwBo4gZZNXX0B6jxJiS0v 2sFqmAUMJI4smsMKYctLNG+dzQzRqy3R0NTBOoFRaBaS3bOQtMxC0rKAkXkVI3tuYmZOernh JkZgcB/c8lt3B+OpcyKHGKU5WJTEeT+c2hUoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1 MCbJ+Eyo92Lc7ZoV6LQh/MT6k+t3pzNJ7Npz5s33Wev9VzVcDEqSWHqqdq3Ho5aShItz2zZs kCm9Iii3OnmNPs/y+CCmeM4Jf3rfBHoZPulKt5hgIrI8N+0uu9iJypdt4QYK977Jr36hUmBY +klSRnWDs82Zve1XCo2n6DH/OqaU43HW4mZYkxJLcUaioRZzUXEiAAs+RylBAgAA Cc: draft-ietf-mmusic-rfc2326bis@tools.ietf.org, General Area Review Team , "ietf@ietf.org" , mmusic@ietf.org Subject: Re: [MMUSIC] Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:41:57 -0000 Hi Robert, Thanks for the massive review. A number of really good comments in here. Below you will find my answers, comments, questions and in most cases clarifications what I see us doing with your comment. These covers your major and minor comments. The nits we will simply implement as we see fit, if we have questions we will comeback with those. WG, there are a number of issues in here that would be greatly helped by your input! On 2013-06-05 23:56, Robert Sparks wrote: > Document: draft-ietf-mmusic-rfc2326bis-34 > Reviewer: Robert Sparks > Review Date: 05-Jun-2013 > IETF LC End Date: 04-Jun-2013 > IESG Telechat date: not yet on a telechat > > > The document is very long, and the structure is unusual - much of the > definition of the protocol itself is in the appendices. You are missing > an opportunity to make this document much shorter (thereby likely > increasing its effectiveness). Much of the jump in from RFC2326 was > importing the description of headers and responses from HTTP, tailoring > them to RTSP. That was a good exercise in that it highlights some issues > that would otherwise be non-obvious (and raises a few questions below). > But you followed the style from HTTP perhaps too closely - much shorter > descriptions without examples might have done the job better. Overall, > separating exposition and examples from the protocol definition would > make it much easier for an implementer to find the definition of the > protocol, and use the document as a reference when diagnosing a failure > to interoperate. Agree, it would be differently structure if we wrote it from scratch today. But it is an document that is 10 years in the making with dual heritage in RFC 2326 and RFC 2068. > > Major Issues > > I'm not seeing what instructs an RTSP element on how to find the server > it would try to open a connection to given an rtsp or rtsps URI? Are you > assuming it would be doing A or AAAA DNS lookups? Yes, using A or AAAA DNS records are assumed. No problem making that explicit. Should this protocol > use NAPTR/SRV? Potentially, but as everyone have been using A records for all these years, I think it is not worth defining it at this stage. The document should be explicit. On a related note, (and > maybe I missed this), but where do you talk about what an element should > check in the server's certificate when connecting over TLS? Are you > assuming a common name match? Or are you expecting some SubjectAltName > processing? This draft says in Section 19.2 the following regarding this: RTSP MUST follow the same guidelines with regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. Where section 3.1 (Server Identity) of RFC 2818 contains the following: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Isn't that clear enough on that matter? > > The document should say more about when connection reuse is appropriate, > particularly when the connections happened because of an rtsps uri. Two > different names might resolve to the same IP address - reusing a > connection formed when looking at the first name (and verifying the > server's cert) is dangerous. A new connection needs to be formed (and > verified) instead. I want to check my understanding of the issue you are seeing here. So a client looks ups foo.example.org, gets an ip address A and establishes an TCP/TLS connection and verifies that there are a SubjectAltName that matches foo.example.org works. Then client is going to open bar.example.com and looks up that address and gets the same IP address A. Client matches A against existing connections and simply sends a request to bar.example.com. Thus bypassing the certificate verification. If we clarify that in the process of opening rtsps://bar.example.com the client MUST verify that the server certificate for the TLS connection it considers re-using has an SubjectAltName of bar.example.com, does that resolve your concerns. If not, please explain the concern further. > > The text talks about the option to queue S->C requests if there isn't a > connection to the client available. Ostensibly, this means the request > can go down some future connection. It's not clear how the server can > tell the right client connected. In particular, when using rtsps, how do > you prevent a malicious client from getting such a queued message that > wasn't meant for him? Okay, this security issue I have totally missed but it is clearly serious. I don't see any easy way of fixing this. Thus I would suggest that we simply make it clear that a server MUST NOT queue the S->C RTSP message, independent if they are requests PLAY_NOTIFY and TEARDOWN or responses to client requests. > > Given that the text talks about queuing S-C requests, it should > explicitly call out whether a server can queue a response if the > connection the associated request arrived on is no longer available. I > think what you want to say is that such a response must not be queued, > and must be dropped. Agreed, lets mandate that they are dropped. > > There are several places in the text that talk about using a 503 > response with a Retry-After header to push back on traffic from an > element (the first is section 10.7). > * It's not clear what the subject of a 503 is. Is it intended to be > scoped to requests to the resource in the RURI of the associated > request? Is it intended to be scoped to the domain in that resource? Or > is it, like in SIP, intended to be scoped to the server issuing the > response, independent of what the RURI contained? Very good question. It is far from obvious what the best choice is. And I think even talking only about URI related scope may not be the best. The case I have in mind is if a proxy that has several already established RTSP sessions over a persistent connection. When a client connected to the proxy requests to establish a new session the server may have insufficient resource to handle the SETUP request and send a 503 answer. However if another client already having an RTSP session for the same resource want to terminate that session it would be strange to refuse to process the message as it will actually free up resources. This makes me believe that you need to have a RTSP Session scope for any request carrying a Session-ID and a general server, or host name scope for non-associated that doesn't prevent established sessions to try. Thoughts on this? > * If the intent is that the 503 talks about the server, then you should > clarify that a proxy doesn't simply forward 503 responses (after > rewriting CSeqs), and should probably have a response of its own. > Otherwise, clients that might be talking to two different servers > through one proxy would lose access to both of them when one of the > servers 503ed. If we us a host and session scope then this issue would not be present. However, if the proxy is actually overloaded that still needs its own 552 Proxy Unavailable response with the same scope rules as for the 503, but where unassociated requests concerns sending to the proxy at all. > > Section 4.9.1 lists values the Seek-Style header can take, but 18.45 > lists a completely different set (which most of the rest of the document > uses). Should 4.9.1 be changed to use the values in 18.45? Are the right > strings being used in sections 13.4.4 through 13.4.6? Those appear to be > using strings from 4.9.1. Yes, clearly an inconsistency issue that needs to be resolved. > > The document will not stand if you delete some of the appendices. They > aren't supplementary material. Please consider restructuring the > normative sections back into the main document, or clearly identifying > which ones define protocol and which are background information. I would like to characterize this differently. I think you will have a working protocol of RTSP, but you can't use it for anything. This as you will have no media transport (C), no media description protocol (D), and no parameters format (F). But, these appendixes are replaceable with other protocol solutions. The Introduction section (1) says: The appendixes describe and define some functionalities that are not part of the core RTSP specification, but which are still important to enable some usages. Among them, the RTP usage is defined in Appendix C and the SDP usage with RTSP is defined in Appendix D, which are two mandatory appendixes. I note that we should add F to this list. I think we should be clear in each of this appendices that if one support Foo for the purpose of bar then this appendix defines normatively how one does it. > > Section 15 talks about a "transparent' proxy, but there is no > description in this document of what protocol such a thing should > follow. What bad thing happens if you remove all mention of > "transparent" proxies from the document? As far as I can tell, that > won't affect the protocol definition at all. Not really, there is no definition of transparent proxies currently. There is one security concern that make require some word smithing if we remove transparent proxies. >From my perspective a transparent proxy is something that hijacks a TCP connection towards an RTSP server to be a proxy between client and server. Further is not detectable from the client's or the servers perspective, but still may modify RTSP messages within the bounds of the RTSP protocol. But, in reality as we have proxies that are visible we should focus on those and forget this bastard version. > > The list of steps for establishing an SRTP cryptographic context in > C.1.4.1 says "This specification does not specify an explicit method for > indicating this SRTP cryptographic context establishment method, but > future specifications may." in the context of looking at the SDP. SDP > _has_ methods of indicating what keying mechanism is used with SRTP - > are you talking about something different? I think you are considering the methods for keying SRTP that are Offer/Answer dependent. The only RTSP SDP using method that exist is the one defined in RFC 4567, which we are explicit on not using. Why doesn't this section say > something like "the use of SRTP with RTSP is only defined with MIKEY > with keys established as defined in this section. Future documents may > talk about how an RTSP implementation might treat SDP that indicates > some other key mechanism be used"? Yes, that is appears better, but we will have to make it clear that is is regarding RTSP 2.0. Must also think if RFC 4567 needs to be worked into that sentence. Could you provide an example in the > document of an RTSP message carrying SDP reflecting the use of SRTP as > defined in this document? The point is that the only difference is that he RTP profile is SAVP/RTP or SAVPF/RTP in the SDP. Thus making such an SDP isn't difficult. Question is if it provides a benefit? > Minor Issues > > The document uses the notion of a "control connection" (it appears first > in section 2.5) without defining what that is, or what kind of > connections you might have that aren't control connections. The "control connection" is the connection established for sending RTSP messages on it. I agree it is undefined and could likely be replaced by the "RTSP connection" or "connection for RTSP messages" > > The update to the registration of the rtsp and rtsps schema call out > that there are changes that can result in interoperability issues. It > doesn't say what the issues are, or who might encounter them. I can > infer that the point is that there might be problems if a URI following > this updated registration were to be processed by an RTSP 1.0 > implementation (or any other application that relied on the previous > definition). It would be better to say that explicitly, and talk about > how a previous implementation is likely to act when presented with a URI > that exercised these new changes. I have gotten these comment elsewhere and have prepared a text update for section 4.2: The details of the syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0. These changes are: o Support for IPV6 literal in host part and future IP literals through RFC 3986 defined mechanism. o A new relative format to use in the RTSP protocol elements that is not required to start with "/". Neither should have any significant impact on interoperability. If one is required to use IPv6 literals to reach an RTSP server, then that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol. If an RTSP 1.0 client attempts to process the URI it will not match the allowed syntax and be considered invalid and processing will be stopped. This is clearly a failure to reach the resource, however it is not a signification issue as RTSP 2.0 support was needed anyway in both server and client. Thus failure will only occur in a later step when there is a RTSP version mismatch between client and server. The second change will only occur in RTSP messages, that are explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0 only agent will not be required to parse this variant. Clear enough? The above is Edited In. (It's not clear to me that all of the > thread at www.ietf.org—msg01567.html > > concluded - I see how the fragments question ended, but what about > things like the addition of IPV6 literals? In particular, I'm not > finding a response where Ted Hardie agreed that the potential for > interoperability failure had been adequately addressed). I talked to him in person about this just after the discussion to better understand his comments. If we want a confirmation I think we need to loop him into a discussion regarding this particular issue. I provided a clarification to the designated URI reviewer which accepted the request. > > > I think you've said something different than you mean in 5.4 item 1. I > think you mean to say that an RTSP implementation would ignore any body > that happened to come in message that MUST NOT contain one. What you've > said is that the part of the parser that's doing framing has to stop > framing at the end of the headers, and that such an errant body would be > parsed as a separate message. As written this would keep someone from > using an Internet Message Format parser since it would have to ignore > any Content-Length that might have appeared, even though it wasn't > supposed to. Yes, it is clearly sufficient to ignore the body, and likely much better from an error handling consideration. We will propose a text change. > > In section 10.4, it looks like a server can keep an RTSP transaction > pending forever if it sends 100 responses often enough. I assume the > client's recourse if it doesn't want to remain involved is to close the > connection. If that's right, it's worth calling it out explicitly in > this section. This is likely a good suggestion, and works fine if the client simply wants to abort the request and is anyway abandoning the RTSP session. However, the question is what to do if just the request becomes irrelevant and instead want to do something else with the RTSP session. A single client may abandon the connection, open a new one and issue a request, to a potentially undetermined session state. Yet another complexity is what a proxy does that has multiple RTSP sessions on the same server. Here the rules for processing in order the different requests and their relation to answers in the same order. This makes me want to weaken the recommendation on re-using an connection for multiple RTSP sessions. > > Somewhere, probably in section 15.2, you should be explicit that a proxy > that is multiplexing requests MUST keep the requests in the same order > as they are folded together. You can infer that, or things simply break, > but saying it explicitly would be better. Probably, as a clarification to what is already present in section 18.19 (CSeq header) Proxies that aggregate several sessions on the same transport will have to ensure that the requests sent towards a particular server have a joint sequence number space, i.e., they will regularly need to renumber the CSeq header field in requests (from proxy to server) and responses (from server to proxy) to fulfill the rules for the header. The proxy MUST increase the CSeq by one for each request it transmits, without regard of different sessions. > > Both GET_PARAMETER and SET_PARAMETER are listed as keep-alive methods in > 10.5, but the note in section 13 on table 7 only uses that as a reason > for requiring SET_PARAMETER. Why doesn't it also apply to GET_PARAMETER? > And why is this only required at servers? "Required" in this section > means Mandatory to Implement, I think. If that's right, it should be > made explicit. If that's not right, what does it mean? Yes, required is Required to implement in the server. The GET_PARAMETER is not required as only one method for keep-alive is necessary. Thus, the ones that needs to use GET/SET_PARAMETER for keep-alive will have to choose SET_PARAMETER. It is only required at the server, as it is in the client implementation choice of how to ensure keep-alive works. As this is also dependent on the media transport support one has, the client may not need a method based keep-alive. Clarifying "Required" should be straightforward. > > Section 13.8 makes a good argument for always putting parameters to be > retrieved in a body. Why are you keeping the complexity of also allowing > them in headers? Some arguments are probably lost in the passage of time. However, the headers specified to be suitable for inclusion in a GET_PARAMETER requests are used for providing these information also in other methods, thus we have not wanted to duplicate the representation of this information in both a body and a header form. > > Section 13.10: "That should not provide any benefit." is not clear - can > you expand it a little? If the REDIRECT request times out following the rules in Section 10.4 the server MAY terminate the session or transport connection that would be redirected by the request. This is a safeguard against misbehaving clients that refuse to respond to a REDIRECT request. That should not provide any benefit. The intention here is to make clear that there shouldn't be an incentive in the protocol to not acknowledge a REDIRECT request and instead simply go on as it wasn't received or seen. Thus, we want to make clear that the server may simply terminate the session in those cases. I propose we change this sentence to: Thus, removing any incentive to not acknowledge the reception of a REDIRECT request. Edited In > > In Section 13.10 you talk about clients _sending_ media (search for > "send or receive media"). Do you mean anything more than possibly RTCP? > Can you make that clear in the section? You mean this sentence: After a REDIRECT request has been processed, a client that wants to continue to send or receive media for the resource identified by the Request-URI will have to establish a new session with the designated host. The mentioning of send media is likely a RECORD reference. In this case I don't see any issue with removing it. Edited In > > Section 15.2's second paragraph appears to be the only place the proxy > rewriting of CSeq in order to multiplex requests is defined, and it is > very loose. It would be easy for a reader to fail to recognize this as > an interoperability requirement. Please consider expanding how this is > specified when addressing the comment about above about keeping requests > in relative order when multiplexing. There are text in Section 18.19 CSeq also. But I do think I agree that this should be clarified. > > You follow the principle of saying a client should treat a response with > an unknown response code, the same as it would treat the x00 of that > class (e.g. 400 for an unknown 4xx). However, you do not define what a > response code of 300 means. How is a client supposed to handle an > unknown 3xx response? Sorry, I don't quite get this comment. Section 17.3 says: If a 3rr response is received for a request in relation to an established session, the client SHOULD send a TEARDOWN request for the session, and MAY reestablish the session using the resource indicated by the Location. If the Location header is used in a response it MUST contain an absolute URI pointing out the media resource the client is redirected to, the URI MUST NOT only contain the host name. As explained above unknown 3XX codes will be 3rr codes, as 304 isn't unknown. If you don't believe this is sufficient can you please be more explicit about the issue? > > As written, a client and server can use HTTP Basic authentication over > TCP that is not protected with TLS. Consider restricting it's use to TLS > only. Are you sure you don't need to say anything RTSP specific about > DIGEST computations (I don't think you need to go as far as SIP did > talking about DIGEST, but I'm surprised you haven't run into issues > relying only on 2617 literally. Are you referring to Section 19.1 here? Yes, I would not have any issue with requiring Basic to be combined with TLS. I think that is appropriate. When it comes to DIGEST, are you referring to section 22.4 in RFC 3261? That section indicates that some clarifications are likely needed. > > > How does 411 Length Required for this protocol make sense? Given that > you've restricted the protocol to TCP and require the Content-Length > header to be present if there is a body, in what circumstance would a > server need to send a 411? It really should occur for malformed messages, which we could use 400 as response. So yes, 411 could be removed. > > > Section 18.19 requires senders to increment CSeq by 1. We have a > reliable transport with no request retransmission, so there should never > be gaps at the receiver. Should the receiver check and react some way if > there are gaps? I think you should explicitly tell them not to even > look. If you agree, why is incrementing by one important as long as you > are always strictly increasing? I agree that for TCP or other reliable transports the receiver SHOULD/SHALL ignore gaps. For any future specification of an unreliable transport of RTSP messages this would be needed. As noted in Appendix G, CSeq is retained for future support of unreliable transport. > > You call out several places where RTCP is essential to allow RTSP using > RTP to work correctly, yet section C.1.2 sets up conditions where RTCP > MUST NOT be sent. Why are you allowing those instead of treating the > conditions you describe as errors? Good question. I think it is a case we must ensure that you can negotiate and configure your desired way, without really considering if it should be allowed at all. I think mandating usage of RTCP with RTP for RTSP 2.0 would be good. But, I think that needs to be verified with the WG. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fandreas@cisco.com Tue Jun 18 05:53:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BB921F9B97 for ; Tue, 18 Jun 2013 05:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjEzxvxlt8Np for ; Tue, 18 Jun 2013 05:53:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4A521F9BBD for ; Tue, 18 Jun 2013 05:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3515; q=dns/txt; s=iport; t=1371560007; x=1372769607; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZxNzV/FZGO4XfGAoWVEWW/R5mkHvTsACtd5ZGldLCYk=; b=dVtVpv3+ym3SfqF81yGp5FyPQHJGESWDM1WldozwHZjxLA2FkeDwQhIM ttCKLdB82dh9T6H5Mep93U3zdkr1QN8gyyG/3fUI05f/laqvwIGiJVJZn f2T86OxmAmFQU0dt5cTDy1kIGiaJJDyUeu8/hWqZp/lO1C9Ca6x7CB6AZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYHANlWwFGtJV2a/2dsb2JhbAA/GoMJMYkoojSTeIEAFnSCIwEBAQR4ARALBBQJFg8JAwIBAgFFBg0BBwEBBYgFDDO6E487B4NhA5dBkUODKyA X-IronPort-AV: E=Sophos;i="4.87,888,1363132800"; d="scan'208,217";a="221252446" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jun 2013 12:53:13 +0000 Received: from Flemmings-MacBook-Pro.local (bxb-vpn3-855.cisco.com [10.86.251.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5ICrCW8004746; Tue, 18 Jun 2013 12:53:13 GMT Message-ID: <51C05839.7010502@cisco.com> Date: Tue, 18 Jun 2013 08:53:13 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic References: <51BF1AA8.2020902@ericsson.com> In-Reply-To: <51BF1AA8.2020902@ericsson.com> Content-Type: multipart/alternative; boundary="------------040503060704060704010303" Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Subject: Re: [MMUSIC] Virtual interim meeting material X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 12:53:32 -0000 This is a multi-part message in MIME format. --------------040503060704060704010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Greetings Below you will find a link to the recording for yesterday's MMUSIC Virtual Interim meeting that was focused on the "Plan A or Plan B" discussion related to RTCWeb et. al. Thanks -- Flemming Your recording is now available on the WebEx service site. Click the link below to play it: https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69199732&rKey=cac5fee577de08f8 MMUSIC Virtual Interim-20130617 1405-1 Monday, June 17, 2013 10:05 am New York Time 2 Hours 57 Minutes * You can forward this message to others to allow them to play back the recording. * On 6/17/13 10:18 AM, Ari Keränen wrote: > Virtual interim meeting material available here: > http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/proceedings.html > > > Chair slides with agenda proposal(s): > http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt > > > Cheers, > Ari > --------------040503060704060704010303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

Below you will find a link to the recording for yesterday's MMUSIC Virtual Interim meeting that was focused on the "Plan A or Plan B" discussion related to RTCWeb et. al.

Thanks

-- Flemming


Your recording is now available on the WebEx service site. Click the link below to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69199732&rKey=cac5fee577de08f8

MMUSIC Virtual Interim-20130617 1405-1
Monday, June 17, 2013 10:05 am New York Time
2 Hours 57 Minutes

* You can forward this message to others to allow them to play back the recording. *


On 6/17/13 10:18 AM, Ari Keränen wrote:
Virtual interim meeting material available here:
http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/proceedings.html

Chair slides with agenda proposal(s): http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt


Cheers,
Ari


--------------040503060704060704010303-- From rjsparks@nostrum.com Tue Jun 18 07:21:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0FD21F949F; Tue, 18 Jun 2013 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZmQ3PEWLTCW; Tue, 18 Jun 2013 07:21:34 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E621F9133; Tue, 18 Jun 2013 07:21:32 -0700 (PDT) Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5IELLtJ024140 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 18 Jun 2013 09:21:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51C06CDC.9050804@nostrum.com> Date: Tue, 18 Jun 2013 09:21:16 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Magnus Westerlund References: <51AFB3FF.7000009@nostrum.com> <51C047BC.1050207@ericsson.com> In-Reply-To: <51C047BC.1050207@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism) Cc: draft-ietf-mmusic-rfc2326bis@tools.ietf.org, General Area Review Team , "ietf@ietf.org" , mmusic@ietf.org Subject: Re: [MMUSIC] Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:21:37 -0000 Hi Magnus - Thanks for your careful treatment of these comments - I think you're on a good path with all the suggestions below. Responses to questions and a few comments inline: On 6/18/13 6:42 AM, Magnus Westerlund wrote: > Hi Robert, > > Thanks for the massive review. A number of really good comments in here. > Below you will find my answers, comments, questions and in most cases > clarifications what I see us doing with your comment. These covers your > major and minor comments. The nits we will simply implement as we see > fit, if we have questions we will comeback with those. > > WG, there are a number of issues in here that would be greatly helped by > your input! > > On 2013-06-05 23:56, Robert Sparks wrote: >> Document: draft-ietf-mmusic-rfc2326bis-34 >> Reviewer: Robert Sparks >> Review Date: 05-Jun-2013 >> IETF LC End Date: 04-Jun-2013 >> IESG Telechat date: not yet on a telechat >> >> >> The document is very long, and the structure is unusual - much of the >> definition of the protocol itself is in the appendices. You are missing >> an opportunity to make this document much shorter (thereby likely >> increasing its effectiveness). Much of the jump in from RFC2326 was >> importing the description of headers and responses from HTTP, tailoring >> them to RTSP. That was a good exercise in that it highlights some issues >> that would otherwise be non-obvious (and raises a few questions below). >> But you followed the style from HTTP perhaps too closely - much shorter >> descriptions without examples might have done the job better. Overall, >> separating exposition and examples from the protocol definition would >> make it much easier for an implementer to find the definition of the >> protocol, and use the document as a reference when diagnosing a failure >> to interoperate. > Agree, it would be differently structure if we wrote it from scratch > today. But it is an document that is 10 years in the making with dual > heritage in RFC 2326 and RFC 2068. > >> Major Issues >> >> I'm not seeing what instructs an RTSP element on how to find the server >> it would try to open a connection to given an rtsp or rtsps URI? Are you >> assuming it would be doing A or AAAA DNS lookups? > Yes, using A or AAAA DNS records are assumed. No problem making that > explicit. > > Should this protocol >> use NAPTR/SRV? > Potentially, but as everyone have been using A records for all these > years, I think it is not worth defining it at this stage. > > The document should be explicit. On a related note, (and >> maybe I missed this), but where do you talk about what an element should >> check in the server's certificate when connecting over TLS? Are you >> assuming a common name match? Or are you expecting some SubjectAltName >> processing? > This draft says in Section 19.2 the following regarding this: > > RTSP MUST follow the same guidelines with > regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. > > Where section 3.1 (Server Identity) of RFC 2818 contains the following: > > If a subjectAltName extension of type dNSName is present, that MUST > be used as the identity. Otherwise, the (most specific) Common Name > field in the Subject field of the certificate MUST be used. > > Isn't that clear enough on that matter? Yes - I was worried that I might have missed it before. > >> The document should say more about when connection reuse is appropriate, >> particularly when the connections happened because of an rtsps uri. Two >> different names might resolve to the same IP address - reusing a >> connection formed when looking at the first name (and verifying the >> server's cert) is dangerous. A new connection needs to be formed (and >> verified) instead. > I want to check my understanding of the issue you are seeing here. So a > client looks ups foo.example.org, gets an ip address A and establishes > an TCP/TLS connection and verifies that there are a SubjectAltName that > matches foo.example.org works. Then client is going to open > bar.example.com and looks up that address and gets the same IP address A. > Client matches A against existing connections and simply sends a request to > bar.example.com. Thus bypassing the certificate verification. > > If we clarify that in the process of opening rtsps://bar.example.com the > client MUST verify that the server certificate for the TLS connection it > considers re-using has an SubjectAltName of bar.example.com, does that > resolve your concerns. If not, please explain the concern further. You understood what I intended, and your resolution looks sufficient. > > >> The text talks about the option to queue S->C requests if there isn't a >> connection to the client available. Ostensibly, this means the request >> can go down some future connection. It's not clear how the server can >> tell the right client connected. In particular, when using rtsps, how do >> you prevent a malicious client from getting such a queued message that >> wasn't meant for him? > > Okay, this security issue I have totally missed but it is clearly > serious. I don't see any easy way of fixing this. Thus I would suggest > that we simply make it clear that a server MUST NOT queue the S->C RTSP > message, independent if they are requests PLAY_NOTIFY and TEARDOWN or > responses to client requests. Works for me. Does this mean you are removing cross-connection queueing altogether? > > >> Given that the text talks about queuing S-C requests, it should >> explicitly call out whether a server can queue a response if the >> connection the associated request arrived on is no longer available. I >> think what you want to say is that such a response must not be queued, >> and must be dropped. > Agreed, lets mandate that they are dropped. > > >> There are several places in the text that talk about using a 503 >> response with a Retry-After header to push back on traffic from an >> element (the first is section 10.7). >> * It's not clear what the subject of a 503 is. Is it intended to be >> scoped to requests to the resource in the RURI of the associated >> request? Is it intended to be scoped to the domain in that resource? Or >> is it, like in SIP, intended to be scoped to the server issuing the >> response, independent of what the RURI contained? > Very good question. It is far from obvious what the best choice is. And > I think even talking only about URI related scope may not be the best. > > The case I have in mind is if a proxy that has several already > established RTSP sessions over a persistent connection. When a client > connected to the proxy requests to establish a new session the server > may have insufficient resource to handle the SETUP request and send a > 503 answer. However if another client already having an RTSP session for > the same resource want to terminate that session it would be strange to > refuse to process the message as it will actually free up resources. > > This makes me believe that you need to have a RTSP Session scope for any > request carrying a Session-ID and a general server, or host name scope > for non-associated that doesn't prevent established sessions to try. > > Thoughts on this? That seems like it might work - exploring the idea should get some WG cycles. > > >> * If the intent is that the 503 talks about the server, then you should >> clarify that a proxy doesn't simply forward 503 responses (after >> rewriting CSeqs), and should probably have a response of its own. >> Otherwise, clients that might be talking to two different servers >> through one proxy would lose access to both of them when one of the >> servers 503ed. > If we us a host and session scope then this issue would not be present. > However, if the proxy is actually overloaded that still needs its own > 552 Proxy Unavailable response with the same scope rules as for the 503, > but where unassociated requests concerns sending to the proxy at all. If you build one of these, please be sure to highlight the impact of the other sessions already established, and call out the potential for problems if you forward one as a Proxy, as opposed to generating your own based on the situation. > >> Section 4.9.1 lists values the Seek-Style header can take, but 18.45 >> lists a completely different set (which most of the rest of the document >> uses). Should 4.9.1 be changed to use the values in 18.45? Are the right >> strings being used in sections 13.4.4 through 13.4.6? Those appear to be >> using strings from 4.9.1. > Yes, clearly an inconsistency issue that needs to be resolved. > >> The document will not stand if you delete some of the appendices. They >> aren't supplementary material. Please consider restructuring the >> normative sections back into the main document, or clearly identifying >> which ones define protocol and which are background information. > I would like to characterize this differently. I think you will have a > working protocol of RTSP, but you can't use it for anything. This as you > will have no media transport (C), no media description protocol (D), and > no parameters format (F). But, these appendixes are replaceable with > other protocol solutions. > > The Introduction section (1) says: > > The appendixes describe and define some > functionalities that are not part of the core RTSP specification, but > which are still important to enable some usages. Among them, the RTP > usage is defined in Appendix C and the SDP usage with RTSP is defined > in Appendix D, which are two mandatory appendixes. > > I note that we should add F to this list. > > I think we should be clear in each of this appendices that if one > support Foo for the purpose of bar then this appendix defines > normatively how one does it. Makes my head swim, but maybe it's must me. fwiw - I'm still worried that there are information in Appendix B that's not captured in the main text, but I can't find easy things to point to. Elwyn seems more comfortable that everything is covered. > > >> Section 15 talks about a "transparent' proxy, but there is no >> description in this document of what protocol such a thing should >> follow. What bad thing happens if you remove all mention of >> "transparent" proxies from the document? As far as I can tell, that >> won't affect the protocol definition at all. > Not really, there is no definition of transparent proxies currently. > There is one security concern that make require some word smithing if we > remove transparent proxies. > > >From my perspective a transparent proxy is something that hijacks a TCP > connection towards an RTSP server to be a proxy between client and > server. Further is not detectable from the client's or the servers > perspective, but still may modify RTSP messages within the bounds of the > RTSP protocol. > > But, in reality as we have proxies that are visible we should focus on > those and forget this bastard version. > >> The list of steps for establishing an SRTP cryptographic context in >> C.1.4.1 says "This specification does not specify an explicit method for >> indicating this SRTP cryptographic context establishment method, but >> future specifications may." in the context of looking at the SDP. SDP >> _has_ methods of indicating what keying mechanism is used with SRTP - >> are you talking about something different? > I think you are considering the methods for keying SRTP that are > Offer/Answer dependent. The only RTSP SDP using method that exist is the > one defined in RFC 4567, which we are explicit on not using. > > Why doesn't this section say >> something like "the use of SRTP with RTSP is only defined with MIKEY >> with keys established as defined in this section. Future documents may >> talk about how an RTSP implementation might treat SDP that indicates >> some other key mechanism be used"? > Yes, that is appears better, but we will have to make it clear that is > is regarding RTSP 2.0. Must also think if RFC 4567 needs to be worked > into that sentence. > > Could you provide an example in the >> document of an RTSP message carrying SDP reflecting the use of SRTP as >> defined in this document? > The point is that the only difference is that he RTP profile is SAVP/RTP > or SAVPF/RTP in the SDP. Thus making such an SDP isn't difficult. > Question is if it provides a benefit? I think it would be worth the extra space it would take up. > > > >> Minor Issues >> >> The document uses the notion of a "control connection" (it appears first >> in section 2.5) without defining what that is, or what kind of >> connections you might have that aren't control connections. > The "control connection" is the connection established for sending RTSP > messages on it. I agree it is undefined and could likely be replaced by > the "RTSP connection" or "connection for RTSP messages" > >> The update to the registration of the rtsp and rtsps schema call out >> that there are changes that can result in interoperability issues. It >> doesn't say what the issues are, or who might encounter them. I can >> infer that the point is that there might be problems if a URI following >> this updated registration were to be processed by an RTSP 1.0 >> implementation (or any other application that relied on the previous >> definition). It would be better to say that explicitly, and talk about >> how a previous implementation is likely to act when presented with a URI >> that exercised these new changes. > I have gotten these comment elsewhere and have prepared a text update > for section 4.2: > > The details of the syntax of "rtsp" and "rtsps" URIs has been changed > from RTSP 1.0. These changes are: > > o Support for IPV6 literal in host part and future IP literals > through RFC 3986 defined mechanism. > > o A new relative format to use in the RTSP protocol elements that is > not required to start with "/". > > Neither should have any significant impact on interoperability. If > one is required to use IPv6 literals to reach an RTSP server, then > that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully > IPv6 capable protocol. If an RTSP 1.0 client attempts to process the > URI it will not match the allowed syntax and be considered invalid > and processing will be stopped. This is clearly a failure to reach > the resource, however it is not a signification issue as RTSP 2.0 > support was needed anyway in both server and client. Thus failure > will only occur in a later step when there is a RTSP version > mismatch between client and server. The second change will only > occur in RTSP messages, that are explicitly identified as being RTSP > 2.0 messages, thus a RTSP 1.0 only agent will not be required to > parse this variant. > > Clear enough? Maybe. In the last sentence, are you saying you would never see a relative URL in a request URI? If you're not already saying that explicitly in the document (you might be) please consider doing so. Saying it that way in this text would also help. > > The above is Edited In. > > (It's not clear to me that all of the >> thread at www.ietf.org—msg01567.html >> >> concluded - I see how the fragments question ended, but what about >> things like the addition of IPV6 literals? In particular, I'm not >> finding a response where Ted Hardie agreed that the potential for >> interoperability failure had been adequately addressed). > I talked to him in person about this just after the discussion to better > understand his comments. If we want a confirmation I think we need to > loop him into a discussion regarding this particular issue. I suggest the shepherd/AD double-check with him if he doesn't jump into this thread before. > > I provided a clarification to the designated URI reviewer which accepted > the request. > >> >> I think you've said something different than you mean in 5.4 item 1. I >> think you mean to say that an RTSP implementation would ignore any body >> that happened to come in message that MUST NOT contain one. What you've >> said is that the part of the parser that's doing framing has to stop >> framing at the end of the headers, and that such an errant body would be >> parsed as a separate message. As written this would keep someone from >> using an Internet Message Format parser since it would have to ignore >> any Content-Length that might have appeared, even though it wasn't >> supposed to. > Yes, it is clearly sufficient to ignore the body, and likely much better > from an error handling consideration. > > We will propose a text change. > > >> In section 10.4, it looks like a server can keep an RTSP transaction >> pending forever if it sends 100 responses often enough. I assume the >> client's recourse if it doesn't want to remain involved is to close the >> connection. If that's right, it's worth calling it out explicitly in >> this section. > This is likely a good suggestion, and works fine if the client simply > wants to abort the request and is anyway abandoning the RTSP session. > However, the question is what to do if just the request becomes > irrelevant and instead want to do something else with the RTSP session. > A single client may abandon the connection, open a new one and issue a > request, to a potentially undetermined session state. Yet another > complexity is what a proxy does that has multiple RTSP sessions on the > same server. Here the rules for processing in order the different > requests and their relation to answers in the same order. > > This makes me want to weaken the recommendation on re-using an > connection for multiple RTSP sessions. Are there also considerations here wrt pipelining? > > >> Somewhere, probably in section 15.2, you should be explicit that a proxy >> that is multiplexing requests MUST keep the requests in the same order >> as they are folded together. You can infer that, or things simply break, >> but saying it explicitly would be better. > Probably, as a clarification to what is already present in section 18.19 > (CSeq header) > > Proxies that aggregate several sessions on the same transport will > have to ensure that the requests sent towards a particular server > have a joint sequence number space, i.e., they will regularly need to > renumber the CSeq header field in requests (from proxy to server) and > responses (from server to proxy) to fulfill the rules for the header. > The proxy MUST increase the CSeq by one for each request it > transmits, without regard of different sessions. > > >> Both GET_PARAMETER and SET_PARAMETER are listed as keep-alive methods in >> 10.5, but the note in section 13 on table 7 only uses that as a reason >> for requiring SET_PARAMETER. Why doesn't it also apply to GET_PARAMETER? >> And why is this only required at servers? "Required" in this section >> means Mandatory to Implement, I think. If that's right, it should be >> made explicit. If that's not right, what does it mean? > Yes, required is Required to implement in the server. The GET_PARAMETER > is not required as only one method for keep-alive is necessary. Thus, > the ones that needs to use GET/SET_PARAMETER for keep-alive will have to > choose SET_PARAMETER. > > It is only required at the server, as it is in the client implementation > choice of how to ensure keep-alive works. As this is also dependent on > the media transport support one has, the client may not need a method > based keep-alive. > > Clarifying "Required" should be straightforward. > >> Section 13.8 makes a good argument for always putting parameters to be >> retrieved in a body. Why are you keeping the complexity of also allowing >> them in headers? > Some arguments are probably lost in the passage of time. However, the > headers specified to be suitable for inclusion in a GET_PARAMETER > requests are used for providing these information also in other methods, > thus we have not wanted to duplicate the representation of this > information in both a body and a header form. > >> Section 13.10: "That should not provide any benefit." is not clear - can >> you expand it a little? > If the REDIRECT request times out following the rules in Section 10.4 > the server MAY terminate the session or transport connection that > would be redirected by the request. This is a safeguard against > misbehaving clients that refuse to respond to a REDIRECT request. > That should not provide any benefit. > > The intention here is to make clear that there shouldn't be an incentive > in the protocol to not acknowledge a REDIRECT request and instead simply > go on as it wasn't received or seen. Thus, we want to make clear that > the server may simply terminate the session in those cases. > > I propose we change this sentence to: > > Thus, removing any incentive to not acknowledge the reception of a > REDIRECT request. > > Edited In > >> In Section 13.10 you talk about clients _sending_ media (search for >> "send or receive media"). Do you mean anything more than possibly RTCP? >> Can you make that clear in the section? > You mean this sentence: > > After a REDIRECT request has been processed, a client that wants to > continue to send or receive media for the resource identified by the > Request-URI will have to establish a new session with the designated > host. > > The mentioning of send media is likely a RECORD reference. In this case > I don't see any issue with removing it. > > Edited In > >> Section 15.2's second paragraph appears to be the only place the proxy >> rewriting of CSeq in order to multiplex requests is defined, and it is >> very loose. It would be easy for a reader to fail to recognize this as >> an interoperability requirement. Please consider expanding how this is >> specified when addressing the comment about above about keeping requests >> in relative order when multiplexing. > There are text in Section 18.19 CSeq also. But I do think I agree that > this should be clarified. > >> You follow the principle of saying a client should treat a response with >> an unknown response code, the same as it would treat the x00 of that >> class (e.g. 400 for an unknown 4xx). However, you do not define what a >> response code of 300 means. How is a client supposed to handle an >> unknown 3xx response? > Sorry, I don't quite get this comment. Section 17.3 says: > > If a 3rr response is received for a request in relation to > an established session, the client SHOULD send a TEARDOWN request for > the session, and MAY reestablish the session using the resource > indicated by the Location. > > If the Location header is used in a response it MUST contain an > absolute URI pointing out the media resource the client is redirected > to, the URI MUST NOT only contain the host name. > > As explained above unknown 3XX codes will be 3rr codes, as 304 isn't > unknown. > > If you don't believe this is sufficient can you please be more explicit > about the issue? Sure. It might be quickest if you look at the table of contents. Note that you define 100 in 17.1.1, 200 in 17.2.1, 400 in 17.4.1, 500 in 17.5.1, but you do not define 300 anywhere - you jump straight to 301. Please add a section defining it, or declaring that you will never see a literal 300 on the wire, but if you did you would do (what you quote above) and nothing else. > >> As written, a client and server can use HTTP Basic authentication over >> TCP that is not protected with TLS. Consider restricting it's use to TLS >> only. Are you sure you don't need to say anything RTSP specific about >> DIGEST computations (I don't think you need to go as far as SIP did >> talking about DIGEST, but I'm surprised you haven't run into issues >> relying only on 2617 literally. > Are you referring to Section 19.1 here? Yes > > Yes, I would not have any issue with requiring Basic to be combined with > TLS. I think that is appropriate. > > When it comes to DIGEST, are you referring to section 22.4 in RFC 3261? Yes > > That section indicates that some clarifications are likely needed. > >> >> How does 411 Length Required for this protocol make sense? Given that >> you've restricted the protocol to TCP and require the Content-Length >> header to be present if there is a body, in what circumstance would a >> server need to send a 411? > It really should occur for malformed messages, which we could use 400 as > response. So yes, 411 could be removed. > >> >> Section 18.19 requires senders to increment CSeq by 1. We have a >> reliable transport with no request retransmission, so there should never >> be gaps at the receiver. Should the receiver check and react some way if >> there are gaps? I think you should explicitly tell them not to even >> look. If you agree, why is incrementing by one important as long as you >> are always strictly increasing? > I agree that for TCP or other reliable transports the receiver > SHOULD/SHALL ignore gaps. For any future specification of an unreliable > transport of RTSP messages this would be needed. As noted in Appendix G, > CSeq is retained for future support of unreliable transport. > >> You call out several places where RTCP is essential to allow RTSP using >> RTP to work correctly, yet section C.1.2 sets up conditions where RTCP >> MUST NOT be sent. Why are you allowing those instead of treating the >> conditions you describe as errors? > Good question. I think it is a case we must ensure that you can > negotiate and configure your desired way, without really considering if > it should be allowed at all. I think mandating usage of RTCP with RTP > for RTSP 2.0 would be good. But, I think that needs to be verified with > the WG. Ack > > cheers > > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From prvs=2882cd9844=christer.holmberg@ericsson.com Wed Jun 19 04:53:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934E621F99D9 for ; Wed, 19 Jun 2013 04:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axgwKyBCmW9h for ; Wed, 19 Jun 2013 04:53:22 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D121F99D1 for ; Wed, 19 Jun 2013 04:53:21 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-b5-51c19bafb04c Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 7A.51.10205.FAB91C15; Wed, 19 Jun 2013 13:53:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 13:53:19 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CSw== Date: Wed, 19 Jun 2013 11:53:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3AFDB7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre762QcDDbreWVlMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3Bn7L+9jLljiV7Hu4nTWBsZ3zl2MnBwSAiYSTccbWCBsMYkL 99azdTFycQgJHGWUaH2/GMpZxCixu2cXkMPBwSZgIdH9TxukQURAXeLr3h5mEFtYwFhi2qtm Voi4hcTEFxvYIWw9ictr+8FqWARUJRYcfAoW5xXwlbi+ZgsjiM0ItPj7qTVMIDazgLjErSfz mSAOEpBYsuc8M4QtKvHy8T9WkBMkBBQllvfLQZTnS3x4+Z0FYqSgxMmZT1gmMArNQjJpFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGjuLU4qTcdCODTYzAwD+45bfFDsbL f20OMUpzsCiJ8346tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJqYBRtUBEoKvPqvJWQ O8fd/NnRzpLT52z8Xs24JZypeX/rStmToVIzONOF/3ntcXARFG4ySzby6192MPbJ37Qthzg3 C96dtnV/QxA3193O3fbnI/WjL9+1fyrKXPO29t55k+fXI+6rv63zDb7yoIN79eVbNos1Y/+L HfIL/OnslH+yq7ZLed2ENiWW4oxEQy3mouJEACIIM+5PAgAA Subject: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 11:53:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3AFDB7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I put together some text regarding the de-muxing for BUNDLE. Note that there is yet no text on HOW the de-muxing is performed. The text = only cover the SCOPE of what will be specified in the BUNDLE spec. I want u= s to agree on that first :) Regards, Christer --------------------------------------------------- 9. Transport Protocol De-Multiplexing 9.1. General Endpoints can assign "m=3D" lines representing different transport protocols [RFC4566], identified using the "m=3D" line proto value [RFC4566]. As each "m=3D" line in a BUNDLE group share the BUNDLE address, an endpoint MUST be able to de-multiplex data received on the BUNDLE address, meaning it MUST be able to associate the received with one of the transport protocols assigned to the BUNDLE group. Endpoints MUST NOT assign a transport protocols to a BUNDLE group, unless it is able to separate received data from data associated with other transport protocols assigned to the BUNDLE group. In addition, if an endpoint assigns multiple "m=3D" lines representing the same transport protocol to a BUNDLE group, the endpoint MUST be able to, in addition to associating received data to its transport protocol, also associate the received data with a specific "m=3D" line representing that transport protocol. This specification defines how to de-multiplex received media associated with the following transport protocols: o "RTP/AVP" [RFC4566]; o "RTP/AVPF" [RFC4585]; o "RTP/SAVP" [RFC3711]; o "RTP/SAVPF" [RFC5124];and o "SCTP/DTLS" [ref-to-be added]. This specification also specifies how RTP packats are separated from RTCP packets. If an endpoint assigns multiple "m=3D" lines representing RTP/RTCP media to a BUNDLE group, it is outside the scope of this specification how the endpoint associates received RTP/RTCP packets with a specific RTP/RTCP "m=3D" line (endpoints might use payload type values, or SSRC values, for the association). If endpoints want to assign "m=3D" lines representing other transport protocols to a BUNDLE group, it MUST be documented how the de- multiplexing is performed. There might also be a need for signalling extensions in order for endpoints to exchange data needed for the de- multiplexing. --_000_7594FB04B1934943A5C02806D1A2204B1C3AFDB7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I put together some text regarding the de-muxing for= BUNDLE.

 

Note that there is yet no text on HOW the de-muxing = is performed. The text only cover the SCOPE of what will be specified in th= e BUNDLE spec. I want us to agree on that first :)

 

Regards,

 

Christer

 

 

---------------------------------------------------<= o:p>

 

 

 

9.  Transport Protocol De-Multiplexing

 

9.1.  General

 

   Endpoints can assign "m=3D" l= ines representing different transport

   protocols [RFC4566], identified using t= he "m=3D" line proto value

   [RFC4566].

 

   As each "m=3D" line in a BUND= LE group share the BUNDLE address, an

   endpoint MUST be able to de-multiplex d= ata received on the BUNDLE

   address, meaning it MUST be able to ass= ociate the received with one

   of the transport protocols assigned to = the BUNDLE group.  Endpoints

   MUST NOT assign a transport protocols t= o a BUNDLE group, unless it is

   able to separate received data from dat= a associated with other

   transport protocols assigned to the BUN= DLE group.

 

   In addition, if an endpoint assigns mul= tiple "m=3D" lines representing

   the same transport protocol to a BUNDLE= group, the endpoint MUST be

   able to, in addition to associating rec= eived data to its transport

   protocol, also associate the received d= ata with a specific "m=3D" line

   representing that transport protocol.

 

   This specification defines how to de-mu= ltiplex received media

   associated with the following transport= protocols:

 

   o  "RTP/AVP" [RFC4566];<= o:p>

 

   o  "RTP/AVPF" [RFC4585];=

 

   o  "RTP/SAVP" [RFC3711];=

 

   o  "RTP/SAVPF" [RFC5124]= ;and

 

   o  "SCTP/DTLS" [ref-to-b= e added].

 

   This specification also specifies how R= TP packats are separated from

   RTCP packets.

 

   If an endpoint assigns multiple "m= =3D" lines representing RTP/RTCP

   media to a BUNDLE group, it is outside = the scope of this

   specification how the endpoint associat= es received RTP/RTCP packets

   with a specific RTP/RTCP "m=3D&quo= t; line (endpoints might use payload type

   values, or SSRC values, for the associa= tion).

 

   If endpoints want to assign "m=3D&= quot; lines representing other transport

   protocols to a BUNDLE group, it MUST be= documented how the de-

   multiplexing is performed.  There = might also be a need for signalling

   extensions in order for endpoints to ex= change data needed for the de-

   multiplexing.

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3AFDB7ESESSMB209erics_-- From hannes.tschofenig@gmx.net Wed Jun 19 05:12:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1621F9A33 for ; Wed, 19 Jun 2013 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.114 X-Spam-Level: X-Spam-Status: No, score=-101.114 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNdoW0gTUzoD for ; Wed, 19 Jun 2013 05:11:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1F52F21F9A47 for ; Wed, 19 Jun 2013 05:11:57 -0700 (PDT) Received: from 3capp-gmx-bs32.server.lan ([172.19.170.84]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M0euW-1U2HFq04mU-00ut7I; Wed, 19 Jun 2013 14:11:48 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs32.server.lan with HTTP; Wed Jun 19 14:11:48 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Flemming Andreasen" Content-Type: text/html; charset=UTF-8 Date: Wed, 19 Jun 2013 14:11:47 +0200 (CEST) Importance: normal Sensitivity: Normal In-Reply-To: <51BA44CC.6000607@cisco.com> References: <51BA44CC.6000607@cisco.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:JRPP7RtjMO2jXR2WTWcUwrKz5sbFbH2ZctA5+qhSNKl Ct85QhNF75oDaFpeng3z2zBiHpgdEPagFC5sFy+6VI3Hs/Fljk soKsgmeRu5ZA76Qul7uF5MhJKE64Cjb2+2oK/4VwifZr6DiamE imD4auM+vH7KLY3crVLtA3kWUvIqJraLlQJSIP5RZvgwJryznn AsqyoZJiL2ofgoArxnZ+AphnAD3f/x/Ej2yuQd7k6vI0a5lfxA 3Mmxuq7ZednNj/0JBiLJLtea9onlKBG4pQc3nV9FJ2eH+Mae8j 67YPpo= Cc: Ari Keranen , mmusic , Hadriel Kaplan , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 12:12:04 -0000
Hi Flemming, 
 
I am still willing to continue and complete this work. 
 
Gonzalo and I had tried to reach out to Hadriel numerous times to better understand his review remarks but unfortunately without success. 
 
Ciao
Hannes
 
PS: Btw, the "significant concerns", as you called them, came from one person, Hadriel. 
 
 
Gesendet: Freitag, 14. Juni 2013 um 00:16 Uhr
Von: "Flemming Andreasen" <fandreas@cisco.com>
An: mmusic <mmusic@ietf.org>
Cc: "Ari Keranen" <ari.keranen@ericsson.com>, "Hadriel Kaplan" <HKaplan@acmepacket.com>, draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org
Betreff: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ?
Greetings MMUSIC

As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and we have a WG draft for that in the form of

    http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/

When we polled for interest in this work about 1 year ago (per the above thread), there was some indication of continued interest in the work, however there were also some (significant) concerns expressed with the draft itself (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). These concerns have existed for well over a year and we have seen very little discussion or active work trying to resolve them.

In lieu of the above, the chairs would like to ask the WG participants to

1) Indicate if you are in favor of continuing this work.

2) If you are willing to actively contribute to the work by either
a) Sign on as co-author, drive the open issues to resolution, and update the document accordingly
b) Actively contribute to discussion and resolution of open issues in the draft.

Please note, that if you answer "yes" to 2a or 2b, then you should assume that you *will* get called upon to deliver on that.

Also please note, that if we do not get sufficient positive responses to both 1 and 2 above, then our plan is to remove the milestone and abandon the WG draft.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)












 
From thomas.stach@siemens-enterprise.com Wed Jun 19 05:12:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7132321F995B for ; Wed, 19 Jun 2013 05:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPm3z3cMqiqd for ; Wed, 19 Jun 2013 05:12:45 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 991FF21F965B for ; Wed, 19 Jun 2013 05:12:44 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0B6C21EB85BC; Wed, 19 Jun 2013 14:12:43 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Wed, 19 Jun 2013 14:12:42 +0200 From: "Stach, Thomas" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CSwAAg1pg Date: Wed, 19 Jun 2013 12:12:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE12114507CBMCHP04MSXglobal_" MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 12:12:57 -0000 --_000_F81CEE99482EFE438DAE2A652361EE12114507CBMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, although BUNDLE can be used independent of ICE, the de-mux should consider = STUN messages which will also arrive at the BUNDLE address. If this is then in scope or out of the scope of the BUNDLE spec can be disc= ussed. However, I would regard it being in scope. Regards Thomas ________________________________ Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im Auftrag vo= n Christer Holmberg Gesendet: Mittwoch, 19. Juni 2013 13:53 An: mmusic@ietf.org Betreff: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Hi, I put together some text regarding the de-muxing for BUNDLE. Note that there is yet no text on HOW the de-muxing is performed. The text = only cover the SCOPE of what will be specified in the BUNDLE spec. I want u= s to agree on that first :) Regards, Christer --------------------------------------------------- 9. Transport Protocol De-Multiplexing 9.1. General Endpoints can assign "m=3D" lines representing different transport protocols [RFC4566], identified using the "m=3D" line proto value [RFC4566]. As each "m=3D" line in a BUNDLE group share the BUNDLE address, an endpoint MUST be able to de-multiplex data received on the BUNDLE address, meaning it MUST be able to associate the received with one of the transport protocols assigned to the BUNDLE group. Endpoints MUST NOT assign a transport protocols to a BUNDLE group, unless it is able to separate received data from data associated with other transport protocols assigned to the BUNDLE group. In addition, if an endpoint assigns multiple "m=3D" lines representing the same transport protocol to a BUNDLE group, the endpoint MUST be able to, in addition to associating received data to its transport protocol, also associate the received data with a specific "m=3D" line representing that transport protocol. This specification defines how to de-multiplex received media associated with the following transport protocols: o "RTP/AVP" [RFC4566]; o "RTP/AVPF" [RFC4585]; o "RTP/SAVP" [RFC3711]; o "RTP/SAVPF" [RFC5124];and o "SCTP/DTLS" [ref-to-be added]. This specification also specifies how RTP packats are separated from RTCP packets. If an endpoint assigns multiple "m=3D" lines representing RTP/RTCP media to a BUNDLE group, it is outside the scope of this specification how the endpoint associates received RTP/RTCP packets with a specific RTP/RTCP "m=3D" line (endpoints might use payload type values, or SSRC values, for the association). If endpoints want to assign "m=3D" lines representing other transport protocols to a BUNDLE group, it MUST be documented how the de- multiplexing is performed. There might also be a need for signalling extensions in order for endpoints to exchange data needed for the de- multiplexing. --_000_F81CEE99482EFE438DAE2A652361EE12114507CBMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Christer,
 
although BUNDLE can be used independent of ICE, the de-mux s= hould consider STUN messages which will also arrive at the BUNDLE address.<= /font>
If this is then in scope or out of the scope of the BUNDLE s= pec can be discussed.
However, I would regard it being in scope.
 

Regards
Thomas

 

Von: mmusic-bounces@ietf.org [mailt= o:mmusic-bounces@ietf.org] Im Auftrag von Christer Holmberg
Gesendet: Mittwoch, 19. Juni 2013 13:53
An: mmusic@ietf.org
Betreff: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Hi,

 

I put together some text regarding the de-muxing for= BUNDLE.

 

Note that there is yet no text on HOW the de-muxing = is performed. The text only cover the SCOPE of what will be specified in th= e BUNDLE spec. I want us to agree on that first :)

 

Regards,

 

Christer

 

 

---------------------------------------------------<= o:p>

 

 

 

9.  Transport Protocol De-Multiplexing

 

9.1.  General

 

   Endpoints can assign "m=3D" l= ines representing different transport

   protocols [RFC4566], identified using t= he "m=3D" line proto value

   [RFC4566].

 

   As each "m=3D" line in a BUND= LE group share the BUNDLE address, an

   endpoint MUST be able to de-multiplex d= ata received on the BUNDLE

   address, meaning it MUST be able to ass= ociate the received with one

   of the transport protocols assigned to = the BUNDLE group.  Endpoints

   MUST NOT assign a transport protocols t= o a BUNDLE group, unless it is

   able to separate received data from dat= a associated with other

   transport protocols assigned to the BUN= DLE group.

 

   In addition, if an endpoint assigns mul= tiple "m=3D" lines representing

   the same transport protocol to a BUNDLE= group, the endpoint MUST be

   able to, in addition to associating rec= eived data to its transport

   protocol, also associate the received d= ata with a specific "m=3D" line

   representing that transport protocol.

 

   This specification defines how to de-mu= ltiplex received media

   associated with the following transport= protocols:

 

   o  "RTP/AVP" [RFC4566];<= o:p>

 

   o  "RTP/AVPF" [RFC4585];=

 

   o  "RTP/SAVP" [RFC3711];=

 

   o  "RTP/SAVPF" [RFC5124]= ;and

 

   o  "SCTP/DTLS" [ref-to-b= e added].

 

   This specification also specifies how R= TP packats are separated from

   RTCP packets.

 

   If an endpoint assigns multiple "m= =3D" lines representing RTP/RTCP

   media to a BUNDLE group, it is outside = the scope of this

   specification how the endpoint associat= es received RTP/RTCP packets

   with a specific RTP/RTCP "m=3D&quo= t; line (endpoints might use payload type

   values, or SSRC values, for the associa= tion).

 

   If endpoints want to assign "m=3D&= quot; lines representing other transport

   protocols to a BUNDLE group, it MUST be= documented how the de-

   multiplexing is performed.  There = might also be a need for signalling

   extensions in order for endpoints to ex= change data needed for the de-

   multiplexing.

 

--_000_F81CEE99482EFE438DAE2A652361EE12114507CBMCHP04MSXglobal_-- From prvs=2882cd9844=christer.holmberg@ericsson.com Wed Jun 19 05:19:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CBB21F9BFB for ; Wed, 19 Jun 2013 05:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.764 X-Spam-Level: X-Spam-Status: No, score=-5.764 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB2sJlRZDYXY for ; Wed, 19 Jun 2013 05:19:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18E21F9BF1 for ; Wed, 19 Jun 2013 05:19:08 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-6e-51c1a1bc82a9 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 94.FF.18006.CB1A1C15; Wed, 19 Jun 2013 14:19:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 14:19:08 +0200 From: Christer Holmberg To: "Stach, Thomas" , "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CSwAAg1pgAABrTjA= Date: Wed, 19 Jun 2013 12:19:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AFE5D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvre6ehQcDDV7sF7GYuvwxi8Wu7TUO TB5Llvxk8rhx+z1zAFMUt01SYklZcGZ6nr5dAnfGoWfvmAtWSlasPH6IvYHxokgXIyeHhICJ RNest6wQtpjEhXvr2boYuTiEBA4zSixctpEVwlnEKLH+YitjFyMHB5uAhUT3P22QBhGBBImX r3azg9jCAuYSHyb8YYeIW0hMfLEByraSuDTjERuIzSKgKnHjdDtYnFfAV+LD+ZcsEPMnMUqs +zIZrIhTwF/i4YbVYDYj0EXfT61hArGZBcQlbj2ZzwRxqYDEkj3nmSFsUYmXj/+xgtwmIaAo sbxfDqJcT+LG1ClsELa2xLKFr5kh9gpKnJz5hGUCo+gsJFNnIWmZhaRlFpKWBYwsqxjZcxMz c9LLjTYxAmPh4JbfqjsY75wTOcQozcGiJM778dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTByc IIJLqoGxU9u2e/vbXdINjjf7OoRC8/XCPEt/1zJ++OEqFG3StZgxwC3v7YaKlTPePP39bKEC m9mXt2cEcsRnWqW0heTaiRyKlvrC8fLrZJUY4VY7s8MX1S9HTlvYuy3r9eeWOdMKlArTbhv9 DSqx3uNfLx3AW/PYMoN5gjLD70PTDuiGSBywujOTo1CJpTgj0VCLuag4EQCgqeGYWAIAAA== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 12:19:17 -0000 Hi Thomas, =A0 > although BUNDLE can be used independent of ICE, the de-mux should conside= r STUN messages which will also arrive at the BUNDLE address. > If this is then in scope or out of the scope of the BUNDLE spec can be di= scussed. > However, I would regard it being in scope. Good point. I personally strongly think STUN shall be in the scope. Regards, Christer =A0 ________________________________________ Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im Auftrag vo= n Christer Holmberg Gesendet: Mittwoch, 19. Juni 2013 13:53 An: mmusic@ietf.org Betreff: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Hi, I put together some text regarding the de-muxing for BUNDLE. Note that there is yet no text on HOW the de-muxing is performed. The text = only cover the SCOPE of what will be specified in the BUNDLE spec. I want u= s to agree on that first :) Regards, Christer --------------------------------------------------- 9.=A0 Transport Protocol De-Multiplexing 9.1.=A0 General =A0=A0 Endpoints can assign "m=3D" lines representing different transport =A0=A0 protocols [RFC4566], identified using the "m=3D" line proto value =A0=A0 [RFC4566]. =A0=A0 As each "m=3D" line in a BUNDLE group share the BUNDLE address, an =A0=A0 endpoint MUST be able to de-multiplex data received on the BUNDLE =A0=A0 address, meaning it MUST be able to associate the received with one =A0=A0 of the transport protocols assigned to the BUNDLE group.=A0 Endpoint= s =A0=A0 MUST NOT assign a transport protocols to a BUNDLE group, unless it i= s =A0=A0 able to separate received data from data associated with other =A0=A0 transport protocols assigned to the BUNDLE group. =A0=A0 In addition, if an endpoint assigns multiple "m=3D" lines representi= ng =A0=A0 the same transport protocol to a BUNDLE group, the endpoint MUST be =A0=A0 able to, in addition to associating received data to its transport =A0=A0 protocol, also associate the received data with a specific "m=3D" li= ne =A0=A0 representing that transport protocol. =A0=A0 This specification defines how to de-multiplex received media =A0=A0 associated with the following transport protocols: =A0=A0 o=A0 "RTP/AVP" [RFC4566]; =A0=A0 o=A0 "RTP/AVPF" [RFC4585]; =A0=A0 o=A0 "RTP/SAVP" [RFC3711]; =A0=A0 o=A0 "RTP/SAVPF" [RFC5124];and =A0=A0 o=A0 "SCTP/DTLS" [ref-to-be added]. =A0=A0 This specification also specifies how RTP packats are separated from =A0=A0 RTCP packets. =A0=A0 If an endpoint assigns multiple "m=3D" lines representing RTP/RTCP =A0=A0 media to a BUNDLE group, it is outside the scope of this =A0=A0 specification how the endpoint associates received RTP/RTCP packets =A0=A0 with a specific RTP/RTCP "m=3D" line (endpoints might use payload ty= pe =A0=A0 values, or SSRC values, for the association). =A0=A0 If endpoints want to assign "m=3D" lines representing other transpor= t =A0=A0 protocols to a BUNDLE group, it MUST be documented how the de- =A0=A0 multiplexing is performed.=A0 There might also be a need for signall= ing =A0=A0 extensions in order for endpoints to exchange data needed for the de= - =A0=A0 multiplexing. From harald@alvestrand.no Wed Jun 19 05:31:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353821F9BFB for ; Wed, 19 Jun 2013 05:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SJcTPlKQdyg for ; Wed, 19 Jun 2013 05:31:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 22CF821F9BB3 for ; Wed, 19 Jun 2013 05:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E599739E1C4 for ; Wed, 19 Jun 2013 14:31:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZWtO1yZ-sV7 for ; Wed, 19 Jun 2013 14:31:32 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 52EA239E1C2 for ; Wed, 19 Jun 2013 14:31:32 +0200 (CEST) Message-ID: <51C1A4A3.6070105@alvestrand.no> Date: Wed, 19 Jun 2013 14:31:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------060705010308080600080404" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 12:31:42 -0000 This is a multi-part message in MIME format. --------------060705010308080600080404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/19/2013 01:53 PM, Christer Holmberg wrote: > > Hi, > > I put together some text regarding the de-muxing for BUNDLE. > > Note that there is yet no text on HOW the de-muxing is performed. The > text only cover the SCOPE of what will be specified in the BUNDLE > spec. I want us to agree on that first :) > I think you should be careful about this. You risk duplicating material from other specs. > Regards, > > Christer > > --------------------------------------------------- > > 9. Transport Protocol De-Multiplexing > > 9.1. General > > Endpoints can assign "m=" lines representing different transport > > protocols [RFC4566], identified using the "m=" line proto value > > [RFC4566]. > > As each "m=" line in a BUNDLE group share the BUNDLE address, an > > endpoint MUST be able to de-multiplex data received on the BUNDLE > > address, meaning it MUST be able to associate the received with one > > of the transport protocols assigned to the BUNDLE group. Endpoints > > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > > able to separate received data from data associated with other > > transport protocols assigned to the BUNDLE group. > > In addition, if an endpoint assigns multiple "m=" lines representing > > the same transport protocol to a BUNDLE group, the endpoint MUST be > > able to, in addition to associating received data to its transport > > protocol, also associate the received data with a specific "m=" line > > representing that transport protocol. > > This specification defines how to de-multiplex received media > > associated with the following transport protocols: > > o "RTP/AVP" [RFC4566]; > > o "RTP/AVPF" [RFC4585]; > > o "RTP/SAVP" [RFC3711]; > > o "RTP/SAVPF" [RFC5124];and > > o "SCTP/DTLS" [ref-to-be added]. > This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead: This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []). And that makes the specification of the demultiplexing very simple: "See RFC 5764 section 5.1.2" > This specification also specifies how RTP packats are separated from > > RTCP packets. > Again, the specification of how to do this separation is very simple: "See RFC 5761 section 4" > > If an endpoint assigns multiple "m=" lines representing RTP/RTCP > > media to a BUNDLE group, it is outside the scope of this > > specification how the endpoint associates received RTP/RTCP packets > > with a specific RTP/RTCP "m=" line (endpoints might use payload type > > values, or SSRC values, for the association). > > If endpoints want to assign "m=" lines representing other transport > > protocols to a BUNDLE group, it MUST be documented how the de- > > multiplexing is performed. There might also be a need for signalling > > extensions in order for endpoints to exchange data needed for the de- > > multiplexing. > I agree with the sense of these paragraphs. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------060705010308080600080404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/19/2013 01:53 PM, Christer Holmberg wrote:

Hi,

 

I put together some text regarding the de-muxing for BUNDLE.

 

Note that there is yet no text on HOW the de-muxing is performed. The text only cover the SCOPE of what will be specified in the BUNDLE spec. I want us to agree on that first :)


I think you should be careful about this. You risk duplicating material from other specs.

 

Regards,

 

Christer

 

 

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

 

 

 

9.  Transport Protocol De-Multiplexing

 

9.1.  General

 

   Endpoints can assign "m=" lines representing different transport

   protocols [RFC4566], identified using the "m=" line proto value

   [RFC4566].

 

   As each "m=" line in a BUNDLE group share the BUNDLE address, an

   endpoint MUST be able to de-multiplex data received on the BUNDLE

   address, meaning it MUST be able to associate the received with one

   of the transport protocols assigned to the BUNDLE group.  Endpoints

   MUST NOT assign a transport protocols to a BUNDLE group, unless it is

   able to separate received data from data associated with other

   transport protocols assigned to the BUNDLE group.

 

   In addition, if an endpoint assigns multiple "m=" lines representing

   the same transport protocol to a BUNDLE group, the endpoint MUST be

   able to, in addition to associating received data to its transport

   protocol, also associate the received data with a specific "m=" line

   representing that transport protocol.

 

   This specification defines how to de-multiplex received media

   associated with the following transport protocols:

 

   o  "RTP/AVP" [RFC4566];

 

   o  "RTP/AVPF" [RFC4585];

 

   o  "RTP/SAVP" [RFC3711];

 

   o  "RTP/SAVPF" [RFC5124];and

 

   o  "SCTP/DTLS" [ref-to-be added].


This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead:

This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []).

And that makes the specification of the demultiplexing very simple:

"See RFC 5764 section 5.1.2"

 

   This specification also specifies how RTP packats are separated from

   RTCP packets.


Again, the specification of how to do this separation is very simple:

"See RFC 5761 section 4"

 

   If an endpoint assigns multiple "m=" lines representing RTP/RTCP

   media to a BUNDLE group, it is outside the scope of this

   specification how the endpoint associates received RTP/RTCP packets

   with a specific RTP/RTCP "m=" line (endpoints might use payload type

   values, or SSRC values, for the association).

 

   If endpoints want to assign "m=" lines representing other transport

   protocols to a BUNDLE group, it MUST be documented how the de-

   multiplexing is performed.  There might also be a need for signalling

   extensions in order for endpoints to exchange data needed for the de-

   multiplexing.


I agree with the sense of these paragraphs.

 



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

--------------060705010308080600080404-- From prvs=58822a6647=christer.holmberg@ericsson.com Wed Jun 19 05:37:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12CB21F9C61 for ; Wed, 19 Jun 2013 05:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.777 X-Spam-Level: X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLOMss6LKMaA for ; Wed, 19 Jun 2013 05:37:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83E21F853A for ; Wed, 19 Jun 2013 05:36:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-81-51c1a5ea4d6b Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0E.12.18006.AE5A1C15; Wed, 19 Jun 2013 14:36:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 14:36:58 +0200 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTA= Date: Wed, 19 Jun 2013 12:36:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> In-Reply-To: <51C1A4A3.6070105@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvre7rpQcDDT5+5LM41tfFZjF1+WMW ByaPKxOusHosWfKTKYApitsmKbGkLDgzPU/fLoE74/qNmewFTXIV61d2MDUwbpboYuTkkBAw keha9ZEVwhaTuHBvPVsXIxeHkMBhRonpvU+ZIJxFjBL7G9vZuxg5ONgELCS6/2mDNIgIBEss /7SdCcQWFnCQuPd7FiNE3FGieclbFgjbSuLck/lsIDaLgKrE4y0N7CA2r4CvxJLjW8AWCwkU SHQf/QdWwymgKzF753OwOYxAB30/tQZsPrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP1aQ0yQE FCWW98tBlOtJ3Jg6hQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVI3tu YmZOernRJkZgLBzc8lt1B+OdcyKHGKU5WJTEeT+e2hUoJJCeWJKanZpakFoUX1Sak1p8iJGJ gxNEcEk1MDIuvOPUNWGRiabZEgu+ltir8+/N/iSpcVdYz9OHicGao6uGKydlqlll4OPNe6ep Goqqfl/w7dlNWcXPy94czbQT0dOcxVrzjsn4gLX18UStfYfNLWes+vY42lZkRZ6laE3Sjl2V l071v93ppt29f0vcM6b0ec9lZoTkP9Xexrdgh5Dpa6OtJ5VYijMSDbWYi4oTAdCL9HZYAgAA Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 12:37:34 -0000 Hi Harald, =A0 >>I put together some text regarding the de-muxing for BUNDLE. >> >>Note that there is yet no text on HOW the de-muxing is performed. The tex= t only cover the SCOPE of what will be specified in the BUNDLE spec. I want= us to agree on that first :) > > I think you should be careful about this. You risk duplicating material f= rom other specs. That's why I am eager to hear your input on what shall be covered in the BU= NDLE spec regarding de-muxing :) For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is d= one? Regards, Christer =A0 =A0 --------------------------------------------------- =A0 =A0 =A0 9.=A0 Transport Protocol De-Multiplexing =A0 9.1.=A0 General =A0 =A0=A0 Endpoints can assign "m=3D" lines representing different transport =A0=A0 protocols [RFC4566], identified using the "m=3D" line proto value =A0=A0 [RFC4566]. =A0 =A0=A0 As each "m=3D" line in a BUNDLE group share the BUNDLE address, an =A0=A0 endpoint MUST be able to de-multiplex data received on the BUNDLE =A0=A0 address, meaning it MUST be able to associate the received with one =A0=A0 of the transport protocols assigned to the BUNDLE group.=A0 Endpoint= s =A0=A0 MUST NOT assign a transport protocols to a BUNDLE group, unless it i= s =A0=A0 able to separate received data from data associated with other =A0=A0 transport protocols assigned to the BUNDLE group. =A0 =A0=A0 In addition, if an endpoint assigns multiple "m=3D" lines representi= ng =A0=A0 the same transport protocol to a BUNDLE group, the endpoint MUST be =A0=A0 able to, in addition to associating received data to its transport =A0=A0 protocol, also associate the received data with a specific "m=3D" li= ne =A0=A0 representing that transport protocol. =A0 =A0=A0 This specification defines how to de-multiplex received media =A0=A0 associated with the following transport protocols: =A0 =A0=A0 o=A0 "RTP/AVP" [RFC4566]; =A0 =A0=A0 o=A0 "RTP/AVPF" [RFC4585]; =A0 =A0=A0 o=A0 "RTP/SAVP" [RFC3711]; =A0 =A0=A0 o=A0 "RTP/SAVPF" [RFC5124];and =A0 =A0=A0 o=A0 "SCTP/DTLS" [ref-to-be added]. This is somewhat incomprehensible to me; the most logical description I can= make is that it means that you can separate packets into one heap containi= ng all the RTP variants and another heap containing SCTP/DTLS - but that is= not obvious. Suggest instead: This specification defines how to de-multiplex protocols carried over RTP (= which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from pro= tocols carried over DTLS (which include SCTP/DTLS []). And that makes the specification of the demultiplexing very simple: "See RFC 5764 section 5.1.2" =A0 =A0=A0 This specification also specifies how RTP packats are separated from =A0=A0 RTCP packets. Again, the specification of how to do this separation is very simple: "See RFC 5761 section 4" =A0 =A0=A0 If an endpoint assigns multiple "m=3D" lines representing RTP/RTCP =A0=A0 media to a BUNDLE group, it is outside the scope of this =A0=A0 specification how the endpoint associates received RTP/RTCP packets =A0=A0 with a specific RTP/RTCP "m=3D" line (endpoints might use payload ty= pe =A0=A0 values, or SSRC values, for the association). =A0 =A0=A0 If endpoints want to assign "m=3D" lines representing other transpor= t =A0=A0 protocols to a BUNDLE group, it MUST be documented how the de- =A0=A0 multiplexing is performed.=A0 There might also be a need for signall= ing =A0=A0 extensions in order for endpoints to exchange data needed for the de= - =A0=A0 multiplexing. I agree with the sense of these paragraphs. =A0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Wed Jun 19 05:48:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921C221F9A59 for ; Wed, 19 Jun 2013 05:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2NvGgRyrri6 for ; Wed, 19 Jun 2013 05:48:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10221F9A36 for ; Wed, 19 Jun 2013 05:48:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DBE839E1C8; Wed, 19 Jun 2013 14:48:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tri+RwgpzC1D; Wed, 19 Jun 2013 14:48:27 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0AD5D39E1C4; Wed, 19 Jun 2013 14:48:26 +0200 (CEST) Message-ID: <51C1A89A.9020603@alvestrand.no> Date: Wed, 19 Jun 2013 14:48:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 12:48:34 -0000 On 06/19/2013 02:36 PM, Christer Holmberg wrote: > Hi Harald, > >>> I put together some text regarding the de-muxing for BUNDLE. >>> >>> Note that there is yet no text on HOW the de-muxing is performed. The text only cover the SCOPE of what will be specified in the BUNDLE spec. I want us to agree on that first :) >> I think you should be careful about this. You risk duplicating material from other specs. > That's why I am eager to hear your input on what shall be covered in the BUNDLE spec regarding de-muxing :) > > For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is done? Absolutely, I'm saying that BUNDLE should not specify a procedure for de-muxing. Instead, it should point to the specs that already specify how the de-muxing is done. See my comments below as to what I think it should say. > > Regards, > > Christer > > > > > --------------------------------------------------- > > > > 9. Transport Protocol De-Multiplexing > > 9.1. General > > Endpoints can assign "m=" lines representing different transport > protocols [RFC4566], identified using the "m=" line proto value > [RFC4566]. > > As each "m=" line in a BUNDLE group share the BUNDLE address, an > endpoint MUST be able to de-multiplex data received on the BUNDLE > address, meaning it MUST be able to associate the received with one > of the transport protocols assigned to the BUNDLE group. Endpoints > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > able to separate received data from data associated with other > transport protocols assigned to the BUNDLE group. > > In addition, if an endpoint assigns multiple "m=" lines representing > the same transport protocol to a BUNDLE group, the endpoint MUST be > able to, in addition to associating received data to its transport > protocol, also associate the received data with a specific "m=" line > representing that transport protocol. > > This specification defines how to de-multiplex received media > associated with the following transport protocols: > > o "RTP/AVP" [RFC4566]; > > o "RTP/AVPF" [RFC4585]; > > o "RTP/SAVP" [RFC3711]; > > o "RTP/SAVPF" [RFC5124];and > > o "SCTP/DTLS" [ref-to-be added]. > > This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead: > > > This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []). > > And that makes the specification of the demultiplexing very simple: > > "See RFC 5764 section 5.1.2" > > > > This specification also specifies how RTP packats are separated from > RTCP packets. > > Again, the specification of how to do this separation is very simple: > > "See RFC 5761 section 4" > > > If an endpoint assigns multiple "m=" lines representing RTP/RTCP > media to a BUNDLE group, it is outside the scope of this > specification how the endpoint associates received RTP/RTCP packets > with a specific RTP/RTCP "m=" line (endpoints might use payload type > values, or SSRC values, for the association). > > If endpoints want to assign "m=" lines representing other transport > protocols to a BUNDLE group, it MUST be documented how the de- > multiplexing is performed. There might also be a need for signalling > extensions in order for endpoints to exchange data needed for the de- > multiplexing. > > I agree with the sense of these paragraphs. > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From prvs=48823f5ea6=christer.holmberg@ericsson.com Wed Jun 19 06:06:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0992521F9A08 for ; Wed, 19 Jun 2013 06:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q9WczVGedR8 for ; Wed, 19 Jun 2013 06:06:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 304A321F99DC for ; Wed, 19 Jun 2013 06:06:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-7b-51c1acbbdab8 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CD.20.15700.BBCA1C15; Wed, 19 Jun 2013 15:06:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 15:06:03 +0200 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAP//2dHg Date: Wed, 19 Jun 2013 13:06:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B0052@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> <51C1A89A.9020603@alvestrand.no> In-Reply-To: <51C1A89A.9020603@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre7uNQcDDVZdF7Q41tfFZjF1+WMW ByaPKxOusHosWfKTKYApitsmKbGkLDgzPU/fLoE7Y8ulG6wFNxUqll29zNbA2CvZxcjBISFg InF0pU0XIyeQKSZx4d56ti5GLg4hgcOMEtduXGWFcBYxShx40cYC0sAmYCHR/U8bpEFEQEfi 4f4GJpAws4C6xNXFQSBhYQEHiXu/ZzFClDhKNC95ywJhu0nc3DmDCcRmEVCVmHVnLzuIzSvg K7HwfQ/UquuMEh+/XmMFSXAK6ErM+nsErIER6Ljvp9aA2cwC4hK3nsxngjhaQGLJnvPMELao xMvH/1gh/lKUWN4vB1GuI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkqmzkLTMQtIyC0nL AkaWVYzsuYmZOenlhpsYgRFycMtv3R2Mp86JHGKU5mBREuf9cGpXoJBAemJJanZqakFqUXxR aU5q8SFGJg5OEMEl1cCoe3bulBWb20yVis5tdCg5Ldbefe3sr6y8/96yC9k3pN3PiT7LrM81 zUJC3/v83TJfF+sj3XbtIm4l/Fpf+P3+vK7W0P/0oUDy01bHZSs1BL7sMHVo/fPggGJZhaA7 7+8jMgqhT2p4mzdUfcg/e6/RZpKnNyPfmSquues5H6wo2Wh5abHpK3ElluKMREMt5qLiRADZ zxoDYwIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:06:10 -0000 Hi, =20 >>>> I put together some text regarding the de-muxing for BUNDLE. >>>> >>>> Note that there is yet no text on HOW the de-muxing is performed.=20 >>>>> The text only cover the SCOPE of what will be specified in the=20 >>>> BUNDLE spec. I want us to agree on that first :) >>> I think you should be careful about this. You risk duplicating material= from other specs. >> That's why I am eager to hear your input on what shall be covered in=20 >> the BUNDLE spec regarding de-muxing :) >> >> For example, are you saying BUNDLE shouldn't specify HOW the de-muxing i= s done? > > Absolutely, I'm saying that BUNDLE should not specify a procedure for de-= muxing. > Instead, it should point to the specs that already specify how the de-mux= ing is done. > > See my comments below as to what I think it should say. I didn't see your comments in the previous mail. Sorry for that. But, as Thomas said, we also need to cover STUN packets. Regards, Christer > 9. Transport Protocol De-Multiplexing > =20 > 9.1. General > =20 > Endpoints can assign "m=3D" lines representing different transport > protocols [RFC4566], identified using the "m=3D" line proto value > [RFC4566]. > =20 > As each "m=3D" line in a BUNDLE group share the BUNDLE address, an > endpoint MUST be able to de-multiplex data received on the BUNDLE > address, meaning it MUST be able to associate the received with one > of the transport protocols assigned to the BUNDLE group. Endpoints > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > able to separate received data from data associated with other > transport protocols assigned to the BUNDLE group. > =20 > In addition, if an endpoint assigns multiple "m=3D" lines representin= g > the same transport protocol to a BUNDLE group, the endpoint MUST be > able to, in addition to associating received data to its transport > protocol, also associate the received data with a specific "m=3D" lin= e > representing that transport protocol. > =20 > This specification defines how to de-multiplex received media > associated with the following transport protocols: > =20 > o "RTP/AVP" [RFC4566]; > =20 > o "RTP/AVPF" [RFC4585]; > =20 > o "RTP/SAVP" [RFC3711]; > =20 > o "RTP/SAVPF" [RFC5124];and > =20 > o "SCTP/DTLS" [ref-to-be added]. > > This is somewhat incomprehensible to me; the most logical description I c= an make is that it means that you can separate packets into one heap contai= ning all the RTP variants and another heap containing SCTP/DTLS - but that = is not obvious. Suggest instead: > > > This specification defines how to de-multiplex protocols carried over RTP= (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from p= rotocols carried over DTLS (which include SCTP/DTLS []). > > And that makes the specification of the demultiplexing very simple: > > "See RFC 5764 section 5.1.2" > > > =20 > This specification also specifies how RTP packats are separated from > RTCP packets. > > Again, the specification of how to do this separation is very simple: > > "See RFC 5761 section 4" > > =20 > If an endpoint assigns multiple "m=3D" lines representing RTP/RTCP > media to a BUNDLE group, it is outside the scope of this > specification how the endpoint associates received RTP/RTCP packets > with a specific RTP/RTCP "m=3D" line (endpoints might use payload typ= e > values, or SSRC values, for the association). > =20 > If endpoints want to assign "m=3D" lines representing other transport > protocols to a BUNDLE group, it MUST be documented how the de- > multiplexing is performed. There might also be a need for signalling > extensions in order for endpoints to exchange data needed for the de- > multiplexing. > > I agree with the sense of these paragraphs. > > > =20 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Wed Jun 19 06:37:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4906121F8E8C for ; Wed, 19 Jun 2013 06:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIODjupTMKqb for ; Wed, 19 Jun 2013 06:37:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F227C21F91A5 for ; Wed, 19 Jun 2013 06:37:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 53DA339E1C2; Wed, 19 Jun 2013 15:37:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0iZk6fWCdzb; Wed, 19 Jun 2013 15:37:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 081F739E1BD; Wed, 19 Jun 2013 15:37:36 +0200 (CEST) Message-ID: <51C1B420.40500@alvestrand.no> Date: Wed, 19 Jun 2013 15:37:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> <51C1A89A.9020603@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B0052@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B0052@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:37:50 -0000 On 06/19/2013 03:06 PM, Christer Holmberg wrote: > Hi, > >>>>> I put together some text regarding the de-muxing for BUNDLE. >>>>> >>>>> Note that there is yet no text on HOW the de-muxing is performed. >>>>>> The text only cover the SCOPE of what will be specified in the >>>>> BUNDLE spec. I want us to agree on that first :) >>>> I think you should be careful about this. You risk duplicating material from other specs. >>> That's why I am eager to hear your input on what shall be covered in >>> the BUNDLE spec regarding de-muxing :) >>> >>> For example, are you saying BUNDLE shouldn't specify HOW the de-muxing is done? >> Absolutely, I'm saying that BUNDLE should not specify a procedure for de-muxing. >> Instead, it should point to the specs that already specify how the de-muxing is done. >> >> See my comments below as to what I think it should say. > I didn't see your comments in the previous mail. Sorry for that. > > But, as Thomas said, we also need to cover STUN packets. This is also covered in RFC 5764 section 5.1.2. > > Regards, > > Christer > > > > > >> 9. Transport Protocol De-Multiplexing >> >> 9.1. General >> >> Endpoints can assign "m=" lines representing different transport >> protocols [RFC4566], identified using the "m=" line proto value >> [RFC4566]. >> >> As each "m=" line in a BUNDLE group share the BUNDLE address, an >> endpoint MUST be able to de-multiplex data received on the BUNDLE >> address, meaning it MUST be able to associate the received with one >> of the transport protocols assigned to the BUNDLE group. Endpoints >> MUST NOT assign a transport protocols to a BUNDLE group, unless it is >> able to separate received data from data associated with other >> transport protocols assigned to the BUNDLE group. >> >> In addition, if an endpoint assigns multiple "m=" lines representing >> the same transport protocol to a BUNDLE group, the endpoint MUST be >> able to, in addition to associating received data to its transport >> protocol, also associate the received data with a specific "m=" line >> representing that transport protocol. >> >> This specification defines how to de-multiplex received media >> associated with the following transport protocols: >> >> o "RTP/AVP" [RFC4566]; >> >> o "RTP/AVPF" [RFC4585]; >> >> o "RTP/SAVP" [RFC3711]; >> >> o "RTP/SAVPF" [RFC5124];and >> >> o "SCTP/DTLS" [ref-to-be added]. >> >> This is somewhat incomprehensible to me; the most logical description I can make is that it means that you can separate packets into one heap containing all the RTP variants and another heap containing SCTP/DTLS - but that is not obvious. Suggest instead: >> >> >> This specification defines how to de-multiplex protocols carried over RTP (which include RTP/AVP [], RTP/AVPF [], RTP/SAVP[] and RTP/SAVPF [] from protocols carried over DTLS (which include SCTP/DTLS []). >> >> And that makes the specification of the demultiplexing very simple: >> >> "See RFC 5764 section 5.1.2" >> >> >> >> This specification also specifies how RTP packats are separated from >> RTCP packets. >> >> Again, the specification of how to do this separation is very simple: >> >> "See RFC 5761 section 4" >> >> >> If an endpoint assigns multiple "m=" lines representing RTP/RTCP >> media to a BUNDLE group, it is outside the scope of this >> specification how the endpoint associates received RTP/RTCP packets >> with a specific RTP/RTCP "m=" line (endpoints might use payload type >> values, or SSRC values, for the association). >> >> If endpoints want to assign "m=" lines representing other transport >> protocols to a BUNDLE group, it MUST be documented how the de- >> multiplexing is performed. There might also be a need for signalling >> extensions in order for endpoints to exchange data needed for the de- >> multiplexing. >> >> I agree with the sense of these paragraphs. >> >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> From bernard_aboba@hotmail.com Wed Jun 19 06:38:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1C21F9C2B for ; Wed, 19 Jun 2013 06:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcxJcpZ4jDsI for ; Wed, 19 Jun 2013 06:37:59 -0700 (PDT) Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by ietfa.amsl.com (Postfix) with ESMTP id D950821F8E8C for ; Wed, 19 Jun 2013 06:37:58 -0700 (PDT) Received: from BLU169-W56 ([65.55.116.8]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 06:37:58 -0700 X-TMN: [kA7Nsp3kMWrFYxvZpvI4IYzA/J4RaBKp] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_7248ffb9-de1c-45e6-b890-963e78729c17_" From: Bernard Aboba To: Harald Alvestrand , Christer Holmberg Date: Wed, 19 Jun 2013 06:37:57 -0700 Importance: Normal In-Reply-To: <51C1A89A.9020603@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 13:37:58.0208 (UTC) FILETIME=[35DFFC00:01CE6CF2] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:38:07 -0000 --_7248ffb9-de1c-45e6-b890-963e78729c17_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 > Absolutely=2C I'm saying that BUNDLE should not specify a procedure for=20 > de-muxing. Instead=2C it should point to the specs that already specify h= ow the=20 > de-muxing is done. [BA] RTP/RTCP multiplexing is covered in RFC 5761=2C and de-multiplexing of= RTP and DTLS is covered in RFC 5764=2C so there is no need for BUNDLE to c= reate new text on those aspects. However=2C there is still the open questi= on of whether payload type can be required to be unique on all bundled m li= nes. If so=2C then PT demultiplexing is viable=3B if not=2C then a combina= tion of PT and SSRC de-muliplexing will be needed. = --_7248ffb9-de1c-45e6-b890-963e78729c17_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said: =3B
<= div>
>=3B Absolutely=2C I'm saying that BUNDLE should not specify a pr= ocedure for
>=3B de-muxing. =3BInstead=2C it should point to the = specs that already specify how the
>=3B de-muxing is done.
=
[BA] RTP/RTCP multiplexing is covered in RFC 5761=2C and de-= multiplexing of RTP and DTLS is covered in RFC 5764=2C so there is no need = for BUNDLE to create new text on those aspects.  =3BHowever=2C there is= still the open question of whether&nbs= p=3Bpayload type can be required to be unique on all bundled m lines.  = =3BIf so=2C then PT demultiplexing is viable=3B if not=2C then a combinatio= n of PT and SSRC de-muliplexing will be needed.
= --_7248ffb9-de1c-45e6-b890-963e78729c17_-- From prvs=2882cd9844=christer.holmberg@ericsson.com Wed Jun 19 06:48:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A93E21F9649 for ; Wed, 19 Jun 2013 06:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28FLDeFJqWrp for ; Wed, 19 Jun 2013 06:48:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 89ECC21F9263 for ; Wed, 19 Jun 2013 06:48:09 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-57-51c1b697adcb Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CB.FA.18006.796B1C15; Wed, 19 Jun 2013 15:48:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 15:48:07 +0200 From: Christer Holmberg To: Bernard Aboba , Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleA= Date: Wed, 19 Jun 2013 13:48:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvre6MbQcDDba85LTYv+Qys8Wxvi42 i6nLH7M4MHtcmXCF1eNxzxk2jyVLfjIFMEdx2yQllpQFZ6bn6dslcGcc6FjCWrCdo+L6rjbm BsYbbF2MnBwSAiYSd/rus0DYYhIX7q0HinNxCAkcZpT4u+04O4SziFFi6dfDQA4HB5uAhUT3 P22QBhGBSIlHMz+ygoSZBdQlri4OAgkLCzhI3Ps9ixGixFGieclbFgjbT2JHdz8TiM0ioCrx +sYVVhCbV8BXYsnT3YwQqxqZJL4dOg3WwClgJXH83yFmEJsR6Ljvp9aANTMLiEvcejKfCeJo AYkle84zQ9iiEi8f/wO7R0JAUWJ5vxxEuZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEaxWUim zkLSMgtJyywkLQsYWVYxsucmZuaklxttYgTGzcEtv1V3MN45J3KIUZqDRUmc9+OpXYFCAumJ JanZqakFqUXxRaU5qcWHGJk4OEEEl1QDo8unvqkzoz4etTypk9lXlvTHKsFw/RWRdao39QuT f+6I0Piz55v1lwopMbd1Qu47cp7t+B24JO9C9dWpaQ96F5l6iccFWKnI7Wqs4+X6XFwX1q2m 1THFkr1PVH9KtPFqDdXCKm3m8oq3Lx5qM695ekf88uMJVXbr/l+b8+PC7RX3NKLdlGJSlViK MxINtZiLihMB2uNLs24CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 13:48:16 -0000 Hi, >Harald said:=A0 > >> Absolutely, I'm saying that BUNDLE should not specify a procedure for=20 >> de-muxing.=A0Instead, it should point to the specs that already specify = how the=20 >> de-muxing is done. > > [BA] RTP/RTCP multiplexing is covered in RFC 5761, and de-multiplexing of= RTP and DTLS is covered in RFC 5764, so there is no need for BUNDLE to cre= ate new text on those aspects.=20 Great. >=A0However, there is still the open question of whether=A0payload type can= be required to be unique on all bundled m lines. =A0If so, then PT demulti= plexing is viable; if not, then a combination of PT and SSRC de-muliplexing= will be needed. The suggested text currently says that, in case you have multiple "m=3D" li= nes associated with the same transport protocol (e.g. RTP/AVP), selecting w= hich of those "m=3D" lines received media belongs (whether it's based on PT= , SSRC or something else) to is outside the scope of the document. But, IF we think that shall be described, then we need to add text. Regards, Christer From bernard_aboba@hotmail.com Wed Jun 19 07:13:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C467F21F9BD4 for ; Wed, 19 Jun 2013 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvPlHMK0oypc for ; Wed, 19 Jun 2013 07:13:33 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id BE73E21F9BB5 for ; Wed, 19 Jun 2013 07:13:32 -0700 (PDT) Received: from BLU169-W128 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 07:13:32 -0700 X-TMN: [VXqn182QVkVizkhkry9zUkdVsb64Y33T] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_5ec8b460-707c-44c9-ab21-cc3ef69628c9_" From: Bernard Aboba To: Christer Holmberg , Harald Alvestrand Date: Wed, 19 Jun 2013 07:13:31 -0700 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 14:13:32.0120 (UTC) FILETIME=[2DC91D80:01CE6CF7] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 14:13:38 -0000 --_5ec8b460-707c-44c9-ab21-cc3ef69628c9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer said: "The suggested text currently says that=2C in case you have multiple "m=3D"= lines associated with the same transport protocol (e.g. RTP/AVP)=2C select= ing which of those "m=3D" lines received media belongs (whether it's based = on PT=2C SSRC or something else) to is outside the scope of the document. But=2C IF we think that shall be described=2C then we need to add text." [BA] Leaving this out could result in interoperability problems (unless it = is specified elsewhere and this document references that). So I do thin= k that some text is needed=2C somewhere. = --_5ec8b460-707c-44c9-ab21-cc3ef69628c9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Christer said:

"The suggested text currently says that=2C in case you hav= e multiple "m=3D" lines associated with the same transport protocol (e.g. R= TP/AVP)=2C selecting which of those "m=3D" lines received media belongs (wh= ether it's based on PT=2C SSRC or something else) to is outside the scope o= f the document.

But=2C IF we think that shall be described=2C then w= e need to add text."

[BA] Leaving this out could r= esult in interoperability problems (unless it is specified elsewhere and th= is document references that).  =3B  =3B So I do think that some tex= t is needed=2C somewhere. =3B
= --_5ec8b460-707c-44c9-ab21-cc3ef69628c9_-- From fandreas@cisco.com Wed Jun 19 07:26:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1267421F9C10 for ; Wed, 19 Jun 2013 07:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avGNOH7MZVRR for ; Wed, 19 Jun 2013 07:26:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68421F9C0D for ; Wed, 19 Jun 2013 07:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9980; q=dns/txt; s=iport; t=1371651994; x=1372861594; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jp7t0mLqYio1XV/6uiv2e20OXpQ+dZq1pZDrqPe54bU=; b=HCzABB6qWDwe4EG4K1rlM/3cTfL49RjNope7f/edvz5PULHID6wH70aY jWb9O3RLl+y+HLp7iRAyucgN4LhAb6Nu/P6WsjSIBzMFdz3uliShhPpNQ 22v5KFvlsjctoq1RQVnmLTVJF9KyJkoO6tbl+medKAi4SX55RneVkU4kp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwFABK/wVGtJXG+/2dsb2JhbABagkVEMYNLhV62O4EAFnSCIwEBAQMBI0sKAQULCxgJFgQHAgIJAwIBAgFFBg0BBQIBAQWHfwYMqgSRQ44QBYEtB4JNgRQDl0GBKZAbgViBUyCBLgcX X-IronPort-AV: E=Sophos;i="4.87,896,1363132800"; d="scan'208,217";a="224811827" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jun 2013 14:26:33 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.252.18]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5JEQVLW014822; Wed, 19 Jun 2013 14:26:32 GMT Message-ID: <51C1BF98.2020304@cisco.com> Date: Wed, 19 Jun 2013 10:26:32 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <51BA44CC.6000607@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207010002090403050909" Cc: Ari Keranen , mmusic , Hadriel Kaplan , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 14:26:39 -0000 This is a multi-part message in MIME format. --------------010207010002090403050909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/19/13 8:11 AM, Hannes Tschofenig wrote: > Hi Flemming, > I am still willing to continue and complete this work. > Gonzalo and I had tried to reach out to Hadriel numerous times to > better understand his review remarks but unfortunately without success. I have seen several e-mails on the MMUSIC list from Hadriel raising issues/questions but I haven't seen the follow-ups from the document authors to resolve those. Please make sure to use the mailing list. Thanks -- Flemming > Ciao > Hannes > PS: Btw, the "significant concerns", as you called them, came from one > person, Hadriel. > *Gesendet:* Freitag, 14. Juni 2013 um 00:16 Uhr > *Von:* "Flemming Andreasen" > *An:* mmusic > *Cc:* "Ari Keranen" , "Hadriel Kaplan" > , > draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org > *Betreff:* [MMUSIC] What should we do with the middleboxes draft > (draft-ietf-mmusic-media-path-middleboxes) ? > Greetings MMUSIC > > As noted previously > (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), > we currently have a milestone for " Considerations for using SDP > offer/answer with middleboxes" and we have a WG draft for that in the > form of > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/ > > When we polled for interest in this work about 1 year ago (per the > above thread), there was some indication of continued interest in the > work, however there were also some (significant) concerns expressed > with the draft itself (see e.g. most recent thread in > http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). > These concerns have existed for well over a year and we have seen very > little discussion or active work trying to resolve them. > > In lieu of the above, the chairs would like to ask the WG participants to > > 1) Indicate if you are in favor of continuing this work. > > 2) If you are willing to actively contribute to the work by either > a) Sign on as co-author, drive the open issues to resolution, and > update the document accordingly > b) Actively contribute to discussion and resolution of open issues in > the draft. > > Please note, that if you answer "yes" to 2a or 2b, then you should > assume that you *will* get called upon to deliver on that. > > Also please note, that if we do not get sufficient positive responses > to both 1 and 2 above, then our plan is to remove the milestone and > abandon the WG draft. > > Thanks > > -- Ari & Flemming (MMUSIC co-chairs) > > > > > > > > > > > > > . --------------010207010002090403050909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 6/19/13 8:11 AM, Hannes Tschofenig wrote:
Hi Flemming, 
 
I am still willing to continue and complete this work. 
 
Gonzalo and I had tried to reach out to Hadriel numerous times to better understand his review remarks but unfortunately without success. 
 
I have seen several e-mails on the MMUSIC list from Hadriel raising issues/questions but I haven't seen the follow-ups from the document authors to resolve those. Please make sure to use the mailing list.

Thanks

-- Flemming

Ciao
Hannes
 
PS: Btw, the "significant concerns", as you called them, came from one person, Hadriel. 
 
 
Gesendet: Freitag, 14. Juni 2013 um 00:16 Uhr
Von: "Flemming Andreasen" <fandreas@cisco.com>
An: mmusic <mmusic@ietf.org>
Cc: "Ari Keranen" <ari.keranen@ericsson.com>, "Hadriel Kaplan" <HKaplan@acmepacket.com>, draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org
Betreff: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ?
Greetings MMUSIC

As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and we have a WG draft for that in the form of

    http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/

When we polled for interest in this work about 1 year ago (per the above thread), there was some indication of continued interest in the work, however there were also some (significant) concerns expressed with the draft itself (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). These concerns have existed for well over a year and we have seen very little discussion or active work trying to resolve them.

In lieu of the above, the chairs would like to ask the WG participants to

1) Indicate if you are in favor of continuing this work.

2) If you are willing to actively contribute to the work by either
a) Sign on as co-author, drive the open issues to resolution, and update the document accordingly
b) Actively contribute to discussion and resolution of open issues in the draft.

Please note, that if you answer "yes" to 2a or 2b, then you should assume that you *will* get called upon to deliver on that.

Also please note, that if we do not get sufficient positive responses to both 1 and 2 above, then our plan is to remove the milestone and abandon the WG draft.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)












 
.

--------------010207010002090403050909-- From prvs=2882cd9844=christer.holmberg@ericsson.com Wed Jun 19 08:56:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66121F9986 for ; Wed, 19 Jun 2013 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXLoXDWUrcXT for ; Wed, 19 Jun 2013 08:56:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 137AD21F9D98 for ; Wed, 19 Jun 2013 08:56:37 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-a5-51c1d4b49e85 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.67.18006.4B4D1C15; Wed, 19 Jun 2013 17:56:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 17:56:36 +0200 From: Christer Holmberg To: Bernard Aboba , Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg Date: Wed, 19 Jun 2013 15:56:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3B0EF1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre6WKwcDDf6d0bTYv+Qys8Wxvi42 i6nLH7M4MHtcmXCF1eNxzxk2jyVLfjIFMEdx2yQllpQFZ6bn6dslcGesOj6XveCjSsWHZedY Gxjb5bsYOTkkBEwk+u7cZoGwxSQu3FvP1sXIxSEkcJhRYu/JjVDOIkaJVUdusncxcnCwCVhI dP/TBmkQEYiUeDTzIyuIzSygKvF66ncwW1jAQeLe71mMEDWOEs1L3rKAtIoIREks31EFEmYB Kj8z9xPYXl4BX4lnz1+wQKz6wCTxrXc6O0iCU8BaYkVzFxOIzQh03PdTa5ggdolL3Hoynwni aAGJJXvOM0PYohIvH/+DuidfYs269+wQCwQlTs58wjKBUWQWkvZZSMpmISmDiOtJ3Jg6hQ3C 1pZYtvA1M4StKzHj3yEWZPEFjOyrGNlzEzNz0suNNjECI+rglt+qOxjvnBM5xCjNwaIkzvvx 1K5AIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJwggkuqgXHujcbIu/xzQvNkzv8+9EJ1d8kvn6p7 196FBsULP2dd96br+zSprp0WNX37c5LaanJUPNl5eh/933V3cxzzQ81VsnMSzOcIh5deZU+8 t53lw/L9B5f0iu3I82Ro+3TFYN/PNTxnt+2aPOW57P1jj25/68i7vGvZrLL86KmF9rUXltSL tzA/ed+pxFKckWioxVxUnAgAhLUEe3sCAAA= Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 15:56:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3B0EF1ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The question is whether we shall specify exactly how entities associate RTP= packets with the correct m=3D lines, or whether we shall simply give some = guidelines and hints. For example, a client can choose to use unique PT values per m- values, wit= hin a given BUNDLE group, and everything should work fine. And, if the endp= oint runs out of PT values, the create a new BUNDLE group. Now, whether it'= s religiously correct, I don't know :) OR, if the endpoints are able to signal which SSRCs they are going to use, = they can use that. OR, if the endpoints support some kind of RTP header extension for this pur= pose, they can use that. Etc. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Bernard Aboba [bernard_aboba@hotmail.com] To: Christer Holmberg [christer.holmberg@ericsson.com]; Harald Alvestrand [= harald@alvestrand.no] CC: mmusic@ietf.org [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Christer said: "The suggested text currently says that, in case you have multiple "m=3D" l= ines associated with the same transport protocol (e.g. RTP/AVP), selecting = which of those "m=3D" lines received media belongs (whether it's based on P= T, SSRC or something else) to is outside the scope of the document. But, IF we think that shall be described, then we need to add text." [BA] Leaving this out could result in interoperability problems (unless it = is specified elsewhere and this document references that). So I do thin= k that some text is needed, somewhere. --_000_7594FB04B1934943A5C02806D1A2204B1C3B0EF1ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The question is whether we shall specify exactly how entities associat= e RTP packets with the correct m=3D lines, or whether we shall simply give = some guidelines and hints.
 
For example, a client can choose to use unique PT values per m- values= , within a given BUNDLE group, and everything should work fine. And, if the= endpoint runs out of PT values, the create a new BUNDLE group. Now, whethe= r it's religiously correct, I don't know :)
 
OR, if the endpoints are able to signal which SSRCs they are going to = use, they can use that.
 
OR, if the endpoints support some kind of RTP header extension for thi= s purpose, they can use that.
 
Etc.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Bernard Aboba [bernard_aboba@hotmail.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]; Harald Alves= trand [harald@alvestrand.no]
CC: mmusic@ietf.org [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Christer said:

"The suggested text currently says that, in case you have multipl= e "m=3D" lines associated with the same transport protocol (e.g. = RTP/AVP), selecting which of those "m=3D" lines received media be= longs (whether it's based on PT, SSRC or something else) to is outside the scope of the document.

But, IF we think that shall be described, then we need to add text."

[BA] Leaving this out could result in interoperability problems (unles= s it is specified elsewhere and this document references that).   &nbs= p; So I do think that some text is needed, somewhere. 
--_000_7594FB04B1934943A5C02806D1A2204B1C3B0EF1ESESSMB209erics_-- From harald@alvestrand.no Wed Jun 19 09:33:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8057221F9D03 for ; Wed, 19 Jun 2013 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwPytQv5YBGT for ; Wed, 19 Jun 2013 09:33:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EC21F9D09 for ; Wed, 19 Jun 2013 09:33:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D3FD39E1BD; Wed, 19 Jun 2013 18:33:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb4pnagNqRdt; Wed, 19 Jun 2013 18:32:59 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 00D0B39E0E1; Wed, 19 Jun 2013 18:32:58 +0200 (CEST) Message-ID: <51C1DD3A.8030705@alvestrand.no> Date: Wed, 19 Jun 2013 18:32:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------090808080403090008020807" Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 16:33:14 -0000 This is a multi-part message in MIME format. --------------090808080403090008020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/19/2013 05:56 PM, Christer Holmberg wrote: > Hi, > The question is whether we shall specify exactly how entities > associate RTP packets with the correct m= lines, or whether we shall > simply give some guidelines and hints. > For example, a client can choose to use unique PT values per m- > values, within a given BUNDLE group, and everything should work fine. > And, if the endpoint runs out of PT values, the create a new BUNDLE > group. Now, whether it's religiously correct, I don't know :) > OR, if the endpoints are able to signal which SSRCs they are going to > use, they can use that. > OR, if the endpoints support some kind of RTP header extension for > this purpose, they can use that. OR, if they don't care which M-line the stream is associated with, the question may be moot. In all cases, the payload type MUST clearly identify the codec configuration it's associated with. At the moment the text says: o - The dynamic payload type values used in the "m=" lines MUST NOT overlap. That's a holdover from the time I imagined this only being used with a very small number of M-lines; since we're now discussing potential SDP with hundreds of M-lines, I'd like to change this to: o - If the configuration of two M-lines differs in any aspect except (.. maybe something goes here ..), the dynamic payload type values used in the "m=" lines MUST be different. YMMV. > Etc. > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Bernard Aboba [bernard_aboba@hotmail.com] > *To:* Christer Holmberg [christer.holmberg@ericsson.com]; Harald > Alvestrand [harald@alvestrand.no] > *CC:* mmusic@ietf.org [mmusic@ietf.org] > *Subject:* RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) > > Christer said: > > "The suggested text currently says that, in case you have multiple > "m=" lines associated with the same transport protocol (e.g. RTP/AVP), > selecting which of those "m=" lines received media belongs (whether > it's based on PT, SSRC or something else) to is outside the scope of > the document. > > But, IF we think that shall be described, then we need to add text." > > [BA] Leaving this out could result in interoperability problems > (unless it is specified elsewhere and this document references that). > So I do think that some text is needed, somewhere. --------------090808080403090008020807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/19/2013 05:56 PM, Christer Holmberg wrote:
Hi,
 
The question is whether we shall specify exactly how entities associate RTP packets with the correct m= lines, or whether we shall simply give some guidelines and hints.
 
For example, a client can choose to use unique PT values per m- values, within a given BUNDLE group, and everything should work fine. And, if the endpoint runs out of PT values, the create a new BUNDLE group. Now, whether it's religiously correct, I don't know :)
 
OR, if the endpoints are able to signal which SSRCs they are going to use, they can use that.
 
OR, if the endpoints support some kind of RTP header extension for this purpose, they can use that.

OR, if they don't care which M-line the stream is associated with, the question may be moot.

In all cases, the payload type MUST clearly identify the codec configuration it's associated with.

At the moment the text says:

   o  - The dynamic payload type values used in the "m=" lines MUST NOT
      overlap.
 
That's a holdover from the time I imagined this only being used with a very small number of M-lines; since we're now discussing potential SDP with hundreds of M-lines, I'd like to change this to:

  o - If the configuration of two M-lines differs in any aspect except (.. maybe something goes here ..),
       the dynamic payload type values used in the "m=" lines MUST be different.

YMMV.

 
Etc.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown (www.nitrodesk.com)
-----Original Message-----
From: Bernard Aboba [bernard_aboba@hotmail.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]; Harald Alvestrand [harald@alvestrand.no]
CC: mmusic@ietf.org [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Christer said:

"The suggested text currently says that, in case you have multiple "m=" lines associated with the same transport protocol (e.g. RTP/AVP), selecting which of those "m=" lines received media belongs (whether it's based on PT, SSRC or something else) to is outside the scope of the document.

But, IF we think that shall be described, then we need to add text."

[BA] Leaving this out could result in interoperability problems (unless it is specified elsewhere and this document references that).     So I do think that some text is needed, somewhere. 

--------------090808080403090008020807-- From prvs=2882cd9844=christer.holmberg@ericsson.com Wed Jun 19 09:47:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D5C21F9976 for ; Wed, 19 Jun 2013 09:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK6tyZQ0uB2V for ; Wed, 19 Jun 2013 09:47:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D421F9D0F for ; Wed, 19 Jun 2013 09:47:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-fc-51c1e09aa97f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FC.65.15700.A90E1C15; Wed, 19 Jun 2013 18:47:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 18:47:22 +0200 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEA== Date: Wed, 19 Jun 2013 16:47:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> In-Reply-To: <51C1DD3A.8030705@alvestrand.no> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvre6sBwcDDY7c07PYv+Qys8Wxvi42 i6nLH7M4MHtcmXCF1eNxzxk2jyVLfjIFMEdx2yQllpQFZ6bn6dslcGdc2r+IqeCeRMXOu5uZ GxhvC3cxcnJICJhIfPk3jRnCFpO4cG89WxcjF4eQwGFGidO/lzFCOIsYJT7+OszUxcjBwSZg IdH9TxukQURAR+Lh/gYmEJtZIEji3IcNbCC2sICDxLHXM5kgahwlmpe8ZQFpFRHIkpi1zB8k zCKgKnHg4x9GEJtXwFdi/8O5rBCrrjNLLH6yhxUkwSmgK/Ft3Tp2EJsR6Ljvp9ZA7RKX+HDw OtTRAhJL9pyHskUlXj7+xwphK0k0LnnCClGvJ3Fj6hQ2CFtbYtnC18wQiwUlTs58wjKBUWwW krGzkLTMQtIyC0nLAkaWVYzsuYmZOenlhpsYgZFzcMtv3R2Mp86JHGKU5mBREuf9cGpXoJBA emJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cDYkPHYIC//2hGBppZczbWtfyfcK7978LlYR8dx +T8coifcAk0MWz++EBEoZDu9+aLFYa3E/MInejukREq1Cy7cWWV8LPCddebpCAGHnLkfX3G+ eeIS9sfu3JEkrsyrp9QmJh5quth1wMFj/wrR6pR7uxauKdjvdNRIquNM40XX7PU7KqX+N3oq sRRnJBpqMRcVJwIA6TfBDm8CAAA= Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 16:47:42 -0000 Hi, =A0 >> The question is whether we shall specify exactly how entities associate = RTP packets with the correct m=3D lines, or whether we shall simply give so= me guidelines and hints. >> >> For example, a client can choose to use unique PT values per m- values, = within a given BUNDLE group, and everything should work fine. And, if the e= ndpoint runs out of PT values, the create a new BUNDLE group. Now, whether = it's religiously correct, I don't know :) >>=A0 >> OR, if the endpoints are able to signal which SSRCs they are going to us= e, they can use that. >>=A0 >> OR, if the endpoints support some kind of RTP header extension for this = purpose, they can use that. >> > OR, if they don't care which M-line the stream is associated with, the qu= estion may be moot. Correct. > In all cases, the payload type MUST clearly identify the codec configurat= ion it's associated with. *IF* you have a way to find the right m=3D line, couldn't PT X have differe= nt codec configurations in different m=3D lines? > At the moment the text says: > >=A0=A0 o=A0 - The dynamic payload type values used in the "m=3D" lines MUS= T NOT >=A0=A0=A0=A0=A0 overlap. > > That's a holdover from the time I imagined this only being used with a ve= ry small number of M-lines; True. I haven't touched that text in the latest version. Guess I could have= removed it, or at least added a big NOTE saying it's an open issue. > since we're now discussing potential SDP with hundreds of M-lines, I'd li= ke to change this to: > >=A0 o - If the configuration of two M-lines differs in any aspect except (= .. maybe something goes here ..),=20 >=A0=A0=A0=A0=A0=A0 the dynamic payload type values used in the "m=3D" line= s MUST be different. What do you mean by "configuration of two M-lines"? Don't you mean the configuration of two codecs? For example, if I have 2 m= =3D lines, with exactly the same H.264 configuration in each, could I use t= he same PT value in both m=3D lines? But, if I have different codec configu= rations in each m=3D line, I CANNOT use the same PT value for both? ...assuming, of course, that there is some other mechanism to find the righ= t m=3D line, IF needed. Regards, Christer -----Original Message----- From: Bernard Aboba [bernard_aboba@hotmail.com] To: Christer Holmberg [christer.holmberg@ericsson.com]; Harald Alvestrand [= harald@alvestrand.no] CC: mmusic@ietf.org [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)=20 Christer said: "The suggested text currently says that, in case you have multiple "m=3D" l= ines associated with the same transport protocol (e.g. RTP/AVP), selecting = which of those "m=3D" lines received media belongs (whether it's based on P= T, SSRC or something else) to is outside the scope of the document. But, IF we think that shall be described, then we need to add text." [BA] Leaving this out could result in interoperability problems (unless it = is specified elsewhere and this document references that). =A0 =A0 So I do = think that some text is needed, somewhere.=A0 From emil@sip-communicator.org Wed Jun 19 10:09:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83A921F9E20 for ; Wed, 19 Jun 2013 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVrSO2DTYvCE for ; Wed, 19 Jun 2013 10:09:50 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 54DB621F9E22 for ; Wed, 19 Jun 2013 10:09:45 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so879474wiv.15 for ; Wed, 19 Jun 2013 10:09:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=3TLG1JH7y/jrwToAum1Prdq6NrOEJnGdlE8tasNwEW8=; b=BhkNe2zr6U82RucUgvdS+B79MeIv4GrHoKyUQKHgkV4gFPEEtM4SyRmtIQRzWBFc91 /O0cF0fjoroOHf9ViiZXj0PvYkjJ91QB5GS5+Oehl7eePIMkx94DObwEpSed6NGF1ThM TPi+mU4QKp9oBx6CSKXrXFqyGb9CSkZ24QQEJ4CJPdde0iGYoheaBqlsYw4njFtUzFG8 OliL0s1dsmlthtkMy6Hv8Wl4XRk1QAtyOzlGXIiridoLIBTWrT+l95wlc4RTAfNvMAKR I65kLm1AnJ7jJop9LdhhQEmH3+PgPjIudUWUM2Yc0dvMf2LF49xp4XnS5Y1D+Q7M87Gd 37Yw== X-Received: by 10.194.110.73 with SMTP id hy9mr2871901wjb.95.1371661784290; Wed, 19 Jun 2013 10:09:44 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:a929:df1f:bef6:68ec]) by mx.google.com with ESMTPSA id dz8sm10496385wib.11.2013.06.19.10.09.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 10:09:43 -0700 (PDT) Message-ID: <51C1E5D5.9020009@jitsi.org> Date: Wed, 19 Jun 2013 19:09:41 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnvNHey6mBn8zCmp4Yxy/hAM+MtSmOfgqMoLKEtfTI1Lx3fmcWlNJ3/y7cBTR4KKnsg+oeQ Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 17:09:50 -0000 On 19.06.13, 18:47, Christer Holmberg wrote: > Hi, > >>> The question is whether we shall specify exactly how entities associate RTP packets with the correct m= lines, or whether we shall simply give some guidelines and hints. >>> >>> For example, a client can choose to use unique PT values per m- values, within a given BUNDLE group, and everything should work fine. And, if the endpoint runs out of PT values, the create a new BUNDLE group. Now, whether it's religiously correct, I don't know :) >>> >>> OR, if the endpoints are able to signal which SSRCs they are going to use, they can use that. >>> >>> OR, if the endpoints support some kind of RTP header extension for this purpose, they can use that. >>> >> OR, if they don't care which M-line the stream is associated with, the question may be moot. > > Correct. > >> In all cases, the payload type MUST clearly identify the codec configuration it's associated with. > > *IF* you have a way to find the right m= line, couldn't PT X have different codec configurations in different m= lines? Let's assume that it could ... but then how would you know that your peer also supports the same demuxing technique as yourself? In SIP for example, when constructing a first offer, you may want to map both Opus and VP8 to 96, then add SSRCs for demuxing. This means that you expect your peer to support SSRC demuxing and you can't expect that unless we mandate it. Or am I missing something? Emil -- https://jitsi.org From prvs=788294ad5f=christer.holmberg@ericsson.com Wed Jun 19 11:01:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79A21F9AC3 for ; Wed, 19 Jun 2013 11:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Auh0C5AVvQDA for ; Wed, 19 Jun 2013 11:01:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A49C821F9BD4 for ; Wed, 19 Jun 2013 11:01:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-4f-51c1f1df184d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B0.5E.18006.FD1F1C15; Wed, 19 Jun 2013 20:01:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 20:01:03 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//91ifA= Date: Wed, 19 Jun 2013 18:01:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B14BD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> In-Reply-To: <51C1E5D5.9020009@jitsi.org> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvre79jwcDDZYcsbBYs3MCi8Wxvi42 i6nLH7M4MHtcmXCF1WPJkp9MHv/fBAYwR3HbJCWWlAVnpufp2yVwZ7Ss2MNYsEqw4uOzNtYG xiu8XYycHBICJhLzt61khrDFJC7cW8/WxcjFISRwmFFiwoOvLBDOIkaJ71cXsnYxcnCwCVhI dP/TBmkQEZCX6G5bxARiMwsESmzd8YUVxBYWcJA49nomE0SNo0TzkrcsEHaZxJND/9hAbBYB VYkrc/+DLeYV8JXo+dPBCrHrDIvE//VvwBo4BTQlZm3uAhvKCHTd91NroJaJS3w4eB3qagGJ JXvOQ9miEi8f/2OFsJUkGpc8YYWo15FYsPsTG4StLbFs4WuoxYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkb23MTMnPRyo02MwMg5uOW36g7GO+dEDjFKc7AoifN+PLUrUEggPbEkNTs1 tSC1KL6oNCe1+BAjEwcniOCSamCcvfae+LabGvxPbft+3P5m/ff+tp99vBuWX048uPdUxPSL Ank5RV2d0Qe3zhdeocTOZd5oMfNNM2Nr+E/9OjvzjXFWrSseXG9kqCmQmPpZtfwY87ZdrcW8 C14yvAhx25ZyePnFzujGaxWCF7pMfOaLGe/s27hHhqd6VsV2kTKjSQJthrPm/n6pxFKckWio xVxUnAgADVQZ3m8CAAA= Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 18:01:32 -0000 Hi, >>>> The question is whether we shall specify exactly how entities associat= e RTP packets with the correct m=3D lines, or whether we shall simply give = some guidelines and hints. >>>> >>>> For example, a client can choose to use unique PT values per m-=20 >>>> values, within a given BUNDLE group, and everything should work=20 >>>> fine. And, if the endpoint runs out of PT values, the create a new=20 >>>> BUNDLE group. Now, whether it's religiously correct, I don't know :) >>>> >>>> OR, if the endpoints are able to signal which SSRCs they are going to = use, they can use that. >>>> >>>> OR, if the endpoints support some kind of RTP header extension for thi= s purpose, they can use that. >>>> >>> OR, if they don't care which M-line the stream is associated with, the = question may be moot. >> >> Correct. >> >>> In all cases, the payload type MUST clearly identify the codec configur= ation it's associated with. >> >> *IF* you have a way to find the right m=3D line, couldn't PT X have diff= erent codec configurations in different m=3D lines? > > Let's assume that it could ... but then how would you know that your peer= also supports the same demuxing technique as yourself? In the PT case, he doesn't have to, because he is going to tell you what PT= values he wants you to send him. > In SIP for example, when constructing a first offer, you may want to map = both Opus and VP8 to 96, then add SSRCs for demuxing. This means that you e= xpect your peer to support SSRC demuxing and you can't expect that unless w= e mandate it. > > Or am I missing something? No. In case of support of extensions (e.g. the SDP ssrc attribute), you eit= her have to perform some kind of capability exchange before you send the in= itial Offer. Or, you will figure out in the response to the initial Offer, = and then you can "fix" it in a new Offer (as BUNDLE is currently specified,= you will have to send a second Offer anyway). But, again, what I want to discuss now is whether/what we are going to spec= ify regarding the usage of multiple m=3D lines with the same transport prot= ocol (RTP, or whatever other there could be). Regards, Christer From prvs=788294ad5f=christer.holmberg@ericsson.com Wed Jun 19 11:38:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD52C21F9D05 for ; Wed, 19 Jun 2013 11:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvYVOsVl0VGM for ; Wed, 19 Jun 2013 11:38:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC01521F9B95 for ; Wed, 19 Jun 2013 11:38:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-f3-51c1faa7c258 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 99.AA.15700.7AAF1C15; Wed, 19 Jun 2013 20:38:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 20:38:31 +0200 From: Christer Holmberg To: mmusic_ietf.org Thread-Topic: BUNDLE TEXT: De-mux procedures (June 19th) - Late night version Thread-Index: Ac5tHDF8oQfPVxE5Tx+3QSEPln8FiA== Date: Wed, 19 Jun 2013 18:38:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B154D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvre7yXwcDDV6+M7OYuvwxiwOjx5Il P5kCGKO4bZISS8qCM9Pz9O0SuDP+btvNUnBCoGLeJK8Gxt88XYycHBICJhLzzrUxQdhiEhfu rWfrYuTiEBI4zChx8zeMs4hR4v7cB4xdjBwcbAIWEt3/tEEaRARUJX5vmM0IYgsLeEjsWnuE GSLuK3H7+ik2CFtP4lLXDHYQmwWoflXrBjCbF6hm+vUlYDYj0OLvp9aAHcEsIC7x4eB1ZoiD BCSW7DkPZYtKvHz8jxXCVpJoXPKEFaJeR2LB7k9sELa2xLKFr5kh5gtKnJz5hGUCo/AsJGNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAsP44JbfujsYT50TOcQozcGiJM774dSuQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycIIJLqoGRtzei18jFxkjIPOnyhOnfptgUhbasj/7+d5+LGCPj HT61gyHf8/I+PDwzs2Dlm2fBxy6uvXTSbQaf0v+KmftelC+8IBlrtEnnbffLeu9bTJt8il9I NBjrfd/4z6KdUXey/zS9GX+Kml+EH3maXXFj6U2tLLtlGsF/2/OMhXZYL0zeqs8rtG+yEktx RqKhFnNRcSIAr6bTsDYCAAA= Subject: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 18:38:40 -0000 Hi, I modified the text, based on the comments. - The text now refers to RFC 5764 for RTP, DTLS, STUN de-multiplexing. - I added an open note regarding how much we need to specify regarding "m= =3D line de-muxing" for the same transport protocol. - I removed the MUST for having to be able to do "m=3D line de-muxing" for = the same transport protocol, as there could be cases where it's not needed. Regards, Christer -------------------------------------------------- 9.1. General Endpoints can assign "m=3D" lines representing different transport protocols [RFC4566], identified using the "m=3D" line proto value [RFC4566]. As each "m=3D" line in a BUNDLE group share the BUNDLE address, an endpoint MUST be able to de-multiplex data received on the BUNDLE address, meaning it MUST be able to associate the received with one of the transport protocols assigned to the BUNDLE group. Endpoints MUST NOT assign a transport protocols to a BUNDLE group, unless it is able to separate received data from data associated with other transport protocols assigned to the BUNDLE group. In addition, if an endpoint assigns multiple "m=3D" lines representing the same transport protocol to a BUNDLE group, the endpoint might also have to be able to, in addition to associating received data to its transport protocol, associate the received data with a specific "m=3D" line representing that transport protocol. OPEN ISSUE: We need to discuss how much, if anything, we need to say about associating RTP packets with the correct "m=3D" line, in cases where there are multiple "m=3D" lines for RTP media. Section 5.1.2 of [RFC5764] specifies how to de-multiplex RTP, DTLS and STUN [RFC5389] data packets. If endpoints want to assign "m=3D" lines representing other transport protocols to a BUNDLE group, it MUST be documented how the de- multiplexing is performed. There might also be a need for signalling extensions in order for endpoints to exchange data needed for the de- multiplexing. From hadriel.kaplan@oracle.com Wed Jun 19 11:40:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3D21F9E79 for ; Wed, 19 Jun 2013 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKTcENBL2FNM for ; Wed, 19 Jun 2013 11:40:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 866CD21F9D45 for ; Wed, 19 Jun 2013 11:40:21 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5JIXvcK017999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 18:33:57 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JIeD9p018113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 18:40:14 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JIeDNQ018107; Wed, 19 Jun 2013 18:40:13 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 11:40:13 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_41C188C4-C6B9-447A-8933-9F711704E49C" From: Hadriel Kaplan X-Priority: 3 In-Reply-To: Date: Wed, 19 Jun 2013 14:40:11 -0400 Message-Id: References: <51BA44CC.6000607@cisco.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Flemming Andreasen , Ari Keranen , mmusic , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 18:40:27 -0000 --Apple-Mail=_41C188C4-C6B9-447A-8933-9F711704E49C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yup, my fault. You made a good effort and it's not fair to hold up work = for one person. So I withdraw the objections I raised. -hadriel p.s. I think if you review all the emails, I wasn't the only one to = raise concerns... but that's up to them to clear up. On Jun 19, 2013, at 8:11 AM, Hannes Tschofenig = wrote: > Hi Flemming,=20 > =20 > I am still willing to continue and complete this work.=20 > =20 > Gonzalo and I had tried to reach out to Hadriel numerous times to = better understand his review remarks but unfortunately without success.=20= > =20 > Ciao > Hannes > =20 > PS: Btw, the "significant concerns", as you called them, came from one = person, Hadriel.=20 > =20 > =20 > Gesendet: Freitag, 14. Juni 2013 um 00:16 Uhr > Von: "Flemming Andreasen" > An: mmusic > Cc: "Ari Keranen" , "Hadriel Kaplan" = , = draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org > Betreff: [MMUSIC] What should we do with the middleboxes draft = (draft-ietf-mmusic-media-path-middleboxes) ? > Greetings MMUSIC >=20 > As noted previously = (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we = currently have a milestone for " Considerations for using SDP = offer/answer with middleboxes" and we have a WG draft for that in the = form of >=20 > = http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/ >=20 > When we polled for interest in this work about 1 year ago (per the = above thread), there was some indication of continued interest in the = work, however there were also some (significant) concerns expressed with = the draft itself (see e.g. most recent thread in = http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). = These concerns have existed for well over a year and we have seen very = little discussion or active work trying to resolve them. >=20 > In lieu of the above, the chairs would like to ask the WG participants = to >=20 > 1) Indicate if you are in favor of continuing this work. >=20 > 2) If you are willing to actively contribute to the work by either > a) Sign on as co-author, drive the open issues to resolution, and = update the document accordingly > b) Actively contribute to discussion and resolution of open issues in = the draft. >=20 > Please note, that if you answer "yes" to 2a or 2b, then you should = assume that you *will* get called upon to deliver on that. >=20 > Also please note, that if we do not get sufficient positive responses = to both 1 and 2 above, then our plan is to remove the milestone and = abandon the WG draft. >=20 > Thanks >=20 > -- Ari & Flemming (MMUSIC co-chairs) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_41C188C4-C6B9-447A-8933-9F711704E49C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Yup, my fault.  You made a good effort and it's not fair to hold up work for one person.  So I withdraw the objections I raised.

-hadriel
p.s. I think if you review all the emails, I wasn't the only one to raise concerns... but that's up to them to clear up.


On Jun 19, 2013, at 8:11 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:

Hi Flemming, 
 
I am still willing to continue and complete this work. 
 
Gonzalo and I had tried to reach out to Hadriel numerous times to better understand his review remarks but unfortunately without success. 
 
Ciao
Hannes
 
PS: Btw, the "significant concerns", as you called them, came from one person, Hadriel. 
 
 
Gesendet: Freitag, 14. Juni 2013 um 00:16 Uhr
Von: "Flemming Andreasen" <fandreas@cisco.com>
An: mmusic <mmusic@ietf.org>
Cc: "Ari Keranen" <ari.keranen@ericsson.com>, "Hadriel Kaplan" <HKaplan@acmepacket.com>, draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org
Betreff: [MMUSIC] What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ?
Greetings MMUSIC

As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and we have a WG draft for that in the form of

    http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/

When we polled for interest in this work about 1 year ago (per the above thread), there was some indication of continued interest in the work, however there were also some (significant) concerns expressed with the draft itself (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). These concerns have existed for well over a year and we have seen very little discussion or active work trying to resolve them.

In lieu of the above, the chairs would like to ask the WG participants to

1) Indicate if you are in favor of continuing this work.

2) If you are willing to actively contribute to the work by either
a) Sign on as co-author, drive the open issues to resolution, and update the document accordingly
b) Actively contribute to discussion and resolution of open issues in the draft.

Please note, that if you answer "yes" to 2a or 2b, then you should assume that you *will* get called upon to deliver on that.

Also please note, that if we do not get sufficient positive responses to both 1 and 2 above, then our plan is to remove the milestone and abandon the WG draft.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)












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

--Apple-Mail=_41C188C4-C6B9-447A-8933-9F711704E49C-- From pkyzivat@alum.mit.edu Wed Jun 19 12:11:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC46021F9ECB for ; Wed, 19 Jun 2013 12:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CivCktUbRWr for ; Wed, 19 Jun 2013 12:11:36 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22F21F995F for ; Wed, 19 Jun 2013 12:11:35 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta09.emeryville.ca.mail.comcast.net with comcast id qGgJ1l0041smiN4A9KBWSf; Wed, 19 Jun 2013 19:11:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([63.226.120.12]) by omta20.emeryville.ca.mail.comcast.net with comcast id qK9M1l00p0G8kgX8gK9PUu; Wed, 19 Jun 2013 19:09:27 +0000 Message-ID: <51C201E1.2000309@alum.mit.edu> Date: Wed, 19 Jun 2013 15:09:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371669090; bh=uSfTGflNpg9p1Kn9JeUCYq55L7DsoW7wu9tq9Z8zoaM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eu0jpFp9s+5dC3LcQx40qSC2A6CZrVTGjQBUdfexAr+HJJoOcxEtAJj+BLQwZwh+C kiF1B/4qjuH4UbMlmuaxeqIouuwWaXc3jOVB9A32SpJrDBXnOjo9CnqedLux4JDHoi sf4tT3tEOJ+P3XUtxqql6Wky1VZ1O7G/AgKuWR05Kh6KuAfPQoCCuuUTr40hvRM8xO TD+cteyFjjgkQcVERyv4RpNApSJCqIQyZVzKEkQYgn0rmY6WGeFsU4vSG7t41rr7pq hEUCmZ+/rWVuigieFhqoPkx2Hd5iNiEpCz6C1BaX2gddh+3NdcN5AS1SInGO+MGQC/ jiP8KJ9ChyUHg== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:11:41 -0000 On 6/19/13 7:53 AM, Christer Holmberg wrote: > Hi, > > I put together some text regarding the de-muxing for BUNDLE. > > Note that there is yet no text on HOW the de-muxing is performed. The > text only cover the SCOPE of what will be specified in the BUNDLE spec. > I want us to agree on that first :) > > Regards, > > Christer > > --------------------------------------------------- > > 9. Transport Protocol De-Multiplexing > > 9.1. General > > Endpoints can assign "m=" lines representing different transport > > protocols [RFC4566], identified using the "m=" line proto value > > [RFC4566]. > > As each "m=" line in a BUNDLE group share the BUNDLE address, an > > endpoint MUST be able to de-multiplex data received on the BUNDLE > > address, meaning it MUST be able to associate the received with one > > of the transport protocols assigned to the BUNDLE group. Endpoints > > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > > able to separate received data from data associated with other > > transport protocols assigned to the BUNDLE group. There is something this doesn't address. Suppose I tried to bundle an RTP/AVP with a TCP/RTP/AVP. I could indeed demux them, because they actually travel over different 5-tuples. But I don't think we should consider this bundling. So, to be bundled, I think at the lowest level they must all share the same transport protocol. But I don't know exactly what terminology to use to say that. Thanks, Paul From harald@alvestrand.no Wed Jun 19 12:18:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EFC21F9FC3 for ; Wed, 19 Jun 2013 12:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggkf-KB47ctT for ; Wed, 19 Jun 2013 12:18:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A22F21F9FDB for ; Wed, 19 Jun 2013 12:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 504FE39E1D0; Wed, 19 Jun 2013 21:18:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0RHxZq4RoIZ; Wed, 19 Jun 2013 21:18:07 +0200 (CEST) Received: from [172.30.42.105] (c-e2fee555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.254.226]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7361F39E0E1; Wed, 19 Jun 2013 21:18:07 +0200 (CEST) Message-ID: <51C203EF.4090404@alvestrand.no> Date: Wed, 19 Jun 2013 21:18:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> In-Reply-To: <51C1E5D5.9020009@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic_ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:18:17 -0000 On 06/19/2013 07:09 PM, Emil Ivov wrote: > > > On 19.06.13, 18:47, Christer Holmberg wrote: >> Hi, >> >>>> The question is whether we shall specify exactly how entities >>>> associate RTP packets with the correct m= lines, or whether we >>>> shall simply give some guidelines and hints. >>>> >>>> For example, a client can choose to use unique PT values per m- >>>> values, within a given BUNDLE group, and everything should work >>>> fine. And, if the endpoint runs out of PT values, the create a new >>>> BUNDLE group. Now, whether it's religiously correct, I don't know :) >>>> >>>> OR, if the endpoints are able to signal which SSRCs they are going >>>> to use, they can use that. >>>> >>>> OR, if the endpoints support some kind of RTP header extension for >>>> this purpose, they can use that. >>>> >>> OR, if they don't care which M-line the stream is associated with, >>> the question may be moot. >> >> Correct. >> >>> In all cases, the payload type MUST clearly identify the codec >>> configuration it's associated with. >> >> *IF* you have a way to find the right m= line, couldn't PT X have >> different codec configurations in different m= lines? > > Let's assume that it could ... but then how would you know that your > peer also supports the same demuxing technique as yourself? > > In SIP for example, when constructing a first offer, you may want to > map both Opus and VP8 to 96, then add SSRCs for demuxing. This means > that you expect your peer to support SSRC demuxing and you can't > expect that unless we mandate it. Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs. The corner case where we're discussing whether one can use the same payload type is if you have two M-lines that both specify VP8, with the same codec parameters - whether they can both use 96, given that it's the same codec. > > Or am I missing something? > > Emil > > From pkyzivat@alum.mit.edu Wed Jun 19 12:20:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1A521F9425 for ; Wed, 19 Jun 2013 12:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxlTearVoLjQ for ; Wed, 19 Jun 2013 12:20:44 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id 043BF21E8053 for ; Wed, 19 Jun 2013 12:20:43 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta05.emeryville.ca.mail.comcast.net with comcast id qJ831l0011zF43QA5KLj79; Wed, 19 Jun 2013 19:20:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([63.226.120.12]) by omta24.emeryville.ca.mail.comcast.net with comcast id qKJa1l00d0G8kgX8kKJcx3; Wed, 19 Jun 2013 19:18:41 +0000 Message-ID: <51C2040A.3010104@alum.mit.edu> Date: Wed, 19 Jun 2013 15:18:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371669643; bh=D+GfGMHUHjE07ySB9ZJsv+VjZo48cI9Rl7z+G0nCz8M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WIWYlOk7OKFHpqFeJQXUXCawtC8MYoFVibxNsv+LJ3uR7oOk7fisuQdMG9iZN79Hj Ykyrz/crKUvqOur86p1BUvEcD9qZ66tyQ+aeDgy3raPb4uq/ggCUauRIk0Vd9b3IJx SNqwMQP9FVrdrqMeFx+H/AdocW74Ozq1Om9GMMixiS8hJswEVCVwHrNSwtjsX50NT3 /7N3VENPyiu9k0EgYtMVOzoT9dPpB8rH2F3WhSldGDZogwbmTXCjZxwA6h/vmYneEi kiy3QZROcq7aO7qdI3702H/40dRhOmi5fnt/mzmGleDeYKcyQxdikRfPjGnnxLjOX2 KQLdhZcPTzNxQ== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:20:50 -0000 On 6/19/13 9:37 AM, Bernard Aboba wrote: > Harald said: > > > Absolutely, I'm saying that BUNDLE should not specify a procedure for > > de-muxing. Instead, it should point to the specs that already specify > how the > > de-muxing is done. > > [BA] RTP/RTCP multiplexing is covered in RFC 5761, and de-multiplexing > of RTP and DTLS is covered in RFC 5764, so there is no need for BUNDLE > to create new text on those aspects. I'm replying here, rather than to Harald because both of you say more or less the same thing and its more concise here. IIUC, RFC 5764 says how to demux DTLS from DTLS/SRTP, but not how to demux DTLS from other RTP. I think it turns out that the same mechanism works for both, but that is by accident rather than specification. I don't know if/when someone would want to use vanilla RTP with DTLS, but somebody will probably find a reason. (Not RTCWEB.) It will take more than a reference to 5764 to cover it. Also, 5764 only covers a single m-line using DTLS payload packets. That also needs to be addressed explicitly. > However, there is still the open > question of whether payload type can be required to be unique on all > bundled m lines. If so, then PT demultiplexing is viable; if not, then > a combination of PT and SSRC de-muliplexing will be needed. I agree. Thanks, Paul From emil@sip-communicator.org Wed Jun 19 12:21:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1BE21F9B8B for ; Wed, 19 Jun 2013 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VivJkwNANQpC for ; Wed, 19 Jun 2013 12:21:18 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1E85821F99A7 for ; Wed, 19 Jun 2013 12:20:56 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so1066375wib.10 for ; Wed, 19 Jun 2013 12:20:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=wW4Gm/6Wc/Go+KyoNg+pB3MuDc7J07AlowMgX+s0bOY=; b=HaVrhGTvS/FFkvOtF40I3uTePclhsUWQsV0+2vjcJ9CTkgj9CyOp2vDa6GVnQqtAo+ lj9xIt+vGl7mlV2k4J5EpLFV9WVmu23Qt+bEX4ZtwXS9gl7OlfDFCk+P5vP/c8uj0OMB 0w4YiwqRm+cKpT9b/2LDEHOX27mlo13otubrsohuSqpPlZlmdY5S6gXLHSn/Jyy3VJ60 /gM528RDdQ8G731wAgvEjsMFN9tpHsI++Btt8gfN46fnmV3Q6Mw7FkrCQPmhVVihaucW uohMR5sNoXvx7VkZbIZckP8LQCLWh0IGTkY3/BqODFb4cJFoa8DHn1IDCDKJEpTNzfOu jebA== X-Received: by 10.194.110.73 with SMTP id hy9mr3231406wjb.95.1371669656136; Wed, 19 Jun 2013 12:20:56 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id u9sm11393147wif.6.2013.06.19.12.20.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 12:20:55 -0700 (PDT) Message-ID: <51C20492.9070803@jitsi.org> Date: Wed, 19 Jun 2013 21:20:50 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3B14BD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B14BD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk9nzR8pN3CnC4ugw6v8SE57kh7XpU1Kyci5c+2Bk2/Kqxx3IfzA9Qu1UjEZh9ptCf0a+rm Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:21:21 -0000 On 19.06.13, 20:01, Christer Holmberg wrote: > Hi, > >>>>> The question is whether we shall specify exactly how entities >>>>> associate RTP packets with the correct m= lines, or whether >>>>> we shall simply give some guidelines and hints. >>>>> >>>>> For example, a client can choose to use unique PT values per >>>>> m- values, within a given BUNDLE group, and everything should >>>>> work fine. And, if the endpoint runs out of PT values, the >>>>> create a new BUNDLE group. Now, whether it's religiously >>>>> correct, I don't know :) >>>>> >>>>> OR, if the endpoints are able to signal which SSRCs they are >>>>> going to use, they can use that. >>>>> >>>>> OR, if the endpoints support some kind of RTP header >>>>> extension for this purpose, they can use that. >>>>> >>>> OR, if they don't care which M-line the stream is associated >>>> with, the question may be moot. >>> >>> Correct. >>> >>>> In all cases, the payload type MUST clearly identify the codec >>>> configuration it's associated with. >>> >>> *IF* you have a way to find the right m= line, couldn't PT X have >>> different codec configurations in different m= lines? >> >> Let's assume that it could ... but then how would you know that >> your peer also supports the same demuxing technique as yourself? > > In the PT case, he doesn't have to, because he is going to tell you > what PT values he wants you to send him. Yes but how do you know whether or not it is going to pre-announce SSRCs so that you could demux the payload types that you want to receive? >> In SIP for example, when constructing a first offer, you may want >> to map both Opus and VP8 to 96, then add SSRCs for demuxing. This >> means that you expect your peer to support SSRC demuxing and you >> can't expect that unless we mandate it. >> >> Or am I missing something? > > No. In case of support of extensions (e.g. the SDP ssrc attribute), > you either have to perform some kind of capability exchange before > you send the initial Offer. Or, you will figure out in the response > to the initial Offer, and then you can "fix" it in a new Offer (as > BUNDLE is currently specified, you will have to send a second Offer > anyway). Exactly. So what bothers me is that without at least one default demuxing a bundle offer can be downgraded to non-bundle if 1. the answerer doesn't support bundle 2. the answerer doesn't support the demuxing mechanism the offerer would like to use. Point 2 means that UAs would have to support as many demuxing mechanisms as possible, even if they don't actually need them, just so that they could have bundle. This doesn't sound like a great thing. What would be the downside of mandating PT demuxing but allowing it to be overridden by other mechanisms when available? Emil > But, again, what I want to discuss now is whether/what we are going > to specify regarding the usage of multiple m= lines with the same > transport protocol (RTP, or whatever other there could be). > > Regards, > > Christer > > -- https://jitsi.org From pkyzivat@alum.mit.edu Wed Jun 19 12:24:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB2B21F9B8F for ; Wed, 19 Jun 2013 12:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foEouCRXwexO for ; Wed, 19 Jun 2013 12:24:11 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3A21F9BA5 for ; Wed, 19 Jun 2013 12:24:11 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta15.emeryville.ca.mail.comcast.net with comcast id qG7Z1l0041vN32cAFKQBwR; Wed, 19 Jun 2013 19:24:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([63.226.120.12]) by omta22.emeryville.ca.mail.comcast.net with comcast id qKN21l00m0G8kgX8iKN4SY; Wed, 19 Jun 2013 19:22:08 +0000 Message-ID: <51C204DA.9030203@alum.mit.edu> Date: Wed, 19 Jun 2013 15:22:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> In-Reply-To: <51C1DD3A.8030705@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371669851; bh=AB/iihruDweEyx9dG1ygJ2RMqsqeEzP1qMxRbXj14Bg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AGQY1ThuDjoLIfEtmCvQ5hjuC9UfvHzL/EoNZjN9X9yNwaBwVZl5W0MH/2n2G2UkA nwu11VkVZz80ECEdTDlNvqaTx7x9ezsJTSL2Tqa4noloYbgtwHIyp5gGmPnONBMI/B jvvawh+51gfgtQscRb80T1tMUmh1Aguv/2FPokxUTPItDSCL5TVFiA3a20ZSslsRA/ vWrwP1j0sZILtmviEJFQ2IUl9srApTPPVAB5InCT7RpLT6HAq7nkiOFgxoxFoflrFP 1A1Df1y18FztWUcJbsiajhrKcheAQuIKjQlGboLwpwUFgbqhhTX39HV4EVJZv+kBCV cWn30Vz1ov8VQ== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:24:17 -0000 On 6/19/13 12:32 PM, Harald Alvestrand wrote: > On 06/19/2013 05:56 PM, Christer Holmberg wrote: >> Hi, >> The question is whether we shall specify exactly how entities >> associate RTP packets with the correct m= lines, or whether we shall >> simply give some guidelines and hints. >> For example, a client can choose to use unique PT values per m- >> values, within a given BUNDLE group, and everything should work fine. >> And, if the endpoint runs out of PT values, the create a new BUNDLE >> group. Now, whether it's religiously correct, I don't know :) >> OR, if the endpoints are able to signal which SSRCs they are going to >> use, they can use that. >> OR, if the endpoints support some kind of RTP header extension for >> this purpose, they can use that. > > OR, if they don't care which M-line the stream is associated with, the > question may be moot. I think this is a silly argument. If they don't care which m-line the stream is associated with then there was no need to insert the m-line. If there is a reason to have the m-lines, then there needs to be a way to associate packets with m-lines. Thanks, Paul From emil@sip-communicator.org Wed Jun 19 12:25:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9357721F99AA for ; Wed, 19 Jun 2013 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an9ujvtHtY7G for ; Wed, 19 Jun 2013 12:25:36 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE2621F995C for ; Wed, 19 Jun 2013 12:25:35 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so4778720wgh.6 for ; Wed, 19 Jun 2013 12:25:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=/c54A7g6wX4P0gtXWkXcDOfsUrOAeaXvgD6nbkC6FgA=; b=ddDg8dw5Ve2wm5GPQHIFg84oHdt9uyux4+3Uhsnt5Q1kSnawo/3+v1j3V52ohuSg1L J0VrrVf8HxydbJWhqhp7iuJCT+a0aj3co6Y3M6kVwX5Km5aLBX8REgCOKOmvkN9xNACp nRqmBCXJif5zOnjVGTaYEzEVn81rYyYBaQCFzPmnilvMcIV9Ylc+VnVxBGtvV7vtUfvd neEHPngZqqlWRTx50S1BQOq9Tq/0nyHpOgLleydsc4Vvh7zNhMxtdLcGDDj1+EolAuZw uobsJow+O8vNJXNSo6CqmZW9BdBjWNNgAfSrDJG3242UoM0h9Jq9RTy2LUw2iZ77zC/D OJTQ== X-Received: by 10.194.119.228 with SMTP id kx4mr3273429wjb.33.1371669935161; Wed, 19 Jun 2013 12:25:35 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id k10sm11444814wia.4.2013.06.19.12.25.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 12:25:34 -0700 (PDT) Message-ID: <51C205AA.6000308@jitsi.org> Date: Wed, 19 Jun 2013 21:25:30 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Harald Alvestrand References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> In-Reply-To: <51C203EF.4090404@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmdTymHmt6s66FJXvrRW2BCNBFbukBnUaMJ+ei6nXW16EG0uvATYyBkbupms32kjamro0tO Cc: "mmusic_ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:25:37 -0000 On 19.06.13, 21:18, Harald Alvestrand wrote: > On 06/19/2013 07:09 PM, Emil Ivov wrote: >> >> >> On 19.06.13, 18:47, Christer Holmberg wrote: >>> Hi, >>> >>>>> The question is whether we shall specify exactly how entities >>>>> associate RTP packets with the correct m= lines, or whether we >>>>> shall simply give some guidelines and hints. >>>>> >>>>> For example, a client can choose to use unique PT values per m- >>>>> values, within a given BUNDLE group, and everything should work >>>>> fine. And, if the endpoint runs out of PT values, the create a new >>>>> BUNDLE group. Now, whether it's religiously correct, I don't know :) >>>>> >>>>> OR, if the endpoints are able to signal which SSRCs they are going >>>>> to use, they can use that. >>>>> >>>>> OR, if the endpoints support some kind of RTP header extension for >>>>> this purpose, they can use that. >>>>> >>>> OR, if they don't care which M-line the stream is associated with, >>>> the question may be moot. >>> >>> Correct. >>> >>>> In all cases, the payload type MUST clearly identify the codec >>>> configuration it's associated with. >>> >>> *IF* you have a way to find the right m= line, couldn't PT X have >>> different codec configurations in different m= lines? >> >> Let's assume that it could ... but then how would you know that your >> peer also supports the same demuxing technique as yourself? >> >> In SIP for example, when constructing a first offer, you may want to >> map both Opus and VP8 to 96, then add SSRCs for demuxing. This means >> that you expect your peer to support SSRC demuxing and you can't >> expect that unless we mandate it. > > Using 96 for both Opus and VP8 is flat out illegal according to the RTP > specs. It somehow sounded to me that people decided this didn't matter. Crazy times :). I am glad to know I was wrong. > The corner case where we're discussing whether one can use the same > payload type is if you have two M-lines that both specify VP8, with the > same codec parameters - whether they can both use 96, given that it's > the same codec. Well same question then: what would be the downside of only allowing that once support for a non-PT demuxing mechanism has been confirmed? Emil -- https://jitsi.org From harald@alvestrand.no Wed Jun 19 12:26:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE47B21F9EC6 for ; Wed, 19 Jun 2013 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj7+p1KSV6-1 for ; Wed, 19 Jun 2013 12:26:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA97B21F9EC4 for ; Wed, 19 Jun 2013 12:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90FEF39E1D0; Wed, 19 Jun 2013 21:26:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwzNmubmCzdF; Wed, 19 Jun 2013 21:26:20 +0200 (CEST) Received: from [172.30.42.105] (c-e2fee555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.254.226]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9473A39E0E1; Wed, 19 Jun 2013 21:26:20 +0200 (CEST) Message-ID: <51C205DC.5090309@alvestrand.no> Date: Wed, 19 Jun 2013 21:26:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:26:30 -0000 On 06/19/2013 06:47 PM, Christer Holmberg wrote: > Hi, > >>> The question is whether we shall specify exactly how entities associate RTP packets with the correct m= lines, or whether we shall simply give some guidelines and hints. >>> >>> For example, a client can choose to use unique PT values per m- values, within a given BUNDLE group, and everything should work fine. And, if the endpoint runs out of PT values, the create a new BUNDLE group. Now, whether it's religiously correct, I don't know :) >>> >>> OR, if the endpoints are able to signal which SSRCs they are going to use, they can use that. >>> >>> OR, if the endpoints support some kind of RTP header extension for this purpose, they can use that. >>> >> OR, if they don't care which M-line the stream is associated with, the question may be moot. > Correct. > >> In all cases, the payload type MUST clearly identify the codec configuration it's associated with. > *IF* you have a way to find the right m= line, couldn't PT X have different codec configurations in different m= lines? > > >> At the moment the text says: >> >> o - The dynamic payload type values used in the "m=" lines MUST NOT >> overlap. >> >> That's a holdover from the time I imagined this only being used with a very small number of M-lines; > True. I haven't touched that text in the latest version. Guess I could have removed it, or at least added a big NOTE saying it's an open issue. > >> since we're now discussing potential SDP with hundreds of M-lines, I'd like to change this to: >> >> o - If the configuration of two M-lines differs in any aspect except (.. maybe something goes here ..), >> the dynamic payload type values used in the "m=" lines MUST be different. > What do you mean by "configuration of two M-lines"? I mean everything that follows "m=" and right up to the next "m=". I don't think it ever makes sense to insist that two M-lines have the same MID, so the parenthesis should not be empty. But I want to hear from other people what they think are the conditions under which they think that the PT *MUST* be different (as opposed to MAY be different; it is always permissible to make them different, as long as you have PTs enough). > > Don't you mean the configuration of two codecs? For example, if I have 2 m= lines, with exactly the same H.264 configuration in each, could I use the same PT value in both m= lines? But, if I have different codec configurations in each m= line, I CANNOT use the same PT value for both? > > ...assuming, of course, that there is some other mechanism to find the right m= line, IF needed. If you have different codec configuration (the stuff like a=fmtp that is indexed by PT), I think you MUST use different PTs. From pkyzivat@alum.mit.edu Wed Jun 19 12:37:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2038921F9B8B for ; Wed, 19 Jun 2013 12:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31sKOoz7mF30 for ; Wed, 19 Jun 2013 12:37:23 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 5856921F9B85 for ; Wed, 19 Jun 2013 12:37:22 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta10.emeryville.ca.mail.comcast.net with comcast id qHpU1l00816AWCUAAKdNib; Wed, 19 Jun 2013 19:37:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([63.226.120.12]) by omta06.emeryville.ca.mail.comcast.net with comcast id qKbD1l00R0G8kgX8SKbFrv; Wed, 19 Jun 2013 19:35:19 +0000 Message-ID: <51C207F1.1010102@alum.mit.edu> Date: Wed, 19 Jun 2013 15:35:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> In-Reply-To: <51C1E5D5.9020009@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371670642; bh=a8SzmfyxxAAplHuh6dyns+lZRWlQywqjaSI7njbUaJ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OwNnnHs6UvfjmPQ6SrGKuc4t5DiswhMaynPRa/JkGKks7ZAvqr2Z9a2ZHZ1f+eNgm rLDpadY/xprMnTgImMjdLxMioRhZIY1PVS4yWXjYcb/QAcrdWdwJyd/lJgibbIxyeu pFo++KKv2BkFszxnfmHvDqR9LH7G0+Ia2+jcka9SRKDzC59/ADiGSoJ9InAuWKmoBw dnU3zWqzw8QpMGDhnFgI3chYD9rsSFanYxFrQEP48AoPIn4blIdydCah3te+HDPFt2 76gLZJk7/nSo6KrwFZ5E0MfVyvU1LG24AP7tRJKdVbL7EnJKrkcITUGy2dz+K7QohR Y3hS8rpQoY1Dw== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:37:37 -0000 On 6/19/13 1:09 PM, Emil Ivov wrote: > > > On 19.06.13, 18:47, Christer Holmberg wrote: >> Hi, >> >>>> The question is whether we shall specify exactly how entities >>>> associate RTP packets with the correct m= lines, or whether we shall >>>> simply give some guidelines and hints. >>>> >>>> For example, a client can choose to use unique PT values per m- >>>> values, within a given BUNDLE group, and everything should work >>>> fine. And, if the endpoint runs out of PT values, the create a new >>>> BUNDLE group. Now, whether it's religiously correct, I don't know :) >>>> >>>> OR, if the endpoints are able to signal which SSRCs they are going >>>> to use, they can use that. >>>> >>>> OR, if the endpoints support some kind of RTP header extension for >>>> this purpose, they can use that. >>>> >>> OR, if they don't care which M-line the stream is associated with, >>> the question may be moot. >> >> Correct. >> >>> In all cases, the payload type MUST clearly identify the codec >>> configuration it's associated with. >> >> *IF* you have a way to find the right m= line, couldn't PT X have >> different codec configurations in different m= lines? Yes, I think so. > Let's assume that it could ... but then how would you know that your > peer also supports the same demuxing technique as yourself? Muxing/demuxing (in the sense of associating to a particular m-line) MUST be consistent on both ends. (The sender knows which m-line he associates a packet with, and expects that the receiver will make the same association.) There must be enough signaling to get the two sides in sync about this. > In SIP for example, when constructing a first offer, you may want to map > both Opus and VP8 to 96, then add SSRCs for demuxing. This means that > you expect your peer to support SSRC demuxing and you can't expect that > unless we mandate it. In this case there will be two m-lines, one audio and one video, each using PT 96. And the offer specifies a specific ssrc for each m-line. If the answerer does't understand or support muxing by ssrc it will then note that if it accepted both m-lines it would not be able to associate packets with m-lines. So it then has two choices in constructing its answer: - reject the bundle, but accept both m-lines - accept the bundle, but reject one of the m-lines. This works even for hypothetical new demux techniques that might not be supported by all. Thanks, Paul > Or am I missing something? > > Emil > > From prvs=0882b88578=christer.holmberg@ericsson.com Wed Jun 19 12:38:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B9E21F9E41 for ; Wed, 19 Jun 2013 12:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqP9rDeBAsGP for ; Wed, 19 Jun 2013 12:38:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3A21F9E2D for ; Wed, 19 Jun 2013 12:38:32 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-66-51c208b7d662 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3B.02.18006.7B802C15; Wed, 19 Jun 2013 21:38:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 21:38:31 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CSwALI32AAAUTdLA= Date: Wed, 19 Jun 2013 19:38:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B164D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C201E1.2000309@alum.mit.edu> In-Reply-To: <51C201E1.2000309@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre52jkOBBq3vtSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApitsmKbGkLDgzPU/fLoE7Y8W5aewF69krzh7Jb2B8ydrFyMkhIWAi sX/mDRYIW0ziwr31bF2MXBxCAocZJW7cmQ7lLGKUeLX1B1AVBwebgIVE9z9tkAYRAV+JZ49v s4HYwgIOEsdez2SCiDtKNC95C1YuImAlsfRmEEiYRUBV4vCkucwgNi9Qa+uJx2A3CAnkS/Rf m8cKUs4poCOxe4MSSJgR6Jzvp9aATWQWEJf4cPA6M8SZAhJL9pyHskUlXj7+B/WKkkTjkies EPU6Egt2f2KDsLUlli18DbVWUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm60 iREYBwe3/FbdwXjnnMghRmkOFiVx3o+ndgUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFIN jKYLbl284jlrc3DROs9u7bLjGrectglYLZwY0Jy5unR714TePmcjnib1X3Lr5oVcWezyi13T yzznVwnDNOaXrTxux0LFTc4mt73S0nJKylh7sUnGq/CPRKVAu5N96cKwdaHud2K4vbJE+YN6 2DaycBh4/5S7HbWD/dxn1q3ZjH331KqV5i9UYinOSDTUYi4qTgQAc30LklYCAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:38:42 -0000 Hi, > There is something this doesn't address. Suppose I tried to bundle an RTP= /AVP with a TCP/RTP/AVP. I could indeed demux them, because they=20 > actually travel over different 5-tuples. But I don't think we should cons= ider this bundling. > > So, to be bundled, I think at the lowest level they must all share the sa= me transport protocol. But I don't know exactly what terminology to use to = say that. Well, the low level transport protocol is part of the 5-tuple definition, b= ut I agree that it's currently not part of the BUNDLE address definition (w= here we only talk about the IP address and port). However, the idea from the beginning has been that a BUNDLE group shares a = single 5-tuple, so we need to make sure that is clear. In the text, however, I use the SDP definition of "transport protocol", whi= ch refers to the whole m=3D line proto value (e.g. "RTP/AVP", etc). Regards, Christer From bernard_aboba@hotmail.com Wed Jun 19 12:53:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AF621F9FE2 for ; Wed, 19 Jun 2013 12:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI0Wu0fK5cS2 for ; Wed, 19 Jun 2013 12:53:39 -0700 (PDT) Received: from blu0-omc1-s11.blu0.hotmail.com (blu0-omc1-s11.blu0.hotmail.com [65.55.116.22]) by ietfa.amsl.com (Postfix) with ESMTP id E07C421F9FB7 for ; Wed, 19 Jun 2013 12:53:38 -0700 (PDT) Received: from BLU169-W108 ([65.55.116.9]) by blu0-omc1-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 12:53:38 -0700 X-TMN: [CyODihsyGHNCRR1TywVKNVM2XPHv2YZe] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1e8602c1-f2c2-4462-9cc4-9b19796e5fd1_" From: Bernard Aboba To: Harald Alvestrand , Christer Holmberg Date: Wed, 19 Jun 2013 12:53:38 -0700 Importance: Normal In-Reply-To: <51C205DC.5090309@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se>, <51C205DC.5090309@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 19:53:38.0747 (UTC) FILETIME=[B11548B0:01CE6D26] Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 19:53:45 -0000 --_1e8602c1-f2c2-4462-9cc4-9b19796e5fd1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer said:=20 Don't you mean the configuration of two codecs? For example=2C if I have 2 = m=3D lines=2C with exactly the same H.264 configuration in each=2C could I = use the same PT value in both m=3D lines? But=2C if I have different codec = configurations in each m=3D line=2C I CANNOT use the same PT value for both= ? ...assuming=2C of course=2C that there is some other mechanism to find the= right m=3D line=2C IF needed. =20 If you have different codec configuration (the stuff like a=3Dfmtp that is= indexed by PT)=2C I think you MUST use different PTs. [BA] This advice is consistent with examples from RFC 6190 and other docume= nts. For example=2C RFC 6190 shows different PTs used for an offer includin= g support for both H.264/AVC and H.264/SVC. =20 =20 However=2C we need to be a bit careful about how we phrase the requirement= =2C exactly. I do not consider simulcast and layered streams to represent = a "different codec configuration" which would require a different PT for ea= ch stream (or even a different SSRC). = --_1e8602c1-f2c2-4462-9cc4-9b19796e5fd1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Christer said:

Don't= you mean the configuration of two codecs? For example=2C if I have 2 m=3D = lines=2C with exactly the same H.264 configuration in each=2C could I use t= he same PT value in both m=3D lines? But=2C if I have different codec confi= gurations in each m=3D line=2C I CANNOT use the same PT value for both?
=
 =3B...assuming=2C of course=2C that there is some other mechanism = to find the right m=3D line=2C IF needed.
 =3B
If you have diffe= rent codec configuration (the stuff like a=3Dfmtp that is indexed by PT)=2C= I think you MUST use different PTs.

[BA] This advice is consistent = with examples from RFC 6190 and other documents. For example=2C RFC 6190 sh= ows different PTs used for an offer including support for both H.264/AVC an= d H.264/SVC. =3B
 =3B
However=2C we need to be a bit careful= about how we phrase the requirement=2C exactly. =3B =3BI do not co= nsider simulcast and layered streams to represent a "different codec = =3Bconfiguration" which would require a different PT for each stream (or ev= en a different SSRC).

= --_1e8602c1-f2c2-4462-9cc4-9b19796e5fd1_-- From csp@csperkins.org Wed Jun 19 13:24:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B32E21F9FEA for ; Wed, 19 Jun 2013 13:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQNX+B0SVVQq for ; Wed, 19 Jun 2013 13:23:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 22DFE21F9FE0 for ; Wed, 19 Jun 2013 13:23:54 -0700 (PDT) Received: from [81.187.2.149] (port=42608 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UpOus-0004ub-54; Wed, 19 Jun 2013 21:23:44 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51C203EF.4090404@alvestrand.no> Date: Wed, 19 Jun 2013 21:23:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic_ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 20:24:05 -0000 On 19 Jun 2013, at 20:18, Harald Alvestrand wrote: > On 06/19/2013 07:09 PM, Emil Ivov wrote: >> On 19.06.13, 18:47, Christer Holmberg wrote: >>>>> The question is whether we shall specify exactly how entities = associate RTP packets with the correct m=3D lines, or whether we shall = simply give some guidelines and hints. >>>>>=20 >>>>> For example, a client can choose to use unique PT values per m- = values, within a given BUNDLE group, and everything should work fine. = And, if the endpoint runs out of PT values, the create a new BUNDLE = group. Now, whether it's religiously correct, I don't know :) >>>>>=20 >>>>> OR, if the endpoints are able to signal which SSRCs they are going = to use, they can use that. >>>>>=20 >>>>> OR, if the endpoints support some kind of RTP header extension for = this purpose, they can use that. >>>>>=20 >>>> OR, if they don't care which M-line the stream is associated with, = the question may be moot. >>>=20 >>> Correct. >>>=20 >>>> In all cases, the payload type MUST clearly identify the codec = configuration it's associated with. >>>=20 >>> *IF* you have a way to find the right m=3D line, couldn't PT X have = different codec configurations in different m=3D lines? >>=20 >> Let's assume that it could ... but then how would you know that your = peer also supports the same demuxing technique as yourself? >>=20 >> In SIP for example, when constructing a first offer, you may want to = map both Opus and VP8 to 96, then add SSRCs for demuxing. This means = that you expect your peer to support SSRC demuxing and you can't expect = that unless we mandate it. >=20 > Using 96 for both Opus and VP8 is flat out illegal according to the = RTP specs. Agree. > The corner case where we're discussing whether one can use the same = payload type is if you have two M-lines that both specify VP8, with the = same codec parameters - whether they can both use 96, given that it's = the same codec. Surely yes, but you lose the ability to distinguish the m=3D line based = on the PT if you use the same PT (mapped to the exact same codec and set = of codec parameters) in several m=3D lines. Some applications care about = distinguishing m=3D lines based on PT values, and so need distinct PT = values for every m=3D line; others don't care, and can use the same PT = to represent the same codec across multiple m=3D lines. --=20 Colin Perkins http://csperkins.org/ From prvs=788326972c=christer.holmberg@ericsson.com Wed Jun 19 21:47:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4480311E80FD for ; Wed, 19 Jun 2013 21:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-1.745, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQItt9w8giwo for ; Wed, 19 Jun 2013 21:47:33 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 92EAF11E80F7 for ; Wed, 19 Jun 2013 21:47:32 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-af-51c289635a8c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DF.BB.10205.36982C15; Thu, 20 Jun 2013 06:47:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 06:47:31 +0200 From: Christer Holmberg To: Bernard Aboba , Harald Alvestrand Thread-Topic: VS: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//q/QA//9QRwD//eu2IA== Date: Thu, 20 Jun 2013 04:47:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B19F2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se>, <51C205DC.5090309@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvrW5y56FAg+3XtC32L7nMbHGsr4vN YuryxywOzB5XJlxh9Xjcc4bNY8mSn0wBzFHcNkmJJWXBmel5+nYJ3BkTTi1iK3jBVbF0h3UD 4ymOLkZODgkBE4llb7+wQ9hiEhfurWfrYuTiEBI4yiix5UIvK4SziFGi88Us5i5GDg42AQuJ 7n/aIA0iApESj2Z+ZAWxmQVUJV5P/c4KUiIs4CLx7IoBRImrxPnVa9kh7DqJFa86wMpZgMp/ P9jIBGLzCvhKLG4/xg6x6i2LxMFNS1hAEpwC1hL/trUxg9iMQMd9P7WGCWKXuMStJ/OZII4W kFiy5zwzhC0q8fLxP7AbJAQUJZb3y0GU60ncmDqFDcLWlli28DUzxF5BiZMzn7BMYBSbhWTq LCQts5C0zELSsoCRZRUjR3FqcVJuupHBJkZg3Bzc8ttiB+PlvzaHGKU5WJTEeT+d2hUoJJCe WJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MKoteOyywelZ16oNx1OZWLM/+69nnXvhb/g5HsVS 2VUHUmcxz18TtvfTKpZkjomrbszP8Aks4dny7HlH6fwZs7Z/vKPjbbhR4eL76fLSojqf/m0M OHO8+scVF4fdCm/v6h1Xumjh9bxWxjrp9/LgWzUtcuc3vz9TdfemZ1jZptzAwiyvgB42tQQl luKMREMt5qLiRACRYqyHbgIAAA== Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 04:47:39 -0000 Hi, >> Christer said:=20 >> >> Don't you mean the configuration of two codecs? For example, if I have 2= m=3D lines, with exactly the same H.264 configuration in each,=20 >> could I use the same PT value in both m=3D lines? But, if I have differe= nt codec configurations in each m=3D line, I CANNOT use the same PT value f= or both? >> >> ...assuming, of course, that there is some other mechanism to find the r= ight m=3D line, IF needed. >=A0 > If you have different codec configuration (the stuff like a=3Dfmtp that i= s indexed by PT), I think you MUST use different PTs. > > [BA] This advice is consistent with examples from RFC 6190 and other docu= ments. For example, RFC 6190 shows different PTs used for an offer includin= g support for both H.264/AVC and H.264/SVC.=A0=20 > > However, we need to be a bit careful about how we phrase the requirement,= exactly.=A0=A0I do not consider simulcast and layered streams to represent= =20 > a "different codec=A0configuration" which would require a different PT fo= r each stream (or even a different SSRC). My hope is that we, in BUNDLE, don't need to specify how endpoints assign t= heir PT values.=20 Of course, if there is some mechanism which requires usage of the same PT v= alue in multiple m=3D lines, we probably need to say something about that i= n BUNDLE. Regards, Christer From prvs=4883623d57=christer.holmberg@ericsson.com Wed Jun 19 21:53:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620BA21E80A3 for ; Wed, 19 Jun 2013 21:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6DgdhLJbpy2 for ; Wed, 19 Jun 2013 21:53:09 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2AA21E8056 for ; Wed, 19 Jun 2013 21:53:09 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-56-51c28ab240e4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1D.97.09795.2BA82C15; Thu, 20 Jun 2013 06:53:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 06:53:05 +0200 From: Christer Holmberg To: Colin Perkins , Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//+AYoD//u50gP/9LnHA Date: Thu, 20 Jun 2013 04:53:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> In-Reply-To: <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvre6mrkOBBmtnSlosf3mC0WLNzgks Fsf6utgspi5/zOLA4nFlwhVWj2n377N5LFnyk8nj/5vAAJYobpukxJKy4Mz0PH27BO6MGTuv MhVM4KxoXd7K3sDYw97FyMkhIWAicWDuATYIW0ziwr31QDYXh5DAYUaJ3w8PMEE4ixglLm9s Burg4GATsJDo/qcN0iAiECjxfvFnRhCbWcBJ4vy87WCDhAUcJO79nsUIUeMo0bzkLQvIHBGB JkaJvjmnWUESLAKqEn17TzCD2LwCvhL9x74yQixbwipx/9kfJpAEJ1D3wet/wRoYgc77fmoN E8Q2cYlbT+YzQZwtILFkz3lmCFtU4uXjf6wgh0oIKEos75eDKNeRWLD7ExuErS2xbOFrqL2C EidnPmGZwCg2C8nUWUhaZiFpmYWkZQEjyypG9tzEzJz0cvNNjMBoOrjlt8EOxk33xQ4xSnOw KInzfjq1K1BIID2xJDU7NbUgtSi+qDQntfgQIxMHJ4jgkmpgPG7yRtqoS5j3Vwy7i9Lr9/fO l9XXqv2IvrVhMWu1/zpe6dvtrm8cq7aIHmlevUPw4k9elrtzuE9uivun2v9oMc8LuWj7Muvr CWbasR5rVpb8Xf7QTf3Skdov199WPElqZ57J1784oJfBq9Tx0UpW1f9RremVa6I5tL8u+Ltl e16PI+fkJ01GSizFGYmGWsxFxYkADiF3Q3kCAAA= Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 04:53:27 -0000 Hi, >> Using 96 for both Opus and VP8 is flat out illegal according to the RTP = specs. > > Agree. So, we DO agree that the usage of the *same* PT value (even if in different= m=3D lines) for different codecs, or different codec configurations, is no= t allowed. Is there some specific section in some specific RFC that can be referenced = to show that? >> The corner case where we're discussing whether one can use the same payl= oad type is if you have two M-lines that both specify VP8, with=20 >> the same codec parameters - whether they can both use 96, given that it'= s the same codec. > > Surely yes, but you lose the ability to distinguish the m=3D line based o= n the PT if you use the same PT (mapped to the exact same codec and set of = codec parameters) in > several m=3D lines. Some applications care about distinguishing m=3D line= s based on PT values, and so need distinct PT values for every m=3D line; o= thers don't care, and can=20 > use the same PT to represent the same codec across multiple m=3D lines. Exactly. So, I think it's a good idea to have some text about that in BUNDL= E. Regards, Christer From prvs=2883809ad1=christer.holmberg@ericsson.com Wed Jun 19 22:04:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74A021E80B6 for ; Wed, 19 Jun 2013 22:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSyn+XVqwAEz for ; Wed, 19 Jun 2013 22:04:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A098421E80B2 for ; Wed, 19 Jun 2013 22:04:14 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-60-51c28d4d4ade Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DA.C7.18006.D4D82C15; Thu, 20 Jun 2013 07:04:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 07:04:13 +0200 From: Christer Holmberg To: Emil Ivov , Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//+AYoD//v6zAP/9Osrg Date: Thu, 20 Jun 2013 05:04:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1A65@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <51C205AA.6000308@jitsi.org> In-Reply-To: <51C205AA.6000308@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvra5v76FAgx/9qhZrdk5gsTjW18Vm MXX5YxYHZo8rE66weixZ8pPJ4/+bwADmKG6bpMSSsuDM9Dx9uwTujD+XF7MWLGOtmLr4IVsD 40SWLkZODgkBE4nLb7YwQdhiEhfurWfrYuTiEBI4zCjx6eMHZghnEaPE5nOfgDIcHGwCFhLd /7RBGkQEPCXuPp0B1swsoCrxeup3VhBbWMBB4t7vWYwQNY4SzUvesoDMERFoYpQ4Oe02WIIF qOFPN8gCTg5eAV+Jx9NmMEIs62GVePF9OthUTgFNib0fj4EVMQKd9/3UGqht4hK3nsyHOltA Ysme88wQtqjEy8f/WEEOlRBQlFjeLwdRriOxYDfI/SC2tsSyha+h9gpKnJz5hGUCo9gsJFNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAiPn4JbfqjsY75wTOcQozcGiJM778dSuQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycIIJLqoGRoXbudxb5yY3TTU/bcWu9fSXs+euY+4uJZ21Fe6fZ bot9PNU8zJXvSUqs9bKLH4pO9s8tnrPybsm8PJsj+uKN3/6s0Vs4+byL5rniR2vEJc47Xsj2 VJn96bDG78slG4qMXcRzjI2f3pivxRzqzXXN5dSmqhuhdrebk1cvOc3KMsvq1oHpclumKrEU ZyQaajEXFScCAOkQo8lvAgAA Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 05:04:31 -0000 Hi, >> The corner case where we're discussing whether one can use the same=20 >> payload type is if you have two M-lines that both specify VP8, with=20 >> the same codec parameters - whether they can both use 96, given that=20 >> it's the same codec. > > Well same question then: what would be the downside of only allowing that= once support for a non-PT demuxing mechanism has been confirmed? It for sure seems like a feasible solution, in my opinion. But, again, at this point I'd like to figure out whether we are going to sp= ecify A rule in BUNDLE to begin with, or whether we trust the applications = to do the right thing :) Regards, Christer From prvs=88837ccfb6=christer.holmberg@ericsson.com Wed Jun 19 22:11:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3430F21F9E04 for ; Wed, 19 Jun 2013 22:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ6ZovaGUDMp for ; Wed, 19 Jun 2013 22:11:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDFD21F9DFA for ; Wed, 19 Jun 2013 22:11:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-a9-51c28f047f2a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.F8.09795.40F82C15; Thu, 20 Jun 2013 07:11:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 07:11:32 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//97moD//jZq4A== Date: Thu, 20 Jun 2013 05:11:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1A7F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C207F1.1010102@alum.mit.edu> In-Reply-To: <51C207F1.1010102@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvrS5L/6FAg94tWhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxW2TlFhSFpyZnqdvl8CdcXDeMqaCO4IVJ+cuYmtg/MrbxcjJISFg ItF0dg0bhC0mceHeeiCbi0NI4DCjxPcZj6GcRYwSdw+1MXYxcnCwCVhIdP/TBmkQEfCVePb4 NlizsICDxL3fsxgh4o4SzUveskDYdRL9M3eA2SwCqhIN8zexg9i8QL37Wx8zQ8x/wyKxefJC sCJOAR2JRY8Pgg1lBLro+6k1TCA2s4C4xK0n85kgLhWQWLLnPDOELSrx8vE/VpDbJAQUJZb3 y0GU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTqLCQts5C0zELSsoCRZRUje25iZk56 ufkmRmA0HNzy22AH46b7YocYpTlYlMR5P53aFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDE0Rw STUwHlyQe6ur8FJ+1/Ka5UYv7rIuN5+m9/WYRfj9rSzf33vlzPld8da7IzK+S2aJ9O35r1X1 Yy1vTijrDZaTalGdtbrEpuf64ilx5o/XHtq+Wsf16d+rkdqfbwrVs7KfqJrzZVkLO3fqcvWT Vv2Lt7Bff6t9OL/llKP9z2caz6dyHEtkFXsnkqv7UomlOCPRUIu5qDgRADGqUVZZAgAA Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 05:11:40 -0000 Hi, >> *IF* you have a way to find the right m=3D line, couldn't PT X have=20 >> different codec configurations in different m=3D lines? > > Yes, I think so. RTP seems to forbid it, though. >> Let's assume that it could ... but then how would you know that your=20 >> peer also supports the same demuxing technique as yourself? > > Muxing/demuxing (in the sense of associating to a particular m-line) MUST= be consistent on both ends. (The sender knows which m-line he associates a= packet with, and expects that the receiver will make the same association.= ) > > There must be enough signaling to get the two sides in sync about this. When it comes to PT values, each endpoint decides which PT values it wants = to other endpoint to send. So, even if Alice uses the same PT value in multiple "m=3D" lines, and have= some way to find the "m=3D" line when media is received, Bob can still ass= ign unique PT values in each "m=3D" line. I don't think there is a requirement to have symmetric PT values in both di= rections, eventhough I know implementations often do that. >> In SIP for example, when constructing a first offer, you may want to=20 >> map both Opus and VP8 to 96, then add SSRCs for demuxing. This means=20 >> that you expect your peer to support SSRC demuxing and you can't=20 >> expect that unless we mandate it. > > In this case there will be two m-lines, one audio and one video, each usi= ng PT 96. And the offer specifies a specific ssrc for each m-line. > > If the answerer does't understand or support muxing by ssrc it will then = note that if it accepted both m-lines it would not be able to associate pac= kets with m-lines. So it then has two choices in constructing its answer: > > - reject the bundle, but accept both m-lines > - accept the bundle, but reject one of the m-lines. Again, my understanding is that the Offerer indicates which PT values it wa= nts to RECEIVE. So, it it assigns the same PT value to both audio and video= , it will receive the same PT value in the media packets. But, the Answerer can indicate different PT values for audio and video in t= he SDP Answer, and it will receive different PT values in the media packets= . Regards, Christer From emcho@sip-communicator.org Thu Jun 20 01:10:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCCD21F9CCD for ; Thu, 20 Jun 2013 01:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAKto1Uolo5t for ; Thu, 20 Jun 2013 01:10:29 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 309F611E810F for ; Thu, 20 Jun 2013 01:10:29 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so5914491pbc.24 for ; Thu, 20 Jun 2013 01:10:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EJNeaZAhykx3SwmUnR+IwCkZYSpgONb5iSvIJyQ87EA=; b=mYsGoUU0rgskP/iyt3pnr7qJ1kl3J0Y2QsLHnxVcLq15nML6FwospwAJPW0FFckrCa ViVyzmeoqg+/1CJYBxEzkWySaZJ4AnmY8EdyeEx+GVNCtq79+UCersbw38GARj9j4JL3 obFubNbMOefDtouR0rBmmP8vQQFHf5S+fipsWZstnlG5JkHPs03YaVzC5JD9RyoFymrZ tsCKGKPbWk7zRl4+OM9iFZc1rCZoe3NY/YnEuThT+sDWFtshK64KffG3E1QMI83cCR9F KBM3ZYhvrhGUdd1hiCsWvwrwb6UM1HsfoM5yPvGtmczuUpNfIlBs5YuPjXqDvqbdFOyC 0Ong== X-Received: by 10.68.32.161 with SMTP id k1mr6331242pbi.221.1371715828915; Thu, 20 Jun 2013 01:10:28 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [2607:f8b0:400e:c03::229]) by mx.google.com with ESMTPSA id xj9sm26796676pbc.16.2013.06.20.01.10.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 01:10:28 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so6064110pad.0 for ; Thu, 20 Jun 2013 01:10:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.190.104 with SMTP id gp8mr6425408pbc.120.1371715827908; Thu, 20 Jun 2013 01:10:27 -0700 (PDT) Received: by 10.66.122.130 with HTTP; Thu, 20 Jun 2013 01:10:27 -0700 (PDT) Received: by 10.66.122.130 with HTTP; Thu, 20 Jun 2013 01:10:27 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1A65@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> <51C1A89A.9020603@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <51C205AA.6000308@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A65@ESESSMB209.ericsson.se> Date: Thu, 20 Jun 2013 10:10:27 +0200 Message-ID: From: Emil Ivov To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8ff1c09ca7dff504df917aab X-Gm-Message-State: ALoCoQnLveHZzyz+43F62oOiZMdI+0Ete8enKjfeQtakzaI/uebfKZuj/qusuzNMyIDNGgmGEbjd Cc: mmusic Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 08:10:29 -0000 --e89a8ff1c09ca7dff504df917aab Content-Type: text/plain; charset=ISO-8859-1 On Jun 20, 2013 7:04 AM, "Christer Holmberg" wrote: > > > > Well same question then: what would be the downside of only > > allowing that once support for a non-PT demuxing mechanism has > > been confirmed? > > It for sure seems like a feasible solution, in my opinion. > > But, again, at this point I'd like to figure out whether we are going to > specify A rule in BUNDLE to begin with, or whether we trust the > applications to do the right thing :) I was suggesting (here http://www.ietf.org/mail-archive/web/mmusic/current/msg11569.html ) that we adopt PT demuxing and make it the default and MTI mechanism. Others would of course also be allowed to override it if supported by both sides. This way SIP UAs wouldn't need to implement five demuxing techniques to maximize their chances of successfully negotiating bundle from the first o/a. Is there any downside to this? Emil -- sent from my mobile --e89a8ff1c09ca7dff504df917aab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 20, 2013 7:04 AM, "Christer Holmberg" <christer.holmberg@ericsson.com> wr= ote:
> >
> > Well same question then: what would be the downside of only
> > allowing that once support for a non-PT demuxing mechanism has &g= t; > been confirmed?
>
> It for sure seems like a feasible solution, in my opinion.
>
> But, again, at this point I'd like to figure out whether we are go= ing to
> specify A rule in BUNDLE to begin with, or whether we trust the
> applications to do the right thing :)

I was suggesting (here=A0 http://www.ietf.org/mail-archiv= e/web/mmusic/current/msg11569.html ) that we adopt PT demuxing and make= it the default and MTI mechanism. Others would of course also be allowed t= o override it if supported by both sides. This way SIP UAs wouldn't nee= d=A0 to implement five demuxing techniques to maximize their chances of suc= cessfully negotiating bundle from the first o/a.

Is there any downside to this?

Emil

-- sent from my mobile

--e89a8ff1c09ca7dff504df917aab-- From prvs=18839a6962=christer.holmberg@ericsson.com Thu Jun 20 01:52:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C76B21F9EB7 for ; Thu, 20 Jun 2013 01:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcIRf13IFP6A for ; Thu, 20 Jun 2013 01:52:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0F21F9D4D for ; Thu, 20 Jun 2013 01:52:19 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-93-51c2c2c2104e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B8.D1.18006.2C2C2C15; Thu, 20 Jun 2013 10:52:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 10:52:18 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//+AYoD//v6zAP/9Osrg//pid4D/9JhQcA== Date: Thu, 20 Jun 2013 08:52:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1E9E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> <51C1A89A.9020603@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <51C205AA.6000308@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A65@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre6hQ4cCDZb/1LRYs3MCi8Wxvi42 i6nLH7M4MHtcmXCF1WPJkp9MHv/fBAYwR3HbJCWWlAVnpufp2yVwZ8x8OpOxYApnxcbnfWwN jEvYuxg5OSQETCTefXzJBmGLSVy4tx7I5uIQEjjMKNH2pocRwlnEKDF9zkzmLkYODjYBC4nu f9ogDSIC8hLdbYuYQMLMAm4SJ/rqQMLCAg4S937PYoQocZRoXvKWBcKexChxYDEniM0ioCqx 7/RXVpBWXgFfifaFphCbJrJJ/Pu4lxWkhlMgUOJnyzIwmxHotu+n1jCB2MwC4hK3nsxngrhZ QGLJnvPMELaoxMvH/8BmSggoSizvl4Mo15O4MXUKG4StLbFs4Wuwcl4BQYmTM5+wTGAUm4Vk 6iwkLbOQtMxC0rKAkWUVI3tuYmZOernRJkZgzBzc8lt1B+OdcyKHGKU5WJTEeT+e2hUoJJCe WJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MAaY2Csw3L67cNuH5Qb5Lm+b5xyOWhVwNStNQelZ bciEs5kVT5vXsCseM7BcfORtarv0ZbtNMQKbb4fyP+axb0vyl29YvD0usKDy0bbfzM9exPMV 3Nxkkrxw4tPKTx6eyjf1g7iFE+WcVpuLqn9L/+3+8d4X0ZScB1N0C429rvPXLDM9FVUmrcRS nJFoqMVcVJwIAGGq1bdsAgAA Cc: mmusic Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 08:52:25 -0000 Hi, >>> Well same question then: what would be the downside of only=20 >>> allowing that once support for a non-PT demuxing mechanism has > > been= confirmed? >> >> It for sure seems like a feasible solution, in my opinion. >> >> But, again, at this point I'd like to figure out whether we are going to= =20 >> specify A rule in BUNDLE to begin with, or whether we trust the=20 >> applications to do the right thing :) > > I was suggesting (here=A0 http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg11569.html ) that we adopt PT demuxing and make it the default=20 > and MTI mechanism. Others would of course also be allowed to override it = if supported by both sides. This way SIP UAs wouldn't need=A0 to implement= =20 > five demuxing techniques to maximize their chances of successfully negoti= ating bundle from the first o/a. > Is there any downside to this? That could be done for RTP, yes. Keep in mind, though, that the text in BUNDLE is generic. You could also ha= ve multiple m=3D lines for some other transport protocol, and I don't think= we want to start specifying solutions for all of them. Regards, Christer From emil@sip-communicator.org Thu Jun 20 04:33:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9501C21F9BD9 for ; Thu, 20 Jun 2013 04:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnlNylMnD86h for ; Thu, 20 Jun 2013 04:33:13 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 833DA21F9BDB for ; Thu, 20 Jun 2013 04:33:13 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so6118wgg.5 for ; Thu, 20 Jun 2013 04:33:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=xuQ4MQa+T/h0MLeSZa38JnzSCEanSfD62zjS8YOlnYU=; b=QVFsAODe/PDcWigvPUI1a8JRkFQVxVhHuE7G5llSo0PFmML8Qkv+re37swYMXqH3v4 IxPZd5RwCxHWCRsl3jdKhHv12nPKDFcLrGg7QEyeSrZkfUSQcGaxANmEvZnAb2hSxsRR gIxdhVt1zllNz02SpbDwJyf7QmZMekmRQ/DptJUqj+5LGShpAk5TxGJHUO/JPZz5Urtg IGmjjdPwb7HcqySgPFeondRMLfYJT93eZ0m8j3B1bgQg9Gix0/ZpZUB07oMI9Krkz9sq Yhtjf8LVYRNnGFulZ1g8Dx/xor+PfPYNbS3sb+LoXmEUZL06ZxYios0RpgACAMhVzpho F3zQ== X-Received: by 10.180.102.37 with SMTP id fl5mr14106200wib.52.1371727992640; Thu, 20 Jun 2013 04:33:12 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id f8sm15173508wiv.0.2013.06.20.04.33.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 04:33:11 -0700 (PDT) Message-ID: <51C2E875.6020000@jitsi.org> Date: Thu, 20 Jun 2013 13:33:09 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> <51C1A89A.9020603@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <51C205AA.6000308@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A65@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1E9E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1E9E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk228iS1xVPOSwQlKDa3DXNitRgQGbo066V4mm5RXflYix6OkhMRWcQkEeUnjGMaFmGnj3v Cc: mmusic Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 11:33:14 -0000 Hey Christer, On 20.06.13, 10:52, Christer Holmberg wrote: > Hi, > >>>> Well same question then: what would be the downside of only >>>> allowing that once support for a non-PT demuxing mechanism has > > been confirmed? >>> >>> It for sure seems like a feasible solution, in my opinion. >>> >>> But, again, at this point I'd like to figure out whether we are going to >>> specify A rule in BUNDLE to begin with, or whether we trust the >>> applications to do the right thing :) >> >> I was suggesting (here http://www.ietf.org/mail-archive/web/mmusic/current/msg11569.html ) that we adopt PT demuxing and make it the default >> and MTI mechanism. Others would of course also be allowed to override it if supported by both sides. This way SIP UAs wouldn't need to implement >> five demuxing techniques to maximize their chances of successfully negotiating bundle from the first o/a. >> Is there any downside to this? > > That could be done for RTP, yes. > > Keep in mind, though, that the text in BUNDLE is generic. You could also have multiple m= lines for some other transport protocol, and I don't think we want to start specifying solutions for all of them. Well we'd certainly need RTP demuxing to be discussed somewhere. Given that 3264 takes RTP rather "personally", I don't think it would be a bad idea to do the same in BUNDLE and at least define one default mechanism there. I agree that BUNDLE is not the right place to define demuxing procedures for any possible transport. (One of the main issues being that all possible transports have yet to be specified.) Emil -- https://jitsi.org From csp@csperkins.org Thu Jun 20 05:37:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9E21F9B4C for ; Thu, 20 Jun 2013 05:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jApAGh7zfXfJ for ; Thu, 20 Jun 2013 05:37:11 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0004E21F9B4B for ; Thu, 20 Jun 2013 05:37:10 -0700 (PDT) Received: from [130.209.247.112] (port=64669 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Upe6s-0002Y2-Sw; Thu, 20 Jun 2013 13:37:08 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se> Date: Thu, 20 Jun 2013 13:37:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 12:37:16 -0000 On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>> Using 96 for both Opus and VP8 is flat out illegal according to the = RTP specs. >>=20 >> Agree. >=20 > So, we DO agree that the usage of the *same* PT value (even if in = different m=3D lines) for different codecs, or different codec = configurations, is not allowed. >=20 > Is there some specific section in some specific RFC that can be = referenced to show that? RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is = defined per RTP profile (i.e., for RTP/AVP and profiles derived from = it). The BUNDLE defines a single RTP session, which operates under a = single RTP profile, so must have a single mapping from Payload Type to = Payload Formats. RFC 3551 section 3 says: ... mechanisms for defining dynamic payload type bindings have been specified in the Session Description Protocol (SDP) and in other protocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestamp clock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided. You'll note that the association is per RTP session, not per SSRC or = other subset of the session. If you're looking for a statement that two m=3D lines in an SDP can't = map the same PT value to different things, you're unlikely to find it, = since pre-BUNDLE those two m=3D lines would refer to different RTP = sessions, so it would be legal to reuse PT values across m=3D lines. = It's because BUNDLE makes a single RTP session out of several m=3D lines = that you need unique PT mapping across all the m=3D lines. Colin >>> The corner case where we're discussing whether one can use the same = payload type is if you have two M-lines that both specify VP8, with=20 >>> the same codec parameters - whether they can both use 96, given that = it's the same codec. >>=20 >> Surely yes, but you lose the ability to distinguish the m=3D line = based on the PT if you use the same PT (mapped to the exact same codec = and set of codec parameters) in >> several m=3D lines. Some applications care about distinguishing m=3D = lines based on PT values, and so need distinct PT values for every m=3D = line; others don't care, and can=20 >> use the same PT to represent the same codec across multiple m=3D = lines. >=20 > Exactly. So, I think it's a good idea to have some text about that in = BUNDLE. >=20 > Regards, >=20 > Christer >=20 --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Thu Jun 20 06:01:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12BD21F9A64 for ; Thu, 20 Jun 2013 06:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.054 X-Spam-Level: X-Spam-Status: No, score=-4.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8MUfRkrj9Bg for ; Thu, 20 Jun 2013 06:01:22 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3521F9A63 for ; Thu, 20 Jun 2013 06:01:21 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-74-51c2fd20b29f Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A8.45.10205.02DF2C15; Thu, 20 Jun 2013 15:01:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 15:01:20 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//+AYoD//u50gP/9LnHA//n7YID/888tcA== Date: Thu, 20 Jun 2013 13:01:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B2436@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra7i30OBBluncFksf3mC0WLNzgks Fsf6utgspi5/zOLA4nFlwhVWj2n377N5LFnyk8nj/5vAAJYoLpuU1JzMstQifbsErowv3XeZ C94KVuz4tp+1gbGRr4uRk0NCwESiY80vRghbTOLCvfVsXYxcHEICRxkluk/PYIdwFjFKbNo3 CaiKg4NNwEKi+582SIOIgKrEjuP/wJqZBfIkts3aywpiCws4SBx7PZMJosZRonnJWxaQOSIC kxgl3nYvZQFJsAA1fz/1mw3E5hXwlZjTupEZxBYSmM8m8WJRAojNCdT859IjsAWMQNd9P7WG CWKZuMSHg9eZIa4WkFiy5zyULSrx8vE/VghbSaJxyRNWiHodiQW7P7FB2NoSyxa+ZobYKyhx cuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoTi1Oyk03MtjECIymg1t+W+xgvPzX5hCjNAeL kjjvp1O7AoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwnv75R/2wqnW71g8r92cBot8zvOzu qAYVRgXeFhFnmDcv4tVPhgk2Sz8Wsa4TsP2+4vr3pW82Hlss/MPwrU584KFj766cPNy//J56 qbZRuqDWA97VBjHJ5t3LPdOnizodPeslvydqxscb6byPJkr5mrxIdN6nfcV85+E3bIs3pNfz XvH3+Pk9R4mlOCPRUIu5qDgRAElvvgB0AgAA Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 13:01:29 -0000 Hi, >>>> Using 96 for both Opus and VP8 is flat out illegal according to the RT= P specs. >>>=20 >>> Agree. >>=20 >> So, we DO agree that the usage of the *same* PT value (even if in differ= ent m=3D lines) for different codecs, or different codec configurations, is= not allowed. >>=20 >> Is there some specific section in some specific RFC that can be referenc= ed to show that? > > RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is de= fined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The= BUNDLE=20 > defines a single RTP session, which operates under a single RTP profile, = so must have a single mapping from Payload Type to Payload Formats. RFC 355= 1 section 3 says: > > ... > mechanisms for defining dynamic payload type bindings have been > specified in the Session Description Protocol (SDP) and in other > protocols such as ITU-T Recommendation H.323/H.245. These mechanisms > associate the registered name of the encoding/payload format, along > with any additional required parameters, such as the RTP timestamp > clock rate and number of channels, with a payload type number. This > association is effective only for the duration of the RTP session in > which the dynamic payload type binding is made. This association > applies only to the RTP session for which it is made, thus the > numbers can be re-used for different encodings in different sessions > so the number space limitation is avoided. > > You'll note that the association is per RTP session, not per SSRC or othe= r subset of the session. > > If you're looking for a statement that two m=3D lines in an SDP can't map= the same PT value to different things, you're unlikely to find it, since p= re-BUNDLE those two m=3D lines would refer to > different RTP sessions, so it would be legal to reuse PT values across m= =3D lines. It's because BUNDLE makes a single RTP session out of several m= =3D lines that you need unique PT=20 > mapping across all the m=3D lines. I agree. So, unless someone disagrees, BUNDLE can reference the text above, and clar= ify that the rule applies to the whole BUNDLE group, as it forms a single R= TP session. Thanks! Regards, Christer From christer.holmberg@ericsson.com Thu Jun 20 06:05:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532D21F9C95 for ; Thu, 20 Jun 2013 06:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Eh4h9QmCOnv for ; Thu, 20 Jun 2013 06:05:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE1921F9C96 for ; Thu, 20 Jun 2013 06:05:26 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-ff-51c2fe15c260 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A1.3B.15700.51EF2C15; Thu, 20 Jun 2013 15:05:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 15:05:24 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//+AYoD//v6zAP/9Osrg//pid4D/9JhQcP/pJJyA/9IO2fA= Date: Thu, 20 Jun 2013 13:05:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B244F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se> <51C1A4A3.6070105@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se> <51C1A89A.9020603@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <51C205AA.6000308@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A65@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B1E9E@ESESSMB209.ericsson.se> <51C2E875.6020000@jitsi.org> In-Reply-To: <51C2E875.6020000@jitsi.org> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvra7ov0OBBpdPKFus2TmBxeJYXxeb xdTlj1kcmD2uTLjC6rFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgyHh/7y1TwmLdi2pzPjA2M TdxdjJwcEgImEtvOvmWBsMUkLtxbz9bFyMUhJHCYUWLRn7eMEM4iRonfv6cCVXFwsAlYSHT/ 0wZpEBGQl+huW8QEEmYWcJM40VcHEhYWcJA49nomE0SJo0TzEpD5XED2PEaJX58+soEkWARU JQ6c/sAMYvMK+Eq8+/iUBWLXFzaJp4dXgRVxCmhKPOs8AzaJEei676fWgNnMAuISHw5eZ4a4 WkBiyZ7zULaoxMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+BpqsaDEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyipE9NzEzJ73ccBMjMG4Obvmtu4Px1DmRQ4zSHCxK4rwfTu0KFBJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cDYeCtUf3vOxh7XK6ddcwOvadg+3Lo0qMla0i0i+Op87/WF ci86WmTVEloC3f2tNy79MrGDJ+3dRgazc2fXpm25ZL5B59tuVZONYTcygs/deKep2bllT4Ef x8qCBfpeFntuLD0XorZ8kxQHwyrb77Ojzdcf7OxkOTytOEzq+W5FE4GDXY3/4h4qsRRnJBpq MRcVJwIASUY3T2kCAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 13:05:37 -0000 Hi, >>>>> Well same question then: what would be the downside of only=20 >>>>> allowing that once support for a non-PT demuxing mechanism has > > be= en confirmed? >>>> >>>> It for sure seems like a feasible solution, in my opinion. >>>> >>>> But, again, at this point I'd like to figure out whether we are=20 >>>> going to specify A rule in BUNDLE to begin with, or whether we trust=20 >>>> the applications to do the right thing :) >>> >>> I was suggesting (here =20 >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11569.html )=20 >>> that we adopt PT demuxing and make it the default and MTI mechanism. Ot= hers would of course also be allowed to override it if supported by both si= des. This=20 >>> way SIP UAs wouldn't need to implement five demuxing techniques to max= imize their chances of successfully negotiating bundle from the first o/a. >>> Is there any downside to this? >> >> That could be done for RTP, yes. >> >> Keep in mind, though, that the text in BUNDLE is generic. You could also= have multiple m=3D lines for some other transport protocol, and I don't th= ink we want to start specifying solutions for all of them. > > Well we'd certainly need RTP demuxing to be discussed somewhere. Given th= at 3264 takes RTP rather "personally", I don't think it would be a bad idea= to do the same in BUNDLE and at least define one default mechanism there. I personally have no problem to specify a default mechanism for RTP in BUND= LE, and use the mechanism you suggest. After all, RTP is probably going to = be the most common transport protocol using multiple m=3D lines. After the weekend, I'll put together a separate RFD (Request For Decision) = e-mail for that :) Regards, Christer From pkyzivat@alum.mit.edu Thu Jun 20 07:32:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0243721F9BCB for ; Thu, 20 Jun 2013 07:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QlyTrx0fK+W for ; Thu, 20 Jun 2013 07:32:44 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0872421F9CAD for ; Thu, 20 Jun 2013 07:32:42 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id qbJL1l0030EZKEL5CeYiYN; Thu, 20 Jun 2013 14:32:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id qeYi1l0063ZTu2S3MeYiKv; Thu, 20 Jun 2013 14:32:42 +0000 Message-ID: <51C3128B.20402@alum.mit.edu> Date: Thu, 20 Jun 2013 10:32:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C203EF.4090404@alvestrand.no> <4CE4A01D-E103-4AD2-8A08-DE382DA590F1@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B1A08@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371738762; bh=gmHbB5HoZXNimm5xhaHi2Uzz/FS2ZckZXKSyFC8gei0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mmXGQM9RDRlhIuFdeOPhEfkLpUDk62QS1IoC0h07TvnkfaM/wEQ+Lz5zSg1FskgI0 Fwg18s3N/PpXn8aygrp6J1jsl1T/WgqDIJm3rwsbf7aQ7Cr+fv4JbiLu2KINdLK9kq sht7TmWUU/SxwKj/7Xs8P093j8tMVAH6HIJ22xU3/kVoRJPT2JIe1f7ONc4K0bVJ9/ 5jn837SGZ9gqK/KDjXsWVXOOWAqaNWuBLMHLy4eFIT6AhsUgaS38rtMpwle1ao3BE4 rBn8/kRkFlrbSmTS7qviLLVt++xHiVSGFgSVx/adgAcDqEg3cHvv1v2EvBfrQqA+Tt aBxFfoI7w9LNA== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 14:32:50 -0000 On 6/20/13 8:37 AM, Colin Perkins wrote: > On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>>> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs. >>> >>> Agree. >> >> So, we DO agree that the usage of the *same* PT value (even if in different m= lines) for different codecs, or different codec configurations, is not allowed. >> >> Is there some specific section in some specific RFC that can be referenced to show that? > > RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The BUNDLE defines a single RTP session, which operates under a single RTP profile, so must have a single mapping from Payload Type to Payload Formats. RFC 3551 section 3 says: > > ... > mechanisms for defining dynamic payload type bindings have been > specified in the Session Description Protocol (SDP) and in other > protocols such as ITU-T Recommendation H.323/H.245. These mechanisms > associate the registered name of the encoding/payload format, along > with any additional required parameters, such as the RTP timestamp > clock rate and number of channels, with a payload type number. This > association is effective only for the duration of the RTP session in > which the dynamic payload type binding is made. This association > applies only to the RTP session for which it is made, thus the > numbers can be re-used for different encodings in different sessions > so the number space limitation is avoided. > > You'll note that the association is per RTP session, not per SSRC or other subset of the session. I'm not inclined to argue the details of RTP with an RTP expert! But just wearing my standards-lawyer hat I read all of the above references, and could not find anything that clearly justified the assertions you make. I read them as clearly stating that the *static* ones are defined for a profile. I guess the key part of the quote above is: "This association is effective only for the duration of the RTP session". That seems to *bound* the scope of the association, but doesn't explicitly state that it must be unique within that scope. But maybe that is just a matter of me not reading it right, or of the text not having captured every nuance of the intent. > If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to different RTP sessions, so it would be legal to reuse PT values across m= lines. It's because BUNDLE makes a single RTP session out of several m= lines that you need unique PT mapping across all the m= lines. Of course. So I think that means its important for bundle to clearly state the requirement, if it is to be a real one. Thanks, Paul > Colin > > >>>> The corner case where we're discussing whether one can use the same payload type is if you have two M-lines that both specify VP8, with >>>> the same codec parameters - whether they can both use 96, given that it's the same codec. >>> >>> Surely yes, but you lose the ability to distinguish the m= line based on the PT if you use the same PT (mapped to the exact same codec and set of codec parameters) in >>> several m= lines. Some applications care about distinguishing m= lines based on PT values, and so need distinct PT values for every m= line; others don't care, and can >>> use the same PT to represent the same codec across multiple m= lines. >> >> Exactly. So, I think it's a good idea to have some text about that in BUNDLE. >> >> Regards, >> >> Christer >> > > > From pkyzivat@alum.mit.edu Thu Jun 20 07:55:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7121F99EF for ; Thu, 20 Jun 2013 07:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdGLkmm7KyIR for ; Thu, 20 Jun 2013 07:55:01 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8421F9AAF for ; Thu, 20 Jun 2013 07:55:00 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta10.westchester.pa.mail.comcast.net with comcast id qbfw1l0081GhbT85Aev053; Thu, 20 Jun 2013 14:55:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id qeuz1l00u3ZTu2S3Tev00d; Thu, 20 Jun 2013 14:55:00 +0000 Message-ID: <51C317C4.7020907@alum.mit.edu> Date: Thu, 20 Jun 2013 10:55:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org> <51C207F1.1010102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3B1A7F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B1A7F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371740100; bh=cB4sjIEwNtMxJ206EzCLWAydRa5c/fZMjYmF5d8QFGw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CX5s6/ykujpDPmJ1C8Sdl0yULIIj34H3wqVHOkyh+DCzjAEed6hgbR3FKlDdUOFoo 2VEpK2Em2rdRvt4KS/NmzV0AD6tt4XPA7eAvIdWKqbLuxiS95SSYYr3M2vkbmAskj4 iulAXk74A4kJdPfZzhVse9zGZixwTlGsT9lsRcCgLewefTEUwxfW+afPSI9adbCQP8 2N0iv84MW1ZAV2k6HeZL2ZxiRCIgYhi1jATvUxP54uo3Z2vLXx0T1vAkpOsMu4v21L d6iU9aOhdEiuRowjLNLjfRB8KO3yLFTxCW6z+DElaZUB810I448vzrEzW8IW6ZR2Fb XcscyjbdTu/Yw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 14:55:07 -0000 On 6/20/13 1:11 AM, Christer Holmberg wrote: > Hi, > >>> *IF* you have a way to find the right m= line, couldn't PT X have >>> different codec configurations in different m= lines? >> >> Yes, I think so. > > RTP seems to forbid it, though. I just commented on that in a separate reply. I can't find clear text about that. But if that is the consensus interpretation, then I'm fine with that as long as then the bundle spec clearly specifies the implications of that on bundle usage. >>> Let's assume that it could ... but then how would you know that your >>> peer also supports the same demuxing technique as yourself? >> >> Muxing/demuxing (in the sense of associating to a particular m-line) MUST be consistent on both ends. (The sender knows which m-line he associates a packet with, and expects that the receiver will make the same association.) >> >> There must be enough signaling to get the two sides in sync about this. > > When it comes to PT values, each endpoint decides which PT values it wants to other endpoint to send. > > So, even if Alice uses the same PT value in multiple "m=" lines, and have some way to find the "m=" line when media is received, Bob can still assign unique PT values in each "m=" line. > > I don't think there is a requirement to have symmetric PT values in both directions, eventhough I know implementations often do that. Yeah, you are right about that. But I don't think it changes the essence of what I am saying, at least for PT, since there is no question that both sides support the notion of PT. Specifically, the answerer can look at the offer, and the answer it is planning to send, and it can determine if: - the offerer will be able to associate any packet that might be sent to a specific m-line by use of PT alone. - the answerer will be able to associate any packet it might receive to a specific m-line by use of PT alone. And if it can't, and nothing else has been negotiated to assist in the association, then the answer is invalid. So then it will have to revise the answer before sending it. >>> In SIP for example, when constructing a first offer, you may want to >>> map both Opus and VP8 to 96, then add SSRCs for demuxing. This means >>> that you expect your peer to support SSRC demuxing and you can't >>> expect that unless we mandate it. >> >> In this case there will be two m-lines, one audio and one video, each using PT 96. And the offer specifies a specific ssrc for each m-line. >> >> If the answerer does't understand or support muxing by ssrc it will then note that if it accepted both m-lines it would not be able to associate packets with m-lines. So it then has two choices in constructing its answer: >> >> - reject the bundle, but accept both m-lines >> - accept the bundle, but reject one of the m-lines. > > Again, my understanding is that the Offerer indicates which PT values it wants to RECEIVE. So, it it assigns the same PT value to both audio and video, it will receive the same PT value in the media packets. > > But, the Answerer can indicate different PT values for audio and video in the SDP Answer, and it will receive different PT values in the media packets. I think I covered all the PT issues above. But it may be a little harder than I suggest above to figure out if things are ok using ssrc, since a=ssrc only applies to what will be sent. It works ok for the answerer deciding if he will be able to associate received packets to m-lines. But for the answerer to decide if the offerer will be able to associate the packets it receives to m-lines, the answerer will need to know if the offerer supports using the ssrc to associate packets to m-lines. The simplest thing I can suggest for that is that if the offer requires using ssrc for demux, then perhaps one can assume that the offerer is also prepared to use ssrc to demux on its end. Most of the time that would be a no-brainer. Thanks, Paul From bernard_aboba@hotmail.com Thu Jun 20 09:48:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0C21F9D37 for ; Thu, 20 Jun 2013 09:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1JMV5nF18tA for ; Thu, 20 Jun 2013 09:48:10 -0700 (PDT) Received: from blu0-omc3-s28.blu0.hotmail.com (blu0-omc3-s28.blu0.hotmail.com [65.55.116.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59021F9CEB for ; Thu, 20 Jun 2013 09:48:10 -0700 (PDT) Received: from BLU169-W102 ([65.55.116.72]) by blu0-omc3-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 09:48:09 -0700 X-TMN: [H9LiFgXZpXa9Sxl4PT3QfG/ExY+3obCh] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_129ac546-bc56-476f-ac14-c9c07aef675c_" From: Bernard Aboba To: Paul Kyzivat , Christer Holmberg Date: Thu, 20 Jun 2013 09:48:08 -0700 Importance: Normal In-Reply-To: <51C317C4.7020907@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, , <51C1A4A3.6070105@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, , <51C1A89A.9020603@alvestrand.no>, , , , <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, , , <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se>, <51C1DD3A.8030705@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se>, <51C1E5D5.9020009@jitsi.org> <51C207F1.1010102@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C3B1A7F@ESESSMB209.ericsson.se>, <51C317C4.7020907@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 16:48:09.0555 (UTC) FILETIME=[F1FB1A30:01CE6DD5] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 16:48:15 -0000 --_129ac546-bc56-476f-ac14-c9c07aef675c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:=20 > I just commented on that in a separate reply. > I can't find clear text about that. [BA] Within the Multiiplexing Guidelines document=2C Appendix A cover PT mu= ltiplexing (see text below): http://tools.ietf.org/html/draft-ietf-avtcore-= multiplex-guidelines However=2C I do not see any text there addressing the specific issues that = are being discussed relating to the BUNDLE document. IMHO=2C this is unfor= tunate.=20 > But if that is the consensus interpretation=2C then I'm fine with that as= > long as then the bundle spec clearly specifies the implications of that= =20 > on bundle usage. [BA] If in fact there is a consensus=2C I'd argue that it should be include= d in the WG consensus document that is supposed to be covering this topic (= e.g. the Multiplexing Guidelines document).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Appendix A. Dismissing Payload Type Multiplexing=0A= =0A= This section documents a number of reasons why using the payload type=0A= as a multiplexing point for most things related to multiple streams=0A= is unsuitable. If one attempts to use Payload type multiplexing=0A= beyond it's defined usage=2C that has well known negative effects on=0A= RTP. To use Payload type as the single discriminator for multiple=0A= streams implies that all the different media streams are being sent=0A= with the same SSRC=2C thus using the same timestamp and sequence number= =0A= space. This has many effects:=0A= =0A= 1. Putting restraint on RTP timestamp rate for the multiplexed=0A= media. For example=2C media streams that use different RTP=0A= timestamp rates cannot be combined=2C as the timestamp values need= =0A= to be consistent across all multiplexed media frames. Thus=0A= streams are forced to use the same rate. When this is not=0A= possible=2C Payload Type multiplexing cannot be used.=0A= =0A= 2. Many RTP payload formats may fragment a media object over=0A= multiple packets=2C like parts of a video frame. These payload=0A= formats need to determine the order of the fragments to=0A= correctly decode them. Thus it is important to ensure that all=0A= fragments related to a frame or a similar media object are=0A= transmitted in sequence and without interruptions within the=0A= object. This can relatively simple be solved on the sender side=0A= by ensuring that the fragments of each media stream are sent in=0A= sequence.=0A= =0A= 3. Some media formats require uninterrupted sequence number space=0A= between media parts. These are media formats where any missing=0A= RTP sequence number will result in decoding failure or invoking=0A= of a repair mechanism within a single media context. The text/=0A= T140 payload format [RFC4103] is an example of such a format.=0A= These formats will need a sequence numbering abstraction=0A= function between RTP and the individual media stream before=0A= being used with Payload Type multiplexing.=0A= =0A= 4. Sending multiple streams in the same sequence number space makes=0A= it impossible to determine which Payload Type and thus which=0A= stream a packet loss relates to.=0A= =0A= 5. If RTP Retransmission [RFC4588] is used and there is a loss=2C it= =0A= is possible to ask for the missing packet(s) by SSRC and=0A= sequence number=2C not by Payload Type. If only some of the=0A= Payload Type multiplexed streams are of interest=2C there is no=0A= way of telling which missing packet(s) belong to the interesting=0A= stream(s) and all lost packets must be requested=2C wasting=0A= bandwidth.=0A= =0A= 6. The current RTCP feedback mechanisms are built around providing=0A= feedback on media streams based on stream ID (SSRC)=2C packet=0A= (sequence numbers) and time interval (RTP Timestamps). There is=0A= almost never a field to indicate which Payload Type is reported=2C= =0A= so sending feedback for a specific media stream is difficult=0A= without extending existing RTCP reporting.=0A= =0A= 7. The current RTCP media control messages [RFC5104] specification=0A= is oriented around controlling particular media flows=2C i.e.=0A= requests are done addressing a particular SSRC. Such mechanisms=0A= would need to be redefined to support Payload Type multiplexing.=0A= 8. The number of payload types are inherently limited.=0A= Accordingly=2C using Payload Type multiplexing limits the number=0A= of streams that can be multiplexed and does not scale. This=0A= limitation is exacerbated if one uses solutions like RTP and=0A= RTCP multiplexing [RFC5761] where a number of payload types are=0A= blocked due to the overlap between RTP and RTCP.=0A= =0A= 9. At times=2C there is a need to group multiplexed streams and this= =0A= is currently possible for RTP Sessions and for SSRC=2C but there=0A= is no defined way to group Payload Types.=0A= =0A= 10. It is currently not possible to signal bandwidth requirements=0A= per media stream when using Payload Type Multiplexing.=0A= =0A= 11. Most existing SDP media level attributes cannot be applied on a=0A= per Payload Type level and would require re-definition in that=0A= context.=0A= =0A= 12. A legacy endpoint that doesn't understand the indication that=0A= different RTP payload types are different media streams may be=0A= slightly confused by the large amount of possibly overlapping or=0A= identically defined RTP Payload Types. = --_129ac546-bc56-476f-ac14-c9c07aef675c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul said: =3B

>=3B I just commented on that in a separate reply.
>=3B I can'= t find clear text about that.

[BA] Within the Mult= iiplexing Guidelines document=2C Appendix A cover PT multiplexing (see text= below): =3B
http://tools.ietf.org/html/draft-ietf-avtcore-mu= ltiplex-guidelines

However=2C I do not see any tex= t there addressing the specific issues that are being discussed relating to= the BUNDLE document.  =3BIMHO=2C this is unfortunate. =3B

>=3B But if that is = the consensus interpretation=2C then I'm fine with that as =3B
>=3B long as then the bundle spec clearly specifies the implicat= ions of that
>=3B on bundle usage.

[BA] If i= n fact there is a consensus=2C I'd argue that it should be included in the = WG consensus document that is supposed to be covering this topic (e.g. the = Multiplexing Guidelines document). =3B

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

= 
Appendix A.  Dismissing Payloa=
d Type Multiplexing
=0A=
=0A=
   This section documents a number of reasons why using the payload type=0A=
   as a multiplexing point for most things related to multiple streams=0A=
   is unsuitable.  If one attempts to use Payload type multiplexing=0A=
   beyond it's defined usage=2C that has well known negative effects on=0A=
   RTP.  To use Payload type as the single discriminator for multiple=0A=
   streams implies that all the different media streams are being sent=0A=
   with the same SSRC=2C thus using the same timestamp and sequence number=
=0A=
   space.  This has many effects:=0A=
=0A=
   1.   Putting restraint on RTP timestamp rate for the multiplexed=0A=
        media.  For example=2C media streams that use different RTP=0A=
        timestamp rates cannot be combined=2C as the timestamp values need=
=0A=
        to be consistent across all multiplexed media frames.  Thus=0A=
        streams are forced to use the same rate.  When this is not=0A=
        possible=2C Payload Type multiplexing cannot be used.=0A=
=0A=

   2.   Many RTP paylo=
ad formats may fragment a media object over=0A=
        multiple packets=2C like parts of a video frame.  These payload=0A=
        formats need to determine the order of the fragments to=0A=
        correctly decode them.  Thus it is important to ensure that all=0A=
        fragments related to a frame or a similar media object are=0A=
        transmitted in sequence and without interruptions within the=0A=
        object.  This can relatively simple be solved on the sender side=0A=
        by ensuring that the fragments of each media stream are sent in=0A=
        sequence.=0A=
=0A=
   3.   Some media formats require uninterrupted sequence number space=0A=
        between media parts.  These are media formats where any missing=0A=
        RTP sequence number will result in decoding failure or invoking=0A=
        of a repair mechanism within a single media context.  The text/=0A=
        T140 payload format [RFC4103] i=
s an example of such a format.=0A=
        These formats will need a sequence numbering abstraction=0A=
        function between RTP and the individual media stream before=0A=
        being used with Payload Type multiplexing.=0A=
=0A=
   4.   Sending multiple streams in the same sequence number space makes=0A=
        it impossible to determine which Payload Type and thus which=0A=
        stream a packet loss relates to.=0A=
=0A=
   5.   If RTP Retransmission [RFC4588]=
 is used and there is a loss=2C it=0A=
        is possible to ask for the missing packet(s) by SSRC and=0A=
        sequence number=2C not by Payload Type.  If only some of the=0A=
        Payload Type multiplexed streams are of interest=2C there is no=0A=
        way of telling which missing packet(s) belong to the interesting=0A=
        stream(s) and all lost packets must be requested=2C wasting=0A=
        bandwidth.=0A=
=0A=
   6.   The current RTCP feedback mechanisms are built around providing=0A=
        feedback on media streams based on stream ID (SSRC)=2C packet=0A=
        (sequence numbers) and time interval (RTP Timestamps).  There is=0A=
        almost never a field to indicate which Payload Type is reported=2C=
=0A=
        so sending feedback for a specific media stream is difficult=0A=
        without extending existing RTCP reporting.=0A=
=0A=
   7.   The current RTCP media control messages [RFC5104] specification=
=0A=
        is oriented around controlling particular media flows=2C i.e.=0A=
        requests are done addressing a particular SSRC.  Such mechanisms=0A=
        would need to be redefined to support Payload Type multiplexing.=0A=


   8.   The number of payload types ar=
e inherently limited.=0A=
        Accordingly=2C using Payload Type multiplexing limits the number=0A=
        of streams that can be multiplexed and does not scale.  This=0A=
        limitation is exacerbated if one uses solutions like RTP and=0A=
        RTCP multiplexing [RFC5761] where a number of payload types are=0A=
        blocked due to the overlap between RTP and RTCP.=0A=
=0A=
   9.   At times=2C there is a need to group multiplexed streams and this=
=0A=
        is currently possible for RTP Sessions and for SSRC=2C but there=0A=
        is no defined way to group Payload Types.=0A=
=0A=
   10.  It is currently not possible to signal bandwidth requirements=0A=
        per media stream when using Payload Type Multiplexing.=0A=
=0A=
   11.  Most existing SDP media level attributes cannot be applied on a=0A=
        per Payload Type level and would require re-definition in that=0A=
        context.=0A=
=0A=
   12.  A legacy endpoint that doesn't understand the indication that=0A=
        different RTP payload types are different media streams may be=0A=
        slightly confused by the large amount of possibly overlapping or=0A=
        identically defined RTP Payload Types.




= --_129ac546-bc56-476f-ac14-c9c07aef675c_-- From pkyzivat@alum.mit.edu Thu Jun 20 11:18:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BA621F9C88 for ; Thu, 20 Jun 2013 11:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyVjP52YWQRX for ; Thu, 20 Jun 2013 11:18:27 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9493421F9CD7 for ; Thu, 20 Jun 2013 11:18:24 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id qamS1l0010EZKEL55iJ9ib; Thu, 20 Jun 2013 18:18:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id qiJ81l00o3ZTu2S3MiJ8iq; Thu, 20 Jun 2013 18:18:09 +0000 Message-ID: <51C34761.2080500@alum.mit.edu> Date: Thu, 20 Jun 2013 14:18:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3B154D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B154D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371752289; bh=y/SnIn3OzzjoaN37VmH0Qbstm+aiwgSUgAVvA4sP89U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ea1fjDsk/7nl+KgkTk6SxXWDJvTR/cJDPtJyMWW/OLpsA5/lH09fpCpG5WZ0kyssx fPfsl6jNOR0BIBLijrj7s3/Xm5R5p5aF1F3hYYGVmJGY1XcEnIrcTCObE+S4z1fr1u TbMSbJ5Fa+5TjcUGkvTDMd6tKgWymlX8iAZvdrzarpJO4nU7991S3tiR8cRHKx9zlM waz1ySUrRhjRCBpa3O8r4qUjJPA9Nz4ToaXYcBaZLCfCS1cDgh53eKAHeRpRSEveKo e1L1NQTDk07sGNTpZaAXVfnXBKe+Dkq/UsP2PU44pHQRydUS2KHGIP/F5z6rDfttml FAhFxV6HAO4Wg== Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 18:18:32 -0000 Getting better. More inline. On 6/19/13 2:38 PM, Christer Holmberg wrote: > Hi, > > I modified the text, based on the comments. > > - The text now refers to RFC 5764 for RTP, DTLS, STUN de-multiplexing. > - I added an open note regarding how much we need to specify regarding "m= line de-muxing" for the same transport protocol. > - I removed the MUST for having to be able to do "m= line de-muxing" for the same transport protocol, as there could be cases where it's not needed. > > Regards, > > Christer > > -------------------------------------------------- > > > 9.1. General > > Endpoints can assign "m=" lines representing different transport > protocols [RFC4566], identified using the "m=" line proto value > [RFC4566]. > > As each "m=" line in a BUNDLE group share the BUNDLE address, an > endpoint MUST be able to de-multiplex data received on the BUNDLE > address, meaning it MUST be able to associate the received with one > of the transport protocols assigned to the BUNDLE group. Endpoints > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > able to separate received data from data associated with other > transport protocols assigned to the BUNDLE group. > > In addition, if an endpoint assigns multiple "m=" lines representing > the same transport protocol to a BUNDLE group, the endpoint might > also have to be able to, in addition to associating received data to > its transport protocol, associate the received data with a specific > "m=" line representing that transport protocol. > > OPEN ISSUE: We need to discuss how much, if anything, we need to say > about associating RTP packets with the correct "m=" line, in cases > where there are multiple "m=" lines for RTP media. My position on this is well known - presumably the issue refers to my arguments. So I won't repeat them here. *If* we can agree that associating packets to m-lines is a MUST, then the two paragraphs above the open issue can be collapsed into one. (If you can associate to an m-line, then of course you can associate to the protocol described by the m-line. > Section 5.1.2 of [RFC5764] specifies how to de-multiplex RTP, DTLS and > STUN [RFC5389] data packets. Something special must be said about STUN, because it is indeed an exception to my point about associating to an m-line. It is also an exception to associating to a protocol mentioned in m-lines. What is complex here is that we are dealing with layered protocols, but SDP syntax pretends they are not. To address this fully, I think it is necessary to identify the protocol *stack* for each m-line, and then figure out which of those layers are shared by multiple m-lines. STUN is a middle layer in the stack, presumably shared by all the m-lines. Thanks, Paul > If endpoints want to assign "m=" lines representing other transport > protocols to a BUNDLE group, it MUST be documented how the de- > multiplexing is performed. There might also be a need for signalling > extensions in order for endpoints to exchange data needed for the de- > multiplexing. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From lsmt@ietf.org Wed Jun 19 11:05:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6A721F9E27; Wed, 19 Jun 2013 11:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJJlTPqAgnsh; Wed, 19 Jun 2013 11:05:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6DE21F9E0B; Wed, 19 Jun 2013 11:05:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Susanna Kooistra <3GPPLiaison@etsi.org> X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619180511.22660.92516.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 11:05:11 -0700 X-Mailman-Approved-At: Thu, 20 Jun 2013 14:40:34 -0700 Cc: Flemming Andreasen , Ari Keranen , Gonzalo Camarillo , Multiparty Multimedia Session Control Discussion List Subject: [MMUSIC] New Liaison Statement, "Reply to Liaison statement to IETF concerning 3D video formats signalling in SDP" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:05:17 -0000 Title: Reply to Liaison statement to IETF concerning 3D video formats signa= lling in SDP Submission Date: 2013-06-19 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1260/ From: Multiparty Multimedia Session Control (Flemming Andreasen ) To: 3GPP (Susanna Kooistra <3GPPLiaison@etsi.org>) Cc: Gonzalo Camarillo ,Flemming Andreasen <= fandreas@cisco.com>,Ari Keranen ,Gonzalo Camarill= o ,Richard Barnes ,Multiparty M= ultimedia Session Control Discussion List Reponse Contact: Ari Keranen , Flemming Andreasen= Technical Contact: = Purpose: In response Referenced liaison: Liaison statement to IETF concerning 3D video formats s= ignalling in SDP (http://datatracker.ietf.org/liaison/1239/) Body: Source: IETF MMUSIC WG To: TSG-SA WG4 The MMUSIC Working Groups thanks SA4 for their information request around w= ork related to SDP signaling of 3D video formats. At the present time, the = MMUSIC WG does not have any active work in this area. For your information, the MMUSIC WG did previously (in 2012) consider work = in this area based on the following 3 documents: http://datatracker.ietf.org/doc/draft-capelastegui-mmusic-3dv-sdp/ http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-parallax/ http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-3d-format/ The drafts were presented in a couple of meetings and discussed on the MMUS= IC mailing list. While work was initially being pursued, there was ultimate= ly not sufficient interest or technical agreement in the WG for continued w= ork and adoption of these items. It was also believed that additional 3D vi= deo expertise and alignment with JCT-3V, MPEG and ITU-T Q6/16 (VCEG) would = be needed to adequately cover this area. In lieu of the above, the work did= not proceed. The MMUSIC WG would welcome further input from SA WG4 on this matter. Next IETF meetings: - IETF 87 July 28 - August 2, 2013, Berlin, Germany - IETF 88 November 3-8, 2013, Vancouver, BC, Canada Regards, Flemming Andreasen and Ari Ker=EF=BF=BDnen MMUSIC WG co-chairs Attachments: No document has been attached From gonzalo.camarillo@ericsson.com Fri Jun 21 01:33:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2C21F9A5F for ; Fri, 21 Jun 2013 01:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.053 X-Spam-Level: X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDMnr4kUv4EW for ; Fri, 21 Jun 2013 01:33:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0949E21E80D2 for ; Fri, 21 Jun 2013 01:33:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-cf-51c40fcb9afe Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EA.5E.09795.BCF04C15; Fri, 21 Jun 2013 10:33:15 +0200 (CEST) Received: from [131.160.126.58] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 21 Jun 2013 10:33:15 +0200 Message-ID: <51C40FCA.3070608@ericsson.com> Date: Fri, 21 Jun 2013 11:33:14 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Flemming Andreasen References: <51BF1AA8.2020902@ericsson.com> <51C05839.7010502@cisco.com> In-Reply-To: <51C05839.7010502@cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vvc0/5FAg95+FYv3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZbxftJS94DlPRffVGUwNjKu4uhg5OSQETCTe t/QwQthiEhfurWfrYuTiEBI4xSix/t8UFghnDaPEwbXPgTIcHLwC2hI/vuqBNLAIqEpsWXiF FcRmE7CQ2HLrPguILSoQJTFn3QM2EJtXQFDi5MwnLCCtIkCtUxdYgISZBSIlWv/dZwexhQXM JJbdu88KUiIk4CGx7roGSJhTQFPi1sSvbBCnSUpsedHODtGqJzHlagsjhC0v0bx1NjOILQQ0 ffmzFpYJjEKzkCyehaRlFpKWBYzMqxjZcxMzc9LLzTcxAoP04JbfBjsYN90XO8QozcGiJM77 6dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M1pfedwhxNBpPaJ58vPntz5NqHm3b+XJs n72d0pD/w/5fZZnws2b9HfvU+jxCuL2WclfaS7yJy72wspPN3T7sseCpjzennUu8n2896bzT jajo2cFNGkeeKqRwL/j9P3x9V/LrF+8Dz//2f8ywN3LGB/mUbeH8XOKzVr4zaTh9bI8Jf/T2 OBYDJZbijERDLeai4kQA5fk+kiACAAA= Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] Virtual interim meeting material X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 08:33:22 -0000 Folks, by the way, during the agenda bash people asked why we did not have the ADs on this particular call. When the chairs were scheduling this interim, they could not find any slots where both the key participants and the ADs were available. So, we chose to give priority to the key participants because without them the usefulness of the interim would have been compromised. Cheers, Gonzalo On 18/06/2013 3:53 PM, Flemming Andreasen wrote: > Greetings > > Below you will find a link to the recording for yesterday's MMUSIC > Virtual Interim meeting that was focused on the "Plan A or Plan B" > discussion related to RTCWeb et. al. > > Thanks > > -- Flemming > > > Your recording is now available on the WebEx service site. Click the > link below to play it: > > https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69199732&rKey=cac5fee577de08f8 > > > MMUSIC Virtual Interim-20130617 1405-1 > Monday, June 17, 2013 10:05 am New York Time > 2 Hours 57 Minutes > > * You can forward this message to others to allow them to play back the > recording. * > > > On 6/17/13 10:18 AM, Ari Keränen wrote: >> Virtual interim meeting material available here: >> http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/proceedings.html >> >> >> Chair slides with agenda proposal(s): >> http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt >> >> >> Cheers, >> Ari >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Mon Jun 24 02:31:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C6421F9BA5 for ; Mon, 24 Jun 2013 02:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSEV-QC-vahe for ; Mon, 24 Jun 2013 02:31:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D7ED111E80E6 for ; Mon, 24 Jun 2013 02:31:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-cd-51c811f4e568 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 29.CB.09795.4F118C15; Mon, 24 Jun 2013 11:31:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 11:31:32 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version Thread-Index: AQHObeKrFZ3edTBr0kKLyJE1dgAr65lEnxZA Date: Mon, 24 Jun 2013 09:31:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B8F09@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3B154D@ESESSMB209.ericsson.se> <51C34761.2080500@alum.mit.edu> In-Reply-To: <51C34761.2080500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre5XwROBBge7mCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj7WcPS8El+Yq+n//ZGxjfS3QxcnJICJhI rJ7xkhHCFpO4cG89G4gtJHCYUeL0spQuRi4gexGjxNq/N5m7GDk42AQsJLr/aYPUiAj4Sjx7 fJsNJCwsEC5xrz8TIhwhsehbD1hYRMBI4tQpe5Awi4CqRNeSJ+wgNi9Q55rne6A25Ut8Wf6L CaScU0BH4kFrBEiYEeiY76fWMIHYzALiEreezGeCOFJAYsme88wQtqjEy8f/WCFsRYn2pw2M EPV6EjemTmGDsLUlli18zQyxVlDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15u vokRGAMHt/w22MG46b7YIUZpDhYlcd5Pp3YFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk +xmk79rhJ7K7SdjOUiXnyIeLdkkuH7q3bOa7xlR48MlD2dilH1Ps9ty+VzSrVpDl1FNNR5GV hx/Mjf4Vtaz91I16lolmR5586Nh5+1iRS62JsUo747QfiTah8w7v88xtq1hy3X9d1P1/Qs9X sXxiSQ8sW52wV/K9R9CtU+s4jLpbpQ9xs6xVYinOSDTUYi4qTgQA5Mm+tE8CAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late night version X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 09:31:41 -0000 Hi Paul, I submitted the late night version text before you questioned whether refer= encing RFC 5764 is enough, so we obviously need to sort that out before mov= ing ahead with the text :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 20. kes=E4kuuta 2013 21:18 To: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) - Late nig= ht version Getting better. More inline. On 6/19/13 2:38 PM, Christer Holmberg wrote: > Hi, > > I modified the text, based on the comments. > > - The text now refers to RFC 5764 for RTP, DTLS, STUN de-multiplexing. > - I added an open note regarding how much we need to specify regarding "m= =3D line de-muxing" for the same transport protocol. > - I removed the MUST for having to be able to do "m=3D line de-muxing" fo= r the same transport protocol, as there could be cases where it's not neede= d. > > Regards, > > Christer > > -------------------------------------------------- > > > 9.1. General > > Endpoints can assign "m=3D" lines representing different transport > protocols [RFC4566], identified using the "m=3D" line proto value > [RFC4566]. > > As each "m=3D" line in a BUNDLE group share the BUNDLE address, an > endpoint MUST be able to de-multiplex data received on the BUNDLE > address, meaning it MUST be able to associate the received with one > of the transport protocols assigned to the BUNDLE group. Endpoints > MUST NOT assign a transport protocols to a BUNDLE group, unless it is > able to separate received data from data associated with other > transport protocols assigned to the BUNDLE group. > > In addition, if an endpoint assigns multiple "m=3D" lines representin= g > the same transport protocol to a BUNDLE group, the endpoint might > also have to be able to, in addition to associating received data to > its transport protocol, associate the received data with a specific > "m=3D" line representing that transport protocol. > > OPEN ISSUE: We need to discuss how much, if anything, we need to say > about associating RTP packets with the correct "m=3D" line, in cases > where there are multiple "m=3D" lines for RTP media. My position on this is well known - presumably the issue refers to my argum= ents. So I won't repeat them here. *If* we can agree that associating packets to m-lines is a MUST, then the t= wo paragraphs above the open issue can be collapsed into one. (If you can a= ssociate to an m-line, then of course you can associate to the protocol des= cribed by the m-line. > Section 5.1.2 of [RFC5764] specifies how to de-multiplex RTP, DTLS an= d > STUN [RFC5389] data packets. Something special must be said about STUN, because it is indeed an exceptio= n to my point about associating to an m-line. It is also an exception to as= sociating to a protocol mentioned in m-lines. What is complex here is that we are dealing with layered protocols, but SDP= syntax pretends they are not. To address this fully, I think it is necessa= ry to identify the protocol *stack* for each m-line, and then figure out wh= ich of those layers are shared by multiple m-lines. STUN is a middle layer = in the stack, presumably shared by all the m-lines. Thanks, Paul > If endpoints want to assign "m=3D" lines representing other transport > protocols to a BUNDLE group, it MUST be documented how the de- > multiplexing is performed. There might also be a need for signalling > extensions in order for endpoints to exchange data needed for the de- > multiplexing. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon Jun 24 03:41:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4C21E80DF for ; Mon, 24 Jun 2013 03:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p5cpq0GVc1D for ; Mon, 24 Jun 2013 03:41:05 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20021E80DC for ; Mon, 24 Jun 2013 03:41:00 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-7f-51c8223b0107 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D2.35.09795.B3228C15; Mon, 24 Jun 2013 12:40:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 12:40:58 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)] Thread-Index: Ac5wx08/TAURHL5TRnSJwZ3ZRjxyOQ== Date: Mon, 24 Jun 2013 10:40:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@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.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvra610olAg/29YhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx5GIHc0GPWsXamf1MDYxvZLsYOTkkBEwk Pu6Yxg5hi0lcuLeerYuRi0NI4DCjxPFbaxghnEVAzv9LQBkODjYBC4nuf9ogDSICvhLPHt8G axAW6GWU6Pj5ihXEERGYxCjR8H8pG0SVnsT/h/tZQZpZBFQlXvR7goR5gZonrm5gBbEZgTZ/ P7WGCcRmFhCXuPVkPhPERQISS/acZ4awRSVePv7HCmErSrQ/bWCEqNeTuDF1ChuErS2xbOFr Zoj5ghInZz5hmcAoPAvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLzTYzA4D645bfBDsZN98UO MUpzsCiJ8346tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OqQ0/ep+fdDc6PW2li9HSP 6NSDz7WEDyoIHBTNqDu9itWcyeLJM0ePLJ4f381TN4Q9bvRTY45N7ead3aC58nX4PpnOfi3h NSYKdX3Ngmempzvsq3V8XcDzsGC7WLuu8enFQacLCgzWHE+Jjj4qXMuyTJ2NMcPSZf8evyNH qudPMvM32sdUrcRSnJFoqMVcVJwIABmbXoc8AgAA Subject: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 10:41:11 -0000 Hi, Based on the input and discussion, let's see if we can make a couple of dec= isions :) Q1: Can we agree that, within a BUNDLE group (including all m- lines associ= ated with the group), any given PT value can only be used for a single code= c configuration? NOTE: If you think we need some clarification text on what "codec configura= tion" means, or if you think we should use some other wording - feel free t= o suggest :) Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, as= there are opinions that simply referencing RFC 3550 might not be clear eno= ugh? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 20. kes=E4kuuta 2013 17:33 To: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) On 6/20/13 8:37 AM, Colin Perkins wrote: > On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>>> Using 96 for both Opus and VP8 is flat out illegal according to the RT= P specs. >>> >>> Agree. >> >> So, we DO agree that the usage of the *same* PT value (even if in differ= ent m=3D lines) for different codecs, or different codec configurations, is= not allowed. >> >> Is there some specific section in some specific RFC that can be referenc= ed to show that? > > RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is de= fined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The= BUNDLE defines a single RTP session, which operates under a single RTP pro= file, so must have a single mapping from Payload Type to Payload Formats. R= FC 3551 section 3 says: > > ... > mechanisms for defining dynamic payload type bindings have been > specified in the Session Description Protocol (SDP) and in other > protocols such as ITU-T Recommendation H.323/H.245. These mechanisms > associate the registered name of the encoding/payload format, along > with any additional required parameters, such as the RTP timestamp > clock rate and number of channels, with a payload type number. This > association is effective only for the duration of the RTP session in > which the dynamic payload type binding is made. This association > applies only to the RTP session for which it is made, thus the > numbers can be re-used for different encodings in different sessions > so the number space limitation is avoided. > > You'll note that the association is per RTP session, not per SSRC or othe= r subset of the session. I'm not inclined to argue the details of RTP with an RTP expert! But just wearing my standards-lawyer hat I read all of the above references= , and could not find anything that clearly justified the assertions you mak= e. I read them as clearly stating that the *static* ones are defined for a = profile. I guess the key part of the quote above is: "This association is effective only for the duration of the RTP session= ". That seems to *bound* the scope of the association, but doesn't explicit= ly state that it must be unique within that scope. But maybe that is just a matter of me not reading it right, or of the text = not having captured every nuance of the intent. > If you're looking for a statement that two m=3D lines in an SDP can't map= the same PT value to different things, you're unlikely to find it, since p= re-BUNDLE those two m=3D lines would refer to different RTP sessions, so it= would be legal to reuse PT values across m=3D lines. It's because BUNDLE m= akes a single RTP session out of several m=3D lines that you need unique PT= mapping across all the m=3D lines. Of course. So I think that means its important for bundle to clearly state = the requirement, if it is to be a real one. Thanks, Paul > Colin > > >>>> The corner case where we're discussing whether one can use the same=20 >>>> payload type is if you have two M-lines that both specify VP8, with th= e same codec parameters - whether they can both use 96, given that it's the= same codec. >>> >>> Surely yes, but you lose the ability to distinguish the m=3D line=20 >>> based on the PT if you use the same PT (mapped to the exact same=20 >>> codec and set of codec parameters) in several m=3D lines. Some applicat= ions care about distinguishing m=3D lines based on PT values, and so need d= istinct PT values for every m=3D line; others don't care, and can use the s= ame PT to represent the same codec across multiple m=3D lines. >> >> Exactly. So, I think it's a good idea to have some text about that in BU= NDLE. >> >> Regards, >> >> Christer >> > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon Jun 24 03:45:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8A121E80D2 for ; Mon, 24 Jun 2013 03:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.873 X-Spam-Level: X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSi64FbO+Gf4 for ; Mon, 24 Jun 2013 03:45:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 58FED21E80DB for ; Mon, 24 Jun 2013 03:45:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-df-51c8235d96bb Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 30.D5.09795.D5328C15; Mon, 24 Jun 2013 12:45:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 12:45:48 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] Thread-Index: Ac5wx08/TAURHL5TRnSJwZ3ZRjxyOQAAFz+A Date: Mon, 24 Jun 2013 10:45:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@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.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrW6s8olAgxev5C2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj2/J3TAWbdCoW3X3O1sDYr9zFyMkhIWAi 8evYHVYIW0ziwr31bF2MXBxCAocZJZ6ePscC4SxilFj27QVQhoODTcBCovufNkhcRKCZUeLa +eVgRcICExklVnQeYIbITGKUuLFzJwvIXBEBI4kt2y+xgdgsAqoSd47sZQSxeQV8JdbNusIE YgsB2bNXtYDZnAJ+Eofm9YD1MgLd9P3UGrA4s4C4xK0n85kgbhWQWLLnPDOELSrx8vE/qB8U JdqfNjBC1OtJ3Jg6hQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tu YmZOern5JkZgRBzc8ttgB+Om+2KHGKU5WJTEeT+d2hUoJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgXG3xXSuzU+nCT/N17oZcPl8aV7knbTLBsnnZ9+0eWO+9dhj+xnfrp3zZV422+n71NDZ 0eeTDRw43z+rZc3VnREwoz+LdT+7+o7F8dbMEjNSdHdVczRN3tMz8djje1LTEpQ9L/5wk15y RFj85/utS73nC10+ta09Zl31LIOHsnz3kxYGBKhLh8gqsRRnJBpqMRcVJwIAiE8lDlYCAAA= Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 10:45:56 -0000 Hi, Regarding Q2, as Bernard suggested to specify it in draft-ietf-avtcore-mult= iplex-guidelines, please replace the question with: Q2: If we agree on Q1, do we agree that we need EXPLICIT text SOMEWHERE, as= there are opinions that simply referencing RFC 3550 might not be clear eno= ugh? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 24. kes=E4kuuta 2013 13:41 To: Paul Kyzivat; mmusic@ietf.org Subject: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in = a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] Hi, Based on the input and discussion, let's see if we can make a couple of dec= isions :) Q1: Can we agree that, within a BUNDLE group (including all m- lines associ= ated with the group), any given PT value can only be used for a single code= c configuration? NOTE: If you think we need some clarification text on what "codec configura= tion" means, or if you think we should use some other wording - feel free t= o suggest :) Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, as= there are opinions that simply referencing RFC 3550 might not be clear eno= ugh? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 20. kes=E4kuuta 2013 17:33 To: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) On 6/20/13 8:37 AM, Colin Perkins wrote: > On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>>> Using 96 for both Opus and VP8 is flat out illegal according to the RT= P specs. >>> >>> Agree. >> >> So, we DO agree that the usage of the *same* PT value (even if in differ= ent m=3D lines) for different codecs, or different codec configurations, is= not allowed. >> >> Is there some specific section in some specific RFC that can be referenc= ed to show that? > > RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is de= fined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The= BUNDLE defines a single RTP session, which operates under a single RTP pro= file, so must have a single mapping from Payload Type to Payload Formats. R= FC 3551 section 3 says: > > ... > mechanisms for defining dynamic payload type bindings have been > specified in the Session Description Protocol (SDP) and in other > protocols such as ITU-T Recommendation H.323/H.245. These mechanisms > associate the registered name of the encoding/payload format, along > with any additional required parameters, such as the RTP timestamp > clock rate and number of channels, with a payload type number. This > association is effective only for the duration of the RTP session in > which the dynamic payload type binding is made. This association > applies only to the RTP session for which it is made, thus the > numbers can be re-used for different encodings in different sessions > so the number space limitation is avoided. > > You'll note that the association is per RTP session, not per SSRC or othe= r subset of the session. I'm not inclined to argue the details of RTP with an RTP expert! But just wearing my standards-lawyer hat I read all of the above references= , and could not find anything that clearly justified the assertions you mak= e. I read them as clearly stating that the *static* ones are defined for a = profile. I guess the key part of the quote above is: "This association is effective only for the duration of the RTP session= ". That seems to *bound* the scope of the association, but doesn't explicit= ly state that it must be unique within that scope. But maybe that is just a matter of me not reading it right, or of the text = not having captured every nuance of the intent. > If you're looking for a statement that two m=3D lines in an SDP can't map= the same PT value to different things, you're unlikely to find it, since p= re-BUNDLE those two m=3D lines would refer to different RTP sessions, so it= would be legal to reuse PT values across m=3D lines. It's because BUNDLE m= akes a single RTP session out of several m=3D lines that you need unique PT= mapping across all the m=3D lines. Of course. So I think that means its important for bundle to clearly state = the requirement, if it is to be a real one. Thanks, Paul > Colin > > >>>> The corner case where we're discussing whether one can use the same=20 >>>> payload type is if you have two M-lines that both specify VP8, with th= e same codec parameters - whether they can both use 96, given that it's the= same codec. >>> >>> Surely yes, but you lose the ability to distinguish the m=3D line=20 >>> based on the PT if you use the same PT (mapped to the exact same=20 >>> codec and set of codec parameters) in several m=3D lines. Some applicat= ions care about distinguishing m=3D lines based on PT values, and so need d= istinct PT values for every m=3D line; others don't care, and can use the s= ame PT to represent the same codec across multiple m=3D lines. >> >> Exactly. So, I think it's a good idea to have some text about that in BU= NDLE. >> >> Regards, >> >> Christer >> > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Mon Jun 24 04:39:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17D121E80E6 for ; Mon, 24 Jun 2013 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.127 X-Spam-Level: X-Spam-Status: No, score=-106.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jypCaRv8U0k9 for ; Mon, 24 Jun 2013 04:39:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC621E80E5 for ; Mon, 24 Jun 2013 04:39:37 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-50-51c82ff44651 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.D3.18006.4FF28C15; Mon, 24 Jun 2013 13:39:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 24 Jun 2013 13:39:32 +0200 Message-ID: <51C8300F.8040709@ericsson.com> Date: Mon, 24 Jun 2013 13:39:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvre5X/ROBBrsPMlpc2z2FyWLq8scs DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfG7fO7WQt+i1SsX9vM0sB4U6CLkZNDQsBE YufMOawQtpjEhXvr2boYuTiEBE4xShxd8YsdwlnOKPHu6gU2kCpeAW2JjqfbgGwODhYBVYnf q5VBwmwCFhI3fzSClYgKBEsc2b6ZBaJcUOLkzCdgtoiAukTr5j6wZcwC8RLLn1xnBLGFBRwk Gg+vZYI4QlJiy4t2dogaPYkpV1sYIWx5ieats5lBbCGgExqaOlgnMArMQrJiFpKWWUhaFjAy r2Jkz03MzEkvN9rECAy9g1t+q+5gvHNO5BCjNAeLkjjvx1O7AoUE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwMoXfu3BZVTA++0O6e1BERVA4+47ZFsct+zetSHC4lf4obnacQ8eT2h0WLv0d +ZMPzO74mv7GImXxrPYO07LSTPUY+WsitYILLiQVcbIIas3cb6XNu11h/22bdqbqdB35w9YT ZD9d3H5N54yxWfuhHub5LnGvjrLffnPc4eejJlE3u2P/5t5TYinOSDTUYi4qTgQAMvUSlAsC AAA= Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" Subject: [MMUSIC] RTSP 2.0: Removing queuing of server to client requests X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 11:39:45 -0000 WG, Robert raised an issue regarding some text in 10.2: A server that attempts to send a request to a client that has no connection currently to the server SHOULD discard the request directly, but it MAY queue it for later delivery. However, if the server queues the request it SHOULD when adding additional requests to the queue ensure to remove older requests that are now redundant. >> >> The text talks about the option to queue S->C requests if there isn't a >> connection to the client available. Ostensibly, this means the request >> can go down some future connection. It's not clear how the server can >> tell the right client connected. In particular, when using rtsps, how do >> you prevent a malicious client from getting such a queued message that >> wasn't meant for him? > > > Okay, this security issue I have totally missed but it is clearly > serious. I don't see any easy way of fixing this. Thus I would suggest > that we simply make it clear that a server MUST NOT queue the S->C RTSP > message, independent if they are requests PLAY_NOTIFY and TEARDOWN or > responses to client requests. > > >> >> Given that the text talks about queuing S-C requests, it should >> explicitly call out whether a server can queue a response if the >> connection the associated request arrived on is no longer available. I >> think what you want to say is that such a response must not be queued, >> and must be dropped. > > Agreed, lets mandate that they are dropped. > > I propose that this change is done and implemented like this text replacing the above one. A server that attempts to send a request to a client that has no connection currently to the server SHALL discard the request directly. I also propose that we add a indented reasons paragraph: Queuing of server to client requests has been considered. However a security issue exist in how one authorizes a client establishing a new connection as being a legit receiver of request related to a particular RTSP session without the client first issuing requests related to the request. Thus, likely making any such requests even more delayed and less useful. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Mon Jun 24 04:46:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE5921F9926 for ; Mon, 24 Jun 2013 04:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc-9r228CJJm for ; Mon, 24 Jun 2013 04:46:14 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57F21F9605 for ; Mon, 24 Jun 2013 04:46:14 -0700 (PDT) Received: from [81.187.2.149] (port=34164 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ur5Dm-00055G-PT; Mon, 24 Jun 2013 12:46:11 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> Date: Mon, 24 Jun 2013 12:46:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 11:46:19 -0000 Christer, For Q1 - I agree.=20 For Q2 - I agree that we need explicit text somewhere.=20 We might also add an explicit statement that it's okay to use the same = PT for the exact same codec confirmation in multiple m=3D lines, = _provided_ you don't want to use the PT values to associate packets with = m=3D lines. Colin On 24 Jun 2013, at 11:45, Christer Holmberg wrote: > Hi, >=20 > Regarding Q2, as Bernard suggested to specify it in = draft-ietf-avtcore-multiplex-guidelines, please replace the question = with: >=20 > Q2: If we agree on Q1, do we agree that we need EXPLICIT text = SOMEWHERE, as there are opinions that simply referencing RFC 3550 might = not be clear enough? >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Christer Holmberg > Sent: 24. kes=E4kuuta 2013 13:41 > To: Paul Kyzivat; mmusic@ietf.org > Subject: [MMUSIC] DECISION: Unique PT value/codec configuration = mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June = 19th)] >=20 >=20 > Hi, >=20 > Based on the input and discussion, let's see if we can make a couple = of decisions :) >=20 >=20 > Q1: Can we agree that, within a BUNDLE group (including all m- lines = associated with the group), any given PT value can only be used for a = single codec configuration? >=20 > NOTE: If you think we need some clarification text on what "codec = configuration" means, or if you think we should use some other wording - = feel free to suggest :) >=20 >=20 >=20 > Q2: If we agree on Q1, do we agree that we need EXPLICIT text in = BUNDLE, as there are opinions that simply referencing RFC 3550 might not = be clear enough? >=20 >=20 > Regards, >=20 > Christer ... --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Mon Jun 24 04:56:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652AF11E8129 for ; Mon, 24 Jun 2013 04:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GncjEaLamjv for ; Mon, 24 Jun 2013 04:56:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8712421F9B09 for ; Mon, 24 Jun 2013 04:55:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-79-51c833ce17c9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7F.95.18006.EC338C15; Mon, 24 Jun 2013 13:55:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 13:55:58 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] Thread-Index: Ac5wx08/TAURHL5TRnSJwZ3ZRjxyOQAAFz+A///v9oD//9wroA== Date: Mon, 24 Jun 2013 11:55:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org> In-Reply-To: <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre454xOBBmtXK1ksf3mC0WLq8scs Fis2HGB1YPb4+/4Dk8e0+/fZPJYs+ckUwBzFZZOSmpNZllqkb5fAldH2SLrgOH/F3T/z2RoY p/F0MXJySAiYSDS/OMUCYYtJXLi3nq2LkYtDSOAwo8Si+/uZIZxFjBL/Hx1h7WLk4GATsJDo /qcN0iAioCqx4/g/RhCbWcBX4uWCL2D1wgITGSVWdB4Ac0QEJjFK3Ni5kwWkWUTASeLpSh+Q Bhag5uXPWsCaeYGaV29ayQ6x7ASjxKzVi8ASnAKOEp+ev2AGsRmBzvt+ag0TxDZxiVtP5jNB nC0gsWTPeWYIW1Ti5eN/rBC2okT70wao6/QkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMwcg5u+a26g/HOOZFDjNIcLErivB9P7QoUEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwMglXrLCdLthSneCjE2IirgEF+vjCydm7mU4dpkhzfeq o/27xGfS//zVc7IeB5XtMP1jLBq5PDnozRSxLnFW+8YL0j/EZoUWFB3iZFc8OMto2xL/qleO qUbcD8LcTn5X99hbXVm2b+kjxtYXrGv1fuy9z/fg+Jn19qISNx3vbZxuXj3H/fLnMCWW4oxE Qy3mouJEAMQRzQ5qAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 11:56:07 -0000 Hi, > Christer, > > For Q1 - I agree.=20 > > For Q2 - I agree that we need explicit text somewhere.=20 > > We might also add an explicit statement that it's okay to use the same PT= for the exact same codec confirmation in multiple m=3D lines, _provided_ y= ou don't want to use the PT values to associate packets with m=3D lines. I left that question out on purpose, because I intend to ask it separately = :) Regards, Christer On 24 Jun 2013, at 11:45, Christer Holmberg wrote: > Hi, >=20 > Regarding Q2, as Bernard suggested to specify it in draft-ietf-avtcore-mu= ltiplex-guidelines, please replace the question with: >=20 > Q2: If we agree on Q1, do we agree that we need EXPLICIT text SOMEWHERE, = as there are opinions that simply referencing RFC 3550 might not be clear e= nough? >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Christer Holmberg > Sent: 24. kes=E4kuuta 2013 13:41 > To: Paul Kyzivat; mmusic@ietf.org > Subject: [MMUSIC] DECISION: Unique PT value/codec configuration mapping i= n a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] >=20 >=20 > Hi, >=20 > Based on the input and discussion, let's see if we can make a couple of d= ecisions :) >=20 >=20 > Q1: Can we agree that, within a BUNDLE group (including all m- lines asso= ciated with the group), any given PT value can only be used for a single co= dec configuration? >=20 > NOTE: If you think we need some clarification text on what "codec configu= ration" means, or if you think we should use some other wording - feel free= to suggest :) >=20 >=20 >=20 > Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, = as there are opinions that simply referencing RFC 3550 might not be clear e= nough? >=20 >=20 > Regards, >=20 > Christer ... --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Jun 24 05:02:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE7A21F9007 for ; Mon, 24 Jun 2013 05:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1cpW5oKnQMN for ; Mon, 24 Jun 2013 05:02:13 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8358921F8763 for ; Mon, 24 Jun 2013 05:01:42 -0700 (PDT) Received: from [81.187.2.149] (port=39511 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ur5Sl-0006Of-NH; Mon, 24 Jun 2013 13:01:40 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se> Date: Mon, 24 Jun 2013 13:01:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27108551-D2EC-4A45-8EE6-07053873F61D@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 12:02:18 -0000 On 24 Jun 2013, at 12:55, Christer Holmberg wrote: >> Christer, >>=20 >> For Q1 - I agree.=20 >>=20 >> For Q2 - I agree that we need explicit text somewhere.=20 >>=20 >> We might also add an explicit statement that it's okay to use the = same PT for the exact same codec confirmation in multiple m=3D lines, = _provided_ you don't want to use the PT values to associate packets with = m=3D lines. >=20 > I left that question out on purpose, because I intend to ask it = separately :) In that case, I agree with Q1 and Q2 :-) --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Mon Jun 24 05:22:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7511E812B for ; Mon, 24 Jun 2013 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.135 X-Spam-Level: X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU3a3pFGYEsz for ; Mon, 24 Jun 2013 05:22:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60C21F9DAE for ; Mon, 24 Jun 2013 05:22:16 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-85-51c839f69ec9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F9.D8.18006.6F938C15; Mon, 24 Jun 2013 14:22:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 24 Jun 2013 14:22:14 +0200 Message-ID: <51C83A10.40601@ericsson.com> Date: Mon, 24 Jun 2013 14:22:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre43yxOBBp+Pmlpc2z2FyWLq8scs DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfG+6avzAWzrCtmb77J3sA4Vb+LkZNDQsBE 4kjzKmYIW0ziwr31bF2MXBxCAqcYJc5u/MsK4SxnlLh0bw4bSBWvgKbE+bVfWUFsFgFViVff p7CA2GwCFhI3fzSC1YgKBEsc2b6ZBaJeUOLkzCdgtoiAukTr5j6wXmaBeInlT64zgtjCAn4S qxZeY4e4QlJiy4t2dogaPYkpV1sYIWx5ieats8EuFRLQlmho6mCdwCgwC8mKWUhaZiFpWcDI vIqRPTcxMye93GgTIzD4Dm75rbqD8c45kUOM0hwsSuK8H0/tChQSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAaDbtdJ1+zOG3Qp9nTJfs2fJl4XLpX2GJNyPvfNihmWbZIfa/Omumcfsj76w1 d0SWxHSdW6L/X7ST6di0m1sEJjCurG3ZJ2/woT53yqobWYzKhq3Tj+YnS2/5+uJ6nWQz4x4G ZQt+0Un7nZmj9wpFlqxOe+Q+p2A3T1zMVolIQaEjArlnkm+WKLEUZyQaajEXFScCAGW4JxgM AgAA Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" Subject: [MMUSIC] RTSP 2.0: Change of recommendation for multiple connections to server X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 12:22:25 -0000 WG, Both Robert Sparks and Elwyn Davies found issues that relates to the following paragraph in section 10.2 of draft-ietf-mmusic-rfc2326bis-34 An RTSP agent SHOULD NOT have more than one connection to the server at any given point. If a client or proxy handles multiple RTSP sessions on the same server, it SHOULD use only one connection for managing those sessions. This saves connection resources on the server. It also reduces complexity by enabling the server to maintain less state about its sessions and connections. Elwyn wrote: s10.2, para 6 and following note: I can't see that the note following para 6 can be justified: since the restriction on multiple connections from a client to a server is only a SHOULD, an interoperable server MUST be capable of handling multiple connections from a client unless the server can explicitly send back a TOO MANY CONNECTIONS status. Robert had two issues that relates to this (including my comments to the original issue): >> >> In section 10.4, it looks like a server can keep an RTSP transaction >> pending forever if it sends 100 responses often enough. I assume the >> client's recourse if it doesn't want to remain involved is to close the >> connection. If that's right, it's worth calling it out explicitly in >> this section. > > This is likely a good suggestion, and works fine if the client simply > wants to abort the request and is anyway abandoning the RTSP session. > However, the question is what to do if just the request becomes > irrelevant and instead want to do something else with the RTSP session. > A single client may abandon the connection, open a new one and issue a > request, to a potentially undetermined session state. Yet another > complexity is what a proxy does that has multiple RTSP sessions on the > same server. Here the rules for processing in order the different > requests and their relation to answers in the same order. > > This makes me want to weaken the recommendation on re-using an > connection for multiple RTSP sessions. > The second issue is related to the 503 and Retry-After response and what happens when multiple sessions are on the same connections: >> >> There are several places in the text that talk about using a 503 >> response with a Retry-After header to push back on traffic from an >> element (the first is section 10.7). >> * It's not clear what the subject of a 503 is. Is it intended to be >> scoped to requests to the resource in the RURI of the associated >> request? Is it intended to be scoped to the domain in that resource? Or >> is it, like in SIP, intended to be scoped to the server issuing the >> response, independent of what the RURI contained? > > Very good question. It is far from obvious what the best choice is. And > I think even talking only about URI related scope may not be the best. > > The case I have in mind is if a proxy that has several already > established RTSP sessions over a persistent connection. When a client > connected to the proxy requests to establish a new session the server > may have insufficient resource to handle the SETUP request and send a > 503 answer. However if another client already having an RTSP session for > the same resource want to terminate that session it would be strange to > refuse to process the message as it will actually free up resources. > > This makes me believe that you need to have a RTSP Session scope for any > request carrying a Session-ID and a general server, or host name scope > for non-associated that doesn't prevent established sessions to try. > > Thoughts on this? > > >> * If the intent is that the 503 talks about the server, then you should >> clarify that a proxy doesn't simply forward 503 responses (after >> rewriting CSeqs), and should probably have a response of its own. >> Otherwise, clients that might be talking to two different servers >> through one proxy would lose access to both of them when one of the >> servers 503ed. > > If we us a host and session scope then this issue would not be present. > However, if the proxy is actually overloaded that still needs its own > 552 Proxy Unavailable response with the same scope rules as for the 503, > but where unassociated requests concerns sending to the proxy at all. > My proposal for dealing with these issues are the following: 1. Change the recommendation around multiple sessions over one connection to a MAY use multiple sessions over a connection and that it is allowed also for proxies. Proposed text: An RTSP agent MAY use one connection to handle multiple RTSP sessions on the same server. The RTSP agent SHALL NOT use more than one connection per RTSP session at any given point. Using a single connection for multiple RTSP session saves connection resources on the server. Not using more than one connection at a time for a particular RTSP session avoids wasting connection resources and allows the server to track only for the latest in client to server used connection for each RTSP session as being the currently valid server to client connection. 2. Making clear the the downsides of closing a multi-session connection, but also how to recover from it by writing the following in 10.4: A requester SHOULD wait at least 10 seconds for a response before concluding that the responder will not be responding to its request. After receiving a 100 response, the requester SHOULD continue waiting for further responses. If more than 10 seconds elapses without receiving any response, the requester MAY assume that the responder is unresponsive and abort the connection by closing the TCP connection. Note: In cases multiple RTSP sessions share the same transport connection, abandoning a request closing the connection may have significant impact on those other sessions. First of all, other RTSP requests may have become queued up due to the request taking long time. Secondly also those sessions loose the possibility to receive server to client requests. To mitigate that situation the RTSP Agent should establish a new connection and send any queued up and non-responded requests on this new connection. Secondly, to ensure that the RTSP server knows which connection that is valid for a particular RTSP session, the RTSP agent should send a keep-alive request, if no other request will be sent immeditely for that RTSP session, for each RTSP session on the old connection. The keep-alive request will normally be a GET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session. 3. I recommend that we make the separation for the 503 response proposed above, i.e.: Session scope if session request, otherwise server scope according to host name. Especially noting that a server scope 503 response does not prevent one from issue session related requests for already established sessions. Comments and feedback? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tireddy@cisco.com Mon Jun 24 06:06:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E10311E8141 for ; Mon, 24 Jun 2013 06:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhEjGKTzSlVM for ; Mon, 24 Jun 2013 06:06:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B51A011E812F for ; Mon, 24 Jun 2013 06:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2144; q=dns/txt; s=iport; t=1372079169; x=1373288769; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=V8gR7VjPZKfBKKWEQaZNvLKL5HuRPsHNTh4UtfhZVB0=; b=K0LRmN+UC2UOOmyp4spLMwvjM+M0cRKLCpaGr4olGOinY5JQ2s94hakU C9c77FIy++x3jx+v95idHsVt0FXVngJvHOj7VgqBYWnC71r/IdXDmfn00 BVOO6WnRaCCv23iGVUr8OgINeTfve+qylHX0xtrhET+3R4STpk4WHH7kX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAGBDyFGtJV2c/2dsb2JhbABbgwkxQwaDBbwyDXUWdIIjAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUFBBMIAYgFBwWZQo58kQaBJo14PoJJM2EDmGyQG4MQgig X-IronPort-AV: E=Sophos;i="4.87,928,1363132800"; d="scan'208";a="226643792" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jun 2013 13:06:09 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5OD69LV028451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Jun 2013 13:06:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 08:06:09 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt Thread-Index: AQHOcK15+DWlJMUbHkqfCSOc2ALdLplEelaQ Date: Mon, 24 Jun 2013 13:06:08 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B8C943@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:06:14 -0000 SGkgYWxsLA0KDQp3ZSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IGJhc2VkIG9uIHRoZSBjb21tZW50 cyByZWNlaXZlZCBkdXJpbmcgSUVURiA4NiB0byBjb21wYXJlIE1JQ0Ugd2l0aCBJQ0UgcmVzdGFy dCBhbmQgVHJpY2tsZSBJQ0UgKFNlY3Rpb24gNiAiQ29tcGFyaXNvbiB0byBJQ0UgUmVzdGFydCBh bmQgVHJpY2tsZSBJQ0UiKS4gY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0K DQpCZXN0IFJlZ2FyZHMsDQotLUF1dGhvcnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdW5lIDI0LCAyMDEzIDE6MDYgUE0NClRvOiBQcmFz aGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFu IFdpbmcgKGR3aW5nKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS0wNC50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmls aXR5LTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW4gV2luZyBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXdp bmctbW11c2ljLWljZS1tb2JpbGl0eQ0KUmV2aXNpb246CSAwNA0KVGl0bGU6CQkgTW9iaWxpdHkg d2l0aCBJQ0UgKE1JQ0UpDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNi0yNA0KR3JvdXA6CQkgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE5DQpVUkw6ICAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbmctbW11c2ljLWlj ZS1tb2JpbGl0eS0wNC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkNCkh0bWxpemVkOiAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmls aXR5LTA0DQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS0wNA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg c3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgaG93IGVuZHBvaW50IG1vYmlsaXR5IGNhbiBiZSBhY2hp ZXZlZA0KICAgdXNpbmcgSUNFLiAgVHdvIG1lY2hhbmlzbXMgYXJlIHNob3duLCBvbmUgd2hlcmUg Ym90aCBlbmRwb2ludHMNCiAgIHN1cHBvcnQgSUNFIGFuZCBhbm90aGVyIHdoZXJlIG9ubHkgb25l IGVuZHBvaW50IHN1cHBvcnRzIElDRS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From emil@sip-communicator.org Mon Jun 24 07:02:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6521A11E8151 for ; Mon, 24 Jun 2013 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmpnphKkBs80 for ; Mon, 24 Jun 2013 07:02:13 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F321F9F27 for ; Mon, 24 Jun 2013 07:02:12 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so2576212wid.3 for ; Mon, 24 Jun 2013 07:02:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=mPIzwwrXm2exHqvBC2dqreUMfWWWO+oSixaRFY2rPh4=; b=fjXiNdDfYOS464EZi9/D53csA1k7iuZNzRDgTLRqQXkw1ArFYy2lks3D93M3fRbKlC POArluFgolpExK3QJxcefijhv6VEaa01qJZf0MOqay51PQRsABK6x1VPWvMy8tnOAHCA lX3a2wU7HFIiJV9zXfFBvgoQ11uxEgyr9mZcing1m385Mi8OBH3wK7Vzsgx33Kv+yFiV dhXvCzucsXncpR/lu+OfR6JyNZoKAbB6LuvTaCXjj1p3kn5qUqmTKZ6/+C+KPylmHw5h RTzcILGXeiBRPyFn8B0fXTATFxpkiA0nn45i4ekqAl/8LF9pZ8Rt+dncBBrlujl39i5K 3e3Q== X-Received: by 10.180.182.229 with SMTP id eh5mr6052433wic.63.1372082531908; Mon, 24 Jun 2013 07:02:11 -0700 (PDT) Received: from camionet.local (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id nj19sm284434wic.1.2013.06.24.07.02.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 07:02:11 -0700 (PDT) Message-ID: <51C85164.5080208@jitsi.org> Date: Mon, 24 Jun 2013 16:02:12 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A14B8C943@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B8C943@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnLRurj8DiYqnla2ynVCwCf9Iw/u9Qk6l0NjRg8Kee/vIjDn4TrxDbtzc11tmALQYeg2ZDi Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:02:19 -0000 Hey Tiru, On 24.06.13, 15:06, Tirumaleswar Reddy (tireddy) wrote: > Hi all, > > we have updated the draft based on the comments received during IETF > 86 to compare MICE with ICE restart and Trickle ICE (Section 6 > "Comparison to ICE Restart and Trickle ICE"). comments and > suggestions are welcome. Thanks for doing this. A few comments on that comparison: > 6.2. Break Before Make - Trickle ICE > > o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for RTP > Mobility then in case of Break before Make, > > 1. Trickle ICE can begin connectivity checks while the endpoint > is still gathering candidates and can considerably shorten the > time necessary for ICE processing to complete. It still > involves the overhead of step 1 explained in section > Section 6.1. The said overhead being SIP re-registration, I don't see how trickle-ice and mice are in a different position here. Why would one be able to restart attempts without it, while the other wouldn't? > 2. The endpoint would learn host candidates and inform them to > the remote peer in offer, the remote peer will provide its > candidates in answer. The host, server reflexive, peer > reflexive and relayed candidates of the remote peer may not > change and the remote peer does not have to gather the > candidates again. Trickle ICE will test local host candidates > with all types of remote candidates provided by the remote > peer in the answer. If the ICE peer is behind NAT performing > end-point independent mapping and filtering then ICE > connectivity checks initiated by the endpoint to the remote > peer will succeed. Actually that's what you'd need the NAT to be without trickle ICE so that break-before-make mice would succeed (which I've already expressed as a concern with this draft). Using trickle ICE would allow you to succeed with endpoint dependent filtering because the remote party would also start checks in your direction. I guess what I am trying to say is that it doesn't make sense for mice not to use trickle ICE for this case. > 3. Trickle ICE must be supported by both endpoints for it be > used. I am not sure I understand this argument. Any kind of mobility management would have to be supported by both pears in order to be used. Cheers, Emil > > Best Regards, --Authors. > > -----Original Message----- From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org] Sent: Monday, June 24, 2013 1:06 > PM To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Dan > Wing (dwing); Pal Martinsen (palmarti) Subject: New Version > Notification for draft-wing-mmusic-ice-mobility-04.txt > > > A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt has been > successfully submitted by Dan Wing and posted to the IETF > repository. > > Filename: draft-wing-mmusic-ice-mobility Revision: 04 Title: > Mobility with ICE (MICE) Creation date: 2013-06-24 Group: > Individual Submission Number of pages: 19 URL: > http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-04.txt > > Status: http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility > Htmlized: > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04 Diff: > http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-04 > > Abstract: This specification describes how endpoint mobility can be > achieved using ICE. Two mechanisms are shown, one where both > endpoints support ICE and another where only one endpoint supports > ICE. > > > > > The IETF Secretariat > > _______________________________________________ mmusic mailing list > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From magnus.westerlund@ericsson.com Mon Jun 24 07:51:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0893811E8164; Mon, 24 Jun 2013 07:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.717 X-Spam-Level: X-Spam-Status: No, score=-103.717 tagged_above=-999 required=5 tests=[AWL=-2.318, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwneeBgJJct5; Mon, 24 Jun 2013 07:51:34 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD8521E8165; Mon, 24 Jun 2013 07:51:20 -0700 (PDT) X-AuditID: c1b4fb38-b7fa16d0000027dd-96-51c85ce73591 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.30.10205.7EC58C15; Mon, 24 Jun 2013 16:51:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 24 Jun 2013 16:51:19 +0200 Message-ID: <51C85D02.1050907@ericsson.com> Date: Mon, 24 Jun 2013 16:51:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Elwyn Davies References: <1370477514.4596.9052.camel@mightyatom> In-Reply-To: <1370477514.4596.9052.camel@mightyatom> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvre7zmBOBBtt2CVtc/HKE3eL4gR3s FldffWaxmLr8MYsDi8fXk+0sHkuW/GTy+HL5M1sAcxSXTUpqTmZZapG+XQJXxq/z09gLVqRX fGhLbGBcEdjFyMkhIWAi0Tp/CyuELSZx4d56ti5GLg4hgTOMEstnLWGCcJYzSqxqfcQGUsUr oC3x714PUIKDg0VAVeLY7giQMJuAhcTNH41gJaICwRJHtm9mgSgXlDg58wmYLSKgJrH56wNG EJtZoJtR4v1aXhBbWMBHYsuE1WA1QgLGEo+/vgc7iBPouLutXVDHSUpsedHODtGrJzHlagvU HHmJ5q2zmSF6tSUamjpYJzAKzUKyehaSlllIWhYwMq9i5ChOLU7KTTcy2MQIDOSDW35b7GC8 /NfmEKM0B4uSOO+nU7sChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTC2x3IqGjfbNhd2Llu3 UfiWw863WwJmfZ5gNv9Z9SOZ5Zyt/JE+HW6va5bc5rJ/XW75VFXY+vGLfCkVIaEfu98+nGK1 S3zFrfxuX4vVs68Ghs06Ih7+qlSUZQofp7FF8Lqvwuk3nzd/+qqxxM/BqXtyGp+1h5G3tNFj 3vT7p5Vr7qZqLbVjb1JiKc5INNRiLipOBABeXH+6MgIAAA== Cc: General Area Review Team , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 14:51:41 -0000 Elwyn, Follow up on some of the nits that is not simply to implement or where I disagree or want to provide feedback. This email covers all issues up to and including Section 11. That is as far as I have managed to process them yet. I will now handle over the rest of this list to my co-authors. On 2013-06-06 02:11, Elwyn Davies wrote: > > s2.3, para 5: >> The server should also regularly send every 5 >> minutes the current media range in a PLAY_NOTIFY request. > Shouldn't this be configurable? As discussed in Section 13.5.2 the reasons for the picked time is the following: The recommendation for sending updates every 5 minutes is due to any clock skew issues. In 5 minutes the clock skew should not become too significant as this is not used for media playback and synchronization, only for determining which content is available to the user. Yes, it can be configurable, and in fact 5 min is only the recommended interval. So, if an implementation that have a good reason for something else can do that. Do you have a reason why you think this should be configurable? But, if it should be rewritten, I think the acceptable range for within to adjust it should be specified, like between 1 min and 2 hours. > > s2.3, last para: >> If the client waits too long >> before resuming the pause point, the content may no longer be >> available. In this case the pause point will be adjusted to the end >> of the available media. > I know this is a subjective choice, but I would have thought adjusting > to the beginning of the available media would be what the user expects. > Later: Having read s13.4.1, I think this conflicts with (or is unclear) > compared with s13.4.1, para 2 which states that the pause point will be > the oldest retained time - that is what I would have expected. Yes, "end" in the above sentence is not quite right. My proposal is the following: In this case the pause point will be adjusted to the closest point in the available media. > > > s3.1, para 3: Clearly there won't be any smaller type paras in the > ASCII version.. is there a PDF version that actually has smaller type? > The one I get from the repository doesn't seem to have any smaller type > paras. I removed the "small type" as this is a remains from when the draft was produced using LaTex and a PDF version was produced. > > s4.4: An external reference to the relevant Society of Motion Picture > and Television Engineers standard (probably SMPTE 12M) ought to be > included to define things like "SMPTE 30 drop". [Aside: 29.97 frames > per second?? Must be something to do with Never Twice the Same Color. > Oh, well, a little research job for whan I am really bored.] Yes, it is ST 12M-1 2008 that appears to be the relevant reference. Yes, SMPTE 30 drop is a NTSC thing. > > s4.9.1: There seems to be some confusion in this section between the > values from the Seek-Style header and the values from the > Media-Properties random access property. The section says the values > are from Seek-Style but they are actually from the random access > property. Presumably there was some intention to interelate the media > capabilities and the play event policies? Further this section has > Random Access, Conditional Random Access, Return to Start and No > Seeking. This doesn't match exactly with either Seek-Style (RAP, CoRAP, > First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only > and No-Seeking). Yes, this was confused. Actual the Media-Properties headers values are a distinct set. Then if doing random access then the Seek-Style policies applies. This I propose to clarify by writing Section 4.9.1 as: 4.9.1. Random Access and Seeking Random Access is the ability to specify and get media delivered from any point inside the content, an operation called seeking. The Media-Properties header will indicate the general capability for a media resource to perform random access. If random access is possible the actual behavior policy when seeking can be controlled using the Seek-Style header (Section 18.45). Random-Access: The media is seekable to any out of a large number of points within the media. Due to media encoding limitations, a particular point may not be reachable, but seeking to a point close by is enabled. A floating point number of seconds may be provided to express the worst case distance between random access points. Beginning-Only: Seeking is only possible to the beginning of the content. No-seeking: Seeking is not possible at all. > > s4.9.x: It would be desirable to use the parameter names in the same > form as they appear in s18 (e.g., Random-Access instead of Random > Access, No-Seeking instead of No seeking) both in the definitions > (s4.9.1 - s4.9.4) and the mapping (s4.9.5). Yes, that is has been addressed. > > > ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified > values "smpte", "npt" and "clock" are valid in the Range parameter. > What is the meaning of such an unqualified value? You are correct about that the basic definition in ABNF allows for empty. The reason for this is the following stated in Section 18.38: It MAY be included in GET_PARAMETER requests from the client to the server with only a Range format and no value to request the current media position, whether the session is in Play or Ready state in the included format. > > s5: It would be sensible to note that the ABNF fragments in s5 and the > following sections match with the full syntax productions in s20. I have added a note, but they are in fact equivalent, but not identical. Thus I make it clear that that this is for information and the formal is in section 20.2.2. > > Table 3: Proxy-Authorization (Section 18.34) doesn't appear in any of > the various header categorization tables [I must have better things to > do than checking they were all there :-( ]. I think it belongs here. Sorry, for not having found this myself before. You noticing it missing, was actually a larger inconsistency issue. It was missing in the ABNF also. I have spent quite some time now to ensure that the ABNF, the tables in Section 6-8 and the header description now align as they should regarding category. > s8.1.1, code 505: HTTP code 505 is explicitly '*HTTP* version not > supported' - should there really be a separate code for 'RTSP version > not supported'? Yes, but the import of HTTP response codes are their meaning not there exact definition. Thus 505 is RTSP version not supported as listed in table. That is also what section 17.5.6 defines it as. > > s9: Is it deliberately left vague as to whether other message types > might have message bodies? This is unnecessary vague. In attempt to clarify this I have proposed the following rewrite of that paragraph: The SET_PARAMETER and GET_PARAMETER request and response, and DESCRIBE response is by this specification defined that they MAY have a message body and its purpose. All 4xx and 5xx responses MAY also have a message body to carry additional response information. A message body MAY occur on any RTSP 2.0 request or response, but the content of the message body MAY be ignored. Extensions to this specification can specify the purpose and content of message bodies, including requireing their inclusion. > > s10.2, para 6 and following note: I can't see that the note following > para 6 can be justified: since the restriction on multiple connections > from a client to a server is only a SHOULD, an interoperable server MUST > be capable of handling multiple connections from a client unless the > server can explicitly send back a TOO MANY CONNECTIONS status. See separate email > > s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... > should these be carried over into RTSP? The IANA registry says they are. I am uncertain what you want here? Yes, the URI format allows for future definitions of literal IP address versions. However, RTSP does contain explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP versions will require some extension definition to function. > s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED > here are usually MANDATORY. (Also applies to wait timer in last para of > this section). Yes, I agree that they usually are. I personally have no issues making them required. I think the Recommended formulation is really one of these cases, do this or something even better or you will hang yourself to be a bit blunt. But, if I understand you, you think this paragraph should read: An RTSP server or proxy in an overload situation must select the value of the Retry-After header carefully and bearing in mind its current load situation. It is REQUIRED to increase the timeout period in proportion to the current load on the server, i.e., an increasing workload should result in an increased length of the indicated unavailability. It is REQUIRED to not send the same value in the Retry-After header to all requesting proxies and clients, but to add a variation to the mean value of the Retry-After header. Objections to this? > > s10.7, last para: Should the doubling of the wait timer have an upper limit? Yes, I added an upper limit of 30 minutes. This is way beyond what any human will accept, only robots will keep on going at this timeout value. And I think that is large enough to avoid any issues. I also propose to clarify the range for the variations and added the classical 0.5 to 1.5 times the deterministic value. Text proposal. That timer MUST be doubled for each additional failure to connect or receive response until the value exceeds 30 minutes when the timers deterministic value may be set to 30 minutes. It is RECOMMENDED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. > > s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed > are 'defined' in this draft. The nearest thing to a definition of > play.basic that I can find is the last sentence of para 4 in this > section. I am not convinced that I could produce an interoperable > implementation of a server with this feature-tag with the one sentence > 'definition'. References to where play.xxx are defined would be useful > (play.scale in s18.44, play.speed in s18.48). > Hmmm, the other feature-tags than play.basic are pretty straightforward and well contained. play-basic is really a minimal RTSP server implementation according to the whole spec for media playback. This can probably be more clearly expressed somewhere, but it can't really be enumerated. Then we are back to the issue we had with RFC 2326 minimal implementation list that was incomplete and lacked a lot of things really necessary. This issue still haven't resulted in any changes to our source. > s11, Supported (and Proxy-Supported) bullets: > OLD: > This results in the > receiver is learning the requester's feature support. > NEW: > This results in the > receiver learning the requester's feature support > relevant to the specified resource. > [Note: I added 'specified resource' here and then thought about whether > this made any sense. It probably needs to be clearer what set of > features are included in the Supported list for both requester and > responder. Are they restricted to those relevant to the specified > resource that might of course be the whole server, proxy - or client?? - > in which case there isn't an issue, but it might be a specific > presentation - what happens then? Affects s13.1, para 3 also.] Actually, I don't think it is specific to the media resource. The issue with making it specific to a media resource is that a RTSP client needs to be able to look into the future and supply an answer for a media resource it may not yet know sufficient to provide a tailored response for. I think it is simpler and better to provide general capabilities in the supported header and then later determine how well they apply for the media resource itself. We do have Media-Properties header to provide more details for what specific media transformations a server can do when the support play.scale. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pkyzivat@alum.mit.edu Mon Jun 24 08:41:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1171821E811B for ; Mon, 24 Jun 2013 08:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey-HjqCcLC45 for ; Mon, 24 Jun 2013 08:41:08 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 930E921E8118 for ; Mon, 24 Jun 2013 08:41:07 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta07.westchester.pa.mail.comcast.net with comcast id sErb1l0011wpRvQ57Fh71V; Mon, 24 Jun 2013 15:41:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id sFh61l00m3ZTu2S3eFh6d1; Mon, 24 Jun 2013 15:41:07 +0000 Message-ID: <51C86891.5090203@alum.mit.edu> Date: Mon, 24 Jun 2013 11:41:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Perkins References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se> <27108551-D2EC-4A45-8EE6-07053873F61D@csperkins.org> In-Reply-To: <27108551-D2EC-4A45-8EE6-07053873F61D@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372088467; bh=IkpJs/0v4Z6IuaFfj7GLVA1lh6wn4JnYgefPWRvhjx0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EqJh1KkjvNhkxk6mwMeNbPMRMjT9+hdcZI27KM0oZQChp9DCZHzURfEkCzKRzWue0 7roq3CkPukYFNIqBVqyestqNkVLClc/add8ufGtle094EAQYencI8nSNRsA8E3WJcs v5AwiM3NokYyMypItjJNKtlCU5hOYVpDJnEI+Ncj8JH6eOvpT8z9Zu3lEYtZoMvWFQ jltM2oVkcvXurxzNOgYf+V7/hGdJagvcTDzgVFk+7pulLOgCMOT0ViwxKKlpG6IwvQ f5XY6uJm88CZHrAtg2W2E1ukIsI63K5Tib/C/YWj7E/d8oAWl4Zta32tj4PgbDWawS JDeWizvhcEGCg== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 15:41:14 -0000 I'll support both Q1 and Q2. Thanks, Paul On 6/24/13 8:01 AM, Colin Perkins wrote: > On 24 Jun 2013, at 12:55, Christer Holmberg wrote: >>> Christer, >>> >>> For Q1 - I agree. >>> >>> For Q2 - I agree that we need explicit text somewhere. >>> >>> We might also add an explicit statement that it's okay to use the same PT for the exact same codec confirmation in multiple m= lines, _provided_ you don't want to use the PT values to associate packets with m= lines. >> >> I left that question out on purpose, because I intend to ask it separately :) > > > In that case, I agree with Q1 and Q2 :-) > From mary.ietf.barnes@gmail.com Mon Jun 24 10:10:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AB321E813E for ; Mon, 24 Jun 2013 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n32GeLy+YH3o for ; Mon, 24 Jun 2013 10:10:45 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0052121E812A for ; Mon, 24 Jun 2013 10:10:35 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id l18so2397824qak.9 for ; Mon, 24 Jun 2013 10:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=voF3aGfdRx6q+BVQlAEfK1dvocQc6RCozru9vbsH9U8=; b=LCR5aBIZy+pa390ZL3I3xn5TTdOFDaQ1v1TDwx02KtBVICqzp2v5NxWlI0outpaaui mrVTpwyN45QN8De567cO7HfwYLvTTXF6K4cVFdpMGEhzLbv4lXaiUk2X9vXBUbJI0ZLC 8+OGOOBG3j+dXJy+8BgGWl3WQeUphWb8bREGeLoo8HnZxJE1fQ7q6N9XkTYt/LGzofga h3VFDOpyNBcI3MNsBCjjdQyr+bvAngp1VYr2Iyp2JCxTqeI/cP/aMokAImgkCNhUos/J BYev4nVfy2oWoDZMivYe9v+vtB7oh+ogtMWSh2WArEooDRYSTsnTfp4FeQIl16chcuX3 5BDA== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr27703825qaj.13.1372093832176; Mon, 24 Jun 2013 10:10:32 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 24 Jun 2013 10:10:32 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> Date: Mon, 24 Jun 2013 12:10:32 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 17:10:46 -0000 I too agree with Q1 and Q2. Mary. On Mon, Jun 24, 2013 at 5:40 AM, Christer Holmberg wrote: > > Hi, > > Based on the input and discussion, let's see if we can make a couple of d= ecisions :) > > > Q1: Can we agree that, within a BUNDLE group (including all m- lines asso= ciated with the group), any given PT value can only be used for a single co= dec configuration? > > NOTE: If you think we need some clarification text on what "codec configu= ration" means, or if you think we should use some other wording - feel free= to suggest :) > > > > Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, = as there are opinions that simply referencing RFC 3550 might not be clear e= nough? > > > Regards, > > Christer > > > > > > > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: 20. kes=E4kuuta 2013 17:33 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) > > On 6/20/13 8:37 AM, Colin Perkins wrote: >> On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>>>> Using 96 for both Opus and VP8 is flat out illegal according to the R= TP specs. >>>> >>>> Agree. >>> >>> So, we DO agree that the usage of the *same* PT value (even if in diffe= rent m=3D lines) for different codecs, or different codec configurations, i= s not allowed. >>> >>> Is there some specific section in some specific RFC that can be referen= ced to show that? >> >> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is d= efined per RTP profile (i.e., for RTP/AVP and profiles derived from it). Th= e BUNDLE defines a single RTP session, which operates under a single RTP pr= ofile, so must have a single mapping from Payload Type to Payload Formats. = RFC 3551 section 3 says: >> >> ... >> mechanisms for defining dynamic payload type bindings have been >> specified in the Session Description Protocol (SDP) and in other >> protocols such as ITU-T Recommendation H.323/H.245. These mechanism= s >> associate the registered name of the encoding/payload format, along >> with any additional required parameters, such as the RTP timestamp >> clock rate and number of channels, with a payload type number. This >> association is effective only for the duration of the RTP session in >> which the dynamic payload type binding is made. This association >> applies only to the RTP session for which it is made, thus the >> numbers can be re-used for different encodings in different sessions >> so the number space limitation is avoided. >> >> You'll note that the association is per RTP session, not per SSRC or oth= er subset of the session. > > I'm not inclined to argue the details of RTP with an RTP expert! > But just wearing my standards-lawyer hat I read all of the above referenc= es, and could not find anything that clearly justified the assertions you m= ake. I read them as clearly stating that the *static* ones are defined for = a profile. I guess the key part of the quote above > is: "This association is effective only for the duration of the RTP sessi= on". That seems to *bound* the scope of the association, but doesn't explic= itly state that it must be unique within that scope. > > But maybe that is just a matter of me not reading it right, or of the tex= t not having captured every nuance of the intent. > >> If you're looking for a statement that two m=3D lines in an SDP can't ma= p the same PT value to different things, you're unlikely to find it, since = pre-BUNDLE those two m=3D lines would refer to different RTP sessions, so i= t would be legal to reuse PT values across m=3D lines. It's because BUNDLE = makes a single RTP session out of several m=3D lines that you need unique P= T mapping across all the m=3D lines. > > Of course. So I think that means its important for bundle to clearly stat= e the requirement, if it is to be a real one. > > Thanks, > Paul > >> Colin >> >> >>>>> The corner case where we're discussing whether one can use the same >>>>> payload type is if you have two M-lines that both specify VP8, with t= he same codec parameters - whether they can both use 96, given that it's th= e same codec. >>>> >>>> Surely yes, but you lose the ability to distinguish the m=3D line >>>> based on the PT if you use the same PT (mapped to the exact same >>>> codec and set of codec parameters) in several m=3D lines. Some applica= tions care about distinguishing m=3D lines based on PT values, and so need = distinct PT values for every m=3D line; others don't care, and can use the = same PT to represent the same codec across multiple m=3D lines. >>> >>> Exactly. So, I think it's a good idea to have some text about that in B= UNDLE. >>> >>> Regards, >>> >>> Christer >>> >> >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Mon Jun 24 10:11:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0A411E8169 for ; Mon, 24 Jun 2013 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpcCaUY+GicA for ; Mon, 24 Jun 2013 10:11:24 -0700 (PDT) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7EF11E8163 for ; Mon, 24 Jun 2013 10:11:24 -0700 (PDT) Received: from BLU169-W106 ([65.55.116.72]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jun 2013 10:11:23 -0700 X-TMN: [OxxfWOVD+ERM9e26wqPZQIquhvZAUZfE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1ba4e55d-314c-4b72-b8f2-e5c65c16c9e6_" From: Bernard Aboba To: Paul Kyzivat , Colin Perkins Date: Mon, 24 Jun 2013 10:11:23 -0700 Importance: Normal In-Reply-To: <51C86891.5090203@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se>, <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se>, <27108551-D2EC-4A45-8EE6-07053873F61D@csperkins.org>, <51C86891.5090203@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jun 2013 17:11:23.0982 (UTC) FILETIME=[DAC6C6E0:01CE70FD] Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 17:11:30 -0000 --_1ba4e55d-314c-4b72-b8f2-e5c65c16c9e6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with this - support both Q1 and the (reformulated) Q2. =20 =20 > Date: Mon=2C 24 Jun 2013 11:41:05 -0400 > From: pkyzivat@alum.mit.edu > To: csp@csperkins.org > CC: mmusic@ietf.org=3B christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mappi= ng in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] >=20 > I'll support both Q1 and Q2. >=20 > Thanks=2C > Paul >=20 > On 6/24/13 8:01 AM=2C Colin Perkins wrote: > > On 24 Jun 2013=2C at 12:55=2C Christer Holmberg wrote: > >>> Christer=2C > >>> > >>> For Q1 - I agree. > >>> > >>> For Q2 - I agree that we need explicit text somewhere. = --_1ba4e55d-314c-4b72-b8f2-e5c65c16c9e6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with this - support both= Q1 and the (reformulated) Q2.  =3B
 =3B
>=3B Date: Mo= n=2C 24 Jun 2013 11:41:05 -0400
>=3B From: pkyzivat@alum.mit.edu
&g= t=3B To: csp@csperkins.org
>=3B CC: mmusic@ietf.org=3B christer.holmbe= rg@ericsson.com
>=3B Subject: Re: [MMUSIC] DECISION: Unique PT value/c= odec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux proc= edures (June 19th)]
>=3B
>=3B I'll support both Q1 and Q2.
&g= t=3B
>=3B Thanks=2C
>=3B Paul
>=3B
>=3B On 6/24/13 = 8:01 AM=2C Colin Perkins wrote:
>=3B >=3B On 24 Jun 2013=2C at 12:55= =2C Christer Holmberg wrote:
>=3B >=3B>=3B>=3B Christer=2C
&g= t=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B For Q1 - I agree.
&= gt=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B For Q2 - I agree that= we need explicit text somewhere.
= --_1ba4e55d-314c-4b72-b8f2-e5c65c16c9e6_-- From emcho@sip-communicator.org Mon Jun 24 10:11:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2180621E8154 for ; Mon, 24 Jun 2013 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBCEgWcCgdOw for ; Mon, 24 Jun 2013 10:11:33 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E565321E813E for ; Mon, 24 Jun 2013 10:11:32 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so570786pdj.17 for ; Mon, 24 Jun 2013 10:11:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=/oM9dpVTzG/RjHN4IyGnzfU0MO2n+URevYjEZ6t37iQ=; b=ggnO410ER63uuhSutwDuGeZrPq005n66Dg38WzVZqUQRMQHXxBKskzYh1fEpc/IHG3 kYO7NnClHp970zdB5Gm9291dFRPQMe4LRwtjgd32Hyaot4NQ0I2gpshC/X+ahaIZrpXK wQhb6Wss0xJ+a2Z64Q62R9TdK3MEpjo94mteYy2XntjmJR2qnzAtxX4Ip4GGh5a5d/2J iavAmRtQVS0DJ2JmLCl5VEfCk41kAQ/vG+c8y1RHmpbi7HWdw+28M8PKaNISEsmNto8I h4UZchub5FX6vsfdnMcB1UCrnSUBLXrCmrt8jURMw5cwbuCurbzB75l0nZAIKOZmfzvN J5bw== X-Received: by 10.66.190.164 with SMTP id gr4mr27800862pac.215.1372093892573; Mon, 24 Jun 2013 10:11:32 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [2607:f8b0:400e:c02::235]) by mx.google.com with ESMTPSA id xl3sm19004635pbb.17.2013.06.24.10.11.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 10:11:32 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so569468pdj.12 for ; Mon, 24 Jun 2013 10:11:31 -0700 (PDT) X-Received: by 10.68.217.170 with SMTP id oz10mr5908311pbc.152.1372093891887; Mon, 24 Jun 2013 10:11:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.122.130 with HTTP; Mon, 24 Jun 2013 10:11:10 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> From: Emil Ivov Date: Mon, 24 Jun 2013 19:11:10 +0200 Message-ID: To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2+RI16WAEMkMCbHTMYqCW2yUx0QFLWiUCA99d0OWp+IkaHa57mKKMap1EXtlIPjw+QuDG Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 17:11:34 -0000 +1 Emil On Mon, Jun 24, 2013 at 7:10 PM, Mary Barnes w= rote: > I too agree with Q1 and Q2. > > Mary. > > On Mon, Jun 24, 2013 at 5:40 AM, Christer Holmberg > wrote: >> >> Hi, >> >> Based on the input and discussion, let's see if we can make a couple of = decisions :) >> >> >> Q1: Can we agree that, within a BUNDLE group (including all m- lines ass= ociated with the group), any given PT value can only be used for a single c= odec configuration? >> >> NOTE: If you think we need some clarification text on what "codec config= uration" means, or if you think we should use some other wording - feel fre= e to suggest :) >> >> >> >> Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE,= as there are opinions that simply referencing RFC 3550 might not be clear = enough? >> >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Paul Kyzivat >> Sent: 20. kes=E4kuuta 2013 17:33 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) >> >> On 6/20/13 8:37 AM, Colin Perkins wrote: >>> On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>>>>> Using 96 for both Opus and VP8 is flat out illegal according to the = RTP specs. >>>>> >>>>> Agree. >>>> >>>> So, we DO agree that the usage of the *same* PT value (even if in diff= erent m=3D lines) for different codecs, or different codec configurations, = is not allowed. >>>> >>>> Is there some specific section in some specific RFC that can be refere= nced to show that? >>> >>> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is = defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). T= he BUNDLE defines a single RTP session, which operates under a single RTP p= rofile, so must have a single mapping from Payload Type to Payload Formats.= RFC 3551 section 3 says: >>> >>> ... >>> mechanisms for defining dynamic payload type bindings have been >>> specified in the Session Description Protocol (SDP) and in other >>> protocols such as ITU-T Recommendation H.323/H.245. These mechanis= ms >>> associate the registered name of the encoding/payload format, along >>> with any additional required parameters, such as the RTP timestamp >>> clock rate and number of channels, with a payload type number. Thi= s >>> association is effective only for the duration of the RTP session i= n >>> which the dynamic payload type binding is made. This association >>> applies only to the RTP session for which it is made, thus the >>> numbers can be re-used for different encodings in different session= s >>> so the number space limitation is avoided. >>> >>> You'll note that the association is per RTP session, not per SSRC or ot= her subset of the session. >> >> I'm not inclined to argue the details of RTP with an RTP expert! >> But just wearing my standards-lawyer hat I read all of the above referen= ces, and could not find anything that clearly justified the assertions you = make. I read them as clearly stating that the *static* ones are defined for= a profile. I guess the key part of the quote above >> is: "This association is effective only for the duration of the RTP sess= ion". That seems to *bound* the scope of the association, but doesn't expli= citly state that it must be unique within that scope. >> >> But maybe that is just a matter of me not reading it right, or of the te= xt not having captured every nuance of the intent. >> >>> If you're looking for a statement that two m=3D lines in an SDP can't m= ap the same PT value to different things, you're unlikely to find it, since= pre-BUNDLE those two m=3D lines would refer to different RTP sessions, so = it would be legal to reuse PT values across m=3D lines. It's because BUNDLE= makes a single RTP session out of several m=3D lines that you need unique = PT mapping across all the m=3D lines. >> >> Of course. So I think that means its important for bundle to clearly sta= te the requirement, if it is to be a real one. >> >> Thanks, >> Paul >> >>> Colin >>> >>> >>>>>> The corner case where we're discussing whether one can use the same >>>>>> payload type is if you have two M-lines that both specify VP8, with = the same codec parameters - whether they can both use 96, given that it's t= he same codec. >>>>> >>>>> Surely yes, but you lose the ability to distinguish the m=3D line >>>>> based on the PT if you use the same PT (mapped to the exact same >>>>> codec and set of codec parameters) in several m=3D lines. Some applic= ations care about distinguishing m=3D lines based on PT values, and so need= distinct PT values for every m=3D line; others don't care, and can use the= same PT to represent the same codec across multiple m=3D lines. >>>> >>>> Exactly. So, I think it's a good idea to have some text about that in = BUNDLE. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>> >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 https://jitsi.org FAX: +33.1.77.62.47.31 From christer.holmberg@ericsson.com Mon Jun 24 11:43:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEA511E8174 for ; Mon, 24 Jun 2013 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUqLwrrU9gan for ; Mon, 24 Jun 2013 11:43:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 811A111E8164 for ; Mon, 24 Jun 2013 11:43:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-9d-51c8933b5318 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C0.88.18006.B3398C15; Mon, 24 Jun 2013 20:43:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 20:43:07 +0200 From: Christer Holmberg To: Bernard Aboba , Paul Kyzivat , Colin Perkins Thread-Topic: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] Thread-Index: Ac5wx08/TAURHL5TRnSJwZ3ZRjxyOQAAFz+A///v9oD//9wroIAAKCgAgAA9UYCAABk6gP//xcng Date: Mon, 24 Jun 2013 18:43:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B97B2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se>, <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se>, <27108551-D2EC-4A45-8EE6-07053873F61D@csperkins.org>, <51C86891.5090203@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3B97B2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvra7N5BOBBts7WCz2L7nMbLH85QlG i6nLH7NYrNhwgNWBxePv+w9MHtPu32fzeNxzhs1jyZKfTAEsUVw2Kak5mWWpRfp2CVwZfz5s YSrodKo483EGUwPjJ6suRk4OCQETiTuXPjJD2GISF+6tZ+ti5OIQEjjMKLFm+RJWCGcRo8Tf c8uAMhwcbAIWEt3/tEFMEYEKiZn7uEBMZgF1iauLg0CqhQUmMkp8uvwNrFVEYBKjxI2dO1lA FogIREmcmXKIHcRmEVCVONv7CizOK+ArsXbbFFYQW0igh1mi514kiM0pYC2xfvpBsDgj0HHf T61hArGZBcQlPhy8DnW0gMSSPeehbFGJl4//sULYShKNS56wQtTnS9x6OYUJYpegxMmZT1gm MIrOQjJqFpKyWUjKIOJ6EjemTmGDsLUlli18DVWvKzHj3yEWZPEFjOyrGNlzEzNz0suNNjEC Y+/glt+qOxjvnBM5xCjNwaIkzvvx1K5AIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwRfAKi 4VNmTQvc0Crbr+z14+GswxO4ZtUqWD6p2GXzNt+sYMfSLcoJf+90iM5SXaY6p2pHTNwZFgel 7ekT/L894VHj/rT57WMbRvOXh6fHdn/Jup5Zeulycvz+2tXMXzWsLs2cfvMun87kDUaS0ZMk okSDkqwOW04+7rvD/2fHvT419t86TbeVWIozEg21mIuKEwGrAXRaiwIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 18:43:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3B97B2ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernard, If I understood you correctly, your suggestion was to document the rule in = draft-ietf-avtcore-multiplex-guidelines. As the authors of that draft are most likely reading this, it would be nice= to get their input. Formally, of course, the work would have to be done in= AVTCORE. Regards, Christer L=E4hett=E4j=E4: Bernard Aboba [mailto:bernard_aboba@hotmail.com] L=E4hetetty: 24. kes=E4kuuta 2013 20:11 Vastaanottaja: Paul Kyzivat; Colin Perkins Kopio: mmusic@ietf.org; Christer Holmberg Aihe: RE: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in= a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] I agree with this - support both Q1 and the (reformulated) Q2. > Date: Mon, 24 Jun 2013 11:41:05 -0400 > From: pkyzivat@alum.mit.edu > To: csp@csperkins.org > CC: mmusic@ietf.org; christer.holmberg@ericsson.c= om > Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mappi= ng in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] > > I'll support both Q1 and Q2. > > Thanks, > Paul > > On 6/24/13 8:01 AM, Colin Perkins wrote: > > On 24 Jun 2013, at 12:55, Christer Holmberg wrote: > >>> Christer, > >>> > >>> For Q1 - I agree. > >>> > >>> For Q2 - I agree that we need explicit text somewhere. --_000_7594FB04B1934943A5C02806D1A2204B1C3B97B2ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bernard= ,

 = ;

If I under= stood you correctly, your suggestion was to document the rule in draft-ietf= -avtcore-multiplex-guidelines.

 = ;

As the aut= hors of that draft are most likely reading this, it would be nice to get th= eir input. Formally, of course, the work would have to be done in AVTCORE.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
L=E4hetetty: 24. kes=E4kuuta 2013 20:11
Vastaanottaja: Paul Kyzivat; Colin Perkins
Kopio: mmusic@ietf.org; Christer Holmberg
Aihe: RE: [MMUSIC] DECISION: Unique PT value/codec configuration map= ping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)]

 

I agree with this - support both Q1 and the (reformulate= d) Q2.  
 

> Date: Mon, 24 Jun 2013 11:41:05 -040= 0
> From: pkyzivat@alum.mit.edu
> To: csp@c= sperkins.org
> CC: mmusic@= ietf.org; c= hrister.holmberg@ericsson.com
> Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration ma= pping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] >
> I'll support both Q1 and Q2.
>
> Thanks,
> Paul
>
> On 6/24/13 8:01 AM, Colin Perkins wrote:
> > On 24 Jun 2013, at 12:55, Christer Holmberg wrote:
> >>> Christer,
> >>>
> >>> For Q1 - I agree.
> >>>
> >>> For Q2 - I agree that we need explicit text somewhere.

--_000_7594FB04B1934943A5C02806D1A2204B1C3B97B2ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Jun 25 04:16:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756FE11E80E8 for ; Tue, 25 Jun 2013 04:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.066 X-Spam-Level: X-Spam-Status: No, score=-4.066 tagged_above=-999 required=5 tests=[AWL=-1.468, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ap5Rhk1QOV8 for ; Tue, 25 Jun 2013 04:16:14 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9758921E8090 for ; Tue, 25 Jun 2013 04:16:12 -0700 (PDT) X-AuditID: c1b4fb38-b7f476d0000049c9-51-51c97bfbbea7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B6.13.18889.BFB79C15; Tue, 25 Jun 2013 13:16:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 13:16:10 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NA== Date: Tue, 25 Jun 2013 11:16:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BA9EFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre7v6pOBBk9WS1pMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXun32cumKZYcWHeLeYGxv0yXYycHBICJhLTt61jhbDFJC7c W88GYgsJHGWUOHlBsIuRC8hexCixqOcjexcjBwebgIVE9z9tkBoRAXWJr3t7mEFsYYEwidPt /WwQ8WiJ3tXTWUDKRQT0JO6vKwMJswioSkzuX8oOYvMK+Ep8fX8KrJURaO33U2uYQGxmAXGJ W0/mM0GcIyCxZM95ZghbVOLl439QZypKtD9tYISoz5c4f+cVI8RMQYmTM5+wTGAUmoVk1Cwk ZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBzFqcVJuelGBpsYgUF/cMtvix2M l//aHGKU5mBREuf9dGpXoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGU32LNf/dtHrj6hQS emZyxCFtvhlbVJhbVzdPZ+GMX5pvsUjkWrJQuKNZTvbXjsZ96VfUuu23ezz4nsDcFRrp7qx+ PnTurJqjJv8/ZCgEhQu/3271xuurgo2q4jXOb742D5R4bqh0PXscc95R5WCYPPuExdPWrwoT zpZmULpzpyCga06A/mQlluKMREMt5qLiRAD2btN4SAIAAA== Subject: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:16:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BA9EFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There has been some discussions about whether BUNDLE should mandate that us= ers are mandated to always (no matter what transport protocols are used in = the BUNDLE group) have a mechanism to map received data to an m- line, or w= hether it from a generic BUNDLE perspective should be optional - IF there w= ould be cases where it's not needed. We haven't had that much discussion about it yet, so I will not ask a DECIS= ION question at this point, but I would really like to get some input from = people who have opinions about this :) Note that this issue is NOT about HOW to map data to m- lines (there will b= e a separate question about how to map RTP to m- lines etc), or whether we = should allow usage of the same PT value (for the same codec configuration) = in multiple m- lines, but more about a general rule. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BA9EFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There has been some discussions about whether BUNDLE= should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE gr= oup) have a mechanism to map received data to an m- line, or whether it fro= m a generic BUNDLE perspective should be optional – IF there would be= cases where it’s not needed.

 

We haven’t had that much discussion about it y= et, so I will not ask a DECISION question at this point, but I would really= like to get some input from people who have opinions about this :)

 

Note that this issue is NOT about HOW to map data to= m- lines (there will be a separate question about how to map RTP to m- lin= es etc), or whether we should allow usage of the same PT value (for the sam= e codec configuration) in multiple m- lines, but more about a general rule.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3BA9EFESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Jun 25 04:34:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998BD21F9F80 for ; Tue, 25 Jun 2013 04:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0XSdCMLAvA9 for ; Tue, 25 Jun 2013 04:34:12 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A28C321F9F4E for ; Tue, 25 Jun 2013 04:34:11 -0700 (PDT) X-AuditID: c1b4fb25-b7f0a6d000005db8-d2-51c98032911d Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A0.94.23992.23089C15; Tue, 25 Jun 2013 13:34:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 13:34:09 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0Ngw== Date: Tue, 25 Jun 2013 11:34:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BAA2FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvra5Rw8lAgyWXpC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAlXnrIULFOtmL3ep4FxgkIXIyeHhICJxL9v+9ghbDGJC/fW s3UxcnEICRxmlJj3FMThBHIWMUosXOzdxcjBwSZgIdH9TxskLCKgLvF1bw8zSFhYIFBiWl8R RDhMYs2G14wQtp7ExW8drCA2i4CqxJpHr5hBbF4BX4m/7yYwgdiMQGu/n1oDZjMLiEvcejKf CeIcAYkle84zQ9iiEi8f/2OFsBUl2p82MELU50v8uPqDDWKmoMTJmU9YJjAKzUIyahaSsllI yiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HKjTYzAgD+45bfqDsY750QO MUpzsCiJ8348tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PukcXx/364Fe9UvLpvr8Ry y2KmZkfFKHZdozXptU+3JW9RXfL37pLi7StiMwW1pa4kqWx/eviRap29bumirKoHExN7Zywv Vqg92Z+4uXmK+fyOclmLDIM/WqoJFRn+YlE6m079YXG2WOqlFfo+UuTry4qoQ+dzfH63Xguq ORkjwtjgL9NhrcRSnJFoqMVcVJwIAKXgJfRGAgAA Subject: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:34:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BAA2FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Emil suggested that the default, "MTI", mechanism for mapping RTP data to m= - lines should be based on PT. Applications are allowed to use whatever oth= er mechanisms, but usage of such mechanisms must be negotiated (or, applica= tions need to have some other means knowing that the other endpoint support= such mechanisms). Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to= m- lines? Q4: If Q3, do we mandate applications to support, and use (unless applicati= ons are made aware of other mechanisms supported by all endpoints) PT for m= apping received RTP media? This means that, when mapping RTP to m- lines is required (whether it is al= ways mandated is discussed in another thread), within a BUNDLE group each P= T value must be unique to an individual m- line. NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no", please = indicate which mechanism you prefer :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BAA2FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Emil suggested that the default, “MTI”, = mechanism for mapping RTP data to m- lines should be based on PT. Applicati= ons are allowed to use whatever other mechanisms, but usage of such mechani= sms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mech= anisms).

 

Q3: Do we need to specify a default, MTI, mec= hanism for mapping RTP data to m- lines?

 

Q4: If Q3, do we mandate applications to supp= ort, and use (unless applications are made aware of other mechanisms suppor= ted by all endpoints) PT for mapping received RTP media?

 

This means that, when mapping RTP to m- lines is req= uired (whether it is always mandated is discussed in another thread), withi= n a BUNDLE group each PT value must be unique to an individual m- line.

 

NOTE: If your answer to Q3 is “yes”, but= your answer to Q4 is “no”, please indicate which mechanism you= prefer J

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3BAA2FESESSMB209erics_-- From harald@alvestrand.no Tue Jun 25 04:37:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C9E21F9CBB for ; Tue, 25 Jun 2013 04:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuBCOhU6brA6 for ; Tue, 25 Jun 2013 04:37:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4BD21F8FE5 for ; Tue, 25 Jun 2013 04:37:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A15739E176 for ; Tue, 25 Jun 2013 13:37:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIZBHqTaU1KD for ; Tue, 25 Jun 2013 13:37:08 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C9E6E39E0D7 for ; Tue, 25 Jun 2013 13:37:08 +0200 (CEST) Message-ID: <51C980F9.1090501@alvestrand.no> Date: Tue, 25 Jun 2013 13:37:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:37:16 -0000 On 06/24/2013 12:40 PM, Christer Holmberg wrote: > Hi, > > Based on the input and discussion, let's see if we can make a couple of decisions :) > > > Q1: Can we agree that, within a BUNDLE group (including all m- lines associated with the group), any given PT value can only be used for a single codec configuration? Yes, I agree with Q1. > > NOTE: If you think we need some clarification text on what "codec configuration" means, or if you think we should use some other wording - feel free to suggest :) I believe "codec configuration" should be defined as the content of the a=rtpmap and a=fmtp lines, since those are the lines that are defined in payload registrations. I think it's uncontroversial to declare those two items as part of codec configuration. It's far less clear that there are other uncontroversial items. > > > > Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, as there are opinions that simply referencing RFC 3550 might not be clear enough? Explicit text is better. If it is informative explicit text that points to normative explicit text elsewhere, that's fine too - but some text should be in BUNDLE, and be explicit. > > > Regards, > > Christer > > > > > > > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 20. kesäkuuta 2013 17:33 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) > > On 6/20/13 8:37 AM, Colin Perkins wrote: >> On 20 Jun 2013, at 05:53, Christer Holmberg wrote: >>>>> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs. >>>> Agree. >>> So, we DO agree that the usage of the *same* PT value (even if in different m= lines) for different codecs, or different codec configurations, is not allowed. >>> >>> Is there some specific section in some specific RFC that can be referenced to show that? >> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The BUNDLE defines a single RTP session, which operates under a single RTP profile, so must have a single mapping from Payload Type to Payload Formats. RFC 3551 section 3 says: >> >> ... >> mechanisms for defining dynamic payload type bindings have been >> specified in the Session Description Protocol (SDP) and in other >> protocols such as ITU-T Recommendation H.323/H.245. These mechanisms >> associate the registered name of the encoding/payload format, along >> with any additional required parameters, such as the RTP timestamp >> clock rate and number of channels, with a payload type number. This >> association is effective only for the duration of the RTP session in >> which the dynamic payload type binding is made. This association >> applies only to the RTP session for which it is made, thus the >> numbers can be re-used for different encodings in different sessions >> so the number space limitation is avoided. >> >> You'll note that the association is per RTP session, not per SSRC or other subset of the session. > I'm not inclined to argue the details of RTP with an RTP expert! > But just wearing my standards-lawyer hat I read all of the above references, and could not find anything that clearly justified the assertions you make. I read them as clearly stating that the *static* ones are defined for a profile. I guess the key part of the quote above > is: "This association is effective only for the duration of the RTP session". That seems to *bound* the scope of the association, but doesn't explicitly state that it must be unique within that scope. > > But maybe that is just a matter of me not reading it right, or of the text not having captured every nuance of the intent. > >> If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to different RTP sessions, so it would be legal to reuse PT values across m= lines. It's because BUNDLE makes a single RTP session out of several m= lines that you need unique PT mapping across all the m= lines. > Of course. So I think that means its important for bundle to clearly state the requirement, if it is to be a real one. > > Thanks, > Paul > >> Colin >> >> >>>>> The corner case where we're discussing whether one can use the same >>>>> payload type is if you have two M-lines that both specify VP8, with the same codec parameters - whether they can both use 96, given that it's the same codec. >>>> Surely yes, but you lose the ability to distinguish the m= line >>>> based on the PT if you use the same PT (mapped to the exact same >>>> codec and set of codec parameters) in several m= lines. Some applications care about distinguishing m= lines based on PT values, and so need distinct PT values for every m= line; others don't care, and can use the same PT to represent the same codec across multiple m= lines. >>> Exactly. So, I think it's a good idea to have some text about that in BUNDLE. >>> >>> Regards, >>> >>> Christer >>> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From tireddy@cisco.com Tue Jun 25 05:41:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A3521F99DC for ; Tue, 25 Jun 2013 05:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v8GBjPKXbS4 for ; Tue, 25 Jun 2013 05:41:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C90F621F8B51 for ; Tue, 25 Jun 2013 05:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6241; q=dns/txt; s=iport; t=1372164107; x=1373373707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mdmfmv2CbYO1ldoWxxqG2UzMtjNzNXHFKHU1haQzGGs=; b=mvJAWMV4RHgea3FBAek26i1BHjH+5e2n3ZiljD0kzqNYfkfEPKgjsZJr a3ePbVI5BKPpG0uKQXh2ThffScylplqSpThHj5w3kD0iSATMxOed2Z5jo 3Qjr1MU5Siy6y66AK5tLNYPQyj8lQfbUiTCnb2auNiMoA3kZI6KPGuhtJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFALmPyVGtJXG8/2dsb2JhbABagwkxQwa/OYEBFnSCIwEBAQMBAQEBNzQJAgwEAgEIDgMEAQEBChQJBycLFAgBCAIEDgUIAYd/BgcFun6OHXcxBwaCfGEDk3GEe5AbgViBOIIo X-IronPort-AV: E=Sophos;i="4.87,936,1363132800"; d="scan'208";a="227220427" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jun 2013 12:41:46 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5PCfjbf022989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 12:41:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 07:41:45 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt Thread-Index: AQHOcK15+DWlJMUbHkqfCSOc2ALdLplEelaQgAC++QD//94/UA== Date: Tue, 25 Jun 2013 12:41:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B8D7A3@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14B8C943@xmb-rcd-x10.cisco.com> <51C85164.5080208@jitsi.org> In-Reply-To: <51C85164.5080208@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:41:52 -0000 Hi Emil, Thanks for the review. Please see inline > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Monday, June 24, 2013 7:32 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-= ice- > mobility-04.txt >=20 > Hey Tiru, >=20 > On 24.06.13, 15:06, Tirumaleswar Reddy (tireddy) wrote: > > Hi all, > > > > we have updated the draft based on the comments received during IETF > > 86 to compare MICE with ICE restart and Trickle ICE (Section 6 > > "Comparison to ICE Restart and Trickle ICE"). comments and > > suggestions are welcome. >=20 > Thanks for doing this. >=20 > A few comments on that comparison: >=20 > > 6.2. Break Before Make - Trickle ICE > > > > o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for RTP > > Mobility then in case of Break before Make, > > > > 1. Trickle ICE can begin connectivity checks while the endpoint > > is still gathering candidates and can considerably shorten the > > time necessary for ICE processing to complete. It still > > involves the overhead of step 1 explained in section > > Section 6.1. >=20 > The said overhead being SIP re-registration, I don't see how trickle-ice > and mice are in a different position here. Why would one be able to > restart attempts without it, while the other wouldn't ? Mobility using ICE will be started without waiting for SIP re-registration = to start (performed entirely in the media path). Please refer to the explan= ation in http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04#secti= on-3.1=20 >=20 > > 2. The endpoint would learn host candidates and inform them to > > the remote peer in offer, the remote peer will provide its > > candidates in answer. The host, server reflexive, peer > > reflexive and relayed candidates of the remote peer may not > > change and the remote peer does not have to gather the > > candidates again. Trickle ICE will test local host candidates > > with all types of remote candidates provided by the remote > > peer in the answer. If the ICE peer is behind NAT performing > > end-point independent mapping and filtering then ICE > > connectivity checks initiated by the endpoint to the remote > > peer will succeed. >=20 > Actually that's what you'd need the NAT to be without trickle ICE so > that break-before-make mice would succeed (which I've already expressed > as a concern with this draft). Yes, we have updated the draft about the concern you raised last time Section 3.1=20 ... Mobility using ICE could fail in case of Simultaneous Mobility or if the IC= E peer is behind NAT that performs Address-Dependent Filtering (see Section 5 of [RFC5245]).... And this concern could be addressed by either of the following techniques -= Section 3.2 "Keeping unused relayed candidates active" or Appendix=20 A.2.1. "Keeping unused candidates in the valid list active" >=20 > Using trickle ICE would allow you to succeed with endpoint dependent > filtering because the remote party would also start checks in your > direction. The problem in the above scenario is endpoint would just learn host candida= tes and inform them to the remote peer in offer, so if the endpoint is behi= nd endpoint independent filtering NAT and the remote peer is behind endpoin= t dependent filtering NAT (Let's say NAT X). The STUN connectivity checks s= ent by the endpoint will be blocked by X, STUN connectivity checks initiate= d by the remote peer will fail to reach the endpoint because it is behind N= AT. >=20 > I guess what I am trying to say is that it doesn't make sense for mice > not to use trickle ICE for this case. MICE can be used with Trickle ICE, we are only responding to comments in th= e last IETF asking for the benefits of MICE in comparison with ICE restart = and Trickle ICE. >=20 > > 3. Trickle ICE must be supported by both endpoints for it be > > used. >=20 > I am not sure I understand this argument. Any kind of mobility > management would have to be supported by both pears in order to be used. when only one endpoint supports MICE, TURN server can be used to provide mo= bility (Section 5 - "Mobility using TURN"). The endpoint will use local rel= ayed candidates for communicating with the remote peer. Even If endpoint ro= ams and gets a new IP address, it will continue to reach the remote peer us= ing the local relayed candidates as explained in section 5 (using the MOBIL= ITY-TICKET). The remote peer will not even be aware that the endpoint IP ad= dress has changed. Regards, --Tiru.=20 >=20 > Cheers, > Emil >=20 >=20 >=20 > > > > Best Regards, --Authors. > > > > -----Original Message----- From: internet-drafts@ietf.org > > [mailto:internet-drafts@ietf.org] Sent: Monday, June 24, 2013 1:06 > > PM To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Dan > > Wing (dwing); Pal Martinsen (palmarti) Subject: New Version > > Notification for draft-wing-mmusic-ice-mobility-04.txt > > > > > > A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt has been > > successfully submitted by Dan Wing and posted to the IETF > > repository. > > > > Filename: draft-wing-mmusic-ice-mobility Revision: 04 Title: > > Mobility with ICE (MICE) Creation date: 2013-06-24 Group: > > Individual Submission Number of pages: 19 URL: > > http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-04.t= xt > > > > > Status: > http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility > > Htmlized: > > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04 Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-ice-mobility-04 > > > > Abstract: This specification describes how endpoint mobility can be > > achieved using ICE. Two mechanisms are shown, one where both > > endpoints support ICE and another where only one endpoint supports > > ICE. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ mmusic mailing list > > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > -- > https://jitsi.org From andrew.hutton@siemens-enterprise.com Tue Jun 25 05:45:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB421F9A8F for ; Tue, 25 Jun 2013 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4UoibC9Brtl for ; Tue, 25 Jun 2013 05:45:26 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5182821F9CEB for ; Tue, 25 Jun 2013 05:45:26 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 472101EB8546; Tue, 25 Jun 2013 14:45:23 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 14:45:23 +0200 From: "Hutton, Andrew" To: Emil Ivov , Mary Barnes Thread-Topic: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] Thread-Index: Ac5wx08/TAURHL5TRnSJwZ3ZRjxyOQAJakAAAAAFqgAALS79IA== Date: Tue, 25 Jun 2013 12:45:22 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D8197@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@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: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:45:30 -0000 +1 Andy > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: 24 June 2013 18:11 > To: Mary Barnes > Cc: mmusic@ietf.org; Paul Kyzivat; Christer Holmberg > Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration > mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June > 19th)] >=20 > +1 >=20 > Emil >=20 > On Mon, Jun 24, 2013 at 7:10 PM, Mary Barnes > wrote: > > I too agree with Q1 and Q2. > > > > Mary. > > > > On Mon, Jun 24, 2013 at 5:40 AM, Christer Holmberg > > wrote: > >> > >> Hi, > >> > >> Based on the input and discussion, let's see if we can make a couple > of decisions :) > >> > >> > >> Q1: Can we agree that, within a BUNDLE group (including all m- lines > associated with the group), any given PT value can only be used for a > single codec configuration? > >> > >> NOTE: If you think we need some clarification text on what "codec > configuration" means, or if you think we should use some other wording > - feel free to suggest :) > >> > >> > >> > >> Q2: If we agree on Q1, do we agree that we need EXPLICIT text in > BUNDLE, as there are opinions that simply referencing RFC 3550 might > not be clear enough? > >> > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > >> Sent: 20. kes=E4kuuta 2013 17:33 > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th) > >> > >> On 6/20/13 8:37 AM, Colin Perkins wrote: > >>> On 20 Jun 2013, at 05:53, Christer Holmberg wrote: > >>>>>> Using 96 for both Opus and VP8 is flat out illegal according to > the RTP specs. > >>>>> > >>>>> Agree. > >>>> > >>>> So, we DO agree that the usage of the *same* PT value (even if in > different m=3D lines) for different codecs, or different codec > configurations, is not allowed. > >>>> > >>>> Is there some specific section in some specific RFC that can be > referenced to show that? > >>> > >>> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping > is defined per RTP profile (i.e., for RTP/AVP and profiles derived from > it). The BUNDLE defines a single RTP session, which operates under a > single RTP profile, so must have a single mapping from Payload Type to > Payload Formats. RFC 3551 section 3 says: > >>> > >>> ... > >>> mechanisms for defining dynamic payload type bindings have been > >>> specified in the Session Description Protocol (SDP) and in > other > >>> protocols such as ITU-T Recommendation H.323/H.245. These > mechanisms > >>> associate the registered name of the encoding/payload format, > along > >>> with any additional required parameters, such as the RTP > timestamp > >>> clock rate and number of channels, with a payload type number. > This > >>> association is effective only for the duration of the RTP > session in > >>> which the dynamic payload type binding is made. This > association > >>> applies only to the RTP session for which it is made, thus the > >>> numbers can be re-used for different encodings in different > sessions > >>> so the number space limitation is avoided. > >>> > >>> You'll note that the association is per RTP session, not per SSRC > or other subset of the session. > >> > >> I'm not inclined to argue the details of RTP with an RTP expert! > >> But just wearing my standards-lawyer hat I read all of the above > references, and could not find anything that clearly justified the > assertions you make. I read them as clearly stating that the *static* > ones are defined for a profile. I guess the key part of the quote above > >> is: "This association is effective only for the duration of the RTP > session". That seems to *bound* the scope of the association, but > doesn't explicitly state that it must be unique within that scope. > >> > >> But maybe that is just a matter of me not reading it right, or of > the text not having captured every nuance of the intent. > >> > >>> If you're looking for a statement that two m=3D lines in an SDP can't > map the same PT value to different things, you're unlikely to find it, > since pre-BUNDLE those two m=3D lines would refer to different RTP > sessions, so it would be legal to reuse PT values across m=3D lines. It's > because BUNDLE makes a single RTP session out of several m=3D lines that > you need unique PT mapping across all the m=3D lines. > >> > >> Of course. So I think that means its important for bundle to clearly > state the requirement, if it is to be a real one. > >> > >> Thanks, > >> Paul > >> > >>> Colin > >>> > >>> > >>>>>> The corner case where we're discussing whether one can use the > same > >>>>>> payload type is if you have two M-lines that both specify VP8, > with the same codec parameters - whether they can both use 96, given > that it's the same codec. > >>>>> > >>>>> Surely yes, but you lose the ability to distinguish the m=3D line > >>>>> based on the PT if you use the same PT (mapped to the exact same > >>>>> codec and set of codec parameters) in several m=3D lines. Some > applications care about distinguishing m=3D lines based on PT values, and > so need distinct PT values for every m=3D line; others don't care, and > can use the same PT to represent the same codec across multiple m=3D > lines. > >>>> > >>>> Exactly. So, I think it's a good idea to have some text about that > in BUNDLE. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > https://jitsi.org FAX: +33.1.77.62.47.31 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From elwynd@folly.org.uk Tue Jun 25 05:49:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8579D21F9E82; Tue, 25 Jun 2013 05:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktiq-NqsFxPg; Tue, 25 Jun 2013 05:49:23 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id 092B621F96EB; Tue, 25 Jun 2013 05:49:23 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1UrSgP-0006o3-2u; Tue, 25 Jun 2013 13:49:17 +0100 From: Elwyn Davies To: Magnus Westerlund In-Reply-To: <51C85D02.1050907@ericsson.com> References: <1370477514.4596.9052.camel@mightyatom> <51C85D02.1050907@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Folly Consulting Date: Tue, 25 Jun 2013 13:47:46 +0100 Message-Id: <1372164466.4524.9526.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:49:27 -0000 Hi, Magnus. Thanks for the (continuing) responses. Some comments in line. I look forward to the updated document! /Elwyn On Mon, 2013-06-24 at 16:51 +0200, Magnus Westerlund wrote: > Elwyn, >=20 > Follow up on some of the nits that is not simply to implement or where I > disagree or want to provide feedback. >=20 > This email covers all issues up to and including Section 11. That is as > far as I have managed to process them yet. I will now handle over the > rest of this list to my co-authors. >=20 > On 2013-06-06 02:11, Elwyn Davies wrote: > >=20 > > s2.3, para 5: > >> The server should also regularly send every 5 > >> minutes the current media range in a PLAY_NOTIFY request. > > Shouldn't this be configurable? >=20 > As discussed in Section 13.5.2 the reasons for the picked time is the > following: >=20 > The recommendation for sending updates every 5 minutes is due to > any clock skew issues. In 5 minutes the clock skew should not > become too significant as this is not used for media playback and > synchronization, only for determining which content is available > to the user. >=20 > Yes, it can be configurable, and in fact 5 min is only the recommended > interval. So, if an implementation that have a good reason for something > else can do that. Do you have a reason why you think this should be > configurable? Standard review reaction to an apparently sensible but arbitrary fixed parameter! =20 >=20 > But, if it should be rewritten, I think the acceptable range for within > to adjust it should be specified, like between 1 min and 2 hours. Suggest: - adding 'approximately' ('send approximately every') and a ref to s13.5.2 to s2.3.=20 - change s13.5.2: OLD: In addition it is RECOMMENDED that the server sends these notifications every 5 minutes for time-progressing content to ensure the long-term stability of the client estimation and allowing for clock skew detection by the client.=20 NEW: In addition it is RECOMMENDED that the server sends these notifications approximately=20 every 5 minutes for time-progressing content to ensure the long-term stability of the client estimation and allowing for clock skew detection by the client. The time between notifications should be greater than 1 minute=20 and less than 2 hours. >=20 > >=20 > > s2.3, last para: > >> If the client waits too long > >> before resuming the pause point, the content may no longer be > >> available. In this case the pause point will be adjusted to the e= nd > >> of the available media. > > I know this is a subjective choice, but I would have thought adjusting=20 > > to the beginning of the available media would be what the user expects. > > Later: Having read s13.4.1, I think this conflicts with (or is unclear)= =20 > > compared with s13.4.1, para 2 which states that the pause point will be > > the oldest retained time - that is what I would have expected. >=20 > Yes, "end" in the above sentence is not quite right. My proposal is the > following: >=20 > In this case the pause point will be adjusted to the closest point in > the available media. >=20 Seems like a good choice. >=20 > >=20 > >=20 > > s3.1, para 3: Clearly there won't be any smaller type paras in the=20 > > ASCII version.. is there a PDF version that actually has smaller type? = =20 > > The one I get from the repository doesn't seem to have any smaller type= =20 > > paras. >=20 > I removed the "small type" as this is a remains from when the draft was > produced using LaTex and a PDF version was produced. Fine. >=20 > >=20 > > s4.4: An external reference to the relevant Society of Motion Picture=20 > > and Television Engineers standard (probably SMPTE 12M) ought to be=20 > > included to define things like "SMPTE 30 drop". [Aside: 29.97 frames=20 > > per second?? Must be something to do with Never Twice the Same Color. =20 > > Oh, well, a little research job for whan I am really bored.] >=20 > Yes, it is ST 12M-1 2008 that appears to be the relevant reference. Yes, > SMPTE 30 drop is a NTSC thing. :-) >=20 > >=20 > > s4.9.1: There seems to be some confusion in this section between the > > values from the Seek-Style header and the values from the > > Media-Properties random access property. The section says the values > > are from Seek-Style but they are actually from the random access > > property. Presumably there was some intention to interelate the media > > capabilities and the play event policies? Further this section has > > Random Access, Conditional Random Access, Return to Start and No > > Seeking. This doesn't match exactly with either Seek-Style (RAP, CoRAP= , > > First-Prior and Next) or Media-Properties (Random-Access, Beginning-Onl= y > > and No-Seeking). >=20 > Yes, this was confused. Actual the Media-Properties headers values are a > distinct set. Then if doing random access then the Seek-Style policies > applies. This I propose to clarify by writing Section 4.9.1 as: >=20 > 4.9.1. Random Access and Seeking >=20 > Random Access is the ability to specify and get media delivered=20 > from any point inside the content, an operation called seeking. The ^^^^^^^^^^^^^^^^^^^^^ Try: starting from any time instant within > Media-Properties header will indicate the general capability for a > media resource to perform random access. If random access is > possible the actual behavior policy when seeking can be controlled > using the Seek-Style header (Section 18.45). >=20 > Random-Access: The media is seekable to any out of a large number of > points within the media. Due to media encoding limitations, a > particular point may not be reachable, but seeking to a point > close by is enabled. A floating point number of seconds may be > provided to express the worst case distance between random access > points. >=20 > Beginning-Only: Seeking is only possible to the beginning of the > content. >=20 > No-seeking: Seeking is not possible at all. >=20 Generally fine - small suggestion above. >=20 > > s4.9.x: It would be desirable to use the parameter names in the same=20 > > form as they appear in s18 (e.g., Random-Access instead of Random=20 > > Access, No-Seeking instead of No seeking) both in the definitions=20 > > (s4.9.1 - s4.9.4) and the mapping (s4.9.5). >=20 > Yes, that is has been addressed. >=20 OK > >=20 > >=20 > > ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified= =20 > > values "smpte", "npt" and "clock" are valid in the Range parameter. =20 > > What is the meaning of such an unqualified value? >=20 > You are correct about that the basic definition in ABNF allows for > empty. The reason for this is the following stated in Section 18.38: >=20 > It MAY be > included in GET_PARAMETER requests from the client to the server with > only a Range format and no value to request the current media > position, whether the session is in Play or Ready state in the > included format. >=20 Two points: - A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4. Add a bit of text in the new s4.4 saying that the range specifiers are used in the RANGE header and pointing to s18.38 for the unqualified use. (consistent with s2.7 which gives usage). - An issue I hadn't spotted: I haven't checked but are the unqualified values allowed in the SDP extension case (s20.3)? >=20 >=20 > >=20 > > s5: It would be sensible to note that the ABNF fragments in s5 and the= =20 > > following sections match with the full syntax productions in s20. >=20 > I have added a note, but they are in fact equivalent, but not identical. > Thus I make it clear that that this is for information and the formal is > in section 20.2.2. OK >=20 >=20 > >=20 > > Table 3: Proxy-Authorization (Section 18.34) doesn't appear in any of=20 > > the various header categorization tables [I must have better things to=20 > > do than checking they were all there :-( ]. I think it belongs here. >=20 > Sorry, for not having found this myself before. You noticing it missing, > was actually a larger inconsistency issue. It was missing in the ABNF als= o. (I think I noted that later). >=20 > I have spent quite some time now to ensure that the ABNF, the tables in > Section 6-8 and the header description now align as they should > regarding category. Yes.. tedious job as I found out! Good! >=20 >=20 > > s8.1.1, code 505: HTTP code 505 is explicitly '*HTTP* version not=20 > > supported' - should there really be a separate code for 'RTSP version=20 > > not supported'? >=20 > Yes, but the import of HTTP response codes are their meaning not there > exact definition. Thus 505 is RTSP version not supported as listed in > table. That is also what section 17.5.6 defines it as. I won't push this one. >=20 > >=20 > > s9: Is it deliberately left vague as to whether other message types=20 > > might have message bodies? >=20 > This is unnecessary vague. In attempt to clarify this I have proposed > the following rewrite of that paragraph: >=20 > The SET_PARAMETER and GET_PARAMETER request and response, and DESCRIBE > response is by this specification defined that they MAY have a message > body and its purpose. All 4xx and 5xx responses MAY also have a message > body to carry additional response information. A message body MAY occur > on any RTSP 2.0 request or response, but the content of the message body > MAY be ignored. Extensions to this specification can specify the purpose > and content of message bodies, including requireing their inclusion. Seems sensible. Editorial update: The SET_PARAMETER and GET_PARAMETER requests and responses, and the DESCRIBE response as defined by this specification MAY have a message body; the purpose of the message body is defined in each case. All 4xx and 5xx responses MAY also have a message body to carry additional response information. Generally a message body MAY be attached to any RTSP 2.0 request or response, but the content of the message body MAY be ignored by the receiver. Extensions to this specification can specify the purpose and content of message bodies, including requiring their inclusion. >=20 >=20 > >=20 > > s10.2, para 6 and following note: I can't see that the note following=20 > > para 6 can be justified: since the restriction on multiple connections=20 > > from a client to a server is only a SHOULD, an interoperable server MUS= T=20 > > be capable of handling multiple connections from a client unless the=20 > > server can explicitly send back a TOO MANY CONNECTIONS status. >=20 > See separate email Should I have had this already? >=20 > >=20 > > s10.6: RFC 3986 has capability for dealing with IP versions beyond 6...= =20 > > should these be carried over into RTSP? The IANA registry says they ar= e. >=20 > I am uncertain what you want here? Yes, the URI format allows for future > definitions of literal IP address versions. However, RTSP does contain > explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP > versions will require some extension definition to function. Perhaps an excess of zeal on my behalf. Perhaps a (non-normative) note saying what you just wrote: 'Although the general URI format envisages=20 potential future new versions of the literal IP address, usage of any such new version would require other modifications to the RTSP specofication (e.g., ...[any relevant section(s)]).'=20 >=20 >=20 >=20 > > s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED=20 > > here are usually MANDATORY. (Also applies to wait timer in last para of= =20 > > this section). >=20 > Yes, I agree that they usually are. I personally have no issues making > them required. I think the Recommended formulation is really one of > these cases, do this or something even better or you will hang yourself > to be a bit blunt. >=20 > But, if I understand you, you think this paragraph should read: >=20 > An RTSP server or proxy in an overload situation must select the value > of the Retry-After header carefully and bearing in mind its current load > situation. It is REQUIRED to increase the timeout period in proportion > to the current load on the server, i.e., an increasing workload should > result in an increased length of the indicated unavailability. It is > REQUIRED to not send the same value in the Retry-After header to all > requesting proxies and clients, but to add a variation to the mean value > of the Retry-After header. >=20 > Objections to this? I was only really concerned about the variation. I would leave the 'how much to increase' as a RECOMMENDED, but say there MUST be variation in the retry values sent to different clients if theye are sent at all. >=20 > >=20 > > s10.7, last para: Should the doubling of the wait timer have an upper l= imit? >=20 > Yes, I added an upper limit of 30 minutes. This is way beyond what any > human will accept, only robots will keep on going at this timeout value. > And I think that is large enough to avoid any issues. Agreed >=20 > I also propose to clarify the range for the variations and added the > classical 0.5 to 1.5 times the deterministic value. >=20 > Text proposal. >=20 > That timer MUST be doubled for each additional failure to connect or > receive response until the value exceeds 30 minutes when the timers > deterministic value may be set to 30 minutes. It is RECOMMENDED to not ^^^^^^^^^^^^^ base? > set the same value in the timer for each scheduling, but instead to add > a variation to the mean value, resulting in picking a random value > within the range of 0.5 to 1.5 of the mean value. >=20 > >=20 > > s11, para 4: According to s22.1.3, play.basic, play.scale and play.spee= d > > are 'defined' in this draft. The nearest thing to a definition of > > play.basic that I can find is the last sentence of para 4 in this > > section. I am not convinced that I could produce an interoperable > > implementation of a server with this feature-tag with the one sentence > > 'definition'. References to where play.xxx are defined would be useful > > (play.scale in s18.44, play.speed in s18.48). > >=20 >=20 > Hmmm, the other feature-tags than play.basic are pretty straightforward > and well contained. play-basic is really a minimal RTSP server > implementation according to the whole spec for media playback. >=20 > This can probably be more clearly expressed somewhere, but it can't > really be enumerated. Then we are back to the issue we had with RFC 2326 > minimal implementation list that was incomplete and lacked a lot of > things really necessary. >=20 > This issue still haven't resulted in any changes to our source. Ah! I see I have (re-)opened a can of worms! One thought for providing the proverbial larger can into which the worms can be stuffed back: Define 'play.basic' as the default that you get back if none of the others apply. How's that for weasel words! >=20 >=20 > > s11, Supported (and Proxy-Supported) bullets:=20 > > OLD: > > This results in the > > receiver is learning the requester's feature support. > > NEW: > > This results in the > > receiver learning the requester's feature support=20 > > relevant to the specified resource. > > [Note: I added 'specified resource' here and then thought about whether > > this made any sense. It probably needs to be clearer what set of > > features are included in the Supported list for both requester and > > responder. Are they restricted to those relevant to the specified > > resource that might of course be the whole server, proxy - or client?? = - > > in which case there isn't an issue, but it might be a specific > > presentation - what happens then? Affects s13.1, para 3 also.] >=20 > Actually, I don't think it is specific to the media resource. The issue > with making it specific to a media resource is that a RTSP client needs > to be able to look into the future and supply an answer for a media > resource it may not yet know sufficient to provide a tailored response > for. I think it is simpler and better to provide general capabilities in > the supported header and then later determine how well they apply for > the media resource itself. So maybe make it clear that feature support returned is just what the responder can do generally and is not specific to the URI provided. Either that or make the request valid only for non-specific URIs (i.e. at the server/client level) if that is possible (not sure how that would work for server asking client if that is allowed). >=20 > We do have Media-Properties header to provide more details for what > specific media transformations a server can do when the support play.scal= e. Right. /Elwyn >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From pkyzivat@alum.mit.edu Tue Jun 25 05:51:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8FB21F9607 for ; Tue, 25 Jun 2013 05:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIQNMHv7ErcA for ; Tue, 25 Jun 2013 05:51:45 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id C2CDA21F9302 for ; Tue, 25 Jun 2013 05:51:44 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta10.westchester.pa.mail.comcast.net with comcast id sbul1l0061HzFnQ5AcrkWp; Tue, 25 Jun 2013 12:51:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id scrk1l0083ZTu2S3acrkNm; Tue, 25 Jun 2013 12:51:44 +0000 Message-ID: <51C9925F.9000901@alum.mit.edu> Date: Tue, 25 Jun 2013 08:51:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372164704; bh=4RyIppQaCa+gz6qKnNwry5iu35dsN6BmVJGd8Qps898=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oEFD+Vuuk+xyehBMxN376XCXeXIXHpKpLhbYnuD7OAcatmhN2NcYAZLpMOzcCbUHb osInaxEq9CUvF2/A4RpU0v9+zei0ehmw+i+j97sGkvRIFdu67J5yUO5MnuHzmJ/pn4 /SKVq5A64Tboigpz42YfEh2+Jb2TsyQeQdmO1ITE1cU4V9Lg6CNTOGuQNZJQQcoOMI gVbtINrhCKrsexOLIHLeqPdxYwmQBaCguroLxhdnfQXbxexnKksv4SIf7MEkZM/II8 +FLAl4EGSnoaMjYFDr5W5nqwxbmf4s7V+UTR2Hyx83ZymDNAT5lI+MbeJdyQ2IsR/+ B5dDLcfCaKp1g== Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:51:49 -0000 I started this issue, so I'll make my case again. There must be a reason to have multiple m-lines in the bundle. (If there isn't, leave them out, and then maybe you won't need bundle at all.) I assert that in all cases that reason can't be realized without being able to associate packets with the corresponding m-line. The exception to this are those packets that deal only with those aspects of the bundle that are common. The most obvious example of this is ICE. But if *all* packets are common to all the m-lines then there is no reason for the bundle. Thanks, Paul On 6/25/13 7:16 AM, Christer Holmberg wrote: > Hi, > > There has been some discussions about whether BUNDLE should mandate that > users are mandated to *always* (no matter what transport protocols are > used in the BUNDLE group) have a mechanism to map received data to an m- > line, or whether it from a generic BUNDLE perspective should be optional > – IF there would be cases where it’s not needed. > > We haven’t had that much discussion about it yet, so I will not ask a > DECISION question at this point, but I would really like to get some > input from people who have opinions about this :) > > Note that this issue is NOT about HOW to map data to m- lines (there > will be a separate question about how to map RTP to m- lines etc), or > whether we should allow usage of the same PT value (for the same codec > configuration) in multiple m- lines, but more about a general rule. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue Jun 25 07:48:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54021E8098 for ; Tue, 25 Jun 2013 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 348KCowXY1yw for ; Tue, 25 Jun 2013 07:48:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05CC211E8110 for ; Tue, 25 Jun 2013 07:48:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000005ad4-5d-51c9adc291f6 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.CC.23252.2CDA9C15; Tue, 25 Jun 2013 16:48:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 16:48:34 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NP//+aaA///Dn0A= Date: Tue, 25 Jun 2013 14:48:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu> In-Reply-To: <51C9925F.9000901@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre6htScDDTb1yFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG91m72QvWCFa8/r6cvYHxJW8XIyeHhICJ xNLTe9khbDGJC/fWs3UxcnEICRxmlDh66TY7hLOIUWL+jh9MXYwcHGwCFhLd/7RBGkQEfCWe Pb7NBmILCyRLTHnzlw0iniJxd/95dgjbSuLOlCmsIDaLgKrE10ltYDYvUG/7krlMILaQQL7E zEubwOo5BXQkFq07xgJiMwId9P3UGrAaZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2okT7 0wZGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYmTPTczM SS833MQIjIWDW37r7mA8dU7kEKM0B4uSOO+HU7sChQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTCGB2eKRNuGfS3r1LAUqJoY/LlWYM9qlTlp/zPWfdrm4Me1ZMpzkV0FuVob89QfOO5VXjzx mGSdIsPWN/YuGlnfnzLdqmk9f+aFwr+dd97Y12v9Yzu8dIHSsshla9K3Ptrb6b39a+6SSr0b z23WvpmsPHnxm6MafGs3vr6QdvbslXR/nhL3jv+MSizFGYmGWsxFxYkAKEhV/FMCAAA= Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:48:44 -0000 Hi, > I started this issue, so I'll make my case again. > > There must be a reason to have multiple m-lines in the bundle. (If there = isn't, leave them out, and then maybe you won't need bundle at all.) > > I assert that in all cases that reason can't be realized without being ab= le to associate packets with the corresponding m-line. The reason for having m- lines could be because different characteristics (= bandwidth, priority etc) is requested from the NETWORK, while the endpoint = application that receive the data might not care which m- line it belongs t= o. > The exception to this are those packets that deal only with those aspects= of the bundle that are common. The most obvious example=20 > of this is ICE. But if *all* packets are common to all the m-lines then t= here is no reason for the bundle. Correct. For ICE we explicitly say that the STUN messages apply to the whol= e BUNDLE group. Regards, Christer On 6/25/13 7:16 AM, Christer Holmberg wrote: > Hi, > > There has been some discussions about whether BUNDLE should mandate=20 > that users are mandated to *always* (no matter what transport=20 > protocols are used in the BUNDLE group) have a mechanism to map=20 > received data to an m- line, or whether it from a generic BUNDLE=20 > perspective should be optional - IF there would be cases where it's not n= eeded. > > We haven't had that much discussion about it yet, so I will not ask a=20 > DECISION question at this point, but I would really like to get some=20 > input from people who have opinions about this :) > > Note that this issue is NOT about HOW to map data to m- lines (there=20 > will be a separate question about how to map RTP to m- lines etc), or=20 > whether we should allow usage of the same PT value (for the same codec > configuration) in multiple m- lines, but more about a general rule. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Tue Jun 25 08:12:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4347821E8091 for ; Tue, 25 Jun 2013 08:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI85-LUpyoVE for ; Tue, 25 Jun 2013 08:12:32 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7C47621F9CF1 for ; Tue, 25 Jun 2013 08:12:30 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so894063wgg.1 for ; Tue, 25 Jun 2013 08:12:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=YxZKxusP4du6FEiVu21A/snms4dyaPE+U3AF/dbePYc=; b=pBFs5GtqDNjJO0mAQp6nJep5A/tI+OPsDq85peF/AzyDiiD0vrIzD9Y3edcBWvduPW bDfKnI86F5MD/e1Bxc9pp23YOWktxkMiu+bjzBMMh5CECO1WtBe+GTNbupfI3DVoVYif SSDbbpyog4Xgv0bT8mL0/SprBt9EK1MeoLV88m9NrC1KVFT7YgOtmi9stOoKlqInkgMb /AsPWXehdC5lAvgpKF2F/DhSk+kT/bb4tfXOxSBMLcbXdpDaF2WAhp+rrWWFLkC2JKm1 43niQfX2oPB3ZDmRy27UaxQPgF6BASpB95teo7LfWYWC27SSwcQtecPeh6A79GgG1/PL KJ2w== X-Received: by 10.194.157.65 with SMTP id wk1mr20425873wjb.8.1372173149537; Tue, 25 Jun 2013 08:12:29 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id m3sm4746456wij.5.2013.06.25.08.12.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 08:12:28 -0700 (PDT) Message-ID: <51C9B35A.1000608@jitsi.org> Date: Tue, 25 Jun 2013 17:12:26 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A14B8C943@xmb-rcd-x10.cisco.com> <51C85164.5080208@jitsi.org> <913383AAA69FF945B8F946018B75898A14B8D7A3@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B8D7A3@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlzQIQmPHxpRHL8q3Wc4u+HU27wz7rdABuuqa/hDLqh6h+DS6emyalqY/rnB5bl+M0iMCxa Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:12:40 -0000 Hey Tiru, On 25.06.13, 14:41, Tirumaleswar Reddy (tireddy) wrote: > Hi Emil, > > Thanks for the review. Please see inline > >> -----Original Message----- From: Emil Ivov >> [mailto:emcho@jitsi.org] Sent: Monday, June 24, 2013 7:32 PM To: >> Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org Subject: Re: >> [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice- >> mobility-04.txt >> >> Hey Tiru, >> >> On 24.06.13, 15:06, Tirumaleswar Reddy (tireddy) wrote: >>> Hi all, >>> >>> we have updated the draft based on the comments received during >>> IETF 86 to compare MICE with ICE restart and Trickle ICE (Section >>> 6 "Comparison to ICE Restart and Trickle ICE"). comments and >>> suggestions are welcome. >> >> Thanks for doing this. >> >> A few comments on that comparison: >> >>> 6.2. Break Before Make - Trickle ICE >>> >>> o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for >>> RTP Mobility then in case of Break before Make, >>> >>> 1. Trickle ICE can begin connectivity checks while the endpoint >>> is still gathering candidates and can considerably shorten the >>> time necessary for ICE processing to complete. It still involves >>> the overhead of step 1 explained in section Section 6.1. >> >> The said overhead being SIP re-registration, I don't see how >> trickle-ice and mice are in a different position here. Why would >> one be able to restart attempts without it, while the other >> wouldn't ? > > Mobility using ICE will be started without waiting for SIP > re-registration to start (performed entirely in the media path). > Please refer to the explanation in > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04#section-3.1 Yes, sure. What would prevent you from doing the same if you were to do mobility with trickle ICE? Obviously, the trickle updates would need to through the SIP server and they would potentially have to be re-authenticated, but nothing stops you from engaging in the semantics defined in MICE just because you are also doing trickle ICE. >>> 2. The endpoint would learn host candidates and inform them to >>> the remote peer in offer, the remote peer will provide its >>> candidates in answer. The host, server reflexive, peer reflexive >>> and relayed candidates of the remote peer may not change and the >>> remote peer does not have to gather the candidates again. Trickle >>> ICE will test local host candidates with all types of remote >>> candidates provided by the remote peer in the answer. If the ICE >>> peer is behind NAT performing end-point independent mapping and >>> filtering then ICE connectivity checks initiated by the endpoint >>> to the remote peer will succeed. >> >> Actually that's what you'd need the NAT to be without trickle ICE >> so that break-before-make mice would succeed (which I've already >> expressed as a concern with this draft). > > Yes, we have updated the draft about the concern you raised last > time > > Section 3.1 ... Mobility using ICE could fail in case of Simultaneous > Mobility or if the ICE peer is behind NAT that performs > Address-Dependent Filtering (see Section 5 of [RFC5245]).... What I am saying is that rather than just warning about it, you could also resolve it with trickle ICE. > And this concern could be addressed by either of the following > techniques - Section 3.2 "Keeping unused relayed candidates active" True. But this would be suboptimal. > or Appendix A.2.1. "Keeping unused candidates in the valid list > active" Not true. Keeping your server reflexive candidates alive wouldn't change anything in the case of a NAT with EPD filtering. >> Using trickle ICE would allow you to succeed with endpoint >> dependent filtering because the remote party would also start >> checks in your direction. > > The problem in the above scenario is endpoint would just learn host > candidates and inform them to the remote peer in offer, I don't get this. Why would an endpoint only inform of host candidates? It would also inform of server-reflexive candidates as soon as it discovers them. > so if the > endpoint is behind endpoint independent filtering NAT and the remote > peer is behind endpoint dependent filtering NAT (Let's say NAT X). > The STUN connectivity checks sent by the endpoint will be blocked by > X, STUN connectivity checks initiated by the remote peer will fail to > reach the endpoint because it is behind NAT. Again, this is the case *without* trickle ICE. If however you allowed trickle ICE to help MICE, the endpoint that's behind the EPD filtering NAT would eventually learn about your new candidates and also start sending checks there. >> I guess what I am trying to say is that it doesn't make sense for >> mice not to use trickle ICE for this case. > > MICE can be used with Trickle ICE, we are only responding to comments > in the last IETF asking for the benefits of MICE in comparison with > ICE restart and Trickle ICE. My point is that MICE can not only be used with but also optimized with trickle ICE and made more reliable. Cheers, Emil >>> 3. Trickle ICE must be supported by both endpoints for it be >>> used. >> >> I am not sure I understand this argument. Any kind of mobility >> management would have to be supported by both pears in order to be >> used. > > when only one endpoint supports MICE, TURN server can be used to > provide mobility (Section 5 - "Mobility using TURN"). The endpoint > will use local relayed candidates for communicating with the remote > peer. Even If endpoint roams and gets a new IP address, it will > continue to reach the remote peer using the local relayed candidates > as explained in section 5 (using the MOBILITY-TICKET). The remote > peer will not even be aware that the endpoint IP address has > changed. > > Regards, --Tiru. > >> >> Cheers, Emil >> >> >> >>> >>> Best Regards, --Authors. >>> >>> -----Original Message----- From: internet-drafts@ietf.org >>> [mailto:internet-drafts@ietf.org] Sent: Monday, June 24, 2013 >>> 1:06 PM To: Prashanth Patil (praspati); Tirumaleswar Reddy >>> (tireddy); Dan Wing (dwing); Pal Martinsen (palmarti) Subject: >>> New Version Notification for >>> draft-wing-mmusic-ice-mobility-04.txt >>> >>> >>> A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt has >>> been successfully submitted by Dan Wing and posted to the IETF >>> repository. >>> >>> Filename: draft-wing-mmusic-ice-mobility Revision: 04 Title: >>> Mobility with ICE (MICE) Creation date: 2013-06-24 Group: >>> Individual Submission Number of pages: 19 URL: >>> http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-04.txt >>> >>> >> >>> Status: >> http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility >>> Htmlized: >>> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-04 >>> >>> >>> Abstract: This specification describes how endpoint mobility can be >>> achieved using ICE. Two mechanisms are shown, one where both >>> endpoints support ICE and another where only one endpoint >>> supports ICE. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> _______________________________________________ mmusic mailing >>> list mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- https://jitsi.org > -- https://jitsi.org From pkyzivat@alum.mit.edu Tue Jun 25 08:13:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093AF21F9E0D for ; Tue, 25 Jun 2013 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCNQXNNqp5nW for ; Tue, 25 Jun 2013 08:13:47 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7FD21E809C for ; Tue, 25 Jun 2013 08:13:46 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id sbLr1l0020Fqzac55fDmEe; Tue, 25 Jun 2013 15:13:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id sfDm1l00E3ZTu2S3UfDmRl; Tue, 25 Jun 2013 15:13:46 +0000 Message-ID: <51C9B3A9.2000106@alum.mit.edu> Date: Tue, 25 Jun 2013 11:13:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372173226; bh=wcneZD/uMNLdok/JQXB6i9s9X0ykOhdNeSOjsrgZzZ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aZFA/JWjsp6zzR+XlRF/0b2ExpyiGYzQv8YYrD4XVqUzL4jrWIU0x4aDKN/HrwvZ4 S3EpUospy8prcZZGZT84BhQwQW5hJ0D3Ve++sI2uvVY683B3+ym6OeDmt6anWYvyv2 FzYRDHOE/RGAjUAOr8ICHa3j0OdKHxZIjHc8Nc0i0fzFYreJqwRwnfuPKHRiMzoPGk YFoboYy9Pv7y7RdmJ46ljjjnM/z8eGCf2BfPaVkNtFnwg4BVh0rNAMaM6sOq10H78c E/zwkgyBWP0ZxIdd69qt9rmrMmgQnmRSpDtd9dX+M3vwagq34Jh65INOfyOcETu2lb uZnqVtE7MjX2Q== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:13:52 -0000 On 6/25/13 10:48 AM, Christer Holmberg wrote: > Hi, > >> I started this issue, so I'll make my case again. >> >> There must be a reason to have multiple m-lines in the bundle. (If there isn't, leave them out, and then maybe you won't need bundle at all.) >> >> I assert that in all cases that reason can't be realized without being able to associate packets with the corresponding m-line. > > The reason for having m- lines could be because different characteristics (bandwidth, priority etc) is requested from the NETWORK, while the endpoint application that receive the data might not care which m- line it belongs to. Can you be specific? Note that if you are requesting different characteristics from the NETWORK, then the NETWORK must be able to distinguish the packets in order to apply those characteristics properly. So then *it* will need a way to distinguish. If so, then the endpoints can too. If you are just requesting characteristics for the entire bundle, then it should be possible to do it with fewer m-lines, that you can then associate with. >> The exception to this are those packets that deal only with those aspects of the bundle that are common. The most obvious example >> of this is ICE. But if *all* packets are common to all the m-lines then there is no reason for the bundle. > > Correct. For ICE we explicitly say that the STUN messages apply to the whole BUNDLE group. It can in principle apply to more than just ICE. Somewhere I commented that the field describes more than just the low level transport protocol. It often describes a whole protocol stack with many layers. When we bundle multiple m-lines with different fields, they have different stacks. For the bundle to be valid, at least the bottom level of each stack must be the same. (E.g., UDP.) There may be more layers in common among some or all of the stacks. When some of the m-lines have multiple layers in common, then there may be some packets that pertain to housekeeping of the layer, and so need not be associated with one particular m-line. For instance, *in principle* one could bundle multiple DTLS/SCTP m-lines together. Then there could be some SCTP housekeeping packets that can't be associated with a single m-line, but for this to work, SCTP payload packets would need to be distinguishable, probably by SCTP port. (Note, I'm not sure if there are any SCTP packets that don't have an SCTP port, so this might not be a good example. And of course for this example to work there would need to be a way to specify the SCTP port in SDP for DTLS/SCTP.) AFAIK, for stuff *currently* under discussion only ICE falls into this category. But if we are going to define bundle so it can be applied to future cases then we need to phrase the constraint properly. Thanks, Paul > Regards, > > Christer > > > > > On 6/25/13 7:16 AM, Christer Holmberg wrote: >> Hi, >> >> There has been some discussions about whether BUNDLE should mandate >> that users are mandated to *always* (no matter what transport >> protocols are used in the BUNDLE group) have a mechanism to map >> received data to an m- line, or whether it from a generic BUNDLE >> perspective should be optional - IF there would be cases where it's not needed. >> >> We haven't had that much discussion about it yet, so I will not ask a >> DECISION question at this point, but I would really like to get some >> input from people who have opinions about this :) >> >> Note that this issue is NOT about HOW to map data to m- lines (there >> will be a separate question about how to map RTP to m- lines etc), or >> whether we should allow usage of the same PT value (for the same codec >> configuration) in multiple m- lines, but more about a general rule. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From jakubadamek@gmail.com Tue Jun 25 08:34:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6783321F9F6B for ; Tue, 25 Jun 2013 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=2.181, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h55GXcn+-BOl for ; Tue, 25 Jun 2013 08:34:34 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE211E80AD for ; Tue, 25 Jun 2013 08:34:34 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UrVGL-00066R-Mr for mmusic@ietf.org; Tue, 25 Jun 2013 08:34:33 -0700 Date: Tue, 25 Jun 2013 08:34:33 -0700 (PDT) From: jakubadamek To: mmusic@ietf.org Message-ID: <1372174473646-373839.post@n7.nabble.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:03:25 -0000 Hi Nigel, could you please tell me roughly how much time it took to implement the RFC? And how well does it work for you? Thx Jakub -- View this message in context: http://ietf.10.n7.nabble.com/Comments-on-ICE-TCP-specification-RFC-6544-tp191890p373839.html Sent from the IETF - mmusic mailing list archive at Nabble.com. From emil@sip-communicator.org Tue Jun 25 10:03:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03C421E80A3 for ; Tue, 25 Jun 2013 10:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAdz0WAWOWN7 for ; Tue, 25 Jun 2013 10:03:07 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA321E80AD for ; Tue, 25 Jun 2013 10:03:05 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so1001476wgg.3 for ; Tue, 25 Jun 2013 10:03:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=tCJIS5EjFDXhQbyNZQzNZ2rkUYnXu7Zo53QxBS9C5AA=; b=W7jcr8niAaWfBnrNBEnE3JVQ5kSBBLcZqMG4YPjQJLVGAzVzUosusowbRLxUo6xSqN kdmJyRm2wQI+lkwZAdnw1GOUF/H0j5237p3CpBpRRxSuQ/sQqsVKEDh9YISQ6VQ8uMQr M3LZl2vsOxB9ZXBNKMpZ2ofbGOqsdsSspQvxbqjDk1YesTBOTcKKIYjheHRz3SavcKwT ZkleECPJaVuDozN29d+JCTY7EXvPo/KVosHd04VMDyfGtatFl3iLC2S8MmGDfJ7mSQxW RwjOlFeoMjebQmkDJX1hyZ5itjcoRmz67sTqmKj7r0SDe9qloIaKUpiihRbFYoL6YNlt Ix0w== X-Received: by 10.194.242.136 with SMTP id wq8mr20901981wjc.60.1372179784324; Tue, 25 Jun 2013 10:03:04 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id d8sm5441172wiz.0.2013.06.25.10.03.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 10:03:03 -0700 (PDT) Message-ID: <51C9CD45.3050404@jitsi.org> Date: Tue, 25 Jun 2013 19:03:01 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnT/Tmv1VNOIImDLag89niPwYqNdZv7pOJr0JKf9/R5tR0ck0IAoQckTVnIZzireKpxHAJU Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:03:12 -0000 On 25.06.13, 13:34, Christer Holmberg wrote: > Hi, > > Emil suggested that the default, =93MTI=94, mechanism for mapping RTP d= ata > to m- lines should be based on PT. Actually, what I thought was important was having it as the "default"=20 mechanism. Personally I don't mind having it as MTI might but it might=20 be a tad too strong: implementations that deem PT demux insufficient and = wouldn't want to use bundle without it, don't need implement it. We should probably also agree on how an answerer can determine whether=20 or not it is expected to provide additional demuxing information (e.g.=20 SSRCs) or if the offerer is using the default mechanism. One way would be for the answerer to inspect all m=3D lines and try to=20 detect duplicating PTs. This could be a bit clumsy though. The offerer=20 could expect SSRCs but its first offer may not yet contain PT reuse. With that in mind ... (more below) > Applications are allowed to use > whatever other mechanisms, but usage of such mechanisms must be > negotiated (or, applications need to have some other means knowing that= > the other endpoint support such mechanisms). > > *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP > data to m- lines? I am in favour of having a "default" one. Without this BUNDLE would have to be an abstract spec and I don't see=20 why we would want to leave it that way. > *Q4*: If Q3, do we mandate applications to support, and use (unless > applications are made aware of other mechanisms supported by all > endpoints) PT for mapping received RTP media? In favour. Cheers, Emil > > This means that, when mapping RTP to m- lines is required (whether it i= s > always mandated is discussed in another thread), within a BUNDLE group > each PT value must be unique to an individual m- line. > > NOTE: If your answer to Q3 is =93yes=94, but your answer to Q4 is =93no= =94, > please indicate which mechanism you prefer J > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --=20 https://jitsi.org From bernard_aboba@hotmail.com Tue Jun 25 10:11:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3848211E8110 for ; Tue, 25 Jun 2013 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAG+pzYREd77 for ; Tue, 25 Jun 2013 10:11:29 -0700 (PDT) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB4611E810D for ; Tue, 25 Jun 2013 10:11:29 -0700 (PDT) Received: from BLU403-EAS314 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jun 2013 10:11:29 -0700 X-TMN: [HttogwBUHEmppodiDQtuDE/wGb5NBW2S] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51C9CD45.3050404@jitsi.org> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51C9CD45.3050404@jitsi.org> Date: Tue, 25 Jun 2013 10:11:20 -0700 To: Emil Ivov X-OriginalArrivalTime: 25 Jun 2013 17:11:29.0011 (UTC) FILETIME=[082FE430:01CE71C7] Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:11:34 -0000 QWdyZWUgd2l0aCBFbWlsIHRoYXQgImRlZmF1bHQiIG1ha2VzIG1vcmUgc2Vuc2UgZm9yIHVzZSBv ZiBQVCBmb3IgbWFwcGluZyB0byBhbiBtIGxpbmUuIElmIGE9U1NSQyBpcyBzcGVjaWZpZWQgb24g YW4gbSBsaW5lIHRoZW4gdGhhdCBzaG91bGQgdGFrZSBwcmVjZWRlbmNlIG92ZXIgUFQuDQoNCk9u IEp1biAyNSwgMjAxMywgYXQgMTA6MDMgQU0sICJFbWlsIEl2b3YiIDxlbWNob0BqaXRzaS5vcmc+ IHdyb3RlOg0KDQo+IA0KPiANCj4gT24gMjUuMDYuMTMsIDEzOjM0LCBDaHJpc3RlciBIb2xtYmVy ZyB3cm90ZToNCj4+IEhpLA0KPj4gDQo+PiBFbWlsIHN1Z2dlc3RlZCB0aGF0IHRoZSBkZWZhdWx0 LCDigJxNVEnigJ0sIG1lY2hhbmlzbSBmb3IgbWFwcGluZyBSVFAgZGF0YQ0KPj4gdG8gbS0gbGlu ZXMgc2hvdWxkIGJlIGJhc2VkIG9uIFBULg0KPiANCj4gQWN0dWFsbHksIHdoYXQgSSB0aG91Z2h0 IHdhcyBpbXBvcnRhbnQgd2FzIGhhdmluZyBpdCBhcyB0aGUgImRlZmF1bHQiIG1lY2hhbmlzbS4g UGVyc29uYWxseSBJIGRvbid0IG1pbmQgaGF2aW5nIGl0IGFzIE1USSBtaWdodCBidXQgaXQgbWln aHQgYmUgYSB0YWQgdG9vIHN0cm9uZzogaW1wbGVtZW50YXRpb25zIHRoYXQgZGVlbSBQVCBkZW11 eCBpbnN1ZmZpY2llbnQgYW5kIHdvdWxkbid0IHdhbnQgdG8gdXNlIGJ1bmRsZSB3aXRob3V0IGl0 LCBkb24ndCBuZWVkIGltcGxlbWVudCBpdC4NCj4gDQo+IFdlIHNob3VsZCBwcm9iYWJseSBhbHNv IGFncmVlIG9uIGhvdyBhbiBhbnN3ZXJlciBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IGl0 IGlzIGV4cGVjdGVkIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBkZW11eGluZyBpbmZvcm1hdGlvbiAo ZS5nLiBTU1JDcykgb3IgaWYgdGhlIG9mZmVyZXIgaXMgdXNpbmcgdGhlIGRlZmF1bHQgbWVjaGFu aXNtLg0KPiANCj4gT25lIHdheSB3b3VsZCBiZSBmb3IgdGhlIGFuc3dlcmVyIHRvIGluc3BlY3Qg YWxsIG09IGxpbmVzIGFuZCB0cnkgdG8gZGV0ZWN0IGR1cGxpY2F0aW5nIFBUcy4gVGhpcyBjb3Vs ZCBiZSBhIGJpdCBjbHVtc3kgdGhvdWdoLiBUaGUgb2ZmZXJlciBjb3VsZCBleHBlY3QgU1NSQ3Mg YnV0IGl0cyBmaXJzdCBvZmZlciBtYXkgbm90IHlldCBjb250YWluIFBUIHJldXNlLg0KPiANCj4g V2l0aCB0aGF0IGluIG1pbmQgLi4uIChtb3JlIGJlbG93KQ0KPiANCj4+IEFwcGxpY2F0aW9ucyBh cmUgYWxsb3dlZCB0byB1c2UNCj4+IHdoYXRldmVyIG90aGVyIG1lY2hhbmlzbXMsIGJ1dCB1c2Fn ZSBvZiBzdWNoIG1lY2hhbmlzbXMgbXVzdCBiZQ0KPj4gbmVnb3RpYXRlZCAob3IsIGFwcGxpY2F0 aW9ucyBuZWVkIHRvIGhhdmUgc29tZSBvdGhlciBtZWFucyBrbm93aW5nIHRoYXQNCj4+IHRoZSBv dGhlciBlbmRwb2ludCBzdXBwb3J0IHN1Y2ggbWVjaGFuaXNtcykuDQo+PiANCj4+ICpRMyo6IERv IHdlIG5lZWQgdG8gc3BlY2lmeSBhIGRlZmF1bHQsIE1USSwgbWVjaGFuaXNtIGZvciBtYXBwaW5n IFJUUA0KPj4gZGF0YSB0byBtLSBsaW5lcz8NCj4gDQo+IEkgYW0gaW4gZmF2b3VyIG9mIGhhdmlu ZyBhICJkZWZhdWx0IiBvbmUuDQo+IA0KPiBXaXRob3V0IHRoaXMgQlVORExFIHdvdWxkIGhhdmUg dG8gYmUgYW4gYWJzdHJhY3Qgc3BlYyBhbmQgSSBkb24ndCBzZWUgd2h5IHdlIHdvdWxkIHdhbnQg dG8gbGVhdmUgaXQgdGhhdCB3YXkuDQo+IA0KPj4gKlE0KjogSWYgUTMsIGRvIHdlIG1hbmRhdGUg YXBwbGljYXRpb25zIHRvIHN1cHBvcnQsIGFuZCB1c2UgKHVubGVzcw0KPj4gYXBwbGljYXRpb25z IGFyZSBtYWRlIGF3YXJlIG9mIG90aGVyIG1lY2hhbmlzbXMgc3VwcG9ydGVkIGJ5IGFsbA0KPj4g ZW5kcG9pbnRzKSBQVCBmb3IgbWFwcGluZyByZWNlaXZlZCBSVFAgbWVkaWE/DQo+IA0KPiBJbiBm YXZvdXIuDQo+IA0KPiBDaGVlcnMsDQo+IEVtaWwNCj4gDQo+PiANCj4+IFRoaXMgbWVhbnMgdGhh dCwgd2hlbiBtYXBwaW5nIFJUUCB0byBtLSBsaW5lcyBpcyByZXF1aXJlZCAod2hldGhlciBpdCBp cw0KPj4gYWx3YXlzIG1hbmRhdGVkIGlzIGRpc2N1c3NlZCBpbiBhbm90aGVyIHRocmVhZCksIHdp dGhpbiBhIEJVTkRMRSBncm91cA0KPj4gZWFjaCBQVCB2YWx1ZSBtdXN0IGJlIHVuaXF1ZSB0byBh biBpbmRpdmlkdWFsIG0tIGxpbmUuDQo+PiANCj4+IE5PVEU6IElmIHlvdXIgYW5zd2VyIHRvIFEz IGlzIOKAnHllc+KAnSwgYnV0IHlvdXIgYW5zd2VyIHRvIFE0IGlzIOKAnG5v4oCdLA0KPj4gcGxl YXNlIGluZGljYXRlIHdoaWNoIG1lY2hhbmlzbSB5b3UgcHJlZmVyIEoNCj4+IA0KPj4gUmVnYXJk cywNCj4+IA0KPj4gQ2hyaXN0ZXINCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW11c2ljDQo+IA0KPiAtLSANCj4gaHR0cHM6Ly9qaXRzaS5vcmcNCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5n IGxpc3QNCj4gbW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQo= From bernard_aboba@hotmail.com Tue Jun 25 10:20:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9233E21F9AEE for ; Tue, 25 Jun 2013 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF4pltkSd8Ji for ; Tue, 25 Jun 2013 10:20:34 -0700 (PDT) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id E51C921F96F5 for ; Tue, 25 Jun 2013 10:20:32 -0700 (PDT) Received: from BLU401-EAS82 ([65.55.116.73]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jun 2013 10:20:32 -0700 X-TMN: [IlkZKjbQKVMgN4IAd2RcRTYO4bIyq0Uh] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-C0E01066-DC61-4B51-8AF5-48A166A5F814" Content-Transfer-Encoding: 7bit References: <7594FB04B1934943A5C02806D1A2204B1C3B8F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3B8FA1@ESESSMB209.ericsson.se> <2DFFC9BD-3B84-41C6-BC6B-9743CEB10059@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3B9105@ESESSMB209.ericsson.se> <27108551-D2EC-4A45-8EE6-07053873F61D@csperkins.org> <51C86891.5090203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3B97B2@ESESSMB209.ericsson.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3B97B2@ESESSMB209.ericsson.se> Date: Tue, 25 Jun 2013 10:20:31 -0700 To: Christer Holmberg X-OriginalArrivalTime: 25 Jun 2013 17:20:32.0580 (UTC) FILETIME=[4C2DF040:01CE71C8] Cc: Colin Perkins , Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:20:42 -0000 --Apple-Mail-C0E01066-DC61-4B51-8AF5-48A166A5F814 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLiANCg0KT24gSnVuIDI0LCAyMDEzLCBhdCAxMTo0MyBBTSwgIkNocmlzdGVyIEhvbG1iZXJn IiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPiBIaSBCZXJuYXJk LA0KPiAgDQo+IElmIEkgdW5kZXJzdG9vZCB5b3UgY29ycmVjdGx5LCB5b3VyIHN1Z2dlc3Rpb24g d2FzIHRvIGRvY3VtZW50IHRoZSBydWxlIGluIGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aXBsZXgt Z3VpZGVsaW5lcy4NCj4gIA0KPiBBcyB0aGUgYXV0aG9ycyBvZiB0aGF0IGRyYWZ0IGFyZSBtb3N0 IGxpa2VseSByZWFkaW5nIHRoaXMsIGl0IHdvdWxkIGJlIG5pY2UgdG8gZ2V0IHRoZWlyIGlucHV0 LiBGb3JtYWxseSwgb2YgY291cnNlLCB0aGUgd29yayB3b3VsZCBoYXZlIHRvIGJlIGRvbmUgaW4g QVZUQ09SRS4NCj4gIA0KPiBSZWdhcmRzLA0KPiAgDQo+IENocmlzdGVyDQo+ICANCj4gTMOkaGV0 dMOkasOkOiBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbV0g DQo+IEzDpGhldGV0dHk6IDI0LiBrZXPDpGt1dXRhIDIwMTMgMjA6MTENCj4gVmFzdGFhbm90dGFq YTogUGF1bCBLeXppdmF0OyBDb2xpbiBQZXJraW5zDQo+IEtvcGlvOiBtbXVzaWNAaWV0Zi5vcmc7 IENocmlzdGVyIEhvbG1iZXJnDQo+IEFpaGU6IFJFOiBbTU1VU0lDXSBERUNJU0lPTjogVW5pcXVl IFBUIHZhbHVlL2NvZGVjIGNvbmZpZ3VyYXRpb24gbWFwcGluZyBpbiBhIEJVTkRMRSBncm91cCBb V0FTOiBCVU5ETEUgVEVYVDogRGUtbXV4IHByb2NlZHVyZXMgKEp1bmUgMTl0aCldDQo+ICANCj4g SSBhZ3JlZSB3aXRoIHRoaXMgLSBzdXBwb3J0IGJvdGggUTEgYW5kIHRoZSAocmVmb3JtdWxhdGVk KSBRMi4gIA0KPiAgDQo+ID4gRGF0ZTogTW9uLCAyNCBKdW4gMjAxMyAxMTo0MTowNSAtMDQwMA0K PiA+IEZyb206IHBreXppdmF0QGFsdW0ubWl0LmVkdQ0KPiA+IFRvOiBjc3BAY3NwZXJraW5zLm9y Zw0KPiA+IENDOiBtbXVzaWNAaWV0Zi5vcmc7IGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bQ0KPiA+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBERUNJU0lPTjogVW5pcXVlIFBUIHZhbHVlL2Nv ZGVjIGNvbmZpZ3VyYXRpb24gbWFwcGluZyBpbiBhIEJVTkRMRSBncm91cCBbV0FTOiBCVU5ETEUg VEVYVDogRGUtbXV4IHByb2NlZHVyZXMgKEp1bmUgMTl0aCldDQo+ID4gDQo+ID4gSSdsbCBzdXBw b3J0IGJvdGggUTEgYW5kIFEyLg0KPiA+IA0KPiA+IFRoYW5rcywNCj4gPiBQYXVsDQo+ID4gDQo+ ID4gT24gNi8yNC8xMyA4OjAxIEFNLCBDb2xpbiBQZXJraW5zIHdyb3RlOg0KPiA+ID4gT24gMjQg SnVuIDIwMTMsIGF0IDEyOjU1LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gPiA+Pj4gQ2hy aXN0ZXIsDQo+ID4gPj4+DQo+ID4gPj4+IEZvciBRMSAtIEkgYWdyZWUuDQo+ID4gPj4+DQo+ID4g Pj4+IEZvciBRMiAtIEkgYWdyZWUgdGhhdCB3ZSBuZWVkIGV4cGxpY2l0IHRleHQgc29tZXdoZXJl Lg0K --Apple-Mail-C0E01066-DC61-4B51-8AF5-48A166A5F814 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+WWVzLiZu YnNwOzwvZGl2PjxkaXY+PGJyPk9uIEp1biAyNCwgMjAxMywgYXQgMTE6NDMgQU0sICJDaHJpc3Rl ciBIb2xtYmVyZyIgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0 ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLlNoa3Bvc3RpdHl5bGkxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gNzAuODVwdCAyLjBjbTt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBCZXJuYXJkLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBJIHVuZGVyc3Rvb2QgeW91IGNvcnJlY3RseSwgeW91 ciBzdWdnZXN0aW9uIHdhcyB0byBkb2N1bWVudCB0aGUgcnVsZSBpbiBkcmFmdC1pZXRmLWF2dGNv cmUtbXVsdGlwbGV4LWd1aWRlbGluZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFzIHRoZSBhdXRob3JzIG9mIHRoYXQgZHJhZnQgYXJlIG1vc3QgbGlrZWx5IHJlYWRpbmcg dGhpcywgaXQgd291bGQgYmUgbmljZSB0byBnZXQgdGhlaXIgaW5wdXQuIEZvcm1hbGx5LCBvZiBj b3Vyc2UsIHRoZSB3b3JrIHdvdWxkIGhhdmUgdG8gYmUNCiBkb25lIGluIEFWVENPUkUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkzDpGhldHTDpGrDpDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gQmVybmFyZCBBYm9iYSBbPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmRfYWJvYmFA aG90bWFpbC5jb20iPm1haWx0bzpiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPC9hPl0NCjxicj4N CjxiPkzDpGhldGV0dHk6PC9iPiAyNC4ga2Vzw6RrdXV0YSAyMDEzIDIwOjExPGJyPg0KPGI+VmFz dGFhbm90dGFqYTo8L2I+IFBhdWwgS3l6aXZhdDsgQ29saW4gUGVya2luczxicj4NCjxiPktvcGlv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9h PjsgQ2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5BaWhlOjwvYj4gUkU6IFtNTVVTSUNdIERFQ0lT SU9OOiBVbmlxdWUgUFQgdmFsdWUvY29kZWMgY29uZmlndXJhdGlvbiBtYXBwaW5nIGluIGEgQlVO RExFIGdyb3VwIFtXQVM6IEJVTkRMRSBURVhUOiBEZS1tdXggcHJvY2VkdXJlcyAoSnVuZSAxOXRo KV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SSBhZ3JlZSB3aXRoIHRoaXMgLSBzdXBwb3J0IGJvdGggUTEgYW5kIHRoZSAo cmVmb3JtdWxhdGVkKSBRMi4gJm5ic3A7PGJyPg0KJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7IERhdGU6IE1vbiwgMjQgSnVuIDIwMTMgMTE6NDE6MDUgLTA0MDA8YnI+DQomZ3Q7IEZyb206 IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1 Ij48c3BhbiBsYW5nPSJFTi1VUyI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCiZndDsgVG86IDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YSBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmciPjxzcGFuIGxhbmc9IkVOLVVT Ij5jc3BAY3NwZXJraW5zLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQomZ3Q7IENDOiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOm1t dXNpY0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gbGFu Zz0iRU4tVVMiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbTU1VU0lD XSBERUNJU0lPTjogVW5pcXVlIFBUIHZhbHVlL2NvZGVjIGNvbmZpZ3VyYXRpb24gbWFwcGluZyBp biBhIEJVTkRMRSBncm91cCBbV0FTOiBCVU5ETEUgVEVYVDogRGUtbXV4IHByb2NlZHVyZXMgKEp1 bmUgMTl0aCldPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEknbGwgc3VwcG9ydCBib3RoIFExIGFuZCBR Mi48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQom Z3Q7IFBhdWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gNi8yNC8xMyA4OjAxIEFNLCBDb2xpbiBQ ZXJraW5zIHdyb3RlOjxicj4NCiZndDsgJmd0OyBPbiAyNCBKdW4gMjAxMywgYXQgMTI6NTUsIENo cmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IENocmlzdGVyLDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRm9yIFExIC0gSSBh Z3JlZS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEZvciBR MiAtIEkgYWdyZWUgdGhhdCB3ZSBuZWVkIGV4cGxpY2l0IHRleHQgc29tZXdoZXJlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCg0KDQo8L2Rpdj48L2Jsb2Nr cXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-C0E01066-DC61-4B51-8AF5-48A166A5F814-- From pkyzivat@alum.mit.edu Tue Jun 25 10:26:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205A021E8091 for ; Tue, 25 Jun 2013 10:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLuewFTlAQ3R for ; Tue, 25 Jun 2013 10:26:53 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 463BB21E80A8 for ; Tue, 25 Jun 2013 10:26:51 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id sgfX1l0030vyq2s57hSrqc; Tue, 25 Jun 2013 17:26:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id shSr1l00V3ZTu2S3RhSrDw; Tue, 25 Jun 2013 17:26:51 +0000 Message-ID: <51C9D2DA.7090703@alum.mit.edu> Date: Tue, 25 Jun 2013 13:26:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372181211; bh=AZudjk3mshDb4AEgCHmTA+CxhtRbjGuoe+PGY8Q8j68=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WruNBr1nQ2Bvn5XJED10fSZGRT9vn1YwmPAgkWAi+Hrypy7/fy9/9SeZ3Gj2vbLA8 uLTS44c0Oq5y1GswFTA+QzvdTIv+XhC89fqDA8LdN5BtW9AGmnFEHp94KOh93lftcK ZeyCvqo3ukgK131s5Qai6ESxd2WAJ8d+/h6A3WI7ewQvBI20uKg5pGWobw9cWOJLOJ ngvKs6gpAlM1KT0bnPdRV6TuJjmXKPh5+Tqzz1Rus+XLOqHDeU+gXG1PgcUqjZjYS4 ga5NaKGMOx6CmquiD+TY7d2NDx280vsZkifU1jxOwKpArQ81836qi4ZEA9NsixWnwS gV+S2CutmaDFA== Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:26:58 -0000 I guess if you want to call this a "default" MTI mechanism *for RTP*, then I won't object. But doing so is mostly stating the obvious. The reason it can be the default is because there is no way to have an RTP m-line without a PT. So if you are bundling RTP m-lines, then you have PT available on every m-line to use for associating packets with m-lines. But that is only sufficient if a given PT only appears on a single m-line. Its also insufficient if there are non-RTP m-lines. If you choose to have non-RTP m-lines in the bundle, or multiple RTP m-lines with the same PT, then you are obligated to support some other mechanism, and for it to be signaled in such a way that both sides will understand what it is. Thanks, Paul On 6/25/13 7:34 AM, Christer Holmberg wrote: > Hi, > > Emil suggested that the default, “MTI”, mechanism for mapping RTP data > to m- lines should be based on PT. Applications are allowed to use > whatever other mechanisms, but usage of such mechanisms must be > negotiated (or, applications need to have some other means knowing that > the other endpoint support such mechanisms). > > *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP > data to m- lines? > > *Q4*: If Q3, do we mandate applications to support, and use (unless > applications are made aware of other mechanisms supported by all > endpoints) PT for mapping received RTP media? > > This means that, when mapping RTP to m- lines is required (whether it is > always mandated is discussed in another thread), within a BUNDLE group > each PT value must be unique to an individual m- line. > > NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”, > please indicate which mechanism you prefer J > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Tue Jun 25 10:44:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0660221E8099 for ; Tue, 25 Jun 2013 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.503 X-Spam-Level: X-Spam-Status: No, score=0.503 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym1Hl4ED7NF0 for ; Tue, 25 Jun 2013 10:44:05 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id C5D8F21E80AC for ; Tue, 25 Jun 2013 10:44:00 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id scRv1l0021vXlb859hjz8D; Tue, 25 Jun 2013 17:43:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id shjz1l00L3ZTu2S3dhjzq7; Tue, 25 Jun 2013 17:43:59 +0000 Message-ID: <51C9D6DE.3090509@alum.mit.edu> Date: Tue, 25 Jun 2013 13:43:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51C9CD45.3050404@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372182239; bh=u1OMp+OvBHtQBEiww3Cje5kw+QxOfz1PRNbYpjH2Iz4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T699IhSmTzijKtUhOhCI7Lr8wH8RuqzlqoDX8kVBaQdfBLhhfqsmw+St8ID4yVrIV Z/rZD9TwmWuXlxMgpxc+6IDWuEUBfIno+oCfeUCDQdtTy/ZoaoWGy7EoQvdMpmfSrB kxVpOvTGtuhg+PYmuGuMdwKWOShMemk4b5w+YmoAAnPCEVtTEihzqBl98WynzAVPhV Iz6yWK2XqAm6bEsxP3FShQZV36f/bEhLIDVM6VkrQyL51PcVmFYiedXwjiZzVv+Ldm ovBq7Xge3l90vySU2oTG110mTMj8I3GyonkMWIe0qbmgSFXFiDKKYV4Ufk8yi2+AaY QyH0S9oNBgqzA== Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:44:10 -0000 On 6/25/13 1:11 PM, Bernard Aboba wrote: > Agree with Emil that "default" makes more sense for use of PT for mapping to an m line. If a=SSRC is specified on an m line then that should take precedence over PT. I don't think "takes precedence" is quite the right way to think about it. You support some number of mechanisms: PT only, or PT & SSRC, or ... For the set of mechanisms you support, for each m-line you have some values for some of the mechanisms. When you receive a packet, attempt to match it to each m-line based on the the values it contains and those specified for each m-line. If a packet matches more than one m-line, then choose the m-line that matches the most values. If that still matches multiple m-lines, then there is an error. You can statically analyze an offer and a candidate answer and determine if there can be any non-unique matches. If so, then you should not send that answer. Instead, send one that is more unique, or else reject some of the m-lines, or refuse to bundle some of them. You can also statically analyze the O/A and determine a precedence for applying the mechanisms that minimizes the checking required for doing the matching. When using PT & SSRC, depending on the details it may be favorable to check one or the other first. Thanks, Paul > On Jun 25, 2013, at 10:03 AM, "Emil Ivov" wrote: > >> >> >> On 25.06.13, 13:34, Christer Holmberg wrote: >>> Hi, >>> >>> Emil suggested that the default, “MTIâ€, mechanism for mapping RTP data >>> to m- lines should be based on PT. >> >> Actually, what I thought was important was having it as the "default" mechanism. Personally I don't mind having it as MTI might but it might be a tad too strong: implementations that deem PT demux insufficient and wouldn't want to use bundle without it, don't need implement it. >> >> We should probably also agree on how an answerer can determine whether or not it is expected to provide additional demuxing information (e.g. SSRCs) or if the offerer is using the default mechanism. >> >> One way would be for the answerer to inspect all m= lines and try to detect duplicating PTs. This could be a bit clumsy though. The offerer could expect SSRCs but its first offer may not yet contain PT reuse. >> >> With that in mind ... (more below) >> >>> Applications are allowed to use >>> whatever other mechanisms, but usage of such mechanisms must be >>> negotiated (or, applications need to have some other means knowing that >>> the other endpoint support such mechanisms). >>> >>> *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP >>> data to m- lines? >> >> I am in favour of having a "default" one. >> >> Without this BUNDLE would have to be an abstract spec and I don't see why we would want to leave it that way. >> >>> *Q4*: If Q3, do we mandate applications to support, and use (unless >>> applications are made aware of other mechanisms supported by all >>> endpoints) PT for mapping received RTP media? >> >> In favour. >> >> Cheers, >> Emil >> >>> >>> This means that, when mapping RTP to m- lines is required (whether it is >>> always mandated is discussed in another thread), within a BUNDLE group >>> each PT value must be unique to an individual m- line. >>> >>> NOTE: If your answer to Q3 is “yesâ€, but your answer to Q4 is “noâ€, >>> please indicate which mechanism you prefer J >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> -- >> https://jitsi.org >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Tue Jun 25 22:24:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66B21E808E for ; Tue, 25 Jun 2013 22:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGf5O2xWW3yi for ; Tue, 25 Jun 2013 22:24:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 002B221E80EF for ; Tue, 25 Jun 2013 22:24:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4E3539E176 for ; Wed, 26 Jun 2013 07:24:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lfof4dlEflI for ; Wed, 26 Jun 2013 07:24:42 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D6FAF39E05D for ; Wed, 26 Jun 2013 07:24:40 +0200 (CEST) Message-ID: <51CA7B2D.5050601@alvestrand.no> Date: Wed, 26 Jun 2013 07:25:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------000608080100000607000100" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 05:24:54 -0000 This is a multi-part message in MIME format. --------------000608080100000607000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/25/2013 01:34 PM, Christer Holmberg wrote: > > Hi, > > Emil suggested that the default, "MTI", mechanism for mapping RTP data > to m- lines should be based on PT. Applications are allowed to use > whatever other mechanisms, but usage of such mechanisms must be > negotiated (or, applications need to have some other means knowing > that the other endpoint support such mechanisms). > > *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP > data to m- lines? > No. This makes the assumption that all applications have the need to map RTP data to m-lines; this assumption is not proven (and probably cannot be - it's hard to prove a negative. It might be possible to disprove it, though). > *Q4*: If Q3, do we mandate applications to support, and use (unless > applications are made aware of other mechanisms supported by all > endpoints) PT for mapping received RTP media? > If the WG disagrees with me on Q3, it might as well go down this path. I have no strong opinion. > This means that, when mapping RTP to m- lines is required (whether it > is always mandated is discussed in another thread), within a BUNDLE > group each PT value must be unique to an individual m- line. > > NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no", > please indicate which mechanism you prefer J > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------000608080100000607000100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/25/2013 01:34 PM, Christer Holmberg wrote:

Hi,

 

Emil suggested that the default, “MTI”, mechanism for mapping RTP data to m- lines should be based on PT. Applications are allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).

 

Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to m- lines?


No. This makes the assumption that all applications have the need to map RTP data to m-lines; this assumption is not proven (and probably cannot be - it's hard to prove a negative. It might be possible to disprove it, though).

 

Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media?


If the WG disagrees with me on Q3, it might as well go down this path. I have no strong opinion.

 

This means that, when mapping RTP to m- lines is required (whether it is always mandated is discussed in another thread), within a BUNDLE group each PT value must be unique to an individual m- line.

 

NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”, please indicate which mechanism you prefer J

 

Regards,

 

Christer



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

--------------000608080100000607000100-- From christer.holmberg@ericsson.com Tue Jun 25 23:58:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7263D11E810A for ; Tue, 25 Jun 2013 23:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-7C21hDoSwM for ; Tue, 25 Jun 2013 23:58:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C527221E808E for ; Tue, 25 Jun 2013 23:58:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7f146d00000411d-f8-51ca9120912f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 90.F9.16669.0219AC15; Wed, 26 Jun 2013 08:58:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 08:58:40 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NP//+aaA///Dn0CAAGQQgP/+2P9g Date: Wed, 26 Jun 2013 06:58:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB686@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> <51C9B3A9.2000106@alum.mit.edu> In-Reply-To: <51C9B3A9.2000106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra7CxFOBBss7TC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjUsMW5oKT6hXTz2xgamDcL9/FyMkhIWAi MXnOJlYIW0ziwr31bF2MXBxCAocZJeZ09bFCOIsYJVqONgFlODjYBCwkuv9pg5giAhoSk7aq gZjMAuoSVxcHgYwRFkiWmPLmLxuILSKQInF3/3l2CNtN4sqFp0wgNouAqsSW0x+ZQVp5BXwl Vi4NBAkLCVxllFj/EqyEU0BH4mvXR7AxjECXfT+1BizOLCAucevJfCaIiwUkluw5zwxhi0q8 fPwP6hNFifanDYwQ9ToSC3Z/YoOwtSWWLXwNVs8rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYmTPTczMSS833MQIjI6DW37r7mA8dU7kEKM0B4uSOO+HU7sChQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDynT5QEB3DK54vcjN77++NCpusDRJn5qw4mNdl0Bm7ol+p8pnk1H1zjfUk ynV8nXb07E0vTDif4OO475as6u/LvbxNQf6Hnd6b18kvt/b8X7C8XmnOljKeoBNCqm5SX07d FEo1XtFpZrDOMWu3/5MlcwK9t6ieTdrloiJuXL3o17ayt8+4U5RYijMSDbWYi4oTAYbAH5Bc AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 06:58:47 -0000 Hi, >>> I started this issue, so I'll make my case again. >>> >>> There must be a reason to have multiple m-lines in the bundle. (If=20 >>> there isn't, leave them out, and then maybe you won't need bundle at=20 >>> all.) >>> >>> I assert that in all cases that reason can't be realized without being = able to associate packets with the corresponding m-line. >> >> The reason for having m- lines could be because different characteristic= s (bandwidth, priority etc) is requested from the NETWORK, while the endpoi= nt application that receive the data might not care which m- line it belong= s to. > > Can you be specific? I'm afraid not - I was just speculating :) > Note that if you are requesting different characteristics from the NETWOR= K, then the NETWORK must be able to distinguish the packets in order to=20 > apply those characteristics properly. So then *it* will need a way to dis= tinguish. If so, then the endpoints can too. True. What about the direction attributes? The network may use the information e.= g. for bandwidth calculation purpose, but it does not need to distinguish t= he packets. Anyway, I personally don't have any strong preference, so I'd like to hear = from people who DO have an opinion :) > If you are just requesting characteristics for the entire bundle, then it= should be possible to do it with fewer m-lines, that you can then associat= e with. > >>> The exception to this are those packets that deal only with those=20 >>> aspects of the bundle that are common. The most obvious example of this= is ICE. But if *all* packets are common to all the m-lines then there is n= o reason for the bundle. >> >> Correct. For ICE we explicitly say that the STUN messages apply to the w= hole BUNDLE group. > > It can in principle apply to more than just ICE. > > Somewhere I commented that the field describes more than just the= low level transport protocol. It often describes a whole protocol stack=20 > with many layers. When we bundle multiple m-lines with different = fields, they have different stacks. For the bundle to be valid, at least th= e=20 > bottom level of each stack must be the same. (E.g., UDP.)=20 I think we should use whatever "stack" is referenced in the 5-tuple definit= ion. > There may be more layers in common among some or all of the stacks. When = some of the m-lines have multiple layers in common, then there=20 > may be some packets that pertain to housekeeping of the layer, and so nee= d not be associated with one particular m-line. > > For instance, *in principle* one could bundle multiple DTLS/SCTP m-lines = together. Then there could be some SCTP housekeeping packets that can't=20 > be associated with a single m-line, but for this to work, SCTP payload pa= ckets would need to be distinguishable, probably by SCTP port. (Note, I'm n= ot=20 > sure if there are any SCTP packets that don't have an SCTP port, so this = might not be a good example. And of course for this example to work there=20 > would need to be a way to specify the SCTP port in SDP for DTLS/SCTP.) > > AFAIK, for stuff *currently* under discussion only ICE falls into this ca= tegory. But if we are going to define bundle so it can be=20 > applied to future cases then we need to phrase the constraint properly. Sure, but it is not (I hope) the task of BUNDLE to define HOW data is mappe= d to m- lines for all kind of transport protocols.=20 We are going to specify/reference something for RTP, but do you think BUNDL= E should also e.g. define a mechanism for transporting SCTP ports in SDP? W= e COULD (I assume it would be a rather simply task), but should we? Regards, Christer > > > > > On 6/25/13 7:16 AM, Christer Holmberg wrote: >> Hi, >> >> There has been some discussions about whether BUNDLE should mandate=20 >> that users are mandated to *always* (no matter what transport=20 >> protocols are used in the BUNDLE group) have a mechanism to map=20 >> received data to an m- line, or whether it from a generic BUNDLE=20 >> perspective should be optional - IF there would be cases where it's not = needed. >> >> We haven't had that much discussion about it yet, so I will not ask a=20 >> DECISION question at this point, but I would really like to get some=20 >> input from people who have opinions about this :) >> >> Note that this issue is NOT about HOW to map data to m- lines (there=20 >> will be a separate question about how to map RTP to m- lines etc), or=20 >> whether we should allow usage of the same PT value (for the same=20 >> codec >> configuration) in multiple m- lines, but more about a general rule. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Jun 26 00:05:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B197221E808E for ; Wed, 26 Jun 2013 00:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqbKrmySaaQD for ; Wed, 26 Jun 2013 00:05:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C521E80B4 for ; Wed, 26 Jun 2013 00:05:04 -0700 (PDT) X-AuditID: c1b4fb30-b7fab6d00000040c-12-51ca929fe0d5 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 71.4B.01036.F929AC15; Wed, 26 Jun 2013 09:05:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:05:02 +0200 From: Christer Holmberg To: Bernard Aboba , Emil Ivov Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAHdeyAAABKWwAAIT/5AA== Date: Wed, 26 Jun 2013 07:05:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB6D3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51C9CD45.3050404@jitsi.org> 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.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvre78SacCDV7uELbYv+Qys8WanRNY LKYuf8ziwOzxuOcMm8eSJT+ZPP6/CQxgjuKySUnNySxLLdK3S+DKuHlIvWCTbMX3S99ZGhgv yHQxcnJICJhIPOy+xAphi0lcuLeerYuRi0NI4DCjxKxzi1ghnEWMEk3dW4AcDg42AQuJ7n/a IA0iAl4S3+d/YAcJMwuoS1xdHARiCgvESezZZQZiigjESxyaZQRR7CRxr2M2E4jNIqAq8etS EzOIzSvgK3Hk4AuwC4QE5jJK3GorAbE5BWwlfs6dxAhiMwJd9v3UGrBeZgFxiVtP5jNBXCwg sWTPeWYIW1Ti5eN/UJ8oSrQ/bWCEOExTYv0ufYhWRYkp3Q/ZIdYKSpyc+YRlAqPYLCRTZyF0 zELSMQtJxwJGllWM7LmJmTnp5eabGIGRcnDLb4MdjJvuix1ilOZgURLn/XRqV6CQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxjNFP75+vNN2N2RTvscqTgfjpZdEvk5fuuSFmneG6aPnYvKm vna1M85rNZosur901rJ3wguLFkz5bvnCN22WYMajTZ1tD/n0pE9NNc0QM9/a+zJ4AeM13V0n 4xN3pEQYnnR/Ind65Yr9DA2b1Odw1G3dczxD1li9faZx9L/bmSxLbhTvTuuzmq7EUpyRaKjF XFScCAAprKLEYgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 07:05:20 -0000 SGksDQoNCj4gQWdyZWUgd2l0aCBFbWlsIHRoYXQgImRlZmF1bHQiIG1ha2VzIG1vcmUgc2Vuc2Ug Zm9yIHVzZSBvZiBQVCBmb3IgbWFwcGluZyB0byBhbiBtIGxpbmUuIElmIGE9U1NSQyBpcyBzcGVj aWZpZWQgb24gYW4gbSBsaW5lIHRoZW4gdGhhdCBzaG91bGQgdGFrZSBwcmVjZWRlbmNlIG92ZXIg UFQuDQoNClN1cmUsIGJ1dCBhPVNTUkMgd291bGQgYmUgIndoYXRldmVyIG90aGVyIG1lY2hhbmlz bSIgOikNCg0KVGhlIHF1ZXN0aW9uIGlzLCB0aG91Z2gsIGhvdyBtdWNoIEJVTkRMRSBzaG91bGQg dGFsayBhYm91dCAib3RoZXIgbWVjaGFuaXNtcyIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQo+IE9uIDI1LjA2LjEzLCAxMzozNCwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+PiBI aSwNCj4+IA0KPj4gRW1pbCBzdWdnZXN0ZWQgdGhhdCB0aGUgZGVmYXVsdCwg4oCcTVRJ4oCdLCBt ZWNoYW5pc20gZm9yIG1hcHBpbmcgUlRQIA0KPj4gZGF0YSB0byBtLSBsaW5lcyBzaG91bGQgYmUg YmFzZWQgb24gUFQuDQo+IA0KPiBBY3R1YWxseSwgd2hhdCBJIHRob3VnaHQgd2FzIGltcG9ydGFu dCB3YXMgaGF2aW5nIGl0IGFzIHRoZSAiZGVmYXVsdCIgbWVjaGFuaXNtLiBQZXJzb25hbGx5IEkg ZG9uJ3QgbWluZCBoYXZpbmcgaXQgYXMgTVRJIG1pZ2h0IGJ1dCBpdCBtaWdodCBiZSBhIHRhZCB0 b28gc3Ryb25nOiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkZWVtIFBUIGRlbXV4IGluc3VmZmljaWVu dCBhbmQgd291bGRuJ3Qgd2FudCB0byB1c2UgYnVuZGxlIHdpdGhvdXQgaXQsIGRvbid0IG5lZWQg aW1wbGVtZW50IGl0Lg0KPiANCj4gV2Ugc2hvdWxkIHByb2JhYmx5IGFsc28gYWdyZWUgb24gaG93 IGFuIGFuc3dlcmVyIGNhbiBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgaXQgaXMgZXhwZWN0ZWQg dG8gcHJvdmlkZSBhZGRpdGlvbmFsIGRlbXV4aW5nIGluZm9ybWF0aW9uIChlLmcuIFNTUkNzKSBv ciBpZiB0aGUgb2ZmZXJlciBpcyB1c2luZyB0aGUgZGVmYXVsdCBtZWNoYW5pc20uDQo+IA0KPiBP bmUgd2F5IHdvdWxkIGJlIGZvciB0aGUgYW5zd2VyZXIgdG8gaW5zcGVjdCBhbGwgbT0gbGluZXMg YW5kIHRyeSB0byBkZXRlY3QgZHVwbGljYXRpbmcgUFRzLiBUaGlzIGNvdWxkIGJlIGEgYml0IGNs dW1zeSB0aG91Z2guIFRoZSBvZmZlcmVyIGNvdWxkIGV4cGVjdCBTU1JDcyBidXQgaXRzIGZpcnN0 IG9mZmVyIG1heSBub3QgeWV0IGNvbnRhaW4gUFQgcmV1c2UuDQo+IA0KPiBXaXRoIHRoYXQgaW4g bWluZCAuLi4gKG1vcmUgYmVsb3cpDQo+IA0KPj4gQXBwbGljYXRpb25zIGFyZSBhbGxvd2VkIHRv IHVzZQ0KPj4gd2hhdGV2ZXIgb3RoZXIgbWVjaGFuaXNtcywgYnV0IHVzYWdlIG9mIHN1Y2ggbWVj aGFuaXNtcyBtdXN0IGJlIA0KPj4gbmVnb3RpYXRlZCAob3IsIGFwcGxpY2F0aW9ucyBuZWVkIHRv IGhhdmUgc29tZSBvdGhlciBtZWFucyBrbm93aW5nIA0KPj4gdGhhdCB0aGUgb3RoZXIgZW5kcG9p bnQgc3VwcG9ydCBzdWNoIG1lY2hhbmlzbXMpLg0KPj4gDQo+PiAqUTMqOiBEbyB3ZSBuZWVkIHRv IHNwZWNpZnkgYSBkZWZhdWx0LCBNVEksIG1lY2hhbmlzbSBmb3IgbWFwcGluZyBSVFAgDQo+PiBk YXRhIHRvIG0tIGxpbmVzPw0KPiANCj4gSSBhbSBpbiBmYXZvdXIgb2YgaGF2aW5nIGEgImRlZmF1 bHQiIG9uZS4NCj4gDQo+IFdpdGhvdXQgdGhpcyBCVU5ETEUgd291bGQgaGF2ZSB0byBiZSBhbiBh YnN0cmFjdCBzcGVjIGFuZCBJIGRvbid0IHNlZSB3aHkgd2Ugd291bGQgd2FudCB0byBsZWF2ZSBp dCB0aGF0IHdheS4NCj4gDQo+PiAqUTQqOiBJZiBRMywgZG8gd2UgbWFuZGF0ZSBhcHBsaWNhdGlv bnMgdG8gc3VwcG9ydCwgYW5kIHVzZSAodW5sZXNzIA0KPj4gYXBwbGljYXRpb25zIGFyZSBtYWRl IGF3YXJlIG9mIG90aGVyIG1lY2hhbmlzbXMgc3VwcG9ydGVkIGJ5IGFsbA0KPj4gZW5kcG9pbnRz KSBQVCBmb3IgbWFwcGluZyByZWNlaXZlZCBSVFAgbWVkaWE/DQo+IA0KPiBJbiBmYXZvdXIuDQo+ IA0KPiBDaGVlcnMsDQo+IEVtaWwNCj4gDQo+PiANCj4+IFRoaXMgbWVhbnMgdGhhdCwgd2hlbiBt YXBwaW5nIFJUUCB0byBtLSBsaW5lcyBpcyByZXF1aXJlZCAod2hldGhlciBpdCANCj4+IGlzIGFs d2F5cyBtYW5kYXRlZCBpcyBkaXNjdXNzZWQgaW4gYW5vdGhlciB0aHJlYWQpLCB3aXRoaW4gYSBC VU5ETEUgDQo+PiBncm91cCBlYWNoIFBUIHZhbHVlIG11c3QgYmUgdW5pcXVlIHRvIGFuIGluZGl2 aWR1YWwgbS0gbGluZS4NCj4+IA0KPj4gTk9URTogSWYgeW91ciBhbnN3ZXIgdG8gUTMgaXMg4oCc eWVz4oCdLCBidXQgeW91ciBhbnN3ZXIgdG8gUTQgaXMg4oCcbm/igJ0sIA0KPj4gcGxlYXNlIGlu ZGljYXRlIHdoaWNoIG1lY2hhbmlzbSB5b3UgcHJlZmVyIEoNCj4+IA0KPj4gUmVnYXJkcywNCj4+ IA0KPj4gQ2hyaXN0ZXINCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVz aWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11 c2ljDQo+IA0KPiAtLQ0KPiBodHRwczovL2ppdHNpLm9yZw0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2ljIG1haWxpbmcgbGlzdA0K PiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMNCg== From christer.holmberg@ericsson.com Wed Jun 26 00:11:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED13821E8119 for ; Wed, 26 Jun 2013 00:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m76IGKZfPIU0 for ; Wed, 26 Jun 2013 00:11:40 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 68C4521E808E for ; Wed, 26 Jun 2013 00:11:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7f146d00000411d-11-51ca942bdbf5 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 36.BB.16669.B249AC15; Wed, 26 Jun 2013 09:11:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:11:39 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAIStwAACDM+QA= Date: Wed, 26 Jun 2013 07:11:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB713@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51C9D2DA.7090703@alum.mit.edu> In-Reply-To: <51C9D2DA.7090703@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvra72lFOBBmvPKVlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGjq+1Bb3CFY+P/GRsYJzE38XIySEhYCKx ePoSVghbTOLCvfVsXYxcHEIChxkl1n3azgrhLGKUODj5GnMXIwcHm4CFRPc/bZAGEQFfiWeP b7OBhIUF4iT27DIDMUUE4iUOzTKCqLCS+N2wjxHEZhFQlXj1vo8FpIQXqPNmqzNIWEggX+LC syawCzgFdCRuPWlgBrEZga75fmoNE4jNLCAOFJ/PBHGlgMSSPeeZIWxRiZeP/0FdryjR/rSB EaJeR2LB7k9sELa2xLKFr8HqeQUEJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM7LmJmTnp 5YabGIExcHDLb90djKfOiRxilOZgURLn/XBqV6CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG RsGyf/7bBKrzr1bsaLgm8jM88GLLrmSHV/4FFxinOvYmxKRsvZ55etaeT7KR2kUsJ564BBnd tdn+U7jfxD9sys05Wa4P+T47ucW2JDWXZ27/lmtgafD1R9fEC+f4lr9gNtYp+MxfKh1s55Bp cP2ZldN67Q8Rx0Rud7grvTDe/8VLrya0ZM9GJZbijERDLeai4kQAsdwZDE8CAAA= Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 07:11:46 -0000 Hi, > I guess if you want to call this a "default" MTI mechanism *for RTP*, the= n I won't object. Yes, I should have clarified that it was for RTP. > But doing so is mostly stating the obvious. We should be careful to make such assumptions :) > The reason it can be the default is because there is no way to have an RT= P m-line without a PT. So if you are bundling RTP m-lines, then you have PT= available on every m-line to use for associating packets with m-lines. > > But that is only sufficient if a given PT only appears on a single m-line= .=20 Correct, and I think it is good to point that out, eventhough it may seem o= bvious to many. > Its also insufficient if there are non-RTP m-lines. > > If you choose to have non-RTP m-lines in the bundle, or multiple RTP m-li= nes with the same PT, then you are obligated to support some other=20 > mechanism, and for it to be signaled in such a way that both sides will u= nderstand what it is. The mechanism to find the right "type" of m- line is a separate issue :) Regards, Christer On 6/25/13 7:34 AM, Christer Holmberg wrote: > Hi, > > Emil suggested that the default, "MTI", mechanism for mapping RTP data=20 > to m- lines should be based on PT. Applications are allowed to use=20 > whatever other mechanisms, but usage of such mechanisms must be=20 > negotiated (or, applications need to have some other means knowing=20 > that the other endpoint support such mechanisms). > > *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP=20 > data to m- lines? > > *Q4*: If Q3, do we mandate applications to support, and use (unless=20 > applications are made aware of other mechanisms supported by all > endpoints) PT for mapping received RTP media? > > This means that, when mapping RTP to m- lines is required (whether it=20 > is always mandated is discussed in another thread), within a BUNDLE=20 > group each PT value must be unique to an individual m- line. > > NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no",=20 > please indicate which mechanism you prefer J > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Wed Jun 26 00:14:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C030921E808E for ; Wed, 26 Jun 2013 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S67STWoylP4m for ; Wed, 26 Jun 2013 00:14:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0551621E80B4 for ; Wed, 26 Jun 2013 00:14:41 -0700 (PDT) X-AuditID: c1b4fb25-b7fed6d000004760-de-51ca94e06b99 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.CC.18272.0E49AC15; Wed, 26 Jun 2013 09:14:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:14:40 +0200 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAhX+uAAAfyqoA= Date: Wed, 26 Jun 2013 07:14:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB724@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51CA7B2D.5050601@alvestrand.no> In-Reply-To: <51CA7B2D.5050601@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BB724ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7DKacCDQ6dZrM41tfFZjF1+WMW ByaPKxOusHosWfKTKYApissmJTUnsyy1SN8ugSvj/uZfjAXf/SpeLtjA2sA4waWLkZNDQsBE YvXXhywQtpjEhXvr2boYuTiEBA4zShxoucQO4SxilGhfsJmpi5GDg03AQqL7nzZIg4hAsMTy T9vBwsICcRJ7dpmBmCIC8RKHZhlBVFhJdLydzAxiswioSmyauxnM5hXwlWh9/R9srZBAgcSV vinsIDangK7EgQcHWEFsRqBzvp9awwRiMwuIS9x6Mp8J4kwBiSV7zjND2KISLx//Y4WwFSXa nzYwQtTnS8yaso8NYpegxMmZT1gmMIrMQjJqFpKyWUjKIOJ6EjemTmGDsLUlli18zQxh60rM +HeIBVl8ASP7Kkb23MTMnPRyo02MwLg5uOW36g7GO+dEDjFKc7AoifN+PLUrUEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANjceSxXS1fLh0L70/3mnjOesKOiBmT/bY+m8NwfEL8jLiMh+ka C+WDH5lcidh799MjeYl4hkcscc1n5GbrFXYuWDppzd1FTVMPnnI0ns3JcpXvTvwzlx3z3/WJ 7/695syEI1JhGgaMm1d6sRf/q930JdXUcxZb+1zGBVM1sw9x+1i65qycanL2vBJLcUaioRZz UXEiACDOXQZpAgAA Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 07:14:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BB724ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Harald, Just for my clarification: Assuming we are talking about applications using= RTP (instead of ANY BUNDLE application), is your answer to Q3 still "no"? In other words, do you think there might be RTP cases where it is not neede= d to associate the RTP data with an m- line? OR, do you think that BUNDLE simply shouldn't say anything about how to map= RTP packets to m- lines? Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 26. kes=E4kuuta 2013 8:25 To: mmusic@ietf.org Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- lin= e is based on PT? On 06/25/2013 01:34 PM, Christer Holmberg wrote: Hi, Emil suggested that the default, "MTI", mechanism for mapping RTP data to m= - lines should be based on PT. Applications are allowed to use whatever oth= er mechanisms, but usage of such mechanisms must be negotiated (or, applica= tions need to have some other means knowing that the other endpoint support= such mechanisms). Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to= m- lines? No. This makes the assumption that all applications have the need to map RT= P data to m-lines; this assumption is not proven (and probably cannot be - = it's hard to prove a negative. It might be possible to disprove it, though)= . Q4: If Q3, do we mandate applications to support, and use (unless applicati= ons are made aware of other mechanisms supported by all endpoints) PT for m= apping received RTP media? If the WG disagrees with me on Q3, it might as well go down this path. I ha= ve no strong opinion. This means that, when mapping RTP to m- lines is required (whether it is al= ways mandated is discussed in another thread), within a BUNDLE group each P= T value must be unique to an individual m- line. NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no", please = indicate which mechanism you prefer :) Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C3BB724ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Harald,<= /span>

 

Just for my clarificat= ion: Assuming we are talking about applications using RTP (instead of ANY B= UNDLE application), is your answer to Q3 still “no”?

 

In other words, do you= think there might be RTP cases where it is not needed to associate the RTP= data with an m- line?

 

OR, do you think that = BUNDLE simply shouldn’t say anything about how to map RTP packets to = m- lines?

 

Regards,

 

Christer

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Harald Alvestrand
Sent: 26. kes=E4kuuta 2013 8:25
To: mmusic@ietf.org
Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to= m- line is based on PT?

 

On 06/25/2013 01:34 PM, Christer Holmberg wrote:

Hi,

 

Emil suggested that the default, “MTI”, = mechanism for mapping RTP data to m- lines should be based on PT. Applicati= ons are allowed to use whatever other mechanisms, but usage of such mechani= sms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mech= anisms).

 

Q3: Do we need to specify a default, MTI, mec= hanism for mapping RTP data to m- lines?


No. This makes the assumption that all applications have the need to map RT= P data to m-lines; this assumption is not proven (and probably cannot be - = it's hard to prove a negative. It might be possible to disprove it, though)= .


 

Q4: If Q3, do we mandate applications to supp= ort, and use (unless applications are made aware of other mechanisms suppor= ted by all endpoints) PT for mapping received RTP media?


If the WG disagrees with me on Q3, it might as well go down this path. I ha= ve no strong opinion.


 

This means that, when mapping RTP to m- lines is req= uired (whether it is always mandated is discussed in another thread), withi= n a BUNDLE group each PT value must be unique to an individual m- line.

 

NOTE: If your answer to Q3 is “yes”, but= your answer to Q4 is “no”, please indicate which mechanism you= prefer J

 

Regards,

 

Christer




_______________________________________________
mmusic mailing list
mmusic@ietf.org

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


 
--_000_7594FB04B1934943A5C02806D1A2204B1C3BB724ESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Jun 26 00:25:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C5721F8EB2 for ; Wed, 26 Jun 2013 00:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZhRhFmb+Hx4 for ; Wed, 26 Jun 2013 00:25:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D083721E80D7 for ; Wed, 26 Jun 2013 00:25:38 -0700 (PDT) X-AuditID: c1b4fb25-b7fed6d000004760-a4-51ca9770ceee Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A3.9E.18272.0779AC15; Wed, 26 Jun 2013 09:25:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:25:35 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAHdeyAAABKWwAAASPEAAAgyLhA Date: Wed, 26 Jun 2013 07:25:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB755@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51C9CD45.3050404@jitsi.org> <51C9D6DE.3090509@alum.mit.edu> In-Reply-To: <51C9D6DE.3090509@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvrW7B9FOBBitWSllMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGud9LmQsOGFQ0PG1hbWBcoN/FyMkhIWAi 0bhjEyuELSZx4d56ti5GLg4hgcOMEscv3WWCcBYxSjw82c7excjBwSZgIdH9TxukQUTAV+LZ 49tsIGFhgTiJPbvMQEwRgXiJQ7OMICrcJB4tXMwMYrMIqEqs6ACZyMnBC9S56slvZojpBxkl 7r4+yAKS4BTQkWi5MAmsgRHonu+n1oA1MAuIS9x6Mp8J4k4BiSV7zjND2KISLx//g7pfUaL9 aQMjyA3MApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGJkz03M zEkvN9rECIyCg1t+q+5gvHNO5BCjNAeLkjjvx1O7AoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUw9iyYPC9Ozl+cp5Z5ZWfOhDlLO1kn20fxacz7PnP5Zw42s698d9evf6BTfmr+ydI/FTcn vtp3PaF8bl+HQOS1BUvP37v0eun889GCPZ/ShHiMHE9djq3ZkeO8i23ituJ8t29PjKRERHgd okrf6y2etFryX8M+9WM/5POfef718W6Ksp7X4fh4uxJLcUaioRZzUXEiAOfPazRQAgAA Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 07:25:44 -0000 SGksDQoNCj4+IEFncmVlIHdpdGggRW1pbCB0aGF0ICJkZWZhdWx0IiBtYWtlcyBtb3JlIHNlbnNl IGZvciB1c2Ugb2YgUFQgZm9yIG1hcHBpbmcgdG8gYW4gbSBsaW5lLiBJZiBhPVNTUkMgaXMgc3Bl Y2lmaWVkIG9uIGFuIG0gbGluZSB0aGVuIHRoYXQgc2hvdWxkIHRha2UgcHJlY2VkZW5jZSBvdmVy IFBULg0KPg0KPiBJIGRvbid0IHRoaW5rICJ0YWtlcyBwcmVjZWRlbmNlIiBpcyBxdWl0ZSB0aGUg cmlnaHQgd2F5IHRvIHRoaW5rIGFib3V0IGl0Lg0KPg0KPiBZb3Ugc3VwcG9ydCBzb21lIG51bWJl ciBvZiBtZWNoYW5pc21zOiBQVCBvbmx5LCBvciBQVCAmIFNTUkMsIG9yIC4uLg0KPg0KPiBGb3Ig dGhlIHNldCBvZiBtZWNoYW5pc21zIHlvdSBzdXBwb3J0LCBmb3IgZWFjaCBtLWxpbmUgeW91IGhh dmUgc29tZSB2YWx1ZXMgZm9yIHNvbWUgb2YgdGhlIG1lY2hhbmlzbXMuIFdoZW4geW91IHJlY2Vp dmUgYSBwYWNrZXQsIGF0dGVtcHQgdG8gbWF0Y2ggaXQgDQo+IHRvIGVhY2ggbS1saW5lIGJhc2Vk IG9uIHRoZSB0aGUgdmFsdWVzIGl0IGNvbnRhaW5zIGFuZCB0aG9zZSBzcGVjaWZpZWQgZm9yIGVh Y2ggbS1saW5lLiBJZiBhIHBhY2tldCBtYXRjaGVzIG1vcmUgdGhhbiBvbmUgbS1saW5lLCB0aGVu IGNob29zZSB0aGUgbS1saW5lICcNCj4gdGhhdCBtYXRjaGVzIHRoZSBtb3N0IHZhbHVlcy4gSWYg dGhhdCBzdGlsbCBtYXRjaGVzIG11bHRpcGxlIG0tbGluZXMsIHRoZW4gdGhlcmUgaXMgYW4gZXJy b3IuDQo+DQo+IFlvdSBjYW4gc3RhdGljYWxseSBhbmFseXplIGFuIG9mZmVyIGFuZCBhIGNhbmRp ZGF0ZSBhbnN3ZXIgYW5kIGRldGVybWluZSBpZiB0aGVyZSBjYW4gYmUgYW55IG5vbi11bmlxdWUg bWF0Y2hlcy4gSWYgc28sIHRoZW4geW91IHNob3VsZCBub3Qgc2VuZCANCj4gdGhhdCBhbnN3ZXIu IEluc3RlYWQsIHNlbmQgb25lIHRoYXQgaXMgbW9yZSB1bmlxdWUsIG9yIGVsc2UgcmVqZWN0IHNv bWUgb2YgdGhlIG0tbGluZXMsIG9yIHJlZnVzZSB0byBidW5kbGUgc29tZSBvZiB0aGVtLg0KPg0K PiBZb3UgY2FuIGFsc28gc3RhdGljYWxseSBhbmFseXplIHRoZSBPL0EgYW5kIGRldGVybWluZSBh IHByZWNlZGVuY2UgZm9yIGFwcGx5aW5nIHRoZSBtZWNoYW5pc21zIHRoYXQgbWluaW1pemVzIHRo ZSBjaGVja2luZyByZXF1aXJlZCBmb3IgZG9pbmcgdGhlIG1hdGNoaW5nLiANCj4gV2hlbiB1c2lu ZyBQVCAmIFNTUkMsIGRlcGVuZGluZyBvbiB0aGUgZGV0YWlscyBpdCBtYXkgYmUgZmF2b3JhYmxl IHRvIGNoZWNrIG9uZSBvciB0aGUgb3RoZXIgZmlyc3QuDQoNCkkgZG9uJ3QgdGhpbmsgd2Ugc2hv dWxkIHNwZWNpZnkgd2hpY2ggbWVjaGFuaXNtICJ0YWtlcyBwcmVjZWRlbmNlIi4gTXkgc3VnZ2Vz dGlvbiBpcyB0byBkZWZpbmUgdGhlICJkZWZhdWx0IiBvbmUsIGFuZCB0aGVuIHBlb3BsZSBjYW4g dXNlIHdoYXRldmVyIG90aGVyIG1lY2hhbmlzbXMgaWYgdGhleSB3YW50LiBPbmUgcXVlc3Rpb24g aXMgd2hldGhlciB3ZSBzaG91bGQgZXZlbiBtZW50aW9uIG90aGVyIG1lY2hhbmlzbXMuDQoNCihJ ZiBCVU5ETEUgd291bGQsIGZvciBSVFAsIG1hbmRhdGUgdGhlIHVzYWdlIG9mIGE9c3NyYywgd2Ug Y291bGQgb2YgY291cnNlIGFsc28gc3BlY2lmeSB0aGF0IGFzICJkZWZhdWx0IiwgYnV0IGN1cnJl bnRseSBCVU5ETEUgZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNhZ2Ugb2YgYT1zc3JjKS4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KPiBPbiBKdW4gMjUsIDIwMTMsIGF0IDEwOjAzIEFN LCAiRW1pbCBJdm92IiA8ZW1jaG9Aaml0c2kub3JnPiB3cm90ZToNCj4NCj4+DQo+Pg0KPj4gT24g MjUuMDYuMTMsIDEzOjM0LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+PiBIaSwNCj4+Pg0K Pj4+IEVtaWwgc3VnZ2VzdGVkIHRoYXQgdGhlIGRlZmF1bHQsIOKAnE1USeKAnSwgbWVjaGFuaXNt IGZvciBtYXBwaW5nIFJUUCANCj4+PiBkYXRhIHRvIG0tIGxpbmVzIHNob3VsZCBiZSBiYXNlZCBv biBQVC4NCj4+DQo+PiBBY3R1YWxseSwgd2hhdCBJIHRob3VnaHQgd2FzIGltcG9ydGFudCB3YXMg aGF2aW5nIGl0IGFzIHRoZSAiZGVmYXVsdCIgbWVjaGFuaXNtLiBQZXJzb25hbGx5IEkgZG9uJ3Qg bWluZCBoYXZpbmcgaXQgYXMgTVRJIG1pZ2h0IGJ1dCBpdCBtaWdodCBiZSBhIHRhZCB0b28gc3Ry b25nOiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkZWVtIFBUIGRlbXV4IGluc3VmZmljaWVudCBhbmQg d291bGRuJ3Qgd2FudCB0byB1c2UgYnVuZGxlIHdpdGhvdXQgaXQsIGRvbid0IG5lZWQgaW1wbGVt ZW50IGl0Lg0KPj4NCj4+IFdlIHNob3VsZCBwcm9iYWJseSBhbHNvIGFncmVlIG9uIGhvdyBhbiBh bnN3ZXJlciBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IGl0IGlzIGV4cGVjdGVkIHRvIHBy b3ZpZGUgYWRkaXRpb25hbCBkZW11eGluZyBpbmZvcm1hdGlvbiAoZS5nLiBTU1JDcykgb3IgaWYg dGhlIG9mZmVyZXIgaXMgdXNpbmcgdGhlIGRlZmF1bHQgbWVjaGFuaXNtLg0KPj4NCj4+IE9uZSB3 YXkgd291bGQgYmUgZm9yIHRoZSBhbnN3ZXJlciB0byBpbnNwZWN0IGFsbCBtPSBsaW5lcyBhbmQg dHJ5IHRvIGRldGVjdCBkdXBsaWNhdGluZyBQVHMuIFRoaXMgY291bGQgYmUgYSBiaXQgY2x1bXN5 IHRob3VnaC4gVGhlIG9mZmVyZXIgY291bGQgZXhwZWN0IFNTUkNzIGJ1dCBpdHMgZmlyc3Qgb2Zm ZXIgbWF5IG5vdCB5ZXQgY29udGFpbiBQVCByZXVzZS4NCj4+DQo+PiBXaXRoIHRoYXQgaW4gbWlu ZCAuLi4gKG1vcmUgYmVsb3cpDQo+Pg0KPj4+IEFwcGxpY2F0aW9ucyBhcmUgYWxsb3dlZCB0byB1 c2UNCj4+PiB3aGF0ZXZlciBvdGhlciBtZWNoYW5pc21zLCBidXQgdXNhZ2Ugb2Ygc3VjaCBtZWNo YW5pc21zIG11c3QgYmUgDQo+Pj4gbmVnb3RpYXRlZCAob3IsIGFwcGxpY2F0aW9ucyBuZWVkIHRv IGhhdmUgc29tZSBvdGhlciBtZWFucyBrbm93aW5nIA0KPj4+IHRoYXQgdGhlIG90aGVyIGVuZHBv aW50IHN1cHBvcnQgc3VjaCBtZWNoYW5pc21zKS4NCj4+Pg0KPj4+ICpRMyo6IERvIHdlIG5lZWQg dG8gc3BlY2lmeSBhIGRlZmF1bHQsIE1USSwgbWVjaGFuaXNtIGZvciBtYXBwaW5nIA0KPj4+IFJU UCBkYXRhIHRvIG0tIGxpbmVzPw0KPj4NCj4+IEkgYW0gaW4gZmF2b3VyIG9mIGhhdmluZyBhICJk ZWZhdWx0IiBvbmUuDQo+Pg0KPj4gV2l0aG91dCB0aGlzIEJVTkRMRSB3b3VsZCBoYXZlIHRvIGJl IGFuIGFic3RyYWN0IHNwZWMgYW5kIEkgZG9uJ3Qgc2VlIHdoeSB3ZSB3b3VsZCB3YW50IHRvIGxl YXZlIGl0IHRoYXQgd2F5Lg0KPj4NCj4+PiAqUTQqOiBJZiBRMywgZG8gd2UgbWFuZGF0ZSBhcHBs aWNhdGlvbnMgdG8gc3VwcG9ydCwgYW5kIHVzZSAodW5sZXNzIA0KPj4+IGFwcGxpY2F0aW9ucyBh cmUgbWFkZSBhd2FyZSBvZiBvdGhlciBtZWNoYW5pc21zIHN1cHBvcnRlZCBieSBhbGwNCj4+PiBl bmRwb2ludHMpIFBUIGZvciBtYXBwaW5nIHJlY2VpdmVkIFJUUCBtZWRpYT8NCj4+DQo+PiBJbiBm YXZvdXIuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gRW1pbA0KPj4NCj4+Pg0KPj4+IFRoaXMgbWVhbnMg dGhhdCwgd2hlbiBtYXBwaW5nIFJUUCB0byBtLSBsaW5lcyBpcyByZXF1aXJlZCAod2hldGhlciAN Cj4+PiBpdCBpcyBhbHdheXMgbWFuZGF0ZWQgaXMgZGlzY3Vzc2VkIGluIGFub3RoZXIgdGhyZWFk KSwgd2l0aGluIGEgDQo+Pj4gQlVORExFIGdyb3VwIGVhY2ggUFQgdmFsdWUgbXVzdCBiZSB1bmlx dWUgdG8gYW4gaW5kaXZpZHVhbCBtLSBsaW5lLg0KPj4+DQo+Pj4gTk9URTogSWYgeW91ciBhbnN3 ZXIgdG8gUTMgaXMg4oCceWVz4oCdLCBidXQgeW91ciBhbnN3ZXIgdG8gUTQgaXMg4oCcbm/igJ0s IA0KPj4+IHBsZWFzZSBpbmRpY2F0ZSB3aGljaCBtZWNoYW5pc20geW91IHByZWZlciBKDQo+Pj4N Cj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG1tdXNpYyBt YWlsaW5nIGxpc3QNCj4+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPj4NCj4+IC0tDQo+PiBodHRwczovL2ppdHNpLm9y Zw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4g bW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW11c2ljDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= From christer.holmberg@ericsson.com Wed Jun 26 00:33:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091321F9F90 for ; Wed, 26 Jun 2013 00:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV75Eu65c0FV for ; Wed, 26 Jun 2013 00:33:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 778D221F9FA8 for ; Wed, 26 Jun 2013 00:33:32 -0700 (PDT) X-AuditID: c1b4fb25-b7fed6d000004760-d6-51ca994b2851 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 16.40.18272.B499AC15; Wed, 26 Jun 2013 09:33:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:33:31 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: DECISION: Offerer assigning address:port to multiple m- lines before Answerer has selected that address:port as BUNDLE address? Thread-Index: Ac5yP3Rn0wMjs/ReTzidmfr59LvAtw== Date: Wed, 26 Jun 2013 07:33:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB7D0@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BB7D0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvra73zFOBBpMua1lMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGVu/yhR81qw4fuIhawNjp0oXIyeHhICJxLS5t9khbDGJC/fW s3UxcnEICRxmlDi/cw8LhLOIUWLqwbesXYwcHGwCFhLd/7RBGkQE1CW+7u1hBqkRFuhilFi/ YikTRKKfUeL1lGgIW0/i7p02VhCbRUBV4tzLN2wgNq+Ar8SSb81gNiPQ5u+n1oD1MguIS9x6 Mp8J4iIBiSV7zjND2KISLx//Y4WwFSXanzYwQtTnSxw/v4YVYqagxMmZT1gmMArNQjJqFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0cqNNjMCwP7jlt+oOxjvn RA4xSnOwKInzfjy1K1BIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY4P5nLWnbHdE+R7e/u+H b8kU9inXvYuNtn7VOdYRUzGz4uX5rZ3XCmX3ujI9LKn4fFDPNMnnuXpvvvJe4/mPJpaovSqa 9aNGat0kSa05McV8vd4Vfi9vPWv8tHtDs0ySlWU32xNWy4g5P/44NsS/SpJ40LN5a9zzLxfl jmbIi2mn/VzjefVzqRJLcUaioRZzUXEiAK4sK51JAgAA Subject: [MMUSIC] DECISION: Offerer assigning address:port to multiple m- lines before Answerer has selected that address:port as BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 07:33:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BB7D0ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, BUNDLE currently specifies that an Offerer is not allowed to assign an addr= ess:port to multiple m- lines before that address:port has been selected as= BUNDLE address by the Answerer. Paul indicated that such rule is ineffective, as it always requires two O/A= transactions (one for the negotiation, and another one for the sync) in or= der to negotiate/re-negotiate a BUNDLE address. Instead, Paul suggested that an Offerer should be allowed to assign a new a= ddress:port to multiple m- lines before the Answerer has selected that addr= ess:port as a BUNDLE address. Paul also suggested that an Offerer should be allowed to do this before the= Answerer has sent an SDP Answer, indicating support of BUNDLE. Q5: Within a SIP session, once both endpoints have indicated support of BUN= DLE, do we allow an Offerer to assign an address:port to multiple m- lines,= before the Answerer has selected that address:port as a BUNDLE address? Q6: If Q5, do we allow an Offerer to assign an address:port to multiple m- = lines before the Answerer has, within the SIP session, indicated that it su= pports BUNDLE? A typical example would be assigning an address:port to mult= iple m- lines already in the initial SDP Offer for a SIP session. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BB7D0ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

BUNDLE currently specifies that an Offerer is not al= lowed to assign an address:port to multiple m- lines before that address:po= rt has been selected as BUNDLE address by the Answerer.

 

Paul indicated that such rule is ineffective, as it = always requires two O/A transactions (one for the negotiation, and another = one for the sync) in order to negotiate/re-negotiate a BUNDLE address.=

 

Instead, Paul suggested that an Offerer should be al= lowed to assign a new address:port to multiple m- lines before the Answerer= has selected that address:port as a BUNDLE address.

 

Paul also suggested that an Offerer should be allowe= d to do this before the Answerer has sent an SDP Answer, indicating support= of BUNDLE.

 

Q5: Within a SIP session, once both endpoints= have indicated support of BUNDLE, do we allow an Offerer to assign an addr= ess:port to multiple m- lines, before the Answerer has selected that addres= s:port as a BUNDLE address?

 

Q6: If Q5, do we allow an Offerer to assign a= n address:port to multiple m- lines before the Answerer has, within the SIP= session, indicated that it supports BUNDLE? A typical example would be ass= igning an address:port to multiple m- lines already in the initial SDP Offer for a SIP session.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3BB7D0ESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Jun 26 00:45:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B09C21E80FD for ; Wed, 26 Jun 2013 00:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftonSSNcLG9u for ; Wed, 26 Jun 2013 00:45:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8F421E8089 for ; Wed, 26 Jun 2013 00:45:25 -0700 (PDT) X-AuditID: c1b4fb25-b7fed6d000004760-1e-51ca9c149dc4 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 07.42.18272.41C9AC15; Wed, 26 Jun 2013 09:45:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:45:24 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE questions and Berlin Thread-Index: Ac5yQDfd2Ovj8kgGTumicbqgM4/2xw== Date: Wed, 26 Jun 2013 07:45:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BB802@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BB802ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvra7InFOBBm9PqlpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRMfTmcq+KtQ8WntbaYGxtUyXYycHBICJhI/ll5nh7DFJC7c W8/WxcjFISRwmFFi7tRXjBDOIkaJG+8bmbsYOTjYBCwkuv9pgzSICKhLfN3bwwxiCwuoSHy5 fZYJIq4pcerJXChbT+LOy2tsIK0sAqoS869agIR5BXwl9s7bywpiMwLt/X5qDVg5s4C4xK0n 85kg7hGQWLLnPDOELSrx8vE/VghbUaL9aQMjRH2+xI7228wQMwUlTs58wjKBUWgWklGzkJTN QlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGy5yZm5qSXG21iBAb9wS2/VXcw3jkn cohRmoNFSZz346ldgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYZZq8ztt8zCt65+d1dMWj hF9LNi/sUd6q239jl6LXpSkzXwkdPLp55qSrFVJn3laFuTh/ynjZcP/9HdvPNorHwy9nXcxk sJeY0mL/3+T8zebaaokzP/+bXRKz25h/el8G34ajm9SXLN397ce5a8pzK6/e/mggVXV9iVhm yILcoA+c7q9t9l5YdUmJpTgj0VCLuag4EQBsQREWSAIAAA== Subject: [MMUSIC] BUNDLE questions and Berlin X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 07:45:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BB802ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As you have seen, I have sent out a number of BUNDLE related questions on t= he list, trying to close open issues. My intention is to go through the questions in Berlin, and present the stat= us of what people have replied, so there will be a few weeks for people who= need some time to think about what to reply. People can of course still give their opinion in Berlin (and, even after Be= rlin), but I would hope that we will be able to actually close as many open= issues as possible in Berlin. So I encourage anyone with an opinion to rai= se it on the list, as it also allow us to have mail discussions on topics b= efore the Berlin meeting. Thanks! And, feel free to raise issues YOU think we need so close on BUNDLE, in cas= e I have forgotten them :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BB802ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As you have seen, I have sent out a number of BUNDLE= related questions on the list, trying to close open issues.

 

My intention is to go through the questions in Berli= n, and present the status of what people have replied, so there will be a f= ew weeks for people who need some time to think about what to reply.

 

People can of course still give their opinion in Ber= lin (and, even after Berlin), but I would hope that we will be able to actu= ally close as many open issues as possible in Berlin. So I encourage anyone= with an opinion to raise it on the list, as it also allow us to have mail discussions on topics before the Be= rlin meeting.

 

Thanks!

 

And, feel free to raise issues YOU think we need so = close on BUNDLE, in case I have forgotten them :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3BB802ESESSMB209erics_-- From internet-drafts@ietf.org Wed Jun 26 00:53:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6711E80C5; Wed, 26 Jun 2013 00:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlsM21bZc9ts; Wed, 26 Jun 2013 00:53:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F6821F9FB8; Wed, 26 Jun 2013 00:53:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130626075329.3024.65739.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 00:53:29 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 07:53:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Audio and Video Media Streams Over Circuit-Switched Bearers In The Public = Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-21.txt Pages : 36 Date : 2013-06-26 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-21 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Wed Jun 26 00:58:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0611E819B for ; Wed, 26 Jun 2013 00:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXCwZVjnmn-D for ; Wed, 26 Jun 2013 00:58:35 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1C011E8134 for ; Wed, 26 Jun 2013 00:58:35 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5Q7wCVn025783 for ; Wed, 26 Jun 2013 10:58:33 +0300 Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 10:58:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Jun 2013 10:58:18 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.116]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.02.0328.011; Wed, 26 Jun 2013 08:00:08 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-21.txt Thread-Index: AQHOckJFwiWHU15qf0SD707g4KP5nJlHoTCg Date: Wed, 26 Jun 2013 08:00:07 +0000 Message-ID: References: <20130626075329.3024.65739.idtracker@ietfa.amsl.com> In-Reply-To: <20130626075329.3024.65739.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYnlIOU/7CEqZsQzgO2h5JeKdm/L04pq+sa6o/OUfJI3JdoGJOBXVFYEAkLokerytFvl5hbJtzv9tJj3h6m/KCBC8ReQnzOcPs9lJx+mTsxltsA+GuutZ5T88naOz34NJQgsej8+f6FkDALlZkltyqHmGm5F3LfMO//+U858Wc7IHWWXvITCH7NuyqYMzMUQx9g== x-originating-ip: [172.21.81.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2013 07:58:18.0967 (UTC) FILETIME=[EBCAD670:01CE7242] X-Nokia-AV: Clean Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 07:58:40 -0000 Hello all, One more revision round to address IESG review comments. This time the chan= ges are: - Removed the "-" addrtype both from the text as well as from IANA consider= ations (now we register only "E164" addrtype); all PSTN endpoints have onl= y E.164 addresses - Clarified that when generating the Offer and the Answer, before using "au= dio" or "video" media types the endpoint must have knowledge that these med= ia types are available on the circuit-switched network (as opposed to CS da= ta, for example) - Clarified that the mechanisms presented in the draft are specific to PSTN= networks (where a call signaling protocol is available), not to a generic = circuit-switched networks. Cheers, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 26. kes=E4kuuta 2013 10:53 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-21.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Audio and Video Media Streams Over Circuit-Switched Bearers In The Public = Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-21.txt Pages : 36 Date : 2013-06-26 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-21 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From csp@csperkins.org Wed Jun 26 03:23:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4CA11E80D2 for ; Wed, 26 Jun 2013 03:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNvw7Mo3DOYG for ; Wed, 26 Jun 2013 03:23:16 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 835EB21E8128 for ; Wed, 26 Jun 2013 03:23:11 -0700 (PDT) Received: from [81.187.2.149] (port=46339 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UrmsU-0007VJ-3B; Wed, 26 Jun 2013 11:23:06 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B099E22B-A583-4F61-BDE8-EF1BC9461030" From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> Date: Wed, 26 Jun 2013 11:23:04 +0100 Message-Id: <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 10:23:21 -0000 --Apple-Mail=_B099E22B-A583-4F61-BDE8-EF1BC9461030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 Jun 2013, at 12:34, Christer Holmberg wrote: > Hi, > =20 > Emil suggested that the default, =93MTI=94, mechanism for mapping RTP = data to m- lines should be based on PT. Applications are allowed to use = whatever other mechanisms, but usage of such mechanisms must be = negotiated (or, applications need to have some other means knowing that = the other endpoint support such mechanisms). > =20 > Q3: Do we need to specify a default, MTI, mechanism for mapping RTP = data to m- lines? I think the BUNDLE specification needs to define how RTP flows can be = associated with m=3D lines, but ought not mandate that applications do = so. The document that describes how WebRTC uses BUNDLE might want to = mandate that WebRTC applications use the mechanism.=20 > Q4: If Q3, do we mandate applications to support, and use (unless = applications are made aware of other mechanisms supported by all = endpoints) PT for mapping received RTP media? I think we should specify how the combination of PT values and a=3Dssrc: = lines can be used to associate RTP data with m=3D lines, for = applications that want to do so.=20 I don't think just using PT values is sufficient, since the PT space is = small (I can imagine applications that want to send lots of flows using = the same codec configuration, and it's more natural to give them all the = same PT and use a=3Dssrc: lines to distinguish). >=20 > This means that, when mapping RTP to m- lines is required (whether it = is always mandated is discussed in another thread), within a BUNDLE = group each PT value must be unique to an individual m- line. > =20 > NOTE: If your answer to Q3 is =93yes=94, but your answer to Q4 is = =93no=94, please indicate which mechanism you prefer J > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_B099E22B-A583-4F61-BDE8-EF1BC9461030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,
 
Emil suggested that the = default, =93MTI=94, mechanism for mapping RTP data to m- lines should be = based on PT. Applications are allowed to use whatever other mechanisms, = but usage of such mechanisms must be negotiated (or, applications need = to have some other means knowing that the other endpoint support such = mechanisms).
 
Q3: Do we need to specify a default, MTI, mechanism = for mapping RTP data to m- = lines?

I = think the BUNDLE specification needs to define how RTP flows can be = associated with m=3D lines, but ought not mandate that applications do = so. The document that describes how WebRTC uses BUNDLE might want to = mandate that WebRTC applications use the = mechanism. 

Q4: If Q3, do we = mandate applications to support, and use (unless applications are made = aware of other mechanisms supported by all endpoints) PT for mapping = received RTP = media?

I think = we should specify how the combination of PT values and a=3Dssrc: lines = can be used to associate RTP data with m=3D lines, for applications that = want to do so. 

I don't think just using = PT values is sufficient, since the PT space is small (I can imagine = applications that want to send lots of flows using the same codec = configuration, and it's more natural to give them all the same PT and = use a=3Dssrc: lines to = distinguish).

This means that, when mapping = RTP to m- lines is required (whether it is always mandated is discussed = in another thread), within a BUNDLE group each PT value must be unique = to an individual m- line.
 
NOTE: If your answer to Q3 is =93yes=94, but your answer = to Q4 is =93no=94, please indicate which mechanism you prefer J
 
Regards,
 
Christer
_________________________________________= ______
mmusic mailing list


-- 
Colin Perkins



= --Apple-Mail=_B099E22B-A583-4F61-BDE8-EF1BC9461030-- From harald@alvestrand.no Wed Jun 26 04:38:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6A321F9F9F for ; Wed, 26 Jun 2013 04:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.264 X-Spam-Level: X-Spam-Status: No, score=-109.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNWqduomixpL for ; Wed, 26 Jun 2013 04:38:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C797011E80E3 for ; Wed, 26 Jun 2013 04:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE15439E17B; Wed, 26 Jun 2013 13:38:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu2BgGU3ywNX; Wed, 26 Jun 2013 13:38:01 +0200 (CEST) Received: from [10.243.75.72] (73-76-11.connect.netcom.no [176.11.76.73]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3B40E39E166; Wed, 26 Jun 2013 13:37:55 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BB724@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51CA7B2D.5050601@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3BB724@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GBGLXOEQCGHTHMXF2KKSD0AV5SJZJ4" From: Harald Alvestrand Date: Wed, 26 Jun 2013 13:37:46 +0200 To: Christer Holmberg , "mmusic@ietf.org" Message-ID: Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 11:38:13 -0000 ------GBGLXOEQCGHTHMXF2KKSD0AV5SJZJ4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I am on vacation now, so short answer: Apps that use m-lines for rtp session negotiation and not for stream control need no such association. If we mandate such association, we load those apps with extra luggage. Christer Holmberg wrote: >Hi Harald, > >Just for my clarification: Assuming we are talking about applications >using RTP (instead of ANY BUNDLE application), is your answer to Q3 >still "no"? > >In other words, do you think there might be RTP cases where it is not >needed to associate the RTP data with an m- line? > >OR, do you think that BUNDLE simply shouldn't say anything about how to >map RTP packets to m- lines? > >Regards, > >Christer > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >Behalf Of Harald Alvestrand >Sent: 26. kesäkuuta 2013 8:25 >To: mmusic@ietf.org >Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- >line is based on PT? > >On 06/25/2013 01:34 PM, Christer Holmberg wrote: >Hi, > >Emil suggested that the default, "MTI", mechanism for mapping RTP data >to m- lines should be based on PT. Applications are allowed to use >whatever other mechanisms, but usage of such mechanisms must be >negotiated (or, applications need to have some other means knowing that >the other endpoint support such mechanisms). > >Q3: Do we need to specify a default, MTI, mechanism for mapping RTP >data to m- lines? > >No. This makes the assumption that all applications have the need to >map RTP data to m-lines; this assumption is not proven (and probably >cannot be - it's hard to prove a negative. It might be possible to >disprove it, though). > > > >Q4: If Q3, do we mandate applications to support, and use (unless >applications are made aware of other mechanisms supported by all >endpoints) PT for mapping received RTP media? > >If the WG disagrees with me on Q3, it might as well go down this path. >I have no strong opinion. > > > >This means that, when mapping RTP to m- lines is required (whether it >is always mandated is discussed in another thread), within a BUNDLE >group each PT value must be unique to an individual m- line. > >NOTE: If your answer to Q3 is "yes", but your answer to Q4 is "no", >please indicate which mechanism you prefer :) > >Regards, > >Christer > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------GBGLXOEQCGHTHMXF2KKSD0AV5SJZJ4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I am on vacation now, so short answer:

Apps that use m-lines for rtp session negotiation and not for stream control need no such association.

If we mandate such association, we load those apps with extra luggage.


Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Harald,

 

Just for my clarification: Assuming we are talking about applications using RTP (instead of ANY BUNDLE application), is your answer to Q3 still “no”?

 

In other words, do you think there might be RTP cases where it is not needed to associate the RTP data with an m- line?

 

OR, do you think that BUNDLE simply shouldn’t say anything about how to map RTP packets to m- lines?

 

Regards,

 

Christer

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 26. kesäkuuta 2013 8:25
To: mmusic@ietf.org
Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?

 

On 06/25/2013 01:34 PM, Christer Holmberg wrote:

Hi,

 

Emil suggested that the default, “MTI”, mechanism for mapping RTP data to m- lines should be based on PT. Applications are allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have some other means knowing that the other endpoint support such mechanisms).

 

Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to m- lines?


No. This makes the assumption that all applications have the need to map RTP data to m-lines; this assumption is not proven (and probably cannot be - it's hard to prove a negative. It might be possible to disprove it, though).


 

Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media?


If the WG disagrees with me on Q3, it might as well go down this path. I have no strong opinion.


 

This means that, when mapping RTP to m- lines is required (whether it is always mandated is discussed in another thread), within a BUNDLE group each PT value must be unique to an individual m- line.

 

NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”, please indicate which mechanism you prefer J

 

Regards,

 

Christer




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

 


--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------GBGLXOEQCGHTHMXF2KKSD0AV5SJZJ4-- From tireddy@cisco.com Wed Jun 26 04:53:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4411E80DC for ; Wed, 26 Jun 2013 04:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLCdHfVH1IsT for ; Wed, 26 Jun 2013 04:53:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68ABA11E80E3 for ; Wed, 26 Jun 2013 04:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9588; q=dns/txt; s=iport; t=1372247602; x=1373457202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WlLR9GyVwQ/J/Nqv8gf+OBBhlzZ4otpSvcknms4oCeE=; b=fmw0mLEoV+ZjJWmVB+u6MMcztFuig0b9zK4OUbvUbD+EoMFzqO6GrAM4 uSAnNq/f62zl1aKhH5rnd155f8xUwEEiFWjochob1/JXZB1LrWyUHtAgF OIzPUw3v9v6Gt3jnTxLioPR+3cLJY03f1YUARK3x6rkCtxCKIligYrnsP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAP/UylGtJV2a/2dsb2JhbABagwkxQwa+e4EDFnSCIwEBAQMBAQEBNzQJAgwEAgEIDgMEAQEBChQJBycLFAgBCAIEDgUIAYd/BgcFujaOI3cxBwaCfGEDk3OEe5AcgViBOYIo X-IronPort-AV: E=Sophos;i="4.87,943,1363132800"; d="scan'208";a="227409138" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jun 2013 11:53:19 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5QBrJr7000619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 11:53:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 06:53:19 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt Thread-Index: AQHOcK15+DWlJMUbHkqfCSOc2ALdLplEelaQgAC++QD//94/UIABx7UA//+xkTA= Date: Wed, 26 Jun 2013 11:53:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B8E47A@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14B8C943@xmb-rcd-x10.cisco.com> <51C85164.5080208@jitsi.org> <913383AAA69FF945B8F946018B75898A14B8D7A3@xmb-rcd-x10.cisco.com> <51C9B35A.1000608@jitsi.org> In-Reply-To: <51C9B35A.1000608@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:53:31 -0000 Hi Emil, Please see inline > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Tuesday, June 25, 2013 8:42 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-= ice- > mobility-04.txt >=20 > Hey Tiru, >=20 > On 25.06.13, 14:41, Tirumaleswar Reddy (tireddy) wrote: > > Hi Emil, > > > > Thanks for the review. Please see inline > > > >> -----Original Message----- From: Emil Ivov > >> [mailto:emcho@jitsi.org] Sent: Monday, June 24, 2013 7:32 PM To: > >> Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org Subject: Re: > >> [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice- > >> mobility-04.txt > >> > >> Hey Tiru, > >> > >> On 24.06.13, 15:06, Tirumaleswar Reddy (tireddy) wrote: > >>> Hi all, > >>> > >>> we have updated the draft based on the comments received during > >>> IETF 86 to compare MICE with ICE restart and Trickle ICE (Section > >>> 6 "Comparison to ICE Restart and Trickle ICE"). comments and > >>> suggestions are welcome. > >> > >> Thanks for doing this. > >> > >> A few comments on that comparison: > >> > >>> 6.2. Break Before Make - Trickle ICE > >>> > >>> o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for > >>> RTP Mobility then in case of Break before Make, > >>> > >>> 1. Trickle ICE can begin connectivity checks while the endpoint > >>> is still gathering candidates and can considerably shorten the > >>> time necessary for ICE processing to complete. It still involves > >>> the overhead of step 1 explained in section Section 6.1. > >> > >> The said overhead being SIP re-registration, I don't see how > >> trickle-ice and mice are in a different position here. Why would > >> one be able to restart attempts without it, while the other > >> wouldn't ? > > > > Mobility using ICE will be started without waiting for SIP > > re-registration to start (performed entirely in the media path). > > Please refer to the explanation in > > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04#section-3.= 1 >=20 > Yes, sure. What would prevent you from doing the same if you were to do > mobility with trickle ICE ? Obviously, the trickle updates would need to > through the SIP server and they would potentially have to be > re-authenticated, but nothing stops you from engaging in the semantics > defined in MICE just because you are also doing trickle ICE. There seems to be some confusion, we also agree that MICE can be used with = trickle ICE. There was comment when Dan presented this draft in IETF 86 tha= t If trickle ICE is used then MICE is not required, we are only trying to a= ddress that comment. >=20 > >>> 2. The endpoint would learn host candidates and inform them to > >>> the remote peer in offer, the remote peer will provide its > >>> candidates in answer. The host, server reflexive, peer reflexive > >>> and relayed candidates of the remote peer may not change and the > >>> remote peer does not have to gather the candidates again. Trickle > >>> ICE will test local host candidates with all types of remote > >>> candidates provided by the remote peer in the answer. If the ICE > >>> peer is behind NAT performing end-point independent mapping and > >>> filtering then ICE connectivity checks initiated by the endpoint > >>> to the remote peer will succeed. > >> > >> Actually that's what you'd need the NAT to be without trickle ICE > >> so that break-before-make mice would succeed (which I've already > >> expressed as a concern with this draft). > > > > Yes, we have updated the draft about the concern you raised last > > time > > > > Section 3.1 ... Mobility using ICE could fail in case of Simultaneous > > Mobility or if the ICE peer is behind NAT that performs > > Address-Dependent Filtering (see Section 5 of [RFC5245]).... >=20 > What I am saying is that rather than just warning about it, you could > also resolve it with trickle ICE. Based on your last comment we have updated the draft that the above problem= will be handled by doing SIP re-registration/ICE restart in parallel, so t= hat if MICE fails ICE restart would succeed for EPD filtering use-case. If = endpoints support Trickle ICE it will also help in this scenario. >=20 > > And this concern could be addressed by either of the following > > techniques - Section 3.2 "Keeping unused relayed candidates active" >=20 > True. But this would be suboptimal. >=20 > > or Appendix A.2.1. "Keeping unused candidates in the valid list > > active" >=20 > Not true. Keeping your server reflexive candidates alive wouldn't change > anything in the case of a NAT with EPD filtering. The unused candidates from other interfaces are kept-alive using STUN Bindi= ng request/response with the remote peer (it's explained in Appendix "A.2.1= .1. Sending keep alive requests"). This approach can be used as a fail-over= technique but brings in overhead and is only mentioned as a optional techn= ique.=20 >=20 > >> Using trickle ICE would allow you to succeed with endpoint > >> dependent filtering because the remote party would also start > >> checks in your direction. > > > > The problem in the above scenario is endpoint would just learn host > > candidates and inform them to the remote peer in offer, >=20 > I don't get this. Why would an endpoint only inform of host candidates ? > It would also inform of server-reflexive candidates as soon as it > discovers them. Yes, I meant host candidates would be learnt quickly and informed to the re= mote peer using Trickle ICE (in step 1). The endpoint would also in paralle= l learn the server-reflexive candidates which would take some time, these c= andidates would be informed subsequently (in step 2). Step 1 could fail if = remote peer is behind EPD filtering NAT, but step 2 would eventually succee= d. >=20 > > so if the > > endpoint is behind endpoint independent filtering NAT and the remote > > peer is behind endpoint dependent filtering NAT (Let's say NAT X). > > The STUN connectivity checks sent by the endpoint will be blocked by > > X, STUN connectivity checks initiated by the remote peer will fail to > > reach the endpoint because it is behind NAT. >=20 > Again, this is the case *without* trickle ICE. If however you allowed > trickle ICE to help MICE, the endpoint that's behind the EPD filtering > NAT would eventually learn about your new candidates and also start > sending checks there. Agreed. =20 Best Regards, --Tiru. >=20 > >> I guess what I am trying to say is that it doesn't make sense for > >> mice not to use trickle ICE for this case. > > > > MICE can be used with Trickle ICE, we are only responding to comments > > in the last IETF asking for the benefits of MICE in comparison with > > ICE restart and Trickle ICE. >=20 > My point is that MICE can not only be used with but also optimized with > trickle ICE and made more reliable. >=20 > Cheers, > Emil >=20 > >>> 3. Trickle ICE must be supported by both endpoints for it be > >>> used. > >> > >> I am not sure I understand this argument. Any kind of mobility > >> management would have to be supported by both pears in order to be > >> used. > > > > when only one endpoint supports MICE, TURN server can be used to > > provide mobility (Section 5 - "Mobility using TURN"). The endpoint > > will use local relayed candidates for communicating with the remote > > peer. Even If endpoint roams and gets a new IP address, it will > > continue to reach the remote peer using the local relayed candidates > > as explained in section 5 (using the MOBILITY-TICKET). The remote > > peer will not even be aware that the endpoint IP address has > > changed. > > > > Regards, --Tiru. > > > >> > >> Cheers, Emil > >> > >> > >> > >>> > >>> Best Regards, --Authors. > >>> > >>> -----Original Message----- From: internet-drafts@ietf.org > >>> [mailto:internet-drafts@ietf.org] Sent: Monday, June 24, 2013 > >>> 1:06 PM To: Prashanth Patil (praspati); Tirumaleswar Reddy > >>> (tireddy); Dan Wing (dwing); Pal Martinsen (palmarti) Subject: > >>> New Version Notification for > >>> draft-wing-mmusic-ice-mobility-04.txt > >>> > >>> > >>> A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt has > >>> been successfully submitted by Dan Wing and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-wing-mmusic-ice-mobility Revision: 04 Title: > >>> Mobility with ICE (MICE) Creation date: 2013-06-24 Group: > >>> Individual Submission Number of pages: 19 URL: > >>> http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-04= .txt > >>> > >>> > >> > >>> > Status: > >> http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility > >>> Htmlized: > >>> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04 > >>> Diff: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-ice-mobility-04 > >>> > >>> > >>> > Abstract: This specification describes how endpoint mobility can be > >>> achieved using ICE. Two mechanisms are shown, one where both > >>> endpoints support ICE and another where only one endpoint > >>> supports ICE. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >>> _______________________________________________ mmusic mailing > >>> list mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> -- https://jitsi.org > > >=20 > -- > https://jitsi.org From christer.holmberg@ericsson.com Wed Jun 26 05:20:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6321E80D7 for ; Wed, 26 Jun 2013 05:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxrqgg+TX8yl for ; Wed, 26 Jun 2013 05:20:15 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1321E8088 for ; Wed, 26 Jun 2013 05:20:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7f866d000000c2d-96-51cadc7d563a Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7A.B8.03117.D7CDAC15; Wed, 26 Jun 2013 14:20:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 14:20:13 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAryLEAAAfraoA= Date: Wed, 26 Jun 2013 12:20:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> In-Reply-To: <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW7tnVOBBv035C2WvzzBaDF1+WMW ByaPaffvs3ksWfKTKYApissmJTUnsyy1SN8ugSvj0RzlguOCFas6f7M2MDbwdTFyckgImEjs unKKCcIWk7hwbz1bFyMXh5DAYUaJ0zNOgiWEBBYxShxpF+5i5OBgE7CQ6P6nDRIWEVCV2HH8 HyNImFlAXeLq4iAQU1ggTmLPLjMQU0QgXuLQLCOIYiuJL4sWMoPYLECN7fe7WUBsXgFfiSOL DrJCLG1hlHjxpYcRJMEp4Cgxb/96sCJGoMu+n1oDdgyzgLjErSfzoS4WkFiy5zwzhC0q8fLx P1YIW1Gi/WkDI0S9nsSNqVPYIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZ VjGy5yZm5qSXG25iBMbGwS2/dXcwnjoncohRmoNFSZz3w6ldgUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYZx6a+ml1YWYTz/+1fMGb5BXv7z2wKHI+y6RzWunKZ+5enLt/kd6HIj693FlC epf1JohGVgiGNlw9u2rZoecxXqc2T/3Zri9Qe5L/YWPnvCKBtGv+kVu/mE+b8fVN/tINxg13 r/m0pu/tP7n+Qk64ax5LDaNkmrEO62y/AAGJ5K2PA8W5Ai6fUGIpzkg01GIuKk4EAAMAmERb AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 12:20:28 -0000 Hi Colin, >> Emil suggested that the default, "MTI", mechanism for mapping RTP data t= o m- lines should be based on PT. Applications are=20 >> allowed to use whatever other mechanisms, but usage of such mechanisms m= ust be negotiated (or, applications need to have=20 >> some other means knowing that the other endpoint support such mechanisms= ). >>=A0 >> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data= to m- lines? > > I think the BUNDLE specification needs to define how RTP flows can be ass= ociated with m=3D lines, but ought not mandate that applications=20 > do so. The document that describes how WebRTC uses BUNDLE might want to m= andate that WebRTC applications use the mechanism.=A0 Note that there is a separate discussion, BUNDLE DISCUSION: Always mandate = mechanism to map received data to m- line?, on whether BUNDLE shall mandate= that the receiver must always be able to map received data to an m- line. So far only Paul has commented on that discussion, but I assume it's just a= question of hours before your input will be posted? :) >> Q4: If Q3, do we mandate applications to support, and use (unless applic= ations are made aware of other mechanisms supported by all endpoints) PT fo= r mapping received RTP media? > > I think we should specify how the combination of PT values and a=3Dssrc: = lines can be used to associate RTP data with m=3D lines, for applications t= hat want to do so.=A0 > > I don't think just using PT values is sufficient, since the PT space is s= mall (I can imagine applications that want to send lots of flows using=20 > the same codec configuration, and it's more natural to give them all the = same PT and use a=3Dssrc: lines to distinguish). If you run out of PTs, and have to re-use the same PT in multiple m- lines = (for the same codec configuration, though), you will obviously need somethi= ng else for mapping RTP to m- lines, and we should probably state that. But, my take from your reply is that you don't think we should specify a de= fault mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), bu= t it would be up to applications to decide what to use. Correct? Regards, Christer From pkyzivat@alum.mit.edu Wed Jun 26 06:40:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD97F21E814E for ; Wed, 26 Jun 2013 06:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua9oRc15EQXh for ; Wed, 26 Jun 2013 06:40:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 06DED21E8150 for ; Wed, 26 Jun 2013 06:39:49 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id szJ31l0020bG4ec531fpg4; Wed, 26 Jun 2013 13:39:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id t1fo1l01E3ZTu2S3P1foQ8; Wed, 26 Jun 2013 13:39:48 +0000 Message-ID: <51CAEF23.5060305@alum.mit.edu> Date: Wed, 26 Jun 2013 09:39:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> <51C9B3A9.2000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BB686@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BB686@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372253989; bh=HdUieD86NuNz8gM+18HlivOnU5i8twQgWg7QsZCAAz8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SOOdITp9rAcTt4riOjAYke9RGeGkzRnmcDNILayQG8porfgN+h4r+jJ3da79XPg7a nX4pXersn6zbpp4ubfK+edTwGzH5SAZK8C6yAbw68rV6nB497mw81WdFiT3lqy4Yve 5MgRUOJK0zmJ7qYSQyrQm+PzoFlESi8eEjUSsCj0vU2iG2G65L0iBC3b2VC7vHrPId bNOqJGJOMoO494RMW8JMzkG3dRI5KZWLnIHJZW95RPi35zppHYCGkJshF+s1bcvbmf iunc1ozBO2eQUixUvAw7ft7wWIqHc8ZcAUiI9lNEZqugH28syLRyn7WZmYA5g2qANN NB5msYVtkEIBw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 13:40:11 -0000 Inline, near end. On 6/26/13 2:58 AM, Christer Holmberg wrote: > Hi, > >>>> I started this issue, so I'll make my case again. >>>> >>>> There must be a reason to have multiple m-lines in the bundle. (If >>>> there isn't, leave them out, and then maybe you won't need bundle at >>>> all.) >>>> >>>> I assert that in all cases that reason can't be realized without being able to associate packets with the corresponding m-line. >>> >>> The reason for having m- lines could be because different characteristics (bandwidth, priority etc) is requested from the NETWORK, while the endpoint application that receive the data might not care which m- line it belongs to. >> >> Can you be specific? > > I'm afraid not - I was just speculating :) > >> Note that if you are requesting different characteristics from the NETWORK, then the NETWORK must be able to distinguish the packets in order to >> apply those characteristics properly. So then *it* will need a way to distinguish. If so, then the endpoints can too. > > True. > > What about the direction attributes? The network may use the information e.g. for bandwidth calculation purpose, but it does not need to distinguish the packets. > > Anyway, I personally don't have any strong preference, so I'd like to hear from people who DO have an opinion :) > >> If you are just requesting characteristics for the entire bundle, then it should be possible to do it with fewer m-lines, that you can then associate with. >> >>>> The exception to this are those packets that deal only with those >>>> aspects of the bundle that are common. The most obvious example of this is ICE. But if *all* packets are common to all the m-lines then there is no reason for the bundle. >>> >>> Correct. For ICE we explicitly say that the STUN messages apply to the whole BUNDLE group. >> >> It can in principle apply to more than just ICE. >> >> Somewhere I commented that the field describes more than just the low level transport protocol. It often describes a whole protocol stack >> with many layers. When we bundle multiple m-lines with different fields, they have different stacks. For the bundle to be valid, at least the >> bottom level of each stack must be the same. (E.g., UDP.) > > I think we should use whatever "stack" is referenced in the 5-tuple definition. > >> There may be more layers in common among some or all of the stacks. When some of the m-lines have multiple layers in common, then there >> may be some packets that pertain to housekeeping of the layer, and so need not be associated with one particular m-line. >> >> For instance, *in principle* one could bundle multiple DTLS/SCTP m-lines together. Then there could be some SCTP housekeeping packets that can't >> be associated with a single m-line, but for this to work, SCTP payload packets would need to be distinguishable, probably by SCTP port. (Note, I'm not >> sure if there are any SCTP packets that don't have an SCTP port, so this might not be a good example. And of course for this example to work there >> would need to be a way to specify the SCTP port in SDP for DTLS/SCTP.) >> >> AFAIK, for stuff *currently* under discussion only ICE falls into this category. But if we are going to define bundle so it can be >> applied to future cases then we need to phrase the constraint properly. > > Sure, but it is not (I hope) the task of BUNDLE to define HOW data is mapped to m- lines for all kind of transport protocols. No, Bundle can't define this for all possible m-lines. But it can call out the requirement that this must be possible for a bundle to be valid, and that it is the responsibility of the answerer to ensure that. Part of that is for the answerer to ensure that the *offerer* will be able to do it, and that both ends agree about *how* it will be done. (So that the sender and receiver of each packet agree on which m-line it is associated with.) I am not sure if there is ever a need to *explicitly* signal what mechanism(s) are to be used, or if it can always be inferred from the presence in the SDP of the data needed for the association. The place where this is an issue is if there is data in the answer that would allow the offerer to do the association, but the answerer is not certain if the offerer is prepared to use that data for that purpose. > We are going to specify/reference something for RTP, but do you think BUNDLE should also e.g. define a mechanism for transporting SCTP ports in SDP? We COULD (I assume it would be a rather simply task), but should we? We had this discussion already. IIUC there was consensus that the SDP for DTLS/SCTP would *not* include a way to convey the SCTP port, so that only a single default port can be used. This implies that one can't bundle two m-lines for this together. While I didn't agree with this decision, I can live with it until (if ever) a need arises. But I do think it needs to specify how to demux a bundle including a DTLS/SCTP and some RTP m-lines. Thanks, Paul > Regards, > > Christer > > >> >> >> >> >> On 6/25/13 7:16 AM, Christer Holmberg wrote: >>> Hi, >>> >>> There has been some discussions about whether BUNDLE should mandate >>> that users are mandated to *always* (no matter what transport >>> protocols are used in the BUNDLE group) have a mechanism to map >>> received data to an m- line, or whether it from a generic BUNDLE >>> perspective should be optional - IF there would be cases where it's not needed. >>> >>> We haven't had that much discussion about it yet, so I will not ask a >>> DECISION question at this point, but I would really like to get some >>> input from people who have opinions about this :) >>> >>> Note that this issue is NOT about HOW to map data to m- lines (there >>> will be a separate question about how to map RTP to m- lines etc), or >>> whether we should allow usage of the same PT value (for the same >>> codec >>> configuration) in multiple m- lines, but more about a general rule. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From pkyzivat@alum.mit.edu Wed Jun 26 06:45:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC211E80E2 for ; Wed, 26 Jun 2013 06:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGXC1nAPXxJ3 for ; Wed, 26 Jun 2013 06:45:19 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 83BEC21E8155 for ; Wed, 26 Jun 2013 06:45:17 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id sz501l0021wpRvQ531lFrF; Wed, 26 Jun 2013 13:45:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id t1lF1l00S3ZTu2S3e1lFcv; Wed, 26 Jun 2013 13:45:15 +0000 Message-ID: <51CAF06A.3080302@alum.mit.edu> Date: Wed, 26 Jun 2013 09:45:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BB7D0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BB7D0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372254315; bh=F5CLZf/sJdWXWFkTbCWTU6mHPkoUvF5xL3fcR9vwRe8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gthc+vuEC1OIGcRbuEOof6Rae/tmCNm6m9cpbNxull9zkBh4L4Yd1F0NeEsivmUea Nd2KdWOmOLT7qwE9rn4K44qXvgdlV9xpKuqGjyegANb0jkBi1a8fu8feM+HAa+H4zP wmtQxziiV+Izmant5jZZN63qC1FhTKdJOpGBpQqqw7a7BO4m8iwdjOzlgmuPSBGaIa JzmauMYMZ0HJ2akqpEZR3XCOABU8EkqKVkgdyOc23MoaGKkQbQJ3AWfwWaat5YnBW3 lHtjq7NoUm+/2ovMAqJEOHmEVlcwbRa9IeQw2SnxPdFclkDyidLozLXfSfHxvLpEXJ yMp6CCBTv5LZA== Subject: Re: [MMUSIC] DECISION: Offerer assigning address:port to multiple m- lines before Answerer has selected that address:port as BUNDLE address? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 13:45:23 -0000 Q5: yes Q6: yes. I don't expect this to be used all the time. But there will be cases when the offerer has enough understanding of the context in which it is used that doing so is worthwhile in order to save effort in session setup. Doing so comes with the obligation to cope with the consequences if the assumptions are wrong and the answerer doesn't support bundle. This is also a matter of acknowledging the real world. If we ban this, it is reasonable to expect that those that want it will do so anyway. Thanks, Paul On 6/26/13 3:33 AM, Christer Holmberg wrote: > Hi, > > BUNDLE currently specifies that an Offerer is not allowed to assign an > address:port to multiple m- lines before that address:port has been > selected as BUNDLE address by the Answerer. > > Paul indicated that such rule is ineffective, as it always requires two > O/A transactions (one for the negotiation, and another one for the sync) > in order to negotiate/re-negotiate a BUNDLE address. > > Instead, Paul suggested that an Offerer should be allowed to assign a > new address:port to multiple m- lines before the Answerer has selected > that address:port as a BUNDLE address. > > Paul also suggested that an Offerer should be allowed to do this before > the Answerer has sent an SDP Answer, indicating support of BUNDLE. > > *Q5*: Within a SIP session, once both endpoints have indicated support > of BUNDLE, do we allow an Offerer to assign an address:port to multiple > m- lines, before the Answerer has selected that address:port as a BUNDLE > address? > > *Q6*: If Q5, do we allow an Offerer to assign an address:port to > multiple m- lines before the Answerer has, within the SIP session, > indicated that it supports BUNDLE? A typical example would be assigning > an address:port to multiple m- lines already in the initial SDP Offer > for a SIP session. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Wed Jun 26 07:17:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1921F9FC3 for ; Wed, 26 Jun 2013 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYn+1iBo9NuE for ; Wed, 26 Jun 2013 07:17:00 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1258321F9FC8 for ; Wed, 26 Jun 2013 07:16:57 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id t0Ny1l00316LCl0532Gx83; Wed, 26 Jun 2013 14:16:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id t2Gx1l0033ZTu2S3S2GxZc; Wed, 26 Jun 2013 14:16:57 +0000 Message-ID: <51CAF7D7.50700@alum.mit.edu> Date: Wed, 26 Jun 2013 10:16:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <51CA7B2D.5050601@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3BB724@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372256217; bh=xUiHLOPKSKRTZ9VZMxk3NwcvBCZ0pAsoRkEaVcZyVWM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pxhFaxRBsQN3rnoclgoHiJ88RnxejvtmwbfY6kFHNr7+xGWxM6FTd7V7PSyuPNp2a +r0o6xSpwYYbSjzZuh6oScgJLbblARN1ddwLTMk7eikNItDYb/HpP2CG65COkCgexA vyboRE+eFQ0Jd6a+eR1JGWF19Ll7xPSco9W5YDA9IIVeWSccpTi+NGJAnojz/dE4Gk rB5E1ePSAk4gGcy0cObR579BSPXop76E8UDAW2NPsqR0PwdSYsm6eYiKl14gjsfXNK y6odC20UdxdrWryh45qrSAqNVRqsoE7qIKQ/K9tnfq/5FI/DjrV3G4Zas+kmhI81WR JXL+9DsokVE0w== Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 14:17:04 -0000 On 6/26/13 7:37 AM, Harald Alvestrand wrote: > I am on vacation now, so short answer: You don't keep working while on vacation? :-) > Apps that use m-lines for rtp session negotiation and not for stream > control need no such association. > > If we mandate such association, we load those apps with extra luggage. I still don't understand. If the m-lines are only used for session negotiation and not stream control then there is no need for multiple m-lines. And note that what is being proposed is only that there be enough information available so that the association is *possible*. It isn't a requirement that the association actually be *done*. (But I don't see a case where it wouldn't be needed.) Are you thinking of the case where there is just a bundle of one audio and one video m-line, because that is necessary in order to define the PTs for both audio and video? If so, then if the PTs are unique for the two m-lines, as they must be for it to work, then it is indeed possible to associate each packet with the proper m-line. Thanks, Paul > Christer Holmberg wrote: > > Hi Harald, > > Just for my clarification: Assuming we are talking about > applications using RTP (instead of ANY BUNDLE application), is your > answer to Q3 still “no”? > > In other words, do you think there might be RTP cases where it is > not needed to associate the RTP data with an m- line? > > OR, do you think that BUNDLE simply shouldn’t say anything about how > to map RTP packets to m- lines? > > Regards, > > Christer > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Harald Alvestrand > *Sent:* 26. kesäkuuta 2013 8:25 > *To:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] DECISION: Default mechanism to map RTP data > to m- line is based on PT? > > On 06/25/2013 01:34 PM, Christer Holmberg wrote: > > Hi, > > Emil suggested that the default, “MTI”, mechanism for mapping > RTP data to m- lines should be based on PT. Applications are > allowed to use whatever other mechanisms, but usage of such > mechanisms must be negotiated (or, applications need to have > some other means knowing that the other endpoint support such > mechanisms). > > *Q3*: Do we need to specify a default, MTI, mechanism for > mapping RTP data to m- lines? > > > No. This makes the assumption that all applications have the need to > map RTP data to m-lines; this assumption is not proven (and probably > cannot be - it's hard to prove a negative. It might be possible to > disprove it, though). > > > *Q4*: If Q3, do we mandate applications to support, and use (unless > applications are made aware of other mechanisms supported by all > endpoints) PT for mapping received RTP media? > > > If the WG disagrees with me on Q3, it might as well go down this > path. I have no strong opinion. > > > This means that, when mapping RTP to m- lines is required (whether > it is always mandated is discussed in another thread), within a > BUNDLE group each PT value must be unique to an individual m- line. > > NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”, > please indicate which mechanism you prefer J > > Regards, > > Christer > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From mohamed.boucadair@orange.com Wed Jun 26 08:05:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6813F21E8087; Wed, 26 Jun 2013 08:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYrr-4sgqB-W; Wed, 26 Jun 2013 08:04:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3273511E811B; Wed, 26 Jun 2013 08:04:56 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 859F922D5F1; Wed, 26 Jun 2013 17:04:54 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 655134C015; Wed, 26 Jun 2013 17:04:54 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 26 Jun 2013 17:04:54 +0200 From: To: "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Date: Wed, 26 Jun 2013 17:04:52 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> In-Reply-To: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.26.131226 Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:05:00 -0000 Dear all, I submitted this short I-D to explain how PCP can be used in IPv6 SIP deplo= yments (with a focus on the managed networks case). Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: mercredi 26 juin 2013 15:40 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP for IPv6-enabled SIP Deployments Author(s) : Mohamed Boucadair Filename : draft-boucadair-pcp-sip-ipv6-00.txt Pages : 7 Date : 2013-06-26 Abstract: This document discusses how PCP can be used in IPv6-enabled SIP deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mperumal@cisco.com Wed Jun 26 08:58:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321ED21E8063; Wed, 26 Jun 2013 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcBd435qQLM5; Wed, 26 Jun 2013 08:58:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BA52D11E80DF; Wed, 26 Jun 2013 08:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2238; q=dns/txt; s=iport; t=1372262293; x=1373471893; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1Qf+oMAVxOgwxCHGz0xiv9DJRB9TgKehyS5DmLadoRs=; b=H/uTF/Eoxvw2GwMlhI6DjswmTDBl3D8TSxCdplaF+ulTBKt+yQ4LJF1X fqyfzJNCg10fMQ2dYJSLSuXJjPz2u40l372iAo/l/LAW/6kWuH1EEMOfW QwT5yBFfNPtUynePj3F/h8s/7PC8yk+xgDOz0mlkd1+Zap+M5INcITqV4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADAPy1GtJV2Y/2dsb2JhbABagwkxSb59gQEWdIIjAQEBBAEBAWsXBAIBCBEEAQELHQcnCxQJCAEBBAESCAGIBQy6NI8aMwUGgnxhA4hqkASKeoUigxGCKA X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227720897" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2013 15:58:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5QFwCsn007918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 15:58:12 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 10:58:11 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099QAAGlhKA= Date: Wed, 26 Jun 2013 15:58:10 +0000 Message-ID: References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.236] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:58:22 -0000 Hi Med, This looks interesting. Comparing with ICE, what is missing are the connect= ivity checks that are particularly important when the IPv6/IPv4 path is bro= ken. So, using PCP for retrieving the external media transport addresses an= d using ICE for concluding on them might work, I think. Muthu =20 |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f |mohamed.boucadair@orange.com |Sent: Wednesday, June 26, 2013 8:35 PM |To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org |Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt | |Dear all, | |I submitted this short I-D to explain how PCP can be used in IPv6 SIP depl= oyments (with a focus on the |managed networks case). | |Cheers, |Med | |-----Message d'origine----- |De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] De la part de internet- |drafts@ietf.org |Envoy=E9=A0: mercredi 26 juin 2013 15:40 |=C0=A0: i-d-announce@ietf.org |Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt | | |A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. | | | Title : PCP for IPv6-enabled SIP Deployments | Author(s) : Mohamed Boucadair | Filename : draft-boucadair-pcp-sip-ipv6-00.txt | Pages : 7 | Date : 2013-06-26 | |Abstract: | This document discusses how PCP can be used in IPv6-enabled SIP | deployments. | | |The IETF datatracker status page for this draft is: |https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 | |There's also a htmlized version available at: |http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 | | |Internet-Drafts are also available by anonymous FTP at: |ftp://ftp.ietf.org/internet-drafts/ | |_______________________________________________ |I-D-Announce mailing list |I-D-Announce@ietf.org |https://www.ietf.org/mailman/listinfo/i-d-announce |Internet-Draft directories: http://www.ietf.org/shadow.html |or ftp://ftp.ietf.org/ietf/1shadow-sites.txt |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From nigel.pattinson@kaseya.com Wed Jun 26 20:41:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF7921F8F29 for ; Wed, 26 Jun 2013 20:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h603DqbDGT1N for ; Wed, 26 Jun 2013 20:41:11 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4DE21F84A8 for ; Wed, 26 Jun 2013 20:41:10 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Us34w-0004uY-Lo for mmusic@ietf.org; Wed, 26 Jun 2013 20:41:08 -0700 Date: Wed, 26 Jun 2013 20:41:02 -0700 (PDT) From: Nigel Pattinson To: mmusic@ietf.org Message-ID: <1372304462652-374094.post@n7.nabble.com> In-Reply-To: <1372174473646-373839.post@n7.nabble.com> References: <1372174473646-373839.post@n7.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 03:41:16 -0000 jakubadamek wrote > could you please tell me roughly how much time it took to implement the > RFC? That's difficult to say - we started from scratch, so had to implement STUN, TURN (client and server), as well as Jingle. Probably the ICE portion was 2 - 3 man months. jakubadamek wrote > And how well does it work for you? We haven't shipped yet, but it seems like it will work fine. However in practice we suspect the outcome will be that host candidates will be used within a LAN, and a relayed connection in almost all other cases. We have all the usual ICE code for server and peer reflexive candidates, and for simultaneous open TCP candidates, but we expect that the cases where they can be successfully used to establish a connection will be rare. Also as my previous post suggested, your TCP code may need to be more different from UDP than the specification might lead you to believe. In the end, if a relayed connection is an acceptable outcome and peer-to-peer is a bonus, then ICE-TCP seems worth investigating. But if peer-to-peer is the priority UDP might be the way to go. Nigel -- View this message in context: http://ietf.10.n7.nabble.com/Comments-on-ICE-TCP-specification-RFC-6544-tp191890p374094.html Sent from the IETF - mmusic mailing list archive at Nabble.com. From adam@nostrum.com Wed Jun 26 22:15:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47E321F9BDC for ; Wed, 26 Jun 2013 22:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e201hOTXtFWS for ; Wed, 26 Jun 2013 22:15:05 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96E21F9BD4 for ; Wed, 26 Jun 2013 22:15:05 -0700 (PDT) Received: from 99-152-145-110.lightspeed.dllstx.sbcglobal.net (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5R5F3Q3038927 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 00:15:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51CBCA56.8040709@nostrum.com> Date: Thu, 27 Jun 2013 00:15:02 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nigel Pattinson References: <1372174473646-373839.post@n7.nabble.com> <1372304462652-374094.post@n7.nabble.com> In-Reply-To: <1372304462652-374094.post@n7.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 05:15:05 -0000 On 6/26/13 22:41, Nigel Pattinson wrote: > However in > practice we suspect the outcome will be that host candidates will be used > within a LAN, and a relayed connection in almost all other cases. How many techniques from sections 5.3 and 5.4 did you implement? Did your implementation make use of the following advice? If the local network or host does not support IPv6 addressing, clients SHOULD make use of other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates. My experience is that Teredo-to-Teredo tunneling has success rates well above 50% (at least for RFC6081 implementations) -- although this is admittedly from my own personal use of Teredo, and is far from a scientific survey. /a From mohamed.boucadair@orange.com Wed Jun 26 22:49:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088B21F9BCE; Wed, 26 Jun 2013 22:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1J7VxIjkobh; Wed, 26 Jun 2013 22:49:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0D421F9BCB; Wed, 26 Jun 2013 22:49:13 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 11851264C83; Thu, 27 Jun 2013 07:49:12 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1D75235C04E; Thu, 27 Jun 2013 07:49:00 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 27 Jun 2013 07:49:00 +0200 From: To: "Muthu Arul Mozhi Perumal (mperumal)" , "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Date: Thu, 27 Jun 2013 07:48:58 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099QAAGlhKAAHPPhkA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C836F@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [MMUSIC] I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:49:17 -0000 Dear Muthu, Thank you for the feedback.=20 For managed networks, there is no need to do connectivity checks. For the g= eneral case, yes PCP can co-exist with ICE as discussed in draft-penno-rtcw= eb-pcp. Various reasons are identified in that document. You may notice this text in the draft which captures this discussion: " Even in deployments where ICE [RFC5245] is required, PCP can be of great help as discussed in [I-D.penno-rtcweb-pcp]. The document is targeting SIP deployments in managed networks." Cheers, Med >-----Message d'origine----- >De=A0: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >Envoy=E9=A0: mercredi 26 juin 2013 17:58 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org; mmusic@ietf.org; >dispatch@ietf.org >Objet=A0: RE: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > >Hi Med, > >This looks interesting. Comparing with ICE, what is missing are the >connectivity checks that are particularly important when the IPv6/IPv4 pat= h >is broken. So, using PCP for retrieving the external media transport >addresses and using ICE for concluding on them might work, I think. > >Muthu > >|-----Original Message----- >|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >Of >|mohamed.boucadair@orange.com >|Sent: Wednesday, June 26, 2013 8:35 PM >|To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org >|Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >| >|Dear all, >| >|I submitted this short I-D to explain how PCP can be used in IPv6 SIP >deployments (with a focus on the >|managed networks case). >| >|Cheers, >|Med >| >|-----Message d'origine----- >|De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] >De la part de internet- >|drafts@ietf.org >|Envoy=E9=A0: mercredi 26 juin 2013 15:40 >|=C0=A0: i-d-announce@ietf.org >|Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >| >| >|A New Internet-Draft is available from the on-line Internet-Drafts >directories. >| >| >| Title : PCP for IPv6-enabled SIP Deployments >| Author(s) : Mohamed Boucadair >| Filename : draft-boucadair-pcp-sip-ipv6-00.txt >| Pages : 7 >| Date : 2013-06-26 >| >|Abstract: >| This document discusses how PCP can be used in IPv6-enabled SIP >| deployments. >| >| >|The IETF datatracker status page for this draft is: >|https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 >| >|There's also a htmlized version available at: >|http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 >| >| >|Internet-Drafts are also available by anonymous FTP at: >|ftp://ftp.ietf.org/internet-drafts/ >| >|_______________________________________________ >|I-D-Announce mailing list >|I-D-Announce@ietf.org >|https://www.ietf.org/mailman/listinfo/i-d-announce >|Internet-Draft directories: http://www.ietf.org/shadow.html >|or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >|_______________________________________________ >|mmusic mailing list >|mmusic@ietf.org >|https://www.ietf.org/mailman/listinfo/mmusic From aurelien.sollaud@orange.com Thu Jun 27 01:22:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682F021F965B for ; Thu, 27 Jun 2013 01:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipq-mLdWmP9S for ; Thu, 27 Jun 2013 01:22:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C321F9A5F for ; Thu, 27 Jun 2013 01:22:30 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 140A53252C9; Thu, 27 Jun 2013 10:22:24 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DCA5C27C046; Thu, 27 Jun 2013 10:22:23 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 10:22:23 +0200 From: To: "mmusic@ietf.org" , "mperumal@cisco.com" , "partha@parthasarathi.co.in" Thread-Topic: comments on draft-ietf-mmusic-sdp-g723-g729-03 Thread-Index: Ac5zD3LDp2qz/2AGQwu/7apfDc5rAA== Date: Thu, 27 Jun 2013 08:22:23 +0000 Message-ID: <19821_1372321344_51CBF63F_19821_1932_3_719DF432C01EA6418EBA5185063A16610D006F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 08:22:36 -0000 Hi I reviewed draft-ietf-mmusic-sdp-g723-g729-03 and I have some comments. The= y are quite symmetrical between G723 and G729. ** Section 3 1) ----- Based on the above, it is best not to use comfort noise frames if the SDP offer or answer indicates that comfort noise is not supported. ----- The words "it is best not to use" are not strong enough, because it can not= work if one of the party do not support comfort noise frames (SID frames i= n the ITU-T Annexes specs). It is rather a "MUST NOT use". The word "restrict the use" in the RFC3551 quote is to be interpreted as "f= orbid the use". ** Section 3.1 2) After the first paragraph, I suggest to insert the new paragraph below: ---NEW The Annex A of the codec concerns both sending and receiving, so both sides of a bi-directional session MUST have the same setting. If one party indicates that it does not support Annex A, Annex A must be deactivated both ways. ----- That defines the general rationale of the following paragraphs. 3) ----- When the offer has G723 with annexa=3Dno then the answer MUST NOT have annexa=3Dyes for G723. Thus the annexa parameter can be turned off by the answerer, but cannot be turned on. ----- I don't think this new requirement is needed. Anyway implementation that will not implement this RFC-to-be will not compl= y with it. Plus, with the following paragraph, it breaks the equivalence between annex= a=3Dyes and annexa omitted. Note that RFC3264 allows the SDP answer to include media format that are no= t present in the SDP offer, so it could be the same for the Annex A support. 4) ----- When the offer has G723 with annexa=3Dno, the reason for not mandating that the answer MUST have annexa=3Dno for G723 is that there are there implementations that omit the annexa parameter in answer and expect the least common denominator to be used. ----- Add the following sentence at the end of the paragraph, to be explicit abou= t the "least common denominator": In such cases the offerer and answerer MUST proceed as if G723 is=20 negotiated with annexa=3Dno. ** Section 3.2 5) After the first two paragraphs, I suggest to insert the new paragraph below: ---NEW The Annex B of the codec concerns both sending and receiving, so both sides of a bi-directional session MUST have the same setting. If one party indicates that it does not support Annex B, Annex B must be deactivated both ways. ----- That defines the general rationale of the following paragraphs. 6) ----- When the offer or answer has G729 and the annexb parameter is absent, it MUST be considered as if the offer or answer has G729 with annexb=3Dyes. ----- This paragraph is redundant with what is said before. Remove it. 7) ----- When the offer has G729 with annexb=3Dno then the answer MUST NOT have annexb=3Dyes for G729. Thus the annexb parameter can be turned off by the answerer, but cannot be turned on. ----- I don't think this new requirement is needed. For the same reason as for G723 8) ----- When the offer has G729 with annexa=3Dno, the reason for not mandating that the answer MUST have annexa=3Dno for G729 is that there are there implementations that omit the annexa parameter in answer and expect the least common denominator to be used. ----- Replace annexa by annexb (copy/paste error I guess) And add the following sentence at the end of the paragraph, to be explicit = about the "least common denominator": In such cases the offerer and answerer MUST proceed as if G729 is=20 negotiated with annexb=3Dno. Best regards, Aurelien ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From palmarti@cisco.com Thu Jun 27 01:35:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C47E21F9C7A for ; Thu, 27 Jun 2013 01:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS2qIb874bwg for ; Thu, 27 Jun 2013 01:35:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BCBEF21F9C79 for ; Thu, 27 Jun 2013 01:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1566; q=dns/txt; s=iport; t=1372322136; x=1373531736; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WAsHJDR3DE96SznZTciet94OP8cFalByJIReLp7kPf0=; b=FGTP48iz2fhIrQl3schWLiXLOfN4pVRWQdL+VT+aaVEutn4jJYLa7909 5lNzNcHlMfz2XjVGFzSShWnW/O+AqQ2ut7TFIyw6RQrmd4u2GUgslJYAg lM21fTygc9EVrI7TZqpox2ZXuR2QBlXQImtyeD+f2miuR1oMXV4yyxzgk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAFX4y1GtJV2Y/2dsb2JhbABbgwl6vwN9FnSCJQEEZyQBKlYnBBsTh3OaAqA6jySDOmEDiGqgIIMRgig X-IronPort-AV: E=Sophos;i="4.87,950,1363132800"; d="scan'208";a="228014593" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jun 2013 08:35:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5R8ZZMW029060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Jun 2013 08:35:35 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 03:35:35 -0500 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnbw== Date: Thu, 27 Jun 2013 08:35:34 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.163] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 08:35:43 -0000 Hi All, We see a need for better application to network communication to convey how= the network should/could treat the different streams described in the meda= lines of the SDP. This is especially important as video codecs have become = very elastic regarding network bandwidth. It would be useful for the networ= k to know the nature regarding the usage of the video stream. The network c= ould treat the stream very differently whatever it is realtime video requir= ing low latency and high bandwidth or is it a more static presentation flow= carrying a slideshow. Getting information from the network to the applicat= ion can also prove to be useful. Todays existing solutions can be difficult to implement on some devices as = the information is carried in the IP header or the markings in the packets = is ignored across administrative domains. Other solution treats the network= as a black box and tries to fix problems when they are discovered. Both th= e network and the application would benefit if information regarding things= that is about to happen as opposed to just happened could be conveyed. We are considering extending ICE connectivity checks and keepalives (STUN) = to provide this communication from the endpoint to the network and from the network to the endpoint. Are other folks seeing this problem as well, or are existing techniques and= throwing bandwidth at the problem sufficient today and sufficient tomorrow= ? Any comments, feedback and ideas are very welcome. Regards P=E5l-Erik Martinsen= From christer.holmberg@ericsson.com Thu Jun 27 02:42:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2AA21F9AFA for ; Thu, 27 Jun 2013 02:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2bBeEK2NTYB for ; Thu, 27 Jun 2013 02:42:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19721F9AF3 for ; Thu, 27 Jun 2013 02:42:31 -0700 (PDT) X-AuditID: c1b4fb25-b7f1e6d00000274b-89-51cc0906dd58 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 43.71.10059.6090CC15; Thu, 27 Jun 2013 11:42:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 11:42:30 +0200 From: Christer Holmberg To: "Pal Martinsen (palmarti)" , mmusic Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRA Date: Thu, 27 Jun 2013 09:42:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvrS4b55lAg3t3lS2mLn/MYvH++koW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjz6/zTAWPBCqWb/jI2MB4h7eLkYNDQsBE YtVkiy5GTiBTTOLCvfVsILaQwGFGif3TZboYuYDsRYwS35rmsYHUswlYSHT/0wapERHwlfhx oo8RJCwsYCjx4KEvRNhIYurfXhaQMIh9ZxErSJhFQFXi45wvLCA2L1DnwumvWCA2+Uhc/fka zOYEir/Z+oIdxGYEuub7qTVMIDazgLjErSfzmSCuFJBYsuc8M4QtKvHy8T9WCFtRov1pAyNE vZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtt YgTGwMEtv1V3MN45J3KIUZqDRUmc9+OpXYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKNn MeVtaPzSsurf4zMqXnffCHdtru5jF1bfw7NtneSkyJ7v0/T+7PC1/vlhayvP3YNRZpfZX5yL XWu67snCPMkZZhuuPZEOnx5kYjK11l027/2uo/FBGs7d6rMnKS+SLs8N+Z3oO3HCqvXBk46G SyxtT5n94MVtjZnaV1/YzikolCor0pTd2K3EUpyRaKjFXFScCACcXDBZTwIAAA== Subject: Re: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 09:42:37 -0000 Hi, I am not really sure what you mean by "how network should treat different s= treams". What kind of network entities are you referring to, and what kind of treatm= ent? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Pal Martinsen (palmarti) Sent: 27. kes=E4kuuta 2013 11:36 To: mmusic Subject: [MMUSIC] Application to Network Communication Hi All, We see a need for better application to network communication to convey how= the network should/could treat the different streams described in the meda= lines of the SDP. This is especially important as video codecs have become = very elastic regarding network bandwidth. It would be useful for the networ= k to know the nature regarding the usage of the video stream. The network c= ould treat the stream very differently whatever it is realtime video requir= ing low latency and high bandwidth or is it a more static presentation flow= carrying a slideshow. Getting information from the network to the applicat= ion can also prove to be useful. Todays existing solutions can be difficult to implement on some devices as = the information is carried in the IP header or the markings in the packets = is ignored across administrative domains. Other solution treats the network= as a black box and tries to fix problems when they are discovered. Both th= e network and the application would benefit if information regarding things= that is about to happen as opposed to just happened could be conveyed. We are considering extending ICE connectivity checks and keepalives (STUN) = to provide this communication from the endpoint to the network and from the= network to the endpoint. Are other folks seeing this problem as well, or are existing techniques and= throwing bandwidth at the problem sufficient today and sufficient tomorrow= ? Any comments, feedback and ideas are very welcome. Regards P=E5l-Erik Martinsen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Thu Jun 27 16:02:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2FE21F9CAB for ; Thu, 27 Jun 2013 16:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOOfiDfybsPu for ; Thu, 27 Jun 2013 16:02:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9FA21F9B64 for ; Thu, 27 Jun 2013 16:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=656; q=dns/txt; s=iport; t=1372374149; x=1373583749; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=VDUBhbeKi0uyoxEhv6Emzt/H29h56ismb7GtikyGXIc=; b=mYxCd1PTGmxUCK4W9iWB1CvMtaW9wMDgx6RASAnN7XytsaypphjppGSR hWFMBS49iiNxM34X+hFWcJeJeRJmZv3COta2TqnhyFNKodIdelqC6txrm uOjltxIiZV5lk5ZC5XG7uq0WxQm8zIwhh6FoiMD4ESZ/rxXjLHtAzx+sH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAMvDzFGtJV2Y/2dsb2JhbABbgwkBwAWBAhZ0gmI2CgE8FhgDAgECAUsNAQcBAYgKu0yOI4Eyg2wDl0WRRYMtIIE1 X-IronPort-AV: E=Sophos;i="4.87,955,1363132800"; d="scan'208";a="228375762" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jun 2013 23:02:28 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5RN2SY9014535; Thu, 27 Jun 2013 23:02:28 GMT Message-ID: <51CCC484.2060903@cisco.com> Date: Thu, 27 Jun 2013 19:02:28 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 23:02:35 -0000 Greetings MMUSIC has been allocated a total of 4 hours for the upcoming IETF 87 in Berlin. If you want to request a time slot to discuss a draft, please send an e-mail to the chairs at this point. As usual, we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. Thanks -- Ari and Flemming From palmarti@cisco.com Fri Jun 28 00:13:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FC921F9DB9 for ; Fri, 28 Jun 2013 00:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.76 X-Spam-Level: X-Spam-Status: No, score=-6.76 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCn4Le7T2JVQ for ; Fri, 28 Jun 2013 00:13:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A6B8A21F9D91 for ; Fri, 28 Jun 2013 00:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4636; q=dns/txt; s=iport; t=1372403606; x=1373613206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KXOnw9RLfh31cexi3wroqZ11w1EdxUTlPGBkzXsrOTo=; b=dNlYSUPUA/ShCqiDuBsooRdzQovoPEovj/Spa29/DMQqLnSge8zr7gDg moFBIyoEyb2V08Oxfjz1ZWRxdiXoq8gFv4YqsVogFK9Q8nS1Zab1fxpIg 9IvOXaNbzPUF2+IFJ5u74tgKAU8g2xwN1ffl0zARaN6CQ7Tl7dkS0xAEC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKI2zVGtJV2Y/2dsb2JhbABbgwkxSb8IgQQWdIIjAQEBAwEBAQFkBAMLBQcEAgEIEQQBAQsdBycLFAkIAgQOBQgTh20GDLtKBI8iAjEHBoJ8YwOIaqAggxGCKA X-IronPort-AV: E=Sophos;i="4.87,957,1363132800"; d="scan'208";a="228486292" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jun 2013 07:13:26 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5S7DQCn022304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 07:13:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 02:13:25 -0500 From: "Pal Martinsen (palmarti)" To: Christer Holmberg Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRAgAG89AA= Date: Fri, 28 Jun 2013 07:13:25 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com> References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.208.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2E65583CBA687D4DA173590C8E95B6FD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 07:13:39 -0000 On Jun 27, 2013, at 11:42 AM, Christer Holmberg wrote: > Hi, >=20 > I am not really sure what you mean by "how network should treat different= streams". >=20 > What kind of network entities are you referring to, and what kind of trea= tment? >=20 Routers, switches, firewalls, NATs, ALGs, SBCs, B2Bs. And a few acronyms I = probably don=B4t know exist. In short any device in the network that rightf= ully or not is or inserts itself in the media path.=20 The name of the draft that currently is being drafted is MALICE (Metadata A= ttribute signaLing with ICE). The basic idea is to signal a set of descript= ive metadata attributes in some of the STUN messages that are sent when an = agent does ICE. The way STUN is crafted makes it easy for network entities = to distinguish the STUN metadata packets and act on the information.=20 One of the short term use cases this can solve is the problem where DSCP ma= rkings can be lost when the packet crosses administrative domains. If metad= ata is sent in-band with STUN it can for instance describe this stream as v= ideo. If SRTP is in use it would be hard/impossible for any network entity = to know that the stream is video without this in-band metadata. So if netwo= rk A and B want to treat video differently by having their own DSCP marking= s they can now do this.=20 MALICE tries to just be a framework for sending the metadata, thus enabling= application to network communication. It also tries to describe how router= s can add useful information to the metadata packets, and how that informat= ion can be sent back to the application without relying on address spoofing= or opening up for multiplying attacks. This opens up for network to applic= ation communication. Like ECN, but more descriptive and it works on more pl= atforms. (I am no expert n the area, but I am under the impression that it = is difficult to get the complete IP header up to the application on some pl= atforms) =20 This can be used in a multitude of ways; Optimising the ICE path selection = based on actual network feedback, making it easier for video application to= choose the correct starting bandwidth, can enable better down/and up speed= ing of video streams. Hopefully there are a lot of other use cases as well.= =20 I don=B4t expect this to be an easy problem to solve. So for now I think th= e big question is: "Is it worthwile trying to come up with machanisms that enable better appli= cation to/from network communication?" .-. P=E5l-Erik > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Pal Martinsen (palmarti) > Sent: 27. kes=E4kuuta 2013 11:36 > To: mmusic > Subject: [MMUSIC] Application to Network Communication >=20 > Hi All, >=20 > We see a need for better application to network communication to convey h= ow the network should/could treat the different streams described in the me= dalines of the SDP. This is especially important as video codecs have becom= e very elastic regarding network bandwidth. It would be useful for the netw= ork to know the nature regarding the usage of the video stream. The network= could treat the stream very differently whatever it is realtime video requ= iring low latency and high bandwidth or is it a more static presentation fl= ow carrying a slideshow. Getting information from the network to the applic= ation can also prove to be useful. >=20 > Todays existing solutions can be difficult to implement on some devices a= s the information is carried in the IP header or the markings in the packet= s is ignored across administrative domains. Other solution treats the netwo= rk as a black box and tries to fix problems when they are discovered. Both = the network and the application would benefit if information regarding thin= gs that is about to happen as opposed to just happened could be conveyed. >=20 > We are considering extending ICE connectivity checks and keepalives (STUN= ) to provide this communication from the endpoint to the network and from t= he network to the endpoint. >=20 > Are other folks seeing this problem as well, or are existing techniques a= nd throwing bandwidth at the problem sufficient today and sufficient tomorr= ow? >=20 > Any comments, feedback and ideas are very welcome. >=20 > Regards > P=E5l-Erik Martinsen > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Simo.Veikkolainen@nokia.com Fri Jun 28 03:36:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1994821F9ECD for ; Fri, 28 Jun 2013 03:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeIjAYLhYNin for ; Fri, 28 Jun 2013 03:36:04 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 228A721F9CAA for ; Fri, 28 Jun 2013 03:36:04 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5SAZvVI013134 for ; Fri, 28 Jun 2013 13:36:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Jun 2013 13:35:57 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.116]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 10:37:50 +0000 From: To: Thread-Topic: Help needed on SDP capneg example using media titles Thread-Index: Ac5z6tzYxi9pUps9SKq5CIiGnRaTGw== Date: Fri, 28 Jun 2013 10:37:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: /l7IPXixAhc7RTUH/zCwpl3wa+q/EbJEBCNLK0yb5eP+UqiYUwkVkCFEF4dEqkOVhwhiOaW0snSvlTJ3Qnti4sMkDYWJaJHzP51hjzxhduMJZaKm1QIsti9AQ5E6SXh9TMrG5akNTsT6bYCSbnWZtrfB1z7l4yJkpXdeTO7LdmRWOq2JRJ/5xC7jr+6lzLwQN6KzrJGPRJIJfq4O1N6jey527uoQQimSLuB2+RBRdl7oN9QGKCHNyacO1b4IiWWJMfZsZ/eZUAoTRWUjKlt5vw== x-originating-ip: [172.21.81.138] Content-Type: multipart/alternative; boundary="_000_D09DAE6B636851459F7575D146EFB54B2409AED4008AM1MPN1024mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2013 10:35:57.0825 (UTC) FILETIME=[46898710:01CE73EB] X-Nokia-AV: Clean Subject: [MMUSIC] Help needed on SDP capneg example using media titles X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 10:36:14 -0000 --_000_D09DAE6B636851459F7575D146EFB54B2409AED4008AM1MPN1024mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WG, http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps extends= SDP Capability Negotiation with a media or session title capability attrib= ute ("a=3Dicap"). I would like to add an example to this draft showing an SDP Offer with a ti= tle capability using a different character encoding than that offered in th= e "i=3D" line, so that if the potential configuration gets selected, the ti= tle would be interpreted in a different charset. I'm not an expert on inte= rnationalization, so I would appreciate some help with this. I'm expecting the SDP Offer to look something like this: v=3D0 o=3D- 25678 753849 IN IP4 192.0.2.1 s=3D c=3DIN IP4 192.0.2.1 t=3D0 0 a=3Dcreq:icap-v0 m=3Dvideo 53456 RTP/AVP 100 a=3Drtpmap:100 H264/90000 i=3Dsome text using the default charset a=3Dicap:1 some text in other charset a=3Dacap:1 charset:ISO-8859-5 a=3Dpcfg:1 a=3D1 i=3D1 where the "i=3D" line is the media title, and an alternative media title is= offered in the "a=3Dicap" attribute line. For the title capability, we nee= d to also indicate the character set which is used to interpret it (in this= example ISO-8859-5 but it could be anything other than the default ISO-106= 46). How is the text in the "a=3Dicap" attribute line to be encoded using this a= lternative character set? I also copy the relevant text from http://tools.ietf.org/html/draft-ietf-mm= usic-sdp-miscellaneous-caps which specifies the usage of charsets with the = "a=3Dicap" attribute: As defined in SDP [RFC4566], the ses= sion information field ("i=3D", referred to as "title" in this document) is subject to the "a=3Dcharset" attribute in order to support different character sets and hence internationalization. The title capability attribute itself ("a=3Dicap") is however not subject to the "a=3Dcharset" attribut= e as this would preclude the inclusion of alternative session/title information each using different character sets. Instead, the session/title value embedded in an "a=3Dicap" attribute (title capability) will be subject to the "a=3Dcharset" value used within a configuration that includes that title capability. This provides for consistent SDP operation while allowing for capabilities and configurations with different session/title information values with different character set encodings (with each such configuration including an "a=3Dcharset" value with the relevant character set for the session/title information in question). Thanks, Simo --_000_D09DAE6B636851459F7575D146EFB54B2409AED4008AM1MPN1024mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello WG,

 

http://tools.ietf.org/html/draft-ietf-mmusic-sd= p-miscellaneous-caps extends SDP Capability Negotiation with a media or= session title capability attribute (“a=3Dicap”).

 

I would like to add an example to this draft showing= an SDP Offer with a title capability using a different character encoding = than that offered in the “i=3D” line, so that if the potential = configuration gets selected, the title would be interpreted in a different charset.  I’m not an expert on inter= nationalization, so I would appreciate some help with this.

 

I’m expecting the SDP Offer to look something = like this:

 

      v=3D0

      o=3D- 25678 753849= IN IP4 192.0.2.1

      s=3D

      c=3DIN IP4 192.0.2= .1

      t=3D0 0=

      a=3Dcreq:icap-v0

      m=3Dvideo 53456 RT= P/AVP 100

      a=3Drtpmap:100 H26= 4/90000

      i=3Dsome text usin= g the default charset

      a=3Dicap:1 some te= xt in other charset

      a=3Dacap:1 charset= :ISO-8859-5

      a=3Dpcfg:1 a=3D1 i= =3D1

 

where the “i=3D” line is the media title= , and an alternative media title is offered in the “a=3Dicap” a= ttribute line. For the title capability, we need to also indicate the chara= cter set which is used to interpret it (in this example ISO-8859-5 but it could be anything other than the default ISO-10646).

 

How is the text in the “a=3Dicap” attrib= ute line to be encoded using this alternative character set?

 

I also copy the relevant text from http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps whi= ch specifies the usage of charsets with the “a=3Dicap” attribut= e:

 

   As defined in SDP [RFC45=
66], the session information field ("i=3D",=

   referred to as "title" in this document) i=
s subject to the
   "a=3Dcharset" attribute in order to suppor=
t different character sets
   and hence internationalization.  The title capa=
bility attribute
   itself ("a=3Dicap") is however not subject=
 to the "a=3Dcharset" attribute
   as this would preclude the inclusion of alternative =
session/title
   information each using different character sets.&nbs=
p; Instead, the
   session/title value embedded in an "a=3Dicap&qu=
ot; attribute (title
   capability) will be subject to the "a=3Dcharset=
" value used within a
   configuration that includes that title capability.&n=
bsp; This provides for
   consistent SDP operation while allowing for capabili=
ties and
   configurations with different session/title informat=
ion values with
   different character set encodings (with each such co=
nfiguration
   including an "a=3Dcharset" value with the =
relevant character set for
   the session/title information in question).

 


Thanks,

Simo

--_000_D09DAE6B636851459F7575D146EFB54B2409AED4008AM1MPN1024mg_-- From christer.holmberg@ericsson.com Fri Jun 28 04:06:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8021F9C65 for ; Fri, 28 Jun 2013 04:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n0Z3ek3sAmU for ; Fri, 28 Jun 2013 04:06:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 370A521F9D3E for ; Fri, 28 Jun 2013 04:06:17 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-22-51cd6e27ca08 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.95.19388.72E6DC15; Fri, 28 Jun 2013 13:06:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 13:06:15 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NP//+aaA///Dn0CAAGQQgP/+2P9ggAKfFYD//lfdEA== Date: Fri, 28 Jun 2013 11:06:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BE516@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> <51C9B3A9.2000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BB686@ESESSMB209.ericsson.se> <51CAEF23.5060305@alum.mit.edu> In-Reply-To: <51CAEF23.5060305@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra5G3tlAg0WXeSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj824LU8EHjYpTn7qYGxhXK3QxcnJICJhI vJj2nxnCFpO4cG89WxcjF4eQwGFGiR+b17NDOIsYJR4928naxcjBwSZgIdH9TxvEFBHQkJi0 VQ3EZBZQl7i6OAhkjLBAssSUN3/ZQGwRgRSJu/vPs0PYYRItDQ+YQcpZBFQlVj2WAwnzCvhK TOpeyAKxaDeTxISlM8B6OQV0JK7cfgHWywh02vdTa5hAbGYBcYlbT+YzQZwsILFkz3mo80Ul Xj7+xwphK0q0P21ghKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkb23MTMnPRy802MwPg4uOW3wQ7GTffFDjFKc7AoifNu1jsTKCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGx9qH4nJ7dKa93LH/444BouClj/Pnnrqc13rtz9xVwb1hykTP5jnxGxUT1 1qZ4x93SH/R2re/R/+P874Pevs0BdmuM6ye+bC7hNTJ/avC6ZSLrta+9Wn+F35YknnfcsCqA p7L0V0HT+cU/0kPnRpq9PB53/87WoIkyeSmrNm1YL2R5XL/97md7JZbijERDLeai4kQAZP+f sF0CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 11:06:29 -0000 Hi, >>>>> The exception to this are those packets that deal only with those=20 >>>>> aspects of the bundle that are common. The most obvious example of th= is is ICE. But if *all* packets are common to all the m-lines then there is= no reason for the bundle. >>>> >>>> Correct. For ICE we explicitly say that the STUN messages apply to the= whole BUNDLE group. >>> >>> It can in principle apply to more than just ICE. >>> >>> Somewhere I commented that the field describes more than just=20 >>> the low level transport protocol. It often describes a whole protocol=20 >>> stack with many layers. When we bundle multiple m-lines with=20 >>> different fields, they have different stacks. For the bundle=20 >>> to be valid, at least the bottom level of each stack must be the=20 >>> same. (E.g., UDP.) >> >> I think we should use whatever "stack" is referenced in the 5-tuple defi= nition. >> >>> There may be more layers in common among some or all of the stacks.=20 >>> When some of the m-lines have multiple layers in common, then there may= be some packets that pertain to housekeeping of the layer, and so need not= be associated with one particular m-line. >>> >>> For instance, *in principle* one could bundle multiple DTLS/SCTP=20 >>> m-lines together. Then there could be some SCTP housekeeping packets=20 >>> that can't be associated with a single m-line, but for this to work,=20 >>> SCTP payload packets would need to be distinguishable, probably by=20 >>> SCTP port. (Note, I'm not sure if there are any SCTP packets that=20 >>> don't have an SCTP port, so this might not be a good example. And of=20 >>> course for this example to work there would need to be a way to=20 >>> specify the SCTP port in SDP for DTLS/SCTP.) >>> >>> AFAIK, for stuff *currently* under discussion only ICE falls into=20 >>> this category. But if we are going to define bundle so it can be applie= d to future cases then we need to phrase the constraint properly. >> >> Sure, but it is not (I hope) the task of BUNDLE to define HOW data is ma= pped to m- lines for all kind of transport protocols. > > No, Bundle can't define this for all possible m-lines. > > But it can call out the requirement that this must be possible for a bund= le to be valid, and that it is the responsibility of the answerer to ensure= that. > > Part of that is for the answerer to ensure that the *offerer* will be abl= e to do it, and that both ends agree about *how* it will be done. (So that = the sender and receiver of each packet agree on which m-line it is associat= ed with.) > > I am not sure if there is ever a need to *explicitly* signal what > mechanism(s) are to be used, or if it can always be inferred from the pre= sence in the SDP of the data needed for the association. Assuming we do mandate mapping to m- lines, the Offer should only place m- = lines in a BUNDLE group in a way that allows it to do the mapping. The same goes for the Answerer. If it's not able to do mapping (e.g. becaus= e it does not support an extension which would be required to do the mappin= g), it should either remove m- line(s) from the BUNDLE group, or reject m- = line(s). Exactly HOW the mapping is done, and what SDP information it may require, i= s out of the scope of BUNDLE - perhaps with the exception of mapping betwee= n DTLS/SCTP and RTP (see below). > The place where this is an issue is if there is data in the answer that w= ould allow the offerer to do the association, but the answerer is not certa= in if the offerer is prepared to use that data for that purpose. Well, as the Offerer has assigned the m- lines to the BUNDLE group, it need= s to be able to do the mapping using *A* mechanism. SDP attributes etc can = then be used to provide more information and data associated with such mech= anisms. >> We are going to specify/reference something for RTP, but do you think BU= NDLE should also e.g. define a mechanism=20 >> for transporting SCTP ports in SDP? We COULD (I assume it would be a rat= her simply task), but should we? > > We had this discussion already. IIUC there was consensus that the SDP for= DTLS/SCTP would *not* include a way to convey the=20 > SCTP port, so that only a single default port can be used. This implies t= hat one can't bundle two m-lines for this together.=20 > While I didn't agree with this decision, I can live with it until (if eve= r) a need arises. But, I guess BUNDLE doesn't need to explicitly forbid the usage of multiple= DTLS/SCTP m- lines, as there in future might be a mechanism which allows t= o map DTLS/SCTP data to the correct DTLS/SCTP m- line. It would go under a = general "if-you-can't-demux-it-don't-put-it-in-the-bundle-group" rule. > But I do think it needs to specify how to demux a bundle including a DTLS= /SCTP and some RTP m-lines. I personally agree with that. There are basically two things: 1) How to demux between DTLS/SCTP and RTP. 2) With multiple RTP m- lines, how to map data to the correct one. Regards, Christer PS. I will leave for my summer vacation today, so I will not read my e-mail= on a daily basis during that time. From christer.holmberg@ericsson.com Fri Jun 28 04:25:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C61B21F9F1E for ; Fri, 28 Jun 2013 04:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5tSpj+KBX87 for ; Fri, 28 Jun 2013 04:25:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1521F9EAC for ; Fri, 28 Jun 2013 04:25:30 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-14-51cd72a90d2d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.A7.19388.9A27DC15; Fri, 28 Jun 2013 13:25:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 13:25:29 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Thread-Index: Ac5z8ekD0a7SetWORja/n46Ib+raCQ== Date: Fri, 28 Jun 2013 11:25:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BE558@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BE558ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvre6qorOBBkunMFpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXNXb2crmKpcce7UHrYGxglyXYycHBICJhI7vvYwQ9hiEhfu rWfrYuTiEBI4zChxa9k7KGcRo0TP3RtMXYwcHGwCFhLd/7RBGkQE1CW+7oVoFhaIlVh87g0L RDxJYvPNK0wQtp7E/zsfwVpZBFQl/n8wBzF5BXwl1jSlgFQwAq39fmoNWDWzgLjErSfzmSDO EZBYsuc81GmiEi8f/2OFsBUl2p82MELU50ucXT2bHcTmFRCUODnzCcsERqFZSEbNQlI2C0kZ RFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XInpuYmZNebr6JERjyB7f8NtjBuOm+2CFG aQ4WJXHezXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwru5szK4508QueGnTiaoHnDeM +6t51RLOi5wo93ltK7L309tfPQ32zxTU8lwnfrLx+ZcvUGSs8HPyxOJnE1teuBnLHZ7h5HWN 7U9Mwts01olbnuW+LEibczfjKcv82O3lmYyR2x9fnsR9maHy944A+ePHbt5ck5z9iTMk52m6 Rla8u/lE+SOflViKMxINtZiLihMBrcpAREcCAAA= Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 11:25:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BE558ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In Q1, I asked whether we can agree that a PT value can only be used for a = single codec configuration. Eventhough the question is still open, the feed= back received so far seem to indicate that people agree to that. We have also discussed whether it should, within a BUNDLE group, be allowed= to use the same PT value in multiple m- lines - if used for the same codec= configuration. I will now put forward a question on that :) Q7: Within a BUNDLE group, do we allow the usage of the same PT value in mu= ltiple RTP m- lines, for the SAME codec configuration? Note: This of course prevents the mapping to m- line purely based on PT, an= d based on the outcome of that discussion we may have to add restrictions o= n when the same PT value can be used etc. But, this question is whether we = generally want to allow the usage of the same PT value in multiple m- lines= :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BE558ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In Q1, I asked whether we can agree that a PT value = can only be used for a single codec configuration. Eventhough the question = is still open, the feedback received so far seem to indicate that people ag= ree to that.

 

We have also discussed whether it should, within a B= UNDLE group, be allowed to use the same PT value in multiple m- lines – if used for the same code= c configuration. I will now put forward a question on that :)

 

 

Q7: Within a BUNDLE group, do we allow the us= age of the same PT value in multiple RTP m- lines, for the SAME codec confi= guration?

 

Note: This of course prevents the mapping to m- line= purely based on PT, and based on the outcome of that discussion we may hav= e to add restrictions on when the same PT value can be used etc. But, this = question is whether we generally want to allow the usage of the same PT value in multiple m= - lines :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3BE558ESESSMB209erics_-- From christer.holmberg@ericsson.com Fri Jun 28 05:19:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45B521F9C91 for ; Fri, 28 Jun 2013 05:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PAI1HkVv7wK for ; Fri, 28 Jun 2013 05:19:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D3D6C21F846E for ; Fri, 28 Jun 2013 05:19:26 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-2e-51cd7f4b80ee Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 12.9D.19388.B4F7DC15; Fri, 28 Jun 2013 14:19:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 14:19:23 +0200 From: Christer Holmberg To: "Pal Martinsen (palmarti)" Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRAgAG89ACAAABJEA== Date: Fri, 28 Jun 2013 12:19:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BE5EA@ESESSMB209.ericsson.se> References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com> In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra53/dlAg8MrtCymLn/MYvH++koW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj/9NNrAXHtSqeXbZqYFyr1MXIySEhYCKx 9Mg/JghbTOLCvfVsXYxcHEIChxkleo48ZIRwFjFKTPrwEyjDwcEmYCHR/U8bpEFEwFii+chR dhCbWUBGYsbZRiaQEmEBQ4kHD30hSowkpv7tZYGwnSRuzH/JBmKzCKhKrPlxiRXE5hXwlVhw ehMLxKrLjBLPFneBHcQJlFg4fxFYMyPQcd9PrWGC2CUucevJfKijBSSW7DnPDGGLSrx8/I8V wlaUaH/awAhRrydxY+oUNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWM 7LmJmTnp5eabGIERcnDLb4MdjJvuix1ilOZgURLn3ax3JlBIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QD4/EsU/WKfOUnnH8ckl/YHnEUc54i6/lt71+DmMIe01yNwuTqRp+pwedmX5EOnmq5 b1PFUY73y8uZPmo9ma58bNrcTFbtJ3Gqbp+3OEXVluwqLxTb1W438YHDRO1bQeG8Zp/kWfew +Chd4f0mx5idKBqzYiXfocnm8QzVZyKfruk8b/dk/9dpSizFGYmGWsxFxYkAANV2Kl4CAAA= Cc: mmusic Subject: Re: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 12:19:43 -0000 Hi, I guess my questions will be answered once I read the draft, but I'll ask a= couple of high-level questions at this point anyway :) Q1: How will you associate the STUN requests with a given media flow? If yo= ur answer is based on IP address:port, do you then assume that there will b= e only a single flow per IP address:port? Q2: You say that the network will provide information using STUN requests. = Will the network piggyback information in the STUN requests sent by the ICE= endpoints, or will the network generate their own STUN requests? Regards, Christer -----Original Message----- From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Sent: 28. kes=E4kuuta 2013 10:13 To: Christer Holmberg Cc: mmusic Subject: Re: Application to Network Communication On Jun 27, 2013, at 11:42 AM, Christer Holmberg wrote: > Hi, >=20 > I am not really sure what you mean by "how network should treat different= streams". >=20 > What kind of network entities are you referring to, and what kind of trea= tment? >=20 Routers, switches, firewalls, NATs, ALGs, SBCs, B2Bs. And a few acronyms I = probably don=B4t know exist. In short any device in the network that rightf= ully or not is or inserts itself in the media path.=20 The name of the draft that currently is being drafted is MALICE (Metadata A= ttribute signaLing with ICE). The basic idea is to signal a set of descript= ive metadata attributes in some of the STUN messages that are sent when an = agent does ICE. The way STUN is crafted makes it easy for network entities = to distinguish the STUN metadata packets and act on the information.=20 One of the short term use cases this can solve is the problem where DSCP ma= rkings can be lost when the packet crosses administrative domains. If metad= ata is sent in-band with STUN it can for instance describe this stream as v= ideo. If SRTP is in use it would be hard/impossible for any network entity = to know that the stream is video without this in-band metadata. So if netwo= rk A and B want to treat video differently by having their own DSCP marking= s they can now do this.=20 MALICE tries to just be a framework for sending the metadata, thus enabling= application to network communication. It also tries to describe how router= s can add useful information to the metadata packets, and how that informat= ion can be sent back to the application without relying on address spoofing= or opening up for multiplying attacks. This opens up for network to applic= ation communication. Like ECN, but more descriptive and it works on more pl= atforms. (I am no expert n the area, but I am under the impression that it = is difficult to get the complete IP header up to the application on some pl= atforms) =20 This can be used in a multitude of ways; Optimising the ICE path selection = based on actual network feedback, making it easier for video application to= choose the correct starting bandwidth, can enable better down/and up speed= ing of video streams. Hopefully there are a lot of other use cases as well.= =20 I don=B4t expect this to be an easy problem to solve. So for now I think th= e big question is: "Is it worthwile trying to come up with machanisms that enable better appli= cation to/from network communication?" .-. P=E5l-Erik > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Pal Martinsen (palmarti) > Sent: 27. kes=E4kuuta 2013 11:36 > To: mmusic > Subject: [MMUSIC] Application to Network Communication >=20 > Hi All, >=20 > We see a need for better application to network communication to convey h= ow the network should/could treat the different streams described in the me= dalines of the SDP. This is especially important as video codecs have becom= e very elastic regarding network bandwidth. It would be useful for the netw= ork to know the nature regarding the usage of the video stream. The network= could treat the stream very differently whatever it is realtime video requ= iring low latency and high bandwidth or is it a more static presentation fl= ow carrying a slideshow. Getting information from the network to the applic= ation can also prove to be useful. >=20 > Todays existing solutions can be difficult to implement on some devices a= s the information is carried in the IP header or the markings in the packet= s is ignored across administrative domains. Other solution treats the netwo= rk as a black box and tries to fix problems when they are discovered. Both = the network and the application would benefit if information regarding thin= gs that is about to happen as opposed to just happened could be conveyed. >=20 > We are considering extending ICE connectivity checks and keepalives (STUN= ) to provide this communication from the endpoint to the network and from t= he network to the endpoint. >=20 > Are other folks seeing this problem as well, or are existing techniques a= nd throwing bandwidth at the problem sufficient today and sufficient tomorr= ow? >=20 > Any comments, feedback and ideas are very welcome. >=20 > Regards > P=E5l-Erik Martinsen > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From palmarti@cisco.com Fri Jun 28 06:41:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD43B21F9C1F for ; Fri, 28 Jun 2013 06:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.059 X-Spam-Level: X-Spam-Status: No, score=-8.059 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4Sv-jGFOBze for ; Fri, 28 Jun 2013 06:41:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3F21F9374 for ; Fri, 28 Jun 2013 06:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6313; q=dns/txt; s=iport; t=1372426860; x=1373636460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6y+mBC2Q/Av1PTSwvEatkfHH+2gZ3LvBNc4hiiYXCPg=; b=eJ6AZEJDRTZU2YdEp6y/BU4jwwG37XcBZQu+8onDw/5HGCn2l+WCslNQ bch76g7BD6TLRUNWpGY3bwmIhq4K8wzBCfPMl/+aFLlnNB9eSWFHLUlUV gbJTgF7kYkV6OsOw2Raf6XZYoDBunqECAAoTYSubWvW4r9FBj8CsNSoT+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANeQzVGtJV2d/2dsb2JhbABbgwkxSb8KgQYWdIIjAQEBAwEBAQFkBAMLBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIE4dtBgy7eASPIgIxBwaCfGMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228609596" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jun 2013 13:40:58 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5SDew2k006296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 13:40:58 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 08:40:58 -0500 From: "Pal Martinsen (palmarti)" To: Christer Holmberg Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRAgAG89ACAAABJEIAAa/0A Date: Fri, 28 Jun 2013 13:40:57 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB114289C4@xmb-rcd-x06.cisco.com> References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BE5EA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BE5EA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.209.39] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5E6F3B890C2329418B2E85B6D2832EC1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 13:41:04 -0000 On Jun 28, 2013, at 14:19 PM, Christer Holmberg wrote: > Hi, >=20 > I guess my questions will be answered once I read the draft, but I'll ask= a couple of high-level questions at this point anyway :) I am afraid that the draft will open up for more questions than answers.;-) >=20 > Q1: How will you associate the STUN requests with a given media flow? If = your answer is based on IP address:port, do you then assume that there will= be only a single flow per IP address:port? The STUN messages are sent on the same 5-tuple as media, so the metadata in= the STUN packets needs to describe whatever is being sent on that 5-tuple. Introducing BUNDLE into this is interesting=85 But again I think that is up= to what the metadata want to describe. If audio and video is flowing on th= e same 5-tuple, that needs to be described.=20 >=20 > Q2: You say that the network will provide information using STUN requests= . Will the network piggyback information in the STUN requests sent by the I= CE endpoints, or will the network generate their own STUN requests? >=20 Piggyback. The plan is to add attributes the network elements can write inf= ormation into. That might save some mallocs on the network side.=20 .-. P=E5l-Erik > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 > Sent: 28. kes=E4kuuta 2013 10:13 > To: Christer Holmberg > Cc: mmusic > Subject: Re: Application to Network Communication >=20 >=20 > On Jun 27, 2013, at 11:42 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> I am not really sure what you mean by "how network should treat differen= t streams". >>=20 >> What kind of network entities are you referring to, and what kind of tre= atment? >>=20 >=20 > Routers, switches, firewalls, NATs, ALGs, SBCs, B2Bs. And a few acronyms = I probably don=B4t know exist. In short any device in the network that righ= tfully or not is or inserts itself in the media path.=20 >=20 > The name of the draft that currently is being drafted is MALICE (Metadata= Attribute signaLing with ICE). The basic idea is to signal a set of descri= ptive metadata attributes in some of the STUN messages that are sent when a= n agent does ICE. The way STUN is crafted makes it easy for network entitie= s to distinguish the STUN metadata packets and act on the information.=20 >=20 > One of the short term use cases this can solve is the problem where DSCP = markings can be lost when the packet crosses administrative domains. If met= adata is sent in-band with STUN it can for instance describe this stream as= video. If SRTP is in use it would be hard/impossible for any network entit= y to know that the stream is video without this in-band metadata. So if net= work A and B want to treat video differently by having their own DSCP marki= ngs they can now do this.=20 >=20 > MALICE tries to just be a framework for sending the metadata, thus enabli= ng application to network communication. It also tries to describe how rout= ers can add useful information to the metadata packets, and how that inform= ation can be sent back to the application without relying on address spoofi= ng or opening up for multiplying attacks. This opens up for network to appl= ication communication. Like ECN, but more descriptive and it works on more = platforms. (I am no expert n the area, but I am under the impression that i= t is difficult to get the complete IP header up to the application on some = platforms) >=20 > This can be used in a multitude of ways; Optimising the ICE path selectio= n based on actual network feedback, making it easier for video application = to choose the correct starting bandwidth, can enable better down/and up spe= eding of video streams. Hopefully there are a lot of other use cases as wel= l.=20 >=20 > I don=B4t expect this to be an easy problem to solve. So for now I think = the big question is: > "Is it worthwile trying to come up with machanisms that enable better app= lication to/from network communication?" >=20 > .-. > P=E5l-Erik >=20 >=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Pal Martinsen (palmarti) >> Sent: 27. kes=E4kuuta 2013 11:36 >> To: mmusic >> Subject: [MMUSIC] Application to Network Communication >>=20 >> Hi All, >>=20 >> We see a need for better application to network communication to convey = how the network should/could treat the different streams described in the m= edalines of the SDP. This is especially important as video codecs have beco= me very elastic regarding network bandwidth. It would be useful for the net= work to know the nature regarding the usage of the video stream. The networ= k could treat the stream very differently whatever it is realtime video req= uiring low latency and high bandwidth or is it a more static presentation f= low carrying a slideshow. Getting information from the network to the appli= cation can also prove to be useful. >>=20 >> Todays existing solutions can be difficult to implement on some devices = as the information is carried in the IP header or the markings in the packe= ts is ignored across administrative domains. Other solution treats the netw= ork as a black box and tries to fix problems when they are discovered. Both= the network and the application would benefit if information regarding thi= ngs that is about to happen as opposed to just happened could be conveyed. >>=20 >> We are considering extending ICE connectivity checks and keepalives (STU= N) to provide this communication from the endpoint to the network and from = the network to the endpoint. >>=20 >> Are other folks seeing this problem as well, or are existing techniques = and throwing bandwidth at the problem sufficient today and sufficient tomor= row? >>=20 >> Any comments, feedback and ideas are very welcome. >>=20 >> Regards >> P=E5l-Erik Martinsen >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From pkyzivat@alum.mit.edu Fri Jun 28 08:34:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F11D21F9BAA for ; Fri, 28 Jun 2013 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Di0mXuJZNUL for ; Fri, 28 Jun 2013 08:34:52 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id CE06521F9BC1 for ; Fri, 28 Jun 2013 08:34:51 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id tpcu1l00B17dt5G5DraqXL; Fri, 28 Jun 2013 15:34:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id traq1l00b3ZTu2S3Zraq7e; Fri, 28 Jun 2013 15:34:50 +0000 Message-ID: <51CDAD19.4060609@alum.mit.edu> Date: Fri, 28 Jun 2013 11:34:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <51C9925F.9000901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BAC94@ESESSMB209.ericsson.se> <51C9B3A9.2000106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BB686@ESESSMB209.ericsson.se> <51CAEF23.5060305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3BE516@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BE516@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372433690; bh=WVPhR3fPQprfU8xgO3n+UXHjzAtd/B+AH2SSDDSw87s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X2UrnmLhOdUK4ehe4A2A4Wuw8TlCWPvZUJYiNKx4LvmVd5Iq2vNOHzmXKcDsmX1k4 iPcBWKKmIZB+GurAnwhWXjz7v/qrsCGz6kQoamz9uxoH49Cp+WYAtDjAdXGkhWJtqt NVGXQpwYh/cMCP+Xf3cTBLRfxCnqvsostsO2r7CQRLEIxbZPdQth9BllMRynKQ+pRH 7S1JiqVBsf0hrE5gLsKrcOjjBGJy0ASMkF+qcRcrJv1AEvCoEB9PtS6J1BOt4if6+0 Qnlxb9yt73PqAoH1wRvj3dVDyumfCtt1ajv00zpQPqN//xX1eTHGuRGmIQLZr422/z Wv8tqgskn7h0g== Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 15:34:56 -0000 Christer, I think we are mostly in agreement here. I've put one question inline. Have a good vacation. Don't work too hard while on vacation. (But do at least check your email every 5 minutes! :-) See you in Berlin. On 6/28/13 7:06 AM, Christer Holmberg wrote: > Hi, > >>>>>> The exception to this are those packets that deal only with those >>>>>> aspects of the bundle that are common. The most obvious example of this is ICE. But if *all* packets are common to all the m-lines then there is no reason for the bundle. >>>>> >>>>> Correct. For ICE we explicitly say that the STUN messages apply to the whole BUNDLE group. >>>> >>>> It can in principle apply to more than just ICE. >>>> >>>> Somewhere I commented that the field describes more than just >>>> the low level transport protocol. It often describes a whole protocol >>>> stack with many layers. When we bundle multiple m-lines with >>>> different fields, they have different stacks. For the bundle >>>> to be valid, at least the bottom level of each stack must be the >>>> same. (E.g., UDP.) >>> >>> I think we should use whatever "stack" is referenced in the 5-tuple definition. >>> >>>> There may be more layers in common among some or all of the stacks. >>>> When some of the m-lines have multiple layers in common, then there may be some packets that pertain to housekeeping of the layer, and so need not be associated with one particular m-line. >>>> >>>> For instance, *in principle* one could bundle multiple DTLS/SCTP >>>> m-lines together. Then there could be some SCTP housekeeping packets >>>> that can't be associated with a single m-line, but for this to work, >>>> SCTP payload packets would need to be distinguishable, probably by >>>> SCTP port. (Note, I'm not sure if there are any SCTP packets that >>>> don't have an SCTP port, so this might not be a good example. And of >>>> course for this example to work there would need to be a way to >>>> specify the SCTP port in SDP for DTLS/SCTP.) >>>> >>>> AFAIK, for stuff *currently* under discussion only ICE falls into >>>> this category. But if we are going to define bundle so it can be applied to future cases then we need to phrase the constraint properly. >>> >>> Sure, but it is not (I hope) the task of BUNDLE to define HOW data is mapped to m- lines for all kind of transport protocols. >> >> No, Bundle can't define this for all possible m-lines. >> >> But it can call out the requirement that this must be possible for a bundle to be valid, and that it is the responsibility of the answerer to ensure that. >> >> Part of that is for the answerer to ensure that the *offerer* will be able to do it, and that both ends agree about *how* it will be done. (So that the sender and receiver of each packet agree on which m-line it is associated with.) >> >> I am not sure if there is ever a need to *explicitly* signal what >> mechanism(s) are to be used, or if it can always be inferred from the presence in the SDP of the data needed for the association. > > Assuming we do mandate mapping to m- lines, the Offer should only place m- lines in a BUNDLE group in a way that allows it to do the mapping. > > The same goes for the Answerer. If it's not able to do mapping (e.g. because it does not support an extension which would be required to do the mapping), it should either remove m- line(s) from the BUNDLE group, or reject m- line(s). > > Exactly HOW the mapping is done, and what SDP information it may require, is out of the scope of BUNDLE - perhaps with the exception of mapping between DTLS/SCTP and RTP (see below). > >> The place where this is an issue is if there is data in the answer that would allow the offerer to do the association, but the answerer is not certain if the offerer is prepared to use that data for that purpose. > > Well, as the Offerer has assigned the m- lines to the BUNDLE group, it needs to be able to do the mapping using *A* mechanism. SDP attributes etc can then be used to provide more information and data associated with such mechanisms. I think this will usually be sufficient. But I haven't convinced myself that there aren't some possible exceptions. So I would like others to think about this - try to find exceptions, and report if you find one. >>> We are going to specify/reference something for RTP, but do you think BUNDLE should also e.g. define a mechanism >>> for transporting SCTP ports in SDP? We COULD (I assume it would be a rather simply task), but should we? >> >> We had this discussion already. IIUC there was consensus that the SDP for DTLS/SCTP would *not* include a way to convey the >> SCTP port, so that only a single default port can be used. This implies that one can't bundle two m-lines for this together. >> While I didn't agree with this decision, I can live with it until (if ever) a need arises. > > But, I guess BUNDLE doesn't need to explicitly forbid the usage of multiple DTLS/SCTP m- lines, as there in future might be a mechanism which allows to map DTLS/SCTP data to the correct DTLS/SCTP m- line. It would go under a general "if-you-can't-demux-it-don't-put-it-in-the-bundle-group" rule. > >> But I do think it needs to specify how to demux a bundle including a DTLS/SCTP and some RTP m-lines. > > I personally agree with that. There are basically two things: > > 1) How to demux between DTLS/SCTP and RTP. > > 2) With multiple RTP m- lines, how to map data to the correct one. > > Regards, > > Christer > > PS. I will leave for my summer vacation today, so I will not read my e-mail on a daily basis during that time. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Fri Jun 28 08:42:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C6621F9C2B for ; Fri, 28 Jun 2013 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+RONSzJWMsu for ; Fri, 28 Jun 2013 08:42:22 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id B88A421F9C32 for ; Fri, 28 Jun 2013 08:42:21 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id trco1l0021HzFnQ58riLEk; Fri, 28 Jun 2013 15:42:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id triL1l00T3ZTu2S3ariLvM; Fri, 28 Jun 2013 15:42:20 +0000 Message-ID: <51CDAEDB.9060802@alum.mit.edu> Date: Fri, 28 Jun 2013 11:42:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372434140; bh=m8ipXO2/W/Q70Uvy4ObW4EZMUd80djKzqKD9gGiw7YU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oK6Jcp3Q5hxOEiQPqzq7IcbWEO63rboXq9JSTGIZpCOMIvtv+PyEWAmrlAVfVAdmw VxtpqEMgispLjjJUicu6fyDCLSBP9d9fH2hL8r59i/YRTJDUSf1yDCMWOTZQi5vok2 H/VJgRHQnYuPTgGpvxL1+kdYrUvimccijb4hD7UPHyptCZRXkb1PTDTqyhdOz+uKQK 0jib7ruzhDAD8B6s1kPtsctPPyIUuss1LFe2fvs5NBLHa5Sg5C3yTAi4EaUneXDg2f 3s+4iHzpoJj9BWGNXWdW+wLDWEuF3vJ/7PFUXHK7Kh/zSVh4U77ZmOw8cbgiViL1v7 u3sjLGGBdpAEw== Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:42:26 -0000 On 6/28/13 7:25 AM, Christer Holmberg wrote: > Hi, > > In Q1, I asked whether we can agree that a PT value can only be used for > a single codec configuration. Eventhough the question is still open, the > feedback received so far seem to indicate that people agree to that. > > We have also discussed whether it should, within a BUNDLE group, be > allowed to use the *same PT value in multiple m- lines* – if used for > the same codec configuration. I will now put forward a question on that :) > > *Q7*: Within a BUNDLE group, do we allow the usage of the same PT value > in multiple RTP m- lines, for the SAME codec configuration? Q7: YES But it may be necessary to clarify both Q1 and Q7: This technically applies to a SDP offer or answer. While the values are normally preserved between offer and answer, that isn't required. Also, PTs can change in a subsequent O/A, though it could be disruptive if they do, and I have never seen any discussion of how the transition is to be handled. Thanks, Paul > Note: This of course prevents the mapping to m- line purely based on PT, > and based on the outcome of that discussion we may have to add > restrictions on when the same PT value can be used etc. But, this > question is whether we *generally* want to allow the usage of the same > PT value in multiple m- lines :) > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From roni.even@mail01.huawei.com Fri Jun 28 08:55:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B179021F9AF3 for ; Fri, 28 Jun 2013 08:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSeKrkucTtPh for ; Fri, 28 Jun 2013 08:55:36 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (hwsga01-in.huaweimarine.com [58.251.153.223]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8E621F9AE1 for ; Fri, 28 Jun 2013 08:55:35 -0700 (PDT) Received: from 172.24.1.78 (EHLO szxpml203-edg.exmail.huawei.com) ([172.24.1.78]) by szxrg11-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id ATE39376; Fri, 28 Jun 2013 23:55:32 +0800 (CST) Received: from SZXPML406-HUB.exmail.huawei.com (10.82.67.70) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Jun 2013 23:54:11 +0800 Received: from SZXPML504-MBS.exmail.huawei.com ([169.254.4.230]) by szxpml406-hub.exmail.huawei.com ([10.82.67.70]) with mapi id 14.01.0323.003; Fri, 28 Jun 2013 23:54:38 +0800 From: Roni Even To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-even-mmusic-application-token-00.txt Thread-Index: AQHOdBQi4UsiD7x+ekSL/jyFB3uX+5lLQJx8 Date: Fri, 28 Jun 2013 15:54:38 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> In-Reply-To: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:55:40 -0000 Hi, We have submitted this document that defines a mechanism to provide the ma= pping between the SSRCs of RTP streams and the application semantics by defining extensio= ns to RTP and RTCP messages. It defines a new SDP attribute, RTCP SDES message and RTP header extension = for this puropose. The document explains how it can be used with the differ= ent multiplexing proposal (Plan A, Plan B and no plan). It can be used also in CLUE to map SSRCs to Clue media capture. Please review and send comments Thanks Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, June 28, 2013 6:27 PM To: Jonathan Lennox; Qin Wu; Roni Even Subject: New Version Notification for draft-even-mmusic-application-token= -00.txt A new version of I-D, draft-even-mmusic-application-token-00.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-mmusic-application-token Revision: 00 Title: The Session Description Protocol (SDP) Application Token A= ttribute Creation date: 2013-06-28 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-appl= ication-token-00.txt Status: http://datatracker.ietf.org/doc/draft-even-mmusic-applicat= ion-token Htmlized: http://tools.ietf.org/html/draft-even-mmusic-application-t= oken-00 Abstract: The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how you de-multiplex streams within an RTP session, but in some use cases applications need further identifiers in order to identify the application semantics associated with particular streams within the session. This document defines a mechanism to provide the mapping between the SSRCs of RTP streams and the application semantics by defining extensions to RTP and RTCP messages. The IETF Secretariat= From emcho@sip-communicator.org Fri Jun 28 09:42:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632F621F9B94 for ; Fri, 28 Jun 2013 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWQUdxi5OZYF for ; Fri, 28 Jun 2013 09:42:08 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 44DEA21F9BC4 for ; Fri, 28 Jun 2013 09:42:06 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf11so2646586pab.24 for ; Fri, 28 Jun 2013 09:42:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=I9YSh9la2dE2uxS30d19OrDp47gAJsEEoTIrE7sJssg=; b=T98FqOB8nlKn7LH0yTwekMfccopDbmjtT8qPyHY/uOU6EILh4kLQ7ySRn+ctqzlid1 RlTh1eTZg/EgTcKbZ9F6vj7Rq8/gmd8QhZtSMtL3elMU3L3qd8LIgrjRiGNJMyZWQuhq qWraa/9bgR8juNIuyL2U79jTIUtL3v1UuzaB0e5RUAdWbpiFke9y141AWaL4ii6/KVcH li9xQ/7xCGzHZ2SfsuS1vs1Fmz8oxCNj/hlpRL8JVYTArT04wSTmM7dEAmLvEHZl1nqZ l2F9X5ieLy1dpOnEPeWz/4xe4ZP4vfHPG60Z2C0iqb97BYE8yhWfszGve4ZuqsnZW8Rn kX5w== X-Received: by 10.68.222.135 with SMTP id qm7mr12176428pbc.38.1372437725566; Fri, 28 Jun 2013 09:42:05 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [2607:f8b0:400e:c01::22a]) by mx.google.com with ESMTPSA id y9sm8834185pbb.46.2013.06.28.09.42.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 09:42:05 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so2488390pbc.15 for ; Fri, 28 Jun 2013 09:42:05 -0700 (PDT) X-Received: by 10.68.241.135 with SMTP id wi7mr12337374pbc.88.1372437724985; Fri, 28 Jun 2013 09:42:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.12.41 with HTTP; Fri, 28 Jun 2013 09:41:44 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> From: Emil Ivov Date: Fri, 28 Jun 2013 18:41:44 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl06p1IT8Asv7/tQ6VgbW0tujQTWwC132W5ALEraow367TfPXgMPZ1ebedpTVvthIoJIWo5 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:42:14 -0000 On Fri, Jun 28, 2013 at 1:25 PM, Christer Holmberg wrote: > Q7: Within a BUNDLE group, do we allow the usage of the same PT value in > multiple RTP m- lines, for the SAME codec configuration? Generally yes. > Note: This of course prevents the mapping to m- line purely based on PT, You mean, only in case its actually used and not as a general BUNDLE rule, right? Emil From pkyzivat@alum.mit.edu Fri Jun 28 09:57:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DA321F9A08 for ; Fri, 28 Jun 2013 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwJTCUFVeyPM for ; Fri, 28 Jun 2013 09:57:21 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA4321F9950 for ; Fri, 28 Jun 2013 09:57:20 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id tpgW1l0051uE5Es5CsxLzz; Fri, 28 Jun 2013 16:57:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id tsxL1l00R3ZTu2S3csxLnr; Fri, 28 Jun 2013 16:57:20 +0000 Message-ID: <51CDC06F.8070607@alum.mit.edu> Date: Fri, 28 Jun 2013 12:57:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372438640; bh=8bMypzF7z42hp9we2/dWYJ++fJ/ycjhVIO0KaNPGcm4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ixRoUjUnn8RTk1zce4z/DnYSpn0+VI6ZBcDuokm6IhvlKXlK6Ka27dsPsbWszY/Pv ztnYf/l0jGiSnKFMyPw2QbUPVpzyyis4Nd4pIFn31yZ8l6aEED4zGh67HEpjBQfySO dIsGrglSUK3eL69V1rEwUixRJQrqPDRowgqnUDLQXjW1M9tIUeRQlLEIkc2M6cHu8G wIBXGmvecXVbUoiyuvc3nJ4ekVVF+pWYeIGuLP86FYn6ajKu2mYIfApD8SNoQJ5Boy 313RaSCoxk/gpY2iEf1IsgIJMKcDPB9+YlMjmcLFxJHaG8KuDjyt+Mb2nyy9A2c+fT 0+wsUfKhyfbeg== Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:57:27 -0000 On 6/28/13 12:41 PM, Emil Ivov wrote: > On Fri, Jun 28, 2013 at 1:25 PM, Christer Holmberg > wrote: > >> Q7: Within a BUNDLE group, do we allow the usage of the same PT value in >> multiple RTP m- lines, for the SAME codec configuration? > > Generally yes. > >> Note: This of course prevents the mapping to m- line purely based on PT, > > You mean, only in case its actually used and not as a general BUNDLE > rule, right? I'm not sure I understand the distinction you are drawing. The point is that when a packet with this PT is received, you won't be able to use the PT to determine which m-line in the bundle the packet should be associated with. There must have been *some* reason that two m-lines were used, with the same PT, rather than just one. Each m-line heads a media section of the SDP that contains a bunch of declarations. Some of those are part of the payload description and so are the same. Something else must be different in those two media sections, or else a single media section would have been enough. Presumably whatever it is that is different is intended to affect how received packets are processed or interpreted. If you can't associate the packet with the m-line, then you don't know which of the multiple interpretations to apply to the packet. Thanks, Paul From emil@sip-communicator.org Fri Jun 28 13:12:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14B21F9C5A for ; Fri, 28 Jun 2013 13:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV1NgGH1KOok for ; Fri, 28 Jun 2013 13:12:18 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7C90821F9C45 for ; Fri, 28 Jun 2013 13:12:17 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so2012954wgh.7 for ; Fri, 28 Jun 2013 13:12:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=0ABwZ+ocBwaTdzGkSL1otuxNv+MoyVxijfn4S8h/BEY=; b=e5qYbykWbJuu2RL5yiKmvnHXUwCalYYTn23+MUwsv0Ej3s9I0CnzTebsYIUQFnghgl 8/TvkjtMYu39YON3fHeqtEKp7E/wgKSBsPfeC8Ei85I99MhwRHQheWy0uPorbc99YC6T z6n+nqr70EnvQGf4pxTQkKg+zPbDdHFy/pdUogz7D5CUYYBr6KPy167vjoZVLzuBPboP VeOJNasys08EmXAoJHZfj8S3bDr5I1va324o6Dg5loPJpQM+JVXPSUjRoyl9HgY9vNqg nZf1hkQjKoD2avHRIo2e2OTW08tkclXUaGAp0YP19NClLRBfmAXuh3L+ADL9BxWXrmDI 2J3g== X-Received: by 10.180.11.146 with SMTP id q18mr3490628wib.50.1372450337188; Fri, 28 Jun 2013 13:12:17 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:bd21:a94c:89bf:5d80]) by mx.google.com with ESMTPSA id cd11sm75705wib.10.2013.06.28.13.12.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 13:12:16 -0700 (PDT) Message-ID: <51CDEE1E.5010701@jitsi.org> Date: Fri, 28 Jun 2013 22:12:14 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <51CDC06F.8070607@alum.mit.edu> In-Reply-To: <51CDC06F.8070607@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQltVAMMWorqxEPioUbqrjsoFQnLxbb2tKB7bNJZU/Tb5dLFC5245mPEDVb1640Co+IiWD68 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:12:23 -0000 Hey Paul, On 28.06.13, 18:57, Paul Kyzivat wrote: > On 6/28/13 12:41 PM, Emil Ivov wrote: >> On Fri, Jun 28, 2013 at 1:25 PM, Christer Holmberg >> wrote: >> >>> Q7: Within a BUNDLE group, do we allow the usage of the same PT value in >>> multiple RTP m- lines, for the SAME codec configuration? >> >> Generally yes. >> >>> Note: This of course prevents the mapping to m- line purely based on PT, >> >> You mean, only in case its actually used and not as a general BUNDLE >> rule, right? > > I'm not sure I understand the distinction you are drawing. What I meant was that if one doesn't reuse PTs on multiple m- lines in the SDP, they could continue relying solely on PT for demuxing. Or in other words, I wanted to confirm that we weren't about to make an alternative demuxing mechanism mandatory for use of BUNDLE. Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Fri Jun 28 14:01:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5D221F9A94 for ; Fri, 28 Jun 2013 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEwmaurm17m2 for ; Fri, 28 Jun 2013 14:01:17 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 6722621F9A90 for ; Fri, 28 Jun 2013 14:01:17 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id tvdp1l0031uE5Es56x1G8N; Fri, 28 Jun 2013 21:01:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id tx1G1l00b3ZTu2S3cx1G1k; Fri, 28 Jun 2013 21:01:16 +0000 Message-ID: <51CDF99B.1080808@alum.mit.edu> Date: Fri, 28 Jun 2013 17:01:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <51CDC06F.8070607@alum.mit.edu> <51CDEE1E.5010701@jitsi.org> In-Reply-To: <51CDEE1E.5010701@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372453276; bh=sFhcHvrvR2xtE739o6w6D1UWwMn2EMAe6hd/Dw0tSfY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YPh9vAYMxr1TjjtVoY33cfdDwdsTO85RPPzJdwY7i3/8e1NuNGZifKwlhFEsFzqwr 5yXDK75yryuhuQ2cntx6jKgfKLNEesxGDvRGdFSz0jccpzAJ9yY/jYRpTm4FhrrpAu dUQKEmPX3i4vD8Ci3degIIerZ3GXhZK5T6zUKN4hLjyTXC/vkwDJcqDB4MzYekYnBO ND4YHe+RivjOwhWnhrPSxpMLdWbIZFXiTz1sIIMrSHxPFupOXRRtkDsF0MOX5x3Eif 5qr8yz26MBAuDxnbPeweY5B/QjkQ0HaREWwx1X0G/hsJUck9ReWwcQgJ90x7vJxmdF aDfg5UapG8gyw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 21:01:23 -0000 On 6/28/13 4:12 PM, Emil Ivov wrote: > Hey Paul, > > On 28.06.13, 18:57, Paul Kyzivat wrote: >> On 6/28/13 12:41 PM, Emil Ivov wrote: >>> On Fri, Jun 28, 2013 at 1:25 PM, Christer Holmberg >>> wrote: >>> >>>> Q7: Within a BUNDLE group, do we allow the usage of the same PT >>>> value in >>>> multiple RTP m- lines, for the SAME codec configuration? >>> >>> Generally yes. >>> >>>> Note: This of course prevents the mapping to m- line purely based on >>>> PT, >>> >>> You mean, only in case its actually used and not as a general BUNDLE >>> rule, right? >> >> I'm not sure I understand the distinction you are drawing. > > What I meant was that if one doesn't reuse PTs on multiple m- lines in > the SDP, they could continue relying solely on PT for demuxing. Yes, I intend that to be true. Christer and I are only talking about the situation when the same PT *is* used on multiple m-lines. Thanks, Paul > Or in other words, I wanted to confirm that we weren't about to make an > alternative demuxing mechanism mandatory for use of BUNDLE. > > Emil > > From christer.holmberg@ericsson.com Fri Jun 28 15:07:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B7021F9D1F for ; Fri, 28 Jun 2013 15:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+1Bu813oduV for ; Fri, 28 Jun 2013 15:07:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7D21F9CEF for ; Fri, 28 Jun 2013 15:07:25 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-07-51ce091a8a8a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 82.FE.19388.A190EC15; Sat, 29 Jun 2013 00:07:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 00:07:21 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Thread-Index: Ac5z8ekD0a7SetWORja/n46Ib+raCQAE2YGAABF7S7A= Date: Fri, 28 Jun 2013 22:07:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BEA2C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <51CDAEDB.9060802@alum.mit.edu> In-Reply-To: <51CDAEDB.9060802@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvra4U57lAg+mrBC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj0cNPTAVH+Sombr3H2sC4h7uLkZNDQsBE 4sTRf4wQtpjEhXvr2boYuTiEBA4zSszdehzKWcQosad9HnMXIwcHm4CFRPc/bZAGEQFfiWeP b7OBhIUFsiSmPAiCCGdLbFy2hAnCtpL4/WAhC4jNIqAq8e1qJ9guXqDWx1/PMIPYQgL5Eovf 9YPZnAI6ErMn9oLVMwLd8/3UGrA5zALiEh8OXmeGuFNAYsme81C2qMTLx/9YIWwliR8bLrFA 1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOern5 JkZgJBzc8ttgB+Om+2KHGKU5WJTEeTfrnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhj Ec58uHpZdt6GwoMS7p+vxO57za6SI3Pp5AKt19zeEjMUrz/0vtJeGFn1KePdT6NY5fzJz27K /N8hcaqnMEiw88Kci+qB85dtEHg5X4IhJP02f90KzgzJDr3cfT6pmr+tanLEd+qo7NMS61TZ 7VhTGVj0uCnjM+t/ZY/gKwlm7d1Jyg1blViKMxINtZiLihMBPKebnlICAAA= Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:07:31 -0000 Hi, >> In Q1, I asked whether we can agree that a PT value can only be used=20 >> for a single codec configuration. Eventhough the question is still=20 >> open, the feedback received so far seem to indicate that people agree to= that. >> >> We have also discussed whether it should, within a BUNDLE group, be=20 >> allowed to use the *same PT value in multiple m- lines* - if used for=20 >> the same codec configuration. I will now put forward a question on=20 >> that :) >> >> *Q7*: Within a BUNDLE group, do we allow the usage of the same PT=20 >> value in multiple RTP m- lines, for the SAME codec configuration? > > Q7: YES > > But it may be necessary to clarify both Q1 and Q7: > > This technically applies to a SDP offer or answer. While the values are n= ormally preserved between offer and answer, that isn't required. Correct. > Also, PTs can change in a subsequent O/A,=20 Correct. So, to clarify, I am referring to any given Offer, or any given Answer. > though it could be disruptive if they do, and I have never seen any discu= ssion of how the transition is to be handled. True. But, that is not BUNDLE specific, is it? Regards, Chrsiter > Note: This of course prevents the mapping to m- line purely based on=20 > PT, and based on the outcome of that discussion we may have to add=20 > restrictions on when the same PT value can be used etc. But, this=20 > question is whether we *generally* want to allow the usage of the same=20 > PT value in multiple m- lines :) > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Jun 28 15:11:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B621F9A59 for ; Fri, 28 Jun 2013 15:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.712 X-Spam-Level: X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3VcN2sMnqF8 for ; Fri, 28 Jun 2013 15:11:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8721F9A3B for ; Fri, 28 Jun 2013 15:11:15 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-3f-51ce0a02a6df Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 73.2F.19388.20A0EC15; Sat, 29 Jun 2013 00:11:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 00:11:12 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Thread-Index: Ac5z8ekD0a7SetWORja/n46Ib+raCQAG7LsAAA+VV+A= Date: Fri, 28 Jun 2013 22:11:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BEA3C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvrS4T17lAg689AhZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyti0YBlrwUzWign95xgbGH8zdzFyckgImEjM frWPDcIWk7hwbz2QzcUhJHCYUWLvtoUsEM4iRonPtz4wdjFycLAJWEh0/9MGaRARkJfoblvE BBJmFlCXuLo4CMQUFsiSmPIgCKIiW2LjsiVMELaVxNX1V5hBSlgEVCXar7CDhHkFfCWONK5n hFg0hVFi5+OdYAlOgUCJX40zWEBsRqDTvp9aAzaHWUBc4sPB61DnC0gs2XMeyhaVePn4HyuE rSTxY8MlFoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGJk z03MzEkvN9/ECIyOg1t+G+xg3HRf7BCjNAeLkjjvZr0zgUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYrY6tqos00cmoSRToO8sgr3s+zClR12YeQ+Pmi0mVsflmqpcVTM+LKzBvzalNfsju yDjTXeLK4afKXxTmmEeo1P54N++JIefj690rVzE0/F00N7FZZdP/UjPtmkAbbQGj7JPK75c8 v2JZNKHlw47PBXoTKgTEc/wD/dgOv6/k7/xqeaZd7oMSS3FGoqEWc1FxIgBtkntIXAIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:11:22 -0000 Hi, >> Q7: Within a BUNDLE group, do we allow the usage of the same PT value=20 >> in multiple RTP m- lines, for the SAME codec configuration? > > Generally yes. > >> Note: This of course prevents the mapping to m- line purely based on=20 >> PT, > > You mean, only in case its actually used and not as a general BUNDLE rule= , right? I mean what I said: this of course prevents the mapping to m- line purely b= ased on PT. Whether mapping based on PT is going to de defined as a "default" rule, and= /or whether we are going to mandate entities to always be able to map to m-= line, is part of another discussion :) Regards, Christer From christer.holmberg@ericsson.com Fri Jun 28 15:17:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8675121F9CEC for ; Fri, 28 Jun 2013 15:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl+WxKtZh++K for ; Fri, 28 Jun 2013 15:17:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 048F121F9CDA for ; Fri, 28 Jun 2013 15:17:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-af-51ce0b7bb8ba Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 36.DD.06741.B7B0EC15; Sat, 29 Jun 2013 00:17:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 00:17:31 +0200 From: Christer Holmberg To: Paul Kyzivat , Emil Ivov Thread-Topic: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Thread-Index: Ac5z8ekD0a7SetWORja/n46Ib+raCQAG7LsAAACLU4AABs6xAAABtj+AAAa+KGA= Date: Fri, 28 Jun 2013 22:17:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BEA60@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <51CDC06F.8070607@alum.mit.edu> <51CDEE1E.5010701@jitsi.org> <51CDF99B.1080808@alum.mit.edu> In-Reply-To: <51CDF99B.1080808@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW4197lAg9tn1C3W7JzAYjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBl/O66yFrwlKviQ9MH1gbG QxxdjJwcEgImEpemvWeBsMUkLtxbz9bFyMUhJHCYUeL2+gWsEM4iRomZO3cDZTg42AQsJLr/ aYOYIgKuEvOeKYKYzALqElcXB4GYwgJZElMeBIFMFBHIlti4bAkThO0n8XBlJ9gmFgFViekT 54HFeQV8JY5Nns4KYgsJfGWUePxFDcTmFNCR+Dv1DjuIzQh02fdTa8DqmQXEJT4cvM4McbGA xJI956FsUYmXj/+xQthKEj82XGKBqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ2FlI WmYhaZmFpGUBI8sqRvbcxMyc9HLDTYzAeDm45bfuDsZT50QOMUpzsCiJ827SOxMoJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgVFjvkaevdzKPtOvPuxhi9tPneu5KrpgwUWmD23FZ7s6rp2c ZV+6mf/9C6v9N9ZFSzySW5DiHcu0+uhLZdsFR259+6fy8BjHvasNSWYdTAVH5CPCZKbwLi4I Fj56c+Xn1B0RtuvKP7x9Ni8l1j8wrf2rv/Qk8fDuWTJz0mZXONiwB6UF+8bOLlNiKc5INNRi LipOBAB5+JEJZQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:17:38 -0000 Hi, >>>>> Q7: Within a BUNDLE group, do we allow the usage of the same PT=20 >>>>> value in multiple RTP m- lines, for the SAME codec configuration? >>>> >>>> Generally yes. >>>> >>>>> Note: This of course prevents the mapping to m- line purely based=20 >>>>> on PT, >>>> >>>> You mean, only in case its actually used and not as a general BUNDLE=20 >>>> rule, right? >>> >>> I'm not sure I understand the distinction you are drawing. >> >> What I meant was that if one doesn't reuse PTs on multiple m- lines in=20 >> the SDP, they could continue relying solely on PT for demuxing. > > Yes, I intend that to be true. Christer and I are only talking about the = situation when the same PT *is* used on multiple m-lines. Correct. > Or in other words, I wanted to confirm that we weren't about to make an a= lternative demuxing mechanism mandatory for use of BUNDLE. We are still discussing whether we are going to have a mandatory RTP demuxi= ng mechanism to begin with (Q3), and, if so, what mechanism it should be (Q= 4) :) Regards, Christer > Or in other words, I wanted to confirm that we weren't about to make=20 > an alternative demuxing mechanism mandatory for use of BUNDLE. > > Emil > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Jun 28 15:28:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C3721F9D58 for ; Fri, 28 Jun 2013 15:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+R4AG6CSRy9 for ; Fri, 28 Jun 2013 15:28:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3694621F9D6A for ; Fri, 28 Jun 2013 15:27:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-13-51ce0dee475e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D9.1E.06741.EED0EC15; Sat, 29 Jun 2013 00:27:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 00:27:57 +0200 From: Christer Holmberg To: "Pal Martinsen (palmarti)" Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRAgAG89ACAAABJEIAAa/0AgAA8kYA= Date: Fri, 28 Jun 2013 22:27:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BEA73@ESESSMB209.ericsson.se> References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BE5EA@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB114289C4@xmb-rcd-x06.cisco.com> In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB114289C4@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvre473nOBBt/OiFpMXf6YxeL99ZUs DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfG3zULWAt2mlfc3/aYpYFxs04XIyeHhICJ xMxjE1kgbDGJC/fWs3UxcnEICRxmlFg8rQHKWcQosa13M1MXIwcHm4CFRPc/bZAGEQFjieYj R9lBbGYBGYkZZxuZQGxhAUOJVxNPsEPUGElM/dvLAmH7SextuMYGYrMIqEpc37yHFcTmFfCV WP33ODPErltMEhPXbAcr4gRKbFn/BqyZEei676fWMEEsE5f4cPA6M8TVAhJL9pyHskUlXj7+ xwphK0n82HCJBaJeT+LG1ClsELa2xLKFr5khFgtKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYws qxjZcxMzc9LLDTcxAqPk4JbfujsYT50TOcQozcGiJM67Se9MoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbG0rfP9cPYI/nMeGb953v4YNI+hVPzfd6uMjI4E3rN7ldq9+RtWjk7ry+NLXp1 K+Wli1XI3haBgwxi6d4T1U0Wf51bu4nfKotD5bfN0jNzjcT/fWJYq/rlrXGNUVXgNbNWtdi/ 7jYmxa1+/IaPpf6amxyZ/zX3zJLZtjrcfz777S9bUtYlljtNiaU4I9FQi7moOBEAWAIvGGAC AAA= Cc: mmusic Subject: Re: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 22:28:07 -0000 Hi, >> I guess my questions will be answered once I read the draft, but I'll as= k a couple of high-level questions at this point anyway :) > > I am afraid that the draft will open up for more questions than answers.;= -) Well, at least it's good if the questions come before the draft is publishe= d as RFC :) >> Q1: How will you associate the STUN requests with a given media flow? If= your answer is based on IP address:port, do you=20 >> then assume that there will be only a single flow= per IP address:port? >> > > The STUN messages are sent on the same 5-tuple as media, so the metadata = in the STUN packets needs to describe whatever is being sent on that 5-tupl= e. > > Introducing BUNDLE into this is interesting. But again I think that is up= to what the metadata want to describe. If audio and video is flowing on th= e same 5-tuple, that needs to be described.=20 BUNDLE is one case, but there are also discussions about sending multiple m= edia flows of the same media type, separated by SSRC, on the same 5-tuple. = The SDP a=3Dssrc attribute might be enough to signal that, so you wouldn't = need BUNDLE. >> Q2: You say that the network will provide information using STUN request= s. Will the network piggyback information in the STUN requests sent by the = ICE endpoints, or will the network generate their own STUN requests? >>=20 > Piggyback. The plan is to add attributes the network elements can write i= nformation into. That might save some mallocs on the network side.=20 Keep in mind that if one endpoint is ICE lite, it won't send any STUN conne= ctivity check requests (only responses) or keep-alives. That might not be a= n issue in UA-to-UA scenarios, where both ICE endpoints are typically full = ICE.=20 But, if one ICE endpoint is located within the network it will often be ICE= lite. Now, I don't think you would have to mandate those to become full IC= E, but I guess they at least would need to send keep-alives, in order to al= low piggybacking of data in both directions. Regards, Christer > -----Original Message----- > From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 > Sent: 28. kes=E4kuuta 2013 10:13 > To: Christer Holmberg > Cc: mmusic > Subject: Re: Application to Network Communication >=20 >=20 > On Jun 27, 2013, at 11:42 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> I am not really sure what you mean by "how network should treat differen= t streams". >>=20 >> What kind of network entities are you referring to, and what kind of tre= atment? >>=20 >=20 > Routers, switches, firewalls, NATs, ALGs, SBCs, B2Bs. And a few acronyms = I probably don=B4t know exist. In short any device in the network that righ= tfully or not is or inserts itself in the media path.=20 >=20 > The name of the draft that currently is being drafted is MALICE (Metadata= Attribute signaLing with ICE). The basic idea is to signal a set of descri= ptive metadata attributes in some of the STUN messages that are sent when a= n agent does ICE. The way STUN is crafted makes it easy for network entitie= s to distinguish the STUN metadata packets and act on the information.=20 >=20 > One of the short term use cases this can solve is the problem where DSCP = markings can be lost when the packet crosses administrative domains. If met= adata is sent in-band with STUN it can for instance describe this stream as= video. If SRTP is in use it would be hard/impossible for any network entit= y to know that the stream is video without this in-band metadata. So if net= work A and B want to treat video differently by having their own DSCP marki= ngs they can now do this.=20 >=20 > MALICE tries to just be a framework for sending the metadata, thus enabli= ng application to network communication. It also tries to describe how rout= ers can add useful information to the metadata packets, and how that inform= ation can be sent back to the application without relying on address spoofi= ng or opening up for multiplying attacks. This opens up for network to appl= ication communication. Like ECN, but more descriptive and it works on more = platforms. (I am no expert n the area, but I am under the impression that i= t is difficult to get the complete IP header up to the application on some = platforms) >=20 > This can be used in a multitude of ways; Optimising the ICE path selectio= n based on actual network feedback, making it easier for video application = to choose the correct starting bandwidth, can enable better down/and up spe= eding of video streams. Hopefully there are a lot of other use cases as wel= l.=20 >=20 > I don=B4t expect this to be an easy problem to solve. So for now I think = the big question is: > "Is it worthwile trying to come up with machanisms that enable better app= lication to/from network communication?" >=20 > .-. > P=E5l-Erik >=20 >=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Pal Martinsen (palmarti) >> Sent: 27. kes=E4kuuta 2013 11:36 >> To: mmusic >> Subject: [MMUSIC] Application to Network Communication >>=20 >> Hi All, >>=20 >> We see a need for better application to network communication to convey = how the network should/could treat the different streams described in the m= edalines of the SDP. This is especially important as video codecs have beco= me very elastic regarding network bandwidth. It would be useful for the net= work to know the nature regarding the usage of the video stream. The networ= k could treat the stream very differently whatever it is realtime video req= uiring low latency and high bandwidth or is it a more static presentation f= low carrying a slideshow. Getting information from the network to the appli= cation can also prove to be useful. >>=20 >> Todays existing solutions can be difficult to implement on some devices = as the information is carried in the IP header or the markings in the packe= ts is ignored across administrative domains. Other solution treats the netw= ork as a black box and tries to fix problems when they are discovered. Both= the network and the application would benefit if information regarding thi= ngs that is about to happen as opposed to just happened could be conveyed. >>=20 >> We are considering extending ICE connectivity checks and keepalives (STU= N) to provide this communication from the endpoint to the network and from = the network to the endpoint. >>=20 >> Are other folks seeing this problem as well, or are existing techniques = and throwing bandwidth at the problem sufficient today and sufficient tomor= row? >>=20 >> Any comments, feedback and ideas are very welcome. >>=20 >> Regards >> P=E5l-Erik Martinsen >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From ron.even.tlv@gmail.com Sat Jun 29 00:31:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815B311E80A2 for ; Sat, 29 Jun 2013 00:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afeUU+n6hqeH for ; Sat, 29 Jun 2013 00:31:49 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C54F321F9958 for ; Sat, 29 Jun 2013 00:31:48 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so1857272wev.28 for ; Sat, 29 Jun 2013 00:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=oVu//zJemrsldKREBDxPe/ZT6pnvQT+g3hKBYOWu7XE=; b=huKnaiA4jRmDoVlNQl86QMvigpp/WCxdc1dol6GMpSyrif2xjKFlcIboqeoJOJ2imO 6C9TIIqs3o/NQsS3Pq/ZN+qOtt+YxjjqoczLN8LzifR1sa6NRZJ3EKn8jM5bUqakHt0Q Yr+rrkcK/fRsCXJ2Hoir81zB6TP4J7bHe5oEXNqbRgK3B2CPkEoV2RDNWexpgTPCMSk1 jH9jChUnF8/AgRARYqs1pw7Wr/BMKaifD8B0TtYyTwGAT44e+bFX5QWWnv8EYiKdDFwk H2AUl+bbPAvkH58qhlpHHBIaCWuV+bBd9k0VjPRBZUZhs/iZcP2w1wpZNrKh/c2pTR7u g7Qg== X-Received: by 10.194.63.229 with SMTP id j5mr12528784wjs.79.1372491107958; Sat, 29 Jun 2013 00:31:47 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id fd3sm2207389wic.10.2013.06.29.00.31.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 29 Jun 2013 00:31:47 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> Date: Sat, 29 Jun 2013 10:30:19 +0300 Message-ID: <042501ce749a$84521300$8cf63900$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01CE74B3.A9A03560" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHh/gpGsmWjhOKpyEWXgP0lggNVQZklNNLA Content-Language: en-us Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 07:31:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0426_01CE74B3.A9A03560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Q7: I am not sure how you define the same configuration. Do you mean that all the attributes are the same so the m-lines are identical. For example same a=imageattr or b= a=content and so on. In this case I do not understand the use case for it. I see no problem if each of the m-line will have an a=ssrc to define the RTP stream but if not the mapping will be problematic. Roni From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28 June, 2013 2:25 PM To: mmusic@ietf.org Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Hi, In Q1, I asked whether we can agree that a PT value can only be used for a single codec configuration. Eventhough the question is still open, the feedback received so far seem to indicate that people agree to that. We have also discussed whether it should, within a BUNDLE group, be allowed to use the same PT value in multiple m- lines - if used for the same codec configuration. I will now put forward a question on that :) Q7: Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration? Note: This of course prevents the mapping to m- line purely based on PT, and based on the outcome of that discussion we may have to add restrictions on when the same PT value can be used etc. But, this question is whether we generally want to allow the usage of the same PT value in multiple m- lines :) Regards, Christer ------=_NextPart_000_0426_01CE74B3.A9A03560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Q7:

I am not sure how you = define the same configuration. Do you mean that all the attributes are = the same so the m-lines are identical.

For example same = a=3Dimageattr or b=3D a=3Dcontent and so on. In this case I do not = understand the use case for it.

I see no problem if each = of the m-line will have an a=3Dssrc to define the RTP stream but if not = the mapping will be problematic.

 

Roni

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: 28 June, 2013 2:25 = PM
To: mmusic@ietf.org
Subject: [MMUSIC] DECISION: = Usage of same PT value in multiple m- lines for SAME codec = configuration

 

Hi,

 

In Q1, I = asked whether we can agree that a PT value can only be used for a single = codec configuration. Eventhough the question is still open, the feedback = received so far seem to indicate that people agree to = that.

 

We have also discussed whether it should, within a = BUNDLE group, be allowed to use the same PT value in multiple m- = lines – if used for the same codec configuration. I will now = put forward a question on that :)

 

 

Q7: = Within a BUNDLE group, do we allow the usage of the same PT value in = multiple RTP m- lines, for the SAME codec = configuration?

 

Note: This = of course prevents the mapping to m- line purely based on PT, and based = on the outcome of that discussion we may have to add restrictions on = when the same PT value can be used etc. But, this question is whether we = generally want to allow the usage of the same PT value in = multiple m- lines :)

 

Regards,

 

Christer

------=_NextPart_000_0426_01CE74B3.A9A03560-- From christer.holmberg@ericsson.com Sat Jun 29 00:45:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A2A21F9E30 for ; Sat, 29 Jun 2013 00:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.888 X-Spam-Level: X-Spam-Status: No, score=-4.888 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwrtSktJBaQW for ; Sat, 29 Jun 2013 00:44:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D396E21F9E27 for ; Sat, 29 Jun 2013 00:44:56 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-f1-51ce907221ce Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 96.0C.05990.2709EC15; Sat, 29 Jun 2013 09:44:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 09:44:50 +0200 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Thread-Index: Ac5z8ekD0a7SetWORja/n46Ib+raCQAl9UmAAAST8eA= Date: Sat, 29 Jun 2013 07:44:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BEC06@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <042501ce749a$84521300$8cf63900$@gmail.com> In-Reply-To: <042501ce749a$84521300$8cf63900$@gmail.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BEC06ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrW7xhHOBBjPCLKYuf8xi8bed2YHJ Y+esu+weS5b8ZApgiuKySUnNySxLLdK3S+DKeHjnKkvB7YCKR6eWMjUwrnXrYuTgkBAwkTj0 r6yLkRPIFJO4cG89WxcjF4eQwGFGibbvv5ggnEWMElN232MGaWATsJDo/qcN0iAi4C2xuGcF WFhYIEtiyoMgiHC2xMZlS5ggbCuJQ5tWgtksAqoSk9vWsIPYvAK+EosfrWUFsYUEqiU2b1gB VsMJNP3Z1z6wGkage76fWgMWZxYQl/hw8DozxJ0CEkv2nIeyRSVePv7HCmErSfzYcIkFoj5f YtnNzcwQuwQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZ VzGy5yZm5qSXG21iBMbMwS2/VXcw3jkncohRmoNFSZx3s96ZQCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M4jzXe56u5CzPfG+/sEf1lNXKxHRJQ+bYtW+W+Ae7Bwt/bZMoUwyfJ2y79MrJ YJsO3vs3sxVFVhRXJS+2aixd+vzO5/QAq6+pB647JG6trkucKPnk+AVPX79Xzn5NTfP/79wp tbmAzfL35u5JC1tyln082vNtCpOjuPuK95+f5ztMXvay8wifEktxRqKhFnNRcSIAafkF9WcC AAA= Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 07:45:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BEC06ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, > Q7: >I am not sure how you define the same configuration. Do you mean that all = the attributes are the same so the m-lines are identical. Something like that - this is the opportunity for you media plane people to= be creative and come up with good wording :) >For example same a=3Dimageattr or b=3D a=3Dcontent and so on. In this case= I do not understand the use case for it. >I see no problem if each of the m-line will have an a=3Dssrc to define the= RTP stream but if not the mapping will be problematic. Are you saying that, if a=3Dssrc is used, PT value X could be used for DIFF= ERENT codec configurations? If so, you should answer "no" to Q1 :) Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28 June, 2013 2:25 PM To: mmusic@ietf.org Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for= SAME codec configuration Hi, In Q1, I asked whether we can agree that a PT value can only be used for a = single codec configuration. Eventhough the question is still open, the feed= back received so far seem to indicate that people agree to that. We have also discussed whether it should, within a BUNDLE group, be allowed= to use the same PT value in multiple m- lines - if used for the same codec= configuration. I will now put forward a question on that :) Q7: Within a BUNDLE group, do we allow the usage of the same PT value in mu= ltiple RTP m- lines, for the SAME codec configuration? Note: This of course prevents the mapping to m- line purely based on PT, an= d based on the outcome of that discussion we may have to add restrictions o= n when the same PT value can be used etc. But, this question is whether we = generally want to allow the usage of the same PT value in multiple m- lines= :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BEC06ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

> Q7:

>I am not sure how you defi= ne the same configuration. Do you mean that all the attributes are the same= so the m-lines are identical.

&n= bsp;

Somethi= ng like that – this is the opportunity for you media plane people to = be creative and come up with good wording :)

&n= bsp;

>For example same a=3Dimage= attr or b=3D a=3Dcontent and so on. In this case I do not understand the us= e case for it.

>I see no problem if each o= f the m-line will have an a=3Dssrc to define the RTP stream but if not the = mapping will be problematic.

&n= bsp;

Are you= saying that, if a=3Dssrc is used, PT value X could be used for DIFFERENT c= odec configurations? If so, you should answer “no” to Q1 :)

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28 June, 2013 2:25 PM
To: mmusic@ietf.org
Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- li= nes for SAME codec configuration

 

Hi,

 

In Q1, I asked whether we can a= gree that a PT value can only be used for a single codec configuration. Eve= nthough the question is still open, the feedback received so far seem to in= dicate that people agree to that.

 

We have also discussed whether = it should, within a BUNDLE group, be allowed to use the same PT value in multiple m- lines – if used for the same code= c configuration. I will now put forward a question on that :)

 

 

Q7: Within a BUNDLE group, do we allow the usage of the same PT value i= n multiple RTP m- lines, for the SAME codec configuration?

 

Note: This of course prevents t= he mapping to m- line purely based on PT, and based on the outcome of that = discussion we may have to add restrictions on when the same PT value can be= used etc. But, this question is whether we generally want to allow the usage of the same PT value in multip= le m- lines :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3BEC06ESESSMB209erics_-- From ron.even.tlv@gmail.com Sat Jun 29 03:46:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230A21F9F4F for ; Sat, 29 Jun 2013 03:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytw7jSRVPamr for ; Sat, 29 Jun 2013 03:46:05 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id E6BC121F9F48 for ; Sat, 29 Jun 2013 03:46:04 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so2334475wgh.33 for ; Sat, 29 Jun 2013 03:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=xPAKtV68+unz5N9WPC5MLrpooHFoOCR5weXgU6m8kPc=; b=eEVdWDy3oYUmTfbtgYBTyRgw0Oh908yVwIFCGRXZXEH0Yf/cqH3Hxy2z/zcPym405Y U76n3lgz3i4TI1I+r4vgUsi2VwGSHbLr5DNtcQm1jEY16rfY40Xc1vJlXvmMfF8KkWWB Peabaqvbr0dlW+xKm93rsGn46ci7omFYH9l4P+Y0E49RuD7HnuS1ccLiP1e0Gfm3bx+8 74D1iystNMgFf3wvbV7zRqAOGesLRVomwx35GRxrzmQuXO4GAP9O3IvfedjEwmVT5zGs hSL9W9+6w5a7RUkRkzwdDyF974+KR0lnRufpky8zNj/zvUCAnpardY8uKb9v6eitVaxy L0Eg== X-Received: by 10.180.108.129 with SMTP id hk1mr5851868wib.42.1372502763965; Sat, 29 Jun 2013 03:46:03 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id f8sm3885636wiv.0.2013.06.29.03.46.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 29 Jun 2013 03:46:03 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <042501ce749a$84521300$8cf63900$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3BEC06@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BEC06@ESESSMB209.ericsson.se> Date: Sat, 29 Jun 2013 13:44:36 +0300 Message-ID: <043601ce74b5$a7a4a190$f6ede4b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0437_01CE74CE.CCF2EB00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHh/gpGsmWjhOKpyEWXgP0lggNVQQID3CZhAV49V+CZCl164A== Content-Language: en-us Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 10:46:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0437_01CE74CE.CCF2EB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, I am not sure how to answer this question without knowing what is the multiplexing decision. If we multiplex only based on PT than unique PT numbers are needed and the answer to Q7 is NO If we are using a combination of PT and SSRC for multiplexing we should recommend using unique PT but allow non-unique if can be identified in an m-line or multiple BUNDLED m-line (single RTP session) based on SSRC Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 29 June, 2013 10:45 AM To: Roni Even; mmusic@ietf.org Subject: VS: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Hi, > Q7: >I am not sure how you define the same configuration. Do you mean that all the attributes are the same so the m-lines are identical. Something like that - this is the opportunity for you media plane people to be creative and come up with good wording :) >For example same a=imageattr or b= a=content and so on. In this case I do not understand the use case for it. >I see no problem if each of the m-line will have an a=ssrc to define the RTP stream but if not the mapping will be problematic. Are you saying that, if a=ssrc is used, PT value X could be used for DIFFERENT codec configurations? If so, you should answer "no" to Q1 :) Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28 June, 2013 2:25 PM To: mmusic@ietf.org Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Hi, In Q1, I asked whether we can agree that a PT value can only be used for a single codec configuration. Eventhough the question is still open, the feedback received so far seem to indicate that people agree to that. We have also discussed whether it should, within a BUNDLE group, be allowed to use the same PT value in multiple m- lines - if used for the same codec configuration. I will now put forward a question on that :) Q7: Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration? Note: This of course prevents the mapping to m- line purely based on PT, and based on the outcome of that discussion we may have to add restrictions on when the same PT value can be used etc. But, this question is whether we generally want to allow the usage of the same PT value in multiple m- lines :) Regards, Christer ------=_NextPart_000_0437_01CE74CE.CCF2EB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

I am not sure how to = answer this question without knowing what is the multiplexing = decision.

If we multiplex only based on PT than unique PT = numbers are needed and the answer to Q7 is NO

If we are using a = combination of PT and SSRC for multiplexing we should recommend using = unique PT but allow non-unique if can be identified in an m-line or = multiple BUNDLED m-line (single RTP session) based on = SSRC

Roni

 

From:= = Christer Holmberg [mailto:christer.holmberg@ericsson.com] =
Sent: 29 June, 2013 10:45 AM
To: Roni Even; = mmusic@ietf.org
Subject: VS: [MMUSIC] DECISION: Usage of same = PT value in multiple m- lines for SAME codec = configuration

 

Hi,

 

> = Q7:

>I am not sure how you define the same = configuration. Do you mean that all the attributes are the same so the = m-lines are identical.

 

Something like that = – this is the opportunity for you media plane people to be = creative and come up with good wording :)

 

>For example same = a=3Dimageattr or b=3D a=3Dcontent and so on. In this case I do not = understand the use case for it.

>I see no problem if = each of the m-line will have an a=3Dssrc to define the RTP stream but if = not the mapping will be problematic.

 

Are you saying that, if = a=3Dssrc is used, PT value X could be used for DIFFERENT codec = configurations? If so, you should answer “no” to Q1 = :)

 

Regards,

 

Christer

 

 

From:= = mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28 June, 2013 = 2:25 PM
To: mmusic@ietf.org
Subject: = [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME = codec configuration

 

Hi,

 

In Q1, I = asked whether we can agree that a PT value can only be used for a single = codec configuration. Eventhough the question is still open, the feedback = received so far seem to indicate that people agree to = that.

 

We have also discussed whether it should, within a = BUNDLE group, be allowed to use the same PT value in multiple m- = lines – if used for the same codec configuration. I will now = put forward a question on that :)

 

 

Q7: = Within a BUNDLE group, do we allow the usage of the same PT value in = multiple RTP m- lines, for the SAME codec = configuration?

 

Note: This = of course prevents the mapping to m- line purely based on PT, and based = on the outcome of that discussion we may have to add restrictions on = when the same PT value can be used etc. But, this question is whether we = generally want to allow the usage of the same PT value in = multiple m- lines :)

 

Regards,

 

Christer

------=_NextPart_000_0437_01CE74CE.CCF2EB00-- From ron.even.tlv@gmail.com Sat Jun 29 03:50:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4888321F9F21 for ; Sat, 29 Jun 2013 03:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBEA39j72Kt9 for ; Sat, 29 Jun 2013 03:50:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D050821F9930 for ; Sat, 29 Jun 2013 03:50:20 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so1601837wiv.11 for ; Sat, 29 Jun 2013 03:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=Pa6Yi+GoTY/FLta0S0ZNUURtxuSZgNrRKuDJ3cAeMOM=; b=lCbl/YPPfA1x47DhXvOg0LC/dLq5WjoEuXhfOToJ5eCNh8ym20qHB4xnow99XD18OF Z00NtqOmj1Kc0zWEZEjREuPF/8sIV8MIpqpFCY32oBwDagy4/PMCNFNy+X9qI91uAvtm 0v64o0/oIjRmji6TEJArwYztAIy8bOmoU9KAUJ7XGp8DmBfSqQpajzGMQKP/oFqYxxin VBAEUhlloro307/vs6EoVf+c5RhEpgW/Xq2BsLhkO3xd2jiDWgnkShn79iUS1picW2sO Og8bx6p+wkZ1vOTij1YXE75aBpUsh3dGH6B2OEkO8nWiV5oOhJBv7JCGj/2AgYRqwbBY +4NQ== X-Received: by 10.180.21.147 with SMTP id v19mr5854102wie.25.1372503019593; Sat, 29 Jun 2013 03:50:19 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id fb2sm3232753wic.4.2013.06.29.03.50.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 29 Jun 2013 03:50:19 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> Date: Sat, 29 Jun 2013 13:48:52 +0300 Message-ID: <043b01ce74b6$4059cd20$c10d6760$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_043C_01CE74CF.65A7A160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHh/gpGsmWjhOKpyEWXgP0lggNVQZklb1Bg Content-Language: en-us Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 10:50:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043C_01CE74CF.65A7A160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Jonathan Lennox, Qin and I submitted a draft about mapping the PT from the SDP m-line to the application semantics. It allows for having the same PT numbers in different m-lines since each m-line will have different application IDs that can be used to map to an SSRC using RTCP SDES or RTP header extension. Roni From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28 June, 2013 2:25 PM To: mmusic@ietf.org Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Hi, In Q1, I asked whether we can agree that a PT value can only be used for a single codec configuration. Eventhough the question is still open, the feedback received so far seem to indicate that people agree to that. We have also discussed whether it should, within a BUNDLE group, be allowed to use the same PT value in multiple m- lines - if used for the same codec configuration. I will now put forward a question on that :) Q7: Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration? Note: This of course prevents the mapping to m- line purely based on PT, and based on the outcome of that discussion we may have to add restrictions on when the same PT value can be used etc. But, this question is whether we generally want to allow the usage of the same PT value in multiple m- lines :) Regards, Christer ------=_NextPart_000_043C_01CE74CF.65A7A160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Jonathan Lennox, Qin and = I submitted a draft about mapping the PT from the SDP m-line to the = application semantics.

It allows for having the same PT numbers in = different m-lines since each m-line will have different application IDs = that can be used to map to an SSRC using RTCP SDES or RTP header = extension.

Roni

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: 28 June, 2013 2:25 = PM
To: mmusic@ietf.org
Subject: [MMUSIC] DECISION: = Usage of same PT value in multiple m- lines for SAME codec = configuration

 

Hi,

 

In Q1, I = asked whether we can agree that a PT value can only be used for a single = codec configuration. Eventhough the question is still open, the feedback = received so far seem to indicate that people agree to = that.

 

We have also discussed whether it should, within a = BUNDLE group, be allowed to use the same PT value in multiple m- = lines – if used for the same codec configuration. I will now = put forward a question on that :)

 

 

Q7: = Within a BUNDLE group, do we allow the usage of the same PT value in = multiple RTP m- lines, for the SAME codec = configuration?

 

Note: This = of course prevents the mapping to m- line purely based on PT, and based = on the outcome of that discussion we may have to add restrictions on = when the same PT value can be used etc. But, this question is whether we = generally want to allow the usage of the same PT value in = multiple m- lines :)

 

Regards,

 

Christer

------=_NextPart_000_043C_01CE74CF.65A7A160-- From csp@csperkins.org Sat Jun 29 05:45:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7C111E8100 for ; Sat, 29 Jun 2013 05:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOJx88LQttsj for ; Sat, 29 Jun 2013 05:44:55 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id DD14F11E8102 for ; Sat, 29 Jun 2013 05:44:52 -0700 (PDT) Received: from [81.187.2.149] (port=33757 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UsuWC-0003sn-1D; Sat, 29 Jun 2013 13:44:47 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> Date: Sat, 29 Jun 2013 13:44:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2013 12:45:01 -0000 On 26 Jun 2013, at 13:20, Christer Holmberg wrote: > Hi Colin, >=20 >>> Emil suggested that the default, "MTI", mechanism for mapping RTP = data to m- lines should be based on PT. Applications are=20 >>> allowed to use whatever other mechanisms, but usage of such = mechanisms must be negotiated (or, applications need to have=20 >>> some other means knowing that the other endpoint support such = mechanisms). >>> =20 >>> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP = data to m- lines? >>=20 >> I think the BUNDLE specification needs to define how RTP flows can be = associated with m=3D lines, but ought not mandate that applications=20 >> do so. The document that describes how WebRTC uses BUNDLE might want = to mandate that WebRTC applications use the mechanism.=20 >=20 > Note that there is a separate discussion, BUNDLE DISCUSION: Always = mandate mechanism to map received data to m- line?, on whether BUNDLE = shall mandate that the receiver must always be able to map received data = to an m- line. >=20 > So far only Paul has commented on that discussion, but I assume it's = just a question of hours before your input will be posted? :) >=20 >>> Q4: If Q3, do we mandate applications to support, and use (unless = applications are made aware of other mechanisms supported by all = endpoints) PT for mapping received RTP media? >>=20 >> I think we should specify how the combination of PT values and = a=3Dssrc: lines can be used to associate RTP data with m=3D lines, for = applications that want to do so.=20 >>=20 >> I don't think just using PT values is sufficient, since the PT space = is small (I can imagine applications that want to send lots of flows = using=20 >> the same codec configuration, and it's more natural to give them all = the same PT and use a=3Dssrc: lines to distinguish). >=20 > If you run out of PTs, and have to re-use the same PT in multiple m- = lines (for the same codec configuration, though), you will obviously = need something else for mapping RTP to m- lines, and we should probably = state that. >=20 > But, my take from your reply is that you don't think we should specify = a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC = etc), but it would be up to applications to decide what to use. Correct? No.=20 Specifying a "default" suggests that there might be alternative ways of = doing this. If we specify an algorithm for mapping RTP flows to m=3D = lines, we should specify a single algorithm. We don't need multiple ways = of doing this. I think that single algorithm should look at the PT and = the a=3Dssrc: lines. Just looking at the PT isn't sufficient. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Sat Jun 29 05:50:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BDD11E8105 for ; Sat, 29 Jun 2013 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i18Yy-dKnWZ for ; Sat, 29 Jun 2013 05:50:40 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6911E8103 for ; Sat, 29 Jun 2013 05:50:39 -0700 (PDT) Received: from [81.187.2.149] (port=48782 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Usubu-0004lO-0x; Sat, 29 Jun 2013 13:50:39 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> Date: Sat, 29 Jun 2013 13:50:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2013 12:50:53 -0000 Christer, On 25 Jun 2013, at 12:16, Christer Holmberg wrote: > There has been some discussions about whether BUNDLE should mandate = that users are mandated to always (no matter what transport protocols = are used in the BUNDLE group) have a mechanism to map received data to = an m- line, or whether it from a generic BUNDLE perspective should be = optional =96 IF there would be cases where it=92s not needed. > =20 > We haven=92t had that much discussion about it yet, so I will not ask = a DECISION question at this point, but I would really like to get some = input from people who have opinions about this :) My opinion: BUNDLE needs to mandate a single algorithm for mapping from = RTP flows to m=3D lines, for those applications that care about such a = mapping. I don't think it should mandate that all applications need to = care. --=20 Colin Perkins http://csperkins.org/ From pkyzivat@alum.mit.edu Sat Jun 29 08:45:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1F311E816B for ; Sat, 29 Jun 2013 08:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_24=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28MtlaosLoJO for ; Sat, 29 Jun 2013 08:44:55 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB511E8169 for ; Sat, 29 Jun 2013 08:44:54 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id uEVa1l0011c6gX854FkuFG; Sat, 29 Jun 2013 15:44:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id uFku1l0023ZTu2S3jFkuXb; Sat, 29 Jun 2013 15:44:54 +0000 Message-ID: <51CF00F4.4050605@alum.mit.edu> Date: Sat, 29 Jun 2013 11:44:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372520694; bh=WUbUE0qZewI8BEUVcRMpo8WUS6TIZcat6ghENx6eaac=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DfwpxY6TeUxKyDZWXw7lfV9fXQLgE2vLs/E2kIsBseM0D0UL6b6D67LCcFvj6yRob hP2EB1JB3KdJVeCCQ/ObEZp4gdyxTZDXYg1X63hcMLIlz1PA2a16dAwvRF70B4+jXq ErVAwb0fg2kg7UtXBLKk32fBqJ5gjAU6wldgW2hdNeP0YnHUBLgJ/nGdoR1gIzG44P 8nXUbvw4JMvDPZam43DBoevGD49h8Lb2Nb7m+avW6phVAHulLDub2hEzrqqx3sakyZ VD4ipMHSPo+2v51/Tzmhb42BYuqxYQZ/wpsgNqrN3PnbCSSBPAqlD/cxMeXoCamrqh h1bz61o7cjojQ== Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2013 15:45:01 -0000 On 6/29/13 8:44 AM, Colin Perkins wrote: > On 26 Jun 2013, at 13:20, Christer Holmberg wrote: >> Hi Colin, >> >>>> Emil suggested that the default, "MTI", mechanism for mapping RTP data to m- lines should be based on PT. Applications are >>>> allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have >>>> some other means knowing that the other endpoint support such mechanisms). >>>> >>>> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to m- lines? >>> >>> I think the BUNDLE specification needs to define how RTP flows can be associated with m= lines, but ought not mandate that applications >>> do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism. >> >> Note that there is a separate discussion, BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?, on whether BUNDLE shall mandate that the receiver must always be able to map received data to an m- line. >> >> So far only Paul has commented on that discussion, but I assume it's just a question of hours before your input will be posted? :) >> >>>> Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media? >>> >>> I think we should specify how the combination of PT values and a=ssrc: lines can be used to associate RTP data with m= lines, for applications that want to do so. >>> >>> I don't think just using PT values is sufficient, since the PT space is small (I can imagine applications that want to send lots of flows using >>> the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish). >> >> If you run out of PTs, and have to re-use the same PT in multiple m- lines (for the same codec configuration, though), you will obviously need something else for mapping RTP to m- lines, and we should probably state that. >> >> But, my take from your reply is that you don't think we should specify a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), but it would be up to applications to decide what to use. Correct? > > > No. > > Specifying a "default" suggests that there might be alternative ways of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single algorithm. We don't need multiple ways of doing this. I think that single algorithm should look at the PT and the a=ssrc: lines. Just looking at the PT isn't sufficient. But we *will* have alternative ways of doing this: - one way is by SSRC, specifying which SSRC goes to which m-line - another way could be by appid (from Roni's new draft) The only thing that is special about PT is that *every* RTP media section contains PTs, so it is always available to be used. If I want to use appid, I may very well *not* want to use ssrc as well. I may want the same ssrc to associate with *different* m-lines in the bundle depending on which appid it has. And in that case I may well not want to use PT either. Thanks, Paul From pkyzivat@alum.mit.edu Sat Jun 29 08:58:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA421F9F5B for ; Sat, 29 Jun 2013 08:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwkQ3GWbsEE8 for ; Sat, 29 Jun 2013 08:58:48 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id C236721F9F21 for ; Sat, 29 Jun 2013 08:58:47 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta07.westchester.pa.mail.comcast.net with comcast id uFUF1l0021YDfWL57Fymie; Sat, 29 Jun 2013 15:58:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id uFym1l00v3ZTu2S3gFymJx; Sat, 29 Jun 2013 15:58:46 +0000 Message-ID: <51CF0435.3050305@alum.mit.edu> Date: Sat, 29 Jun 2013 11:58:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372521526; bh=aRmwbSsrSPcjEOVGbHQkPkElXEOuaxc0TTQN9We6de8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iZq4GsTdekMHrrsKF/cCH5bfcaV8QFbr1miNO+4xTe9VCYPoPybQHpdlZCfi/7HtY /vr6bpiwOn78TnY2uALJyrfqIWV3SRg+tRG6TCUQcRZFGTfKiwFL2GytCjtcWFSWAR Ob4xB2ykNWfPv3jM49LvnP1uBT47c2nTiB7NrGynkCLYjmxAPc48UruedduLKM5UnA KgZV1wNOai/j/fK803GwqZKxOjSHR50JCNsVVh4oNm7tsT4NtMfmlkJzqyf1nBt/dS nkzDLCBZ5Nr9jJrwFoWUPWXEyI9UvuIeS/0g+6wfT7XG6Plh5x6rqDDY/+CW2b0s8J qry+wL0+MeM9A== Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 15:58:52 -0000 I looked this over, and it seems to solve many of the issues at hand. There are no doubt some nits to iron out, but we should get agreement over the concepts before worrying too much about the details. A couple of things I wanted to comment on: You give examples of form: a=ssrc:11111 AppID:1 But you don't say too much about the meaning of this. The reason I ask is that you say elsewhere that the appid can move from one ssrc to another. My question is: If this form is used, can that appid later be bound to a different ssrc via the header extension? Also, is the following legal? a=ssrc:11111,22222 AppID:1 My other issue is with: In the CLUE WG case the mapping is from an RTP stream to a CLUE media capture specified in the CLUE framework [I-D.ietf-clue-framework]. This should be to a CLUE capture-encoding. Thanks, Paul On 6/28/13 11:54 AM, Roni Even wrote: > Hi, > We have submitted this document that defines a mechanism to provide the mapping between the > SSRCs of RTP streams and the application semantics by defining extensions to RTP and RTCP messages. > > It defines a new SDP attribute, RTCP SDES message and RTP header extension for this puropose. The document explains how it can be used with the different multiplexing proposal (Plan A, Plan B and no plan). > > It can be used also in CLUE to map SSRCs to Clue media capture. > > Please review and send comments > Thanks > Roni Even > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, June 28, 2013 6:27 PM > To: Jonathan Lennox; Qin Wu; Roni Even > Subject: New Version Notification for draft-even-mmusic-application-token-00.txt > > A new version of I-D, draft-even-mmusic-application-token-00.txt > has been successfully submitted by Roni Even and posted to the > IETF repository. > > Filename: draft-even-mmusic-application-token > Revision: 00 > Title: The Session Description Protocol (SDP) Application Token Attribute > Creation date: 2013-06-28 > Group: Individual Submission > Number of pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-application-token-00.txt > Status: http://datatracker.ietf.org/doc/draft-even-mmusic-application-token > Htmlized: http://tools.ietf.org/html/draft-even-mmusic-application-token-00 > > > Abstract: > The RTP fixed header includes the payload type number and the SSRC > values of the RTP stream. RTP defines how you de-multiplex streams > within an RTP session, but in some use cases applications need > further identifiers in order to identify the application semantics > associated with particular streams within the session. > > This document defines a mechanism to provide the mapping between the > SSRCs of RTP streams and the application semantics by defining > extensions to RTP and RTCP messages. > > > > > The IETF Secretariat > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Sat Jun 29 09:12:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BEE11E817B for ; Sat, 29 Jun 2013 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkhjYxYXnhd2 for ; Sat, 29 Jun 2013 09:12:26 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 7811111E8175 for ; Sat, 29 Jun 2013 09:12:26 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta14.westchester.pa.mail.comcast.net with comcast id uG3l1l0040mv7h05EGCR5u; Sat, 29 Jun 2013 16:12:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id uGCR1l00e3ZTu2S3XGCRHw; Sat, 29 Jun 2013 16:12:25 +0000 Message-ID: <51CF0768.7030504@alum.mit.edu> Date: Sat, 29 Jun 2013 12:12:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> In-Reply-To: <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372522345; bh=/vw9oe4mIrpw8jV1iqJBmG/nUIVRb8qsaDXSU+posV8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eNnp3QHkNf2iND3qBO6MVn/AbckNnqIjceaNcCYhPpyyrtBQCCKwzTfmgTBSxF8N2 FuyCHXHcPYspaGRsIPd/ye0djgx3V+tfaRJjsph27tneUkw4eUDWkGNmimp9ta9ysH 1Xks3UjMTleCXPIV+67BYpM30lB9rQll88wJWVO9iE8a1Kf56ln9QQba8RMCkkLwVT cem+7lG7ld7vLCB//jWhs4a7YVm02NGJ67TXIgMp2dR4njThwcezpSIDCBMJ5S4+Ne WX+swzqRtuaWnWt+EILG0Y1ogi+PNHQS4KaDYjCKuydS5QnAL9GdqnELuRzssLu7YQ kP4VpQms94x5g== Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2013 16:12:32 -0000 On 6/29/13 8:50 AM, Colin Perkins wrote: > Christer, > > On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional – IF there would be cases where it’s not needed. >> >> We haven’t had that much discussion about it yet, so I will not ask a DECISION question at this point, but I would really like to get some input from people who have opinions about this :) > > My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. I just replied elsewhere on this. My opinion turns out to be the exact opposite of yours: we need to support multiple algorithms, and that all applications should care. I won't repeat the stuff about multiple algorithms. I will repeat what I have said about the need for being able to associate: There must have been *some* reason that two m-lines were used, rather than just one. Each m-line heads a media section of the SDP that contains a bunch of declarations. Something must be different in those two media sections, or else a single media section would have been enough. Presumably whatever it is that is different is intended to affect how received packets are processed or interpreted. (If not, again there is no need for it to be there.) If you can't associate the packet with the m-line, then you don't know which of the multiple interpretations to apply to the packet. Maybe there is some exception to this, though I haven't come up with anything. If there is, then I hope someone will call it out. If so, then the constraint can be tightened. Thanks, Paul From ron.even.tlv@gmail.com Sat Jun 29 22:31:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0C121F9E07 for ; Sat, 29 Jun 2013 22:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H09b2fVph7Pv for ; Sat, 29 Jun 2013 22:31:27 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D1F6021F9DE6 for ; Sat, 29 Jun 2013 22:31:26 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a15so1465709eae.40 for ; Sat, 29 Jun 2013 22:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=XANj28ERF2ZhsoYF26G8y8pwbD1cluhVPw51+0j3IXY=; b=QC4tMvp3oOM2TpxS5oiQ0NgST7DQWkK/pywJ6pJ//enu7h0dVHwJMdrAY+42F6esu5 6NA3duMF0T0waoXrxfwu+hQ6twL2oDVZDtb4IAJZ3J2UUC35yjyVEte/6H1IOwHIKfaF 8RY39eelWwJ6cuq20WZmdGAVQYnxHGHfCNglwDmHB+LsTJhegnRQYd5+Bb230der42Lr OJsevIjyIdsPKJFV1Zuso4GE+0AAvUQAnpPaTWL7KtCFxWTdV/bhI/hoceg/fk2tsoM7 UDc5UbvRj1O7ESm0vk+AGLqEyNIUEKq4WmxpPT0J+C3cEQSYe1OBm0OZuLyoaAxz0J87 bRWQ== X-Received: by 10.15.23.194 with SMTP id h42mr15774596eeu.123.1372570285942; Sat, 29 Jun 2013 22:31:25 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id ci50sm21080695eeb.12.2013.06.29.22.31.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 29 Jun 2013 22:31:25 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51CF0435.3050305@alum.mit.edu> In-Reply-To: <51CF0435.3050305@alum.mit.edu> Date: Sun, 30 Jun 2013 08:29:58 +0300 Message-ID: <047901ce7552$de032840$9a0978c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeUlghD62FOWC7Z8hplVA8xNyLagHaS0jkAkLxBlqajRPwIA== Content-Language: en-us Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 05:31:28 -0000 Inline > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 29 June, 2013 6:59 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- > mmusic-application-token-00.txt > > I looked this over, and it seems to solve many of the issues at hand. > There are no doubt some nits to iron out, but we should get agreement over > the concepts before worrying too much about the details. > > A couple of things I wanted to comment on: > > You give examples of form: > a=ssrc:11111 AppID:1 > But you don't say too much about the meaning of this. The reason I ask is > that you say elsewhere that the appid can move from one ssrc to another. > My question is: If this form is used, can that appid later be bound to a > different ssrc via the header extension? Also, is the following legal? > a=ssrc:11111,22222 AppID:1 [Roni Even] The AppID can be mapped later using SDES or header extension to a new SSRC and our view is that this is a replacement. An AppID can be mapped to a single SSRC at a time. We looked at having more than one SSRC mapped to a single AppID and decided to leave it to discussion. It will require to distinguish between adding and SSRC and replacing an SSRC when a new mapping is specified. My view is that the unique mapping is clearer and I assume we can look at using SDP grouping if want to associate two RTP media streams to an application usage. Roni > > My other issue is with: > In the CLUE WG case the mapping is from an RTP stream to a CLUE media > capture specified in the CLUE framework [I-D.ietf-clue-framework]. > This should be to a CLUE capture-encoding. [Roni Even] OK, will fix it > > Thanks, > Paul > > On 6/28/13 11:54 AM, Roni Even wrote: > > Hi, > > We have submitted this document that defines a mechanism to provide > the mapping between the > > SSRCs of RTP streams and the application semantics by defining > extensions to RTP and RTCP messages. > > > > It defines a new SDP attribute, RTCP SDES message and RTP header > extension for this puropose. The document explains how it can be used with > the different multiplexing proposal (Plan A, Plan B and no plan). > > > > It can be used also in CLUE to map SSRCs to Clue media capture. > > > > Please review and send comments > > Thanks > > Roni Even > > > > ________________________________________ > > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > > Sent: Friday, June 28, 2013 6:27 PM > > To: Jonathan Lennox; Qin Wu; Roni Even > > Subject: New Version Notification for draft-even-mmusic-application- > token-00.txt > > > > A new version of I-D, draft-even-mmusic-application-token-00.txt > > has been successfully submitted by Roni Even and posted to the IETF > > repository. > > > > Filename: draft-even-mmusic-application-token > > Revision: 00 > > Title: The Session Description Protocol (SDP) Application Token > Attribute > > Creation date: 2013-06-28 > > Group: Individual Submission > > Number of pages: 11 > > URL: http://www.ietf.org/internet-drafts/draft-even-mmusic- > application-token-00.txt > > Status: http://datatracker.ietf.org/doc/draft-even-mmusic- > application-token > > Htmlized: http://tools.ietf.org/html/draft-even-mmusic-application- > token-00 > > > > > > Abstract: > > The RTP fixed header includes the payload type number and the SSRC > > values of the RTP stream. RTP defines how you de-multiplex streams > > within an RTP session, but in some use cases applications need > > further identifiers in order to identify the application semantics > > associated with particular streams within the session. > > > > This document defines a mechanism to provide the mapping between > the > > SSRCs of RTP streams and the application semantics by defining > > extensions to RTP and RTCP messages. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Sun Jun 30 09:02:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D121F9B12 for ; Sun, 30 Jun 2013 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vreODPZ0aw9 for ; Sun, 30 Jun 2013 09:02:39 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 1823421F9A27 for ; Sun, 30 Jun 2013 09:02:38 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id ufbC1l0061YDfWL5Fg2eVt; Sun, 30 Jun 2013 16:02:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id ug2d1l0103ZTu2S3gg2eMY; Sun, 30 Jun 2013 16:02:38 +0000 Message-ID: <51D0569C.3020508@alum.mit.edu> Date: Sun, 30 Jun 2013 12:02:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51CF0435.3050305@alum.mit.edu> <047901ce7552$de032840$9a0978c0$@gmail.com> In-Reply-To: <047901ce7552$de032840$9a0978c0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372608158; bh=ovvasw1MozG+fJEZufGz/4MWR8jxcHbybOUF2JwPo7o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y3gYkRYRQeeUqqjIAp7PFybrcMhQB/WvLFg+h0Y30IoDYW84qsR/N1FXCH12y9hop 9kNUK4ecTl0Rb47w9VG5W5/uyQaD1uJ1T5pO0ZQrT6NKuforYghpJ2GyrKinZplJ5C sKEDMPJqQKZ3M9H8qQ9QfCIx8rfi5VdW5HCZd58si8X0sYnBRl5Q0ZQQCZTM7N6N59 QYfrV34oaVYD+h53/6g0AYIc9F0m1TzRFdaQX4bZIx9qJjkFooRuG+nv0n4nwK7bkd kTF4eeRyxCGQh3TwUAXmfVLdqhJ7XFuv7xlOswc0FFfz6eSzo6ULpU9suO0Ny6pVyo INljPxmnK8JNw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 16:02:44 -0000 On 6/30/13 1:29 AM, Roni Even wrote: > Inline > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 29 June, 2013 6:59 PM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- >> mmusic-application-token-00.txt >> >> I looked this over, and it seems to solve many of the issues at hand. >> There are no doubt some nits to iron out, but we should get agreement over >> the concepts before worrying too much about the details. >> >> A couple of things I wanted to comment on: >> >> You give examples of form: >> a=ssrc:11111 AppID:1 >> But you don't say too much about the meaning of this. The reason I ask is >> that you say elsewhere that the appid can move from one ssrc to another. >> My question is: If this form is used, can that appid later be bound to a >> different ssrc via the header extension? Also, is the following legal? >> a=ssrc:11111,22222 AppID:1 > [Roni Even] The AppID can be mapped later using SDES or header extension to > a new SSRC and our view is that this is a replacement. An AppID can be > mapped to a single SSRC at a time. OK. That's fine, but then I think the draft should say more about it. Also, a followup question: Suppose I start with an offer with a=ssrc:11111 AppID:1 and then use SDES or header extension to change move AppID 1 to ssrc 22222. If there is then another O/A, with the same SDP as before: a=ssrc:11111 AppID:1 Does that change the mapping back to 11111, or does it stay as 22222? This impacts how closely the SDP signaling must be coupled to the media processing. > We looked at having more than one SSRC mapped to a single AppID and decided > to leave it to discussion. It will require to distinguish between adding and > SSRC and replacing an SSRC when a new mapping is specified. > My view is that the unique mapping is clearer and I assume we can look at > using SDP grouping if want to associate two RTP media streams to an > application usage. I asked about a=ssrc:11111,22222 AppID:1 just because it seemed to be allowed by the syntax. My next question would be what it means. E.g, it *could* mean that it is expected that 11111 and 22222 may both be used, but won't be used simultaneously. If it turned out that they *were* used simultaneously, then the effect would be to switch rapidly between them. Thanks, Paul > Roni > >> >> My other issue is with: >> In the CLUE WG case the mapping is from an RTP stream to a CLUE media >> capture specified in the CLUE framework [I-D.ietf-clue-framework]. >> This should be to a CLUE capture-encoding. > [Roni Even] OK, will fix it >> >> Thanks, >> Paul >> >> On 6/28/13 11:54 AM, Roni Even wrote: >>> Hi, >>> We have submitted this document that defines a mechanism to provide >> the mapping between the >>> SSRCs of RTP streams and the application semantics by defining >> extensions to RTP and RTCP messages. >>> >>> It defines a new SDP attribute, RTCP SDES message and RTP header >> extension for this puropose. The document explains how it can be used with >> the different multiplexing proposal (Plan A, Plan B and no plan). >>> >>> It can be used also in CLUE to map SSRCs to Clue media capture. >>> >>> Please review and send comments >>> Thanks >>> Roni Even >>> >>> ________________________________________ >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >>> Sent: Friday, June 28, 2013 6:27 PM >>> To: Jonathan Lennox; Qin Wu; Roni Even >>> Subject: New Version Notification for draft-even-mmusic-application- >> token-00.txt >>> >>> A new version of I-D, draft-even-mmusic-application-token-00.txt >>> has been successfully submitted by Roni Even and posted to the IETF >>> repository. >>> >>> Filename: draft-even-mmusic-application-token >>> Revision: 00 >>> Title: The Session Description Protocol (SDP) Application > Token >> Attribute >>> Creation date: 2013-06-28 >>> Group: Individual Submission >>> Number of pages: 11 >>> URL: http://www.ietf.org/internet-drafts/draft-even-mmusic- >> application-token-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-even-mmusic- >> application-token >>> Htmlized: > http://tools.ietf.org/html/draft-even-mmusic-application- >> token-00 >>> >>> >>> Abstract: >>> The RTP fixed header includes the payload type number and the SSRC >>> values of the RTP stream. RTP defines how you de-multiplex streams >>> within an RTP session, but in some use cases applications need >>> further identifiers in order to identify the application semantics >>> associated with particular streams within the session. >>> >>> This document defines a mechanism to provide the mapping between >> the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> >>> >>> >>> The IETF Secretariat >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From internet-drafts@ietf.org Sun Jun 30 09:32:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E821F9B9B; Sun, 30 Jun 2013 09:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwzcwfOD1aua; Sun, 30 Jun 2013 09:32:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 730DB21F9B92; Sun, 30 Jun 2013 09:32:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130630163215.12814.46061.idtracker@ietfa.amsl.com> Date: Sun, 30 Jun 2013 09:32:15 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 16:32:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media = Transport in the Session Description Protocol (SDP) Author(s) : Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-04.txt Pages : 12 Date : 2013-06-30 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From salvatore.loreto@ericsson.com Sun Jun 30 09:34:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A621F99F6 for ; Sun, 30 Jun 2013 09:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5UJlc1f6ewP for ; Sun, 30 Jun 2013 09:34:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEEDE21F9273 for ; Sun, 30 Jun 2013 09:34:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-47-51d05e00246c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.EC.06741.00E50D15; Sun, 30 Jun 2013 18:34:08 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.146) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Sun, 30 Jun 2013 18:34:08 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4D28211042A for ; Sun, 30 Jun 2013 19:34:08 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 41B78555E1 for ; Sun, 30 Jun 2013 19:34:05 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C6A96537BC for ; Sun, 30 Jun 2013 19:34:04 +0300 (EEST) Message-ID: <51D05E00.3080203@ericsson.com> Date: Sun, 30 Jun 2013 18:34:08 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <20130630163215.12814.46061.idtracker@ietfa.amsl.com> In-Reply-To: <20130630163215.12814.46061.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvrS5D3IVAg1+nrSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO5LaQUT+Spe9Nxnb2CcwN3FyMkhIWAiMfnSFyYIW0ziwr31 bF2MXBxCAocZJSZtXc0C4WxglFg+/T+Uc5lR4s2ZL6wQzhFGiSW7vjFCOGcZJd5OmcQOMoxX QFvi5eR5zCA2i4CqxLz3S8GWsAmYSTx/uAUsLiqQLPH+yh1miHpBiZMzn7CA2CICohKPLi5i BbGFBZwlvk9oYwSxhQQcJVqW/QObwyngJPHi5zKwXcwCthIX5lxngbDlJba/ncMM8ZCaxNVz m5gherUkes92Mk1gFJmFZN0sJO2zkLQvYGRexciem5iZk15uuIkRGMwHt/zW3cF46pzIIUZp DhYlcd5NemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTA6RtvMPH/o58nFG4KYEyZuevRx elGzmcDDTN/Tl0/z5DlLH/ocu/PJO9/D088dv9p0/O7Pys+5cZ+834f+Kn9z+dyl28bbFNvW LI1hudI361JQSp+7SdWzuUdrqrjbbzsK/H33bctdqYOcYT/ZMg+9nty0c7Ucf9wip7UBC6zP TS1sDEjX6XwyRYmlOCPRUIu5qDgRAJ9zuH00AgAA Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 16:34:15 -0000 Hi there, I have produced a new version to address all the comments received on the mailing list Comments, feedback and questions are very well appreciated and requested cheers Salvatore On 6/30/13 6:32 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) > Author(s) : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-04.txt > Pages : 12 > Date : 2013-06-30 > > Abstract: > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-04 > > > 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 > > -- Salvatore Loreto, PhD www.sloreto.com From christer.holmberg@ericsson.com Sun Jun 30 09:58:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125A221F9B14 for ; Sun, 30 Jun 2013 09:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.145 X-Spam-Level: X-Spam-Status: No, score=-5.145 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilNW7WElknBA for ; Sun, 30 Jun 2013 09:58:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 437C621F9B91 for ; Sun, 30 Jun 2013 09:58:01 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-2c-51d063989b00 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B2.7D.06741.89360D15; Sun, 30 Jun 2013 18:58:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Sun, 30 Jun 2013 18:57:59 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAryLEAAAfraoAAk+azAAA/Mr5Q Date: Sun, 30 Jun 2013 16:57:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BFF53@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre6M5AuBBpsXCFssf3mC0WLq8scs Dkwe0+7fZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfGjW1PGQvmSFTsPfCYrYFxhXAXIyeHhICJ xJ7fq9ghbDGJC/fWs3UxcnEICRxmlNj48xAjhLOIUeLr1E7mLkYODjYBC4nuf9ogDSICqhI7 jv9jBAkzC6hLXF0cBBIWFoiT2HNjOVhYRCBe4tAsI4hqN4mNN6axgYRZgDo3NeWDhHkFfCV+ 3/nCCrHoP6PEnf6PLCAJTgFHiak3/jGB2IxAp30/tQbMZhYQl/hw8DozxMkCEkv2nIeyRSVe Pv7HCmErSTQuecIKUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQtMxC0jILScsC RpZVjOy5iZk56eWGmxiB8XFwy2/dHYynzokcYpTmYFES592kdyZQSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA6PLh0nNBulZZ2UEmhp9tad0+0T+KT9n0HqKK3gt036Z2fcmyc+Q/3pRZ/8G 5fXu8yp+7RV5q/Pkbe3a95c+7306YWX9z6g12vo7mlZ8eXd6z9/prwIdInfobNaSUtBPnbOl 125agvbbxqm1PxeLV38+8WnLGxEb9/7SraVTl55acc1xvcUFv8euSizFGYmGWsxFxYkA7zCA wl0CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2013 16:58:08 -0000 Hi, >>>> Emil suggested that the default, "MTI", mechanism for mapping RTP=20 >>>> data to m- lines should be based on PT. Applications are allowed to=20 >>>> use whatever other mechanisms, but usage of such mechanisms must be ne= gotiated (or, applications need to have some other means knowing that the o= ther endpoint support such mechanisms). >>>> =20 >>>> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP da= ta to m- lines? >>>=20 >>> I think the BUNDLE specification needs to define how RTP flows can be=20 >>> associated with m=3D lines, but ought not mandate that applications do = so. The document that describes how WebRTC uses BUNDLE might want to mandat= e that WebRTC applications use the mechanism. >>=20 >> Note that there is a separate discussion, BUNDLE DISCUSION: Always manda= te mechanism to map received data to m- line?, on whether BUNDLE shall mand= ate that the receiver must always be able to map received data to an m- lin= e. >>=20 >> So far only Paul has commented on that discussion, but I assume it's=20 >> just a question of hours before your input will be posted? :) >>=20 >>>> Q4: If Q3, do we mandate applications to support, and use (unless appl= ications are made aware of other mechanisms supported by all endpoints) PT = for mapping received RTP media? >>>=20 >>> I think we should specify how the combination of PT values and a=3Dssrc= : lines can be used to associate RTP data with m=3D lines, for applications= that want to do so.=20 >>>=20 >>> I don't think just using PT values is sufficient, since the PT space=20 >>> is small (I can imagine applications that want to send lots of flows us= ing the same codec configuration, and it's more natural to give them all th= e same PT and use a=3Dssrc: lines to distinguish). >>=20 >> If you run out of PTs, and have to re-use the same PT in multiple m- lin= es (for the same codec configuration, though), you will obviously need some= thing else for mapping RTP to m- lines, and we should probably state that. >>=20 >> But, my take from your reply is that you don't think we should specify a= default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc),= but it would be up to applications to decide what to use. Correct? > > > No.=20 > > Specifying a "default" suggests that there might be alternative ways of d= oing this. If we specify an algorithm for mapping RTP flows to m=3D lines, = we should specify a single > algorithm. We don't need multiple ways of doing this. I think that single= algorithm should look at the PT and the a=3Dssrc: lines. Just looking at t= he PT isn't sufficient. But, what if there is no a=3Dssrc? Are you suggesting we shall mandate usag= e of a=3Dssrc in case of multiple RTP m- lines in a BUNDLE group? As Paul says in his reply, there may be different mechanisms which can be u= sed (and in future there might be even more). You seem to suggest that BUND= LE shall say "Mechanism X is the only mechanism for mapping RTP media to m-= lines". Or? Regards, Christer From christer.holmberg@ericsson.com Sun Jun 30 10:01:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632EF21F9B91 for ; Sun, 30 Jun 2013 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1AzXlksnLdW for ; Sun, 30 Jun 2013 10:01:31 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4462F21F9B14 for ; Sun, 30 Jun 2013 10:01:30 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-82-51d0646798d2 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.BE.11907.76460D15; Sun, 30 Jun 2013 19:01:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Sun, 30 Jun 2013 19:01:27 +0200 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration Thread-Index: Ac5z8ekD0a7SetWORja/n46Ib+raCQAs5HYAAENw1mA= Date: Sun, 30 Jun 2013 17:01:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BFF68@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BE558@ESESSMB209.ericsson.se> <043b01ce74b6$4059cd20$c10d6760$@gmail.com> In-Reply-To: <043b01ce74b6$4059cd20$c10d6760$@gmail.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BFF68ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvrW5GyoVAg2lb+CymLn/MYvG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyjj55jJzwRyPip+P9jA1MHbadzFyckgImEj8 7H/ECGGLSVy4t54NxBYSOMoo0XelsouRC8hexCgx79kS9i5GDg42AQuJ7n/aIDUiAt4Si3tW MIOEhQWyJKY8CIIIZ0tsXLaECcK2ktj6fy4ziM0ioCqx598LsFW8Ar4Sc5+tYIdYVS1x7m47 mM0JNP3ZrSYWEJsR6Jzvp9aAzWEWEJf4cPA6M8SZAhJL9pyHskUlXj7+xwphK0k0LnnCClGf L/H25AU2iF2CEidnPmGZwCgyC8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM 7KsYOYpTi5Ny040MNjEC4+bglt8WOxgv/7U5xCjNwaIkzrtF70ygkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsbMu0yHCr6aL2FKyzoudZHr6y2tA3v27euu5la99q9o+QGjcO+5F7vqJnU/ WZ/EaTPT7sHjORopl99kWxhIO8l9e3Q63z9is11KTZMjc5aTSXFghf22G07R9b2FFt8MBBsV Mu9nfdCY+vvzrrON0lwdR28L1si8Xj5xz8+LvLMXN2T7pTZ3WCqxFGckGmoxFxUnAgBJQnIG aQIAAA== Subject: Re: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for SAME codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 17:01:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3BFF68ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, > Jonathan Lennox, Qin and I submitted a draft about mapping the PT from th= e SDP m-line to the application semantics. > It allows for having the same PT numbers in different m-lines since each = m-line will have different application IDs that can be used to map to an SS= RC using RTCP SDES or RTP header extension. And, the same PT numbers could, in different m- lines, even be used for dif= ferent codecs/codec configurations? Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28 June, 2013 2:25 PM To: mmusic@ietf.org Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- lines for= SAME codec configuration Hi, In Q1, I asked whether we can agree that a PT value can only be used for a = single codec configuration. Eventhough the question is still open, the feed= back received so far seem to indicate that people agree to that. We have also discussed whether it should, within a BUNDLE group, be allowed= to use the same PT value in multiple m- lines - if used for the same codec= configuration. I will now put forward a question on that :) Q7: Within a BUNDLE group, do we allow the usage of the same PT value in mu= ltiple RTP m- lines, for the SAME codec configuration? Note: This of course prevents the mapping to m- line purely based on PT, an= d based on the outcome of that discussion we may have to add restrictions o= n when the same PT value can be used etc. But, this question is whether we = generally want to allow the usage of the same PT value in multiple m- lines= :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3BFF68ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

&n= bsp;

> Jonathan Lennox, Qin and = I submitted a draft about mapping the PT from the SDP m-line to the applica= tion semantics.

> It allows for having the = same PT numbers in different m-lines since each m-line will have different = application IDs that can be used to map to an SSRC using RTCP SDES or RTP header extension.

&n= bsp;

And, th= e same PT numbers could, in different m- lines, even be used for different = codecs/codec configurations?

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28 June, 2013 2:25 PM
To: mmusic@ietf.org
Subject: [MMUSIC] DECISION: Usage of same PT value in multiple m- li= nes for SAME codec configuration

 

Hi,

 

In Q1, I asked whether we can a= gree that a PT value can only be used for a single codec configuration. Eve= nthough the question is still open, the feedback received so far seem to in= dicate that people agree to that.

 

We have also discussed whether = it should, within a BUNDLE group, be allowed to use the same PT value in multiple m- lines – if used for the same code= c configuration. I will now put forward a question on that :)

 

 

Q7: Within a BUNDLE group, do we allow the usage of the same PT value i= n multiple RTP m- lines, for the SAME codec configuration?

 

Note: This of course prevents t= he mapping to m- line purely based on PT, and based on the outcome of that = discussion we may have to add restrictions on when the same PT value can be= used etc. But, this question is whether we generally want to allow the usage of the same PT value in multip= le m- lines :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3BFF68ESESSMB209erics_-- From csp@csperkins.org Sun Jun 30 10:05:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2721F9BAA for ; Sun, 30 Jun 2013 10:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ibwVeOHJPZT for ; Sun, 30 Jun 2013 10:04:57 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9608521F9AFE for ; Sun, 30 Jun 2013 10:04:57 -0700 (PDT) Received: from [81.187.2.149] (port=38421 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UtL3X-0008HB-SF; Sun, 30 Jun 2013 18:04:56 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BFF53@ESESSMB209.ericsson.se> Date: Sun, 30 Jun 2013 18:04:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BFF53@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2013 17:05:03 -0000 On 30 Jun 2013, at 17:57, Christer Holmberg wrote: > Hi, >=20 >>>>> Emil suggested that the default, "MTI", mechanism for mapping RTP=20= >>>>> data to m- lines should be based on PT. Applications are allowed = to=20 >>>>> use whatever other mechanisms, but usage of such mechanisms must = be negotiated (or, applications need to have some other means knowing = that the other endpoint support such mechanisms). >>>>>=20 >>>>> Q3: Do we need to specify a default, MTI, mechanism for mapping = RTP data to m- lines? >>>>=20 >>>> I think the BUNDLE specification needs to define how RTP flows can = be=20 >>>> associated with m=3D lines, but ought not mandate that applications = do so. The document that describes how WebRTC uses BUNDLE might want to = mandate that WebRTC applications use the mechanism. >>>=20 >>> Note that there is a separate discussion, BUNDLE DISCUSION: Always = mandate mechanism to map received data to m- line?, on whether BUNDLE = shall mandate that the receiver must always be able to map received data = to an m- line. >>>=20 >>> So far only Paul has commented on that discussion, but I assume it's=20= >>> just a question of hours before your input will be posted? :) >>>=20 >>>>> Q4: If Q3, do we mandate applications to support, and use (unless = applications are made aware of other mechanisms supported by all = endpoints) PT for mapping received RTP media? >>>>=20 >>>> I think we should specify how the combination of PT values and = a=3Dssrc: lines can be used to associate RTP data with m=3D lines, for = applications that want to do so.=20 >>>>=20 >>>> I don't think just using PT values is sufficient, since the PT = space=20 >>>> is small (I can imagine applications that want to send lots of = flows using the same codec configuration, and it's more natural to give = them all the same PT and use a=3Dssrc: lines to distinguish). >>>=20 >>> If you run out of PTs, and have to re-use the same PT in multiple m- = lines (for the same codec configuration, though), you will obviously = need something else for mapping RTP to m- lines, and we should probably = state that. >>>=20 >>> But, my take from your reply is that you don't think we should = specify a default mechanism. We CAN describe different mechanisms (PT, = PT+SSRC etc), but it would be up to applications to decide what to use. = Correct? >>=20 >>=20 >> No.=20 >>=20 >> Specifying a "default" suggests that there might be alternative ways = of doing this. If we specify an algorithm for mapping RTP flows to m=3D = lines, we should specify a single >> algorithm. We don't need multiple ways of doing this. I think that = single algorithm should look at the PT and the a=3Dssrc: lines. Just = looking at the PT isn't sufficient. >=20 > But, what if there is no a=3Dssrc? Are you suggesting we shall mandate = usage of a=3Dssrc in case of multiple RTP m- lines in a BUNDLE group? No, I'm saying that we should define a single algorithm for mapping the = RTP flows to m=3D lines. That algorithm should take into account a=3Dssrc:= lines, if present, as well as payload type mapping. > As Paul says in his reply, there may be different mechanisms which can = be used (and in future there might be even more). You seem to suggest = that BUNDLE shall say "Mechanism X is the only mechanism for mapping RTP = media to m- lines". Or? I'm suggesting we specify something tractable: one algorithm, if at all = possible. I'm unconvinced that too much flexibility is a good thing = here. --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Sun Jun 30 10:10:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17D21F9B85 for ; Sun, 30 Jun 2013 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.027 X-Spam-Level: X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4FzkRXQJzaB for ; Sun, 30 Jun 2013 10:10:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6F2021F9B15 for ; Sun, 30 Jun 2013 10:10:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-4e-51d06678965a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DB.CD.06741.87660D15; Sun, 30 Jun 2013 19:10:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 30 Jun 2013 19:10:16 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? Thread-Index: Ac5xlz4qXnbgXU0zSAKuYyddRY0NgwAryLEAAAfraoAAk+azAAA/Mr5Q///hcQD//93/UA== Date: Sun, 30 Jun 2013 17:10:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3C0021@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BFF53@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW5F2oVAg+Oz1SyWvzzBaDF1+WMW ByaPaffvs3ksWfKTKYApissmJTUnsyy1SN8ugSvjx6Y+loLJUhWzTr5hbmBsFO1i5OSQEDCR uPBjCTuELSZx4d56NhBbSOAwo8SvztguRi4gexGjxN+m76xdjBwcbAIWEt3/tEFqRARUJXYc /8cIEmYWUJe4ujgIJCwsECex58ZysLCIQLzEoVlGENVhEp+mXGICsVmAOl+ufcYKYvMK+Eo0 7nrADrHpF5PEvo4pYAlOAUeJRY9/M4LYjECnfT+1BqyZWUBc4sPB68wQJwtILNlzHsoWlXj5 +B8rhK0k0bjkCStEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxsucmZuaklxtuYgTGx8Etv3V3MJ46J3KIUZqDRUmcd5PemUAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjIFz0k909j7gOrjuZw3T5sqexQf6Z/F3fTFKMOvXYitMSD0361+Ud8IuHUEB Y/sFHfm5p76qXD6qx89g/rzqyb5TNixny4okmAJ2P2EvdjJ4tbvJJvJT9+yvx+omzeXPUnuV +1zc8sa/c5vS7m6MnHIu0aUux+nxN79VJzTKrV96/s0yUX7MpcRSnJFoqMVcVJwIAI8X+ohd AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2013 17:10:24 -0000 Hi, >>>>>> Emil suggested that the default, "MTI", mechanism for mapping RTP=20 >>>>>> data to m- lines should be based on PT. Applications are allowed=20 >>>>>> to use whatever other mechanisms, but usage of such mechanisms must = be negotiated (or, applications need to have some other means knowing that = the other endpoint support such mechanisms). >>>>>>=20 >>>>>> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP = data to m- lines? >>>>>=20 >>>>> I think the BUNDLE specification needs to define how RTP flows can=20 >>>>> be associated with m=3D lines, but ought not mandate that application= s do so. The document that describes how WebRTC uses BUNDLE might want to m= andate that WebRTC applications use the mechanism. >>>>=20 >>>> Note that there is a separate discussion, BUNDLE DISCUSION: Always man= date mechanism to map received data to m- line?, on whether BUNDLE shall ma= ndate that the receiver must always be able to map received data to an m- l= ine. >>>>=20 >>>> So far only Paul has commented on that discussion, but I assume it's=20 >>>> just a question of hours before your input will be posted? :) >>>>=20 >>>>>> Q4: If Q3, do we mandate applications to support, and use (unless ap= plications are made aware of other mechanisms supported by all endpoints) P= T for mapping received RTP media? >>>>>=20 >>>>> I think we should specify how the combination of PT values and a=3Dss= rc: lines can be used to associate RTP data with m=3D lines, for applicatio= ns that want to do so.=20 >>>>>=20 >>>>> I don't think just using PT values is sufficient, since the PT=20 >>>>> space is small (I can imagine applications that want to send lots of = flows using the same codec configuration, and it's more natural to give the= m all the same PT and use a=3Dssrc: lines to distinguish). >>>>=20 >>>> If you run out of PTs, and have to re-use the same PT in multiple m- l= ines (for the same codec configuration, though), you will obviously need so= mething else for mapping RTP to m- lines, and we should probably state that= . >>>>=20 >>>> But, my take from your reply is that you don't think we should specify= a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc= ), but it would be up to applications to decide what to use. Correct? >>>=20 >>>=20 >>> No.=20 >>>=20 >>> Specifying a "default" suggests that there might be alternative ways=20 >>> of doing this. If we specify an algorithm for mapping RTP flows to m=3D= lines, we should specify a single algorithm. We don't need multiple ways o= f doing this. I think that single algorithm should look at the PT and the a= =3Dssrc: lines. Just looking at the PT isn't sufficient. >>=20 >> But, what if there is no a=3Dssrc? Are you suggesting we shall mandate u= sage of a=3Dssrc in case of multiple RTP m- lines in a BUNDLE group? > > No, I'm saying that we should define a single algorithm for mapping the R= TP flows to m=3D lines. That algorithm should take into account a=3Dssrc: l= ines, if present, as well as payload type mapping. Ok, so you want to have explicit text about usage of a=3Dssrc, if present. = But, I still don't think we should forbid usage of other mechanisms, eventh= ough we won't describe them in the BUNDLE spec. Regards, Christer From nigel.pattinson@kaseya.com Sun Jun 30 14:26:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9A221F9C93 for ; Sun, 30 Jun 2013 14:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amTkGBvku9+W for ; Sun, 30 Jun 2013 14:26:20 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id B10EF21F9C8F for ; Sun, 30 Jun 2013 14:26:20 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UtP8W-0004Qa-4g for mmusic@ietf.org; Sun, 30 Jun 2013 14:26:20 -0700 Date: Sun, 30 Jun 2013 14:26:20 -0700 (PDT) From: Nigel Pattinson To: mmusic@ietf.org Message-ID: <1372627580120-374584.post@n7.nabble.com> In-Reply-To: <51CBCA56.8040709@nostrum.com> References: <1372174473646-373839.post@n7.nabble.com> <1372304462652-374094.post@n7.nabble.com> <51CBCA56.8040709@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2013 21:26:25 -0000 Adam Roach-3 wrote > How many techniques from sections 5.3 and 5.4 did you implement? Did > your implementation make use of the following advice? > > If the local network or host > does not support IPv6 addressing, clients SHOULD make use of > other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or > SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates. > > > My experience is that Teredo-to-Teredo tunneling has success rates well > above 50% (at least for RFC6081 implementations) -- although this is > admittedly from my own personal use of Teredo, and is far from a > scientific survey. To be clear my comments about success rates are largely speculation at the moment. We do set up host candidates for Teredo where available. My understanding of Teredo is limited, I was thinking that when a Teredo-to-Teredo connection was established the traffic would still be relayed, just via a Teredo relay rather than a TURN relay. Nigel -- View this message in context: http://ietf.10.n7.nabble.com/Comments-on-ICE-TCP-specification-RFC-6544-tp191890p374584.html Sent from the IETF - mmusic mailing list archive at Nabble.com. From adam@nostrum.com Sun Jun 30 16:51:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CBA21F9D5C for ; Sun, 30 Jun 2013 16:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5Add7v1-Lba for ; Sun, 30 Jun 2013 16:51:46 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E169921F9D29 for ; Sun, 30 Jun 2013 16:51:45 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5UNpijf047063 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 18:51:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51D0C48B.9020900@nostrum.com> Date: Sun, 30 Jun 2013 18:51:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nigel Pattinson References: <1372174473646-373839.post@n7.nabble.com> <1372304462652-374094.post@n7.nabble.com> <51CBCA56.8040709@nostrum.com> <1372627580120-374584.post@n7.nabble.com> In-Reply-To: <1372627580120-374584.post@n7.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2013 23:51:46 -0000 On 6/30/13 16:26, Nigel Pattinson wrote: > Adam Roach-3 wrote >> How many techniques from sections 5.3 and 5.4 did you implement? Did >> your implementation make use of the following advice? >> >> If the local network or host >> does not support IPv6 addressing, clients SHOULD make use of >> other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or >> SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates. >> >> >> My experience is that Teredo-to-Teredo tunneling has success rates well >> above 50% (at least for RFC6081 implementations) -- although this is >> admittedly from my own personal use of Teredo, and is far from a >> scientific survey. > To be clear my comments about success rates are largely speculation at the > moment. We do set up host candidates for Teredo where available. My > understanding of Teredo is limited, I was thinking that when a > Teredo-to-Teredo connection was established the traffic would still be > relayed, just via a Teredo relay rather than a TURN relay. > I'm pretty sure that Teredo-to-Teredo traffic only has to go through a relay if both sides of the connection are behind symmetric NATs. It's been a while since I played around with it, though, so I might be misremembering. /a From mzanaty@cisco.com Sun Jun 30 20:33:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A6221F9EF9 for ; Sun, 30 Jun 2013 20:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgpuXvH6FtPx for ; Sun, 30 Jun 2013 20:33:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9497321F9EE3 for ; Sun, 30 Jun 2013 20:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3359; q=dns/txt; s=iport; t=1372649580; x=1373859180; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uhwz3mJjn56VLlBhW+OiZpbkTvHErSfdyVp7ukU4yXo=; b=i5IA4fOETaE5/umSznXKBPVe9IfECemV40eIgXSfNUn8E9lRfq0bDQs5 9wAcAc5Ed0GAytTtCaSXnGnDSjq/Ng64l2cfHUCbMogJaWjJYKL4DzTpt oEKSdkewsRDBlTlSyUCEmMDwnxRFK7rz3u0Au4luzfN36DwUKWV6AVV8v g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAKD20FGtJXG+/2dsb2JhbABaDoJ7Mkm/F4EDFnSCIwEBAQQBAQE3NBcEAgEIDgMEAQEBChQJBycLFAkIAgQBEgiIBwy6cgSPLTgGgn5jA6kNgVh7PoIo X-IronPort-AV: E=Sophos;i="4.87,971,1363132800"; d="scan'208";a="226280574" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 01 Jul 2013 03:33:00 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r613Wx6G030484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 03:32:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sun, 30 Jun 2013 22:32:59 -0500 From: "Mo Zanaty (mzanaty)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: AQHOdON5iUTc8DI+/Em0svjaZWQNnJlPEy+A Date: Mon, 1 Jul 2013 03:32:58 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> In-Reply-To: <51CF0768.7030504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.211.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2013 03:33:05 -0000 Informative descriptions of possible mappings are fine, but nothing normati= ve, please. Some applications won't care about the mapping, and others may = care but use a different mapping from those described. The only normative s= tatement you could make is something like: "If you care about the mapping, = you MUST have a mapping mechanism. You MAY use the mechanism(s) described h= ere, or some other mechanism." But why mandate such a tautology? The assumption below that multiple m-lines always require different m-line-= specific processing of the packets also assumes Plan B, i.e. that multiple = streams with similar processing should always be signaled with a single m-l= ine (for example, using a=3Dssrc or max-ssrc). Plan A purists would use mul= tiple m-lines even for multiple streams with the same processing. I don't t= hink we want to force bundle to pick a plan. Mo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Saturday, June 29, 2013 12:12 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? On 6/29/13 8:50 AM, Colin Perkins wrote: > Christer, > > On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >> There has been some discussions about whether BUNDLE should mandate that= users are mandated to always (no matter what transport protocols are used = in the BUNDLE group) have a mechanism to map received data to an m- line, o= r whether it from a generic BUNDLE perspective should be optional - IF ther= e would be cases where it's not needed. >> >> We haven't had that much discussion about it yet, so I will not ask a DE= CISION question at this point, but I would really like to get some input fr= om people who have opinions about this :) > > My opinion: BUNDLE needs to mandate a single algorithm for mapping from R= TP flows to m=3D lines, for those applications that care about such a mappi= ng. I don't think it should mandate that all applications need to care. I just replied elsewhere on this. My opinion turns out to be the exact opposite of yours: we need to=20 support multiple algorithms, and that all applications should care. I won't repeat the stuff about multiple algorithms. I will repeat what I have said about the need for being able to associate: There must have been *some* reason that two m-lines were used, rather=20 than just one. Each m-line heads a media section of the SDP that=20 contains a bunch of declarations. Something must be different in those=20 two media sections, or else a single media section would have been=20 enough. Presumably whatever it is that is different is intended to=20 affect how received packets are processed or interpreted. (If not, again=20 there is no need for it to be there.) If you can't associate the packet=20 with the m-line, then you don't know which of the multiple=20 interpretations to apply to the packet. Maybe there is some exception to this, though I haven't come up with=20 anything. If there is, then I hope someone will call it out. If so, then=20 the constraint can be tightened. Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic