From nobody Tue Jul 1 07:57:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D271B280E for ; Tue, 1 Jul 2014 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.87 X-Spam-Level: * X-Spam-Status: No, score=1.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JtXMGyBEq_j for ; Tue, 1 Jul 2014 07:57:46 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876A11B280D for ; Tue, 1 Jul 2014 07:57:46 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/1/2014 10:57:41 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-275/SG:5 7/1/2014 10:56:58 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.866498 p=-0.979487 Source White X-Signature-Violations: 0-0-0-26689-c X-Note-419: 31.2006 ms. Fail:0 Chk:1337 of 1337 total X-Note: SCH-CT/SI:0-1337/SG:1 7/1/2014 10:57:23 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 109595081; Tue, 01 Jul 2014 10:57:41 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Tue, 1 Jul 2014 09:57:40 -0500 From: Jonathan Lennox To: Suhas Nandakumar Thread-Topic: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis Thread-Index: AQHPjpRcTSsSmgi9qkCGBpSoE1Vx4JuLsEWA Date: Tue, 1 Jul 2014 14:57:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_BD9416036CB14855924DB5D134555778vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4uNAFJ7Pw7FXsxBue4ztpexqKn8 Cc: mmusic Subject: Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:57:48 -0000 --_000_BD9416036CB14855924DB5D134555778vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 22, 2014, at 11:36 PM, Suhas Nandakumar > wrote: Hello All Continuing the discussions from London on analyzing multiplexing behavio= r for SDP attributes that are defined per Payload Type, I was thinking on = making following changes to the draft-ietf-mmusic-sdp-mux-attributes-01. 1. Add new category called IDENTICAL-PER-PT to the SDP Attribute analysis f= ramework in Section 4 which is defined as IDENTICAL-PER-PT: Attributes that define the RTP payload configuration on p= er Payload Type basis and MUST have identical values across all the media d= escriptions for a given RTP Payload Type when repeated. As a framework, this makes sense to me. 2. Similarly add another category IDENTICAL-PER-SSRC to accommodate source = level SDP attributes. IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP Packet= Streams in a given RTP Session and MUST have identical values when repeate= d across multiple media description for a given SSRC. 3. For all the attributes that directly/indirectly impact codec configurati= on and packetization of the media, I have attempted to assign a SDP MUX cat= egory and provide some insights on how such a decision was made (wherever a= pplicable) Attribute: a=3Dptime, a=3Dmaxptime Mux Category: IDENTICAL-PER-PT Notes: For a given codec the audio packetization time must be same if the P= T is repeated. This will ensure that the RTP receiver can unambiguously dec= ode the incoming audio packets. This is a bit complicated by the fact that a=3Dptime and a=3Dmaxptime attri= butes don=92t actually specify PTs. Does this mean that if two m-lines sha= re *any* PTs, then their a=3Dptime and a=3Dmaxptime values must match? That=92s fine, but it=92s a somewhat different semantic than for attributes= that explicitly list their PT values. I wonder if we need to have a separate IDENTICAL-IF-SHARED-PT mix category? Attribute: a=3Dframerate Mux Category: IDENTICAL-PER-PT Similar, IDENTICAL-IF-SHARED-PT, I think. Attribute: a=3Drtpmap Mux Category: IDENTICAL-PER-PT Yes. Attribute: a=3Dfmtp Mux Category: IDENTICAL-PER-PT Notes: Yes. Attribute: a=3Drtcp-fb Mux Category: NORMAL Notes: Since the feedback messages are reported per SSRC, the category of N= ORMAL suffices. Yes. In this, I disagree with Bo. I think it may be reasonable to have two stre= ams, one of which supports NACK (say), and another one which does not. Attribute: a=3Ddepend (RFC5583) Mux Category: IDENTICAL-PER-PT Notes: Since each dependency identifies a unique RTP packetization and thus MUST = be identified via unique Payload Type. Similarly if the Payload Type is repeated across media descriptions, they M= UST represent the Identical codec configuration. Yes. Attribute: a=3Dssrc:xyz fmtp: ... Mux Category: IDENTICAL-PER-PT Notes: RFC5576 says this : " Within a media stream, "ssrc" attributes with the same value of describe different attributes of the same media sources. Across media streams, values are not correlated (unless correlation is indicated by media-stream grouping or some other mechanism) and MAY be repeated. " Thus if the RTP Payload Type used to specify fmtp parameters is repeated, = it MUST represent the same codec configuration. example: m=3Dvideo ... a=3Drtpmap:98 VP8/90000 a=3Dssrc:12345 fmtp:98max-fr=3D15; max-fs-1200 m=3Dvideo ... a=3Drtpmap:98 VP8/90000 a=3Dssrc:56789 fmtp:98 max-fr=3D15; max-fs-1200 No, that=92s not what that section of RFC 5576 meant. Since this was pre-B= UNDLE, media streams were the same as RTP sessions, so this was just saying= that SSRCs in different RTP sessions aren=92t related. The purpose of fmtp as a source attribute was specifically to make it possi= ble to send different attributes of streams even if they have the same PT = =97 the specific motivation was H.264 sprop-* parameters. So it would make= me somewhat sad (as the inventor of fmtp as a source attribute) to make th= is IDENTICAL-PER-PT =97 I=92d rather have it IDENTICAL-PER-SSRC-AND-PT (whi= ch probably actually means SPECIAL). That said, no work to actually define fmtp source attributes for any media = formats has actually gone anywhere =97 I published draft-lennox-avt-h264-so= urce-fmtp-00 seven years ago, but it didn=92t get any traction. So maybe n= o one cares, and this should just be deprecated. Attribute: a=3Dssrc:xyz cname: .... Mux Category: IDENTICAL-PER-SSRC Notes: RFC5576 defines the identical requirement as it is. Yes. Attribute: a=3Dimageattr Mux Category: IDENTICAL-PER-PT Yes. Attribute: a=3Dframesize Mux Category: IDENTICAL-PER-PT Yes. Attributes: a=3Dfec-source-flow, a=3Dfec-repair-flow, a=3Drepair-window Mux Category: NORMAL Don=92t know these well enough. --_000_BD9416036CB14855924DB5D134555778vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 22, 2014, at 11:36 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:

Hello All

   Continuing the discuss= ions from London on analyzing multiplexing behavior for SDP attributes that= are defined per  Payload Type, I was thinking on making following cha= nges to the draft-ietf-mmusic-sdp-mux-attributes-01. 

1. Add new category called IDENTICA= L-PER-PT to the SDP Attribute analysis framework in Section 4 which is defi= ned as

IDENTICAL-PER-PT: Attributes that d= efine the RTP payload configuration on per Payload Type basis and MUST have= identical values across all the media descriptions for a given RTP Payload Type when repeated.

As a framework, this makes sense to me.

2. Similarly add anothe= r category IDENTICAL-PER-SSRC to accommodate source level SDP attributes.

IDENTICAL-PER-SSRC: Attributes that= correspond to the individual RTP Packet Streams in a given RTP Session and= MUST have identical values when repeated across multiple media description= for a given SSRC.

3. For all the attributes that dire= ctly/indirectly impact codec configuration and packetization of the media, = I have attempted to assign a SDP MUX category and provide some insights on = how such a decision was made (wherever applicable)

Attribute: a=3Dptime, a=3Dmaxpti= me
Mux Category: IDENTICAL-PER-PT
Notes: For a given codec the audio = packetization time must be same if the PT is repeated. This will ensure tha= t the RTP receiver can unambiguously decode the incoming audio pa= ckets.

This is a bit complicated by the fact that a=3Dptime and a=3Dmaxptime = attributes don=92t actually specify PTs.  Does this mean that if two m= -lines share *any* PTs, then their a=3Dptime and a=3Dmaxptime values must m= atch?

That=92s fine, but it=92s a somewhat different semantic than for attri= butes that explicitly list their PT values.

I wonder if we need to have a separate IDENTICAL-IF-SHARED-PT mix cate= gory?

Attribute: a=3Dframerat= e
Mux Cat= egory: IDENTICAL-PER-PT

Similar, IDENTICAL-IF-SHARED-PT, I think.

Attribute: a=3Drtpmap
Mux Cat= egory: IDENTICAL-PER-PT

Yes.


Attribute: a=3Dfmtp
Mux Cat= egory: IDENTICAL-PER-PT
Notes: 

Yes.

Attribute: a=3Drtcp-fb
Mux Category: NORMAL
Notes: Since the feedback messages are reported per SSRC, t= he category of NORMAL suffices.

Yes.

In this, I disagree with Bo.  I think it may be reasonable to hav= e two streams, one of which supports NACK (say), and another one which does= not.

Attribute: a=3Ddepend (RFC5583)
Mux Category: IDENTICAL-PER-PT
Notes:
Since each dependency identifies a unique RTP packetization  and = thus MUST be identified via unique Payload Type. 
Similarly if the Payload Type is repeated across media descriptions, t= hey MUST represent the Identical codec configuration. 

Yes.


Attribute: a=3Dssrc:xyz  fmtp:<fmt> ... 
Mux Category: IDENTICAL-PER-PT
Notes:
RFC5576 says this :
"  
Within a media stream, "ssrc"= ; attributes with the same value of
 
<ssrc-id> describe different a=
ttributes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other

mechanism) and MAY be repeated.


"


Thus if the RTP Payload Type used to=
 specify fmtp parameters  is repeated, it MUST represent the same codec configurat=
ion.


example:


m=3Dvideo =
...


a=3Drtpmap=
:98 VP8/90000


a=3Dssrc:1=
2345 fmtp:98max-fr=3D15; max-fs-1200





m=3Dvideo ..=
.
a=
=3Drtpmap:98 VP8/90000


a=3Dssrc:56789 f=
mtp:98 max-fr=3D15; max-fs-1200

No, that=92s not what that section of RFC 5576 meant.  Since this= was pre-BUNDLE, media streams were the same as RTP sessions, so this was j= ust saying that SSRCs in different RTP sessions aren=92t related.

The purpose of fmtp as a source attribute was specifically to make it = possible to send different attributes of streams even if they have the same= PT =97 the specific motivation was H.264 sprop-* parameters.  So it w= ould make me somewhat sad (as the inventor of fmtp as a source attribute) to make this IDENTICAL-PER-PT =97 I=92d rat= her have it IDENTICAL-PER-SSRC-AND-PT (which probably actually means SPECIA= L).

That said, no work to actually define fmtp source attributes for any m= edia formats has actually gone anywhere =97 I published draft-lennox-a= vt-h264-source-fmtp-00 seven years ago, but it didn=92t get any traction. &= nbsp;So maybe no one cares, and this should just be deprecated.


Attribute: a=3Dssrc:xyz  cname: ....
Mux Category: IDENTICAL-PER-SSRC
Notes: RFC5576 defines the identical requirement as it is.

Yes.

Attribute: a=3Dimageattr
Mux Category: IDENTICAL-PER-PT

Yes.

Attribute: a=3Dframesize
Mux Category: IDENTICAL-PER-PT

Yes.

Attributes: a=3Dfec-source-flow, a= =3Dfec-repair-flow, a=3Drepair-windo= w
Mux Category: NORMAL

Don=92t know these well enough.

--_000_BD9416036CB14855924DB5D134555778vidyocom_-- From nobody Tue Jul 1 08:07:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D8C1A0537 for ; Tue, 1 Jul 2014 08:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.87 X-Spam-Level: * X-Spam-Status: No, score=1.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-8XAqVfGsy7 for ; Tue, 1 Jul 2014 08:07:27 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6C51A0549 for ; Tue, 1 Jul 2014 08:07:26 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/1/2014 11:07:25 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-280/SG:5 7/1/2014 11:06:58 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.867208 p=-0.979628 Source White X-Signature-Violations: 0-0-0-26704-c X-Note-419: 15.6003 ms. Fail:0 Chk:1337 of 1337 total X-Note: SCH-CT/SI:0-1337/SG:1 7/1/2014 11:07:23 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 109600245; Tue, 01 Jul 2014 11:07:25 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Tue, 1 Jul 2014 10:07:24 -0500 From: Jonathan Lennox To: Harald Alvestrand Thread-Topic: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis Thread-Index: AQHPlTkoTSsSmgi9qkCGBpSoE1Vx4JuLpbSA Date: Tue, 1 Jul 2014 15:07:24 +0000 Message-ID: References: <53B14959.2090907@alvestrand.no> In-Reply-To: <53B14959.2090907@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_EFB18D89924E4DDCA039EA891898F6D2vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/W5a6yuqDPswSJTnv7jCoUmZZPCg Cc: mmusic Subject: Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 15:07:29 -0000 --_000_EFB18D89924E4DDCA039EA891898F6D2vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 30, 2014, at 7:26 AM, Harald Alvestrand > wrote: I agree with Bo's analysis concluding that IDENTICAL-PER-SSRC is likely not= needed, and that situations where one has one SSRC in multiple media descr= iptions are probably a Bad Thing (I can't think of a case where it would re= present anything but a bug). The use case for it, I think, would be a scenario where a single RTP packet= stream can satisfy the intended semantics of more than one media descripti= on. My usual example is when I am in a conference, viewing both the current lou= dest speaker and also a specific person (say, my boss, or the customer). I= send two separate media descriptions requesting both those items. During those times when that specific person is the loudest speaker, the se= rver can save bandwidth by sending the single RTP packet stream carrying th= at person=92s video only once. It sends the same SSRC in both media descri= ptions to indicate that that packet stream is intended to be consumed by bo= th of them. Now, maybe we don=92t want to support this use case, or maybe we want to su= pport it in some way other than SDP-based signaling (as being too heavyweig= ht for moving SSRCs around on the timescale of loudest-speaker timescale sw= itching). But we should make that decision explicitly. IDENTICAL-PER-PT seems like a sensible thing to add. On 06/23/2014 05:36 AM, Suhas Nandakumar wrote: Hello All Continuing the discussions from London on analyzing multiplexing behavio= r for SDP attributes that are defined per Payload Type, I was thinking on = making following changes to the draft-ietf-mmusic-sdp-mux-attributes-01. 1. Add new category called IDENTICAL-PER-PT to the SDP Attribute analysis f= ramework in Section 4 which is defined as IDENTICAL-PER-PT: Attributes that define the RTP payload configuration on p= er Payload Type basis and MUST have identical values across all the media d= escriptions for a given RTP Payload Type when repeated. 2. Similarly add another category IDENTICAL-PER-SSRC to accommodate source = level SDP attributes. IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP Packet= Streams in a given RTP Session and MUST have identical values when repeate= d across multiple media description for a given SSRC. 3. For all the attributes that directly/indirectly impact codec configurati= on and packetization of the media, I have attempted to assign a SDP MUX cat= egory and provide some insights on how such a decision was made (wherever a= pplicable) Attribute: a=3Dptime, a=3Dmaxptime Mux Category: IDENTICAL-PER-PT Notes: For a given codec the audio packetization time must be same if the P= T is repeated. This will ensure that the RTP receiver can unambiguously dec= ode the incoming audio packets. Attribute: a=3Dframerate Mux Category: IDENTICAL-PER-PT Attribute: a=3Drtpmap Mux Category: IDENTICAL-PER-PT Attribute: a=3Dfmtp Mux Category: IDENTICAL-PER-PT Notes: Attribute: a=3Drtcp-fb Mux Category: NORMAL Notes: Since the feedback messages are reported per SSRC, the category of N= ORMAL suffices. Attribute: a=3Ddepend (RFC5583) Mux Category: IDENTICAL-PER-PT Notes: Since each dependency identifies a unique RTP packetization and thus MUST = be identified via unique Payload Type. Similarly if the Payload Type is repeated across media descriptions, they M= UST represent the Identical codec configuration. Attribute: a=3Dssrc:xyz fmtp: ... Mux Category: IDENTICAL-PER-PT Notes: RFC5576 says this : " Within a media stream, "ssrc" attributes with the same value of describe different attributes of the same media sources. Across media streams, values are not correlated (unless correlation is indicated by media-stream grouping or some other mechanism) and MAY be repeated. " Thus if the RTP Payload Type used to specify fmtp parameters is repeated, = it MUST represent the same codec configuration. example: m=3Dvideo ... a=3Drtpmap:98 VP8/90000 a=3Dssrc:12345 fmtp:98max-fr=3D15; max-fs-1200 m=3Dvideo ... a=3Drtpmap:98 VP8/90000 a=3Dssrc:56789 fmtp:98 max-fr=3D15; max-fs-1200 Attribute: a=3Dssrc:xyz cname: .... Mux Category: IDENTICAL-PER-SSRC Notes: RFC5576 defines the identical requirement as it is. Attribute: a=3Dimageattr Mux Category: IDENTICAL-PER-PT Attribute: a=3Dframesize Mux Category: IDENTICAL-PER-PT Attributes: a=3Dfec-source-flow, a=3Dfec-repair-flow, a=3Drepair-window Mux Category: NORMAL I believe these cover all PT scoped SDP attributes. Please let me know your= thoughts and comments. Cheers Suhas Nandakumar _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_EFB18D89924E4DDCA039EA891898F6D2vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4EB84CF21D28794382099F9FA40AD808@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Jun 30, 2014, at 7:26 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

I agree with Bo's analysis concluding that I= DENTICAL-PER-SSRC is likely not needed, and that situations where one has o= ne SSRC in multiple media descriptions are probably a Bad Thing (I can't th= ink of a case where it would represent anything but a bug).

The use case for it, I think, would be a scenario where a single RTP packet= stream can satisfy the intended semantics of more than one media descripti= on.

My usual example is when I am in a conference, viewing both the curren= t loudest speaker and also a specific person (say, my boss, or the customer= ).  I send two separate media descriptions requesting both those items= .

During those times when that specific person is the loudest speaker, t= he server can save bandwidth by sending the single RTP packet stream carryi= ng that person=92s video only once.  It sends the same SSRC in both me= dia descriptions to indicate that that packet stream is intended to be consumed by both of them.

Now, maybe we don=92t want to support this use case, or maybe we want = to support it in some way other than SDP-based signaling (as being too heav= yweight for moving SSRCs around on the timescale of loudest-speaker timesca= le switching).  But we should make that decision explicitly.

IDENTICAL-PER-PT seems like a sensible thing= to add.

On 06/23/2014 05:36 AM, Suhas Nandakumar wrote:
Hello All

  
   Continuing the discuss= ions from London on analyzing multiplexing behavior for SDP attributes that= are defined per  Payload Type, I was thinking on making following cha= nges to the draft-ietf-mmusic-sdp-mux-attributes-01. 

1. Add new category called IDENTICA= L-PER-PT to the SDP Attribute analysis framework in Section 4 which is defi= ned as

IDENTICAL-PER-PT: Attributes that d= efine the RTP payload configuration on per Payload Type basis and MUST have= identical values across all the media descriptions for a given RTP Payload Type when repeated.

2. Similarly add anothe= r category IDENTICAL-PER-SSRC to accommodate source level SDP attributes.

IDENTICAL-PER-SSRC: Attributes that= correspond to the individual RTP Packet Streams in a given RTP Session and= MUST have identical values when repeated across multiple media description= for a given SSRC.

3. For all the attributes that dire= ctly/indirectly impact codec configuration and packetization of the media, = I have attempted to assign a SDP MUX category and provide some insights on = how such a decision was made (wherever applicable)

Attribute: a=3Dptime, a=3Dmaxpti= me
Mux Category: IDENTICAL-PER-PT
Notes: For a given codec the audio = packetization time must be same if the PT is repeated. This will ensure tha= t the RTP receiver can unambiguously decode the incoming audio pa= ckets.


Attribute: a=3Dframerate
Mux Category: IDENTICAL-PER-PT

Attribute: a=3Drtpmap
Mux Category: IDENTICAL-PER-PT


Attribute: a=3Dfmtp
Mux Category: IDENTICAL-PER-PT
Notes: 

Attribute: a=3Drtcp-fb
Mux Category: NORMAL
Notes: Since the feedback messages are reported per SSRC, t= he category of NORMAL suffices.

Attribute: a=3Ddepend (RFC5583)
Mux Category: IDENTICAL-PER-PT
Notes:
Since each dependency identifies a unique RTP packetization  and = thus MUST be identified via unique Payload Type. 
Similarly if the Payload Type is repeated across media descriptions, t= hey MUST represent the Identical codec configuration. 

Attribute: a=3Dssrc:xyz  fmtp:<fmt> ... 
Mux Category: IDENTICAL-PER-PT
Notes:
RFC5576 says this :
"  
Within a media stream, "ssrc"= ; attributes with the same value of
 
<ssrc-id> describe different a=
ttributes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other

mechanism) and MAY be repeated.


"


Thus if the RTP Payload Type used to=
 specify fmtp parameters  is repeated, it MUST represent the same codec configurat=
ion.


example:


m=3Dvideo =
...


a=3Drtpmap=
:98 VP8/90000


a=3Dssrc:1=
2345 fmtp:98max-fr=3D15; max-fs-1200




m=3Dvideo ..=
.
a=
=3Drtpmap:98 VP8/90000


a=3Dssrc:56789 f=
mtp:98 max-fr=3D15; max-fs-1200










Attribute: a=3Dssrc:xyz  cname: ....


Mux Category: IDENTICAL-PER-SSRC


Notes: RFC5576 defines the identical requirement as it is.
















Attribute: a=3Dimageattr


Mux Category: IDENTICAL-PER-PT














Attribute: a=3Dframesize


Mux Category: IDENTICAL-PER-PT














Attributes: a=3Dfec-source-flow, a=
=3Dfec-repair-flow, a=3Drepair-windo=
w


Mux Category: NORMAL














I believe these cover all PT scoped SDP attributes. Please let me know=
 your thoughts and comments.







Cheers


Suhas Nandakumar










 


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








_______________________________________________

mmusic mailing list

mmusic@ietf.org

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










--_000_EFB18D89924E4DDCA039EA891898F6D2vidyocom_--


From nobody Tue Jul  1 08:38:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7B41A058E for ; Tue,  1 Jul 2014 08:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzDXPHo5al8F for ; Tue,  1 Jul 2014 08:38:29 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF161B282A for ; Tue,  1 Jul 2014 08:38:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 445397C38CC; Tue,  1 Jul 2014 17:38:27 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RSut66izv7T; Tue,  1 Jul 2014 17:38:26 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 074747C3847; Tue,  1 Jul 2014 17:38:26 +0200 (CEST)
Message-ID: <53B2D5F1.4030708@alvestrand.no>
Date: Tue, 01 Jul 2014 17:38:25 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Jonathan Lennox 
References:  <53B14959.2090907@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050005010100030105030601"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CKgaD1epYcncNmVmSI0YVgtOMlk
Cc: mmusic 
Subject: Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Jul 2014 15:38:32 -0000

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

On 07/01/2014 05:07 PM, Jonathan Lennox wrote:
>
> On Jun 30, 2014, at 7:26 AM, Harald Alvestrand  > wrote:
>
>> I agree with Bo's analysis concluding that IDENTICAL-PER-SSRC is 
>> likely not needed, and that situations where one has one SSRC in 
>> multiple media descriptions are probably a Bad Thing (I can't think 
>> of a case where it would represent anything but a bug).
>
> The use case for it, I think, would be a scenario where a single RTP 
> packet stream can satisfy the intended semantics of more than one 
> media description.
>
> My usual example is when I am in a conference, viewing both the 
> current loudest speaker and also a specific person (say, my boss, or 
> the customer).  I send two separate media descriptions requesting both 
> those items.
>
> During those times when that specific person is the loudest speaker, 
> the server can save bandwidth by sending the single RTP packet stream 
> carrying that persons video only once.  It sends the same SSRC in 
> both media descriptions to indicate that that packet stream is 
> intended to be consumed by both of them.
>
> Now, maybe we dont want to support this use case, or maybe we want to 
> support it in some way other than SDP-based signaling (as being too 
> heavyweight for moving SSRCs around on the timescale of 
> loudest-speaker timescale switching).  But we should make that 
> decision explicitly.

If we want to support that scenario, we also need to make the app-id 
token used for association between an RTP packet and an m-line 
multivalued. It seems to me that we've so far just assumed that it's 
single-valued.

I can see the logic in wanting to support such a scenario, but I am 
afraid of finding that there are more places than I can think of where 
we've implicitly made the opposite assumption (app-id was only the first 
one I could think of).


--------------050005010100030105030601
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 07/01/2014 05:07 PM, Jonathan Lennox
      wrote:

    

    

      
      

      

        
On Jun 30, 2014, at 7:26 AM, Harald Alvestrand <harald@alvestrand.no>
          wrote:

        

        

          

            
I agree with Bo's analysis
              concluding that IDENTICAL-PER-SSRC is likely not needed,
              and that situations where one has one SSRC in multiple
              media descriptions are probably a Bad Thing (I can't think
              of a case where it would represent anything but a bug).

            

          

        

        


        

        The use case for it, I think, would be a scenario where a single
        RTP packet stream can satisfy the intended semantics of more
        than one media description.

      


      

      
My usual example is when I am in a conference, viewing both
        the current loudest speaker and also a specific person (say, my
        boss, or the customer). I send two separate media descriptions
        requesting both those items.

      


      

      
During those times when that specific person is the loudest
        speaker, the server can save bandwidth by sending the single RTP
        packet stream carrying that persons video only once. It sends
        the same SSRC in both media descriptions to indicate that that
        packet stream is intended to be consumed by both of them.

        


        

        
Now, maybe we dont want to support this use case, or maybe
          we want to support it in some way other than SDP-based
          signaling (as being too heavyweight for moving SSRCs around on
          the timescale of loudest-speaker timescale switching). But we
          should make that decision explicitly.

      

    

    

    If we want to support that scenario, we also need to make the app-id
    token used for association between an RTP packet and an m-line
    multivalued. It seems to me that we've so far just assumed that it's
    single-valued.

    

    I can see the logic in wanting to support such a scenario, but I am
    afraid of finding that there are more places than I can think of
    where we've implicitly made the opposite assumption (app-id was only
    the first one I could think of).

    

  


--------------050005010100030105030601--


From nobody Tue Jul  1 09:28:59 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7EF1B2855 for ; Tue,  1 Jul 2014 09:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5V8TuhX89Ob for ; Tue,  1 Jul 2014 09:28:56 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F211B284E for ; Tue,  1 Jul 2014 09:28:55 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 49C7720CE7 for ; Tue,  1 Jul 2014 12:28:55 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 01 Jul 2014 12:28:55 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=oF49dU+hIJtjya95KWCuxEz fPoc=; b=B5iiPlWWJxhJnKZ/S9qLySfr4xzecx6IBOx1YK8oJRQLOxXp+ti52nB ktGeCzFc+2F8ZS3sPgIjdukyaxDBSaCy3yPSkDgtyFJqjd/4o4ElBa7OVH9a5mUw qcRn4uLwaGgNnZX8evvHF3W/O0kpXsIEcMndFkn3jv8wQ2vrevZs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=oF49dU+hIJtjya95KWCuxEzfPoc=; b=AALp0Y4/c2/p+oWYRu3B8BjiYe0r yviBBARyHGjIbrIKQMQJNVcfiMZz3qXPB0AoYNhqJFHEr7/UK8zolsaLsDXhqK5Q JLq2SSJ7104dxz23LkgtqkNsFSFC530AzySdBKcZQsQsCg12duoHzAJcV25W+ta1 njAtMi4p8+khGhw=
X-Sasl-enc: o/9BsbY84bqwcP2UxiVdzGjOB9bWv1ADRRKfrEGrGhOw 1404232134
Received: from [10.21.67.129] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 3F1DFC007AC; Tue,  1 Jul 2014 12:28:51 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Tue, 01 Jul 2014 12:28:46 -0400
From: Alissa Cooper 
To: IESG 
Message-ID: 
Thread-Topic: Approved: draft-ietf-mmusic-latching-08
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FzdJRyRF5SJ1tjIMLZnsTG4MQFs
Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic@ietf.org
Subject: [MMUSIC] Approved: draft-ietf-mmusic-latching-08
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Jul 2014 16:28:57 -0000

Dear Secretariat (BCC'ed):

This draft is approved.  Please send it to the RFC Editor.

Thanks,
Alissa



From nobody Tue Jul  1 09:33:30 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA10C1B285C; Tue,  1 Jul 2014 09:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWECvSXB4bDJ; Tue,  1 Jul 2014 09:33:26 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DCF1B2842; Tue,  1 Jul 2014 09:33:24 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140701163324.8895.17038.idtracker@ietfa.amsl.com>
Date: Tue, 01 Jul 2014 09:33:24 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aq9IzVrKqv7-twYZgTUzyC84HSw
Cc: mmusic chair , mmusic mailing list , RFC Editor 
Subject: [MMUSIC] Document Action: 'Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication' to Informational RFC (draft-ietf-mmusic-latching-08.txt)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Jul 2014 16:33:28 -0000

The IESG has approved the following document:
- 'Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
   Communication'
  (draft-ietf-mmusic-latching-08.txt) as Informational RFC

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Alissa Cooper and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/




Technical Summary

  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.


Working Group Summary

  There is WG consensus behind this draft. All issues raised during and 
  before WGLC have been addressed. There were concerns regarding the 
  harmfulness of the documented mechanisms, especially regarding security.
  The document was updated to stress that it only documents existing 
  behavior and does not recommend them as good practices.


Document Quality

  The document is well written and readable. It documents existing behavior
  that has been already earlier implemented by various vendors.


Personnel

  Ari Keranen is the Document Shepherd, and the Responsible Area
  Director is Alissa Cooper.


From nobody Wed Jul  2 14:02:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3B1B2A89 for ; Wed,  2 Jul 2014 14:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMxsuHk0xJc3 for ; Wed,  2 Jul 2014 14:02:09 -0700 (PDT)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6928D1B28A8 for ; Wed,  2 Jul 2014 14:02:09 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id k15so9413835qaq.16 for ; Wed, 02 Jul 2014 14:02:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=MAGsqRF83ZTJfGofgzVj87j+GBCvYpGBialnfjQNDUE=; b=EewAE8Vk9lsN+KgARjew4DR3IWiO+YqjVsqe8mABhKMEQQe7/J43VwZpxLVDDxv5A0 +mmyMNAQwAL7Gr4Odzxzcd7YfP74eqaFwK94Bm10sMqhDXqph5aVngDWWTLBJgV1Axtp HaoFDFMx3ki1nYF/wesBTwVm3Tw5AfWrbf/YEUA4UvhiUG8VLj52cR6ZHq77HZkqtbKt n2aRTMThDY1K9Px4Q7KmXc034rm/ZRwdbIrUpY2vk56t8Pp8XKdZgY/ViLYmadk5YL/Y yDBXxjQKPzqa5tQq4PydEHorAhH6DlTnP1iTtx+TH5eBISWkIpM1c93dhPLvW7gMJ5hL qbLA==
X-Gm-Message-State: ALoCoQkSYysJpjY3YgXKrVx6nrAn6/APahQEe9I6cGsB18M8ctd51nCzmpx2mDxwDO0UnlbMiWID
X-Received: by 10.229.51.201 with SMTP id e9mr865413qcg.2.1404334928563; Wed, 02 Jul 2014 14:02:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.131 with HTTP; Wed, 2 Jul 2014 14:01:48 -0700 (PDT)
In-Reply-To: <53A0B9CB.3050909@jitsi.org>
References: <20140617215119.31326.31295.idtracker@ietfa.amsl.com> <53A0B9CB.3050909@jitsi.org>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 2 Jul 2014 23:01:48 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3kD_5i6gNEpGLap4hUWdaAzrU3c
Cc: MMUSIC 
Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-trickle-ice-sip-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 Jul 2014 21:02:11 -0000

2014-06-17 23:57 GMT+02:00 Emil Ivov :
> Trickle ICE for SIP:
> [0] html: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02
> [1] diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ivov-mmusic-trickle-ice-sip-02

Hi,

Great work, I strongly support it!

Just some minor comments:


- Please clarify that receiving a non-100 provisional response is not
enough for starting INFO requests. The 1XX response MUST contain a
Contact header (unfortunately some ugly SIP devices do not add Contact
nor Record-Route in provisional responses).


- 5.2. Trickle ICE discovery with GRUU

>   Such targeted trickling may happen in different ways.  One option
>   would be for a SIP UA to learn the GRUU instance ID of a peer through
>   presence and to then query its capabilities direction with an OPTIONS
>   request.  Alternately, it can also just send an OPTIONS request to
>   the AOR it intends to contact and then inspect the returned
>   response(s) for support of both GRUU and trickle ICE (Figure 7).

"Alternately, it can also just send an OPTIONS request to the AOR"

The usage of OPTIONS for that is a bad idea since an OPTIONS to a
non-GRUU AOR will receive a single response in case of forking (and
may be Bob-1 supports trickle-ice but Bob-2 does not, and the next
INVITE is answered by Bob-2...).


Apart from that, I consider the spec excellent, and it is good to see
a nice usage for INFO :)

Great! hope there is agreement on this work and we get some point to
start deploying ICE-trickle capable SIP stuff.



--=20
I=C3=B1aki Baz Castillo



From nobody Wed Jul  2 16:23:23 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280901A0AC1 for ; Wed,  2 Jul 2014 16:23:21 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM2zxQNXkyyr for ; Wed,  2 Jul 2014 16:23:18 -0700 (PDT)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5199C1A03FD for ; Wed,  2 Jul 2014 16:23:18 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u57so12075402wes.19 for ; Wed, 02 Jul 2014 16:23:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=SOixgqPKEOcvQhZGWlj7jsdv7HuN3JrmTagTiDY6/rg=; b=FPOr4QeWf466ps2mF5tnquyjo2LazHMlTf5GqtELwdz9Zb70BGCCok+YdpR9230Sjy W+RUUdSkpK9hw2ZB3WmRODxTGv4UHrdQFzjccY8rOGN3io9F8VBveC87fbblHPA9GTl/ lvGMijAqZfQ+In36KGd7SRq9ec5D0f+HwsnX7WzgQwj05WewgZhhE5mZYyUb2zZucksk 2SU/yl1wecl7mGxSeT1w+lxjlO4suJhDh+ytC48Lea/1UmzzeUgkx4BkcHQKTj2wrC10 PSST1HErKzKTzsTkCPxfdZIyFyhcx6hp4iI979EJ2+GetQo+Nau9CugpMSts5F8qxWlW QvSg==
X-Gm-Message-State: ALoCoQkpTlw17kgTWu0dEAzo/36wXl+wRiN9uDkn80MaSqDZfyS0CQYf1hSZDmH+Rc6N0nt//VgT
X-Received: by 10.180.76.20 with SMTP id g20mr6285948wiw.7.1404343397007; Wed, 02 Jul 2014 16:23:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.57.202 with HTTP; Wed, 2 Jul 2014 16:22:36 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:d67:f212:2165:1fd2]
From: Eric Rescorla 
Date: Wed, 2 Jul 2014 16:22:36 -0700
Message-ID: 
To: mmusic WG , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d04343946525dfe04fd3e2ddb
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YB7ZZr6LyN03-8LdaTC62e8rGpo
Subject: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 Jul 2014 23:23:21 -0000

--f46d04343946525dfe04fd3e2ddb
Content-Type: text/plain; charset=UTF-8

Folks,

https://github.com/rtcweb-wg/jsep/issues/41


We ran into a place where bundle and trickle conflict.

Trickle requires that you use port 9 for the c-line if you are doing full
trickle:
http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1


However, JSEP explicitly requires that we use distinct ports for
each m= line:
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1

Obviously 9 is equal to itself, so this isn't going to work.


The JSEP editors got together and came to the conclusion that
we probably needed to use sequential numbers < 1024. Does
anyone object to this? If not, perhaps Emil can edit this into Trickle.


Also, JSEP uses the term "null" for these ports. We propose that
instead we use the term "dummy".

-Ekr

--f46d04343946525dfe04fd3e2ddb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Folks,







Trickle requires that you use port 9 for the c-line if =
you are doing full
trickle:


However, JSEP explicitly requires =
that we use distinct ports for
each m=3D line:

Obviously 9 is equal to itself, so this isn't=
 going to work.


The JSEP editors go=
t together and came to the conclusion that
we probably needed to =
use sequential numbers < 1024. Does



anyone object to this? If not, perhaps Emil can edit this into Trickle=
.


Also, JSEP uses the term "nu=
ll" for these ports. We propose that
instead we use the term=
 "dummy".




-Ekr



=







--f46d04343946525dfe04fd3e2ddb--


From nobody Wed Jul  2 16:36:55 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E401A03FD; Wed,  2 Jul 2014 16:36:53 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR1NaB1ko3xO; Wed,  2 Jul 2014 16:36:52 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F801A0387; Wed,  2 Jul 2014 16:36:52 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id n12so11641416wgh.19 for ; Wed, 02 Jul 2014 16:36: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=b4+tOolvxcpd0ktMD30/K729vkqmjdPEA4F1+Fpsg6w=; b=JDlohnSSetoe3JOG7z1ompZcU6sDYzjEQbul+o0XDn6g+fiZHSCjwmqqwMPXachmMB /p961G+3BEqtWJR6CUssszYr/+4AkgNTAA7hEX6U+lX+iq2IXJOc9rT0/CCGMFtzEoT+ Ih0LWXLryh90ysGWugjNemMhcH5pGl2PKqc73RIOD7neRVsZRU59CDlSUcMLItofP+JS JqCniqhnbn6OszEqaO6RsN9g63/Tvl/aP78ZCP3xNv/rDXF/IX41BlCE7IcEmDm6llNe y1apwEYe/kGK6Ax2GOxEoo230LtSIKQ2lmWDC4h8RCMsS0hfkwWlpbsgNido5JdjKbpg rHbQ==
MIME-Version: 1.0
X-Received: by 10.180.101.39 with SMTP id fd7mr7072565wib.65.1404344210753; Wed, 02 Jul 2014 16:36:50 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Wed, 2 Jul 2014 16:36:50 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 2 Jul 2014 16:36:50 -0700
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/14aL2DYoWMKZlbFzB6eyH8vcO-w
Cc: "rtcweb@ietf.org" , mmusic WG 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 02 Jul 2014 23:36:53 -0000

On 2 July 2014 16:22, Eric Rescorla  wrote:
>
> However, JSEP explicitly requires that we use distinct ports for
> each m= line:
> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1
>
> Obviously 9 is equal to itself, so this isn't going to work.

I'm not sure that this is actually a problem, unless I've missed something.

The reason for having different ports is to make it clear that the m=
section will have distinct transport endpoints and can be unbungled if
the answerer wants that.  But the presence (or absence) of
a=bungle-only is sufficient to distinguish those m= sections.

> Also, JSEP uses the term "null" for these ports. We propose that
> instead we use the term "dummy".

WFM.


From nobody Fri Jul  4 01:12:01 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260F51B2C5F for ; Fri,  4 Jul 2014 01:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR0EIBG9K3I3 for ; Fri,  4 Jul 2014 01:11:56 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DA1B2C5E for ; Fri,  4 Jul 2014 01:11:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 32DE47C38DD for ; Fri,  4 Jul 2014 10:11:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5YA4Lm6PAul for ; Fri,  4 Jul 2014 10:11:54 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:101:1bc:3f43:82ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 06C347C3855 for ; Fri,  4 Jul 2014 10:11:54 +0200 (CEST)
Message-ID: <53B661C9.6090009@alvestrand.no>
Date: Fri, 04 Jul 2014 10:11:53 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tK0nM1UnGfwvZ1O50W2nTNMRYuo
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 08:11:59 -0000

On 07/03/2014 01:36 AM, Martin Thomson wrote:
> On 2 July 2014 16:22, Eric Rescorla  wrote:
>> However, JSEP explicitly requires that we use distinct ports for
>> each m= line:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1
>>
>> Obviously 9 is equal to itself, so this isn't going to work.
> I'm not sure that this is actually a problem, unless I've missed something.
>
> The reason for having different ports is to make it clear that the m=
> section will have distinct transport endpoints and can be unbungled if
> the answerer wants that.  But the presence (or absence) of
> a=bungle-only is sufficient to distinguish those m= sections.

Requiring multiple port 9s is silly. BUNDLE should not require this.

If I remember rightly, port 9 started out with TCP candidates where the 
transport can only be established as an outgoing call.

BUNDLE should say "MUST be unique, unless they're the discard port (port 
9)".

>
>> Also, JSEP uses the term "null" for these ports. We propose that
>> instead we use the term "dummy".
> WFM.
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Fri Jul  4 01:26:45 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E431B2C71 for ; Fri,  4 Jul 2014 01:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cltfKVg9aN0j for ; Fri,  4 Jul 2014 01:26:41 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726541B2C5D for ; Fri,  4 Jul 2014 01:26:41 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id z60so1182912qgd.2 for ; Fri, 04 Jul 2014 01:26:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Aumc4PerOUx3XBuhKRx7g0aLLCAAhHeWIzP4vgTtq7c=; b=lahesmiUYsVvMcFGRDUMNwuIjrANTfdhZ9sq9Bv1l33Ycl1QzlJZMsyqK5RyCjjL14 AEv22pq5sYgxUKIM/bYi7yFuvSYAx6PLS2W+0w7BsYkrKfyOzJYGAaO/ZTfIR5n9H4+G +U2Z4fh+7QPF0zNDSJjD+Q2ib6/yi3NJU5wVcLO/RUEMDMQ/f5Qkv9DdKGfF9vng1Faz zapmqVm/un8lZohWOolgWJTOD1cngkgNJ1XqgdAV7aycfubGzXYVk2o4dxkAOHpqRDDd vzeO3L3CxvxuaR5Z+GbZ47aXrMoTgtMTJq3OBoNnqGNQy3Us51kmARYYafVz86fUkBJs Se0w==
X-Gm-Message-State: ALoCoQmAsMLmiW9z+y6D8bFjN5ee45DbTBE2ZHil7GgR8a6oSdvD0CaikFqiKQiV9pu11DpZH6jg
X-Received: by 10.140.40.81 with SMTP id w75mr15363853qgw.112.1404462400662; Fri, 04 Jul 2014 01:26:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.131 with HTTP; Fri, 4 Jul 2014 01:26:20 -0700 (PDT)
In-Reply-To: 
References: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 4 Jul 2014 10:26:20 +0200
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/e2z95Y5c80xQMBW_WPFIhROTgMU
Cc: "rtcweb@ietf.org" , mmusic WG 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 08:26:43 -0000

2014-07-03 1:22 GMT+02:00 Eric Rescorla :
> Trickle requires that you use port 9 for the c-line if you are doing full
> trickle:
> http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1

Isn't there any other way to indicate it instead of setting port to 9?
=C2=BFany attribute?

Section 5.1 [*] in draft-ietf-mmusic-trickle-ice-01 is really exasperating.

[*] http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1


--=20
I=C3=B1aki Baz Castillo



From nobody Fri Jul  4 03:01:02 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D612A1B2CCA; Fri,  4 Jul 2014 03:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAzvMyzgsPWw; Fri,  4 Jul 2014 03:00:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3D1B2CCF; Fri,  4 Jul 2014 03:00:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140704100058.924.23387.idtracker@ietfa.amsl.com>
Date: Fri, 04 Jul 2014 03:00:58 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8_-0400jiiPekmHF0QKColUNMTE
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 10:01:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : A Framework for SDP Attributes when Multiplexing
        Author          : Suhas Nandakumar
	Filename        : draft-ietf-mmusic-sdp-mux-attributes-02.txt
	Pages           : 68
	Date            : 2014-07-04

Abstract:
   The Session Description Protocol (SDP) provides mechanisms to
   describe attributes of multimedia sessions and of individual media
   streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
   multimedia session.  In the RTCWeb WG, there is a need to use a
   single 5-tuple for sending and receiving media associated with
   multiple media descriptions ("m=" lines).  Such a requirement has
   raised concerns over the semantic implications of the SDP attributes
   associated with the RTP Media Streams multiplexed over a single
   transport layer flow.

   The scope of this specification is to provide a framework for
   analyzing the multiplexing characteristics of SDP attributes.  The
   specification also categorizes existing attributes based on the
   framework described herein.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jul  4 12:47:00 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3B11B2F49; Fri,  4 Jul 2014 12:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLKSNd_HNFPJ; Fri,  4 Jul 2014 12:46:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FB31B2F17; Fri,  4 Jul 2014 12:46:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140704194655.28949.11788.idtracker@ietfa.amsl.com>
Date: Fri, 04 Jul 2014 12:46:55 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZqHTtY7k64HdaWCZ6XHxLB8egfI
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-07.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 19:46:57 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)
        Authors         : Salvatore Loreto
                          Gonzalo Camarillo
	Filename        : draft-ietf-mmusic-sctp-sdp-07.txt
	Pages           : 14
	Date            : 2014-07-04

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-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jul  4 13:22:41 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4980E1B2F5D; Fri,  4 Jul 2014 13:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZJsnLcfGN-W; Fri,  4 Jul 2014 13:22:38 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85C1B2F50; Fri,  4 Jul 2014 13:22:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140704202238.1596.55511.idtracker@ietfa.amsl.com>
Date: Fri, 04 Jul 2014 13:22:38 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UJPe8uQt8FzEX8O3kfTBrMekLas
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-05.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 20:22:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : The Session Description Protocol (SDP) 'trafficclass' Attribute
        Authors         : James Polk
                          Subha Dhesikan
                          Paul E. Jones
	Filename        : draft-ietf-mmusic-traffic-class-for-sdp-05.txt
	Pages           : 29
	Date            : 2014-07-04

Abstract:
   This document proposes a new Session Description Protocol (SDP)
   attribute to identify the traffic class a session is requesting
   in its offer/answer exchange.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-traffic-class-for-sdp-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jul  4 13:52:17 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4C41B2D43 for ; Fri,  4 Jul 2014 13:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.235
X-Spam-Level: 
X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8S--Z5xJXnA for ; Fri,  4 Jul 2014 13:52:14 -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 7D6C11B2A3D for ; Fri,  4 Jul 2014 13:52:14 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id NLr41o0020vyq2s53LsEYR; Fri, 04 Jul 2014 20:52:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id NLsC1o00Z3ZTu2S3RLsESm; Fri, 04 Jul 2014 20:52:14 +0000
Message-ID: <53B713FC.5010507@alum.mit.edu>
Date: Fri, 04 Jul 2014 16:52:12 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References:   <53B661C9.6090009@alvestrand.no>
In-Reply-To: <53B661C9.6090009@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=q20140121; t=1404507134; bh=cNb4AuMlej9HOLmXuKYfvP4HNKq9qDz2X36temv9y7I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uthffxo/hRI2wH45EfjY7IJ/Wt6shqKyWDH18XryuIUYCyJ6kKSU148xint6WQ+6v ctZZlnFnW+/p4XA2ITDiO5goeTnMNJkshqha3cO/ZyY+zTdqhwYkAP1X/vlqmem6S/ XnOwNNKMmciZo6MB75R/sCwJP5BqPs0jXVZJEJWtTejS6hysOLfKLDPJvmZO5jM4Sn Tk6jQ+KsPahO00zBbjxkwXJroYieHUVfnUqEsR9+InlbYEEW/lkvSmZcklStSIy145 A2AdiJwzFO64tMKvFYj6dceyr806EH+4KqUiaKGRTvDa70IPsyfRWfGxJdPt2iwhaw T+BM3B1ovesOQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GRXDDWMfoW0RMrxv8YRbOzSzB9c
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 20:52:16 -0000

On 7/4/14 4:11 AM, Harald Alvestrand wrote:
> On 07/03/2014 01:36 AM, Martin Thomson wrote:
>> On 2 July 2014 16:22, Eric Rescorla  wrote:
>>> However, JSEP explicitly requires that we use distinct ports for
>>> each m= line:
>>> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1
>>>
>>> Obviously 9 is equal to itself, so this isn't going to work.
>> I'm not sure that this is actually a problem, unless I've missed
>> something.
>>
>> The reason for having different ports is to make it clear that the m=
>> section will have distinct transport endpoints and can be unbungled if
>> the answerer wants that.  But the presence (or absence) of
>> a=bungle-only is sufficient to distinguish those m= sections.

It isn't sufficient in the first offer, before you know if the other 
side supports it. If not, then you don't want the media to happen at 
all. The port=9 will ensure that, just as port=0 would.

But the answerer that doesn't understand bundle-only may also be 
disturbed by finding multiple port 9's. (If it gave any thought to the 
matter it wouldn't, but by the letter of the law it is incorrect.

> Requiring multiple port 9s is silly. BUNDLE should not require this.
>
> If I remember rightly, port 9 started out with TCP candidates where the
> transport can only be established as an outgoing call.
>
> BUNDLE should say "MUST be unique, unless they're the discard port (port
> 9)".

Certainly you should be able to use unique-ports. But then you might as 
well not bother with bundle-only, since you need to allocate the ports.

	Thanks,
	Paul

>>> Also, JSEP uses the term "null" for these ports. We propose that
>>> instead we use the term "dummy".
>> WFM.
>>
>> _______________________________________________
>> 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 nobody Fri Jul  4 14:41:41 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45C1A008B; Fri,  4 Jul 2014 14:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csuxWpo3m9cR; Fri,  4 Jul 2014 14:41:35 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B811A0061; Fri,  4 Jul 2014 14:41:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140704214135.6616.61362.idtracker@ietfa.amsl.com>
Date: Fri, 04 Jul 2014 14:41:35 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WM6kxkgC8ti7QemOTAY2_SA8Z2c
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 21:41:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
        Authors         : Ari Keranen
                          Jonathan Rosenberg
	Filename        : draft-ietf-mmusic-rfc5245bis-02.txt
	Pages           : 89
	Date            : 2014-07-04

Abstract:
   This document describes a protocol for Network Address Translator
   (NAT) traversal for UDP-based multimedia sessions established with
   the offer/answer model.  This protocol is called Interactive
   Connectivity Establishment (ICE).  ICE makes use of the Session
   Traversal Utilities for NAT (STUN) protocol and its extension,
   Traversal Using Relay NAT (TURN).  ICE can be used by any protocol
   utilizing the offer/answer model, such as the Session Initiation
   Protocol (SIP).

   This document obsoletes RFC 5245.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc5245bis-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jul  4 14:41:59 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B26B1A0095; Fri,  4 Jul 2014 14:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt1yyKBogVmy; Fri,  4 Jul 2014 14:41:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127A1A00A7; Fri,  4 Jul 2014 14:41:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140704214149.24444.81015.idtracker@ietfa.amsl.com>
Date: Fri, 04 Jul 2014 14:41:49 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EeLiXJ_sDty-dB-BWAnpr9a-g18
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-03.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Jul 2014 21:41:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
        Authors         : Marc Petit-Huguenin
                          Ari Keranen
	Filename        : draft-ietf-mmusic-ice-sip-sdp-03.txt
	Pages           : 41
	Date            : 2014-07-04

Abstract:
   This document describes how Interactive Connectivity Establishment
   (ICE) is used with Session Description Protocol (SDP) offer/answer
   and Session Initiation Protocol (SIP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Mon Jul  7 01:07:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFE51B279F for ; Mon,  7 Jul 2014 01:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM8PBqMCUCtY for ; Mon,  7 Jul 2014 01:07:08 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDF91B279D for ; Mon,  7 Jul 2014 01:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5154; q=dns/txt; s=iport; t=1404720429; x=1405930029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=StfnKrIVw4fGqxi/aIo131cNiary2GuKTVVWQTHw8vo=; b=gINRYCgzaIri7xR9iHxZ8QUhrbkcbFyiO4KtUPjj5JoeFicXJJ/olEX8 DGVRe946giYirwvPcZ8ymmw34PW12NLzchw1FBh4vAMSGVAn6LvZoLFZp GCapuwwdoj6R1ufJ2cdt1yr5dngV+jTr/x2bRf9qFXV4q3A8xXUEqvoeb 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcFAMpTulOtJA2M/2dsb2JhbABQCg6CXCRSWr5zhmxTAYEPFnWEAwEBAQMBAQEBNzQLEAIBCA4KHhAnCyUBAQQOBRuIHwgBDMlEEwSJZYRQCwYIAgIBHDMHgy2BFgWadpQMgwFCgjA
X-IronPort-AV: E=Sophos;i="5.01,616,1400025600"; d="scan'208";a="58750644"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 07 Jul 2014 08:07:07 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s67876Es007709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 08:07:06 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 03:07:06 -0500
From: "Ali C. Begen (abegen)" 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] 4566bis outstanding issues
Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IAEqYhwgA==
Date: Mon, 7 Jul 2014 08:07:05 +0000
Message-ID: 
References:  <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com>
In-Reply-To: <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.233.66]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4B5B8D4A3F39A84885BB376C33A3CCE7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/X8rzc58NoYZ5KuLJFt8vlMFz-xA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 4566bis outstanding issues
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 08:07:11 -0000

Hi Paul,

OK, no one else seems to be paying attention to this. I have some comments =
inline and lets see whether we can reach an agreement:

>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:
>>> Hi everyone
>>>=20
>>> I went thru the mail archives since 01/2012 and tried to list the issue=
s that seem to be unresolved at this point. I can put them in the tracker b=
ut I wanna provide a summary first.
>>>=20
>>> For some of the issues below, no solution has been proposed. For the re=
st, there was no agreement on what to do. Here it goes:
>>>=20
>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 =
defined.
>>>=20
>>> Comments: This was discussed again in a side meeting in London and ther=
e was not a consensus whether we actually needed this.
>>=20
>> IIRC the argument against doing this is that we might get it wrong.
>>=20
>> But IMO we should do it because if we can't get it right how can we expe=
ct readers to get it right?

I personally don't wanna take on this task. It is a tedious task and I am n=
ot such an ABNF lover to get these definitions right. If you wanna voluntee=
r, by all means, please do so.

Also, dozens of attributes have been defined since 4566 w/o issues so I am =
not seeing this as a high priority issue (or an issue at all).

>>=20
>>> 2) 4566bis should update the format of the IANA registries to reflect t=
he dependency between addrtype and net type.
>>>=20
>>> Comments: There does not seem an agreement on this but it looks to be a=
n easy fix.

You did not comment on this but this is an easy fix so I will do this.

@Chairs,

Is this (and all other IANA related issues) supposed to be part of the 4566=
bis document or a separate document? A separate document may keep 4566bis c=
lean and nice IMO.


>>>=20
>>> 3) Section 8.2.4 defines the IANA registry and populates it with the at=
tributes defined in 4566, however, Section 8.2.4 does not specify the name =
or format of the table.
>>>=20
>>> Comments: No text has been proposed or agreed but seems to be an easy f=
ix if we wanna do this.

I will also take care of this along with issue #2.

>>>=20
>>> 4) 4566bis does not make the registration of new network or address typ=
es mandatory. Section 8.2.6 and 8.2.7.
>>>=20
>>> Comments: If we agree that this should be mandatory, we can change the =
text.
>>=20
>> IMO we should make this change

I will make this change.

>>=20
>>> 5) Source-level attributes defined in 5576. Should these attributes be =
included in the same table structure in the IANA registry?
>>>=20
>>> Comments: This seems to be an organizational issue rather than a techni=
cal issue. If we agree we need this, we can take on this as well.
>>=20
>> Yes, but IMO an important one. The current registries are hard to read, =
and easy to get wrong when adding new attributes.
>>=20
>> Also, we ought to have templates for what goes into the IANA considerati=
on section when defining new attributes, and that template would be best in=
 this document.

OK, this will be taken care of along with issues #2 and #3.


>>=20
>>> 6) Should we add a new column called "registered network type" in the a=
ddrtype table in the IANA registry as not all address types are applicable =
for all network types?
>>>=20
>>> Comments: This is also an IANA fix that we can do in this bis document =
or in a separate document (with all the other IANA registry changes).
>>=20
>> Similar comment to the one just above.

Ditto.

>>=20
>>> These are the issues I was able to identify. There is one more thing re=
lated to ICE and I sent an email about this to Marc Petit-Huguenin. As soon=
 as he responds and depending on his answer, I might add one more issue.
>>>=20
>>> If there are things I missed, please let me know. The chairs and editor=
s would like to close these issues and finalize 4566bis soon.
>>=20
>> There is an ongoing problem when SDP extensions are defined - lack of a =
consistent format for defining new attributes. Many people look to 4566 for=
 examples of how to do this, but it provides bad examples.
>>=20
>> IMO 4566bis should show the definition of all attributes in a style that=
 complies with a recommended format for defining attributes.
>>=20
>> (Of course that implies that we could agree on such a format.)

OK, this goes back to the issue #1. Personally, I suggest we do not define =
the abnfs for every sdp attribute in 4566, but then you have a good point. =
We can seek a format and provide a few good examples to show prospective au=
thors.

To do this, obviously as you said, we need to agree on that format. Has the=
re been a proposal in the past or does anyone have a good proposal to start=
 with?

Thanks.
-acbegen


>>=20
>> 	Thanks,
>> 	Paul
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Mon Jul  7 04:17:07 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FBB1B2819 for ; Mon,  7 Jul 2014 04:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.601
X-Spam-Level: 
X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS1KOxV30VIw for ; Mon,  7 Jul 2014 04:17:02 -0700 (PDT)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697981B2812 for ; Mon,  7 Jul 2014 04:17:02 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id x12so4153118wgg.34 for ; Mon, 07 Jul 2014 04:17:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H9lGRSumWVNvx39J+CPbTmdiBPbceDqm8yoBLUsJA0w=; b=LSj6ExhzH/F3WI6NwBGzZv9UNHaw9EcWSTgDCtEEHhkpQKnupVIZiX5g6LTeh9xSkO /gYnT+2zqx6exFMNM+15kv9TYWaaCEkaGXwMwDhKbGEzHsZIE2BgZJNv5Rc21S2SsO/F LHC2RnXTuSlRpE0oj5t0evV1Yk+In6qxfUSYxOxCq98Hu6cpNzMCKI+sDKZjukXH8ppP MDPpef+Gz9baZFpNMAF7BDMA9w5qUtcjmid4es1K66x4gwDRPoNY166Z5Cez0iQZzcKT UXhR8+2zQ3Ks+vZlLlcQ3N6hl5u+hZ1Pcy31Knj4xhZ3VIYzQmfthM4NQlGBeQU7uFib 5olw==
X-Gm-Message-State: ALoCoQnCuBVcr6EkjEM4MYN8cSB9IG2eG/yBuT9wg3a6KxT8PtXN6RnZxoOpwZ/e/gq6W3bpZ0WO
X-Received: by 10.180.184.36 with SMTP id er4mr35341332wic.37.1404731818394; Mon, 07 Jul 2014 04:16:58 -0700 (PDT)
Received: from [192.168.1.23] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id pj4sm51792760wic.12.2014.07.07.04.16.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 04:16:57 -0700 (PDT)
Message-ID: <53BA81A3.8090108@jitsi.org>
Date: Mon, 07 Jul 2014 13:16:51 +0200
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Paul Kyzivat , mmusic@ietf.org,  Eric Rescorla 
References:   <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu>
In-Reply-To: <53B713FC.5010507@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EKhzZo9pF3qmwY_CaACMaeICl8k
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 11:17:04 -0000

Hey Eric, all,

 From what I've seen here, it sounds as if using port 9 on multiple m= 
lines still sounds like a reasonable thing to do.

Does that mean that jsep would be adjusted to relax that requirement and 
only apply it in cases where it is still unclear what the remote side 
supports?

Emil

On 04.07.14, 22:52, Paul Kyzivat wrote:
> On 7/4/14 4:11 AM, Harald Alvestrand wrote:
>> On 07/03/2014 01:36 AM, Martin Thomson wrote:
>>> On 2 July 2014 16:22, Eric Rescorla  wrote:
>>>> However, JSEP explicitly requires that we use distinct ports for
>>>> each m= line:
>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1
>>>>
>>>> Obviously 9 is equal to itself, so this isn't going to work.
>>> I'm not sure that this is actually a problem, unless I've missed
>>> something.
>>>
>>> The reason for having different ports is to make it clear that the m=
>>> section will have distinct transport endpoints and can be unbungled if
>>> the answerer wants that.  But the presence (or absence) of
>>> a=bungle-only is sufficient to distinguish those m= sections.
>
> It isn't sufficient in the first offer, before you know if the other
> side supports it. If not, then you don't want the media to happen at
> all. The port=9 will ensure that, just as port=0 would.
>
> But the answerer that doesn't understand bundle-only may also be
> disturbed by finding multiple port 9's. (If it gave any thought to the
> matter it wouldn't, but by the letter of the law it is incorrect.
>
>> Requiring multiple port 9s is silly. BUNDLE should not require this.
>>
>> If I remember rightly, port 9 started out with TCP candidates where the
>> transport can only be established as an outgoing call.
>>
>> BUNDLE should say "MUST be unique, unless they're the discard port (port
>> 9)".
>
> Certainly you should be able to use unique-ports. But then you might as
> well not bother with bundle-only, since you need to allocate the ports.
>
>      Thanks,
>      Paul
>
>>>> Also, JSEP uses the term "null" for these ports. We propose that
>>>> instead we use the term "dummy".
>>> WFM.
>>>
>>> _______________________________________________
>>> 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 nobody Mon Jul  7 04:25:50 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3B1B2815 for ; Mon,  7 Jul 2014 04:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3_yUoSQZLVD for ; Mon,  7 Jul 2014 04:25:47 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEF21A03AD for ; Mon,  7 Jul 2014 04:25:46 -0700 (PDT)
X-AuditID: c1b4fb3a-f799e6d000005085-9e-53ba83b81047
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.61.20613.8B38AB35; Mon,  7 Jul 2014 13:25:44 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Jul 2014 13:25: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 6C2D1110294; Mon,  7 Jul 2014 14:25:43 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 073F558816;	Mon,  7 Jul 2014 14:26:28 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A3F3358815;	Mon,  7 Jul 2014 14:26:27 +0300 (EEST)
Message-ID: <53BA83B5.6050206@ericsson.com>
Date: Mon, 7 Jul 2014 14:25:41 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
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+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6O5l3BBpdeaFmsPX6T0WLq8scs DkweS5b8ZPI4fvo6awBTFJdNSmpOZllqkb5dAlfGhqsdjAVH2SpmbJ3O0sC4n7WLkZNDQsBE YsHhy0wQtpjEhXvr2boYuTiEBI4ySpxa28UC4axnlHj//g8jhLOXUWLD0dNQzjpGiQXntkM5 Kxgl9h+8xgYyjFdAW+LBnLMsIDaLgIrEol0XwWw2AXuJmxOus4PYogLJEtPPr2WHqBeUODnz CViNiICMxN5Nm5m7GDk4mAUMJbYdjwcJCwvoSTzt2AZWwixgK3FhznUoW15i+9s5zBA/qElc PbcJzBYSUJW4+u8V4wRG4VlINsxC0j4LSfsCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWb GIFBfnDLb6sdjAefOx5iFOBgVOLhfXBsZ7AQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamBcKpTgd3KR/b4Hczdm1+irPOe6ez/sTm9Bst+MQ9x/K6N99ZbZ VR16Jlj+JKjwd4LHhrt9i6rehkr0TklsZK1d9vXJp/srw9YeYrknWyxSfX/ZJuZl7w8/irE+ E8W5PutPh9nkWqcZFfZC2dvvRTHd9GNSeeF14fPapwF6p2JYRGPvah1LzjmoxFKckWioxVxU nAgAzObAp1MCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/H1SBuqq2NeP2MXw4Zawla4DQ7v8
Cc: Marc Petit-Huguenin 
Subject: [MMUSIC] Updates to ICE bis and ICE SIP drafts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 11:25:48 -0000

Hi all,

We have updated the ICE bis and ICE SIP drafts to address (most of) the 
issues discussed during and after the previous meeting. That is:

* connectivity check pacing negotiation

* extension-att-name and -value to use token and *VCHAR instead of 
byte-strings

* allowing to use invalid (all-zeros) address and zero port for related 
address of TURN candidates for privacy reasons

* clarifying use of candidate priorities when using multiple TURN servers

Here are the latest versions and diffs; comments welcome:

ICE bis:
http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-02
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc5245bis-02

ICE SIP:
http://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-03
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-03


Cheers,
Ari


From nobody Mon Jul  7 07:02:31 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69D1A00FE for ; Mon,  7 Jul 2014 07:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OhWyJuvOAu5 for ; Mon,  7 Jul 2014 07:02:28 -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 47BD71A011C for ; Mon,  7 Jul 2014 07:02:28 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta04.westchester.pa.mail.comcast.net with comcast id PRpS1o0020bG4ec54S2T3l; Mon, 07 Jul 2014 14:02:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id PS2T1o00S3ZTu2S3PS2Tp3; Mon, 07 Jul 2014 14:02:27 +0000
Message-ID: <53BAA873.6050907@alum.mit.edu>
Date: Mon, 07 Jul 2014 10:02:27 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" 
References:  <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.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=q20140121; t=1404741747; bh=O5auDimovej4fH8QMv+yro+kARZieRYA0vkjNoxvOXE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gwaJUX2HJAp+2jK4XZLrWhBbthgvkUaeqk9ZBaUdhJuVY1Y3RVi8gRjxHI+Ss9hE/ TgXaTJmTF0bz/ZYCaFUf9MsmF4H0TsevcX+6/xVrqxUa4shCLBlPkME/vzJLqpRBC0 ZB9BpVthg8LuNeON19LTjFU1y+bbsq1J70GCXkjEBDrT6PosZ70dUxPuAg14+N262P IEHDcHsQ8p0oU4gwNNMs7Uh1UHQ4ZMaCj97GcJlL2NRPNM9OMkpMUXS3vhJM8u3fQc IjHFlSvDN2dCcGuFti2SMpcgmRlMF5AMnRC+x1lbtVwy6ElgKo33X4Au8tw1k/UBmV lCq85bgB3uF3A==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XY_aHZZevWiEzqtO-0egdpigsgA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 4566bis outstanding issues
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 14:02:29 -0000

On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
> Hi Paul,
>
> OK, no one else seems to be paying attention to this. I have some comments inline and lets see whether we can reach an agreement:

OK.

I've trimmed to a few points to comment on...

>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:

>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined.
>>>> Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this.
>>>
>>> IIRC the argument against doing this is that we might get it wrong.
>>>
>>> But IMO we should do it because if we can't get it right how can we expect readers to get it right?
>
> I personally don't wanna take on this task. It is a tedious task and I am not such an ABNF lover to get these definitions right. If you wanna volunteer, by all means, please do so.

I'm willing to contribute to this, but won't have time until after the 
Toronto meeting. Also, I'm not intimately familiar with all of the 
attributes.

I think I could probably produce a credible proposal for an ABNF 
description all of the attributes currently defined within 4566. This 
would then need to be carefully reviewed.

> Also, dozens of attributes have been defined since 4566 w/o issues so I am not seeing this as a high priority issue (or an issue at all).

Like many things, the ones defined more recently tend to be more 
rigorous than those defined longer ago. But it is uneven, and tends to 
depend upon who does it and (lately) who from the SDP directorate 
reviewed it.

>>> There is an ongoing problem when SDP extensions are defined - lack of a consistent format for defining new attributes. Many people look to 4566 for examples of how to do this, but it provides bad examples.
>>>
>>> IMO 4566bis should show the definition of all attributes in a style that complies with a recommended format for defining attributes.
>>>
>>> (Of course that implies that we could agree on such a format.)
>
> OK, this goes back to the issue #1. Personally, I suggest we do not define the abnfs for every sdp attribute in 4566, but then you have a good point. We can seek a format and provide a few good examples to show prospective authors.
>
> To do this, obviously as you said, we need to agree on that format. Has there been a proposal in the past or does anyone have a good proposal to start with?

Not a formal one. There has been some discussion about this during 
review of individual attribute definitions. My take has been that there 
is not agreement.

One question is whether the definition of a new attribute should:
1) define the full syntax of the line (starting with "a="),
2) should provide additional definitions of  (via "/=")
3) should provide additional definitions of  and 
    (via "/=")
4) provide definitions of the name and value that are consistent with
     and  without formally extending the
    definitions of those.

Note that 4566 loosely follows (4) but gives the definitions informally 
rather than via ABNF. So it gives no guidance on how to use ABNF for 
this. A number of drafts have chosen to follow (2). Some have started to 
do (1) but I don't know of any that ended up that way.

A question I have raised is: if (2) or (3) is followed, does that mean 
that the draft doing so must be considered as "updating" 4566?

One thing that people sometimes forget when defining new attributes is 
that the syntax of the new attribute MUST also be valid when parsed by 
the "generic" attribute syntax. AFAIK there is no way in ABNF to specify 
that. I think that (4) comes closest.

	Thanks,
	Paul


From nobody Mon Jul  7 09:16:17 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753CF1A0365 for ; Mon,  7 Jul 2014 09:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQsy4PFJk4YY for ; Mon,  7 Jul 2014 09:16:10 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60F11A035A for ; Mon,  7 Jul 2014 09:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4471; q=dns/txt; s=iport; t=1404749769; x=1405959369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4auIsdHxuAwyHpRTX5+nJJbsRlnQrs/dcFtsoCpURK0=; b=GVMHs6w1bvfugQbnGI+FyvvkhhjHxRHYt8n95beAj9JemwFzy2KK9JLS pUIm15dMsn4xSA14HXghbsHhE+vr1clkxn2YyqD4eARWpAtg1p7kPP9aK JhQkrnFE38Ktl/3GgBGw6IXQef0gEo0TeS/XQc/QjiQNBr9b1AeMXQyHG 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAFTHulOtJA2F/2dsb2JhbABaDoJcJIEsxjsBgRcWdYQDAQEBAwF5BQsCAQgOCi4yJQEBBA4FiDoIAcoSF45OITMHgy2BFgWKF5BflAyDAUKCMA
X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="338254562"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jul 2014 16:16:09 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s67GG9cg030819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 16:16:09 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 11:16:09 -0500
From: "Ali C. Begen (abegen)" 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] 4566bis outstanding issues
Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IAEqYhwgAAMaTqAAASrOQA=
Date: Mon, 7 Jul 2014 16:16:08 +0000
Message-ID: 
References:  <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com>  <53BAA873.6050907@alum.mit.edu>
In-Reply-To: <53BAA873.6050907@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.247.95]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7CAD44A4CE59844CB84FEA3C70299BBF@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BDZzYebAbx2ob2JZDf2XoiyDYtc
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 4566bis outstanding issues
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 16:16:12 -0000

On Jul 7, 2014, at 11:02 PM, Paul Kyzivat  wrote:

> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
>> Hi Paul,
>>=20
>> OK, no one else seems to be paying attention to this. I have some commen=
ts inline and lets see whether we can reach an agreement:
>=20
> OK.
>=20
> I've trimmed to a few points to comment on...
>=20
>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:
>=20
>>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 456=
6 defined.
>>>>> Comments: This was discussed again in a side meeting in London and th=
ere was not a consensus whether we actually needed this.
>>>>=20
>>>> IIRC the argument against doing this is that we might get it wrong.
>>>>=20
>>>> But IMO we should do it because if we can't get it right how can we ex=
pect readers to get it right?
>>=20
>> I personally don't wanna take on this task. It is a tedious task and I a=
m not such an ABNF lover to get these definitions right. If you wanna volun=
teer, by all means, please do so.
>=20
> I'm willing to contribute to this, but won't have time until after the To=
ronto meeting.

That is fine.

> Also, I'm not intimately familiar with all of the attributes.

Nobody is I am afraid.

>=20
> I think I could probably produce a credible proposal for an ABNF descript=
ion all of the attributes currently defined within 4566. This would then ne=
ed to be carefully reviewed.

Thanks for volunteering.

>=20
>> Also, dozens of attributes have been defined since 4566 w/o issues so I =
am not seeing this as a high priority issue (or an issue at all).
>=20
> Like many things, the ones defined more recently tend to be more rigorous=
 than those defined longer ago. But it is uneven, and tends to depend upon =
who does it and (lately) who from the SDP directorate reviewed it.
>=20
>>>> There is an ongoing problem when SDP extensions are defined - lack of =
a consistent format for defining new attributes. Many people look to 4566 f=
or examples of how to do this, but it provides bad examples.
>>>>=20
>>>> IMO 4566bis should show the definition of all attributes in a style th=
at complies with a recommended format for defining attributes.
>>>>=20
>>>> (Of course that implies that we could agree on such a format.)
>>=20
>> OK, this goes back to the issue #1. Personally, I suggest we do not defi=
ne the abnfs for every sdp attribute in 4566, but then you have a good poin=
t. We can seek a format and provide a few good examples to show prospective=
 authors.
>>=20
>> To do this, obviously as you said, we need to agree on that format. Has =
there been a proposal in the past or does anyone have a good proposal to st=
art with?
>=20
> Not a formal one. There has been some discussion about this during review=
 of individual attribute definitions. My take has been that there is not ag=
reement.

If you can recall, can you point us to that proposal and maybe briefly expl=
ain the disagreements as well?

>=20
> One question is whether the definition of a new attribute should:
> 1) define the full syntax of the line (starting with "a=3D"),
> 2) should provide additional definitions of  (via "/=3D")
> 3) should provide additional definitions of  and 
>   (via "/=3D")
> 4) provide definitions of the name and value that are consistent with
>    and  without formally extending the
>   definitions of those.
>=20
> Note that 4566 loosely follows (4) but gives the definitions informally r=
ather than via ABNF. So it gives no guidance on how to use ABNF for this. A=
 number of drafts have chosen to follow (2). Some have started to do (1) bu=
t I don't know of any that ended up that way.
>=20
> A question I have raised is: if (2) or (3) is followed, does that mean th=
at the draft doing so must be considered as "updating" 4566?

I dont see why it should. Personally most of the attributes I defined follo=
wed (4). That seemed the easiest option.=20

>=20
> One thing that people sometimes forget when defining new attributes is th=
at the syntax of the new attribute MUST also be valid when parsed by the "g=
eneric" attribute syntax. AFAIK there is no way in ABNF to specify that. I =
think that (4) comes closest.

Yes, but this must be checked during the last call by actual humans not som=
e abnf parser.=20

-acbegen

>=20
> 	Thanks,
> 	Paul
>=20


From nobody Mon Jul  7 10:32:20 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8D1A04D2 for ; Mon,  7 Jul 2014 10:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OApDh2huunuI for ; Mon,  7 Jul 2014 10:32: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 7C5DD1A040D for ; Mon,  7 Jul 2014 10:32:17 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id PSSB1o00427AodY5FVYHev; Mon, 07 Jul 2014 17:32:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id PVYG1o00M3ZTu2S3fVYGM7; Mon, 07 Jul 2014 17:32:17 +0000
Message-ID: <53BAD9A0.6060304@alum.mit.edu>
Date: Mon, 07 Jul 2014 13:32:16 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References:  <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com>  <53BAA873.6050907@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=q20140121; t=1404754337; bh=WC1R4DWlMsxDf4D65Hrj+/rucnSYxvV7Mjb2cVCf5iU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XNHJYyKQ1el25eBYkWbwkUoLlH5dX/9XY26SnNUEBW148Mn62CNhC2E1r+q5iKQ4D OEzS57u6XPsW4wXRD55LH9ayS20t1ZDGsA7Gv72aVg6chK3NJLO1dif5/KeGRpeKNI DhpJl/YjzTOddh/D2c6Sao4Sjwb2C2JFGlQltsIXROlohYjRt/oxQS/ZtaqFBpMRz7 F7NBz25HHNEKpmr5yyf63oOcSExGm+du3KzT/ebnBmta7z5bV/PekFqFuxp58YGqf4 l1JFsO5vCUY15BBvIQ0W+IfIH2QnuU7jNKptZ4+a4IK4EgYZYmBPbflLlXOXFq2Tpr lLyt0ArTW+CoQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fhMRz6EHSyvX84Isu5IG9WhC4XU
Subject: Re: [MMUSIC] 4566bis outstanding issues
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 17:32:18 -0000

Trimming again.

On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote:
>
> On Jul 7, 2014, at 11:02 PM, Paul Kyzivat  wrote:
>
>> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
>>> Hi Paul,
>>>
>>> OK, no one else seems to be paying attention to this. I have some comments inline and lets see whether we can reach an agreement:
>>
>> OK.
>>
>> I've trimmed to a few points to comment on...
>>
>>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:
>>
>>>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined.
>>>>>> Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this.
>>>>>
>>>>> IIRC the argument against doing this is that we might get it wrong.
>>>>>
>>>>> But IMO we should do it because if we can't get it right how can we expect readers to get it right?
>>>
>>> I personally don't wanna take on this task. It is a tedious task and I am not such an ABNF lover to get these definitions right. If you wanna volunteer, by all means, please do so.
>>
>> I'm willing to contribute to this, but won't have time until after the Toronto meeting.
>
> That is fine.
>
>> Also, I'm not intimately familiar with all of the attributes.
>
> Nobody is I am afraid.

There are a lots of people who at least *use* them, and so are familiar 
with them at that level. I don't "do" media, so when I'm trying to 
create examples I can get as far as "m=audio", and I know there should 
be an "a=rtpmap", but beyond that I need to find an example to copy.

>>> OK, this goes back to the issue #1. Personally, I suggest we do not define the abnfs for every sdp attribute in 4566, but then you have a good point. We can seek a format and provide a few good examples to show prospective authors.
>>>
>>> To do this, obviously as you said, we need to agree on that format. Has there been a proposal in the past or does anyone have a good proposal to start with?
>>
>> Not a formal one. There has been some discussion about this during review of individual attribute definitions. My take has been that there is not agreement.
>
> If you can recall, can you point us to that proposal and maybe briefly explain the disagreements as well?

I think it will take a lot of searching to find it. So I can't do so 
quickly/easily.

>> One question is whether the definition of a new attribute should:
>> 1) define the full syntax of the line (starting with "a="),
>> 2) should provide additional definitions of  (via "/=")
>> 3) should provide additional definitions of  and 
>>    (via "/=")
>> 4) provide definitions of the name and value that are consistent with
>>     and  without formally extending the
>>    definitions of those.
>>
>> Note that 4566 loosely follows (4) but gives the definitions informally rather than via ABNF. So it gives no guidance on how to use ABNF for this. A number of drafts have chosen to follow (2). Some have started to do (1) but I don't know of any that ended up that way.
>>
>> A question I have raised is: if (2) or (3) is followed, does that mean that the draft doing so must be considered as "updating" 4566?
>
> I dont see why it should. Personally most of the attributes I defined followed (4). That seemed the easiest option.

I've been outnumbered on the discussions of this. ISTM that whenever I write

	attribute =/ something new

then I have at least extended the rfc that defines  and 
arguably have updated it. The reason it might be considered an update is 
that what I am defining implicitly includes the definition of 
 and thus probably all the abnf that includes the definition 
of . To verify my new abnf, or to generate a parser, I need 
to create a combined abnf. And abnf doesn't have namespaces. So all the 
rulenames I newly define must be distinct from those defined with 
.

And that is true for *every* extension. And for them to be compatible 
with one another they all must define rulenames that are unique among 
them all.

So effectively each one is an update.

It is subtly different if I follow (4), even if I use abnf to define the 
syntax for my new attribute, and even if I reuse rule definitions (like 
) from the base sdp definition.

>> One thing that people sometimes forget when defining new attributes is that the syntax of the new attribute MUST also be valid when parsed by the "generic" attribute syntax. AFAIK there is no way in ABNF to specify that. I think that (4) comes closest.
>
> Yes, but this must be checked during the last call by actual humans not some abnf parser.

For now that is true. I have found such errors while doing SDP 
directorate reviews.

	Thanks,
	Paul

> -acbegen
>
>>
>> 	Thanks,
>> 	Paul
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Mon Jul  7 14:31:02 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA61B28E1 for ; Mon,  7 Jul 2014 14:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeBqsg22Njfh for ; Mon,  7 Jul 2014 14:31:00 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560981B2942 for ; Mon,  7 Jul 2014 14:30:58 -0700 (PDT)
X-AuditID: c1b4fb30-f79da6d000006b80-68-53bb1190cbdd
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7D.6A.27520.0911BB35; Mon,  7 Jul 2014 23:30:56 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Jul 2014 23:30:56 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 3E0DC110295; Tue,  8 Jul 2014 00:30:56 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6754F5266A;	Tue,  8 Jul 2014 00:31:41 +0300 (EEST)
Received: from As-MacBook-Air.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0D96252144;	Tue,  8 Jul 2014 00:31:41 +0300 (EEST)
Message-ID: <53BB118F.3070505@ericsson.com>
Date: Tue, 8 Jul 2014 00:30:55 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
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+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvje4Ewd3BBr9X61u8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+PkoceMBX8YK+Y1n2RpYDzF2MXIwSEhYCKx Y6ZOFyMnkCkmceHeerYuRi4OIYGjjBLTH39iB0kICaxnlFj4UQEisZdR4tmVqYwQzjpGiQld +6CqVjBKrPmdC2LzCmhLLH75jAlkA4uAisTeV3ogYTYBe4mbE66DlYsKJEus2TqJHaJcUOLk zCcsILaIgIzE3k2bmUFsZqAxs+/MYgKxhQU0JFZ9XMoIEbeVuDDnOguELS+x/e0cZogP1CSu ntvEDHGOqsTVf68YJzAKz0KyYhaS9llI2hcwMq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnE CAzug1t+G+xgfPnc8RCjAAejEg+vwoNdwUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgbH2/7O5n7V/8cx7XZn1b9ourilsXNJzXdwi9r13exX75V23n8D5 l9MtI59Zte5jUFrdOv12Z2+l396bd5a8tFXw3Pzr5dzjF8R5DS1lN7x7tjmvNmfS3zlyPTbL 93Cc4usz32/DYLKzhddLc9r7MkWtPbq9rzgSYq9P1V90OeCC6wk551ax3/uUWIozEg21mIuK EwFkemEwTwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fx3daBci-a1gDc6rwSCSZNKCZTs
Cc: Flemming Andreasen 
Subject: [MMUSIC] MMUSIC draft agenda for IETF 90
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jul 2014 21:31:01 -0000

Hi all,

Draft agenda for the MMUSIC meeting at the IETF 90 is now available here:
http://www.ietf.org/proceedings/90/agenda/agenda-90-mmusic

Please have a look and let us know if you have any questions or comments.


Thanks,
Ari & Flemming


From nobody Tue Jul  8 07:14:24 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691041B27AC for ; Tue,  8 Jul 2014 07:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K6pLQVckFF1 for ; Tue,  8 Jul 2014 07:14:22 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BD31B2ADB for ; Tue,  8 Jul 2014 07:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2287; q=dns/txt; s=iport; t=1404828862; x=1406038462; h=message-id:date:from:mime-version:to:cc:subject; bh=80u7qqb6TY1jinsgwisOjmjZAHWTzo91tJKubdil8YQ=; b=CDZnD+vmrydgryi3wDsgsYZ4NhQeEx2MnIUrTEXLautOH/yQfXV902ek 8VfZTSESfuN2ARZJx8s1xX9Kk2kX7RujZRXdA41Nn+idx7XIQiV49B+Jp wOU4UH5kwq6Si6euk1xjKvXce1WpiuGW5KaBS0+WqOhgVZjcmJsEw48Ja c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AukKAEb8u1OtJV2S/2dsb2JhbABZgw5SrE0BAQEBAQEFAQVpAZIYh0GBFhZ1hCdRCgEfARwWGAMCAQIBSw0BBwEBiD4NyTIXhXqJSIRKBZp2gUiFR4x9g18h
X-IronPort-AV: E=Sophos; i="5.01,625,1400025600"; d="scan'208,217"; a="59140335"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 08 Jul 2014 14:14:21 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s68EEKIG003665; Tue, 8 Jul 2014 14:14:20 GMT
Message-ID: <53BBFCBC.7020707@cisco.com>
Date: Tue, 08 Jul 2014 10:14:20 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic 
Content-Type: multipart/alternative; boundary="------------020506040001070308030800"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1a9Zw8vpzRhLGgDBzIycrhARbxI
Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org, "mmusic-chairs@tools.ietf.org" 
Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 14:14:23 -0000

This is a multi-part message in MIME format.
--------------020506040001070308030800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greetings,

We have an MMUSIC milestone for "SIP usage for Trickle ICE", and at the 
IETF 89 meeting we had a call for adoption of the Trickle ICE SIP draft 
as a WG document. There was a strong consensus in favor of adopting the 
document. After the meeting there were a few comments on the document, 
which were discussed on the MMUSIC mailing list and resulted in an 
updated version of the document:

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02

At this point, the chairs would like to confirm adopting the updated 
draft as a WG document. If you have any concerns regarding the adoption, 
please let us know no later than Friday, July 18th, 2014.

Thanks,

     Ari & Flemming (MMUSIC chairs)

--------------020506040001070308030800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Greetings,

    

    We have an MMUSIC milestone for
    
    "SIP usage for Trickle ICE", and at the IETF 89 meeting we had a
    call for adoption of the Trickle ICE SIP draft as a WG document.
    There was a strong consensus in favor of adopting the document.
    After the meeting there were a few comments on the document, which
    were discussed on the MMUSIC mailing list and resulted in an updated
    version of the document:
    

    

    http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02
    

    

    At this point, the chairs would like to confirm adopting the updated
    draft as a WG document. If you have any concerns regarding the
    adoption, please let us know no later than Friday, July 18th, 2014.
    

    

    Thanks,
    

    

        Ari & Flemming (MMUSIC chairs)
  


--------------020506040001070308030800--


From nobody Wed Jul  9 05:46:59 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF911A04F6 for ; Wed,  9 Jul 2014 05:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qZ7-JY64Aen for ; Wed,  9 Jul 2014 05:46:07 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0596A1A04D2 for ; Wed,  9 Jul 2014 05:46:07 -0700 (PDT)
Received: from localhost ([::1]:35543 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rFw-0008OK-78; Wed, 09 Jul 2014 05:45:52 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:45:52 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/14
Message-ID: <057.fd5b9191f403d6ede7290dc1d8ab94d1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 14
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vhY1zU9StsW2QYcDslYPB3uw8eM
X-Mailman-Approved-At: Wed, 09 Jul 2014 05:46:50 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #14 (rfc4566bis): 4566bis: Need to provide ABNF syntax for all 4566 attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:46:08 -0000

#14: 4566bis: Need to provide ABNF syntax for all 4566 attributes

 Comments: This was discussed again in a side meeting in London and there
 was not a consensus whether we actually needed this.

 Paul K: IIRC the argument against doing this is that we might get it
 wrong. But IMO we should do it because if we can't get it right how can we
 expect readers to get it right?

 Paul K: I'm willing to contribute to this, but won't have time until after
 the Toronto meeting. Also, I'm not intimately familiar with all of the
 attributes. I think I could probably produce a credible proposal for an
 ABNF description all of the attributes currently defined within 4566. This
 would then need to be carefully reviewed.

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  enhancement   |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:47:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214401A0538 for ; Wed,  9 Jul 2014 05:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkS9LvC_qGPX for ; Wed,  9 Jul 2014 05:47:38 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BFB1A0527 for ; Wed,  9 Jul 2014 05:47:38 -0700 (PDT)
Received: from localhost ([::1]:35599 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rHc-0002ui-1a; Wed, 09 Jul 2014 05:47:36 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:47:36 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/15
Message-ID: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 15
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RbFXmdY1UULuSvulLa4yzp_90xI
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #15 (rfc4566bis): 4566bis: Update the format of the IANA registries to reflect the dependency between addrtype and net type.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:47:40 -0000

#15: 4566bis: Update the format of the IANA registries to reflect the dependency
between addrtype and net type.

 Comments: There does not seem an agreement on this but it looks to be an
 easy fix.

 @Chairs,

 Is this (and all other IANA related issues) supposed to be part of the
 4566bis document or a separate document? A separate document may keep
 4566bis clean and nice.

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  defect        |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:49:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CA31A0527 for ; Wed,  9 Jul 2014 05:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjXqd2Szira5 for ; Wed,  9 Jul 2014 05:49:02 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7655E1A03EF for ; Wed,  9 Jul 2014 05:49:02 -0700 (PDT)
Received: from localhost ([::1]:35629 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rIy-00068K-3x; Wed, 09 Jul 2014 05:49:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:49:00 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/16
Message-ID: <057.9bfd39ad29d72d9028ea7907a8536817@trac.tools.ietf.org>
X-Trac-Ticket-ID: 16
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-HQ_2gAwTXcu64jkyep5vErVy2M
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #16 (rfc4566bis): 4566bis: Section 8.2.4 defines the IANA registry and populates it with the attributes defined in 4566, however, Section 8.2.4 does not specify the name or format of the table.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:49:03 -0000

#16: 4566bis: Section 8.2.4 defines the IANA registry and populates it with the
attributes defined in 4566, however, Section 8.2.4 does not specify the
name or format of the table.

 This will be fixed.

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  defect        |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:50:49 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70671A0535 for ; Wed,  9 Jul 2014 05:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSnnI6zakctQ for ; Wed,  9 Jul 2014 05:50:41 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BFE1A0546 for ; Wed,  9 Jul 2014 05:50:40 -0700 (PDT)
Received: from localhost ([::1]:35717 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rKY-0001Qv-21; Wed, 09 Jul 2014 05:50:38 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:50:38 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/17
Message-ID: <057.29493d7a93b31d297f43badc9385c7cf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 17
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mrKwADVDUJsETmdvr4sTdTbbdog
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #17 (rfc4566bis): 4566bis: Make the registration of new network or address types mandatory (Sections 8.2.6 and 8.2.7)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:50:43 -0000

#17: 4566bis: Make the registration of new network or address types mandatory
(Sections 8.2.6 and 8.2.7)

 This should be fixed.

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  defect        |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:52:11 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D21A053B for ; Wed,  9 Jul 2014 05:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrvcurdVbwG2 for ; Wed,  9 Jul 2014 05:52:07 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50251A0538 for ; Wed,  9 Jul 2014 05:52:07 -0700 (PDT)
Received: from localhost ([::1]:35767 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rLw-0001wz-VZ; Wed, 09 Jul 2014 05:52:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:52:04 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/18
Message-ID: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 18
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3bhNU8KK2Z8-XOgQsao_wlbMZwk
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #18 (rfc4566bis): 4566bis: Should the source-level attributes defined in 5576 be included in the same table structure in the IANA registry?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:52:09 -0000

#18: 4566bis: Should the source-level attributes defined in 5576 be included in
the same table structure in the IANA registry?

 Comments: This seems to be an organizational issue rather than a technical
 issue. If we agree we need this, we can take on this as well.

 Paul K.: Yes, but IMO an important one. The current registries are hard to
 read, and easy to get wrong when adding new attributes. Also, we ought to
 have templates for what goes into the IANA consideration section when
 defining new attributes, and that template would be best in this document.

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  enhancement   |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:53:20 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA481A053B for ; Wed,  9 Jul 2014 05:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeHl0CHnMelH for ; Wed,  9 Jul 2014 05:53:15 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA321A0538 for ; Wed,  9 Jul 2014 05:53:15 -0700 (PDT)
Received: from localhost ([::1]:35792 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rN2-00025c-BQ; Wed, 09 Jul 2014 05:53:12 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:53:12 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/19
Message-ID: <057.9b3ba397834dc7dffceba720d1463edf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 19
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/pJ-OBceUsO5CDoPAt9_RFUlk5T4
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #19 (rfc4566bis): 4566bis: Should we add a new column called "registered network type" in the addrtype table in the IANA registry as not all address types are applicable for all network types?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:53:16 -0000

#19: 4566bis: Should we add a new column called "registered network type" in the
addrtype table in the IANA registry as not all address types are applicable
for all network types?

 Comments: This is also an IANA fix that we can do in this bis document or
 in a separate document (with all the other IANA registry changes).

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  defect        |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:58:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5940B1A053B for ; Wed,  9 Jul 2014 05:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o4jOpTmr8Fr for ; Wed,  9 Jul 2014 05:58:03 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5400C1A063B for ; Wed,  9 Jul 2014 05:58:00 -0700 (PDT)
Received: from localhost ([::1]:35901 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rRd-0002wB-D8; Wed, 09 Jul 2014 05:57:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:57:57 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/20
Message-ID: <057.3b838e4d829c5715eff10acf0456626c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 20
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: abegen@cisco.com, csp@csperkins.org, m.handley@cs.ucl.ac.uk, van@parc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-Ps2_CWR0mc7vCtH-LZZAEwWZT0
Cc: mmusic@ietf.org
Subject: [MMUSIC] [mmusic] #20 (rfc4566bis): 4566bis: Lack of a consistent format for defining new attributes.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:58:04 -0000

#20: 4566bis: Lack of a consistent format for defining new attributes.

 Paul K.: Many people look to 4566 for examples of how to do this, but it
 provides bad examples. IMO 4566bis should show the definition of all
 attributes in a style that complies with a recommended format for defining
 attributes. (Of course that implies that we could agree on such a format.)

 From http://www.ietf.org/mail-archive/web/mmusic/current/msg13471.html

 One question is whether the definition of a new attribute should:
 1) define the full syntax of the line (starting with "a="),
 2) should provide additional definitions of  (via "/=")
 3) should provide additional definitions of  and 
   (via "/=")
 4) provide definitions of the name and value that are consistent with
    and  without formally extending the
   definitions of those.

 Note that 4566 loosely follows (4) but gives the definitions informally
 rather than via ABNF. So it gives no guidance on how to use ABNF for this.
 A number of drafts have chosen to follow (2). Some have started to do (1)
 but I don't know of any that ended up that way.

 A question I have raised is: if (2) or (3) is followed, does that mean
 that the draft doing so must be considered as "updating" 4566?

 One thing that people sometimes forget when defining new attributes is
 that the syntax of the new attribute MUST also be valid when parsed by the
 "generic" attribute syntax. AFAIK there is no way in ABNF to specify that.
 I think that (4) comes closest.

-- 
-------------------------+-------------------------------------------------
Reporter:                |      Owner:  draft-ietf-mmusic-
  abegen@cisco.com       |  rfc4566bis@tools.ietf.org
    Type:  enhancement   |     Status:  new
Priority:  major         |  Component:  rfc4566bis
 Version:                |   Severity:  Active WG Document
Keywords:                |
-------------------------+-------------------------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:59:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995921A03EF for ; Wed,  9 Jul 2014 05:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch39vaAj_447 for ; Wed,  9 Jul 2014 05:59:07 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0ACC1A03A4 for ; Wed,  9 Jul 2014 05:59:06 -0700 (PDT)
Received: from localhost ([::1]:35934 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rSk-0003QO-QS; Wed, 09 Jul 2014 05:59:06 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:59:06 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/13#comment:1
Message-ID: <072.a16d79f02c14f527df9e9319f3ad88bd@trac.tools.ietf.org>
References: <057.623779feec9bfa672fc3218eb4ffb595@trac.tools.ietf.org>
X-Trac-Ticket-ID: 13
In-Reply-To: <057.623779feec9bfa672fc3218eb4ffb595@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CMzqJjL-IO5Sc598txNzuvg237w
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #13 (rfc4566bis): This is a test ticket for 4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:59:11 -0000

#13: This is a test ticket for 4566bis

Changes (by abegen@cisco.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  defect            |     Status:  closed
  Priority:  trivial           |  Component:  rfc4566bis
   Version:  2.0               |   Severity:  Active WG Document
Resolution:  fixed             |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 05:59:53 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795CD1A0546 for ; Wed,  9 Jul 2014 05:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP0cn-0GWZsa for ; Wed,  9 Jul 2014 05:59:47 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03171A063A for ; Wed,  9 Jul 2014 05:59:46 -0700 (PDT)
Received: from localhost ([::1]:35958 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rTO-0003WU-Js; Wed, 09 Jul 2014 05:59:46 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 12:59:46 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/14#comment:1
Message-ID: <072.eaa93a52f0ba0a8fe56ce0d39f888a53@trac.tools.ietf.org>
References: <057.fd5b9191f403d6ede7290dc1d8ab94d1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 14
In-Reply-To: <057.fd5b9191f403d6ede7290dc1d8ab94d1@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TDd7S-idkYh53O3LWywmCO48T0c
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #14 (rfc4566bis): 4566bis: Need to provide ABNF syntax for all 4566 attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 12:59:49 -0000

#14: 4566bis: Need to provide ABNF syntax for all 4566 attributes

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  enhancement       |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 06:00:22 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1E1A063D for ; Wed,  9 Jul 2014 06:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znHeu-9cEo8C for ; Wed,  9 Jul 2014 06:00:18 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0AE1A0546 for ; Wed,  9 Jul 2014 06:00:18 -0700 (PDT)
Received: from localhost ([::1]:35989 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rTu-0003n8-Cf; Wed, 09 Jul 2014 06:00:18 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 13:00:18 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/18#comment:1
Message-ID: <072.6e3d25673ad83c5fcdcc80b550dc55b8@trac.tools.ietf.org>
References: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 18
In-Reply-To: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Atpv9h9GGp8Sq4GoxiDI4ssF0pA
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #18 (rfc4566bis): 4566bis: Should the source-level attributes defined in 5576 be included in the same table structure in the IANA registry?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 13:00:20 -0000

#18: 4566bis: Should the source-level attributes defined in 5576 be included in
the same table structure in the IANA registry?

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  enhancement       |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 06:01:05 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A302A1A063A for ; Wed,  9 Jul 2014 06:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv4RHL3RFoH0 for ; Wed,  9 Jul 2014 06:01:02 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0401A061D for ; Wed,  9 Jul 2014 06:01:02 -0700 (PDT)
Received: from localhost ([::1]:36032 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rUc-0004El-9w; Wed, 09 Jul 2014 06:01:02 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 13:01:02 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/20#comment:1
Message-ID: <072.520856909f0ef913b7d87a61cb18c9d8@trac.tools.ietf.org>
References: <057.3b838e4d829c5715eff10acf0456626c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 20
In-Reply-To: <057.3b838e4d829c5715eff10acf0456626c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IFRdSl8lX-VUvMJ4bLRChifPkQM
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #20 (rfc4566bis): 4566bis: Lack of a consistent format for defining new attributes.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 13:01:03 -0000

#20: 4566bis: Lack of a consistent format for defining new attributes.

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  enhancement       |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 06:01:29 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6569A1A063A for ; Wed,  9 Jul 2014 06:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13Tlu-6b2UFv for ; Wed,  9 Jul 2014 06:01:26 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06631A061D for ; Wed,  9 Jul 2014 06:01:25 -0700 (PDT)
Received: from localhost ([::1]:36052 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rUz-0004UA-T9; Wed, 09 Jul 2014 06:01:25 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 13:01:25 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/15#comment:1
Message-ID: <072.0173a03a404ffdc2a433460e66a674b0@trac.tools.ietf.org>
References: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 15
In-Reply-To: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VUctIi1Gp-McgXgEZgPxHS243PY
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #15 (rfc4566bis): 4566bis: Update the format of the IANA registries to reflect the dependency between addrtype and net type.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 13:01:27 -0000

#15: 4566bis: Update the format of the IANA registries to reflect the dependency
between addrtype and net type.

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  defect            |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 06:01:40 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F391A0643 for ; Wed,  9 Jul 2014 06:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5VnoDkRiQPZ for ; Wed,  9 Jul 2014 06:01:36 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7691A063C for ; Wed,  9 Jul 2014 06:01:36 -0700 (PDT)
Received: from localhost ([::1]:36061 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rVA-0004WM-Jq; Wed, 09 Jul 2014 06:01:36 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 13:01:36 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/19#comment:1
Message-ID: <072.428d71483369398928dd6c72c31fbf31@trac.tools.ietf.org>
References: <057.9b3ba397834dc7dffceba720d1463edf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 19
In-Reply-To: <057.9b3ba397834dc7dffceba720d1463edf@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GS_luKVcw8zB1N0KEIXiR5duK5c
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #19 (rfc4566bis): 4566bis: Should we add a new column called "registered network type" in the addrtype table in the IANA registry as not all address types are applicable for all network types?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 13:01:39 -0000

#19: 4566bis: Should we add a new column called "registered network type" in the
addrtype table in the IANA registry as not all address types are applicable
for all network types?

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  defect            |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 06:02:14 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5314E1A0546 for ; Wed,  9 Jul 2014 06:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG1njLU7KyUe for ; Wed,  9 Jul 2014 06:01:50 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D22F1A063B for ; Wed,  9 Jul 2014 06:01:50 -0700 (PDT)
Received: from localhost ([::1]:36077 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rVO-0004Z9-B3; Wed, 09 Jul 2014 06:01:50 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 13:01:50 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/17#comment:1
Message-ID: <072.b8491af8ef99559312a139307a790a56@trac.tools.ietf.org>
References: <057.29493d7a93b31d297f43badc9385c7cf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 17
In-Reply-To: <057.29493d7a93b31d297f43badc9385c7cf@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mHmbeP6qIM1DI70if9AY_WIzB0E
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #17 (rfc4566bis): 4566bis: Make the registration of new network or address types mandatory (Sections 8.2.6 and 8.2.7)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 13:02:07 -0000

#17: 4566bis: Make the registration of new network or address types mandatory
(Sections 8.2.6 and 8.2.7)

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  defect            |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Wed Jul  9 06:02:20 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30D1A0546 for ; Wed,  9 Jul 2014 06:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPuIrmy4J_dz for ; Wed,  9 Jul 2014 06:02:05 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A621A061D for ; Wed,  9 Jul 2014 06:01:58 -0700 (PDT)
Received: from localhost ([::1]:36090 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4rVW-0004la-85; Wed, 09 Jul 2014 06:01:58 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "mmusic issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: abegen@cisco.com
X-Trac-Project: mmusic
Date: Wed, 09 Jul 2014 13:01:58 -0000
X-URL: http://tools.ietf.org/mmusic/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/16#comment:1
Message-ID: <072.e939a3467a01e08ea10ce20d1b37e9c5@trac.tools.ietf.org>
References: <057.9bfd39ad29d72d9028ea7907a8536817@trac.tools.ietf.org>
X-Trac-Ticket-ID: 16
In-Reply-To: <057.9bfd39ad29d72d9028ea7907a8536817@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: abegen@cisco.com, mmusic@ietf.org
X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_ZZkDBc6MFDCdruXUexZBYDSK4M
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #16 (rfc4566bis): 4566bis: Section 8.2.4 defines the IANA registry and populates it with the attributes defined in 4566, however, Section 8.2.4 does not specify the name or format of the table.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 13:02:13 -0000

#16: 4566bis: Section 8.2.4 defines the IANA registry and populates it with the
attributes defined in 4566, however, Section 8.2.4 does not specify the
name or format of the table.

Changes (by abegen@cisco.com):

 * owner:  draft-ietf-mmusic-rfc4566bis@tools.ietf.org => abegen@cisco.com


-- 
-------------------------------+--------------------------------
  Reporter:  abegen@cisco.com  |      Owner:  abegen@cisco.com
      Type:  defect            |     Status:  new
  Priority:  major             |  Component:  rfc4566bis
   Version:                    |   Severity:  Active WG Document
Resolution:                    |   Keywords:
-------------------------------+--------------------------------

Ticket URL: 
mmusic 


From nobody Thu Jul 10 08:10:27 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29BB1A0ABB; Thu, 10 Jul 2014 08:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkMCsJDsUJAi; Thu, 10 Jul 2014 08:10:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BFA1A0AB1; Thu, 10 Jul 2014 08:09:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140710150950.31065.4396.idtracker@ietfa.amsl.com>
Date: Thu, 10 Jul 2014 08:09:50 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LumAU3LJ9wrKBM03Vgrz7EmlLBM
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-22.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Jul 2014 15:10:25 -0000

--NextPart

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

    Title         : A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)
    Author(s)     : J. Goldberg, et al
    Filename      : draft-ietf-mmusic-rtsp-nat
    Pages         : 32 
    Date          : 2014-07-10 
    
   This document defines a solution for Network Address Translation
   (NAT) traversal for datagram based media streams set up and
   controlled with Real-time Streaming Protocol version 2 (RTSP 2.0).
   It uses Interactive Connectivity Establishment (ICE) adapted to use
   RTSP as a signaling channel, defining the necessary RTSP extensions
   and procedures.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-22.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-07-10080950.I-D@ietf.org>


--NextPart--


From nobody Fri Jul 11 09:33:30 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED821B2B55 for ; Fri, 11 Jul 2014 09:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.029
X-Spam-Level: 
X-Spam-Status: No, score=-4.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbUQwSVup2Af for ; Fri, 11 Jul 2014 09:33:25 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E253B1A0385 for ; Fri, 11 Jul 2014 09:33:22 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hy4so2525345vcb.6 for ; Fri, 11 Jul 2014 09:33:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=U+SeOe75rYz24F0yrZ5FnMPbCR1ts4/Q1u8/V4dnbf4=; b=jMyfnILvvcoCKmV6eZ9pBR6M9rwAUHUoPzPYucMi0cdUu4P1ykzByU0U3sewh5bI8A BCKkw9oBNqnO3a/0cy5vr4OvMA27mVIh7zE2qut+t7QY2wtoTm77G0jvgqZuhTUimB/T RDhp0em7PRgNFELSo6j7Cr5EbrA7sFHY8vjRenJr2e6gtr4x+ouUd95uawvy0bAGinoz A80RddENjOT54dh2JzHRKOsg3LZjS9LyVogVzN+iSrcvIHPrr0ob7DlG+w5xX6YWCdOt zjyPFBS4M1heK95uq2y7uaArXaM2Je04qOnlPlSCCiAdC+8FskJtSZ2bwj2j4iZA7nQB 4wQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=U+SeOe75rYz24F0yrZ5FnMPbCR1ts4/Q1u8/V4dnbf4=; b=bZ7u0/Namn+QU0ym/xmXItNn9tEXe2TpojPPirt+uZ1g19oAzQjo3zRAmCfKpEjk4X 5EH/gFKQLoTZbUsJCLBZNcHOslVWeG+VUCAUnHRQrYHtn8280MZKraY4h2jE+HbNoQJc bQG7yogGvTqu3JrA3HaVeBjaKOBaPxbdFSbADXU6CAhcvwbeyBwKipoAaGYwXturSKht DZDYF792dFmEPEclegmsreFv9bnBcKNCICXJHUHtsPkHFtOT2n/1kvltCga8XdYQxHJc h6zagdK5Jbpp/PWxABUlB2di5YeycYI9284FtlRjmbjM8ZRALBGDs8NcNCQd1KPLWYmv oANg==
X-Gm-Message-State: ALoCoQkk4Oc2DqwahhQp9WRJjJ4yt8nwmibvldgAN+QIKkL1+G9PtxHHsbKVAlkUnxlKb2U05qDf
X-Received: by 10.52.7.163 with SMTP id k3mr1904721vda.58.1405096401945; Fri, 11 Jul 2014 09:33:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:33:00 -0700 (PDT)
In-Reply-To: <53BA81A3.8090108@jitsi.org>
References:   <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org>
From: Justin Uberti 
Date: Fri, 11 Jul 2014 09:33:00 -0700
Message-ID: 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=bcaec50164afe9ef6304fded7f66
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Bo0f6pQ1GQ4GoW84BV5o-HlTb3M
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:33:28 -0000

--bcaec50164afe9ef6304fded7f66
Content-Type: text/plain; charset=UTF-8

If I recall correctly, the reason this was an issue was that it was thought
that some equipment would key off the port number, and freak out when
multiple m= lines had the same port number (i.e., 9).

This really has nothing to do with BUNDLE, it can occur in any usage of
trickle ICE, where the initial offer has all 'dummy' ports. However, it
only occurs when doing trickle, so legacy non-trickle gear should not be
affected.

Anyway, the choices here are simple:
a) We require unique 'dummy' ports in the initial trickle offer.
b) We allow use of the same dummy port (9) in the initial trickle offer.
(This is what Chrome does, although it currently uses port 1).

We had been leaning towards (a) based on the legacy equipment case
mentioned above. However, if nobody can provide details on this case, I
agree we should end up with (b).


On Mon, Jul 7, 2014 at 4:16 AM, Emil Ivov  wrote:

> Hey Eric, all,
>
> From what I've seen here, it sounds as if using port 9 on multiple m=
> lines still sounds like a reasonable thing to do.
>
> Does that mean that jsep would be adjusted to relax that requirement and
> only apply it in cases where it is still unclear what the remote side
> supports?
>
> Emil
>
>
> On 04.07.14, 22:52, Paul Kyzivat wrote:
>
>> On 7/4/14 4:11 AM, Harald Alvestrand wrote:
>>
>>> On 07/03/2014 01:36 AM, Martin Thomson wrote:
>>>
>>>> On 2 July 2014 16:22, Eric Rescorla  wrote:
>>>>
>>>>> However, JSEP explicitly requires that we use distinct ports for
>>>>> each m= line:
>>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1
>>>>>
>>>>> Obviously 9 is equal to itself, so this isn't going to work.
>>>>>
>>>> I'm not sure that this is actually a problem, unless I've missed
>>>> something.
>>>>
>>>> The reason for having different ports is to make it clear that the m=
>>>> section will have distinct transport endpoints and can be unbungled if
>>>> the answerer wants that.  But the presence (or absence) of
>>>> a=bungle-only is sufficient to distinguish those m= sections.
>>>>
>>>
>> It isn't sufficient in the first offer, before you know if the other
>> side supports it. If not, then you don't want the media to happen at
>> all. The port=9 will ensure that, just as port=0 would.
>>
>> But the answerer that doesn't understand bundle-only may also be
>> disturbed by finding multiple port 9's. (If it gave any thought to the
>> matter it wouldn't, but by the letter of the law it is incorrect.
>>
>>  Requiring multiple port 9s is silly. BUNDLE should not require this.
>>>
>>> If I remember rightly, port 9 started out with TCP candidates where the
>>> transport can only be established as an outgoing call.
>>>
>>> BUNDLE should say "MUST be unique, unless they're the discard port (port
>>> 9)".
>>>
>>
>> Certainly you should be able to use unique-ports. But then you might as
>> well not bother with bundle-only, since you need to allocate the ports.
>>
>>      Thanks,
>>      Paul
>>
>>  Also, JSEP uses the term "null" for these ports. We propose that
>>>>> instead we use the term "dummy".
>>>>>
>>>> WFM.
>>>>
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--bcaec50164afe9ef6304fded7f66
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


If I recall correctly, the reason this was an issue was th=
at it was thought that some equipment would key off the port number, and fr=
eak out when multiple m=3D lines had the same port number (i.e., 9).=C2=A0<=
div>



This really has nothing to do with BUNDLE, it can occur in any u=
sage of trickle ICE, where the initial offer has all 'dummy' ports.=
 However, it only occurs when doing trickle, so legacy non-trickle gear sho=
uld not be affected.




Anyway, the choices here are simple:
a) We re=
quire unique 'dummy' ports in the initial trickle offer.
=
b) We allow use of the same dummy port (9) in the initial trickle offer. (T=
his is what Chrome does, although it currently uses port 1).




We had been leaning towards (a) based on the legacy equ=
ipment case mentioned above. However, if nobody can provide details on this=
 case, I agree we should end up with (b).




On Mon, Jul 7, 2014 at 4:16 AM, Emil Ivo=
v <emcho@jitsi.org> wrote:


Hey Eric, all,



>From what I've seen here, it sounds as if using port 9 on multiple m=3D=
 lines still sounds like a reasonable thing to do.



Does that mean that jsep would be adjusted to relax that requirement and on=
ly apply it in cases where it is still unclear what the remote side support=
s?



Emil




On 04.07.14, 22:52, Paul Kyzivat wrote:



On 7/4/14 4:11 AM, Harald Alvestrand wrote:



On 07/03/2014 01:36 AM, Martin Thomson wrote:



On 2 July 2014 16:22, Eric Rescorla <ekr@rtfm.com> wrote:



However, JSEP explicitly requires that we use distinct ports for

each m=3D line:

http://tools.ietf.org/html/draft-ietf-rtcweb-j=
sep-06#section-5.2.1



Obviously 9 is equal to itself, so this isn't going to work.



I'm not sure that this is actually a problem, unless I've missed
something.



The reason for having different ports is to make it clear that the m=3D

section will have distinct transport endpoints and can be unbungled if

the answerer wants that. =C2=A0But the presence (or absence) of

a=3Dbungle-only is sufficient to distinguish those m=3D sections.





It isn't sufficient in the first offer, before you know if the other
side supports it. If not, then you don't want the media to happen at
all. The port=3D9 will ensure that, just as port=3D0 would.



But the answerer that doesn't understand bundle-only may also be

disturbed by finding multiple port 9's. (If it gave any thought to the<=
br>
matter it wouldn't, but by the letter of the law it is incorrect.





Requiring multiple port 9s is silly. BUNDLE should not require this.



If I remember rightly, port 9 started out with TCP candidates where the

transport can only be established as an outgoing call.



BUNDLE should say "MUST be unique, unless they're the discard port=
 (port

9)".





Certainly you should be able to use unique-ports. But then you might as

well not bother with bundle-only, since you need to allocate the ports.



=C2=A0 =C2=A0 =C2=A0Thanks,

=C2=A0 =C2=A0 =C2=A0Paul







Also, JSEP uses the term "null" for these ports. We propose that<=
br>
instead we use the term "dummy".



WFM.



_______________________________________________

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




_______________________________________________

mmusic mailing list

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





--bcaec50164afe9ef6304fded7f66--


From nobody Fri Jul 11 10:51:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C381B2987 for ; Fri, 11 Jul 2014 10:51:32 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W32VT0tGt79q for ; Fri, 11 Jul 2014 10:51:31 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243711B2974 for ; Fri, 11 Jul 2014 10:51:30 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id ho1so81699wib.4 for ; Fri, 11 Jul 2014 10:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lDGokFq2VAHFaYas0n/wqj1ElZhdDm5bzUZ0KSlkII4=; b=HPPIVjf3pPHS7V97zzuRZLhllj8FcvUJKvWoDaeb1l0tVQ840pss53Ar5bW+iwxRlU QZ4RHGe1sIBhpk9o9aA2bDDuGH4hWZdYEoUy0PmBJKCEi2jzwWcPhjqX4veyWSK3Kmuk kXg7n3MSjKSqUDZviLA26NMcr4sB+j//RFGBineE6WYL7iLDJ2jasP6uzcBKCT8VztV6 B7GKYGGLA4TDFucfN8KnIrs4YIOdDCgCu91EBuU8C56LdtAinw3SDldP5WQW7r7/yfkj n+DNSg+fHDwf6ygvMOASJScGmeOp9UtovGThtK3wvIbNH5Vm07gh3t4cXSxcg2yJsKFu amag==
MIME-Version: 1.0
X-Received: by 10.180.92.38 with SMTP id cj6mr6858679wib.64.1405101086517; Fri, 11 Jul 2014 10:51:26 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 10:51:26 -0700 (PDT)
In-Reply-To: 
References:   <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org> 
Date: Fri, 11 Jul 2014 10:51:26 -0700
Message-ID: 
From: Martin Thomson 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OeJKEz4z3gSTs-Ghuz1tZ_9ECps
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:51:32 -0000

On 11 July 2014 09:33, Justin Uberti  wrote:
> a) We require unique 'dummy' ports in the initial trickle offer.
> b) We allow use of the same dummy port (9) in the initial trickle offer.
> (This is what Chrome does, although it currently uses port 1).
>
> We had been leaning towards (a) based on the legacy equipment case mentioned
> above. However, if nobody can provide details on this case, I agree we
> should end up with (b).

As a general rule, if accommodating legacy equipment is particularly
hard for us here, then we should leave the fixups needed for that
legacy equipment to application code.  This seems like a good
candidate for that.  It's not like non-9 ports will work with all
legacy equipment anyway.


From nobody Fri Jul 11 11:17:54 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE931A0AAF for ; Fri, 11 Jul 2014 11:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14NmACqOejwG for ; Fri, 11 Jul 2014 11:17:50 -0700 (PDT)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354F81A0309 for ; Fri, 11 Jul 2014 11:17:49 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so111505wib.8 for ; Fri, 11 Jul 2014 11:17:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FIcn0ZXBV3nAn+fh1hO/aPAPvWPZ4kGXxSSx4uh+KGM=; b=Nsr0v7fBFkSO1rokZU2PvGEzovyuaLkgcDNfBpP/QodV0ofCre8NuS8J6LADCTas9g w+45G6kg7FguYIq2ckwahczydfRmeamtBSGoF9R7jcfXFtXIuwuh+Bi/fHxDfRlS3Gen 5D3Syeq9H/E09pKLqFhComLbMQaR3httND6L2ljkg5/gsYQU8DPQq4aq0nYMVL4/VbjO cM5s/O+9N6scIKGGOGkY6pTgY3sZIX1Qd8RNyeJRj+/IfTSr6BUywdrTftTEcLAut27m owi020Q8Yy4CxXqHcb5Ky/Ie1+eoOgHKk/lxyb2bwCqMJ7xMokueHxIjdVMH9YC4FcsV VxEQ==
X-Gm-Message-State: ALoCoQmtOTOR9463yr+lffVBTjKOVN77oHvEnjEKzwou2/0/HUJmNxopv9GJK2aHofowNPtkhZLB
X-Received: by 10.194.11.74 with SMTP id o10mr726728wjb.82.1405102666107; Fri, 11 Jul 2014 11:17:46 -0700 (PDT)
Received: from [192.168.1.23] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id pq9sm6621347wjc.35.2014.07.11.11.17.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 11:17:44 -0700 (PDT)
Message-ID: <53C02A45.40703@jitsi.org>
Date: Fri, 11 Jul 2014 20:17:41 +0200
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Martin Thomson ,  Justin Uberti 
References: 		<53B661C9.6090009@alvestrand.no>	<53B713FC.5010507@alum.mit.edu>	<53BA81A3.8090108@jitsi.org>	 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rfySFZAoPvXsDwr0JDOpr_2wScM
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:17:52 -0000

On 11.07.14, 19:51, Martin Thomson wrote:
> On 11 July 2014 09:33, Justin Uberti  wrote:
>> a) We require unique 'dummy' ports in the initial trickle offer.
>> b) We allow use of the same dummy port (9) in the initial trickle offer.
>> (This is what Chrome does, although it currently uses port 1).
>>
>> We had been leaning towards (a) based on the legacy equipment case mentioned
>> above. However, if nobody can provide details on this case, I agree we
>> should end up with (b).
>
> As a general rule, if accommodating legacy equipment is particularly
> hard for us here, then we should leave the fixups needed for that
> legacy equipment to application code.  This seems like a good
> candidate for that.  It's not like non-9 ports will work with all
> legacy equipment anyway.


Also note that, in the case of trickle, port 9s would only occur if the 
offerer expects (knows) it would be supported. In other cases it would 
just do half trickle and the problem wouldn't exist.

Emil


-- 
https://jitsi.org


From nobody Fri Jul 11 11:34:17 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D981A0377 for ; Fri, 11 Jul 2014 11:34:15 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gIMdtiNZa-j for ; Fri, 11 Jul 2014 11:34:14 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E3D1A020B for ; Fri, 11 Jul 2014 11:34:14 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w62so1204669wes.15 for ; Fri, 11 Jul 2014 11:34:10 -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=tLQcH/oRj84MD2KnNVvCnLln3vsqlLRVnWauZ7U9ZDE=; b=bos6dOXErkYQe02kmPRguaqRPhJkamtQuE25QO8e5vjV060XYm+RNaj2MCqA1Qfu3H w210GNJW0wMSF96OsjcmPW6O7ilTkOyTkbM2riyQxFV03dA3xbHL4P0ZGuakXSGUij18 /BFVheJW8r/4qdcLyHC56asSAc+hCLLgynK3QtvZtAFzrzMEfh8a0Qi82FD4d6AztWiq Zx0ySqVBjzqGqKxX4Mp8hAKGVRBw9BfQgkoFDgrsa0rxkG2hyHY905PRHkdhpEcIrH5p 4DLexgYSMokkXN/3f1u4FM8yg4AjFOffDxPyJiItKkZtT190mZqO/uZrSGRiFbZnYy1R O6GQ==
MIME-Version: 1.0
X-Received: by 10.180.210.239 with SMTP id mx15mr6840853wic.65.1405103648922;  Fri, 11 Jul 2014 11:34:08 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 11:34:08 -0700 (PDT)
In-Reply-To: <53C02A45.40703@jitsi.org>
References:   <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org>   <53C02A45.40703@jitsi.org>
Date: Fri, 11 Jul 2014 11:34:08 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7P4QSfY4Pc9YUiJ29mcZYDUEUog
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:34:15 -0000

On 11 July 2014 11:17, Emil Ivov  wrote:
>
>
> On 11.07.14, 19:51, Martin Thomson wrote:
>>
>> On 11 July 2014 09:33, Justin Uberti  wrote:
>>>
>>> a) We require unique 'dummy' ports in the initial trickle offer.
>>> b) We allow use of the same dummy port (9) in the initial trickle offer.
>>> (This is what Chrome does, although it currently uses port 1).
>>>
>>> We had been leaning towards (a) based on the legacy equipment case
>>> mentioned
>>> above. However, if nobody can provide details on this case, I agree we
>>> should end up with (b).
>>
>>
>> As a general rule, if accommodating legacy equipment is particularly
>> hard for us here, then we should leave the fixups needed for that
>> legacy equipment to application code.  This seems like a good
>> candidate for that.  It's not like non-9 ports will work with all
>> legacy equipment anyway.
>
> Also note that, in the case of trickle, port 9s would only occur if the
> offerer expects (knows) it would be supported. In other cases it would just
> do half trickle and the problem wouldn't exist.

Yeah, that's even more reason to do the right thing (as opposed to the
safe thing).


From nobody Mon Jul 14 06:43:52 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE7F1A0414 for ; Mon, 14 Jul 2014 06:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FymlBdAX47gb for ; Mon, 14 Jul 2014 06:43:49 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A2D4E1A0413 for ; Mon, 14 Jul 2014 06:43:48 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 5E9E91EB8482; Mon, 14 Jul 2014 15:43:46 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Mon, 14 Jul 2014 15:43:46 +0200
From: "Stach, Thomas" 
To: Roman Shpount 
Thread-Topic: [rtcweb] ICE-Mismatch and WebRTC
Thread-Index: AQHPmhz0+RWo25njHkOOjwGUM70wJZuWPuqAgAAqLoCAABC2AIAEdOyAgAAa8wCAABQEAIAAGF8AgAAQJACABFPHIA==
Date: Mon, 14 Jul 2014 13:43:45 +0000
Message-ID: 
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org> 
In-Reply-To: 
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE1217AC9CE1MCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cI3McIhB9dC14NGHMy_QL_aRxN8
Cc: MMUSIC 
Subject: Re: [MMUSIC] [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jul 2014 13:43:50 -0000

--_000_F81CEE99482EFE438DAE2A652361EE1217AC9CE1MCHP04MSXglobal_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayB0aGlzIG1ha2VzIHNlbnNlLCBidXQganVzdCBmb3IgY2xhcml0eSBzb21lIHRob3Vn
aHRzIGlubGluZeKApg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogRnJlaXRhZywgMTEuIEp1
bGkgMjAxNCAyMzoyMQ0KVG86IEVtaWwgSXZvdg0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVj
dDogUmU6IFtydGN3ZWJdIElDRS1NaXNtYXRjaCBhbmQgV2ViUlRDDQoNCkkgd291bGQgYWdyZWUg
d2l0aDoNCg0KMS4gTXVzdCBmYWlsIGlmIGM9L209IGxpbmUgSVAgZG9lcyBub3QgbWF0Y2ggYW55
IGNhbmRpZGF0ZS4gTXVzdCBhbHNvIGZhaWwgaWYgcnRjcCBhdHRyaWJ1dGUgZG9lcyBub3QgbWF0
Y2ggYW55IFJUQ1AgY2FuZGlkYXRlcy4NCltUU10gV2hhdCB0byBkbyBpZiB0aGlzIGlzIG9ubHkg
dGhlIGNhc2UgZm9yIG9uZSBtLWxpbmUsIGJ1dCBub3QgZm9yIG90aGVycz8NCjIuIE11c3QgZmFp
bCBpZiAiaWNlLW1pc21hdGNoIiBhdHRyaWJ1dGUgaXMgcHJlc2VudCBzYW1lIGFzIG5vIElDRQ0K
W1RTXSBJQ0UtbWlzbWF0Y2ggaXMgYSBtZWRpYS1sZXZlbCBhdHRyaWJ1dGUuIFdoYXQgaWYgeW91
IGhhdmUgYW4gaWNlLW1pc21hdGNoIGZvciBqdXN0IG9uZSBtLWxpbmUsIGJ1dCBub3QgZm9yIG90
aGVycz8NCg0KMy4gUG9ydCAwIGluIG09IGxpbmUgdG8gZGlzYWJsZSB0aGUgbGluZSBtdXN0IGJl
IHVuZGVyc3Rvb2QNCltUU10gWWVzLiBPZiBjb3Vyc2UsIGlmIHRoZSBtLWxpbmUgaXMgZGlzYWJs
ZWQgaXQgc2hvdWxkIG5vdCBjYXJyeSBjYW5kaWRhdGVzIGFuZCB0aHVzIGFuIGljZS1taXNtYXRj
aCBzaG91bGQgbm90IG9jY3VyIGZvciB0aGF0IG0tbGluZS4NCg0KNC4gYz0gbGluZSB3aXRoIDAu
MC4wLjAgbXVzdCBmYWlsDQpbVFNdIEFnYWluLCBNVVNUIGZhaWwgaW4gY2FzZSBvZiBhbGwgbS1s
aW5lcyBvciBhbHJlYWR5IGZvciBhIHNpbmdsZSBtLWxpbmU/DQoNCkRvZXMgdGhpcyBtYWtlIHNl
bnNlPw0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo=

--_000_F81CEE99482EFE438DAE2A652361EE1217AC9CE1MCHP04MSXglobal_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0
IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y
bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0
Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl
cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5
bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlzIG1ha2VzIHNlbnNlLCBidXQganVzdCBmb3IgY2xh
cml0eSBzb21lIHRob3VnaHRzIGlubGluZeKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRj
d2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
PlJvbWFuIFNocG91bnQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJlaXRhZywgMTEuIEp1bGkgMjAxNCAy
MzoyMTxicj4NCjxiPlRvOjwvYj4gRW1pbCBJdm92PGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0
Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIElDRS1NaXNtYXRjaCBhbmQg
V2ViUlRDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgd291bGQgYWdyZWUgd2l0aDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+MS4gTXVzdCBmYWlsIGlmIGM9L209IGxpbmUgSVAgZG9lcyBub3QgbWF0Y2gg
YW55IGNhbmRpZGF0ZS4gTXVzdCBhbHNvIGZhaWwgaWYgcnRjcCBhdHRyaWJ1dGUgZG9lcyBub3Qg
bWF0Y2ggYW55IFJUQ1AgY2FuZGlkYXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5bVFNdIFdoYXQgdG8gZG8gaWYgdGhpcyBpcyBvbmx5IHRoZSBjYXNlIGZvciBvbmUg
bS1saW5lLCBidXQgbm90IGZvciBvdGhlcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gTXVzdCBmYWlsIGlmICZxdW90O2ljZS1t
aXNtYXRjaCZxdW90OyBhdHRyaWJ1dGUgaXMgcHJlc2VudCBzYW1lIGFzIG5vIElDRTxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPltUU10gSUNFLW1pc21hdGNoIGlzIGEgbWVkaWEtbGV2ZWwgYXR0cmli
dXRlLiBXaGF0IGlmIHlvdSBoYXZlIGFuIGljZS1taXNtYXRjaCBmb3IganVzdCBvbmUgbS1saW5l
LCBidXQgbm90IGZvciBvdGhlcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBQb3J0IDAgaW4gbT0gbGluZSB0byBkaXNhYmxl
IHRoZSBsaW5lIG11c3QgYmUgdW5kZXJzdG9vZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUU10g
WWVzLiBPZiBjb3Vyc2UsIGlmIHRoZSBtLWxpbmUgaXMgZGlzYWJsZWQgaXQgc2hvdWxkIG5vdCBj
YXJyeSBjYW5kaWRhdGVzIGFuZCB0aHVzIGFuIGljZS1taXNtYXRjaCBzaG91bGQgbm90IG9jY3Vy
IGZvciB0aGF0IG0tbGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuIGM9IGxpbmUgd2l0aCAwLjAuMC4wIG11c3QgZmFpbDxz
cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPltUU10gQWdhaW4sIE1VU1QgZmFpbCBpbiBjYXNlIG9mIGFsbCBtLWxpbmVzIG9yIGFs
cmVhZHkgZm9yIGEgc2luZ2xlIG0tbGluZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJv
bWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_F81CEE99482EFE438DAE2A652361EE1217AC9CE1MCHP04MSXglobal_--


From nobody Mon Jul 14 09:27:17 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4396D1A0AD3; Mon, 14 Jul 2014 09:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtnM8my4iOe9; Mon, 14 Jul 2014 09:27:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7085E1A0AD7; Mon, 14 Jul 2014 09:27:13 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140714162713.16908.49912.idtracker@ietfa.amsl.com>
Date: Mon, 14 Jul 2014 09:27:13 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CkaAGKk9jjOMn0WNSHn7HPOe7F4
Cc: mmusic chair , mmusic mailing list , RFC Editor 
Subject: [MMUSIC] Protocol Action: 'A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)' to Proposed Standard (draft-ietf-mmusic-rtsp-nat-22.txt)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jul 2014 16:27:16 -0000

The IESG has approved the following document:
- 'A Network Address Translator (NAT) Traversal Mechanism for Media
   Controlled by Real-Time Streaming Protocol (RTSP)'
  (draft-ietf-mmusic-rtsp-nat-22.txt) as Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Alissa Cooper and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/





Technical Summary

The document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary RTSP extensions and procedures.

Working Group Summary

The RTSP specification (RFC 2326 and RFC2326bis) has long suffered from lack of a standardized NAT traversal mechanism and hence there was a desire to rectify that. The WG has separately investigated different approaches to RTSP NAT and concluded that a solution leveraging ICE was preferred. The ICE-based solution appeared initially in the -05 WG version of this document in 2007. Since the document is a companion to RTSP 2.0, progress on the document was to some extent gated on RTSP 2.0 progress as well as progress on the accompanying RTSP NAT Evaluation document, but a WGLC was issued on the -14 version in the latter part of 2012. Following review comments and updates, another WGLC was issued on -15 in the middle of 2013 with no major comments received. A few minor updates have been done since then as a result of active reviews from 2 people while waiting for RTSP 2.0 and the accompanying RTSP NAT Evalution documents to progress.

Document Quality

The document has been reviewed in detail several times after WGLC (incl. by one of the ICE-bis authors) and in preparation for the publication request and the authors have made various minor updates as a result of those. The document is considered to be of good quality at this point.

There are no known implementations of the current specification, however a prototype implementation of an earlier version of the spec was done a while back. 

There are no new media types, MIBs, etc. and hence no such reviews apply.

Personnel

Flemming Andreasen is the document shepherd. Alissa Cooper is the responsible area director.

RFC Editor Note

Please replace the current text in Section 11.2 with the following:

The logging of NAT translations is helpful to analysts, particularly in enterprises, who need to be able to map sessions when investigating possible issues where the NAT happens.  When using logging on the public Internet, it is possible that the logs are large and privacy invasive, so procedures for log flushing and privacy protection SHALL be in place. Care should be taken in the protection of these logs and consideration taken to log integrity, privacy protection, and purging logs (retention policies, etc.).  Also, logging of connection errors and other messages established by this draft can be important.




From nobody Mon Jul 14 10:56:53 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618C21AD62A for ; Mon, 14 Jul 2014 10:56:49 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh4NGT3xaZ8z for ; Mon, 14 Jul 2014 10:56:47 -0700 (PDT)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9211B2789 for ; Mon, 14 Jul 2014 10:56:46 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id x48so2710859wes.5 for ; Mon, 14 Jul 2014 10:56:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EPrb7ffsXVE0fcrtWWFtiuSQUqlDUGeAyZm5u00h9Ao=; b=TpEK1ju0B5gs0DThrFCbB83nrb3imIHac5nFv9eW1G1SCTKIy4xn3wyFAJDWe6bZYc rVz2XMxwbZet2hdDlpEqMf4SShg63NYHzXSWuAHBytLql6KXhH9RPAuAw/QZB2cmpRsW F39ecOELN5pj5Eyl6ijyvjaUtX+ZObg+3HkfrNLgUjdW2XOXnLA8KxYqQXiBZ45+fSCK i+xNc9uudBb4CZ4Ey8wTq3gSjBP3XUsa3y6rXHg2oRZV+ThkHz+NdtWmb2eHJuGF96/+ qa9jGgLQy6GTmXfDuQZnhZRSlZlm/2wywNpK2tkh89p/R8QwQF5YvMkgIGCST4+5KSQY gWzA==
X-Gm-Message-State: ALoCoQmprTpq9JXlasFcFS7/JTC6whWxMqhHQxMAzQkVVL9Z9/PGzvHxWxnF1oKomoiR9hHc2Pis
X-Received: by 10.194.84.101 with SMTP id x5mr21192629wjy.52.1405360605449; Mon, 14 Jul 2014 10:56:45 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx.google.com with ESMTPSA id h13sm26936102wjs.2.2014.07.14.10.56.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 10:56:44 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id b13so2347348wgh.18 for ; Mon, 14 Jul 2014 10:56:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.92.177 with SMTP id cn17mr21374812wjb.71.1405360603755;  Mon, 14 Jul 2014 10:56:43 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Mon, 14 Jul 2014 10:56:43 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org>  
Date: Mon, 14 Jul 2014 13:56:43 -0400
Message-ID: 
From: Roman Shpount 
To: "Stach, Thomas" 
Content-Type: multipart/alternative; boundary=047d7beb91aa9188e604fe2b031b
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eYIvw2J-CCujU0y-wq4N3QcVPD8
Cc: MMUSIC 
Subject: Re: [MMUSIC] [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jul 2014 17:56:49 -0000

--047d7beb91aa9188e604fe2b031b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 14, 2014 at 9:43 AM, Stach, Thomas 
wrote:

>  I think this makes sense, but just for clarity some thoughts inline=E2=
=80=A6
>
>
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Roman
> Shpount
> *Sent:* Freitag, 11. Juli 2014 23:21
> *To:* Emil Ivov
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] ICE-Mismatch and WebRTC
>
>
>
> I would agree with:
>
>
>
> 1. Must fail if c=3D/m=3D line IP does not match any candidate. Must also=
 fail
> if rtcp attribute does not match any RTCP candidates.
>
> [TS] What to do if this is only the case for one m-line, but not for
> others?
>

It should fail if this is the case for any m=3D line. Offer/Answer updates
are atomic, so if information for one line is broken, the whole update
should fail.


>   2. Must fail if "ice-mismatch" attribute is present same as no ICE
>
> [TS] ICE-mismatch is a media-level attribute. What if you have an
> ice-mismatch for just one m-line, but not for others?
>

It should fail if ice-mismatch is present on any m=3D line. Same reason as
above.


>  3. Port 0 in m=3D line to disable the line must be understood
>
>  [TS] Yes. Of course, if the m-line is disabled it should not carry
> candidates and thus an ice-mismatch should not occur for that m-line.
>
>
>
> 4. c=3D line with 0.0.0.0 must fail
>
> [TS] Again, MUST fail in case of all m-lines or already for a single
> m-line?
>

It should fail if 0.0.0.0 is present on any m-line. Same reason as above.

_____________
Roman Shpount

--047d7beb91aa9188e604fe2b031b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On M=
on, Jul 14, 2014 at 9:43 AM, Stach, Thomas <thomas.stach@unify.com> wrote:













I think this makes sense, but just for clari=
ty some thoughts inline=E2=80=A6


=C2=A0


=C2=A0








From: rtcweb [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Roman Shpount

Sent: Freitag, 11. Juli 2014 23:21

To: Emil Ivov

Cc: rtcweb@ietf=
.org

Subject: Re: [rtcweb] ICE-Mismatch and WebRTC





=C2=A0




I would agree with:




=C2=A0






1. Must fail if c=3D/m=3D line IP does not match any=
 candidate. Must also fail if rtcp attribute does not match any RTCP candid=
ates.






[TS] What to do if this is only the case for=
 one m-line, but not for others?



It should fail if this is the case f=
or any m=3D line. Offer/Answer updates are atomic, so if information for on=
e line is broken, the whole update should fail.
=C2=A0









2. Must fail if "ice-mismatch" attribute i=
s present same as no ICE


[TS] ICE-mismatch is a media-level att=
ribute. What if you have an ice-mismatch for just one m-line, but not for o=
thers?



=
It should fail if ice-mismatch is present on any m=3D line. Same reason as =
above.
=C2=A0







3. Port 0 in m=3D line to disable the line must be understood


[TS] Yes. Of course, if the m-line is =
disabled it should not carry candidates and thus an ice-mismatch should not=
 occur for that m-line.







=C2=A0






4. c=3D line with 0.0.0.0 must fail




[TS] Again, MUST fail in case of all m-lines=
 or already for a single m-line?



It should fail if 0.0.0.0 is p=
resent on any m-line. Same reason as above.

______=
_______
Roman Shpount
=C2=A0


--047d7beb91aa9188e604fe2b031b--


From nobody Tue Jul 15 09:15:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D271B28C3 for ; Tue, 15 Jul 2014 09:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU_6e1jXLZrM for ; Tue, 15 Jul 2014 09:15:33 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6394C1B287F for ; Tue, 15 Jul 2014 09:15:32 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-88-53c553a219e3
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4C.84.04090.2A355C35; Tue, 15 Jul 2014 18:15:30 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Tue, 15 Jul 2014 18:15:30 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 22CF5110298; Tue, 15 Jul 2014 19:15:30 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 808F758917;	Tue, 15 Jul 2014 19:15:30 +0300 (EEST)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1E64153DD9;	Tue, 15 Jul 2014 19:15:30 +0300 (EEST)
Message-ID: <53C5539E.2070607@ericsson.com>
Date: Tue, 15 Jul 2014 19:15:26 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: , 
References: <20140630184553.31625.21293.idtracker@ietfa.amsl.com> <803DB627-3D5F-494D-9D25-E1000200A7A1@cisco.com>
In-Reply-To: <803DB627-3D5F-494D-9D25-E1000200A7A1@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvje6i4KPBBhc69C0+vO5htXh/Qddi 6vLHLA7MHlN+b2T1WLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgyXv08zV4whafiUn8TWwPj ZM4uRk4OCQETibVHJzBD2GISF+6tZwOxhQSOMkpseVrVxcgFZG9glLhy+jsjRGIvo0TzKxWI xDpGiaX3W5kgnBWMEq+3XQdr5xXQlrjyr50dxGYRUJXYsOgh2Ao2AXuJmxOug8VFBZIluh79 YIeoF5Q4OfMJC4gtIuAr0X/1KlA9B4ewgKHEppkWEIuLJJ4t2wNWwilgK7Gi4z4TiM0MZF+Y c50FwpaX2P52DtQ3ahJXz21ihuhVlbj67xXjBEaRWUi2zULSPgtJ+wJG5lWMosWpxcW56UZG eqlFmcnFxfl5enmpJZsYgbFwcMtvqx2MB587HmIU4GBU4uFdIHUkWIg1say4MvcQozQHi5I4 78Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MOqW3WpcanPXUXLX63dsAV9cXSWXTdQ5 fVNrwn81vfQk7u/lui2qW58LaD/ZW+cYHTBr622rWQuKnyxW2BFxqXDuF/PrvbuuCe7b2tSp ZjDv4mSWe+5Lc9X7RTPkTk9tfusY7N36XXj6om93gv9fnmr1ZemUT7tu7nrOLzdJp8zx7NWl Ow+EV85WYinOSDTUYi4qTgQAKtwMqmYCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IoJlF371WK1DMQVdSFIhznt_gZw
Subject: [MMUSIC] draft-reddy-mmusic-ice-happy-eyeballs-07
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 16:15:34 -0000

Hi,

I read the latest draft and, without a chair hat on, I think this is 
useful work and would make sense to specify in an RFC.

Regarding where to do the work, I think the best way forward would be to 
have this as a separate draft and ICE bis to have this as a reference on 
how to do candidate prioritization in a dual-stack environment.

Additionally, it would be good for someone designing a different 
algorithm for the candidate prioritization to have some more guidelines 
on how to play around with the values. As you can remember from the past 
versions, it's not always easy to get it right.

And here's a few editorial comments on the draft:

3.  Improving ICE Dual-stack Fairness

    An ICE agent can choose an algorithm or a technique of its choice to
    ensure that the resulting check lists have a fair intermingled mix of
    IPv4 and IPv6 address families.  Modifying the check list directly
    can lead to uncoordinated local and remote check lists that result in
    ICE taking longer to complete or in the worst case scenario fail.

These two sentences seem to be contradicting each other. Maybe it's 
better to start the second one with "However,".


4.  Compatibility

    To allow for earlier connectivity checks for the IPv4
    server reflexive candidates, some of the IPv6 host candidates was
    demoted.

s/was demoted/were demoted/
(or "are demoted")


                   (1)  HOST       IPv6      (1)    212928947

This line seems to be missing the last digit.


Cheers,
Ari


From nobody Tue Jul 15 14:47:24 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F451B2960 for ; Tue, 15 Jul 2014 14:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.95
X-Spam-Level: 
X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNqDAN-a3-f7 for ; Tue, 15 Jul 2014 14:47:21 -0700 (PDT)
Received: from BLU004-OMC2S38.hotmail.com (blu004-omc2s38.hotmail.com [65.55.111.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5013D1A0102 for ; Tue, 15 Jul 2014 14:47:21 -0700 (PDT)
Received: from BLU181-W7 ([65.55.111.73]) by BLU004-OMC2S38.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 15 Jul 2014 14:47:20 -0700
X-TMN: [zq8iMLUe3o6QyAi2BZ5gYOZbBPsrtskK]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_a3ca8870-62ae-4122-81e6-b467cc237506_"
From: Bernard Aboba 
To: "mmusic@ietf.org" 
Date: Tue, 15 Jul 2014 14:47:20 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Jul 2014 21:47:20.0875 (UTC) FILETIME=[5AE7A7B0:01CFA076]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7GFtuDICBjz7Qqy5HIJ4eNcJnJI
Subject: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 21:47:23 -0000

--_a3ca8870-62ae-4122-81e6-b467cc237506_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
RFC 5245 Section 9.1.1.1 (see below) deals with ICE restarts.=0A=

=0A=
In checking for revisions of this material in draft-ietf-mmusic-rfc5245bis=
=0A=
and draft-ietf-mmusic-ice-sip-sdp=2C I noticed that material on=0A=
ICE restart was included in the ICE SIP/SDP usage draft=2C but not=0A=
in RFC 5245bis.=0A=

=0A=
This seems a bit odd to me=2C because not all of the material in=0A=
Section 9.1.1.1 of the ICE SIP/SDP usage draft is dependent on SIP.=0A=
For an implementer of WebRTC (where signaling is out of scope)=2C this=0A=
might raise questions about the applicability of some of the paragraphs.=0A=
For example=2C by including this material only in the SIP/SDP usage=0A=
draft=2C are we saying that the requirement that the agent change=0A=
the ice-pwd and ice-ufrag to restart ICE only applies to SIP?=0A=

=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 5245 Section 9.1.1.1 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=

=0A=
9.1.1.1.  ICE Restarts=0A=

=0A=
   An agent MAY restart ICE processing for an existing media stream.  An=0A=
   ICE restart=2C as the name implies=2C will cause all previous states of=
=0A=
   ICE processing to be flushed and checks to start anew.  The only=0A=
   difference between an ICE restart and a brand new media session is=0A=
   that=2C during the restart=2C media can continue to be sent to the=0A=
   previously validated pair.=0A=

=0A=
   An agent MUST restart ICE for a media stream if:=0A=

=0A=
   o  The offer is being generated for the purposes of changing the=0A=
      target of the media stream.  In other words=2C if an agent wants to=
=0A=
      generate an updated offer that=2C had ICE not been in use=2C would=0A=
      result in a new value for the destination of a media component.=0A=

=0A=
   o  An agent is changing its implementation level.  This typically=0A=
      only happens in third party call control use cases=2C where the=0A=
      entity performing the signaling is not the entity receiving the=0A=
      media=2C and it has changed the target of media mid-session to=0A=
      another entity that has a different ICE implementation.=0A=

=0A=
   These rules imply that setting the IP address in the c line to=0A=
   0.0.0.0 will cause an ICE restart.  Consequently=2C ICE implementations=
=0A=
   MUST NOT utilize this mechanism for call hold=2C and instead MUST use=0A=
   a=3Dinactive and a=3Dsendonly as described in [RFC3264].=0A=

=0A=
   To restart ICE=2C an agent MUST change both the ice-pwd and the ice-=0A=
   ufrag for the media stream in an offer.  Note that it is permissible=0A=
   to use a session-level attribute in one offer=2C but to provide the=0A=
   same ice-pwd or ice-ufrag as a media-level attribute in a subsequent=0A=
   offer.  This is not a change in password=2C just a change in its=0A=
   representation=2C and does not cause an ICE restart.=0A=

=0A=
   An agent sets the rest of the fields in the SDP for this media stream=0A=
   as it would in an initial offer of this media stream (see=0A=
   Section 4.3).  Consequently=2C the set of candidates MAY include some=2C=
=0A=
   none=2C or all of the previous candidates for that stream and MAY=0A=
   include a totally new set of candidates gathered as described in=0A=
   Section 4.1.1. 		 	   		  =

--_a3ca8870-62ae-4122-81e6-b467cc237506_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





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

RFC 5245 Section 9.1.1.1 (see below) deals with ICE restart=
s.
=0A=


=0A=

In checking for revisions of this material in draft-ietf-mm=
usic-rfc5245bis
=0A=

and draft-ietf-mmusic-ice-sip-sdp=2C I noticed that materia=
l on
=0A=

ICE restart was included in the ICE SIP/SDP usage draft=2C =
but not
=0A=

in RFC 5245bis.
=0A=


=0A=

This seems a bit odd to me=2C because not all of the materi=
al in
=0A=

Section 9.1.1.1 of the ICE SIP/SDP usage draft is dependent=
 on SIP.
=0A=

For an implementer of WebRTC (where signaling is out of sco=
pe)=2C this
=0A=

might raise questions about the applicability of some of th=
e paragraphs.
=0A=

For example=2C by including this material only in the SIP/S=
DP usage
=0A=

draft=2C are we saying that the requirement that the agent =
change
=0A=

the ice-pwd and ice-ufrag to restart ICE only applies to SI=
P?
=0A=


=0A=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 5245 S=
ection 9.1.1.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A=


=0A=

9.1.1.1. =3B ICE Restarts
=0A=


=0A=

 =3B =3B An agent MAY restart ICE processing for an=
 existing media stream. =3B An
=0A=

 =3B =3B ICE restart=2C as the name implies=2C will=
 cause all previous states of
=0A=

 =3B =3B ICE processing to be flushed and checks to=
 start anew. =3B The only
=0A=

 =3B =3B difference between an ICE restart and a br=
and new media session is
=0A=

 =3B =3B that=2C during the restart=2C media can co=
ntinue to be sent to the
=0A=

 =3B =3B previously validated pair.
=0A=


=0A=

 =3B =3B An agent MUST restart ICE for a media stre=
am if:
=0A=


=0A=

 =3B =3B o =3B The offer is being generated for=
 the purposes of changing the
=0A=

 =3B  =3B  =3B target of the media stream. =
=3B In other words=2C if an agent wants to
=0A=

 =3B  =3B  =3B generate an updated offer that=
=2C had ICE not been in use=2C would
=0A=

 =3B  =3B  =3B result in a new value for the de=
stination of a media component.
=0A=


=0A=

 =3B =3B o =3B An agent is changing its impleme=
ntation level. =3B This typically
=0A=

 =3B  =3B  =3B only happens in third party call=
 control use cases=2C where the
=0A=

 =3B  =3B  =3B entity performing the signaling =
is not the entity receiving the
=0A=

 =3B  =3B  =3B media=2C and it has changed the =
target of media mid-session to
=0A=

 =3B  =3B  =3B another entity that has a differ=
ent ICE implementation.
=0A=


=0A=

 =3B =3B These rules imply that setting the IP addr=
ess in the c line to
=0A=

 =3B =3B 0.0.0.0 will cause an ICE restart. =3B=
 Consequently=2C ICE implementations
=0A=

 =3B =3B MUST NOT utilize this mechanism for call h=
old=2C and instead MUST use
=0A=

 =3B =3B a=3Dinactive and a=3Dsendonly as described=
 in [RFC3264].
=0A=


=0A=

 =3B =3B To restart ICE=2C an agent MUST change bot=
h the ice-pwd and the ice-
=0A=

 =3B =3B ufrag for the media stream in an offer.&nb=
sp=3B Note that it is permissible
=0A=

 =3B =3B to use a session-level attribute in one of=
fer=2C but to provide the
=0A=

 =3B =3B same ice-pwd or ice-ufrag as a media-level=
 attribute in a subsequent
=0A=

 =3B =3B offer. =3B This is not a change in pas=
sword=2C just a change in its
=0A=

 =3B =3B representation=2C and does not cause an IC=
E restart.
=0A=


=0A=

 =3B =3B An agent sets the rest of the fields in th=
e SDP for this media stream
=0A=

 =3B =3B as it would in an initial offer of this me=
dia stream (see
=0A=

 =3B =3B Section 4.3). =3B Consequently=2C the =
set of candidates MAY include some=2C
=0A=

 =3B =3B none=2C or all of the previous candidates =
for that stream and MAY
=0A=

 =3B =3B include a totally new set of candidates ga=
thered as described in
=0A=

 =3B =3B Section 4.1.1.
 		 	   		  

=

--_a3ca8870-62ae-4122-81e6-b467cc237506_--


From nobody Tue Jul 15 15:08:10 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C141B278B for ; Tue, 15 Jul 2014 15:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level: 
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTJi1IdjZm8m for ; Tue, 15 Jul 2014 15:08:04 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DAF1A010F for ; Tue, 15 Jul 2014 15:08:04 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-85-53c5a6411393
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E9.86.03739.146A5C35; Wed, 16 Jul 2014 00:08:02 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 00:08:01 +0200
From: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
To: Bernard Aboba 
Thread-Topic: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
Thread-Index: AQHPoHk9ddsU5RWVf067fT/gUeG0Jg==
Date: Tue, 15 Jul 2014 22:08:00 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Rtdp2dFgg0sd/Bb7l1xmtpi6/DGL A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYvPsNa8E62YqZHx4wNjA+F+ti5OSQEDCR WDlzLjOELSZx4d56ti5GLg4hgaOMEv/ezmKHcBYzSuxcvZEFpIpNwF5i8pqPjF2MHBwiAroS f7uMQExmAXWJq4uDQCqEBXwkJn/YwARiiwj4SlxvW8EMYetJzNo+mw3EZhFQlei6fwdsIi/Q xP03roHVCwlYSDyccZMdxOYUsJT4eriHFcRmBLrt+6k1YDXMAuISt57MZ4K4WUBiyZ7zUPeL Srx8/I8VwlaSaFzyhBWiXk/ixtQpbBC2tcTD1z+g5mhLLFv4mhniBkGJkzOfsExgFJ+FZMUs JO2zkLTPQtI+C0n7AkbWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB0XZwy2/dHYyrXzse YhTgYFTi4VXIORosxJpYVlyZe4hRmoNFSZx30bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoYQ5ecdl8YcEwgNe/Hwo11J+685+YNT6jIu6H4zdYpjYfl0Owlwbs33rl/KL1ssbiv6u9P bjwuaX6/H/7mfTttm+kcZvZVmQ5G1oHLq1coLHxQulNiIkfDLIuXDS06b6ZaphnnviwWd43M 1Z+fsLHF3KJqyxXtZLGEDVc5L/HynZn92mDisSVNSizFGYmGWsxFxYkAjL84+5cCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TigtPwlKgfeAOKQj8ywm-CH3qdU
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 22:08:08 -0000

Hi Bernard,

On Jul 16, 2014, at 12:47 AM, Bernard Aboba wrote:
> RFC 5245 Section 9.1.1.1 (see below) deals with ICE restarts.
>=20
> In checking for revisions of this material in draft-ietf-mmusic-rfc5245bi=
s
> and draft-ietf-mmusic-ice-sip-sdp, I noticed that material on
> ICE restart was included in the ICE SIP/SDP usage draft, but not
> in RFC 5245bis.
>=20
> This seems a bit odd to me, because not all of the material in
> Section 9.1.1.1 of the ICE SIP/SDP usage draft is dependent on SIP.
> For an implementer of WebRTC (where signaling is out of scope), this
> might raise questions about the applicability of some of the paragraphs.
> For example, by including this material only in the SIP/SDP usage
> draft, are we saying that the requirement that the agent change
> the ice-pwd and ice-ufrag to restart ICE only applies to SIP?

Good catch. It was not the intention to remove this kind of details from th=
e ICE spec with the split. Will need to have a closer look on which parts s=
hould go to which spec. Regarding this section, I think the change of ice-p=
wd and -ufrag applies to other protocols too and should be mentioned in the=
 main spec. Anything else in particular to consider?


Cheers,
Ari

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 5245 Section 9.1.1.1=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 9.1.1.1.  ICE Restarts
>=20
>    An agent MAY restart ICE processing for an existing media stream.  An
>    ICE restart, as the name implies, will cause all previous states of
>    ICE processing to be flushed and checks to start anew.  The only
>    difference between an ICE restart and a brand new media session is
>    that, during the restart, media can continue to be sent to the
>    previously validated pair.
>=20
>    An agent MUST restart ICE for a media stream if:
>=20
>    o  The offer is being generated for the purposes of changing the
>       target of the media stream.  In other words, if an agent wants to
>       generate an updated offer that, had ICE not been in use, would
>       result in a new value for the destination of a media component.
>=20
>    o  An agent is changing its implementation level.  This typically
>       only happens in third party call control use cases, where the
>       entity performing the signaling is not the entity receiving the
>       media, and it has changed the target of media mid-session to
>       another entity that has a different ICE implementation.
>=20
>    These rules imply that setting the IP address in the c line to
>    0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
>    MUST NOT utilize this mechanism for call hold, and instead MUST use
>    a=3Dinactive and a=3Dsendonly as described in [RFC3264].
>=20
>    To restart ICE, an agent MUST change both the ice-pwd and the ice-
>    ufrag for the media stream in an offer.  Note that it is permissible
>    to use a session-level attribute in one offer, but to provide the
>    same ice-pwd or ice-ufrag as a media-level attribute in a subsequent
>    offer.  This is not a change in password, just a change in its
>    representation, and does not cause an ICE restart.
>=20
>    An agent sets the rest of the fields in the SDP for this media stream
>    as it would in an initial offer of this media stream (see
>    Section 4.3).  Consequently, the set of candidates MAY include some,
>    none, or all of the previous candidates for that stream and MAY
>    include a totally new set of candidates gathered as described in
>    Section 4.1.1.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Tue Jul 15 15:53:19 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE81B29AA for ; Tue, 15 Jul 2014 15:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLVBwQXKwVcF for ; Tue, 15 Jul 2014 15:53:17 -0700 (PDT)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017A81B29A4 for ; Tue, 15 Jul 2014 15:53:16 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id wm4so103395obc.2 for ; Tue, 15 Jul 2014 15:53:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=r/OBvrUW85SdkXFmb1GEClgEg7nWg+H4diyTuWlhCZA=; b=doQe5A2mKbtsFWMKjpYqEPfNi+153u9FZD8DOZ/3KSV0ySn7qJFqBwpHA13xdjF6Sq GuQiKKrXxhgS8LuAHAAKfEUC0Iqheclr3MKGZtDldt+nQZajXPCwp3hmoiJzT7z6y6Zu XQWIJuiPLJ224CLlUpy4AKX7Yu0IFdaCOEToB90IS98qPlYpmWHmiRgS+rNikbJaRJfz phyYtK2H7dVOMaiCnkNtL7cCqtBI+3hSDUjA6xy65vvI5uj/BwFXf2HXfu8BHacV6Agn gELuKp6L6zgji8UZvoriVM1cVqSSbBOGSiDkraPNM6V/tR+rJGAkeJLsKwDW3XfH85+x 9PSQ==
X-Gm-Message-State: ALoCoQkASgHJCCZv0Hw4qlOFIxLzglOOXfWkEvFzzrIUqXRvJXFVAFR7hi4xcxceLKzWpouE6Y5e
X-Received: by 10.60.176.134 with SMTP id ci6mr8123126oec.85.1405464796149; Tue, 15 Jul 2014 15:53:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.9.197 with HTTP; Tue, 15 Jul 2014 15:52:56 -0700 (PDT)
In-Reply-To: 
References:  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 16 Jul 2014 00:52:56 +0200
Message-ID: 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uI7QL9DAPynKoV69zx76ICFVqgU
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 22:53:18 -0000

2014-07-16 0:08 GMT+02:00 Ari Ker=C3=A4nen :
> I think the change of ice-pwd and -ufrag applies to other protocols

Why should the ufrag and pwd change upon ICE restart? I mean: is there
a real reason for that?


--=20
I=C3=B1aki Baz Castillo



From nobody Tue Jul 15 16:04:47 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E721B29AC for ; Tue, 15 Jul 2014 16:04:46 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmQ1UWMNJszi for ; Tue, 15 Jul 2014 16:04:45 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBCC1B29A5 for ; Tue, 15 Jul 2014 16:04:45 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id n3so4875842wiv.2 for ; Tue, 15 Jul 2014 16:04:44 -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=GPrJrKvnvuPWVzuHiO1jbOVTa1XEN8aFWbISCRUqVNM=; b=ZlTVDuhGgtkw1iQogle9vmSDt5Kwz0te2HdRyHy0atJZvAioBUBrks24/uEOOPp+cS qDzNPhLcoPfBM8HEtCFYQWMNBJ2D9ITPNPScviA1X0ZMejKuMJ4703kw0RHnR+LwUAoY aK3+DmW8RXCaV8SVc6bcTTQf0G9xnCREDcpqbM375zCO7yeA2K9DWrMyFwmRgc0FR6sY 6LgaoSYXoJdENvy+HTwVDOl6InMh0dVdFIW/iPD2ai80N1mn5uA6PTXSipKVFxzP6wgM uc2fC9Db0VlSQGIw6RFaKwy6MNy1tQmlWSH7rb+HaD5A51H/hpchRiYyHZXVPoVJ3g0r uVFA==
MIME-Version: 1.0
X-Received: by 10.195.11.132 with SMTP id ei4mr22127916wjd.95.1405465484259; Tue, 15 Jul 2014 16:04:44 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 15 Jul 2014 16:04:44 -0700 (PDT)
In-Reply-To: 
References:   
Date: Tue, 15 Jul 2014 16:04:44 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LedtCWWMTNANqycWq5Mj5Fg5qRQ
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 23:04:46 -0000

On 15 July 2014 15:52, I=C3=B1aki Baz Castillo  wrote:
> Why should the ufrag and pwd change upon ICE restart? I mean: is there
> a real reason for that?

Yes, it's a signal to a peer that a restart is happening.  Ostensibly,
it's actually unnecessary, but as a practical matter, you gotta do it.


From nobody Tue Jul 15 16:42:50 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900961A01E6 for ; Tue, 15 Jul 2014 16:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWxrdQCVFbt5 for ; Tue, 15 Jul 2014 16:42:43 -0700 (PDT)
Received: from BLU004-OMC3S9.hotmail.com (blu004-omc3s9.hotmail.com [65.55.116.84]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333F81B2788 for ; Tue, 15 Jul 2014 16:42:42 -0700 (PDT)
Received: from BLU181-W67 ([65.55.116.73]) by BLU004-OMC3S9.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 15 Jul 2014 16:42:41 -0700
X-TMN: [M7k83cv3hNfhEtb2fcAOt/v/EChbee8T]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_255af475-6dd4-48ec-bc56-9a9f0cb858f0_"
From: Bernard Aboba 
To: =?iso-8859-1?B?QXJpIEtlcuRuZW4=?= 
Date: Tue, 15 Jul 2014 16:42:41 -0700
Importance: Normal
In-Reply-To: 
References: , 
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Jul 2014 23:42:41.0666 (UTC) FILETIME=[78048E20:01CFA086]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xdo-n5w1sNMeo4rmy-aahypH7S4
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 23:42:44 -0000

--_255af475-6dd4-48ec-bc56-9a9f0cb858f0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Ari said:=20
"Anything else in particular to consider?"
[BA] Does the MUST restart guidance apply more generally?  For example=2C w=
hether a restart is always required when changing the target of the media s=
tream or the implementation level.   Also=2C the guidance on the set of can=
didates (some=2C none or all of  the previous candidates or a new set) does=
n't seem specific to SIP.=20

 		 	   		  =

--_255af475-6dd4-48ec-bc56-9a9f0cb858f0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Ari said: =3B

"Anything else in particul=
ar to consider?"

[BA] Does the MUST resta=
rt guidance apply more generally?  =3BFor example=2C whether a restart is always required when =3Bchanging the target of the media st=
ream or the implementation level.  =3B Also=2C the guidance on =3B<=
/span>the set of candidates (some=2C non=
e or all of  =3Bthe previous =
candidates or a new set) doesn't seem specific to SIP. =3B
=



 		 	   		  

=

--_255af475-6dd4-48ec-bc56-9a9f0cb858f0_--


From nobody Wed Jul 16 01:09:04 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F232A1B2AA4 for ; Wed, 16 Jul 2014 01:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9wnxyBrI7XL for ; Wed, 16 Jul 2014 01:08:59 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FE01B29E2 for ; Wed, 16 Jul 2014 01:08:58 -0700 (PDT)
X-AuditID: c1b4fb30-f79da6d000006b80-af-53c633181225
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.00.27520.81336C35; Wed, 16 Jul 2014 10:08:56 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 10:08:55 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: Ac+gzPU1emAL6VKdRxqp/JxOiqLvoA==
Date: Wed, 16 Jul 2014 08:08:55 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3C7224ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja6E8bFgg/2zxC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujM4b99kL1npXfP65m6mBcZpjFyMnh4SAicSStbdYIGwxiQv3 1rN1MXJxCAkcZZR4tP0qI0hCSGARo8TyZe5djBwcbAIWEt3/tEHCIgLqEl/39jCD2MICvhJ3 VsxmgoiHSCz6vJgZwtaT2PPhHNgYFgFViS/9t9lBbF6g+tM7b4LVMwLt/X5qDZjNLCAucevJ fCaIewQkluw5zwxhi0q8fPyPFcJWklh0+zNUfb7Ex3Xf2CBmCkqcnPmEZQKj0Cwko2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3Z xAiMiINbfhvsYHz53PEQowAHoxIPr0LO0WAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cAYW7ny5xmLcjkjeZHmhm7/iL9vtovXzN55gJmD+d+dq0cT9Q9v 3/y+nCn26gUJLSOjueKXRDp2pkR7J7WJ+m0o44q0vuvNdVk2tVRWp0C7Ka8139zlpHqh3ox6 37qEHKF5Jc1VbxwvPhLkOXv9AQuH83ruTx5Ljlh5KmcW+l1f2pPPoTubR4mlOCPRUIu5qDgR APxdSjxpAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/88rnWJp4_Pbev7zmIB2VVYm6HRI
Subject: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 08:09:02 -0000

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

Hi BUNDLE lovers,

The main remaining open issue in BUNDLE is the "receiver-id", i.e. the mech=
anism for the Offerer to map received RTP/RTCP packets with the associated =
m- line - even before the SDP answer has been received.

In London we more or less agreed to use Roni's app-id for this.

Since then, we've had some off-line discussions with Roni, and instead of u=
sing app-id we suggest the following:


-          We use the SDP mid attribute value to map RTP/RTCP packets with =
m- lines

-          We define a new RTP header extension, and a new RTCP SDES item, =
for carrying the mid value

-          The RTP header extension/RTCP SDES item are generic, which means=
 they can also be used with other protocols than SDP

The advantage is that the SDP mid attribute already exists, the usage is ma=
ndatory in BUNDLE, and the value is unique for each m- line. The semantics =
also fit, as it is referencing an m- line.

Some of the detailed questions we need to deal with are:

Q1: The syntax of the SDP mid attribute value must "fit" into an RTP header=
 extension of RTCP SDES item.
Q2: When are the mid value sent? During Offer/Answer transaction? During wh=
ole session? When SSRC change?
Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both direction=
s?
Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the mechanism i=
n draft-westerlund-avtext-sdes-hdr-ext?

I intend to talk about during the MMUSIC session on Monday, but feel free t=
o comment and give input on the list :)

Regards,

Christer


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











Hi BUNDLE lovers,


 


The main remaining open issue in BUNDLE is the ̶=
0;receiver-id”, i.e. the mechanism for the Offerer to map received RT=
P/RTCP packets with the associated m- line – even before the SDP answ=
er has been received.


 


In London we more or less agreed to use Roni’s=
 app-id for this.


 


Since then, we’ve had some off-line discussion=
s with Roni, and instead of using app-id we suggest the following:


 


-     &=
nbsp;   
We use the SDP mid attribute value to map RTP/RTCP =
packets with m- lines


-     &=
nbsp;   
We define a new RTP header extension, and a new RTC=
P SDES item, for carrying the mid value


-     &=
nbsp;   
The RTP header extension/RTCP SDES item are generic=
, which means they can also be used with other protocols than SDP


 


The advantage is that the SDP mid attribute already =
exists, the usage is mandatory in BUNDLE, and the value is unique for each =
m- line. The semantics also fit, as it is referencing an m- line.


 


Some of the detailed questions we need to deal with =
are:


 


Q1: The syntax of the SDP mid attribute value must &=
#8220;fit” into an RTP header extension of RTCP SDES item.=



Q2: When are the mid value sent? During Offer/Answer=
 transaction? During whole session? When SSRC change?



Q3: Do we, for BUNDLE usage, allow usage of the mech=
anism in both directions?


Q4: Do we carry the RTCP SDES item in RTCP, or in RT=
P using the mechanism in draft-westerlund-avtext-sdes-hdr-ext?

 


I intend to talk about during the MMUSIC session on =
Monday, but feel free to comment and give input on the list :)

 


Regards,


 


Christer 


 






--_000_7594FB04B1934943A5C02806D1A2204B1D3C7224ESESSMB209erics_--


From nobody Wed Jul 16 07:50:03 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397191B28AF for ; Wed, 16 Jul 2014 07:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej8hkZ3DWzLB for ; Wed, 16 Jul 2014 07:50:00 -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 46B691B28AD for ; Wed, 16 Jul 2014 07:49:53 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta13.westchester.pa.mail.comcast.net with comcast id T0C71o0010xGWP85D2ps9U; Wed, 16 Jul 2014 14:49:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id T2ps1o00q3ZTu2S3Y2psz1; Wed, 16 Jul 2014 14:49:52 +0000
Message-ID: <53C69110.504@alum.mit.edu>
Date: Wed, 16 Jul 2014 10:49:52 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405522192; bh=uX8TpSl8nbc2VBY0dbXUtYTIEb4t9OCkuVq0TPMjYJQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nLFf549G4Sv6HZJe9tgjlK1ghqmnisxme4mV6TrGHtd3Xb8kALjjDbPzNOaNHTWZL n277hCrQRw1EIXjwAhKKnAqATuF0oIWbiGfZNks2ScyNraJtE60TTPUk3poLDxuC1M mWfTt8Y+uZTbMteIWhz0tsnHL8ibgHeuDEb7nKUDUGwsETYRT3/MSAsNlLee1AQ+dL 1cm5sL4ZAvbdSO/6WaFxv7ORCzihW6yFEJlsaSc6mCtwuu4xGNHm4bznkny/wjz9X5 IORZ97pfjIZ6Y5zy1hVu64SMtuxnp4Kl4KkOlH4JLKyjnPwwOnzY4TJ3v2V5+q9dDK bOJrWFK9EoI4Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bvvq6y14mMhCvcapxrKr2C2FYK0
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 14:50:01 -0000

On 7/16/14 4:08 AM, Christer Holmberg wrote:
> Hi BUNDLE lovers,
>
> The main remaining open issue in BUNDLE is the receiver-id, i.e. the
> mechanism for the Offerer to map received RTP/RTCP packets with the
> associated m- line  even before the SDP answer has been received.
>
> In London we more or less agreed to use Ronis app-id for this.
>
> Since then, weve had some off-line discussions with Roni, and instead
> of using app-id we suggest the following:
>
> -We use the SDP mid attribute value to map RTP/RTCP packets with m- lines
>
> -We define a new RTP header extension, and a new RTCP SDES item, for
> carrying the mid value
>
> -The RTP header extension/RTCP SDES item are generic, which means they
> can also be used with other protocols than SDP
>
> The advantage is that the SDP mid attribute already exists, the usage is
> mandatory in BUNDLE, and the value is unique for each m- line. The
> semantics also fit, as it is referencing an m- line.
>
> Some of the detailed questions we need to deal with are:
>
> Q1: The syntax of the SDP mid attribute value must fit into an RTP
> header extension of RTCP SDES item.
>
> Q2: When are the mid value sent? During Offer/Answer transaction? During
> whole session? When SSRC change?
>
> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
> directions?
>
> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>
> I intend to talk about during the MMUSIC session on Monday, but feel
> free to comment and give input on the list :)

Another question:

When the grouping framework is used, then *every* m-line must have a mid 
assigned, whether it is bundled or not, and whether the mid is necessary 
to associate media packets to m-lines or not.

Will this require the header extension and SDES item to *used* for RTP 
of every m-line? (That would be unfortunate.)

Else, what are the complete set of conditions that determine when this 
is used?

	Thanks,
	Paul


From nobody Wed Jul 16 08:10:00 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB11B1B29AF for ; Wed, 16 Jul 2014 08:09:58 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGcqyzLQZuN4 for ; Wed, 16 Jul 2014 08:09:57 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196A31B2B91 for ; Wed, 16 Jul 2014 08:09:55 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-c6-53c695c1cc69
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7D.55.04090.1C596C35; Wed, 16 Jul 2014 17:09:54 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 17:09:49 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuizRjw
Date: Wed, 16 Jul 2014 15:09:49 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8B2A@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>
In-Reply-To: <53C69110.504@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.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje6hqceCDf4v4LGYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MbSscC6YJVWx5KNDAuImvi5GTQ0LAROLi pVZ2CFtM4sK99WxdjFwcQgJHGSXmXFjPDOEsYpS4evYJSxcjBwebgIVE9z9tkAYRAV+JZ49v s4HYwgIxEp0Xm5gh4rESX/7/hLKNJH4//MoEYrMIqEpMW36JEcTmBepdNfEjmC0kkC0xbWMb mM0poCFx4NhMsIMYgQ76fmoNWC+zgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtJYsV2iPnM AjoSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlycm25k pJdalJlcXJyfp5eXWrKJERgjB7f8ttrBePC54yFGAQ5GJR7ehNZjwUKsiWXFlbmHGKU5WJTE eReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZGhIT7//Kv01ynddpP37Ok4y3haUXbZ ySyLzKJ7Rxpi+2xMeuWnrdsi8+XXhO1vzi0tfMqp+N/8xLH/5VfsUtduD4q6OXveu2Uiz7Py VC2SJymUtSfpZrCpLu723nP4fdsqJq8ppQvdNp9eY8F5PaRyT+rxs7PmfVk5e8lHsbo99pw5 /z7NXRqmxFKckWioxVxUnAgAohumPnICAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NBBWXJctWNyXS3_qW4WEpG8QsOE
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:09:59 -0000

Hi,

>> The main remaining open issue in BUNDLE is the "receiver-id", i.e. the=20
>> mechanism for the Offerer to map received RTP/RTCP packets with the=20
>> associated m- line - even before the SDP answer has been received.
>>
>> In London we more or less agreed to use Roni's app-id for this.
>>
>> Since then, we've had some off-line discussions with Roni, and instead=20
>> of using app-id we suggest the following:
>>
>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>> lines
>>
>> -We define a new RTP header extension, and a new RTCP SDES item, for=20
>> carrying the mid value
>>
>> -The RTP header extension/RTCP SDES item are generic, which means they=20
>> can also be used with other protocols than SDP
>>
>> The advantage is that the SDP mid attribute already exists, the usage=20
>> is mandatory in BUNDLE, and the value is unique for each m- line. The=20
>> semantics also fit, as it is referencing an m- line.
>>
>> Some of the detailed questions we need to deal with are:
>>
>> Q1: The syntax of the SDP mid attribute value must "fit" into an RTP=20
>> header extension of RTCP SDES item.
>>
>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>> During whole session? When SSRC change?
>>
>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>> directions?
>>
>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>
>> I intend to talk about during the MMUSIC session on Monday, but feel=20
>> free to comment and give input on the list :)
>
>
>Another question:
>
>When the grouping framework is used, then *every* m-line must have a mid a=
ssigned, whether it is >bundled or not, and whether the mid is necessary to=
 associate media packets to m-lines or not.
>
>Will this require the header extension and SDES item to *used* for RTP of =
every m-line? (That >would be unfortunate.)
>
>Else, what are the complete set of conditions that determine when this is =
used?

Good question - I'll add that.

My personal opinion is that we would use the mechanism only for RTP/RTCP as=
sociated with bundled m- lines. Non-bundled media can be mapped to m- lines=
 using their unique 5-tuple.

Regards,

Christer


From nobody Wed Jul 16 08:11:21 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C28C1B2B7E for ; Wed, 16 Jul 2014 08:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhCu0Fyv7JNR for ; Wed, 16 Jul 2014 08:11:18 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2221B2AB9 for ; Wed, 16 Jul 2014 08:11:17 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id p10so1085277wes.30 for ; Wed, 16 Jul 2014 08:11:16 -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=lTeep46SRW8i2eDe5+HVH885xMqlxfoo0m6MIH01VSo=; b=WjuQs+pZ94H8qrUzzswWe8G1uJz2eJUhxJUAiQQ4j8lRtdD1ojyVX5lnKand8e83PB VdIxzl4hslCjy80MNzc7rvCz7d49sbWk7GyNNpU3JI7SxcNy/szRiSlY35C9Ff2QfK0J WupLfkPkTBL49wgrNBwKw2T0HePNwwB11gX2vIiYsYiQlkqUgRyUBX+mG8hB6FQtp3L4 uSpV1sNIWVGuia3O7Np0KT3XnzkDDow8Ji2T6VDLNjRVluEDPGIGfDZolS00NZGfdbqg mnxjgPB1tnt052IezOfgbxmO81g1Ct798ebE8iu9obKedo8JMJ9QlRqS5MMAhag1IpSY FSJg==
MIME-Version: 1.0
X-Received: by 10.180.73.139 with SMTP id l11mr297112wiv.30.1405523476233; Wed, 16 Jul 2014 08:11:16 -0700 (PDT)
Received: by 10.194.10.201 with HTTP; Wed, 16 Jul 2014 08:11:16 -0700 (PDT)
In-Reply-To: <53C69110.504@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>
Date: Wed, 16 Jul 2014 20:41:16 +0530
Message-ID: 
From: Suhas Nandakumar 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=f46d043c07de86426904fe50efc0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BqR8zx_hVU7Ul65Cn74II4e-RkQ
Cc: mmusic WG 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:11:19 -0000

--f46d043c07de86426904fe50efc0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Paul

  Some thoughts inline.



On Wed, Jul 16, 2014 at 8:19 PM, Paul Kyzivat  wrote=
:

> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>
>> Hi BUNDLE lovers,
>>
>> The main remaining open issue in BUNDLE is the =E2=80=9Creceiver-id=E2=
=80=9D, i.e. the
>> mechanism for the Offerer to map received RTP/RTCP packets with the
>> associated m- line =E2=80=93 even before the SDP answer has been receive=
d.
>>
>> In London we more or less agreed to use Roni=E2=80=99s app-id for this.
>>
>> Since then, we=E2=80=99ve had some off-line discussions with Roni, and i=
nstead
>> of using app-id we suggest the following:
>>
>> -We use the SDP mid attribute value to map RTP/RTCP packets with m- line=
s
>>
>> -We define a new RTP header extension, and a new RTCP SDES item, for
>> carrying the mid value
>>
>> -The RTP header extension/RTCP SDES item are generic, which means they
>>
>> can also be used with other protocols than SDP
>>
>> The advantage is that the SDP mid attribute already exists, the usage is
>> mandatory in BUNDLE, and the value is unique for each m- line. The
>> semantics also fit, as it is referencing an m- line.
>>
>> Some of the detailed questions we need to deal with are:
>>
>> Q1: The syntax of the SDP mid attribute value must =E2=80=9Cfit=E2=80=9D=
 into an RTP
>> header extension of RTCP SDES item.
>>
>> Q2: When are the mid value sent? During Offer/Answer transaction? During
>> whole session? When SSRC change?
>>
>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
>> directions?
>>
>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>
>> I intend to talk about during the MMUSIC session on Monday, but feel
>> free to comment and give input on the list :)
>>
>
> Another question:
>
> When the grouping framework is used, then *every* m-line must have a mid
> assigned, whether it is bundled or not, and whether the mid is necessary =
to
> associate media packets to m-lines or not.
>
> Will this require the header extension and SDES item to *used* for RTP of
> every m-line? (That would be unfortunate.)
>
> Else, what are the complete set of conditions that determine when this is
> used?
>

[Suhas] .. I dont see a need for RTP header extension to be repeated for
all the m=3Dlines where a mid is specified. Since the purpose is to map the
incoming media packets to a m=3Dline, we need to specify the header extensi=
on
only for this requirement.

So whenever BUNDLE grouping framework is used and when PT is not enough to
map the RTP packets to a m=3D line, the implementation MUST signal (in SDP)
the RTP Header extension for all the media lines where the disambiguation
is needed and no more or less.


>         Thanks,
>         Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--f46d043c07de86426904fe50efc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Paul

=C2=A0 Some thoughts inline.



On Wed, Jul 16, 2014 at 8:19 PM, Paul Kyzivat <pkyzivat@alum.mit.=
edu> wrote:


On 7/16/14 4:08 AM, Christer=
 Holmberg wrote:



Hi BUNDLE lovers,



The main remaining open issue in BUNDLE is the =E2=80=9Creceiver-id=E2=80=
=9D, i.e. the

mechanism for the Offerer to map received RTP/RTCP packets with the

associated m- line =E2=80=93 even before the SDP answer has been received.<=
br>


In London we more or less agreed to use Roni=E2=80=99s app-id for this.



Since then, we=E2=80=99ve had some off-line discussions with Roni, and inst=
ead

of using app-id we suggest the following:



-We use the SDP mid attribute value to map RTP/RTCP packets with m- lines


-We define a new RTP header extension, and a new RTCP SDES item, for

carrying the mid value



-The RTP header extension/RTCP SDES item are generic, which means they


can also be used with other protocols than SDP



The advantage is that the SDP mid attribute already exists, the usage is
mandatory in BUNDLE, and the value is unique for each m- line. The

semantics also fit, as it is referencing an m- line.



Some of the detailed questions we need to deal with are:



Q1: The syntax of the SDP mid attribute value must =E2=80=9Cfit=E2=80=9D in=
to an RTP

header extension of RTCP SDES item.



Q2: When are the mid value sent? During Offer/Answer transaction? During
whole session? When SSRC change?



Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both

directions?



Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the

mechanism in draft-westerlund-avtext-sdes-hdr-ext?



I intend to talk about during the MMUSIC session on Monday, but feel

free to comment and give input on the list :)





Another question:



When the grouping framework is used, then *every* m-line must have a mid as=
signed, whether it is bundled or not, and whether the mid is necessary to a=
ssociate media packets to m-lines or not.



Will this require the header extension and SDES item to *used* for RTP of e=
very m-line? (That would be unfortunate.)



Else, what are the complete set of conditions that determine when this is u=
sed?

[Suhas] .. I dont see a need for R=
TP header extension to be repeated for all the m=3Dlines where a mid is spe=
cified. Since the purpose is to map the incoming media packets to a m=3Dlin=
e, we need to specify the header extension only for this requirement.=C2=A0=




So whenever BUNDLE grouping framework is used and when =
PT is not enough to map the RTP packets to a m=3D line, the implementation =
MUST signal (in SDP) the RTP Header extension for all the media lines where=
 the disambiguation is needed and no more or less.






=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul



_______________________________________________

mmusic mailing list

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





--f46d043c07de86426904fe50efc0--


From nobody Wed Jul 16 08:25:28 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D711B29A4 for ; Wed, 16 Jul 2014 08:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdF7puNbtOB8 for ; Wed, 16 Jul 2014 08:25:24 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A941B28B0 for ; Wed, 16 Jul 2014 08:25:23 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-7f-53c69961d906
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 16.C6.04090.16996C35; Wed, 16 Jul 2014 17:25:22 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 17:25:21 +0200
From: Christer Holmberg 
To: Suhas Nandakumar , Paul Kyzivat 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuirM8AgAAlB4A=
Date: Wed, 16 Jul 2014 15:25:21 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8B71@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@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.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3C8B71ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjW7SzGPBBvfm8llMXf6YxWLFhgOs FjvndjA7MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyvi2fR9TQUMPY8XF43dZ GhgXdDB2MXJySAiYSExY+4kVwhaTuHBvPVsXIxeHkMBRRonJt5+xQjiLGCX+nJwM1MHBwSZg IdH9TxukQUQgSGLuy81MIDazgLzEhSVrwGxhgRiJzotNzBA1sRJf/v9kBmkVEbCS2DfRHiTM IqAq8ebZPrByXgFfiQ9rtkCt2sQocfPxBbDjOAUCJfb/nQk2hxHouO+n1kDtEpe49WQ+E8TR AhJL9pxnhrBFJV4+/gf1jJLEiu2XGCHq8yU+3O1hhFgmKHFy5hOWCYyis5CMmoWkbBaSsllA ZzMLaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eakl mxiBUXhwy2+rHYwHnzseYhTgYFTi4U1oPRYsxJpYVlyZe4hRmoNFSZx34bl5wUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYG15fWdHhO3WFontP8hb9bz9n1y6srzxssJP7zBpOroRSccaN XfuLP9RetNNK+8iZ+vq25/v6aYxpwc9T3+0Lebkm5oGX3EU79SkFtXld522Cj01pP+vg9ejj Z85VW4Q3tppE/17Vriki9PcRV8q2ryGrRIS1pPL1frW4vszfYDnnZP2OhH5LJZbijERDLeai 4kQAnKmxhqMCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kuJG-kufax9gKkc3s_i-69a9Igo
Cc: mmusic WG 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:25:26 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D3C8B71ESESSMB209erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgU3VoYXMsDQoNCllvdSBhbHNvIHJhaXNlIGFuIGltcG9ydGFudCBwb2ludCwgd2hpY2ggSSBm
b3Jnb3QgdG8gbWVudGlvbi4NCg0KVGhlIHN1Z2dlc3Rpb24gaXMgdGhhdCBCVU5ETEUgZW50aXRp
ZXMgTVVTVCBzdXBwb3J0IHRoZSBtZWNoYW5pc20uDQoNCkhPV0VWRVIsIElGIGEgQlVORExFIGVu
dGl0eSBpcyBhYmxlIHRvIG1hcCBSVFAgYmFzZWQgb24gUFQsIGl0IHdvdWxkIHNpbXBseSBub3Qg
aW5kaWNhdGUgdXNhZ2Ugb2YgdGhlIG1lY2hhbmlzbSAodXNpbmcgdGhlIFNEUCBleHRtYXAgYXR0
cmlidXRlKS4gVGhlIHJlbW90ZSBlbnRpdHkgd291bGQgdGhlbiBOT1QgaW5jbHVkZSB0aGUgbWlk
IHZhbHVlIGluIHNlbnQgUlRQL1JUQ1AgcGFja2V0cy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN
Cg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBTdWhhcyBOYW5kYWt1bWFyDQpTZW50OiAxNiBKdWx5IDIwMTQgMTg6MTENClRvOiBQYXVs
IEt5eml2YXQNCkNjOiBtbXVzaWMgV0cNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBCVU5ETEU6IHVz
YWdlIG9mIFNEUCBtaWQgYXR0cmlidXRlIHZhbHVlIHRvIGltcGxlbWVudCAicmVjZWl2ZXItaWQi
Pw0KDQpIaSBQYXVsDQoNCiAgU29tZSB0aG91Z2h0cyBpbmxpbmUuDQoNCg0KT24gV2VkLCBKdWwg
MTYsIDIwMTQgYXQgODoxOSBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8
bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KT24gNy8xNi8xNCA0OjA4IEFN
LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCkhpIEJVTkRMRSBsb3ZlcnMsDQoNClRoZSBtYWlu
IHJlbWFpbmluZyBvcGVuIGlzc3VlIGluIEJVTkRMRSBpcyB0aGUg4oCccmVjZWl2ZXItaWTigJ0s
IGkuZS4gdGhlDQptZWNoYW5pc20gZm9yIHRoZSBPZmZlcmVyIHRvIG1hcCByZWNlaXZlZCBSVFAv
UlRDUCBwYWNrZXRzIHdpdGggdGhlDQphc3NvY2lhdGVkIG0tIGxpbmUg4oCTIGV2ZW4gYmVmb3Jl
IHRoZSBTRFAgYW5zd2VyIGhhcyBiZWVuIHJlY2VpdmVkLg0KDQpJbiBMb25kb24gd2UgbW9yZSBv
ciBsZXNzIGFncmVlZCB0byB1c2UgUm9uaeKAmXMgYXBwLWlkIGZvciB0aGlzLg0KDQpTaW5jZSB0
aGVuLCB3ZeKAmXZlIGhhZCBzb21lIG9mZi1saW5lIGRpc2N1c3Npb25zIHdpdGggUm9uaSwgYW5k
IGluc3RlYWQNCm9mIHVzaW5nIGFwcC1pZCB3ZSBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6DQotV2Ug
dXNlIHRoZSBTRFAgbWlkIGF0dHJpYnV0ZSB2YWx1ZSB0byBtYXAgUlRQL1JUQ1AgcGFja2V0cyB3
aXRoIG0tIGxpbmVzDQoNCi1XZSBkZWZpbmUgYSBuZXcgUlRQIGhlYWRlciBleHRlbnNpb24sIGFu
ZCBhIG5ldyBSVENQIFNERVMgaXRlbSwgZm9yDQpjYXJyeWluZyB0aGUgbWlkIHZhbHVlDQoNCi1U
aGUgUlRQIGhlYWRlciBleHRlbnNpb24vUlRDUCBTREVTIGl0ZW0gYXJlIGdlbmVyaWMsIHdoaWNo
IG1lYW5zIHRoZXkNCg0KY2FuIGFsc28gYmUgdXNlZCB3aXRoIG90aGVyIHByb3RvY29scyB0aGFu
IFNEUA0KDQpUaGUgYWR2YW50YWdlIGlzIHRoYXQgdGhlIFNEUCBtaWQgYXR0cmlidXRlIGFscmVh
ZHkgZXhpc3RzLCB0aGUgdXNhZ2UgaXMNCm1hbmRhdG9yeSBpbiBCVU5ETEUsIGFuZCB0aGUgdmFs
dWUgaXMgdW5pcXVlIGZvciBlYWNoIG0tIGxpbmUuIFRoZQ0Kc2VtYW50aWNzIGFsc28gZml0LCBh
cyBpdCBpcyByZWZlcmVuY2luZyBhbiBtLSBsaW5lLg0KDQpTb21lIG9mIHRoZSBkZXRhaWxlZCBx
dWVzdGlvbnMgd2UgbmVlZCB0byBkZWFsIHdpdGggYXJlOg0KDQpRMTogVGhlIHN5bnRheCBvZiB0
aGUgU0RQIG1pZCBhdHRyaWJ1dGUgdmFsdWUgbXVzdCDigJxmaXTigJ0gaW50byBhbiBSVFANCmhl
YWRlciBleHRlbnNpb24gb2YgUlRDUCBTREVTIGl0ZW0uDQoNClEyOiBXaGVuIGFyZSB0aGUgbWlk
IHZhbHVlIHNlbnQ/IER1cmluZyBPZmZlci9BbnN3ZXIgdHJhbnNhY3Rpb24/IER1cmluZw0Kd2hv
bGUgc2Vzc2lvbj8gV2hlbiBTU1JDIGNoYW5nZT8NCg0KUTM6IERvIHdlLCBmb3IgQlVORExFIHVz
YWdlLCBhbGxvdyB1c2FnZSBvZiB0aGUgbWVjaGFuaXNtIGluIGJvdGgNCmRpcmVjdGlvbnM/DQoN
ClE0OiBEbyB3ZSBjYXJyeSB0aGUgUlRDUCBTREVTIGl0ZW0gaW4gUlRDUCwgb3IgaW4gUlRQIHVz
aW5nIHRoZQ0KbWVjaGFuaXNtIGluIGRyYWZ0LXdlc3Rlcmx1bmQtYXZ0ZXh0LXNkZXMtaGRyLWV4
dD8NCg0KSSBpbnRlbmQgdG8gdGFsayBhYm91dCBkdXJpbmcgdGhlIE1NVVNJQyBzZXNzaW9uIG9u
IE1vbmRheSwgYnV0IGZlZWwNCmZyZWUgdG8gY29tbWVudCBhbmQgZ2l2ZSBpbnB1dCBvbiB0aGUg
bGlzdCA6KQ0KDQpBbm90aGVyIHF1ZXN0aW9uOg0KDQpXaGVuIHRoZSBncm91cGluZyBmcmFtZXdv
cmsgaXMgdXNlZCwgdGhlbiAqZXZlcnkqIG0tbGluZSBtdXN0IGhhdmUgYSBtaWQgYXNzaWduZWQs
IHdoZXRoZXIgaXQgaXMgYnVuZGxlZCBvciBub3QsIGFuZCB3aGV0aGVyIHRoZSBtaWQgaXMgbmVj
ZXNzYXJ5IHRvIGFzc29jaWF0ZSBtZWRpYSBwYWNrZXRzIHRvIG0tbGluZXMgb3Igbm90Lg0KDQpX
aWxsIHRoaXMgcmVxdWlyZSB0aGUgaGVhZGVyIGV4dGVuc2lvbiBhbmQgU0RFUyBpdGVtIHRvICp1
c2VkKiBmb3IgUlRQIG9mIGV2ZXJ5IG0tbGluZT8gKFRoYXQgd291bGQgYmUgdW5mb3J0dW5hdGUu
KQ0KDQpFbHNlLCB3aGF0IGFyZSB0aGUgY29tcGxldGUgc2V0IG9mIGNvbmRpdGlvbnMgdGhhdCBk
ZXRlcm1pbmUgd2hlbiB0aGlzIGlzIHVzZWQ/DQoNCltTdWhhc10gLi4gSSBkb250IHNlZSBhIG5l
ZWQgZm9yIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIHRvIGJlIHJlcGVhdGVkIGZvciBhbGwgdGhlIG09
bGluZXMgd2hlcmUgYSBtaWQgaXMgc3BlY2lmaWVkLiBTaW5jZSB0aGUgcHVycG9zZSBpcyB0byBt
YXAgdGhlIGluY29taW5nIG1lZGlhIHBhY2tldHMgdG8gYSBtPWxpbmUsIHdlIG5lZWQgdG8gc3Bl
Y2lmeSB0aGUgaGVhZGVyIGV4dGVuc2lvbiBvbmx5IGZvciB0aGlzIHJlcXVpcmVtZW50Lg0KDQpT
byB3aGVuZXZlciBCVU5ETEUgZ3JvdXBpbmcgZnJhbWV3b3JrIGlzIHVzZWQgYW5kIHdoZW4gUFQg
aXMgbm90IGVub3VnaCB0byBtYXAgdGhlIFJUUCBwYWNrZXRzIHRvIGEgbT0gbGluZSwgdGhlIGlt
cGxlbWVudGF0aW9uIE1VU1Qgc2lnbmFsIChpbiBTRFApIHRoZSBSVFAgSGVhZGVyIGV4dGVuc2lv
biBmb3IgYWxsIHRoZSBtZWRpYSBsaW5lcyB3aGVyZSB0aGUgZGlzYW1iaWd1YXRpb24gaXMgbmVl
ZGVkIGFuZCBubyBtb3JlIG9yIGxlc3MuDQoNCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBh
dWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1t
dXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K

--_000_7594FB04B1934943A5C02806D1A2204B1D3C8B71ESESSMB209erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu
MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I
aSBTdWhhcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMiPllvdSBhbHNvIHJhaXNlIGFuIGltcG9ydGFudCBwb2ludCwgd2hpY2gg
SSBmb3Jnb3QgdG8gbWVudGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBzdWdnZXN0aW9uIGlzIHRoYXQgQlVORExF
IGVudGl0aWVzIE1VU1Qgc3VwcG9ydCB0aGUgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SE9XRVZFUiwgSUYg
YSBCVU5ETEUgZW50aXR5IGlzIGFibGUgdG8gbWFwIFJUUCBiYXNlZCBvbiBQVCwgaXQgd291bGQg
c2ltcGx5IG5vdCBpbmRpY2F0ZSB1c2FnZSBvZiB0aGUgbWVjaGFuaXNtICh1c2luZyB0aGUgU0RQ
IGV4dG1hcA0KIGF0dHJpYnV0ZSkuIFRoZSByZW1vdGUgZW50aXR5IHdvdWxkIHRoZW4gTk9UIGlu
Y2x1ZGUgdGhlIG1pZCB2YWx1ZSBpbiBzZW50IFJUUC9SVENQIHBhY2tldHMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdh
cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtbXVzaWMgW21haWx0bzptbXVzaWMt
Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VoYXMgTmFuZGFrdW1hcjxi
cj4NCjxiPlNlbnQ6PC9iPiAxNiBKdWx5IDIwMTQgMTg6MTE8YnI+DQo8Yj5Ubzo8L2I+IFBhdWwg
S3l6aXZhdDxicj4NCjxiPkNjOjwvYj4gbW11c2ljIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbTU1VU0lDXSBCVU5ETEU6IHVzYWdlIG9mIFNEUCBtaWQgYXR0cmlidXRlIHZhbHVlIHRvIGlt
cGxlbWVudCAmcXVvdDtyZWNlaXZlci1pZCZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IaSBQYXVsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsgU29tZSB0aG91Z2h0cyBpbmxpbmUuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gV2VkLCBKdWwgMTYsIDIwMTQgYXQgODoxOSBQTSwgUGF1bCBLeXppdmF0ICZsdDs8YSBo
cmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+cGt5eml2
YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcvMTYvMTQgNDowOCBBTSwgQ2hyaXN0
ZXIgSG9sbWJlcmcgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I
aSBCVU5ETEUgbG92ZXJzLDxicj4NCjxicj4NClRoZSBtYWluIHJlbWFpbmluZyBvcGVuIGlzc3Vl
IGluIEJVTkRMRSBpcyB0aGUg4oCccmVjZWl2ZXItaWTigJ0sIGkuZS4gdGhlPGJyPg0KbWVjaGFu
aXNtIGZvciB0aGUgT2ZmZXJlciB0byBtYXAgcmVjZWl2ZWQgUlRQL1JUQ1AgcGFja2V0cyB3aXRo
IHRoZTxicj4NCmFzc29jaWF0ZWQgbS0gbGluZSDigJMgZXZlbiBiZWZvcmUgdGhlIFNEUCBhbnN3
ZXIgaGFzIGJlZW4gcmVjZWl2ZWQuPGJyPg0KPGJyPg0KSW4gTG9uZG9uIHdlIG1vcmUgb3IgbGVz
cyBhZ3JlZWQgdG8gdXNlIFJvbmnigJlzIGFwcC1pZCBmb3IgdGhpcy48YnI+DQo8YnI+DQpTaW5j
ZSB0aGVuLCB3ZeKAmXZlIGhhZCBzb21lIG9mZi1saW5lIGRpc2N1c3Npb25zIHdpdGggUm9uaSwg
YW5kIGluc3RlYWQ8YnI+DQpvZiB1c2luZyBhcHAtaWQgd2Ugc3VnZ2VzdCB0aGUgZm9sbG93aW5n
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tV2UgdXNlIHRo
ZSBTRFAgbWlkIGF0dHJpYnV0ZSB2YWx1ZSB0byBtYXAgUlRQL1JUQ1AgcGFja2V0cyB3aXRoIG0t
IGxpbmVzPGJyPg0KPGJyPg0KLVdlIGRlZmluZSBhIG5ldyBSVFAgaGVhZGVyIGV4dGVuc2lvbiwg
YW5kIGEgbmV3IFJUQ1AgU0RFUyBpdGVtLCBmb3I8YnI+DQpjYXJyeWluZyB0aGUgbWlkIHZhbHVl
PGJyPg0KPGJyPg0KLVRoZSBSVFAgaGVhZGVyIGV4dGVuc2lvbi9SVENQIFNERVMgaXRlbSBhcmUg
Z2VuZXJpYywgd2hpY2ggbWVhbnMgdGhleTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCmNhbiBhbHNvIGJlIHVzZWQgd2l0aCBvdGhlciBwcm90b2NvbHMg
dGhhbiBTRFA8YnI+DQo8YnI+DQpUaGUgYWR2YW50YWdlIGlzIHRoYXQgdGhlIFNEUCBtaWQgYXR0
cmlidXRlIGFscmVhZHkgZXhpc3RzLCB0aGUgdXNhZ2UgaXM8YnI+DQptYW5kYXRvcnkgaW4gQlVO
RExFLCBhbmQgdGhlIHZhbHVlIGlzIHVuaXF1ZSBmb3IgZWFjaCBtLSBsaW5lLiBUaGU8YnI+DQpz
ZW1hbnRpY3MgYWxzbyBmaXQsIGFzIGl0IGlzIHJlZmVyZW5jaW5nIGFuIG0tIGxpbmUuPGJyPg0K
PGJyPg0KU29tZSBvZiB0aGUgZGV0YWlsZWQgcXVlc3Rpb25zIHdlIG5lZWQgdG8gZGVhbCB3aXRo
IGFyZTo8YnI+DQo8YnI+DQpRMTogVGhlIHN5bnRheCBvZiB0aGUgU0RQIG1pZCBhdHRyaWJ1dGUg
dmFsdWUgbXVzdCDigJxmaXTigJ0gaW50byBhbiBSVFA8YnI+DQpoZWFkZXIgZXh0ZW5zaW9uIG9m
IFJUQ1AgU0RFUyBpdGVtLjxicj4NCjxicj4NClEyOiBXaGVuIGFyZSB0aGUgbWlkIHZhbHVlIHNl
bnQ/IER1cmluZyBPZmZlci9BbnN3ZXIgdHJhbnNhY3Rpb24/IER1cmluZzxicj4NCndob2xlIHNl
c3Npb24/IFdoZW4gU1NSQyBjaGFuZ2U/PGJyPg0KPGJyPg0KUTM6IERvIHdlLCBmb3IgQlVORExF
IHVzYWdlLCBhbGxvdyB1c2FnZSBvZiB0aGUgbWVjaGFuaXNtIGluIGJvdGg8YnI+DQpkaXJlY3Rp
b25zPzxicj4NCjxicj4NClE0OiBEbyB3ZSBjYXJyeSB0aGUgUlRDUCBTREVTIGl0ZW0gaW4gUlRD
UCwgb3IgaW4gUlRQIHVzaW5nIHRoZTxicj4NCm1lY2hhbmlzbSBpbiBkcmFmdC13ZXN0ZXJsdW5k
LWF2dGV4dC1zZGVzLWhkci1leHQ/PGJyPg0KPGJyPg0KSSBpbnRlbmQgdG8gdGFsayBhYm91dCBk
dXJpbmcgdGhlIE1NVVNJQyBzZXNzaW9uIG9uIE1vbmRheSwgYnV0IGZlZWw8YnI+DQpmcmVlIHRv
IGNvbW1lbnQgYW5kIGdpdmUgaW5wdXQgb24gdGhlIGxpc3QgOik8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQW5vdGhlciBx
dWVzdGlvbjo8YnI+DQo8YnI+DQpXaGVuIHRoZSBncm91cGluZyBmcmFtZXdvcmsgaXMgdXNlZCwg
dGhlbiAqZXZlcnkqIG0tbGluZSBtdXN0IGhhdmUgYSBtaWQgYXNzaWduZWQsIHdoZXRoZXIgaXQg
aXMgYnVuZGxlZCBvciBub3QsIGFuZCB3aGV0aGVyIHRoZSBtaWQgaXMgbmVjZXNzYXJ5IHRvIGFz
c29jaWF0ZSBtZWRpYSBwYWNrZXRzIHRvIG0tbGluZXMgb3Igbm90Ljxicj4NCjxicj4NCldpbGwg
dGhpcyByZXF1aXJlIHRoZSBoZWFkZXIgZXh0ZW5zaW9uIGFuZCBTREVTIGl0ZW0gdG8gKnVzZWQq
IGZvciBSVFAgb2YgZXZlcnkgbS1saW5lPyAoVGhhdCB3b3VsZCBiZSB1bmZvcnR1bmF0ZS4pPGJy
Pg0KPGJyPg0KRWxzZSwgd2hhdCBhcmUgdGhlIGNvbXBsZXRlIHNldCBvZiBjb25kaXRpb25zIHRo
YXQgZGV0ZXJtaW5lIHdoZW4gdGhpcyBpcyB1c2VkPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1N1aGFzXSAuLiBJIGRvbnQgc2Vl
IGEgbmVlZCBmb3IgUlRQIGhlYWRlciBleHRlbnNpb24gdG8gYmUgcmVwZWF0ZWQgZm9yIGFsbCB0
aGUgbT1saW5lcyB3aGVyZSBhIG1pZCBpcyBzcGVjaWZpZWQuIFNpbmNlIHRoZSBwdXJwb3NlIGlz
IHRvIG1hcCB0aGUgaW5jb21pbmcgbWVkaWEgcGFja2V0cyB0byBhIG09bGluZSwgd2UgbmVlZCB0
byBzcGVjaWZ5IHRoZSBoZWFkZXIgZXh0ZW5zaW9uIG9ubHkgZm9yIHRoaXMNCiByZXF1aXJlbWVu
dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+U28gd2hlbmV2ZXIgQlVORExFIGdyb3VwaW5nIGZyYW1ld29yayBpcyB1c2VkIGFuZCB3
aGVuIFBUIGlzIG5vdCBlbm91Z2ggdG8gbWFwIHRoZSBSVFAgcGFja2V0cyB0byBhIG09IGxpbmUs
IHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIHNpZ25hbCAoaW4gU0RQKSB0aGUgUlRQIEhlYWRlciBl
eHRlbnNpb24gZm9yIGFsbCB0aGUgbWVkaWEgbGluZXMgd2hlcmUgdGhlIGRpc2FtYmlndWF0aW9u
IGlzIG5lZWRlZCBhbmQNCiBubyBtb3JlIG9yIGxlc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBh
dWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bW11c2lj
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B1D3C8B71ESESSMB209erics_--


From nobody Wed Jul 16 08:27:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6981B29A4 for ; Wed, 16 Jul 2014 08:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APSznBms92kQ for ; Wed, 16 Jul 2014 08:27:03 -0700 (PDT)
Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5968F1A03F8 for ; Wed, 16 Jul 2014 08:27:03 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/16/2014 11:27:01 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-226/SG:2 7/16/2014 11:27:00 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.891184 p=-0.980698 Source White
X-Signature-Violations: 0-0-0-7521-c
X-Note-419: 15.6004 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/16/2014 11:26:53 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail2.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 113322998; Wed, 16 Jul 2014 11:27:01 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 16 Jul 2014 10:26:59 -0500
From: Jonathan Lennox 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQi4z+ymwa9k3km9HO4Fqr7VRZujJoMA
Date: Wed, 16 Jul 2014 15:26:58 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>
In-Reply-To: <53C69110.504@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [206.104.135.61]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <39EB6A1C7F692943BB0B809D320FF359@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f0d3zjpnU3vbcgipBXOx6kmYCOE
Cc: mmusic 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:27:05 -0000

On Jul 16, 2014, at 10:49 AM, Paul Kyzivat  wrote:

> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>> Hi BUNDLE lovers,
>>=20
>> The main remaining open issue in BUNDLE is the =93receiver-id=94, i.e. t=
he
>> mechanism for the Offerer to map received RTP/RTCP packets with the
>> associated m- line =96 even before the SDP answer has been received.
>>=20
>> In London we more or less agreed to use Roni=92s app-id for this.
>>=20
>> Since then, we=92ve had some off-line discussions with Roni, and instead
>> of using app-id we suggest the following:
>>=20
>> -We use the SDP mid attribute value to map RTP/RTCP packets with m- line=
s
>>=20
>> -We define a new RTP header extension, and a new RTCP SDES item, for
>> carrying the mid value
>>=20
>> -The RTP header extension/RTCP SDES item are generic, which means they
>> can also be used with other protocols than SDP
>>=20
>> The advantage is that the SDP mid attribute already exists, the usage is
>> mandatory in BUNDLE, and the value is unique for each m- line. The
>> semantics also fit, as it is referencing an m- line.
>>=20
>> Some of the detailed questions we need to deal with are:
>>=20
>> Q1: The syntax of the SDP mid attribute value must =93fit=94 into an RTP
>> header extension of RTCP SDES item.
>>=20
>> Q2: When are the mid value sent? During Offer/Answer transaction? During
>> whole session? When SSRC change?
>>=20
>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
>> directions?
>>=20
>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>=20
>> I intend to talk about during the MMUSIC session on Monday, but feel
>> free to comment and give input on the list :)
>=20
> Another question:
>=20
> When the grouping framework is used, then *every* m-line must have a mid =
assigned, whether it is bundled or not, and whether the mid is necessary to=
 associate media packets to m-lines or not.
>=20
> Will this require the header extension and SDES item to *used* for RTP of=
 every m-line? (That would be unfortunate.)
>=20
> Else, what are the complete set of conditions that determine when this is=
 used?

I was part of the offline discussion that contributed to this (as co-author=
 of the appid draft), and my understanding of the discussion was as follows=
:

An m-line group would carry an =93a=3Drtcp-mid=94 attribute to indicate tha=
t the mid would be sent in RTCP, and also an appropriate a=3Dextmap attribu=
te (URL to be determined) to indicate that the mid would also be sent in a =
header extension.

This attribute is included in SDP to explicitly indicate that you are sendi=
ng mids in RTP/RTCP; including the attribute is mandatory when you are usin=
g BUNDLE with overlapping payload types.  (Optional otherwise, I suppose, t=
hough this wasn=92t discussed.)


Another important issue: POF/PAN wants to mandate that mid values are long,=
 to minimize the possibility of mid collisions between simultaneous partial=
 offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short, s=
o they fit in RTP header extensions with minimal overhead.  Is there a way =
we can reconcile these requirements?


From nobody Wed Jul 16 08:36:53 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DB91B2BA0 for ; Wed, 16 Jul 2014 08:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTd6Yn5oMkrP for ; Wed, 16 Jul 2014 08:36:48 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4E01B2B85 for ; Wed, 16 Jul 2014 08:36:48 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-4b-53c69c0e0bc6
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 01.F7.04090.E0C96C35; Wed, 16 Jul 2014 17:36:46 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 17:36:46 +0200
From: Christer Holmberg 
To: Jonathan Lennox , Paul Kyzivat 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuisTIAgAAir2A=
Date: Wed, 16 Jul 2014 15:36:46 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@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.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+JvjS7fnGPBBoe3aVrsX3ye2WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPNqe3WEPYI7isklJzcksSy3St0vgyniwuY2p4IJ8Rf+SV4wN jDsluxg5OSQETCRa7qxmhLDFJC7cW88GYgsJHGWU2D/XAcJexChxvVu7i5GDg03AQqL7nzZI WETAT+Jl/zcmEJtZQEZixtlGMFtYIEai82ITM0RNrMSX/z+hbCuJW6+fga1iEVCVeLViBpjN K+Ar0bNxIksXIxfQqjmMEjvnP2YFSXAK2Er83tcAdg8j0G3fT62BWiYucevJfCaImwUkluw5 zwxhi0q8fPyPFcJWklix/RIjRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG1MEtv612MB587niIUYCDUYmH N6H1WLAQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDkf/rn esX/HRLHZ97nDEkzPiYocvD+601nyn9Mn7J/lpPG6vu5ba2R8qV7eOfmP/e+/JCB+6p7ROmJ SVPOsuQ9TIo+e31B64ZDrY+zIxqXbKvYmnJ5T7LBbrZTDx6Zua58Hvd6woeE5Q2N35PXzksw d15ozvc+1frobuvDgjEX7QxDq56vlFulo8RSnJFoqMVcVJwIAImM+g6JAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/U73E2rGXmz2XSYgUdkltyW-vCc0
Cc: mmusic 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:36:50 -0000

Hi Jonathan,

My suggestion was to use the a=3Dmid attribute - not to define a new a=3Drt=
cp-mid attribute.

But, of course, if the mid values will be too big (I have expressed some is=
sues on the suggested POF/PAN usage of the mid values) to carry in RTP/RTCP=
, I guess we have to consider something else.

Regards,

Christer


-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lennox
Sent: 16 July 2014 18:27
To: Paul Kyzivat
Cc: mmusic
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement=
 "receiver-id"?


On Jul 16, 2014, at 10:49 AM, Paul Kyzivat  wrote:

> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>> Hi BUNDLE lovers,
>>=20
>> The main remaining open issue in BUNDLE is the "receiver-id", i.e.=20
>> the mechanism for the Offerer to map received RTP/RTCP packets with=20
>> the associated m- line - even before the SDP answer has been received.
>>=20
>> In London we more or less agreed to use Roni's app-id for this.
>>=20
>> Since then, we've had some off-line discussions with Roni, and=20
>> instead of using app-id we suggest the following:
>>=20
>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>> lines
>>=20
>> -We define a new RTP header extension, and a new RTCP SDES item, for=20
>> carrying the mid value
>>=20
>> -The RTP header extension/RTCP SDES item are generic, which means=20
>> they can also be used with other protocols than SDP
>>=20
>> The advantage is that the SDP mid attribute already exists, the usage=20
>> is mandatory in BUNDLE, and the value is unique for each m- line. The=20
>> semantics also fit, as it is referencing an m- line.
>>=20
>> Some of the detailed questions we need to deal with are:
>>=20
>> Q1: The syntax of the SDP mid attribute value must "fit" into an RTP=20
>> header extension of RTCP SDES item.
>>=20
>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>> During whole session? When SSRC change?
>>=20
>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>> directions?
>>=20
>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>=20
>> I intend to talk about during the MMUSIC session on Monday, but feel=20
>> free to comment and give input on the list :)
>=20
> Another question:
>=20
> When the grouping framework is used, then *every* m-line must have a mid =
assigned, whether it is bundled or not, and whether the mid is necessary to=
 associate media packets to m-lines or not.
>=20
> Will this require the header extension and SDES item to *used* for RTP=20
> of every m-line? (That would be unfortunate.)
>=20
> Else, what are the complete set of conditions that determine when this is=
 used?

I was part of the offline discussion that contributed to this (as co-author=
 of the appid draft), and my understanding of the discussion was as follows=
:

An m-line group would carry an "a=3Drtcp-mid" attribute to indicate that th=
e mid would be sent in RTCP, and also an appropriate a=3Dextmap attribute (=
URL to be determined) to indicate that the mid would also be sent in a head=
er extension.

This attribute is included in SDP to explicitly indicate that you are sendi=
ng mids in RTP/RTCP; including the attribute is mandatory when you are usin=
g BUNDLE with overlapping payload types.  (Optional otherwise, I suppose, t=
hough this wasn't discussed.)


Another important issue: POF/PAN wants to mandate that mid values are long,=
 to minimize the possibility of mid collisions between simultaneous partial=
 offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short, s=
o they fit in RTP header extensions with minimal overhead.  Is there a way =
we can reconcile these requirements?

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


From nobody Wed Jul 16 08:41:22 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7F31B2BA8 for ; Wed, 16 Jul 2014 08:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzpDtAtDDJrf for ; Wed, 16 Jul 2014 08:41:19 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA961B2B99 for ; Wed, 16 Jul 2014 08:41:18 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/16/2014 11:41:17 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-188/SG:2 7/16/2014 11:41:00 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.892173 p=-0.980883 Source White
X-Signature-Violations: 0-0-0-10401-c
X-Note-419: 15.6004 ms. Fail:1 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:1-1335/SG:1 7/16/2014 11:41:13 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail2.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 113330628; Wed, 16 Jul 2014 11:41:17 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 16 Jul 2014 10:41:16 -0500
From: Jonathan Lennox 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQi4z+ymwa9k3km9HO4Fqr7VRZujJoMAgAACvQCAAAFBgA==
Date: Wed, 16 Jul 2014 15:41:16 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [206.104.135.61]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/70u3noUdlNSqMvo9y_6gHtoc9YU
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:41:20 -0000

In my suggestion, a=3Dmid still contains the value.  a=3Drtcp-mid is a flag=
 attribute (i.e., not containing any content) that simply indicates that th=
e mid values will indeed be sent in RTCP.

I don=92t think simply splitting the mid correlator into a separate value f=
rom a=3Dmid would solve the POF/PAN problem.  The correlators need to be un=
ique, but in POF/PAN you have the possibility of collision between simultan=
eous partial offers.

On Jul 16, 2014, at 11:36 AM, Christer Holmberg  wrote:

> Hi Jonathan,
>=20
> My suggestion was to use the a=3Dmid attribute - not to define a new a=3D=
rtcp-mid attribute.
>=20
> But, of course, if the mid values will be too big (I have expressed some =
issues on the suggested POF/PAN usage of the mid values) to carry in RTP/RT=
CP, I guess we have to consider something else.
>=20
> Regards,
>=20
> Christer
>=20
>=20
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lenno=
x
> Sent: 16 July 2014 18:27
> To: Paul Kyzivat
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to impleme=
nt "receiver-id"?
>=20
>=20
> On Jul 16, 2014, at 10:49 AM, Paul Kyzivat  wrote:
>=20
>> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>>> Hi BUNDLE lovers,
>>>=20
>>> The main remaining open issue in BUNDLE is the "receiver-id", i.e.=20
>>> the mechanism for the Offerer to map received RTP/RTCP packets with=20
>>> the associated m- line - even before the SDP answer has been received.
>>>=20
>>> In London we more or less agreed to use Roni's app-id for this.
>>>=20
>>> Since then, we've had some off-line discussions with Roni, and=20
>>> instead of using app-id we suggest the following:
>>>=20
>>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>>> lines
>>>=20
>>> -We define a new RTP header extension, and a new RTCP SDES item, for=20
>>> carrying the mid value
>>>=20
>>> -The RTP header extension/RTCP SDES item are generic, which means=20
>>> they can also be used with other protocols than SDP
>>>=20
>>> The advantage is that the SDP mid attribute already exists, the usage=20
>>> is mandatory in BUNDLE, and the value is unique for each m- line. The=20
>>> semantics also fit, as it is referencing an m- line.
>>>=20
>>> Some of the detailed questions we need to deal with are:
>>>=20
>>> Q1: The syntax of the SDP mid attribute value must "fit" into an RTP=20
>>> header extension of RTCP SDES item.
>>>=20
>>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>>> During whole session? When SSRC change?
>>>=20
>>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>>> directions?
>>>=20
>>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>>=20
>>> I intend to talk about during the MMUSIC session on Monday, but feel=20
>>> free to comment and give input on the list :)
>>=20
>> Another question:
>>=20
>> When the grouping framework is used, then *every* m-line must have a mid=
 assigned, whether it is bundled or not, and whether the mid is necessary t=
o associate media packets to m-lines or not.
>>=20
>> Will this require the header extension and SDES item to *used* for RTP=20
>> of every m-line? (That would be unfortunate.)
>>=20
>> Else, what are the complete set of conditions that determine when this i=
s used?
>=20
> I was part of the offline discussion that contributed to this (as co-auth=
or of the appid draft), and my understanding of the discussion was as follo=
ws:
>=20
> An m-line group would carry an "a=3Drtcp-mid" attribute to indicate that =
the mid would be sent in RTCP, and also an appropriate a=3Dextmap attribute=
 (URL to be determined) to indicate that the mid would also be sent in a he=
ader extension.
>=20
> This attribute is included in SDP to explicitly indicate that you are sen=
ding mids in RTP/RTCP; including the attribute is mandatory when you are us=
ing BUNDLE with overlapping payload types.  (Optional otherwise, I suppose,=
 though this wasn't discussed.)
>=20
>=20
> Another important issue: POF/PAN wants to mandate that mid values are lon=
g, to minimize the possibility of mid collisions between simultaneous parti=
al offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short,=
 so they fit in RTP header extensions with minimal overhead.  Is there a wa=
y we can reconcile these requirements?
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Wed Jul 16 08:44:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D441B2BA2 for ; Wed, 16 Jul 2014 08:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m_Lb2zkYyDu for ; Wed, 16 Jul 2014 08:44:07 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B4B1B2B9D for ; Wed, 16 Jul 2014 08:44:06 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-90-53c69dc44697
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.56.03739.4CD96C35; Wed, 16 Jul 2014 17:44:04 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 17:44:04 +0200
From: Christer Holmberg 
To: Jonathan Lennox 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuisTIAgAAir2D//+FPAIAAIckQ
Date: Wed, 16 Jul 2014 15:44:03 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8C09@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@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.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje6RuceCDfon6ljsX3ye2WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPNqe3WEPYI7isklJzcksSy3St0vgyuh695mx4I1axZf+/6wN jLPkuxg5OSQETCTuH7jJAmGLSVy4t56ti5GLQ0jgKKPE4Qvr2CGcRYwS36fOAqri4GATsJDo /qcN0iAioCFx8dkHNhCbWcBJ4lrXS2YQW1ggRqLzYhMzRE2sxJf/P6FsN4m10+aC2SwCqhIb Fv0Ds3kFfCXuHGuB2jWZSeL9i6+sIAlOAVuJz5OWghUxAl33/dQaJohl4hK3nsxngrhaQGLJ nvPMELaoxMvH/1ghbCWJFdsvMULU60gs2P0J6lBtiWULX0MtFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRG1cEtv3V3MK5+7XiIUYCDUYmH VyHnaLAQa2JZcWXuIUZpDhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBM/fAo YXNn9vHsBxU1Jub2NsIvf3NOeqni/y+/nndvwSnNN1YPdxlLf1y+uenD6mOfg9P4VBf9VVu7 bvmPHwmTFqyo0Pf1c7U7ca/ca/qG+FkRWSbvkio/n6lLTZS/eCH12fHMiy1KAm+vnF9lNW9H XdG6Be8X3lEPkrN+vner66r1J1/kVx/2UmIpzkg01GIuKk4EAJZFSx6LAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-GYbx80FvIgeipbTSOKoi5UyLm0
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:44:09 -0000

Hi,

>In my suggestion, a=3Dmid still contains the value.  a=3Drtcp-mid is a fla=
g attribute (i.e., not containing >any content) that simply indicates that =
the mid values will indeed be sent in RTCP.

Ok, I get it. But, why can't we use the a=3Dextmap attribute to indicate th=
at the value will be sent both in RTCP and RTP? Do we want to be able to ch=
oose?

Regards,

Christer





I don't think simply splitting the mid correlator into a separate value fro=
m a=3Dmid would solve the POF/PAN problem.  The correlators need to be uniq=
ue, but in POF/PAN you have the possibility of collision between simultaneo=
us partial offers.

On Jul 16, 2014, at 11:36 AM, Christer Holmberg  wrote:

> Hi Jonathan,
>=20
> My suggestion was to use the a=3Dmid attribute - not to define a new a=3D=
rtcp-mid attribute.
>=20
> But, of course, if the mid values will be too big (I have expressed some =
issues on the suggested POF/PAN usage of the mid values) to carry in RTP/RT=
CP, I guess we have to consider something else.
>=20
> Regards,
>=20
> Christer
>=20
>=20
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan=20
> Lennox
> Sent: 16 July 2014 18:27
> To: Paul Kyzivat
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to impleme=
nt "receiver-id"?
>=20
>=20
> On Jul 16, 2014, at 10:49 AM, Paul Kyzivat  wrote:
>=20
>> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>>> Hi BUNDLE lovers,
>>>=20
>>> The main remaining open issue in BUNDLE is the "receiver-id", i.e.=20
>>> the mechanism for the Offerer to map received RTP/RTCP packets with=20
>>> the associated m- line - even before the SDP answer has been received.
>>>=20
>>> In London we more or less agreed to use Roni's app-id for this.
>>>=20
>>> Since then, we've had some off-line discussions with Roni, and=20
>>> instead of using app-id we suggest the following:
>>>=20
>>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>>> lines
>>>=20
>>> -We define a new RTP header extension, and a new RTCP SDES item, for=20
>>> carrying the mid value
>>>=20
>>> -The RTP header extension/RTCP SDES item are generic, which means=20
>>> they can also be used with other protocols than SDP
>>>=20
>>> The advantage is that the SDP mid attribute already exists, the=20
>>> usage is mandatory in BUNDLE, and the value is unique for each m-=20
>>> line. The semantics also fit, as it is referencing an m- line.
>>>=20
>>> Some of the detailed questions we need to deal with are:
>>>=20
>>> Q1: The syntax of the SDP mid attribute value must "fit" into an RTP=20
>>> header extension of RTCP SDES item.
>>>=20
>>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>>> During whole session? When SSRC change?
>>>=20
>>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>>> directions?
>>>=20
>>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>>=20
>>> I intend to talk about during the MMUSIC session on Monday, but feel=20
>>> free to comment and give input on the list :)
>>=20
>> Another question:
>>=20
>> When the grouping framework is used, then *every* m-line must have a mid=
 assigned, whether it is bundled or not, and whether the mid is necessary t=
o associate media packets to m-lines or not.
>>=20
>> Will this require the header extension and SDES item to *used* for=20
>> RTP of every m-line? (That would be unfortunate.)
>>=20
>> Else, what are the complete set of conditions that determine when this i=
s used?
>=20
> I was part of the offline discussion that contributed to this (as co-auth=
or of the appid draft), and my understanding of the discussion was as follo=
ws:
>=20
> An m-line group would carry an "a=3Drtcp-mid" attribute to indicate that =
the mid would be sent in RTCP, and also an appropriate a=3Dextmap attribute=
 (URL to be determined) to indicate that the mid would also be sent in a he=
ader extension.
>=20
> This attribute is included in SDP to explicitly indicate that you are=20
> sending mids in RTP/RTCP; including the attribute is mandatory when=20
> you are using BUNDLE with overlapping payload types.  (Optional=20
> otherwise, I suppose, though this wasn't discussed.)
>=20
>=20
> Another important issue: POF/PAN wants to mandate that mid values are lon=
g, to minimize the possibility of mid collisions between simultaneous parti=
al offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short,=
 so they fit in RTP header extensions with minimal overhead.  Is there a wa=
y we can reconcile these requirements?
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Wed Jul 16 08:53:52 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9892C1B2A93 for ; Wed, 16 Jul 2014 08:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmhmuBftliYT for ; Wed, 16 Jul 2014 08:53:49 -0700 (PDT)
Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911C81A04A1 for ; Wed, 16 Jul 2014 08:53:48 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/16/2014 11:53:47 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-176/SG:2 7/16/2014 11:53:04 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.853408 p=-0.977215 Source White
X-Signature-Violations: 0-0-0-12983-c
X-Note-419: 15.6007 ms. Fail:1 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:1-1335/SG:1 7/16/2014 11:53:30 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 139771045; Wed, 16 Jul 2014 11:53:47 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 16 Jul 2014 10:53:45 -0500
From: Jonathan Lennox 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQi4z+ymwa9k3km9HO4Fqr7VRZujJoMAgAACvQCAAAFBgIAAAMiAgAACtoA=
Date: Wed, 16 Jul 2014 15:53:45 +0000
Message-ID: <697B252B-B666-47CD-8829-ECCCC2BE0977@vidyo.com>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D3C8C09@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3C8C09@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [206.104.135.61]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <4C9B9C5BE8496B4396ABDDFEE7394392@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V65D-f8vQwHE5ybyIuCyNy3xFmo
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 15:53:51 -0000

I see three possible states:

1. Mid will not be sent at all.  This is what is indicated by current signa=
ling, implicitly.
2. Mid will be sent in RTCP, but not RTP.
3. Mid will be sent in RTCP and RTP both.

(I don=92t think we want to allow mid in RTP but not in RTCP.)

In my suggestion, if you don=92t say anything, it means #1.  #2 is indicate=
d by a=3Drtcp-mid, and #3 is indicated by a=3Drtcp-mid and a=3Dextmap.

Unless you want to say that the BUNDLE group semantic implicitly implies ei=
ther #2 or #3 (always?  Iff overlapping payload types?), I don=92t think it=
=92s a good idea to start sending a new mechanism at the media layer withou=
t some SDP signaling indicating/negotiating that it will be done.

I don=92t know if we want to allow the #2 possibility.  I can imagine use c=
ases in which it would be desirable, but it also adds complexity.

On Jul 16, 2014, at 11:44 AM, Christer Holmberg  wrote:

> Hi,
>=20
>> In my suggestion, a=3Dmid still contains the value.  a=3Drtcp-mid is a f=
lag attribute (i.e., not containing >any content) that simply indicates tha=
t the mid values will indeed be sent in RTCP.
>=20
> Ok, I get it. But, why can't we use the a=3Dextmap attribute to indicate =
that the value will be sent both in RTCP and RTP? Do we want to be able to =
choose?
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
> I don't think simply splitting the mid correlator into a separate value f=
rom a=3Dmid would solve the POF/PAN problem.  The correlators need to be un=
ique, but in POF/PAN you have the possibility of collision between simultan=
eous partial offers.
>=20
> On Jul 16, 2014, at 11:36 AM, Christer Holmberg  wrote:
>=20
>> Hi Jonathan,
>>=20
>> My suggestion was to use the a=3Dmid attribute - not to define a new a=
=3Drtcp-mid attribute.
>>=20
>> But, of course, if the mid values will be too big (I have expressed some=
 issues on the suggested POF/PAN usage of the mid values) to carry in RTP/R=
TCP, I guess we have to consider something else.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan=20
>> Lennox
>> Sent: 16 July 2014 18:27
>> To: Paul Kyzivat
>> Cc: mmusic
>> Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implem=
ent "receiver-id"?
>>=20
>>=20
>> On Jul 16, 2014, at 10:49 AM, Paul Kyzivat  wrote=
:
>>=20
>>> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>>>> Hi BUNDLE lovers,
>>>>=20
>>>> The main remaining open issue in BUNDLE is the "receiver-id", i.e.=20
>>>> the mechanism for the Offerer to map received RTP/RTCP packets with=20
>>>> the associated m- line - even before the SDP answer has been received.
>>>>=20
>>>> In London we more or less agreed to use Roni's app-id for this.
>>>>=20
>>>> Since then, we've had some off-line discussions with Roni, and=20
>>>> instead of using app-id we suggest the following:
>>>>=20
>>>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>>>> lines
>>>>=20
>>>> -We define a new RTP header extension, and a new RTCP SDES item, for=20
>>>> carrying the mid value
>>>>=20
>>>> -The RTP header extension/RTCP SDES item are generic, which means=20
>>>> they can also be used with other protocols than SDP
>>>>=20
>>>> The advantage is that the SDP mid attribute already exists, the=20
>>>> usage is mandatory in BUNDLE, and the value is unique for each m-=20
>>>> line. The semantics also fit, as it is referencing an m- line.
>>>>=20
>>>> Some of the detailed questions we need to deal with are:
>>>>=20
>>>> Q1: The syntax of the SDP mid attribute value must "fit" into an RTP=20
>>>> header extension of RTCP SDES item.
>>>>=20
>>>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>>>> During whole session? When SSRC change?
>>>>=20
>>>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>>>> directions?
>>>>=20
>>>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>>>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>>>=20
>>>> I intend to talk about during the MMUSIC session on Monday, but feel=20
>>>> free to comment and give input on the list :)
>>>=20
>>> Another question:
>>>=20
>>> When the grouping framework is used, then *every* m-line must have a mi=
d assigned, whether it is bundled or not, and whether the mid is necessary =
to associate media packets to m-lines or not.
>>>=20
>>> Will this require the header extension and SDES item to *used* for=20
>>> RTP of every m-line? (That would be unfortunate.)
>>>=20
>>> Else, what are the complete set of conditions that determine when this =
is used?
>>=20
>> I was part of the offline discussion that contributed to this (as co-aut=
hor of the appid draft), and my understanding of the discussion was as foll=
ows:
>>=20
>> An m-line group would carry an "a=3Drtcp-mid" attribute to indicate that=
 the mid would be sent in RTCP, and also an appropriate a=3Dextmap attribut=
e (URL to be determined) to indicate that the mid would also be sent in a h=
eader extension.
>>=20
>> This attribute is included in SDP to explicitly indicate that you are=20
>> sending mids in RTP/RTCP; including the attribute is mandatory when=20
>> you are using BUNDLE with overlapping payload types.  (Optional=20
>> otherwise, I suppose, though this wasn't discussed.)
>>=20
>>=20
>> Another important issue: POF/PAN wants to mandate that mid values are lo=
ng, to minimize the possibility of mid collisions between simultaneous part=
ial offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short=
, so they fit in RTP header extensions with minimal overhead.  Is there a w=
ay we can reconcile these requirements?
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20


From nobody Wed Jul 16 09:12:26 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68091B2BBA for ; Wed, 16 Jul 2014 09:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJOMQaUsLn38 for ; Wed, 16 Jul 2014 09:12:21 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF41A1A0769 for ; Wed, 16 Jul 2014 09:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3111; q=dns/txt; s=iport; t=1405527140; x=1406736740; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DddjzGIA3Z+383l1YercrMEgbq6WIngE0f7r8UFqcr8=; b=jdX7NyCq3CEHBc4ePaQiYSyFXQEgDB5qUq/UkqJ/r0L9V/2x2N7rGaYd j/uoOr187guYaABz3Mo/MxoVjcXsSLevYhPUtG/mfBw/taxBjnE49mGhZ Q+Y0AEgmbT/yJY8Mztn0W4zvtyCTpWQQhiuWlCFwi03HvRyOfdKm52Mlw Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAKqjxlOtJV2U/2dsb2JhbABZDoMAgSkEynIBgQkWdoQDAQEBAwF+CwIBCA4KLjIlAgQBEog6CMp7F453ITqEQwWKKpBzlCyCAoEAQmyBRQ
X-IronPort-AV: E=Sophos;i="5.01,673,1400025600"; d="scan'208";a="61344438"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 16 Jul 2014 16:12:20 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6GGCK8U024659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 16:12:20 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 11:12:19 -0500
From: "Mo Zanaty (mzanaty)" 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoRC3ZRne2qJ8rUW7u0OcFiKPVQ==
Date: Wed, 16 Jul 2014 16:12:19 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>
In-Reply-To: <53C69110.504@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.81.3.65]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8FA8654F812D7748B5190E15C3C63BC8@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xvk6S2w2_eu9ENkNFffITTfhr4I
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 16:12:22 -0000

Paul Kyzivat  wrote:
On 7/16/14 4:08 AM, Christer Holmberg wrote:
> Hi BUNDLE lovers,
>
> The main remaining open issue in BUNDLE is the =B3receiver-id=B2, i.e. th=
e
> mechanism for the Offerer to map received RTP/RTCP packets with the
> associated m- line =AD even before the SDP answer has been received.
>
> In London we more or less agreed to use Roni=B9s app-id for this.
>
> Since then, we=B9ve had some off-line discussions with Roni, and instead
> of using app-id we suggest the following:
>
> -We use the SDP mid attribute value to map RTP/RTCP packets with m- lines
>
> -We define a new RTP header extension, and a new RTCP SDES item, for
> carrying the mid value
>
> -The RTP header extension/RTCP SDES item are generic, which means they
> can also be used with other protocols than SDP
>
> The advantage is that the SDP mid attribute already exists, the usage is
> mandatory in BUNDLE, and the value is unique for each m- line. The
> semantics also fit, as it is referencing an m- line.
>
> Some of the detailed questions we need to deal with are:
>
> Q1: The syntax of the SDP mid attribute value must =B3fit=B2 into an RTP
> header extension of RTCP SDES item.

Note that SDP mid values and RTCP SDES items are both text (token and
UTF-8, respectively). Compact values for small RTP header extensions
should keep this in mind.


> Q2: When are the mid value sent? During Offer/Answer transaction? During
> whole session? When SSRC change?

If negotiated, the RTCP SDES mid item should be sent whenever CNAME is
sent. If negotiated, the RTP header extension echoes this value for the
first few media frames of a new SSRC, or optionally for all critical media
frames (e.g. video key frames or parameter sets).


> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
> directions?

The mechanism applies to the m-line direction (both if sendrecv). A bundle
offer MUST include this if the offerer is otherwise unable to associate
received RTP streams with m-lines (e.g. due to PT reuse across m-lines). A
bundle answer MUST include this if offered.


> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
> mechanism in draft-westerlund-avtext-sdes-hdr-ext?

Yes, follow that format but with no normative dependency. The RTP header
extension name should be:
  a=3Dextmap:1 urn:ietf:params:rtp-hdrext:sdes:mid


> I intend to talk about during the MMUSIC session on Monday, but feel
> free to comment and give input on the list :)

> Another question:

> When the grouping framework is used, then *every* m-line must have a mid
assigned, whether it is bundled or not, and whether the mid is necessary
to associate media packets to m-lines or not.

> Will this require the header extension and SDES item to *used* for RTP
of every m-line? (That would be unfortunate.)

No, only if negotiated on the m-lines where it is needed to associate
received RTP streams.


> Else, what are the complete set of conditions that determine when this
>is used?

See answer to Q3.

Mo


From nobody Wed Jul 16 09:25:16 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FFA1A0007 for ; Wed, 16 Jul 2014 09:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.552
X-Spam-Level: 
X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gVzjwjd7tKE for ; Wed, 16 Jul 2014 09:25:10 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CF11A0002 for ; Wed, 16 Jul 2014 09:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6663; q=dns/txt; s=iport; t=1405527911; x=1406737511; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oFHqgv3c3zOlxX7q2fZaLU4iMS+aApDb3DCCKeHJzpE=; b=WR1HkZzkOEFMCZPSq8OtgS6PIQbFa29JnfBuyC7rUNcw3s13Qm7SxHBK pqLOd+mxTjng79aCSeMKrniMSK3mNYEhxoMqAWW8rpR9nMQvjfUTc56R/ fejvnN/xFStmmInFCDbpTGbyiGmiCtsjjgBASVgstM+Mg7JmilXixt54a w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FALemxlOtJA2B/2dsb2JhbABZgw5SVwTDJgqGb1MBgQkWdoQDAQEBAwEBAQFrCwUHBAIBCBEEAQEBJwcnCxQJCAIEAQ0FiDoIDcpkEwSOdyEzBwaEPQWKKpBzlCyCAoFCbIFF
X-IronPort-AV: E=Sophos;i="5.01,673,1400025600"; d="scan'208";a="340262851"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 16 Jul 2014 16:25:10 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6GGP9G8009279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 16:25:09 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 11:25:09 -0500
From: "Mo Zanaty (mzanaty)" 
To: Jonathan Lennox , Christer Holmberg 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoRKCTqdJLIJYlU6ZqOKTc+t7CA==
Date: Wed, 16 Jul 2014 16:25:08 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D3C8C09@ESESSMB209.ericsson.se> <697B252B-B666-47CD-8829-ECCCC2BE0977@vidyo.com>
In-Reply-To: <697B252B-B666-47CD-8829-ECCCC2BE0977@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.81.3.65]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <802C776067D1EC4BBBDF9E8AE7E333A7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/O7_kTb3l4Qv-3EwLd8PxR_J2750
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 16:25:13 -0000

If we don=B9t care much about 2, then 3 can be negotiated using the existin=
g
a=3Dextmap attribute with the format proposed for SDES items in
draft-westerlund-avtext-sdes-hdr-ext.

  a=3Dextmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

This makes it clear the RTP header extension is also an RTCP SDES item. I
agree we should not allow mid in RTP but not RTCP, so naming the header
extension in this way closes that door.


Mo


Jonathan Lennox  wrote:

I see three possible states:

1. Mid will not be sent at all.  This is what is indicated by current
signaling, implicitly.
2. Mid will be sent in RTCP, but not RTP.
3. Mid will be sent in RTCP and RTP both.

(I don=B9t think we want to allow mid in RTP but not in RTCP.)

In my suggestion, if you don=B9t say anything, it means #1.  #2 is indicate=
d
by a=3Drtcp-mid, and #3 is indicated by a=3Drtcp-mid and a=3Dextmap.

Unless you want to say that the BUNDLE group semantic implicitly implies
either #2 or #3 (always?  Iff overlapping payload types?), I don=B9t think
it=B9s a good idea to start sending a new mechanism at the media layer
without some SDP signaling indicating/negotiating that it will be done.

I don=B9t know if we want to allow the #2 possibility.  I can imagine use
cases in which it would be desirable, but it also adds complexity.

On Jul 16, 2014, at 11:44 AM, Christer Holmberg
 wrote:

> Hi,
>=20
>> In my suggestion, a=3Dmid still contains the value.  a=3Drtcp-mid is a f=
lag
>>attribute (i.e., not containing >any content) that simply indicates that
>>the mid values will indeed be sent in RTCP.
>=20
> Ok, I get it. But, why can't we use the a=3Dextmap attribute to indicate
>that the value will be sent both in RTCP and RTP? Do we want to be able
>to choose?
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
> I don't think simply splitting the mid correlator into a separate value
>from a=3Dmid would solve the POF/PAN problem.  The correlators need to be
>unique, but in POF/PAN you have the possibility of collision between
>simultaneous partial offers.
>=20
> On Jul 16, 2014, at 11:36 AM, Christer Holmberg
> wrote:
>=20
>> Hi Jonathan,
>>=20
>> My suggestion was to use the a=3Dmid attribute - not to define a new
>>a=3Drtcp-mid attribute.
>>=20
>> But, of course, if the mid values will be too big (I have expressed
>>some issues on the suggested POF/PAN usage of the mid values) to carry
>>in RTP/RTCP, I guess we have to consider something else.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan
>> Lennox
>> Sent: 16 July 2014 18:27
>> To: Paul Kyzivat
>> Cc: mmusic
>> Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to
>>implement "receiver-id"?
>>=20
>>=20
>> On Jul 16, 2014, at 10:49 AM, Paul Kyzivat 
>>wrote:
>>=20
>>> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>>>> Hi BUNDLE lovers,
>>>>=20
>>>> The main remaining open issue in BUNDLE is the "receiver-id", i.e.
>>>> the mechanism for the Offerer to map received RTP/RTCP packets with
>>>> the associated m- line - even before the SDP answer has been received.
>>>>=20
>>>> In London we more or less agreed to use Roni's app-id for this.
>>>>=20
>>>> Since then, we've had some off-line discussions with Roni, and
>>>> instead of using app-id we suggest the following:
>>>>=20
>>>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-
>>>> lines
>>>>=20
>>>> -We define a new RTP header extension, and a new RTCP SDES item, for
>>>> carrying the mid value
>>>>=20
>>>> -The RTP header extension/RTCP SDES item are generic, which means
>>>> they can also be used with other protocols than SDP
>>>>=20
>>>> The advantage is that the SDP mid attribute already exists, the
>>>> usage is mandatory in BUNDLE, and the value is unique for each m-
>>>> line. The semantics also fit, as it is referencing an m- line.
>>>>=20
>>>> Some of the detailed questions we need to deal with are:
>>>>=20
>>>> Q1: The syntax of the SDP mid attribute value must "fit" into an RTP
>>>> header extension of RTCP SDES item.
>>>>=20
>>>> Q2: When are the mid value sent? During Offer/Answer transaction?
>>>> During whole session? When SSRC change?
>>>>=20
>>>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
>>>> directions?
>>>>=20
>>>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
>>>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>>>=20
>>>> I intend to talk about during the MMUSIC session on Monday, but feel
>>>> free to comment and give input on the list :)
>>>=20
>>> Another question:
>>>=20
>>> When the grouping framework is used, then *every* m-line must have a
>>>mid assigned, whether it is bundled or not, and whether the mid is
>>>necessary to associate media packets to m-lines or not.
>>>=20
>>> Will this require the header extension and SDES item to *used* for
>>> RTP of every m-line? (That would be unfortunate.)
>>>=20
>>> Else, what are the complete set of conditions that determine when this
>>>is used?
>>=20
>> I was part of the offline discussion that contributed to this (as
>>co-author of the appid draft), and my understanding of the discussion
>>was as follows:
>>=20
>> An m-line group would carry an "a=3Drtcp-mid" attribute to indicate that
>>the mid would be sent in RTCP, and also an appropriate a=3Dextmap
>>attribute (URL to be determined) to indicate that the mid would also be
>>sent in a header extension.
>>=20
>> This attribute is included in SDP to explicitly indicate that you are
>> sending mids in RTP/RTCP; including the attribute is mandatory when
>> you are using BUNDLE with overlapping payload types.  (Optional
>> otherwise, I suppose, though this wasn't discussed.)
>>=20
>>=20
>> Another important issue: POF/PAN wants to mandate that mid values are
>>long, to minimize the possibility of mid collisions between simultaneous
>>partial offers.  Meanwhile, rtcp-mid wants to mandate that mid values
>>are short, so they fit in RTP header extensions with minimal overhead.
>>Is there a way we can reconcile these requirements?
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20

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


From nobody Wed Jul 16 11:33:08 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD81A017A for ; Wed, 16 Jul 2014 11:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.035
X-Spam-Level: 
X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQXfIT_5Vi_g for ; Wed, 16 Jul 2014 11:33: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 927481A015F for ; Wed, 16 Jul 2014 11:33:01 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id T5Sy1o0040bG4ec5A6Z1KQ; Wed, 16 Jul 2014 18:33:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id T6Z01o00q3ZTu2S3P6Z0QU; Wed, 16 Jul 2014 18:33:01 +0000
Message-ID: <53C6C55C.6040207@alum.mit.edu>
Date: Wed, 16 Jul 2014 14:33:00 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Christer Holmberg ,  Suhas Nandakumar 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B71@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3C8B71@ESESSMB209.ericsson.se>
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=q20140121; t=1405535581; bh=lqjIDOZKHoCSeMBXkrEflD//vx0qJOdVoVDud6Acqfo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rLWEpK57WHMt4w6bm1zsNtokgaHG+UMImfIV0f2qZcXioH27lP0Pp+2O4g6p0bBxG E9UAtCyopXiB74mGT2mRL9xV1ZlAtngfq85l6cwWMMeDW9Q9YJRIJM+Oy2C89s3VUR ajsIajhlPsGW9cWmT6xnu9Wu2CeM/roszcJg3883RAZtlUAworrxYuWAbplnDyL6jL PrpMCWwNfZy4DQWXXxAIR8681DlTP3o2mGvWEnb91dfKg6fshmLamh2JscokHO4K9y ix4UK3IVDnHhF2LG4vsg624FxMZkdt6m2FY557axJ7uEhBaAqa7bAP36bHDXdoAdKJ aICji+617JvDQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/KMWpr42MorwwtFgepKWL9piPtzE
Cc: mmusic WG 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 18:33:03 -0000

On 7/16/14 11:25 AM, Christer Holmberg wrote:
> Hi Suhas,
>
> You also raise an important point, which I forgot to mention.
>
> The suggestion is that BUNDLE entities MUST support the mechanism.
>
> HOWEVER, IF a BUNDLE entity is able to map RTP based on PT, it would
> simply not indicate usage of the mechanism (using the SDP extmap
> attribute). The remote entity would then NOT include the mid value in
> sent RTP/RTCP packets.

I just skimmed 5285 for the first time. It isn't immediately apparent to 
me whether the SDP for extmap is negotiating *support* or *use*. If its 
like most things, it is probably support, and use is still optional.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Suhas
> Nandakumar
> *Sent:* 16 July 2014 18:11
> *To:* Paul Kyzivat
> *Cc:* mmusic WG
> *Subject:* Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to
> implement "receiver-id"?
>
> Hi Paul
>
>    Some thoughts inline.
>
> On Wed, Jul 16, 2014 at 8:19 PM, Paul Kyzivat  > wrote:
>
>     On 7/16/14 4:08 AM, Christer Holmberg wrote:
>
>         Hi BUNDLE lovers,
>
>         The main remaining open issue in BUNDLE is the “receiver-id”,
>         i.e. the
>         mechanism for the Offerer to map received RTP/RTCP packets with the
>         associated m- line – even before the SDP answer has been received.
>
>         In London we more or less agreed to use Roni’s app-id for this.
>
>         Since then, we’ve had some off-line discussions with Roni, and
>         instead
>         of using app-id we suggest the following:
>
>         -We use the SDP mid attribute value to map RTP/RTCP packets with
>         m- lines
>
>         -We define a new RTP header extension, and a new RTCP SDES item, for
>         carrying the mid value
>
>         -The RTP header extension/RTCP SDES item are generic, which
>         means they
>
>
>         can also be used with other protocols than SDP
>
>         The advantage is that the SDP mid attribute already exists, the
>         usage is
>         mandatory in BUNDLE, and the value is unique for each m- line. The
>         semantics also fit, as it is referencing an m- line.
>
>         Some of the detailed questions we need to deal with are:
>
>         Q1: The syntax of the SDP mid attribute value must “fit” into an RTP
>         header extension of RTCP SDES item.
>
>         Q2: When are the mid value sent? During Offer/Answer
>         transaction? During
>         whole session? When SSRC change?
>
>         Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both
>         directions?
>
>         Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the
>         mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>
>         I intend to talk about during the MMUSIC session on Monday, but feel
>         free to comment and give input on the list :)
>
>
>     Another question:
>
>     When the grouping framework is used, then *every* m-line must have a
>     mid assigned, whether it is bundled or not, and whether the mid is
>     necessary to associate media packets to m-lines or not.
>
>     Will this require the header extension and SDES item to *used* for
>     RTP of every m-line? (That would be unfortunate.)
>
>     Else, what are the complete set of conditions that determine when
>     this is used?
>
> [Suhas] .. I dont see a need for RTP header extension to be repeated for
> all the m=lines where a mid is specified. Since the purpose is to map
> the incoming media packets to a m=line, we need to specify the header
> extension only for this requirement.
>
> So whenever BUNDLE grouping framework is used and when PT is not enough
> to map the RTP packets to a m= line, the implementation MUST signal (in
> SDP) the RTP Header extension for all the media lines where the
> disambiguation is needed and no more or less.
>
>
>              Thanks,
>              Paul
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org 
>     https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Wed Jul 16 12:20:32 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397B71A01CB for ; Wed, 16 Jul 2014 11:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Level: 
X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSc9BFdWSn_O for ; Wed, 16 Jul 2014 11:57:32 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075071A01AA for ; Wed, 16 Jul 2014 11:57:31 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-a7-53c6cb1919b9
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 91.7B.19155.91BC6C35; Wed, 16 Jul 2014 20:57:30 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 20:57:29 +0200
From: Christer Holmberg 
To: Paul Kyzivat , Suhas Nandakumar 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuirM8AgAAlB4CAABNWAIAAJuEw
Date: Wed, 16 Jul 2014 18:57:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8E2F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B71@ESESSMB209.ericsson.se> <53C6C55C.6040207@alum.mit.edu>
In-Reply-To: <53C6C55C.6040207@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.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja7U6WPBBtNOcFhMXf6YxWLFhgOs FjvndjA7MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyti4tImtYIFBRe/mG4wN jA36XYwcHBICJhJTrsl0MXICmWISF+6tZ+ti5OIQEjjKKPFt0w1WCGcRo8SR5XNZQRrYBCwk uv9pgzSICARJnF11lQ3EZhaQl7iwZA0TiC0sECPRebGJGaImVuLL/59QtpvE0QlXwGpYBFQl Wr92sIPYvAK+Eo8eNTFB7JrBJHF91y5WkASngI5E9+zJLCA2I9B1309BLGAWEJe49WQ+E8TV AhJL9pxnhrBFJV4+/scKYStJLLr9mQnkZmYBTYn1u/QhWhUlpnQ/hNorKHFy5hOWCYxis5BM nYXQMQtJxywkHQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMbTwS2/VXcwXn7jeIhR gINRiYc3ofVYsBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YCwXVjF1NixeflNt/bUDycmHX5z49/RayOFD5ab/liY9KeuepbDZhuXcexEzKZvcDBddwbef z93XZuk+byB57bfP/TCjyEfz5+9Uj39f+f1q84n6QznMPEpX5p66nnymNaToRM0SbeG+5PU/ qji8Z0l9ddn++LmFir5X0+Sl6tMCmdyfTm7n/a7EUpyRaKjFXFScCACoZ0IYiAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/47WoJ9M-x-rNkoSYjsz42FnldU4
Cc: mmusic WG 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 18:57:35 -0000

SGksDQoNCj4+IFlvdSBhbHNvIHJhaXNlIGFuIGltcG9ydGFudCBwb2ludCwgd2hpY2ggSSBmb3Jn
b3QgdG8gbWVudGlvbi4NCj4+DQo+PiBUaGUgc3VnZ2VzdGlvbiBpcyB0aGF0IEJVTkRMRSBlbnRp
dGllcyBNVVNUIHN1cHBvcnQgdGhlIG1lY2hhbmlzbS4NCj4+DQo+PiBIT1dFVkVSLCBJRiBhIEJV
TkRMRSBlbnRpdHkgaXMgYWJsZSB0byBtYXAgUlRQIGJhc2VkIG9uIFBULCBpdCB3b3VsZCANCj4+
IHNpbXBseSBub3QgaW5kaWNhdGUgdXNhZ2Ugb2YgdGhlIG1lY2hhbmlzbSAodXNpbmcgdGhlIFNE
UCBleHRtYXAgDQo+PiBhdHRyaWJ1dGUpLiBUaGUgcmVtb3RlIGVudGl0eSB3b3VsZCB0aGVuIE5P
VCBpbmNsdWRlIHRoZSBtaWQgdmFsdWUgaW4gDQo+PiBzZW50IFJUUC9SVENQIHBhY2tldHMuDQo+
DQo+IEkganVzdCBza2ltbWVkIDUyODUgZm9yIHRoZSBmaXJzdCB0aW1lLiBJdCBpc24ndCBpbW1l
ZGlhdGVseSBhcHBhcmVudCB0byBtZSB3aGV0aGVyIHRoZSBTRFAgZm9yIA0KPiBleHRtYXAgaXMg
bmVnb3RpYXRpbmcgKnN1cHBvcnQqIG9yICp1c2UqLiBJZiBpdHMgbGlrZSBtb3N0IHRoaW5ncywg
aXQgaXMgcHJvYmFibHkgc3VwcG9ydCwgYW5kIHVzZSBpcyANCj4gc3RpbGwgb3B0aW9uYWwuDQoN
CkFzc3VtaW5nIGl0IG1lYW5zIGluZGljYXRpbmcgc3VwcG9ydCwgd2UgY2FuIGFsd2F5cyBzcGVj
aWZ5IHRoYXQgaWYgdGhlIHJlbW90ZSBlbmRwb2ludCBpbmRpY2F0ZXMgKnN1cHBvcnQqLCB0aGUg
cmVjZWl2aW5nIGVuZHBvaW50IG11c3QgKnVzZSouIEJlY2F1c2UsIHRoZSByZWNlaXZpbmcgZW5k
cG9pbnQgaXMgdGhlIG9uZSB0aGF0IHdpbGwgaW5zZXJ0IHRoZSBtaWQgdmFsdWUgaW4gdGhlIFJU
UC9SVFBDIHBhY2tldHMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KPiAqRnJv
bToqbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2Yg
KlN1aGFzIA0KPiBOYW5kYWt1bWFyDQo+ICpTZW50OiogMTYgSnVseSAyMDE0IDE4OjExDQo+ICpU
bzoqIFBhdWwgS3l6aXZhdA0KPiAqQ2M6KiBtbXVzaWMgV0cNCj4gKlN1YmplY3Q6KiBSZTogW01N
VVNJQ10gQlVORExFOiB1c2FnZSBvZiBTRFAgbWlkIGF0dHJpYnV0ZSB2YWx1ZSB0byANCj4gaW1w
bGVtZW50ICJyZWNlaXZlci1pZCI/DQo+DQo+IEhpIFBhdWwNCj4NCj4gICAgU29tZSB0aG91Z2h0
cyBpbmxpbmUuDQo+DQo+IE9uIFdlZCwgSnVsIDE2LCAyMDE0IGF0IDg6MTkgUE0sIFBhdWwgS3l6
aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1IA0KPiA8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0
LmVkdT4+IHdyb3RlOg0KPg0KPiAgICAgT24gNy8xNi8xNCA0OjA4IEFNLCBDaHJpc3RlciBIb2xt
YmVyZyB3cm90ZToNCj4NCj4gICAgICAgICBIaSBCVU5ETEUgbG92ZXJzLA0KPg0KPiAgICAgICAg
IFRoZSBtYWluIHJlbWFpbmluZyBvcGVuIGlzc3VlIGluIEJVTkRMRSBpcyB0aGUg4oCccmVjZWl2
ZXItaWTigJ0sDQo+ICAgICAgICAgaS5lLiB0aGUNCj4gICAgICAgICBtZWNoYW5pc20gZm9yIHRo
ZSBPZmZlcmVyIHRvIG1hcCByZWNlaXZlZCBSVFAvUlRDUCBwYWNrZXRzIHdpdGggdGhlDQo+ICAg
ICAgICAgYXNzb2NpYXRlZCBtLSBsaW5lIOKAkyBldmVuIGJlZm9yZSB0aGUgU0RQIGFuc3dlciBo
YXMgYmVlbiByZWNlaXZlZC4NCj4NCj4gICAgICAgICBJbiBMb25kb24gd2UgbW9yZSBvciBsZXNz
IGFncmVlZCB0byB1c2UgUm9uaeKAmXMgYXBwLWlkIGZvciB0aGlzLg0KPg0KPiAgICAgICAgIFNp
bmNlIHRoZW4sIHdl4oCZdmUgaGFkIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgd2l0aCBSb25p
LCBhbmQNCj4gICAgICAgICBpbnN0ZWFkDQo+ICAgICAgICAgb2YgdXNpbmcgYXBwLWlkIHdlIHN1
Z2dlc3QgdGhlIGZvbGxvd2luZzoNCj4NCj4gICAgICAgICAtV2UgdXNlIHRoZSBTRFAgbWlkIGF0
dHJpYnV0ZSB2YWx1ZSB0byBtYXAgUlRQL1JUQ1AgcGFja2V0cyB3aXRoDQo+ICAgICAgICAgbS0g
bGluZXMNCj4NCj4gICAgICAgICAtV2UgZGVmaW5lIGEgbmV3IFJUUCBoZWFkZXIgZXh0ZW5zaW9u
LCBhbmQgYSBuZXcgUlRDUCBTREVTIGl0ZW0sIGZvcg0KPiAgICAgICAgIGNhcnJ5aW5nIHRoZSBt
aWQgdmFsdWUNCj4NCj4gICAgICAgICAtVGhlIFJUUCBoZWFkZXIgZXh0ZW5zaW9uL1JUQ1AgU0RF
UyBpdGVtIGFyZSBnZW5lcmljLCB3aGljaA0KPiAgICAgICAgIG1lYW5zIHRoZXkNCj4NCj4NCj4g
ICAgICAgICBjYW4gYWxzbyBiZSB1c2VkIHdpdGggb3RoZXIgcHJvdG9jb2xzIHRoYW4gU0RQDQo+
DQo+ICAgICAgICAgVGhlIGFkdmFudGFnZSBpcyB0aGF0IHRoZSBTRFAgbWlkIGF0dHJpYnV0ZSBh
bHJlYWR5IGV4aXN0cywgdGhlDQo+ICAgICAgICAgdXNhZ2UgaXMNCj4gICAgICAgICBtYW5kYXRv
cnkgaW4gQlVORExFLCBhbmQgdGhlIHZhbHVlIGlzIHVuaXF1ZSBmb3IgZWFjaCBtLSBsaW5lLiBU
aGUNCj4gICAgICAgICBzZW1hbnRpY3MgYWxzbyBmaXQsIGFzIGl0IGlzIHJlZmVyZW5jaW5nIGFu
IG0tIGxpbmUuDQo+DQo+ICAgICAgICAgU29tZSBvZiB0aGUgZGV0YWlsZWQgcXVlc3Rpb25zIHdl
IG5lZWQgdG8gZGVhbCB3aXRoIGFyZToNCj4NCj4gICAgICAgICBRMTogVGhlIHN5bnRheCBvZiB0
aGUgU0RQIG1pZCBhdHRyaWJ1dGUgdmFsdWUgbXVzdCDigJxmaXTigJ0gaW50byBhbiBSVFANCj4g
ICAgICAgICBoZWFkZXIgZXh0ZW5zaW9uIG9mIFJUQ1AgU0RFUyBpdGVtLg0KPg0KPiAgICAgICAg
IFEyOiBXaGVuIGFyZSB0aGUgbWlkIHZhbHVlIHNlbnQ/IER1cmluZyBPZmZlci9BbnN3ZXINCj4g
ICAgICAgICB0cmFuc2FjdGlvbj8gRHVyaW5nDQo+ICAgICAgICAgd2hvbGUgc2Vzc2lvbj8gV2hl
biBTU1JDIGNoYW5nZT8NCj4NCj4gICAgICAgICBRMzogRG8gd2UsIGZvciBCVU5ETEUgdXNhZ2Us
IGFsbG93IHVzYWdlIG9mIHRoZSBtZWNoYW5pc20gaW4gYm90aA0KPiAgICAgICAgIGRpcmVjdGlv
bnM/DQo+DQo+ICAgICAgICAgUTQ6IERvIHdlIGNhcnJ5IHRoZSBSVENQIFNERVMgaXRlbSBpbiBS
VENQLCBvciBpbiBSVFAgdXNpbmcgdGhlDQo+ICAgICAgICAgbWVjaGFuaXNtIGluIGRyYWZ0LXdl
c3Rlcmx1bmQtYXZ0ZXh0LXNkZXMtaGRyLWV4dD8NCj4NCj4gICAgICAgICBJIGludGVuZCB0byB0
YWxrIGFib3V0IGR1cmluZyB0aGUgTU1VU0lDIHNlc3Npb24gb24gTW9uZGF5LCBidXQgZmVlbA0K
PiAgICAgICAgIGZyZWUgdG8gY29tbWVudCBhbmQgZ2l2ZSBpbnB1dCBvbiB0aGUgbGlzdCA6KQ0K
Pg0KPg0KPiAgICAgQW5vdGhlciBxdWVzdGlvbjoNCj4NCj4gICAgIFdoZW4gdGhlIGdyb3VwaW5n
IGZyYW1ld29yayBpcyB1c2VkLCB0aGVuICpldmVyeSogbS1saW5lIG11c3QgaGF2ZSBhDQo+ICAg
ICBtaWQgYXNzaWduZWQsIHdoZXRoZXIgaXQgaXMgYnVuZGxlZCBvciBub3QsIGFuZCB3aGV0aGVy
IHRoZSBtaWQgaXMNCj4gICAgIG5lY2Vzc2FyeSB0byBhc3NvY2lhdGUgbWVkaWEgcGFja2V0cyB0
byBtLWxpbmVzIG9yIG5vdC4NCj4NCj4gICAgIFdpbGwgdGhpcyByZXF1aXJlIHRoZSBoZWFkZXIg
ZXh0ZW5zaW9uIGFuZCBTREVTIGl0ZW0gdG8gKnVzZWQqIGZvcg0KPiAgICAgUlRQIG9mIGV2ZXJ5
IG0tbGluZT8gKFRoYXQgd291bGQgYmUgdW5mb3J0dW5hdGUuKQ0KPg0KPiAgICAgRWxzZSwgd2hh
dCBhcmUgdGhlIGNvbXBsZXRlIHNldCBvZiBjb25kaXRpb25zIHRoYXQgZGV0ZXJtaW5lIHdoZW4N
Cj4gICAgIHRoaXMgaXMgdXNlZD8NCj4NCj4gW1N1aGFzXSAuLiBJIGRvbnQgc2VlIGEgbmVlZCBm
b3IgUlRQIGhlYWRlciBleHRlbnNpb24gdG8gYmUgcmVwZWF0ZWQgDQo+IGZvciBhbGwgdGhlIG09
bGluZXMgd2hlcmUgYSBtaWQgaXMgc3BlY2lmaWVkLiBTaW5jZSB0aGUgcHVycG9zZSBpcyB0byAN
Cj4gbWFwIHRoZSBpbmNvbWluZyBtZWRpYSBwYWNrZXRzIHRvIGEgbT1saW5lLCB3ZSBuZWVkIHRv
IHNwZWNpZnkgdGhlIA0KPiBoZWFkZXIgZXh0ZW5zaW9uIG9ubHkgZm9yIHRoaXMgcmVxdWlyZW1l
bnQuDQo+DQo+IFNvIHdoZW5ldmVyIEJVTkRMRSBncm91cGluZyBmcmFtZXdvcmsgaXMgdXNlZCBh
bmQgd2hlbiBQVCBpcyBub3QgDQo+IGVub3VnaCB0byBtYXAgdGhlIFJUUCBwYWNrZXRzIHRvIGEg
bT0gbGluZSwgdGhlIGltcGxlbWVudGF0aW9uIE1VU1QgDQo+IHNpZ25hbCAoaW4NCj4gU0RQKSB0
aGUgUlRQIEhlYWRlciBleHRlbnNpb24gZm9yIGFsbCB0aGUgbWVkaWEgbGluZXMgd2hlcmUgdGhl
IA0KPiBkaXNhbWJpZ3VhdGlvbiBpcyBuZWVkZWQgYW5kIG5vIG1vcmUgb3IgbGVzcy4NCj4NCj4N
Cj4gICAgICAgICAgICAgIFRoYW5rcywNCj4gICAgICAgICAgICAgIFBhdWwNCj4NCj4gICAgIF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBtbXVz
aWMgbWFpbGluZyBsaXN0DQo+ICAgICBtbXVzaWNAaWV0Zi5vcmcgPG1haWx0bzptbXVzaWNAaWV0
Zi5vcmc+DQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp
Yw0KPg0KDQo=


From nobody Wed Jul 16 12:20:47 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E291A0190 for ; Wed, 16 Jul 2014 12:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_SUHw9TvjNe for ; Wed, 16 Jul 2014 12:03:50 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1901A007A for ; Wed, 16 Jul 2014 12:03:48 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-ce-53c6cc93f63b
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 71.D3.03739.39CC6C35; Wed, 16 Jul 2014 21:03:47 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 21:03:46 +0200
From: Christer Holmberg 
To: Jonathan Lennox 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuisTIAgAAir2D//+FPAIAAIckQ///htICAAFVG8A==
Date: Wed, 16 Jul 2014 19:03:46 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8E42@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8B9D@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D3C8C09@ESESSMB209.ericsson.se> <697B252B-B666-47CD-8829-ECCCC2BE0977@vidyo.com>
In-Reply-To: <697B252B-B666-47CD-8829-ECCCC2BE0977@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje7kM8eCDT7sFLXYv/g8s8XU5Y9Z LFZsOMDqwOzx9/0HJo8lS34yebQ9u8MewBzFZZOSmpNZllqkb5fAldGwfQJLwR2jih0H7rE1 MO7T6GLk5JAQMJE43HybGcIWk7hwbz1bFyMXh5DAUUaJuVtvQjmLGCW2/VrD1MXIwcEmYCHR /U8bpEFEQEPi4rMPbCA2s4CTxLWul2CDhAViJDovNjFD1MRKfPn/E8oOkzjy7wKYzSKgKnHt 8FYWEJtXwFdi583JrCC2kEAXs8TrGxIgNqeArUT/hB1MIDYj0HHfT61hgtglLnHryXwmiKMF JJbsOQ/1gKjEy8f/WCFsJYlFtz9D1etILNj9CepObYllC18zQ+wVlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbUwS2/dXcwrn7teIhRgINR iYd3wd5jwUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH5 SNLcqzJ1Li7H7JIzldwWWYna7u2uepWQ6RGWFL5C1fndLV9zi29CqlbuZ6zC/O61eH2ofVir PHtx8/Lpx849v/KgzPTlgwexvXbZf9343n/Z/m6SyYYq19P+VV9Z4ufMcb5/oaBWze/5ljDH iAm8R/PyPj60+sxg2sDKc/3BzWlRVbW/hZVYijMSDbWYi4oTAdFFPu6KAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Xm2cxz7dmXlu6xIZwSDFMDPKhgo
Cc: mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 19:03:52 -0000

Hi,

> I see three possible states:
>
> 1. Mid will not be sent at all.  This is what is indicated by current sig=
naling, implicitly.
> 2. Mid will be sent in RTCP, but not RTP.
> 3. Mid will be sent in RTCP and RTP both.
>
> (I don't think we want to allow mid in RTP but not in RTCP.)
>
> In my suggestion, if you don't say anything, it means #1.

Agree.

> #2 is indicated by a=3Drtcp-mid, and #3 is indicated by a=3Drtcp-mid and =
a=3Dextmap.

The question is whether we see a need to allow #2, or whether usage always =
means #3.

> Unless you want to say that the BUNDLE group semantic implicitly implies =
either #2 or #3 (always?  > Iff overlapping payload types?),

I do NOT want to say that :)

> I don't think it's a good idea to start sending a new mechanism at the me=
dia layer without some=20
> SDP signaling indicating/negotiating that it will be done.

I agree.

But again: I thought the extmap value would be enough, because my assumptio=
n has been that usage always means #3.

> I don't know if we want to allow the #2 possibility.  I can imagine use c=
ases in which it would be=20
> desirable, but it also adds complexity.

If there is a good use case for #2, I won't object.=20

Regards,

Christer


On Jul 16, 2014, at 11:44 AM, Christer Holmberg  wrote:

> Hi,
>=20
>> In my suggestion, a=3Dmid still contains the value.  a=3Drtcp-mid is a f=
lag attribute (i.e., not containing >any content) that simply indicates tha=
t the mid values will indeed be sent in RTCP.
>=20
> Ok, I get it. But, why can't we use the a=3Dextmap attribute to indicate =
that the value will be sent both in RTCP and RTP? Do we want to be able to =
choose?
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
> I don't think simply splitting the mid correlator into a separate value f=
rom a=3Dmid would solve the POF/PAN problem.  The correlators need to be un=
ique, but in POF/PAN you have the possibility of collision between simultan=
eous partial offers.
>=20
> On Jul 16, 2014, at 11:36 AM, Christer Holmberg  wrote:
>=20
>> Hi Jonathan,
>>=20
>> My suggestion was to use the a=3Dmid attribute - not to define a new a=
=3Drtcp-mid attribute.
>>=20
>> But, of course, if the mid values will be too big (I have expressed some=
 issues on the suggested POF/PAN usage of the mid values) to carry in RTP/R=
TCP, I guess we have to consider something else.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan=20
>> Lennox
>> Sent: 16 July 2014 18:27
>> To: Paul Kyzivat
>> Cc: mmusic
>> Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implem=
ent "receiver-id"?
>>=20
>>=20
>> On Jul 16, 2014, at 10:49 AM, Paul Kyzivat  wrote=
:
>>=20
>>> On 7/16/14 4:08 AM, Christer Holmberg wrote:
>>>> Hi BUNDLE lovers,
>>>>=20
>>>> The main remaining open issue in BUNDLE is the "receiver-id", i.e.=20
>>>> the mechanism for the Offerer to map received RTP/RTCP packets with=20
>>>> the associated m- line - even before the SDP answer has been received.
>>>>=20
>>>> In London we more or less agreed to use Roni's app-id for this.
>>>>=20
>>>> Since then, we've had some off-line discussions with Roni, and=20
>>>> instead of using app-id we suggest the following:
>>>>=20
>>>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>>>> lines
>>>>=20
>>>> -We define a new RTP header extension, and a new RTCP SDES item,=20
>>>> for carrying the mid value
>>>>=20
>>>> -The RTP header extension/RTCP SDES item are generic, which means=20
>>>> they can also be used with other protocols than SDP
>>>>=20
>>>> The advantage is that the SDP mid attribute already exists, the=20
>>>> usage is mandatory in BUNDLE, and the value is unique for each m-=20
>>>> line. The semantics also fit, as it is referencing an m- line.
>>>>=20
>>>> Some of the detailed questions we need to deal with are:
>>>>=20
>>>> Q1: The syntax of the SDP mid attribute value must "fit" into an=20
>>>> RTP header extension of RTCP SDES item.
>>>>=20
>>>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>>>> During whole session? When SSRC change?
>>>>=20
>>>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>>>> directions?
>>>>=20
>>>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>>>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>>>>=20
>>>> I intend to talk about during the MMUSIC session on Monday, but=20
>>>> feel free to comment and give input on the list :)
>>>=20
>>> Another question:
>>>=20
>>> When the grouping framework is used, then *every* m-line must have a mi=
d assigned, whether it is bundled or not, and whether the mid is necessary =
to associate media packets to m-lines or not.
>>>=20
>>> Will this require the header extension and SDES item to *used* for=20
>>> RTP of every m-line? (That would be unfortunate.)
>>>=20
>>> Else, what are the complete set of conditions that determine when this =
is used?
>>=20
>> I was part of the offline discussion that contributed to this (as co-aut=
hor of the appid draft), and my understanding of the discussion was as foll=
ows:
>>=20
>> An m-line group would carry an "a=3Drtcp-mid" attribute to indicate that=
 the mid would be sent in RTCP, and also an appropriate a=3Dextmap attribut=
e (URL to be determined) to indicate that the mid would also be sent in a h=
eader extension.
>>=20
>> This attribute is included in SDP to explicitly indicate that you are=20
>> sending mids in RTP/RTCP; including the attribute is mandatory when=20
>> you are using BUNDLE with overlapping payload types.  (Optional=20
>> otherwise, I suppose, though this wasn't discussed.)
>>=20
>>=20
>> Another important issue: POF/PAN wants to mandate that mid values are lo=
ng, to minimize the possibility of mid collisions between simultaneous part=
ial offers.  Meanwhile, rtcp-mid wants to mandate that mid values are short=
, so they fit in RTP header extensions with minimal overhead.  Is there a w=
ay we can reconcile these requirements?
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20


From nobody Wed Jul 16 12:20:53 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15F1A01D5 for ; Wed, 16 Jul 2014 12:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r6oNYod8M6C for ; Wed, 16 Jul 2014 12:10:53 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15E31A0190 for ; Wed, 16 Jul 2014 12:10:52 -0700 (PDT)
X-AuditID: c1b4fb30-f79da6d000006b80-a0-53c6ce3ac830
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 14.4E.27520.A3EC6C35; Wed, 16 Jul 2014 21:10:51 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 21:10:50 +0200
From: Christer Holmberg 
To: "Mo Zanaty (mzanaty)" , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuivd2AgABRmWA=
Date: Wed, 16 Jul 2014 19:10:49 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C8E50@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@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.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja71uWPBBk+281lMXf6YxeLFgzlM Fis2HGB1YPb4+/4Dk8eU3xtZPZYs+ckUwBzFZZOSmpNZllqkb5fAldE3fzZLwRnRisXTr7A1 MM4T7GLk5JAQMJFYtO47O4QtJnHh3nq2LkYuDiGBo4wSDRPesoIkhAQWMUrM7/LpYuTgYBOw kOj+pw0SFhGokth37yULiC0sECPRebGJGSIeK/Hl/08o20pi2f65bCA2i4CqxNneVrBdvAK+ EvOn3ITa1cco8ePjDbAGTgF9idt3IJoZgQ76fmoNE4jNLCAucevJfCaIQwUkluw5zwxhi0q8 fPyPFcJWklh0+zNUvZ7EjalT2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsY WVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbOwS2/DXYwvnzueIhRgINRiYd3wd5jwUKs iWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFeaoJqTvfNlwwq vuF/bn6zvb/wx26OENV/U+cdvxK6LkdWJYLJ3Hnx72BZAY01x5OuLlrGdfZWkNe5W40tMyco Ngo35kmtSJitkL6Ysf36WzYb1V93Tu76+/z4vz9CO3W4lhSG6LfMaXNS5WzyP7mq+LH+9ZRF qU+3rvm0XZ7p0UO7Sx9yNgcrsRRnJBpqMRcVJwIAkS6vxn4CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iQLrSL4aMqkhVv3SZMBF48ESiaE
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 19:10:54 -0000

Hi,

>> The main remaining open issue in BUNDLE is the =B3receiver-id=B2, i.e. t=
he=20
>> mechanism for the Offerer to map received RTP/RTCP packets with the=20
>> associated m- line =AD even before the SDP answer has been received.
>>
>> In London we more or less agreed to use Roni=B9s app-id for this.
>>
>> Since then, we=B9ve had some off-line discussions with Roni, and instead=
=20
>> of using app-id we suggest the following:
>>
>> -We use the SDP mid attribute value to map RTP/RTCP packets with m-=20
>> lines
>>
>> -We define a new RTP header extension, and a new RTCP SDES item, for=20
>> carrying the mid value
>>
>> -The RTP header extension/RTCP SDES item are generic, which means they=20
>> can also be used with other protocols than SDP
>>
>> The advantage is that the SDP mid attribute already exists, the usage=20
>> is mandatory in BUNDLE, and the value is unique for each m- line. The=20
>> semantics also fit, as it is referencing an m- line.
>>
>> Some of the detailed questions we need to deal with are:
>>
>> Q1: The syntax of the SDP mid attribute value must =B3fit=B2 into an RTP=
=20
>> header extension of RTCP SDES item.
>
> Note that SDP mid values and RTCP SDES items are both text (token and UTF=
-8, respectively).=20
> Compact values for small RTP header extensions should keep this in mind.
>
>> Q2: When are the mid value sent? During Offer/Answer transaction?=20
>> During whole session? When SSRC change?
>
> If negotiated, the RTCP SDES mid item should be sent whenever CNAME is se=
nt. If negotiated, the=20
> RTP header extension echoes this value for the first few media frames of =
a new SSRC, or optionally > for all critical media frames (e.g. video key f=
rames or parameter sets).
>
>> Q3: Do we, for BUNDLE usage, allow usage of the mechanism in both=20
>> directions?
>
> The mechanism applies to the m-line direction (both if sendrecv). A bundl=
e offer MUST include this > if the offerer is otherwise unable to associate=
 received RTP streams with m-lines (e.g. due to PT=20
> reuse across m-lines). A bundle answer MUST include this if offered.

Note that you can also indicate direction in the examap attribute, but I ha=
ven't had time to check how/if it is relate to the direction attribute.

>> Q4: Do we carry the RTCP SDES item in RTCP, or in RTP using the=20
>> mechanism in draft-westerlund-avtext-sdes-hdr-ext?
>
> Yes, follow that format but with no normative dependency. The RTP header =
extension name=20
> should be:  a=3Dextmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

Just to verify: you are suggestion to send the value in RTP using draft-wes=
terlund-avtext-sdes-hdr-ext, and in RTCP using a SDES item?

Regards,

Christer


From nobody Wed Jul 16 12:57:48 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871BE1A0264 for ; Wed, 16 Jul 2014 12:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.552
X-Spam-Level: 
X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7vRw4Jczq3X for ; Wed, 16 Jul 2014 12:57:41 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E4A1A026C for ; Wed, 16 Jul 2014 12:57:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1105; q=dns/txt; s=iport; t=1405540656; x=1406750256; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9fldJ8l0zcfFUj0nbXU7K80if6wtx8pQz2EYROBNIPs=; b=HdJEJEeVmI8WryeeqZFBI8W86bOAtfraVywPeOMKpuL5M9jnBmoE89u2 fYxhY1EJpS1idinGIJzjKwEWIV8ugcoh6NEDOEEp+ZAxuJ7Xuwr2Lqp8E 68ErCtCyO65wqMhtnWOcDgc/OyBF8vnJmwG83vcaEOOGH3VcEwWXQ2lnM E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAGnYxlOtJV2Z/2dsb2JhbABZDoMAgSkEynQBgQkWdoQDAQEBAwF+CwIBCBguMiUCBAESiDoIyl0Xjxg6hEMBBIoqkHOULIICgQBCbIEDBT0
X-IronPort-AV: E=Sophos;i="5.01,673,1400025600"; d="scan'208";a="340484681"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 16 Jul 2014 19:57:35 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6GJvZAl013890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 19:57:35 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 14:57:35 -0500
From: "Mo Zanaty (mzanaty)" 
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoTAvrrSwb6tUF0SBRNjPkqcVvg==
Date: Wed, 16 Jul 2014 19:57:34 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8E50@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3C8E50@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.81.3.65]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2F05A35D6B9D6747B6B574188AB3B849@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_7qYtywNyCwnsVdA2IcNAc1SjiQ
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 19:57:44 -0000

Christer Holmberg  wrote:
> Note that you can also indicate direction in the extmap attribute, but I
>haven't had time to check how/if it is relate to the direction attribute.

Good point. I didn=B9t think that would be useful at first, but now see som=
e
possible uses. The extmap direction inherits from the m-line direction,
but can override it. This could be useful for a=3Dsendrecv cases where the
offerer does not need to receive the extension (e.g. it offers unique PTs
across m-lines), but is willing to send the extension in case the answerer
needs it.

Offer: (does not need to receive RTP mid, but willing to send it)
a=3Dsendrecv
a=3Dextmap:1/sendonly urn:ietf:params:rtp-hdrext:sdes:mid

Answer1: (needs to receive RTP mid)
a=3Dsendrecv
a=3Dextmap:1/recvonly urn:ietf:params:rtp-hdrext:sdes:mid

Answer2: (does not need to receive RTP mid)
a=3Dsendrecv
(no a=3Dextmap)



> Just to verify: you are suggestion to send the value in RTP using
>draft-westerlund-avtext-sdes-hdr-ext, and in RTCP using a SDES item?


Correct.


Mo


From nobody Wed Jul 16 14:54:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF58A1A035D for ; Wed, 16 Jul 2014 14:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFsLFb8sgMRL for ; Wed, 16 Jul 2014 14:53:59 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B2C1A01E7 for ; Wed, 16 Jul 2014 14:53:47 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-19-53c6f468f5a5
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.55.19155.864F6C35; Wed, 16 Jul 2014 23:53:45 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 23:53:44 +0200
From: Christer Holmberg 
To: "Mo Zanaty (mzanaty)" , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoQU78h52Sxxq+0KgfCIIEBDlnZuivd2AgABRmWD//+1WAIAAQTvg
Date: Wed, 16 Jul 2014 21:53:43 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3C9278@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8E50@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.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW7ml2PBBt+n8FpMXf6YxeLFgzlM Fis2HGB1YPb4+/4Dk8eU3xtZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfGmYTFrwQ+OimefWpka GBeydzFyckgImEj8fXKUFcIWk7hwbz1bFyMXh5DAUUaJS4ces0M4ixglelb8Bari4GATsJDo /qcN0iAiUCWx795LFhBbWCBGovNiEzNEPFbiy/+fULabxMr2nWALWARUJc5/uQ+2mFfAV+Lf g1/MEPO/M0pMmn6RCSTBKaAvMevIXTCbEeii76fWgNnMAuISt57MZ4K4VEBiyZ7zzBC2qMTL x/+gPlCSWLH9EiNEvZ7EjalT2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsY WVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbPwS2/VXcwXn7jeIhRgINRiYc3ofVYsBBr YllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHRg0ZS339T26fzm QwFCXp27/9pwKIfE/PZhXPPTRp7RcNpGw/vvZ2oHcq1+/0RuteztHbWi9x+ZuEpb+XU8XL7m dXfdwZ3N2819i+2fq2mo9uxZsI4t+X6xc3fXt30czBq1B+dOmCl+R6l9z7aK6XWTp95M9BTe HWtTofV9cbv+3qD7CYfkNyqxFGckGmoxFxUnAgAmCmWHfwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sxwURJFHNmEW2gASeTz89nRHaXE
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 21:54:07 -0000

Hi,

>> Note that you can also indicate direction in the extmap attribute, but=20
>>I haven't had time to check how/if it is relate to the direction attribut=
e.
>
>Good point. I didn=B9t think that would be useful at first, but now see so=
me possible uses. The extmap >direction inherits from the m-line direction,=
 but can override it. This could be useful for a=3Dsendrecv >cases where th=
e offerer does not need to receive the extension (e.g. it offers unique PTs=
 across m->lines), but is willing to send the extension in case the answere=
r needs it.
>
>Offer: (does not need to receive RTP mid, but willing to send it) a=3Dsend=
recv a=3Dextmap:1/sendonly >urn:ietf:params:rtp-hdrext:sdes:mid
>
>Answer1: (needs to receive RTP mid)
>a=3Dsendrecv
>a=3Dextmap:1/recvonly urn:ietf:params:rtp-hdrext:sdes:mid
>
>Answer2: (does not need to receive RTP mid) a=3Dsendrecv (no a=3Dextmap)

That would mean that the offerer must always include the extmap attribute i=
n the offer, even if it does not need to receive, as it shall allow for the=
 answerer to indicate that it wants to receive.

Regards,

Christer


From nobody Wed Jul 16 15:27:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DE1A0365 for ; Wed, 16 Jul 2014 15:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.552
X-Spam-Level: 
X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZFfyhoHRal8 for ; Wed, 16 Jul 2014 15:27:03 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6131A0354 for ; Wed, 16 Jul 2014 15:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2432; q=dns/txt; s=iport; t=1405549624; x=1406759224; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UUa3jys2HAjnGanbM8wduNr5Amt36F8dWTT/5OMmly0=; b=Rf3lVSFQFpmSFXQL1ZoTwWWqMKj373JfPaXVQQcOlpq/QgB1H+8YNULm 4GcqXzVxPDdY7IzvymobKe7N6IO+KEOqMXhVVSXhJv4eEqhghmFqHEziS NXDiOmaju1/6xdUYnNbJ+cdXggPFSFfZls7tK9qxHgtttQ4VGVvD/CzGh I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAFL7xlOtJV2b/2dsb2JhbABaDoMAgSkEgnLIAwEZchZ2hAQBAQMBJw1VAgEIHCgCAjAlAgQBEog6CJZWnCEGl1oXgSaNcjqCcYFSAQSbHZQsggKBAEJsgQMFPQ
X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208";a="340567924"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jul 2014 22:27:03 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6GMR3VK007484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 22:27:03 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 17:27:02 -0500
From: "Mo Zanaty (mzanaty)" 
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
Thread-Index: AQHPoUUQ15vAFzwn4UeHJ2tqhlBcXg==
Date: Wed, 16 Jul 2014 22:27:01 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3C7224@ESESSMB209.ericsson.se> <53C69110.504@alum.mit.edu>  <7594FB04B1934943A5C02806D1A2204B1D3C8E50@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D3C9278@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3C9278@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.82.253.22]
Content-Type: text/plain; charset="euc-kr"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2f068gd_A3KMLAMLfvZAnLthwyQ
Subject: Re: [MMUSIC] BUNDLE: usage of SDP mid attribute value to implement "receiver-id"?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 22:27:05 -0000

VGhhdCBtYXkgYmUgYSBnb29kIGFwcHJvYWNoLg0KDQpBbHRob3VnaCB5b3UgY291bGQgYXJndWUg
dGhhdCBpZiB0aGUgb2ZmZXJlciBjYW4gYXZvaWQgcmV1c2luZyBQVHMgYW5kDQp0aHVzIG5vdCBu
ZWVkIGFueSBSVFAgbWlkLCBzbyBjYW4gdGhlIGFuc3dlcmVyLiBUaGUgYW5zd2VyZXIgbWF5IHVz
ZQ0KZGlmZmVyZW50IFBUIHZhbHVlcywgYnV0IGl0IGNhbqGvdCBhbnN3ZXIgd2l0aCBtb3JlIFBU
cyB0aGFuIG9mZmVyZWQuDQoNClRoZSBvbmx5IGNhc2Ugd2hlcmUgSSBjYW4gZW52aXNpb24gdGhp
cyBiZWluZyB1c2VmdWwgaXMgaWYgdGhlIG9mZmVyZXINCnVzZXMgdGhlIGVudGlyZSBwcmltYXJ5
IGR5bmFtaWMgUFQgcmFuZ2UgYW5kIGlzIHdpbGxpbmcgdG8gdXNlIHNlY29uZGFyeQ0KYW5kIHRl
cnRpYXJ5IFBUIHJhbmdlcyBhcyB3ZWxsLCBidXQgdGhlIGFuc3dlcmVyIGZvciBzb21lIHJlYXNv
biBpcyBvbmx5DQp3aWxsaW5nIG9yIGFibGUgdG8gdXNlIHRoZSBwcmltYXJ5IGR5bmFtaWMgcmFu
Z2UgYW5kIHRoZXJlZm9yZSBtdXN0IHJldXNlDQpQVHMgaWYgaXQgYWNjZXB0cyB0aGF0IG1hbnkg
Zm9ybWF0cy4NCg0KTW8NCg0KDQpDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tPiB3cm90ZToNCkhpLA0KDQo+PiBOb3RlIHRoYXQgeW91IGNhbiBhbHNvIGlu
ZGljYXRlIGRpcmVjdGlvbiBpbiB0aGUgZXh0bWFwIGF0dHJpYnV0ZSwgYnV0DQo+PkkgaGF2ZW4n
dCBoYWQgdGltZSB0byBjaGVjayBob3cvaWYgaXQgaXMgcmVsYXRlIHRvIHRoZSBkaXJlY3Rpb24N
Cj4+YXR0cmlidXRlLg0KPg0KPkdvb2QgcG9pbnQuIEkgZGlkbqn2dCB0aGluayB0aGF0IHdvdWxk
IGJlIHVzZWZ1bCBhdCBmaXJzdCwgYnV0IG5vdyBzZWUNCj5zb21lIHBvc3NpYmxlIHVzZXMuIFRo
ZSBleHRtYXAgPmRpcmVjdGlvbiBpbmhlcml0cyBmcm9tIHRoZSBtLWxpbmUNCj5kaXJlY3Rpb24s
IGJ1dCBjYW4gb3ZlcnJpZGUgaXQuIFRoaXMgY291bGQgYmUgdXNlZnVsIGZvciBhPXNlbmRyZWN2
DQo+PmNhc2VzIHdoZXJlIHRoZSBvZmZlcmVyIGRvZXMgbm90IG5lZWQgdG8gcmVjZWl2ZSB0aGUg
ZXh0ZW5zaW9uIChlLmcuIGl0DQo+Pm9mZmVycyB1bmlxdWUgUFRzIGFjcm9zcyBtLT5saW5lcyks
IGJ1dCBpcyB3aWxsaW5nIHRvIHNlbmQgdGhlIGV4dGVuc2lvbg0KPj5pbiBjYXNlIHRoZSBhbnN3
ZXJlciBuZWVkcyBpdC4NCj4NCj5PZmZlcjogKGRvZXMgbm90IG5lZWQgdG8gcmVjZWl2ZSBSVFAg
bWlkLCBidXQgd2lsbGluZyB0byBzZW5kIGl0KQ0KPmE9c2VuZHJlY3YNCj5hPWV4dG1hcDoxL3Nl
bmRvbmx5IHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQo+DQo+QW5zd2VyMTog
KG5lZWRzIHRvIHJlY2VpdmUgUlRQIG1pZCkNCj5hPXNlbmRyZWN2DQo+YT1leHRtYXA6MS9yZWN2
b25seSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KPg0KPkFuc3dlcjI6IChk
b2VzIG5vdCBuZWVkIHRvIHJlY2VpdmUgUlRQIG1pZCkNCj5hPXNlbmRyZWN2DQo+KG5vIGE9ZXh0
bWFwKQ0KDQpUaGF0IHdvdWxkIG1lYW4gdGhhdCB0aGUgb2ZmZXJlciBtdXN0IGFsd2F5cyBpbmNs
dWRlIHRoZSBleHRtYXAgYXR0cmlidXRlDQppbiB0aGUgb2ZmZXIsIGV2ZW4gaWYgaXQgZG9lcyBu
b3QgbmVlZCB0byByZWNlaXZlLCBhcyBpdCBzaGFsbCBhbGxvdyBmb3INCnRoZSBhbnN3ZXJlciB0
byBpbmRpY2F0ZSB0aGF0IGl0IHdhbnRzIHRvIHJlY2VpdmUuDQoNClJlZ2FyZHMsDQoNCkNocmlz
dGVyDQoNCg==


From nobody Wed Jul 16 20:31:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236501A0537 for ; Wed, 16 Jul 2014 20:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0hV3D7F6kdX for ; Wed, 16 Jul 2014 20:31:02 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1311A0389 for ; Wed, 16 Jul 2014 20:31:02 -0700 (PDT)
Received: by mail-yk0-f173.google.com with SMTP id 131so988775ykp.32 for ; Wed, 16 Jul 2014 20:31:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ZaZDaAhdgvTsj0ScRiRL+GIY6zv7KQEoihTY4xUEbqQ=; b=KjApXTJ4m6PrL87rcbabzYMomvvMguOYT/n6f/W7unmqSbDcBd9O3b+tufWB7Gv6Jg CyYDVECqUPPAnNgzdbT9nxIvhTsSNT0YQ5xiQPd4Si40Kfp45GiarZ1CG746kFGDNvoZ b0ib9zJwaqL5uiGWJQbEHy1cm7JT0NzN7qfRw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=ZaZDaAhdgvTsj0ScRiRL+GIY6zv7KQEoihTY4xUEbqQ=; b=OBgwynKOhCH2A23QC9pfGu2f9Kstlxu/iV+6mT8M7Gj5hG25MRhxgo5H8ezK7ueVdY AFiXJdNPA5ev/XNKsC1nU5m6ux2v66b5o8ofQsItl+Gkr88cGHd1VqKPO97THcogR6JW BWTU9i5sqAOGHWn0Bpo2KmjL8L//e7zKajRUlGgJyeYnweFJXqlO9q6OgeuUC2SnxDBr uwur4Z14qzKzqceHL85OYI3zwHT0cStg0e23k0w6cUh5XPS8BEzOAmW68CfgiQBlfzXX P3MlEURtQvn1MO49NgbPjDyoFPHXQ5j7wOYWeUh3A4blAj1Z935+AAp/f4r2OSCWq3jX alDQ==
X-Gm-Message-State: ALoCoQnuKrWZKuQNiTrsAlHZqcLV83G2FgFixrKR+XCkm0zcep9QkgS1YQ4TF3TO2ptDh88Sm9QZ
X-Received: by 10.236.209.97 with SMTP id r61mr14241598yho.3.1405567861731; Wed, 16 Jul 2014 20:31:01 -0700 (PDT)
Received: from [192.168.2.106] (cpe-72-190-19-229.tx.res.rr.com. [72.190.19.229]) by mx.google.com with ESMTPSA id o42sm2691153yhe.51.2014.07.16.20.31.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 20:31:01 -0700 (PDT)
From: Dean Willis 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Wed, 16 Jul 2014 22:30:58 -0500
To: mmusic@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CiJxLRSzd5kHH5-oZ5svDEWQAw8
Subject: [MMUSIC] Mail archive prior to 2002
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:31:04 -0000

The official IETF email archive for this group starts in 2002.

I seem to recall a =93conference control=94 mailing list prior to that =
time.=20

Can anybody point me to an archive?

I thought we were going to migrate said archive (which I hope exists =
SOMEWHERE) to the IETF system, when we migrated the lists. I probably =
have an archive of 1998-2002 somewhere, but it would be a bit tedious to =
retrieve.

=97
Dean=


From nobody Wed Jul 16 23:41:38 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206261A0645 for ; Wed, 16 Jul 2014 23:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaGOS3unQCQB for ; Wed, 16 Jul 2014 23:41:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4731A02DB for ; Wed, 16 Jul 2014 23:41:33 -0700 (PDT)
Received: from [172.17.0.14] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6H6fU2v009418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 01:41:32 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be [172.17.0.14]
References: 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11D257)
From: Adam Roach 
Date: Thu, 17 Jul 2014 01:41:30 -0500
To: Dean Willis 
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MmGQYYgX2rRIW-EGTYYGkYBVSO4
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Mail archive prior to 2002
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 06:41:35 -0000

https://mailarchive.ietf.org/ contains the confctrl archives going all the w=
ay back to the creation of that mailing list.

If that doesn't work for you, let me know -- I have a copy of the whole thin=
g, downloaded from the ISC servers, in mbox format.=20

/a

> On Jul 16, 2014, at 22:30, Dean Willis  wrote:
>=20
>=20
> The official IETF email archive for this group starts in 2002.
>=20
> I seem to recall a =E2=80=9Cconference control=E2=80=9D mailing list prior=
 to that time.=20
>=20
> Can anybody point me to an archive?
>=20
> I thought we were going to migrate said archive (which I hope exists SOMEW=
HERE) to the IETF system, when we migrated the lists. I probably have an arc=
hive of 1998-2002 somewhere, but it would be a bit tedious to retrieve.
>=20
> =E2=80=94
> Dean
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Thu Jul 17 06:03:56 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D4F1B27AA for ; Tue, 15 Jul 2014 17:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level: 
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2dAnRKuT0Xd for ; Tue, 15 Jul 2014 17:31:42 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654B41B27A2 for ; Tue, 15 Jul 2014 17:31:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1405470702; x=1437006702; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=W5B9DEWvwnD0VEnD9Zum7daa3nz/hrvkFqygDUpndrs=; b=BOlTQPt19ri4PiJBHp3mGrP1I3dyzxSjl1SAk6BWl4+D+Vw5WXfwzKS5 gaG8154d+X5MrW2HhouH6aTkU0GkR+WtY47uz8SWugvSBm7qCQ4QWNluT p5dUoujVtBeao68azk0luOkD5NX4QOua1Ki3cFt93F+1NV21mJ6h3fe47 o=;
X-IronPort-AV: E=McAfee;i="5600,1067,7500"; a="71232582"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 15 Jul 2014 17:31:41 -0700
X-IronPort-AV: E=Sophos;i="5.01,668,1400050800"; d="scan'208";a="713654038"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Jul 2014 17:31:41 -0700
Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 15 Jul 2014 17:31:40 -0700
Message-ID: 
In-Reply-To:                       
References:   <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell> 	<513B64DC.7070305@stpeter.im>   <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com>  <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se>    <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell> 	<513B64DC.7070305@stpeter.im>   <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com>  <513CDF15.8070601@alvestrand.no>   <51EEC4A8.9050108@alum.mit.edu> <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu>     <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell> 	<513B64DC.7070305@stpeter.im>   <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com>  <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se>  <513CFBC5.6060209@omnitor.se>   <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>   <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <513B64DC.7070305@stpeter.im>   <949EF20990823C4C85C18D59AA11AD8BEE98@FR712WXCHMBA11.zeu.alcatel-lucen t.com>   <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <513B64DC.7070305@stpeter.im>    <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <513B64DC.7070305@stpeter.im>   <1895B1D5-99E2-45CB-89EC-7B949091F622@standardstrack.com>  	<512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <513B64DC.7070305@stpeter.im>   <9F33F40F6F2CD847824537F3C4E37DDF06892E82@MCHP04MSX.global-ad.net>  	<512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell> 	<513B64DC.7070305@stpeter.im>   <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com>  	<512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <51362552.9070204@qti.qualcomm.com>   <51EEC4A8.9050108@alum.mit.edu> <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu>   <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <513B64DC.7070305@stpeter.im>    <512C4B0D.5000701@cisco.com>  <6E90227CD3894A258EDE91D85B987169@DougEwell>  <513B64DC.7070305@stpeter.im>  <51EEC4A8.9050108@alum.mit.edu> <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu>        <513C996A.6000007@cisco.com>              <512C4B0D.5000701@cisco.com>                        <6E90227CD3894A258EDE91D85B987169@DougEwell>             <513B6C0E.8000604@isode.com>  
X-Mailer: Eudora for Mac OS X
Date: Tue, 15 Jul 2014 17:31:37 -0700
To: Flemming Andreasen , Gunnar Hellstrom , Brian Rosen , Peter Saint-Andre , Keith Drage , Peter Saint-Andre , Brian Rosen , Ari Keranen , Pete Resnick , Alexey Melnikov , Eric Burger , Eric Burger , "Hutton, Andrew" , Harald Alvestrand , Henning Schulzrinne , Nathaniel Borenstein , Nik Tomkinson , 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DiIr4ai3Pj2XbVP1bxPRMzF2WKE
X-Mailman-Approved-At: Thu, 17 Jul 2014 06:03:55 -0700
Cc: ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: [MMUSIC] Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jul 2014 00:31:44 -0000

Hi to everyone who participated in previous discussions about the 
human language negotiation draft.

I'd like to make progress on this draft.  I think meeting in Toronto 
can help that.  Please participate.

I created a Doodle poll to see if we can find a time in Toronto to 
meet face to face.

Doodle poll for time at Toronto to discuss open issues and moving 
forward with Human Language Negotiation: 
http://doodle.com/pm3mph6xa3m9kupp

Link to current version (-02) of draft: 
http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Citizens for corrupt government, unclean water, higher taxes,
unsafe streets, and poor schools.


From nobody Thu Jul 17 11:40:19 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B0E1A00CD for ; Thu, 17 Jul 2014 11:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbAgNgEL-F3u for ; Thu, 17 Jul 2014 11:38:21 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBBE1A00B8 for ; Thu, 17 Jul 2014 11:38:20 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-63-53c8181abafd
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C0.11.04090.A1818C35; Thu, 17 Jul 2014 20:38:18 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.174.1; Thu, 17 Jul 2014 20:38:17 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id BDAC9110299; Thu, 17 Jul 2014 21:38:17 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0D67E589BE;	Thu, 17 Jul 2014 21:38:21 +0300 (EEST)
Received: from Aris-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BD099589BD;	Thu, 17 Jul 2014 21:38:20 +0300 (EEST)
Message-ID: <53C8180C.40701@ericsson.com>
Date: Thu, 17 Jul 2014 21:38:04 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Bernard Aboba 
References: ,  
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja6UxIlgg0XbjCz2L7nMbDF1+WMW ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJWx7/Zh9oLFHBXb9z5iaWA8zNbFyMkhIWAi 8eHPRXYIW0ziwr31QHEuDiGBo4wSe691MUI4GxglTnVcgcrsZZSY2rifFcJZxyjR+v4fC0i/ kMAqRonLS2JBbF4BTYl519eygtgsAqoSi34fBNvHJmAvcXPCdbB9ogLJEl2PfrBD1AtKnJz5 BGgOB4eIgK7E3y4jEJNZQF3i6uIgkAphAR+JyR82MEGsnc0osW/lcSaQBKeAlcSdmTfBxjML 2EpcmHOdBcKWl2jeOpsZ4jU1iavnNjFDnKkqcfXfK8YJjKKzkGyehaR9FpL2BYzMqxhFi1OL i3PTjYz0Uosyk4uL8/P08lJLNjECY+Lglt9WOxgPPnc8xCjAwajEw6vAfyJYiDWxrLgy9xCj NAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwzm1gdpn3dr7wO7GECzvWXyvu 1cvjWsXBYX9ohXbkls6WqDOuO+3nFlVJWHYanjspnDtnyrEFK85r3nC5p18/eYLvXqNzj8Xa Np6e9vzOvVAOwzWvb/WcaAp8MmlvXX5vTfithZI2MicYtjN8f+3MP/uxxdu7SxcffGcde/Gp h8DOpG//NztwlyixFGckGmoxFxUnAgDoXtEqagIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sL00NABL12sjWbfr0O1D8qFgfzM
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 18:38:22 -0000

On 16/07/14 02:42, Bernard Aboba wrote:
>
> Ari said:
>
> "Anything else in particular to consider?"
>
> [BA] Does the MUST restart guidance apply more generally?  For example,
> whether a restart is always required when changing the target of the
> media stream or the implementation level.   Also, the guidance on the
> set of candidates (some, none or all of the previous candidates or a new
> set) doesn't seem specific to SIP.

Regarding the media stream target and "implementation level", since 
these may not even apply to many non-SIP protocols, I would say that it 
should not be in the main spec. However, probably we should state here 
that the protocol using ICE needs to define when/if a restart is really 
required.

If you want to proxy your protocol to a SIP environment, doing the same 
thing that SIP does regarding restarts is probably a MUST.

The candidate guidance (last sentence of section 9.1.1.1 in RFC5245) 
seems to me generic enough to stay here as such.

Sounds like a good way forward?


Cheers,
Ari


From nobody Thu Jul 17 11:42:34 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF9C1A00DC for ; Thu, 17 Jul 2014 11:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ32EzuQzm2v for ; Thu, 17 Jul 2014 11:40:53 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C111A009C for ; Thu, 17 Jul 2014 11:40:52 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-d5-53c818b298e5
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.F4.19155.2B818C35; Thu, 17 Jul 2014 20:40:51 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Thu, 17 Jul 2014 20:40:50 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 7770D110299; Thu, 17 Jul 2014 21:40:50 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BC7D4589BE;	Thu, 17 Jul 2014 21:40:53 +0300 (EEST)
Received: from Aris-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 717C2589BD;	Thu, 17 Jul 2014 21:40:53 +0300 (EEST)
Message-ID: <53C818A5.30406@ericsson.com>
Date: Thu, 17 Jul 2014 21:40:37 +0300
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References: 		 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje5miRPBBnNb2S2m77OxuHbmH6PF 1OWPWRyYPc41vGf32DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgytpxlK9jKUrFv5nX2BsY9 zF2MnBwSAiYSty/dZYWwxSQu3FvP1sXIxSEkcJRR4vbNT8wQzgZGie8r5rJAOHsZJQ587IBy 1jFKzP/byA7hrGKU2D+9BWwYr4CmRFdbJ9gSFgFVicYnz9hAbDYBW4nVr26ygNiiAskSXY9+ sEPUC0qcnPkELC4iYCNxY+IEpi5GDg5mgRCJC0dCQcLCAj4Skz9sYILY9Y1RYseWY4wgCU6B QImN1/eA7WUWsJBY/OYgO4QtL9G8dTbUo2oSV89tArOFgO65+u8V4wRG0VlIVs9C0j4LSfsC RuZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFxcnDLb9UdjJffOB5iFOBgVOLhfXDteLAQ a2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDMl/fZtXfOOeG5 +mL3W34dW+rSFrpznuVlkdk+/wyKJ9xUslp2pf1/2m7NVpP9l49/ZPkQm/Y7qmGKQOvaVI9e 3dLZanFTNvZz3XG7n6I166/qPb49k6MnKSwPqsldL5G5ioth8srVp+6fmPfuzpXtkSqfnPWn 12c4Sy8VK9aa3vvQLoTv8dI0JZbijERDLeai4kQASQZ27HQCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2Z7hDDBr7UOQvZLlFVk9ie6JAjs
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 18:40:55 -0000

On 16/07/14 02:04, Martin Thomson wrote:
> On 15 July 2014 15:52, Iñaki Baz Castillo  wrote:
>> Why should the ufrag and pwd change upon ICE restart? I mean: is there
>> a real reason for that?
>
> Yes, it's a signal to a peer that a restart is happening.  Ostensibly,
> it's actually unnecessary, but as a practical matter, you gotta do it.

I think it makes sense to keep this behavior (for better 
interoperability with SIP environments, backward compatibility, etc.) 
unless there is a good reason not to do it.


Cheers,
Ari



From nobody Thu Jul 17 13:28:25 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5171A0208 for ; Thu, 17 Jul 2014 13:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.202
X-Spam-Level: 
X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozap-8X1Gv_a for ; Thu, 17 Jul 2014 13:28:21 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40FE71A0023 for ; Thu, 17 Jul 2014 13:28:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1565; q=dns/txt; s=iport; t=1405628902; x=1406838502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qn6QpX1i9+1JRoBo4JEmXH7l+KbXkwz6PMS/NaZORtQ=; b=jejXKQIJHO12lrIZ2SaP0g6LXoro0sHM2PnrQAhIWlFNgp4RYXzIfLCU f05Mazkq86hLzt5C6qK/js/b3Si1F71vsRADNtf67tt8wTcD/8rsuMBkt ytwJwbbzApDg1lBbnSfGLih4+K+H3n3njZA2ZG3B5gfrsBhEAH8uLF86v Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFACkxyFOtJV2c/2dsb2JhbABZgw6BKQTLTgGBBxZ2hAQBAQMBeQULAgEIRjIlAgQOBYg6CMVnF48YMweDLoEYAQSKKpB1lCyDRGyBRQ
X-IronPort-AV: E=Sophos;i="5.01,680,1400025600"; d="scan'208";a="61778274"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 17 Jul 2014 20:28:21 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6HKSKHN017153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 20:28:20 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 15:28:20 -0500
From: "Pal Martinsen (palmarti)" 
To: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
Thread-Topic: [MMUSIC] draft-reddy-mmusic-ice-happy-eyeballs-07
Thread-Index: AQHPoEgL90MWCE+1WUOBcqlJ80tW1JulDoyA
Date: Thu, 17 Jul 2014 20:28:20 +0000
Message-ID: <2DF3EF3C-B089-4DA9-97CD-83051E90E15C@cisco.com>
References: <20140630184553.31625.21293.idtracker@ietfa.amsl.com> <803DB627-3D5F-494D-9D25-E1000200A7A1@cisco.com> <53C5539E.2070607@ericsson.com>
In-Reply-To: <53C5539E.2070607@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.163.205]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5D668AF641042C468619DF8A289D1A2B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-c55buetL8oRS7ToUXApwfeJEOk
Cc: "draft-reddy-mmusic-ice-happy-eyeballs@tools.ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] draft-reddy-mmusic-ice-happy-eyeballs-07
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 20:28:23 -0000

On 15 Jul 2014, at 18:15, Ari Ker=E4nen  wrote:

> Hi,
>=20
> I read the latest draft and, without a chair hat on, I think this is=20
> useful work and would make sense to specify in an RFC.
>=20
> Regarding where to do the work, I think the best way forward would be to=
=20
> have this as a separate draft and ICE bis to have this as a reference on=
=20
> how to do candidate prioritization in a dual-stack environment.
>=20
>From a development perspective I agree. For a already implemented ICE stack=
 it is easier to deal with a new RFC than catching the changes in a ICEbis =
version. For new implementations I would focus on getting ICE to work and t=
hen add improvements like this draft provides later.=20

> Additionally, it would be good for someone designing a different=20
> algorithm for the candidate prioritization to have some more guidelines=20
> on how to play around with the values. As you can remember from the past=
=20
> versions, it's not always easy to get it right.
>=20

Yes, the draft currently says its ok to play with the local_preference valu=
e because the pair_priority value would be correct due to the formula used =
when forming the candidate pair.=20

There have been some suggestions that getting some metrics collected so we =
can actually measure the effect on any proposed algorithm.=20
I am going to prepare a slide discussing this for the Toronto meeting.


> And here's a few editorial comments on the draft:
>=20
Thanks will fix those.

.-.
P=E5l-Erik


From nobody Thu Jul 17 17:01:21 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BCB1B28DE for ; Thu, 17 Jul 2014 17:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRx09Z7PtjJp for ; Thu, 17 Jul 2014 17:01:09 -0700 (PDT)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0A14A1B28B7 for ; Thu, 17 Jul 2014 17:01:02 -0700 (PDT)
Received: from userPC (unknown [122.166.174.13]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 60160639499; Fri, 18 Jul 2014 00:00:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1405641664; bh=tHMtQsyENwAvNULYfnuXdXYWnJ1oNhvb8CZD51tY83o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=BmS+mfYC+0d58/6JRQ4tI3RXuVZ+YJr1Auw8TPrdeledZs9UKYbs9uXfJU90Fi2wY 4QXJsT9LoD9BGCdcCno/WepRje3zVwt35l7YZqqOR7eWd+dzcLwMI4rKZx4c/BiCie rH/msTcs0gn5R2VHXnR0+UP4/rXxmeLbTMELJCsE=
From: "Parthasarathi R" 
To: "'Flemming Andreasen'" , "'mmusic'" 
References: <53BBFCBC.7020707@cisco.com>
In-Reply-To: <53BBFCBC.7020707@cisco.com>
Date: Fri, 18 Jul 2014 05:30:48 +0530
Message-ID: <002701cfa21b$597f10b0$0c7d3210$@co.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01CFA249.73374CB0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac+atu5QUdjBU6V/SO2PQBNRPTMzeQHZCTdQ
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020202.53C863BE.004A, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64
X-CTCH-VOD: Unknown
X-CTCH-Spam: Suspect
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 64
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5d5z0qFMur8TzvWbdfQ341vRkN4
Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org, mmusic-chairs@tools.ietf.org
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG	document
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 00:01:17 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0028_01CFA249.73374CB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,

 

I support the adoption of this draft.

 

Thanks

Partha

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming
Andreasen
Sent: Tuesday, July 08, 2014 7:44 PM
To: mmusic
Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org;
mmusic-chairs@tools.ietf.org
Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG
document

 

Greetings,

We have an MMUSIC milestone for "SIP usage for Trickle ICE", and at the IETF
89 meeting we had a call for adoption of the Trickle ICE SIP draft as a WG
document. There was a strong consensus in favor of adopting the document.
After the meeting there were a few comments on the document, which were
discussed on the MMUSIC mailing list and resulted in an updated version of
the document: 

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02 

At this point, the chairs would like to confirm adopting the updated draft
as a WG document. If you have any concerns regarding the adoption, please
let us know no later than Friday, July 18th, 2014. 

Thanks, 

    Ari & Flemming (MMUSIC chairs) 


------=_NextPart_000_0028_01CFA249.73374CB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi all,



 



I support the adoption of this =
draft.



 



Thanks



Partha



 












From: mmusic
[mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming =
Andreasen

Sent: Tuesday, July 08, 2014 7:44 PM

To: mmusic

Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org;
mmusic-chairs@tools.ietf.org

Subject: [MMUSIC] Adoption of =
draft-ivov-mmusic-trickle-ice-sip-02 as WG
document









 



Greetings,



We have an MMUSIC milestone for "SIP usage for Trickle ICE", =
and at
the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP =
draft as
a WG document. There was a strong consensus in favor of adopting the =
document.
After the meeting there were a few comments on the document, which were
discussed on the MMUSIC mailing list and resulted in an updated version =
of the
document: 



=
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02




At this point, the chairs would like to confirm adopting the updated =
draft as a
WG document. If you have any concerns regarding the adoption, please let =
us
know no later than Friday, July 18th, 2014. 



Thanks, 



    Ari & Flemming (MMUSIC chairs) 












------=_NextPart_000_0028_01CFA249.73374CB0--


From nobody Thu Jul 17 17:24:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB91A0233 for ; Thu, 17 Jul 2014 17:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo_1i29EA-wG for ; Thu, 17 Jul 2014 17:24:40 -0700 (PDT)
Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387621A00E2 for ; Thu, 17 Jul 2014 17:24:40 -0700 (PDT)
Received: by mail-oa0-f42.google.com with SMTP id n16so1933058oag.15 for ; Thu, 17 Jul 2014 17:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lwE8q6TXY0gcTE8udXNscQ2Fcb2jYbxr3zgKLsOB/Pk=; b=iTPAa5L65JqrpYtO9emIbrJT4kClD1p358MJKLVdTk4fn6YBScPgLLQInV/nmf+dvA daaOupPJeyrNk1mzyjbFH5vtORanzkTQF8XJ64oKVhwXcAgzo5CktE+/T6pl6gEdOElC X3RFIgT6G8wj0BKIBPI9k1KkYCjU+aYxHMeaI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lwE8q6TXY0gcTE8udXNscQ2Fcb2jYbxr3zgKLsOB/Pk=; b=jG+TwrqBE6hhwYyVXLcUpifn5EYZLrcsQ84f0D9JrivZ6JTO+rOZOhGU4A7/IL/Cr0 oOFpgsl5rIdm0gvA0FukeDhrmIGhQ1dHR6lFXfuOe1EI8jjVjxul2IHfjHGnC2nMbfX+ O4rhMtC1uRFKzQelHf/z6bIzlNGYpFR4suaTBJJ7HghoJCAB03V9XkDzCf47teQnO7zf bYwx+29V1W4d2wV9py7PsRa17IM8pI2bOjlzhHp0AJ7P6gJaEY388wGuG5d2N3u1AyFH gVLDVNMXNCEOIVkNJJf1zfgecbvpwk5RsTHUzCbVwEYYyyUrRATGs10dB1yfNICAzUh8 uG+g==
X-Gm-Message-State: ALoCoQnPRJJdTJA9DK+6Q8EPwwtZhj8pF/KqR+TjhdB4fOauvy6ClJdMlR7RTnJOBEhpPg5GVks5
X-Received: by 10.60.23.34 with SMTP id j2mr1177197oef.32.1405643079648; Thu, 17 Jul 2014 17:24:39 -0700 (PDT)
Received: from [192.168.2.106] (cpe-72-190-19-229.tx.res.rr.com. [72.190.19.229]) by mx.google.com with ESMTPSA id lk2sm5233763obc.15.2014.07.17.17.24.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 17:24:38 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dean Willis 
In-Reply-To: 
Date: Thu, 17 Jul 2014 19:24:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C5541E2-A4F8-4FDA-ABD0-5DCB462E9AFD@softarmor.com>
References:  
To: Adam Roach 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Aj-W1zzSX0xgpFjSH1pUGckLIC0
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Mail archive prior to 2002
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 00:24:42 -0000

On Jul 17, 2014, at 1:41 AM, Adam Roach  wrote:

> https://mailarchive.ietf.org/ contains the confctrl archives going all =
the way back to the creation of that mailing list.
>=20

It has the content from the time the mailing list moved to IETF. We had =
a lot of history before 2001; specifically, all the SIP work that =
happened before the spinoff of the SIP working group.


> If that doesn't work for you, let me know -- I have a copy of the =
whole thing, downloaded from the ISC servers, in mbox format.=20

ooh, that would be awesome.

Turns out that for AVT, the =93old server=94 archives are on an IETF FTP =
server, sortof hiding.

=97
Dean=


From nobody Thu Jul 17 18:36:26 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5FF1A011E for ; Thu, 17 Jul 2014 18:36:24 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImhXEf63rFMv for ; Thu, 17 Jul 2014 18:36:23 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CC01A0115 for ; Thu, 17 Jul 2014 18:36:23 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6I1aLKg019822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 20:36:22 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <53C87A14.3020300@nostrum.com>
Date: Thu, 17 Jul 2014 20:36:20 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Dean Willis 
References:   <0C5541E2-A4F8-4FDA-ABD0-5DCB462E9AFD@softarmor.com>
In-Reply-To: <0C5541E2-A4F8-4FDA-ABD0-5DCB462E9AFD@softarmor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/L2Z5C8pu0wiuLTsKlShyzU-VH7k
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Mail archive prior to 2002
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 01:36:25 -0000

On 7/17/14 19:24, Dean Willis wrote:
> On Jul 17, 2014, at 1:41 AM, Adam Roach  wrote:
>
>> https://mailarchive.ietf.org/ contains the confctrl archives going all the way back to the creation of that mailing list.
>>
> It has the content from the time the mailing list moved to IETF. We had a lot of history before 2001; specifically, all the SIP work that happened before the spinoff of the SIP working group.

You mean stuff like this?

https://mailarchive.ietf.org/arch/msg/mmusic/cbc9aaDbP82YUOGnsldWTLHNz5Y

Yeah, it's in there.

>
>> If that doesn't work for you, let me know -- I have a copy of the whole thing, downloaded from the ISC servers, in mbox format.
> ooh, that would be awesome.

For a limited time only:

https://dl.dropboxusercontent.com/u/53717247/confctrl.mail.gz

/a


From nobody Thu Jul 17 18:43:03 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F88C1A014C for ; Thu, 17 Jul 2014 18:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwDXwbisJFzn for ; Thu, 17 Jul 2014 18:43:00 -0700 (PDT)
Received: from BLU004-OMC3S3.hotmail.com (blu004-omc3s3.hotmail.com [65.55.116.78]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4861A011E for ; Thu, 17 Jul 2014 18:43:00 -0700 (PDT)
Received: from BLU181-W72 ([65.55.116.73]) by BLU004-OMC3S3.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Thu, 17 Jul 2014 18:42:59 -0700
X-TMN: [JTBVATFRAqAAUielvwc3+ePr2Li5ABFE]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_52070376-e0e9-4f07-bcb4-06377fb52d7f_"
From: Bernard Aboba 
To: Parthasarathi R , 'Flemming Andreasen' , 'mmusic' 
Date: Thu, 17 Jul 2014 18:42:58 -0700
Importance: Normal
In-Reply-To: <002701cfa21b$597f10b0$0c7d3210$@co.in>
References: <53BBFCBC.7020707@cisco.com>, <002701cfa21b$597f10b0$0c7d3210$@co.in>
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jul 2014 01:42:59.0614 (UTC) FILETIME=[9B1383E0:01CFA229]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4bbzOvgymKb2e0Ag0NlBUz07dM4
Cc: "draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" 
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 01:43:02 -0000

--_52070376-e0e9-4f07-bcb4-06377fb52d7f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I also support adoption.=20

From: partha@parthasarathi.co.in
To: fandreas@cisco.com=3B mmusic@ietf.org
Date: Fri=2C 18 Jul 2014 05:30:48 +0530
CC: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org=3B mmusic-chairs@tools=
.ietf.org
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as W=
G	document

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Hi all=2C=0A=
=0A=
 =0A=
=0A=
I support the adoption of this draft.=0A=
=0A=
 =0A=
=0A=
Thanks=0A=
=0A=
Partha=0A=
=0A=
 =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
From: mmusic=0A=
[mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
=0A=
Sent: Tuesday=2C July 08=2C 2014 7:44 PM
=0A=
To: mmusic
=0A=
Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org=3B=0A=
mmusic-chairs@tools.ietf.org
=0A=
Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG=0A=
document=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
 =0A=
=0A=
Greetings=2C
=0A=

=0A=
We have an MMUSIC milestone for "SIP usage for Trickle ICE"=2C and at=0A=
the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP draft=
 as=0A=
a WG document. There was a strong consensus in favor of adopting the docume=
nt.=0A=
After the meeting there were a few comments on the document=2C which were=
=0A=
discussed on the MMUSIC mailing list and resulted in an updated version of =
the=0A=
document:=20
=0A=

=0A=
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02=0A=

=0A=

=0A=
At this point=2C the chairs would like to confirm adopting the updated draf=
t as a=0A=
WG document. If you have any concerns regarding the adoption=2C please let =
us=0A=
know no later than Friday=2C July 18th=2C 2014.=20
=0A=

=0A=
Thanks=2C=20
=0A=

=0A=
    Ari & Flemming (MMUSIC chairs) =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

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

--_52070376-e0e9-4f07-bcb4-06377fb52d7f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





I also support adoption. =3B=


From: partha@parthasarathi.co.in
To=
: fandreas@cisco.com=3B mmusic@ietf.org
Date: Fri=2C 18 Jul 2014 05:30:4=
8 +0530
CC: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org=3B mmusic-c=
hairs@tools.ietf.org
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic=
-trickle-ice-sip-02 as WG	document

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

=0A=
=0A=

Hi al=
l=2C
=0A=
=0A=

 =
=3B
=0A=
=0A=

I sup=
port the adoption of this draft.
=0A=
=0A=

 =
=3B
=0A=
=0A=

Thank=
s
=0A=
=0A=

Parth=
a
=0A=
=0A=

 =
=3B
=0A=
=0A=

=0A=
=0A=

=0A=
=0A=

=0A=
=0A=

=
From: mmusic=0A=
[mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
=
=0A=
Sent: Tuesday=2C July 08=2C 2014 7:44 PM
=0A=
To: mmusic
=0A=
Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org=3B=0A=
mmusic-chairs@tools.ietf.org
=0A=
Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 a=
s WG=0A=
document
=0A=
=0A=

=0A=
=0A=

=0A=
=0A=

 =3B
=0A=
=0A=

Greetings=2C
=0A=

=0A=
We have an MMUSIC milestone for "SIP usage for Trickle ICE"=2C and at=0A=
the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP draft=
 as=0A=
a WG document. There was a strong consensus in favor of adopting the docume=
nt.=0A=
After the meeting there were a few comments on the document=2C which were=
=0A=
discussed on the MMUSIC mailing list and resulted in an updated version of =
the=0A=
document: 
=0A=

=0A=
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice=
-sip-02=0A=

=0A=

=0A=
At this point=2C the chairs would like to confirm adopting the updated draf=
t as a=0A=
WG document. If you have any concerns regarding the adoption=2C please let =
us=0A=
know no later than Friday=2C July 18th=2C 2014. 
=0A=

=0A=
Thanks=2C 
=0A=

=0A=
 =3B =3B =3B Ari &=3B Flemming (MMUSIC chairs) 
=0A=
=0A=

=0A=
=0A=

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

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

=

--_52070376-e0e9-4f07-bcb4-06377fb52d7f_--


From nobody Fri Jul 18 09:59:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49CD1A0ABE for ; Fri, 18 Jul 2014 09:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCE5V64gFH9i for ; Fri, 18 Jul 2014 09:59:39 -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 E4E301A01C8 for ; Fri, 18 Jul 2014 09:59:37 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id TsnJ1o0040vyq2s53szdih; Fri, 18 Jul 2014 16:59:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Tszc1o00u3ZTu2S3RszdBh; Fri, 18 Jul 2014 16:59:37 +0000
Message-ID: <53C95278.3080305@alum.mit.edu>
Date: Fri, 18 Jul 2014 12:59:36 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: IETF MMUSIC WG ,  "Salvatore Loreto (JO/LMF)" 
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=q20140121; t=1405702777; bh=mtf5NgLDoDIgMk32wNJV1dbIqcfhhQXlJjoGH4joNgg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g4pVwd6u/qaJyvmPIBw7OMpMrxBE33GZepzbMEWIV9yMzhq8nxx6ANp3D7f3tvYvV 4nxUuxkLJ+JyzqTlmTtKeXRcJPRn5QpwMQ8lbfIGg3gOX+Wi4kSHTrLTlX2lSm7qJM 7hgypP5zKXoRJ1vHRBw6HiVxetL2vqqunOybP2bQwk4vEGNi1tfflBx5mLPeX87cq8 gKSzAuAFJ+A9z82hm555QCXkA46JDV/o3Nv/NIfmSKDGb3FN7aiNDfqlc6/W9YMpmY 7gZ35iGW+0Jh8caHI7T7mHhB+uiODfTc6dW3I0H9T5jnLQtH4Npuzi5AKYsXiQIkZl d0H2APLPsBbPQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yBysIrJXbht4C9GnASksiE_8kAs
Subject: [MMUSIC] Plans for draft-ietf-mmusic-sctp-sdp-07
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 16:59:41 -0000

I am surprised not to see discussion of the sctp-sdp draft on the mmusic 
agenda. Why is that?

	Thanks,
	Paul


From nobody Fri Jul 18 14:28:23 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10A11B27EB for ; Fri, 18 Jul 2014 14:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9eQuDe5v4_R for ; Fri, 18 Jul 2014 14:28:20 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54391A023F for ; Fri, 18 Jul 2014 14:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=944; q=dns/txt; s=iport; t=1405718900; x=1406928500; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=g5t8T8zpsdJc3LnTZTRVDB1JUf4oJabjdG1/pcNYrAg=; b=DnW4os2BHsTbF58jUpoUUeTeNIiwqbrSWrnqmPXlavPXYz4yfqzTjzLg xUAGA41Jl0C17Q9HmUppNs9ZUVGQnJmC3/ob7Z/yDvOcZLWUSpR5o+xoQ jDwG9VlsAwHLclqcCkvVwMAZvsLJZzwci+GHE7Hhq7kIpdOU1lCj6j7nN 8=;
X-IronPort-AV: E=Sophos;i="5.01,687,1400025600"; d="scan'208";a="341160428"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2014 21:28:20 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILSJcX013962; Fri, 18 Jul 2014 21:28:19 GMT
Message-ID: <53C99172.8040403@cisco.com>
Date: Fri, 18 Jul 2014 17:28:18 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic issue tracker , draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
References: <057.fd5b9191f403d6ede7290dc1d8ab94d1@trac.tools.ietf.org>
In-Reply-To: <057.fd5b9191f403d6ede7290dc1d8ab94d1@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CHeSEd1BmmBjqcqrhKM9G6VhmwE
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #14 (rfc4566bis): 4566bis: Need to provide ABNF syntax for all 4566 attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:28:22 -0000

I'm in favor of having an ABNF as well. We routinely require it for any 
new extensions to avoid ambiguity.

-- Flemming

On 7/9/14, 8:45 AM, mmusic issue tracker wrote:
> #14: 4566bis: Need to provide ABNF syntax for all 4566 attributes
>
>   Comments: This was discussed again in a side meeting in London and there
>   was not a consensus whether we actually needed this.
>
>   Paul K: IIRC the argument against doing this is that we might get it
>   wrong. But IMO we should do it because if we can't get it right how can we
>   expect readers to get it right?
>
>   Paul K: I'm willing to contribute to this, but won't have time until after
>   the Toronto meeting. Also, I'm not intimately familiar with all of the
>   attributes. I think I could probably produce a credible proposal for an
>   ABNF description all of the attributes currently defined within 4566. This
>   would then need to be carefully reviewed.
>


From nobody Fri Jul 18 14:32:08 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5774D1A026C for ; Fri, 18 Jul 2014 14:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S18GPZ9wew6Q for ; Fri, 18 Jul 2014 14:32:05 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FEE1A0267 for ; Fri, 18 Jul 2014 14:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=877; q=dns/txt; s=iport; t=1405719125; x=1406928725; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gID0Gm155AKpv+NHdsIjjcbCuolSp6GDjx0XuChUg4w=; b=YBCrH+UqFt3CmgDHkAMx5epTyeG0tm3V7apShQl4IIALKSJw/5BA81o8 6NfbTOHV229+jvyv+n6WlsIJHCHE87k0IdYyzz8sRSovTPmZllHN34wAH 7Dfc68KYSLQVAzITXr4Uj2K4ebfz0MqKZ4jiz496tOw5Am3NofcIs+DCG M=;
X-IronPort-AV: E=Sophos;i="5.01,687,1400025600"; d="scan'208";a="341161082"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2014 21:32:04 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILW3ou032081; Fri, 18 Jul 2014 21:32:03 GMT
Message-ID: <53C99253.4020206@cisco.com>
Date: Fri, 18 Jul 2014 17:32:03 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic issue tracker , draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
References: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org>
In-Reply-To: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/745c3FkiogOOs99-aeVKl94Y6FA
Cc: Jonathan Lennox , mmusic , Paul Kyzivat 
Subject: Re: [MMUSIC] [mmusic] #18 (rfc4566bis): 4566bis: Should the source-level attributes defined in 5576 be included in the same table structure in the IANA registry?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:32:06 -0000

I agree with the template part per Paul's comment. I'm less clear on 
what is meant by the 5576 reference. Is it because of bundle and future 
extensions needing to consider the impact of that ?

Thanks

-- Flemming

On 7/9/14, 8:52 AM, mmusic issue tracker wrote:
> #18: 4566bis: Should the source-level attributes defined in 5576 be included in
> the same table structure in the IANA registry?
>
>   Comments: This seems to be an organizational issue rather than a technical
>   issue. If we agree we need this, we can take on this as well.
>
>   Paul K.: Yes, but IMO an important one. The current registries are hard to
>   read, and easy to get wrong when adding new attributes. Also, we ought to
>   have templates for what goes into the IANA consideration section when
>   defining new attributes, and that template would be best in this document.
>


From nobody Fri Jul 18 14:34:51 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848C11A028A for ; Fri, 18 Jul 2014 14:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRnkqSJg24Xn for ; Fri, 18 Jul 2014 14:34:46 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20791A026E for ; Fri, 18 Jul 2014 14:34:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1841; q=dns/txt; s=iport; t=1405719285; x=1406928885; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=eKxvYWoVeaX6uY9G+QaVXIB5I7uDyr8WfnfB0G35usI=; b=NScR5LSj/MZKU0bkJnH3U/TNePheJP8hafWqfONBgKylFLA2rwtnh1HR GFf3kV4SpKYmZwQpCHvF6ikyZWDQMMAxXttnNR5ZpFGL87jv8wUsXzTjA bUuORP2bOy895A8zzSH9ELUnoi8wtzEQxp4wwpMo8/D88cCQlDJNBnpdd Y=;
X-IronPort-AV: E=Sophos;i="5.01,687,1400025600"; d="scan'208";a="341161522"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2014 21:34:45 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILYi6F001331; Fri, 18 Jul 2014 21:34:44 GMT
Message-ID: <53C992F4.1050509@cisco.com>
Date: Fri, 18 Jul 2014 17:34:44 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic issue tracker , draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
References: <057.3b838e4d829c5715eff10acf0456626c@trac.tools.ietf.org>
In-Reply-To: <057.3b838e4d829c5715eff10acf0456626c@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sxBY6ntQ8k6EkYfg7V8MIPbndbM
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #20 (rfc4566bis): 4566bis: Lack of a consistent format for defining new attributes.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:34:47 -0000

I think I agree with 4), but the important part here is that we actually 
get a valid ABNF for all extensions.

-- Flemming

On 7/9/14, 8:57 AM, mmusic issue tracker wrote:
> #20: 4566bis: Lack of a consistent format for defining new attributes.
>
>   Paul K.: Many people look to 4566 for examples of how to do this, but it
>   provides bad examples. IMO 4566bis should show the definition of all
>   attributes in a style that complies with a recommended format for defining
>   attributes. (Of course that implies that we could agree on such a format.)
>
>   From http://www.ietf.org/mail-archive/web/mmusic/current/msg13471.html
>
>   One question is whether the definition of a new attribute should:
>   1) define the full syntax of the line (starting with "a="),
>   2) should provide additional definitions of  (via "/=")
>   3) should provide additional definitions of  and 
>     (via "/=")
>   4) provide definitions of the name and value that are consistent with
>      and  without formally extending the
>     definitions of those.
>
>   Note that 4566 loosely follows (4) but gives the definitions informally
>   rather than via ABNF. So it gives no guidance on how to use ABNF for this.
>   A number of drafts have chosen to follow (2). Some have started to do (1)
>   but I don't know of any that ended up that way.
>
>   A question I have raised is: if (2) or (3) is followed, does that mean
>   that the draft doing so must be considered as "updating" 4566?
>
>   One thing that people sometimes forget when defining new attributes is
>   that the syntax of the new attribute MUST also be valid when parsed by the
>   "generic" attribute syntax. AFAIK there is no way in ABNF to specify that.
>   I think that (4) comes closest.
>


From nobody Fri Jul 18 14:35:56 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FDA1A026C for ; Fri, 18 Jul 2014 14:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAMDm4-41Xu7 for ; Fri, 18 Jul 2014 14:35:50 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC161A023F for ; Fri, 18 Jul 2014 14:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=677; q=dns/txt; s=iport; t=1405719350; x=1406928950; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0iMgouofSTq9iW2GfQxmQ5/NgX64j3GdCO9D0YBuJ+4=; b=X4rtvyA+Ml3hlx6WxAAQlF7isA+8JcOBHIrWI9EUw3cvtgvh2zwBbfXH S1wChwyYbu1pD3kV00N+8WeqcClJ8ewjkUdwkcEXCbzNYJxyWorKdn6m3 2zuaiEyecmnTHPpi576DdrLy5lMNTfe4hzsoXVoXpA8XzFInxsKMTUzAV Q=;
X-IronPort-AV: E=Sophos;i="5.01,687,1400025600"; d="scan'208";a="341178675"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2014 21:35:50 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILZnXI002217; Fri, 18 Jul 2014 21:35:49 GMT
Message-ID: <53C99334.2070704@cisco.com>
Date: Fri, 18 Jul 2014 17:35:48 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic issue tracker , draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
References: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org>
In-Reply-To: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/i81V5H5KrM82wzPWLz00hqZfRO4
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #15 (rfc4566bis): 4566bis: Update the format of the IANA registries to reflect the dependency between addrtype and net type.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:35:51 -0000

My preference would be to do this in 4566bis since the timeline for a 
separate draft at this point is unlikely to be any faster. Why look in 
two places when we have an upcoming bis-draft ?

-- Flemming

On 7/9/14, 8:47 AM, mmusic issue tracker wrote:
> #15: 4566bis: Update the format of the IANA registries to reflect the dependency
> between addrtype and net type.
>
>   Comments: There does not seem an agreement on this but it looks to be an
>   easy fix.
>
>   @Chairs,
>
>   Is this (and all other IANA related issues) supposed to be part of the
>   4566bis document or a separate document? A separate document may keep
>   4566bis clean and nice.
>


From nobody Fri Jul 18 14:36:42 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68A1A0277 for ; Fri, 18 Jul 2014 14:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyz4MF9VuGBM for ; Fri, 18 Jul 2014 14:36:38 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0991A023F for ; Fri, 18 Jul 2014 14:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=444; q=dns/txt; s=iport; t=1405719398; x=1406928998; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z28bKzFCio/d9vrTrNbXsxY3FxIvsLOQfXzwIAstrQw=; b=XQrfiYq8z4e6DwNUpBf3+z/Yr6mJzxsipFXNRQy7t9cHh6cl1VakhnqZ KSptoKnnx2ixeKGoUEmEMMBiKtyZwjcfmOPhMMWJe4oJSs0eaQ7j8Cd1G n7+RxYkezZQkPCdrzrFpnJ5NhHBu/20K2qm5e/aWWDvfviDl9qUaALrYK c=;
X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="62077414"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 18 Jul 2014 21:36:37 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILaacp022462; Fri, 18 Jul 2014 21:36:36 GMT
Message-ID: <53C99364.80509@cisco.com>
Date: Fri, 18 Jul 2014 17:36:36 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic issue tracker , draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
References: <057.9b3ba397834dc7dffceba720d1463edf@trac.tools.ietf.org>
In-Reply-To: <057.9b3ba397834dc7dffceba720d1463edf@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/oxAS-jXy9xoV5kan5ezLLtsB_ZM
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #19 (rfc4566bis): 4566bis: Should we add a new column called "registered network type" in the addrtype table in the IANA registry as not all address types are applicable for all network types?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:36:40 -0000

We should fix this in 4566bis.

-- Flemming

On 7/9/14, 8:53 AM, mmusic issue tracker wrote:
> #19: 4566bis: Should we add a new column called "registered network type" in the
> addrtype table in the IANA registry as not all address types are applicable
> for all network types?
>
>   Comments: This is also an IANA fix that we can do in this bis document or
>   in a separate document (with all the other IANA registry changes).
>


From nobody Fri Jul 18 14:40:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D518E1B27C2 for ; Fri, 18 Jul 2014 14:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCtQsUkt96v5 for ; Fri, 18 Jul 2014 14:40:03 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B3F1ACCF3 for ; Fri, 18 Jul 2014 14:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=334; q=dns/txt; s=iport; t=1405719605; x=1406929205; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Qqaqs0hEfgsDrFirEKEcjuzWkt7Rb4TRIT2WZNTGgUg=; b=SqbIHx2VhszRiCTuB+HyBndZwW2r/SwvFVyRG7Z93ft0gHXxo06DzLV+ F+QiFMdM4NH7cSPMAvPSXuNfMtlSdn6gA0ZPk9CE56b1XlZVf5cYAgQ6y 6N06SZIMv0IdJ6bZ/h6pEmteZIGT2R5LzXjWypDhfhAjgDzUfuZ2TniUR Y=;
X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="338063615"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jul 2014 21:40:04 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILe2bm004088; Fri, 18 Jul 2014 21:40:02 GMT
Message-ID: <53C99431.8090005@cisco.com>
Date: Fri, 18 Jul 2014 17:40:01 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic issue tracker , draft-ietf-mmusic-rfc4566bis@tools.ietf.org, abegen@cisco.com
References: <057.29493d7a93b31d297f43badc9385c7cf@trac.tools.ietf.org>
In-Reply-To: <057.29493d7a93b31d297f43badc9385c7cf@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/HJ2shJZVp7rqsdkLTU4aQ6CT90Q
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [mmusic] #17 (rfc4566bis): 4566bis: Make the registration of new network or address types mandatory (Sections 8.2.6 and 8.2.7)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:40:05 -0000

Agreed. We need to agree on the specification level though (per RFC 
5226). I'm leaning towards "Specification Required".

-- Flemming

On 7/9/14, 8:50 AM, mmusic issue tracker wrote:
> #17: 4566bis: Make the registration of new network or address types mandatory
> (Sections 8.2.6 and 8.2.7)
>
>   This should be fixed.
>


From nobody Fri Jul 18 14:45:57 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB61B2907 for ; Fri, 18 Jul 2014 14:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS-o9R1AWK8Z for ; Fri, 18 Jul 2014 14:45:48 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7187E1B27C7 for ; Fri, 18 Jul 2014 14:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1386; q=dns/txt; s=iport; t=1405719945; x=1406929545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k2l/y0sE/60TuSH3bZDXHqHiMBD2BCpVPMEBMmqpCJQ=; b=MOHxcSrHUkvKwjRUB0x56QdrmToi+X9F0ClREBK7oN1ccDeb0lJXU+/K IWH8l2O1AhrDWiFSp0FxYfyjiUaQ8Koo7SBB955d81D3ypaLChiWlUIKu gNiKZbceqhOCQ3QBk9N2gnQwSVPAmJf+LYrbR2chC403vNoOIy+uCnFLd E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFALiUyVOtJV2S/2dsb2JhbABZgmokgR8KBMxCAYEJFnaEAwEBAQMBeQULAgEIGCMLMiUCBA4FiDoIAcNAF48YMweDLoEYAQSKK5B6lC+CAoFCbIFF
X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="341180447"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2014 21:45:44 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6ILjhUC000901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 21:45:43 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 16:45:43 -0500
From: "Ali C. Begen (abegen)" 
To: "Flemming Andreasen (fandreas)" 
Thread-Topic: [MMUSIC] [mmusic] #18 (rfc4566bis): 4566bis: Should the source-level attributes defined in 5576 be included in the same table structure in the IANA registry?
Thread-Index: AQHPm3SWDAFkyFd46EGS8gEZtl2sd5umvFaAgAADz4A=
Date: Fri, 18 Jul 2014 21:45:42 +0000
Message-ID: <159B3D1E-ED5C-4A87-917D-C69899D72638@cisco.com>
References: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org> <53C99253.4020206@cisco.com>
In-Reply-To: <53C99253.4020206@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.243.115]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <02737A76199CF34B95536AB29468BE8D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hLKZqyJvbPhxgVRCZkdagSsg00s
Cc: mmusic issue tracker , "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" , mmusic , Paul Kyzivat , Jonathan Lennox 
Subject: Re: [MMUSIC] [mmusic] #18 (rfc4566bis): 4566bis: Should the source-level attributes defined in 5576 be included in the same table structure in the IANA registry?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 21:45:50 -0000

Currently the IANA registry has attributes listed as media, session or medi=
a and session level. 5576 stuff refers to "source level" attributes and I g=
uess Paul is asking to have that explicitly follow the same table structure=
 on the registry page. Right now, semantics from 5576 are not listed as "so=
urce level".

Paul can correct me I got it wrong.


On Jul 19, 2014, at 12:32 AM, Flemming Andreasen  wrote=
:

> I agree with the template part per Paul's comment. I'm less clear on what=
 is meant by the 5576 reference. Is it because of bundle and future extensi=
ons needing to consider the impact of that ?
>=20
> Thanks
>=20
> -- Flemming
>=20
> On 7/9/14, 8:52 AM, mmusic issue tracker wrote:
>> #18: 4566bis: Should the source-level attributes defined in 5576 be incl=
uded in
>> the same table structure in the IANA registry?
>>=20
>>  Comments: This seems to be an organizational issue rather than a techni=
cal
>>  issue. If we agree we need this, we can take on this as well.
>>=20
>>  Paul K.: Yes, but IMO an important one. The current registries are hard=
 to
>>  read, and easy to get wrong when adding new attributes. Also, we ought =
to
>>  have templates for what goes into the IANA consideration section when
>>  defining new attributes, and that template would be best in this docume=
nt.
>>=20
>=20


From nobody Fri Jul 18 15:05:33 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FA31A0205 for ; Fri, 18 Jul 2014 15:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC4xfVR44E0B for ; Fri, 18 Jul 2014 15:05:04 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79571A0064 for ; Fri, 18 Jul 2014 15:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1097; q=dns/txt; s=iport; t=1405721103; x=1406930703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2sbkTGgdCprvz8MxVTZx2uau4H0/rrPAF24IPchdKyI=; b=NYfLjtRCRVJDl7/b2FKI1P2zBRq1cXvGtAN5ZOWhPN5N07Q6Ywu9263X d3oO0PII7BhFA9iWRSGxs/SgnL209D78uz1pVj4tAzcjGxJVFRQ5x8qUj LvdBbyWRASzhkDhDvKuywgLtWK/RZd5qE4oFRPf2kZSwGTtUsImy2ZqIp I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAOmYyVOtJA2G/2dsb2JhbABZgmokgR8KBMxFAYEJFnaEAwEBAQMBeQULAgEIGCMLMiUCBA4FiDoIAcMuF48YMweDLoEYAQSKK5B6lC+CAoFCbIFF
X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="341183635"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2014 22:05:02 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6IM51Zo021912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 22:05:01 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 17:05:01 -0500
From: "Ali C. Begen (abegen)" 
To: "Flemming Andreasen (fandreas)" 
Thread-Topic: [MMUSIC] [mmusic] #15 (rfc4566bis): 4566bis: Update the format of the IANA registries to reflect the dependency between addrtype and net type.
Thread-Index: AQHPm3P2tcGjBouSKE+7ZDvRDyC+EpumvWQAgAAIKYA=
Date: Fri, 18 Jul 2014 22:05:01 +0000
Message-ID: <91A73A9E-71E1-4DCC-8B62-24D7D841C5A3@cisco.com>
References: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org> <53C99334.2070704@cisco.com>
In-Reply-To: <53C99334.2070704@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.243.115]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5767F6EF658CB54BA7EFF5B1C0CF9E18@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zQzy1-iIYiQDD7txNdp4nsnttcE
Cc: mmusic issue tracker , "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] [mmusic] #15 (rfc4566bis): 4566bis: Update the format of the IANA registries to reflect the dependency between addrtype and net type.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 22:05:16 -0000

On Jul 19, 2014, at 12:35 AM, Flemming Andreasen  wrote=
:

> My preference would be to do this in 4566bis since the timeline for a sep=
arate draft at this point is unlikely to be any faster.

I am not sure. Defining abnf for all 4566 attributes and agreeing on the te=
mplates might be a long process.=20

> Why look in two places when we have an upcoming bis-draft ?

The readers should not be needing to read the other draft. Its main purpose=
 is to fix the IANA issues. 4566bis just mentions that draft fixed the IANA=
 issues.

>=20
> -- Flemming
>=20
> On 7/9/14, 8:47 AM, mmusic issue tracker wrote:
>> #15: 4566bis: Update the format of the IANA registries to reflect the de=
pendency
>> between addrtype and net type.
>>=20
>>  Comments: There does not seem an agreement on this but it looks to be a=
n
>>  easy fix.
>>=20
>>  @Chairs,
>>=20
>>  Is this (and all other IANA related issues) supposed to be part of the
>>  4566bis document or a separate document? A separate document may keep
>>  4566bis clean and nice.
>>=20
>=20


From nobody Fri Jul 18 15:17:30 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06CA1A0242 for ; Fri, 18 Jul 2014 15:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVvjTRGeS-Yl for ; Fri, 18 Jul 2014 15:17: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 9BE481A02D7 for ; Fri, 18 Jul 2014 15:17:19 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id TyC31o0031HzFnQ5EyHK4n; Fri, 18 Jul 2014 22:17:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id TyHJ1o00L3ZTu2S3ayHJS3; Fri, 18 Jul 2014 22:17:19 +0000
Message-ID: <53C99CEE.3090506@alum.mit.edu>
Date: Fri, 18 Jul 2014 18:17:18 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" ,  "Flemming Andreasen (fandreas)" 
References: <057.ff7aa703d4d9bc4c610db6667c10051a@trac.tools.ietf.org> <53C99253.4020206@cisco.com> <159B3D1E-ED5C-4A87-917D-C69899D72638@cisco.com>
In-Reply-To: <159B3D1E-ED5C-4A87-917D-C69899D72638@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405721839; bh=WXGfWRukGToZvC9Q/mrNmwGN1btCcQJfnLKKH10SwPg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J2O9eCPphH+vftdt1r3fFbWtPdkZmnh6Fim3M2m/5nhq5NVx/4GE99GTOusfBWE0O yLO4ifBvclbBBAOJKA2n9HjkGne3B/wVuKzeN0ncjEXZ76ErXHjTNsy4a9UOy1pTBL gqFXs//RPPJFm31BQkvO2WOarpFDTLVfDYeBoybj6IXnqywBlGerZnCe2MG8BwPfgN PDriO3qIKMHnHjOtLLu658ix1RtBEIgyGwwshW7dIyKdNT+CY6kE1UmBZJPWp4eF1M DEDgEv6Rpjd5CZyXIa6e9I3fsk1eFL/vSNREIS3jvZppqsbsGrW1zKwK8eYvtGKNOu A+olvblhOdsOw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Zy0MV5db8ug9cFIWU3PvlWaC7DE
Cc: mmusic issue tracker , "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" , mmusic , Jonathan Lennox 
Subject: Re: [MMUSIC] [mmusic] #18 (rfc4566bis): 4566bis: Should the source-level attributes defined in 5576 be included in the same table structure in the IANA registry?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 22:17:27 -0000

I think a single table containing all the attributes.
Three columns (check boxes) indicating if the attribute is valid at 
session, media, and/or source level.

(Or a single column that with some notation that can describe any 
combination.)

	Thanks,
	Paul

On 7/18/14 5:45 PM, Ali C. Begen (abegen) wrote:
> Currently the IANA registry has attributes listed as media, session or media and session level. 5576 stuff refers to "source level" attributes and I guess Paul is asking to have that explicitly follow the same table structure on the registry page. Right now, semantics from 5576 are not listed as "source level".
>
> Paul can correct me I got it wrong.
>
>
> On Jul 19, 2014, at 12:32 AM, Flemming Andreasen  wrote:
>
>> I agree with the template part per Paul's comment. I'm less clear on what is meant by the 5576 reference. Is it because of bundle and future extensions needing to consider the impact of that ?
>>
>> Thanks
>>
>> -- Flemming
>>
>> On 7/9/14, 8:52 AM, mmusic issue tracker wrote:
>>> #18: 4566bis: Should the source-level attributes defined in 5576 be included in
>>> the same table structure in the IANA registry?
>>>
>>>   Comments: This seems to be an organizational issue rather than a technical
>>>   issue. If we agree we need this, we can take on this as well.
>>>
>>>   Paul K.: Yes, but IMO an important one. The current registries are hard to
>>>   read, and easy to get wrong when adding new attributes. Also, we ought to
>>>   have templates for what goes into the IANA consideration section when
>>>   defining new attributes, and that template would be best in this document.
>>>
>>
>
>


From nobody Fri Jul 18 15:21:09 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3361A02E6 for ; Fri, 18 Jul 2014 15:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcEi2buHJ-Ui for ; Fri, 18 Jul 2014 15:21:07 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E61FF1A02DE for ; Fri, 18 Jul 2014 15:21:06 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id TyKV1o0041YDfWL51yM6Zm; Fri, 18 Jul 2014 22:21:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id TyM61o00E3ZTu2S3gyM6Hj; Fri, 18 Jul 2014 22:21:06 +0000
Message-ID: <53C99DD2.90503@alum.mit.edu>
Date: Fri, 18 Jul 2014 18:21:06 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <057.54c2e3276817f5dd682a23ac32547bc4@trac.tools.ietf.org> <53C99334.2070704@cisco.com> <91A73A9E-71E1-4DCC-8B62-24D7D841C5A3@cisco.com>
In-Reply-To: <91A73A9E-71E1-4DCC-8B62-24D7D841C5A3@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405722066; bh=hoVX3YOGLQsad9DzXFLIi2MSZes8ZYvBvaL99ABn4wg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HKHpXtlCa1u26sESfk8+wfYMeC1rowD2J5fifXMNIdCU0dYIBwxTNjPjXyfH9jd2C R+xuRTuSbMu9pLf6WzQldiuYxvgw6Iy6cXPg48sgFgs/iPxVWe8Gg80i7b2NhiWhuk DqUdJEc4uExWzTwQcFHaV0DOKKwriI5Iz0t9aeIRWXRLYj0+ilDcJedJI0qDLJ7Df1 6E6y/1KosF0wb2GpVyZfqVAhtCXN/S7jb02aYGxz2Tma4WwerMBmmfXNSJU/1tA0QC iche5iOs6CvwzRmiIJcvRfGjI34g+IJFFcLyYc62ubFXUn9Xon+YlCILBL52RTzpTX VjoqZ2EFit1YA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UkK8hKg2gzMhrXT9UlEdoeG42UQ
Subject: Re: [MMUSIC] [mmusic] #15 (rfc4566bis): 4566bis: Update the format of the IANA registries to reflect the dependency between addrtype and net type.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 22:21:08 -0000

One reason for a doing it all in 4566bis is that it then sets an example 
for future definitions.

Also, if we plan to put it in a different draft, then what do we put in 
4566bis? If we leave it as-is then there will be two different 
definitions of those attributes.

	Thanks
	Paul

On 7/18/14 6:05 PM, Ali C. Begen (abegen) wrote:
>
> On Jul 19, 2014, at 12:35 AM, Flemming Andreasen  wrote:
>
>> My preference would be to do this in 4566bis since the timeline for a separate draft at this point is unlikely to be any faster.
>
> I am not sure. Defining abnf for all 4566 attributes and agreeing on the templates might be a long process.
>
>> Why look in two places when we have an upcoming bis-draft ?
>
> The readers should not be needing to read the other draft. Its main purpose is to fix the IANA issues. 4566bis just mentions that draft fixed the IANA issues.
>
>>
>> -- Flemming
>>
>> On 7/9/14, 8:47 AM, mmusic issue tracker wrote:
>>> #15: 4566bis: Update the format of the IANA registries to reflect the dependency
>>> between addrtype and net type.
>>>
>>>   Comments: There does not seem an agreement on this but it looks to be an
>>>   easy fix.
>>>
>>>   @Chairs,
>>>
>>>   Is this (and all other IANA related issues) supposed to be part of the
>>>   4566bis document or a separate document? A separate document may keep
>>>   4566bis clean and nice.
>>>
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Sat Jul 19 04:22:55 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83A31A0A9D for ; Sat, 19 Jul 2014 04:22:52 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq1bFqZhg4m0 for ; Sat, 19 Jul 2014 04:22:51 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8686C1A02CB for ; Sat, 19 Jul 2014 04:22:50 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id mc6so3539905lab.6 for ; Sat, 19 Jul 2014 04:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=o3lLGLCLJAJ0iaO5JpfnTH4MtdkUh8bLfoLf3JGTUKI=; b=lOt0RWevXimAYWcvTO35mtHC7zMf2pbmHe+PQidgCL3iogxJPfUk2Iman9zWaAAx3j QA0KGR6M4aiPUWbsIq8nqonPoZ0YfFiiduTprd8mV1HlF+aFqyRoGJJl2ihuWd61lu8d AlkOQ856A9c7fIpn7cB5HqSZpFz9Uq5auogVfc92ys3lAsa85XTTKlN1MGAQrwM6+ZKy KoExahItJtYv+6sT5gdetQHExiTqh0d0NOmFN2ZwnNO9ZJAQgW5RkURkAjep19cWkg0Z zn/jbByQPoPTs1yKfA1+613nD6VquAvQRRUTxAuyzzMorhdh6DihESiqf5hztUfAtAtF e5HQ==
MIME-Version: 1.0
X-Received: by 10.112.118.42 with SMTP id kj10mr10946165lbb.86.1405768968810;  Sat, 19 Jul 2014 04:22:48 -0700 (PDT)
Received: by 10.114.166.38 with HTTP; Sat, 19 Jul 2014 04:22:48 -0700 (PDT)
In-Reply-To: 
References: <53BBFCBC.7020707@cisco.com> <002701cfa21b$597f10b0$0c7d3210$@co.in> 
Date: Sat, 19 Jul 2014 13:22:48 +0200
Message-ID: 
From: Xavier Marjou 
To: mmusic 
Content-Type: multipart/alternative; boundary=047d7bfcf68c05b71904fe8a181b
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/08YG0c8AyAnQUwofFWmGyp8rhRk
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jul 2014 11:22:52 -0000

--047d7bfcf68c05b71904fe8a181b
Content-Type: text/plain; charset=UTF-8

+1


On Fri, Jul 18, 2014 at 3:42 AM, Bernard Aboba 
wrote:

> I also support adoption.
>
> ------------------------------
> From: partha@parthasarathi.co.in
> To: fandreas@cisco.com; mmusic@ietf.org
> Date: Fri, 18 Jul 2014 05:30:48 +0530
> CC: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org;
> mmusic-chairs@tools.ietf.org
> Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as
> WG document
>
>
>  Hi all,
>
>
>
> I support the adoption of this draft.
>
>
>
> Thanks
>
> Partha
>
>
>
> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Flemming
> Andreasen
> *Sent:* Tuesday, July 08, 2014 7:44 PM
> *To:* mmusic
> *Cc:* draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org;
> mmusic-chairs@tools.ietf.org
> *Subject:* [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as
> WG document
>
>
>
> Greetings,
>
> We have an MMUSIC milestone for "SIP usage for Trickle ICE", and at the
> IETF 89 meeting we had a call for adoption of the Trickle ICE SIP draft as
> a WG document. There was a strong consensus in favor of adopting the
> document. After the meeting there were a few comments on the document,
> which were discussed on the MMUSIC mailing list and resulted in an updated
> version of the document:
>
> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02
>
> At this point, the chairs would like to confirm adopting the updated draft
> as a WG document. If you have any concerns regarding the adoption, please
> let us know no later than Friday, July 18th, 2014.
>
> Thanks,
>
>     Ari & Flemming (MMUSIC chairs)
>
> _______________________________________________ mmusic mailing list
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--047d7bfcf68c05b71904fe8a181b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1


On Fri, Jul 18, 2014 at 3:42 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:






I also support adoption.=C2=A0

From: =
partha@part=
hasarathi.co.in
To: fandreas@cisco.com; mmusic@ietf.org

Date: Fri, 18 Jul 2014 05:30:48 +0530
CC: draft-ivov-mmusic-t=
rickle-ice-sip@tools.ietf.org; mmusic-chairs@tools.ietf.org

Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as W=
G	document

















Hi all,



=C2=A0



I support the adoption of this draft.<=
/p>


=C2=A0



Thanks



Partha



=C2=A0












From: mmusic
[mailto:mmusic=
-bounces@ietf.org] On Behalf Of Flemming Andreasen

Sent: Tuesday, July 08, 2014 7:44 PM

To: mmusic

Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org;
mmusic-ch=
airs@tools.ietf.org

Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 a=
s WG
document









=C2=A0



Greetings,



We have an MMUSIC milestone for "SIP usage for Trickle ICE", and =
at
the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP draft=
 as
a WG document. There was a strong consensus in favor of adopting the docume=
nt.
After the meeting there were a few comments on the document, which were
discussed on the MMUSIC mailing list and resulted in an updated version of =
the
document: 



http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice=
-sip-02




At this point, the chairs would like to confirm adopting the updated draft =
as a
WG document. If you have any concerns regarding the adoption, please let us
know no later than Friday, July 18th, 2014. 



Thanks, 



=C2=A0=C2=A0=C2=A0 Ari & Flemming (MMUSIC chairs) 












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


_______________________________________________

mmusic mailing list

mmusic@ietf.org

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





--047d7bfcf68c05b71904fe8a181b--


From nobody Sat Jul 19 17:31:50 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820621B285C; Sat, 19 Jul 2014 08:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.103
X-Spam-Level: 
X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5g9eu467lNo; Sat, 19 Jul 2014 08:46:17 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970E51B2858; Sat, 19 Jul 2014 08:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1405784777; x=1437320777; h=message-id:date:to:from:subject:cc:mime-version; bh=sFWKBHmVaK1/gTlW5SpcOI2BxuhjJvJisUOVFv5lolI=; b=U1MLqqap32fbiqDt83fKVDZUpuQ6kz0pZPgCjRZ4uOMwnj7Ytct9auUj AtlYnoEzDtxaNOs/7oLlImzUVHYTwZDhMT/eudUvJ17irA6HLbaR1gOgP r2PQPgXm4e5J4RsXo82cHRIQ+My0dmMjwsIoyHld5a5HGm9KpjxgBeDF3 o=;
X-IronPort-AV: E=McAfee;i="5600,1067,7503"; a="70839378"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 19 Jul 2014 08:46:17 -0700
X-IronPort-AV: E=Sophos;i="5.01,692,1400050800"; d="scan'208";a="715817531"
Received: from nasanexhc02.na.qualcomm.com ([10.46.56.110]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Jul 2014 08:46:16 -0700
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC02.na.qualcomm.com (10.46.56.110) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 19 Jul 2014 08:46:16 -0700
Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 19 Jul 2014 08:46:15 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Sat, 19 Jul 2014 08:44:47 -0700
To: Flemming Andreasen , Gunnar Hellstrom , Brian Rosen , "Peter Saint-Andre" , Keith Drage , Peter Saint-Andre , Brian Rosen , Ari Keranen , Pete Resnick , "Alexey Melnikov" , Eric Burger , Eric Burger , "Hutton, Andrew" , Harald Alvestrand , Henning Schulzrinne , "Nathaniel Borenstein" , , Nik Tomkinson , 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/A4hu8SiszUjZObz_KVXp56Wz_dM
X-Mailman-Approved-At: Sat, 19 Jul 2014 17:31:49 -0700
Cc: dispatch@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: [MMUSIC] Updated: Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jul 2014 15:46:19 -0000

[[ The Doodle poll to find a time to meet in Toronto has been updated 
with two new time slots. ]]

Hi to everyone who participated in previous discussions about the 
human language negotiation draft.

I'd like to make progress on this draft.  I think meeting in Toronto 
can help that.  Please participate.

I created a Doodle poll to see if we can find a time in Toronto to 
meet face to face.

Doodle poll for time at Toronto to discuss open issues and moving 
forward with Human Language Negotiation: 
http://doodle.com/pm3mph6xa3m9kupp

Link to current version (-02) of draft: 
http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A logician saves the life of a space alien and is rewarded with
an offer to answer any question.  After a thought he asks: What
is the best question to ask and the correct answer to it?  After
a brief panic the alien consults her computer and says: The best
question to ask is the one you just did and the correct answer
to it is the one I gave.


From nobody Sat Jul 19 19:41:31 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904C81B2B5D for ; Sat, 19 Jul 2014 19:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VgKywbrsMie for ; Sat, 19 Jul 2014 19:41:25 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CD21B2B5A for ; Sat, 19 Jul 2014 19:41:24 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-9a-53cb2c5200e6
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.34.19155.25C2BC35; Sun, 20 Jul 2014 04:41:22 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.174.1; Sun, 20 Jul 2014 04:41: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 25ABF110297; Sun, 20 Jul 2014 05:41:22 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9E0CA58958;	Sun, 20 Jul 2014 05:41:28 +0300 (EEST)
Received: from dhcp-8b9d.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CE890587E3;	Sun, 20 Jul 2014 05:41:27 +0300 (EEST)
Message-ID: <53CB2C50.90603@ericsson.com>
Date: Sat, 19 Jul 2014 22:41:20 -0400
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Pal Martinsen (palmarti)" 
References: <20140630184553.31625.21293.idtracker@ietfa.amsl.com> <803DB627-3D5F-494D-9D25-E1000200A7A1@cisco.com> <53C5539E.2070607@ericsson.com> <2DF3EF3C-B089-4DA9-97CD-83051E90E15C@cisco.com>
In-Reply-To: <2DF3EF3C-B089-4DA9-97CD-83051E90E15C@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW6Qzulgg65pWhYfXvewWkxd/pjF 4v31lSwOzB5Tfm9k9Viy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mu6fzCl4xl9xefMt5gbG UzxdjJwcEgImEudOrGOBsMUkLtxbz9bFyMUhJHCUUWLxhwOMEM4GRolpe66zQzh7GSWm9pyG ctYxShx49pQRzmn78IUNZBivgKbE4x9HWLsYOThYBFQlGqYngoTZBOwlbk4AmcTJISqQLLFm 6yR2iHJBiZMzn4DdISJgLNF85CjYAmaBWYwSz+5PB0sIC9hJnG/8xwyx7DCjRMuVXYwgCzgF bCWObXEAqWEGMi/Muc4CYctLNG+dzQzxnJrE1XObwGwhoHuu/nvFOIFRdBaS3bOQtM9C0r6A kXkVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmCkHNzyW3UH4+U3jocYBTgYlXh4E16dChZi TSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxBNx6Z84Tzr/UK vvCw/7z18dIJi+7O3rTg/WpRGUU2lxPXl/+d9uaf3PT/e5OefZCzTL2x5MDfdUfrI7fIaO2a EfjRsn3nvtTNex4HqtgxTJIyK4rdf+T9Z7XbJ9b59PInHDOSrT2bsiro3qFdB4v/R5SmrPm4 1ShuckHA/2D1qxpfhf/U3Zu+VImlOCPRUIu5qDgRANTWkOV1AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IZMj-YY8m1IbMWu8oMau8YgycAw
Cc: "draft-reddy-mmusic-ice-happy-eyeballs@tools.ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] draft-reddy-mmusic-ice-happy-eyeballs-07
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 02:41:28 -0000

On 7/17/14 11:28 PM, Pal Martinsen (palmarti) wrote:
>
> On 15 Jul 2014, at 18:15, Ari Kernen  wrote:
>
>> Hi,
>>
>> I read the latest draft and, without a chair hat on, I think this is
>> useful work and would make sense to specify in an RFC.
>>
>> Regarding where to do the work, I think the best way forward would be to
>> have this as a separate draft and ICE bis to have this as a reference on
>> how to do candidate prioritization in a dual-stack environment.
>>
>  From a development perspective I agree. For a already implemented ICE stack it is easier to deal with a new RFC than catching the changes in a ICEbis version. For new implementations I would focus on getting ICE to work and then add improvements like this draft provides later.

Makes sense.

>> Additionally, it would be good for someone designing a different
>> algorithm for the candidate prioritization to have some more guidelines
>> on how to play around with the values. As you can remember from the past
>> versions, it's not always easy to get it right.
>>
>
> Yes, the draft currently says its ok to play with the local_preference value because the pair_priority value would be correct due to the formula used when forming the candidate pair.

Yes, this is at least one thing to take into account. Also it may make 
sense to stress more the fact that the algorithm must be such that both 
endpoints end up with same (or very similar) checklists, in case someone 
comes up with something smart that doesn't use just the local_preference.

But since you will get the real benefits only if both endpoints use the 
same/similar algorithm, is there some signaling needed to choose the 
right one if one implements more than one?

> There have been some suggestions that getting some metrics collected so we can actually measure the effect on any proposed algorithm.
> I am going to prepare a slide discussing this for the Toronto meeting.

This sounds good too.


Cheers,
Ari


From nobody Sun Jul 20 06:24:23 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FED1B2C20; Sun, 20 Jul 2014 06:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saMGZmZ7E64M; Sun, 20 Jul 2014 06:24:18 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986001B2803; Sun, 20 Jul 2014 06:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1405862658; x=1437398658; h=message-id:date:to:from:subject:mime-version; bh=cel7aZzwpD3akFxVJ/xpMuudU85teAZPmKo6znrOhUY=; b=mj/3w1g7NosfSrpYfmI47s6eYK2AqL5yEFfp4r9v1E0wTM0mO492yqLg hyNj7HCB4CVewqV9rftBrnlB2YB/oyJGrLFHMpf2GeTCYDeebpP4V83xk Yd/b5J39GK0jCht6cJkD2o9gZFG/xc4N2e48VjzuuYeikXD9qJGYiPuEY s=;
X-IronPort-AV: E=McAfee;i="5600,1067,7504"; a="70872542"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 20 Jul 2014 06:24:18 -0700
X-IronPort-AV: E=Sophos;i="5.01,695,1400050800"; d="scan'208";a="679124950"
Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jul 2014 06:24:18 -0700
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 20 Jul 2014 06:24:17 -0700
Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 20 Jul 2014 06:24:17 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Sun, 20 Jul 2014 06:24:12 -0700
To: , , 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CgDyzRHVsMe3Tx0mmi6EDILZdjc
Subject: [MMUSIC] Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 13:24:20 -0000

It looks like Thursday at 4:40 is the most popular time.  I'll leave 
the poll up at least until this evening to give more people a chance 
to weigh in on a preferred time, but as it stands now it looks like 
Thursday at 4:40 PM.

>  Hi to everyone who participated in previous discussions about the 
> human language negotiation draft.
>
>  I'd like to make progress on this draft.  I think meeting in 
> Toronto can help that.  Please participate.
>
>  I created a Doodle poll to see if we can find a time in Toronto to 
> meet face to face.
>
>  Doodle poll for time at Toronto to discuss open issues and moving 
> forward with Human Language Negotiation: 
> http://doodle.com/pm3mph6xa3m9kupp
>
>  Link to current version of draft: 
> http://tools.ietf.org/html/draft-gellens-negotiating-human-language


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The price of apathy towards public affairs is to be ruled by evil men.
                    --Plato


From nobody Sun Jul 20 07:40:51 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C41B1B2B6D for ; Sat, 19 Jul 2014 22:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhD6uECYH7gE for ; Sat, 19 Jul 2014 22:17:49 -0700 (PDT)
Received: from vsp-authed-04-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D190F1B2B6B for ; Sat, 19 Jul 2014 22:17:48 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-04-02.binero.net (Halon Mail Gateway) with ESMTPS; Sun, 20 Jul 2014 07:17:35 +0200 (CEST)
Received: from [192.168.43.175] (2.67.117.195.mobile.tre.se [2.67.117.195]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id F0BD53A177; Sun, 20 Jul 2014 07:17:29 +0200 (CEST)
Message-ID: <53CB50F1.4070404@omnitor.se>
Date: Sun, 20 Jul 2014 07:17:37 +0200
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Randall Gellens ,  Flemming Andreasen , Brian Rosen , Peter Saint-Andre ,  Keith Drage , Peter Saint-Andre ,  Brian Rosen , Ari Keranen ,  Pete Resnick , Alexey Melnikov ,  Eric Burger , Eric Burger ,  "Hutton, Andrew" , Harald Alvestrand ,  Henning Schulzrinne , Nathaniel Borenstein , john-ietf@jck.com,  Nik Tomkinson , hannes.tschofenig@gmx.net
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020708090503000504010109"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IfCFa0SOr8f4E4XPV376G7M1KRY
X-Mailman-Approved-At: Sun, 20 Jul 2014 07:40:50 -0700
Cc: dispatch@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: Re: [MMUSIC] Updated: Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 05:17:51 -0000

This is a multi-part message in MIME format.
--------------020708090503000504010109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Yes, good idea to retry on this topic.
I cannot be there, but I hope there will be progress.

Te link did not work. Try this:
http://tools.ietf.org/id/draft-gellens-negotiating-human-language-02.txt

I see you set the topic for the meeting to mainly discuss where to place 
the language declarations, in SIP or SDP. How about other alternatives, 
more related to user profiles?
E.g. provide in SIP or other session establishment procedure a URI to a 
user profile record with the language preference and capability 
information.
For SIP, it can be made similar to how location by reference is provided 
according to RFC 6442. One benefit is that it can easily be carried over 
to other environments ( like WebRTC ).

Gunnar
------------------------------------------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2014-07-19 17:44, Randall Gellens wrote:
> [[ The Doodle poll to find a time to meet in Toronto has been updated 
> with two new time slots. ]]
>
> Hi to everyone who participated in previous discussions about the 
> human language negotiation draft.
>
> I'd like to make progress on this draft.  I think meeting in Toronto 
> can help that.  Please participate.
>
> I created a Doodle poll to see if we can find a time in Toronto to 
> meet face to face.
>
> Doodle poll for time at Toronto to discuss open issues and moving 
> forward with Human Language Negotiation: 
> http://doodle.com/pm3mph6xa3m9kupp
>
> Link to current version (-02) of draft: 
> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt
>
>


--------------020708090503000504010109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Yes, good idea to retry on this topic.

      I cannot be there, but I hope there will be progress.

      

      Te link did not work. Try this:

http://tools.ietf.org/id/draft-gellens-negotiating-human-language-02.txt

      

      I see you set the topic for the meeting to mainly discuss where to
      place the language declarations, in SIP or SDP. How about other
      alternatives, more related to user profiles?

      E.g. provide in SIP or other session establishment procedure a URI
      to a user profile record with the language preference and
      capability information. 

      For SIP, it can be made similar to how location by reference is
      provided according to RFC 6442. One benefit is that it can easily
      be carried over to other environments ( like WebRTC ).

      

      Gunnar

      

        

        Gunnar Hellström

        Omnitor

        gunnar.hellstrom@omnitor.se

        +46708204288

      

      On 2014-07-19 17:44, Randall Gellens wrote:

    

    
[[ The Doodle poll to find a time to meet in Toronto
      has been updated with two new time slots. ]]
      

      

      Hi to everyone who participated in previous discussions about the
      human language negotiation draft.
      

      

      I'd like to make progress on this draft.  I think meeting in
      Toronto can help that.  Please participate.
      

      

      I created a Doodle poll to see if we can find a time in Toronto to
      meet face to face.
      

      

      Doodle poll for time at Toronto to discuss open issues and moving
      forward with Human Language Negotiation:
      http://doodle.com/pm3mph6xa3m9kupp
      

      

      Link to current version (-02) of draft:
http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

      

      

    

    

  


--------------020708090503000504010109--


From nobody Sun Jul 20 07:40:52 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4521B2C1C; Sun, 20 Jul 2014 06:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtE0dOymruZG; Sun, 20 Jul 2014 06:11:28 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5C61B2C11; Sun, 20 Jul 2014 06:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1405861888; x=1437397888; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=ECR6pZEn5t3c1dC79e+6Jvjos3i9ZFfVQmtD8IZUR3I=; b=WFkW+GbraqopsKV7GVJQhZl7WCdW1Nl96KlH0KRbmJqSx+PM0uDs7jVK liV8XCxRMJCzk11xuS2Inr+tZVmlhdrGQjw1x74JmuKseElOZqNRamCkQ iYjPDG+eg8A2DwFIXU9xkCcmEc4Frath7aJ8ikZUX/9GCTmbk3rgS2sLu E=;
X-IronPort-AV: E=McAfee;i="5600,1067,7504"; a="71465681"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 20 Jul 2014 06:11:27 -0700
X-IronPort-AV: E=Sophos;i="5.01,695,1400050800"; d="scan'208";a="679121429"
Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jul 2014 06:11:26 -0700
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 20 Jul 2014 06:11:26 -0700
Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 20 Jul 2014 06:11:25 -0700
Message-ID: 
In-Reply-To: <53CB50F1.4070404@omnitor.se>
References:  <53CB50F1.4070404@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Sun, 20 Jul 2014 05:56:58 -0700
To: Gunnar Hellstrom , Randall Gellens , Flemming Andreasen , "Brian Rosen" , Peter Saint-Andre , "Keith Drage" , "Peter  Saint-Andre" , Brian Rosen , Ari Keranen , Pete Resnick , "Alexey Melnikov" , Eric Burger , Eric Burger , "Hutton, Andrew" , Harald Alvestrand , Henning Schulzrinne , "Nathaniel Borenstein" , , Nik Tomkinson , 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8dWUPGsg47nijffK7ed_o5YTAKU
X-Mailman-Approved-At: Sun, 20 Jul 2014 07:40:50 -0700
Cc: dispatch@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: Re: [MMUSIC] Updated: Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 13:11:38 -0000

At 7:17 AM +0200 7/20/14, Gunnar Hellstrom wrote:

>  I see you set the topic for the meeting to mainly discuss where to 
> place the language declarations, in SIP or SDP. How about other 
> alternatives, more related to user profiles?
>  E.g. provide in SIP or other session establishment procedure a URI 
> to a user profile record with the language preference and 
> capability information.
>  For SIP, it can be made similar to how location by reference is 
> provided according to RFC 6442. One benefit is that it can easily 
> be carried over to other environments ( like WebRTC ).

For real-time communications, I think it better to not rely on either 
party needing to fetch resources from external servers, as that 
introduces additional delay and failure cases.  Especially since one 
of the driving use cases is emergency calls, we don't want to add 
fragility.


>
>
>  On 2014-07-19 17:44, Randall Gellens wrote:
>
>>  [[ The Doodle poll to find a time to meet in Toronto has been 
>> updated with two new time slots. ]]
>>
>>  Hi to everyone who participated in previous discussions about the 
>> human language negotiation draft.
>>
>>  I'd like to make progress on this draft.  I think meeting in 
>> Toronto can help that.  Please participate.
>>
>>  I created a Doodle poll to see if we can find a time in Toronto to 
>> meet face to face.
>>
>>  Doodle poll for time at Toronto to discuss open issues and moving 
>> forward with Human Language Negotiation: 
>> http://doodle.com/pm3mph6xa3m9kupp
>>
>>  Link to current version (-02) of draft: 
>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Citizens for corrupt government, unclean water, higher taxes,
unsafe streets, and poor schools.


From nobody Sun Jul 20 13:30:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2B81A0B05 for ; Sun, 20 Jul 2014 12:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJst2orciFrI for ; Sun, 20 Jul 2014 12:47:47 -0700 (PDT)
Received: from vsp-authed-04-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43651A0AF0 for ; Sun, 20 Jul 2014 12:47:46 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-04-02.binero.net (Halon Mail Gateway) with ESMTPS; Sun, 20 Jul 2014 21:47:30 +0200 (CEST)
Received: from [192.168.43.175] (2.65.30.55.mobile.tre.se [2.65.30.55]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id CCEDB3A21A; Sun, 20 Jul 2014 21:47:26 +0200 (CEST)
Message-ID: <53CC1CD5.2060008@omnitor.se>
Date: Sun, 20 Jul 2014 21:47:33 +0200
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Randall Gellens ,  Flemming Andreasen , Brian Rosen , Peter Saint-Andre ,  Keith Drage , Peter Saint-Andre ,  Brian Rosen , Ari Keranen ,  Pete Resnick , Alexey Melnikov ,  Eric Burger , Eric Burger ,  "Hutton, Andrew" , Harald Alvestrand ,  Henning Schulzrinne , Nathaniel Borenstein , john-ietf@jck.com,  Nik Tomkinson , hannes.tschofenig@gmx.net
References:  <53CB50F1.4070404@omnitor.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050207020401090109050801"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5jlo7_Wbd6TMv50etkW6Ztt4sPo
X-Mailman-Approved-At: Sun, 20 Jul 2014 13:30:41 -0700
Cc: dispatch@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: Re: [MMUSIC] Updated: Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 19:47:53 -0000

This is a multi-part message in MIME format.
--------------050207020401090109050801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

We need to collect the requirements before we decide on the mechanism.

I think we discussed them earlier, but they are not captured fully in 
the draft.

Here are some basic requirements:

Purpose: The declaration and negotiation of capabilities and preferences 
for modalities and languages shall make it possible to optimize call 
handling by routing calls to call handlers with most suitable 
capabilities or by including assisting services in the call to cover 
gaps in modality and language handling capability between the caller and 
the callee.

The modalities shall at least be: real-time text , message-wise text, 
speech, voice, sign language and speech-reading.

The capability and preference declaration shall enable declaration of 
more than one modality, and the relative preference between the modalities.

The capability and preference declaration shall enable declaration of 
more than one language per modality, and the relative preference between 
the languages within the modalities.

The capability and preference declaration shall enable declaration of 
different capabilities and preferences for production versus reception 
of language expression.

It shall be possible for servers along the route to take the decision on 
routing.

It shall be possible to indicate that an assisting service is included 
in a call, so that double invocation of assisting services is avoided.


This is a start. It can be further expanded.

Gunnar

------------------------------------------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2014-07-20 14:56, Randall Gellens wrote:
> At 7:17 AM +0200 7/20/14, Gunnar Hellstrom wrote:
>
>>  I see you set the topic for the meeting to mainly discuss where to 
>> place the language declarations, in SIP or SDP. How about other 
>> alternatives, more related to user profiles?
>>  E.g. provide in SIP or other session establishment procedure a URI 
>> to a user profile record with the language preference and capability 
>> information.
>>  For SIP, it can be made similar to how location by reference is 
>> provided according to RFC 6442. One benefit is that it can easily be 
>> carried over to other environments ( like WebRTC ).
>
> For real-time communications, I think it better to not rely on either 
> party needing to fetch resources from external servers, as that 
> introduces additional delay and failure cases.  Especially since one 
> of the driving use cases is emergency calls, we don't want to add 
> fragility.
>
>
>>
>>
>>  On 2014-07-19 17:44, Randall Gellens wrote:
>>
>>>  [[ The Doodle poll to find a time to meet in Toronto has been 
>>> updated with two new time slots. ]]
>>>
>>>  Hi to everyone who participated in previous discussions about the 
>>> human language negotiation draft.
>>>
>>>  I'd like to make progress on this draft.  I think meeting in 
>>> Toronto can help that.  Please participate.
>>>
>>>  I created a Doodle poll to see if we can find a time in Toronto to 
>>> meet face to face.
>>>
>>>  Doodle poll for time at Toronto to discuss open issues and moving 
>>> forward with Human Language Negotiation: 
>>> http://doodle.com/pm3mph6xa3m9kupp
>>>
>>>  Link to current version (-02) of draft: 
>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt
>
>


--------------050207020401090109050801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
We need to collect the requirements
      before we decide on the mechanism. 

      

      I think we discussed them earlier, but they are not captured fully
      in the draft.

      

      Here are some basic requirements:

      

      Purpose: The declaration and negotiation of capabilities and
      preferences for modalities and languages shall make it possible to
      optimize call handling by routing calls to call handlers with most
      suitable capabilities or by including assisting services in the
      call to cover gaps in modality and language handling capability
      between the caller and the callee.

      

      The modalities shall at least be: real-time text , message-wise
      text, speech, voice, sign language and speech-reading.

      

      The capability and preference declaration shall enable declaration
      of more than one modality, and the relative preference between the
      modalities.

      

      The capability and preference declaration shall enable declaration
      of more than one language per modality, and the relative
      preference between the languages within the modalities.

      

      The capability and preference declaration shall enable declaration
      of different capabilities and preferences for production versus
      reception of language expression.

      

      It shall be possible for servers along the route to take the
      decision on routing.

      

      It shall be possible to indicate that an assisting service is
      included in a call, so that double invocation of assisting
      services is avoided.

      

      

      This is a start. It can be further expanded.

      

      Gunnar

      

      

        

        Gunnar Hellström

        Omnitor

        gunnar.hellstrom@omnitor.se

        +46708204288

      

      On 2014-07-20 14:56, Randall Gellens wrote:

    

    
At 7:17 AM +0200 7/20/14, Gunnar Hellstrom wrote:
      

      

      
 I see you set the topic for the meeting
        to mainly discuss where to place the language declarations, in
        SIP or SDP. How about other alternatives, more related to user
        profiles?
        

         E.g. provide in SIP or other session establishment procedure a
        URI to a user profile record with the language preference and
        capability information.
        

         For SIP, it can be made similar to how location by reference is
        provided according to RFC 6442. One benefit is that it can
        easily be carried over to other environments ( like WebRTC ).
        

      

      

      For real-time communications, I think it better to not rely on
      either party needing to fetch resources from external servers, as
      that introduces additional delay and failure cases.  Especially
      since one of the driving use cases is emergency calls, we don't
      want to add fragility.
      

      

      

      

        

        

         On 2014-07-19 17:44, Randall Gellens wrote:
        

        

        
 [[ The Doodle poll to find a time to
          meet in Toronto has been updated with two new time slots. ]]
          

          

           Hi to everyone who participated in previous discussions about
          the human language negotiation draft.
          

          

           I'd like to make progress on this draft.  I think meeting in
          Toronto can help that.  Please participate.
          

          

           I created a Doodle poll to see if we can find a time in
          Toronto to meet face to face.
          

          

           Doodle poll for time at Toronto to discuss open issues and
          moving forward with Human Language Negotiation:
<http://doodle.com/pm3mph6xa3m9kupp>http://doodle.com/pm3mph6xa3m9kupp

          

           Link to current version (-02) of draft:
<http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt>http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

        

      

      

      

    

    

  


--------------050207020401090109050801--


From nobody Mon Jul 21 06:36:03 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DCC1B2E09 for ; Mon, 21 Jul 2014 06:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tdiC07BufXw for ; Mon, 21 Jul 2014 06:35:54 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B0A1B2DE9 for ; Mon, 21 Jul 2014 06:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8636; q=dns/txt; s=iport; t=1405949483; x=1407159083; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VxfAToR0ujt/e31PoDZfK56Wgcv495Xt1LqBLYM/XJ0=; b=i0UtCqMzqlBScmG6MMtlbjWBC+1oVvAHp7wRPAQdQE75k8uSk48O9CJu p29KVVg64MkI9uHI0r4jlolqoeEd8kHaEogTJdXbLRp4ftq/mTPP+17y5 AEfRjyRF8zB8A7nhTftybQLQj8dJR57Nflz90zjshlHOMJLJ+qFbVjoKL E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmoFAPMUzVOtJV2d/2dsb2JhbABZgkdHUluxOZIngVcBCYZyUwGBFRZ2hAMBAQEEAQEBGlEbAgEIEQMBAQEoByEGCxQJCAIEE4guAxENtzcNhyMXjR6CHA0KAYMugRgFjkOKXwGCAoFNjEaGHINEbIFF
X-IronPort-AV: E=Sophos;i="5.01,701,1400025600";  d="scan'208,217";a="341609986"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jul 2014 13:31:22 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6LDVLPr028500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 13:31:21 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 08:31:21 -0500
From: "Pal Martinsen (palmarti)" 
To: mmusic 
Thread-Topic: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document
Thread-Index: AQHPoimhFkxidQ89rUuYhi7UA3ZeipunlwgAgANIkwA=
Date: Mon, 21 Jul 2014 13:31:20 +0000
Message-ID: 
References: <53BBFCBC.7020707@cisco.com> <002701cfa21b$597f10b0$0c7d3210$@co.in>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.84.219]
Content-Type: multipart/alternative; boundary="_000_E1F2915779C845279F7E666405406E97ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ro-QQc7bixj1cbTfp499aikNfdQ
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 13:35:57 -0000

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


+1 for me as well.

On 19 Jul 2014, at 07:22, Xavier Marjou > wrote:

+1


On Fri, Jul 18, 2014 at 3:42 AM, Bernard Aboba > wrote:
I also support adoption.

________________________________
From: partha@parthasarathi.co.in
To: fandreas@cisco.com; mmusic@ietf.org
Date: Fri, 18 Jul 2014 05:30:48 +0530
CC: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; mmusic-chairs@tools.ietf.org
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as W=
G document



Hi all,



I support the adoption of this draft.



Thanks

Partha



From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Tuesday, July 08, 2014 7:44 PM
To: mmusic
Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; mmusic-chairs@tools.ietf.org
Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG do=
cument



Greetings,

We have an MMUSIC milestone for "SIP usage for Trickle ICE", and at the IET=
F 89 meeting we had a call for adoption of the Trickle ICE SIP draft as a W=
G document. There was a strong consensus in favor of adopting the document.=
 After the meeting there were a few comments on the document, which were di=
scussed on the MMUSIC mailing list and resulted in an updated version of th=
e document:

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02

At this point, the chairs would like to confirm adopting the updated draft =
as a WG document. If you have any concerns regarding the adoption, please l=
et us know no later than Friday, July 18th, 2014.

Thanks,

    Ari & Flemming (MMUSIC chairs)

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

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


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


--_000_E1F2915779C845279F7E666405406E97ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <91998D1BC03F074EAA3B7965D868FBE2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable












+1 for me as well.






On 19 Jul 2014, at 07:22, Xavier Marjou <xavier.marjou@gmail.com> wrote:






+1









On Fri, Jul 18, 2014 at 3:42 AM, Bernard Aboba <=
span dir=3D"ltr">
<bernard_=
aboba@hotmail.com> wrote:






I also support adoption. 







From: parth=
a@parthasarathi.co.in

To: fandreas@cisco.=
com; 
mmusic@ietf.org

Date: Fri, 18 Jul 2014 05:30:48 +0530

CC: 
draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; 
mmusic-chairs@tools.ietf.org

Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as W=
G document










Hi all,


 




I support the adoption of this draft.<=
/p>

 




Thanks


Partha


 










From: mmusic [mailto:mmusic-bounces@ietf.org]
On Behalf Of Flemming Andreasen

Sent: Tuesday, July 08, 2014 7:44 PM

To: mmusic

Cc: 
draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; 
mmusic-chairs@tools.ietf.org

Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 a=
s WG document






 




Greetings,



We have an MMUSIC milestone for "SIP usage for Trickle ICE", and =
at the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP dr=
aft as a WG document. There was a strong consensus in favor of adopting the=
 document. After the meeting there were a
 few comments on the document, which were discussed on the MMUSIC mailing l=
ist and resulted in an updated version of the document:




http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice=
-sip-02




At this point, the chairs would like to confirm adopting the updated draft =
as a WG document. If you have any concerns regarding the adoption, please l=
et us know no later than Friday, July 18th, 2014.




Thanks, 



    Ari & Flemming (MMUSIC chairs) 











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







_______________________________________________

mmusic mailing list

mmusic@ietf.org

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











_______________________________________________

mmusic mailing list

mmusic@ietf.org

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










--_000_E1F2915779C845279F7E666405406E97ciscocom_--


From nobody Mon Jul 21 13:46:03 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060C11A04B0 for ; Mon, 21 Jul 2014 13:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGuFmaG47-TJ for ; Mon, 21 Jul 2014 13:46:00 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3CE1A0328 for ; Mon, 21 Jul 2014 13:46:00 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id d1so4771952wiv.3 for ; Mon, 21 Jul 2014 13:45:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=9CMC4//vH2j9nDmWDJ9X4cHyfe9ISfK5kzG9S1cdpMk=; b=l4cVrCqz+1RnWL7sFi3Ly+1RodjtDuNxYAGa2PrM4Ym0MfkZcjpAIDAUQoUVf4E7L6 gQG6KGK9VViDVxMqMiCSVFgTsCpxh3ySHgeOeV/FqhkPEhEaIRtNN8iOc8GlFfk6NV/d EBzrToIRGNHxPoIN4mpjNlJofGD5s55uk+kSx338GMnvjop+VKFoucP8wONe6Vas1V7D BX42ODJOg3x4Z3Xiaib8L9+a7e2wIjD48tyPdxtT3Do/H2oCPguTga7TdNJvjra66ME0 /SNpdp5THQHc99BFGcUzPXepXtgqjDOP6NoNuNhNVtmxX8g7mU32vvpqtr6p6qjGgo7c GEjA==
X-Gm-Message-State: ALoCoQkYhx1uLc6zjx5Hx3jUPS4NB301KJ6mh1G/I1m/Mra1pOzj3X5qDdYzq69pcOeDVYxSKBee
X-Received: by 10.180.184.20 with SMTP id eq20mr7641594wic.37.1405975558932; Mon, 21 Jul 2014 13:45:58 -0700 (PDT)
Received: from dhcp-9545.meeting.ietf.org (monitoring.jitsi.net. [178.33.104.217]) by mx.google.com with ESMTPSA id ek3sm40217885wjd.17.2014.07.21.13.45.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 13:45:58 -0700 (PDT)
Message-ID: <53CD7C04.8070106@jitsi.org>
Date: Mon, 21 Jul 2014 16:45:56 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/HCdfyfP8WWEhDveSjAUWLOfMPpg
Subject: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 20:46:02 -0000

Hey all,

In London we mentioned the option of adding a new attribute that, during 
aggressive nomination, the controlling agent can use to notify its peer 
that ICE processing is over and no more changes are going to be 
attempted. This way controlled agents will no they can now release 
resources.

This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or, 
as Justin suggested in an off-list discussion, we could have the 
controlling agent send a second USE-CANDIDATE once aggressive nomination 
converges.

Any thoughts?

Emil


-- 
https://jitsi.org


From nobody Tue Jul 22 02:21:24 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8E1A0503 for ; Tue, 22 Jul 2014 02:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5SQJQ4KnjC3 for ; Tue, 22 Jul 2014 02:21:10 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE31A04AE for ; Tue, 22 Jul 2014 02:21:09 -0700 (PDT)
Received: from [192.168.40.44] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 41CE293C1AF; Tue, 22 Jul 2014 09:20:53 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_370FE1C5-54D3-43C2-8128-D130A08CB2BD"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Tue, 22 Jul 2014 11:21:07 +0200
Message-Id: <7BE98380-62D8-434A-A48F-4532CD504682@edvina.net>
References: <53BBFCBC.7020707@cisco.com> <002701cfa21b$597f10b0$0c7d3210$@co.in>   
To: "Pal Martinsen (palmarti)" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rRw0nR2sDwB5xXzfVFpMOKRJ1j0
Cc: mmusic 
Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 09:21:23 -0000

--Apple-Mail=_370FE1C5-54D3-43C2-8128-D130A08CB2BD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1 from a sunny Sweden!

/O
On 21 Jul 2014, at 15:31, Pal Martinsen (palmarti)  =
wrote:

>=20
> +1 for me as well.
>=20
> On 19 Jul 2014, at 07:22, Xavier Marjou  =
wrote:
>=20
>> +1
>>=20
>>=20
>> On Fri, Jul 18, 2014 at 3:42 AM, Bernard Aboba =
 wrote:
>> I also support adoption.=20
>>=20
>> From: partha@parthasarathi.co.in
>> To: fandreas@cisco.com; mmusic@ietf.org
>> Date: Fri, 18 Jul 2014 05:30:48 +0530
>> CC: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; =
mmusic-chairs@tools.ietf.org
>> Subject: Re: [MMUSIC] Adoption of =
draft-ivov-mmusic-trickle-ice-sip-02 as WG document
>>=20
>>=20
>> Hi all,
>>=20
>> =20
>> I support the adoption of this draft.
>>=20
>> =20
>> Thanks
>>=20
>> Partha
>>=20
>> =20
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming =
Andreasen
>> Sent: Tuesday, July 08, 2014 7:44 PM
>> To: mmusic
>> Cc: draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; =
mmusic-chairs@tools.ietf.org
>> Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as =
WG document
>>=20
>> =20
>> Greetings,
>>=20
>> We have an MMUSIC milestone for "SIP usage for Trickle ICE", and at =
the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP =
draft as a WG document. There was a strong consensus in favor of =
adopting the document. After the meeting there were a few comments on =
the document, which were discussed on the MMUSIC mailing list and =
resulted in an updated version of the document:=20
>>=20
>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02=20
>>=20
>> At this point, the chairs would like to confirm adopting the updated =
draft as a WG document. If you have any concerns regarding the adoption, =
please let us know no later than Friday, July 18th, 2014.=20
>>=20
>> Thanks,=20
>>=20
>>     Ari & Flemming (MMUSIC chairs)
>>=20
>>=20
>> _______________________________________________ mmusic mailing list =
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>=20
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--Apple-Mail=_370FE1C5-54D3-43C2-8128-D130A08CB2BD
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

+1 from a sunny Sweden!

/O
On 21 Jul 2014, at 15:31, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:













+1 for me as well.






On 19 Jul 2014, at 07:22, Xavier Marjou <xavier.marjou@gmail.com> wrote:






+1









On Fri, Jul 18, 2014 at 3:42 AM, Bernard Aboba 
<bernard_aboba@hotmail.com> wrote:






I also support adoption. 







From: partha@parthasarathi.co.in

To: fandreas@cisco.com; 
mmusic@ietf.org

Date: Fri, 18 Jul 2014 05:30:48 +0530

CC: 
draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; 
mmusic-chairs@tools.ietf.org

Subject: Re: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document








Hi all,


 


I support the adoption of this draft.


 


Thanks
Partha


 








From: mmusic [mailto:mmusic-bounces@ietf.org]
On Behalf Of Flemming Andreasen

Sent: Tuesday, July 08, 2014 7:44 PM

To: mmusic

Cc: 
draft-ivov-mmusic-trickle-ice-sip@tools.ietf.org; 
mmusic-chairs@tools.ietf.org

Subject: [MMUSIC] Adoption of draft-ivov-mmusic-trickle-ice-sip-02 as WG document






 


Greetings,



We have an MMUSIC milestone for "SIP usage for Trickle ICE", and at the IETF 89 meeting we had a call for adoption of the Trickle ICE SIP draft as a WG document. There was a strong consensus in favor of adopting the document. After the meeting there were a
 few comments on the document, which were discussed on the MMUSIC mailing list and resulted in an updated version of the document:




http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02




At this point, the chairs would like to confirm adopting the updated draft as a WG document. If you have any concerns regarding the adoption, please let us know no later than Friday, July 18th, 2014.




Thanks, 



    Ari & Flemming (MMUSIC chairs) 











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







_______________________________________________

mmusic mailing list

mmusic@ietf.org

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











_______________________________________________

mmusic mailing list

mmusic@ietf.org

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










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


--Apple-Mail=_370FE1C5-54D3-43C2-8128-D130A08CB2BD--


From nobody Tue Jul 22 02:58:01 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFDF1A064A for ; Tue, 22 Jul 2014 02:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQA6IwJUBH2P for ; Tue, 22 Jul 2014 02:57:47 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE02C1A032A for ; Tue, 22 Jul 2014 02:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1581; q=dns/txt; s=iport; t=1406023067; x=1407232667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xEnDOh3wqheSHJt5EnNirqJZWn36EhJW9ZvDlSzG9ok=; b=hbSTr+E/en/3o2/5gkS/uyT8sBJlUdoxJo5ymUR4gLPst4QGanGmgh+G 6Pj+flx7sQps2smO41EWocTEjhMNLbmlmjvYL0zXEZ4CdOZB8b9yQVard IOTWIYoWdnjanBkEkZSZ4AoCMHwc2PA8maLdzAcbPXS6Z2+AJCr8v5sfB c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFAD41zlOtJA2N/2dsb2JhbABYgw5SVwTHBwqGclMBgREWdoQEAQEDAQEBAWsLBQsCAQgOOCcLJQIEDgUZiCEIDb8+EwSOdyEzB4MugRgFiiyQepQvg0RsgUU
X-IronPort-AV: E=Sophos;i="5.01,709,1400025600"; d="scan'208";a="62937116"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 22 Jul 2014 09:57:46 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6M9vj4a021439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 09:57:45 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 04:57:45 -0500
From: "Pal Martinsen (palmarti)" 
To: Emil Ivov 
Thread-Topic: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
Thread-Index: AQHPpSTNMoyao5qjc0uyG0oVeP4rqpusMEwA
Date: Tue, 22 Jul 2014 09:57:44 +0000
Message-ID: <9F57A7FF-0029-4228-931C-0B19A49A81BB@cisco.com>
References: <53CD7C04.8070106@jitsi.org>
In-Reply-To: <53CD7C04.8070106@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.194.214]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2F235BD9604007439643A3B5E5714D14@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LsSIFO8_Zm5fAqMOI_XUO3iwP2I
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 09:57:59 -0000

On 21 Jul 2014, at 16:45, Emil Ivov  wrote:

> Hey all,
>=20
> In London we mentioned the option of adding a new attribute that, during=
=20
> aggressive nomination, the controlling agent can use to notify its peer=20
> that ICE processing is over and no more changes are going to be=20
> attempted. This way controlled agents will no they can now release=20
> resources.
>=20
+1

And it makes life somewhat easier for people looking through Wireshark trac=
es trying to figure out why the ICE negotiation failed.

Middle boxes that understand ICE would also benefit from this. (As a side e=
ffect, not the main motivation)

> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or,=
=20

I prefer this approach. The new attribute will not hurt backwards compatibi=
lity, and it is a nice hint to say that this behaviour is supported.

> as Justin suggested in an off-list discussion, we could have the=20
> controlling agent send a second USE-CANDIDATE once aggressive nomination=
=20
> converges.

I just want to avoid keeping more states in the ICE machinery.=20

Keeping track of how many USE-CANIDATES received with the same USERNAME, bu=
t different STUN transaction Ids on the same 5-tuple is just a bit inconven=
ient.=20

Or am I missing something?

.-.
P=E5l-Erik
=20
>=20
> Any thoughts?
>=20
> Emil
>=20
>=20
> --=20
> https://jitsi.org
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Tue Jul 22 05:14:11 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2261A064A; Tue, 22 Jul 2014 05:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0zFerxpHJ_w; Tue, 22 Jul 2014 05:14:01 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401581A0117; Tue, 22 Jul 2014 05:14:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1406031241; x=1437567241; h=message-id:date:to:from:subject:mime-version; bh=JqF/04iUkQU7qeNHhXSQ7WiOnKf8t3Lbd8ySVV+C60U=; b=JoOAAlYQjJ6DUb2UUXIPUhtdKsibUywwQe6Mfs5AyHPzD/F9d19woef1 TLYGq8SbEXK7So7MFDbSUjvmJ9K3wjju4eWAIp+JPPXbTXXtqan189ZhD 6DmAllz3fs2IhF6fVY56tJkT0FvlVFD21wW2yFb9LJCAJ0O0Bp/Wr8uBo g=;
X-IronPort-AV: E=McAfee;i="5600,1067,7506"; a="71571649"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 22 Jul 2014 05:14:00 -0700
X-IronPort-AV: E=Sophos;i="5.01,710,1400050800"; d="scan'208";a="703346627"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Jul 2014 05:14:00 -0700
Received: from [192.168.6.56] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 22 Jul 2014 05:13:58 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Tue, 22 Jul 2014 05:13:53 -0700
To: , , 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/pW6rXkwfGIG6ljWItoEi1y6vyhI
Subject: [MMUSIC] Toronto time for human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 12:14:06 -0000

Hi Everyone,

Since Thursday at 4:40 is the most popular time, let's meet then. 
This is just before ECRIT.  Paul can't make it then, but he and I can 
chat Friday at 4:40 for a second discussion.  Anyone else who is 
available on Friday is welcome to join us then as well.

Let's meet both times at the IETF message board.

>  Hi to everyone who participated in previous discussions about the 
> human language negotiation draft.
>
>  I'd like to make progress on this draft.  I think meeting in 
> Toronto can help that.  Please participate.
>
>  I created a Doodle poll to see if we can find a time in Toronto to 
> meet face to face.
>
>  Doodle poll for time at Toronto to discuss open issues and moving 
> forward with Human Language Negotiation: 
> http://doodle.com/pm3mph6xa3m9kupp
>
>  Link to current version of draft: 
> http://tools.ietf.org/html/draft-gellens-negotiating-human-language


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
We do not stop playing because we grow old; we grow old because we stop
playing.             --U.S. Supreme Court Justice Oliver Wendell Holmes


From nobody Tue Jul 22 08:02:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F31A007A for ; Tue, 22 Jul 2014 08:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydebx4Ls1lkv for ; Tue, 22 Jul 2014 08:02:40 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89C71A0073 for ; Tue, 22 Jul 2014 08:02:39 -0700 (PDT)
X-AuditID: c1b4fb30-f79da6d000006b80-97-53ce7d0d8e30
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.0D.27520.D0D7EC35; Tue, 22 Jul 2014 17:02:38 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Tue, 22 Jul 2014 17:02:37 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id ABD24110299; Tue, 22 Jul 2014 18:02:37 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F5C7589BE;	Tue, 22 Jul 2014 18:02:47 +0300 (EEST)
Received: from dhcp-8b9d.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F1919577F2;	Tue, 22 Jul 2014 18:02:46 +0300 (EEST)
Message-ID: <53CE7D0A.4030406@ericsson.com>
Date: Tue, 22 Jul 2014 11:02:34 -0400
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Emil Ivov 
References: <53CD7C04.8070106@jitsi.org>
In-Reply-To: <53CD7C04.8070106@jitsi.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+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjS5f7blgg1UN/BZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgylh9fw9LwU22indPHzM2MK5n7WLk5JAQMJH4 +nQCE4QtJnHh3nq2LkYuDiGBo4wSrc+WM0E4GxglVm9qYIRw9jJK/Jg4BapsHaPEn1nvWOCc Kwd+gA3jFdCWuDL9MxuIzSKgKrHg915GEJtNwF7i5oTr7CC2qECyxJqtk9gh6gUlTs58wgJi iwjIS3S3LQKbwywgIzHjbCOYLSxgI7GieR1zFyMH0DINieUXuUFMTgFNifuvXSGqbSUuzLnO AmHLS2x/O4cZ4jU1iavnNoHZQkDXXP33inECo+gsJItnIWmfhaR9ASPzKkbR4tTipNx0IyO9 1KLM5OLi/Dy9vNSSTYzAiDi45bfBDsaXzx0PMQpwMCrx8CqEng0WYk0sK67MPcQozcGiJM67 8Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2My7OnhUnNeJJcfTVK1mrSRZXd/81NV/yy 26xj8K6vNDXt0967BU/8JnW5tvHUfp5rVzUtatX6bZF/lv2JlVyqcpCJ0X3S/mrzIDcWSe5j af2LjWNd17y/p7j0Us0ly4dW992EDp5wmhrt29nxrOl61Pyn+g+ZV8x4mtqjf9+/UefBg+fp flziSizFGYmGWsxFxYkAzvzdGmkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/I-vJndKKYD8J6StF9hq2Pa3TTRA
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 15:02:42 -0000

Hi,

On 7/21/14 4:45 PM, Emil Ivov wrote:
> In London we mentioned the option of adding a new attribute that, during
> aggressive nomination, the controlling agent can use to notify its peer
> that ICE processing is over and no more changes are going to be
> attempted. This way controlled agents will no they can now release
> resources.
>
> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or,
> as Justin suggested in an off-list discussion, we could have the
> controlling agent send a second USE-CANDIDATE once aggressive nomination
> converges.

Did you consider using the updated offer to indicate that you're really 
done? This would require that you always send it (i.e., a slight 
modification to 5245), but that's something that has been already 
proposed to be updated for other purposes.


Cheers,
Ari


From nobody Tue Jul 22 08:06:18 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096321A007A for ; Tue, 22 Jul 2014 08:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsxK88aiyGqE for ; Tue, 22 Jul 2014 08:06:13 -0700 (PDT)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BD71A02D0 for ; Tue, 22 Jul 2014 08:06:12 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id l18so8226844wgh.14 for ; Tue, 22 Jul 2014 08:06:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oWsYyOFGPctD5voQAovkbuvu9twPwAMnt8/TxE5RCYM=; b=eDFaJEugCGbAYx03pDhT7j/K4UwEKFJri90NPG7bFXpYjq1Nb643uDUoCi758uZQsg 9ORfAyQTYBnuRdJ+XT4Bsfw4324xDLx8dQEUbZyH07VOpqAgkNyqybzJ+JCua9utor+n gU0wUaVDjM4dTYdjyiHzycrnovA2DRv3bhg55LMtsjr6tFpvfJLzliOozoaxuIxZEwQh LEr5DJTxOJdBLrsOXTyYErG4fMumxzHh8a2W4rhq8eZx0Plr6KYnHyayiFtzNyuqElJ9 0dfygpQu2jtE0lDptpon87suriLQFZrvZsHNhHZdD+77++d0DeCqu4bca2kZLtD+PP3y YyaQ==
X-Gm-Message-State: ALoCoQmcvazJopH3V9XVCkx/CL8Io+LmpKGSF63ksHjL8kLoAWXzn+17F80K+FOCvaeYQR3QfGlC
X-Received: by 10.194.86.164 with SMTP id q4mr35468972wjz.88.1406041571430; Tue, 22 Jul 2014 08:06:11 -0700 (PDT)
Received: from dhcp-9b62.meeting.ietf.org (dhcp-9b62.meeting.ietf.org. [31.133.155.98]) by mx.google.com with ESMTPSA id a13sm1620208wjs.12.2014.07.22.08.06.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 08:06:07 -0700 (PDT)
Message-ID: <53CE7DDD.5030406@jitsi.org>
Date: Tue, 22 Jul 2014 11:06:05 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com>
In-Reply-To: <53CE7D0A.4030406@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LUpCw6Hul6wfGeOH4ERQCnOKAjY
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 15:06:16 -0000

On 22.07.14, 11:02, Ari Kernen wrote:
> Hi,
>
> On 7/21/14 4:45 PM, Emil Ivov wrote:
>> In London we mentioned the option of adding a new attribute that, during
>> aggressive nomination, the controlling agent can use to notify its peer
>> that ICE processing is over and no more changes are going to be
>> attempted. This way controlled agents will no they can now release
>> resources.
>>
>> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or,
>> as Justin suggested in an off-list discussion, we could have the
>> controlling agent send a second USE-CANDIDATE once aggressive nomination
>> converges.
>
> Did you consider using the updated offer to indicate that you're really
> done? This would require that you always send it (i.e., a slight
> modification to 5245), but that's something that has been already
> proposed to be updated for other purposes.

The point is to have all that information without involving signalling, 
as is the case with regular nomination.

Let me ask the question the other way. Is there any reason not to do this?

Emil


-- 
https://jitsi.org


From nobody Tue Jul 22 12:33:07 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EF91B27BD for ; Tue, 22 Jul 2014 12:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOt7miT4DNmI for ; Tue, 22 Jul 2014 12:33:01 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF35D1A0118 for ; Tue, 22 Jul 2014 12:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2301; q=dns/txt; s=iport; t=1406057581; x=1407267181; h=message-id:date:from:mime-version:to:cc:subject; bh=BN5nhgBhto0sj3ravstXmAwNqiS7TdlqC4S1A615eT8=; b=jFX8FjzWmmFG5qN09SQ/tn5zeq9Ko5f0T7+ycmyyiQCNRtSq9W+DX4iO F8RMetgQalX5NmJ0AZT/MuMpu6x/O8cUq6qUufvDe06i8vPb0k7BndzXc gj0mjHJfIqTup5Xw3inOc1sJEa9cADxjtqw/wLn7pqgbNlOKdppOFHMHl w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0RAMi7zlOtJA2K/2dsb2JhbABYgw5SWK5gDAEBAQEBAQUBbgGXMYdFgRQWdoUCAR8BHBYYAwIBAgFLDQEHAQGIPg2/aReFe4lQhE0FmyeBTYVKjRyDYiE
X-IronPort-AV: E=Sophos;i="5.01,711,1400025600";  d="scan'208,217";a="342117978"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 22 Jul 2014 19:33:00 +0000
Received: from [10.86.241.5] (che-vpn-cluster-1-260.cisco.com [10.86.241.5]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6MJWxPY018456; Tue, 22 Jul 2014 19:32:59 GMT
Message-ID: <53CEBC6A.9080302@cisco.com>
Date: Tue, 22 Jul 2014 15:32:58 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic 
Content-Type: multipart/alternative; boundary="------------000706070109050005000502"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fUTLPMF16oOShYncVPz8VdLCONs
Cc: "mmusic-chairs@tools.ietf.org" , draft-ietf-avtext-rtp-grouping-taxonomy@tools.ietf.org, "avtext-chairs@tools.ietf.org" 
Subject: [MMUSIC] RTP Taxonomy Draft: MMUSIC comments due August 6.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 19:33:06 -0000

This is a multi-part message in MIME format.
--------------000706070109050005000502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greetings

The AVTEXT group is getting close to issuing a WGLC on the RTP Taxonomy 
draft (" A Taxonomy of Grouping Semantics and Mechanisms for Real-Time 
Transport"), which is of relevance to people in the MMUSIC group (and 
other groups). AVTEXT has asked that MMUSIC takes a look at the document 
and that we provide any comments or concerns we may have by August 6. In 
particular, MMUSIC document authors that work on RTP or grouping related 
drafts should be reviewing the draft. The current document can be found at:

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

Comments confirming that people are comfortable with the document would 
be helpful as well.

Thanks

-- Flemming (MMUSIC co-chair)

--------------000706070109050005000502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Greetings

    

    The AVTEXT group is getting close to issuing a WGLC on the RTP
    Taxonomy draft ("
    
    A Taxonomy of Grouping Semantics and Mechanisms for Real-Time
    Transport"), which is of relevance to people in the MMUSIC group
    (and other groups). AVTEXT has asked that MMUSIC takes a look at the
    document and that we provide any comments or concerns we may have by
    August 6. In particular, MMUSIC document authors that work on RTP or
    grouping related drafts should be reviewing the draft. The current
    document can be found at:

    

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

    

    Comments confirming that people are comfortable with the document
    would be helpful as well. 

    

    Thanks 

    

    -- Flemming (MMUSIC co-chair)

  


--------------000706070109050005000502--


From nobody Tue Jul 22 15:12:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B1A1A03C8 for ; Tue, 22 Jul 2014 15:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTJdkmPIHWmp for ; Tue, 22 Jul 2014 15:11:56 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A5D1A010C for ; Tue, 22 Jul 2014 15:11:55 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-14-53cee1a97d37
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.24.03739.9A1EEC35; Wed, 23 Jul 2014 00:11:53 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.174.1; Wed, 23 Jul 2014 00:11:53 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 36EFC11029A; Wed, 23 Jul 2014 01:11:53 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8EE97589BE;	Wed, 23 Jul 2014 01:12:03 +0300 (EEST)
Received: from dhcp-9130.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E943E577F2;	Wed, 23 Jul 2014 01:12:02 +0300 (EEST)
Message-ID: <53CEE1A7.7070202@ericsson.com>
Date: Tue, 22 Jul 2014 18:11:51 -0400
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Emil Ivov 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org>
In-Reply-To: <53CE7DDD.5030406@jitsi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje7Kh+eCDfpbDCzW7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlfF3xQemgl88FQfmTGNuYNzF1cXIySEhYCKx /+FeZghbTOLCvfVsXYxcHEICRxklJj7czAjhbGCUuPLtBAuEs5dR4uTZLVDOOkaJ15db2OCc xVsegQ3jFdCWmLfuKxuIzSKgKvHrTx8TiM0mYC9xc8J1dhBbVCBZYs3WSewQ9YISJ2c+YQGx RQTkJbrbFoHVMwvISMw42whmCwvYSKxoXgc2X0ggVeLMrxtgNqeApsT2Cc8YIeptJS7Muc4C YctLNG+dDfWcmsTVc5ugelUlrv57xTiBUXQWktWzkLTPQtK+gJF5FaNocWpxcW66kbFealFm cnFxfp5eXmrJJkZgVBzc8lt3B+Pq146HGAU4GJV4eBcsOxcsxJpYVlyZe4hRmoNFSZx30bl5 wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYbX3WTVb/+yMiddGaC9ZzlXztK626/krbs7k1 LWPRvaEvvSGE8QO7/vsZstkB0w/uSyzgCn5vcfOzY9KGif937lauMp19m9Wb1XjumgtThbo6 shcnxX1O9peYXiY/fa3l5z/L22O6n9S0Nz8/qc2VPuFWJstRV9Pf7sv9Zn235PrSeiTyyWk5 JZbijERDLeai4kQA/k3G7msCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4fua_KVMmBVJGrNFDoYNQYbH71c
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 22:12:04 -0000

On 7/22/14 11:06 AM, Emil Ivov wrote:
> On 22.07.14, 11:02, Ari Kernen wrote:
>> Hi,
>>
>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>> In London we mentioned the option of adding a new attribute that, during
>>> aggressive nomination, the controlling agent can use to notify its peer
>>> that ICE processing is over and no more changes are going to be
>>> attempted. This way controlled agents will no they can now release
>>> resources.
>>>
>>> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or,
>>> as Justin suggested in an off-list discussion, we could have the
>>> controlling agent send a second USE-CANDIDATE once aggressive nomination
>>> converges.
>>
>> Did you consider using the updated offer to indicate that you're really
>> done? This would require that you always send it (i.e., a slight
>> modification to 5245), but that's something that has been already
>> proposed to be updated for other purposes.
>
> The point is to have all that information without involving signalling,
> as is the case with regular nomination.
>
> Let me ask the question the other way. Is there any reason not to do this?

Just the usual: are the benefits higher than the added complexity. Here, 
depending how it's done, the added complexity should be fairly low though.

For the benefits, currently with SIP you are allowed to release the not 
selected candidate resources after 3 seconds from concluding ICE 
(http://tools.ietf.org/html/rfc5245#section-8.3.1). For non-SIP cases 
probably some more guidance in bis would be in order. Or did you have 
some other kind of resources in mind?


Cheers,
Ari


From nobody Tue Jul 22 16:12:25 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AAF1A0027 for ; Tue, 22 Jul 2014 16:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiLfAppdZuFP for ; Tue, 22 Jul 2014 16:12:22 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452331A0004 for ; Tue, 22 Jul 2014 16:12:22 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hy4so698315vcb.22 for ; Tue, 22 Jul 2014 16:12:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3b3n4IXcCTLY2vPaR3mCdgU2s2ASmOJdnjHodiQYIxU=; b=U/cNjONhnatDRLAEpLKFx9vhOMgb48pp6K/TQaCBR4BbQP5q7g0Mi/DRoEN+2P/lkU +UQY34HjUwSbRyydGDU5FhNHPnvaP3cfTLKYhNzmzLtGM6wcO1sP5BmeBHBHBMmh99IE G91w+cPi4Dxmq3I/3ls81uFyM29v73UrqHwZUBlFsqE0sQ9WsB/aTPB6dHqzz0aYs4Jn C5dAfqftr+els59nV1Z0EHqodeqYff3HOZKrBORkD6M9P6wWIX2cEZj+GXUOdy4Ah0XR urNt694Y1teQ3BThgHhc9nHODjfcL8KGGZH5fyN7DZoIx5tJjNppYkGQ1Q5CrbbmwEHh LN0w==
X-Gm-Message-State: ALoCoQkk9vZdmfsKRMu+7DsYvxlZ/OBjYk+SXYzei3JF+Xakb+pYoddtfutuCvCDN0ZATLGzbz5p
X-Received: by 10.52.53.135 with SMTP id b7mr21876696vdp.67.1406070741196; Tue, 22 Jul 2014 16:12:21 -0700 (PDT)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx.google.com with ESMTPSA id pa15sm917448vdb.14.2014.07.22.16.12.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 16:12:20 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so709592vcb.21 for ; Tue, 22 Jul 2014 16:12:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.81.194 with SMTP id y2mr44913738vck.29.1406070740423; Tue, 22 Jul 2014 16:12:20 -0700 (PDT)
Received: by 10.220.238.75 with HTTP; Tue, 22 Jul 2014 16:12:20 -0700 (PDT)
Received: by 10.220.238.75 with HTTP; Tue, 22 Jul 2014 16:12:20 -0700 (PDT)
In-Reply-To: <53CEE1A7.7070202@ericsson.com>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>
Date: Tue, 22 Jul 2014 19:12:20 -0400
Message-ID: 
From: Emil Ivov 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: multipart/alternative; boundary=001a11c2d8600333d304fed05b72
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MOI5TLkvqiMSTPima8Qh4_oL41w
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 23:12:23 -0000

--001a11c2d8600333d304fed05b72
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen"  wrote=
:
>
> On 7/22/14 11:06 AM, Emil Ivov wrote:
>>
>> On 22.07.14, 11:02, Ari Ker=C3=A4nen wrote:
>>>
>>> Hi,
>>>
>>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>>>
>>>> In London we mentioned the option of adding a new attribute that,
during
>>>> aggressive nomination, the controlling agent can use to notify its pee=
r
>>>> that ICE processing is over and no more changes are going to be
>>>> attempted. This way controlled agents will no they can now release
>>>> resources.
>>>>
>>>> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED)
or,
>>>> as Justin suggested in an off-list discussion, we could have the
>>>> controlling agent send a second USE-CANDIDATE once aggressive
nomination
>>>> converges.
>>>
>>>
>>> Did you consider using the updated offer to indicate that you're really
>>> done? This would require that you always send it (i.e., a slight
>>> modification to 5245), but that's something that has been already
>>> proposed to be updated for other purposes.
>>
>>
>> The point is to have all that information without involving signalling,
>> as is the case with regular nomination.
>>
>> Let me ask the question the other way. Is there any reason not to do
this?
>
>
> Just the usual: are the benefits higher than the added complexity. Here,
depending how it's done, the added complexity should be fairly low though.

The complexity of having to handle that over signalling and the need to
implement it on every sig protocol that ever dares to use ICE is arguably
much higher than that of an extra attribute

> For the benefits, currently with SIP you are allowed to release the not
selected candidate resources after 3 seconds from concluding ICE (
http://tools.ietf.org/html/rfc5245#section-8.3.1).

And that is the whole point because currently with aggressive nomination
you simply don't know exactly when ICE has concluded.

Emil

--sent from my mobile

> For non-SIP cases probably some more guidance in bis would be in order.
Or did you have some other kind of resources in mind?

>
>
> Cheers,
> Ari

--001a11c2d8600333d304fed05b72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen" <ari.keranen@ericsson.com> wrote:

>

> On 7/22/14 11:06 AM, Emil Ivov wrote:

>>

>> On 22.07.14, 11:02, Ari Ker=C3=A4nen wrote:

>>>

>>> Hi,

>>>

>>> On 7/21/14 4:45 PM, Emil Ivov wrote:

>>>>

>>>> In London we mentioned the option of adding a new attribut=
e that, during

>>>> aggressive nomination, the controlling agent can use to no=
tify its peer

>>>> that ICE processing is over and no more changes are going =
to be

>>>> attempted. This way controlled agents will no they can now=
 release

>>>> resources.

>>>>

>>>> This could either be a new attribute (e.g., USE-CANDIDATE-=
CONFIRMED) or,

>>>> as Justin suggested in an off-list discussion, we could ha=
ve the

>>>> controlling agent send a second USE-CANDIDATE once aggress=
ive nomination

>>>> converges.

>>>

>>>

>>> Did you consider using the updated offer to indicate that you&=
#39;re really

>>> done? This would require that you always send it (i.e., a slig=
ht

>>> modification to 5245), but that's something that has been =
already

>>> proposed to be updated for other purposes.

>>

>>

>> The point is to have all that information without involving signal=
ling,

>> as is the case with regular nomination.

>>

>> Let me ask the question the other way. Is there any reason not to =
do this?

>

>

> Just the usual: are the benefits higher than the added complexity. Her=
e, depending how it's done, the added complexity should be fairly low t=
hough.


The complexity of having to handle that over signalling and =
the need to implement it on every sig protocol that ever dares to use ICE i=
s arguably much higher than that of an extra attribute


> For the benefits, currently with SIP you are allowed to=
 release the not selected candidate resources after 3 seconds from concludi=
ng ICE (http:/=
/tools.ietf.org/html/rfc5245#section-8.3.1). 



And that is the whole point because currently with aggressiv=
e nomination you simply don't know exactly when ICE has concluded.


Emil


--sent from my mobile


> For non-SIP cases probably some more guidance in bis wo=
uld be in order. Or did you have some other kind of resources in mind?
<=
/p>

>

>

> Cheers,

> Ari




--001a11c2d8600333d304fed05b72--


From nobody Wed Jul 23 05:00:21 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53101A0ABC for ; Wed, 23 Jul 2014 05:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe6rqi_2zZnL for ; Wed, 23 Jul 2014 05:00:07 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9948E1A0A9F for ; Wed, 23 Jul 2014 05:00:06 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 21CAE23F069A; Wed, 23 Jul 2014 14:00:05 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 23 Jul 2014 14:00:04 +0200
From: "Stach, Thomas" 
To: MMUSIC 
Thread-Topic: ICE and the "unexpected answer" problem
Thread-Index: Ac+mbaDUMIq2nv4JQ7KZBsyANFFFPg==
Date: Wed, 23 Jul 2014 12:00:04 +0000
Message-ID: 
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE1217AD2CB4MCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/HXVMnWmaBZTNoQF-fmN_wqlA8dY
Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= 
Subject: [MMUSIC] ICE and the "unexpected answer" problem
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:00:11 -0000

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

ICE experts,

we came across the following situation that has some relation to ICE restar=
t procedures.

Consider that A calls B via a B2BUA. Both A and B support ICE and have succ=
essfully finished ICE procedures though the B2BUA is ICE-unaware.
Now after a while either A or B sends out a new offer to put the other part=
y on hold (a=3Dinactive) without indicating an ICE restart.
It includes the in-use candidates and the remote-candidates as required by =
section 9 of RFC5245 and expects to get the remote-candidates reflected in =
the answer.

However, the B2BUA in the signaling path introduces via some 3PCC means a m=
edia server that provides MoH to the Held UA.
On the call-leg towards the Holding UA, the B2BUA sends back some dummy ans=
wer that fulfills RFC3264 requirements (e.g. includes a=3Dinactive) but doe=
s not include the expected remote-candidates.
The Holding UA was unaware of the B2BUA's interference, but now gets an "un=
expected answer" to its hold offer.

Of course there could al                so exist other similar situations w=
here the peer changes mid-call and the offerer receives some "unexpected" a=
nswer. If we take RFC3264 into consideration, an offerer would need to be p=
repared to receive such an "unexpected" answer.
But with respect to ICE procedures there is no guidance what to do next, al=
though http://tools.ietf.org/html/rfc5245#section-9.1.1.1 talks already abo=
ut Hold and ICE restarts.
However, it does not cover the above situation.
Would it be justified to include some clarification e.g.  into rfc5245bis o=
r draft-ietf-mmusic-ice-sip-sdp that something like the above could happen =
and even give some suggestions when/how to perform ICE restart?

Such suggestion could look roughly as follows:
The UA that got the "unexpected answer" would have to do an ICE restart in =
order to get things straight again once it sends out its next offer.
In the above situation It would be sufficient when the Holding UA performs =
the ICE restart once it reconnects to the Held UA,
i.e. it would not be necessary to do the ICE restart immediately although i=
n other situations that might be justified.
In yet other situations there might even be an ICE restart performed from t=
he peer, that sent the "unexpected answer".

Any thoughts/comments?
If people agree I would also be happy to contribute corresponding text.

Regards
Thomas


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











ICE experts,


 


we came across the following situation that has some=
 relation to ICE restart procedures.


 


Consider that A calls B via a B2BUA. Both A and B su=
pport ICE and have successfully finished ICE procedures though the B2BUA is=
 ICE-unaware.


Now after a while either A or B sends out a new offe=
r to put the other party on hold (a=3Dinactive) without indicating an ICE r=
estart.



It includes the in-use candidates and the remote-can=
didates as required by section 9 of RFC5245 and expects to get the remote-c=
andidates reflected in the answer.


 


However, the B2BUA in the signaling path introduces =
via some 3PCC means a media server that provides MoH to the Held UA.



On the call-leg towards the Holding UA, the B2BUA se=
nds back some dummy answer that fulfills RFC3264 requirements (e.g. include=
s a=3Dinactive) but does not include the expected remote-candidates.


The Holding UA was unaware of the B2BUA’s inte=
rference, but now gets an “unexpected answer” to its hold offer=
.


 


Of course there could al    &nbs=
p;           so exist oth=
er similar situations where the peer changes mid-call and the offerer recei=
ves some “unexpected” answer. If we take RFC3264 into considera=
tion, an offerer would need to be prepared to
 receive such an “unexpected” answer. 


But with respect to ICE procedures there is no guida=
nce what to do next, although
http://tools=
.ietf.org/html/rfc5245#section-9.1.1.1 talks already about Hold and ICE=
 restarts.


However, it does not cover the above situation.=



Would it be justified to include some clarification =
e.g.  into rfc5245bis or draft-ietf-mmusic-ice-sip-sdp that something =
like the above could happen and even give some suggestions when/how to perf=
orm ICE restart?


 


Such suggestion could look roughly as follows:<=
/o:p>


The UA that got the “unexpected answer” =
would have to do an ICE restart in order to get things straight again once =
it sends out its next offer.



In the above situation It would be sufficient when t=
he Holding UA performs the ICE restart once it reconnects to the Held UA,


i.e. it would not be necessary to do the ICE restart=
 immediately although in other situations that might be justified.


In yet other situations there might even be an ICE r=
estart performed from the peer, that sent the “unexpected answer̶=
1;.


 


Any thoughts/comments?


If people agree I would also be happy to contribute =
corresponding text.


 


Regards


Thomas


 






--_000_F81CEE99482EFE438DAE2A652361EE1217AD2CB4MCHP04MSXglobal_--


From nobody Wed Jul 23 09:30:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED791A00F0 for ; Wed, 23 Jul 2014 09:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgRieXTEz-EW for ; Wed, 23 Jul 2014 09:30:31 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A281A0084 for ; Wed, 23 Jul 2014 09:30:30 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-ae-53cfe324749c
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.C6.04090.423EFC35; Wed, 23 Jul 2014 18:30:28 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Wed, 23 Jul 2014 18:30:27 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 3525B11029C; Wed, 23 Jul 2014 19:30:28 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9A2BC589CC;	Wed, 23 Jul 2014 19:30:39 +0300 (EEST)
Received: from dhcp-bcda.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 01B6B589C9;	Wed, 23 Jul 2014 19:30:38 +0300 (EEST)
Message-ID: <53CFE322.5000508@ericsson.com>
Date: Wed, 23 Jul 2014 12:30:26 -0400
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Emil Ivov 
References: <53CD7C04.8070106@jitsi.org>	<53CE7D0A.4030406@ericsson.com>	<53CE7DDD.5030406@jitsi.org>	<53CEE1A7.7070202@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja7K4/PBBus/G1ms2TmBxWLq8scs DkweS5b8ZPL4/yYwgCmKyyYlNSezLLVI3y6BK+NPX0DBJ9GKbT8eMDUwThXsYuTkkBAwkfix uo0JwhaTuHBvPVsXIxeHkMBRRomD855CORsYJe7v/MQK4exllPj04RIjhLOOUeL8i1tMcM7v J90sIMN4BbQlZu/8wQZiswioSvz+eRjMZhOwlVj96iZYjahAssSarZPYIeoFJU7OfAIWFxGQ l+huWwR2FLOAjMSMs41gtrCAjcSK5nXMEMtOMUq0LL0C1MDBwSkQKNG6Nw2i3kJi8ZuD7BC2 vETz1tnMEM+pSVw9twnMFgK65+q/V4wTGEVnIVk9C0n7LCTtCxiZVzGKFqcWF+emGxnppRZl JhcX5+fp5aWWbGIExsTBLb+tdjAefO54iFGAg1GJh/fB/vPBQqyJZcWVuYcYpTlYlMR5F56b FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMV338YJZ96byCJb0+2cqyEyrWxrfZ5+yeIOP sXKPEEut6Z2CpHhGOd20PReWXgt83z7LeEZU+YxLM3yc74S5VinOq4tM1T25+vi8Kf/nWBZ2 nLP5vuadysayn5GdrrNvV8cbPVky1Ua8amfffBcdzSlT+Z7r1YmezHlfIM5a+JPJZ97uO+HG SizFGYmGWsxFxYkAfCrz/2oCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EfAqZdTxZhHOWYxOTmhAlJ2yw6Q
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 16:30:34 -0000

On 7/22/14 7:12 PM, Emil Ivov wrote:
>
> On 22 Jul 2014 6:11 PM, "Ari Keränen"  > wrote:
>  >
>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>  >>
>  >> On 22.07.14, 11:02, Ari Keränen wrote:
>  >>>
>  >>> Hi,
>  >>>
>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>  >>>>
>  >>>> In London we mentioned the option of adding a new attribute that,
> during
>  >>>> aggressive nomination, the controlling agent can use to notify its
> peer
>  >>>> that ICE processing is over and no more changes are going to be
>  >>>> attempted. This way controlled agents will no they can now release
>  >>>> resources.
>  >>>>
>  >>>> This could either be a new attribute (e.g.,
> USE-CANDIDATE-CONFIRMED) or,
>  >>>> as Justin suggested in an off-list discussion, we could have the
>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
> nomination
>  >>>> converges.
>  >>>
>  >>>
>  >>> Did you consider using the updated offer to indicate that you're really
>  >>> done? This would require that you always send it (i.e., a slight
>  >>> modification to 5245), but that's something that has been already
>  >>> proposed to be updated for other purposes.
>  >>
>  >>
>  >> The point is to have all that information without involving signalling,
>  >> as is the case with regular nomination.
>  >>
>  >> Let me ask the question the other way. Is there any reason not to do
> this?
>  >
>  >
>  > Just the usual: are the benefits higher than the added complexity.
> Here, depending how it's done, the added complexity should be fairly low
> though.
>
> The complexity of having to handle that over signalling and the need to
> implement it on every sig protocol that ever dares to use ICE is
> arguably much higher than that of an extra attribute

Actually I meant the complexity of implementing something like this, and 
why to do/not to do this (in any way).

>  > For the benefits, currently with SIP you are allowed to release the
> not selected candidate resources after 3 seconds from concluding ICE
> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>
> And that is the whole point because currently with aggressive nomination
> you simply don't know exactly when ICE has concluded.

So if you assume aggressive ICE has concluded after you've got your 
first USE-CANDIDATE checks done (as the text currently says), and you 
stop doing keep-alives on all except the selected candidate pair and let 
your relayed and reflexive candidates die away. You still have some time 
to switch between the candidates since the candidates are still alive 
for at least some (tens of?) seconds. Isn't that OK?

Or did you have some other kind of resources in mind?


Cheers,
Ari


From nobody Wed Jul 23 12:50:16 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E348C1A0204 for ; Wed, 23 Jul 2014 12:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uKb4mGcApJT for ; Wed, 23 Jul 2014 12:50:06 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F6C1B2CD9 for ; Wed, 23 Jul 2014 12:50:05 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hy4so3262490vcb.27 for ; Wed, 23 Jul 2014 12:50:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wtL3alfmkC97yFdpw8rYMH68lliI2bsRHBv9rk6Xtfk=; b=lBTmewYucUEYlHsepQ2cClqvWpfGrrtR43yM2URz8zWjPUjxaE9KmNfajjGkyNI7Pp vHzNoRBurrF+HC8pqMARdjtP7J/ocSEOadbdUJ1PWEFSChRLMkHmzgpeActpvMq1tgQw xda0u2wEFBaHGshV/EcKSY74m+REQIEV3MsKSmgeP/ZOzkfHNWmNjmjGlJM/cAsRUy7r Tod385BFJhMlQfMecye3+CvKFt2CGaVieMq2IhBcgZR8MuvwJrUmDGAfga0GHPXztlGp Ao2o2zcomLf+0chEEyVAYWAeKtg9EB1RKQnJUHxjJkhS/HOxZvEay+uaS+45goGUxskq WYgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wtL3alfmkC97yFdpw8rYMH68lliI2bsRHBv9rk6Xtfk=; b=CDDTcbCdssxfcOLplpBTXrKgHc3vnCUy+uUSCsrvf88mhYE9yPdkPbrsmGLVL99mjY X0kXw/LX2oiqI9GZkroHGbI34n9NtdrqgqbuMk+ZDpu2+R7pUbAG8wWxRsKq+gMSjuVN 1LK18R3WEdYjibZI33ZbKM4imUxL+735u3lwYgISYx2lcTTx6fxgKMdMpMdOslHJJVsV 9bIuO1vcPsgaANwomBeRFKNE/FjcZubjkSjwJW7qqgi4CDEIKUdzCBGbpGKlnXOI7YyO v40P17CCUdYmXPlFNXycFExgUs6VdfQxux0wrdSUwNl1HaxyHMa2NXk21rxZRURzt6hR W52w==
X-Gm-Message-State: ALoCoQlUjzG0GbmVGwEa/CQKQKWR2FzGY++j8IwtsobMsokfdrTWdHG+zOIiOcFoiG/Bv+mSZN+r
X-Received: by 10.52.154.106 with SMTP id vn10mr4610834vdb.36.1406145004944; Wed, 23 Jul 2014 12:50:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 12:49:44 -0700 (PDT)
In-Reply-To: 
References:   <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org>   <53C02A45.40703@jitsi.org> 
From: Justin Uberti 
Date: Wed, 23 Jul 2014 15:49:44 -0400
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=bcaec51d2f4885e4eb04fee1a535
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/P7T3tAX6nqkOK1J0dRN7xmtSF54
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 19:50:07 -0000

--bcaec51d2f4885e4eb04fee1a535
Content-Type: text/plain; charset=UTF-8

The JSEP authors discussed a bit more and agreed that using port 9s on all
m= lines when doing full trickle is the right solution to this problem.


On Fri, Jul 11, 2014 at 2:34 PM, Martin Thomson 
wrote:

> On 11 July 2014 11:17, Emil Ivov  wrote:
> >
> >
> > On 11.07.14, 19:51, Martin Thomson wrote:
> >>
> >> On 11 July 2014 09:33, Justin Uberti  wrote:
> >>>
> >>> a) We require unique 'dummy' ports in the initial trickle offer.
> >>> b) We allow use of the same dummy port (9) in the initial trickle
> offer.
> >>> (This is what Chrome does, although it currently uses port 1).
> >>>
> >>> We had been leaning towards (a) based on the legacy equipment case
> >>> mentioned
> >>> above. However, if nobody can provide details on this case, I agree we
> >>> should end up with (b).
> >>
> >>
> >> As a general rule, if accommodating legacy equipment is particularly
> >> hard for us here, then we should leave the fixups needed for that
> >> legacy equipment to application code.  This seems like a good
> >> candidate for that.  It's not like non-9 ports will work with all
> >> legacy equipment anyway.
> >
> > Also note that, in the case of trickle, port 9s would only occur if the
> > offerer expects (knows) it would be supported. In other cases it would
> just
> > do half trickle and the problem wouldn't exist.
>
> Yeah, that's even more reason to do the right thing (as opposed to the
> safe thing).
>

--bcaec51d2f4885e4eb04fee1a535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The JSEP authors discussed a bit more and agreed that usin=
g port 9s on all m=3D lines when doing full trickle is the right solution t=
o this problem.




On Fri, Jul 11, 2014 at 2:34 PM, Martin Thomson <martin.thomson@gma=
il.com> wrote:



On 11 July 2014 11:17, Emil Ivov &l=
t;emcho@jitsi.org> wrote:

>

>

> On 11.07.14, 19:51, Martin Thomson wrote:

>>

>> On 11 July 2014 09:33, Justin Uberti <juberti@google.com> wrote:

>>>

>>> a) We require unique 'dummy' ports in the initial tric=
kle offer.

>>> b) We allow use of the same dummy port (9) in the initial tric=
kle offer.

>>> (This is what Chrome does, although it currently uses port 1).=


>>>

>>> We had been leaning towards (a) based on the legacy equipment =
case

>>> mentioned

>>> above. However, if nobody can provide details on this case, I =
agree we

>>> should end up with (b).

>>

>>

>> As a general rule, if accommodating legacy equipment is particular=
ly

>> hard for us here, then we should leave the fixups needed for that<=
br>
>> legacy equipment to application code. =C2=A0This seems like a good=


>> candidate for that. =C2=A0It's not like non-9 ports will work =
with all

>> legacy equipment anyway.

>

> Also note that, in the case of trickle, port 9s would only occur if th=
e

> offerer expects (knows) it would be supported. In other cases it would=
 just

> do half trickle and the problem wouldn't exist.




Yeah, that's even more reason to do the right thing (as opp=
osed to the

safe thing).





--bcaec51d2f4885e4eb04fee1a535--


From nobody Wed Jul 23 12:59:07 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4175A1A01D6 for ; Wed, 23 Jul 2014 12:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level: 
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpk1b311JQdC for ; Wed, 23 Jul 2014 12:59:04 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A161A014F for ; Wed, 23 Jul 2014 12:59:04 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so3184113vcb.7 for ; Wed, 23 Jul 2014 12:59:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VPNJD6hDrzQmqzEuvVAFwHJQlqTZqvUPN4J5+8jOL0Y=; b=UMtsiqDlNHrGLiwwU7QFfJHNwO021xC9fcIu0sVF6TZmQAHDtWwdGemJbIo6yCrJu9 7iapX159qMx8oov4Nu0zIQGzhVnP4hgphlgpHUA5rhVsEJJxsnmqIgLlNdxFziXjHtZC j8tCcwSFgaMFWg73sAoJYFdGraPrLm+ljvvrpv6lmSg0ZX1OpDbj9TrIC3mWDdJX6nej /Y+/SAxUnINTkvbE38F8YPVFfKkdw+2/yOMK5xnSXoN9TMybBtKosyKq3fIVc3wBRBsE Zj/qWT0ZXHnHI+Weyl9FGGZg9LVwrMLOFPDt7rzxZLJJOKUhn2Art96AlS1Q3klaidRe tV/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VPNJD6hDrzQmqzEuvVAFwHJQlqTZqvUPN4J5+8jOL0Y=; b=bZLOZXialLen64MVVLhkOlFbj1glymUKOeN875CZvzojd2IlueNe0d8NqBHYQo+Rp/ iCK6vH38ycaEDtT23migwI5ah+34etMCt/DxSFaZZiiwPlutU9VZCRFdUO1B0FwMKunh DV/7F/QwZUFQ8P+JprYwFnw5X3V7J9gQSjTGKnmpn/6R133V4TxIKuyx9dPGEUZoe5/e +9Um/J+enTSLRbDCetNbuPOY667T35q/Nki+TX714nf9fbdRhbxas5qGrQVKyO3D6byG sJ6nrvpDCsLV3UXfCazurJ8MDWvK3d7gdDiTqzc05r3EkhmMYdr1NoZyB74UFgElphyv Oehg==
X-Gm-Message-State: ALoCoQmNglOoaRInhG1Qs9iW960ZCaliwkVur2quuKM1x2zvP4OY2cZ1Nm2hUkZjAlocCEjYbgPh
X-Received: by 10.52.13.98 with SMTP id g2mr4878611vdc.46.1406145543637; Wed, 23 Jul 2014 12:59:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 12:58:42 -0700 (PDT)
In-Reply-To: <53CFE322.5000508@ericsson.com>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com>
From: Justin Uberti 
Date: Wed, 23 Jul 2014 15:58:42 -0400
Message-ID: 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: multipart/alternative; boundary=20cf302ef544a1af7504fee1c51a
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/b83jxn9pqC_SdICIoNMeTPX4DDE
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 19:59:06 -0000

--20cf302ef544a1af7504fee1c51a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The issue isn't just that you don't know when aggressive nomination has
ended - it's that the CONTROLLING side can't truly express its desires to
the CONTROLLED side, including use of some dynamic metric (e.g. RTT) to
choose the active candidate pair instead of PRIORITY.

With regular nomination, the CONTROLLING side has this option, but not with
aggressive nomination. This is the core issue that I want to fix, and I
would definitely want to fix this in the media plane using something like
REALLY-USE-CANDIDATE, since it may change fairly quickly as RTT values
stabilize.

There are other things that we can try to fix at the same time, e.g. the
CONTROLLED side can keep other candidate pairs warm and switch to them at
any time (via another REALLY-USE-CANDIDATE).


On Wed, Jul 23, 2014 at 12:30 PM, Ari Ker=C3=A4nen 
wrote:

> On 7/22/14 7:12 PM, Emil Ivov wrote:
>
>>
>> On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen" > > wrote:
>>  >
>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>>  >>
>>  >> On 22.07.14, 11:02, Ari Ker=C3=A4nen wrote:
>>  >>>
>>  >>> Hi,
>>  >>>
>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>  >>>>
>>  >>>> In London we mentioned the option of adding a new attribute that,
>> during
>>  >>>> aggressive nomination, the controlling agent can use to notify its
>> peer
>>  >>>> that ICE processing is over and no more changes are going to be
>>  >>>> attempted. This way controlled agents will no they can now release
>>  >>>> resources.
>>  >>>>
>>  >>>> This could either be a new attribute (e.g.,
>> USE-CANDIDATE-CONFIRMED) or,
>>  >>>> as Justin suggested in an off-list discussion, we could have the
>>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
>> nomination
>>  >>>> converges.
>>  >>>
>>  >>>
>>  >>> Did you consider using the updated offer to indicate that you're
>> really
>>  >>> done? This would require that you always send it (i.e., a slight
>>  >>> modification to 5245), but that's something that has been already
>>  >>> proposed to be updated for other purposes.
>>  >>
>>  >>
>>  >> The point is to have all that information without involving
>> signalling,
>>  >> as is the case with regular nomination.
>>  >>
>>  >> Let me ask the question the other way. Is there any reason not to do
>> this?
>>  >
>>  >
>>  > Just the usual: are the benefits higher than the added complexity.
>> Here, depending how it's done, the added complexity should be fairly low
>> though.
>>
>> The complexity of having to handle that over signalling and the need to
>> implement it on every sig protocol that ever dares to use ICE is
>> arguably much higher than that of an extra attribute
>>
>
> Actually I meant the complexity of implementing something like this, and
> why to do/not to do this (in any way).
>
>
>   > For the benefits, currently with SIP you are allowed to release the
>> not selected candidate resources after 3 seconds from concluding ICE
>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>
>> And that is the whole point because currently with aggressive nomination
>> you simply don't know exactly when ICE has concluded.
>>
>
> So if you assume aggressive ICE has concluded after you've got your first
> USE-CANDIDATE checks done (as the text currently says), and you stop doin=
g
> keep-alives on all except the selected candidate pair and let your relaye=
d
> and reflexive candidates die away. You still have some time to switch
> between the candidates since the candidates are still alive for at least
> some (tens of?) seconds. Isn't that OK?
>
>
> Or did you have some other kind of resources in mind?
>
>
> Cheers,
> Ari
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--20cf302ef544a1af7504fee1c51a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The issue isn't just that you don't know when aggr=
essive nomination has ended - it's that the CONTROLLING side can't =
truly express its desires to the CONTROLLED side, including use of some dyn=
amic metric (e.g. RTT) to choose the active candidate pair instead of PRIOR=
ITY.



With regular nomination, the CONTROLLING side has this optio=
n, but not with aggressive nomination. This is the core issue that I want t=
o fix, and I would definitely want to fix this in the media plane using som=
ething like REALLY-USE-CANDIDATE, since it may change fairly quickly as RTT=
 values stabilize.




There are other things that we can try to fix at the sa=
me time, e.g. the CONTROLLED side can keep other candidate pairs warm and s=
witch to them at any time (via another REALLY-USE-CANDIDATE).





On Wed, Jul 2=
3, 2014 at 12:30 PM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com=
> wrote:



On 7/22/14 7:12 PM, Emil Ivo=
v wrote:





On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen" <ari.keranen@ericsson.com

<mailto:ar=
i.keranen@ericsson.com>> wrote:

=C2=A0>

=C2=A0> On 7/22/14 11:06 AM, Emil Ivov wrote:

=C2=A0>>

=C2=A0>> On 22.07.14, 11:02, Ari Ker=C3=A4nen wrote:

=C2=A0>>>

=C2=A0>>> Hi,

=C2=A0>>>

=C2=A0>>> On 7/21/14 4:45 PM, Emil Ivov wrote:

=C2=A0>>>>

=C2=A0>>>> In London we mentioned the option of adding a new at=
tribute that,

during

=C2=A0>>>> aggressive nomination, the controlling agent can use=
 to notify its

peer

=C2=A0>>>> that ICE processing is over and no more changes are =
going to be

=C2=A0>>>> attempted. This way controlled agents will no they c=
an now release

=C2=A0>>>> resources.

=C2=A0>>>>

=C2=A0>>>> This could either be a new attribute (e.g.,

USE-CANDIDATE-CONFIRMED) or,

=C2=A0>>>> as Justin suggested in an off-list discussion, we co=
uld have the

=C2=A0>>>> controlling agent send a second USE-CANDIDATE once a=
ggressive

nomination

=C2=A0>>>> converges.

=C2=A0>>>

=C2=A0>>>

=C2=A0>>> Did you consider using the updated offer to indicate tha=
t you're really

=C2=A0>>> done? This would require that you always send it (i.e., =
a slight

=C2=A0>>> modification to 5245), but that's something that has=
 been already

=C2=A0>>> proposed to be updated for other purposes.

=C2=A0>>

=C2=A0>>

=C2=A0>> The point is to have all that information without involving =
signalling,

=C2=A0>> as is the case with regular nomination.

=C2=A0>>

=C2=A0>> Let me ask the question the other way. Is there any reason n=
ot to do

this?

=C2=A0>

=C2=A0>

=C2=A0> Just the usual: are the benefits higher than the added complexit=
y.

Here, depending how it's done, the added complexity should be fairly lo=
w

though.



The complexity of having to handle that over signalling and the need to

implement it on every sig protocol that ever dares to use ICE is

arguably much higher than that of an extra attribute





Actually I meant the complexity of implementing something like this, and wh=
y to do/not to do this (in any way).






=C2=A0> For the benefits, currently with SIP you are allowed to release =
the

not selected candidate resources after 3 seconds from concluding ICE

(http://tools.ietf.org/html/rfc5245#section-8.3.1).



And that is the whole point because currently with aggressive nomination
you simply don't know exactly when ICE has concluded.





So if you assume aggressive ICE has concluded after you've got your fir=
st USE-CANDIDATE checks done (as the text currently says), and you stop doi=
ng keep-alives on all except the selected candidate pair and let your relay=
ed and reflexive candidates die away. You still have some time to switch be=
tween the candidates since the candidates are still alive for at least some=
 (tens of?) seconds. Isn't that OK?






Or did you have some other kind of resources in mind?





Cheers,

Ari



_______________________________________________

mmusic mailing list

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





--20cf302ef544a1af7504fee1c51a--


From nobody Wed Jul 23 14:46:43 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD21A016F for ; Wed, 23 Jul 2014 14:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcibSlje_-Wn for ; Wed, 23 Jul 2014 14:46:39 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448D31A0172 for ; Wed, 23 Jul 2014 14:46:39 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-74-53d02d3d07a3
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0A.E5.19155.D3D20D35; Wed, 23 Jul 2014 23:46:37 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Wed, 23 Jul 2014 23:46:36 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id CB0EE11029A; Thu, 24 Jul 2014 00:46:36 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 85113589CC;	Thu, 24 Jul 2014 00:46:48 +0300 (EEST)
Received: from dhcp-bcda.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8E54E589C9;	Thu, 24 Jul 2014 00:46:47 +0300 (EEST)
Message-ID: <53D02D3B.4000701@ericsson.com>
Date: Wed, 23 Jul 2014 17:46:35 -0400
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja6t7oVgg0nTxCzW7JzAYrF1qpDF 1OWPWRyYPRZsKvVYsuQnk8f/N4EBzFFcNimpOZllqUX6dglcGWvevGIr+MRecfvLHOYGxqVs XYwcHBICJhJ9neldjJxAppjEhXvrgcJcHEICRxklDk14yAaSEBLYwChxsM0AIrGXUeLFhg+M EM46Rolvt68wQlQBOZveGIHYvALaEs+Xn2UGsVkEVCXWXzoKVsMmYCux+tVNFhBbVCBZYs3W SewQ9YISJ2c+AYuLCKhJPJy1ixXEZhawlDi58itYXFjARmJF8zpmiF3rmSS+tSWD2JwCgRIr bu9jgai3kFj85iA7hC0vsf3tHGaI19Qkrp7bBNWrKnH13yvGCYyis5CsnoWkfRaS9gWMzKsY RYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAuPj4JbfqjsYL79xPMQowMGoxMP7YP/5YCHWxLLi ytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKju7+UbrZT7/PxW17cx z+3Sd0hmOPUtcYz6p73HZ8ElY42UK22P+Z7ZG2oYT0sI7Ml8sjiu+97c7f27O+v/zGx+47Q5 1HfhtuSP3Z9/SzN4TvhlZLVX/HXaP+M7facrc46lmO8MdtKfk/JcdWKa6CPG60lvIj6zqxWp vSx8r/hkfsf0Xd4n3JVYijMSDbWYi4oTAQrKUnpwAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UDvWgVEySJ-8q97aHJdDQdq7gEQ
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 21:46:41 -0000

On 7/23/14 3:58 PM, Justin Uberti wrote:
> The issue isn't just that you don't know when aggressive nomination has
> ended - it's that the CONTROLLING side can't truly express its desires
> to the CONTROLLED side, including use of some dynamic metric (e.g. RTT)
> to choose the active candidate pair instead of PRIORITY.
>
> With regular nomination, the CONTROLLING side has this option, but not
> with aggressive nomination. This is the core issue that I want to fix,
> and I would definitely want to fix this in the media plane using
> something like REALLY-USE-CANDIDATE, since it may change fairly quickly
> as RTT values stabilize.
>
> There are other things that we can try to fix at the same time, e.g. the
> CONTROLLED side can keep other candidate pairs warm and switch to them
> at any time (via another REALLY-USE-CANDIDATE).

OK, that's an interesting case. But if you want to change candidates 
over time, this actually sounds a bit like mobility with ICE?


Cheers,
Ari



From nobody Wed Jul 23 14:51:46 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5871B28ED for ; Wed, 23 Jul 2014 14:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level: 
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5bxc5lN5cVK for ; Wed, 23 Jul 2014 14:51:43 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3734E1B2833 for ; Wed, 23 Jul 2014 14:51:43 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so3339670vcb.40 for ; Wed, 23 Jul 2014 14:51:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBi7+B0q6cJRpsBKh6i0Xgz2YqnTT9zeHcoCl4XG6Og=; b=FPTKSfUJYXy1NbOrRQzQZEyo2+JqxIkrq/6vV5XPQs/cs89bc/fPoaqAv/SAedI7BD 6gV/fyaERYa2eIC6AcWN5UqYe7bC+XgAQ+JbWFwtf6yz1/XcsL6BigqfkpUSBW+EQHeM 5c/aP7mKd2TgQalwYzqgRUPlmoLUgU9/ilw2iVRONsFCytMPTU6eNDCpbzicZ+KjqeVq 1Sfj6OFyi+KSew+UBWdamm4yGhQ+v3ATSAQqm0PhBTWBDH1jDpyimKn3s4pSdar+F6qA 006jVcFy+QsYiMPK35yyJkNiJDRLqg7srne/mMYw9Ojtmfs3WExZ8v+h/4BmnV53pHoR N3JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qBi7+B0q6cJRpsBKh6i0Xgz2YqnTT9zeHcoCl4XG6Og=; b=fpHlMC+GB5swC/7xEF4AxgMePH80c5QOBmsb50MSj/wNofctfn1W03UPwN0LN53zUe Ohyi9+f3joavRLPs6GzgSCeppW57YksFll8/X42nhtSvG52I+tOofspgOyqvtCIj6B6J wQ7B/v6kaJzdo/A4/BauNBwrZzMEpZLCXV32ckP55ebRoYX6io3AC6V/mFqKqga8FbLQ 8f6ereRp0H9zr/JIIY4lkrIkmQW0NpFQMPdNoQ/1XjaEs192Pf+LvVcMLqp6FCCavAZH ez0C99e1wz7w1NGDvYGr/mzIXYhwnKLW9NrYo7X/1/uoAxDKjhoD5guwVWclv+OFpohx KReA==
X-Gm-Message-State: ALoCoQkk4YtOYlx0Qj0/7pSpo8fi4px+EbG5w2JfkSjQip6hTq5YPfvMOzZivshdhqXDP8bLGY0l
MIME-Version: 1.0
X-Received: by 10.52.135.133 with SMTP id ps5mr5414702vdb.33.1406152302113; Wed, 23 Jul 2014 14:51:42 -0700 (PDT)
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 14:51:40 -0700 (PDT)
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 14:51:40 -0700 (PDT)
In-Reply-To: <53D02D3B.4000701@ericsson.com>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com>  <53D02D3B.4000701@ericsson.com>
Date: Wed, 23 Jul 2014 17:51:40 -0400
Message-ID: 
From: Justin Uberti 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: multipart/alternative; boundary=bcaec51a70a277dc8b04fee35898
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/U5JcjitvgomUtfXNB4EckkzUVo0
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 21:51:44 -0000

--bcaec51a70a277dc8b04fee35898
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That part is separable from the basic need for dynamic prioritization.

I will look at the mobility draft to see how these concepts relate.
On Jul 23, 2014 5:46 PM, "Ari Ker=C3=A4nen"  wrot=
e:

> On 7/23/14 3:58 PM, Justin Uberti wrote:
>
>> The issue isn't just that you don't know when aggressive nomination has
>> ended - it's that the CONTROLLING side can't truly express its desires
>> to the CONTROLLED side, including use of some dynamic metric (e.g. RTT)
>> to choose the active candidate pair instead of PRIORITY.
>>
>> With regular nomination, the CONTROLLING side has this option, but not
>> with aggressive nomination. This is the core issue that I want to fix,
>> and I would definitely want to fix this in the media plane using
>> something like REALLY-USE-CANDIDATE, since it may change fairly quickly
>> as RTT values stabilize.
>>
>> There are other things that we can try to fix at the same time, e.g. the
>> CONTROLLED side can keep other candidate pairs warm and switch to them
>> at any time (via another REALLY-USE-CANDIDATE).
>>
>
> OK, that's an interesting case. But if you want to change candidates over
> time, this actually sounds a bit like mobility with ICE?
>
>
> Cheers,
> Ari
>
>
>

--bcaec51a70a277dc8b04fee35898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


That part is separable from the basic need for dynamic prior=
itization. 


I will look at the mobility draft to see how these concepts =
relate.


On Jul 23, 2014 5:46 PM, "Ari Ker=C3=A4nen&=
quot; <ari.keranen@ericsson.=
com> wrote:

On 7/23/14 3:58 PM, Justin Uberti wrote:



The issue isn't just that you don't know when aggressive nomination=
 has

ended - it's that the CONTROLLING side can't truly express its desi=
res

to the CONTROLLED side, including use of some dynamic metric (e.g. RTT)

to choose the active candidate pair instead of PRIORITY.



With regular nomination, the CONTROLLING side has this option, but not

with aggressive nomination. This is the core issue that I want to fix,

and I would definitely want to fix this in the media plane using

something like REALLY-USE-CANDIDATE, since it may change fairly quickly

as RTT values stabilize.



There are other things that we can try to fix at the same time, e.g. the
CONTROLLED side can keep other candidate pairs warm and switch to them

at any time (via another REALLY-USE-CANDIDATE).





OK, that's an interesting case. But if you want to change candidates ov=
er time, this actually sounds a bit like mobility with ICE?





Cheers,

Ari








--bcaec51a70a277dc8b04fee35898--


From nobody Wed Jul 23 15:00:34 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF21B28B2 for ; Wed, 23 Jul 2014 15:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TVLagRMPkfx for ; Wed, 23 Jul 2014 15:00:29 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397701B27C9 for ; Wed, 23 Jul 2014 15:00:27 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id bs8so8557483wib.15 for ; Wed, 23 Jul 2014 15:00:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=acX6ERn7gX36o5GLE0QBtS2ZTvtIhXkFNPItOleYZso=; b=EEQyW+f7RsyD5p1eI2Drw2TGG0tehSWWthVTrccOg0El/GSFaQFtEpYdheflPrK8Gc YQ6OAqUOGMoXN7hkKhXISDiP+4DMX4R7VEA9DS9HXRCGzD3FobkJ9/wzNaaRetEWO0wn C+zuZf8vyEtBnlGi6K3eoCTjVAPrwKIhRZhFTCDdRib/FcwxbrPLaVOCHiXAO30cSyEn 8roRBt4f1oxzNqtuiX2424NzZlDwc7xq0fyJlkGHCEhiov5A0WvIppzq2GUorwUY7zvZ MpxWojiaFiNqaoYQo/ox63QoJ13Jr1Ov4eJjDeA8n3Vzn07ln2+nhGQTh/uEsq4Pl54P 86zQ==
X-Gm-Message-State: ALoCoQnGGDHEUVdCsaLPHNqBZpsKKlEqYh6MUPXT1bP16Stg0PxHaJUxqGqcw/YO8D4iaaQAZP4W
X-Received: by 10.180.221.108 with SMTP id qd12mr6816382wic.83.1406152826663;  Wed, 23 Jul 2014 15:00:26 -0700 (PDT)
Received: from dhcp-97e2.meeting.ietf.org (dhcp-97e2.meeting.ietf.org. [31.133.151.226]) by mx.google.com with ESMTPSA id gd13sm14397022wic.6.2014.07.23.15.00.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 15:00:25 -0700 (PDT)
Message-ID: <53D03077.5080103@jitsi.org>
Date: Wed, 23 Jul 2014 18:00:23 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
References: <53CD7C04.8070106@jitsi.org>	<53CE7D0A.4030406@ericsson.com>	<53CE7DDD.5030406@jitsi.org>	<53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com>
In-Reply-To: <53CFE322.5000508@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/u1SGa6YMvTbQFktlTxxcHZx45T0
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 22:00:32 -0000

On 23.07.14, 12:30, Ari Keränen wrote:
> On 7/22/14 7:12 PM, Emil Ivov wrote:
>>
>> On 22 Jul 2014 6:11 PM, "Ari Keränen" > > wrote:
>>  >
>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>>  >>
>>  >> On 22.07.14, 11:02, Ari Keränen wrote:
>>  >>>
>>  >>> Hi,
>>  >>>
>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>  >>>>
>>  >>>> In London we mentioned the option of adding a new attribute that,
>> during
>>  >>>> aggressive nomination, the controlling agent can use to notify its
>> peer
>>  >>>> that ICE processing is over and no more changes are going to be
>>  >>>> attempted. This way controlled agents will no they can now release
>>  >>>> resources.
>>  >>>>
>>  >>>> This could either be a new attribute (e.g.,
>> USE-CANDIDATE-CONFIRMED) or,
>>  >>>> as Justin suggested in an off-list discussion, we could have the
>>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
>> nomination
>>  >>>> converges.
>>  >>>
>>  >>>
>>  >>> Did you consider using the updated offer to indicate that you're
>> really
>>  >>> done? This would require that you always send it (i.e., a slight
>>  >>> modification to 5245), but that's something that has been already
>>  >>> proposed to be updated for other purposes.
>>  >>
>>  >>
>>  >> The point is to have all that information without involving
>> signalling,
>>  >> as is the case with regular nomination.
>>  >>
>>  >> Let me ask the question the other way. Is there any reason not to do
>> this?
>>  >
>>  >
>>  > Just the usual: are the benefits higher than the added complexity.
>> Here, depending how it's done, the added complexity should be fairly low
>> though.
>>
>> The complexity of having to handle that over signalling and the need to
>> implement it on every sig protocol that ever dares to use ICE is
>> arguably much higher than that of an extra attribute
>
> Actually I meant the complexity of implementing something like this, and
> why to do/not to do this (in any way).

Yes, so did I. We are talking about the "complexity" of adding one ICE 
attribute as opposed to intertwining the states of ICE and signalling 
and making them dependent on each other.

>>  > For the benefits, currently with SIP you are allowed to release the
>> not selected candidate resources after 3 seconds from concluding ICE
>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>
>> And that is the whole point because currently with aggressive nomination
>> you simply don't know exactly when ICE has concluded.
>
> So if you assume aggressive ICE has concluded after you've got your
> first USE-CANDIDATE checks done (as the text currently says), and you
> stop doing keep-alives on all except the selected candidate pair and let
> your relayed and reflexive candidates die away. You still have some time
> to switch between the candidates since the candidates are still alive
> for at least some (tens of?) seconds. Isn't that OK?

If I assume ICE has concluded after my *first* USE-CANDIDATE and let 
everything die away then, with aggressive nomination, how am I ever 
going to get a second?

Emil

-- 
https://jitsi.org


From nobody Wed Jul 23 15:21:54 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1AC1ABD19 for ; Wed, 23 Jul 2014 15:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT5uNh-WVner for ; Wed, 23 Jul 2014 15:21:49 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332E11A040B for ; Wed, 23 Jul 2014 15:21:49 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-30-53d0357a482a
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.E7.19155.A7530D35; Thu, 24 Jul 2014 00:21:47 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.174.1; Thu, 24 Jul 2014 00:21:46 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id A517311029C; Thu, 24 Jul 2014 01:21:46 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 66D47589CC;	Thu, 24 Jul 2014 01:21:58 +0300 (EEST)
Received: from dhcp-bcda.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B7E49589C9;	Thu, 24 Jul 2014 01:21:57 +0300 (EEST)
Message-ID: <53D03578.5020301@ericsson.com>
Date: Wed, 23 Jul 2014 18:21:44 -0400
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Emil Ivov 
References: <53CD7C04.8070106@jitsi.org>	<53CE7D0A.4030406@ericsson.com>	<53CE7DDD.5030406@jitsi.org>	<53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org>
In-Reply-To: <53D03077.5080103@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+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW616YVgg8mn+CzW7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlTHt3Cn2gh8yFZ/mtbA1MP4R62Lk5JAQMJG4 2v+fGcIWk7hwbz0biC0kcJRR4sfiAgh7A6PE098hXYxcQPZeRompXxYxQSTWMUrsPl0CkQCy 502awd7FyMHBK6At8fFQOojJIqAq0TVBGqScTcBWYvWrmywgtqhAssSarZPYQWxeAUGJkzOf gMVFBOQlutsgxjMLyEjMONsIZgsL2EisaF7HDLGqnUli1uMZrCAJTgFNiSs7PrNCNFhILH5z kB3Clpdo3job6jE1iavnNjFD3KwqcfXfK8YJjKKzkOyehaR9FpL2BYzMqxhFi1OLk3LTjYz1 Uosyk4uL8/P08lJLNjECo+Hglt+qOxgvv3E8xCjAwajEw/tg//lgIdbEsuLK3EOM0hwsSuK8 C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6Pr3moe8eCfvkRXu1okdh9qOZ/zeluWz MbZlUzbb0WgRo7fJL/M0WBQTJ1rJ7bl4c6LuXNGZ2zumz/v5dvvG4pSYiJueTTaPzrdrucyZ 5O3ItSZ6he3UN/PU9pabzks/xm+Xxjp3miSDyQHF7ogKfeGggqleSxsMzQpkJz69c/iU+ZbV G3m5lFiKMxINtZiLihMBdY5WHmcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/B_2ogTQjx8m2xP7ROyHCnWVvRDs
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 22:21:51 -0000

On 7/23/14 6:00 PM, Emil Ivov wrote:
>
>
> On 23.07.14, 12:30, Ari Keränen wrote:
>> On 7/22/14 7:12 PM, Emil Ivov wrote:
>>>
>>> On 22 Jul 2014 6:11 PM, "Ari Keränen" >> > wrote:
>>>  >
>>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>>>  >>
>>>  >> On 22.07.14, 11:02, Ari Keränen wrote:
>>>  >>>
>>>  >>> Hi,
>>>  >>>
>>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>>  >>>>
>>>  >>>> In London we mentioned the option of adding a new attribute that,
>>> during
>>>  >>>> aggressive nomination, the controlling agent can use to notify its
>>> peer
>>>  >>>> that ICE processing is over and no more changes are going to be
>>>  >>>> attempted. This way controlled agents will no they can now release
>>>  >>>> resources.
>>>  >>>>
>>>  >>>> This could either be a new attribute (e.g.,
>>> USE-CANDIDATE-CONFIRMED) or,
>>>  >>>> as Justin suggested in an off-list discussion, we could have the
>>>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
>>> nomination
>>>  >>>> converges.
>>>  >>>
>>>  >>>
>>>  >>> Did you consider using the updated offer to indicate that you're
>>> really
>>>  >>> done? This would require that you always send it (i.e., a slight
>>>  >>> modification to 5245), but that's something that has been already
>>>  >>> proposed to be updated for other purposes.
>>>  >>
>>>  >>
>>>  >> The point is to have all that information without involving
>>> signalling,
>>>  >> as is the case with regular nomination.
>>>  >>
>>>  >> Let me ask the question the other way. Is there any reason not to do
>>> this?
>>>  >
>>>  >
>>>  > Just the usual: are the benefits higher than the added complexity.
>>> Here, depending how it's done, the added complexity should be fairly low
>>> though.
>>>
>>> The complexity of having to handle that over signalling and the need to
>>> implement it on every sig protocol that ever dares to use ICE is
>>> arguably much higher than that of an extra attribute
>>
>> Actually I meant the complexity of implementing something like this, and
>> why to do/not to do this (in any way).
>
> Yes, so did I. We are talking about the "complexity" of adding one ICE
> attribute as opposed to intertwining the states of ICE and signalling
> and making them dependent on each other.
>
>>>  > For the benefits, currently with SIP you are allowed to release the
>>> not selected candidate resources after 3 seconds from concluding ICE
>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>>
>>> And that is the whole point because currently with aggressive nomination
>>> you simply don't know exactly when ICE has concluded.
>>
>> So if you assume aggressive ICE has concluded after you've got your
>> first USE-CANDIDATE checks done (as the text currently says), and you
>> stop doing keep-alives on all except the selected candidate pair and let
>> your relayed and reflexive candidates die away. You still have some time
>> to switch between the candidates since the candidates are still alive
>> for at least some (tens of?) seconds. Isn't that OK?
>
> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
> everything die away then, with aggressive nomination, how am I ever
> going to get a second?

It takes a while before your server reflexive and relayed candidates die 
out so you have some time to get more checks through. Of course you 
shouldn't close the local sockets immediately. However, if you want to 
do that considerably (> tens of second) later, and perhaps multiple 
times, it may get more complicated (something like mobility with ICE).


Cheers,
Ari


From nobody Wed Jul 23 15:28:11 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12F51B298E for ; Wed, 23 Jul 2014 15:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KutIFx48zX7l for ; Wed, 23 Jul 2014 15:28:08 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007641A0322 for ; Wed, 23 Jul 2014 15:28:07 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t60so1895088wes.20 for ; Wed, 23 Jul 2014 15:28:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9E5UX6gXkxW8aEDVSQLSxhWYZU8GtPyGAwacWVGax/8=; b=hv1Vya1TVP6Cg19+V+Jj7XshfZ5e0+9kIHRQsY3f7yTryqqOMUAil/vBY4nu6AQBQp 78ppzJZV6xnC/C2nAKHDVqFAsfVjBlhC9wcC1aI+QIIusir9TyuG7+/DCZpJDv+iqBKA 04qWQicjiExZx2W3ahlA/LsZ917bFWu8hZ5Jn7gkkBRnSSQPNqidEcIPgVs3mV5oCkgA FYLm+oJR99gJp5Ij8VUdGqn42Pnh0ooTpo+LtEFm9fIXY1C76o3V5vhFNQ4DvZPNp2IZ uzb6l91qeyFhi3/dSbu59x9Kr0w4NrfJ8vS0Ze6r65sF+0QC6szFNOWihLot36LooGqG lRjw==
X-Gm-Message-State: ALoCoQmDYPeFs1Id4D0rqLK1E/d6jh6Y43HuudHhr+/NU57WP+mvbllNZR3G6CNHJJSDs+e+cdG/
X-Received: by 10.194.158.226 with SMTP id wx2mr6005456wjb.107.1406154486557;  Wed, 23 Jul 2014 15:28:06 -0700 (PDT)
Received: from dhcp-97e2.meeting.ietf.org (dhcp-97e2.meeting.ietf.org. [31.133.151.226]) by mx.google.com with ESMTPSA id fw4sm14353763wib.19.2014.07.23.15.28.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 15:28:05 -0700 (PDT)
Message-ID: <53D036F1.8070504@jitsi.org>
Date: Wed, 23 Jul 2014 18:28:01 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
References: <53CD7C04.8070106@jitsi.org>	<53CE7D0A.4030406@ericsson.com>	<53CE7DDD.5030406@jitsi.org>	<53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com>
In-Reply-To: <53D03578.5020301@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TEqFL0P-GiI5dfXudOTkDE7Y7xk
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 22:28:10 -0000

On 23.07.14, 18:21, Ari Keränen wrote:
> On 7/23/14 6:00 PM, Emil Ivov wrote:
>>
>>
>> On 23.07.14, 12:30, Ari Keränen wrote:
>>> On 7/22/14 7:12 PM, Emil Ivov wrote:
>>>>
>>>> On 22 Jul 2014 6:11 PM, "Ari Keränen" >>> > wrote:
>>>>  >
>>>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>>>>  >>
>>>>  >> On 22.07.14, 11:02, Ari Keränen wrote:
>>>>  >>>
>>>>  >>> Hi,
>>>>  >>>
>>>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>>>  >>>>
>>>>  >>>> In London we mentioned the option of adding a new attribute that,
>>>> during
>>>>  >>>> aggressive nomination, the controlling agent can use to notify
>>>> its
>>>> peer
>>>>  >>>> that ICE processing is over and no more changes are going to be
>>>>  >>>> attempted. This way controlled agents will no they can now
>>>> release
>>>>  >>>> resources.
>>>>  >>>>
>>>>  >>>> This could either be a new attribute (e.g.,
>>>> USE-CANDIDATE-CONFIRMED) or,
>>>>  >>>> as Justin suggested in an off-list discussion, we could have the
>>>>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
>>>> nomination
>>>>  >>>> converges.
>>>>  >>>
>>>>  >>>
>>>>  >>> Did you consider using the updated offer to indicate that you're
>>>> really
>>>>  >>> done? This would require that you always send it (i.e., a slight
>>>>  >>> modification to 5245), but that's something that has been already
>>>>  >>> proposed to be updated for other purposes.
>>>>  >>
>>>>  >>
>>>>  >> The point is to have all that information without involving
>>>> signalling,
>>>>  >> as is the case with regular nomination.
>>>>  >>
>>>>  >> Let me ask the question the other way. Is there any reason not
>>>> to do
>>>> this?
>>>>  >
>>>>  >
>>>>  > Just the usual: are the benefits higher than the added complexity.
>>>> Here, depending how it's done, the added complexity should be fairly
>>>> low
>>>> though.
>>>>
>>>> The complexity of having to handle that over signalling and the need to
>>>> implement it on every sig protocol that ever dares to use ICE is
>>>> arguably much higher than that of an extra attribute
>>>
>>> Actually I meant the complexity of implementing something like this, and
>>> why to do/not to do this (in any way).
>>
>> Yes, so did I. We are talking about the "complexity" of adding one ICE
>> attribute as opposed to intertwining the states of ICE and signalling
>> and making them dependent on each other.
>>
>>>>  > For the benefits, currently with SIP you are allowed to release the
>>>> not selected candidate resources after 3 seconds from concluding ICE
>>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>>>
>>>> And that is the whole point because currently with aggressive
>>>> nomination
>>>> you simply don't know exactly when ICE has concluded.
>>>
>>> So if you assume aggressive ICE has concluded after you've got your
>>> first USE-CANDIDATE checks done (as the text currently says), and you
>>> stop doing keep-alives on all except the selected candidate pair and let
>>> your relayed and reflexive candidates die away. You still have some time
>>> to switch between the candidates since the candidates are still alive
>>> for at least some (tens of?) seconds. Isn't that OK?
>>
>> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
>> everything die away then, with aggressive nomination, how am I ever
>> going to get a second?
>
> It takes a while before your server reflexive and relayed candidates die
> out so you have some time to get more checks through. Of course you
> shouldn't close the local sockets immediately. However, if you want to
> do that considerably (> tens of second) later, and perhaps multiple
> times, it may get more complicated (something like mobility with ICE).

These are exactly the kinds of hacks that implementations try to do 
today. Magic timers and proprietary logic. This is exactly what I was 
hoping we could remove by replicating the same feature in aggressive 
that we already have for regular nomination. As Justin put it:  giving a 
way to the controlling agent to communicate it's selection to the 
controlled.

It simply doesn't make sense not to have it and it would simplify things 
a lot so the argument "it would add complexity" doesn't really hold.

Emil

-- 
https://jitsi.org


From nobody Wed Jul 23 15:42:54 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8151B29E8 for ; Wed, 23 Jul 2014 15:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rg7RPaBqywM for ; Wed, 23 Jul 2014 15:42:51 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AC41B29E3 for ; Wed, 23 Jul 2014 15:42:51 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so1815549wgh.23 for ; Wed, 23 Jul 2014 15:42:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L5h0EhuMNU9+NT//OWqh20BgjRSv/SMVy9ENL37IwJo=; b=gp8x17kKen/yKdUop6bpd4x1A5Dsf383JGZTPaSI2ICaIdo7FPF/4NVG8Ru3wlrNGX JsxQVS12z79Dqm8+GL1q/fUblHJxYZHLwHKY/vRVS016TXUoI7LUH6muh7EjhA3zXibV YzEDXHxco+Tfu94Ri8Jqft8vUUfo5DScOz+jZuB9g9R7yX+PIZpyZ4+YHlzFUozUuTOZ amYeIgoSD7uUbkoQ7jFMpf0z7jltJyx+blzE79NB2v5xXz3VMn8NK/AsgiX2SVDdSguP HsEh3iAaU/dA98y5BnsHDsXcxnW0pRpKUqpR0yaVtBJLX4wCZYYiNrmhEZoUIW/CW6zF fTrA==
X-Gm-Message-State: ALoCoQmVUgiFUl2dDuCgZxR9+ke2qkSKqSNn+r3DuM6D/oSDR7gV/X3Q5hU0WBgk88jUHQVZJDqu
X-Received: by 10.194.205.132 with SMTP id lg4mr6484622wjc.80.1406155370090; Wed, 23 Jul 2014 15:42:50 -0700 (PDT)
Received: from dhcp-97e2.meeting.ietf.org (dhcp-97e2.meeting.ietf.org. [31.133.151.226]) by mx.google.com with ESMTPSA id o12sm14781964wiw.5.2014.07.23.15.42.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 15:42:48 -0700 (PDT)
Message-ID: <53D03A64.303@jitsi.org>
Date: Wed, 23 Jul 2014 18:42:44 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti ,  Martin Thomson 
References:   <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org>   <53C02A45.40703@jitsi.org>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/F-sjocx_VFpigL6VuU4pXurFcw4
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Dummy ports
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 22:42:53 -0000

On 23.07.14, 15:49, Justin Uberti wrote:
> The JSEP authors discussed a bit more and agreed that using port 9s on
> all m= lines when doing full trickle is the right solution to this problem.

Great news! Then we are pretty much ready for WGLC.

Emil

>
> On Fri, Jul 11, 2014 at 2:34 PM, Martin Thomson
> > wrote:
>
>     On 11 July 2014 11:17, Emil Ivov      > wrote:
>      >
>      >
>      > On 11.07.14, 19:51, Martin Thomson wrote:
>      >>
>      >> On 11 July 2014 09:33, Justin Uberti      > wrote:
>      >>>
>      >>> a) We require unique 'dummy' ports in the initial trickle offer.
>      >>> b) We allow use of the same dummy port (9) in the initial
>     trickle offer.
>      >>> (This is what Chrome does, although it currently uses port 1).
>      >>>
>      >>> We had been leaning towards (a) based on the legacy equipment case
>      >>> mentioned
>      >>> above. However, if nobody can provide details on this case, I
>     agree we
>      >>> should end up with (b).
>      >>
>      >>
>      >> As a general rule, if accommodating legacy equipment is particularly
>      >> hard for us here, then we should leave the fixups needed for that
>      >> legacy equipment to application code.  This seems like a good
>      >> candidate for that.  It's not like non-9 ports will work with all
>      >> legacy equipment anyway.
>      >
>      > Also note that, in the case of trickle, port 9s would only occur
>     if the
>      > offerer expects (knows) it would be supported. In other cases it
>     would just
>      > do half trickle and the problem wouldn't exist.
>
>     Yeah, that's even more reason to do the right thing (as opposed to the
>     safe thing).
>
>

-- 
https://jitsi.org


From nobody Wed Jul 23 16:41:05 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8241B2828 for ; Wed, 23 Jul 2014 16:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEmoEu6pU5wg for ; Wed, 23 Jul 2014 16:41:02 -0700 (PDT)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAB81A02A2 for ; Wed, 23 Jul 2014 16:41:02 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id w8so2124373qac.30 for ; Wed, 23 Jul 2014 16:41:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=zC0bK3GvWaHPVnVIrYtW7wI8I1ZMxoJnEGTUVX6wfio=; b=d/7P5Rna0T1NiJziHKRzmVFx9dBjlmZqFe9ESwI1YhkTLmB0++cYz5qFfelORUWpXo wA+Enks4syodhcUdttKQGhuOGNOBSarzI5snxzcfHIiQAyPgpKrfx7NWeCBzrBshUnZS dg4U9hLJteuV7o/sBRsMZu8H5AkcWPb8JK0RYBg0NA/ZTi6jsiiXmxU1H4wjjtetXNja iFTAAJrVaHCeR/K/2+ao+vzcg2GM7oV0XM0lkEDRwC8KYGiASvmuF6RjC1woOsK90YpO FyI9tOyGxRmNEGzHLqQfi2wEfrmyA0xfy1MzEuNbF5Wek9OL/alKj2vM+XSMrsatzKyD BEig==
X-Gm-Message-State: ALoCoQlxcAq5RwPM3zsWQh5hjiOwew73YR6231he7GFwuSYIZHsfemTHoeymKpq+BPvsT/N5+Pb6
X-Received: by 10.140.30.73 with SMTP id c67mr7753756qgc.16.1406158861314; Wed, 23 Jul 2014 16:41:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Wed, 23 Jul 2014 16:40:41 -0700 (PDT)
In-Reply-To: <53CE7D0A.4030406@ericsson.com>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Jul 2014 01:40:41 +0200
Message-ID: 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_8ogH2IaraRXW9_wnO-Mw9u5Pu4
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 23:41:03 -0000

2014-07-22 17:02 GMT+02:00 Ari Ker=C3=A4nen :
> Did you consider using the updated offer to indicate that you're really
> done? This would require that you always send it (i.e., a slight
> modification to 5245), but that's something that has been already propose=
d
> to be updated for other purposes.

Do you mean sending the "updated SDP offer" after ICE is paired? No
please. Relying on that is a bad idea. STUN is a network protocol and
should not rely on a different signaling protocol (SIP+SDP or XXX+SDP)
to indicate nothing. The SDP (or whatever is used) is just needed to
indicate ICE parameters out of band.

And for sure, WebRTC browsers ignore at 100% the "update SDP offer
once ICE is paired".

Regards.


--=20
I=C3=B1aki Baz Castillo



From nobody Wed Jul 23 17:43:16 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9DE1A017A for ; Wed, 23 Jul 2014 17:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5g1Yjveb69M for ; Wed, 23 Jul 2014 17:43:07 -0700 (PDT)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.28]) by ietfa.amsl.com (Postfix) with ESMTP id D0BE21A0115 for ; Wed, 23 Jul 2014 17:43:07 -0700 (PDT)
Received: from userPC (unknown [122.178.241.128]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 8CFE48691D8; Thu, 24 Jul 2014 00:43:02 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406162586; bh=V1b3CvRRo0a6MEJV/JU5K7B/rtmrHvo3/rx+qkBSUS0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KOWHxwdpXwZ3cd0zSkG+sEqe2bkZINzW2megzKUYl0IzZxkLYhHxaksswqjwvGkZn aKWdTIikUU23MflD1SkzdJXOfLiKjEXIxCly+lLbRwizlKFxvjELmFTg968tZWkTYn MvW/6CnGzUDQLg45v99MkX7KyPrdw200NhMSbr1E=
From: "Parthasarathi R" 
To: "'Emil Ivov'" , =?UTF-8?Q?'Ari_Ker=C3=A4nen'?= 
References: <53CD7C04.8070106@jitsi.org>	<53CE7D0A.4030406@ericsson.com>	<53CE7DDD.5030406@jitsi.org>	<53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org>
In-Reply-To: <53D036F1.8070504@jitsi.org>
Date: Thu, 24 Jul 2014 06:12:53 +0530
Message-ID: <011401cfa6d8$378084f0$a6818ed0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac+mxWpY13Fd/ZlBQcufylPJlfn5tgAEqf4Q
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020209.53D05698.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/JpzY734U3HafYX8BeNvCGud2o2A
Cc: 'mmusic' 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 00:43:09 -0000

Hi Emil,

It is better to handle through signaling as it provides to flexibility =
in the application (like forking usecase). In case of pushing the =
intelligence within ICE will just move the portion of the signaling to =
ICE in case the application is required to know.

Please note that the signaling protocol which choose not to indicate it =
based on the specific signaling protocol design.

Thanks
Partha

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Emil Ivov
> Sent: Thursday, July 24, 2014 3:58 AM
> To: Ari Ker=C3=A4nen
> Cc: mmusic
> Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
>=20
>=20
>=20
> On 23.07.14, 18:21, Ari Ker=C3=A4nen wrote:
> > On 7/23/14 6:00 PM, Emil Ivov wrote:
> >>
> >>
> >> On 23.07.14, 12:30, Ari Ker=C3=A4nen wrote:
> >>> On 7/22/14 7:12 PM, Emil Ivov wrote:
> >>>>
> >>>> On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen" =
 >>>> > wrote:
> >>>>  >
> >>>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
> >>>>  >>
> >>>>  >> On 22.07.14, 11:02, Ari Ker=C3=A4nen wrote:
> >>>>  >>>
> >>>>  >>> Hi,
> >>>>  >>>
> >>>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
> >>>>  >>>>
> >>>>  >>>> In London we mentioned the option of adding a new attribute
> that,
> >>>> during
> >>>>  >>>> aggressive nomination, the controlling agent can use to
> notify
> >>>> its
> >>>> peer
> >>>>  >>>> that ICE processing is over and no more changes are going =
to
> be
> >>>>  >>>> attempted. This way controlled agents will no they can now
> >>>> release
> >>>>  >>>> resources.
> >>>>  >>>>
> >>>>  >>>> This could either be a new attribute (e.g.,
> >>>> USE-CANDIDATE-CONFIRMED) or,
> >>>>  >>>> as Justin suggested in an off-list discussion, we could =
have
> the
> >>>>  >>>> controlling agent send a second USE-CANDIDATE once
> aggressive
> >>>> nomination
> >>>>  >>>> converges.
> >>>>  >>>
> >>>>  >>>
> >>>>  >>> Did you consider using the updated offer to indicate that
> you're
> >>>> really
> >>>>  >>> done? This would require that you always send it (i.e., a
> slight
> >>>>  >>> modification to 5245), but that's something that has been
> already
> >>>>  >>> proposed to be updated for other purposes.
> >>>>  >>
> >>>>  >>
> >>>>  >> The point is to have all that information without involving
> >>>> signalling,
> >>>>  >> as is the case with regular nomination.
> >>>>  >>
> >>>>  >> Let me ask the question the other way. Is there any reason =
not
> >>>> to do
> >>>> this?
> >>>>  >
> >>>>  >
> >>>>  > Just the usual: are the benefits higher than the added
> complexity.
> >>>> Here, depending how it's done, the added complexity should be
> fairly
> >>>> low
> >>>> though.
> >>>>
> >>>> The complexity of having to handle that over signalling and the
> need to
> >>>> implement it on every sig protocol that ever dares to use ICE is
> >>>> arguably much higher than that of an extra attribute
> >>>
> >>> Actually I meant the complexity of implementing something like
> this, and
> >>> why to do/not to do this (in any way).
> >>
> >> Yes, so did I. We are talking about the "complexity" of adding one
> ICE
> >> attribute as opposed to intertwining the states of ICE and
> signalling
> >> and making them dependent on each other.
> >>
> >>>>  > For the benefits, currently with SIP you are allowed to =
release
> the
> >>>> not selected candidate resources after 3 seconds from concluding
> ICE
> >>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
> >>>>
> >>>> And that is the whole point because currently with aggressive
> >>>> nomination
> >>>> you simply don't know exactly when ICE has concluded.
> >>>
> >>> So if you assume aggressive ICE has concluded after you've got =
your
> >>> first USE-CANDIDATE checks done (as the text currently says), and
> you
> >>> stop doing keep-alives on all except the selected candidate pair
> and let
> >>> your relayed and reflexive candidates die away. You still have =
some
> time
> >>> to switch between the candidates since the candidates are still
> alive
> >>> for at least some (tens of?) seconds. Isn't that OK?
> >>
> >> If I assume ICE has concluded after my *first* USE-CANDIDATE and =
let
> >> everything die away then, with aggressive nomination, how am I ever
> >> going to get a second?
> >
> > It takes a while before your server reflexive and relayed candidates
> die
> > out so you have some time to get more checks through. Of course you
> > shouldn't close the local sockets immediately. However, if you want
> to
> > do that considerably (> tens of second) later, and perhaps multiple
> > times, it may get more complicated (something like mobility with
> ICE).
>=20
> These are exactly the kinds of hacks that implementations try to do
> today. Magic timers and proprietary logic. This is exactly what I was
> hoping we could remove by replicating the same feature in aggressive
> that we already have for regular nomination. As Justin put it:  giving
> a
> way to the controlling agent to communicate it's selection to the
> controlled.
>=20
> It simply doesn't make sense not to have it and it would simplify
> things
> a lot so the argument "it would add complexity" doesn't really hold.
>=20
> Emil
>=20
> --
> https://jitsi.org
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Wed Jul 23 20:12:51 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE38B1A0B07 for ; Wed, 23 Jul 2014 20:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssBou39MwIsC for ; Wed, 23 Jul 2014 20:12:46 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A3E1A03C1 for ; Wed, 23 Jul 2014 20:12:45 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so3871834vcb.7 for ; Wed, 23 Jul 2014 20:12:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SgmJxxHsb8OaFeeZmALsC9ZfiquakSuAU1WKg+zSO2o=; b=ASlj9xp75N+NbBmco20Vd2W/bkI61yXLtSlZSIIY5D1Ta67ZcfuDyC41opILG4KfXX pJX0XwxwPLreMg7Px+dIqAPb/2mvYbHTAGgKYK0K5SSnoFHvgyVxc7eNUm/jf6Q/lRZ6 HcfSp1XCdEqF5I0QBCxM/OZQhzMcZRRBp5aezMwiJRzAw3qJ0qjDPGL8lWCjcW6D/2Qp rJuibo/z+ZAdENWnRTgOZL0Paey3Ug//LF5EDHv71PPGNsq8CNd2mgT62IzW4ZIEAXHU 43k0uvrTZQWHSLVfvxMUk+bpVgI5e4abuKsYXUpUD1ZDBzcYBTpIrhT08cD5ZhnZXBFF 0OOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SgmJxxHsb8OaFeeZmALsC9ZfiquakSuAU1WKg+zSO2o=; b=drr2IG9cfJWlGamafnDLEdyMHOWWDpLE4yJgNyX6r760avyWJfaukQo8qtf5xjl82g hv/BCHZ7ycWoXGWUp2/ngXi15nVU8O/fFddPl9VWKlObKnFChUZXh8CBGv7DETzxUsQC 7lrXoEeFtM6+V26UgPxn8DMF6PLo6ZxZTn2lhZEKPD34+4OJ/rE4v2Dm7WesqCaU9vme /seuZah4hV0CYbn7v/QhcnegmbxjpBaMHlMaKOVZwHlK+1ruDK0XeNQElIrD3luWbwxn 0qgHRXIwPpp4rSbcovFbn+IDskVOqzbNq79FmPVAdkhKM37koSwPVfbGXBH2YePY1V5T PGYA==
X-Gm-Message-State: ALoCoQlMj6JfWkudSYUZ+pBrqw0sIrJb36iviZpCABJsu5r7ohTnIsDAKAoOkFai0cT5sSP5rsdW
X-Received: by 10.220.94.135 with SMTP id z7mr7977221vcm.46.1406171564658; Wed, 23 Jul 2014 20:12:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 20:12:24 -0700 (PDT)
In-Reply-To: <011401cfa6d8$378084f0$a6818ed0$@co.in>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <011401cfa6d8$378084f0$a6818ed0$@co.in>
From: Justin Uberti 
Date: Wed, 23 Jul 2014 23:12:24 -0400
Message-ID: 
To: Parthasarathi R 
Content-Type: multipart/alternative; boundary=001a11c1e4889af43004fee7d4d4
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lw1TM3dMDrl-FKCQRpC9Xy-pncs
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 03:12:48 -0000

--001a11c1e4889af43004fee7d4d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It is important to understand that this proposed approach doesn't change
the interactions with signaling at all.

Currently, when doing regular nomination, the CONTROLLING can use its own
policy to decide which active candidate pair to use, as is described in
RFC5245, S 8.1.1.1. This is not possible when doing aggressive nomination.
The solution I am proposing fixes this issue.


On Wed, Jul 23, 2014 at 8:42 PM, Parthasarathi R  wrote:

> Hi Emil,
>
> It is better to handle through signaling as it provides to flexibility in
> the application (like forking usecase). In case of pushing the intelligen=
ce
> within ICE will just move the portion of the signaling to ICE in case the
> application is required to know.
>
> Please note that the signaling protocol which choose not to indicate it
> based on the specific signaling protocol design.
>
> Thanks
> Partha
>
> > -----Original Message-----
> > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Emil Ivov
> > Sent: Thursday, July 24, 2014 3:58 AM
> > To: Ari Ker=C3=A4nen
> > Cc: mmusic
> > Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
> >
> >
> >
> > On 23.07.14, 18:21, Ari Ker=C3=A4nen wrote:
> > > On 7/23/14 6:00 PM, Emil Ivov wrote:
> > >>
> > >>
> > >> On 23.07.14, 12:30, Ari Ker=C3=A4nen wrote:
> > >>> On 7/22/14 7:12 PM, Emil Ivov wrote:
> > >>>>
> > >>>> On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen"  > >>>> > wrote:
> > >>>>  >
> > >>>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
> > >>>>  >>
> > >>>>  >> On 22.07.14, 11:02, Ari Ker=C3=A4nen wrote:
> > >>>>  >>>
> > >>>>  >>> Hi,
> > >>>>  >>>
> > >>>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
> > >>>>  >>>>
> > >>>>  >>>> In London we mentioned the option of adding a new attribute
> > that,
> > >>>> during
> > >>>>  >>>> aggressive nomination, the controlling agent can use to
> > notify
> > >>>> its
> > >>>> peer
> > >>>>  >>>> that ICE processing is over and no more changes are going to
> > be
> > >>>>  >>>> attempted. This way controlled agents will no they can now
> > >>>> release
> > >>>>  >>>> resources.
> > >>>>  >>>>
> > >>>>  >>>> This could either be a new attribute (e.g.,
> > >>>> USE-CANDIDATE-CONFIRMED) or,
> > >>>>  >>>> as Justin suggested in an off-list discussion, we could have
> > the
> > >>>>  >>>> controlling agent send a second USE-CANDIDATE once
> > aggressive
> > >>>> nomination
> > >>>>  >>>> converges.
> > >>>>  >>>
> > >>>>  >>>
> > >>>>  >>> Did you consider using the updated offer to indicate that
> > you're
> > >>>> really
> > >>>>  >>> done? This would require that you always send it (i.e., a
> > slight
> > >>>>  >>> modification to 5245), but that's something that has been
> > already
> > >>>>  >>> proposed to be updated for other purposes.
> > >>>>  >>
> > >>>>  >>
> > >>>>  >> The point is to have all that information without involving
> > >>>> signalling,
> > >>>>  >> as is the case with regular nomination.
> > >>>>  >>
> > >>>>  >> Let me ask the question the other way. Is there any reason not
> > >>>> to do
> > >>>> this?
> > >>>>  >
> > >>>>  >
> > >>>>  > Just the usual: are the benefits higher than the added
> > complexity.
> > >>>> Here, depending how it's done, the added complexity should be
> > fairly
> > >>>> low
> > >>>> though.
> > >>>>
> > >>>> The complexity of having to handle that over signalling and the
> > need to
> > >>>> implement it on every sig protocol that ever dares to use ICE is
> > >>>> arguably much higher than that of an extra attribute
> > >>>
> > >>> Actually I meant the complexity of implementing something like
> > this, and
> > >>> why to do/not to do this (in any way).
> > >>
> > >> Yes, so did I. We are talking about the "complexity" of adding one
> > ICE
> > >> attribute as opposed to intertwining the states of ICE and
> > signalling
> > >> and making them dependent on each other.
> > >>
> > >>>>  > For the benefits, currently with SIP you are allowed to release
> > the
> > >>>> not selected candidate resources after 3 seconds from concluding
> > ICE
> > >>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
> > >>>>
> > >>>> And that is the whole point because currently with aggressive
> > >>>> nomination
> > >>>> you simply don't know exactly when ICE has concluded.
> > >>>
> > >>> So if you assume aggressive ICE has concluded after you've got your
> > >>> first USE-CANDIDATE checks done (as the text currently says), and
> > you
> > >>> stop doing keep-alives on all except the selected candidate pair
> > and let
> > >>> your relayed and reflexive candidates die away. You still have some
> > time
> > >>> to switch between the candidates since the candidates are still
> > alive
> > >>> for at least some (tens of?) seconds. Isn't that OK?
> > >>
> > >> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
> > >> everything die away then, with aggressive nomination, how am I ever
> > >> going to get a second?
> > >
> > > It takes a while before your server reflexive and relayed candidates
> > die
> > > out so you have some time to get more checks through. Of course you
> > > shouldn't close the local sockets immediately. However, if you want
> > to
> > > do that considerably (> tens of second) later, and perhaps multiple
> > > times, it may get more complicated (something like mobility with
> > ICE).
> >
> > These are exactly the kinds of hacks that implementations try to do
> > today. Magic timers and proprietary logic. This is exactly what I was
> > hoping we could remove by replicating the same feature in aggressive
> > that we already have for regular nomination. As Justin put it:  giving
> > a
> > way to the controlling agent to communicate it's selection to the
> > controlled.
> >
> > It simply doesn't make sense not to have it and it would simplify
> > things
> > a lot so the argument "it would add complexity" doesn't really hold.
> >
> > Emil
> >
> > --
> > https://jitsi.org
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--001a11c1e4889af43004fee7d4d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


It is important to understand that this proposed approach =
doesn't change the interactions with signaling at all.

Currently, when doing regular nomination, the CONTROLLING can use its ow=
n policy to decide which active candidate pair to use, as is described in R=
FC5245, S 8.1.1.1. This is not possible when doing aggressive nomination. T=
he solution I am proposing fixes this issue.





On Wed,=
 Jul 23, 2014 at 8:42 PM, Parthasarathi R <partha@parthasarathi.c=
o.in> wrote:



Hi Emil,



It is better to handle through signaling as it provides to flexibility in t=
he application (like forking usecase). In case of pushing the intelligence =
within ICE will just move the portion of the signaling to ICE in case the a=
pplication is required to know.





Please note that the signaling protocol which choose not to indicate it bas=
ed on the specific signaling protocol design.



Thanks

Partha




> -----Original Message-----

> From: mmusic [mailto:mmusic=
-bounces@ietf.org] On Behalf Of Emil Ivov

> Sent: Thursday, July 24, 2014 3:58 AM

> To: Ari Ker=C3=A4nen

> Cc: mmusic

> Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

>

>

>

> On 23.07.14, 18:21, Ari Ker=C3=A4nen wrote:

> > On 7/23/14 6:00 PM, Emil Ivov wrote:

> >>

> >>

> >> On 23.07.14, 12:30, Ari Ker=C3=A4nen wrote:

> >>> On 7/22/14 7:12 PM, Emil Ivov wrote:

> >>>>

> >>>> On 22 Jul 2014 6:11 PM, "Ari Ker=C3=A4nen" =
<ari.keranen@ericsson.com

> >>>> <mailto:ari.keranen@ericsson.com>> wrote:

> >>>> =C2=A0>

> >>>> =C2=A0> On 7/22/14 11:06 AM, Emil Ivov wrote:

> >>>> =C2=A0>>

> >>>> =C2=A0>> On 22.07.14, 11:02, Ari Ker=C3=A4nen w=
rote:

> >>>> =C2=A0>>>

> >>>> =C2=A0>>> Hi,

> >>>> =C2=A0>>>

> >>>> =C2=A0>>> On 7/21/14 4:45 PM, Emil Ivov wrot=
e:

> >>>> =C2=A0>>>>

> >>>> =C2=A0>>>> In London we mentioned the opt=
ion of adding a new attribute

> that,

> >>>> during

> >>>> =C2=A0>>>> aggressive nomination, the con=
trolling agent can use to

> notify

> >>>> its

> >>>> peer

> >>>> =C2=A0>>>> that ICE processing is over an=
d no more changes are going to

> be

> >>>> =C2=A0>>>> attempted. This way controlled=
 agents will no they can now

> >>>> release

> >>>> =C2=A0>>>> resources.

> >>>> =C2=A0>>>>

> >>>> =C2=A0>>>> This could either be a new att=
ribute (e.g.,

> >>>> USE-CANDIDATE-CONFIRMED) or,

> >>>> =C2=A0>>>> as Justin suggested in an off-=
list discussion, we could have

> the

> >>>> =C2=A0>>>> controlling agent send a secon=
d USE-CANDIDATE once

> aggressive

> >>>> nomination

> >>>> =C2=A0>>>> converges.

> >>>> =C2=A0>>>

> >>>> =C2=A0>>>

> >>>> =C2=A0>>> Did you consider using the updated=
 offer to indicate that

> you're

> >>>> really

> >>>> =C2=A0>>> done? This would require that you =
always send it (i.e., a

> slight

> >>>> =C2=A0>>> modification to 5245), but that=
9;s something that has been

> already

> >>>> =C2=A0>>> proposed to be updated for other p=
urposes.

> >>>> =C2=A0>>

> >>>> =C2=A0>>

> >>>> =C2=A0>> The point is to have all that informat=
ion without involving

> >>>> signalling,

> >>>> =C2=A0>> as is the case with regular nomination=
.

> >>>> =C2=A0>>

> >>>> =C2=A0>> Let me ask the question the other way.=
 Is there any reason not

> >>>> to do

> >>>> this?

> >>>> =C2=A0>

> >>>> =C2=A0>

> >>>> =C2=A0> Just the usual: are the benefits higher th=
an the added

> complexity.

> >>>> Here, depending how it's done, the added complexi=
ty should be

> fairly

> >>>> low

> >>>> though.

> >>>>

> >>>> The complexity of having to handle that over signalli=
ng and the

> need to

> >>>> implement it on every sig protocol that ever dares to=
 use ICE is

> >>>> arguably much higher than that of an extra attribute<=
br>
> >>>

> >>> Actually I meant the complexity of implementing something=
 like

> this, and

> >>> why to do/not to do this (in any way).

> >>

> >> Yes, so did I. We are talking about the "complexity"=
; of adding one

> ICE

> >> attribute as opposed to intertwining the states of ICE and
> signalling

> >> and making them dependent on each other.

> >>

> >>>> =C2=A0> For the benefits, currently with SIP you a=
re allowed to release

> the

> >>>> not selected candidate resources after 3 seconds from=
 concluding

> ICE

> >>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1=
).

> >>>>

> >>>> And that is the whole point because currently with ag=
gressive

> >>>> nomination

> >>>> you simply don't know exactly when ICE has conclu=
ded.

> >>>

> >>> So if you assume aggressive ICE has concluded after you&#=
39;ve got your

> >>> first USE-CANDIDATE checks done (as the text currently sa=
ys), and

> you

> >>> stop doing keep-alives on all except the selected candida=
te pair

> and let

> >>> your relayed and reflexive candidates die away. You still=
 have some

> time

> >>> to switch between the candidates since the candidates are=
 still

> alive

> >>> for at least some (tens of?) seconds. Isn't that OK?<=
br>
> >>

> >> If I assume ICE has concluded after my *first* USE-CANDIDATE =
and let

> >> everything die away then, with aggressive nomination, how am =
I ever

> >> going to get a second?

> >

> > It takes a while before your server reflexive and relayed candida=
tes

> die

> > out so you have some time to get more checks through. Of course y=
ou

> > shouldn't close the local sockets immediately. However, if yo=
u want

> to

> > do that considerably (> tens of second) later, and perhaps mul=
tiple

> > times, it may get more complicated (something like mobility with<=
br>
> ICE).

>

> These are exactly the kinds of hacks that implementations try to do
> today. Magic timers and proprietary logic. This is exactly what I was<=
br>
> hoping we could remove by replicating the same feature in aggressive
> that we already have for regular nomination. As Justin put it: =C2=A0g=
iving

> a

> way to the controlling agent to communicate it's selection to the<=
br>
> controlled.

>

> It simply doesn't make sense not to have it and it would simplify<=
br>
> things

> a lot so the argument "it would add complexity" doesn't =
really hold.

>

> Emil

>

> --

> https://jitsi.org<=
br>
>

> _______________________________________________

> 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





--001a11c1e4889af43004fee7d4d4--


From nobody Wed Jul 23 20:38:47 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A160F1A0A98 for ; Wed, 23 Jul 2014 20:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgKPmfe4yT3q for ; Wed, 23 Jul 2014 20:38: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 6875B1A03BC for ; Wed, 23 Jul 2014 20:38:43 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id W3EA1o0020cZkys5C3ejhJ; Thu, 24 Jul 2014 03:38:43 +0000
Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta10.westchester.pa.mail.comcast.net with comcast id W3c41o00D3xdsjB3W3c8mL; Thu, 24 Jul 2014 03:36:41 +0000
Message-ID: <53D07F21.1030807@alum.mit.edu>
Date: Wed, 23 Jul 2014 23:36:01 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: 
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=q20140121; t=1406173123; bh=R5FO2FaHPC3aBo/TERAI2cpfnmEm2GgV9SsGaok8aK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=soCa9frjqfcR5AogpQ33TgGHGzDZuHMLl0bV4CbMJoUf9zGQkotIf+vjH5mGZCQfU nehAA90CKRKwVcN1JjDCadMHggV7yd6K1xFPZ0fGwZmRVl6j3q5L4pXE6Pjq5hWnw2 nkR65id35pjcpfEi7+7QlwB4IOziT5tb6wUVjDGzdjB/lf5trQI2fyJykwbQbcE3Cv NShoeFbqRZI5PFE7qQKf00x1v+C0hzsH4/p4cRCKafGTZZXA3ZKPK9t/ROt8/bP2nu BnG8odScluOPvs1fIh/7sWICbZHeUsHD/7UCgcNjCZ3qXf+ibxaFyafJVZSZ78I5Yq FoIoLA3pkvEVg==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rc0XvRbUCz6fGwV_Xre5tCw2RNU
Subject: Re: [MMUSIC] ICE and the "unexpected answer" problem
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 03:38:45 -0000

Thomas,

On 7/23/14 8:00 AM, Stach, Thomas wrote:
> ICE experts,
>
> we came across the following situation that has some relation to ICE
> restart procedures.
>
> Consider that A calls B via a B2BUA. Both A and B support ICE and have
> successfully finished ICE procedures though the B2BUA is ICE-unaware.
>
> Now after a while either A or B sends out a new offer to put the other
> party on hold (a=inactive) without indicating an ICE restart.
>
> It includes the in-use candidates and the remote-candidates as required
> by section 9 of RFC5245 and expects to get the remote-candidates
> reflected in the answer.
>
> However, the B2BUA in the signaling path introduces via some 3PCC means
> a media server that provides MoH to the Held UA.

Not too unusual.

> On the call-leg towards the Holding UA, the B2BUA sends back some dummy
> answer that fulfills RFC3264 requirements (e.g. includes a=inactive) but
> does not include the expected remote-candidates.

Can you provide details of the offers and answers?

If it is going to provide MoH then presumably it isn't setting the media 
inactive. (Or is it doing MoH on audio and setting video inactive?)

Note that once the call goes off hold all this will happen again to get 
back to the actual device again.

	Thanks,
	Paul

> The Holding UA was unaware of the B2BUAs interference, but now gets an
> unexpected answer to its hold offer.
>
> Of course there could al                so exist other similar
> situations where the peer changes mid-call and the offerer receives some
> unexpected answer. If we take RFC3264 into consideration, an offerer
> would need to be prepared to receive such an unexpected answer.
>
> But with respect to ICE procedures there is no guidance what to do next,
> although http://tools.ietf.org/html/rfc5245#section-9.1.1.1 talks
> already about Hold and ICE restarts.
>
> However, it does not cover the above situation.
>
> Would it be justified to include some clarification e.g.  into
> rfc5245bis or draft-ietf-mmusic-ice-sip-sdp that something like the
> above could happen and even give some suggestions when/how to perform
> ICE restart?
>
> Such suggestion could look roughly as follows:
>
> The UA that got the unexpected answer would have to do an ICE restart
> in order to get things straight again once it sends out its next offer.
>
> In the above situation It would be sufficient when the Holding UA
> performs the ICE restart once it reconnects to the Held UA,
>
> i.e. it would not be necessary to do the ICE restart immediately
> although in other situations that might be justified.
>
> In yet other situations there might even be an ICE restart performed
> from the peer, that sent the unexpected answer.
>
> Any thoughts/comments?
>
> If people agree I would also be happy to contribute corresponding text.
>
> Regards
>
> Thomas
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Thu Jul 24 01:23:03 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0043A1A00D8 for ; Thu, 24 Jul 2014 01:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myja9a-L40HS for ; Thu, 24 Jul 2014 01:23:00 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E861A00CA for ; Thu, 24 Jul 2014 01:22:59 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id a108so2792014qge.2 for ; Thu, 24 Jul 2014 01:22:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sw3aZrsvUkBBJ4ObVhnUNKpVWj5bItdL4NnHJntkRRM=; b=XItJwPIU3GfyA03NtYuZMRGIswN9XNEv4FcRHFlFC7gBGrA8CVa+imwF/MIoHZtRpA fJ9f9MUroADpz6imqFNnMqyubbE/lyHRSsHoGEH/ZLShUsVEvtZ+BsfaIrIkX1EYFuOV Z09mBlyi7p2Tn2O6KlPfjBggP/nsDSfnsiSz2564DA9xEhU+ff76JyeUKICQqQr2G0q/ KpfLIQ8fXlPNQrCcE/QeRYmuw7junZ9j55cteJO4Q84SBEaZ6f5xZTn9Y55WYcs26vjT 07P06I+Y1oy7nsf3I+EOraNJBvna8zPfERhONo/sw8mfh7ioI3LerixuR1U01vCFSnoZ DpSg==
X-Gm-Message-State: ALoCoQke325Ujl25QMbhl6r9hk0FKsZCSQqZrx9ZKtTPl0nAHLF08qq1pLRviT+Wp76bntHy4iSv
X-Received: by 10.140.30.73 with SMTP id c67mr11926972qgc.16.1406190179043; Thu, 24 Jul 2014 01:22:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 24 Jul 2014 01:22:38 -0700 (PDT)
In-Reply-To: <011401cfa6d8$378084f0$a6818ed0$@co.in>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <011401cfa6d8$378084f0$a6818ed0$@co.in>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Jul 2014 10:22:38 +0200
Message-ID: 
To: Parthasarathi R 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nmwWMOsFASWBRuDEZ5vEhwEpStE
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 08:23:01 -0000

2014-07-24 2:42 GMT+02:00 Parthasarathi R :
> It is better to handle through signaling as it provides to flexibility in=
 the application (like forking usecase).

No, it is not. So 5245bis si supposed to split ICE network protocol
and SDP, and you propose that a new feature must depend, again, on the
signaling protocol? No way.

And the forking usecase (so you mean the "SIP forking usecase") is
perfectly achiveable via a new STUN attribute (by sending a request
containing it to the specific "SIP forked dialog").


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 24 06:37:09 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7B21A032F for ; Thu, 24 Jul 2014 06:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGDVFD6U1CQ0 for ; Thu, 24 Jul 2014 06:37:05 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BF61A0320 for ; Thu, 24 Jul 2014 06:37:04 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-f9-53d10bffd4b5
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4E.89.19155.FFB01D35; Thu, 24 Jul 2014 15:37:03 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.174.1; Thu, 24 Jul 2014 15:37:02 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id C63E6110299; Thu, 24 Jul 2014 16:37:02 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6757D589DC;	Thu, 24 Jul 2014 16:37:15 +0300 (EEST)
Received: from dhcp-bcda.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A2F45589DB;	Thu, 24 Jul 2014 16:37:14 +0300 (EEST)
Message-ID: <53D10BFC.70409@ericsson.com>
Date: Thu, 24 Jul 2014 09:37:00 -0400
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje5/7ovBBm+3S1qs2TmBxWL6PhuL qcsfszgwe5xreM/usWTJTyaP/28CA5ijuGxSUnMyy1KL9O0SuDKeb+1jL3jMUTGp8SxTA+Nf ti5GTg4JAROJ/uMdzBC2mMSFe+uB4lwcQgJHGSWm3ulghHA2MErMu/icCcLZC5S59hbKWcco 0dW/nxXOudm7nxFkGK+ApsSMz7NZQWwWAVWJr4sOgtlsArYSq1/dZAGxRQWSJdZsncQOUS8o cXLmE7C4iICNxI2JE5hAbGYBS4mTK7+CxYWB4iua1zFDLOtllJjYvB8swSkQKNF4fR8LRIOF xOI3B9khbHmJ5q2zob5Tk7h6bhOYLQR00NV/rxgnMIrOQrJ7FpL2WUjaFzAyr2IULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjJSDW36r7mC8/MbxEKMAB6MSD++D/eeDhVgTy4orcw8xSnOw KInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI/9n88d6J6ZYNVj3dE8N/N2tZHH/ TeXnqKdhTsG+CxRCChxf80mpVQgpMx078dWyWt6rcqGMdX/XCQ62n+dVv07p/fuk/uJLs5WG AcU7vvUn12+wk1HQcAh+57le8WmxZMjMEOlrPa8ts1piGw1fFG6f+v1EPUtKzHfXT1fvBO65 t/4h465jSizFGYmGWsxFxYkA9j8EknUCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uzVn7CuZTepRVsm1iw91uraHPAQ
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 13:37:08 -0000

On 7/23/14 7:40 PM, Iñaki Baz Castillo wrote:
> 2014-07-22 17:02 GMT+02:00 Ari Keränen :
>> Did you consider using the updated offer to indicate that you're really
>> done? This would require that you always send it (i.e., a slight
>> modification to 5245), but that's something that has been already proposed
>> to be updated for other purposes.
>
> Do you mean sending the "updated SDP offer" after ICE is paired? No
> please. Relying on that is a bad idea. STUN is a network protocol and
> should not rely on a different signaling protocol (SIP+SDP or XXX+SDP)
> to indicate nothing. The SDP (or whatever is used) is just needed to
> indicate ICE parameters out of band.
>
> And for sure, WebRTC browsers ignore at 100% the "update SDP offer
> once ICE is paired".

Yes, I meant that the updated (SDP) offer could make sense as an 
indicator for being done since it is already there. But if it isn't 
actually sent, doing it just for the sake of this doesn't sound very 
smart. And perhaps the bundling of these two isn't that good idea to 
start with.


Cheers,
Ari


From nobody Thu Jul 24 07:03:34 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0C1A033B for ; Thu, 24 Jul 2014 07:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSFAgEmPunCs for ; Thu, 24 Jul 2014 07:03:31 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320931A0346 for ; Thu, 24 Jul 2014 07:03:27 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-c4-53d1122de80e
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.6D.03739.D2211D35; Thu, 24 Jul 2014 16:03:25 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.174.1; Thu, 24 Jul 2014 16:03:23 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 30BC5110299; Thu, 24 Jul 2014 17:03:23 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C26C9589DC;	Thu, 24 Jul 2014 17:03:35 +0300 (EEST)
Received: from dhcp-bcda.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2944A589DB;	Thu, 24 Jul 2014 17:03:35 +0300 (EEST)
Message-ID: <53D11228.1080201@ericsson.com>
Date: Thu, 24 Jul 2014 10:03:20 -0400
From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Emil Ivov 
References: <53CD7C04.8070106@jitsi.org>	<53CE7D0A.4030406@ericsson.com>	<53CE7DDD.5030406@jitsi.org>	<53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org>
In-Reply-To: <53D036F1.8070504@jitsi.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja6u0MVgg6cTFSzW7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAldFzUr1gr1DFzHNWDYwf+boYOTkkBEwktq1f wQhhi0lcuLeeDcQWEjjKKPFpSUYXIxeQvYFRYuX1bSwQzl5Gic//PkA56xglXm7vYIJzFiw4 zwrSzyugLTFr11Z2EJtFQFVi5ornLCA2m4CtxOpXN8FsUYFkiTVbJ7FD1AtKnJz5BCwuIiAv 0d22iAnEZhaQkZhxthHMFhawkVjRvI4ZYtkRJomFM5rAlnEKaEp8fv+PGaLBQmLxm4PsELa8 xPa3c5ghnlOTuHpuEzPEc6oSV/+9YpzAKDoLye5ZSNpnIWlfwMi8ilG0OLW4ODfdyFgvtSgz ubg4P08vL7VkEyMwIg5u+a27g3H1a8dDjAIcjEo8vA/2nw8WYk0sK67MPcQozcGiJM676Ny8 YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MAd2vE+dM7Jn2kMdDf6+Z4tWzkUs6hSICCzUa WBIzNCLvetg6/N647EezW1vVuef9+RWl7i1Om7pvVfX5H7w78dEz/e3LkpZeZ9f0dnmTda3j +/lTtQJ/Jt3uFZ2ovc/feF55R9gTwz6ejdzCex5s21Jqv/9Be65iat2TPGYvpeiSbR/DH2op sRRnJBpqMRcVJwIAgQqMamkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_jM_QhD3yuD_m-emHVXPeH85q2c
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 14:03:33 -0000

On 7/23/14 6:28 PM, Emil Ivov wrote:
>>>>>  > For the benefits, currently with SIP you are allowed to release the
>>>>> not selected candidate resources after 3 seconds from concluding ICE
>>>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>>>>
>>>>> And that is the whole point because currently with aggressive
>>>>> nomination
>>>>> you simply don't know exactly when ICE has concluded.
>>>>
>>>> So if you assume aggressive ICE has concluded after you've got your
>>>> first USE-CANDIDATE checks done (as the text currently says), and you
>>>> stop doing keep-alives on all except the selected candidate pair and
>>>> let
>>>> your relayed and reflexive candidates die away. You still have some
>>>> time
>>>> to switch between the candidates since the candidates are still alive
>>>> for at least some (tens of?) seconds. Isn't that OK?
>>>
>>> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
>>> everything die away then, with aggressive nomination, how am I ever
>>> going to get a second?
>>
>> It takes a while before your server reflexive and relayed candidates die
>> out so you have some time to get more checks through. Of course you
>> shouldn't close the local sockets immediately. However, if you want to
>> do that considerably (> tens of second) later, and perhaps multiple
>> times, it may get more complicated (something like mobility with ICE).
>
> These are exactly the kinds of hacks that implementations try to do
> today. Magic timers and proprietary logic. This is exactly what I was
> hoping we could remove by replicating the same feature in aggressive
> that we already have for regular nomination. As Justin put it:  giving a
> way to the controlling agent to communicate it's selection to the
> controlled.

We could of course recommend some values on how long to wait to take 
away some of the magic.

> It simply doesn't make sense not to have it and it would simplify things
> a lot so the argument "it would add complexity" doesn't really hold.

Makes sense. I'm still wondering what's the best way to do this though.

Would the semantics of the new attribute be "I'm no longer trying to 
find better candidate pairs; use the highest priority with 
USE-CANDIDATE" or "don't use the highest priority pair but use X", or 
something else?


Cheers,
Ari


From nobody Thu Jul 24 07:21:34 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE861A016C for ; Thu, 24 Jul 2014 07:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vmmf3UjJiJC for ; Thu, 24 Jul 2014 07:21:24 -0700 (PDT)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74761A0142 for ; Thu, 24 Jul 2014 07:21:21 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so4986853vcb.35 for ; Thu, 24 Jul 2014 07:21:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=7sDDHVsD0OrvEiqSgpVVlgJWnYI1jnG1mr/JD0f+VYA=; b=lbzgbsXXAI070MuOUzaPlx24DZGGob53hFDPzEF5ZcSL0ScpZTPvkiPw4y4yisLm5+ ph4NteA9e9v5ReULl6zYm/2d2vRbxfizyWtlbmTzPaEDysjnll6Plf3fijCNgDuPTD6i kuKd/kU3v9iR32cg2EWJ14UrepFFHKeIloMLbPmI8/D63MoTYvrXRgYN4IgBatHGRoP3 i0od7jRZA292VpiENiJwiXwkTQp1C3Dzoh+aEIkxIUfe/OMQo8nUwuZsIQCI7ih70hTG 9PJesDtc/mqLICfRKXExnGZ7/yevASVICtfSHpxtQrXNfGqId+yHrXnZAaoZMNvzFRvD kbFw==
X-Gm-Message-State: ALoCoQmA2zGnM5W4yx5YMdJ52HUEYA2yG2bmxr136sIDRZVKIbVTT1rGAngomhviiuCK1Xdxierf
X-Received: by 10.52.154.106 with SMTP id vn10mr10489516vdb.36.1406211678371;  Thu, 24 Jul 2014 07:21:18 -0700 (PDT)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx.google.com with ESMTPSA id nu10sm10812999vdb.11.2014.07.24.07.21.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 07:21:18 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id hq11so5008226vcb.38 for ; Thu, 24 Jul 2014 07:21:17 -0700 (PDT)
X-Received: by 10.221.44.69 with SMTP id uf5mr12942592vcb.4.1406211677939; Thu, 24 Jul 2014 07:21:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.238.75 with HTTP; Thu, 24 Jul 2014 07:20:57 -0700 (PDT)
In-Reply-To: <53D11228.1080201@ericsson.com>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>
From: Emil Ivov 
Date: Thu, 24 Jul 2014 10:20:57 -0400
Message-ID: 
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fkgMJf6rptv-8qCcD0GDXwmKunw
Cc: mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 14:21:26 -0000

On Thu, Jul 24, 2014 at 10:03 AM, Ari Ker=C3=A4nen  wrote:
> On 7/23/14 6:28 PM, Emil Ivov wrote:
>>>>>>
>>>>>>  > For the benefits, currently with SIP you are allowed to release t=
he
>>>>>> not selected candidate resources after 3 seconds from concluding ICE
>>>>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>>>>>
>>>>>> And that is the whole point because currently with aggressive
>>>>>> nomination
>>>>>> you simply don't know exactly when ICE has concluded.
>>>>>
>>>>>
>>>>> So if you assume aggressive ICE has concluded after you've got your
>>>>> first USE-CANDIDATE checks done (as the text currently says), and you
>>>>> stop doing keep-alives on all except the selected candidate pair and
>>>>> let
>>>>> your relayed and reflexive candidates die away. You still have some
>>>>> time
>>>>> to switch between the candidates since the candidates are still alive
>>>>> for at least some (tens of?) seconds. Isn't that OK?
>>>>
>>>>
>>>> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
>>>> everything die away then, with aggressive nomination, how am I ever
>>>> going to get a second?
>>>
>>>
>>> It takes a while before your server reflexive and relayed candidates di=
e
>>> out so you have some time to get more checks through. Of course you
>>> shouldn't close the local sockets immediately. However, if you want to
>>> do that considerably (> tens of second) later, and perhaps multiple
>>> times, it may get more complicated (something like mobility with ICE).
>>
>>
>> These are exactly the kinds of hacks that implementations try to do
>> today. Magic timers and proprietary logic. This is exactly what I was
>> hoping we could remove by replicating the same feature in aggressive
>> that we already have for regular nomination. As Justin put it:  giving a
>> way to the controlling agent to communicate it's selection to the
>> controlled.
>
>
> We could of course recommend some values on how long to wait to take away
> some of the magic.
>
>
>> It simply doesn't make sense not to have it and it would simplify things
>> a lot so the argument "it would add complexity" doesn't really hold.
>
>
> Makes sense. I'm still wondering what's the best way to do this though.
>
> Would the semantics of the new attribute be "I'm no longer trying to find
> better candidate pairs; use the highest priority with USE-CANDIDATE" or
> "don't use the highest priority pair but use X", or something else?

USE-CANDIDATE-CONFIRMATION (or whatever name we want) sounds like the
most unambiguous and easy to implement option.

I don't think priorities should play a role at this stage, just as
they don't with regular nomination.

Resending USE-CANDIDATE looks slightly more messy to me (especially
when trying to make sense of wireshark traces) but it would still
work.

Emil





--=20
https://jitsi.org


From nobody Thu Jul 24 07:43:45 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E0A1A03B8 for ; Thu, 24 Jul 2014 07:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVT1Guww8HWX for ; Thu, 24 Jul 2014 07:43:43 -0700 (PDT)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313D21A03B1 for ; Thu, 24 Jul 2014 07:43:43 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id q107so3350185qgd.0 for ; Thu, 24 Jul 2014 07:43:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=RFbM8f+zf97T8DDRzmKDfadWU/XGwy32f8AmyDsqyBI=; b=SwwQ+Gpo6katdvp7eD9h4WyzsWX79YXlfXXn+FWWUTaB6wsZNLFxC5MnnDufKYhawd 3zi1lgTwd40P9ojIYQyPNpmi23pWweiDY55pE9hOhF2dSCs7vm3il8CC+f+wE/AGGf0n d4X5MJRIw3RaHvn/1LcToPTqrMXFVbnE6BnjqMseGDBtJ1DJEKayrwXQGRu5Nde6IC75 2JU/7lCxDC7RWpn4DpFfTrMtNr8XVgNsaMeCF4SnimxPk5ebM5+SZUcj+XOiarn2Ta5W Bmqd81cEj+BEDk+gwnW5EawueaApP2eak9HUPXu312J4nwhM0a2oFfQ1NJEybuxfSHct AIfw==
X-Gm-Message-State: ALoCoQmZQ1qfgwWK+oNYnPDifGgebHW13FnRgDj0CYZQWzo4ymH/QNwq46QX7a/EX5jKeTKKBbRk
X-Received: by 10.224.87.130 with SMTP id w2mr15932714qal.5.1406213022313; Thu, 24 Jul 2014 07:43:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 24 Jul 2014 07:43:22 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Jul 2014 16:43:22 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/09H84_NswL4IuIdrkTEOaTsAWU0
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 14:43:44 -0000

2014-07-24 16:20 GMT+02:00 Emil Ivov :
> USE-CANDIDATE-CONFIRMATION (or whatever name we want) sounds like the
> most unambiguous and easy to implement option.
>
> I don't think priorities should play a role at this stage, just as
> they don't with regular nomination.

Just wondering:

What about re-sending the chosen ICE Request but with a higher
PRIORITY at that point? I mean:

  Req1 (USE-CANDIDATE, PRIORITY: 1234)  -->
  Req2 (USE-CANDIDATE, PRIORITY: 2345)  -->
  (let's choose the first one)
  Req1 (USE-CANDIDATE, PRIORITY: 9999)  -->

For sure you have already thought about this and it is invalid, just
wondering if I miss something. :)
--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 24 07:49:16 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACC71A03D8 for ; Thu, 24 Jul 2014 07:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLNv-12roM85 for ; Thu, 24 Jul 2014 07:49:12 -0700 (PDT)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8E71A03D1 for ; Thu, 24 Jul 2014 07:49:12 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5127070vcb.19 for ; Thu, 24 Jul 2014 07:49:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=U+i/jPM0GDWyv+HlTb9v1nZ8VA7DzG1ZQSqV/BoQU/8=; b=CPM3lC4W5jeE0dDv5PDqw3TNhJGb3JsYFxrOVfVYdPAA5KO0WC22pW5G76L/R+RBcm E2Xm+9xKy9G6M0gvjIM6stTK4qY7d+C1F9NS2NsEhzKsS37ytJYDbLnFU9jAdwDIInAt E4J3LYtlqqqqAZyPbdt8FApMZdAyqkU4/CBHv/co+PgIkp7eUkqe0flnQUfPCmKFOy3b +e/dECfAIStSwjyMjr9OsHaV+p7fYuYWE1dIu26ssH1Moyd9vYr+MXk7uYGE7eLqjiDm 6ZlWkuVU/9/QpKiOLH2lE/7608fdYiLlm/CKMGve6gpIGW5a44ypmOVzDGZQBREnMqyI rJ2A==
X-Gm-Message-State: ALoCoQkS6qHjt4hhC/bffcFv/nVFseItg3eXwFXrJldFXWPZ8JPbiq54LZTWcJBhweo3HiatUZip
X-Received: by 10.52.26.114 with SMTP id k18mr10691778vdg.77.1406213351491; Thu, 24 Jul 2014 07:49:11 -0700 (PDT)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx.google.com with ESMTPSA id r11sm1753082vem.7.2014.07.24.07.49.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 07:49:11 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so4957317vcb.21 for ; Thu, 24 Jul 2014 07:49:11 -0700 (PDT)
X-Received: by 10.220.192.129 with SMTP id dq1mr12823429vcb.57.1406213351132;  Thu, 24 Jul 2014 07:49:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.238.75 with HTTP; Thu, 24 Jul 2014 07:48:51 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>  
From: Emil Ivov 
Date: Thu, 24 Jul 2014 10:48:51 -0400
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/absQdNROok3hXVuprVibpqWC6EE
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 14:49:13 -0000

On Thu, Jul 24, 2014 at 10:43 AM, I=C3=B1aki Baz Castillo  w=
rote:
> 2014-07-24 16:20 GMT+02:00 Emil Ivov :
>> USE-CANDIDATE-CONFIRMATION (or whatever name we want) sounds like the
>> most unambiguous and easy to implement option.
>>
>> I don't think priorities should play a role at this stage, just as
>> they don't with regular nomination.
>
> Just wondering:
>
> What about re-sending the chosen ICE Request but with a higher
> PRIORITY at that point? I mean:
>
>   Req1 (USE-CANDIDATE, PRIORITY: 1234)  -->
>   Req2 (USE-CANDIDATE, PRIORITY: 2345)  -->
>   (let's choose the first one)
>   Req1 (USE-CANDIDATE, PRIORITY: 9999)  -->
>
> For sure you have already thought about this and it is invalid, just
> wondering if I miss something. :)

Well, if you are going to resend it at all then you don't even need to
change priority. The simple fact that you are re-confirming it should
be enough of an indication. That's actually the second option I was
referring to in my previous mail and it would work but I just find it
inconvenient when analysing wireshark traces (i.e., looking for
USE-CANDIDATE-CONFIRMATION is easier than trying to count the number
of USE-CANDIDATEs for a specific pair and then trying to distinguish
retransmissions from new transactions).

Emil


--=20
https://jitsi.org


From nobody Thu Jul 24 08:10:10 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6162B1A0377 for ; Thu, 24 Jul 2014 08:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuJ0FDy6ByCh for ; Thu, 24 Jul 2014 08:10:04 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2657A1A01E1 for ; Thu, 24 Jul 2014 08:08:40 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id s7so3054914qap.37 for ; Thu, 24 Jul 2014 08:08:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=q6+CYCysKQsVPZDKmmKoNWJNABcNGvbSZezMquljAQs=; b=LccL0TQS3VKQUu2tlrn5RIQhWsx+8qNZp5BkrSp2xw7XdKTsadmLGNvti2pgLoiOFW aA6mOqjO69kjCZ2uEIhnRIWqy/RD+/RwUbA+sM5IuBxT9ZPcemgnFcwKUsDXzjW3HPf/ rOa62f4oAT1bfh2W3Z9guMTee+xdDOcWmWnjgP2HRT7Q1HeU2N2f8FB+A6sqD/ZboBSJ 7uuJbce3t7UE+dRwi0BiT1lkT8lx8uRRtMuW6ijvYGktNWm1lqlWep7DSIEuGHhckB+b R7ji+MZkSC9oUs1aqkxGS4xSSoxSD+9rLX1XKQU1wBQnElbgFFj0gdharZioZGsJEfEQ e/KQ==
X-Gm-Message-State: ALoCoQl5saPwI9OdlMZ+CYtPgWObkbsd9AEOQW7yU9HNPAhcVjOBATHMnE5/whjzoXLirtt0oOVQ
X-Received: by 10.140.37.178 with SMTP id r47mr15099239qgr.59.1406214519294; Thu, 24 Jul 2014 08:08:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 24 Jul 2014 08:08:19 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>   
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Jul 2014 17:08:19 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Z5HLUUIL6Sxrbvvc7eHmHKC8EMA
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 15:10:06 -0000

2014-07-24 16:48 GMT+02:00 Emil Ivov :
> Well, if you are going to resend it at all then you don't even need to
> change priority. The simple fact that you are re-confirming it should
> be enough of an indication.

I don't think it should work. The ICE server should select the request
with highest PRIORITY regardless it receives later a new one with less
PRIORITY. This is clear in the RFC. And this is because it is supposed
that both peers agree on selecting the request-response with higher
PRIORITY, regardless which one arrives before.

This makes sense. Let's assume requests come in this order:


1)

   Req1-good-connection PRIORITY: 9000  -->
   Req2-bad-connection PRIORITY: 1000  -->

should the server chose Req2? not at all.


2)

   Req2-bad-connection PRIORITY: 1000  -->
   Req1-good-connection PRIORITY: 9000  -->

server should choose Req1 once it arrives.



--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 24 08:18:16 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA181A0377 for ; Thu, 24 Jul 2014 08:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXFqidNDJvmc for ; Thu, 24 Jul 2014 08:18:11 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8CC1A03CC for ; Thu, 24 Jul 2014 08:15:31 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hu12so5228572vcb.14 for ; Thu, 24 Jul 2014 08:15:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Boz9BNEqohukImrTJxBSBbTGgt26Luu604+zO6jvTsE=; b=DZjruYiWPqKLqb2zLfsnLD9LRlA6B8chjWh4+yKauPXzNwEQUHxlrpQH9Swo4QVJTH eMJ+Ht5wOTSEaIi0nRDOjKiHOSa8M3NkQLxuNQfvR5/tTE35r4cWtTg+djlCHDHB8eQN kyPPcY2EoWvX8DL0kFK25Cxofjq2TdO4t6U+IvzIxuxqAzpOOl+c+joWURMJoH7wuDk5 V+33owqnDC4ut76zFHZ4y1KCS+MRrPjAyZz8jnlTfJigrQaKgRZTWGdmuyGcCDk92y3q dhjknilZM0zMU30H2gaNJLb+rUYVegJWsLXh22Lo9vuiJepU+A5p1alORFQO2z/awxVL Dvvw==
X-Gm-Message-State: ALoCoQkPkZzl+nmGT4iK2mMM+VPNt6L6EXxil8Sf9jhRqqvt8IL96WsQ0qc9kOBMNkQ5FSBTC6W8
X-Received: by 10.220.179.197 with SMTP id br5mr4946042vcb.80.1406214930473; Thu, 24 Jul 2014 08:15:30 -0700 (PDT)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx.google.com with ESMTPSA id u9sm1766125vep.17.2014.07.24.08.15.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 08:15:30 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5140993vcb.33 for ; Thu, 24 Jul 2014 08:15:29 -0700 (PDT)
X-Received: by 10.52.53.33 with SMTP id y1mr11269493vdo.31.1406214929942; Thu, 24 Jul 2014 08:15:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.238.75 with HTTP; Thu, 24 Jul 2014 08:15:09 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>    
From: Emil Ivov 
Date: Thu, 24 Jul 2014 11:15:09 -0400
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SDiFtT1WwoSvzHhFDCVS0RmHAKM
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 15:18:15 -0000

On Thu, Jul 24, 2014 at 11:08 AM, I=C3=B1aki Baz Castillo  w=
rote:
> 2014-07-24 16:48 GMT+02:00 Emil Ivov :
>> Well, if you are going to resend it at all then you don't even need to
>> change priority. The simple fact that you are re-confirming it should
>> be enough of an indication.
>
> I don't think it should work.

It wouldn't work with existing implementations. The point is to define
the spec in a way that makes it work in future implementations.

> The ICE server should select the request
> with highest PRIORITY

I am not sure what you mean by ICE server.

> regardless it receives later a new one with less
> PRIORITY. This is clear in the RFC. And this is because it is supposed
> that both peers agree on selecting the request-response with higher
> PRIORITY, regardless which one arrives before.

This is not true for regular nomination where the nominated candidate
is chosen solely based on the USE-CANDIDATE option.

The point is to create an unambiguous

> This makes sense. Let's assume requests come in this order:
>
> 1)
>
>    Req1-good-connection PRIORITY: 9000  -->
>    Req2-bad-connection PRIORITY: 1000  -->
>
> should the server chose Req2? not at all.
>
> 2)
>
>    Req2-bad-connection PRIORITY: 1000  -->
>    Req1-good-connection PRIORITY: 9000  -->
>
> server should choose Req1 once it arrives.

I think you are confusing multiple received USE-CANDIDATE options for
*different* candidate pairs (which is what happens with aggressive
nomination) with receiving a second USE-CANDIDATE option for *the
same* candidate pair.

Emil


--=20
https://jitsi.org


From nobody Thu Jul 24 08:33:39 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12571A024E for ; Thu, 24 Jul 2014 08:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDcVKy1gv4O2 for ; Thu, 24 Jul 2014 08:33:33 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283111A02D6 for ; Thu, 24 Jul 2014 08:33:29 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id j15so3142498qaq.1 for ; Thu, 24 Jul 2014 08:33:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hsmlAG3oGuNMr2X13BqOY1QtHdw4Fa+NZeNO4foicJA=; b=Bq8mO/HeoHMQj15MArBdImDKm2zG2E+yo0tvP0Sl0ySO8WiGHmW5sCVGxBQBH9NYKD TTq14gg8/RBbakg9RqmPOIgiNRJXGHxiex4klsjZrVeQ4cMLwgQyZo3wD/2vQxkrCnfK FIo93dOHen1/cfMtThIqa3Lr3lAWJX55vVGsltAKOIGj609QmCSzA6xTTaQ/n9AlQyGM 8wsMjOdE6rRMIKIUaSFLYusGbhFc/ZElr0kHQj7ejimKF39OUwCwDKzPM1M0IwrpbSs/ ND+OhmjHU8AXZ6t0ZEVzSURkT0q19tfn9o/QzyynCkqqaLecB2k/uMNaIQITlF9pmCgI SH2Q==
X-Gm-Message-State: ALoCoQnJLGB42TcLpeO8NHPVJsfvhLch+y/uVsOqYedD9UHV7cFW9XNP+2hR1pfXKAiAb2gcZV0f
X-Received: by 10.224.131.71 with SMTP id w7mr16006022qas.91.1406216008278; Thu, 24 Jul 2014 08:33:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 24 Jul 2014 08:33:08 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>     
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Jul 2014 17:33:08 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Vvz8GK7pMi2_pAQ7OkvJA6sN1BQ
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 15:33:36 -0000

2014-07-24 17:15 GMT+02:00 Emil Ivov :
>> The ICE server should select the request
>> with highest PRIORITY
>
> I am not sure what you mean by ICE server.

The ICE agent receiving the requests. Imagine a ICE-Lite server which
is just a "server".


>> regardless it receives later a new one with less
>> PRIORITY. This is clear in the RFC. And this is because it is supposed
>> that both peers agree on selecting the request-response with higher
>> PRIORITY, regardless which one arrives before.
>
> This is not true for regular nomination where the nominated candidate
> is chosen solely based on the USE-CANDIDATE option.

I just mean aggressive nomination.



>> This makes sense. Let's assume requests come in this order:
>>
>> 1)
>>
>>    Req1-good-connection PRIORITY: 9000  -->
>>    Req2-bad-connection PRIORITY: 1000  -->
>>
>> should the server chose Req2? not at all.
>>
>> 2)
>>
>>    Req2-bad-connection PRIORITY: 1000  -->
>>    Req1-good-connection PRIORITY: 9000  -->
>>
>> server should choose Req1 once it arrives.
>
> I think you are confusing multiple received USE-CANDIDATE options for
> *different* candidate pairs (which is what happens with aggressive
> nomination) with receiving a second USE-CANDIDATE option for *the
> same* candidate pair.


Humm, not :)

- ICE-Lite servers opens UDP socket in ports 1111 and 2222.

- Client sends:

  ICE-Req-1 USE_CANDIDATE PRIORITY 555  -->  port 1111
and later:
  ICE-Req-2 USE_CANDIDATE PRIORITY 666  -->  port 2222

I just mean that in this case the ICE-Lite server must first select
Req1--1111 pair and then move to Req2--2222 pair.

But in this case:

  ICE-Req-1 USE_CANDIDATE PRIORITY 666  -->  port 1111
and later:
  ICE-Req-2 USE_CANDIDATE PRIORITY 555  -->  port 2222

the ICE-Lite server must first select Req1--1111 pair and would NOT
move to Req1--2222 pair.






--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 24 08:46:20 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA51A02D6 for ; Thu, 24 Jul 2014 08:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaImwO03KsnM for ; Thu, 24 Jul 2014 08:46:13 -0700 (PDT)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FF91A0350 for ; Thu, 24 Jul 2014 08:46:08 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so2829153wgh.21 for ; Thu, 24 Jul 2014 08:46:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xGzXjPsjMvDa8oE4JuQxfwFxbGARgGl2Qd1YVnVVGCM=; b=FnLknmrqX2aOcJIxWbHF/wZ91AXY5XRYwUyY0oxLbA+aILW4xPO8YjbAsJFimHiJoF W3ysTPDdE42AWW0VxTjSV7g9v/Q1pX+jLH6U3BarURak/yoQdPE5KfWCYjzENUVa+6Ps KUxmvA7Ot0X7aY1Ud0jYVTeqEUxYQEm7wGrdfMKQkKc5ALS4gIkpLOoeGRt4uRwBZYki D3lGv39BfPEVznSuKF/ca7d8wtIqRRXu6rmD6voSc/SQCP+geHFt6SOPd8hbA315Ky3M rZ/pw/ic+eQ/u9botWSexFlI5e9o/i3Yv4q3ljQX9WElMG3jZXdQqY/WsDT52EAWlbMh 5qeQ==
X-Gm-Message-State: ALoCoQnXn+tDCTekXZlImrXkZ8V2gjGfbUCFS65pIkKSRPjnH9GFHHitiicAjVcmMWIGc86eCRz7
X-Received: by 10.194.7.36 with SMTP id g4mr13490582wja.37.1406216765407; Thu, 24 Jul 2014 08:46:05 -0700 (PDT)
Received: from dhcp-8034.meeting.ietf.org (dhcp-8034.meeting.ietf.org. [31.133.128.52]) by mx.google.com with ESMTPSA id fu7sm24156413wib.2.2014.07.24.08.46.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 08:46:04 -0700 (PDT)
Message-ID: <53D12A3A.4080808@jitsi.org>
Date: Thu, 24 Jul 2014 11:46:02 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>      
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dEiYTPDalA_QARoyR1uTIE_Gb3s
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 15:46:18 -0000

On 24.07.14, 11:33, Iñaki Baz Castillo wrote:
> 2014-07-24 17:15 GMT+02:00 Emil Ivov :
>>> The ICE server should select the request
>>> with highest PRIORITY
>>
>> I am not sure what you mean by ICE server.
>
> The ICE agent receiving the requests.  Imagine a ICE-Lite server which
> is just a "server".

Well ok, but an ICE lite agent doesn't really get to select anything. It 
just has to try and understand what the controlling agent has selected. 
Currently it would do that based on priority but this is suboptimal. 
That's what we are trying to improve.

>>> regardless it receives later a new one with less
>>> PRIORITY. This is clear in the RFC. And this is because it is supposed
>>> that both peers agree on selecting the request-response with higher
>>> PRIORITY, regardless which one arrives before.
>>
>> This is not true for regular nomination where the nominated candidate
>> is chosen solely based on the USE-CANDIDATE option.
>
> I just mean aggressive nomination.
>
>
>
>>> This makes sense. Let's assume requests come in this order:
>>>
>>> 1)
>>>
>>>     Req1-good-connection PRIORITY: 9000  -->
>>>     Req2-bad-connection PRIORITY: 1000  -->
>>>
>>> should the server chose Req2? not at all.
>>>
>>> 2)
>>>
>>>     Req2-bad-connection PRIORITY: 1000  -->
>>>     Req1-good-connection PRIORITY: 9000  -->
>>>
>>> server should choose Req1 once it arrives.
>>
>> I think you are confusing multiple received USE-CANDIDATE options for
>> *different* candidate pairs (which is what happens with aggressive
>> nomination) with receiving a second USE-CANDIDATE option for *the
>> same* candidate pair.
>
>
> Humm, not :)

Getting multiple USE-CANDIDATES on *different* candidates is simply the 
definition of aggressive nomination. We are not discussing this.

The "second" USE-CANDIDATE that mails in this thread have referred to 
was about the possibility to do a second USE-CANDIDATE on the *same* 
pair as an indication for selecting that candidate. Neither of your 
examples below display this.

> - ICE-Lite servers opens UDP socket in ports 1111 and 2222.
>
> - Client sends:
>
>    ICE-Req-1 USE_CANDIDATE PRIORITY 555  -->  port 1111
> and later:
>    ICE-Req-2 USE_CANDIDATE PRIORITY 666  -->  port 2222
>
> I just mean that in this case the ICE-Lite server must first select
> Req1--1111 pair and then move to Req2--2222 pair.
>
> But in this case:
>
>    ICE-Req-1 USE_CANDIDATE PRIORITY 666  -->  port 1111
> and later:
>    ICE-Req-2 USE_CANDIDATE PRIORITY 555  -->  port 2222
>
> the ICE-Lite server must first select Req1--1111 pair and would NOT
> move to Req1--2222 pair.


The point is that, once the two checks above succeed, the controlling 
agent may choose to send an additional *third* request on *any* of the 
two in order to communicate its desire to use that candidate pair.

This may be the higher priority candidate pair or it may be another one 
(e.g., if it gave a better RTT) and its choice would depend on the 
controlling agent.

Is it clearer now?

Emil

-- 
https://jitsi.org


From nobody Thu Jul 24 08:48:27 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED971A03D2 for ; Thu, 24 Jul 2014 08:48:18 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6okiwtMtuTK for ; Thu, 24 Jul 2014 08:48:14 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1781A03D0 for ; Thu, 24 Jul 2014 08:48:13 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 54EA31EB855F; Thu, 24 Jul 2014 17:48:12 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 24 Jul 2014 17:48:12 +0200
From: "Stach, Thomas" 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] ICE and the "unexpected answer" problem
Thread-Index: Ac+mbaDUMIq2nv4JQ7KZBsyANFFFPgAcf82AABSSxUA=
Date: Thu, 24 Jul 2014 15:48:10 +0000
Message-ID: 
References:  <53D07F21.1030807@alum.mit.edu>
In-Reply-To: <53D07F21.1030807@alum.mit.edu>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_HDG4Qso7e5hqyjTa9yoSLqx7Xs
Subject: Re: [MMUSIC] ICE and the "unexpected answer" problem
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 15:48:18 -0000

Paul,

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Mittwoch, 23. Juli 2014 23:36
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] ICE and the "unexpected answer" problem
>=20
> Thomas,
>=20
> On 7/23/14 8:00 AM, Stach, Thomas wrote:
> > ICE experts,
> >
> > we came across the following situation that has some relation to ICE
> > restart procedures.
> >
> > Consider that A calls B via a B2BUA. Both A and B support ICE and have
> > successfully finished ICE procedures though the B2BUA is ICE-unaware.
> >
> > Now after a while either A or B sends out a new offer to put the other
> > party on hold (a=3Dinactive) without indicating an ICE restart.
> >
> > It includes the in-use candidates and the remote-candidates as required
> > by section 9 of RFC5245 and expects to get the remote-candidates
> > reflected in the answer.
> >
> > However, the B2BUA in the signaling path introduces via some 3PCC means
> > a media server that provides MoH to the Held UA.
>=20
> Not too unusual.
>=20
> > On the call-leg towards the Holding UA, the B2BUA sends back some dummy
> > answer that fulfills RFC3264 requirements (e.g. includes a=3Dinactive) =
but
> > does not include the expected remote-candidates.
>=20
> Can you provide details of the offers and answers?
>=20
> If it is going to provide MoH then presumably it isn't setting the media
> inactive. (Or is it doing MoH on audio and setting video inactive?)
>=20
> Note that once the call goes off hold all this will happen again to get
> back to the actual device again.
[TS] I could give details about the settings of direction attribute to a=3D=
sendrecv/inactive/sendonly, but that is not the issue I want to clarify.

I want to get clarification for the situation when due to an offer/answer e=
xchange during an active dialog the support for ICE is removed (or added ba=
ck again).=20
In case of an ICE restart section 9.1.1.1 of RFC5245 has some words that me=
ntion changes of implementation level.
However, the case, where the implementation level changed outside of an ICE=
 restart, is not covered.
E.g. in this MoH case, the offer was sent with the in-use candidates, but t=
he answer did no longer include ice-ufrag/ice-pwd/candidates.
An implementation could have decided in such a situation to abandon the cal=
l or stop ICE for the rest of call.=20
I think both would be bad.
It would be better just to do an ICE restart once the next offer is being s=
ent.=20
In the MoH case  it would be OK to do that when the call is put off hold ag=
ain,=20
i.e. it wouldn't be necessary to do the restart immediately.
Regards
Thomas


>=20
> 	Thanks,
> 	Paul
>=20
> > The Holding UA was unaware of the B2BUA's interference, but now gets an
> > "unexpected answer" to its hold offer.
> >
> > Of course there could al                so exist other similar
> > situations where the peer changes mid-call and the offerer receives som=
e
> > "unexpected" answer. If we take RFC3264 into consideration, an offerer
> > would need to be prepared to receive such an "unexpected" answer.
> >
> > But with respect to ICE procedures there is no guidance what to do next=
,
> > although http://tools.ietf.org/html/rfc5245#section-9.1.1.1 talks
> > already about Hold and ICE restarts.
> >
> > However, it does not cover the above situation.
> >
> > Would it be justified to include some clarification e.g.  into
> > rfc5245bis or draft-ietf-mmusic-ice-sip-sdp that something like the
> > above could happen and even give some suggestions when/how to perform
> > ICE restart?
> >
> > Such suggestion could look roughly as follows:
> >
> > The UA that got the "unexpected answer" would have to do an ICE restart
> > in order to get things straight again once it sends out its next offer.
> >
> > In the above situation It would be sufficient when the Holding UA
> > performs the ICE restart once it reconnects to the Held UA,
> >
> > i.e. it would not be necessary to do the ICE restart immediately
> > although in other situations that might be justified.
> >
> > In yet other situations there might even be an ICE restart performed
> > from the peer, that sent the "unexpected answer".
> >
> > Any thoughts/comments?
> >
> > If people agree I would also be happy to contribute corresponding text.
> >
> > Regards
> >
> > Thomas
> >
> >
> >
> > _______________________________________________
> > 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 nobody Thu Jul 24 10:17:46 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3431A0ACE for ; Thu, 24 Jul 2014 10:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12QV2xyAR9sI for ; Thu, 24 Jul 2014 10:17:34 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFB51A0AD3 for ; Thu, 24 Jul 2014 10:17:19 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hu12so5441978vcb.28 for ; Thu, 24 Jul 2014 10:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ncDMgiTpzDQkc6R7buAGLX0cqA4fk1HetKLRuBpGce8=; b=MgBM/WGTeIhusXbwI9r9hxQhYZ3KljtMX+B17Ys53eynnSDXN0Nbco0rzRhGsMlMin P/S2751DXNjcUDKur1/4HAH5mTuX/nKvPIBAGgtKElZf/YT+wJp8k78LhflwuAsNtqkK ibPkVoDAFwMEjQaIwo6CCTPGvO3TK7nhKReHuFdwRQPquGLavdKmw+dimCl5ndMbMNYY J9u4hJw4y2CQ4eHsnIvBg4JPCnHYsxOJc3yL3TbbBYTQ5diYlwVbhHNkmdNmQmns88xc 23uIMkMPndXZK4/qmHHQA23zS6z4ArmZxJMHxFTwtHQgkHBKuk0Us0mdMHl3xq4QAQWF A5ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ncDMgiTpzDQkc6R7buAGLX0cqA4fk1HetKLRuBpGce8=; b=eZ023E5Vz0o4419NdU+2OjIQM8RVM+M70Q5zjRkw+j+TrmQc7e0CoCZxszdQ1/p8qL JEAVPvN/XqzVgIE40pmi1mx4FpY8R9U6aYUSgNxjKKTu9bsf6oVWzRxuiDiExoinw+7t QGEzKmL0MexRJaK2Qz1Y22H3LO3olVZK+jcbk3F1Ai7gZjzdfrfq67NStkBkQlnyHIL5 CPF1skWSGt+sQP+d3dbYlm2qsKDVwGIvnFNvQNAdmmDQhabF51UQ8cCr38K4k+KAprl4 QucFvVp7eG8hZOdyAEaiYUTRiQDDElHEnYNXPG27lVAVNYOEblm3m5M7OsZYt7t1GI+7 /sxw==
X-Gm-Message-State: ALoCoQkX8MLUBAaAPLZc3Dn9Dy3RGHCozozoVfL3SgM5e6X1uv2ufA51gMNLXW4xprU8Fn769zp7
X-Received: by 10.221.44.69 with SMTP id uf5mr14598270vcb.4.1406222238234; Thu, 24 Jul 2014 10:17:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 10:16:58 -0700 (PDT)
In-Reply-To: <53D12A3A.4080808@jitsi.org>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>       <53D12A3A.4080808@jitsi.org>
From: Justin Uberti 
Date: Thu, 24 Jul 2014 13:16:58 -0400
Message-ID: 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=001a11339e88fc567f04fef3a0d8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-eRrYNpaZEX3Pad0H7Ox9rIihCI
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 17:17:36 -0000

--001a11339e88fc567f04fef3a0d8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The PRIORITY attribute is only for determining priority for peer-reflexive
candidates. Using it to change priority for other types of candidates would
be a significant change in semantics; I don't want to go there.


On Thu, Jul 24, 2014 at 11:46 AM, Emil Ivov  wrote:

>
>
> On 24.07.14, 11:33, I=C3=B1aki Baz Castillo wrote:
>
>> 2014-07-24 17:15 GMT+02:00 Emil Ivov :
>>
>>> The ICE server should select the request
>>>> with highest PRIORITY
>>>>
>>>
>>> I am not sure what you mean by ICE server.
>>>
>>
>> The ICE agent receiving the requests.  Imagine a ICE-Lite server which
>> is just a "server".
>>
>
> Well ok, but an ICE lite agent doesn't really get to select anything. It
> just has to try and understand what the controlling agent has selected.
> Currently it would do that based on priority but this is suboptimal. That=
's
> what we are trying to improve.
>
>
>  regardless it receives later a new one with less
>>>> PRIORITY. This is clear in the RFC. And this is because it is supposed
>>>> that both peers agree on selecting the request-response with higher
>>>> PRIORITY, regardless which one arrives before.
>>>>
>>>
>>> This is not true for regular nomination where the nominated candidate
>>> is chosen solely based on the USE-CANDIDATE option.
>>>
>>
>> I just mean aggressive nomination.
>>
>>
>>
>>  This makes sense. Let's assume requests come in this order:
>>>>
>>>> 1)
>>>>
>>>>     Req1-good-connection PRIORITY: 9000  -->
>>>>     Req2-bad-connection PRIORITY: 1000  -->
>>>>
>>>> should the server chose Req2? not at all.
>>>>
>>>> 2)
>>>>
>>>>     Req2-bad-connection PRIORITY: 1000  -->
>>>>     Req1-good-connection PRIORITY: 9000  -->
>>>>
>>>> server should choose Req1 once it arrives.
>>>>
>>>
>>> I think you are confusing multiple received USE-CANDIDATE options for
>>> *different* candidate pairs (which is what happens with aggressive
>>> nomination) with receiving a second USE-CANDIDATE option for *the
>>> same* candidate pair.
>>>
>>
>>
>> Humm, not :)
>>
>
> Getting multiple USE-CANDIDATES on *different* candidates is simply the
> definition of aggressive nomination. We are not discussing this.
>
> The "second" USE-CANDIDATE that mails in this thread have referred to was
> about the possibility to do a second USE-CANDIDATE on the *same* pair as =
an
> indication for selecting that candidate. Neither of your examples below
> display this.
>
>
>  - ICE-Lite servers opens UDP socket in ports 1111 and 2222.
>>
>> - Client sends:
>>
>>    ICE-Req-1 USE_CANDIDATE PRIORITY 555  -->  port 1111
>> and later:
>>    ICE-Req-2 USE_CANDIDATE PRIORITY 666  -->  port 2222
>>
>> I just mean that in this case the ICE-Lite server must first select
>> Req1--1111 pair and then move to Req2--2222 pair.
>>
>> But in this case:
>>
>>    ICE-Req-1 USE_CANDIDATE PRIORITY 666  -->  port 1111
>> and later:
>>    ICE-Req-2 USE_CANDIDATE PRIORITY 555  -->  port 2222
>>
>> the ICE-Lite server must first select Req1--1111 pair and would NOT
>> move to Req1--2222 pair.
>>
>
>
> The point is that, once the two checks above succeed, the controlling
> agent may choose to send an additional *third* request on *any* of the tw=
o
> in order to communicate its desire to use that candidate pair.
>
> This may be the higher priority candidate pair or it may be another one
> (e.g., if it gave a better RTT) and its choice would depend on the
> controlling agent.
>
> Is it clearer now?
>
> Emil
>
> --
> https://jitsi.org
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--001a11339e88fc567f04fef3a0d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The PRIORITY attribute is only for determining priority fo=
r peer-reflexive candidates. Using it to change priority for other types of=
 candidates would be a significant change in semantics; I don't want to=
 go there.





On Thu, Jul 2=
4, 2014 at 11:46 AM, Emil Ivov <emcho@jitsi.org> wrote:







On 24.07.14, 11:33, I=C3=B1aki Baz Castillo wrote:



2014-07-24 17:15 GMT+02:00 Emil Ivov <emcho@jitsi.org>:



The ICE server should select the request

with highest PRIORITY





I am not sure what you mean by ICE server.





The ICE agent receiving the requests. =C2=A0Imagine a ICE-Lite server which=


is just a "server".





Well ok, but an ICE lite agent doesn't really get to select anything. I=
t just has to try and understand what the controlling agent has selected. C=
urrently it would do that based on priority but this is suboptimal. That=
9;s what we are trying to improve.










regardless it receives later a new one with less

PRIORITY. This is clear in the RFC. And this is because it is supposed

that both peers agree on selecting the request-response with higher

PRIORITY, regardless which one arrives before.





This is not true for regular nomination where the nominated candidate

is chosen solely based on the USE-CANDIDATE option.





I just mean aggressive nomination.









This makes sense. Let's assume requests come in this order:



1)



=C2=A0 =C2=A0 Req1-good-connection PRIORITY: 9000 =C2=A0-->

=C2=A0 =C2=A0 Req2-bad-connection PRIORITY: 1000 =C2=A0-->



should the server chose Req2? not at all.



2)



=C2=A0 =C2=A0 Req2-bad-connection PRIORITY: 1000 =C2=A0-->

=C2=A0 =C2=A0 Req1-good-connection PRIORITY: 9000 =C2=A0-->



server should choose Req1 once it arrives.





I think you are confusing multiple received USE-CANDIDATE options for

*different* candidate pairs (which is what happens with aggressive

nomination) with receiving a second USE-CANDIDATE option for *the

same* candidate pair.







Humm, not :)





Getting multiple USE-CANDIDATES on *different* candidates is simply the def=
inition of aggressive nomination. We are not discussing this.



The "second" USE-CANDIDATE that mails in this thread have referre=
d to was about the possibility to do a second USE-CANDIDATE on the *same* p=
air as an indication for selecting that candidate. Neither of your examples=
 below display this.








- ICE-Lite servers opens UDP socket in ports 1111 and 2222.



- Client sends:



=C2=A0 =C2=A0ICE-Req-1 USE_CANDIDATE PRIORITY 555 =C2=A0--> =C2=A0port 1=
111

and later:

=C2=A0 =C2=A0ICE-Req-2 USE_CANDIDATE PRIORITY 666 =C2=A0--> =C2=A0port 2=
222



I just mean that in this case the ICE-Lite server must first select

Req1--1111 pair and then move to Req2--2222 pair.



But in this case:



=C2=A0 =C2=A0ICE-Req-1 USE_CANDIDATE PRIORITY 666 =C2=A0--> =C2=A0port 1=
111

and later:

=C2=A0 =C2=A0ICE-Req-2 USE_CANDIDATE PRIORITY 555 =C2=A0--> =C2=A0port 2=
222



the ICE-Lite server must first select Req1--1111 pair and would NOT

move to Req1--2222 pair.







The point is that, once the two checks above succeed, the controlling agent=
 may choose to send an additional *third* request on *any* of the two in or=
der to communicate its desire to use that candidate pair.



This may be the higher priority candidate pair or it may be another one (e.=
g., if it gave a better RTT) and its choice would depend on the controlling=
 agent.



Is it clearer now?



Emil



-- 

https://jitsi.org




_______________________________________________

mmusic mailing list

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





--001a11339e88fc567f04fef3a0d8--


From nobody Thu Jul 24 17:21:23 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD21A0AAA for ; Thu, 24 Jul 2014 17:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG1HVfWAMGnM for ; Thu, 24 Jul 2014 17:21:17 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99181A0537 for ; Thu, 24 Jul 2014 17:21:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=527; q=dns/txt; s=iport; t=1406247677; x=1407457277; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2N69qqMnch/4OtkmeN7M9uHz4N4wKzbTg+kCX4ar9cM=; b=gr/lK3V7xuoA9UwmvZcxv3kosi1y1fP/5Yz+GaDvP5aAv0XhpkTsSj6c bPKNALeJ/k2msLq9mxA5sWg7DR4AMxoVECQz1EKApsM1tFxbBsFIIa5a+ Zazjr6k5FU36Uksz9x6duWA/fU3WYHd8JKsqJvg/PaQ3dZsrpNIykCrkA c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAISi0VOtJA2D/2dsb2JhbABZgw6BLdIUFneECg5XJgGBACcEiFWZC6ZhF5MAgRgFii+RB5RFg0iCMQ
X-IronPort-AV: E=Sophos;i="5.01,727,1400025600"; d="scan'208";a="339586240"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2014 00:21:17 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6P0LHav011816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Jul 2014 00:21:17 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 19:21:16 -0500
From: "Pal Martinsen (palmarti)" 
To: mmusic 
Thread-Topic: ICEbis and IPv6 Privacy adresses
Thread-Index: AQHPp55ZTl0zyXBggEqaFOjjxZApug==
Date: Fri, 25 Jul 2014 00:21:16 +0000
Message-ID: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.165.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/JiV_1s_3wgwVDfnC_Yk09IqVuDk
Subject: [MMUSIC] ICEbis and IPv6 Privacy adresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 00:21:21 -0000

Hi,

I think we need some text in ICEbis saying that if IPv6 Privacy addresses i=
s in use, some care should be taken not to expose too many of the other pot=
ential candidates you have.=20

Can you reveal your IPv4 host address?
What about SRFX and RELAY adresses?=20
Do we need an TURN extension to ask the TURN server to also use a IPv6 priv=
acy address when allocation a REALY address for you?

Seems to be problematic to find the right balance between privacy and ensur=
ed connectivity.

.-.
P=E5l-Erik=


From nobody Thu Jul 24 19:33:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5491A0AD3 for ; Thu, 24 Jul 2014 19:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCCDiUJpZMwj for ; Thu, 24 Jul 2014 19:33:33 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE141A0AC8 for ; Thu, 24 Jul 2014 19:33:33 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id ij19so6204950vcb.25 for ; Thu, 24 Jul 2014 19:33:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6Hoe9b/f227LBWdwxY136DI0ROroFbfkSdHchL5ajVM=; b=cKiU8Fof1LteqO78pLiG5JhB+MNvpcNm+HIq18zW2n0Zdp7OgBlOtrIdAJnyLhZvEv 2td02twiNJdbiDNtEaDs1zePyuTBdv3iyWBA2sJhudG9jQICTHiJD/S1OuK2kBbM++Do 8905986oWgJ2bD/9L7b+z7yQ0E9frtetA4PAqLnl9SftaC9IJ5om9Zg4aMyEDI36w1Uy 5eeidC2iqPEfRrb1rCRJrq2PfMKvRPAbaq7ABubhPGmZ1S59DUYXgfPsuZ4Ya9lQ2NP1 Cm057a5Q6a8q4bvn7vNBOt1L5qLcwEZkzcooUxDoiCQGszj3DKsOno7fhKu6s8QWxuR6 SdBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6Hoe9b/f227LBWdwxY136DI0ROroFbfkSdHchL5ajVM=; b=Zmwea2Mb+5Sjab7zp1hupoyb8JuZ6P5qFjLW6QTAjUthMBHRfrSp9k0xt0a3sU8n34 x2evy7ePZgaUi/yDZkIfx+iAck8kF6SvoOeaCXQ2B3w4+FjuVtH6NMy1M2zYaDEIhzTH CqNND2DdJXHfks1h6wsF/3LzM7SVsphyyrcw1lo/wxTXaNBdmeKNaawR/Mjisd81BPp9 fM0ddEKrbzkOgS8N/RZikjkIWWc3gqT3no8hkuY5+BL4bZHs6fLRfHH7Gb7+hn4k2iRK WdY7wLWNJVossi6pAyKLEzIV7gJ2NI0ojDu5HVhdM0neLY3vNQEZBDaYe6fLuoBE9HQo mWMg==
X-Gm-Message-State: ALoCoQm490XMYYt/q9KbyAqbguDqOx3M3ErPU66OX1Zj9/t5b5S+uPkXuCofkhQv9ZD/eLBv3gHG
X-Received: by 10.52.35.81 with SMTP id f17mr14802169vdj.13.1406255612498; Thu, 24 Jul 2014 19:33:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 19:33:12 -0700 (PDT)
In-Reply-To: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com>
References: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com>
From: Justin Uberti 
Date: Thu, 24 Jul 2014 22:33:12 -0400
Message-ID: 
To: "Pal Martinsen (palmarti)" 
Content-Type: multipart/alternative; boundary=20cf307ac7893f343804fefb6622
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SqDsosz73LyUQsrcxyG_0Znf5zI
Cc: mmusic 
Subject: Re: [MMUSIC] ICEbis and IPv6 Privacy adresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 02:33:34 -0000

--20cf307ac7893f343804fefb6622
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I believe the point of temporary addresses is to prevent tracking, not to
prevent computing an approximate location. Therefore I don't think we need
to do anything about the other (non-trackable) addresses.


On Thu, Jul 24, 2014 at 8:21 PM, Pal Martinsen (palmarti) <
palmarti@cisco.com> wrote:

> Hi,
>
> I think we need some text in ICEbis saying that if IPv6 Privacy addresses
> is in use, some care should be taken not to expose too many of the other
> potential candidates you have.
>
> Can you reveal your IPv4 host address?
> What about SRFX and RELAY adresses?
> Do we need an TURN extension to ask the TURN server to also use a IPv6
> privacy address when allocation a REALY address for you?
>
> Seems to be problematic to find the right balance between privacy and
> ensured connectivity.
>
> .-.
> P=C3=A5l-Erik
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--20cf307ac7893f343804fefb6622
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I believe the point of temporary addresses is to prevent t=
racking, not to prevent computing an approximate location. Therefore I don&=
#39;t think we need to do anything about the other (non-trackable) addresse=
s.





On Thu, Jul 24, 2014 at 8:21 PM, Pal Mar=
tinsen (palmarti) <palmarti@cisco.com> wrote:



Hi,



I think we need some text in ICEbis saying that if IPv6 Privacy addresses i=
s in use, some care should be taken not to expose too many of the other pot=
ential candidates you have.



Can you reveal your IPv4 host address?

What about SRFX and RELAY adresses?

Do we need an TURN extension to ask the TURN server to also use a IPv6 priv=
acy address when allocation a REALY address for you?



Seems to be problematic to find the right balance between privacy and ensur=
ed connectivity.



.-.

P=C3=A5l-Erik

_______________________________________________

mmusic mailing list

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





--20cf307ac7893f343804fefb6622--


From nobody Fri Jul 25 05:11:15 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2A91B2825; Fri, 25 Jul 2014 05:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaeSIFhNKo_K; Fri, 25 Jul 2014 05:11:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB81B2820; Fri, 25 Jul 2014 05:11:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140725121108.30107.3817.idtracker@ietfa.amsl.com>
Date: Fri, 25 Jul 2014 05:11:08 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/H92l0NkKKUP2GDnBgOl4D-vkqoQ
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-sip-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 12:11:10 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : A Session Initiation Protocol (SIP) usage for Trickle ICE
        Authors         : Emil Ivov
                          Enrico Marocco
                          Christer Holmberg
	Filename        : draft-ietf-mmusic-trickle-ice-sip-00.txt
	Pages           : 21
	Date            : 2014-07-24

Abstract:
   The Interactive Connectivity Establishment (ICE) protocol describes a
   Network Address Translator (NAT) traversal mechanism for UDP-based
   multimedia sessions established with the offer/answer model.  The ICE
   extension for Incremental Provisioning of Candidates (Trickle ICE)
   defines a mechanism that allows ICE agents to shorten session
   establishment delays by making the candidate gathering and
   connectivity checking phases of ICE non-blocking and by executing
   them in parallel.

   This document defines usage semantics for Trickle ICE with the
   Session Initiation Protocol (SIP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jul 25 05:39:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BED1B2820 for ; Fri, 25 Jul 2014 05:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-ygGoaIYqqd for ; Fri, 25 Jul 2014 05:39:32 -0700 (PDT)
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98221A0028 for ; Fri, 25 Jul 2014 05:39:31 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q58so4089857wes.7 for ; Fri, 25 Jul 2014 05:39:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1mtAs8y0sjm2Nv33z27Ynu5AsqnUHpELaoLlTu+g7mc=; b=LvgEcqmKqChqYiqD93zYutTqxORFS80axGTvocmP3a7n3yEEzkTe7FAJwFceUANOGK /+AKtt7pZ9lfJA1ARK2cT1UXc4knCilYaV9bAxhNkCGcCvrqszFHOSaIT4M4rfxPPBTU PM0PbLI4Xynhw0B+s8lIgVIGnDFRBTW4UK8tThBsWHbSxIw0xAclKmIOIc9iNHC9Nnu9 VQbs/Qtz8u+u8gyA1Md4NXFV75ggZ0AangPS2+PE4eZ392HKxZdZVMsNuscqe1iO8RLT xl/f7KFrI8LzSOxRDzFapusSrVOOJ0z2JVKvZxbxrM6Q6+jreGxVoD+XM9tnC86HAuoQ bz2g==
X-Gm-Message-State: ALoCoQm5yOwI4FZFlc0H3kAIY4ijo8i7rlWx6tiNE1Et2WVwqiiczmUUpFB2CaPYSOx1Ta1HR+oX
X-Received: by 10.194.95.132 with SMTP id dk4mr3833138wjb.72.1406291968837; Fri, 25 Jul 2014 05:39:28 -0700 (PDT)
Received: from porto.nomis80.org ([2001:67c:1231:998:9dec:20b7:9edc:fe13]) by mx.google.com with ESMTPSA id ed14sm5528880wic.10.2014.07.25.05.39.27 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 05:39:28 -0700 (PDT)
Message-ID: <53D24FFE.1040802@jive.com>
Date: Fri, 25 Jul 2014 08:39:26 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2c0gZ7fFZZV4j0wfrI6SZZsagdA
Subject: Re: [MMUSIC] ICEbis and IPv6 Privacy adresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 12:39:34 -0000

Le 2014-07-24 22:33, Justin Uberti a crit :
> I believe the point of temporary addresses is to prevent tracking, not
> to prevent computing an approximate location. Therefore I don't think we
> need to do anything about the other (non-trackable) addresses.

Uh? Other addresses *are* trackable, that's the whole point.

The addresses I have right now:

>     inet6 2001:67c:1231:998:9dec:20b7:9edc:fe13/64 scope global temporary dynamic 
>        valid_lft 604798sec preferred_lft 604798sec
>     inet6 2001:67c:1231:998:8e70:5aff:fec5:72e4/64 scope global dynamic 
>        valid_lft 2591999sec preferred_lft 2591999sec
>     inet6 fe80::8e70:5aff:fec5:72e4/64 scope link 
>        valid_lft forever preferred_lft forever

Only the privacy address is not trackable. The other two have fixed
lower 64 bits.

I think Pl's request makes a lot of sense for host candidates.
Server-reflexive and relayed candidates don't matter as they are not
trackable. Asking a TURN server to use a temporary address doesn't make
sense either IMHO.

Therefore, proposed text:

If one or more host candidates corresponding to IPv6 privacy addresses
are advertised, host candidates corresponding to other kinds of IPv6
addresses on the same interface MUST NOT be advertised.

Simon


From nobody Fri Jul 25 07:25:28 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0605C1B2828 for ; Fri, 25 Jul 2014 07:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjiWdrtZFRjn for ; Fri, 25 Jul 2014 07:25:24 -0700 (PDT)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157211B2968 for ; Fri, 25 Jul 2014 07:25:08 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id k14so4272034wgh.8 for ; Fri, 25 Jul 2014 07:25:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cXAZmdoKq8tGufKrtzAcKQFt+Wm7nXQesd2eLhUMx1k=; b=lHLrYp+ZKyE5b5TXY9zH29/kB1EZc5JbsGpBZjsnH7+ZN0qHoM+fVlzTee86XtZ3be jusDPY1hmhcRx24zxfGswlw6fxlCMkeP2ilF2+TJADrawzjjOYJO/3UmhlLUzmN697Rs BfKRFLBk+Os62BRyP81z2dzDwZ2e0bYNZUPBs5+nzeZH/08MKpFbuKfLAGZomlxnbvc6 t2M30Yn7gAV8R4bHChHYwpzg4aEUrOmALbyADMnLsK8mYdf30RN/SNujMSRMQFWBeQVT M2gaPHHa62zv9mh3PmUT3jqIywqMudJpI3wqW9VCV0LpNMVEnJQ91AMKEe8Zckx7cZY2 eYBw==
X-Gm-Message-State: ALoCoQkE4QDMdiUpLxh1uI2wj4y0S91nvNVSaxE1wyyKjZdtIdeHiTgmGeBgU83+T39kAHZN/dct
X-Received: by 10.180.89.143 with SMTP id bo15mr5596258wib.78.1406298307122; Fri, 25 Jul 2014 07:25:07 -0700 (PDT)
Received: from porto.nomis80.org ([2001:67c:1231:998:9dec:20b7:9edc:fe13]) by mx.google.com with ESMTPSA id h3sm25665159wjz.48.2014.07.25.07.25.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 07:25:06 -0700 (PDT)
Message-ID: <53D268C0.1070604@jive.com>
Date: Fri, 25 Jul 2014 10:25:04 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com>  <53D24FFE.1040802@jive.com>
In-Reply-To: <53D24FFE.1040802@jive.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dsw2Mgi39k5FwlFMd8O-acS3bsM
Subject: Re: [MMUSIC] ICEbis and IPv6 Privacy adresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:25:27 -0000

Le 2014-07-25 08:39, Simon Perreault a crit :
> Therefore, proposed text:
> 
> If one or more host candidates corresponding to IPv6 privacy addresses
> are advertised, host candidates corresponding to other kinds of IPv6
> addresses on the same interface MUST NOT be advertised.

Updated text, per today's live discussion:

If one or more host candidates corresponding to IPv6 privacy addresses
are advertised, host candidates corresponding to other kinds of IPv6
addresses on the same interface and having the same network prefix MUST
NOT be advertised.

Simon


From nobody Fri Jul 25 07:43:13 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14D1B2983 for ; Fri, 25 Jul 2014 07:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGxeOVkS9Zpi for ; Fri, 25 Jul 2014 07:43:09 -0700 (PDT)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E211A037C for ; Fri, 25 Jul 2014 07:43:09 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so4287333wgg.31 for ; Fri, 25 Jul 2014 07:43:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gFAMez7CiijB06CCa3pssaoRe1tsucdm9UdP1kiSEZ0=; b=eBPlnXPF6Snx8NAVsyOYoDU/ZtB4zFacqJE+pdx/gdryW+CTF7BmeDHvS/DcVJAodn /+GKbXjEnnEeuegKS7EkjWP6z6xnRMKOsPT7Ms43XNEC+Mab0cI+/EIdhtd6ZC+juA8B TK/UPs82mwjjGV2TjA+nEeA3q+RxTGeHML+Z/S1ODFgpLHBCr7COaZ90S2C+ZbS/tfN2 w1nslZ+FqBVj+/XZcjGcCWlyWVyMN7iYNr9pFi7Q1SbweAL+RJRV9NlUXVWRrfOHncNS sStaU9WA19J1AFo/N8AbtTD76HaA77XQZOnkiRrz8k6PqOZsG3IIUlysXuxpnbUh/QhO YeOw==
X-Gm-Message-State: ALoCoQnBjjwWeAeUJLXWQqDPJA5bWFzcg1WGcGnK6BZoDOaGvpzQHS7D0LWaQOFUPJUoZxOJelDL
X-Received: by 10.180.126.8 with SMTP id mu8mr5883094wib.10.1406299386749; Fri, 25 Jul 2014 07:43:06 -0700 (PDT)
Received: from porto.nomis80.org ([2001:67c:1231:998:9dec:20b7:9edc:fe13]) by mx.google.com with ESMTPSA id di7sm25803561wjb.34.2014.07.25.07.43.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 07:43:06 -0700 (PDT)
Message-ID: <53D26CF8.6000001@jive.com>
Date: Fri, 25 Jul 2014 10:43:04 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com>  <53D24FFE.1040802@jive.com> <53D268C0.1070604@jive.com>
In-Reply-To: <53D268C0.1070604@jive.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iwp9tNdTk9gAY8rV0jjkjak2tak
Subject: Re: [MMUSIC] ICEbis and IPv6 Privacy adresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:43:11 -0000

Le 2014-07-25 10:25, Simon Perreault a crit :
> Le 2014-07-25 08:39, Simon Perreault a crit :
>> Therefore, proposed text:
>>
>> If one or more host candidates corresponding to IPv6 privacy addresses
>> are advertised, host candidates corresponding to other kinds of IPv6
>> addresses on the same interface MUST NOT be advertised.
> 
> Updated text, per today's live discussion:
> 
> If one or more host candidates corresponding to IPv6 privacy addresses
> are advertised, host candidates corresponding to other kinds of IPv6
> addresses on the same interface and having the same network prefix MUST
> NOT be advertised.

Trying to take into account up-to-date nomenclature, and the link-local
case (which is almost always stable):

==========================
If one or more host candidates corresponding to IPv6 address generated
using a mechanism that prevents location tracking
[draft-ietf-6man-ipv6-address-generation-privacy-01] are advertised:

    - host candidates corresponding to IPv6 addresses that do allow
location tracking, that are configured on the same interface, and are
part of the same network prefix MUST NOT be advertised; and

    - host candidates corresponding to IPv6 link-local addresses MUST
NOT be advertised.
==========================

Simon


From nobody Fri Jul 25 16:28:23 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E301A04B0 for ; Fri, 25 Jul 2014 16:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IIUApcBJEGO for ; Fri, 25 Jul 2014 16:28:19 -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 70C7F1A049F for ; Fri, 25 Jul 2014 16:28:19 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta07.westchester.pa.mail.comcast.net with comcast id WnJC1o0030bG4ec57nUK6J; Fri, 25 Jul 2014 23:28:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([206.47.221.210]) by omta03.westchester.pa.mail.comcast.net with comcast id WnSA1o00U4YyHWu3PnSDaU; Fri, 25 Jul 2014 23:26:17 +0000
Message-ID: <53D2E792.4050905@alum.mit.edu>
Date: Fri, 25 Jul 2014 19:26:10 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: IETF MMUSIC WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406330899; bh=3fZLqaSp19Wk1Adm/E8FQvGuWfWA2jBgWnG/IrcTsMQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R5gselOb57a7EYqnq7TgtdEPfKs7kGKSf/lwuyuPSQ4ss51VDVk8supREASMMq0mz lQbc9BClWQcv9qdckw4mnqGz7gMcpzJBD2bIhOorj0zbtVJigO/FeDqPOD2wVLZtlF cFNXswU8ZCC/QVJqkoRA+8XrgGUh7NO4CoyoFkwlYfwnL4omsL6hrdkY0fkGdQVrql yD1Q7u6VYPX74IfXPUsr4r7GLVc9FJueIn61MLRX9lIVBH+PirGONEVs/6++9ZNp4X irAj3WuGUgfhedzWzhqBZnvLCWiTZr9Kvy5ojKxsRtjnA1GK0AuUCxj1KlCzwD9GyF pPzLw1SHZZEvw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/E4YL-FZ_x3h4YZNfrPW1XVHS1eU
Subject: [MMUSIC] IANA considerations for draft-ietf-mmusic-sctp-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 23:28:21 -0000

There are some loose ends to tie up with IANA for this draft to be complete:

This draft defines new proto values:

SCTP
SCTP/DTLS
DTLS/SCTP

They need to be registered in the IANA SDP Parameters registry Proto table.

And then, SDP (RFC4566) says:

       For media using other transport protocols, the  field is
       protocol specific.  Rules for interpretation of the  sub-
       field MUST be defined when registering new protocols (see Section
       8.2.2).

This draft needs to define protocol specific rules for  when used 
with the new family of SCTP protos.

For the moment, I think the rules should probably be that there must be 
exactly one  value on the m-line with these protos. For what values 
are valid, I think we need a new IANA registry. It should be a new table 
within SDP Parameters, and should probably look something like this:

Name: media/fmt values for SCTP family protos

Media         Fmt            Reference
-----------   ------------   ----------
application   raw-sctp       [some SCTP rfc]
application   data-channel   [draft-ietf-rtcweb-data-channel]

Note that I'm suggesting registering media/fmt pairs. If we don't, then 
there is no specification of what the significance of  is with 
these protos. The alternative would be to specify that only 
"application" can be used. But registering pairs makes more sense to me. 
(Somebody may come up with an audio or video application-usage that 
makes sense.)

(We *could* register these formats on a per-proto basis, rather than for 
the whole family of sctp protos. I see no compelling reason to do that, 
and good reasons not to.)

This draft needs to establish the registry, and populate the value for 
raw SCTP. I *think* the reference for the semantics of raw-sctp can be 
just a reference to a basic SCTP rfc. Or maybe we need to reference 
*this* draft and include a paragraph explaining what raw access to an 
SCTP association means.

Ideally draft-ietf-rtcweb-data-channel would register the data channel 
fmt, since it defines how it works. If need be, *this* draft could 
register it.

And note that I'm suggesting calling the fmt "data-channel" rather than 
"webrtc-datachannel", because it can, and will, be used in contexts 
where webrtc is not in use.

	Thanks,
	Paul


From nobody Mon Jul 28 18:01:50 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2821F1A03BD for ; Mon, 28 Jul 2014 18:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeIPuSxeK68e for ; Mon, 28 Jul 2014 18:01:46 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C031A0352 for ; Mon, 28 Jul 2014 18:01:45 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hy4so12849850vcb.27 for ; Mon, 28 Jul 2014 18:01:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kchj1szHeJX4uuWr6sUFJ67v9TWs/Paeyw5/Ut73xBg=; b=A966j2oOk5SXTqAXAHIYkT5W9XUC6w1dqzmntHlXHJ2nHslsARrJmUaTb4O+3uvDoQ xZyBFEL48SsDRO0di+eeOCUUH3JO2FLUhIHis8Xn7W6xU+rEgRtdpbhDY6bPbuNxl3OD jwo7I3MuXKuIh97ZVjA57lt9cFy69wDlfgyUoAYJxrh2NJVQv1gyOEzm9jV8FMj5sRin OzI7EQK+uzMz6uG7+QihvinMSNTgRHqDGjA4kH0AlszUZpVjRq1rJyr/rm6uKW0CALwJ r+xevR2AVB94ebkQZ7Xd6DHgI1DppgsTxnXn9A7EnrCej/7QDtdiWmcsfBRkJ8JHC5Ia OKAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kchj1szHeJX4uuWr6sUFJ67v9TWs/Paeyw5/Ut73xBg=; b=QyIJpeXEsE4puyJwleZ1Jwr/1npVmWLVfUFuX5BW+bEn/SAQG7R2ZZnXCkBOstMsoG qbce8q82lS27DalCwkuMHIbRHeAfUwaphY+htDY/5NZPDj2GzZgNQrUjwLH3H9CZkCcs zGCX38ckFPRdpixaZjTOwIHkmY0YuJ7Vn/V48XQuEf3KxOuY5moR66+2Kyb3dBYxGldS yJbxglyzaEMW2x2y3xJ/EuiEB6Jmmll5yrd4bqFFDdhrnXs8Beqr/V1lS6r4NO6IghbV egE/ydt+gB9GshJq9I5A6IwKjYROWVLrCdgryibOOb3BeCYJlI5xtXNMYxxAOVtyTnoJ pWRA==
X-Gm-Message-State: ALoCoQlbxQRm7rwxaUdg9p1sUf8hURn6vT8nIHiT7YaIBZfHEaWQ8QOqcApbRHWaXiw2xNPn9TXh
X-Received: by 10.52.120.83 with SMTP id la19mr753677vdb.68.1406595704997; Mon, 28 Jul 2014 18:01:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Mon, 28 Jul 2014 18:01:24 -0700 (PDT)
In-Reply-To: <53D24FFE.1040802@jive.com>
References: <5353C0F5-5769-4C56-9A8A-1C884A7F8CC3@cisco.com>  <53D24FFE.1040802@jive.com>
From: Justin Uberti 
Date: Mon, 28 Jul 2014 18:01:24 -0700
Message-ID: 
To: Simon Perreault 
Content-Type: multipart/alternative; boundary=089e0122f12e56f06104ff4a95c5
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rFbztZ4pUBaDkxnqHyncS6eh8Ug
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICEbis and IPv6 Privacy adresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 01:01:49 -0000

--089e0122f12e56f06104ff4a95c5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 25, 2014 at 5:39 AM, Simon Perreault 
wrote:

> Le 2014-07-24 22:33, Justin Uberti a =C3=A9crit :
> > I believe the point of temporary addresses is to prevent tracking, not
> > to prevent computing an approximate location. Therefore I don't think w=
e
> > need to do anything about the other (non-trackable) addresses.
>
> Uh? Other addresses *are* trackable, that's the whole point.
>

I was referring to the cases that Pal pointed out, namely srflx and relay
candidates, as well as IPv4 host candidates.

>
> The addresses I have right now:
>
> >     inet6 2001:67c:1231:998:9dec:20b7:9edc:fe13/64 scope global
> temporary dynamic
> >        valid_lft 604798sec preferred_lft 604798sec
> >     inet6 2001:67c:1231:998:8e70:5aff:fec5:72e4/64 scope global dynamic
> >        valid_lft 2591999sec preferred_lft 2591999sec
> >     inet6 fe80::8e70:5aff:fec5:72e4/64 scope link
> >        valid_lft forever preferred_lft forever
>
> Only the privacy address is not trackable. The other two have fixed
> lower 64 bits.
>
> I think P=C3=A5l's request makes a lot of sense for host candidates.
> Server-reflexive and relayed candidates don't matter as they are not
> trackable. Asking a TURN server to use a temporary address doesn't make
> sense either IMHO.
>
> Therefore, proposed text:
>
> If one or more host candidates corresponding to IPv6 privacy addresses
> are advertised, host candidates corresponding to other kinds of IPv6
> addresses on the same interface MUST NOT be advertised.
>

Agreed. This is what Chrome currently does for IPv6 addresses.

--089e0122f12e56f06104ff4a95c5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Jul 25, 2014 at 5:39 AM, Simon Perreault =
<sperreault@jiv=
e.com> wrote:




Le 2014-07-24 22:33, Justin Uberti a =C3=A9crit :


> I believe the point of temporary addresses is to prevent tracking=
, not

> to prevent computing an approximate location. Therefore I don't th=
ink we

> need to do anything about the other (non-trackable) addresses.




Uh? Other addresses *are* trackable, that's the whole point.
<=
/blockquote>

I was referring to the cases that Pal point=
ed out, namely srflx and relay candidates, as well as IPv4 host candidates.=
 =C2=A0







The addresses I have right now:



> =C2=A0 =C2=A0 inet6 2001:67c:1231:998:9dec:20b7:9edc:fe13/64 scope glo=
bal temporary dynamic

> =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft 604798sec preferred_lft 604798sec=


> =C2=A0 =C2=A0 inet6 2001:67c:1231:998:8e70:5aff:fec5:72e4/64 scope glo=
bal dynamic

> =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft 2591999sec preferred_lft 2591999s=
ec

> =C2=A0 =C2=A0 inet6 fe80::8e70:5aff:fec5:72e4/64 scope link

> =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft forever preferred_lft forever



Only the privacy address is not trackable. The other two have fixed

lower 64 bits.



I think P=C3=A5l's request makes a lot of sense for host candidates.
Server-reflexive and relayed candidates don't matter as they are not
trackable. Asking a TURN server to use a temporary address doesn't make=


sense either IMHO.



Therefore, proposed text:



If one or more host candidates corresponding to IPv6 privacy addresses

are advertised, host candidates corresponding to other kinds of IPv6

addresses on the same interface MUST NOT be advertised.

Agreed. This is what Chrome currently does for IPv6 addres=
ses.=C2=A0


--089e0122f12e56f06104ff4a95c5--


From nobody Wed Jul 30 08:12:10 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D8B1A0255; Wed, 30 Jul 2014 08:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XGbpj2hEvT8; Wed, 30 Jul 2014 08:11:59 -0700 (PDT)
Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF891A01E6; Wed, 30 Jul 2014 08:10:46 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 11:10:43 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-72/SG:2 7/30/2014 11:10:14 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.876892 p=-0.977424 Source White
X-Signature-Violations: 0-0-0-3726-c
X-Note-419: 15.6005 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 11:10:34 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail2.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 116976085; Wed, 30 Jul 2014 11:10:43 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 10:10:42 -0500
From: Jonathan Lennox 
To: Justin Uberti 
Thread-Topic: Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
Thread-Index: AQHPrAhtxaTuo9vyTE6R2p2YHkJufA==
Date: Wed, 30 Jul 2014 15:10:41 +0000
Message-ID: <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xfxdb9nsp9eIkAzrMW69E7KG9xc
Cc: "tram@ietf.org" , mmusic 
Subject: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 15:12:06 -0000

(Moving this discussion to MMusic.  I suggest further discussion drop the t=
ram list, unless it cycles back around to a TURN-specific issue.)

On Jul 29, 2014, at 1:57 PM, Justin Uberti  wrote:
>=20
> The one thing we need to do is update ICE to allow the CONTROLLING side t=
o make dynamic decisions about which pair to use, instead of being forced t=
o use PRIORITY (which is what 5245 says). I am going to try to write this u=
p before Hawaii.=20

This is equivalent to using regular nomination, but saying that an endpoint=
 can send media on any Confirmed candidate pair, not just the Selected one,=
 right?

5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair.  I don=92t know if t=
his means, in practice, that ICE-bis could change to the behavior I=92ve de=
scribed above and still be backward compatible, or if there=92d need to be =
some sort of ice-option negotiation to indicate that this early media (oh, =
dread phrase) is acceptable.



From nobody Wed Jul 30 10:12:21 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BDD1A02A6 for ; Wed, 30 Jul 2014 10:12:18 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXERa-bwYcAc for ; Wed, 30 Jul 2014 10:12:13 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB281A02DE for ; Wed, 30 Jul 2014 10:12:13 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id n3so2700978wiv.13 for ; Wed, 30 Jul 2014 10:12:11 -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=5c5KFXCtCfE4w6YQ4aT0Nt+AQBSPfbHQXpNN1lA2C5w=; b=Bd1otQiWcOGJ1hv8YzzUJAOp6tBGHKDzNt8CDC3kNVRu/1i2UUI69tlwtWk3dVpzty dYXqHHD/aXadc1exmbEI6hxvzvxwXB8H6ioAKCRZGpJPBsLKQUl+V+R3slOlbadtEY57 ziVnuiO7SeG+843JByPs0eHO6SsvR4BfwdErHugqxev4ZSwEKMmijm9yJLQJWx5YRVQG pUvKau0AaOVX8NgAFgvcXB+WgTf8Xa3mUVGKMca6lKMOr8/kcSLDM9bG5OntMM6kYcv6 A/AUJ2wSf5QRjO0c0ULTgYfL2L8ugM83kbhntGvKRi/u3acmxrbcW5tINT51J6NURwc6 BS4w==
MIME-Version: 1.0
X-Received: by 10.180.84.7 with SMTP id u7mr9053940wiy.1.1406740331878; Wed, 30 Jul 2014 10:12:11 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 10:12:11 -0700 (PDT)
In-Reply-To: <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
Date: Wed, 30 Jul 2014 10:12:11 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MslEXq8E77L5W30DEjI-x_Y1ZXA
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 17:12:19 -0000

(Completing the move)

On 30 July 2014 08:10, Jonathan Lennox  wrote:
> This is equivalent to using regular nomination, but saying that an endpoint can send media on any Confirmed candidate pair, not just the Selected one, right?

I like this idea.  I don't know what this does to other
implementations, but Firefox would probably be OK with that based on
my quick check of the code.

The only caveat on that is that we need to have a remote candidate for
the flow before it gets delivered.  We create candidates based on one
of three conditions, as 5245 requires: we have received a valid check
from that remote address, we have received a check response from that
remote address, or the remote address was signaled.  If we are
trickling, that could mean that valid packets get discarded for some
time.  I think that the only downside there is that the sender needs
to retransmit their DTLS handshake packets.

That approach more or less renders aggressive nomination pointless, doesn't it?


From nobody Wed Jul 30 14:00:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4691A046A for ; Wed, 30 Jul 2014 14:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbi7gC9EA-gJ for ; Wed, 30 Jul 2014 14:00:09 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888BE1A040A for ; Wed, 30 Jul 2014 14:00:09 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id ij19so2807731vcb.39 for ; Wed, 30 Jul 2014 14:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=19PRUHmGeGXBSvB58x1DPyzwdxhDASlI3diL+gCIV6s=; b=p1uKp3s62YPnT2RnRLd3nEyakmhTHLFNXzsfr5FpGx31PpZKz0HmMlYe//+4fLv6uA 5YxcpkNE1Gv+F06Wm44mJY4CODNWv8PAstsWrJ4zC0ILI3DUKzhDwUaEDY2fNM7s0HPZ WyuDlCmCvV+6Ox7IxdYRDZRp489MfBZVHEE9HBTXVSOzkPw7HRKnu440kFh9Ae0zRLEL lLnw1l3oOKrRTSppL4LydQPyUSUZtf9bxlwGIJqJgk03WZT5tD5i43MPQtEKkxsOjYGc Aiu6S6zgDyEd3EFe/GNUjhJXcfZiYMoQwI0GvNRPKRt2S5fKnA5TeIIwJOCquhrj24XK scWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=19PRUHmGeGXBSvB58x1DPyzwdxhDASlI3diL+gCIV6s=; b=PeuGcdt8n2hyn0AtA/ZG/lOF5F4pCUbAaI8krv8NXjoLbIouivkvy2+8/GsWl1grrM sddPV/zkNZr5IdGctQI0SrydPY9ydKfNy1W7ihZ78rW1wYaZ2dcZb9BM7BGK/2MLEEl7 JyUXCQ28Uu6UYtuGgHa0HtiOR+suRhsAxMGawFz0gKZGaAugQqjg2zej9eq7Vms9A2YZ hntV3LgA1gctFR/z4Jf+Sp2JNMSW3Y9UPKli2ErrzZCieYZS8rP+94lN4jDmWxQqpJr8 Tv7Cc/lPlx/71r/cIHeVD+PZbI4JKZxnayHCbg/kIlCNlzN12CHc6XFz1HazAN6EzCBj udqA==
X-Gm-Message-State: ALoCoQlPzpEW21kiz9hCJZjmOz0dpOIGOMxGApZnr7Jfnb60tLWygwUtGaukNKE9pP6PId1/f8FJ
X-Received: by 10.52.136.196 with SMTP id qc4mr10886638vdb.22.1406754008550; Wed, 30 Jul 2014 14:00:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 13:59:48 -0700 (PDT)
In-Reply-To: <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
From: Justin Uberti 
Date: Wed, 30 Jul 2014 13:59:48 -0700
Message-ID: 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=bcaec51b12bdf77ea704ff6f7081
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aACCzq-VmszoLlUwWcRPFhMuxHc
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 21:00:11 -0000

--bcaec51b12bdf77ea704ff6f7081
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox  wrote=
:

>
> (Moving this discussion to MMusic.  I suggest further discussion drop the
> tram list, unless it cycles back around to a TURN-specific issue.)
>
> On Jul 29, 2014, at 1:57 PM, Justin Uberti  wrote:
> >
> > The one thing we need to do is update ICE to allow the CONTROLLING side
> to make dynamic decisions about which pair to use, instead of being force=
d
> to use PRIORITY (which is what 5245 says). I am going to try to write thi=
s
> up before Hawaii.
>
> This is equivalent to using regular nomination, but saying that an
> endpoint can send media on any Confirmed candidate pair, not just the
> Selected one, right?
>

It's a bit more than that - the controlled endpoint has to also synchronize
on the candidate pair, which means that it needs to know what its selected
pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
highest priority nominated pair).

So it becomes:
- controlling side can pick any nominated candidate pair it wants to be its
selected pair
- controlled side should use presence of media from controlling side to
decide selected pair (for secure media), or some TBD attribute (for
non-secure media)
- controlling side can tell controlled side when it is OK to discard
candidate pairs that it has nominated (so that the controlling side can
still safely do the switch to a new pair). This is probably done by having
the controlled side keep all candidates alive that have received a check
from the controlling side in the past XX seconds.

>
> 5245 says that an ICE endpoint MUST be prepared to receive media on any
> candidate, but only sends on the Selected candidate pair.  I don=E2=80=99=
t know if
> this means, in practice, that ICE-bis could change to the behavior I=E2=
=80=99ve
> described above and still be backward compatible, or if there=E2=80=99d n=
eed to be
> some sort of ice-option negotiation to indicate that this early media (oh=
,
> dread phrase) is acceptable.
>

Yes, I think we need a new ICE option, or else old ICE impls in the
controlled role will be surprised when they think the selected pair is A
but media arrives on B. We've already seen a number of implementations have
issues with this.

--bcaec51b12bdf77ea704ff6f7081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox =
<jonathan@vidyo.=
com> wrote:






(Moving this discussion to MMusic. =C2=A0I suggest further discussion drop =
the tram list, unless it cycles back around to a TURN-specific issue.)



On Jul 29, 2014, at 1:57 PM, Justin Uberti <juberti@google.com> wrote:

>

> The one thing we need to do is update ICE to allow the CONTROLLING sid=
e to make dynamic decisions about which pair to use, instead of being force=
d to use PRIORITY (which is what 5245 says). I am going to try to write thi=
s up before Hawaii.






This is equivalent to using regular nomination, but saying that an endpoint=
 can send media on any Confirmed candidate pair, not just the Selected one,=
 right?

It's a bit more than that -=
 the controlled endpoint has to also synchronize on the candidate pair, whi=
ch means that it needs to know what its selected pair should be, using logi=
c other than what is outlined in http://tools.ietf.org/html/rfc5245#se=
ction-11.1.1 (which says use the highest priority nominated pair).




So it becomes:
- controlling side can pick an=
y nominated candidate pair it wants to be its selected pair
- con=
trolled side should use presence of media from controlling side to decide s=
elected pair (for secure media), or some TBD attribute (for non-secure medi=
a)




- controlling side can tell controlled side when it is OK to discard c=
andidate pairs that it has nominated (so that the controlling side can stil=
l safely do the switch to a new pair). This is probably done by having the =
controlled side keep all candidates alive that have received a check from t=
he controlling side in the past XX seconds.







5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair. =C2=A0I don=E2=80=99=
t know if this means, in practice, that ICE-bis could change to the behavio=
r I=E2=80=99ve described above and still be backward compatible, or if ther=
e=E2=80=99d need to be some sort of ice-option negotiation to indicate that=
 this early media (oh, dread phrase) is acceptable.





Yes, I think we need a new ICE option, or =
else old ICE impls in the controlled role will be surprised when they think=
 the selected pair is A but media arrives on B. We've already seen a nu=
mber of implementations have issues with this.=C2=A0







--bcaec51b12bdf77ea704ff6f7081--


From nobody Wed Jul 30 14:04:36 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851311A0535 for ; Wed, 30 Jul 2014 14:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08QHLkLDLSuN for ; Wed, 30 Jul 2014 14:04:31 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CE71A052E for ; Wed, 30 Jul 2014 14:04:30 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id im17so2819026vcb.17 for ; Wed, 30 Jul 2014 14:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WkHD/kASOvc2ZgfSp9tSVq4V/aSJfyzZkJRmndE7bUQ=; b=fVSsw9Fe1YJ44okZw755D/mcJmhtrHQFsjDC70/mPz4MDiqKeovm6Hd+wTgJdvamgu h8ssyG0EkMQY9RzwsbEMtG4FRd5A59J8Zc3vOK5fRM2JhoIXFl88X+9p4eVbgSODAZG4 cGrONdRimjxj+vP/LGkB6QgHB+44bI4mFSZOEQs2EEinnIoTlDnmlfxNPcOKdlSJZnPI /39NFEp3EQUC3nlj7iSgDoIux5BXanXMyy60D2+mmJi69mKAfA2+ARyBgqhrKSKd8sTv W/Ee4uFXjZ5ALQ1Pad/Z/1jPkcb8c+4jvhcgJT+Z8MGjDq1NtEfxr+YKIhoEuvu4XrXR JCAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WkHD/kASOvc2ZgfSp9tSVq4V/aSJfyzZkJRmndE7bUQ=; b=a5QvFsRKDAyNI6OzuQw0xQ4p0ChVUbRcGrYSCIMv/NUEy2jw/xYk7hCaYf98qCLJj6 1CE2ZhNBhVhZnp2gSzeVgGW5kOHDMA6Q5XzEVxp2ve0eGjWj25vzJy0lqsOBdgEQsB2N 1RxhlzBQ+CamOIQG0R24zCUSnkKQQL8ZI60qyMvxIOpCtx7YUHrP8yxM+f6rRbOw5cDV Jo/vOAD2MGFEgut3zeC8WQ6lIU2hdL5l85RYrh+uHqhBrWSIR717gbkqe0iGsymkArza uAwFF5oT0p0lTfbYD2eOYK3Zf/ei+64rKF/m/LGDR1apJY99JyouRTA5F66akQIGOp5N My+Q==
X-Gm-Message-State: ALoCoQlNpI/HxY5wkK3agxcjsXr/SCkc5tVLyeCUxe+I7N7KtcOnFT6LjDv2joKxUCbqaBfxhCRG
X-Received: by 10.221.42.135 with SMTP id ty7mr8261408vcb.14.1406754269775; Wed, 30 Jul 2014 14:04:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 14:04:09 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> 
From: Justin Uberti 
Date: Wed, 30 Jul 2014 14:04:09 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a1133997489628404ff6f8010
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/A7BQimPlNIBTz5sEIYhqZV1ueAs
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 21:04:34 -0000

--001a1133997489628404ff6f8010
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 30, 2014 at 10:12 AM, Martin Thomson 
wrote:

> (Completing the move)
>
> On 30 July 2014 08:10, Jonathan Lennox  wrote:
> > This is equivalent to using regular nomination, but saying that an
> endpoint can send media on any Confirmed candidate pair, not just the
> Selected one, right?
>
> I like this idea.  I don't know what this does to other
> implementations, but Firefox would probably be OK with that based on
> my quick check of the code.
>
> The only caveat on that is that we need to have a remote candidate for
> the flow before it gets delivered.  We create candidates based on one
> of three conditions, as 5245 requires: we have received a valid check
> from that remote address, we have received a check response from that
> remote address, or the remote address was signaled.  If we are
> trickling, that could mean that valid packets get discarded for some
> time.  I think that the only downside there is that the sender needs
> to retransmit their DTLS handshake packets.
>

I don't follow the logic here. If a pair is on the valid list (I assume
that is what Jonathan means by Confirmed), you have received a check
response.

--001a1133997489628404ff6f8010
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 10:12 AM, Martin Thomson =
<martin.th=
omson@gmail.com> wrote:



(Completing the move)




On 30 July 2014 08:10, Jonathan Lennox <jonathan@vidyo.com> wrote:

> This is equivalent to using regular nomination, but saying that an end=
point can send media on any Confirmed candidate pair, not just the Selected=
 one, right?




I like this idea. =C2=A0I don't know what this does to other

implementations, but Firefox would probably be OK with that based on

my quick check of the code.



The only caveat on that is that we need to have a remote candidate for

the flow before it gets delivered. =C2=A0We create candidates based on one<=
br>
of three conditions, as 5245 requires: we have received a valid check

from that remote address, we have received a check response from that

remote address, or the remote address was signaled. =C2=A0If we are

trickling, that could mean that valid packets get discarded for some

time. =C2=A0I think that the only downside there is that the sender needs
to retransmit their DTLS handshake packets.

=

I don't follow the logic here. If a pair is on the valid list (I a=
ssume that is what Jonathan means by Confirmed), you have received a check =
response.=C2=A0






--001a1133997489628404ff6f8010--


From nobody Wed Jul 30 14:14:48 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1191A064A for ; Wed, 30 Jul 2014 14:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level: 
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-sTF71yi7hm for ; Wed, 30 Jul 2014 14:14:41 -0700 (PDT)
Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950761A0648 for ; Wed, 30 Jul 2014 14:14:41 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 5:14:38 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-235/SG:5 7/30/2014 5:13:43 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.896023 p=-0.981919 Source White
X-Signature-Violations: 0-0-0-14664-c
X-Note-419: 15.5995 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 5:14:33 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 143604675; Wed, 30 Jul 2014 17:14:38 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 16:14:37 -0500
From: Jonathan Lennox 
To: Justin Uberti 
Thread-Topic: Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
Thread-Index: AQHPrAhtxaTuo9vyTE6R2p2YHkJufJu5biYAgAAEI4A=
Date: Wed, 30 Jul 2014 21:14:37 +0000
Message-ID: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_B2794643ADB54B6698DC841990C85437vidyocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/g2KndWEIMwQosvJJMqY0ZZ7HW1c
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 21:14:45 -0000

--_000_B2794643ADB54B6698DC841990C85437vidyocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


On Jul 30, 2014, at 4:59 PM, Justin Uberti > wrote:

On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox > wrote:

On Jul 29, 2014, at 1:57 PM, Justin Uberti > wrote:
>
> The one thing we need to do is update ICE to allow the CONTROLLING side t=
o make dynamic decisions about which pair to use, instead of being forced t=
o use PRIORITY (which is what 5245 says). I am going to try to write this u=
p before Hawaii.

This is equivalent to using regular nomination, but saying that an endpoint=
 can send media on any Confirmed candidate pair, not just the Selected one,=
 right?

It's a bit more than that - the controlled endpoint has to also synchronize=
 on the candidate pair, which means that it needs to know what its selected=
 pair should be, using logic other than what is outlined in http://tools.ie=
tf.org/html/rfc5245#section-11.1.1 (which says use the highest priority nom=
inated pair).

So it becomes:
- controlling side can pick any nominated candidate pair it wants to be its=
 selected pair
- controlled side should use presence of media from controlling side to dec=
ide selected pair (for secure media), or some TBD attribute (for non-secure=
 media)
- controlling side can tell controlled side when it is OK to discard candid=
ate pairs that it has nominated (so that the controlling side can still saf=
ely do the switch to a new pair). This is probably done by having the contr=
olled side keep all candidates alive that have received a check from the co=
ntrolling side in the past XX seconds.

You=92ve just reinvented regular nomination =97 your =93TBD attribute=94 is=
 regular nomination=92s USE-CANDIDATE.

Thus the suggestion I=92m making =97 do regular nomination, but allow media=
 to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, I=
 should have said =93Valid=94 rather than =93Confirmed=94.  I mis-remembere=
d the terminology.)

5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair.  I don=92t know if t=
his means, in practice, that ICE-bis could change to the behavior I=92ve de=
scribed above and still be backward compatible, or if there=92d need to be =
some sort of ice-option negotiation to indicate that this early media (oh, =
dread phrase) is acceptable.

Yes, I think we need a new ICE option, or else old ICE impls in the control=
led role will be surprised when they think the selected pair is A but media=
 arrives on B. We've already seen a number of implementations have issues w=
ith this.

Do they have issues receiving media if there is no selected pair yet?  This=
 would be nonconformant with 5245, but nevertheless wouldn=92t surprise me.


--_000_B2794643ADB54B6698DC841990C85437vidyocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3F1D31B5F501F4439194034853154E27@vidyo.com>
Content-Transfer-Encoding: quoted-printable











On Jul 30, 2014, at 4:59 PM, Justin Uberti <juberti@google.com> wrote:










On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox=
 
<jonathan@vidyo.=
com> wrote:





On Jul 29, 2014, at 1:57 PM, Justin Uberti <juberti@google.com> wrote:

>

> The one thing we need to do is update ICE to allow the CONTROLLING sid=
e to make dynamic decisions about which pair to use, instead of being force=
d to use PRIORITY (which is what 5245 says). I am going to try to write thi=
s up before Hawaii.



This is equivalent to using regular nomination, but saying that an endpoint=
 can send media on any Confirmed candidate pair, not just the Selected one,=
 right?









It's a bit more than that - the controlled endpoint has to also synchr=
onize on the candidate pair, which means that it needs to know what its sel=
ected pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use =
the highest priority nominated pair).







So it becomes:


- controlling side can pick any nominated candidate pair it wants to b=
e its selected pair


- controlled side should use presence of media from controlling side t=
o decide selected pair (for secure media), or some TBD attribute (for non-s=
ecure media)


- controlling side can tell controlled side when it is OK to discard c=
andidate pairs that it has nominated (so that the controlling side can stil=
l safely do the switch to a new pair). This is probably done by having the =
controlled side keep all candidates
 alive that have received a check from the controlling side in the past XX =
seconds.















You=92ve just reinvented regular nomination =97 your =93TBD attribute=
=94 is regular nomination=92s USE-CANDIDATE.







Thus the suggestion I=92m making =97 do regular nomination, but allow =
media to be sent on any valid pair prior to selection.  (Yes, re-readi=
ng 5245, I should have said =93Valid=94 rather than =93Confirmed=94.  =
I mis-remembered the terminology.)
















5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair.  I don=92t know=
 if this means, in practice, that ICE-bis could change to the behavior I=92=
ve described above and still be backward
 compatible, or if there=92d need to be some sort of ice-option negotiation=
 to indicate that this early media (oh, dread phrase) is acceptable.









Yes, I think we need a new ICE option, or else old ICE impls in the co=
ntrolled role will be surprised when they think the selected pair is A but =
media arrives on B. We've already seen a number of implementations have iss=
ues with this. 














Do they have issues receiving media if there is no selected pair yet? =
 This would be nonconformant with 5245, but nevertheless wouldn=92t su=
rprise me.






--_000_B2794643ADB54B6698DC841990C85437vidyocom_--


From nobody Wed Jul 30 14:49:12 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0F21A0113 for ; Wed, 30 Jul 2014 14:49:01 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpM0fdyuKhUK for ; Wed, 30 Jul 2014 14:48:58 -0700 (PDT)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04731A005D for ; Wed, 30 Jul 2014 14:48:57 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hq11so2907507vcb.30 for ; Wed, 30 Jul 2014 14:48:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u490RRUSqPvra/btkGDYc1qODI93xwrk63lsul15W6I=; b=cotkU4A9l5CDUcnDLQaOIAKa26LphtIhT+1VlqRrJ09P7fyR0YqHtDpD2HBvi2kFw6 6oRFDMhtIKfeuWLKaEdlEhtG5dBvHV+9KWBHndWiFnCa2rwACuGsThbMjJyxPnPqwAlF CaqXSGC99zgFF6l9NdoHagf8buzrgOB1jlJjdBQRLQPdXOZXijHP+0/ihm6sh/25xt3W v3AUun1Lhoeejcg5uFye+oA3qEJDXl2j0Zt6mIchHnqkRIOcsx38sbXhYWqovozzlOqB e2GSS7Nv10JAh82ESipcVwJylrHXjhUf55OeIGW349ipeMLKvNPoAOVACGeHlIIRA4KH xP7w==
X-Gm-Message-State: ALoCoQmBB29EjJcpNFsbKnscgsVXuISQQ7Fo5m03FxKIoEQAzO0q8CQPKFUHVQ+pxnLDcAi1HWVm
X-Received: by 10.52.244.81 with SMTP id xe17mr11127522vdc.24.1406756936945; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx.google.com with ESMTPSA id td9sm1851341veb.8.2014.07.30.14.48.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id ik5so2900261vcb.34 for ; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.171.233 with SMTP id ax9mr5568713vdc.76.1406756936164; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: by 10.220.238.75 with HTTP; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: by 10.220.238.75 with HTTP; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>  
Date: Wed, 30 Jul 2014 23:48:56 +0200
Message-ID: 
From: Emil Ivov 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=089e0158ca7e7749b104ff701f76
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wmw4r0djjvFVMNNW_0hJOHwly1k
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 21:49:01 -0000

--089e0158ca7e7749b104ff701f76
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The main problem with the aggressive version of regular nomination is stuff
like DTLS/SRTP (that's actually already kind of an issue with today's
aggressive nomination).

When it's RTP you don't care where you get it from as long as you do. If
it's a DTLS client halo then what do you do exactly?

Can the controlling agent simply respond on a different valid pair than the
one on which it received it? (This is what Chrome currently does but its
frowned upon by the DTLS/SRTP draft which binds the context to a specific
address:port). Does the controlled agent need to resend it on the new pair
after it gets the USE-CANDIDATE?

What about other protocols? Do they all need to say how they are to be used
with ICE? I hope not and I hope we can find a generic approach for all of
them. For example: all early non-acknowledged reliable data has to be
resent on the nominated pair. This would imply a DTLS neg restart as Martin
suggested.

--sent from my mobile
On 30 Jul 2014 11:14 PM, "Jonathan Lennox"  wrote:

>
>  On Jul 30, 2014, at 4:59 PM, Justin Uberti  wrote:
>
>   On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox 
> wrote:
>
>>
>> On Jul 29, 2014, at 1:57 PM, Justin Uberti  wrote:
>> >
>> > The one thing we need to do is update ICE to allow the CONTROLLING sid=
e
>> to make dynamic decisions about which pair to use, instead of being forc=
ed
>> to use PRIORITY (which is what 5245 says). I am going to try to write th=
is
>> up before Hawaii.
>>
>> This is equivalent to using regular nomination, but saying that an
>> endpoint can send media on any Confirmed candidate pair, not just the
>> Selected one, right?
>>
>
>  It's a bit more than that - the controlled endpoint has to also
> synchronize on the candidate pair, which means that it needs to know what
> its selected pair should be, using logic other than what is outlined in
> http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
> highest priority nominated pair).
>
>  So it becomes:
> - controlling side can pick any nominated candidate pair it wants to be
> its selected pair
> - controlled side should use presence of media from controlling side to
> decide selected pair (for secure media), or some TBD attribute (for
> non-secure media)
> - controlling side can tell controlled side when it is OK to discard
> candidate pairs that it has nominated (so that the controlling side can
> still safely do the switch to a new pair). This is probably done by havin=
g
> the controlled side keep all candidates alive that have received a check
> from the controlling side in the past XX seconds.
>
>
>  You=E2=80=99ve just reinvented regular nomination =E2=80=94 your =E2=80=
=9CTBD attribute=E2=80=9D is
> regular nomination=E2=80=99s USE-CANDIDATE.
>
>  Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination, =
but allow media
> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, =
I
> should have said =E2=80=9CValid=E2=80=9D rather than =E2=80=9CConfirmed=
=E2=80=9D.  I mis-remembered the
> terminology.)
>
>    5245 says that an ICE endpoint MUST be prepared to receive media on
>> any candidate, but only sends on the Selected candidate pair.  I don=E2=
=80=99t know
>> if this means, in practice, that ICE-bis could change to the behavior I=
=E2=80=99ve
>> described above and still be backward compatible, or if there=E2=80=99d =
need to be
>> some sort of ice-option negotiation to indicate that this early media (o=
h,
>> dread phrase) is acceptable.
>>
>
>  Yes, I think we need a new ICE option, or else old ICE impls in the
> controlled role will be surprised when they think the selected pair is A
> but media arrives on B. We've already seen a number of implementations ha=
ve
> issues with this.
>
>
>  Do they have issues receiving media if there is no selected pair yet?
>  This would be nonconformant with 5245, but nevertheless wouldn=E2=80=99t=
 surprise
> me.
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--089e0158ca7e7749b104ff701f76
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The main problem with the aggressive version of regular nomi=
nation is stuff like DTLS/SRTP (that's actually already kind of an issu=
e with today's aggressive nomination).


When it's RTP you don't care where you get it from a=
s long as you do. If it's a DTLS client halo then what do you do exactl=
y? 


Can the controlling agent simply respond on a different vali=
d pair than the one on which it received it? (This is what Chrome currently=
 does but its frowned upon by the DTLS/SRTP draft which binds the context t=
o a specific address:port). Does the controlled agent need to resend it on =
the new pair after it gets the USE-CANDIDATE?



What about other protocols? Do they all need to say how they=
 are to be used with ICE? I hope not and I hope we can find a generic appro=
ach for all of them. For example: all early non-acknowledged reliable data =
has to be resent on the nominated pair. This would imply a DTLS neg restart=
 as Martin suggested.




--sent from my mobile


On 30 Jul 2014 11:14 PM, "Jonathan Lennox&q=
uot; <jonathan@vidyo.com> w=
rote:












On Jul 30, 2014, at 4:59 PM, Justin Uberti <juberti@google.com> wrote:










On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox=
 
<jonathan@vidyo.=
com> wrote:





On Jul 29, 2014, at 1:57 PM, Justin Uberti <juberti@google.com> wrote:

>

> The one thing we need to do is update ICE to allow the CONTROLLING sid=
e to make dynamic decisions about which pair to use, instead of being force=
d to use PRIORITY (which is what 5245 says). I am going to try to write thi=
s up before Hawaii.




This is equivalent to using regular nomination, but saying that an endpoint=
 can send media on any Confirmed candidate pair, not just the Selected one,=
 right?









It's a bit more than that - the controlled endpoint has to also sy=
nchronize on the candidate pair, which means that it needs to know what its=
 selected pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use =
the highest priority nominated pair).







So it becomes:


- controlling side can pick any nominated candidate pair it wants to b=
e its selected pair


- controlled side should use presence of media from controlling side t=
o decide selected pair (for secure media), or some TBD attribute (for non-s=
ecure media)


- controlling side can tell controlled side when it is OK to discard c=
andidate pairs that it has nominated (so that the controlling side can stil=
l safely do the switch to a new pair). This is probably done by having the =
controlled side keep all candidates
 alive that have received a check from the controlling side in the past XX =
seconds.















You=E2=80=99ve just reinvented regular nomination =E2=80=94 your =E2=
=80=9CTBD attribute=E2=80=9D is regular nomination=E2=80=99s USE-CANDIDATE.=








Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination=
, but allow media to be sent on any valid pair prior to selection. =C2=A0(Y=
es, re-reading 5245, I should have said =E2=80=9CValid=E2=80=9D rather than=
 =E2=80=9CConfirmed=E2=80=9D. =C2=A0I mis-remembered the terminology.)
















5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair. =C2=A0I don=E2=80=99=
t know if this means, in practice, that ICE-bis could change to the behavio=
r I=E2=80=99ve described above and still be backward
 compatible, or if there=E2=80=99d need to be some sort of ice-option negot=
iation to indicate that this early media (oh, dread phrase) is acceptable.<=
br>








Yes, I think we need a new ICE option, or else old ICE impls in the co=
ntrolled role will be surprised when they think the selected pair is A but =
media arrives on B. We've already seen a number of implementations have=
 issues with this.=C2=A0















Do they have issues receiving media if there is no selected pair yet? =
=C2=A0This would be nonconformant with 5245, but nevertheless wouldn=E2=80=
=99t surprise me.







_______________________________________________

mmusic mailing list

mmusic@ietf.org

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




--089e0158ca7e7749b104ff701f76--


From nobody Wed Jul 30 14:57:06 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDBC1A0145 for ; Wed, 30 Jul 2014 14:57:04 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wy0kxCaLgn5 for ; Wed, 30 Jul 2014 14:57:03 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A3E1A0119 for ; Wed, 30 Jul 2014 14:57:02 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id p10so1876301wes.30 for ; Wed, 30 Jul 2014 14:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8yRP3Td/EVxSSLTOMatsp+xhtoHv97FXMrfFtSGwh10=; b=QlB5e9u6Uhh6/vy6Axs20M3HXlHxsN6Tj5EDlezsVYTtGL0Y3nlKcGH8CpjPwVRCz2 15VtKG1Yvhi33bzD98ZuFpGCwGh+mHUAjW42eH5qhg3JGJzAcV5Q6BxlJ9W8fpzGDCvd cS8SkpCkGdtQUXcUIkSXzp8+xJRkt4L97hIia27BzJf1al7EmldIV0fW1TIPsHp7OQ1V 8lAW3tPHMLbFiDoazlZ8/tjIaIzAQ05SDqkPGUi7aIqUKVdU8/lDnLFGNX+KbZeHFNJ5 dWyJOSKBtcNSDrMeaoKh4RRwWW/zaaBvrAHQi5d2sJKn4ffwwicPxG+syT6UwWdr6fzg dZgg==
MIME-Version: 1.0
X-Received: by 10.180.92.38 with SMTP id cj6mr10030058wib.64.1406757421409; Wed, 30 Jul 2014 14:57:01 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 14:57:01 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>  
Date: Wed, 30 Jul 2014 14:57:01 -0700
Message-ID: 
From: Martin Thomson 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Hr9ZL8g31L0qt5y_7UNKKDZO3FQ
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 21:57:05 -0000

On 30 July 2014 14:04, Justin Uberti  wrote:
>
> I don't follow the logic here. If a pair is on the valid list (I assume that
> is what Jonathan means by Confirmed), you have received a check response.

If you are sending, this isn't an issue.  It's the receiver that needs
to concern itself with having to receive packets on any one of up to
100 candidate pairs.  It will have seen a check on the pair
previously, but it might not have generated a check itself yet.  This
can happen when trickling.


From nobody Wed Jul 30 14:59:59 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476681A0422 for ; Wed, 30 Jul 2014 14:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O43yzKazkv_4 for ; Wed, 30 Jul 2014 14:59:51 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599431A016C for ; Wed, 30 Jul 2014 14:59:48 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id le20so2872242vcb.14 for ; Wed, 30 Jul 2014 14:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UmaFJnEfhQ2vq45/fQ4TPRh8sWQYxlBpk8pQfP47cb0=; b=mTSOe2RG072w/foYp8arNW26XrNAehJFHrYxnZcwmPmYi3pSoPOHTnKOJ9L+CDQoov uAP0c784G0kFDxLVxNdZvpX5DL9YBCZ54l/DAxVfdOCqtl+NKop6MwL26+7qg80o5BVk m3bA2pEP440jovRqcD+YXb0qEPIb5VYR4yX9+nICYuPqZt2Zprh1uTffaX5L7J1VOdCs i4QAQGdcO7UB03FjtY9o3HFZvcc0x/vgnzkEI5jru6EvkpOLoUnWGWRhDPa8+S6qO6GU AdQNgsW3qHRJWegHf8Mk86QcaIrueYTCHt56mZu4BeXqk2vITwucXcE+ojSv+3M1EK0S fkCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UmaFJnEfhQ2vq45/fQ4TPRh8sWQYxlBpk8pQfP47cb0=; b=BFYuh8v3+ue17I/84QJnYehMLk6bFTndnaDY4rdVQHcXOZPnDTVDlZTbwLS18kEW1d hLIdupAlSVDY2xM6KT9+bi7RKuUXauui99sEWnMn6Xpn831SOXIHXj8pVG84KATbpBVV os+quNlOz0SKFDihsWWXnqjLCA3Tk4EElsv/GUgT33GRRen7d4FyaFBxxEW9zj6lcRqV H4kbQp7aSVluLR65s/NM68cY2luj4L4ZWRVoK3wi1kXJ3FN29twmCg6vgAtjQnTYs0sv aCLqZpQViplpoe2LMHUjfamhNeJDhrZsNVLky1vqYf1/5fHsDBxjvVGUYyWjo29k019O HqOw==
X-Gm-Message-State: ALoCoQnS1dBcDiLe9Tgk9QEAVfKzPY4QgCVYGGd4V2VR6m8EgWgxIwawDCAi6PpEgAFew6bixJf2
X-Received: by 10.221.41.135 with SMTP id tu7mr6579562vcb.70.1406757587499; Wed, 30 Jul 2014 14:59:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 14:59:26 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>  
From: Justin Uberti 
Date: Wed, 30 Jul 2014 14:59:26 -0700
Message-ID: 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=001a1133901c49dc4b04ff7046db
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/090JRG08imeRJUv6aojnYCvwLYQ
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 21:59:56 -0000

--001a1133901c49dc4b04ff7046db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox  wrote=
:

>
>  On Jul 30, 2014, at 4:59 PM, Justin Uberti  wrote:
>
>   On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox 
> wrote:
>
>>
>> On Jul 29, 2014, at 1:57 PM, Justin Uberti  wrote:
>> >
>> > The one thing we need to do is update ICE to allow the CONTROLLING sid=
e
>> to make dynamic decisions about which pair to use, instead of being forc=
ed
>> to use PRIORITY (which is what 5245 says). I am going to try to write th=
is
>> up before Hawaii.
>>
>> This is equivalent to using regular nomination, but saying that an
>> endpoint can send media on any Confirmed candidate pair, not just the
>> Selected one, right?
>>
>
>  It's a bit more than that - the controlled endpoint has to also
> synchronize on the candidate pair, which means that it needs to know what
> its selected pair should be, using logic other than what is outlined in
> http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
> highest priority nominated pair).
>
>  So it becomes:
> - controlling side can pick any nominated candidate pair it wants to be
> its selected pair
> - controlled side should use presence of media from controlling side to
> decide selected pair (for secure media), or some TBD attribute (for
> non-secure media)
> - controlling side can tell controlled side when it is OK to discard
> candidate pairs that it has nominated (so that the controlling side can
> still safely do the switch to a new pair). This is probably done by havin=
g
> the controlled side keep all candidates alive that have received a check
> from the controlling side in the past XX seconds.
>
>
>  You=E2=80=99ve just reinvented regular nomination =E2=80=94 your =E2=80=
=9CTBD attribute=E2=80=9D is
> regular nomination=E2=80=99s USE-CANDIDATE.
>

>  Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination, =
but allow media
> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, =
I
> should have said =E2=80=9CValid=E2=80=9D rather than =E2=80=9CConfirmed=
=E2=80=9D.  I mis-remembered the
> terminology.)
>

Understood. But controlled side needs some way to know what pair it should
use to send media, so we need some way to indicate this. Would this be done
via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATEs as
we figure out the ideal path to use, which doesn't fit exactly with regular
nomination as defined in 5245, but otherwise seems exactly like what I am
proposing. Basically, controlled side uses the pair that it most recently
received USE-CANDIDATE on as its selected pair.

>
>    5245 says that an ICE endpoint MUST be prepared to receive media on
>> any candidate, but only sends on the Selected candidate pair.  I don=E2=
=80=99t know
>> if this means, in practice, that ICE-bis could change to the behavior I=
=E2=80=99ve
>> described above and still be backward compatible, or if there=E2=80=99d =
need to be
>> some sort of ice-option negotiation to indicate that this early media (o=
h,
>> dread phrase) is acceptable.
>>
>
>  Yes, I think we need a new ICE option, or else old ICE impls in the
> controlled role will be surprised when they think the selected pair is A
> but media arrives on B. We've already seen a number of implementations ha=
ve
> issues with this.
>
>
>  Do they have issues receiving media if there is no selected pair yet?
>  This would be nonconformant with 5245, but nevertheless wouldn=E2=80=99t=
 surprise
> me.
>

Since the controlled side sends the ClientHello in the typical case, this
isn't usually a problem. The issue that is most often seen is that the
ServerHello comes from B instead of A and is ignored.

--001a1133901c49dc4b04ff7046db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox =
<jonathan@vidyo.=
com> wrote:















On Jul 30, 2014, at 4:59 PM, Justin Uberti <juberti@google.com> wrote:










On Wed, Jul 30, 2014 at 8:10 AM, Jonathan L=
ennox 
<jonathan@vidyo.=
com> wrote:





On Jul 29, 2014, at 1:57 PM, Justin Uberti <juberti@google.com> wrote:

>

> The one thing we need to do is update ICE to allow the CONTROLLING sid=
e to make dynamic decisions about which pair to use, instead of being force=
d to use PRIORITY (which is what 5245 says). I am going to try to write thi=
s up before Hawaii.






This is equivalent to using regular nomination, but saying that an endpoint=
 can send media on any Confirmed candidate pair, not just the Selected one,=
 right?









It's a bit more than that - the controlled endpoint has to also sy=
nchronize on the candidate pair, which means that it needs to know what its=
 selected pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use =
the highest priority nominated pair).







So it becomes:


- controlling side can pick any nominated candidate pair it wants to b=
e its selected pair


- controlled side should use presence of media from controlling side t=
o decide selected pair (for secure media), or some TBD attribute (for non-s=
ecure media)


- controlling side can tell controlled side when it is OK to discard c=
andidate pairs that it has nominated (so that the controlling side can stil=
l safely do the switch to a new pair). This is probably done by having the =
controlled side keep all candidates
 alive that have received a check from the controlling side in the past XX =
seconds.















You=E2=80=99ve just reinvented regular nomination =E2=80=94 your =E2=
=80=9CTBD attribute=E2=80=9D is regular nomination=E2=80=99s USE-CANDIDATE.=












Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination=
, but allow media to be sent on any valid pair prior to selection. =C2=A0(Y=
es, re-reading 5245, I should have said =E2=80=9CValid=E2=80=9D rather than=
 =E2=80=9CConfirmed=E2=80=9D. =C2=A0I mis-remembered the terminology.)




Understood. But controlled sid=
e needs some way to know what pair it should use to send media, so we need =
some way to indicate this. Would this be done via USE-CANDIDATE? If so, we =
could end up with multiple USE-CANDIDATEs as we figure out the ideal path t=
o use, which doesn't fit exactly with regular nomination as defined in =
5245, but otherwise seems exactly like what I am proposing. Basically, cont=
rolled side uses the pair that it most recently received USE-CANDIDATE on a=
s its selected pair.




















5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair. =C2=A0I don=E2=80=99=
t know if this means, in practice, that ICE-bis could change to the behavio=
r I=E2=80=99ve described above and still be backward
 compatible, or if there=E2=80=99d need to be some sort of ice-option negot=
iation to indicate that this early media (oh, dread phrase) is acceptable.<=
br>








Yes, I think we need a new ICE option, or else old ICE impls in the co=
ntrolled role will be surprised when they think the selected pair is A but =
media arrives on B. We've already seen a number of implementations have=
 issues with this.=C2=A0

















Do they have issues receiving media if there is no selected pair yet? =
=C2=A0This would be nonconformant with 5245, but nevertheless wouldn=E2=80=
=99t surprise me.

Since the con=
trolled side sends the ClientHello in the typical case, this isn't usua=
lly a problem. The issue that is most often seen is that the ServerHello co=
mes from B instead of A and is ignored.





--001a1133901c49dc4b04ff7046db--


From nobody Wed Jul 30 15:01:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3562B1A0659 for ; Wed, 30 Jul 2014 15:01:34 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INJN3wU4OFcm for ; Wed, 30 Jul 2014 15:01:31 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C881A0654 for ; Wed, 30 Jul 2014 15:01:31 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id k48so1899272wev.12 for ; Wed, 30 Jul 2014 15:01: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=3RWgDUdtuX27eZ4ozQhsJfh8s0eKsmtCtJYS+1wwJeU=; b=AbXyd0An8ulExrAdB5LtKdCEzUyOjuRYtjr/l8PBHBVCZHUuJo5g/oCDKawzMM0Xve d4y5itKxwTxBzMrlDv/QS/xIj43OQnoecLMjvQ/AJ5y55kuRsV2tAgenEGXX4yfXhEAu G87y9JBxk+Uz5rEN+mYxPNhOtAugosrjJ5+c3AISJt7yK0Lrz+Ts3yEqMfu6gpRHwJN0 viQc1tYPbJNoqigCT1N658Tstkbv50CsYAaFl8zQIK6ZvGNdLcfd1A0jmXfJ08x4AIvX UMx3UCv6R3BHrSYx7PJaS0opWfk9L2c/zGsVfbWxZizSrq/yUD5uec1TbmX61F3lTncN WCEA==
MIME-Version: 1.0
X-Received: by 10.180.187.197 with SMTP id fu5mr11019376wic.64.1406757689760;  Wed, 30 Jul 2014 15:01:29 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 15:01:29 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>   
Date: Wed, 30 Jul 2014 15:01:29 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ap6YwdzTkuSO5xduO7wSXFBT-UE
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:01:34 -0000

On 30 July 2014 14:48, Emil Ivov  wrote:
> When it's RTP you don't care where you get it from as long as you do. If
> it's a DTLS client halo then what do you do exactly?
>
> Can the controlling agent simply respond on a different valid pair than the
> one on which it received it? (This is what Chrome currently does but its
> frowned upon by the DTLS/SRTP draft which binds the context to a specific
> address:port). Does the controlled agent need to resend it on the new pair
> after it gets the USE-CANDIDATE?

RFC 5764 says this:
   A single DTLS-SRTP session only protects data carried over
   a single UDP source and destination port pair.

But I'll postulate that this is only because the alternative (a
shifting substrate) was not yet conceived.  There is nothing in (D)TLS
that requires anything of the underlying transport protocol,
intentionally.  (c.f., tcpinc wg)

Firefox code seems to be OK (at least superficially) with the idea
that packets can arrive from anywhere.  However, I can see why some
implementations might get sad if things shift around.


From nobody Wed Jul 30 15:05:50 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830A81A0657 for ; Wed, 30 Jul 2014 15:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc89itIgKZvX for ; Wed, 30 Jul 2014 15:05:42 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419CA1A01CA for ; Wed, 30 Jul 2014 15:05:42 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so2917128vcb.15 for ; Wed, 30 Jul 2014 15:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UVrvXjhylxF5E4LYe4X3BGZrWismSoSsDjVpVFBUVhk=; b=B3HHb2/pDo2H7AqoZ5OB57pzSCOpcvEM2DCUoU0MZinfmu6Ez6cSd5apj5lexSY2wX RgTsfhwY7T585/E7WUkY2fV/yf3Dxe37A9LmMImcfLAzQ7d+8IfuDGJ8+QuojDL01CAJ 57/7BXNGw8vIKpGewB+8s9zrJ4nkdxZJwt8vB/1WWd5H8beESqZvzcZBPyzv+UIvJ41Q kM8glpW2lFenxfVvjB3OD40O+3bKISxh64MeTk/QFmZIxFpfp6pJrhM2Xqd8Zlt5Eqbr sXePCu/vyjV3XL6zSJaUbEPKSXLGNrndWGAL5G/mfI7VPiEbdRoSkKum/gYri/H5r0FI rsHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UVrvXjhylxF5E4LYe4X3BGZrWismSoSsDjVpVFBUVhk=; b=AqdjZ95TvzctzOqUvpPC1txGMQ5zEybqLBYumAoqsZM0ZKqHWkbTFfBqA8L0DwSWOS GEd6P7EqPNBbS+mLfsB8gDOJLByPBWYwZapjVw2oLhoV8PLZDmUuNl193y2mruiB2DS1 Y2LM4xwsYeaQvSSby5CSAnO1ih+ju29prd80rOJoQvMPb2f9cDNsQEaWTKKWkopbdmuq VgqrjOpj//HLMsSP8uhxvVFkpnUvGhDW8GVB1OWpB3fCNdCbsRZaZgxdUwd0oUe0nWcb Uf8xfg7lYSIWm54y51rZdyvwz+9+KZ1bhwF1m9Mq1a653pf57NT4Mzfgidzry0ZbFQW6 g8DA==
X-Gm-Message-State: ALoCoQm17gz3WkevbpBVzJ7x+wKbEuDfynSLpiaxMASiC+RosiCksJa+5p/DogQQrnQHWjrevyo8
X-Received: by 10.53.5.163 with SMTP id cn3mr11117613vdd.3.1406757941452; Wed, 30 Jul 2014 15:05:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 15:05:21 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    
From: Justin Uberti 
Date: Wed, 30 Jul 2014 15:05:21 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a1133ce6e62bc5104ff705bd8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ap_-BiSMmia4cJBhCC9vHbgXE8E
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:05:44 -0000

--001a1133ce6e62bc5104ff705bd8
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 30, 2014 at 3:01 PM, Martin Thomson 
wrote:

> On 30 July 2014 14:48, Emil Ivov  wrote:
> > When it's RTP you don't care where you get it from as long as you do. If
> > it's a DTLS client halo then what do you do exactly?
> >
> > Can the controlling agent simply respond on a different valid pair than
> the
> > one on which it received it? (This is what Chrome currently does but its
> > frowned upon by the DTLS/SRTP draft which binds the context to a specific
> > address:port). Does the controlled agent need to resend it on the new
> pair
> > after it gets the USE-CANDIDATE?
>
> RFC 5764 says this:
>    A single DTLS-SRTP session only protects data carried over
>    a single UDP source and destination port pair.
>
> But I'll postulate that this is only because the alternative (a
> shifting substrate) was not yet conceived.  There is nothing in (D)TLS
> that requires anything of the underlying transport protocol,
> intentionally.  (c.f., tcpinc wg)
>
> Firefox code seems to be OK (at least superficially) with the idea
> that packets can arrive from anywhere.  However, I can see why some
> implementations might get sad if things shift around.
>
>
Agreed. I think unless there is some dependency on the lower layer protocol
specifics (which should be uncommon, if at all), the expectation should be
that ICE is a generic, dynamic packet transport (AKA shifting substrate).

--001a1133ce6e62bc5104ff705bd8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 3:01 PM, Martin Thomson &=
lt;martin.tho=
mson@gmail.com> wrote:



On 30 July 2014 14:48, Emil =
Ivov <emcho@jitsi.org> wrote:<=
br>

> When it's RTP you don't care where you get it from as long as =
you do. If

> it's a DTLS client halo then what do you do exactly?

>

> Can the controlling agent simply respond on a different valid pair tha=
n the

> one on which it received it? (This is what Chrome currently does but i=
ts

> frowned upon by the DTLS/SRTP draft which binds the context to a speci=
fic

> address:port). Does the controlled agent need to resend it on the new =
pair

> after it gets the USE-CANDIDATE?




RFC 5764 says this:

=C2=A0 =C2=A0A single DTLS-SRTP session only protects data carried over

=C2=A0 =C2=A0a single UDP source and destination port pair.



But I'll postulate that this is only because the alternative (a

shifting substrate) was not yet conceived. =C2=A0There is nothing in (D)TLS=


that requires anything of the underlying transport protocol,

intentionally. =C2=A0(c.f., tcpinc wg)



Firefox code seems to be OK (at least superficially) with the idea

that packets can arrive from anywhere. =C2=A0However, I can see why some
implementations might get sad if things shift around.



<=
br>
Agreed. I think unless there is some dependency on the lower =
layer protocol specifics (which should be uncommon, if at all), the expecta=
tion should be that ICE is a generic, dynamic packet transport (AKA shiftin=
g substrate).





--001a1133ce6e62bc5104ff705bd8--


From nobody Wed Jul 30 15:06:15 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF71A07AB for ; Wed, 30 Jul 2014 15:06:09 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9060RIdEFCCv for ; Wed, 30 Jul 2014 15:06:07 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BA41A01CA for ; Wed, 30 Jul 2014 15:06:06 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so1826895wgh.23 for ; Wed, 30 Jul 2014 15:06: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=28QpCY8Dhl2NDMlYgjvGafOw5sp7RjyAPPgLTX8e/LA=; b=pzP5tXRCduv7sK6R/XF96EcYFHqJIsQQ1RjPhcb+y2JL+IwBTXx5zcO1yQmuvGt8MX Qataa0w8cxAvNXDpoC0p+MwTegftAgwcoYgyjATgvN01GnPH2YUXbAKtRy7S7YSkyIkd EdYsInY42tTxAuTddQoCistTq0IomuXvgZVKK7y/ZiAENUvDZuTYtfsEcZ32FkET09n6 T+CQIN8dXgw1TZhG8TSkPHtneq7E990prJ4fIYdM3zILh+Zl4UN8svNfjqJhXjfOBeeH Y42ykDJzrYGz51y18kOhxLAklgs5oNRdNUu6BiepXg2OC0GDa6oIOsackoM472QfRzJz 1d7Q==
MIME-Version: 1.0
X-Received: by 10.180.103.74 with SMTP id fu10mr9932234wib.47.1406757965464; Wed, 30 Jul 2014 15:06:05 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 15:06:05 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>   
Date: Wed, 30 Jul 2014 15:06:05 -0700
Message-ID: 
From: Martin Thomson 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Kh4-38XzFpiB_tkdsBZVPdMLxyA
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:06:09 -0000

On 30 July 2014 14:59, Justin Uberti  wrote:
> Basically, controlled side uses the pair that it most recently received
> USE-CANDIDATE on as its selected pair.

That's pretty good.  It would potentially allow us to move the active
pair around in future (i.e., mobility stuff) without massive backward
compatibility breaks too.  Unilaterally even.

> Since the controlled side sends the ClientHello in the typical case, this
> isn't usually a problem. The issue that is most often seen is that the
> ServerHello comes from B instead of A and is ignored.

Yeah, this works out pretty well, unless you have the offerer picking
an active role intentionally.  (We've had some errors come up recently
where there was confusion about which role was which; we definitely
want to avoid that.)


From nobody Wed Jul 30 15:16:51 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338121A01AA for ; Wed, 30 Jul 2014 15:16:49 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtyJ36SUg5TD for ; Wed, 30 Jul 2014 15:16:47 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438E01A0428 for ; Wed, 30 Jul 2014 15:16:47 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id x48so1874025wes.5 for ; Wed, 30 Jul 2014 15:16:45 -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=svQiAfR1bId0i9X/i1uLsZqqiGNtR+j4O/864DG8psY=; b=poM6OxMhlc1CsG4TXpv65FpfWWoyX7VAcZMbPbMjBWmSHKdG2dzAH1geqC97yK89PY V2gs5NyhJe2HA4Ml945/gjOwaT1cMAWJZrUAGZgnkfXP+zHsUWzWZl2+dJdqNVMwnwJx ee5xUczuNGr7FT6tVt6Brq5RM+VYpOBUt5kEEkjxo2pDoHODJpy2BY/dldU43nxCiEQv 4QaGbWQWZBn1eJyISS0SMBqslMMnR/FNRVZez4v4d2GSEV+cG1arTjxZEu1eeye4/SsX o3I5szPH5pU/bIvsaGOWsZQKdiEaOunaCeYWrDOMjI7KetyB60+HO2zBljGGtI5op8Mb D0AA==
MIME-Version: 1.0
X-Received: by 10.180.211.237 with SMTP id nf13mr10952029wic.47.1406758605140;  Wed, 30 Jul 2014 15:16:45 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 15:16:45 -0700 (PDT)
Date: Wed, 30 Jul 2014 15:16:45 -0700
Message-ID: 
From: Martin Thomson 
To: "mmusic@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AROA23TzFrxagK0npYgarDxKQ4c
Subject: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:16:49 -0000

RFC 5245 states that the controlling peer is the offerer, period.
This delays the start of nomination until the answer arrives.

What do folks think about an ICE option like the following?

The option is added to the offer to say: I'm OK if the answerer
nominates.  The answerer echoes the option to indicate that it will
nominate.

The answerer nominating would allow it to send a DTLS ClientHello and
the USE-CANDIDATE check in immediate succession.  That removes the
signaling return path from the session setup time when doing
aggressive nomination.  And it would let us use Jonathan's "aggressive
nomination without USE-CANDIDATE" technique all the time.  We could
then effectively deprecate aggressive nomination, since there are no
real latency gains to be had.

I've probably missed something critical here, so take this opportunity
to tell me that I'm stupid.


From nobody Wed Jul 30 15:20:59 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E391A01AA for ; Wed, 30 Jul 2014 15:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level: 
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvva6x-1a0Ne for ; Wed, 30 Jul 2014 15:20:56 -0700 (PDT)
Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865CE1A00E8 for ; Wed, 30 Jul 2014 15:20:56 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 6:20:53 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-230/SG:5 7/30/2014 6:20:18 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.900414 p=-0.977539 Source White
X-Signature-Violations: 0-0-0-15963-c
X-Note-419: 15.6004 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 6:20:48 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 117160469; Wed, 30 Jul 2014 18:20:53 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 17:20:52 -0500
From: Jonathan Lennox 
To: Justin Uberti 
Thread-Topic: Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
Thread-Index: AQHPrAhtxaTuo9vyTE6R2p2YHkJufJu5biYAgAAEI4CAAAyGAIAABf0A
Date: Wed, 30 Jul 2014 22:20:51 +0000
Message-ID: <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_4877642385944133BD233EA561EC2A9Dvidyocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/l33GG3hGnj4lomnc585gYRtyGoU
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:20:58 -0000

--_000_4877642385944133BD233EA561EC2A9Dvidyocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


On Jul 30, 2014, at 5:59 PM, Justin Uberti > wrote:

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox > wrote:
Thus the suggestion I=92m making =97 do regular nomination, but allow media=
 to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, I=
 should have said =93Valid=94 rather than =93Confirmed=94.  I mis-remembere=
d the terminology.)

Understood. But controlled side needs some way to know what pair it should =
use to send media, so we need some way to indicate this. Would this be done=
 via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATEs as =
we figure out the ideal path to use, which doesn't fit exactly with regular=
 nomination as defined in 5245, but otherwise seems exactly like what I am =
proposing. Basically, controlled side uses the pair that it most recently r=
eceived USE-CANDIDATE on as its selected pair.

Oh, that=92s true, it has to pick something.

In the semantic I=92m suggestion, I think it doesn=92t matter what it picks=
 =97 it could choose any valid pair, just like the controlling agent does, =
since it knows that=92s a working round-trip path.

For both sides, if you receive media on any candidate (from an IP and port =
from which you=92ve received a valid connectivity check), accept it.  USE-C=
ANDIDATE is then just an optimization that lets you close down the unselect=
ed candidates.

I don=92t think you want a rule of =93most recently received USE-CANDIDATE=
=94 to determine the selected pair.  Checks will race each other, especiall=
y when the paths=92 RTTs are very different.

In my model, there is only ever one USE-CANDIDATE sent per component =97 i.=
e., it works like pure regular nomination, except for the =93early media=94=
.

5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair.  I don=92t know if t=
his means, in practice, that ICE-bis could change to the behavior I=92ve de=
scribed above and still be backward compatible, or if there=92d need to be =
some sort of ice-option negotiation to indicate that this early media (oh, =
dread phrase) is acceptable.

Yes, I think we need a new ICE option, or else old ICE impls in the control=
led role will be surprised when they think the selected pair is A but media=
 arrives on B. We've already seen a number of implementations have issues w=
ith this.

Do they have issues receiving media if there is no selected pair yet?  This=
 would be nonconformant with 5245, but nevertheless wouldn=92t surprise me.

Since the controlled side sends the ClientHello in the typical case, this i=
sn't usually a problem. The issue that is most often seen is that the Serve=
rHello comes from B instead of A and is ignored.

These are all in cases when the controlling endpoint is using aggressive no=
mination, though, right?  Do you have any data for regular nomination, i.e.=
 media received before any USE-CANDIDATE attribute?

--_000_4877642385944133BD233EA561EC2A9Dvidyocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <896BB61720059E4E83A6F3B58A6C9738@vidyo.com>
Content-Transfer-Encoding: quoted-printable











On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote:













On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox=
 
<jonathan@vidyo.=
com> wrote:






Thus the suggestion I=92m making =97 do regular nomination, but allow =
media to be sent on any valid pair prior to selection.  (Yes, re-readi=
ng 5245, I should have said =93Valid=94 rather than =93Confirmed=94.  =
I mis-remembered the terminology.)











Understood. But controlled side needs some way to know what pair it sh=
ould use to send media, so we need some way to indicate this. Would this be=
 done via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATE=
s as we figure out the ideal path
 to use, which doesn't fit exactly with regular nomination as defined in 52=
45, but otherwise seems exactly like what I am proposing. Basically, contro=
lled side uses the pair that it most recently received USE-CANDIDATE on as =
its selected pair.















Oh, that=92s true, it has to pick something.







In the semantic I=92m suggestion, I think it doesn=92t matter&n=
bsp;what it picks =97 it could choose any valid pair, just like the control=
ling agent does, since it knows that=92s a working round-trip path.







For both sides, if you receive media on any candidate (from an IP and =
port from which you=92ve received a valid connectivity check), accept it. &=
nbsp;USE-CANDIDATE is then just an optimization that lets you close down th=
e unselected candidates.







I don=92t think you want a rule of =93most recently received USE-CANDI=
DATE=94 to determine the selected pair.  Checks will race each other, =
especially when the paths=92 RTTs are very different.







In my model, there is only ever one USE-CANDIDATE sent per component =
=97 i.e., it works like pure regular nomination, except for the =93early me=
dia=94.



























5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair.  I don=92t know=
 if this means, in practice, that ICE-bis could change to the behavior I=92=
ve described above and still be backward
 compatible, or if there=92d need to be some sort of ice-option negotiation=
 to indicate that this early media (oh, dread phrase) is acceptable.









Yes, I think we need a new ICE option, or else old ICE impls in the co=
ntrolled role will be surprised when they think the selected pair is A but =
media arrives on B. We've already seen a number of implementations have iss=
ues with this. 














Do they have issues receiving media if there is no selected pair yet? =
 This would be nonconformant with 5245, but nevertheless wouldn=92t su=
rprise me.











Since the controlled side sends the ClientHello in the typical case, t=
his isn't usually a problem. The issue that is most often seen is that the =
ServerHello comes from B instead of A and is ignored.














These are all in cases when the controlling endpoint is using aggressi=
ve nomination, though, right?  Do you have any data for regular nomina=
tion, i.e. media received before any USE-CANDIDATE attribute?




--_000_4877642385944133BD233EA561EC2A9Dvidyocom_--


From nobody Wed Jul 30 15:28:26 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B071A0295 for ; Wed, 30 Jul 2014 15:28:25 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFmxaCBNdEyt for ; Wed, 30 Jul 2014 15:28:22 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942581A0111 for ; Wed, 30 Jul 2014 15:28:22 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hi2so8341836wib.4 for ; Wed, 30 Jul 2014 15:28:21 -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=oo4MhiKCXSm44PE5/zxL2IuwFnS93EIzymH8vH+kY4o=; b=yBxZ23BQdoNSXakPd0oWRnhUfsPQjJtECojQG+9mYWu1IKAc6YicAJd6AelAo9Vdwu gdadBIW0bB2W5lgmqzxchWssaqUIrKSggir0a/G0abJbqN4u+WCdyhcbzCSa1v/NmYoS h/PvQ8AgtbUSt/SZPQf1CrjkSf7DKYlAU+gwLF+pLeNEw8h8TM9GDJYHeJS4MDHe1ZpR X02VMjKM1rKxpgXcxglczi0iadLqXP7huJOGMaL6sUxBPWK36zfCGXMcc6NpPjqV4KA+ MC7tNomkyyQv9+D40BszYVZvxL7G93zVhLtICZgVXEAtrG6IEjIZIwxhkU8ygYW7frnp Zvlw==
MIME-Version: 1.0
X-Received: by 10.180.73.6 with SMTP id h6mr9901090wiv.65.1406759301169; Wed, 30 Jul 2014 15:28:21 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 15:28:21 -0700 (PDT)
In-Reply-To: <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
Date: Wed, 30 Jul 2014 15:28:21 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UMKH9xUtiePe4RUqOFtEyGxK5R4
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:28:25 -0000

On 30 July 2014 15:20, Jonathan Lennox  wrote:
>
> I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently received =
USE-CANDIDATE=E2=80=9D to
> determine the selected pair.  Checks will race each other, especially whe=
n
> the paths=E2=80=99 RTTs are very different.
>
> In my model, there is only ever one USE-CANDIDATE sent per component =E2=
=80=94 i.e.,
> it works like pure regular nomination, except for the =E2=80=9Cearly medi=
a=E2=80=9D.

If the controlled peer really does use this as a signal that it's safe
to close out other candidates, then you really do have to have just
the one instance.  Is attaching that semantic safe?  I assume that we
would have to signal in both directions that this new meaning is
acceptable first.  (a=3Dice-options again)


From nobody Wed Jul 30 15:51:19 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9021A0097 for ; Wed, 30 Jul 2014 15:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.831
X-Spam-Level: 
X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEAcVopA7hTz for ; Wed, 30 Jul 2014 15:51:14 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53F21A00AD for ; Wed, 30 Jul 2014 15:51:13 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 6:51:10 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-56/SG:2 7/30/2014 6:50:18 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.901204 p=-0.977711 Source White
X-Signature-Violations: 0-0-0-4858-c
X-Note-419: 0 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 6:51:09 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 117165728; Wed, 30 Jul 2014 18:51:10 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 17:51:09 -0500
From: Jonathan Lennox 
To: Martin Thomson 
Thread-Topic: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
Thread-Index: AQHPrAhtxaTuo9vyTE6R2p2YHkJufJu5biYAgAAEI4CAAAyGAIAABf0AgAACF4CAAAZeAA==
Date: Wed, 30 Jul 2014 22:51:08 +0000
Message-ID: <2512D364-E653-4363-8642-9D8EA1A3408C@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5EE145F3AED7D647845DA61599322F9F@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CFQyOlA-Pq7WWLvAsTZpde1pYVM
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:51:15 -0000

On Jul 30, 2014, at 6:28 PM, Martin Thomson  wrot=
e:

> On 30 July 2014 15:20, Jonathan Lennox  wrote:
>>=20
>> I don=92t think you want a rule of =93most recently received USE-CANDIDA=
TE=94 to
>> determine the selected pair.  Checks will race each other, especially wh=
en
>> the paths=92 RTTs are very different.
>>=20
>> In my model, there is only ever one USE-CANDIDATE sent per component =97=
 i.e.,
>> it works like pure regular nomination, except for the =93early media=94.
>=20
> If the controlled peer really does use this as a signal that it's safe
> to close out other candidates, then you really do have to have just
> the one instance.  Is attaching that semantic safe?  I assume that we
> would have to signal in both directions that this new meaning is
> acceptable first.  (a=3Dice-options again)

5245 8.3.1:
   Once ICE processing
   has reached the Completed state for all peers for media streams using
   those candidates, the agent SHOULD wait an additional three seconds,
   and then it MAY cease responding to checks or generating triggered
   checks on that candidate.  It MAY free the candidate at that time.
You enter the =93Completed=94 state once all components of all streams have=
 sent or received (as appropriate) USE-CANDIDATE.

The =93all peers=94 clause is needed for SIP, to handle forking cases.  For=
 non-forking uses of ICE, =93all peers=94 is equivalent to =93the peer=94.=


From nobody Wed Jul 30 15:56:39 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977321A00AF for ; Wed, 30 Jul 2014 15:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJAxDDYpuEQ7 for ; Wed, 30 Jul 2014 15:56:35 -0700 (PDT)
Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E621A0080 for ; Wed, 30 Jul 2014 15:56:35 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 6:56:33 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-56/SG:2 7/30/2014 6:55:45 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.89975 p=-0.981592 Source White
X-Signature-Violations: 0-0-0-3858-c
X-Note-419: 15.6006 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 6:56:18 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 143629908; Wed, 30 Jul 2014 18:56:33 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 17:56:32 -0500
From: Jonathan Lennox 
To: Martin Thomson 
Thread-Topic: [MMUSIC] Faster ICE by role reversal?
Thread-Index: AQHPrETDHXceLg7ZbU2lUKvim4SOLZu5jkoA
Date: Wed, 30 Jul 2014 22:56:31 +0000
Message-ID: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FTdIzDOaAuhWfwb7_pWuQRQIhh4
Cc: mmusic 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:56:37 -0000

On Jul 30, 2014, at 6:16 PM, Martin Thomson  wrot=
e:

> RFC 5245 states that the controlling peer is the offerer, period.
> This delays the start of nomination until the answer arrives.
>=20
> What do folks think about an ICE option like the following?
>=20
> The option is added to the offer to say: I'm OK if the answerer
> nominates.  The answerer echoes the option to indicate that it will
> nominate.
>=20
> The answerer nominating would allow it to send a DTLS ClientHello and
> the USE-CANDIDATE check in immediate succession.  That removes the
> signaling return path from the session setup time when doing
> aggressive nomination.  And it would let us use Jonathan's "aggressive
> nomination without USE-CANDIDATE" technique all the time.  We could
> then effectively deprecate aggressive nomination, since there are no
> real latency gains to be had.
>=20
> I've probably missed something critical here, so take this opportunity
> to tell me that I'm stupid.

The offerer can=92t send its own connectivity checks until it receives an a=
nswer, because it needs the remote ufrag and password.  Without this, it do=
esn=92t have any valid pairs, and so can=92t send any media.

This suggestion might still save half an RTT, though? I=92d need to work th=
rough a full ladder diagram to figure it out.=


From nobody Wed Jul 30 15:57:47 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113AD1A0197 for ; Wed, 30 Jul 2014 15:57:46 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3I8TnRjIUeE for ; Wed, 30 Jul 2014 15:57:44 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F761A00AF for ; Wed, 30 Jul 2014 15:57:43 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so3157209wib.8 for ; Wed, 30 Jul 2014 15:57:42 -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=an+k1eAL3mRfimaWvRDDnHTRpfzuo8IiSgiaj4HxcwY=; b=PWRF0MeixmXXvh2/LKXw7rDECjL1JgpglDwpX6VYwQln6Zi4PyThOZXO7ZxKwIv/rM YNiWI+vZ8qUrLQHq/824mYwnVwRYT7uAT8sZFxrEn1erm60pOc48m0K1MEIcL4MVmDdw MXZoShNFWs7iTE21rQTHFFEQWWQQ0kYiLBEQmOOzeaDYxmGNmQIj3+g0jnzxzAU2DKRM RYOYlOMptk8/bxbvUZgWYib0ZkrGMa4+0ovw+3kt9DOV8pPiL6Y/YRtdneI7PoqVQj+B etZKvDD7a9LG7E2qmVvj6cyx01jIXOBxZ5g7JcN8YMdU/B/1v7TFO4cyRnmCc4jHhRbr c/tw==
MIME-Version: 1.0
X-Received: by 10.194.143.49 with SMTP id sb17mr10425386wjb.25.1406761062240;  Wed, 30 Jul 2014 15:57:42 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 15:57:42 -0700 (PDT)
In-Reply-To: <2512D364-E653-4363-8642-9D8EA1A3408C@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>  <2512D364-E653-4363-8642-9D8EA1A3408C@vidyo.com>
Date: Wed, 30 Jul 2014 15:57:42 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1Kp7INdjClCz-EpPvdS_P7A7W_w
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 22:57:46 -0000

On 30 July 2014 15:51, Jonathan Lennox  wrote:
>
> On Jul 30, 2014, at 6:28 PM, Martin Thomson  wr=
ote:
>> If the controlled peer really does use this as a signal that it's safe
>> to close out other candidates, then you really do have to have just
>> the one instance.  Is attaching that semantic safe?  I assume that we
>> would have to signal in both directions that this new meaning is
>> acceptable first.  (a=3Dice-options again)
>
> 5245 8.3.1:
>    Once ICE processing
>    has reached the Completed state for all peers for media streams using
>    those candidates, the agent SHOULD wait an additional three seconds,
>    and then it MAY cease responding to checks or generating triggered
>    checks on that candidate.  It MAY free the candidate at that time.
> You enter the =E2=80=9CCompleted=E2=80=9D state once all components of al=
l streams have sent or received (as appropriate) USE-CANDIDATE.
>
> The =E2=80=9Call peers=E2=80=9D clause is needed for SIP, to handle forki=
ng cases.  For non-forking uses of ICE, =E2=80=9Call peers=E2=80=9D is equi=
valent to =E2=80=9Cthe peer=E2=80=9D.


I was looking for a stronger signal.  This assumes that the active
pair is the one with the highest candidate for which USE-CANDIDATE has
been sent or received.  But we've been talking about making other
choices.  That would avoid the need for a 3s cleanup timer.


From nobody Wed Jul 30 16:00:14 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB411A01AA for ; Wed, 30 Jul 2014 16:00:12 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJCOVl8G9X37 for ; Wed, 30 Jul 2014 16:00:11 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E091A00AF for ; Wed, 30 Jul 2014 16:00:10 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id l18so1892809wgh.14 for ; Wed, 30 Jul 2014 16:00: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:content-transfer-encoding; bh=ln9Lo7TQwYVZghGoLxf2fzQIcHM/cGxXWz7FIwvjmVE=; b=jW+6aKJTB6RdBpbynkpxZ/zhHNKrW1UHN0tIVbSeMclkLnps9l8gidxLFFfv0sn6HO iH7i/QevOyxwxqrsEP2omgD3c7MdHfMYBF4Y+bNNpmQzjKYjllsFfjDDet5vjyncujx5 8RwSUsgeS3Izit0+agRdPFY16IUqtBdf2maSLPMG4xmaFjBsmT8tD4BRpo2PfPQurvPq 2UcxbZN36jHP/UNdEZpPJXR+THxYA/vPHFLAPeTtpp9wJb4aBzhZIL7p8bEEfxKlxhFX mKD99Cqf/2i6nRaunyY0Fi8QL2I+C7s8KsbACT1/GVCPcQfVqncYxBGFR+81iD5KEwHv /06A==
MIME-Version: 1.0
X-Received: by 10.194.143.49 with SMTP id sb17mr10439069wjb.25.1406761209084;  Wed, 30 Jul 2014 16:00:09 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 16:00:09 -0700 (PDT)
In-Reply-To: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>
Date: Wed, 30 Jul 2014 16:00:09 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SMCr-54xF96tppN52OekQKnkcZE
Cc: mmusic 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 23:00:12 -0000

On 30 July 2014 15:56, Jonathan Lennox  wrote:
> The offerer can=E2=80=99t send its own connectivity checks until it recei=
ves an answer, because it needs the remote ufrag and password.  Without thi=
s, it doesn=E2=80=99t have any valid pairs, and so can=E2=80=99t send any m=
edia.

Of course.  But you could do all the computation necessary for
generating the ServerHello and accompanying messages (which in TLS 1.3
is quite a bit).

> This suggestion might still save half an RTT, though? I=E2=80=99d need to=
 work through a full ladder diagram to figure it out.

That's the idea.  I haven't plotted it all out either, but I think
that this is the fastest possible start assuming that you don't send
any DTLS messages prior to getting a successful connectivity check
response.


From nobody Wed Jul 30 16:05:30 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2211A01AA for ; Wed, 30 Jul 2014 16:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhrQ9kdl2KZb for ; Wed, 30 Jul 2014 16:05:27 -0700 (PDT)
Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CE91A0080 for ; Wed, 30 Jul 2014 16:05:26 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 7:05:25 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-50/SG:2 7/30/2014 7:04:45 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.900165 p=-0.981666 Source White
X-Signature-Violations: 0-0-0-3697-c
X-Note-419: 0 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 7:05:18 PM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 143631624; Wed, 30 Jul 2014 19:05:25 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 18:05:24 -0500
From: Jonathan Lennox 
To: Martin Thomson 
Thread-Topic: [MMUSIC] Faster ICE by role reversal?
Thread-Index: AQHPrETDHXceLg7ZbU2lUKvim4SOLZu5jkoAgAABA4CAAAF2gA==
Date: Wed, 30 Jul 2014 23:05:23 +0000
Message-ID: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PV45Hr-_2WJIq5o2NnMYxTnQJMs
Cc: mmusic 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 23:05:29 -0000

On Jul 30, 2014, at 7:00 PM, Martin Thomson  wrot=
e:

> On 30 July 2014 15:56, Jonathan Lennox  wrote:
>> The offerer can=92t send its own connectivity checks until it receives a=
n answer, because it needs the remote ufrag and password.  Without this, it=
 doesn=92t have any valid pairs, and so can=92t send any media.
>=20
> Of course.  But you could do all the computation necessary for
> generating the ServerHello and accompanying messages (which in TLS 1.3
> is quite a bit).
>=20
>> This suggestion might still save half an RTT, though? I=92d need to work=
 through a full ladder diagram to figure it out.
>=20
> That's the idea.  I haven't plotted it all out either, but I think
> that this is the fastest possible start assuming that you don't send
> any DTLS messages prior to getting a successful connectivity check
> response.

Actually, if the answerer (controlled endpoint) can send on any Valid pair,=
 as in my suggestion, I don=92t think you need the ICE role reversal for th=
is optimization.  It can send ClientHello as soon as its first check succee=
ds, despite never having received any remote checks (with or without USE-CA=
NDIDATE).=


From nobody Wed Jul 30 16:23:37 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6451A03E9 for ; Wed, 30 Jul 2014 16:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v15bsJt2cwc for ; Wed, 30 Jul 2014 16:23:34 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E417C1A03E8 for ; Wed, 30 Jul 2014 16:23:33 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id ij19so3033130vcb.39 for ; Wed, 30 Jul 2014 16:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kupduRGNgwetG5YF6O2djgk0XD0Ji0mWjxuu7piEb8M=; b=Gu9UAISqyEfLLixDmOMor/LPUEyPjGOkHrLqHXqOnI+iD89BGjDx5tnpqAiI9h8wQ2 sMtfYAswfA0ViN8nnJ7A0dqlqFHJur19PR3deVuz7WMguofaT5kEKiJ4ZR+nUXMTzB/a 88VDPwGK7k1bFaKONqwojBKjjJfBFtDQbc06IW12sgxEhutntnUSZjvje4Qry09wxCBU 7mJyzLb7ZawQTvVMHAYl+zvDlm+f+AzjFzRqz8qM9FeGb98KdkhLOW9cOz+NEJzv64R9 C6unRvyU0AUogJiuoMLTwyXDZWrw4l5Bdn26W2I1KmxvWWQ7W5M8za3JAh+gj1CeBigC hYPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kupduRGNgwetG5YF6O2djgk0XD0Ji0mWjxuu7piEb8M=; b=l7eMMy3BpgfRVxcvLz8CBAN3wdHnSU5C1mOa3N/fpmU21CAVoFvatE9eYATs6R1yzN UQldR/WdZLXEAcWsy+8KodtNj8c9v3nxb1quwRcTK4SxMKH4yy1pIb04/4ia8DMX1oNm JoTjpDqcyABiJcEF9uGk30LAXyijmYixW+H8GSWJVT5QaCbEC43v/iec07te5SZMMKHc n4rxFfztLWr78b/gIer4xJUQb6LdueVwa6Ooi9zUuqTNah5cDS6uC4je2z63nglxeBKr MuX4UMf1UncGKzPWo/Sa9Wp0EisKKr1rITilxPjYt5d4SDjOjPt/l9linAIHsSuEx3Cn GIng==
X-Gm-Message-State: ALoCoQkkEyYbe89qIDhl9hh9TfDkPl/68ynI/GuT++0Xw83zYBHZAJg1v5v4oT22N3qFi7suP9q7
X-Received: by 10.221.41.135 with SMTP id tu7mr6961450vcb.70.1406762613030; Wed, 30 Jul 2014 16:23:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 16:23:12 -0700 (PDT)
In-Reply-To: <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
From: Justin Uberti 
Date: Wed, 30 Jul 2014 16:23:12 -0700
Message-ID: 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=001a1133901cd569d104ff71710f
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ppsdk8Bh-_DFbDBI4rTMB7oK1dM
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 23:23:36 -0000

--001a1133901cd569d104ff71710f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox  wrote=
:

>
>  On Jul 30, 2014, at 5:59 PM, Justin Uberti  wrote:
>
>   On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox 
> wrote:
>
>>  Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination,=
 but allow media
>> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245,=
 I
>> should have said =E2=80=9CValid=E2=80=9D rather than =E2=80=9CConfirmed=
=E2=80=9D.  I mis-remembered the
>> terminology.)
>>
>
>  Understood. But controlled side needs some way to know what pair it
> should use to send media, so we need some way to indicate this. Would thi=
s
> be done via USE-CANDIDATE? If so, we could end up with multiple
> USE-CANDIDATEs as we figure out the ideal path to use, which doesn't fit
> exactly with regular nomination as defined in 5245, but otherwise seems
> exactly like what I am proposing. Basically, controlled side uses the pai=
r
> that it most recently received USE-CANDIDATE on as its selected pair.
>
>
>  Oh, that=E2=80=99s true, it has to pick something.
>
>  In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t *matt=
er* what it
> picks =E2=80=94 it could choose any valid pair, just like the controlling=
 agent
> does, since it knows that=E2=80=99s a working round-trip path.
>
>  For both sides, if you receive media on any candidate (from an IP and
> port from which you=E2=80=99ve received a valid connectivity check), acce=
pt it.
>  USE-CANDIDATE is then just an optimization that lets you close down the
> unselected candidates.
>
>  I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently received=
 USE-CANDIDATE=E2=80=9D
> to determine the selected pair.  Checks will race each other, especially
> when the paths=E2=80=99 RTTs are very different.
>
>  In my model, there is only ever one USE-CANDIDATE sent per component =E2=
=80=94
> i.e., it works like pure regular nomination, except for the =E2=80=9Cearl=
y media=E2=80=9D.
>

OK, I get it now. I think the main issues you face are:
1) Inability to selectively free candidates - all candidates except the
selected pair can be freed by the controlled side after USE-CANDIDATE.
2) No guarantee of symmetric RTP - remote side can use a different pair
than local side - and you can't resolve this without USE-CANDIDATE (see #1)=
.
3) Potential issues when media arrives on non-nominated pair.

Given #3, I think I'd prefer to find a solution that also addresses #1/#2.

>
>       5245 says that an ICE endpoint MUST be prepared to receive media on
>>> any candidate, but only sends on the Selected candidate pair.  I don=E2=
=80=99t know
>>> if this means, in practice, that ICE-bis could change to the behavior I=
=E2=80=99ve
>>> described above and still be backward compatible, or if there=E2=80=99d=
 need to be
>>> some sort of ice-option negotiation to indicate that this early media (=
oh,
>>> dread phrase) is acceptable.
>>>
>>
>>  Yes, I think we need a new ICE option, or else old ICE impls in the
>> controlled role will be surprised when they think the selected pair is A
>> but media arrives on B. We've already seen a number of implementations h=
ave
>> issues with this.
>>
>>
>>  Do they have issues receiving media if there is no selected pair yet?
>>  This would be nonconformant with 5245, but nevertheless wouldn=E2=80=99=
t surprise
>> me.
>>
>
>  Since the controlled side sends the ClientHello in the typical case,
> this isn't usually a problem. The issue that is most often seen is that t=
he
> ServerHello comes from B instead of A and is ignored.
>
>
> These are all in cases when the controlling endpoint is using aggressive
> nomination, though, right?  Do you have any data for regular nomination,
> i.e. media received before any USE-CANDIDATE attribute?
>

Not at this time.

--001a1133901cd569d104ff71710f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox =
<jonathan@vidyo.=
com> wrote:














On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote:













On Wed, Jul 30, 2014 at 2:14 PM,=
 Jonathan Lennox 
<jonathan@vidyo.=
com> wrote:






Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination=
, but allow media to be sent on any valid pair prior to selection. =C2=A0(Y=
es, re-reading 5245, I should have said =E2=80=9CValid=E2=80=9D rather than=
 =E2=80=9CConfirmed=E2=80=9D. =C2=A0I mis-remembered the terminology.)












Understood. But controlled side needs some way to know what pair it sh=
ould use to send media, so we need some way to indicate this. Would this be=
 done via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATE=
s as we figure out the ideal path
 to use, which doesn't fit exactly with regular nomination as defined i=
n 5245, but otherwise seems exactly like what I am proposing. Basically, co=
ntrolled side uses the pair that it most recently received USE-CANDIDATE on=
 as its selected pair.

















Oh, that=E2=80=99s true, it has to pick something.







In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t =
matter=C2=A0what it picks =E2=80=94 it could choose any valid pair, jus=
t like the controlling agent does, since it knows that=E2=80=99s a working =
round-trip path.







For both sides, if you receive media on any candidate (from an IP and =
port from which you=E2=80=99ve received a valid connectivity check), accept=
 it. =C2=A0USE-CANDIDATE is then just an optimization that lets you close d=
own the unselected candidates.









I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently receiv=
ed USE-CANDIDATE=E2=80=9D to determine the selected pair. =C2=A0Checks will=
 race each other, especially when the paths=E2=80=99 RTTs are very differen=
t.







In my model, there is only ever one USE-CANDIDATE sent per component =
=E2=80=94 i.e., it works like pure regular nomination, except for the =E2=
=80=9Cearly media=E2=80=9D.

OK, I get it now. I think the main issues you face are:



1) Inability to selectively free candidates - all candidates except th=
e selected pair can be freed by the controlled side after USE-CANDIDATE.
2) No guarantee of symmetric RTP - remote side can use a different =
pair than local side - and you can't resolve this without USE-CANDIDATE=
 (see #1).



3) Potential issues when media arrives on non-nominated pair.

Given #3, I think I'd prefer to find a solution that a=
lso addresses #1/#2.






























5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair. =C2=A0I don=E2=80=99=
t know if this means, in practice, that ICE-bis could change to the behavio=
r I=E2=80=99ve described above and still be backward
 compatible, or if there=E2=80=99d need to be some sort of ice-option negot=
iation to indicate that this early media (oh, dread phrase) is acceptable.<=
br>








Yes, I think we need a new ICE option, or else old ICE impls in the co=
ntrolled role will be surprised when they think the selected pair is A but =
media arrives on B. We've already seen a number of implementations have=
 issues with this.=C2=A0
















Do they have issues receiving media if there is no selected pair yet? =
=C2=A0This would be nonconformant with 5245, but nevertheless wouldn=E2=80=
=99t surprise me.











Since the controlled side sends the ClientHello in the typical case, t=
his isn't usually a problem. The issue that is most often seen is that =
the ServerHello comes from B instead of A and is ignored.














These are all in cases when the controlling endpoint is using aggressi=
ve nomination, though, right? =C2=A0Do you have any data for regular nomina=
tion, i.e. media received before any USE-CANDIDATE attribute?




Not at this time.=C2=A0



--001a1133901cd569d104ff71710f--


From nobody Wed Jul 30 16:25:32 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D831A03F1 for ; Wed, 30 Jul 2014 16:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA11LAtb5aJy for ; Wed, 30 Jul 2014 16:25:29 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FC21A03C5 for ; Wed, 30 Jul 2014 16:25:29 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so3029171vcb.7 for ; Wed, 30 Jul 2014 16:25:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z7r1fJdceZp6E/sjCDeoGa8oYarNJpaLQ66WYQfuZvo=; b=ZITY8VRk3Q9iPoKeATIuGkTf/e8c+IlYnNzsov2nyyRvOv/djyZ12LXzRXKNP6BU8q pg/44ZM1Okk0DR5jHJZH/OXHwYEbYHgr2cfFyhbKYZnkNar/Rc2zhKtHYKMIOCLdgsaw /sXlTiaHVfHwjt0AkaiM//KiQdz2V5cigETFJSIoeGNvLS2tmCLRZczzdMrjg21J7CXh w6DIjdJOqTdPOnyTpujGy9fcyT6xWwxPeAG1n7KK6hh6RwB/rXhh3uG8pri1wxaq07CE OUd/DvvQelGEdyHenp3rhHzfMHkk06BEMVE1Moge7GZdopUZQVfFYkCJxaFQJjW8IHm+ KpZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Z7r1fJdceZp6E/sjCDeoGa8oYarNJpaLQ66WYQfuZvo=; b=QxgAcehAGUE25jCWuIXT3cJZVuqex2k2AqKC93eLlnNCJslLUzRvoQ9sJX0BLTTdgF Qi9iQxdBJnVChG4oSqgIkWmIRRvQaO84oWngdLLLMSC7g9QBabznk695qAYuIi/6nbOE gCy5y7hvzxJZnWzcVok8nvOARGKFm/xXS0XO8L2KrTzS6/exWYamkIZpaOeXlD7pLLlD RO0xov1WdmCV39Xa8ZqfNmmOv3ANgsnjpIEJsAgeIOMYZgdjf5WvhkX6ptRs65jMd0Ti +x5c+PK9idYWI0LPQGTg7CuBXwSCPQXfWJZ8AkTzRFIK3w764azZ7IKVIIJtsNWna+cT lN8w==
X-Gm-Message-State: ALoCoQmh1UzDu693/c/Mi2XHcrfUelgb6ANZ3L3tOaEz4I8hly2Gw+KPA8+F0kkW8nWdDejBTeYo
X-Received: by 10.52.61.99 with SMTP id o3mr11478742vdr.46.1406762728349; Wed, 30 Jul 2014 16:25:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 16:25:08 -0700 (PDT)
In-Reply-To: <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
From: Justin Uberti 
Date: Wed, 30 Jul 2014 16:25:08 -0700
Message-ID: 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=001a113403d0b4fdfc04ff717833
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XVqzV4N-J576whBWj1Dx-AmkdwE
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 23:25:31 -0000

--001a113403d0b4fdfc04ff717833
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox  wrote=
:

>
>  On Jul 30, 2014, at 5:59 PM, Justin Uberti  wrote:
>
>   On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox 
> wrote:
>
>>  Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination,=
 but allow media
>> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245,=
 I
>> should have said =E2=80=9CValid=E2=80=9D rather than =E2=80=9CConfirmed=
=E2=80=9D.  I mis-remembered the
>> terminology.)
>>
>
>  Understood. But controlled side needs some way to know what pair it
> should use to send media, so we need some way to indicate this. Would thi=
s
> be done via USE-CANDIDATE? If so, we could end up with multiple
> USE-CANDIDATEs as we figure out the ideal path to use, which doesn't fit
> exactly with regular nomination as defined in 5245, but otherwise seems
> exactly like what I am proposing. Basically, controlled side uses the pai=
r
> that it most recently received USE-CANDIDATE on as its selected pair.
>
>
>  Oh, that=E2=80=99s true, it has to pick something.
>
>  In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t *matt=
er* what it
> picks =E2=80=94 it could choose any valid pair, just like the controlling=
 agent
> does, since it knows that=E2=80=99s a working round-trip path.
>
>  For both sides, if you receive media on any candidate (from an IP and
> port from which you=E2=80=99ve received a valid connectivity check), acce=
pt it.
>  USE-CANDIDATE is then just an optimization that lets you close down the
> unselected candidates.
>
>  I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently received=
 USE-CANDIDATE=E2=80=9D
> to determine the selected pair.  Checks will race each other, especially
> when the paths=E2=80=99 RTTs are very different.
>

Agree, although this would be addressed by any of:
- receipt of secure media is considered an indication of the selected pair
- retransmit USE-CANDIDATE periodically on selected pair (need to do this
for consent anyway)
- REALLY-USE-CANDIDATE attribute


>  In my model, there is only ever one USE-CANDIDATE sent per component =E2=
=80=94
> i.e., it works like pure regular nomination, except for the =E2=80=9Cearl=
y media=E2=80=9D.
>
>       5245 says that an ICE endpoint MUST be prepared to receive media on
>>> any candidate, but only sends on the Selected candidate pair.  I don=E2=
=80=99t know
>>> if this means, in practice, that ICE-bis could change to the behavior I=
=E2=80=99ve
>>> described above and still be backward compatible, or if there=E2=80=99d=
 need to be
>>> some sort of ice-option negotiation to indicate that this early media (=
oh,
>>> dread phrase) is acceptable.
>>>
>>
>>  Yes, I think we need a new ICE option, or else old ICE impls in the
>> controlled role will be surprised when they think the selected pair is A
>> but media arrives on B. We've already seen a number of implementations h=
ave
>> issues with this.
>>
>>
>>  Do they have issues receiving media if there is no selected pair yet?
>>  This would be nonconformant with 5245, but nevertheless wouldn=E2=80=99=
t surprise
>> me.
>>
>
>  Since the controlled side sends the ClientHello in the typical case,
> this isn't usually a problem. The issue that is most often seen is that t=
he
> ServerHello comes from B instead of A and is ignored.
>
>
> These are all in cases when the controlling endpoint is using aggressive
> nomination, though, right?  Do you have any data for regular nomination,
> i.e. media received before any USE-CANDIDATE attribute?
>

--001a113403d0b4fdfc04ff717833
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox =
<jonathan@vidyo.=
com> wrote:














On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote:













On Wed, Jul 30, 2014 at 2:14 PM,=
 Jonathan Lennox 
<jonathan@vidyo.=
com> wrote:






Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination=
, but allow media to be sent on any valid pair prior to selection. =C2=A0(Y=
es, re-reading 5245, I should have said =E2=80=9CValid=E2=80=9D rather than=
 =E2=80=9CConfirmed=E2=80=9D. =C2=A0I mis-remembered the terminology.)












Understood. But controlled side needs some way to know what pair it sh=
ould use to send media, so we need some way to indicate this. Would this be=
 done via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATE=
s as we figure out the ideal path
 to use, which doesn't fit exactly with regular nomination as defined i=
n 5245, but otherwise seems exactly like what I am proposing. Basically, co=
ntrolled side uses the pair that it most recently received USE-CANDIDATE on=
 as its selected pair.

















Oh, that=E2=80=99s true, it has to pick something.







In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t =
matter=C2=A0what it picks =E2=80=94 it could choose any valid pair, jus=
t like the controlling agent does, since it knows that=E2=80=99s a working =
round-trip path.







For both sides, if you receive media on any candidate (from an IP and =
port from which you=E2=80=99ve received a valid connectivity check), accept=
 it. =C2=A0USE-CANDIDATE is then just an optimization that lets you close d=
own the unselected candidates.









I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently receiv=
ed USE-CANDIDATE=E2=80=9D to determine the selected pair. =C2=A0Checks will=
 race each other, especially when the paths=E2=80=99 RTTs are very differen=
t.




Agree, although this would be addressed by any of:
- receipt of secure media is considered an indication of the selected=
 pair=C2=A0
- retransmit USE-CANDIDATE periodically on selected p=
air (need to do this for consent anyway)



- REALLY-USE-CANDIDATE attribute








In my model, there is only ever one USE-CANDIDATE sent per component =
=E2=80=94 i.e., it works like pure regular nomination, except for the =E2=
=80=9Cearly media=E2=80=9D.



























5245 says that an ICE endpoint MUST be prepared to receive media on any can=
didate, but only sends on the Selected candidate pair. =C2=A0I don=E2=80=99=
t know if this means, in practice, that ICE-bis could change to the behavio=
r I=E2=80=99ve described above and still be backward
 compatible, or if there=E2=80=99d need to be some sort of ice-option negot=
iation to indicate that this early media (oh, dread phrase) is acceptable.<=
br>








Yes, I think we need a new ICE option, or else old ICE impls in the co=
ntrolled role will be surprised when they think the selected pair is A but =
media arrives on B. We've already seen a number of implementations have=
 issues with this.=C2=A0
















Do they have issues receiving media if there is no selected pair yet? =
=C2=A0This would be nonconformant with 5245, but nevertheless wouldn=E2=80=
=99t surprise me.











Since the controlled side sends the ClientHello in the typical case, t=
his isn't usually a problem. The issue that is most often seen is that =
the ServerHello comes from B instead of A and is ignored.














These are all in cases when the controlling endpoint is using aggressi=
ve nomination, though, right? =C2=A0Do you have any data for regular nomina=
tion, i.e. media received before any USE-CANDIDATE attribute?








--001a113403d0b4fdfc04ff717833--


From nobody Wed Jul 30 16:28:32 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0D51A03E9 for ; Wed, 30 Jul 2014 16:28:30 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJuJcAl1pqU4 for ; Wed, 30 Jul 2014 16:28:29 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7501A02DA for ; Wed, 30 Jul 2014 16:28:28 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so1935433wes.14 for ; Wed, 30 Jul 2014 16:28:27 -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=KDgdXcMiGC8Psxlai7VRJew/iWBqTJwzvoHzev73MOw=; b=XLcHs1j2Gi5+enqZ/IUUs/RU36jVzjC30ovvBt+2SrTeb5qWlaWEmIlOA21O+hzShC 9+9DBgzg53c6vfOAeeD0KnDiF5PFRmodiHmbiugTa3WZ/kPWy2+VVGzQjBOqMPHBvw6v dFHDzOaSHzEow25AralWCof3f23t/plTU3B7I2WBjcYrNhIf/Edh/hO1YbcC+jy8ATaj xkNt5b/Dk38edcbcbI5V+3CEaLwVSI0X2JhSu2qPVe/dJLzM+zI7gNSj+1IcGWXyuK+M cVXXCKo+3NIuef0t81B4O3LkDHEVr3M3CSjECP6QyHIvElaIbTA6njNS+BGO+ngwUMaV Rcug==
MIME-Version: 1.0
X-Received: by 10.180.211.237 with SMTP id nf13mr11370116wic.47.1406762907169;  Wed, 30 Jul 2014 16:28:27 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 16:28:27 -0700 (PDT)
In-Reply-To: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>  
Date: Wed, 30 Jul 2014 16:28:27 -0700
Message-ID: 
From: Martin Thomson 
To: Jonathan Lennox 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/W3f53cmfhF4oGKwcmrtqD9v5r4I
Cc: mmusic 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 23:28:30 -0000

On 30 July 2014 16:05, Jonathan Lennox  wrote:
> Actually, if the answerer (controlled endpoint) can send on any Valid pai=
r, as in my suggestion, I don=E2=80=99t think you need the ICE role reversa=
l for this optimization.  It can send ClientHello as soon as its first chec=
k succeeds, despite never having received any remote checks (with or withou=
t USE-CANDIDATE).

You win.  I think that you just made ICE faster with no mechanism.
That's better than faster ICE with some mechanism.


From nobody Wed Jul 30 16:42:32 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CB91A0451 for ; Wed, 30 Jul 2014 16:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG0OxfxyE-6S for ; Wed, 30 Jul 2014 16:42:29 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFE11A03C4 for ; Wed, 30 Jul 2014 16:42:28 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hy4so3042735vcb.41 for ; Wed, 30 Jul 2014 16:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iLU0LsfgtC3EEpIXG5zboHtkwlcZjBAtgekPwAUypds=; b=TqBGWE/Q9PDAdnqurKiW374we66bazm+ZHbNpIRoYS3W6ARHCypkGwd3GsoVHKgmAU J5TROhG2ltA5k+8w4tTL1Jlr/tZo0bLUxHV8HvgzryQ91Lwl5gcdZfr0WXdBuj9acho/ 7XSkn4fpMuI0V42+dvgrzoQN9plUyuu3TvMh8snzajuxlDcWM1DrXrBQBFzypDlamLiK mM791XX/s/W97YUgyNrn8u30eOgv9WP2PmmMZYpSs9dcAFJbPLze+EuyOawLEBNjIMaM GA94IeJr8OAcMHBQLpz073v2j9c6mBfR3/ZuCbg0Jtp2q2hTWfjB6VNzHytbHyIx0Uys 8SdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iLU0LsfgtC3EEpIXG5zboHtkwlcZjBAtgekPwAUypds=; b=N7OFcG8ZL72qgRPE0CvmWc1K50Muoh5Vvflyxd1ta+fIyPEPF4aFLh0zzXrn35Yztt j5GhbgRz5VvJi3UTks5t7ThQSyhcuEEjmXpRTdXj/1J4UQOS2yI51kC8q06hjeNavS/b tXg6QcuB1AZTf10v+uieqCAuwdLdNiSXsiKRxILQVHyf0WYceImoofNfBpzF9I6v7vKO OpQLlA0psHemVDc+UOcM/fNFSuh7jLoO9Pqhvy/3MDf+6xZOtpdC+gxkzXjMiTNBIa8/ yF7MGs9X7Vl8B7Um0urnJfPNsy9zwPWFpqCBItX+WZImvRwomEL2sZKXZhuIlciiHQis yhGA==
X-Gm-Message-State: ALoCoQmVQpl1JG8oI0zM1uuw6JCC0p6CNi+DB3tgh+E3FvHs3m7IDpwuiJe1iujXqN4lnyUdK3DE
X-Received: by 10.220.96.137 with SMTP id h9mr1008518vcn.46.1406763748029; Wed, 30 Jul 2014 16:42:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 16:42:07 -0700 (PDT)
In-Reply-To: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>  
From: Justin Uberti 
Date: Wed, 30 Jul 2014 16:42:07 -0700
Message-ID: 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=001a11c2dbe67c136004ff71b5cc
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/O6uy_hnT2ZEQUIqSGnkQ1ye_xIc
Cc: mmusic 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 23:42:30 -0000

--001a11c2dbe67c136004ff71b5cc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox  wrote=
:

>
> On Jul 30, 2014, at 7:00 PM, Martin Thomson 
> wrote:
>
> > On 30 July 2014 15:56, Jonathan Lennox  wrote:
> >> The offerer can=E2=80=99t send its own connectivity checks until it re=
ceives an
> answer, because it needs the remote ufrag and password.  Without this, it
> doesn=E2=80=99t have any valid pairs, and so can=E2=80=99t send any media=
.
> >
> > Of course.  But you could do all the computation necessary for
> > generating the ServerHello and accompanying messages (which in TLS 1.3
> > is quite a bit).
> >
> >> This suggestion might still save half an RTT, though? I=E2=80=99d need=
 to work
> through a full ladder diagram to figure it out.
> >
> > That's the idea.  I haven't plotted it all out either, but I think
> > that this is the fastest possible start assuming that you don't send
> > any DTLS messages prior to getting a successful connectivity check
> > response.
>
> Actually, if the answerer (controlled endpoint) can send on any Valid
> pair, as in my suggestion, I don=E2=80=99t think you need the ICE role re=
versal for
> this optimization.  It can send ClientHello as soon as its first check
> succeeds, despite never having received any remote checks (with or withou=
t
> USE-CANDIDATE).
>
> This makes a lot of sense and we should do it. Implementations not
expecting media before choosing a selected pair (on the controlling side
this time) may eat the packet, but it won't be fatal.

--001a11c2dbe67c136004ff71b5cc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox =
<jonathan@vidyo.=
com> wrote:






On Jul 30, 2014, at 7:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<=
br>


> On 30 July 2014 15:56, Jonathan Lennox <jonathan@vidyo.com> wrote:

>> The offerer can=E2=80=99t send its own connectivity checks until i=
t receives an answer, because it needs the remote ufrag and password. =C2=
=A0Without this, it doesn=E2=80=99t have any valid pairs, and so can=E2=80=
=99t send any media.

>

> Of course. =C2=A0But you could do all the computation necessary for
> generating the ServerHello and accompanying messages (which in TLS 1.3=


> is quite a bit).

>

>> This suggestion might still save half an RTT, though? I=E2=80=99d =
need to work through a full ladder diagram to figure it out.

>

> That's the idea. =C2=A0I haven't plotted it all out either, bu=
t I think

> that this is the fastest possible start assuming that you don't se=
nd

> any DTLS messages prior to getting a successful connectivity check

> response.




Actually, if the answerer (controlled endpoint) can send on any Valid=
 pair, as in my suggestion, I don=E2=80=99t think you need the ICE role rev=
ersal for this optimization. =C2=A0It can send ClientHello as soon as its f=
irst check succeeds, despite never having received any remote checks (with =
or without USE-CANDIDATE).






This makes a lot of sense and w=
e should do it. Implementations not expecting media before choosing a selec=
ted pair (on the controlling side this time) may eat the packet, but it won=
't be fatal.






--001a11c2dbe67c136004ff71b5cc--


From nobody Wed Jul 30 19:00:55 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2121A0338 for ; Wed, 30 Jul 2014 19:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov8lVJb2krjU for ; Wed, 30 Jul 2014 19:00:44 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF471A01D9 for ; Wed, 30 Jul 2014 19:00:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1406772044; x=1407981644; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BJbWL6IXsbPnlfkGNx/qPuRKoMcnlzgcIMAnlw87RoM=; b=IFkgsoZh8ehoPxBbLx+c86cP+QOAdHW2YHo4/DmHKavqPIv0/8yeg+tu qwCqXTi+G9VOkylSKspxKATbQF1/YtMxKMbD7ilyA+72MYCCNe2vXFGhC yZbiBuEXnEOx47eLg9COGNxzX1JMsw7kcOxhk9S58GIanE1rKqVsSHtkI g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFALSi2VOtJV2b/2dsb2JhbABZgw5SV8sVh0sBgQoWd4QDAQEBAQIBeRALGBgWITYGE4guAwkIDbcWDYcOF40fgXozBxiDF4EbBYp/jmCCBYFSjFyGJYNpHS8
X-IronPort-AV: E=Sophos;i="5.01,768,1400025600"; d="scan'208";a="65358989"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 31 Jul 2014 02:00:43 +0000
Received: from rtp-vpn5-1695.cisco.com (rtp-vpn5-1695.cisco.com [10.82.238.165]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6V20ewe001444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 02:00:42 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dan Wing 
In-Reply-To: 
Date: Wed, 30 Jul 2014 19:00:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>  
To: Jonathan Lennox 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GWIuyR5VaO4VbCjx6CxvsUxy-9c
Cc: mmusic 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 02:00:50 -0000

On Jul 30, 2014, at 4:05 PM, Jonathan Lennox  wrote:

>=20
> On Jul 30, 2014, at 7:00 PM, Martin Thomson  =
wrote:
>=20
>> On 30 July 2014 15:56, Jonathan Lennox  wrote:
>>> The offerer can=92t send its own connectivity checks until it =
receives an answer, because it needs the remote ufrag and password.  =
Without this, it doesn=92t have any valid pairs, and so can=92t send any =
media.
>>=20
>> Of course.  But you could do all the computation necessary for
>> generating the ServerHello and accompanying messages (which in TLS =
1.3
>> is quite a bit).
>>=20
>>> This suggestion might still save half an RTT, though? I=92d need to =
work through a full ladder diagram to figure it out.
>>=20
>> That's the idea.  I haven't plotted it all out either, but I think
>> that this is the fastest possible start assuming that you don't send
>> any DTLS messages prior to getting a successful connectivity check
>> response.
>=20
> Actually, if the answerer (controlled endpoint) can send on any Valid =
pair, as in my suggestion, I don=92t think you need the ICE role =
reversal for this optimization.  It can send ClientHello as soon as its =
first check succeeds, despite never having received any remote checks =
(with or without USE-CANDIDATE).

Yep, ICE allows sending media once the pair becomes Valid  (middle of =
page 69, http://tools.ietf.org/html/rfc5245#page-69).  It is very =
reasonable that ClientHello is permitted to be sent to a Valid pair, =
too.

Towards the desire to remove a round trip, has there been consideration =
to folding the STUN messaging into the ClientHello?

-d


From nobody Wed Jul 30 20:03:57 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE9D1A04F1 for ; Wed, 30 Jul 2014 20:03:54 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FytyiM-uPfVk for ; Wed, 30 Jul 2014 20:03:50 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3511A03DB for ; Wed, 30 Jul 2014 20:03:49 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q58so2111133wes.21 for ; Wed, 30 Jul 2014 20:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JlZlGf7KZWKA7/xuJPma7Ry9wrAlUTJR7i6UtHElJiQ=; b=ZHWwbfyLwcY94MQYzUHI8dpKHYylnVLRowcowrCL+Qum4QQ3WUZKkBAw9tE2DyW9pK LiuN5YA2J60aHXkHWRuGQsgZAvGKN54iWgg1wn1upDK9j1kLlVIRWvb+aiu+WBO/HWT4 qanT0lREAEbODTsRfxcTNiu4Kf7js8QipGD3Mwg71LMTcGGfQwwFF8ASvZ4ovZgh+Koq lA4YYlbaskLPmusT1yaMpJggbwtn7ADpZa+vfFLFWW+9EWJjF9Y6YJiq+shSt8Zfw+Al k5odd0WCOsoahUTnZV8naJE4wMDPsIGIMStOwlm7FntshhvVKipsOaEfSlkdZPeaKgnr OgUw==
MIME-Version: 1.0
X-Received: by 10.180.73.6 with SMTP id h6mr11431991wiv.65.1406775828319; Wed, 30 Jul 2014 20:03:48 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 20:03:48 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 20:03:48 -0700 (PDT)
In-Reply-To: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>   
Date: Wed, 30 Jul 2014 20:03:48 -0700
Message-ID: 
From: Martin Thomson 
To: Dan Wing 
Content-Type: multipart/alternative; boundary=f46d043c7f0486941004ff748547
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6vMZQQwNjULzJwd6ktN7WJXKdpM
Cc: Jonathan Lennox , mmusic@ietf.org
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 03:03:56 -0000

--f46d043c7f0486941004ff748547
Content-Type: text/plain; charset=UTF-8

On Jul 30, 2014 7:00 PM, "Dan Wing"  wrote:
> Towards the desire to remove a round trip, has there been consideration
to folding the STUN messaging into the ClientHello?

Like http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00 ?

Yeah. It doesn't actually reduce round trips here because you still want to
confirm consent before doing the whole proof-of-possession thing. If you
don't care about the associated DoS vector (and we might not need to worry
about that if you can validate the ClientHello properly), a 1 round trip
handshake would be very fast.

--f46d043c7f0486941004ff748547
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Jul 30, 2014 7:00 PM, "Dan Wing" <dwing@cisco.com> wrote:

> Towards the desire to remove a round trip, has there been consideratio=
n to folding the STUN messaging into the ClientHello?


Like http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-0=
0 ?


Yeah. It doesn't actually reduce round trips here becaus=
e you still want to confirm consent before doing the whole proof-of-possess=
ion thing. If you don't care about the associated DoS vector (and we mi=
ght not need to worry about that if you can validate the ClientHello proper=
ly), a 1 round trip handshake would be very fast.



--f46d043c7f0486941004ff748547--


From nobody Thu Jul 31 00:01:51 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDB81A0377 for ; Thu, 31 Jul 2014 00:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GKKvsB1ppwF for ; Thu, 31 Jul 2014 00:01:48 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D971A036F for ; Thu, 31 Jul 2014 00:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4689; q=dns/txt; s=iport; t=1406790108; x=1407999708; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=EIAgP3cVOVuXe/dbBFRLOp89oarZ0y9PmU365zxRFzk=; b=b+pBWic7Yw7GongUa/tZsP260IlhyoPDAJqcZEa8QVl+X7BbhlExegz8 XGNUaHPLLvImXRwoNf9AUF6NvZ8IiSkF75RUHdn+MDIzh04YEu5c9tBbn 7pYZ/l1ih7Smyu22dpXAQmsdmr7pUf0YwK5gNgF3VTA5wIvIQ/PxEY1yu A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQFABTp2VOtJV2Q/2dsb2JhbABZgw5SV8kogWKHSwGBBRZ3hAMBAQEBAgF5BQsLBBQuITYGE4guAwkIDbURDYcOF40fgi0Hgy+BGwWBWIknjmCCBYFSjFyGJYNpHS8BAYEDJA
X-IronPort-AV: E=Sophos;i="5.01,770,1400025600";  d="scan'208,217";a="344070661"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2014 07:01:47 +0000
Received: from rtp-vpn5-597.cisco.com (rtp-vpn5-597.cisco.com [10.82.234.87]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6V71gZW014519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 07:01:45 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B3F7D58-DB24-43B6-9621-3843241993F4"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dan Wing 
In-Reply-To: 
Date: Thu, 31 Jul 2014 00:01:49 -0700
Message-Id: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>    
To: Martin Thomson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Y4z5iOIXaRb6m8SuQiN7dS0hXO0
Cc: Jonathan Lennox , mmusic@ietf.org
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 07:01:50 -0000

--Apple-Mail=_9B3F7D58-DB24-43B6-9621-3843241993F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 30, 2014, at 8:03 PM, Martin Thomson  =
wrote:

> On Jul 30, 2014 7:00 PM, "Dan Wing"  wrote:
> > Towards the desire to remove a round trip, has there been =
consideration to folding the STUN messaging into the ClientHello?
>=20
> Like http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00 ?
>=20
Sortof.  What I had in mind was sending ClientHello with a new TLS =
extension, let's call the extension STUN Binding Request and let's say =
it contains exactly the same bits as the UDP payload of an actual STUN =
Binding Request.  When the server receives that UDP packet (containing =
both a DTLS ClientHello and embedded STUN Binding Request payload), it =
can do its normal STUN processing against that packet.  When it decides =
to send its STUN Binding Response, it does the processing necessary to =
generate its DTLS ServerHello.  It puts them together into the DTLS =
ServerHello response and replies to the ServerHello.  After that, over =
that 5-tuple, normal ICE processing can occur (such as for the periodic =
consent checks).

> Yeah. It doesn't actually reduce round trips here because you still =
want to confirm consent before doing the whole proof-of-possession =
thing.
>=20
We should be able to optimize the case where we are not being attacked.  =
When attacked, we can incur an additional round trip.
> If you don't care about the associated DoS vector (and we might not =
need to worry about that if you can validate the ClientHello properly), =
a 1 round trip handshake would be very fast.
>=20
The HelloVerifyRequest mitigation described in DTLS =
(http://tools.ietf.org/html/rfc4347#section-4.2.1) seems adequate.

-d


--Apple-Mail=_9B3F7D58-DB24-43B6-9621-3843241993F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Jul =
30, 2014, at 8:03 PM, Martin Thomson <martin.thomson@gmail.com> =
wrote:

On Jul 30, 2014 7:00 PM, "Dan Wing" =
<dwing@cisco.com> =
wrote:

> Towards the desire to remove a round trip, has there been =
consideration to folding the STUN messaging into the ClientHello?
Like http:=
//tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00 =
?
Sortof.  What I had in mind was sending =
ClientHello with a new TLS extension, let's call the extension STUN =
Binding Request and let's say it contains exactly the same bits as the =
UDP payload of an actual STUN Binding Request.  When the server =
receives that UDP packet (containing both a DTLS ClientHello and =
embedded STUN Binding Request payload), it can do its normal STUN =
processing against that packet.  When it decides to send its STUN =
Binding Response, it does the processing necessary to generate its DTLS =
ServerHello.  It puts them together into the DTLS ServerHello =
response and replies to the ServerHello.  After that, over that =
5-tuple, normal ICE processing can occur (such as for the periodic =
consent checks).

Yeah. It doesn't actually reduce round trips here because =
you still want to confirm consent before doing the whole =
proof-of-possession thing. 
We should be able to =
optimize the case where we are not being attacked.  When attacked, =
we can incur an additional round trip.
If you don't care about the associated DoS vector (and we =
might not need to worry about that if you can validate the ClientHello =
properly), a 1 round trip handshake would be very fast.



The HelloVerifyRequest mitigation described in DTLS (http://tools.iet=
f.org/html/rfc4347#section-4.2.1) seems =
adequate.

-d

=

--Apple-Mail=_9B3F7D58-DB24-43B6-9621-3843241993F4--


From nobody Thu Jul 31 03:37:55 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45CE1A0AB0 for ; Thu, 31 Jul 2014 03:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_EVqcPjX2M5 for ; Thu, 31 Jul 2014 03:37:42 -0700 (PDT)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2636D1A01C6 for ; Thu, 31 Jul 2014 03:37:40 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id m5so2300645qaj.35 for ; Thu, 31 Jul 2014 03:37:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=gclsZev2fmBzWhYi7duQyIO0pDKfCAncLaC01dmdzUY=; b=SqBL9IuBQMf3G6om8F25YcYfDBw+UdpcfpcCzILyNsP3JVva6gzcSjYHWfi/mImNN1 FvpAVhORxkYrnnN7uGQ5dLBsZdGSlCA7lLtX9dkLG0StMjf0zjv5Bo67eRVOcqgdjvHp 16FIU8Wt23u25U28BKUct1qibKsVVRPbJFhsfIlkBfNUrRW+epKmbTHe8HSM51ZP13K8 ha2vFfWIWDiVTmgGcr/A3maS1iCcCE0FgjYxmjqFd0ELsEy2sELU/C4MnkqxhLmWCtMH fw0W62yMpez2xuSzLWGetmdrrRQUU4sr4wuszT9lPrCuAbeSRAdZe3imZtYdS8FOBhcz GtMw==
X-Gm-Message-State: ALoCoQnBX6HTj3Hr1K6VFTIrwAi+lgv6jl2KJ7h8uW4tHptNv7cLFPcF0Hi/MbCqEbA52nheNx++
X-Received: by 10.140.30.73 with SMTP id c67mr15499359qgc.16.1406803059284; Thu, 31 Jul 2014 03:37:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 03:37:19 -0700 (PDT)
In-Reply-To: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>    
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 12:37:19 +0200
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0O1te-cjUcwbD_a0QbOtxnwPtjY
Cc: Jonathan Lennox , "mmusic@ietf.org" , Dan Wing 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 10:37:44 -0000

2014-07-31 5:03 GMT+02:00 Martin Thomson :
> Like http://tools.ietf.org/html/draft-thomson-rtcweb-ice-dtls-00 ?

The draft says:

-----------------------
   This requires additional state retention - especially at the (DTLS)
   server - when multiple connectivity checks are sent and received.
   This information does not add significantly to the state burden
   imposed by ICE.  Assuming that the client does not alter the
   configuration for each session, the Random and Cookie fields will
   vary in every ClientHello.
-----------------------

I will just talk about ICE-Lite servers in case they implement that spec:

- With "normal" ICE the Lite server manages ICE requests and once one
with USE-CANDIDATE arrives it is done.
- After that the ICE Lite server should just accept DTLS packets
coming from that source IP:port, and discard everything else.
- This means that just a single DTLS context must be set.


In the case of DTLS-ICE (draft above), the server should:

- Create a DTLS context for each different source address from which
it receives DTLS packets, which means keeping a map/list of source
addresses and associated DTLS contexts for each one.

Nothing too hard, but it is worth mentioning it.

--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 03:51:14 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E31A01A5 for ; Thu, 31 Jul 2014 03:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_nIxqjXHQvX for ; Thu, 31 Jul 2014 03:51:12 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232151A004E for ; Thu, 31 Jul 2014 03:51:12 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id k15so2282539qaq.24 for ; Thu, 31 Jul 2014 03:51:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=D1PeiRiF4MxUSQNFtDnH3Jn2XLGN9J/9MJfFxqSxaGA=; b=K8PvmuB8o+JRiLMl028Cm4ITOjEy9cUEXxfztpB2+IyNSLFk+mtpH3fjGMh9mxydpv +SfCaqLMu3VRnahzus2Uhyk2wtigM5Z37WMqSOMH5MaoGSe0ZuV+fpc/sJjpOXU2UT+h 1zHX5ATC0gT2YCUfj+V7CFMC2iaHIZ9J6Lo6vZB0XdWhwYSpy5DI4a1Qi6RVCmIb2o1d V/KySOu8OY/+DNYXkQ6G6I+iJEX1qFQRsfuGNuSa6hJLFRwappikperH8gCP2lEWgyvT WtHxSlOELEqMM21V8A4f+T7vsuFCQU7i81YHmvzd9sn9wbHNEmwKkqLTAUoLpBmV8IjJ DhpA==
X-Gm-Message-State: ALoCoQmjnv3Tl+ux3i8UyttEPdgDp31a4JQoDscb4n5pKT7QUBOg6o9fAemVyNxgJBHrn2PI5MNT
X-Received: by 10.224.128.9 with SMTP id i9mr17331493qas.50.1406803871239; Thu, 31 Jul 2014 03:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 03:50:51 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>   
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 12:50:51 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YVAXrgfkDrXZx-Z8Z83kmRi-SMI
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 10:51:13 -0000

2014-07-30 23:48 GMT+02:00 Emil Ivov :
> The main problem with the aggressive version of regular nomination is stu=
ff
> like DTLS/SRTP (that's actually already kind of an issue with today's
> aggressive nomination).
>
> When it's RTP you don't care where you get it from as long as you do. If
> it's a DTLS client halo then what do you do exactly?
>
> Can the controlling agent simply respond on a different valid pair than t=
he
> one on which it received it? (This is what Chrome currently does but its
> frowned upon by the DTLS/SRTP draft which binds the context to a specific
> address:port). Does the controlled agent need to resend it on the new pai=
r
> after it gets the USE-CANDIDATE?
>
> What about other protocols? Do they all need to say how they are to be us=
ed
> with ICE? I hope not and I hope we can find a generic approach for all of
> them. For example: all early non-acknowledged reliable data has to be res=
ent
> on the nominated pair. This would imply a DTLS neg restart as Martin
> suggested.


+1

IMHO we need a way for ICE (all the flavors) to fully determine which
is the *only* pair in which media or DTLS can be sent, so a peer can
safely discard any RTP or DTLS packet coming from a source address
that does not match the selected/paired/confirmed address tuple.

And IMHO we also need that a ICE-Lite server implementation does not
need to keep a list of valid pairs or source addresses but just one
(chosen via ICE by the controlling peer).

--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 03:58:27 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0F1A038E for ; Thu, 31 Jul 2014 03:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWAPe_rdIhyT for ; Thu, 31 Jul 2014 03:58:23 -0700 (PDT)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07EE1A0354 for ; Thu, 31 Jul 2014 03:58:22 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id a108so3474600qge.24 for ; Thu, 31 Jul 2014 03:58:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=rgjXHyffNNRRByzYNGkYLY1UKjrqA0O/B8hWOB4dNSQ=; b=hrxlVn/SNtf+xsF67rMp2wXt8cawhNfSXvR/8omsHd4JmIz/7zyrC/I70Mx65qayC0 tyNxuknrnfOvRpoxoj9fV7ceqypvsQER96pNN2A+eqgcCv55UPoUpwCwPPZ7ipFYBmlk ZcwgBOtN+gHtp7JsQIoDa7ZtuOM33w1OHE9331MkQdkGxnuPtc2mt07+tlmEnpVozfZq qR9xkVEeq2g6IItJWo5B7e8j60qSZZ39HSbagkZkWOn1pUBxGMw7/nemW29PB2WJlN0l Tc8/r9AtnVEczxkilgPrrkpxY76vqDxu6CzqtlU8axQdpeXEBm3asu1JYq5bjHF7vbAv hFDQ==
X-Gm-Message-State: ALoCoQn5Ws8D9nr4xve67T9usFefgQm2ogn9ns930aGaQsiLXaS8sD+aFpjcbPWBK10p9ITRaGSC
X-Received: by 10.224.53.137 with SMTP id m9mr16996554qag.66.1406804302150; Thu, 31 Jul 2014 03:58:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 03:58:02 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 12:58:02 +0200
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YvKgFzyFcScmcHlOv_7UdSS1srs
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 10:58:24 -0000

2014-07-31 0:06 GMT+02:00 Martin Thomson :
> On 30 July 2014 14:59, Justin Uberti  wrote:
>> Basically, controlled side uses the pair that it most recently received
>> USE-CANDIDATE on as its selected pair.
>
> That's pretty good.  It would potentially allow us to move the active
> pair around in future (i.e., mobility stuff) without massive backward
> compatibility breaks too.  Unilaterally even.

I must be missing something, but if the controlled receives two
USE-CANDIDATE, selects the last one as "selected pair" and reply to
them, then the controlling peer would probably use the first
USE-CANDIDATE as "selected pair" (it arrived before so most probably
its response arrived first to the controlling peer, and if it arrived
before it may be because it is a better option so had higher
PRIORITY).


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 04:03:28 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437331A0354 for ; Thu, 31 Jul 2014 04:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHEEBXhGIp4w for ; Thu, 31 Jul 2014 04:03:22 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844371A0343 for ; Thu, 31 Jul 2014 04:03:21 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id j15so2337457qaq.1 for ; Thu, 31 Jul 2014 04:03:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=aW/SVAo0mD56rzyT3Y+KXzhocpow6HRGsfTmUchSz7Q=; b=ilWV9gtJLlDzE4tkbPikQRJH/GHY5XSacchHGmvYQsol7+KvB2jOeUhMQK4iJHwYjB bonMFSkVfjLt/v0KwxpEnXYbZ54Zd1JGyNcpcqUNYiOUIfFYAahYkwd7X0Q9Tb0//vfk S+KjxKix8nzdhcHxTC1PKUzwByNuSyNxVoOl7Z6yImBJyuPbEYsozwNdO6FpPYITIOS3 gsulA+54P2x3BCy+KeVdL7n1gau9EK3ybraf2wtHJyuLmgoRwBTevm34qMga4z0UEIlC El9ilhzcWFXIvuCbqWTus5dlrkmYzzY9A2f2McPERU+fcxwUqvS0wJ/ixL4mB3vnDhY+ 1gQg==
X-Gm-Message-State: ALoCoQn1h0IAapzDgRpYj2O1J9PzDGeWoYe2u8P+CpBdsvgtR2c4C2oneLJTBk/3FRux2j38uo5/
X-Received: by 10.140.107.4 with SMTP id g4mr15975014qgf.100.1406804600552; Thu, 31 Jul 2014 04:03:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 04:03:00 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 13:03:00 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/r-wxaJ49RQ-V2F_dn04YHuul7Xg
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 11:03:24 -0000

2014-07-31 1:25 GMT+02:00 Justin Uberti :
>> I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently received=
 USE-CANDIDATE=E2=80=9D to
>> determine the selected pair.  Checks will race each other, especially wh=
en
>> the paths=E2=80=99 RTTs are very different.
>
>
> Agree, although this would be addressed by any of:
> - receipt of secure media is considered an indication of the selected pai=
r

Please, consider DTLS rather than secure media. Secure media is easy
to handle regardless where it comes from. DTLS is not as you need a
separate context for each tuple.

If you mean that "the controlled must determine as selected pair that
on which it receives the *first* DTLS ClientHello, being a previously
validated ICE pair (so the source address is already known thanks to a
previous ICE transaction)" then that sounds better for me.




--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 04:18:08 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D861A0343 for ; Thu, 31 Jul 2014 04:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPMJLLQrf4VE for ; Thu, 31 Jul 2014 04:18:05 -0700 (PDT)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676E11A0324 for ; Thu, 31 Jul 2014 04:18:05 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id e89so3440838qgf.31 for ; Thu, 31 Jul 2014 04:18:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+Swazhb6ErIZ1ecmfia/pcHohjfkkuBWnKVXpMIvmvY=; b=RH1UfOOgBZEWw32ne/M9O6IIvbNE+24q7qpXtB+Iq8mPmvb9C2BOem+rUUnPg8lQsD Ihj9Gk1gYAi7MCfu+CJGQnmPLGuFXwObdhp2Yb+AX9I++MRcvPXkt1v4HEdn8LXDCZ1i LPbljvmQKCM6CVrvYvpvRh6M3TN4p17ticSPE3X4/tcRpUhfVN//agg4xucYONhdLL7e O5C/ixDafcE2wsrtMnsjUkgYPvJwsPmQf34RYLP8SR40b7I7rgtrPbjYfvqAIxTHTk5k 8G++kH8UvZ/5KZOzQVHl1Ne90ygP1F5NJ2QsZ+XM0m+OS/OBtn13ttlFXkRU75Hg4bPA KMCA==
X-Gm-Message-State: ALoCoQn5nOUn4CRKAhyNmsR5Z+2taS9KN0aAqCsHwEzwbRxozYIU7FZidZWKn6IvJ8tAPbE54DvZ
X-Received: by 10.140.95.101 with SMTP id h92mr16283319qge.35.1406805484588; Thu, 31 Jul 2014 04:18:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 04:17:44 -0700 (PDT)
In-Reply-To: <53D12A3A.4080808@jitsi.org>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>       <53D12A3A.4080808@jitsi.org>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 13:17:44 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ETeoPYZ6VuuMixH_fmLNzk36FXg
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 11:18:06 -0000

2014-07-24 17:46 GMT+02:00 Emil Ivov :
> The point is that, once the two checks above succeed, the controlling age=
nt
> may choose to send an additional *third* request on *any* of the two in
> order to communicate its desire to use that candidate pair.
>
> This may be the higher priority candidate pair or it may be another one
> (e.g., if it gave a better RTT) and its choice would depend on the
> controlling agent.
>
> Is it clearer now?

Sorry for the delay (holidays). Yes, clearer, thanks a lot.

The "third request in order to communicate its desire to use that
candidate pair" seems to me like an "ICE restart" without signaling
(but just STUN protocol).

In my example above (once the server has replied to both USE-CANDIDATE
and "assumed" a selected pair by following RFC 5764 procedures) the
server may initiate DTLS (let's assume it gets the setup:active role).
After 10ms the client sends a new USE-CANDIDATE with the new proposed
attribute REALLY-USE-THIS-CANDIDATE while in the middle of the DTLS
handshake.

Now what? How to deal with that? DTLS reset once a
REALLY-USE-THIS-CANDIDATE is received? that must be clarified.

And how should the ICE controlled determine that it must wait for the
optional new ICE request after common RFC 5764 procedures? a new
ice-option attribute in SDP that the remote peer may not understand?


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 04:31:27 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F5B1A0AAE for ; Thu, 31 Jul 2014 04:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPZAtXqWizhx for ; Thu, 31 Jul 2014 04:31:25 -0700 (PDT)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BED41A0AAD for ; Thu, 31 Jul 2014 04:31:25 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id i13so2309939qae.20 for ; Thu, 31 Jul 2014 04:31:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=q1AGtRp/Qdfxs4k/+cCjE/x5MRslVQiYKaitmcipD1M=; b=a3yOYuHg+fW1PgTdnnrvf0LVGDRgwVdMELGROfrvRJvBWrDW5PRCXSS2WAGKmfCZtO Yi0nHCiDsdESGQasblGXfMcX/M+gzkdMGqmIvXJy9LYVQ5vd7WoM2UBD7MAJLrDOqWOT OuUkBCuBOaC/zYe1RVX5GI2WCahXlLw9cYKWX4+8PEnovuYjrvWlNNbRMGfv0zKebiWL RaFWBDA1vmMLYClo2wKCj3pXnuhGeAHoeew2b3QxrqdAL9yLDlsU0CVJeWTftJFGPKSu XnWHGMPeGhpJ1kXXF7KLTaqYGg2nIbwGmFtEA5tMxZtdEaP9/8nVU7ffuMQgnHpgDPP8 1rtg==
X-Gm-Message-State: ALoCoQl21oUWXK8sfGI5KwMCwLJlwrPc3ea91H1jTrg/a0b+EIg/kYYRM7+ogLGySpI2Nssggria
X-Received: by 10.224.128.9 with SMTP id i9mr17722209qas.50.1406806284518; Thu, 31 Jul 2014 04:31:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 04:31:03 -0700 (PDT)
In-Reply-To: <53D12A3A.4080808@jitsi.org>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>       <53D12A3A.4080808@jitsi.org>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 13:31:03 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YjqfMNrZP8Igqdg9yUgHR4m4Iw8
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 11:31:26 -0000

2014-07-24 17:46 GMT+02:00 Emil Ivov :
> Getting multiple USE-CANDIDATES on *different* candidates is simply the
> definition of aggressive nomination. We are not discussing this


Just a question:

- peerA sets two interfaces for ICE and peerB just one.
- peerA uses aggressive ICE.

Does it mean that peerA will send two ICE requests with USE-CANDIDATE
from its two interfaces to the single interface of peerB? or not? That
was my point all the time.

Thanks.

--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 04:35:10 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9279B1A0AAD for ; Thu, 31 Jul 2014 04:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBDv6pIY00hu for ; Thu, 31 Jul 2014 04:35:07 -0700 (PDT)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881611A0AAE for ; Thu, 31 Jul 2014 04:35:07 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id e89so3461813qgf.31 for ; Thu, 31 Jul 2014 04:35:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=WSVdv+Qc+HMWNnnT2zUXkY4lrRoekmui8EmvRXaMV3s=; b=YoafuDta1EL+g+Nmg3aw5DM2+3fnFB0D1PJGZiHVZDtRYPr77VMfkJPRYoghgorbGD 45MJgHaMasR1dnYHweGX/JC0guar7MUaSefDryLFrHlRT46yQDFvXIBEUhbiHoR1EeSd oRdsY3k2VGO3X5sHn3EPyICwC/RzUYG8jUXTlwGBFNoOjHo5cwhmLbhppECj+3grAPKa I8p28y4LW5mNYVEMBqmKCBdurchFnBomEQZHuUi8MgDn4ZGP6evztKYP2ifUk01uoxKb DtTI0mtxYNWW/fGKiEjAbvl/SRat15wiIz3GJuH/UtfFjo3Shb3LbV1WL8Rs6Rx3Zo1U 1YRA==
X-Gm-Message-State: ALoCoQmAy2DtnmRPZYLkd8vyNYbzMmR6Ego9pdHDmNixnbsLmSEnKgq2rsSc0Zm4o3QbtLB/O92U
X-Received: by 10.140.95.101 with SMTP id h92mr16435402qge.35.1406806506775; Thu, 31 Jul 2014 04:35:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 04:34:45 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>       <53D12A3A.4080808@jitsi.org> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 31 Jul 2014 13:34:45 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/l_pKhblTXVVAJ9oaBFbUNClz2WQ
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 11:35:08 -0000

2014-07-24 19:16 GMT+02:00 Justin Uberti :
> The PRIORITY attribute is only for determining priority for peer-reflexiv=
e
> candidates. Using it to change priority for other types of candidates wou=
ld
> be a significant change in semantics; I don't want to go there.

Correct me if I'm wrong, but a ICE-Lite server does not even need to
know about the ICE parameters it signals to the peer and it receives
form the peer (but just its own ufrag and passwd) and can determine
which is the selected pair by just inspecting the PRIORITY attribute
in received ICE requests with USE-CANDIDATE.


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 10:43:34 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7B11B2959 for ; Thu, 31 Jul 2014 10:43:32 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0T6YmM6cEa4 for ; Thu, 31 Jul 2014 10:43:31 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B707A1B2948 for ; Thu, 31 Jul 2014 10:43:27 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so3083930wgg.19 for ; Thu, 31 Jul 2014 10:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jzCORYT6w6VC87JfofI2HluwWa+bNy9ZJ2ZRD1vvK/I=; b=AifSluOrBbmC/YmdiLEXRmWjlSLIkqscExF4IQMDt/fCCYw0wigqqQPeFjynF2JF7h B/85ujYdukLvuD/mPM43kRFoi0+vHx2/t7aLnFjRHzXomX6dfjkZ+ASRPWLZFGLt+jer YQ6OOMlDbNj1Qfk9z1MObYhMJ1kSVpsR/BLjn0gQZKROXaxDzzjkPes/Isnleyg/khDG lXr2i9COyr8oYapWuyDdC7KIulTJXeLFJvNc8dw7G858np6TMGV+SGguB7oz6U8/GIoZ e0WlO+nYyWSYx6SYD1zyDItsJsxUSpQwziKDpmOEWl/SnshHtbXc9G2Qhwvy0UvrLpVH jWFg==
MIME-Version: 1.0
X-Received: by 10.180.73.6 with SMTP id h6mr17946737wiv.65.1406828606244; Thu, 31 Jul 2014 10:43:26 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Thu, 31 Jul 2014 10:43:26 -0700 (PDT)
In-Reply-To: 
References:  <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com>     
Date: Thu, 31 Jul 2014 10:43:26 -0700
Message-ID: 
From: Martin Thomson 
To: Dan Wing 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hCkraXTVXUvtmCJ4GIvR5IexJIM
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Faster ICE by role reversal?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 17:43:33 -0000

On 31 July 2014 00:01, Dan Wing  wrote:
> Sortof.  What I had in mind was sending ClientHello with a new TLS
> extension, let's call the extension STUN Binding Request and let's say it
> contains exactly the same bits as the UDP payload of an actual STUN Binding
> Request.  When the server receives that UDP packet (containing both a DTLS
> ClientHello and embedded STUN Binding Request payload), it can do its normal
> STUN processing against that packet.  When it decides to send its STUN
> Binding Response, it does the processing necessary to generate its DTLS
> ServerHello.  It puts them together into the DTLS ServerHello response and
> replies to the ServerHello.  After that, over that 5-tuple, normal ICE
> processing can occur (such as for the periodic consent checks).


That is an interesting idea.  I'd have to sit down and look at what
goes in a consent check to see if anything can be trimmed out.  Off
the cuff, I can't think of anything that we could safely remove,
except maybe the cookie and fingerprint code.  You still need
XOR-MAPPED-ADDRESS, PRIORITY, proof of possession of ice-pwd, and all
that junk.  I'm not sure about the transaction ID.  (D)TLS defers
proof of receipt more than I'd be comfortable with, I think.

And yes, HelloVerify seems OK.

On the plus side for something like this, indicating support is easy to address.

Maybe this is something we should be talking to Joe Hildebrand about.


From nobody Thu Jul 31 12:09:13 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF751A0048 for ; Thu, 31 Jul 2014 12:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level: 
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvL0ohI7MLhc for ; Thu, 31 Jul 2014 12:09:11 -0700 (PDT)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA2A1A000E for ; Thu, 31 Jul 2014 12:09:11 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id hq11so4977646vcb.38 for ; Thu, 31 Jul 2014 12:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F0MAp1Ro6du0nvsmrOjI1EIyh1gvCr4agtg5BdXS8mQ=; b=hO2fiIxlev1k27LsMzv9ff485WCt4ckjdgCh35WtykcIJTFZx5jhspC+oJHgpNlqV7 1vEep2ypvy6ESk2ZyzKSHXbxy2sQSPus7iL3aG5wnLr80JjEvWm6K8eUtaoEhnYGa7wm nHrIm7FuyrBOTcyDOTrkzhKxUIq6Ji2uzIrvlSV4yuj5z7KuRRPDovK5BpGyL5vwi5T5 AohtSvJAjg+vF/wI1inD1ifUYhDreGWpz1KlhweXPX//C7t+msl/lfCgG6X8WKKNho1H F3dzwop3eA0eL7kbg5G418cGqx0boAp493CB3SS6gLIqlfSYbPV2pKJU2QSNyaJUGRlU auOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F0MAp1Ro6du0nvsmrOjI1EIyh1gvCr4agtg5BdXS8mQ=; b=dBh2lsPHWHlObLPhpCrqroJCPhv0eLKkKVbll86kOOLoDc8I1NJ3WA2v54171GNyfv rRlbhndqYFFCw+oIZafaR+2koFyLhg+5OCA5x/LHdCZYEWq2U/n9/l/9R5c2DMFUnqxu IWyR6j4JFAmxVXn0XWy7XEkCgj1HWopwabKg8CfLWdkJi6EZ1aCc4fTIF/eva9TZZCdb Z58cNJ1hgVZ7pVRzdthhI5smo0i0FG2FnL0acHMihSzbdUXopIdnnwjthPSazvEfK5ta /v5v8pcX+PLe/9lNX+8tHKvXKnz8rDZghwgCAXt8MDQJuLgKc/DnGN4fXDTZ4M7EnDvE UofA==
X-Gm-Message-State: ALoCoQmjldDFzv5kHV9JLVtufR2v97U+XFFIUqInxpkL5tE0jQzh93WQxKxzJQ3w6Lbb7or+cmM+
X-Received: by 10.52.251.195 with SMTP id zm3mr285891vdc.36.1406833750115; Thu, 31 Jul 2014 12:09:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Thu, 31 Jul 2014 12:08:50 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>  
From: Justin Uberti 
Date: Thu, 31 Jul 2014 12:08:50 -0700
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=001a1136030aef2afb04ff82017b
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yJIxjFexwc7x3jcB03NpGicaVGo
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 19:09:12 -0000

--001a1136030aef2afb04ff82017b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 31, 2014 at 4:03 AM, I=C3=B1aki Baz Castillo  wr=
ote:

> 2014-07-31 1:25 GMT+02:00 Justin Uberti :
> >> I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently receiv=
ed USE-CANDIDATE=E2=80=9D
> to
> >> determine the selected pair.  Checks will race each other, especially
> when
> >> the paths=E2=80=99 RTTs are very different.
> >
> >
> > Agree, although this would be addressed by any of:
> > - receipt of secure media is considered an indication of the selected
> pair
>
> Please, consider DTLS rather than secure media. Secure media is easy
> to handle regardless where it comes from. DTLS is not as you need a
> separate context for each tuple.
>
> If you mean that "the controlled must determine as selected pair that
> on which it receives the *first* DTLS ClientHello, being a previously
> validated ICE pair (so the source address is already known thanks to a
> previous ICE transaction)" then that sounds better for me.


As discussed earlier, DTLS does not require a separate context for each
tuple. DTLS should be agnostic about the lower layer protocol (and we
should probably create an errata to resolve this confusion).

--001a1136030aef2afb04ff82017b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Jul 31, 2014 at 4:03 AM, I=C3=B1aki Baz Castillo <=
ibc@aliax.net> wrote:



2014-07-31 1:25 GMT+02:00 Justin Uberti <juberti@google.com>:




>> I don=E2=80=99t think you want a rule of =E2=80=9C=
most recently received USE-CANDIDATE=E2=80=9D to

>> determine the selected pair. =C2=A0Checks will race each other, es=
pecially when

>> the paths=E2=80=99 RTTs are very different.

>

>

> Agree, although this would be addressed by any of:

> - receipt of secure media is considered an indication of the selected =
pair




Please, consider DTLS rather than secure media. Secure media is easy<=
br>
to handle regardless where it comes from. DTLS is not as you need a

separate context for each tuple.



If you mean that "the controlled must determine as selected pair that<=
br>
on which it receives the *first* DTLS ClientHello, being a previously

validated ICE pair (so the source address is already known thanks to a

previous ICE transaction)" then that sounds better for me.

As discussed earlier, DTLS does not require a separate cont=
ext for each tuple. DTLS should be agnostic about the lower layer protocol =
(and we should probably create an errata to resolve this confusion).


=C2=A0


--001a1136030aef2afb04ff82017b--


From nobody Thu Jul 31 12:11:52 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4EB1A0048 for ; Thu, 31 Jul 2014 12:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level: 
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blgMPY2-JOet for ; Thu, 31 Jul 2014 12:11:46 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59031A0021 for ; Thu, 31 Jul 2014 12:11:45 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so4939037vcb.21 for ; Thu, 31 Jul 2014 12:11:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=psrGQXSwOALgVOki0q/LVT8l+O0R6uMGUdGF4l6AyCs=; b=VfuxTPknpAifuJ1PpiM8w6Ns0kxLnyT/pHeMakhQJjbQB6QqaA4bGeUAoWlvU2Ezuc 4jGlhkD2iTa8qhL9cmuRXJRNCdffaLhMsrucrrxGf8B/vAloVHoehaUJcOKf3C+bmGAR G7qNFSpsnsn48yT8DfqbXwBSTSEg8AsezoJFnqolbdeJvDcxlrlZinza1bRw0XjPJdCS g0XFFrjMVHbAqUUfmhIuQl2zNLEF6qSz1W4WLcSWgsozSWBOrqG/2hoszCEFAKhvJ03n NAIlpZ0HmrWntIHQftgo8VusFSiBfXxEsy21UfI50I4dfhH7FRj6kCFCLk0PiKX8y/O+ nlKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=psrGQXSwOALgVOki0q/LVT8l+O0R6uMGUdGF4l6AyCs=; b=VbxUeVrHtHjWYtj2GKY8yCZlTUEHvHq4zVQewj5RFsEdW7N7mKMblHg2EqRmQgUNPd icUz64V+zZCFOOZd5Oz3uonzlSW0G91IwAfWHKUWK14Xu7Qs7nm1B+U43MyssExK5oos PDbx3oZJDIaaH0LQojjJRhNDkz3MhZkiMSksoHtdqJOeiNQ8cU8LWt3SCY9/DdxvflOC afXQlOIrJmFigrTRu03wPXvXjtkj/gjfDXrg+OiIoZvwKz/K6zxkm+PDpmEL0q7IuGPp w9+rcATIX/YeBdJLBQlhu92bbqyohlrvw+rzKgIK2H4mfN3skEKdVk6WlKDKXtXBi8kV LIZA==
X-Gm-Message-State: ALoCoQnZNlDY+tW+pAZ8XV2wCAxy74osaaAZrlNOm2JuY3gfO2vHpthTu5BVrQJIFnrPGq0bxj6/
X-Received: by 10.52.160.10 with SMTP id xg10mr274756vdb.1.1406833903229; Thu, 31 Jul 2014 12:11:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Thu, 31 Jul 2014 12:11:22 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>       <53D12A3A.4080808@jitsi.org>  
From: Justin Uberti 
Date: Thu, 31 Jul 2014 12:11:22 -0700
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=089e013cb7b60f820904ff820bcc
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7TzSXlVZoq6RKD62Ov7dxixVst0
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 19:11:51 -0000

--089e013cb7b60f820904ff820bcc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 31, 2014 at 4:34 AM, I=C3=B1aki Baz Castillo  wr=
ote:

> 2014-07-24 19:16 GMT+02:00 Justin Uberti :
> > The PRIORITY attribute is only for determining priority for
> peer-reflexive
> > candidates. Using it to change priority for other types of candidates
> would
> > be a significant change in semantics; I don't want to go there.
>
> Correct me if I'm wrong, but a ICE-Lite server does not even need to
> know about the ICE parameters it signals to the peer and it receives
> form the peer (but just its own ufrag and passwd) and can determine
> which is the selected pair by just inspecting the PRIORITY attribute
> in received ICE requests with USE-CANDIDATE.
>
>
ICE Lite doesn't care about PRIORITY. Since you have to use regular
nomination with ICE Lite, it just uses the single pair on which
USE-CANDIDATE is set.

--089e013cb7b60f820904ff820bcc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 31, 2014 at 4:34 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:



2014-07-24 19:16 GMT+02:00 Justin Uberti <=
;juberti@google.com>:


> The PRIORITY attribute is only for determining priorit=
y for peer-reflexive

> candidates. Using it to change priority for other types of candidates =
would

> be a significant change in semantics; I don't want to go there.



Correct me if I'm wrong, but a ICE-Lite server does not even need=
 to

know about the ICE parameters it signals to the peer and it receives

form the peer (but just its own ufrag and passwd) and can determine

which is the selected pair by just inspecting the PRIORITY attribute

in received ICE requests with USE-CANDIDATE.



=
=C2=A0
ICE Lite doesn't care about PRIORITY. Since you have t=
o use regular nomination with ICE Lite, it just uses the single pair on whi=
ch USE-CANDIDATE is set.





--089e013cb7b60f820904ff820bcc--


From nobody Thu Jul 31 12:18:37 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FE91A00C2 for ; Thu, 31 Jul 2014 12:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIYBQ-bqPKz2 for ; Thu, 31 Jul 2014 12:18:34 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986341A00DF for ; Thu, 31 Jul 2014 12:18:34 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5052484vcb.33 for ; Thu, 31 Jul 2014 12:18:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W5CIPJrkHXn8E6p176xdNE0aOw9Rw9M/l9kDPkxLi+M=; b=NZ2an0BN5O8M6UfbgpcBEkJd+y7aZ3gtuc0co2cANJv7gSgZWjYIwYIQr/WvnqiZei pickFe0wcueNdj2tFjxz0iWa6dXuUZNXzbOdUSwupIZohn3hUd3nE5sp46ts9CSUg26u aaWFaBUMbGs15EzZv7GWYcHlAnxp/BB1Zz2toaAwMYwbuYYfirXrtu2b00e8aXBaPOVR 49xHq7VMfDGX53C78ZF4C65XabYzgKyX2BuiXlxgYHu0OlrCa+TotrOrcRNrKtIZGfr5 8tgcECQb9QLDeHcLC00V/2YAL3ZokZkeTgyVp6LXQ4PC2N/55SPNasniQ6bRnwXMlIOy KbdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W5CIPJrkHXn8E6p176xdNE0aOw9Rw9M/l9kDPkxLi+M=; b=Gyt49oeGsJyevcpx9W5hiwas55iHjnSlfsBbtpujKHcY6MrbqHLM0haAF8BeQb4c2B 3fXer5boZh46IqP4/N1CxsJW2S+bKYMq2QtL3+vlXs1jvgIFBcKX8IYPCORArh3Fg6wz jsyfEFex/51k/wn0heQ3oO3OZqdhv67vkyANUmffkX0iurEml4cM/igYGUI2h4Ec0LFp POKrBCcKlvTX/wR+NEY9MYyWzIb9Y4AknyyMVEik1JCmxGfbJHJVFspxlAoywXaKvuMa DDkYStHkSBrR2zGXOyde+7b3oAYfUoK4jhld3nyNH8IImZ6ALu2V8MnNc2yHLRa8mcQp xTsw==
X-Gm-Message-State: ALoCoQk+hOflOF7N0ZuCu6+5bhI2zxtemhSwW/h2rIEiG+10z4b04OWMFZu9jKgAllShkeKH4Evi
X-Received: by 10.52.28.9 with SMTP id x9mr342648vdg.48.1406834313714; Thu, 31 Jul 2014 12:18:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Thu, 31 Jul 2014 12:18:13 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> 
From: Justin Uberti 
Date: Thu, 31 Jul 2014 12:18:13 -0700
Message-ID: 
To: Jonathan Lennox 
Content-Type: multipart/alternative; boundary=20cf307abebd86fb6304ff82230b
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5s_HGiUOF-fAEt1kdIt-okP4JD8
Cc: mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 19:18:36 -0000

--20cf307abebd86fb6304ff82230b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti  wrote:

>
>
>
> On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox 
> wrote:
>
>>
>>  On Jul 30, 2014, at 5:59 PM, Justin Uberti  wrote:
>>
>>   On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox 
>> wrote:
>>
>>>  Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination=
, but allow
>>> media to be sent on any valid pair prior to selection.  (Yes, re-readin=
g
>>> 5245, I should have said =E2=80=9CValid=E2=80=9D rather than =E2=80=9CC=
onfirmed=E2=80=9D.  I mis-remembered
>>> the terminology.)
>>>
>>
>>  Understood. But controlled side needs some way to know what pair it
>> should use to send media, so we need some way to indicate this. Would th=
is
>> be done via USE-CANDIDATE? If so, we could end up with multiple
>> USE-CANDIDATEs as we figure out the ideal path to use, which doesn't fit
>> exactly with regular nomination as defined in 5245, but otherwise seems
>> exactly like what I am proposing. Basically, controlled side uses the pa=
ir
>> that it most recently received USE-CANDIDATE on as its selected pair.
>>
>>
>>  Oh, that=E2=80=99s true, it has to pick something.
>>
>>  In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t *mat=
ter* what it
>> picks =E2=80=94 it could choose any valid pair, just like the controllin=
g agent
>> does, since it knows that=E2=80=99s a working round-trip path.
>>
>>  For both sides, if you receive media on any candidate (from an IP and
>> port from which you=E2=80=99ve received a valid connectivity check), acc=
ept it.
>>  USE-CANDIDATE is then just an optimization that lets you close down the
>> unselected candidates.
>>
>>  I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently receive=
d USE-CANDIDATE=E2=80=9D
>> to determine the selected pair.  Checks will race each other, especially
>> when the paths=E2=80=99 RTTs are very different.
>>
>>  In my model, there is only ever one USE-CANDIDATE sent per component =
=E2=80=94
>> i.e., it works like pure regular nomination, except for the =E2=80=9Cear=
ly media=E2=80=9D.
>>
>
> OK, I get it now. I think the main issues you face are:
> 1) Inability to selectively free candidates - all candidates except the
> selected pair can be freed by the controlled side after USE-CANDIDATE.
> 2) No guarantee of symmetric RTP - remote side can use a different pair
> than local side - and you can't resolve this without USE-CANDIDATE (see #=
1).
> 3) Potential issues when media arrives on non-nominated pair.
>
> Given #3, I think I'd prefer to find a solution that also addresses #1/#2=
.
>

Sounds like #3 is unlikely to be a problem given 5245 allows it.

What do others think about #1/#2? These seem to be the main differences
between Jonathan's proposal and my proposal.

--20cf307abebd86fb6304ff82230b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti &l=
t;juberti@google.co=
m> wrote:






On Wed, Jul 30, 2014=
 at 3:20 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:














On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote:













On Wed, Jul 30, 2014 at 2:14 PM, Jonathan L=
ennox 
<jonathan@vidyo.=
com> wrote:






Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nomination=
, but allow media to be sent on any valid pair prior to selection. =C2=A0(Y=
es, re-reading 5245, I should have said =E2=80=9CValid=E2=80=9D rather than=
 =E2=80=9CConfirmed=E2=80=9D. =C2=A0I mis-remembered the terminology.)













Understood. But controlled side needs some way to know what pair it sh=
ould use to send media, so we need some way to indicate this. Would this be=
 done via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATE=
s as we figure out the ideal path
 to use, which doesn't fit exactly with regular nomination as defined i=
n 5245, but otherwise seems exactly like what I am proposing. Basically, co=
ntrolled side uses the pair that it most recently received USE-CANDIDATE on=
 as its selected pair.


















Oh, that=E2=80=99s true, it has to pick something.







In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t =
matter=C2=A0what it picks =E2=80=94 it could choose any valid pair, jus=
t like the controlling agent does, since it knows that=E2=80=99s a working =
round-trip path.







For both sides, if you receive media on any candidate (from an IP and =
port from which you=E2=80=99ve received a valid connectivity check), accept=
 it. =C2=A0USE-CANDIDATE is then just an optimization that lets you close d=
own the unselected candidates.










I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently receiv=
ed USE-CANDIDATE=E2=80=9D to determine the selected pair. =C2=A0Checks will=
 race each other, especially when the paths=E2=80=99 RTTs are very differen=
t.







In my model, there is only ever one USE-CANDIDATE sent per component =
=E2=80=94 i.e., it works like pure regular nomination, except for the =E2=
=80=9Cearly media=E2=80=9D.

OK, I get it now. I think the main issues you face are:




1) Inability to selectively free candidates - all candidates except th=
e selected pair can be freed by the controlled side after USE-CANDIDATE.
2) No guarantee of symmetric RTP - remote side can use a different =
pair than local side - and you can't resolve this without USE-CANDIDATE=
 (see #1).




3) Potential issues when media arrives on non-nominated pair.

Given #3, I think I'd prefer to find a solution that a=
lso addresses #1/#2.




Sounds like #3 is unlikely to be a problem given 5245 allows it.=C2=A0=


What do others think about #1/#2? These seem to b=
e the main differences between Jonathan's proposal and my proposal.





--20cf307abebd86fb6304ff82230b--


From nobody Thu Jul 31 12:59:04 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AA51A0109 for ; Thu, 31 Jul 2014 12:59:02 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8xzWu139eX2 for ; Thu, 31 Jul 2014 12:59:00 -0700 (PDT)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1C51A00FE for ; Thu, 31 Jul 2014 12:59:00 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so5091620vcb.35 for ; Thu, 31 Jul 2014 12:58:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=caPFv/1LLIz9NQMfSJ6iDa4/hwVI4OZt5ize93dOEGk=; b=SJ9lFGj7em3Z1ENhgMVV1BUq9EL5SdUYC0+pTt631oBwrtkvcrBlwqpcmfGQ+4slc4 XpDVuSJgOP0pP2SLAkKpal9wzNA6KULJBGGQf0dT2b2qwxioNikP+xJOTt7l+gkWgRyA dv31bPYEckbp8xwVgct3/Y8bEP+VhGvb/bcTeCHvQpjEgSqqhg0xXBxqFup6E3dvywy1 PmXsaglojUGPlCcY5pGhnJIYWiVkBAN0CH77TM/qMi0DU1DtVGTOn9RKG6Gza/SYEVv7 H2KYGOIN4aNRscxWa9M6R7u7qvn2SjIuy5h36oIFp+xO83OYifLZBB/k4y2KdW2si0VN Ro5A==
X-Gm-Message-State: ALoCoQl3yhlsKiL4U24DQyaiguUM648vWJ8fYGD+zhvZvrLzVjoDZu6VAmDiIlshstrgANj4b/Oo
X-Received: by 10.52.244.81 with SMTP id xe17mr643025vdc.24.1406836736678; Thu, 31 Jul 2014 12:58:56 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx.google.com with ESMTPSA id rt17sm15893545vdb.8.2014.07.31.12.58.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 12:58:55 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hy4so4958773vcb.36 for ; Thu, 31 Jul 2014 12:58:55 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.27.16 with SMTP id p16mr651008vdg.14.1406836735586; Thu, 31 Jul 2014 12:58:55 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Thu, 31 Jul 2014 12:58:55 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Thu, 31 Jul 2014 12:58:55 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>   
Date: Thu, 31 Jul 2014 21:58:55 +0200
Message-ID: 
From: Emil Ivov 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=20cf307d0580e1d5bc04ff82b38c
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/JUr6nJ_2aY2oU8kclSlCasSZP3Y
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 19:59:02 -0000

--20cf307d0580e1d5bc04ff82b38c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 31 Jul 2014 9:09 PM, "Justin Uberti"  wrote:
>
> On Thu, Jul 31, 2014 at 4:03 AM, I=C3=B1aki Baz Castillo  =
wrote:
>>
>> 2014-07-31 1:25 GMT+02:00 Justin Uberti :
>> >> I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently recei=
ved
USE-CANDIDATE=E2=80=9D to
>> >> determine the selected pair.  Checks will race each other, especially
when
>> >> the paths=E2=80=99 RTTs are very different.
>> >
>> >
>> > Agree, although this would be addressed by any of:
>> > - receipt of secure media is considered an indication of the selected
pair
>>
>> Please, consider DTLS rather than secure media. Secure media is easy
>> to handle regardless where it comes from. DTLS is not as you need a
>> separate context for each tuple.
>>
>> If you mean that "the controlled must determine as selected pair that
>> on which it receives the *first* DTLS ClientHello, being a previously
>> validated ICE pair (so the source address is already known thanks to a
>> previous ICE transaction)" then that sounds better for me.
>
>
> As discussed earlier, DTLS does not require a separate context for each
tuple. DTLS should be agnostic about the lower layer protocol (and we
should probably create an errata to resolve this confusion).

+1

--sent from my mobile

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

--20cf307d0580e1d5bc04ff82b38c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 31 Jul 2014 9:09 PM, "Justin Uberti" <juberti@google.com> wrote:

>

> On Thu, Jul 31, 2014 at 4:03 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

>>

>> 2014-07-31 1:25 GMT+02:00 Justin Uberti <juberti@google.com>:

>> >> I don=E2=80=99t think you want a rule of =E2=80=9Cmost re=
cently received USE-CANDIDATE=E2=80=9D to

>> >> determine the selected pair. =C2=A0Checks will race each =
other, especially when

>> >> the paths=E2=80=99 RTTs are very different.

>> >

>> >

>> > Agree, although this would be addressed by any of:

>> > - receipt of secure media is considered an indication of the =
selected pair

>>

>> Please, consider DTLS rather than secure media. Secure media is ea=
sy

>> to handle regardless where it comes from. DTLS is not as you need =
a

>> separate context for each tuple.

>>

>> If you mean that "the controlled must determine as selected p=
air that

>> on which it receives the *first* DTLS ClientHello, being a previou=
sly

>> validated ICE pair (so the source address is already known thanks =
to a

>> previous ICE transaction)" then that sounds better for me.
>

>

> As discussed earlier, DTLS does not require a separate context for eac=
h tuple. DTLS should be agnostic about the lower layer protocol (and we sho=
uld probably create an errata to resolve this confusion).


+1


--sent from my mobile


>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

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

>




--20cf307d0580e1d5bc04ff82b38c--


From nobody Thu Jul 31 13:30:34 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07361A0142 for ; Thu, 31 Jul 2014 13:30:32 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4atO-kSmjw4 for ; Thu, 31 Jul 2014 13:30:30 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070561A00FE for ; Thu, 31 Jul 2014 13:30:29 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hy4so5024441vcb.36 for ; Thu, 31 Jul 2014 13:30:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h13/4I3OFfdbSRFLilGxCVWXHa8x9UgUl1LAayMP6hk=; b=XHp428ib1U1katOmONXXk8XCUuZHjLGDwPqGH4m9U0Jey11elWDwbIsS85T1NIdTMt 31Qg+Bk5FbzVuaV0W+8MT0qIz8wp/OBCwNNH3rxssvlNksYIusAMusrWGWww0/5gY+A+ KvTT3NejZw4ua0RPq5Dy9gwS3pYb1i5xkPBHEMT90NeHqZwJ6Vqr3NFD5mFYtNMxw1/h gKYoStqoBqcXHwbH75cj7gpLRG3RiaWmqXGexOVB6ulVfTXfRBk025Mx5c9uyB3xlw8K n9JDzKZs6M9lkIhFAxtNFvsd7VQSPhFQMMsLkUAG+m6sY8LdAKBMULteI2ACPbJibgHB mwZA==
X-Gm-Message-State: ALoCoQnC+AA6uGrnjyFv8buOWwGW66zVOjI9CgNdCfRu0fu3Ig/C5h91NI5j1RbPL1GbAUScX6GL
X-Received: by 10.221.44.131 with SMTP id ug3mr1004219vcb.40.1406838628252; Thu, 31 Jul 2014 13:30:28 -0700 (PDT)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx.google.com with ESMTPSA id xb6sm16022874vdc.19.2014.07.31.13.30.27 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so5161923vcb.4 for ; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.131.207 with SMTP id y15mr1000695vcs.71.1406838627186; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>    
Date: Thu, 31 Jul 2014 22:30:27 +0200
Message-ID: 
From: Emil Ivov 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=001a11348c2ea153f504ff83248c
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/N4gssFM2ZsPDCPSEGvuzyy37qnU
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 20:30:33 -0000

--001a11348c2ea153f504ff83248c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 31 Jul 2014 9:18 PM, "Justin Uberti"  wrote:
>
>
>
>
> On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti  wrote=
:
>>
>>
>>
>>
>> On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox 
wrote:
>>>
>>>
>>> On Jul 30, 2014, at 5:59 PM, Justin Uberti  wrote:
>>>
>>>> On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox 
wrote:
>>>>>
>>>>> Thus the suggestion I=E2=80=99m making =E2=80=94 do regular nominatio=
n, but allow
media to be sent on any valid pair prior to selection.  (Yes, re-reading
5245, I should have said =E2=80=9CValid=E2=80=9D rather than =E2=80=9CConfi=
rmed=E2=80=9D.  I mis-remembered
the terminology.)
>>>>
>>>>
>>>> Understood. But controlled side needs some way to know what pair it
should use to send media, so we need some way to indicate this. Would this
be done via USE-CANDIDATE? If so, we could end up with multiple
USE-CANDIDATEs as we figure out the ideal path to use, which doesn't fit
exactly with regular nomination as defined in 5245, but otherwise seems
exactly like what I am proposing. Basically, controlled side uses the pair
that it most recently received USE-CANDIDATE on as its selected pair.
>>>
>>>
>>> Oh, that=E2=80=99s true, it has to pick something.
>>>
>>> In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=99t matt=
er what it picks
=E2=80=94 it could choose any valid pair, just like the controlling agent d=
oes,
since it knows that=E2=80=99s a working round-trip path.
>>>
>>> For both sides, if you receive media on any candidate (from an IP and
port from which you=E2=80=99ve received a valid connectivity check), accept=
 it.
 USE-CANDIDATE is then just an optimization that lets you close down the
unselected candidates.
>>>
>>> I don=E2=80=99t think you want a rule of =E2=80=9Cmost recently receive=
d USE-CANDIDATE=E2=80=9D
to determine the selected pair.  Checks will race each other, especially
when the paths=E2=80=99 RTTs are very different.
>>>
>>> In my model, there is only ever one USE-CANDIDATE sent per component =
=E2=80=94
i.e., it works like pure regular nomination, except for the =E2=80=9Cearly =
media=E2=80=9D.
>>
>>
>> OK, I get it now. I think the main issues you face are:
>> 1) Inability to selectively free candidates - all candidates except the
selected pair can be freed by the controlled side after USE-CANDIDATE.
>> 2) No guarantee of symmetric RTP - remote side can use a different pair
than local side - and you can't resolve this without USE-CANDIDATE (see #1)=
.
>> 3) Potential issues when media arrives on non-nominated pair.
>>
>> Given #3, I think I'd prefer to find a solution that also addresses
#1/#2.
>
>
> Sounds like #3 is unlikely to be a problem given 5245 allows it.
>
> What do others think about #1/#2? These seem to be the main differences
between Jonathan's proposal and my proposal.

While #3 is indeed allowed by 5245 I don't think current regular nomination
implementations would actually handle things that way. (Except for those
that started with aggressive nomination as the default).

#1 and #2 can be important for ICE libs that just return a socket for the
app to use (the do need to know whem to return it)


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

--001a11348c2ea153f504ff83248c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 31 Jul 2014 9:18 PM, "Justin Uberti" <juberti@google.com> wrote:

>

>

>

>

> On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti <juberti@google.com> wrote:

>>

>>

>>

>>

>> On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

>>>

>>>

>>> On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote:

>>>

>>>> On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

>>>>>

>>>>> Thus the suggestion I=E2=80=99m making =E2=80=94 do re=
gular nomination, but allow media to be sent on any valid pair prior to sel=
ection. =C2=A0(Yes, re-reading 5245, I should have said =E2=80=9CValid=E2=
=80=9D rather than =E2=80=9CConfirmed=E2=80=9D. =C2=A0I mis-remembered the =
terminology.)


>>>>

>>>>

>>>> Understood. But controlled side needs some way to know wha=
t pair it should use to send media, so we need some way to indicate this. W=
ould this be done via USE-CANDIDATE? If so, we could end up with multiple U=
SE-CANDIDATEs as we figure out the ideal path to use, which doesn't fit=
 exactly with regular nomination as defined in 5245, but otherwise seems ex=
actly like what I am proposing. Basically, controlled side uses the pair th=
at it most recently received USE-CANDIDATE on as its selected pair.


>>>

>>>

>>> Oh, that=E2=80=99s true, it has to pick something.

>>>

>>> In the semantic I=E2=80=99m suggestion, I think it doesn=E2=80=
=99t matter=C2=A0what it picks =E2=80=94 it could choose any valid pair, ju=
st like the controlling agent does, since it knows that=E2=80=99s a working=
 round-trip path.

>>>

>>> For both sides, if you receive media on any candidate (from an=
 IP and port from which you=E2=80=99ve received a valid connectivity check)=
, accept it. =C2=A0USE-CANDIDATE is then just an optimization that lets you=
 close down the unselected candidates.


>>>

>>> I don=E2=80=99t think you want a rule of =E2=80=9Cmost recentl=
y received USE-CANDIDATE=E2=80=9D to determine the selected pair. =C2=A0Che=
cks will race each other, especially when the paths=E2=80=99 RTTs are very =
different.

>>>

>>> In my model, there is only ever one USE-CANDIDATE sent per com=
ponent =E2=80=94 i.e., it works like pure regular nomination, except for th=
e =E2=80=9Cearly media=E2=80=9D.

>>

>>

>> OK, I get it now. I think the main issues you face are:

>> 1) Inability to selectively free candidates - all candidates excep=
t the selected pair can be freed by the controlled side after USE-CANDIDATE=
.

>> 2) No guarantee of symmetric RTP - remote side can use a different=
 pair than local side - and you can't resolve this without USE-CANDIDAT=
E (see #1).

>> 3) Potential issues when media arrives on non-nominated pair.

>>

>> Given #3, I think I'd prefer to find a solution that also addr=
esses #1/#2.

>

>

> Sounds like #3 is unlikely to be a problem given 5245 allows it.=C2=A0=


>

> What do others think about #1/#2? These seem to be the main difference=
s between Jonathan's proposal and my proposal.


While #3 is indeed allowed by 5245 I don't think current=
 regular nomination implementations would actually handle things that way. =
(Except for those that started with aggressive nomination as the default).<=
/p>


#1 and #2 can be important for ICE libs that just return a s=
ocket for the app to use (the do need to know whem to return it)



 _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

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

>




--001a11348c2ea153f504ff83248c--


From nobody Thu Jul 31 15:11:30 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674851A019A for ; Thu, 31 Jul 2014 15:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKOFntMq-EwH for ; Thu, 31 Jul 2014 15:11:24 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED3A1A0188 for ; Thu, 31 Jul 2014 15:11:23 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so4879310qgf.35 for ; Thu, 31 Jul 2014 15:11:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=e8H3eMx7xYEpklu4HJ3KM45O4ZeCfkv57sNDayuTHfw=; b=ViwYTwUWlQtd7FUfkw7qgneZcKyw5GLpXo5Bg60mzImQ4saZmkwECm1GeNSKQwSGLc kcln6VHpzVuiT8qxg+EphxxIFbrIpLe7IeH+tTp0dDSWnyVxGiND3wY5Gp5Res9smoOo wOOaEBms0LmJHl860z7FdODIOORLTA0oZRKjU0ES8shJQKi/xAiUNXs2PvxPr7G37vgX siK/tbSfTYovY8/6cvgQZc/EBc+fDyZp32DZ/jmL4XeofAUnhuNlQa5sNtt1HSC8Cff2 MsUcw4hZ5NSLTuxOENE/K6rWKpY/xVYW5F3prdA/pnr5j52W6tBopYDLvR2XYDQ2PyLt f46A==
X-Gm-Message-State: ALoCoQmdktOzZYAwrtidzXKtyYSJTI8JtCJLvCS+lesolOnTlsqWpo/FP+UKbIFxkrD48MblaXWP
X-Received: by 10.224.131.71 with SMTP id w7mr1928800qas.91.1406844682369; Thu, 31 Jul 2014 15:11:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 15:11:02 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>   
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 1 Aug 2014 00:11:02 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xlmoNobVw1DwiJff0iSOnWgjPOw
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 22:11:26 -0000

2014-07-31 21:08 GMT+02:00 Justin Uberti :
>> Please, consider DTLS rather than secure media. Secure media is easy
>> to handle regardless where it comes from. DTLS is not as you need a
>> separate context for each tuple.
>>
>> If you mean that "the controlled must determine as selected pair that
>> on which it receives the *first* DTLS ClientHello, being a previously
>> validated ICE pair (so the source address is already known thanks to a
>> previous ICE transaction)" then that sounds better for me.
>
>
> As discussed earlier, DTLS does not require a separate context for each
> tuple. DTLS should be agnostic about the lower layer protocol (and we sho=
uld
> probably create an errata to resolve this confusion).

Of course DTLS is low layer agnostic (so it can be carried over UDP,
TCP or whatever) but the fact is that it must be carried over a
"transport" (whatever a transport is). And when it is carried over UDP
it is needed that we create a separate DTLS session/context for each
remote address (IP:port). This is, you cannot open a UDP socket and
deliver there DTLS packets coming from different source addresses.
Instead you need to maintain a DTLS session/context per each source
address. So let's say that DTLS requires a separate transport for each
session (whichever a transport is a TCP connection, a UDP IP:port
tuple or any other data multiplexing solution).

For example, in the case of a ICE-Lite server this is what I expect:

1) The client sends ICE Binding requests and the server replies to
them (ok, a single UDP socket with responses sent to each source
address is ok).
2) At some point the client sends a Binding request with USE-CANDIDATE.
3) Upon that the server can safely determine that the remote address
is the source address from which that Binding request arrived, and can
*safely* ignore any DTLS or SRTP/SRTCP packet coming from any other
source address.

My concern is: is bullet 3) 100% true with the current set of
specifications plus the new proposed ICE mechanism? The fact is that
RFC 5764 states that a peer must be ready to receive "media" in any of
the offered ICE candidates, but that breaks everything, specifically
when it comes to DTLS (as said above that would require that the peer
creates a separate DTLS session for each different source address from
which "media" receipt is considered "valid").


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 15:13:44 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C9A1A01D5 for ; Thu, 31 Jul 2014 15:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcFNF2fukRAF for ; Thu, 31 Jul 2014 15:13:38 -0700 (PDT)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E50B1A01CB for ; Thu, 31 Jul 2014 15:13:38 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id i13so3022466qae.20 for ; Thu, 31 Jul 2014 15:13:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=p0T47s1EQGoSZRqh9BOVZKUKnxiV+IO6oNgSfCp71UY=; b=fd7k5V0i45RTE3OmaDRKV50cEjAjhkdQZZrUIMtdvSyETlElUZbYj5SdWfOuFr+0xD cfQm9H916zCac+AySqvs/2bqxGT8Zcw6CClrhPSHplRHEBMi+SaxXWgr1yZbIqaxuxFh DqsdI/+P1bAWYZPXU2MiuFEf7a2N/hvYyXhlKnKxSiCouLUApXI9Mrf0kgIe5GjL2ix5 EV6jk4ShnOYvRUztJX23lHusQnosClXzlyG5lExtKfM/vop33dgfl1zcHezr5fY9W3ke 8Kyb5lgfFKJJuTV0X48KE72VE4BnbutXVtx2JRxe3WBMKojIZYR5qXU/K+7FQO/NmVfR WsDg==
X-Gm-Message-State: ALoCoQlb+8I0y23+oKcNG4q4oKMqwi8Ok4h+tz3CO8EQS3fOnN5dIOUGUbPLKOPukUrnQN6CKAxN
X-Received: by 10.140.38.169 with SMTP id t38mr1857755qgt.3.1406844817368; Thu, 31 Jul 2014 15:13:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 15:13:17 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>    
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 1 Aug 2014 00:13:17 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/trYUcbAkCWeY8djCPzRyjuvWWK4
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 22:13:39 -0000

2014-08-01 0:11 GMT+02:00 I=C3=B1aki Baz Castillo :
> The fact is that
> RFC 5764 states that a peer must be ready to receive "media" in any of
> the offered ICE candidates,

Sorry, I mean RFC 5245 (ICE).


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 15:18:04 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFBB1A01E5 for ; Thu, 31 Jul 2014 15:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDo3dmyLb2_X for ; Thu, 31 Jul 2014 15:17:59 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54621A01D5 for ; Thu, 31 Jul 2014 15:17:58 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id dc16so3048937qab.22 for ; Thu, 31 Jul 2014 15:17:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=9zl/kjn2eE6FatNnMpkb3AVAKGLdRrlj66/3UnqEfnw=; b=RDyT/wjRSwavrxviIYKm3PeSefF3hlWKAMXZPvseGqfrep+bxmbrrVfEmo3HbZI7Je uUPkSPEa0OlbZhUk9dFllvSoHHMzNFupEfNARM4lhQXGwFVsmmdi1QyJVcO6DU4jxr6P 6JqF8j16ZNhHd88Vod6SaXkB16YCrsSXFLeglRoUl21qB5b4zWaaj12uZtDri4ZcjMxM K25TtPRLluHjVF0G6y/gO3F2TdEfW/f9emRTlva9Xp8wmjh/laPLjQQrhkdoZLqtVIn1 jEVs8TntiFttDkGfLz8IGWwSgaAB5zHwGvq0LFVyGZ8nO1y8uJFfN9In1g2LvacY+loF KPJQ==
X-Gm-Message-State: ALoCoQkCYMWO7rh6B6EhiqJ8m6bTBu1qeQZSCcvWezKRx1rE3/2M0CKAC3kgX1cqBX9mz1nGtgRL
X-Received: by 10.229.178.202 with SMTP id bn10mr2063656qcb.6.1406845078113; Thu, 31 Jul 2014 15:17:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 15:17:38 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>     
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 1 Aug 2014 00:17:38 +0200
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AGc2lHDyvJFnPQeGeq8icu1IkAQ
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 22:18:00 -0000

2014-07-31 22:30 GMT+02:00 Emil Ivov :
>>> 3) Potential issues when media arrives on non-nominated pair.
>>
>> Sounds like #3 is unlikely to be a problem given 5245 allows it.
>
> While #3 is indeed allowed by 5245 I don't think current regular nominati=
on
> implementations would actually handle things that way. (Except for those
> that started with aggressive nomination as the default).

Yes, RFC 5245 allows media coming on non-nominated pair. But note that
RFC 5245 knows nothing about DTLS. I strongly expect that RFC 5245
would not allow that in case of DTLS-SRTP given that allowing DTLS
coming from "any" source address adds too much complexity.

My understanding of ICE is that it should be the definitive tool to
*establish a transport* and once it concludes, the "application data"
(let's say DTLS and SRTP) must be delivered over the selected pair,
and data coming from any other source should be safely discarded.
Sadly RFC 5245 does not mandate that but given that RFC 5245bis is a
work in progress I hope this requirement is added.


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 15:19:21 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8BA1A01F7 for ; Thu, 31 Jul 2014 15:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VND83CAzx1qK for ; Thu, 31 Jul 2014 15:19:17 -0700 (PDT)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B00B1A023F for ; Thu, 31 Jul 2014 15:19:17 -0700 (PDT)
Received: by mail-qa0-f54.google.com with SMTP id k15so3016098qaq.41 for ; Thu, 31 Jul 2014 15:19:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4w5yfWmo0gKH8bo4J/eZ7unEiRK7EaD++4OA7rP4/Nc=; b=IVmbbh0jhI+7RHyt7QAOx4LZQg+9r6+8MAP0l0HvsZXfTQoA8tSgUtwWz0gj72X1XI SefMcH/L6s5trsWUA8yYEZ2gclSTF8MJMz4jafvrQXdxSERoUUUwQKOLivxls33mwiW0 FulIPyB+2lIzLpsjPOmZENiZp+K75tTBcXeUpOk8bHCU7QxyTpaKidlW4zG5jx2rjeLG r9Pm7xOhoME+XIC/uJ87EcFp5HOWoTfInghAIm85IG65bF5UyJQpZMVV2f6TBy0v9t9B +j3hwhS62Sr0YI1t2s4q680Qzzln/7fw6ocge5i5E8XZiY8Y1Fl0xWqY8F6nIUjksEDC Yuyg==
X-Gm-Message-State: ALoCoQnQwDDRgYclGEge8J0SEATpwk/DEGgg7cUFSIYgqHiIm+GVdartCRqs3eSbFT+yD6HVYSNt
X-Received: by 10.224.131.71 with SMTP id w7mr1994845qas.91.1406845156427; Thu, 31 Jul 2014 15:19:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 15:18:56 -0700 (PDT)
In-Reply-To: 
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com>  <53CFE322.5000508@ericsson.com> <53D03077.5080103@jitsi.org> <53D03578.5020301@ericsson.com> <53D036F1.8070504@jitsi.org> <53D11228.1080201@ericsson.com>       <53D12A3A.4080808@jitsi.org>   
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 1 Aug 2014 00:18:56 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/j9THyKvm29MHR7iuva0EMTOqp6s
Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic 
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 22:19:18 -0000

2014-07-31 21:11 GMT+02:00 Justin Uberti :
>> Correct me if I'm wrong, but a ICE-Lite server does not even need to
>> know about the ICE parameters it signals to the peer and it receives
>> form the peer (but just its own ufrag and passwd) and can determine
>> which is the selected pair by just inspecting the PRIORITY attribute
>> in received ICE requests with USE-CANDIDATE.
>>
>
> ICE Lite doesn't care about PRIORITY. Since you have to use regular
> nomination with ICE Lite, it just uses the single pair on which
> USE-CANDIDATE is set.

Yes, sorry, I was confused given that Firefox does not understand
ICE-lite and performs aggressive nomination even when the peer is
ICE-Lite :)


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 15:28:20 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897D91A01E5 for ; Thu, 31 Jul 2014 15:28:19 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atpP4KfVVTRx for ; Thu, 31 Jul 2014 15:28:18 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7EE1A01F7 for ; Thu, 31 Jul 2014 15:28:18 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id u57so3411329wes.38 for ; Thu, 31 Jul 2014 15:28:16 -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=H6X31yvz7B1Tud9PzpK2uRHsQzp+nkFTZkMzQ2S6MbY=; b=b+Y48WV8O/KnLHNti5lFQxnnF1POTe8xu1/oYoujbNzveFafW7m0M+EPfhNnWRv/x6 rbCgHg917WFDYQK111lHZD5pBQrZ/c891Xn6841aRckqpP/z0qLEmme6xBjHw4BjAxZd w3G+9v+Zwx+DMQ0lm4n/FMXuGKqZbkcqmxX/TThOhJCelbMlxe+gPScqwft8jN08B+Cs OZGpRlHjz4s9Q0Si3AyhO4wmflxP/N/tdDLl2qWHHpZkBHVydmKqCq6tj8UAgba3TQnp oAirS45oTsJAHJyHSBRrBEWW1/80VnjHiarcKP+jvHKzdioKAX7nWrT9cDhrZY9Yl4dR Dqyw==
MIME-Version: 1.0
X-Received: by 10.180.90.11 with SMTP id bs11mr802009wib.47.1406845696468; Thu, 31 Jul 2014 15:28:16 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Thu, 31 Jul 2014 15:28:16 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>      
Date: Thu, 31 Jul 2014 15:28:16 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3VA1daK8ZnAXRoSYy3Kq_bdSsY4
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 22:28:19 -0000

On 31 July 2014 15:17, I=C3=B1aki Baz Castillo  wrote:
> Yes, RFC 5245 allows media coming on non-nominated pair. But note that
> RFC 5245 knows nothing about DTLS. I strongly expect that RFC 5245
> would not allow that in case of DTLS-SRTP given that allowing DTLS
> coming from "any" source address adds too much complexity.


I disagree.  I think that the general idea that the flow endpoints
might change is inherent in ICE.

There is obviously a point at which it is expedient for a range of
reasons to nail things down to a single pair of addresses.  That
includes cleanup and some SDP interactions, along with some fun
middlebox issues.  So we have an ICE process that completes, but ICE
doesn't actually *need* to complete.  It's primary goal is to find
some way to get the packets through.


From nobody Thu Jul 31 15:40:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46241A0248 for ; Thu, 31 Jul 2014 15:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l0xJH7JwuKL for ; Thu, 31 Jul 2014 15:40:32 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875DF1A0201 for ; Thu, 31 Jul 2014 15:40:32 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id k15so3056903qaq.24 for ; Thu, 31 Jul 2014 15:40:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=s9wvUdkReiBB4lT0lFASnQuz9lj5sYtHf+ed8tRvwz8=; b=kJ/BwoEhqZb8wQteps37t2UKQ0OaLxS+amP/icdqLekaXtSQrOTpSvi1Peu4R6iy0R l84RjyQti+g9WIXxIyzILzMqfUM59wv2J5OjRH3HOJwPuUH1/4rZObgKe2Vq8ZeY9c4L bZT5mTVgDTD3RsYsFxH1Ntb+BJM+2vgxUBaVL35ipznJjQp62pAWnNEOakEsuRXYG5Eh tklS/+MR1bZ4aOUJwGGnD55l/af1+J/dAORRYx3eyVGKD9U74vuCIQI1vOcM6FzglrTM 9wwvOY4/TRYfII6drc6bz17GIPilaxmRyQXrzyjiDgpJpQfu7hCMNBU1MtHlpkHOGonl /gSg==
X-Gm-Message-State: ALoCoQmReEJmAOLP5GGOaOYWR/TZETv6iwNLjNZJsyKOUl50KXU1PVMxnSS8yKQpjOFRXa1sBkIs
X-Received: by 10.140.37.178 with SMTP id r47mr2064670qgr.59.1406846431835; Thu, 31 Jul 2014 15:40:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Thu, 31 Jul 2014 15:40:11 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>       
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 1 Aug 2014 00:40:11 +0200
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GCfVPAWB2KW6geLRkXRIiXq3gvo
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 22:40:33 -0000

2014-08-01 0:28 GMT+02:00 Martin Thomson :
> There is obviously a point at which it is expedient for a range of
> reasons to nail things down to a single pair of addresses.  That
> includes cleanup and some SDP interactions, along with some fun
> middlebox issues.  So we have an ICE process that completes, but ICE
> doesn't actually *need* to complete.  It's primary goal is to find
> some way to get the packets through.

If you allow "application data" coming from a source address which is
not the ICE nominated one then you must specify how such an
application data must behave when ICE is used to determine the network
path(s). As said before:

- For SRTP/SRTCP it is not a big deal given than you manage each RTP
packet separately (no matter where it comes from as long as it can be
decrypted with the previously negotiated keys).

- For DTLS it means complexity in the sense that a separate DTLS
session/context is required for each "transport".

- For any other network protocol new rules should be specified.

So I would like that ICE is used to determine a *single* and
*definitive* (at least until it is not restarted by STUN/ICE
procedures) network path. Life becomes easier and any kind of
application data can be easily carried once ICE completes (and
provides a *single* network path).


--=20
I=C3=B1aki Baz Castillo



From nobody Thu Jul 31 17:34:32 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6C1A0330 for ; Thu, 31 Jul 2014 17:34:31 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEPu2HC3bqxU for ; Thu, 31 Jul 2014 17:34:29 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3661A0312 for ; Thu, 31 Jul 2014 17:34:29 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so3519930wgh.33 for ; Thu, 31 Jul 2014 17:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JM/VvgkkC0Rrou6za0C8+7T+4HzdrJjqldQSy/5/e7U=; b=BBGxvAFb8LcsW0is+pq+XFbTKply9WwjnobwB3nKk5z3riIpOSe0nDGeSJhdWlo5id 3rdfohTk57tswfX27ywKAuXq77qe8PdKs2+ACrmROmaRD1C3se1Ef8LU5REKFLWnUcQN tSWCWRbbpYAajEf64nbQyXuj6u9fzoDbhZIWkQU50kOKj43xxLqd9xNxn7zMW4D8i+QS 4/55Z7eW8X3MMnlbJ7EZZDSLq3yvRgqOBdSsPFivIl3sPi9xV075V6m0vrQkriuVmSS+ j5lMn8e2sZ7CpUNrXQqikKvkD+xuOnvHCCdpVFtbVAKKE5+eMP7xRZNXW7+0/7zQ9b/8 Hq9Q==
MIME-Version: 1.0
X-Received: by 10.194.185.238 with SMTP id ff14mr2548001wjc.9.1406853268264; Thu, 31 Jul 2014 17:34:28 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Thu, 31 Jul 2014 17:34:28 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>        
Date: Thu, 31 Jul 2014 17:34:28 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/a_lt8g1WiTfV3Lg8kWQ35OPTdKo
Cc: Jonathan Lennox , mmusic 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Aug 2014 00:34:31 -0000

On 31 July 2014 15:40, I=C3=B1aki Baz Castillo  wrote:
> - For DTLS it means complexity in the sense that a separate DTLS
> session/context is required for each "transport".

Not really.  DTLS "says" that, but it doesn't functionally rely on a
stable 5-tuple in any real fashion.

Other protocols that rely on UDP are likely to be similar.  Reliance
in name only.


From nobody Thu Jul 31 18:07:13 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632131A0365 for ; Thu, 31 Jul 2014 18:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrTetjrWYKkq for ; Thu, 31 Jul 2014 18:07:08 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D222B1A0362 for ; Thu, 31 Jul 2014 18:07:00 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so5596941vcb.32 for ; Thu, 31 Jul 2014 18:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ibpJqreRWPIaY2Bj5axgMFRTLzJjWWz/27Q9P+9aJLE=; b=opDae2yd1QVClfd7yrJoMlr2C2vaDP7wKzxmgRzLnO+JB3o8aHZSvANwfvcibblxgy VgjThQjEwOAx6EtbQlYuyvq39/HMJUEoYMRDmS3Q4XjO4YJXEW9S8Tvunz8iPcFL/ARK XguStzSL6A6HPeEzsNY0vZKkTuVlNLTAo6qtiJ1Qin1F/qTAWDHusLJuoGMgUzzCo6nz kL/RTdiUz1apfqrT09UtLBLOSOMxRKkar3XkioOiQyoGuxC8TIjXOu40LtDqprm+D/q1 CZC0Jwr57+eLC7aUMUMdSdFsRPsJGkXszwjb76NDSbIp2e1Uy1xd48j8Jtk8TGjKj6iC /ULw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ibpJqreRWPIaY2Bj5axgMFRTLzJjWWz/27Q9P+9aJLE=; b=AhfO4WSLQG6UX/i7a/dI4v8E+Nav9+alPyX4BZ6yjWwajil+OlEPfvhsN9N6J7aLF5 G2wsu3Mq+i/rUEH44JykQBD+KlkssjxQuUxOFgUNwzwXgCXPBuK/KG2q5AjlT1l5SYRb PoRJc+yfmB941bfGcuRqZSmixmKpziNiAT6SFWOTERs+coyKQ1b8ndPd2WRLpw8VFUuo MfBzl0hqrArznf/lCABs3dG9OOATq7Dn8unDYUoO7JbskjuIrwWJh+ItDlqEiU4FGegb +wb0kVbQbwy8zURgPxi5AqjWRJ6YanVywmhkzSVYXvD+egne9u6IvnJ/BJb1IR/hNMt+ UY5g==
X-Gm-Message-State: ALoCoQk1A/mPrf/YbfyOvu1JCEkMEM+hnHNs61T7zkIspvt6RjQQvdw+tANWPWDKqDGXG46Qn2lQ
X-Received: by 10.52.28.9 with SMTP id x9mr2061422vdg.48.1406855219890; Thu, 31 Jul 2014 18:06:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Thu, 31 Jul 2014 18:06:38 -0700 (PDT)
In-Reply-To: 
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com>  <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com>  <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>    <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>         
From: Justin Uberti 
Date: Thu, 31 Jul 2014 18:06:38 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=20cf307abebda1e8f704ff87010c
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6ZUu_iiqRclVA7hiHARws1QwmIw
Cc: mmusic , Jonathan Lennox 
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Aug 2014 01:07:10 -0000

--20cf307abebda1e8f704ff87010c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 31, 2014 at 5:34 PM, Martin Thomson 
wrote:

> On 31 July 2014 15:40, I=C3=B1aki Baz Castillo  wrote:
> > - For DTLS it means complexity in the sense that a separate DTLS
> > session/context is required for each "transport".
>
> Not really.  DTLS "says" that, but it doesn't functionally rely on a
> stable 5-tuple in any real fashion.
>
> Other protocols that rely on UDP are likely to be similar.  Reliance
> in name only.


Think of ICE as a virtual socket. At higher layers, you don't know the
address of the remote endpoint or exactly how it will be contacted, but you
know if you send something on the virtual socket it will make it to the
remote endpoint. That's all DTLS needs to know.

--20cf307abebda1e8f704ff87010c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 31, 2014 at 5:34 PM, Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:



On 31 July 2014 15:40, I=C3=
=B1aki Baz Castillo <ibc@aliax.net&=
gt; wrote:



> - For DTLS it means complexity in the sense that a separate DTLS

> session/context is required for each "transport".




Not really. =C2=A0DTLS "says" that, but it doesn't func=
tionally rely on a

stable 5-tuple in any real fashion.



Other protocols that rely on UDP are likely to be similar. =C2=A0Reliance
in name only.

Think of ICE as a virtual soc=
ket. At higher layers, you don't know the address of the remote endpoin=
t or exactly how it will be contacted, but you know if you send something o=
n the virtual socket it will make it to the remote endpoint. That's all=
 DTLS needs to know.






--20cf307abebda1e8f704ff87010c--