From mmusic-bounces@ietf.org Mon Oct 02 19:05:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWqZ-000600-1w; Mon, 02 Oct 2006 19:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWqX-0005zW-LA for mmusic@ietf.org; Mon, 02 Oct 2006 19:05:13 -0400 Received: from smtp122.iad.emailsrvr.com ([207.97.245.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUWpA-0003wW-WA for mmusic@ietf.org; Mon, 02 Oct 2006 19:03:50 -0400 Received: from bremen (h66-38-133-13.gtconnect.net [66.38.133.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 5CD6B44C373 for ; Mon, 2 Oct 2006 19:03:48 -0400 (EDT) From: "Derek MacDonald" To: Date: Mon, 2 Oct 2006 16:03:47 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbmcmQ/Y11Rz7UTSZKepCRinPXZsAABI5Ow Message-Id: <20061002230348.5CD6B44C373@relay2.r2.iad.emailsrvr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Subject: [MMUSIC] Communicating Final ICE results X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1834543776==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1834543776== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C6E63C.58984C00" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C6E63C.58984C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Communicating ICE final results Using signaling to convey updated ice results has been contentious, to say the least. Another force on this is the desire for architectural separation between the signaling and media components of ice aware devices. An alternate approach would be: . The controlling endpoint would signal the completion of ice by sending a new stun request, ice-done, which also lists the local and remote candidates that have been selected. . The controlling endpoint MAY send an updated offer but this is based on deployment specific policy, and is not required for ice processing. This would allow: * devices to converge on symmetric RTP streams as quickly as possible, even in the earl-media fedex case * less SIP signaling traffic in the network, which is important to many deployments(ice doubles the invite transactions in a network) Non-IMS deployments will not usually require an updated o/a exchange but do want to agree on the ice result, and stop ice processing. In IMS networks an m/c line mismatch will not occur so the updated offer could be used to inform the network without issue. The additional cost of the ice-done transaction is minimal. -Derek ------=_NextPart_000_0014_01C6E63C.58984C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Communicating ICE final = results

 

Using signaling to convey updated ice results has = been contentious, to say the least.  Another force on this is the desire = for architectural separation between the signaling and media components of = ice aware devices. An alternate approach would = be:

 

•        = ;   The controlling endpoint would signal the completion of ice by sending a = new stun request, ice-done, which also lists the local and remote candidates = that have been selected.

•        = ;   The controlling endpoint MAY send an updated offer but this is based on deployment specific policy, and is not required for ice = processing.

 

This would allow:

 

  • devices to converge on symmetric RTP streams as quickly as possible, even in the = earl-media fedex case
  • less SIP signaling = traffic in the network, which is important to many deployments(ice doubles the = invite transactions in a network)

 

Non-IMS deployments will not usually require an = updated o/a exchange but do want to agree on the ice result, and stop ice = processing.  In IMS networks an m/c line mismatch will not occur so the updated offer = could be used to inform the network without issue.  The additional cost = of the ice-done transaction is minimal.

 

-Derek

 

 

 

------=_NextPart_000_0014_01C6E63C.58984C00-- --===============1834543776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1834543776==-- From mmusic-bounces@ietf.org Mon Oct 02 19:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXZ8-0000Zb-R9; Mon, 02 Oct 2006 19:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXZ6-0000ZW-UQ for mmusic@ietf.org; Mon, 02 Oct 2006 19:51:16 -0400 Received: from smtp152.iad.emailsrvr.com ([207.97.245.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUXZ5-0003eH-A1 for mmusic@ietf.org; Mon, 02 Oct 2006 19:51:16 -0400 Received: from bremen (h66-38-133-13.gtconnect.net [66.38.133.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay5.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id E6FC0172DE for ; Mon, 2 Oct 2006 19:51:14 -0400 (EDT) From: "Derek MacDonald" To: Date: Mon, 2 Oct 2006 16:51:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbmfaTKcVmLlyfTRA68UcbwI0EBWg== Message-Id: <20061002235114.E6FC0172DE@relay5.relay.iad.emailsrvr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [MMUSIC] Ice and open internet devices X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ice should be simplified for devices that are running on the open = internet or not behind a NAT from the perspective of other devices.=A0 The most = common example of this device is a PSTN gateway, although B2BUAs could be = deployed in the =91same place=92.=A0=A0 I do not know of any ice-aware PSTN = gateways that have been deployed, and I suspect this is due to the implementation cost = of ice.=A0=20 Desired simplifications 1. stateless processing, or a much simplified ice state machine=20 2. should never be the deciding endpoint in the ice algorithm=20 3. limited communication between the signaling component and media = component Proposed Solution This type of device, which I will refer to as a GW for convenience, will only ever have one candidate.=A0 The candidate will be the global IP = address of the GW, which will always be the same as the m/c line; so candidate gathering is eliminated. =A0The GW will not have a NAT/FW in front of = it, so it will not have to send STUN requests to open NAT/FW permissions.=A0 = Local permissions would have to be opened based on the remote SDP, but GW = devices that wish to enforce must already do this for the remote m/c line.=A0 A = GW does not prefer any candidate, as it only has one, so it has no = motivation to prioritize candidates. This leads us to: 1. a GW will only perform triggered checks=20 2. for each component the GW will send media to the last successful triggered check, unless informed otherwise by the remote party=20 3. the GW is never the controlling endpoint, and will announce this in = SDP (see later)=20 The triggered check is necessary because the remote (non GW) endpoint = could be behind a NAT/FW which allows outgoing UDP packets but blocks incoming = UDP packets. =A0#2 is the same as we are proposing for normal ice devices, = which will send to the first validated candidate for a component. =A0A new SDP attribute, ice-passive, would be used for #3.=A0 Any GW that advertises ice-passive must be in the open region of the topology, so it will not = need ice to communicate with another GW which offers ice-passive.=A0 So, if = both devices advertise ice-passive, no ice discovery will take place.=A0 = Keepalives should not be necessary, but if they are desired, ice keepalives will be used.=A0 If no side indicates ice-passive, the offerer is the = controlling endpoint, as in ice-10. If the controlling endpoint wishes the ice-passive endpoint to switch to another candidate, it can accomplish this by sending an ice-check which = will cause the GW to send a triggered check and change candidates if the triggered check succeeds. This approach will allow a very light implementation of ICE for this = type of device.=A0 It requires very little state (one table of permissions, one = table of validated candidates from triggered checks) and very little = communication between the signaling and media components.=A0 It eliminates candidate gathering, priority processing and the ice-check state machine. -Derek _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 02 20:10:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXrm-0007GW-5v; Mon, 02 Oct 2006 20:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXrk-0007Fw-3k for mmusic@ietf.org; Mon, 02 Oct 2006 20:10:32 -0400 Received: from smtp122.iad.emailsrvr.com ([207.97.245.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUWoG-0003ra-Up for mmusic@ietf.org; Mon, 02 Oct 2006 19:02:54 -0400 Received: from bremen (h66-38-133-13.gtconnect.net [66.38.133.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 3474044C378 for ; Mon, 2 Oct 2006 19:02:52 -0400 (EDT) From: "Derek MacDonald" To: Date: Mon, 2 Oct 2006 16:02:50 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbmb6OGpnBY8asET96DdJcrX6fAhQABlUbg Message-Id: <20061002230252.3474044C378@relay2.r2.iad.emailsrvr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Subject: [MMUSIC] ICE and open internet devices X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1683260378==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1683260378== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C6E63C.3721B520" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C6E63C.3721B520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ice should be simplified for devices that are running on the open internet or not behind a NAT from the perspective of other devices. The most common example of this device is a PSTN gateway, although B2BUAs could be deployed in the 'same place'. I do not know of any ice-aware PSTN gateways that have been deployed, and I suspect this is due to the implementation cost of ice. Desired simplifications 1. stateless processing, or a much simplified ice state machine 2. should never be the deciding endpoint in the ice algorithm 3. limited communication between the signaling component and media component Proposed Solution This type of device, which I will refer to as a GW for convenience, will only ever have one candidate. The candidate will be the global IP address of the GW, which will always be the same as the m/c line; so candidate gathering is eliminated. The GW will not have a NAT/FW in front of it, so it will not have to send STUN requests to open NAT/FW permissions. Local permissions would have to be opened based on the remote SDP, but GW devices that wish to enforce must already do this for the remote m/c line. A GW does not prefer any candidate, as it only has one, so it has no motivation to prioritize candidates. This leads us to: 1. a GW will only perform triggered checks 2. for each component the GW will send media to the last successful triggered check, unless informed otherwise by the remote party 3. the GW is never the controlling endpoint, and will announce this in SDP (see later) The triggered check is necessary because the remote (non GW) endpoint could be behind a NAT/FW which allows outgoing UDP packets but blocks incoming UDP packets. #2 is the same as we are proposing for normal ice devices, which will send to the first validated candidate for a component. A new SDP attribute, ice-passive, would be used for #3. Any GW that advertises ice-passive must be in the open region of the topology, so it will not need ice to communicate with another GW which offers ice-passive. So, if both devices advertise ice-passive, no ice discovery will take place. Keepalives should not be necessary, but if they are desired, ice keepalives will be used. If no side indicates ice-passive, the offerer is the controlling endpoint, as in ice-10. If the controlling endpoint wishes the ice-passive endpoint to switch to another candidate, it can accomplish this by sending an ice-check which will cause the GW to send a triggered check and change candidates if the triggered check succeeds. This approach will allow a very light implementation of ICE for this type of device. It requires very little state (one table of permissions, one table of validated candidates from triggered checks) and very little communication between the signaling and media components. It eliminates candidate gathering, priority processing and the ice-check state machine. -Derek ------=_NextPart_000_0010_01C6E63C.3721B520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ice should be simplified for devices that are running = on the open internet or not behind a NAT from the perspective of other = devices.  The most common example of this device is a PSTN gateway, although = B2BUAs could be deployed in the ‘same place’.   I do not know = of any ice-aware PSTN gateways that have been deployed, and I suspect this is = due to the implementation cost of ice. 

 

Desired simplifications

 

  1. stateless processing, = or a much simplified ice state machine
  2. should never be the = deciding endpoint in the ice algorithm
  3. limited communication = between the signaling component and media = component

 

Proposed Solution

 

This type of device, which I will refer to as a GW = for convenience, will only ever have one candidate.  The candidate will = be the global IP address of the GW, which will always be the same as the m/c = line; so candidate gathering is eliminated.  The GW will not have a NAT/FW = in front of it, so it will not have to send STUN requests to open NAT/FW permissions.  Local permissions would have to be opened based on = the remote SDP, but GW devices that wish to enforce must already do this for = the remote m/c line.  A GW does not prefer any candidate, as it only = has one, so it has no motivation to prioritize candidates. This leads us = to:

 

  1. a GW will only perform triggered checks
  2. for each component the = GW will send media to the last successful triggered check, unless informed otherwise by the remote party
  3. the GW is never the = controlling endpoint, and will announce this in SDP (see = later)

 

The triggered check is necessary because the remote = (non GW) endpoint could be behind a NAT/FW which allows outgoing UDP packets but = blocks incoming UDP packets.  #2 is the same as we are proposing for = normal ice devices, which will send to the first validated candidate for a = component.  A new SDP attribute, ice-passive, would be used for #3.  Any = GW that advertises ice-passive must be in the open region of the topology, so it = will not need ice to communicate with another GW which offers = ice-passive.  So, if both devices advertise ice-passive, no ice discovery will take = place.  Keepalives should not be necessary, but if they are desired, ice = keepalives will be used.  If no side indicates ice-passive, the offerer is the controlling endpoint, as in ice-10.

 

If the controlling endpoint wishes the ice-passive = endpoint to switch to another candidate, it can accomplish this by sending an = ice-check which will cause the GW to send a triggered check and change candidates = if the triggered check succeeds.

 

This approach will allow a very light implementation = of ICE for this type of device.  It requires very little state (one table = of permissions, one table of validated candidates from triggered checks) = and very little communication between the signaling and media components.  = It eliminates candidate gathering, priority processing and the ice-check state = machine.

 

-Derek

------=_NextPart_000_0010_01C6E63C.3721B520-- --===============1683260378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1683260378==-- From mmusic-bounces@ietf.org Mon Oct 02 20:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXyR-0004Av-8d; Mon, 02 Oct 2006 20:17:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXyP-0004Ai-Uc for mmusic@ietf.org; Mon, 02 Oct 2006 20:17:25 -0400 Received: from smtp152.iad.emailsrvr.com ([207.97.245.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUXyP-0005cf-FF for mmusic@ietf.org; Mon, 02 Oct 2006 20:17:25 -0400 Received: from bremen (h66-38-133-13.gtconnect.net [66.38.133.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay5.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id AD2391874B for ; Mon, 2 Oct 2006 20:17:24 -0400 (EDT) From: "Derek MacDonald" To: Subject: RE: [MMUSIC] ICE and open internet devices--second is a repost; mmusic or my mailserver is glitchy Date: Mon, 2 Oct 2006 17:17:23 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbmb6OGpnBY8asET96DdJcrX6fAhQABlUbgAALN1ZA= In-Reply-To: <20061002230252.3474044C378@relay2.r2.iad.emailsrvr.com> Message-Id: <20061003001724.AD2391874B@relay5.relay.iad.emailsrvr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484634301==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0484634301== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C6E646.A0EF3BD0" This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C6E646.A0EF3BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: Derek MacDonald [mailto:derek@counterpath.com] Sent: Monday, October 02, 2006 4:03 PM To: mmusic@ietf.org Subject: [MMUSIC] ICE and open internet devices Ice should be simplified for devices that are running on the open internet or not behind a NAT from the perspective of other devices. The most common example of this device is a PSTN gateway, although B2BUAs could be deployed in the 'same place'. I do not know of any ice-aware PSTN gateways that have been deployed, and I suspect this is due to the implementation cost of ice. Desired simplifications 1. stateless processing, or a much simplified ice state machine 2. should never be the deciding endpoint in the ice algorithm 3. limited communication between the signaling component and media component Proposed Solution This type of device, which I will refer to as a GW for convenience, will only ever have one candidate. The candidate will be the global IP address of the GW, which will always be the same as the m/c line; so candidate gathering is eliminated. The GW will not have a NAT/FW in front of it, so it will not have to send STUN requests to open NAT/FW permissions. Local permissions would have to be opened based on the remote SDP, but GW devices that wish to enforce must already do this for the remote m/c line. A GW does not prefer any candidate, as it only has one, so it has no motivation to prioritize candidates. This leads us to: 1. a GW will only perform triggered checks 2. for each component the GW will send media to the last successful triggered check, unless informed otherwise by the remote party 3. the GW is never the controlling endpoint, and will announce this in SDP (see later) The triggered check is necessary because the remote (non GW) endpoint could be behind a NAT/FW which allows outgoing UDP packets but blocks incoming UDP packets. #2 is the same as we are proposing for normal ice devices, which will send to the first validated candidate for a component. A new SDP attribute, ice-passive, would be used for #3. Any GW that advertises ice-passive must be in the open region of the topology, so it will not need ice to communicate with another GW which offers ice-passive. So, if both devices advertise ice-passive, no ice discovery will take place. Keepalives should not be necessary, but if they are desired, ice keepalives will be used. If no side indicates ice-passive, the offerer is the controlling endpoint, as in ice-10. If the controlling endpoint wishes the ice-passive endpoint to switch to another candidate, it can accomplish this by sending an ice-check which will cause the GW to send a triggered check and change candidates if the triggered check succeeds. This approach will allow a very light implementation of ICE for this type of device. It requires very little state (one table of permissions, one table of validated candidates from triggered checks) and very little communication between the signaling and media components. It eliminates candidate gathering, priority processing and the ice-check state machine. -Derek ------=_NextPart_000_002B_01C6E646.A0EF3BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Derek = MacDonald [mailto:derek@counterpath.com]
Sent: Monday, October 02, = 2006 4:03 PM
To: mmusic@ietf.org
Subject: [MMUSIC] ICE and = open internet devices

 

Ice should be simplified for devices that are running = on the open internet or not behind a NAT from the perspective of other = devices.  The most common example of this device is a PSTN gateway, although = B2BUAs could be deployed in the ‘same place’.   I do not know = of any ice-aware PSTN gateways that have been deployed, and I suspect this is = due to the implementation cost of ice. 

 

Desired simplifications

 

  1. stateless processing, = or a much simplified ice state machine
  2. should never be the = deciding endpoint in the ice algorithm
  3. limited communication = between the signaling component and media = component

 

Proposed Solution

 

This type of device, which I will refer to as a GW = for convenience, will only ever have one candidate.  The candidate will = be the global IP address of the GW, which will always be the same as the m/c = line; so candidate gathering is eliminated.  The GW will not have a NAT/FW in front of = it, so it will not have to send STUN requests to open NAT/FW permissions.  = Local permissions would have to be opened based on the remote SDP, but GW = devices that wish to enforce must already do this for the remote m/c line.  = A GW does not prefer any candidate, as it only has one, so it has no = motivation to prioritize candidates. This leads us to:

 

  1. a GW will only perform triggered checks
  2. for each component the = GW will send media to the last successful triggered check, unless informed otherwise by the remote party
  3. the GW is never the = controlling endpoint, and will announce this in SDP (see = later)

 

The triggered check is necessary because the remote = (non GW) endpoint could be behind a NAT/FW which allows outgoing UDP packets but = blocks incoming UDP packets.  #2 is the same as we are proposing for = normal ice devices, which will send to the first validated candidate for a = component.  A new SDP attribute, ice-passive, would be used for #3.  Any = GW that advertises ice-passive must be in the open region of the topology, so it = will not need ice to communicate with another GW which offers = ice-passive.  So, if both devices advertise ice-passive, no ice discovery will take = place.  Keepalives should not be necessary, but if they are desired, ice = keepalives will be used.  If no side indicates ice-passive, the offerer is the controlling endpoint, as in ice-10.

 

If the controlling endpoint wishes the ice-passive = endpoint to switch to another candidate, it can accomplish this by sending an = ice-check which will cause the GW to send a triggered check and change candidates = if the triggered check succeeds.

 

This approach will allow a very light implementation = of ICE for this type of device.  It requires very little state (one table = of permissions, one table of validated candidates from triggered checks) = and very little communication between the signaling and media components.  = It eliminates candidate gathering, priority processing and the ice-check = state machine.

 

-Derek

------=_NextPart_000_002B_01C6E646.A0EF3BD0-- --===============0484634301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0484634301==-- From mmusic-bounces@ietf.org Tue Oct 03 04:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfZB-00045d-U2; Tue, 03 Oct 2006 04:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfZA-00043V-Tt for mmusic@ietf.org; Tue, 03 Oct 2006 04:23:52 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfZ9-0006lE-Iq for mmusic@ietf.org; Tue, 03 Oct 2006 04:23:52 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:21:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] About the VAD in SDP negotiation Date: Tue, 3 Oct 2006 09:21:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] About the VAD in SDP negotiation Thread-Index: AcbiBw3fPjTdoIuyRpeQD1G6XhoQOwEtM+8g From: "SOLLAUD Aurelien RD-TECH-LAN" To: X-OriginalArrivalTime: 03 Oct 2006 07:21:09.0431 (UTC) FILETIME=[7F852470:01C6E6BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1439650764==" Errors-To: mmusic-bounces@ietf.org --===============1439650764== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkNCkl0IGlzIGNvZGVjLWRlcGVuZGFudC4gVGhlcmUgaXMgbm8gZ2xvYmFsIFZBRCBhdHRyaWJ1 dGUgaW4gU0RQLg0KVGhlIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIG9mIGFuIGF1ZGlvIGNvZGVj IG1heSBkZWZpbmUgYSBWQUQtcmVsYXRlZCBwYXJhbWV0ZXIgKGUuZy4gJ2FubmV4YicgZm9yIGF1 ZGlvL0c3MjkpLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCglEZSA6 IGFsYW4gW21haWx0bzphbGFuX3poYW5nQHNoLmFza2V5LmNvbS50d10gDQoJRW52b3nDqSA6IG1l cmNyZWRpIDI3IHNlcHRlbWJyZSAyMDA2IDA5OjI4DQoJw4AgOiBtbXVzaWMNCglPYmpldCA6IFtN TVVTSUNdIEFib3V0IHRoZSBWQUQgaW4gU0RQIG5lZ290aWF0aW9uDQoJDQoJDQoJCURlYXIgbW11 c2ljLXJlcXVlc3QgOg0KCSANCgnjgIDjgIBIb3cgdG8gZW5hYmxlL2Rpc2FibGUgVkFEIGluIHNk cCA/IA0KCSANCgkyMDA2LTA5LTI3DQoJPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0gDQoJQmVzdCBSZWdhcmRzIGZyb20gQWxhbiBvbiAyMDA1LzYvMi4NCglNU046bGFvZXIyM0Bo b3RtYWlsLmNvbQ0KCVRlbCA6MDIxLTUwODA4MTg2LTEwOQ0KCU0gOiAxMzU2NDAyMDA2Ng0KCUNv bXBhbnkgOlZvSVAuQXNrZXkNCgkgDQoJ5Zyo5oiR55qE55y86YeM77yM5L2g5aaC5qKm5bm777yB DQoJPT09PT09PT09PT09PT09PT09PT09PT09PT09PeOAgA0KCSANCgkJCQ0KDQo= --===============1439650764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1439650764==-- From mmusic-bounces@ietf.org Tue Oct 03 06:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhkZ-00054h-SA; Tue, 03 Oct 2006 06:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhkY-00054b-Ta for mmusic@ietf.org; Tue, 03 Oct 2006 06:43:46 -0400 Received: from eastmail1.ntt-east.co.jp ([202.229.5.44] helo=evx1.enoc.east.ntt.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhkX-0006t0-BM for mmusic@ietf.org; Tue, 03 Oct 2006 06:43:46 -0400 Received: from emix2.enoc.east.ntt.co.jp by evx1.enoc.east.ntt.co.jp with ESMTP id k93AhhY25260; Tue, 3 Oct 2006 19:43:43 +0900 (JST) Received: from cip9.noc.east.ntt.co.jp by emix2.enoc.east.ntt.co.jp with ESMTP id k93AhhN07235; Tue, 3 Oct 2006 19:43:43 +0900 (JST) Received: from [10.8.52.35] ([10.8.52.35]) by cip9.noc.east.ntt.co.jp (MOS 3.4.6-GR) with ESMTP id CLI74234; Tue, 3 Oct 2006 19:43:42 +0900 (JST) Date: Tue, 03 Oct 2006 19:46:12 +0900 From: j.koshiko@east.ntt.co.jp To: mmusic@ietf.org Message-Id: <20061003192708.3D31.J.KOSHIKO@east.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [ja] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [MMUSIC] Question about bundling SDP m=lines X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Folks, I hope I would like to ask an question on SDP offer/answer model. Imagine the case where the offerer initiates a video call. Is there any parameter which indicates offerer doesn't want answerer to answer an SDP with video medium only, without an audio medium? An SDP offer for video call includes two m=lines, m=audio and m=video. According to RFC4566/3264, the answerer may read each m=line independently, and may return a SDP answer with port 0 in either of the two m=lines. Session may be established with video only, without audio, which is not the caller's intention. offerer answerer | | | INVITE (m=video & m=audio) | |--------------------------------->| | 200 OK (m=video & m=audio port 0)| |<---------------------------------| | RTP session (video only) | |<================================>| | | To avoid this, offerer have to tell the answerer that m=audio and m=video are bundled and that it doesn't want to establish with either of the media. I hope I would like to ask you how to express the offerer's intention. I guess this should be achived by m=line group attribute defined by RFC3388, because it says in Chapter 1 that "expression of how different media streams within a session description relate to each other." I guess that this would make it possible to express that m=audio and m=video are bundled. What the "semantics" field should be set, if I use a group attribute in this way? Four values, "LS", "FID", "SRF" and "ANAT" are registered on IANA, but none of them seems to be intended to influence UA's offer/answer. Is a new semantics parameter needed to meed the requirement? Please let me know your advice. Does this topic match to another mailing list more? I apologize if this subject is off-topic for this mailing list. Thank you, Jun Koshiko _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 09:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkHr-0003mB-NF; Tue, 03 Oct 2006 09:26:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkHq-0003m4-Gi for mmusic@ietf.org; Tue, 03 Oct 2006 09:26:18 -0400 Received: from mx4-1.spamtrap.magma.ca ([209.217.78.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkHo-0003Ou-4b for mmusic@ietf.org; Tue, 03 Oct 2006 09:26:18 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx4-1.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id k93DQCOT023448; Tue, 3 Oct 2006 09:26:13 -0400 Received: from [10.10.80.117] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id k93DQBjr005531 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 3 Oct 2006 09:26:12 -0400 In-Reply-To: <20061002235114.E6FC0172DE@relay5.relay.iad.emailsrvr.com> References: <20061002235114.E6FC0172DE@relay5.relay.iad.emailsrvr.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 09:26:09 -0400 To: Derek MacDonald X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Derek: How does a device determine that it is on the open Internet? Does it look at its IP address? This mostly works, but there was a recent case in Italy where this test would have failed. And, BTW, a PSTN gateway does not have to be on the open Internet. With ICE, a PSTN gateway can easily be behind a NAT. - Philip On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > Ice should be simplified for devices that are running on the open =20 > internet > or not behind a NAT from the perspective of other devices. The =20 > most common > example of this device is a PSTN gateway, although B2BUAs could be =20 > deployed > in the =91same place=92. I do not know of any ice-aware PSTN = gateways =20 > that > have been deployed, and I suspect this is due to the implementation =20= > cost of > ice. > > Desired simplifications > > 1. stateless processing, or a much simplified ice state machine > 2. should never be the deciding endpoint in the ice algorithm > 3. limited communication between the signaling component and media =20 > component > > > Proposed Solution > > This type of device, which I will refer to as a GW for convenience, =20= > will > only ever have one candidate. The candidate will be the global IP =20 > address > of the GW, which will always be the same as the m/c line; so candidate > gathering is eliminated. The GW will not have a NAT/FW in front of =20= > it, so > it will not have to send STUN requests to open NAT/FW permissions. =20= > Local > permissions would have to be opened based on the remote SDP, but GW =20= > devices > that wish to enforce must already do this for the remote m/c line. =20= > A GW > does not prefer any candidate, as it only has one, so it has no =20 > motivation > to prioritize candidates. This leads us to: > > 1. a GW will only perform triggered checks > 2. for each component the GW will send media to the last successful > triggered check, unless informed otherwise by the remote party > 3. the GW is never the controlling endpoint, and will announce this =20= > in SDP > (see later) > > The triggered check is necessary because the remote (non GW) =20 > endpoint could > be behind a NAT/FW which allows outgoing UDP packets but blocks =20 > incoming UDP > packets. #2 is the same as we are proposing for normal ice =20 > devices, which > will send to the first validated candidate for a component. A new SDP > attribute, ice-passive, would be used for #3. Any GW that advertises > ice-passive must be in the open region of the topology, so it will =20 > not need > ice to communicate with another GW which offers ice-passive. So, =20 > if both > devices advertise ice-passive, no ice discovery will take place. =20 > Keepalives > should not be necessary, but if they are desired, ice keepalives =20 > will be > used. If no side indicates ice-passive, the offerer is the =20 > controlling > endpoint, as in ice-10. > > If the controlling endpoint wishes the ice-passive endpoint to =20 > switch to > another candidate, it can accomplish this by sending an ice-check =20 > which will > cause the GW to send a triggered check and change candidates if the > triggered check succeeds. > > This approach will allow a very light implementation of ICE for =20 > this type of > device. It requires very little state (one table of permissions, =20 > one table > of validated candidates from triggered checks) and very little =20 > communication > between the signaling and media components. It eliminates candidate > gathering, priority processing and the ice-check state machine. > > -Derek > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 09:37:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkSn-0001wq-Ek; Tue, 03 Oct 2006 09:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkSm-0001wk-7F for mmusic@ietf.org; Tue, 03 Oct 2006 09:37:36 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkSf-00058r-H6 for mmusic@ietf.org; Tue, 03 Oct 2006 09:37:36 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6F1B68E0001; Tue, 3 Oct 2006 15:37:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 15:37:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 15:37:16 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403D4CBCC@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Ice and open internet devices Thread-Index: Acbm8B52yqO4LNj/QUK1Y52alxXdhAAAEVgA From: "Christer Holmberg \(JO/LMF\)" To: "Philip Matthews" , "Derek MacDonald" X-OriginalArrivalTime: 03 Oct 2006 13:37:18.0140 (UTC) FILETIME=[0B84D7C0:01C6E6F1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I think Derek is bringing up some interesting issues. How a device "knows" whether it's on the "open internet" or not can of course be discussed, but there may be scenarios where the device doesn't have any STUN servers configured - ie it is not able to retrieve candidates no matter what internet it's located on. Now, in that case, if the device still supports ICE, I think it's good to include a candidate for the c/m-line, in order to allow the remote entity (which may be located behind a NAT, and have access to STUN servers), to use ICE. Also, if the global address is chosen for the session, the question is (as Derek said) whether we need STUN keep-alives. We don't need it in order to keep NAT bindings open, but do we need it in order to provide connectivity checks? Or, can we assume that the connectivity will be there? Regards, Christer =20 > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > Sent: 3. lokakuuta 2006 16:26 > To: Derek MacDonald > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Ice and open internet devices >=20 > Derek: >=20 > How does a device determine that it is on the open Internet? > Does it look at its IP address? This mostly works, but there=20 > was a recent case in Italy where this test would have failed. >=20 > And, BTW, a PSTN gateway does not have to be on the open Internet. > With ICE, a PSTN gateway can easily be behind a NAT. >=20 > - Philip >=20 > On 2-Oct-06, at 19:51 , Derek MacDonald wrote: >=20 > > Ice should be simplified for devices that are running on the open=20 > > internet or not behind a NAT from the perspective of other=20 > devices. =20 > > The most common example of this device is a PSTN gateway, although=20 > > B2BUAs could be deployed > > in the 'same place'. I do not know of any ice-aware PSTN=20 > gateways =20 > > that > > have been deployed, and I suspect this is due to the implementation=20 > > cost of ice. > > > > Desired simplifications > > > > 1. stateless processing, or a much simplified ice state machine 2.=20 > > should never be the deciding endpoint in the ice algorithm=20 > 3. limited=20 > > communication between the signaling component and media component > > > > > > Proposed Solution > > > > This type of device, which I will refer to as a GW for=20 > convenience, =20 > > will > > only ever have one candidate. The candidate will be the global IP =20 > > address > > of the GW, which will always be the same as the m/c line;=20 > so candidate > > gathering is eliminated. The GW will not have a NAT/FW in=20 > front of =20 > > it, so > > it will not have to send STUN requests to open NAT/FW=20 > permissions. =20 > > Local > > permissions would have to be opened based on the remote=20 > SDP, but GW =20 > > devices > > that wish to enforce must already do this for the remote=20 > m/c line. =20 > > A GW > > does not prefer any candidate, as it only has one, so it has no =20 > > motivation > > to prioritize candidates. This leads us to: > > > > 1. a GW will only perform triggered checks > > 2. for each component the GW will send media to the last successful > > triggered check, unless informed otherwise by the remote party > > 3. the GW is never the controlling endpoint, and will=20 > announce this =20 > > in SDP > > (see later) > > > > The triggered check is necessary because the remote (non GW) =20 > > endpoint could > > be behind a NAT/FW which allows outgoing UDP packets but blocks =20 > > incoming UDP > > packets. #2 is the same as we are proposing for normal ice =20 > > devices, which > > will send to the first validated candidate for a component.=20 > A new SDP > > attribute, ice-passive, would be used for #3. Any GW that=20 > advertises > > ice-passive must be in the open region of the topology, so it will =20 > > not need > > ice to communicate with another GW which offers ice-passive. So, =20 > > if both > > devices advertise ice-passive, no ice discovery will take place. =20 > > Keepalives > > should not be necessary, but if they are desired, ice keepalives =20 > > will be > > used. If no side indicates ice-passive, the offerer is the =20 > > controlling > > endpoint, as in ice-10. > > > > If the controlling endpoint wishes the ice-passive endpoint to =20 > > switch to > > another candidate, it can accomplish this by sending an ice-check =20 > > which will > > cause the GW to send a triggered check and change candidates if the > > triggered check succeeds. > > > > This approach will allow a very light implementation of ICE for =20 > > this type of > > device. It requires very little state (one table of permissions, =20 > > one table > > of validated candidates from triggered checks) and very little =20 > > communication > > between the signaling and media components. It eliminates candidate > > gathering, priority processing and the ice-check state machine. > > > > -Derek > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 09:55:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkjq-0004EA-Gq; Tue, 03 Oct 2006 09:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkhz-0002zf-Hy for mmusic@ietf.org; Tue, 03 Oct 2006 09:53:19 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkYf-0006Db-Rn for mmusic@ietf.org; Tue, 03 Oct 2006 09:43:43 -0400 Received: by wr-out-0506.google.com with SMTP id i32so474260wra for ; Tue, 03 Oct 2006 06:43:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k3tfEPFqL6qwNdSnNZiKLkVRaq2E/El5F0mjbIjX6c7kwxnxY2NZi7L/UqUivRVrBkqN9NUAuKd7Wac2MISNkKp/r+xN0gW9sY7ryHg/P882Qv7iJSAbbfScSofUTxh6iO0O0rPX7H4XM/trcuWL41OKiDZvsQIfDCpfwjjE3tY= Received: by 10.90.72.10 with SMTP id u10mr3420462aga; Tue, 03 Oct 2006 06:43:41 -0700 (PDT) Received: by 10.90.97.8 with HTTP; Tue, 3 Oct 2006 06:43:41 -0700 (PDT) Message-ID: <1fc32c8f0610030643o45e2ea9dj43762ca8597ac222@mail.gmail.com> Date: Tue, 3 Oct 2006 09:43:41 -0400 From: "Michael Slavitch" To: "Philip Matthews" Subject: Re: [MMUSIC] Ice and open internet devices In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061002235114.E6FC0172DE@relay5.relay.iad.emailsrvr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org In many situations that would fail. An assumption that a public IP address is not behind some kind of firewall, walled garden or gateway is a false assumption. Philip is entirely correct about a PSTN gateway supporting ICE operating behind a NAT. Same goes for any SIP registrar. On 10/3/06, Philip Matthews wrote: > Derek: > > How does a device determine that it is on the open Internet? > Does it look at its IP address? This mostly works, > but there was a recent case in Italy where this test would have failed. > > And, BTW, a PSTN gateway does not have to be on the open Internet. > With ICE, a PSTN gateway can easily be behind a NAT. > > - Philip > > On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > > > Ice should be simplified for devices that are running on the open > > internet > > or not behind a NAT from the perspective of other devices. The > > most common > > example of this device is a PSTN gateway, although B2BUAs could be > > deployed > > in the 'same place'. I do not know of any ice-aware PSTN gateways > > that > > have been deployed, and I suspect this is due to the implementation > > cost of > > ice. > > > > Desired simplifications > > > > 1. stateless processing, or a much simplified ice state machine > > 2. should never be the deciding endpoint in the ice algorithm > > 3. limited communication between the signaling component and media > > component > > > > > > Proposed Solution > > > > This type of device, which I will refer to as a GW for convenience, > > will > > only ever have one candidate. The candidate will be the global IP > > address > > of the GW, which will always be the same as the m/c line; so candidate > > gathering is eliminated. The GW will not have a NAT/FW in front of > > it, so > > it will not have to send STUN requests to open NAT/FW permissions. > > Local > > permissions would have to be opened based on the remote SDP, but GW > > devices > > that wish to enforce must already do this for the remote m/c line. > > A GW > > does not prefer any candidate, as it only has one, so it has no > > motivation > > to prioritize candidates. This leads us to: > > > > 1. a GW will only perform triggered checks > > 2. for each component the GW will send media to the last successful > > triggered check, unless informed otherwise by the remote party > > 3. the GW is never the controlling endpoint, and will announce this > > in SDP > > (see later) > > > > The triggered check is necessary because the remote (non GW) > > endpoint could > > be behind a NAT/FW which allows outgoing UDP packets but blocks > > incoming UDP > > packets. #2 is the same as we are proposing for normal ice > > devices, which > > will send to the first validated candidate for a component. A new SDP > > attribute, ice-passive, would be used for #3. Any GW that advertises > > ice-passive must be in the open region of the topology, so it will > > not need > > ice to communicate with another GW which offers ice-passive. So, > > if both > > devices advertise ice-passive, no ice discovery will take place. > > Keepalives > > should not be necessary, but if they are desired, ice keepalives > > will be > > used. If no side indicates ice-passive, the offerer is the > > controlling > > endpoint, as in ice-10. > > > > If the controlling endpoint wishes the ice-passive endpoint to > > switch to > > another candidate, it can accomplish this by sending an ice-check > > which will > > cause the GW to send a triggered check and change candidates if the > > triggered check succeeds. > > > > This approach will allow a very light implementation of ICE for > > this type of > > device. It requires very little state (one table of permissions, > > one table > > of validated candidates from triggered checks) and very little > > communication > > between the signaling and media components. It eliminates candidate > > gathering, priority processing and the ice-check state machine. > > > > -Derek > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 11:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmai-00022A-34; Tue, 03 Oct 2006 11:53:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmah-00021Q-CX for mmusic@ietf.org; Tue, 03 Oct 2006 11:53:55 -0400 Received: from smtp142.iad.emailsrvr.com ([207.97.245.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmae-00035l-Vv for mmusic@ietf.org; Tue, 03 Oct 2006 11:53:55 -0400 Received: from counterpath.com (webmail8.r4.iad.mlsrvr.com [192.168.1.83]) by relay4.r5.iad.mlsrvr.com (SMTP Server) with ESMTP id 96290C240; Tue, 3 Oct 2006 11:53:42 -0400 (EDT) Received: from ([10.238.10.70]) (proxying for 206.116.29.3) (Webmail authenticated user derek@counterpath.com, derek@counterpath.com); by webmail.counterpath.com with HTTP; Tue, 3 Oct 2006 11:53:42 -0400 (EDT) Message-ID: <57091.10.238.10.70.1159890822.webmail@10.238.10.70> Date: Tue, 3 Oct 2006 11:53:42 -0400 (EDT) Subject: Re: [MMUSIC] Ice and open internet devices From: derek@counterpath.com To: "Michael Slavitch" X-Mailer: Webmail.us v5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: derek@counterpath.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org A device would not determine that it is on the open internet by discovery= ; it would use configuration which is set at delpoyment time. If a PSTN gateway is behind a NAT, it would have to implement full ice. = The purpose of 'ice-passive' is to simplify the implementation of devices= that are not behind a NAT. -Derek Michael Slavitch said: > In many situations that would fail. An assumption that a public IP > address is not behind some kind of firewall, walled garden or gateway > is a false assumption. >=20 > Philip is entirely correct about a PSTN gateway supporting ICE > operating behind a NAT. Same goes for any SIP registrar. >=20 >=20 > On 10/3/06, Philip Matthews wrote: >> Derek: >> >> How does a device determine that it is on the open Internet? >> Does it look at its IP address? This mostly works, >> but there was a recent case in Italy where this test would have failed= . >> >> And, BTW, a PSTN gateway does not have to be on the open Internet. >> With ICE, a PSTN gateway can easily be behind a NAT. >> >> - Philip >> >> On 2-Oct-06, at 19:51 , Derek MacDonald wrote: >> >> > Ice should be simplified for devices that are running on the open >> > internet >> > or not behind a NAT from the perspective of other devices. The >> > most common >> > example of this device is a PSTN gateway, although B2BUAs could be >> > deployed >> > in the 'same place'. I do not know of any ice-aware PSTN gateways >> > that >> > have been deployed, and I suspect this is due to the implementation >> > cost of >> > ice. >> > >> > Desired simplifications >> > >> > 1. stateless processing, or a much simplified ice state machine >> > 2. should never be the deciding endpoint in the ice algorithm >> > 3. limited communication between the signaling component and media >> > component >> > >> > >> > Proposed Solution >> > >> > This type of device, which I will refer to as a GW for convenience, >> > will >> > only ever have one candidate. The candidate will be the global IP >> > address >> > of the GW, which will always be the same as the m/c line; so candida= te >> > gathering is eliminated. The GW will not have a NAT/FW in front of >> > it, so >> > it will not have to send STUN requests to open NAT/FW permissions. >> > Local >> > permissions would have to be opened based on the remote SDP, but GW >> > devices >> > that wish to enforce must already do this for the remote m/c line. >> > A GW >> > does not prefer any candidate, as it only has one, so it has no >> > motivation >> > to prioritize candidates. This leads us to: >> > >> > 1. a GW will only perform triggered checks >> > 2. for each component the GW will send media to the last successful >> > triggered check, unless informed otherwise by the remote party >> > 3. the GW is never the controlling endpoint, and will announce this >> > in SDP >> > (see later) >> > >> > The triggered check is necessary because the remote (non GW) >> > endpoint could >> > be behind a NAT/FW which allows outgoing UDP packets but blocks >> > incoming UDP >> > packets. #2 is the same as we are proposing for normal ice >> > devices, which >> > will send to the first validated candidate for a component. A new S= DP >> > attribute, ice-passive, would be used for #3. Any GW that advertise= s >> > ice-passive must be in the open region of the topology, so it will >> > not need >> > ice to communicate with another GW which offers ice-passive. So, >> > if both >> > devices advertise ice-passive, no ice discovery will take place. >> > Keepalives >> > should not be necessary, but if they are desired, ice keepalives >> > will be >> > used. If no side indicates ice-passive, the offerer is the >> > controlling >> > endpoint, as in ice-10. >> > >> > If the controlling endpoint wishes the ice-passive endpoint to >> > switch to >> > another candidate, it can accomplish this by sending an ice-check >> > which will >> > cause the GW to send a triggered check and change candidates if the >> > triggered check succeeds. >> > >> > This approach will allow a very light implementation of ICE for >> > this type of >> > device. It requires very little state (one table of permissions, >> > one table >> > of validated candidates from triggered checks) and very little >> > communication >> > between the signaling and media components. It eliminates candidate >> > gathering, priority processing and the ice-check state machine. >> > >> > -Derek >> > >> > >> > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mmusic >> > >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 11:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmeu-0005Uc-2v; Tue, 03 Oct 2006 11:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmet-0005UN-2a for mmusic@ietf.org; Tue, 03 Oct 2006 11:58:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmer-0003st-EA for mmusic@ietf.org; Tue, 03 Oct 2006 11:58:15 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2006 08:58:12 -0700 X-IronPort-AV: i="4.09,251,1157353200"; d="scan'208"; a="327668074:sNHT609381830" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93FwC9V029786; Tue, 3 Oct 2006 08:58:12 -0700 Received: from [192.168.1.3] (sjc-vpn6-836.cisco.com [10.21.123.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k93FwBid019757; Tue, 3 Oct 2006 08:58:12 -0700 (PDT) In-Reply-To: References: <20061002235114.E6FC0172DE@relay5.relay.iad.emailsrvr.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <72521807-0B21-4E2B-9016-11CF76C19323@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 08:58:12 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=5903; t=1159891092; x=1160755092; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[MMUSIC]=20Ice=20and=20open=20internet=20devices; X=v=3Dcisco.com=3B=20h=3DsHVxFYMlmhURqEdv2NQbT2yY9cY=3D; b=RPzQsrS0OvGzrbOsLg7lnnHxMxeoIODcfuwB+WG1EvmCCX0Yp/sycIOxnjnHzVZ/Pt4a7bqb nEYu8P8/2m8sho669FwMHLC0bNHm2uxSkwz3Djr7ThTh+D7R71e8eQZi; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I think the simple answer would be that the device does not detect =20 this in any way. Originally we tried to make a scheme where only the =20 UA that was behind a NAT needed to deal with NAT traversal (and stun =20 was invented). That worked some of the time but not all. We then =20 moved to a idea where both sides had to support something new to work =20= through NATs - this is ICE. We recognized that the major drawback of =20 ICE is that both sides, not just one had to do write new software and =20= deploy it. What Derek's proposal here does it reduce the bar on how much work =20 the side that is *not* behind the NAT needs to do. I'm very much in =20 favor of thinking about this and figuring out how to do this. I am =20 not aware of a single ICE GW on the market yet and the current design =20= of full ICE is surprisingly complicated for a large GW to implement. =20 Keep in mind the software that sees the sip is usually running on a =20 different CPU than the one sees the RTP and often they are not even =20 in the same box. Most the large PSTN GWs that can do SS7 interconnect =20= are very distributed in their architecture. It would of course be best if the GWs did full ICE but if they are =20 unwilling to do that, they could instead implement something somewhat =20= reduced that allowed them to work in certain (but not all) topologies =20= - specifically if their IP were always global and routable. Now you might think, who cares if large PSTN GWs can work or not but =20 until they deploy something that the soft-phones can use, there is =20 little benefit in the soft-phones bothering to do ICE since they will =20= have to do something else to work with the PSTN GWs. On Oct 3, 2006, at 6:26 AM, Philip Matthews wrote: > Derek: > > How does a device determine that it is on the open Internet? > Does it look at its IP address? This mostly works, > but there was a recent case in Italy where this test would have =20 > failed. > > And, BTW, a PSTN gateway does not have to be on the open Internet. > With ICE, a PSTN gateway can easily be behind a NAT. > > - Philip > > On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > >> Ice should be simplified for devices that are running on the open =20 >> internet >> or not behind a NAT from the perspective of other devices. The =20 >> most common >> example of this device is a PSTN gateway, although B2BUAs could be =20= >> deployed >> in the =91same place=92. I do not know of any ice-aware PSTN =20 >> gateways that >> have been deployed, and I suspect this is due to the =20 >> implementation cost of >> ice. >> >> Desired simplifications >> >> 1. stateless processing, or a much simplified ice state machine >> 2. should never be the deciding endpoint in the ice algorithm >> 3. limited communication between the signaling component and media =20= >> component >> >> >> Proposed Solution >> >> This type of device, which I will refer to as a GW for =20 >> convenience, will >> only ever have one candidate. The candidate will be the global IP =20= >> address >> of the GW, which will always be the same as the m/c line; so =20 >> candidate >> gathering is eliminated. The GW will not have a NAT/FW in front =20 >> of it, so >> it will not have to send STUN requests to open NAT/FW =20 >> permissions. Local >> permissions would have to be opened based on the remote SDP, but =20 >> GW devices >> that wish to enforce must already do this for the remote m/c =20 >> line. A GW >> does not prefer any candidate, as it only has one, so it has no =20 >> motivation >> to prioritize candidates. This leads us to: >> >> 1. a GW will only perform triggered checks >> 2. for each component the GW will send media to the last successful >> triggered check, unless informed otherwise by the remote party >> 3. the GW is never the controlling endpoint, and will announce =20 >> this in SDP >> (see later) >> >> The triggered check is necessary because the remote (non GW) =20 >> endpoint could >> be behind a NAT/FW which allows outgoing UDP packets but blocks =20 >> incoming UDP >> packets. #2 is the same as we are proposing for normal ice =20 >> devices, which >> will send to the first validated candidate for a component. A new =20= >> SDP >> attribute, ice-passive, would be used for #3. Any GW that advertises >> ice-passive must be in the open region of the topology, so it will =20= >> not need >> ice to communicate with another GW which offers ice-passive. So, =20 >> if both >> devices advertise ice-passive, no ice discovery will take place. =20 >> Keepalives >> should not be necessary, but if they are desired, ice keepalives =20 >> will be >> used. If no side indicates ice-passive, the offerer is the =20 >> controlling >> endpoint, as in ice-10. >> >> If the controlling endpoint wishes the ice-passive endpoint to =20 >> switch to >> another candidate, it can accomplish this by sending an ice-check =20 >> which will >> cause the GW to send a triggered check and change candidates if the >> triggered check succeeds. >> >> This approach will allow a very light implementation of ICE for =20 >> this type of >> device. It requires very little state (one table of permissions, =20 >> one table >> of validated candidates from triggered checks) and very little =20 >> communication >> between the signaling and media components. It eliminates candidate >> gathering, priority processing and the ice-check state machine. >> >> -Derek >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 12:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnJE-00073v-Hw; Tue, 03 Oct 2006 12:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnJD-00073i-4t for mmusic@ietf.org; Tue, 03 Oct 2006 12:39:55 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUnJ8-0006k8-Q2 for mmusic@ietf.org; Tue, 03 Oct 2006 12:39:55 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2006 09:39:51 -0700 X-IronPort-AV: i="4.09,251,1157353200"; d="scan'208"; a="344358250:sNHT50601556" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93GdoHe014201 for ; Tue, 3 Oct 2006 09:39:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k93GdaKL010033 for ; Tue, 3 Oct 2006 09:39:50 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:39:45 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:39:45 -0700 Message-ID: <45229250.7040904@cisco.com> Date: Tue, 03 Oct 2006 12:39:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 16:39:45.0144 (UTC) FILETIME=[88711780:01C6E70A] DKIM-Signature: a=rsa-sha1; q=dns; l=1353; t=1159893590; x=1160757590; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20call=20is=20*on*=20for=20today=20at=20October=203,=201-2pm=20EST; X=v=3Dcisco.com=3B=20h=3DorjUYwW9zvR2ksPb13eNnvIllgM=3D; b=Zz0cj0d22AMHVw0axeOvhXZxkcWC5TCCmk+d5kZlmf+B5iOvRNHxCX5fehgRuPmQbu4EAYd/ WSJddhm0MVbrKUJT1WMWs5dM5pNAGR/bkGTupWXjChVyb54DgR6d8kHz; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [MMUSIC] ICE call is *on* for today at October 3, 1-2pm EST X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Agenda: Continue discussion from last time: 1. when is ice done? when to send media? Is there an ICE state machine? dealing with future-proofing of algorithms and different choices for optimization, and what to do when signaling and ICE don't agree (issues 4, 13, 14) Join the Web Conference 1. Go to: http://meetingplace.cisco.com/join.asp?2203261 2. Fill in the My Name is field then click Attend Meeting 3. Accept any security warnings you receive and wait for the Meeting Room to initialize Join the Voice Conference 1. From the Meeting Room, click on CONNECT (top left pane) and follow the instructions on how to have the system call you or simply follow the Voice only Conference instructions below TO ATTEND A VOICE ONLY CONFERENCE All Users 1. Dial into Cisco MeetingPlace (see Local & Global Access Numbers link above) 2. Press 1 to attend the meeting 3. Follow the prompts to enter the Meeting ID 2203261 and join the meeting This works best from Internet Explorer. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 12:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnQS-0003Wl-R6; Tue, 03 Oct 2006 12:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnQR-0003Wg-D8 for mmusic@ietf.org; Tue, 03 Oct 2006 12:47:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUnQP-0008Ro-NF for mmusic@ietf.org; Tue, 03 Oct 2006 12:47:23 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2006 09:47:21 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93GlL3A023610; Tue, 3 Oct 2006 09:47:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k93GlLql016906; Tue, 3 Oct 2006 09:47:21 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:47:20 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:47:19 -0700 Message-ID: <45229416.2000102@cisco.com> Date: Tue, 03 Oct 2006 12:47:18 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: derek@counterpath.com Subject: Re: [MMUSIC] Ice and open internet devices References: <57091.10.238.10.70.1159890822.webmail@10.238.10.70> In-Reply-To: <57091.10.238.10.70.1159890822.webmail@10.238.10.70> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 16:47:19.0745 (UTC) FILETIME=[9767B310:01C6E70B] DKIM-Signature: a=rsa-sha1; q=dns; l=6682; t=1159894041; x=1160758041; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Ice=20and=20open=20internet=20devices; X=v=3Dcisco.com=3B=20h=3D1U4SM639QidQ2PZkTmTqculwhhs=3D; b=TOOtEvuR6Fp0BSHaBuK7wQA1SEEhbp3hwsraVv6eTiVY/Jc0SRdgX9owMYnYZopy0x/agtT+ 0GOSjdljRM66vxLLsMWdSbdUQu0MdpMRgdelbBWtrv2XS3Sl7Jv7C3D8; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree with Derek here. I like this idea a lot and have been thinking about similar things. Firstly, I agree that it should not be discovered. THis would be something that is specific to the TYPE of device; i.e., a softphone would NEVER do this, whereas a PSTN gateway would have the option configured (or indeed required to be on the public internet). Secondly, instead of a passive/active flag, I have an alternate suggestion. The main question is who does the reinvite at the end of ICE. Today, it says its the offerer. What if the algorithm is this. If, after the ICE checks are done, the agent finds that it alone needs to use a different candidate than is in the m/c-line, it sends a re-invite. If it looks like both sides are using a new candidate, the offerer sends a re-invite. Because a pstn gateway would never see a check produce a different candidate for itself, it would never do a re-invite. I like this algorithm since it puts the burden of work on the component that has the most to gain from the work. Finally, I don't think triggered checks are needed for gateways. I don't understand Derek's use case. In fact, I've been thinking about whether gateways can skip the checks entirely, and just respond to checks they receive. -Jonathan R. derek@counterpath.com wrote: > A device would not determine that it is on the open internet by discovery; it would use configuration which is set at delpoyment time. > > If a PSTN gateway is behind a NAT, it would have to implement full ice. The purpose of 'ice-passive' is to simplify the implementation of devices that are not behind a NAT. > > -Derek > > Michael Slavitch said: > > >>In many situations that would fail. An assumption that a public IP >>address is not behind some kind of firewall, walled garden or gateway >>is a false assumption. >> >>Philip is entirely correct about a PSTN gateway supporting ICE >>operating behind a NAT. Same goes for any SIP registrar. >> >> >>On 10/3/06, Philip Matthews wrote: >> >>>Derek: >>> >>>How does a device determine that it is on the open Internet? >>>Does it look at its IP address? This mostly works, >>>but there was a recent case in Italy where this test would have failed. >>> >>>And, BTW, a PSTN gateway does not have to be on the open Internet. >>>With ICE, a PSTN gateway can easily be behind a NAT. >>> >>>- Philip >>> >>>On 2-Oct-06, at 19:51 , Derek MacDonald wrote: >>> >>> >>>>Ice should be simplified for devices that are running on the open >>>>internet >>>>or not behind a NAT from the perspective of other devices. The >>>>most common >>>>example of this device is a PSTN gateway, although B2BUAs could be >>>>deployed >>>>in the 'same place'. I do not know of any ice-aware PSTN gateways >>>>that >>>>have been deployed, and I suspect this is due to the implementation >>>>cost of >>>>ice. >>>> >>>>Desired simplifications >>>> >>>>1. stateless processing, or a much simplified ice state machine >>>>2. should never be the deciding endpoint in the ice algorithm >>>>3. limited communication between the signaling component and media >>>>component >>>> >>>> >>>>Proposed Solution >>>> >>>>This type of device, which I will refer to as a GW for convenience, >>>>will >>>>only ever have one candidate. The candidate will be the global IP >>>>address >>>>of the GW, which will always be the same as the m/c line; so candidate >>>>gathering is eliminated. The GW will not have a NAT/FW in front of >>>>it, so >>>>it will not have to send STUN requests to open NAT/FW permissions. >>>>Local >>>>permissions would have to be opened based on the remote SDP, but GW >>>>devices >>>>that wish to enforce must already do this for the remote m/c line. >>>>A GW >>>>does not prefer any candidate, as it only has one, so it has no >>>>motivation >>>>to prioritize candidates. This leads us to: >>>> >>>>1. a GW will only perform triggered checks >>>>2. for each component the GW will send media to the last successful >>>>triggered check, unless informed otherwise by the remote party >>>>3. the GW is never the controlling endpoint, and will announce this >>>>in SDP >>>>(see later) >>>> >>>>The triggered check is necessary because the remote (non GW) >>>>endpoint could >>>>be behind a NAT/FW which allows outgoing UDP packets but blocks >>>>incoming UDP >>>>packets. #2 is the same as we are proposing for normal ice >>>>devices, which >>>>will send to the first validated candidate for a component. A new SDP >>>>attribute, ice-passive, would be used for #3. Any GW that advertises >>>>ice-passive must be in the open region of the topology, so it will >>>>not need >>>>ice to communicate with another GW which offers ice-passive. So, >>>>if both >>>>devices advertise ice-passive, no ice discovery will take place. >>>>Keepalives >>>>should not be necessary, but if they are desired, ice keepalives >>>>will be >>>>used. If no side indicates ice-passive, the offerer is the >>>>controlling >>>>endpoint, as in ice-10. >>>> >>>>If the controlling endpoint wishes the ice-passive endpoint to >>>>switch to >>>>another candidate, it can accomplish this by sending an ice-check >>>>which will >>>>cause the GW to send a triggered check and change candidates if the >>>>triggered check succeeds. >>>> >>>>This approach will allow a very light implementation of ICE for >>>>this type of >>>>device. It requires very little state (one table of permissions, >>>>one table >>>>of validated candidates from triggered checks) and very little >>>>communication >>>>between the signaling and media components. It eliminates candidate >>>>gathering, priority processing and the ice-check state machine. >>>> >>>>-Derek >>>> >>>> >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 12:56:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnYs-00011P-BH; Tue, 03 Oct 2006 12:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnYr-00011I-6Q for mmusic@ietf.org; Tue, 03 Oct 2006 12:56:05 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUnYp-0001tG-RZ for mmusic@ietf.org; Tue, 03 Oct 2006 12:56:05 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2006 09:56:03 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93Gu3c6023487; Tue, 3 Oct 2006 09:56:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k93Gu3qn022644; Tue, 3 Oct 2006 09:56:03 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Oct 2006 09:56:03 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:56:02 -0700 Message-ID: <45229621.5070203@cisco.com> Date: Tue, 03 Oct 2006 12:56:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kai.Vehmanen@nokia.com Subject: Re: [MMUSIC] ICE Finishing: Design choices References: <719D5CCC2F6E3644B0A9F5C9B1D00088021BA8EC@esebe104.NOE.Nokia.com> In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D00088021BA8EC@esebe104.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 16:56:02.0736 (UTC) FILETIME=[CF21CB00:01C6E70C] DKIM-Signature: a=rsa-sha1; q=dns; l=2130; t=1159894563; x=1160758563; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20ICE=20Finishing=3A=20Design=20choices; X=v=3Dcisco.com=3B=20h=3DTJLWAOXPiSf4IEVVfQl+Ki2z7kw=3D; b=Z5vzB8nw3C0ywwEJIjzikps3V6k5R5UQEIpGp/st1hw+ec1ERl1tLW0yztim7Mwasc0UD3bh bkJzXEmXQzHfkzjSh7BCPOWHMyvDFUnbugpjKvjyAtbwZmEO+MfDx9Uk; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org There is no extra complexity in ICE for dealing with symmetric RTP; I think there is a fair bit of complexity to get away from it. ICE has been architected around the symmetric RTP assumption. I have listed many times the rationale for symmetric RTP. It includes: * working with offpath QoS installation mechanisms (IMS kind of stuff) * working with monitoring tools which look at SDP and match it to media streams * working with more stringent firewalls that are looking for RTP to keepalive and so on. Thanks, Jonathan R. Kai.Vehmanen@nokia.com wrote: > Hi, > > On 26 September 2006, Jonathan Rosenberg wrote: > >>This came up on last weeks call. It was suggested that with >>the keepalives being generated on the media stream, it was not >>so important to retain symmetric RTP. I remain opposed to >>this. Symmetric RTP seems to be the assumption these days, and >>I think it will be maximally interoperable with firewalls and >>various other intermediate things if we retain this property. > > > I don't have strong opinions on this, but what would be the use cases > where symmetric RTP is really needed when ICE is used? > > As clients cannot really assume a continuous flow of RTP packets > throughout a session (due to aggressive VAD for instance), you anyways > need to send STUN packets to keep the RTP/RTCP flows alive. From > middle-box > point of view, each client will have "two symmetric-RTP flows" per > session (one > for receiving and one for sending, but both have the STUN traffic). > > Symmetric RTP does have some benefits (only one flow needed at stateful > middle-boxes), but it's not that obvious that the benefits outweight > possible > added complexity in ICE to always achieve one symmetric RTP flow. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 14:49:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpKZ-000388-ML; Tue, 03 Oct 2006 14:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpKY-000383-DG for mmusic@ietf.org; Tue, 03 Oct 2006 14:49:26 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpKX-0004rr-31 for mmusic@ietf.org; Tue, 03 Oct 2006 14:49:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2006 11:49:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93InOYR000540 for ; Tue, 3 Oct 2006 11:49:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k93InLqv014459 for ; Tue, 3 Oct 2006 11:49:24 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:49:12 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:49:12 -0700 Message-ID: <4522B0A7.5040508@cisco.com> Date: Tue, 03 Oct 2006 14:49:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 18:49:12.0560 (UTC) FILETIME=[9E2EB700:01C6E71C] DKIM-Signature: a=rsa-sha1; q=dns; l=1458; t=1159901364; x=1160765364; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Notes=20on=20October=203=20ICE=20call; X=v=3Dcisco.com=3B=20h=3DD7zPBBlIVeS7lqRRGPctJE4bdRo=3D; b=XjK1Bbl45zFb8G9GTpES/heXiLxmPR7REYSObqW6y077S0YPQAz8lBZglBmAIWU86xqipvYN ugrtmWlfHuNxVapTt64OKEomGeIt+DjhAA2oBR8pVH08vRHYUIfVW0Yv; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [MMUSIC] Notes on October 3 ICE call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org ICE Call October 3, 2006 Attendees Jonathan Rosenberg Eric Rescorla Philip Matthews Derek MacDonald Tim Moore Eric Cooper Kevin Johns Colin Perkins Cullen Jennings Rohan Mahy Continued discussion on the question of what to do when the m/c-lines and the ICE results don't agree. A final poll at the end of the call reveals that the group remains split on the question. There does seem to be agreement on the idea of having one side choosing a pair and signaling it (rather than having each side pick its own candidate and use the resulting pair), and so the main issue is whether this is with STUN or SIP. There was also general agreement that making things easier for gateways was a good thing. Derek explained his use case for requiring triggered checks for gateways - when the other side is behind a one-way firewall. Next steps: * folks who are concerned about not following the SDP when it doesnt match the results of the ICE checks should post some concrete use cases for that * JDR said he'd think about a possible middle-ground approach and post on that before the next call -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 15:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5K-0003FJ-QO; Tue, 03 Oct 2006 15:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5K-0003F0-5u for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:46 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUq5J-0004Qu-4s for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:46 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 83528D85; Tue, 3 Oct 2006 21:37:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 21:37:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 21:37:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403D4D53B@esealmw113.eemea.ericsson.se> In-Reply-To: <72521807-0B21-4E2B-9016-11CF76C19323@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Ice and open internet devices Thread-Index: AcbnBNmQ6DZdIDXUQD2kwOJi5zy0pwAHZcBQ From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Philip Matthews" X-OriginalArrivalTime: 03 Oct 2006 19:37:44.0148 (UTC) FILETIME=[659FC940:01C6E723] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Cullen, In the case where there the GW is not behind a NAT, does it really make a difference whether the GW implements "full ICE" or not? Because, if there is no NAT, there is no STUN server to connect (at least it makes no sense to connect to one), so there will only be a single candidate in any case... Regards, Christer=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 3. lokakuuta 2006 18:58 > To: Philip Matthews > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Ice and open internet devices >=20 >=20 > I think the simple answer would be that the device does not=20 > detect this in any way. Originally we tried to make a scheme=20 > where only the UA that was behind a NAT needed to deal with=20 > NAT traversal (and stun was invented). That worked some of=20 > the time but not all. We then moved to a idea where both=20 > sides had to support something new to work through NATs -=20 > this is ICE. We recognized that the major drawback of ICE is=20 > that both sides, not just one had to do write new software=20 > and deploy it. >=20 > What Derek's proposal here does it reduce the bar on how much=20 > work the side that is *not* behind the NAT needs to do. I'm=20 > very much in favor of thinking about this and figuring out=20 > how to do this. I am not aware of a single ICE GW on the=20 > market yet and the current design of full ICE is surprisingly=20 > complicated for a large GW to implement. =20 > Keep in mind the software that sees the sip is usually=20 > running on a different CPU than the one sees the RTP and=20 > often they are not even in the same box. Most the large PSTN=20 > GWs that can do SS7 interconnect are very distributed in=20 > theiFrom mmusic-bounces@ietf.org Tue Oct 03 15:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5K-0003FJ-QO; Tue, 03 Oct 2006 15:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5K-0003F0-5u for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:46 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUq5J-0004Qu-4s for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:46 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 83528D85; Tue, 3 Oct 2006 21:37:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 21:37:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 21:37:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403D4D53B@esealmw113.eemea.ericsson.se> In-Reply-To: <72521807-0B21-4E2B-9016-11CF76C19323@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Ice and open internet devices Thread-Index: AcbnBNmQ6DZdIDXUQD2kwOJi5zy0pwAHZcBQ From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Philip Matthews" X-OriginalArrivalTime: 03 Oct 2006 19:37:44.0148 (UTC) FILETIME=[659FC940:01C6E723] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Cullen, In the case where there the GW is not behind a NAT, does it really make a difference whether the GW implements "full ICE" or not? Because, if there is no NAT, there is no STUN server to connect (at least it makes no sense to connect to one), so there will only be a single candidate in any case... Regards, Christer=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 3. lokakuuta 2006 18:58 > To: Philip Matthews > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Ice and open internet devices >=20 >=20 > I think the simple answer would be that the device does not=20 > detect this in any way. Originally we tried to make a scheme=20 > where only the UA that was behind a NAT needed to deal with=20 > NAT traversal (and stun was invented). That worked some of=20 > the time but not all. We then moved to a idea where both=20 > sides had to support something new to work through NATs -=20 > this is ICE. We recognized that the major drawback of ICE is=20 > that both sides, not just one had to do write new software=20 > and deploy it. >=20 > What Derek's proposal here does it reduce the bar on how much=20 > work the side that is *not* behind the NAT needs to do. I'm=20 > very much in favor of thinking about this and figuring out=20 > how to do this. I am not aware of a single ICE GW on the=20 > market yet and the current design of full ICE is surprisingly=20 > complicated for a large GW to implement. =20 > Keep in mind the software that sees the sip is usually=20 > running on a different CPU than the one sees the RTP and=20 > often they are not even in the same box. Most the large PSTN=20 > GWs that can do SS7 interconnect are very distributed in=20 > their architecture. >=20 > It would of course be best if the GWs did full ICE but if=20 > they are unwilling to do that, they could instead implement=20 > something somewhat reduced that allowed them to work in=20 > certain (but not all) topologies > - specifically if their IP were always global and routable. >=20 > Now you might think, who cares if large PSTN GWs can work or=20 > not but until they deploy something that the soft-phones can=20 > use, there is little benefit in the soft-phones bothering to=20 > do ICE since they will have to do something else to work with=20 > the PSTN GWs. >=20 >=20 > On Oct 3, 2006, at 6:26 AM, Philip Matthews wrote: >=20 > > Derek: > > > > How does a device determine that it is on the open Internet? > > Does it look at its IP address? This mostly works, but there was a=20 > > recent case in Italy where this test would have failed. > > > > And, BTW, a PSTN gateway does not have to be on the open Internet. > > With ICE, a PSTN gateway can easily be behind a NAT. > > > > - Philip > > > > On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > > > >> Ice should be simplified for devices that are running on the open=20 > >> internet or not behind a NAT from the perspective of other=20 > devices. =20 > >> The most common example of this device is a PSTN gateway, although=20 > >> B2BUAs could be deployed > >> in the 'same place'. I do not know of any ice-aware PSTN =20 > >> gateways that > >> have been deployed, and I suspect this is due to the=20 > implementation=20 > >> cost of ice. > >> > >> Desired simplifications > >> > >> 1. stateless processing, or a much simplified ice state machine 2.=20 > >> should never be the deciding endpoint in the ice algorithm=20 > 3. limited=20 > >> communication between the signaling component and media component > >> > >> > >> Proposed Solution > >> > >> This type of device, which I will refer to as a GW for =20 > >> convenience, will > >> only ever have one candidate. The candidate will be the=20 > global IP =20 > >> address > >> of the GW, which will always be the same as the m/c line; so =20 > >> candidate > >> gathering is eliminated. The GW will not have a NAT/FW in front =20 > >> of it, so > >> it will not have to send STUN requests to open NAT/FW =20 > >> permissions. Local > >> permissions would have to be opened based on the remote SDP, but =20 > >> GW devices > >> that wish to enforce must already do this for the remote m/c =20 > >> line. A GW > >> does not prefer any candidate, as it only has one, so it has no =20 > >> motivation > >> to prioritize candidates. This leads us to: > >> > >> 1. a GW will only perform triggered checks > >> 2. for each component the GW will send media to the last successful > >> triggered check, unless informed otherwise by the remote party > >> 3. the GW is never the controlling endpoint, and will announce =20 > >> this in SDP > >> (see later) > >> > >> The triggered check is necessary because the remote (non GW) =20 > >> endpoint could > >> be behind a NAT/FW which allows outgoing UDP packets but blocks =20 > >> incoming UDP > >> packets. #2 is the same as we are proposing for normal ice =20 > >> devices, which > >> will send to the first validated candidate for a=20 > component. A new =20 > >> SDP > >> attribute, ice-passive, would be used for #3. Any GW that=20 > advertises > >> ice-passive must be in the open region of the topology, so=20 > it will =20 > >> not need > >> ice to communicate with another GW which offers ice-passive. So, =20 > >> if both > >> devices advertise ice-passive, no ice discovery will take place. =20 > >> Keepalives > >> should not be necessary, but if they are desired, ice keepalives =20 > >> will be > >> used. If no side indicates ice-passive, the offerer is the =20 > >> controlling > >> endpoint, as in ice-10. > >> > >> If the controlling endpoint wishes the ice-passive endpoint to =20 > >> switch to > >> another candidate, it can accomplish this by sending an ice-check =20 > >> which will > >> cause the GW to send a triggered check and change candidates if the > >> triggered check succr architecture. >=20 > It would of course be best if the GWs did full ICE but if=20 > they are unwilling to do that, they could instead implement=20 > something somewhat reduced that allowed them to work in=20 > certain (but not all) topologies > - specifically if their IP were always global and routable. >=20 > Now you might think, who cares if large PSTN GWs can work or=20 > not but until they deploy something that the soft-phones can=20 > use, there is little benefit in the soft-phones bothering to=20 > do ICE since they will have to do something else to work with=20 > the PSTN GWs. >=20 >=20 > On Oct 3, 2006, at 6:26 AM, Philip Matthews wrote: >=20 > > Derek: > > > > How does a device determine that it is on the open Internet? > > Does it look at its IP address? This mostly works, but there was a=20 > > recent case in Italy where this test would have failed. > > > > And, BTW, a PSTN gateway does not have to be on the open Internet. > > With ICE, a PSTN gateway can easily be behind a NAT. > > > > - Philip > > > > On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > > > >> Ice should be simplified for devices that are running on the open=20 > >> internet or not behind a NAT from the perspective of other=20 > devices. =20 > >> The most common example of this device is a PSTN gateway, although=20 > >> B2BUAs could be deployed > >> in the 'same place'. I do not know of any ice-aware PSTN =20 > >> gateways that > >> have been deployed, and I suspect this is due to the=20 > implementation=20 > >> cost of ice. > >> > >> Desired simplifications > >> > >> 1. stateless processing, or a much simplified ice state machine 2.=20 > >> should never be the deciding endpoint in the ice algorithm=20 > 3. limited=20 > >> communication between the signaling component and media component > >> > >> > >> Proposed Solution > >> > >> This type of device, which I will refer to as a GW for =20 > >> convenience, will > >> only ever have one candidate. The candidate will be the=20 > global IP =20 > >> address > >> of the GW, which will always be the same as the m/c line; so =20 > >> candidate > >> gathering is eliminated. The GW will not have a NAT/FW in front =20 > >> of it, so > >> it will not have to send STUN requests to open NAT/FW =20 > >> permissions. Local > >> permissions would have to be opened based on the remote SDP, but =20 > >> GW devices > >> that wish to enforce must already do this for the remote m/c =20 > >> line. A GW > >> does not prefer any candidate, as it only has one, so it has no =20 > >> motivation > >> to prioritize candidates. This leads us to: > >> > >> 1. a GW will only perform triggered checks > >> 2. for each component the GW will send media to the last successful > >> triggered check, unless informed otherwise by the remote party > >> 3. the GW is never the controlling endpoint, and will announce =20 > >> this in SDP > >> (see later) > >> > >> The triggered check is necessary because the remote (non GW) =20 > >> endpoint could > >> be behind a NAT/FW which allows outgoing UDP packets but blocks =20 > >> incoming UDP > >> packets. #2 is the same as we are proposing for normal ice =20 > >> devices, which > >> will send to the first validated candidate for a=20 > component. A new =20 > >> SDP > >> attribute, ice-passive, would be used for #3. Any GW that=20 > advertises > >> ice-passive must be in the open region of the topology, so=20 > it will =20 > >> not need > >> ice to communicate with another GW which offers ice-passive. So, =20 > >> if both > >> devices advertise ice-passive, no ice discovery will take place. =20 > >> Keepalives > >> should not be necessary, but if they are desired, ice keepalives =20 > >> will be > >> used. If no side indicates ice-passive, the offerer is the =20 > >> controlling > >> endpoint, as in ice-10. > >> > >> If the controlling endpoint wishes the ice-passive endpoint to =20 > >> switch to > >> another candidate, it can accomplish this by sending an ice-check =20 > >> which will > >> cause the GW to send a triggered check and change candidates if the > >> triggered check succeeds. > >> > >> This approach will allow a very light implementation of ICE for =20 > >> this type of > >> device. It requires very little state (one table of permissions, =20 > >> one table > >> of validated candidates from triggered checks) and very little =20 > >> communication > >> between the signaling and media components. It eliminates=20 > candidate > >> gathering, priority processing and the ice-check state machine. > >> > >> -Derek > >> > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 15:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5K-0003F5-G5; Tue, 03 Oct 2006 15:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5I-0003Ei-83 for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUq5B-0004P4-BQ for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:44 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2BF2DD85; Tue, 3 Oct 2006 21:37:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 21:37:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 21:37:31 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403D4D53A@esealmw113.eemea.ericsson.se> In-Reply-To: <45229416.2000102@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Ice and open internet devices Thread-Index: AcbnC8bkIBOvaIXkSt2rDboTMv7l1gAF0pJg From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 03 Oct 2006 19:37:32.0773 (UTC) FILETIME=[5ED81950:01C6E723] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, Is this discussion really only related to GWs? What about if there is a normal SIP phone that "knows" it's not behind a NAT? If it supports ICE, I think it's a good idea that it still includes a candidate in the offer, in case the remote party IS behind a NAT, and also wants to use ICE. Regards, Christer =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 3. lokakuuta 2006 19:47 > To: derek@counterpath.com > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Ice and open internet devices >=20 > I agree with Derek here. I like this idea a lot and have been=20 > thinking about similar things. >=20 > Firstly, I agree that it should not be discovered. THieeds. > >> > >> This approach will allow a very light implementation of ICE for =20 > >> this type of > >> device. It requires very little state (one table of permissions, =20 > >> one table > >> of validated candidates from triggered checks) and very little =20 > >> communication > >> between the signaling and media components. It eliminates=20 > candidate > >> gathering, priority processing and the ice-check state machine. > >> > >> -Derek > >> > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 15:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5K-0003F5-G5; Tue, 03 Oct 2006 15:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq5I-0003Ei-83 for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUq5B-0004P4-BQ for mmusic@ietf.org; Tue, 03 Oct 2006 15:37:44 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2BF2DD85; Tue, 3 Oct 2006 21:37:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 21:37:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 21:37:31 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403D4D53A@esealmw113.eemea.ericsson.se> In-Reply-To: <45229416.2000102@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Ice and open internet devices Thread-Index: AcbnC8bkIBOvaIXkSt2rDboTMv7l1gAF0pJg From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 03 Oct 2006 19:37:32.0773 (UTC) FILETIME=[5ED81950:01C6E723] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, Is this discussion really only related to GWs? What about if there is a normal SIP phone that "knows" it's not behind a NAT? If it supports ICE, I think it's a good idea that it still includes a candidate in the offer, in case the remote party IS behind a NAT, and also wants to use ICE. Regards, Christer =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 3. lokakuuta 2006 19:47 > To: derek@counterpath.com > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Ice and open internet devices >=20 > I agree with Derek here. I like this idea a lot and have been=20 > thinking about similar things. >=20 > Firstly, I agree that it should not be discovered. THis would=20 > be something that is specific to the TYPE of device; i.e., a=20 > softphone would NEVER do this, whereas a PSTN gateway would=20 > have the option configured (or indeed required to be on the=20 > public internet). >=20 > Secondly, instead of a passive/active flag, I have an=20 > alternate suggestion. The main question is who does the=20 > reinvite at the end of ICE. Today, it says its the offerer.=20 > What if the algorithm is this. If, after the ICE checks are=20 > done, the agent finds that it alone needs to use a different=20 > candidate than is in the m/c-line, it sends a re-invite.=20 > If it looks like both sides are using a new candidate, the=20 > offerer sends a re-invite. >=20 > Because a pstn gateway would never see a check produce a=20 > different candidate for itself, it would never do a re-invite. >=20 > I like this algorithm since it puts the burden of work on the=20 > component that has the most to gain from the work. >=20 > Finally, I don't think triggered checks are needed for=20 > gateways. I don't understand Derek's use case. In fact, I've=20 > been thinking about whether gateways can skip the checks=20 > entirely, and just respond to checks they receive. >=20 > -Jonathan R. >=20 >=20 > derek@counterpath.com wrote: >=20 > > A device would not determine that it is on the open=20 > internet by discovery; it would use configuration which is=20 > set at delpoyment time. > >=20 > > If a PSTN gateway is behind a NAT, it would have to=20 > implement full ice. The purpose of 'ice-passive' is to=20 > simplify the implementation of devices that are not behind a NAT. > >=20 > > -Derek > >=20 > > Michael Slavitch said: > >=20 > >=20 > >>In many situations that would fail. An assumption that a public IP=20 > >>address is not behind some kind of firewall, walled garden=20 > or gateway=20 > >>is a false assumption. > >> > >>Philip is entirely correct about a PSTN gateway supporting ICE=20 > >>operating behind a NAT. Same goes for any SIP registrar. > >> > >> > >>On 10/3/06, Philip Matthews wrote: > >> > >>>Derek: > >>> > >>>How does a device determine that it is on the open Internet? > >>>Does it look at its IP address? This mostly works, but there was a=20 > >>>recent case in Italy where this test would have failed. > >>> > >>>And, BTW, a PSTN gateway does not have to be on the open Internet. > >>>With ICE, a PSTN gateway can easily be behind a NAT. > >>> > >>>- Philip > >>> > >>>On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > >>> > >>> > >>>>Ice should be simplified for devices that are running on the open=20 > >>>>internet or not behind a NAT from the perspective of=20 > other devices. =20 > >>>>The most common example of this device is a PSTN gateway,=20 > although=20 > >>>>B2BUAs could be deployed > >>>>in the 'same place'. I do not know of any ice-aware=20 > PSTN gateways > >>>>that > >>>>have been deployed, and I suspect this is due to the=20 > implementation=20 > >>>>cost of ice. > >>>> > >>>>Desired simplifications > >>>> > >>>>1. stateless processing, or a much simplified ice state=20 > machine 2.=20 > >>>>should never be the deciding endpoint in the ice algorithm 3.=20 > >>>>limited communication between the signaling component and media=20 > >>>>component > >>>> > >>>> > >>>>Proposed Solution > >>>> > >>>>This type of device, which I will refer to as a GW for=20 > convenience,=20 > >>>>will only ever have one candidate. The candidate will be=20 > the global=20 > >>>>IP address of the GW, which will always be the same as=20 > the m/c line;=20 > >>>>so candidate gathering is eliminated. The GW will not=20 > have a NAT/FW=20 > >>>>in front of it, so it will not have to send STUN requests to open=20 > >>>>NAT/FW permissions. > >>>>Local > >>>>permissions would have to be opened based on the remote=20 > SDP, but GW=20 > >>>>devices that wish to enforce must already do this for the=20 > remote m/c=20 > >>>>line. > >>>>A GW > >>>>does not prefer any candidate, as it only has one, so it has no=20 > >>>>motivation to prioritize candidates. This les would=20 > be something that is specific to the TYPE of device; i.e., a=20 > softphone would NEVER do this, whereas a PSTN gateway would=20 > have the option configured (or indeed required to be on the=20 > public internet). >=20 > Secondly, instead of a passive/active flag, I have an=20 > alternate suggestion. The main question is who does the=20 > reinvite at the end of ICE. Today, it says its the offerer.=20 > What if the algorithm is this. If, after the ICE checks are=20 > done, the agent finds that it alone needs to use a different=20 > candidate than is in the m/c-line, it sends a re-invite.=20 > If it looks like both sides are using a new candidate, the=20 > offerer sends a re-invite. >=20 > Because a pstn gateway would never see a check produce a=20 > different candidate for itself, it would never do a re-invite. >=20 > I like this algorithm since it puts the burden of work on the=20 > component that has the most to gain from the work. >=20 > Finally, I don't think triggered checks are needed for=20 > gateways. I don't understand Derek's use case. In fact, I've=20 > been thinking about whether gateways can skip the checks=20 > entirely, and just respond to checks they receive. >=20 > -Jonathan R. >=20 >=20 > derek@counterpath.com wrote: >=20 > > A device would not determine that it is on the open=20 > internet by discovery; it would use configuration which is=20 > set at delpoyment time. > >=20 > > If a PSTN gateway is behind a NAT, it would have to=20 > implement full ice. The purpose of 'ice-passive' is to=20 > simplify the implementation of devices that are not behind a NAT. > >=20 > > -Derek > >=20 > > Michael Slavitch said: > >=20 > >=20 > >>In many situations that would fail. An assumption that a public IP=20 > >>address is not behind some kind of firewall, walled garden=20 > or gateway=20 > >>is a false assumption. > >> > >>Philip is entirely correct about a PSTN gateway supporting ICE=20 > >>operating behind a NAT. Same goes for any SIP registrar. > >> > >> > >>On 10/3/06, Philip Matthews wrote: > >> > >>>Derek: > >>> > >>>How does a device determine that it is on the open Internet? > >>>Does it look at its IP address? This mostly works, but there was a=20 > >>>recent case in Italy where this test would have failed. > >>> > >>>And, BTW, a PSTN gateway does not have to be on the open Internet. > >>>With ICE, a PSTN gateway can easily be behind a NAT. > >>> > >>>- Philip > >>> > >>>On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > >>> > >>> > >>>>Ice should be simplified for devices that are running on the open=20 > >>>>internet or not behind a NAT from the perspective of=20 > other devices. =20 > >>>>The most common example of this device is a PSTN gateway,=20 > although=20 > >>>>B2BUAs could be deployed > >>>>in the 'same place'. I do not know of any ice-aware=20 > PSTN gateways > >>>>that > >>>>have been deployed, and I suspect this is due to the=20 > implementation=20 > >>>>cost of ice. > >>>> > >>>>Desired simplifications > >>>> > >>>>1. stateless processing, or a much simplified ice state=20 > machine 2.=20 > >>>>should never be the deciding endpoint in the ice algorithm 3.=20 > >>>>limited communication between the signaling component and media=20 > >>>>component > >>>> > >>>> > >>>>Proposed Solution > >>>> > >>>>This type of device, which I will refer to as a GW for=20 > convenience,=20 > >>>>will only ever have one candidate. The candidate will be=20 > the global=20 > >>>>IP address of the GW, which will always be the same as=20 > the m/c line;=20 > >>>>so candidate gathering is eliminated. The GW will not=20 > have a NAT/FW=20 > >>>>in front of it, so it will not have to send STUN requests to open=20 > >>>>NAT/FW permissions. > >>>>Local > >>>>permissions would have to be opened based on the remote=20 > SDP, but GW=20 > >>>>devices that wish to enforce must already do this for the=20 > remote m/c=20 > >>>>line. > >>>>A GW > >>>>does not prefer any candidate, as it only has one, so it has no=20 > >>>>motivation to prioritize candidates. This leads us to: > >>>> > >>>>1. a GW will only perform triggered checks 2. for each=20 > component the=20 > >>>>GW will send media to the last successful triggered check, unless=20 > >>>>informed otherwise by the remote party 3. the GW is never the=20 > >>>>controlling endpoint, and will announce this in SDP (see later) > >>>> > >>>>The triggered check is necessary because the remote (non GW)=20 > >>>>endpoint could be behind a NAT/FW which allows outgoing=20 > UDP packets=20 > >>>>but blocks incoming UDP packets. #2 is the same as we=20 > are proposing=20 > >>>>for normal ice devices, which will send to the first validated=20 > >>>>candidate for a component. A new SDP attribute,=20 > ice-passive, would=20 > >>>>be used for #3. Any GW that advertises ice-passive must=20 > be in the=20 > >>>>open region of the topology, so it will not need ice to=20 > communicate=20 > >>>>with another GW which offers ice-passive. So, if both devices=20 > >>>>advertise ice-passive, no ice discovery will take place. > >>>>Keepalives > >>>>should not be necessary, but if they are desired, ice keepalives=20 > >>>>will be used. If no side indicates ice-passive, the=20 > offerer is the=20 > >>>>controlling endpoint, as in ice-10. > >>>> > >>>>If the controlling endpoint wishes the ice-passive endpoint to=20 > >>>>switch to another candidate, it can accomplish this by sending an=20 > >>>>ice-check which will cause the GW to send a triggered check and=20 > >>>>change candidates if the triggered check succeeds. > >>>> > >>>>This approach will allow a very light implementation of=20 > ICE for this=20 > >>>>type of device. It requires very little state (one table of=20 > >>>>permissions, one table of validated candidates from triggered=20 > >>>>checks) and very little communication between the signaling and=20 > >>>>media components. It eliminates candidate gathering, priority=20 > >>>>processing and the ice-check state machine. > >>>> > >>>>-Derek > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>mmusic mailing list > >>>>mmusic@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/mmusic > >>>> > >>> > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ads us to: > >>>> > >>>>1. a GW will only perform triggered checks 2. for each=20 > component the=20 > >>>>GW will send media to the last successful triggered check, unless=20 > >>>>informed otherwise by the remote party 3. the GW is never the=20 > >>>>controlling endpoint, and will announce this in SDP (see later) > >>>> > >>>>The triggered check is necessary because the remote (non GW)=20 > >>>>endpoint could be behind a NAT/FW which allows outgoing=20 > UDP packets=20 > >>>>but blocks incoming UDP packets. #2 is the same as we=20 > are proposing=20 > >>>>for normal ice devices, which will send to the first validated=20 > >>>>candidate for a component. A new SDP attribute,=20 > ice-passive, would=20 > >>>>be used for #3. Any GW that advertises ice-passive must=20 > be in the=20 > >>>>open region of the topology, so it will not need ice to=20 > communicate=20 > >>>>with another GW which offers ice-passive. So, if both devices=20 > >>>>advertise ice-passive, no ice discovery will take place. > >>>>Keepalives > >>>>should not be necessary, but if they are desired, ice keepalives=20 > >>>>will be used. If no side indicates ice-passive, the=20 > offerer is the=20 > >>>>controlling endpoint, as in ice-10. > >>>> > >>>>If the controlling endpoint wishes the ice-passive endpoint to=20 > >>>>switch to another candidate, it can accomplish this by sending an=20 > >>>>ice-check which will cause the GW to send a triggered check and=20 > >>>>change candidates if the triggered check succeeds. > >>>> > >>>>This approach will allow a very light implementation of=20 > ICE for this=20 > >>>>type of device. It requires very little state (one table of=20 > >>>>permissions, one table of validated candidates from triggered=20 > >>>>checks) and very little communication between the signaling and=20 > >>>>media components. It eliminates candidate gathering, priority=20 > >>>>processing and the ice-check state machine. > >>>> > >>>>-Derek > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>mmusic mailing list > >>>>mmusic@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/mmusic > >>>> > >>> > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 15:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqBu-0007Er-4W; Tue, 03 Oct 2006 15:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqBt-0007El-3g for mmusic@ietf.org; Tue, 03 Oct 2006 15:44:33 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUqBr-0006S0-JY for mmusic@ietf.org; Tue, 03 Oct 2006 15:44:33 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B37788E0001; Tue, 3 Oct 2006 21:44:06 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 21:44:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Notes on October 3 ICE call Date: Tue, 3 Oct 2006 21:44:05 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403D4D553@esealmw113.eemea.ericsson.se> In-Reply-To: <4522B0A7.5040508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Notes on October 3 ICE call Thread-Index: AcbnHRbU+OCmlTaVSjaQV1TgZMKiMAABpB1w From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-OriginalArrivalTime: 03 Oct 2006 19:44:06.0326 (UTC) FILETIME=[496B8560:01C6E724] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, As far as the m/c-lines issue is concerned, I have a feeling we'll need some slides showing use-cases and impacts. It's probably one thing we should spend some time discussing in San Diego (either in the WG meeting, or by the bar). Regards, Christer=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 3. lokakuuta 2006 21:49 > To: IETF MMUSIC WG > Subject: [MMUSIC] Notes on October 3 ICE call >=20 > ICE Call > October 3, 2006 >=20 > Attendees >=20 > Jonathan Rosenberg > Eric Rescorla > Philip Matthews > Derek MacDonald > Tim Moore > Eric Cooper > Kevin Johns > Colin Perkins > Cullen Jennings > Rohan Mahy >=20 > Continued discussion on the question of what to do when the=20 > m/c-lines and the ICE results don't agree. A final poll at=20 > the end of the call reveals that the group remains split on=20 > the question. >=20 > There does seem to be agreement on the idea of having one=20 > side choosing a pair and signaling it (rather than having=20 > each side pick its own candidate and use the resulting pair),=20 > and so the main issue is whether this is with STUN or SIP.=20 > There was also general agreement that making things easier=20 > for gateways was a good thing. Derek explained his use case=20 > for requiring triggered checks for gateways - when the other=20 > side is behind a one-way firewall. >=20 > Next steps: >=20 > * folks who are concerned about not following the SDP when it doesnt > match the results of the ICE checks should post some concrete use > cases for that >=20 > * JDR said he'd think about a possible middle-ground approach and post > on that before the next call >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 03 20:20:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuTj-00067u-C9; Tue, 03 Oct 2006 20:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuTh-00067n-In for mmusic@ietf.org; Tue, 03 Oct 2006 20:19:13 -0400 Received: from smtp152.iad.emailsrvr.com ([207.97.245.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUuTg-0002ZD-5m for mmusic@ietf.org; Tue, 03 Oct 2006 20:19:13 -0400 Received: from bremen (h66-38-133-13.gtconnect.net [66.38.133.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay5.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id 4EC22174F4; Tue, 3 Oct 2006 20:19:11 -0400 (EDT) From: "Derek MacDonald" To: "'Jonathan Rosenberg'" Subject: RE: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 17:19:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcbnDC0qJqRoI7NRTj2WT+EnYOKeRwALIiEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45229416.2000102@cisco.com> Message-Id: <20061004001911.4EC22174F4@relay5.relay.iad.emailsrvr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I think Jonathan's proposal that we do away with the passive/active flag works. This is how I interpret this: If a device only has one candidate, which is the same as its m/c line, it may behave in the passive mode as detailed below in my original post. If two such devices communicate ice would not occur as neither side will originate checks. I don't keepalives will be sent in this case as ice won't have been activated. Basically, the m/c line being the same as the only provided candidate is the same as the passive flag, if that endpoint does not send ice checks. If a full ice implementation happens to have one candidate it can be distinguished from a passive ice implementation by the fact that it sends checks. If two full ice implementations have one candidate the offerer would be the controlling endpoint. -Derek > > I agree with Derek here. I like this idea a lot and have been thinking > about similar things. > > Firstly, I agree that it should not be discovered. THis would be > something that is specific to the TYPE of device; i.e., a softphone > would NEVER do this, whereas a PSTN gateway would have the option > configured (or indeed required to be on the public internet). > > Secondly, instead of a passive/active flag, I have an alternate > suggestion. The main question is who does the reinvite at the end of > ICE. Today, it says its the offerer. What if the algorithm is this. If, > after the ICE checks are done, the agent finds that it alone needs to > use a different candidate than is in the m/c-line, it sends a re-invite. > If it looks like both sides are using a new candidate, the offerer sends > a re-invite. > > Because a pstn gateway would never see a check produce a different > candidate for itself, it would never do a re-invite. > > I like this algorithm since it puts the burden of work on the component > that has the most to gain from the work. > > Finally, I don't think triggered checks are needed for gateways. I don't > understand Derek's use case. In fact, I've been thinking about whether > gateways can skip the checks entirely, and just respond to checks they > receive. > > -Jonathan R. > > > derek@counterpath.com wrote: > > > A device would not determine that it is on the open internet by > discovery; it would use configuration which is set at delpoyment time. > > > > If a PSTN gateway is behind a NAT, it would have to implement full ice. > The purpose of 'ice-passive' is to simplify the implementation of devices > that are not behind a NAT. > > > > -Derek > > > > Michael Slavitch said: > > > > > >>In many situations that would fail. An assumption that a public IP > >>address is not behind some kind of firewall, walled garden or gateway > >>is a false assumption. > >> > >>Philip is entirely correct about a PSTN gateway supporting ICE > >>operating behind a NAT. Same goes for any SIP registrar. > >> > >> > >>On 10/3/06, Philip Matthews wrote: > >> > >>>Derek: > >>> > >>>How does a device determine that it is on the open Internet? > >>>Does it look at its IP address? This mostly works, > >>>but there was a recent case in Italy where this test would have failed. > >>> > >>>And, BTW, a PSTN gateway does not have to be on the open Internet. > >>>With ICE, a PSTN gateway can easily be behind a NAT. > >>> > >>>- Philip > >>> > >>>On 2-Oct-06, at 19:51 , Derek MacDonald wrote: > >>> > >>> > >>>>Ice should be simplified for devices that are running on the open > >>>>internet > >>>>or not behind a NAT from the perspective of other devices. The > >>>>most common > >>>>example of this device is a PSTN gateway, although B2BUAs could be > >>>>deployed > >>>>in the 'same place'. I do not know of any ice-aware PSTN gateways > >>>>that > >>>>have been deployed, and I suspect this is due to the implementation > >>>>cost of > >>>>ice. > >>>> > >>>>Desired simplifications > >>>> > >>>>1. stateless processing, or a much simplified ice state machine > >>>>2. should never be the deciding endpoint in the ice algorithm > >>>>3. limited communication between the signaling component and media > >>>>component > >>>> > >>>> > >>>>Proposed Solution > >>>> > >>>>This type of device, which I will refer to as a GW for convenience, > >>>>will > >>>>only ever have one candidate. The candidate will be the global IP > >>>>address > >>>>of the GW, which will always be the same as the m/c line; so candidate > >>>>gathering is eliminated. The GW will not have a NAT/FW in front of > >>>>it, so > >>>>it will not have to send STUN requests to open NAT/FW permissions. > >>>>Local > >>>>permissions would have to be opened based on the remote SDP, but GW > >>>>devices > >>>>that wish to enforce must already do this for the remote m/c line. > >>>>A GW > >>>>does not prefer any candidate, as it only has one, so it has no > >>>>motivation > >>>>to prioritize candidates. This leads us to: > >>>> > >>>>1. a GW will only perform triggered checks > >>>>2. for each component the GW will send media to the last successful > >>>>triggered check, unless informed otherwise by the remote party > >>>>3. the GW is never the controlling endpoint, and will announce this > >>>>in SDP > >>>>(see later) > >>>> > >>>>The triggered check is necessary because the remote (non GW) > >>>>endpoint could > >>>>be behind a NAT/FW which allows outgoing UDP packets but blocks > >>>>incoming UDP > >>>>packets. #2 is the same as we are proposing for normal ice > >>>>devices, which > >>>>will send to the first validated candidate for a component. A new SDP > >>>>attribute, ice-passive, would be used for #3. Any GW that advertises > >>>>ice-passive must be in the open region of the topology, so it will > >>>>not need > >>>>ice to communicate with another GW which offers ice-passive. So, > >>>>if both > >>>>devices advertise ice-passive, no ice discovery will take place. > >>>>Keepalives > >>>>should not be necessary, but if they are desired, ice keepalives > >>>>will be > >>>>used. If no side indicates ice-passive, the offerer is the > >>>>controlling > >>>>endpoint, as in ice-10. > >>>> > >>>>If the controlling endpoint wishes the ice-passive endpoint to > >>>>switch to > >>>>another candidate, it can accomplish this by sending an ice-check > >>>>which will > >>>>cause the GW to send a triggered check and change candidates if the > >>>>triggered check succeeds. > >>>> > >>>>This approach will allow a very light implementation of ICE for > >>>>this type of > >>>>device. It requires very little state (one table of permissions, > >>>>one table > >>>>of validated candidates from triggered checks) and very little > >>>>communication > >>>>between the signaling and media components. It eliminates candidate > >>>>gathering, priority processing and the ice-check state machine. > >>>> > >>>>-Derek > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>mmusic mailing list > >>>>mmusic@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/mmusic > >>>> > >>> > >>> > >>>_______________________________________________ > >>>mmusic mailing list > >>>mmusic@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 04 00:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyeC-00045v-Gu; Wed, 04 Oct 2006 00:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyeA-00045n-Ig for mmusic@ietf.org; Wed, 04 Oct 2006 00:46:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUye9-0005I3-7h for mmusic@ietf.org; Wed, 04 Oct 2006 00:46:18 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2006 21:46:17 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="327913518:sNHT50611948" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k944kGVO014270; Tue, 3 Oct 2006 21:46:16 -0700 Received: from [192.168.1.3] (sjc-vpn6-709.cisco.com [10.21.122.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k944kFML024132; Tue, 3 Oct 2006 21:46:15 -0700 (PDT) In-Reply-To: <082d01c6e2ac$683146f0$6601a8c0@acmepacket.com> References: <082d01c6e2ac$683146f0$6601a8c0@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50AA10BA-5BED-4DE0-8222-132FD08BA193@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [MMUSIC] ICE Finishing: Design choices Date: Tue, 3 Oct 2006 21:46:15 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1413; t=1159937176; x=1160801176; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[MMUSIC]=20ICE=20Finishing=3A=20Design=20choices; X=v=3Dcisco.com=3B=20h=3D7xtXBIiCI6/qpoQZdWoXcLRc6/Q=3D; b=XRGZluT3EabskEyuPd3kRVAidyDWNkuHfV+cvJwU8Ua1gSrf7FW1uPfxUZcd07X0O5B08zqg Fd57UlbuUgu4WxZ2EcVOL9Xx7zbbFfoUN3AonpYVY71NWMjhgIzMCmEM; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'IETF MMUSIC WG' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Just as side not to the discussion, I'm never quite sure what people mean when they say SBC or middlebox. I can see Hadriel's point that a B2BUA in the path might have a better idea than the originating UA about optimal - however, I can't think of a use case where a proxy or ALG in a NAT has a significantly better idea. On Sep 27, 2006, at 8:15 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >> Sent: Tuesday, September 26, 2006 4:05 PM >> To: Jonathan Rosenberg >> Cc: IETF MMUSIC WG >> Subject: Re: [MMUSIC] ICE Finishing: Design choices >> >> I'm including my opinions in-line. I think questions 2 and 3 imply a >> choice between business as usual for middleboxes and some very >> minimal >> level of ICE-support for at least one middlebox in any network that >> wants to enforce non-optimal paths. > > I don't know why people keep claiming they're non-optimal paths. > The UA has > no idea what the "optimal" path is. The middlebox path may be more > optimal, > or less, or the same. It depends on many things, most of which are > unknowable to a UA, some of which are knowable to a middlebox. > > (size(1) != all.fit();) > > -hadriel > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 04 00:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyhD-0007ti-FX; Wed, 04 Oct 2006 00:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyhC-0007py-Ko for mmusic@ietf.org; Wed, 04 Oct 2006 00:49:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUyhB-0006Lu-VP for mmusic@ietf.org; Wed, 04 Oct 2006 00:49:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 03 Oct 2006 21:49:25 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="1856423844:sNHT68499628" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k944nPZG015017; Tue, 3 Oct 2006 21:49:25 -0700 Received: from [192.168.1.3] (sjc-vpn6-709.cisco.com [10.21.122.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k944nOid005378; Tue, 3 Oct 2006 21:49:24 -0700 (PDT) In-Reply-To: <20061004001911.4EC22174F4@relay5.relay.iad.emailsrvr.com> References: <20061004001911.4EC22174F4@relay5.relay.iad.emailsrvr.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [MMUSIC] Ice and open internet devices Date: Tue, 3 Oct 2006 21:49:25 -0700 To: Derek MacDonald X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=8661; t=1159937365; x=1160801365; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[MMUSIC]=20Ice=20and=20open=20internet=20devices; X=v=3Dcisco.com=3B=20h=3D2xmsXV4Kb2d6V0kXBAWoscjL9Oc=3D; b=lSQM7azlznaw9n0nyF6insyXIy0lMo2U+7i2lgwcqE/yRKNCsKfxWnpswVYWSyy5FneYIubW VT4OESo00HyiTN2cAj2XR6olJMPjzySaYkIdj2l48AuTG8DuhjTRARU+; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I thought about that awhile and I can't see any problems with it. Sounds like a good thing. On Oct 3, 2006, at 5:19 PM, Derek MacDonald wrote: > I think Jonathan's proposal that we do away with the passive/active > flag > works. This is how I interpret this: > > If a device only has one candidate, which is the same as its m/c > line, it > may behave in the passive mode as detailed below in my original > post. If two > such devices communicate ice would not occur as neither side will > originate > checks. I don't keepalives will be sent in this case as ice won't > have been > activated. > > Basically, the m/c line being the same as the only provided > candidate is the > same as the passive flag, if that endpoint does not send ice > checks. If a > full ice implementation happens to have one candidate it can be > distinguished from a passive ice implementation by the fact that it > sends > checks. > > If two full ice implementations have one candidate the offerer > would be the > controlling endpoint. > > -Derek >> >> I agree with Derek here. I like this idea a lot and have been >> thinking >> about similar things. >> >> Firstly, I agree that it should not be discovered. THis would be >> something that is specific to the TYPE of device; i.e., a softphone >> would NEVER do this, whereas a PSTN gateway would have the option >> configured (or indeed required to be on the public internet). >> >> Secondly, instead of a passive/active flag, I have an alternate >> suggestion. The main question is who does the reinvite at the end of >> ICE. Today, it says its the offerer. What if the algorithm is >> this. If, >> after the ICE checks are done, the agent finds that it alone needs to >> use a different candidate than is in the m/c-line, it sends a re- >> invite. >> If it looks like both sides are using a new candidate, the offerer >> sends >> a re-invite. >> >> Because a pstn gateway would never see a check produce a different >> candidate for itself, it would never do a re-invite. >> >> I like this algorithm since it puts the burden of work on the >> component >> that has the most to gain from the work. >> >> Finally, I don't think triggered checks are needed for gateways. I >> don't >> understand Derek's use case. In fact, I've been thinking about >> whether >> gateways can skip the checks entirely, and just respond to checks >> they >> receive. >> >> -Jonathan R. >> >> >> derek@counterpath.com wrote: >> >>> A device would not determine that it is on the open internet by >> discovery; it would use configuration which is set at delpoyment >> time. >>> >>> If a PSTN gateway is behind a NAT, it would have to implement >>> full ice. >> The purpose of 'ice-passive' is to simplify the implementation of >> devices >> that are not behind a NAT. >>> >>> -Derek >>> >>> Michael Slavitch said: >>> >>> >>>> In many situations that would fail. An assumption that a public IP >>>> address is not behind some kind of firewall, walled garden or >>>> gateway >>>> is a false assumption. >>>> >>>> Philip is entirely correct about a PSTN gateway supporting ICE >>>> operating behind a NAT. Same goes for any SIP registrar. >>>> >>>> >>>> On 10/3/06, Philip Matthews wrote: >>>> >>>>> Derek: >>>>> >>>>> How does a device determine that it is on the open Internet? >>>>> Does it look at its IP address? This mostly works, >>>>> but there was a recent case in Italy where this test would have >>>>> failed. >>>>> >>>>> And, BTW, a PSTN gateway does not have to be on the open Internet. >>>>> With ICE, a PSTN gateway can easily be behind a NAT. >>>>> >>>>> - Philip >>>>> >>>>> On 2-Oct-06, at 19:51 , Derek MacDonald wrote: >>>>> >>>>> >>>>>> Ice should be simplified for devices that are running on the open >>>>>> internet >>>>>> or not behind a NAT from the perspective of other devices. The >>>>>> most common >>>>>> example of this device is a PSTN gateway, although B2BUAs >>>>>> could be >>>>>> deployed >>>>>> in the 'same place'. I do not know of any ice-aware PSTN >>>>>> gateways >>>>>> that >>>>>> have been deployed, and I suspect this is due to the >>>>>> implementation >>>>>> cost of >>>>>> ice. >>>>>> >>>>>> Desired simplifications >>>>>> >>>>>> 1. stateless processing, or a much simplified ice state machine >>>>>> 2. should never be the deciding endpoint in the ice algorithm >>>>>> 3. limited communication between the signaling component and >>>>>> media >>>>>> component >>>>>> >>>>>> >>>>>> Proposed Solution >>>>>> >>>>>> This type of device, which I will refer to as a GW for >>>>>> convenience, >>>>>> will >>>>>> only ever have one candidate. The candidate will be the >>>>>> global IP >>>>>> address >>>>>> of the GW, which will always be the same as the m/c line; so >>>>>> candidate >>>>>> gathering is eliminated. The GW will not have a NAT/FW in >>>>>> front of >>>>>> it, so >>>>>> it will not have to send STUN requests to open NAT/FW >>>>>> permissions. >>>>>> Local >>>>>> permissions would have to be opened based on the remote SDP, >>>>>> but GW >>>>>> devices >>>>>> that wish to enforce must already do this for the remote m/c >>>>>> line. >>>>>> A GW >>>>>> does not prefer any candidate, as it only has one, so it has no >>>>>> motivation >>>>>> to prioritize candidates. This leads us to: >>>>>> >>>>>> 1. a GW will only perform triggered checks >>>>>> 2. for each component the GW will send media to the last >>>>>> successful >>>>>> triggered check, unless informed otherwise by the remote party >>>>>> 3. the GW is never the controlling endpoint, and will announce >>>>>> this >>>>>> in SDP >>>>>> (see later) >>>>>> >>>>>> The triggered check is necessary because the remote (non GW) >>>>>> endpoint could >>>>>> be behind a NAT/FW which allows outgoing UDP packets but blocks >>>>>> incoming UDP >>>>>> packets. #2 is the same as we are proposing for normal ice >>>>>> devices, which >>>>>> will send to the first validated candidate for a component. A >>>>>> new SDP >>>>>> attribute, ice-passive, would be used for #3. Any GW that >>>>>> advertises >>>>>> ice-passive must be in the open region of the topology, so it >>>>>> will >>>>>> not need >>>>>> ice to communicate with another GW which offers ice-passive. So, >>>>>> if both >>>>>> devices advertise ice-passive, no ice discovery will take place. >>>>>> Keepalives >>>>>> should not be necessary, but if they are desired, ice keepalives >>>>>> will be >>>>>> used. If no side indicates ice-passive, the offerer is the >>>>>> controlling >>>>>> endpoint, as in ice-10. >>>>>> >>>>>> If the controlling endpoint wishes the ice-passive endpoint to >>>>>> switch to >>>>>> another candidate, it can accomplish this by sending an ice-check >>>>>> which will >>>>>> cause the GW to send a triggered check and change candidates >>>>>> if the >>>>>> triggered check succeeds. >>>>>> >>>>>> This approach will allow a very light implementation of ICE for >>>>>> this type of >>>>>> device. It requires very little state (one table of permissions, >>>>>> one table >>>>>> of validated candidates from triggered checks) and very little >>>>>> communication >>>>>> between the signaling and media components. It eliminates >>>>>> candidate >>>>>> gathering, priority processing and the ice-check state machine. >>>>>> >>>>>> -Derek >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 05 06:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQIa-0000jl-HJ; Thu, 05 Oct 2006 06:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQIY-0000iJ-FW for mmusic@ietf.org; Thu, 05 Oct 2006 06:17:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVQIP-0000Ha-Jc for mmusic@ietf.org; Thu, 05 Oct 2006 06:17:50 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6F8B4F0140; Thu, 5 Oct 2006 12:17:38 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 12:17:38 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 12:17:37 +0200 Received: from [131.160.36.18] (EH3I2003TGFCPET-131160036018.lmf.ericsson.se [131.160.36.18]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CD760233C; Thu, 5 Oct 2006 13:17:37 +0300 (EEST) Message-ID: <4524DBC1.9090208@ericsson.com> Date: Thu, 05 Oct 2006 13:17:37 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [MMUSIC] file transfer, moving forward References: <45010AF7.7080406@nokia.com> <45139617.5060804@nokia.com> In-Reply-To: <45139617.5060804@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 10:17:37.0845 (UTC) FILETIME=[7B886650:01C6E867] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ext Miguel Garcia , mmusic@ietf.org, Dan Wing , "Isomaki Markus \(Nokia-TP/Espoo\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Aki, I find the MIME-based proposal technically more elegant. However, you are probably right that it raises the bar for implementers a little higher than the solution based on SDP attributes. We would like to hear further opinions on this. So far there has not been support for the new approach. We would like to start working on a new revision of the draft shortly and we need to know which approach to use. Cheers, Gonzalo Aki Niemi wrote: > Inline. > > ext Miguel Garcia kirjoitti: >> We discussed the file transfer draft in Montreal, and Dan was >> commenting about the possibility of using message/external-body (RFC >> 2046) as an external reference to the file (see the thread starting >> at http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html >> ). >> >> So, we (the authors) went through Dan's suggestion, and here is an >> example of how a file transfer offer in SDP would look like if we use >> message/external-body. I have highlighted where new tokens or >> extended values are needed, to differentiate them from already >> existing parameters. >> >> We like this idea, because it outsources from SDP the file >> descriptor, besides, it reuses most of the Content-Disposition >> already existing stuff. > > The problem I see is, you now only reuse the syntax, not the actual > semantics of message/external-body. Normally, if I receive a MIME object > with message/external-body, it will tell me what method to use for > fetching the actual content of that object. > > In file transfer, this is not the case, since it's a push instead of a > pull operation. So even if you had support for multipart and > message/external-body, you'd need to implement totally new functionality. > >> We are looking for opinions and consensus of whether this is the way >> to proceed. > > I don't like it. This change seems to only save a few lines of RFC text > by referencing some already defined header fields, instead of defining > them itself. > > But writing specifications is a sunk cost anyway, and we should not > optimize that. instead we should optimize following these criteria: > > a) minimizing the lines of code required to implement the specification > b) maximizing the probability that interop is achieved by implementors > of the specification > > This new approach, IMHO, does neither. > > Also, I suspect that using MIME multipart all but guarantees no existing > middle box will work, and very few SIP implementations will know where > to look for the SDP. In other words, this is not backwards-compatible > (MIME multipart support is a SHOULD in SIP). > >> Here is the example. It is as complete as possible, so, in many >> cases, we woon't be signaling all these metadada: >> >> INVITE ... Content-Type: multipart/related; boundary=ABC >> >> --ABC Content-Type: application/sdp >> >> v=0 ... m=message 7654 TCP/MSRP * >> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >> a=file-descriptor:cid:id1@example.com <---------- extension > > Since you already need to define at least one new SDP attribute, and > there's no way around that, then one way to limit this number is by > reusing some of the already defined SDP fields to serve your purpose. > > For instance, the suggested file name could be carried in the s=field. > AFAIK, nobody uses it to really set the subject of the session; here, > you could make it useful again. > > Also, the name file-descriptor is a terrible name, since that already > has a well-defined meaning in computer programming. > > Cheers, > Aki > >> --ABC Content-type: message/external-body; access-type="MSRP" >> <----------- new token Content-ID: >> >> Content-type: image/jpeg Content-ID: >> Content-Disposition: inline; filename="My cool picture.jpg"; >> size=98320932; byte-range=80-100 <---- >> extension creation-date="Mon, 15 May 2006 15:01:31 +03:00"; >> modification-date="Mon, 16 May 2006 15:01:31 +03:00"; read-date="Mon, >> 18 May 2006 15:01:31 +03:00"; icon="cid:id3@alicepc.example.com"; >> <----------- extension >> hash=sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E <----- ext >> >> --ABC Content-type: image/jpeg; Content-ID: >> >> ...binary JPEG icon image ... >> >> --ABC-- >> >> >> Comments, please. >> >> /Miguel >> > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 05 08:41:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSXA-0000x8-9W; Thu, 05 Oct 2006 08:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSX9-0000wY-94 for mmusic@ietf.org; Thu, 05 Oct 2006 08:41:03 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSIA-0006ub-4D for mmusic@ietf.org; Thu, 05 Oct 2006 08:25:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k95CPINA026582; Thu, 5 Oct 2006 15:25:20 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 15:25:20 +0300 Received: from [172.21.34.112] ([172.21.34.112]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 5 Oct 2006 15:25:19 +0300 Message-ID: <4524F9AF.1010803@nokia.com> Date: Thu, 05 Oct 2006 15:25:19 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [MMUSIC] file transfer, moving forward References: <45010AF7.7080406@nokia.com> <45139617.5060804@nokia.com> <4524DBC1.9090208@ericsson.com> In-Reply-To: <4524DBC1.9090208@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 12:25:19.0321 (UTC) FILETIME=[5220DC90:01C6E879] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Isomaki Markus \(Nokia-TP/Espoo\)" , Aki Niemi , Dan Wing , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I think simplicity should be taken into account. Additionally, if you want rapid deployment, it is easier to integrate the current solution in draft in current deployments (think of SBCs for example). It is true that the current solution is less elegant, but we need to balance between practicalities and elegance. /Miguel Gonzalo Camarillo wrote: > Hi Aki, > > I find the MIME-based proposal technically more elegant. However, you > are probably right that it raises the bar for implementers a little > higher than the solution based on SDP attributes. > > We would like to hear further opinions on this. So far there has not > been support for the new approach. We would like to start working on a > new revision of the draft shortly and we need to know which approach to > use. > > Cheers, > > Gonzalo > > > Aki Niemi wrote: >> Inline. >> >> ext Miguel Garcia kirjoitti: >>> We discussed the file transfer draft in Montreal, and Dan was >>> commenting about the possibility of using message/external-body (RFC >>> 2046) as an external reference to the file (see the thread starting >>> at http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html >>> ). >>> >>> So, we (the authors) went through Dan's suggestion, and here is an >>> example of how a file transfer offer in SDP would look like if we use >>> message/external-body. I have highlighted where new tokens or >>> extended values are needed, to differentiate them from already >>> existing parameters. >>> >>> We like this idea, because it outsources from SDP the file >>> descriptor, besides, it reuses most of the Content-Disposition >>> already existing stuff. >> >> The problem I see is, you now only reuse the syntax, not the actual >> semantics of message/external-body. Normally, if I receive a MIME object >> with message/external-body, it will tell me what method to use for >> fetching the actual content of that object. >> >> In file transfer, this is not the case, since it's a push instead of a >> pull operation. So even if you had support for multipart and >> message/external-body, you'd need to implement totally new functionality. >> >>> We are looking for opinions and consensus of whether this is the way >>> to proceed. >> >> I don't like it. This change seems to only save a few lines of RFC text >> by referencing some already defined header fields, instead of defining >> them itself. >> >> But writing specifications is a sunk cost anyway, and we should not >> optimize that. instead we should optimize following these criteria: >> >> a) minimizing the lines of code required to implement the specification >> b) maximizing the probability that interop is achieved by implementors >> of the specification >> >> This new approach, IMHO, does neither. >> >> Also, I suspect that using MIME multipart all but guarantees no existing >> middle box will work, and very few SIP implementations will know where >> to look for the SDP. In other words, this is not backwards-compatible >> (MIME multipart support is a SHOULD in SIP). >> >>> Here is the example. It is as complete as possible, so, in many >>> cases, we woon't be signaling all these metadada: >>> >>> INVITE ... Content-Type: multipart/related; boundary=ABC >>> >>> --ABC Content-Type: application/sdp >>> >>> v=0 ... m=message 7654 TCP/MSRP * >>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>> a=file-descriptor:cid:id1@example.com <---------- extension >> >> Since you already need to define at least one new SDP attribute, and >> there's no way around that, then one way to limit this number is by >> reusing some of the already defined SDP fields to serve your purpose. >> >> For instance, the suggested file name could be carried in the s=field. >> AFAIK, nobody uses it to really set the subject of the session; here, >> you could make it useful again. >> >> Also, the name file-descriptor is a terrible name, since that already >> has a well-defined meaning in computer programming. >> >> Cheers, >> Aki >> >>> --ABC Content-type: message/external-body; access-type="MSRP" >>> <----------- new token Content-ID: >>> >>> Content-type: image/jpeg Content-ID: >>> Content-Disposition: inline; filename="My cool picture.jpg"; >>> size=98320932; byte-range=80-100 <---- >>> extension creation-date="Mon, 15 May 2006 15:01:31 +03:00"; >>> modification-date="Mon, 16 May 2006 15:01:31 +03:00"; read-date="Mon, >>> 18 May 2006 15:01:31 +03:00"; icon="cid:id3@alicepc.example.com"; >>> <----------- extension >>> hash=sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E <----- ext >>> >>> --ABC Content-type: image/jpeg; Content-ID: >>> >>> ...binary JPEG icon image ... >>> >>> --ABC-- >>> >>> >>> Comments, please. >>> >>> /Miguel >>> >> >> >> > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 05 13:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXTy-0001EP-H5; Thu, 05 Oct 2006 13:58:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXTx-0001EJ-IZ for mmusic@ietf.org; Thu, 05 Oct 2006 13:58:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXTu-0007Sv-Td for mmusic@ietf.org; Thu, 05 Oct 2006 13:58:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 13:57:45 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105868906:sNHT569082726" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95HvdjZ004494; Thu, 5 Oct 2006 13:57:39 -0400 Received: from dwingwxp ([10.32.130.99]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k95HvdbF007180; Thu, 5 Oct 2006 10:57:39 -0700 (PDT) From: "Dan Wing" To: "'Gonzalo Camarillo'" , "'Aki Niemi'" Subject: RE: [MMUSIC] file transfer, moving forward Date: Thu, 5 Oct 2006 10:57:38 -0700 Keywords: direct-to-dwing Message-ID: <09a801c6e8a7$bf41f0b0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4524DBC1.9090208@ericsson.com> Thread-Index: AcboZ31pLIZ9goPIQBuetn5RXbvdAgAPX4tg DKIM-Signature: a=rsa-sha1; q=dns; l=7552; t=1160071059; x=1160935059; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20file=20transfer,=20moving=20forward |To:=22'Gonzalo=20Camarillo'=22=20, =0A=20=20 =20=20=20=20=20=20=22'Aki=20Niemi'=22=20; X=v=3Dcisco.com=3B=20h=3DYmm0g/LH0RiTMA+Ok/d3tKWQVsE=3D; b=fQn8GZm52k8ZJ3mwRT3yRDlrI7UhAwQNSaZIBym5y0UF2M3LUSnETf/ughzR2yJlDmA+GQta Z6yXEq/u+31HuwgBiku/N83TkfSGeCyKtzKnkyRJHfjntaFwfe8h+J9J; Authentication-Results: rtp-dkim-1.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: 'ext Miguel Garcia' , mmusic@ietf.org, "'Isomaki Markus \(Nokia-TP/Espoo\)'" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for investigating my proposal in detail. The primary objection to my proposal, which I agree with, is SIP's mistake to partially adopt MIME without adopting multipart. This is another unfortunate case that demonstrates that mistake. The savings isn't just to save time writing specifications, but in using existing tools that can process external-body MIME types -- Nathaniel Borenstein's classic metamail tools are but one example of existing code that could process such a bodypart. I concur with the objections to using external-body. However, please consider which of the external-body parameters (section 5.2.3.1 of RFC2046) may be useful when you define these same parameters as SDP attributes. For example, RFC2046 defines an expiration date parameter (but draft-garcia-mmusic-file-transfer-mech-00.txt doesn't define an expiration date attribute), and it might be useful to someone to have such an attribute. Another, unrelated thing you might want to consider is consuming only one SDP attribute and putting all the file parameters in that one attribute. For example, instead of your current syntax (this taken from your current -00 document): m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:* a=path:msrp://atlanta.example.com:7654/jshA7we;tcp * a=filename:My cool picture.jpg * a=filetype:image/jpeg * a=disposition:inline * a=filesize:32349 * a=creation-date:Mon, 15 May 2006 15:01:31 +03:00 * a=icon:cid:id2@alicepc.example.com * a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E if it might make more sense to have something like this: m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:* a=path:msrp://atlanta.example.com:7654/jshA7we;tcp * a=file-attributes filename:"My cool picture.jpg" * type:image/jpeg disposition:inline size:32349 * creation:"Mon, 15 May 2006 15:01:31 +03:00" * icon:cid:id2@alicepc.example.com * hash:SHA:72245FE8653DDAF371362F86D471913EE4A2CE2E And one question for you -- will you allow "../" in the filename, or filenames such as "/etc/passwd", or filenames with non-printable characters? The syntax allows it byte-string, which would allow such abuse. I noticed your security considerations is currently just a placeholder; section 5.2.3.6 of RFC2046 may be helpful. -d > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Thursday, October 05, 2006 3:18 AM > To: Aki Niemi > Cc: ext Miguel Garcia; mmusic@ietf.org; Dan Wing; Isomaki > Markus (Nokia-TP/Espoo) > Subject: Re: [MMUSIC] file transfer, moving forward > > Hi Aki, > > I find the MIME-based proposal technically more elegant. However, you > are probably right that it raises the bar for implementers a little > higher than the solution based on SDP attributes. > > We would like to hear further opinions on this. So far there has not > been support for the new approach. We would like to start > working on a > new revision of the draft shortly and we need to know which > approach to use. > > Cheers, > > Gonzalo > > > Aki Niemi wrote: > > Inline. > > > > ext Miguel Garcia kirjoitti: > >> We discussed the file transfer draft in Montreal, and Dan was > >> commenting about the possibility of using > message/external-body (RFC > >> 2046) as an external reference to the file (see the thread starting > >> at > http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html > >> ). > >> > >> So, we (the authors) went through Dan's suggestion, and here is an > >> example of how a file transfer offer in SDP would look > like if we use > >> message/external-body. I have highlighted where new tokens or > >> extended values are needed, to differentiate them from already > >> existing parameters. > >> > >> We like this idea, because it outsources from SDP the file > >> descriptor, besides, it reuses most of the Content-Disposition > >> already existing stuff. > > > > The problem I see is, you now only reuse the syntax, not the actual > > semantics of message/external-body. Normally, if I receive > a MIME object > > with message/external-body, it will tell me what method to use for > > fetching the actual content of that object. > > > > In file transfer, this is not the case, since it's a push > instead of a > > pull operation. So even if you had support for multipart and > > message/external-body, you'd need to implement totally new > functionality. > > > >> We are looking for opinions and consensus of whether this > is the way > >> to proceed. > > > > I don't like it. This change seems to only save a few lines > of RFC text > > by referencing some already defined header fields, instead > of defining > > them itself. > > > > But writing specifications is a sunk cost anyway, and we should not > > optimize that. instead we should optimize following these criteria: > > > > a) minimizing the lines of code required to implement the > specification > > b) maximizing the probability that interop is achieved by > implementors > > of the specification > > > > This new approach, IMHO, does neither. > > > > Also, I suspect that using MIME multipart all but > guarantees no existing > > middle box will work, and very few SIP implementations will > know where > > to look for the SDP. In other words, this is not > backwards-compatible > > (MIME multipart support is a SHOULD in SIP). > > > >> Here is the example. It is as complete as possible, so, in many > >> cases, we woon't be signaling all these metadada: > >> > >> INVITE ... Content-Type: multipart/related; boundary=ABC > >> > >> --ABC Content-Type: application/sdp > >> > >> v=0 ... m=message 7654 TCP/MSRP * > >> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp > >> a=file-descriptor:cid:id1@example.com <---------- extension > > > > Since you already need to define at least one new SDP attribute, and > > there's no way around that, then one way to limit this number is by > > reusing some of the already defined SDP fields to serve > your purpose. > > > > For instance, the suggested file name could be carried in > the s=field. > > AFAIK, nobody uses it to really set the subject of the > session; here, > > you could make it useful again. > > > > Also, the name file-descriptor is a terrible name, since > that already > > has a well-defined meaning in computer programming. > > > > Cheers, > > Aki > > > >> --ABC Content-type: message/external-body; access-type="MSRP" > >> <----------- new token Content-ID: > >> > >> Content-type: image/jpeg Content-ID: > >> Content-Disposition: inline; filename="My cool picture.jpg"; > >> size=98320932; byte-range=80-100 <---- > >> extension creation-date="Mon, 15 May 2006 15:01:31 +03:00"; > >> modification-date="Mon, 16 May 2006 15:01:31 +03:00"; > read-date="Mon, > >> 18 May 2006 15:01:31 +03:00"; icon="cid:id3@alicepc.example.com"; > >> <----------- extension > >> hash=sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E <----- ext > >> > >> --ABC Content-type: image/jpeg; Content-ID: > >> > >> ...binary JPEG icon image ... > >> > >> --ABC-- > >> > >> > >> Comments, please. > >> > >> /Miguel > >> > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 05 14:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXxY-0001Nb-SG; Thu, 05 Oct 2006 14:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXxX-0001NW-Q6 for mmusic@ietf.org; Thu, 05 Oct 2006 14:28:39 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXxR-0007QH-RU for mmusic@ietf.org; Thu, 05 Oct 2006 14:28:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k95ISGY4029865; Thu, 5 Oct 2006 21:28:16 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 21:28:16 +0300 Received: from [10.162.19.198] ([10.162.19.198]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 5 Oct 2006 21:28:13 +0300 Message-ID: <45254EB2.8000804@nokia.com> Date: Thu, 05 Oct 2006 21:28:02 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] file transfer, moving forward References: <09a801c6e8a7$bf41f0b0$c5f0200a@amer.cisco.com> In-Reply-To: <09a801c6e8a7$bf41f0b0$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 18:28:14.0752 (UTC) FILETIME=[054BF200:01C6E8AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: mmusic@ietf.org, "'Isomaki Markus \(Nokia-TP/Espoo\)'" , 'Gonzalo Camarillo' , 'Aki Niemi' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Dan: Thanks for your comments. I get we are getting consensus in this aspect. With respect your points: 1) Parameter from the external-body: We'll do a further examination and determine if something else is needed. I agree with adding the expiration date parameter. One could have think that the Expires header in SIP could do the same job, but it is not true: the Expires headers affect the session (i.e., all the media streams); the expiration-date will affect the file only. 2) Putting all the attributes in a single line. I have no problems with it. Can anyone think that we will break SDP by having very long lines? 3) With respect the file names. I think we ought to be careful here. On one hand, we should not allow to represent directories, mainly due to the disparity of implementations. The same applies for non-printable characters. However, we need to allow for internationalization. So I guess the idea is that the point is taken and we need to be able to solve it. If someone has some concern or idea, I will be happy to hear it. /Miguel Dan Wing wrote: > Thanks for investigating my proposal in detail. > > The primary objection to my proposal, which I agree with, is SIP's mistake > to partially adopt MIME without adopting multipart. This is another > unfortunate case that demonstrates that mistake. The savings isn't just to > save time writing specifications, but in using existing tools that can > process external-body MIME types -- Nathaniel Borenstein's classic metamail > tools are but one example of existing code that could process such a > bodypart. > > I concur with the objections to using external-body. > > > However, please consider which of the external-body parameters (section > 5.2.3.1 of RFC2046) may be useful when you define these same parameters as > SDP attributes. For example, RFC2046 defines an expiration date parameter > (but draft-garcia-mmusic-file-transfer-mech-00.txt doesn't define an > expiration date attribute), and it might be useful to someone to have such > an attribute. > > > Another, unrelated thing you might want to consider is consuming only one > SDP attribute and putting all the file parameters in that one attribute. > For example, instead of your current syntax (this taken from your current > -00 document): > > m=message 7654 TCP/MSRP * > i=This is my latest picture > a=sendonly > a=accept-types:* > a=path:msrp://atlanta.example.com:7654/jshA7we;tcp > * a=filename:My cool picture.jpg > * a=filetype:image/jpeg > * a=disposition:inline > * a=filesize:32349 > * a=creation-date:Mon, 15 May 2006 15:01:31 +03:00 > * a=icon:cid:id2@alicepc.example.com > * a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E > > if it might make more sense to have something like this: > > m=message 7654 TCP/MSRP * > i=This is my latest picture > a=sendonly > a=accept-types:* > a=path:msrp://atlanta.example.com:7654/jshA7we;tcp > * a=file-attributes filename:"My cool picture.jpg" > * type:image/jpeg disposition:inline size:32349 > * creation:"Mon, 15 May 2006 15:01:31 +03:00" > * icon:cid:id2@alicepc.example.com > * hash:SHA:72245FE8653DDAF371362F86D471913EE4A2CE2E > > > > And one question for you -- will you allow "../" in the filename, or > filenames such as "/etc/passwd", or filenames with non-printable characters? > The syntax allows it byte-string, which would allow such abuse. I noticed > your security considerations is currently just a placeholder; section > 5.2.3.6 of RFC2046 may be helpful. > > -d > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Thursday, October 05, 2006 3:18 AM >> To: Aki Niemi >> Cc: ext Miguel Garcia; mmusic@ietf.org; Dan Wing; Isomaki >> Markus (Nokia-TP/Espoo) >> Subject: Re: [MMUSIC] file transfer, moving forward >> >> Hi Aki, >> >> I find the MIME-based proposal technically more elegant. However, you >> are probably right that it raises the bar for implementers a little >> higher than the solution based on SDP attributes. >> >> We would like to hear further opinions on this. So far there has not >> been support for the new approach. We would like to start >> working on a >> new revision of the draft shortly and we need to know which >> approach to use. >> >> Cheers, >> >> Gonzalo >> >> >> Aki Niemi wrote: >>> Inline. >>> >>> ext Miguel Garcia kirjoitti: >>>> We discussed the file transfer draft in Montreal, and Dan was >>>> commenting about the possibility of using >> message/external-body (RFC >>>> 2046) as an external reference to the file (see the thread starting >>>> at >> http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html >>>> ). >>>> >>>> So, we (the authors) went through Dan's suggestion, and here is an >>>> example of how a file transfer offer in SDP would look >> like if we use >>>> message/external-body. I have highlighted where new tokens or >>>> extended values are needed, to differentiate them from already >>>> existing parameters. >>>> >>>> We like this idea, because it outsources from SDP the file >>>> descriptor, besides, it reuses most of the Content-Disposition >>>> already existing stuff. >>> The problem I see is, you now only reuse the syntax, not the actual >>> semantics of message/external-body. Normally, if I receive >> a MIME object >>> with message/external-body, it will tell me what method to use for >>> fetching the actual content of that object. >>> >>> In file transfer, this is not the case, since it's a push >> instead of a >>> pull operation. So even if you had support for multipart and >>> message/external-body, you'd need to implement totally new >> functionality. >>>> We are looking for opinions and consensus of whether this >> is the way >>>> to proceed. >>> I don't like it. This change seems to only save a few lines >> of RFC text >>> by referencing some already defined header fields, instead >> of defining >>> them itself. >>> >>> But writing specifications is a sunk cost anyway, and we should not >>> optimize that. instead we should optimize following these criteria: >>> >>> a) minimizing the lines of code required to implement the >> specification >>> b) maximizing the probability that interop is achieved by >> implementors >>> of the specification >>> >>> This new approach, IMHO, does neither. >>> >>> Also, I suspect that using MIME multipart all but >> guarantees no existing >>> middle box will work, and very few SIP implementations will >> know where >>> to look for the SDP. In other words, this is not >> backwards-compatible >>> (MIME multipart support is a SHOULD in SIP). >>> >>>> Here is the example. It is as complete as possible, so, in many >>>> cases, we woon't be signaling all these metadada: >>>> >>>> INVITE ... Content-Type: multipart/related; boundary=ABC >>>> >>>> --ABC Content-Type: application/sdp >>>> >>>> v=0 ... m=message 7654 TCP/MSRP * >>>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>>> a=file-descriptor:cid:id1@example.com <---------- extension >>> Since you already need to define at least one new SDP attribute, and >>> there's no way around that, then one way to limit this number is by >>> reusing some of the already defined SDP fields to serve >> your purpose. >>> For instance, the suggested file name could be carried in >> the s=field. >>> AFAIK, nobody uses it to really set the subject of the >> session; here, >>> you could make it useful again. >>> >>> Also, the name file-descriptor is a terrible name, since >> that already >>> has a well-defined meaning in computer programming. >>> >>> Cheers, >>> Aki >>> >>>> --ABC Content-type: message/external-body; access-type="MSRP" >>>> <----------- new token Content-ID: >>>> >>>> Content-type: image/jpeg Content-ID: >>>> Content-Disposition: inline; filename="My cool picture.jpg"; >>>> size=98320932; byte-range=80-100 <---- >>>> extension creation-date="Mon, 15 May 2006 15:01:31 +03:00"; >>>> modification-date="Mon, 16 May 2006 15:01:31 +03:00"; >> read-date="Mon, >>>> 18 May 2006 15:01:31 +03:00"; icon="cid:id3@alicepc.example.com"; >>>> <----------- extension >>>> hash=sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E <----- ext >>>> >>>> --ABC Content-type: image/jpeg; Content-ID: >>>> >>>> ...binary JPEG icon image ... >>>> >>>> --ABC-- >>>> >>>> >>>> Comments, please. >>>> >>>> /Miguel >>>> >>> >>> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 05 16:25:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZmH-000460-J2; Thu, 05 Oct 2006 16:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZmF-00045p-JB for mmusic@ietf.org; Thu, 05 Oct 2006 16:25:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZmD-0008H4-Sg for mmusic@ietf.org; Thu, 05 Oct 2006 16:25:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2006 13:25:00 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="45007562:sNHT94574418" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95KOvjG023771; Thu, 5 Oct 2006 16:24:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95KOvYJ009442; Thu, 5 Oct 2006 16:24:57 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 16:24:57 -0400 Received: from [160.39.252.102] ([10.86.240.209]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 16:24:57 -0400 Message-ID: <45256A19.8040605@cisco.com> Date: Thu, 05 Oct 2006 16:24:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] Notes on October 3 ICE call References: <5EB80D22825EEE42872083AD5BFFB59403D4D553@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59403D4D553@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 20:24:57.0182 (UTC) FILETIME=[5311F7E0:01C6E8BC] DKIM-Signature: a=rsa-sha1; q=dns; l=2793; t=1160079897; x=1160943897; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Notes=20on=20October=203=20ICE=20call |To:=22Christer=20Holmberg=20(JO/LMF)=22=20; X=v=3Dcisco.com=3B=20h=3DwxJpnBqIiqbJoy3BeczWImxmIcw=3D; b=k3rKHyJ/l7fGFSYICpnfWzNdZgxWQpGPaorrjX1yPDgOYfRdcuyQQICuPLNovjVGj03RPFAF 6DRk+GgW6KpXqsKO+Ylq2OnkagsXlaObVUaMcPN8c42/vp5dfnU4kz0Z; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This was one of the conclusions - folks want to see some use cases. I'm hoping to still accomplish much prior to the IETF meeting. So, if you have some in mind, please send them to the list! -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > As far as the m/c-lines issue is concerned, I have a feeling we'll need > some slides showing use-cases and impacts. It's probably one thing we > should spend some time discussing in San Diego (either in the WG > meeting, or by the bar). > > Regards, > > Christer > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 3. lokakuuta 2006 21:49 >>To: IETF MMUSIC WG >>Subject: [MMUSIC] Notes on October 3 ICE call >> >>ICE Call >>October 3, 2006 >> >>Attendees >> >>Jonathan Rosenberg >>Eric Rescorla >>Philip Matthews >>Derek MacDonald >>Tim Moore >>Eric Cooper >>Kevin Johns >>Colin Perkins >>Cullen Jennings >>Rohan Mahy >> >>Continued discussion on the question of what to do when the >>m/c-lines and the ICE results don't agree. A final poll at >>the end of the call reveals that the group remains split on >>the question. >> >>There does seem to be agreement on the idea of having one >>side choosing a pair and signaling it (rather than having >>each side pick its own candidate and use the resulting pair), >>and so the main issue is whether this is with STUN or SIP. >>There was also general agreement that making things easier >>for gateways was a good thing. Derek explained his use case >>for requiring triggered checks for gateways - when the other >>side is behind a one-way firewall. >> >>Next steps: >> >>* folks who are concerned about not following the SDP when it doesnt >> match the results of the ICE checks should post some concrete use >> cases for that >> >>* JDR said he'd think about a possible middle-ground approach and post >> on that before the next call >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 06 02:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViv5-0001PJ-65; Fri, 06 Oct 2006 02:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViv4-0001PE-76 for mmusic@ietf.org; Fri, 06 Oct 2006 02:10:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GViux-0008OV-KH for mmusic@ietf.org; Fri, 06 Oct 2006 02:10:50 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 874B78E0002; Fri, 6 Oct 2006 08:10:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 08:10:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 08:10:31 +0200 Received: from [131.160.36.18] (EH3I2003TGFCPET-131160036018.lmf.ericsson.se [131.160.36.18]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D7631249B; Fri, 6 Oct 2006 09:10:31 +0300 (EEST) Message-ID: <4525F357.7080404@ericsson.com> Date: Fri, 06 Oct 2006 09:10:31 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [MMUSIC] file transfer, moving forward References: <09a801c6e8a7$bf41f0b0$c5f0200a@amer.cisco.com> <45254EB2.8000804@nokia.com> In-Reply-To: <45254EB2.8000804@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 06:10:32.0058 (UTC) FILETIME=[211695A0:01C6E90E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "'Isomaki Markus \(Nokia-TP/Espoo\)'" , 'Aki Niemi' , Dan Wing , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, > 2) Putting all the attributes in a single line. I have no problems > with it. Can anyone think that we will break SDP by having very long > lines? I do not see the advantage of putting the attributes in a single line. If we use different lines, standard SDP rules apply to new unknown parameters, such as what to do if you do not understand them. If we define everything in a single line, we would need to replicate all those rules for the contents of our attributes. I believe there will be implementations that only care about certain attributes and will not implement all of them. Separate lines provide us with a more SDP-friendly way to deal with those situations. Cheers, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 06 03:15:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVjuO-0002Tr-MD; Fri, 06 Oct 2006 03:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVjuM-0002Th-QH for mmusic@ietf.org; Fri, 06 Oct 2006 03:14:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVjuD-0001MT-AH for mmusic@ietf.org; Fri, 06 Oct 2006 03:14:10 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C030DF5; Fri, 6 Oct 2006 09:13:54 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 09:13:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 09:13:53 +0200 Received: from [131.160.36.18] (EH3I2003TGFCPET-131160036018.lmf.ericsson.se [131.160.36.18]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 74B3527D2; Fri, 6 Oct 2006 10:13:53 +0300 (EEST) Message-ID: <45260230.2090300@ericsson.com> Date: Fri, 06 Oct 2006 10:13:52 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 07:13:53.0216 (UTC) FILETIME=[FAC14400:01C6E916] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Flemming Andreasen , "James M. Polk" , sdhesika@cisco.com Subject: [MMUSIC] SDP QoS Mechanism Identification X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, last time we presented this draft, Flemming had some concerns about its semantics. We have just submitted a new revision of the draft that tries and addresses Flemming's concerns. Now the result of the offer/answer exchange is a hint of which QoS mechanisms can be used because they are supported by the remote endpoint. However, it does not keep the endpoints from trying different mechanisms that may not be supported by the endpoint but may be supported by the network (e.g., thru an RSVP proxy). Until the draft appears in the official archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-polk-mmusic-qos-mechanism-identification-02.txt Let us know if this revision addresses your concerns. Cheers, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 06 04:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVkhw-0005lF-N3; Fri, 06 Oct 2006 04:05:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSjm-00074X-D0 for mmusic@ietf.org; Thu, 05 Oct 2006 08:54:06 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSjl-00071u-Q8 for mmusic@ietf.org; Thu, 05 Oct 2006 08:54:06 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k95Cs1Cm004387; Thu, 5 Oct 2006 15:54:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 15:54:01 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 15:54:00 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] file transfer, moving forward Date: Thu, 5 Oct 2006 15:53:59 +0300 Message-ID: In-Reply-To: <4524F9AF.1010803@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] file transfer, moving forward Thread-Index: AcboeVKrpPzK1x1fSiyDemaKSe3h1AAACyBg From: To: , X-OriginalArrivalTime: 05 Oct 2006 12:54:00.0991 (UTC) FILETIME=[5452DAF0:01C6E87D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-Mailman-Approved-At: Fri, 06 Oct 2006 04:05:23 -0400 Cc: aki.niemi@nokia.com, dwing@cisco.com, mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I agree with Miguel (and Aki). It is usually a good principle to utilize existing work, and in that sense message/external-body is tempting, and initially I thought we should adopt it. However, it seems that in this case the re-use would not make implementation or interoperability easier but actually more burdensome. Also the implications with SBCs/B2BUAs that inspect or rewrite SDP make me worried. So, based on this rationale, I would keep the current approach. Markus=20 =20 >-----Original Message----- >From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 >Sent: 05 October, 2006 15:25 >To: Gonzalo Camarillo >Cc: Niemi Aki (Nokia-NRC/Helsinki); mmusic@ietf.org; Dan Wing;=20 >Isomaki Markus (Nokia-SIR/Espoo) >Subject: Re: [MMUSIC] file transfer, moving forward > >I think simplicity should be taken into account. > >Additionally, if you want rapid deployment, it is easier to=20 >integrate the current solution in draft in current deployments=20 >(think of SBCs for example). > >It is true that the current solution is less elegant, but we=20 >need to balance between practicalities and elegance. > >/Miguel > >Gonzalo Camarillo wrote: >> Hi Aki, >>=20 >> I find the MIME-based proposal technically more elegant.=20 >However, you=20 >> are probably right that it raises the bar for implementers a little=20 >> higher than the solution based on SDP attributes. >>=20 >> We would like to hear further opinions on this. So far there has not=20 >> been support for the new approach. We would like to start=20 >working on a=20 >> new revision of the draft shortly and we need to know which approach=20 >> to use. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>=20 >> Aki Niemi wrote: >>> Inline. >>> >>> ext Miguel Garcia kirjoitti: >>>> We discussed the file transfer draft in Montreal, and Dan was=20 >>>> commenting about the possibility of using=20 >message/external-body (RFC >>>> 2046) as an external reference to the file (see the thread=20 >starting=20 >>>> at=20 >>>> http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html >>>> ). >>>> >>>> So, we (the authors) went through Dan's suggestion, and here is an=20 >>>> example of how a file transfer offer in SDP would look like if we=20 >>>> use message/external-body. I have highlighted where new tokens or=20 >>>> extended values are needed, to differentiate them from already=20 >>>> existing parameters. >>>> >>>> We like this idea, because it outsources from SDP the file=20 >>>> descriptor, besides, it reuses most of the Content-Disposition=20 >>>> already existing stuff. >>> >>> The problem I see is, you now only reuse the syntax, not the actual=20 >>> semantics of message/external-body. Normally, if I receive a MIME=20 >>> object with message/external-body, it will tell me what=20 >method to use=20 >>> for fetching the actual content of that object. >>> >>> In file transfer, this is not the case, since it's a push=20 >instead of=20 >>> a pull operation. So even if you had support for multipart and=20 >>> message/external-body, you'd need to implement totally new=20 >functionality. >>> >>>> We are looking for opinions and consensus of whether this=20 >is the way=20 >>>> to proceed. >>> >>> I don't like it. This change seems to only save a few lines of RFC=20 >>> text by referencing some already defined header fields, instead of=20 >>> defining them itself. >>> >>> But writing specifications is a sunk cost anyway, and we should not=20 >>> optimize that. instead we should optimize following these criteria: >>> >>> a) minimizing the lines of code required to implement the=20 >>> specification >>> b) maximizing the probability that interop is achieved by=20 >>> implementors of the specification >>> >>> This new approach, IMHO, does neither. >>> >>> Also, I suspect that using MIME multipart all but guarantees no=20 >>> existing middle box will work, and very few SIP=20 >implementations will=20 >>> know where to look for the SDP. In other words, this is not=20 >>> backwards-compatible (MIME multipart support is a SHOULD in SIP). >>> >>>> Here is the example. It is as complete as possible, so, in many=20 >>>> cases, we woon't be signaling all these metadada: >>>> >>>> INVITE ... Content-Type: multipart/related; boundary=3DABC >>>> >>>> --ABC Content-Type: application/sdp >>>> >>>> v=3D0 ... m=3Dmessage 7654 TCP/MSRP * >>>> a=3Dpath:msrp://atlanta.example.com:7654/jshA7we;tcp >>>> a=3Dfile-descriptor:cid:id1@example.com <---------- = extension >>> >>> Since you already need to define at least one new SDP=20 >attribute, and=20 >>> there's no way around that, then one way to limit this number is by=20 >>> reusing some of the already defined SDP fields to serve=20 >your purpose. >>> >>> For instance, the suggested file name could be carried in=20 >the s=3Dfield. >>> AFAIK, nobody uses it to really set the subject of the=20 >session; here,=20 >>> you could make it useful again. >>> >>> Also, the name file-descriptor is a terrible name, since=20 >that already=20 >>> has a well-defined meaning in computer programming. >>> >>> Cheers, >>> Aki >>> >>>> --ABC Content-type: message/external-body; access-type=3D"MSRP" >>>> <----------- new token Content-ID: >>>> >>>> Content-type: image/jpeg Content-ID: >>>> Content-Disposition: inline; filename=3D"My cool picture.jpg"; >>>> size=3D98320932; byte-range=3D80-100 <---- >>>> extension creation-date=3D"Mon, 15 May 2006 15:01:31 +03:00";=20 >>>> modification-date=3D"Mon, 16 May 2006 15:01:31 +03:00";=20 >>>> read-date=3D"Mon, >>>> 18 May 2006 15:01:31 +03:00"; icon=3D"cid:id3@alicepc.example.com"; >>>> <----------- extension >>>> hash=3Dsha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E <----- ext >>>> >>>> --ABC Content-type: image/jpeg; Content-ID: >>>> >>>> ...binary JPEG icon image ... >>>> >>>> --ABC-- >>>> >>>> >>>> Comments, please. >>>> >>>> /Miguel >>>> >>> >>> >>> >>=20 > >--=20 >Miguel A. Garcia tel:+358-50-4804586 >sip:miguel.garcia@neonsite.net >Nokia Research Center Helsinki, Finland > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 06 09:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVpjc-0000EU-JG; Fri, 06 Oct 2006 09:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVpja-0000EK-Qi for mmusic@ietf.org; Fri, 06 Oct 2006 09:27:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVpjX-0004AG-GJ for mmusic@ietf.org; Fri, 06 Oct 2006 09:27:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Oct 2006 09:27:23 -0400 X-IronPort-AV: i="4.09,272,1157342400"; d="scan'208"; a="105974675:sNHT53679200" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96DRNRj018775; Fri, 6 Oct 2006 09:27:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k96DRNDM019617; Fri, 6 Oct 2006 09:27:23 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 09:27:22 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 09:27:22 -0400 Message-ID: <452659BA.9020107@cisco.com> Date: Fri, 06 Oct 2006 09:27:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [MMUSIC] SDP QoS Mechanism Identification References: <45260230.2090300@ericsson.com> In-Reply-To: <45260230.2090300@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 13:27:22.0804 (UTC) FILETIME=[27E90740:01C6E94B] DKIM-Signature: a=rsa-sha1; q=dns; l=2399; t=1160141243; x=1161005243; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[MMUSIC]=20SDP=20QoS=20Mechanism=20Identification |To:Gonzalo=20Camarillo=20; X=v=3Dcisco.com=3B=20h=3DinPS5AUYawI1bYVOkKw6+2oyxfA=3D; b=lQSi7Jbsm0t8oz/tzPfkYin1QdM+6x9NBSZiX/zfU2fnI58FDO3h1O5fPs6zzGn/O6Hc6/Db 8NslZOIlxPEW0iuFz16P88vSs9U+t6Do77XZ/EMef1kJcV/ObCN8GRw/; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Flemming Andreasen , "James M. Polk" , mmusic , sdhesika@cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I don't have any conceptual problems with this draft. But I did find some technical/editorial issues with it: Ref [2] (sdp-new) is now RFC4566 There are problems meshing the syntax with that in 4566, at least in part because 4566 is pretty sloppy about how it defines syntax of attributes. Redefining 'attribute' as done here seems wrong. I defer to somebody more involved with SDP on the "right" way to do this. The best I can see is to give a syntax that doesn't reuse symbols from 4566, and concentrate on getting the iana considerations right. sec 4.2 implies that one might include a *set* of tokens for mechanisms and sec 5 shows examples of this. But they syntax only allows one per a-line. It seems likely that the same mechanisms would be used in both directions. It might be helpful to have a qos-mech-sendrecv that could be used when this is the case. In the iana considerations section, I gather the goal is to register the two attribute-field names, and then to register a single sub registry for qos mechanism tokens that applies to both fields. But I don't find anything in the registration for the attribute fields that links them to this new sub registry. Once again I find 4566 to be a bit sloppy in specifying the iana procedures for registration of attribute fields and values, so there is little guidance on how to do this correctly. Paul Gonzalo Camarillo wrote: > Hi, > > last time we presented this draft, Flemming had some concerns about its > semantics. We have just submitted a new revision of the draft that tries > and addresses Flemming's concerns. Now the result of the offer/answer > exchange is a hint of which QoS mechanisms can be used because they are > supported by the remote endpoint. However, it does not keep the > endpoints from trying different mechanisms that may not be supported by > the endpoint but may be supported by the network (e.g., thru an RSVP > proxy). > > Until the draft appears in the official archives, you can fetch it from: > > http://users.piuha.net/gonzalo/temp/draft-polk-mmusic-qos-mechanism-identification-02.txt > > > Let us know if this revision addresses your concerns. > > Cheers, > > Gonzalo > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 06 16:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVwjH-0006pi-H5; Fri, 06 Oct 2006 16:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVwjF-0006pO-Mb for mmusic@ietf.org; Fri, 06 Oct 2006 16:55:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVwjE-00072g-8q for mmusic@ietf.org; Fri, 06 Oct 2006 16:55:33 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2006 13:55:31 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="328929759:sNHT52889612" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96KtV8n015168 for ; Fri, 6 Oct 2006 13:55:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k96KtRbh014825 for ; Fri, 6 Oct 2006 13:55:31 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 13:55:26 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 13:55:25 -0700 Message-ID: <4526C2BD.4080409@cisco.com> Date: Fri, 06 Oct 2006 16:55:25 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 20:55:26.0091 (UTC) FILETIME=[BF9915B0:01C6E989] DKIM-Signature: a=rsa-sha1; q=dns; l=2149; t=1160168131; x=1161032131; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE-11=20now=20available; X=v=3Dcisco.com=3B=20h=3D5ilyKJFJEt+cAbM2PtvUKCRC8w0=3D; b=rBEA9dBF7SkzTlkUziJGzhqFda4s8pl7vEFRZ3eueDi/w1QHtLqG0+pY78c4XWWS47eS5pD5 8SkXAleeeqn6aHJiMb/502aIBeKl/MOD0Oib2ppjF5FB91XKehaovZd9; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [MMUSIC] ICE-11 now available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I've just submitted an update to ICE which reflects conclusions on some of the issues we've resolved so far. The primary one is on the formula for prioritization and this is the biggest change. I have done nothing in the draft regarding our ongoing debates on concluding ICE processing. Until the draft appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-11.txt It is my intent still to complete our discussions on the remaining ICE open issues and submit a -12 prior to IETF that represents consensus around all known open issues. Here are the specific changes in this version: * added new priority computation equations and updated examples based on them * defined separate check lists for each media stream; however the frozen algorithm remains as before, and will thus freeze all candidates in all but one of the check lists initially. That is, just because there are now check lists for each media stream, checks are not sent independently for each media stream. THe dependencies defined by the frozen algorithm are unchanged from -10 * note that component IDs generally have to go from 1 to 256 * fixed bug about whether peer derived type preferences are higher or lower than server reflexive - should be higher * clarified in the section on stun response processing that the validated pair will usually be different than the check itself * removed this feature whereby, when you received a packet, you only play it out if you had received a check on that candidate. This doesn't work with forking. * mention that ICE itself provides a form of implicit preconditions, but note that it has less functionality then the preconditions spec. * added a definition for Component THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Oct 07 06:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW9F6-0006if-FA; Sat, 07 Oct 2006 06:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW9F5-0006iZ-B0 for mmusic@ietf.org; Sat, 07 Oct 2006 06:17:15 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW9F4-0004Lz-1B for mmusic@ietf.org; Sat, 07 Oct 2006 06:17:15 -0400 Received: by nf-out-0910.google.com with SMTP id l23so1442786nfc for ; Sat, 07 Oct 2006 03:17:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=lBeNiyZrE0fDm/HqRIEPKJvFxpxqBFcirIzI9MT/bmxBpQNyCjVypRvmHshU9PWu1XMGe0S1b949ll1eweiqJGSd1B5qtmQ3OaNAhBD2oLE3UGXtFY/G54V4koqdL5QrAM1fhXQhSslwQe4J283Ig8olWl+eEptpnHDPBD9Xh64= Received: by 10.82.142.9 with SMTP id p9mr268392bud; Sat, 07 Oct 2006 03:17:12 -0700 (PDT) Received: by 10.82.119.10 with HTTP; Sat, 7 Oct 2006 03:17:12 -0700 (PDT) Message-ID: <1398a7990610070317r31b4522cxdf2c4e0293d565ec@mail.gmail.com> Date: Sat, 7 Oct 2006 15:47:12 +0530 From: "Pradip Gajjar" To: mmusic MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [MMUSIC] Muticast in RTSP. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641859139==" Errors-To: mmusic-bounces@ietf.org --===============1641859139== Content-Type: multipart/alternative; boundary="----=_Part_49887_20663226.1160216232680" ------=_Part_49887_20663226.1160216232680 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I have one doubt on multicast mechanism of transport in RTSP. Please refer following example of SETUP request. C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 2 * Transport: RTP/AVP;multicast // Here it says it is multicast session but client doesn't mention client port.* M->C: RTSP/1.0 200 OK CSeq: 2 * Transport: RTP/AVP;multicast;destination=224.2.0.1;port=3456-3457;ttl=16 //here server responds with the port no.* Session: 0456804596 Now session is established but how multicast router would be able to send the response to the client as client hasn't published it's port no in SETUP request? Rgrds, Pradip Gajjar. ------=_Part_49887_20663226.1160216232680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
I have one doubt on multicast mechanism of transport in RTSP.
Please refer following example of SETUP request.

C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0

      CSeq: 2

      Transport: RTP/AVP;multicast    // Here it says it is multicast session but client doesn't mention client port.

M->C: RTSP/1.0 200 OK

      CSeq: 2

      Transport: RTP/AVP;multicast;destination=224.2.0.1;port=3456-3457;ttl=16   //here server responds with the port no.

      Session: 0456804596

 

Now session is established but how multicast router would be able to send the response to the client as client hasn't published it's port no in SETUP request?

 

Rgrds,

Pradip Gajjar.

 

------=_Part_49887_20663226.1160216232680-- --===============1641859139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1641859139==-- From mmusic-bounces@ietf.org Sun Oct 08 16:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeou-0003z0-WB; Sun, 08 Oct 2006 16:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeot-0003xv-Hh for mmusic@ietf.org; Sun, 08 Oct 2006 16:00:19 -0400 Received: from jayblue.broadware.com ([67.91.201.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWenj-0006um-IS for mmusic@ietf.org; Sun, 08 Oct 2006 15:59:09 -0400 Received: from andrewlaptop (adsl-69-226-233-110.dsl.pltn13.pacbell.net [69.226.233.110]) by jayblue.broadware.com (8.13.3/8.13.3) with ESMTP id k98Jwvc6023309; Sun, 8 Oct 2006 12:58:57 -0700 (PDT) From: "Andrew Large" To: "'Pradip Gajjar'" , "'mmusic'" Subject: RE: [MMUSIC] Muticast in RTSP. Date: Sun, 8 Oct 2006 12:58:23 -0700 Organization: Broadware Technologies Message-ID: <004c01c6eb14$1c941d60$4101a8c0@andrewlaptop> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <1398a7990610070317r31b4522cxdf2c4e0293d565ec@mail.gmail.com> Importance: Normal X-Virus-Scanned: ClamAV 0.88.2/2011/Sun Oct 8 11:07:55 2006 on jayblue.broadware.com X-Virus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1061490022==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1061490022== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C6EAD9.7036CC00" This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C6EAD9.7036CC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hmmm. Maybe I'm not understanding your question properly, but here goes... Only one port pair is needed here. When the client gets the setup response, it creates a pair of UDP sockets, binds them to the given addresses (including port), and joins the appropriate multicast group. The multicast group join is what informs the router to forward the packets to the client host. The bind is what distributes the received packets to the right sockets on the client host. -- Andrew Large alarge@broadware.com -----Original Message----- From: Pradip Gajjar [mailto:rtp.discussion@gmail.com] Sent: Saturday, October 07, 2006 3:17 am To: mmusic Subject: [MMUSIC] Muticast in RTSP. Hi All, I have one doubt on multicast mechanism of transport in RTSP. Please refer following example of SETUP request. C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP;multicast // Here it says it is multicast session but client doesn't mention client port. M->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;multicast;destination=224.2.0.1;port=3456-3457;ttl=16 //here server responds with the port no. Session: 0456804596 Now session is established but how multicast router would be able to send the response to the client as client hasn't published it's port no in SETUP request? Rgrds, Pradip Gajjar. ------=_NextPart_000_004D_01C6EAD9.7036CC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hmmm.  Maybe I'm not understanding your question properly, = but here=20 goes...
 
Only one port pair is needed here.  When the client gets = the setup=20 response, it creates a pair of UDP sockets, binds them to the given = addresses=20 (including port), and joins the appropriate multicast = group.
 
The multicast group join is what informs the router to forward = the=20 packets to the client host.  The bind is what distributes the = received=20 packets to the right sockets on the client host.
 
 

--
Andrew Large
alarge@broadware.com

-----Original Message-----
From: = Pradip Gajjar=20 [mailto:rtp.discussion@gmail.com]
Sent: Saturday, October = 07, 2006=20 3:17 am
To: mmusic
Subject: [MMUSIC] Muticast in=20 RTSP.

Hi All,
 
I have one doubt on multicast mechanism of transport in = RTSP.
Please refer following example of SETUP request.

C->M: SETUP rtsp://live.example.com/concert/audio=20 RTSP/1.0

      CSeq: 2

      Transport:=20 RTP/AVP;multicast    // Here it says it is multicast = session=20 but client doesn't mention client port.

M->C: RTSP/1.0 200 OK

      CSeq: 2

      Transport:=20 RTP/AVP;multicast;destination=3D224.2.0.1;port=3D3456-3457;ttl=3D16 &n= bsp; //here=20 server responds with the port no.

      Session: = 0456804596

 

Now session is established but how multicast router = would be=20 able to send the response to the client as client hasn't published = it's port=20 no in SETUP request?

 

Rgrds,

Pradip Gajjar.

 

------=_NextPart_000_004D_01C6EAD9.7036CC00-- --===============1061490022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1061490022==-- From mmusic-bounces@ietf.org Mon Oct 09 15:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX19U-000104-6a; Mon, 09 Oct 2006 15:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX191-000062-6e; Mon, 09 Oct 2006 15:50:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX191-0005fD-3J; Mon, 09 Oct 2006 15:50:35 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GX18y-0004Sk-E8; Mon, 09 Oct 2006 15:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 515A02AC6A; Mon, 9 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX18U-0007Qe-2W; Mon, 09 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --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 : Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-11.txt Pages : 70 Date : 2006-10-9 This document describes a protocol for Network Address Translator (NAT) traversal for multimedia session signaling protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Simple Traversal Underneath NAT (STUN) protocol, applying its binding discovery and relay usages, in addition to defining a new usage for checking connectivity between peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-ice-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-ice-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-9113733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-9113733.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Mon Oct 09 16:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1iJ-0001dk-Jj; Mon, 09 Oct 2006 16:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1iI-0001d2-FV for mmusic@ietf.org; Mon, 09 Oct 2006 16:27:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX1iG-0006bL-53 for mmusic@ietf.org; Mon, 09 Oct 2006 16:27:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Oct 2006 13:26:56 -0700 X-IronPort-AV: i="4.09,285,1157353200"; d="scan'208"; a="45413041:sNHT53914856" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99KQqdb022009 for ; Mon, 9 Oct 2006 16:26:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k99KQjDO006120 for ; Mon, 9 Oct 2006 16:26:52 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 16:26:50 -0400 Received: from [161.44.55.73] ([161.44.55.73]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 16:26:50 -0400 Message-ID: <452AB08A.8090304@cisco.com> Date: Mon, 09 Oct 2006 16:26:50 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 20:26:50.0942 (UTC) FILETIME=[40875DE0:01C6EBE1] DKIM-Signature: a=rsa-sha1; q=dns; l=1120; t=1160425612; x=1161289612; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20call=20is=20ON=20for=20October=2010=201-2pm=20EST |To:IETF=20MMUSIC=20WG=20; X=v=3Dcisco.com=3B=20h=3DvNeH+TqmEWVXkEI+dCEEZRzdM7I=3D; b=zjCrcm2nDsMJxewV0BWEOfDr8Rt2ziKCbnFkVKu4UbWLdvBsGccz9CVMZoYK7u04kIEgtDwf qLFXlQ8g9Qi8vYVxZWn+pX6Mnp0Jqq0Yv0El2V8B9UpPHs15bukUcqU6; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [MMUSIC] ICE call is ON for October 10 1-2pm EST X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Agenda: Continue discussion from last time. Join the Web Conference 1. Go to: http://meetingplace.cisco.com/join.asp?2203261 2. Fill in the My Name is field then click Attend Meeting 3. Accept any security warnings you receive and wait for the Meeting Room to initialize Join the Voice Conference 1. From the Meeting Room, click on CONNECT (top left pane) and follow the instructions on how to have the system call you or simply follow the Voice only Conference instructions below TO ATTEND A VOICE ONLY CONFERENCE All Users 1. Dial into Cisco MeetingPlace (see Local & Global Access Numbers link above) 2. Press 1 to attend the meeting 3. Follow the prompts to enter the Meeting ID 2203261 and join the meeting This works best from Internet Explorer. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 09 21:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6IG-00067T-FI; Mon, 09 Oct 2006 21:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6IE-00066Q-Rn; Mon, 09 Oct 2006 21:20:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX6ID-0003T7-In; Mon, 09 Oct 2006 21:20:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 18:20:25 -0700 X-IronPort-AV: i="4.09,286,1157353200"; d="scan'208"; a="329713477:sNHT50179068" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9A1KOt1030125; Mon, 9 Oct 2006 18:20:24 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9A1KHbF014958; Mon, 9 Oct 2006 18:20:18 -0700 (PDT) From: "Dan Wing" To: , Date: Mon, 9 Oct 2006 18:20:15 -0700 Message-ID: <0e8a01c6ec0a$41ac3230$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbpgU2uvkzemeoxQu+2uMse5KFQcQChqBQQ In-Reply-To: DKIM-Signature: a=rsa-sha1; q=dns; l=1116; t=1160443224; x=1161307224; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:avt-profile-savpf-07=20and=20duplicate=20m-lines; X=v=3Dcisco.com=3B=20h=3DRP/pT23pMjW4LwBmBgaV42VZMD0=3D; b=mevRYy51BVDtNQP3c09AJaPo+RFxQ/pgtA84vDREH8hppablbKfJ1L4mVAyqLjrnjZZgqURz 1JKkiYKmFDWd3s0v+SW5tOQCo3Tm7TjiNuHczrSdAcxBzDrco+C6RZLw; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mmusic@ietf.org, avt@ietf.org, iesg@ietf.org Subject: [MMUSIC] avt-profile-savpf-07 and duplicate m-lines X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I noticed draft-ietf-avt-profile-savpf-07.txt was just posted. In it, example 4 and 5 on pages 11-13 shows RTP and SRTP being offered on the same port. Example 5 clearly highlights the port overloading, but example 4 does not highlight its port overloading; is this an error in the document? (note there are also two "Example 5", one starting on page 12 and another starting on page 13). Based on the differences between -06 and -07 and the DISCUSS that I see on the datatracker, this change was done due to IESG comments. Neither of the two individual submissions related to this problem -- draft-andreasen-mmusic-sdp-capability-negotiation-00.txt or draft-kaplan-mmusic-best-effort-srtp-00.txt -- use the syntax of Example 4 and Example 5 of -avt-profile-savpf. It is my understanding that interoperability problems exist with deployed equipment when it encounters overloaded media lines as shown in Example 4 and 5. Have the authors considered removing both examples 4 and 5, or at least removing the UDP port overloading that is shown on the media lines of those two examples? -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 10 06:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXElM-0002Zt-Sj; Tue, 10 Oct 2006 06:23:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXElL-0002Zo-SW for mmusic@ietf.org; Tue, 10 Oct 2006 06:23:03 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXElK-0004Pb-EO for mmusic@ietf.org; Tue, 10 Oct 2006 06:23:03 -0400 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k9AAN1GQ011619; Tue, 10 Oct 2006 12:23:02 +0200 Received: from [172.25.79.32] ([172.25.79.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006101012225713:6029 ; Tue, 10 Oct 2006 12:22:57 +0200 Message-ID: <452B7480.10203@alcatel.fr> Date: Tue, 10 Oct 2006 12:22:56 +0200 From: Thomas.Levy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.7) Gecko/20050414 X-Accept-Language: fr, en MIME-Version: 1.0 To: mmusic@ietf.org X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/10/2006 12:22:57, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/10/2006 12:22:59, Serialize complete at 10/10/2006 12:22:59 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Thomas FROMENT , Gonzalo.Camarillo@ericsson.com Subject: [MMUSIC] Interworking ICE/SBC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hello all, We identified technical issues related to the deployment of SIP services within NATed networks when ICE and SBC are used simultaneously for NAT traversal. Thus, we would like to have the opinion from the MMUSIC/SIP community about the subject and the best way to solve these issues? Here is the point: We consider that users (and their SIP terminals) are using a NATed IP address. The SIP Service Provider of the users may be different from the ISP of the users. Two approaches for NAT traversal are deployed : On one side, ICE is deployed partly on some UAs. On the other side, a Session Border Controller (SBC) deployed as the proxy for NAT traversal. For instance, the service provider have a SBC already deployed and it wants to introduce new terminals with ICE (for inst: to avoid some media flows to go through its network). In this example, when a user (with UA supporting ICE) intitiates a call, the UA and the SBC on the path are attempting to change the SIP messages (in particular the SDP) for NAT traversal. But, for the moment, it results in an unpredictable behavior for NAT traversal. Depending on the SBC implementation, the call may be rejected, accepted with no working media, or even accepted with media streams being relayed on multiple successive media relays. In both cases, the result is less optimal than for a single solution (ICE or SBC). This is why we would like to discuss the best way to make ICE actually work, even if a SBC is on the path. Please note that this point also applies with 2 users located in different domains. Your opinion is welcome. Sincerely, Thomas LEVY & Thomas FROMENT _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 10 08:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGKt-0003fN-1a; Tue, 10 Oct 2006 08:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGKr-0003bz-Rf for mmusic@ietf.org; Tue, 10 Oct 2006 08:03:49 -0400 Received: from lb01nat08.inode.at ([62.99.145.8] helo=mx.inode.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXGKp-0003PT-Et for mmusic@ietf.org; Tue, 10 Oct 2006 08:03:49 -0400 Received: from [195.58.170.124] (port=9247 helo=inode.at) by smartmx-08.inode.at with smtp (Exim 4.50) id 1GXGKo-0000Ll-LG; Tue, 10 Oct 2006 14:03:46 +0200 Received: from 194.113.59.79 (proxying for 146.112.136.79) (SquirrelMail authenticated user franz.edler@inode.at) by webmail.inode.at with HTTP; Tue, 10 Oct 2006 14:03:46 +0200 (CEST) Message-ID: <194.113.59.79.1160481826.wm@webmail.inode.at> Date: Tue, 10 Oct 2006 14:03:46 +0200 (CEST) Subject: Re: [MMUSIC] Interworking ICE/SBC From: To: In-Reply-To: <452B7480.10203@alcatel.fr> References: <452B7480.10203@alcatel.fr> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mmusic@ietf.org, Thomas.Froment@alcatel.fr, Gonzalo.Camarillo@ericsson.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, > In this example, when a user (with UA supporting ICE) intitiates a call, > the UA and the SBC on the path are attempting to change the SIP > messages (in particular the SDP) for NAT traversal. But, for the > moment, it results in an unpredictable behavior for NAT traversal. >From my point, this looks like a problem of the SBC. ICE is defined to be compatible with UAs not supporting ICE. If the SBC does not have a strategy how to cope with ICE it should ignore it. Than the UA will fallback to normal (non-ICE) behaviour. regards Franz _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 10 08:45:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGyO-00066n-Sg; Tue, 10 Oct 2006 08:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGyN-00066b-OL for mmusic@ietf.org; Tue, 10 Oct 2006 08:44:39 -0400 Received: from web86005.mail.ird.yahoo.com ([217.146.188.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXGyM-0001zW-7q for mmusic@ietf.org; Tue, 10 Oct 2006 08:44:39 -0400 Received: (qmail 96994 invoked by uid 60001); 10 Oct 2006 12:44:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btopenworld.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wSjgkpf5dCoDV0R1WgC1RRbkeTqsZUTEMP/65zlpB+TJZ7ZEybwxckfmotCM+ugXdDYKEmzjoSB+kCpDShmJpun9J18xiINB5tQF7s3Czm48Oc4gYNh0g3mP5PAE7kDS1/cLKotyiM1ps6rpAJZbjo3Zxq9R3Y9P2dpX0EMqYlU= ; Message-ID: <20061010124437.96992.qmail@web86005.mail.ird.yahoo.com> Received: from [194.70.154.226] by web86005.mail.ird.yahoo.com via HTTP; Tue, 10 Oct 2006 13:44:37 BST Date: Tue, 10 Oct 2006 13:44:37 +0100 (BST) From: Subject: Re: [MMUSIC] Interworking ICE/SBC To: mmusic@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0959158550==" Errors-To: mmusic-bounces@ietf.org --===============0959158550== Content-Type: multipart/alternative; boundary="0-1969487887-1160484277=:95748" Content-Transfer-Encoding: 8bit --0-1969487887-1160484277=:95748 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit The problem here goes back to the old question of what the ICE UA chooses as it's initial "in use" candidate (i.e. puts in m/c line). If it were a relayed candidate, then if symmetric RTP is enforced, then it has to ensure it sends from this address. This means via the relay. So even if the ICE UA drops to non-UA behaviour it will have to send via it's relay, which is non optimal. Even worse, if the UA and the network device requiring to take the media (probably not a Service Providers SBC but other enterprise policy device) are co-located. Then media connectivity may fail (as media may go out of a firewall via the relay and then fail when trying to comeback in, in native form) . If I'm correct,I believe this is where the discussions about "ICE and open Internet devices" come into play. In this case SBCs would always appear to ICE UAs as a fellow ICE client, but only advertising it's interface as the only candidate. Ensuring the only path discovered by the ICE UA will be towards the SBC and maybe the most optimal (if ICE candidate checks complete fully). This discussion also introduces the concept of a "passive" client, which reduces the implementation complexity required (SBC may only have to respond to connectivity checks and also not have to re-invite). Cheers, Pete L. -----Original Message----- From: franz.edler@inode.at [mailto:franz.edler@inode.at] Sent: 10 October 2006 13:04 To: Thomas.Levy@alcatel.fr Cc: mmusic@ietf.org; Thomas.Froment@alcatel.fr; Gonzalo.Camarillo@ericsson.com Subject: Re: [MMUSIC] Interworking ICE/SBC Hi, > In this example, when a user (with UA supporting ICE) intitiates a call, > the UA and the SBC on the path are attempting to change the SIP > messages (in particular the SDP) for NAT traversal. But, for the > moment, it results in an unpredictable behavior for NAT traversal. >From my point, this looks like a problem of the SBC. ICE is defined to be compatible with UAs not supporting ICE. If the SBC does not have a strategy how to cope with ICE it should ignore it. Than the UA will fallback to normal (non-ICE) behaviour. regards Franz _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --0-1969487887-1160484277=:95748 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
The problem here goes back to the old question of what the ICE UA chooses as it's initial "in use" candidate (i.e. puts in m/c line). If it were a relayed candidate, then if symmetric RTP is enforced, then it has to ensure it sends from this address. This means via the relay. So even if the ICE UA drops to non-UA behaviour it will have to send via it's relay, which is non optimal. Even worse, if the UA and the network device requiring to take the media (probably not a Service Providers SBC but other enterprise policy device) are co-located. Then media connectivity may fail (as media may go out of a firewall via the relay and then fail when trying to comeback in, in native form) .

If I'm correct,I believe this is where the discussions about "ICE and open Internet devices" come into play. In this case SBCs would always appear to ICE UAs as a fellow ICE client, but only advertising it's interface as the only candidate. Ensuring the only path discovered by the ICE UA will be towards the SBC and maybe the most optimal (if ICE candidate checks complete fully). This discussion also introduces the concept of a "passive" client, which reduces the implementation complexity required (SBC may only have to respond to connectivity checks and also not have to re-invite). 

Cheers,

Pete L.

-----Original Message-----
From: franz.edler@inode.at [mailto:franz.edler@inode.at]
Sent: 10 October 2006 13:04
To: Thomas.Levy@alcatel.fr
Cc: mmusic@ietf.org; Thomas.Froment@alcatel.fr; Gonzalo.Camarillo@ericsson.com
Subject: Re: [MMUSIC] Interworking ICE/SBC

Hi,

> In this example, when a user (with UA supporting ICE) intitiates a call,
>  the UA and the SBC on the path are attempting to change the SIP
> messages  (in particular the SDP) for NAT traversal. But, for the
> moment, it  results in an unpredictable behavior for NAT traversal.

>From my point, this looks like a problem of the SBC. ICE is defined to be
compatible with UAs not supporting ICE. If the SBC does not have a
strategy how to cope with ICE it should ignore it. Than the UA will
fallback to normal (non-ICE) behaviour.

regards
Franz



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

--0-1969487887-1160484277=:95748-- --===============0959158550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0959158550==-- From mmusic-bounces@ietf.org Tue Oct 10 11:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJL1-0001KI-CQ; Tue, 10 Oct 2006 11:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJL0-0001KC-Sn for mmusic@ietf.org; Tue, 10 Oct 2006 11:16:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJKw-0008Tw-99 for mmusic@ietf.org; Tue, 10 Oct 2006 11:16:10 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 10 Oct 2006 08:16:01 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AY8CAJ9VK0U X-IronPort-AV: i="4.09,290,1157353200"; d="scan'208"; a="1857250289:sNHT386929252" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9AFG1EH031291 for ; Tue, 10 Oct 2006 08:16:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9AFG1bF014639 for ; Tue, 10 Oct 2006 08:16:01 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 08:16:01 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 08:16:01 -0700 Message-ID: <452BB930.9000408@cisco.com> Date: Tue, 10 Oct 2006 11:16:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 15:16:01.0304 (UTC) FILETIME=[FEE43180:01C6EC7E] DKIM-Signature: a=rsa-sha1; q=dns; l=6504; t=1160493361; x=1161357361; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Compromise=20proposal=20for=20ICE=20finishing=20algorithm; X=v=3Dcisco.com=3B=20h=3DQo0xSfmrPjek1qV7yOEA6Vtvy94=3D; b=Tp7NTrCvyetgRPvQHiC4VcnpXUVd6OckUm6xTB+r/63n0U0k7hyjg5DtBetMbhAIoTMWEmOK LrgyPCzw0rin1/WSAww2qamZ+Kq6zyyGAlALmeeUrltLF3UFIS+tC0Qc; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [MMUSIC] Compromise proposal for ICE finishing algorithm X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I've been considering this issue about how to have ICE finish over the last week. I've come up with a compromise proposal which I hope works for everyone. The proposal has the following properties: * has one agent acting as controlling, and that agent selects the final pairs that get used and signals those pairs through STUN, allowing for the forwards compatibility we are anxious to have * requires nothing more than a two more bits to be added to the STUN messaging * has no additional latency for call setup as long as the agents are using the default selection algorithm (highest priority pairs that succeed get used) * uses the candidates in the m/c-line always but only if they worked; if checks through them failed, the one selected by the STUN signaling is used * should interoperate with existing SBC and SIP ALG; see below for caveats * Will 'bypass' faulty SBC and ALG in cases where their suggested media paths don't work. For example, if a SIP ALG is broken and doesn't hairpin properly, and both endpoints are behind the same NAT/ALG, they'll take the direct path * relieves PSTN gateways of the responsibility for ever having to generate a re-invite, compute and maintain a valid list. However they would still perform checks. Inter-GW calls would not require a re-invite. All of this comes at the cost of complexity, and it centers around this bigger question of whether it is a requirement for ICE to help calls work in cases where there are SBC or ALG 'in the way'. Some folks have expressed a strong opinion that it should, though this is far from unanimous. The high level approach is a synthesis of what has been suggested throughout the various discussions. Once the offer/answer exchanges are done, each agent checks to see if there is a candidate line for the m/c-line. If there isn't, each agent adds the address and port in the m/c-line as a candidiate, and assigns it the highest priority (see below on exactly how). Fortunately, as of ICE-10, the username/passwords are a function of the media stream and NOT individual candidates, so the username and password are known. This remote candidate is marked as being of a special type, which I'll call 'inserted' for now. After the offer/answer exchange, one agent takes the role of 'controlling'. This will be the agent which had the most number of candidates across all media streams. If it was a tie, the controlling agent is the offerer. The controlling agent gets to decide when the checks finish and what the selected pairs are. However it is somewhat constrained in that, if there was an inserted candidate, that one has to be used if it validated. When the controlling agent selects a pair to be used, it includes a flag in a STUN check for that pair which indicates that this is the pair that was selected. The non-controlling agent will use the resulting pair if and only if it has successfully completed a check in the reverse direction. If multiple checks succeed with the flag set, the highest priority one which worked is used. The reason it gets specified this way is that it allows you to avoid an extra set of checks just to indicate you are done. An implementation which just wants to use the 'highest priority' selection algorithm in ICE-10 would set the flag in all checks it does for the last component of each media stream. As soon as one completes, it would get used. However, an agent looking to use a more complex algorithm would omit the flags initially, perform checks, and when it decides, redo checks for the selected pairs. This way, the latency penalty on setup comes only for implementations doing something more complex than the baseline. Another important aspect of the checks is this. When an agent receives a STUN check, and the source address of the Binding Request matches an inserted candidate, the STUN resposne contains a flag informing the client that this mapped address was an inserted one. This alerts the client that this is not a 'normal' peer derived address, but rather one that was forcefully inserted by an intermediary. If that candidate gets selected (and it probably will as its highest priority), when the agent does the reinvite - it doesnt actually place this addess into the m/c-line. Rather, it places whatever it put in the previous offer or answer. Without this feature, I think there will be interoperability problems with existing SBCs. In particular, without it, the re-invites would convey, from the UAC and UAS, the transport addresses assigned by the SBCs themselves. I fear that this reinvite will seriously confuse existing SBC. So, when the re-invite comes, if the m/c-lines match the selected pairs, great. If not, they get used if and only if the m/c-lines were already validated by checks. If the m/c-line is known as a candidate, but didn't validate, it is NOT used. If the m/c-line in the re-invite is new (meaning its not a known candidate), a check is immediately performed for it, and then as above it is used if it works, otherwise not. Another thing - I believe the re-INVITE can be skipped if the m/c-lines would be unchanged from the previous offer/answer. This makes ICE nice for inter-gateway operation since you'll never need a re-invite there. However you'd still have checks, which is a good thing I think. I worked through some call flows for this, and it works with SIP ALG and SBCs under the following assumptions: * If a SIP ALG sees an SDP from the inside to the outside, but the m/c-line is NOT an internal address, it leaves the m/c-line alone. I don't know if this assumption is always true, but if not, ICE will have serious problems through such ALG no matter what we do. * An SBC will pass STUN packets as if they were RTP packets In terms of the priority for the inserted candidates, the idea is to reserve the largest type preference value, and use that only for inserted candidates. Indeed the astute reader will note that I already left provision for that in ICE-11. We'll discuss on the call today. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 10 11:18:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJNC-0001tD-Pc; Tue, 10 Oct 2006 11:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJNA-0001t1-M2 for mmusic@ietf.org; Tue, 10 Oct 2006 11:18:25 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJN9-0000fB-7q for mmusic@ietf.org; Tue, 10 Oct 2006 11:18:24 -0400 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k9AFIM7M023693; Tue, 10 Oct 2006 17:18:22 +0200 Received: from [172.25.79.32] ([172.25.79.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006101017181772:9954 ; Tue, 10 Oct 2006 17:18:17 +0200 Message-ID: <452BB9BA.2040707@alcatel.fr> Date: Tue, 10 Oct 2006 17:18:18 +0200 From: Thomas.Levy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.7) Gecko/20050414 X-Accept-Language: fr, en MIME-Version: 1.0 To: franz.edler@inode.at Subject: Re: [MMUSIC] Interworking ICE/SBC References: <452B7480.10203@alcatel.fr> <194.113.59.79.1160481826.wm@webmail.inode.at> In-Reply-To: <194.113.59.79.1160481826.wm@webmail.inode.at> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/10/2006 17:18:17, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/10/2006 17:18:19 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mmusic@ietf.org, Thomas.Froment@alcatel.fr, Gonzalo.Camarillo@ericsson.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Franz, I agree that it is mainly the responsability for the SBC to determine=20 that for instance it should not modify ICE processing. However, for the moment, SBCs are simply not aware of ICE!!! Thus, we could imagine a mechanism that allows SBC to detect that a=20 terminal uses ICE (even if the sdp is encrypted ;-) ) Thomas franz.edler@inode.at a =E9crit : >Hi, > > =20 > >>In this example, when a user (with UA supporting ICE) intitiates a call, >> the UA and the SBC on the path are attempting to change the SIP >>messages (in particular the SDP) for NAT traversal. But, for the >>moment, it results in an unpredictable behavior for NAT traversal. >> =20 >> > >From my point, this looks like a problem of the SBC. ICE is defined to be >compatible with UAs not supporting ICE. If the SBC does not have a >strategy how to cope with ICE it should ignore it. Than the UA will >fallback to normal (non-ICE) behaviour. > >regards >Franz > > > =20 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 10 13:58:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLrP-0007k5-9J; Tue, 10 Oct 2006 13:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLrN-0007gk-LN for mmusic@ietf.org; Tue, 10 Oct 2006 13:57:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXLrM-0003YA-90 for mmusic@ietf.org; Tue, 10 Oct 2006 13:57:45 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Oct 2006 10:57:43 -0700 X-IronPort-AV: i="4.09,291,1157353200"; d="scan'208"; a="329988661:sNHT112622374" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9AHvhno007439; Tue, 10 Oct 2006 10:57:43 -0700 Received: from [10.10.254.113] (sjc-vpn5-194.cisco.com [10.21.88.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9AHvfOV028112; Tue, 10 Oct 2006 10:57:42 -0700 (PDT) In-Reply-To: <452B7480.10203@alcatel.fr> References: <452B7480.10203@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [MMUSIC] Interworking ICE/SBC Date: Tue, 10 Oct 2006 10:57:35 -0700 To: Thomas.Levy@alcatel.fr X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2064; t=1160503063; x=1161367063; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[MMUSIC]=20Interworking=20ICE/SBC; X=v=3Dcisco.com=3B=20h=3DZGxJQpLVSuyUJvCW7s1cYvX+/jY=3D; b=kX5h8++7UEMd7SAEKPX5VdRfI/HTk1ODKjIe+8nQtXj6PoxzRkH1VUWVKgeXXu7eMan5H91m /ASOrAFSl/PRES77Hak502jYp118SK9PfhXnTi3p+tOJwney7N0WUxTg; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mmusic@ietf.org, Thomas FROMENT , Gonzalo.Camarillo@ericsson.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Could you please clarify what you mean by SBC in this case. Do you mean a B2BUA with a media relay? On Oct 10, 2006, at 3:22 AM, Thomas.Levy@alcatel.fr wrote: > Hello all, > > We identified technical issues related to the deployment of SIP > services within NATed networks when ICE and SBC are used > simultaneously for NAT traversal. Thus, we would like to have the > opinion from the MMUSIC/SIP community about the subject and the > best way to solve these issues? > > Here is the point: > We consider that users (and their SIP terminals) are using a NATed > IP address. > The SIP Service Provider of the users may be different from the ISP > of the users. > Two approaches for NAT traversal are deployed : > On one side, ICE is deployed partly on some UAs. > On the other side, a Session Border Controller (SBC) deployed as > the proxy for NAT traversal. > > For instance, the service provider have a SBC already deployed and > it wants to introduce new terminals with ICE (for inst: to avoid > some media flows to go through its network). > In this example, when a user (with UA supporting ICE) intitiates a > call, the UA and the SBC on the path are attempting to change the > SIP messages (in particular the SDP) for NAT traversal. But, for > the moment, it results in an unpredictable behavior for NAT > traversal. Depending on the SBC implementation, the call may be > rejected, accepted with no working media, or even accepted with > media streams being relayed on multiple successive media relays. In > both cases, the result is less optimal than for a single solution > (ICE or SBC). > This is why we would like to discuss the best way to make ICE > actually work, even if a SBC is on the path. > Please note that this point also applies with 2 users located in > different domains. > Your opinion is welcome. > > Sincerely, > > Thomas LEVY & Thomas FROMENT > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 10 15:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN92-0006k8-SO; Tue, 10 Oct 2006 15:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8q-0006Se-2s for mmusic@ietf.org; Tue, 10 Oct 2006 15:19:52 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMuB-0000lF-Tk for mmusic@ietf.org; Tue, 10 Oct 2006 15:04:45 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9AJ4hoi032760 for ; Tue, 10 Oct 2006 22:04:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 22:04:43 +0300 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 22:04:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Compromise proposal for ICE finishing algorithm Date: Tue, 10 Oct 2006 22:03:40 +0300 Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D000880227D5E3@esebe104.NOE.Nokia.com> In-Reply-To: <452BB930.9000408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Compromise proposal for ICE finishing algorithm Thread-Index: Acbsf7uxeEURr8cDRsKbNHj+8l6UGgAFrlxg From: To: X-OriginalArrivalTime: 10 Oct 2006 19:04:42.0841 (UTC) FILETIME=[F1909490:01C6EC9E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, all in all this proposal looks good. Some comments: On 10 October, 2006 Jonathan Rosenberg wrote: >After the offer/answer exchange, one agent takes the role of=20 >'controlling'. This will be the agent which had the most=20 >number of candidates across all media streams. If it was a=20 >tie, the controlling agent is the offerer. The controlling=20 what if a comedia style approach would be used here? Offerer could advertise willingness to be in the 'controlling' role. This would seem more robust approach for supporting simple ICE implementation=20 at gateways -- these boxes could then advertise themselves as=20 passive (not capable of being in the 'controlling' ICE role). Relying on low number of candidates at gateways seems somewhat brittle. [inserted candidate] >forcefully inserted by an intermediary. If that candidate gets=20 >selected (and it probably will as its highest priority), when=20 >the agent does the reinvite - it doesnt actually place this=20 >addess into the m/c-line. Rather, it places whatever it put in=20 >the previous offer or answer. Without this feature, I think=20 >there will be interoperability problems with existing SBCs. In=20 This is somewhat nasty, but I guess there are no real alternatives to this if we wish to play nice with already deployed SBCs. >Another thing - I believe the re-INVITE can be skipped if the=20 >m/c-lines would be unchanged from the previous offer/answer. This is a nice addition. =20 >I worked through some call flows for this, and it works with=20 >SIP ALG and SBCs under the following assumptions: [...] >* If a SIP ALG sees an SDP from the inside to the outside, but=20 >the m/c-line is NOT an internal address, it leaves the=20 >m/c-line alone. I don't know if this assumption is always=20 >true, but if not, ICE will have serious problems through such=20 >ALG no matter what we do. I guess any middle-box that is mainly there for policy control, not because of NAT problems, would insert itself on the media path in any case. And I guess this is fairly common in deployed networks.=20 But I don't think ICE should fight this. Either the STUN checks go through the inserted candidate (in which case we are fine), or we=20 need to fall back to non-ICE mode (see below). >* An SBC will pass STUN packets as if they were RTP packets This might not always be the case, but then it's also likely that other checks will fail as well (unless the clients are in the same LAN). So what to do in these cases - none of the candidate pairs=20 validate and we have a modified m/c-line (inserted candidate)? In practise=20 you'd probably want to use the m/c-line in this case even though the STUN=20 checks won't go through (-> fallback to non-ICE mode). The trickiest case is when a middlebox does not let STUN packets through, but we have some lower-prio pair (e.g. clients in the same LAN) that validates ok. We don't want to use the m/c-line as we=20 don't know if it works, but neither can we upgrade the lower-prio pair,=20 as that would potentially confuse the middlebox. --=20 first.surname@nokia.com (Kai Vehmanen) Networking Technologies Laboratory, Nokia Research Center _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 01:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXWZk-0006ax-UA; Wed, 11 Oct 2006 01:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXWZj-0006ZV-6A for mmusic@ietf.org; Wed, 11 Oct 2006 01:24:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXWLM-0001XT-1J for mmusic@ietf.org; Wed, 11 Oct 2006 01:09:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2006 22:09:24 -0700 X-IronPort-AV: i="4.09,292,1157353200"; d="scan'208"; a="45610256:sNHT50390628" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9B59NqQ016511 for ; Wed, 11 Oct 2006 01:09:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9B59NYJ017381 for ; Wed, 11 Oct 2006 01:09:23 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 01:09:23 -0400 Received: from [64.140.28.4] ([10.89.20.90]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 01:09:23 -0400 Message-ID: <452C1CA4.5020708@cisco.com> Date: Tue, 10 Oct 2006 18:20:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 05:09:23.0546 (UTC) FILETIME=[6A8CD3A0:01C6ECF3] DKIM-Signature: a=rsa-sha1; q=dns; l=1806; t=1160543363; x=1161407363; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Notes=20from=20October=2010,=202006=20ICE=20call |To:IETF=20MMUSIC=20WG=20; X=v=3Dcisco.com=3B=20h=3DMqnlN2I36qx3HdRhf33rS0iN2Zc=3D; b=P2xKXnL3CMLzUO7ceRt+bnMAw2m5IK40Ld+kz3URwWEpP+phGZIzlFnxmE22qgg6xmb+ARPQ GJk2GgjZTKFz6E33S6ulDmQvz9RTjfPEen7VKO607gF9X8KxEB9gszT5; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [MMUSIC] Notes from October 10, 2006 ICE call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org ICE Conference Call October 6, 2006 Attendees: Cullen Jennings Jonathan Rosenberg Kevin Johns Eric Rescorla Derek MacDonald Colin Perkins Kai Vehmanen Philip Matthews Jean-Francois Mule Aaron Rosenberg There was general agreement that the proposed compromise mechanism (posted on the list today) was good and worth pursuing. There were some comments that this may have been due to Rohan's absence on the call ;) We had a lot of discussion on whether the proposal really made it simpler for PSTN gateways. Ekr wasn't convinced that the algorithm for selecting who acts as the controller would really help. There were some questions on whether there really was a need (i.e., a requirement) to make it simpler for gateways to implement ICE. A few folks spoke in support of that. Another related question was whether mechanisms for ICE in gateways would be part of the ICE spec, somewhere else, or a matter of local implementation. Jonathan suggested it was a matter of local implementation and our job was to just make sure it was possible. Derek preferred to have it documented. Philip asked whether there had been any thought about whether the algorithms we've agreed to so far worked for TCP. Jonathan indicated that he had not really thought enough about it, and that clearly this was needed. We agreed to have one more call next Tueday to try and resolve the remaining open issues prior to the non-00 deadline. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 03:19:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYMl-0006Aj-8C; Wed, 11 Oct 2006 03:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXFgF-0003FC-0M for mmusic@ietf.org; Tue, 10 Oct 2006 07:21:51 -0400 Received: from web86011.mail.ird.yahoo.com ([217.146.188.10]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXFgD-0005Z1-It for mmusic@ietf.org; Tue, 10 Oct 2006 07:21:50 -0400 Received: (qmail 85666 invoked by uid 60001); 10 Oct 2006 11:21:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btopenworld.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oO+FCmhGN3CANIUc4NYwp/ZtiyrIdkdvix2Y87nei7UpC5Plv0CVHevoGKlrYLf8M1yQSjoGTkCRY6h7EcTi19mgBzawymT+9eeDaFoCwxuIj6IpTZIXcFLiNoSW9P1K7nAufnvLFO1Q6OstMyRq/Ddml5b7+OHOwjv/bvtyhZg= ; Message-ID: <20061010112129.85664.qmail@web86011.mail.ird.yahoo.com> Received: from [194.70.154.226] by web86011.mail.ird.yahoo.com via HTTP; Tue, 10 Oct 2006 12:21:29 BST Date: Tue, 10 Oct 2006 12:21:29 +0100 (BST) From: Subject: RE: [MMUSIC] Interworking ICE/SBC To: Thomas.Levy@alcatel.fr, mmusic@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 11 Oct 2006 03:18:58 -0400 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1232609888==" Errors-To: mmusic-bounces@ietf.org --===============1232609888== Content-Type: multipart/alternative; boundary="0-64616021-1160479289=:84414" Content-Transfer-Encoding: 8bit --0-64616021-1160479289=:84414 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit If I understand your situation (please forgive me if I mis-understand or have made an assumption), there are 2 issue's here? 1). Ensuring media correctly flows through an SBC when it wishes it to do so. Even in ICE environments? Here the discussions about "ICE and open internet devices" come into play. These discussions, I believe, are definitely the right way to go, especially the "passive client" concepts (be the role signaled or discovered). 2). SBC's (e.g.) ability to detect ICE capability of UAs? At present ICE capability is restricted to the actual offer/answer exchange. If a UA's ICE capability could be discovered by some other means (REGISTER or OPTIONS flag) then a network device could make a per call decision on whether to take the media; rather than an all or nothing approach. One issue with these discovery mechanisms, is unless they are required (MUSTs) then they are all but useless. Does the absence of the flag indicate no support of ICE or just no supporting of ICE capability advertisement? However I guess the other issue is these mechanisms would be specific to the signaling protocol delivering the offer/answer. Cheers, Pete L. --0-64616021-1160479289=:84414 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit If I understand your situation (please forgive me if I mis-understand or have made an assumption), there are 2 issue's here?

1). Ensuring media correctly flows through an SBC when it wishes it to do so. Even in ICE environments?
Here the discussions about "ICE and open internet devices" come into play. These discussions, I believe, are definitely the right way to go, especially the "passive client" concepts (be the role signaled or discovered).

2). SBC's (e.g.) ability to detect ICE capability of UAs?
At present ICE capability is restricted to the actual offer/answer exchange. If a UA's ICE capability could be discovered by some other means (REGISTER or OPTIONS flag) then a network device could make a per call decision on whether to take the media; rather than an all or nothing approach. One issue with these discovery mechanisms, is unless they are required (MUSTs) then they are all but useless. Does the absence of the flag indicate no support of ICE or just no supporting of ICE capability advertisement? However I guess the other issue is these mechanisms would be specific to the signaling protocol delivering the offer/answer.

Cheers,

Pete L.

--0-64616021-1160479289=:84414-- --===============1232609888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1232609888==-- From mmusic-bounces@ietf.org Wed Oct 11 05:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXada-0003FV-7S; Wed, 11 Oct 2006 05:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXadZ-0003FN-3N for mmusic@ietf.org; Wed, 11 Oct 2006 05:44:29 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXadX-0003Cg-KI for mmusic@ietf.org; Wed, 11 Oct 2006 05:44:29 -0400 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k9B9iOaD024233; Wed, 11 Oct 2006 11:44:24 +0200 Received: from [172.25.79.32] ([172.25.79.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006101111442001:6405 ; Wed, 11 Oct 2006 11:44:20 +0200 Message-ID: <452CBCF4.5060804@alcatel.fr> Date: Wed, 11 Oct 2006 11:44:20 +0200 From: Thomas.Levy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.7) Gecko/20050414 X-Accept-Language: fr, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [MMUSIC] Interworking ICE/SBC References: <452B7480.10203@alcatel.fr> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/11/2006 11:44:20, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/11/2006 11:44:23 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mmusic@ietf.org, Thomas FROMENT , Gonzalo.Camarillo@ericsson.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Cullen Jennings a =E9crit : > > Could you please clarify what you mean by SBC in this case. Do you =20 > mean a B2BUA with a media relay? Yes a B2BUA used to relay the media flows for NAT traversal. In this case, the SBC is used for (hosted) NAT traversal but not for=20 Access Control. Thomas > > > On Oct 10, 2006, at 3:22 AM, Thomas.Levy@alcatel.fr wrote: > >> Hello all, >> >> We identified technical issues related to the deployment of SIP =20 >> services within NATed networks when ICE and SBC are used =20 >> simultaneously for NAT traversal. Thus, we would like to have the =20 >> opinion from the MMUSIC/SIP community about the subject and the best=20 >> way to solve these issues? >> >> Here is the point: >> We consider that users (and their SIP terminals) are using a NATed =20 >> IP address. >> The SIP Service Provider of the users may be different from the ISP =20 >> of the users. >> Two approaches for NAT traversal are deployed : >> On one side, ICE is deployed partly on some UAs. >> On the other side, a Session Border Controller (SBC) deployed as the=20 >> proxy for NAT traversal. >> >> For instance, the service provider have a SBC already deployed and =20 >> it wants to introduce new terminals with ICE (for inst: to avoid =20 >> some media flows to go through its network). >> In this example, when a user (with UA supporting ICE) intitiates a =20 >> call, the UA and the SBC on the path are attempting to change the =20 >> SIP messages (in particular the SDP) for NAT traversal. But, for the=20 >> moment, it results in an unpredictable behavior for NAT traversal.=20 >> Depending on the SBC implementation, the call may be rejected,=20 >> accepted with no working media, or even accepted with media streams=20 >> being relayed on multiple successive media relays. In both cases,=20 >> the result is less optimal than for a single solution (ICE or SBC). >> This is why we would like to discuss the best way to make ICE =20 >> actually work, even if a SBC is on the path. >> Please note that this point also applies with 2 users located in =20 >> different domains. >> Your opinion is welcome. >> >> Sincerely, >> >> Thomas LEVY & Thomas FROMENT >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 06:26:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbI4-0005JI-7e; Wed, 11 Oct 2006 06:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbI2-0005J5-Fz for mmusic@ietf.org; Wed, 11 Oct 2006 06:26:18 -0400 Received: from web86002.mail.ird.yahoo.com ([217.146.188.87]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXbHx-0005DP-MF for mmusic@ietf.org; Wed, 11 Oct 2006 06:26:18 -0400 Received: (qmail 43250 invoked by uid 60001); 11 Oct 2006 10:26:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btopenworld.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U3JscCN42hRSrs46UOJOEvcqV8oWKQOPXY1XEi83T5OO7yRHDi2oTqtCWpLHjWy9Y3l+Ihc1HRqXajqupP0jntREucoiX3I/L9MjnYMYPcR+Rawe3xlOmS8DpZtpVj97wyK8u/DoD+pEwUh/Sy5CsAzb4o23H49/d8NkLAghajs= ; Message-ID: <20061011102612.43248.qmail@web86002.mail.ird.yahoo.com> Received: from [194.70.154.226] by web86002.mail.ird.yahoo.com via HTTP; Wed, 11 Oct 2006 11:26:12 BST Date: Wed, 11 Oct 2006 11:26:12 +0100 (BST) From: Peter Livesey Subject: Re: FW: [MMUSIC] Compromise proposal for ICE finishing algorithm To: jdrosen@cisco.com In-Reply-To: <01C679F7AECF2B47B489F735B7EE490001873062@47mail.eu.tandberg.int> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Like the proposal. Just looking for a clarification on a couple of points. Just was wondering who would be the 'controller' in the following situation: A PSTN GW is initiating a call (on behalf of a POTS phone), to a UA behind an m/c line changing (non ICE) SBC (or ALG). The UA itself isn't behind a NAT as it's behind the SBC. Therefore, both the PSTN and UA advertise only 1 candidate (their local address). Are the 'inserted' candidates used in the controller decision? If so wouldn't both the PSTN GW and the UA believe the other is the 'controller', as they would have 1 candidate but the received SDP would have 2 (original + 'inserted')? If the 'inserted' candidate isn't taken into account then the PSTN GW is the 'controller', as it's the offerer. Assuming STUN checks on 'inserted' candidate succeed, is it correct that in this case the PSTN GW wouldn't have to send a re-invite as it would just be the same as the original? Would be worth documenting GW algorithm to avoid incorrect implementations due to misinterpretations. Cheers, Pete L. > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 10 October 2006 16:16 > To: IETF MMUSIC WG > Subject: [MMUSIC] Compromise proposal for ICE > finishing algorithm > > I've been considering this issue about how to have > ICE finish over the > last week. I've come up with a compromise proposal > which I hope > works for everyone. > > The proposal has the following properties: > > * has one agent acting as controlling, and that > agent selects the final > pairs that get used and signals those pairs through > STUN, allowing for > the forwards compatibility we are anxious to have > * requires nothing more than a two more bits to be > added to the STUN > messaging > * has no additional latency for call setup as long > as the agents are > using the default selection algorithm (highest > priority pairs that > succeed get used) > * uses the candidates in the m/c-line always but > only if they worked; if > > checks through them failed, the one selected by the > STUN signaling is > used > * should interoperate with existing SBC and SIP ALG; > see below for > caveats > * Will 'bypass' faulty SBC and ALG in cases where > their suggested media > paths don't work. For example, if a SIP ALG is > broken and doesn't > hairpin properly, and both endpoints are behind the > same NAT/ALG, > they'll take the direct path > * relieves PSTN gateways of the responsibility for > ever having to > generate a re-invite, compute and maintain a valid > list. However they > would still perform checks. Inter-GW calls would not > require a > re-invite. > > All of this comes at the cost of complexity, and it > centers around this > bigger question of whether it is a requirement for > ICE to help calls > work in cases where there are SBC or ALG 'in the > way'. Some folks have > expressed a strong opinion that it should, though > this is far from > unanimous. > > The high level approach is a synthesis of what has > been suggested > throughout the various discussions. Once the > offer/answer exchanges > are done, each agent checks to see if there is a > candidate line for > the m/c-line. If there isn't, each agent adds the > address and port in > the m/c-line as a candidiate, and assigns it the > highest priority > (see below on exactly how). Fortunately, as of > ICE-10, the > username/passwords are a function of the media > stream and NOT > individual candidates, so the username and password > are known. This > remote candidate is marked as being of a special > type, which I'll call > 'inserted' for now. > > After the offer/answer exchange, one agent takes the > role of > 'controlling'. This will be the agent which had the > most number of > candidates across all media streams. If it was a > tie, the controlling > agent is the offerer. The controlling agent gets to > decide when the > checks finish and what the selected pairs are. > However it is somewhat > constrained in that, if there was an inserted > candidate, that one has > to be used if it validated. > > When the controlling agent selects a pair to be > used, it includes a > flag in a STUN check for that pair which indicates > that this is the > pair that was selected. The non-controlling agent > will use the > resulting pair if and only if it has successfully > completed a check in > the reverse direction. If multiple checks succeed > with the flag set, the > > highest priority one which worked is used. The > reason it gets specified > this way is that it allows you to avoid an extra set > of checks just to > indicate you are done. An implementation which just > wants to use the > 'highest priority' selection algorithm in ICE-10 > would set the flag in > all checks it does for the last component of each > media stream. As soon > as one completes, it would get used. However, an > agent looking to use a > more complex algorithm would omit the flags > initially, perform checks, > and when it decides, redo checks for the selected > pairs. This way, the > latency penalty on setup comes only for > implementations doing something > more complex than the baseline. > > Another important aspect of the checks is this. When > an agent receives a > > STUN check, and the source address of the Binding > Request matches an > inserted candidate, the STUN resposne contains a > flag informing the > client that this mapped address was an inserted one. > This alerts the > client that this is not a 'normal' peer derived > address, but rather one > that was forcefully inserted by an intermediary. If > that candidate gets > selected (and it probably will as its highest > priority), when the agent > does the reinvite - it doesnt actually place this > addess into the > m/c-line. Rather, it places whatever it put in the > previous offer or > answer. Without this feature, I think there will be > interoperability > problems with existing SBCs. In particular, without > it, the re-invites > would convey, from the UAC and UAS, the transport > addresses assigned by > the SBCs themselves. I fear that this reinvite will > seriously confuse > existing SBC. > > So, when the re-invite comes, if the m/c-lines match > the selected pairs, > > great. If not, they get used if and only if the > m/c-lines were already > validated by checks. If the m/c-line is known as a > candidate, but didn't > > validate, it is NOT used. If the m/c-line in the > re-invite is new > (meaning its not a known candidate), a check is > immediately performed > for it, and then as above it is used if it works, > otherwise not. > > Another thing - I believe the re-INVITE can be > skipped if the m/c-lines > would be unchanged from the previous offer/answer. > This makes ICE nice > for inter-gateway operation since you'll never need > a re-invite there. > However you'd still have checks, which is a good > thing I think. > > I worked through some call flows for this, and it > works with SIP ALG and > > SBCs under the following assumptions: > > * If a SIP ALG sees an SDP from the inside to the > outside, but the > m/c-line is NOT an internal address, it leaves the > m/c-line alone. I > don't know if this assumption is always true, but if > not, ICE will have > serious problems through such ALG no matter what we > do. > > * An SBC will pass STUN packets as if they were RTP > packets > > In terms of the priority for the inserted > candidates, the idea is to > reserve the largest type preference value, and use > that only for > inserted candidates. Indeed the astute reader will > note that I already > left provision for that in ICE-11. > > We'll discuss on the call today. > > Thanks, > Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > Cisco Fellow > Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: > (973) 952-5050 > http://www.jdrosen.net > PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 12:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhIi-0005tR-42; Wed, 11 Oct 2006 12:51:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhIh-0005tL-5G for mmusic@ietf.org; Wed, 11 Oct 2006 12:51:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhIc-0001Fh-KG for mmusic@ietf.org; Wed, 11 Oct 2006 12:51:23 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2006 09:51:17 -0700 X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="330559543:sNHT52454964" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9BGpGH1019178; Wed, 11 Oct 2006 09:51:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9BGpGAo025531; Wed, 11 Oct 2006 09:51:17 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 09:51:16 -0700 Received: from [64.101.174.184] ([64.101.174.184]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 09:51:16 -0700 Message-ID: <452D2104.2050506@cisco.com> Date: Wed, 11 Oct 2006 12:51:16 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Livesey Subject: Re: FW: [MMUSIC] Compromise proposal for ICE finishing algorithm References: <20061011102612.43248.qmail@web86002.mail.ird.yahoo.com> In-Reply-To: <20061011102612.43248.qmail@web86002.mail.ird.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 16:51:16.0611 (UTC) FILETIME=[77E49530:01C6ED55] DKIM-Signature: a=rsa-sha1; q=dns; l=1815; t=1160585477; x=1161449477; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20FW=3A=20[MMUSIC]=20Compromise=20proposal=20for=20ICE=20finishing =20algorithm; X=v=3Dcisco.com=3B=20h=3DwHlM2L0/ggifqk/cXVI0PEQk2Ek=3D; b=CzqCJMiiMu0GII0jIxuTi1CmmC8RWh8R6K0VM4L9dHejwH9CwUx7e32m/AVqDr2zO4IZfrE/ E66wXx50SB0mDsoMtG/ZlUC0dXwFfJi+8dRcVANMOF2Lts72M6rNPWr4; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Peter Livesey wrote: > Like the proposal. Just looking for a clarification on > a couple of points. > > Just was wondering who would be the 'controller' in > the following situation: > A PSTN GW is initiating a call (on behalf of a POTS > phone), to a UA behind an m/c line changing (non ICE) > SBC (or ALG). The UA itself isn't behind a NAT as it's > behind the SBC. Therefore, both the PSTN and UA > advertise only 1 candidate (their local address). > > Are the 'inserted' candidates used in the controller > decision? If so wouldn't both the PSTN GW and the UA > believe the other is the 'controller', as they would > have 1 candidate but the received SDP would have 2 > (original + 'inserted')? No. They don't count. Its quite literally a count of the a=candidate lines in the SDP. In this case it would be a tie and the offerer would win. > > If the 'inserted' candidate isn't taken into account > then the PSTN GW is the 'controller', as it's the > offerer. Assuming STUN checks on 'inserted' candidate > succeed, is it correct that in this case the PSTN GW > wouldn't have to send a re-invite as it would just be > the same as the original? Right. > > Would be worth documenting GW algorithm to avoid > incorrect implementations due to misinterpretations. This came up as an open issue - whether to document this and where. I'm inclined to not bulk back up the core ICE spec now that we got it thinner... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 13:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhlh-0003Pf-PU; Wed, 11 Oct 2006 13:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhlg-0003PZ-2e for mmusic@ietf.org; Wed, 11 Oct 2006 13:21:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhlc-0006FJ-ND for mmusic@ietf.org; Wed, 11 Oct 2006 13:21:20 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Oct 2006 10:21:17 -0700 X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="45672460:sNHT58597376" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9BHLG4f000321; Wed, 11 Oct 2006 13:21:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9BHLGYL002540; Wed, 11 Oct 2006 13:21:16 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:21:15 -0400 Received: from [64.101.174.184] ([64.101.174.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:21:15 -0400 Message-ID: <452D280B.9050708@cisco.com> Date: Wed, 11 Oct 2006 13:21:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: plivesey@btopenworld.com Subject: Re: [MMUSIC] Interworking ICE/SBC References: <20061010124437.96992.qmail@web86005.mail.ird.yahoo.com> In-Reply-To: <20061010124437.96992.qmail@web86005.mail.ird.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 17:21:15.0722 (UTC) FILETIME=[A83F22A0:01C6ED59] DKIM-Signature: a=rsa-sha1; q=dns; l=4327; t=1160587276; x=1161451276; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Interworking=20ICE/SBC |To:plivesey@btopenworld.com; X=v=3Dcisco.com=3B=20h=3DzMlOo53FZCZ0XejoEj0pjlE3zbQ=3D; b=Qwqx7UGu9+g2FB3YHX04VhfaNaVUrDovE2dnFSuGQTXKDBSECyv6kkyEBGtRwOeWvbxawRvt cTpGbaDvbgPfokCBTILlFt0KyIF/g8rOq7PYEFSsDG6Q1KDcUtzUdfTF; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. plivesey@btopenworld.com wrote: > > The problem here goes back to the old question of what the ICE UA > chooses as it's initial "in use" candidate (i.e. puts in m/c line). > If it were a relayed candidate, then if symmetric RTP is enforced, > then it has to ensure it sends from this address. This means via the > relay. So even if the ICE UA drops to non-UA behaviour it will have > to send via it's relay, which is non optimal. Whether this happens depends on the configuration of the SBC. Consider the proposal I made on the list on how to handle SBCs (this whole bit about inserted candidates). If the SBC is in the 'latching' mode, whereby it learns the target for relaying media based on the source IP/port of the RTP rather than the m/c-line of the SDP, everything works fine. The algorithm I described will end up quickly validating, on each side, the pair formed by combining the host candidate with the addresses added by the SBC. The STUN exchanges will indicate that these SBC addresses are inserted. Consequently, there won't normally even be a re-invite; media will simply flow from the host candidate on each agent, to the SBC, towards the remote agent. The TURN servers, though their addresses appeared in the m/c-lines, never see any media traffic and are never used. Media operation is still symmetric as far as the SBC is concerned, but its symmetric because of the 'latching' implemented by the SBC. If, on the other hand, the SBC is configured to insert itself into the media path, but otherwise honor the contents of the SDP, its more interesting. If the SBC requires symmetric RTP (it discards any packets not coming from the IP/port in the m/c-line), the STUN checks will proceed and the only candidate pairs that work are the ones from the TURN server to the SBC. This too will not require a re-invite, but will result in the ugly case of THREE relays (and possibly four) - the SBC (two SBCs if each side has one), and two TURN servers. If the SBC doesn't require symmetric RTP and will accept media (including STUN) from anywhere but otherwise relay it towards what was provided in the m/c-line, its really interesting what happens. You'll end up using the SBCs and only ONE of the two TURN servers (a different one in each direction). So the lesson of this is, if you have an SBC in a network with ICE endpoints, you need to configure the SBC to operate in latching mode (at least towards the ICE-capable devices). I believe most do this as the normal mode of operation. > Even worse, if the UA > and the network device requiring to take the media (probably not a > Service Providers SBC but other enterprise policy device) are > co-located. Then media connectivity may fail (as media may go out of > a firewall via the relay and then fail when trying to comeback in, > in native form) . I dont follow this. Can you describe the topology in more detail? > > If I'm correct,I believe this is where the discussions about "ICE > and open Internet devices" come into play. In this case SBCs would > always appear to ICE UAs as a fellow ICE client, but only > advertising it's interface as the only candidate. Ensuring the only > path discovered by the ICE UA will be towards the SBC and maybe the > most optimal (if ICE candidate checks complete fully). This > discussion also introduces the concept of a "passive" client, which > reduces the implementation complexity required (SBC may only have to > respond to connectivity checks and also not have to re-invite). You are talking now about something different, which is ICE-capable SBCs. There are many, many ways to build such devices, and since the SBC is ICE aware it can be done in a way where the overall right thing happens. That is not the case I'm considering, which is ICE-unaware SBCs. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 13:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhoJ-00045d-3G; Wed, 11 Oct 2006 13:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhoI-00045Y-GK for mmusic@ietf.org; Wed, 11 Oct 2006 13:24:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhoH-0006or-74 for mmusic@ietf.org; Wed, 11 Oct 2006 13:24:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Oct 2006 10:24:01 -0700 X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="45672806:sNHT53467300" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9BHO1Yq001744; Wed, 11 Oct 2006 13:24:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9BHO0DM022650; Wed, 11 Oct 2006 13:24:00 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:24:00 -0400 Received: from [64.101.174.184] ([64.101.174.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:24:00 -0400 Message-ID: <452D28AF.5060209@cisco.com> Date: Wed, 11 Oct 2006 13:23:59 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: franz.edler@inode.at Subject: Re: [MMUSIC] Interworking ICE/SBC References: <452B7480.10203@alcatel.fr> <194.113.59.79.1160481826.wm@webmail.inode.at> In-Reply-To: <194.113.59.79.1160481826.wm@webmail.inode.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 17:24:00.0036 (UTC) FILETIME=[0A2F7640:01C6ED5A] DKIM-Signature: a=rsa-sha1; q=dns; l=1505; t=1160587441; x=1161451441; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Interworking=20ICE/SBC |To:franz.edler@inode.at; X=v=3Dcisco.com=3B=20h=3DzMlOo53FZCZ0XejoEj0pjlE3zbQ=3D; b=MORT029i20TqHu2fQvcU0BJFnRgrTUBrigyViyufUBaOSw3Y0IpkprrTXiI+/LeJKHhvtcev 1EJFoGM3TCjr/saco0qbD/VbjaKSeBlYhCVfh1w3qX/y2jANrJTPcynT; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mmusic@ietf.org, Thomas.Froment@alcatel.fr, Gonzalo.Camarillo@ericsson.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org franz.edler@inode.at wrote: > Hi, > > >>In this example, when a user (with UA supporting ICE) intitiates a call, >> the UA and the SBC on the path are attempting to change the SIP >>messages (in particular the SDP) for NAT traversal. But, for the >>moment, it results in an unpredictable behavior for NAT traversal. > > >>From my point, this looks like a problem of the SBC. ICE is defined to be > compatible with UAs not supporting ICE. If the SBC does not have a > strategy how to cope with ICE it should ignore it. Than the UA will > fallback to normal (non-ICE) behaviour. So, this is what happens in ICE-10. If there is an intermediate SBC the UA falls back to normal non-ICE behavior. The issue that was raised (and its a good one), is that this will typically result in three or even four media relays on the call - the originating TURN server, originating SBC, terminating TURN server, terminating SBC. This is because 'normal' non-ICE processing would be to use the m/c-line which contains a TURN relay. Per my other note, this is fixed by my proposal, which would end up using only the SBC relays in these cases. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 11 18:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXms1-0000ZF-JW; Wed, 11 Oct 2006 18:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXms0-0000ZA-L7 for mmusic@ietf.org; Wed, 11 Oct 2006 18:48:12 -0400 Received: from mx3-4.spamtrap.magma.ca ([209.217.78.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXmrz-0001uw-C5 for mmusic@ietf.org; Wed, 11 Oct 2006 18:48:12 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-4.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id k9BMm59h009515; Wed, 11 Oct 2006 18:48:05 -0400 Received: from [10.25.25.201] (72-255-34-175.client.stsn.net [72.255.34.175]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id k9BMm3ch003958 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 11 Oct 2006 18:48:05 -0400 In-Reply-To: <452D2104.2050506@cisco.com> References: <20061011102612.43248.qmail@web86002.mail.ird.yahoo.com> <452D2104.2050506@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A5C9406-F498-4DAD-8F4A-724785840483@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Compromise proposal for ICE finishing algorithm Date: Wed, 11 Oct 2006 18:48:19 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 11-Oct-06, at 12:51 , Jonathan Rosenberg wrote: > >> Would be worth documenting GW algorithm to avoid >> incorrect implementations due to misinterpretations. > > This came up as an open issue - whether to document this and where. > I'm inclined to not bulk back up the core ICE spec now that we got > it thinner... > My opinion is that, if we are going to take the time to worry about this issue, and add the extra complexity to the specification to make it simpler for some classes of nodes, then we need to (a) document it, (b) make sure that it really does simplify these nodes. I am OK if the former happens in a separate document, but I don't feel the ICE spec should be finalized before that other document is well advanced. As for the latter, I guess that writing this all down would be a good first step to seeing how much simpler it makes things. - Philip (who is still somewhat unsure that adding extra complexity to the ICE spec to make life easier for Gateways will really have any measurable effect). _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 12 04:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXw8k-0004lL-Gq; Thu, 12 Oct 2006 04:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXw8j-0004kw-1z for mmusic@ietf.org; Thu, 12 Oct 2006 04:42:05 -0400 Received: from web86008.mail.ird.yahoo.com ([217.146.188.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXw8h-00024Z-CY for mmusic@ietf.org; Thu, 12 Oct 2006 04:42:05 -0400 Received: (qmail 69392 invoked by uid 60001); 12 Oct 2006 08:42:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btopenworld.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vlgO8KdFJPrYzTXpqxRW4MqvvsaCLuhcd/p0oPaA6LoxYXKUOUOXByOd4PdcWeJMXH0v7JwlzNv356GlETmFWDyJ7WyiN8yxa5XojOJU0yaJU6qOsjkNOvRIbw/67EnVtvQoULm1c6tg8ddg62P9SfBVsK5df5HJtdCqwf+q+WE= ; Message-ID: <20061012084200.69367.qmail@web86008.mail.ird.yahoo.com> Received: from [194.70.154.226] by web86008.mail.ird.yahoo.com via HTTP; Thu, 12 Oct 2006 09:42:00 BST Date: Thu, 12 Oct 2006 09:42:00 +0100 (BST) From: Peter Livesey Subject: Re: [MMUSIC] Interworking ICE/SBC To: Jonathan Rosenberg In-Reply-To: <452D280B.9050708@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I actually sent this mail before your new 'inserted' candidates proposal. Posting of it to the list was delayed due to an administrative error on my part (posting prior to registering this mail address with list) Doh! ;-) . I was trying to describe possible problems I thought may happen, when a SBC/ALG changed the m/c line and the ICE UAs policy on detecting this was to process based on RFC3264 (Draft 10). Sorry for the confusion. The scenario I depict is one where an ICE UA within an enterprise initiates a call. It has selected candidates including a relayed candidate. The UA picks the relayed candidate as being in-use. A network device within the enterprise (maybe private side of ALG/SBC or a Proxy running a Policy Engine), requires to take the media. In order to do so it changes the m/c line of the SDP. On receiving the SDP answer the UA detects the m/c line has been changed and therefore has to fall back to RFC 3264. So the situation we have here is a UA inside an enterprise trying to send media to an internal address, via a relay. So the media is leaving the enterprise, travelling through the relay which will then try to forward the media onto an address back inside the enterprise. This is highly unlikely to succeed. There are ways this could have been avoided. UA selection of 'in-use' candidate, based on some pre-configured awareness of it's location. The network device being ICE aware and now your new proposal (assuming said device doesn't enforce symetric RTP based on m/c line). Once again sorry for the confusion. Cheers, Pete L. --- Jonathan Rosenberg wrote: > inline. > > plivesey@btopenworld.com wrote: > > > > > The problem here goes back to the old question > of what the ICE UA > > chooses as it's initial "in use" candidate > (i.e. puts in m/c line). > > If it were a relayed candidate, then if > symmetric RTP is enforced, > > then it has to ensure it sends from this > address. This means via the > > relay. So even if the ICE UA drops to non-UA > behaviour it will have > > to send via it's relay, which is non optimal. > > Whether this happens depends on the configuration of > the SBC. > > Consider the proposal I made on the list on how to > handle SBCs (this > whole bit about inserted candidates). If the SBC is > in the 'latching' > mode, whereby it learns the target for relaying > media based on the > source IP/port of the RTP rather than the m/c-line > of the SDP, > everything works fine. The algorithm I described > will end up quickly > validating, on each side, the pair formed by > combining the host > candidate with the addresses added by the SBC. The > STUN exchanges will > indicate that these SBC addresses are inserted. > Consequently, there > won't normally even be a re-invite; media will > simply flow from the host > candidate on each agent, to the SBC, towards the > remote agent. The TURN > servers, though their addresses appeared in the > m/c-lines, never see any > media traffic and are never used. Media operation is > still symmetric as > far as the SBC is concerned, but its symmetric > because of the 'latching' > implemented by the SBC. > > If, on the other hand, the SBC is configured to > insert itself into the > media path, but otherwise honor the contents of the > SDP, its more > interesting. If the SBC requires symmetric RTP (it > discards any packets > not coming from the IP/port in the m/c-line), the > STUN checks will > proceed and the only candidate pairs that work are > the ones from the > TURN server to the SBC. This too will not require a > re-invite, but will > result in the ugly case of THREE relays (and > possibly four) - the SBC > (two SBCs if each side has one), and two TURN > servers. > > If the SBC doesn't require symmetric RTP and will > accept media > (including STUN) from anywhere but otherwise relay > it towards what was > provided in the m/c-line, its really interesting > what happens. You'll > end up using the SBCs and only ONE of the two TURN > servers (a different > one in each direction). > > So the lesson of this is, if you have an SBC in a > network with ICE > endpoints, you need to configure the SBC to operate > in latching mode (at > least towards the ICE-capable devices). I believe > most do this as the > normal mode of operation. > > > > > > > Even worse, if the UA > > and the network device requiring to take the > media (probably not a > > Service Providers SBC but other enterprise > policy device) are > > co-located. Then media connectivity may fail > (as media may go out of > > a firewall via the relay and then fail when > trying to comeback in, > > in native form) . > > I dont follow this. Can you describe the topology in > more detail? > > > > > If I'm correct,I believe this is where the > discussions about "ICE > > and open Internet devices" come into play. In > this case SBCs would > > always appear to ICE UAs as a fellow ICE > client, but only > > advertising it's interface as the only > candidate. Ensuring the only > > path discovered by the ICE UA will be towards > the SBC and maybe the > > most optimal (if ICE candidate checks complete > fully). This > > discussion also introduces the concept of a > "passive" client, which > > reduces the implementation complexity required > (SBC may only have to > > respond to connectivity checks and also not > have to re-invite). > > You are talking now about something different, which > is ICE-capable > SBCs. There are many, many ways to build such > devices, and since the SBC > is ICE aware it can be done in a way where the > overall right thing > happens. That is not the case I'm considering, which > is ICE-unaware SBCs. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > Cisco Fellow > Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: > (973) 952-5050 > http://www.jdrosen.net > PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 13 03:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHQ8-0007dK-SB; Fri, 13 Oct 2006 03:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHQ7-0007ar-Oi for mmusic@ietf.org; Fri, 13 Oct 2006 03:25:27 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYHBQ-0005Em-OA for mmusic@ietf.org; Fri, 13 Oct 2006 03:10:18 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 09:10:08 +0200 Received: from L-AT7568 ([10.193.5.78]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 09:10:08 +0200 Date: Fri, 13 Oct 2006 09:10:08 +0200 From: xavier.marjou@orange-ft.com To: mmusic@ietf.org Message-ID: X-Mailer: JBMail 3.2 X-OriginalArrivalTime: 13 Oct 2006 07:10:08.0397 (UTC) FILETIME=[9DA4DBD0:01C6EE96] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [MMUSIC] SIP-RTSP draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org For information, the following draft investigates the option of re-using RTSP in SIP streaming media applications: http://www.ietf.org/internet-drafts/draft-marjou-mmusic-sdp-rtsp-00.txt Xavier _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 13 13:49:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRA0-0008U1-8Y; Fri, 13 Oct 2006 13:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYR9y-0008Rh-Px for mmusic@ietf.org; Fri, 13 Oct 2006 13:49:26 -0400 Received: from prufrock.cs.umd.edu ([128.8.128.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYR9x-0005M4-Ho for mmusic@ietf.org; Fri, 13 Oct 2006 13:49:26 -0400 Received: (from sharno@localhost) by prufrock.cs.umd.edu (8.12.10/8.12.5) id k9DHnPfI022756 for mmusic@ietf.org; Fri, 13 Oct 2006 13:49:25 -0400 (EDT) Date: Fri, 13 Oct 2006 13:49:25 -0400 (EDT) From: Tamer Elsharnouby Message-Id: <200610131749.k9DHnPfI022756@prufrock.cs.umd.edu> To: mmusic@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [MMUSIC] IEEE NetCri 2007: Call for papers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org ** Apologies if you receive multiple copies of this call for papers ** =============================================================================== Call for Papers NetCri 07 The First International Workshop on Research Challenges in Next Generation Networks for First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri In Conjunction with IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =============================================================================== As advances in pervasive computing, wireless communication and sensor networks continue, more opportunities are open to first responders and critical infra- structures to benefit from these technologies. Providing first responders with the best possible technology, infrastructure and services help save the lives of the general public and the first responders as well. One of the main challenges to the operations of first responders and critical infrastructures is to deploy a communication network that is dependable, secure, and rapidly deployable. In order to operate effectively, the deployed network supports services such as location determination, audio and video communication, and in site and remote sensing. Another key feature for first responders and critical infrastructures networks is to support interactions among multiple heterogen- eous networks. This workshop provides a forum for researchers, industry, and government agencies to discuss the challenges facing the design, deployment and operation- al issues for next generation network support for first responders and critical infrastructure. The workshop will identify and define fundamental concepts and techniques, resolve conflicts between different approaches in the area, and provide a common ground for an advanced research and development agenda. Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.) - Fast roaming in heterogonous network environment - Localization and time synchronization - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time control - Network and system support for augmented reality and visual analytics - Simulation studies of first responders and critical infrastructures’ networks - Novel and adaptive communication protocols to support first responders and critical infrastructure’ operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not currently under review by another conference, workshop, or journal. Authors are invited to submit a maximum of 6 pages papers including the abstract, figures and references. Papers should include the title, author(s), authors' affiliation and an abstract. The formatting should be according to IEEE rules. Papers should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and are included in the conference proceedings. Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, USA _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 13 14:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRhi-00071z-JO; Fri, 13 Oct 2006 14:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRhh-00071t-NX for mmusic@ietf.org; Fri, 13 Oct 2006 14:24:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRhe-00020C-DM for mmusic@ietf.org; Fri, 13 Oct 2006 14:24:17 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2006 11:24:14 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9DIOD8G030843 for ; Fri, 13 Oct 2006 11:24:13 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9DINsbV026422 for ; Fri, 13 Oct 2006 11:24:13 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 14:24:06 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.176]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 14:24:06 -0400 Message-Id: <4.3.2.7.2.20061013131620.02260e70@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Oct 2006 13:24:03 -0500 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Oct 2006 18:24:06.0714 (UTC) FILETIME=[C4C259A0:01C6EEF4] DKIM-Signature: a=rsa-sha1; q=dns; l=274; t=1160763853; x=1161627853; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Minor=20Errors=20found=20in=20RFC4566; X=v=3Dcisco.com=3B=20h=3DdRgm7RNoHWM3+9xpnAZirafvYgg=3D; b=Fqn8kd7DupzbgIeYDtlkzS9pVCMwTusxDJizmfqGYjzEj/J3y7eaienSeL4JdwRJjaMP6uro UkmAkU9U+uCbthVLbQ25l6Qgxahi7HLgE4fzpbt7FtK7foqmN8f8Nj91; Authentication-Results: sj-dkim-6.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [MMUSIC] Minor Errors found in RFC4566 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org all In Section 6 "SDP Attributes", in the a=sendrecv and a=type: paragraphs, there are multiple references to H332, which points at reference [26] which is actually ITU-T's H.323 Recommendation - which also calls out H332 once in the references section. James _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 15 10:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6dI-0008Iy-VM; Sun, 15 Oct 2006 10:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6dH-0008Il-33 for mmusic@ietf.org; Sun, 15 Oct 2006 10:06:27 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ6dC-0001sn-Py for mmusic@ietf.org; Sun, 15 Oct 2006 10:06:27 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61839 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GZ6d9-0001J2-Vi; Sun, 15 Oct 2006 15:06:20 +0100 In-Reply-To: <4.3.2.7.2.20061013131620.02260e70@email.cisco.com> References: <4.3.2.7.2.20061013131620.02260e70@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BA1385F-73B1-4F00-A9D8-8C0B496F2BD0@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Minor Errors found in RFC4566 Date: Sun, 15 Oct 2006 15:06:16 +0100 To: James M. Polk X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 13 Oct 2006, at 19:24, James M. Polk wrote: > In Section 6 "SDP Attributes", in the a=sendrecv and a=type: > paragraphs, there are multiple references to H332, which points at > reference [26] which is actually ITU-T's H.323 Recommendation - > which also calls out H332 once in the references section. I'm not sure I understand the problem. Reference [26] in RFC 4566 is: [26] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. which appears correct to be the correct reference to H.332, according to the ITU website (http://www.itu.int/rec/T-REC-H.332-199809-I/en). Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 15 14:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAQT-0001DB-OW; Sun, 15 Oct 2006 14:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAQS-0001Cy-87 for mmusic@ietf.org; Sun, 15 Oct 2006 14:09:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAQO-0002jT-0N for mmusic@ietf.org; Sun, 15 Oct 2006 14:09:28 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Oct 2006 11:09:24 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9FI9NYX002835; Sun, 15 Oct 2006 14:09:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9FI9NYJ013386; Sun, 15 Oct 2006 14:09:23 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 14:09:23 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.192]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 14:09:22 -0400 Message-Id: <4.3.2.7.2.20061015130905.02231f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 15 Oct 2006 13:09:21 -0500 To: Colin Perkins From: "James M. Polk" Subject: Re: [MMUSIC] Minor Errors found in RFC4566 In-Reply-To: <7BA1385F-73B1-4F00-A9D8-8C0B496F2BD0@csperkins.org> References: <4.3.2.7.2.20061013131620.02260e70@email.cisco.com> <4.3.2.7.2.20061013131620.02260e70@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Oct 2006 18:09:22.0922 (UTC) FILETIME=[0ACDE4A0:01C6F085] DKIM-Signature: a=rsa-sha1; q=dns; l=787; t=1160935763; x=1161799763; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[MMUSIC]=20Minor=20Errors=20found=20in=20RFC4566 |To:Colin=20Perkins=20; X=v=3Dcisco.com=3B=20h=3DmDwdCtSMKlaBPeKUZeNhDCEjn08=3D; b=UL7Zn6VWiw6L2wXhW62lvLaiuByON3tzyeprVPJvF+72FmUN+5rez8VoEx03Yn8ppMteP+Jk OPFAj4L7kRe2Gr49Ct2IJ5mzBD6i5v/iyXB7o4Uve1IsLHKzI5/MFI7O; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org perhaps I misspoke At 03:06 PM 10/15/2006 +0100, Colin Perkins wrote: >On 13 Oct 2006, at 19:24, James M. Polk wrote: >>In Section 6 "SDP Attributes", in the a=sendrecv and a=type: >>paragraphs, there are multiple references to H332, which points at >>reference [26] which is actually ITU-T's H.323 Recommendation - >>which also calls out H332 once in the references section. > >I'm not sure I understand the problem. Reference [26] in RFC 4566 is: > > [26] International Telecommunication Union, "H.323 extended for > loosely coupled conferences", ITU Recommendation H.332, > September 1998. > >which appears correct to be the correct reference to H.332, according >to the ITU website (http://www.itu.int/rec/T-REC-H.332-199809-I/en). > >Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 16 06:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPvt-0000fK-Ar; Mon, 16 Oct 2006 06:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPvr-0000fE-Lt for mmusic@ietf.org; Mon, 16 Oct 2006 06:42:55 -0400 Received: from smtp112.iad.emailsrvr.com ([207.97.245.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPvl-0007a2-DW for mmusic@ietf.org; Mon, 16 Oct 2006 06:42:55 -0400 Received: from counterpath.com (webmail9.r5.iad.mlsrvr.com [192.168.1.102]) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 4E9C644C064 for ; Mon, 16 Oct 2006 06:42:49 -0400 (EDT) Received: from ([10.238.10.70]) (proxying for 24.85.147.44) (Webmail authenticated user derek@counterpath.com, derek@counterpath.com); by webmail.counterpath.com with HTTP; Mon, 16 Oct 2006 06:42:49 -0400 (EDT) Message-ID: <51725.10.238.10.70.1160995369.webmail@10.238.10.70> Date: Mon, 16 Oct 2006 06:42:49 -0400 (EDT) From: derek@counterpath.com To: mmusic@ietf.org X-Mailer: Webmail.us v5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for open internet devices X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: derek@counterpath.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I submitted a small draft which outlines the proposed mechanism for simpl= ifying ICE for open internet devices and describes some of the open issue= s. Hopefully this will allow those that not been in the calls or closely = following the relevant email threads to get caught up on the debate.=20 This document may eventually be subsumed into core ice; there are argueme= nts for and against this which are outlined in the draft. Until it shows up in the repository it can be found at: https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-mmusic-i= ce-lite-00.txt -Derek _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 16 15:07:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXmv-0007bt-D0; Mon, 16 Oct 2006 15:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXms-0007ZW-I0 for mmusic@ietf.org; Mon, 16 Oct 2006 15:06:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXfI-0003Mb-8Q for mmusic@ietf.org; Mon, 16 Oct 2006 14:58:22 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Oct 2006 11:58:20 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GIwJQ8001467 for ; Mon, 16 Oct 2006 11:58:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GIwIBO019215 for ; Mon, 16 Oct 2006 11:58:19 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:58:11 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:58:11 -0700 Message-ID: <4533D642.5000004@cisco.com> Date: Mon, 16 Oct 2006 14:58:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 18:58:11.0155 (UTC) FILETIME=[06948A30:01C6F155] DKIM-Signature: a=rsa-sha1; q=dns; l=1128; t=1161025099; x=1161889099; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20call=20October=2017,=201-2pm=20EST=20is=20ON; X=v=3Dcisco.com=3B=20h=3DudrYEP7Cv4WJweH9BALLAYbU7ZM=3D; b=O6QD0+bkI4EgjFV11RaqB4WJorfhXfWvF8XMQ7q8L0HbiXWMdvW0YvAWiYSsG6EtC28o7RD+ xQ2O9H/B2/H9xfZewGc9qkc50tXLq8to/u6QfRd/gXK9jFPMRl54Kgn1; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [MMUSIC] ICE call October 17, 1-2pm EST is ON X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Agenda: See separate mail with remaining open issues. Join the Web Conference 1. Go to: http://meetingplace.cisco.com/join.asp?2203261 2. Fill in the My Name is field then click Attend Meeting 3. Accept any security warnings you receive and wait for the Meeting Room to initialize Join the Voice Conference 1. From the Meeting Room, click on CONNECT (top left pane) and follow the instructions on how to have the system call you or simply follow the Voice only Conference instructions below TO ATTEND A VOICE ONLY CONFERENCE All Users 1. Dial into Cisco MeetingPlace (see Local & Global Access Numbers link above) 2. Press 1 to attend the meeting 3. Follow the prompts to enter the Meeting ID 2203261 and join the meeting This works best from Internet Explorer. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 16 15:07:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXo2-00007q-0V; Mon, 16 Oct 2006 15:07:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXmy-0007ZW-Fn for mmusic@ietf.org; Mon, 16 Oct 2006 15:06:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXds-000384-2B for mmusic@ietf.org; Mon, 16 Oct 2006 14:56:53 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2006 11:56:51 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GIupG1015514 for ; Mon, 16 Oct 2006 11:56:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9GIupip004838 for ; Mon, 16 Oct 2006 11:56:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Oct 2006 11:56:51 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:56:51 -0700 Message-ID: <4533D5EF.2020405@cisco.com> Date: Mon, 16 Oct 2006 14:56:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 18:56:51.0201 (UTC) FILETIME=[D6EC8710:01C6F154] DKIM-Signature: a=rsa-sha1; q=dns; l=6189; t=1161025011; x=1161889011; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Remaining=20ICE=20open=20issues; X=v=3Dcisco.com=3B=20h=3D0F9d/GzDorygS+RRTtaJQBbdxRs=3D; b=o1jctgxrqs0ctIQtWFexMDbhZG0eNC8sLRP64X9B4fQWy2UBKAWR82EgO44CzQ4th0ONjpUy GvG2yzuoAteL+BFfB9P7dEk2w7FBJXnTjqhfgYmI5a0DBQx+GLztkCTj; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [MMUSIC] Remaining ICE open issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On the last ICE call, I indicated that I thought we were mostly done, but that I'd check for straggler open issues. Here is my list of whats closed and whats left, which we'll discuss on the call tomorrow. Please let me know if you see something that is an issue in your mind and not on either list: Open ---- MacDonald-1: Determination of controlling endpoint: through O/A negotiation or heuristic? Status: actively debating MacDonald-2: where should we put text for ICE-for-gateways, and should we hold up ICE for it? Status: actively debating Issue #5: Removing a peer derived candidate. There is currently no way to do it. Status: I suggested no one asked for this feature anyway, may as well leave it as is. No responses posted. Issue #8: The need for connectivity preconditions when you are running ICE is far from clear. Status: I put some text in -11 around this; saying they are only needed if you want the explicit signaling they provide. Need some feedback on whether this text is OK. Issue #9 (never posted AFAICT - just in the slides). Question is that 3pcc Flow III doesnt work with ICE-10. Status: Whether it will work depends on the algorithm for selecting the controlling entity. This has to be something that survives reordering of m/c lines, which can happen in flow III. Issue #10: ICE hammer. STUN checks themselves can cause lots of traffic on the network, and can be used to launch an attack. What to do about it? Status: I posted some ideas on the list, no response. Issue #11: ICE pacing. Should we allow ICE checks to go faster if codecs are at a faster rate? Status: There was some discussion of this on the calls, no real conclusion. We did agreed to make the Ta interval configurable and that some research would ideally be needed to find a good value. But thats about it. Issue #12: (never posted, in slides only). Question is whether to adjust the retransmit interval for STUN when used with ICE. Argument is that ICE transactions will often completely timeout Status: My suggestion in the slides and in the related discussion on behave was to leave it alone Issue #15: Obfuscation of candidate lines to protect from generic ALG Status: I propoed we not do this. There was agreement on the list from Francois and Christer. But it has come up on the calls. Holmberg-1: Christer proposed a way to return a STUN Server in a REGISTER response. The idea is to find one in a local network. Status: I proposed it be out of scope for ICE. Some back-and-forth with Christer, not clear where we are. I still think its out of scope. Holmberg-2: Christer raised an issue about handling of new media streams in a re-offer. You basically need to start a fresh. Status: I agree; with the ICE-states below, the idea is that there would be a set of logic that applies in the 'running' state, anda stream enters the running state when its new. My plan is to make changes in ice-12 to accomodate this. But would be good to make sure we're aligned on the approach. Holmberg-3: ICE checks for inactive lines? b=0 lines? Status: we agree ice checks are done if a line is a=inactive. Christer asks about b=0. Not clear. Holmberg-6: Reliable provisionals Status: Christer argues that the stuff in ICE about resending the 18x until a stun request arrives is a hack, we should be requiring reliable provisionals. No conclusion in discussions. Closed ------- Issue #1: Unified or separate checks across media streams Conclusion: ICE-11 has separate checks, though still coupled via the Frozen algorithm Issue #2: 32 bit space limit for priorities Conclusion: New formula in ICE-11 provides more than enough space Issue #3: limits on number of media streams Conclusion: Resolve in ICE-11 by having separate check lists for each stream. Now there are no limits on the number of media streams Issue #4: when is ICE done? Conclusion: this is NOT in iCE-11 yet. We have agreed to signal conclusion via the stun checks, and to have the stun checks indicate which pairs are selected. ICE is done when the done flag has been set for each component of each media stream by the controlling entity. Issue #6: what to do if keepalives fail? Conclusion: a few comments agreed with my suggestion to do nothing, that this was otuside the scope of ICE to solve Issue #7: forking and receipt of media Conclusion: ICE had this statement that you don't play media you receive unless you had received a check. This completely fails with forking. So, the functionality was removed from -11 Issue #13: when to send media? Conclusion: We agreed (though this is not in ICE-11) that media could be sent once done-ness is signaled via ICE, and could flow in both directions. I will have that in ICE-12 Issue #14: ICE states? DO we need them? Conclusion: Not in ICE-11, but we agreed I think that this made sense. I was going to add the three states per media stream. The need for this goes along with the resolution to #13. Holmberg-4; Option tag? Status: agreed to add an option tag. This will go into ice-12 Holmberg-5: port of zero? IP address of 0.0.0.0? Status: we agreed that no checks are sent for port of zero. We agree that checks are not sent for IP address of 0.0.0.0, and text needs to be added to say that ICE endpoints cannot use that to implement call hold when talking to another endpoint. That will go into ice-12 Matthews-1: spec mentions several times decisions made on whether you are the offerer or answerer. What if an O/A is in progress while the decision ahs to be made and this causes role reversal? Its a race condition. Status: agreed that, if needed, the role would be based on the initial role of offerer vs. answerer Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 16 15:47:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYQ9-0003rK-VW; Mon, 16 Oct 2006 15:46:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYQ8-0003qf-3d for mmusic@ietf.org; Mon, 16 Oct 2006 15:46:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYQ3-00042B-LO for mmusic@ietf.org; Mon, 16 Oct 2006 15:46:44 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2006 12:46:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GJkdRF011352; Mon, 16 Oct 2006 12:46:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GJkcAo009564; Mon, 16 Oct 2006 12:46:38 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Oct 2006 12:46:38 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 12:46:38 -0700 Message-ID: <4533E19D.2040206@cisco.com> Date: Mon, 16 Oct 2006 15:46:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: derek@counterpath.com Subject: Re: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for open internet devices References: <51725.10.238.10.70.1160995369.webmail@10.238.10.70> In-Reply-To: <51725.10.238.10.70.1160995369.webmail@10.238.10.70> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 19:46:38.0359 (UTC) FILETIME=[CB68AA70:01C6F15B] DKIM-Signature: a=rsa-sha1; q=dns; l=3163; t=1161027999; x=1161891999; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20draft-macdonald-mmusic-ice-lite-00=20--=20ice=20for=2 0open=09internet=0A=20devices; X=v=3Dcisco.com=3B=20h=3DCOtcwoPV9J5mLoFreIfE1ha+67A=3D; b=BhbsrrxdC1koWVu4VpnuVrA8RtIrOfEFG39AD1zTOgSzOfS2nN1ltCak2Uj8zNjtrP55eBOj 5KSYgYrzTXGRDgj5NYtvHeVcF4aXAlwLMPBZj8XIjrWsL1v3uz6Ul5ke; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for writing this up. I think there are two main issues in here. The first issue is whether description of a lightweight ICE implementation belongs in ICE or elsewhere. At this point, I buy Philip's arguments that we can't progress ICE till we're sure that works, and in that case, it makes more sense to include the description in an annex in the ICE spec. I think we all agree that the noramtive rules, like this active/passive thing, belong in the core protocol document once we agree on them. On the main technical issue, on the active/passive negotiation. You make a good point on the v4/v6 case. This won't work with my proposed heuristic. I don't object to negotiating in principle, I'm just trying to keep it simple. Perhaps it is easier to just negotiate this with the flag. The question then remains in my mind, what happens when both sides are passive. I think that you still want to do your own check and not just a triggered check. The reason is that sending a check is still necesary for avoiding the voice hammer attack. If a gateway never sends a check, a malicious caller will send an INVITE with the passive attribute set, and then gateway responds in kind. No checks are done, and the gateway floods the target. So, what do you think about an algorithm whereby we use the active/passive flag. If both sides are passive, the done flags are never set, neither side will send a re-invite for ICE reasons, but both sides will generate checks, respond to checks with a triggered check, and not send media until a check validates. So, the main complication for large gateways is not sending the check IMHO, but receiving the username and password for it. That is signaled through SIP. In distributed gateway implementation, it requires an MGCP extension to convey the username/password. If there were a way to avoid THAT it would be really good for gateways. I cannot see a way how that is not seriously flawed from a security perspective. Thanks, Jonathan R. derek@counterpath.com wrote: > I submitted a small draft which outlines the proposed mechanism for simplifying ICE for open internet devices and describes some of the open issues. Hopefully this will allow those that not been in the calls or closely following the relevant email threads to get caught up on the debate. > > This document may eventually be subsumed into core ice; there are arguements for and against this which are outlined in the draft. > > Until it shows up in the repository it can be found at: > > https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-mmusic-ice-lite-00.txt > > -Derek > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 08:45:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoJB-0007im-6J; Tue, 17 Oct 2006 08:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoJA-0007ic-1P for mmusic@ietf.org; Tue, 17 Oct 2006 08:44:36 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZoJ3-000291-8X for mmusic@ietf.org; Tue, 17 Oct 2006 08:44:36 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6B2A4FF; Tue, 17 Oct 2006 14:44:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:44:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Remaining ICE open issues Date: Tue, 17 Oct 2006 14:44:27 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59404161942@esealmw113.eemea.ericsson.se> In-Reply-To: <4533D5EF.2020405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Remaining ICE open issues Thread-Index: AcbxVr3YvWVIJMW+S/Gso35wNO9x/wAX8JiQ From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-OriginalArrivalTime: 17 Oct 2006 12:44:28.0436 (UTC) FILETIME=[FC02E540:01C6F1E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, A very good collection of the open issues. I have a couple of issues: FIRST, assume that the UAC supports ICE, but it is NOT located behind a NAT (or, it has no knowledge of any STUN/TURN servers). Now, the remote UAS may also support ICE, and it may be located behind a NAT. Now, if the UAC does not indicate support of ICE, my understanding is that the remote UAS will not use ICE either. I guess it would be good to describe (or refer to) "ice-lite" behavior in this case. SECOND, we have been talking about what happens when new media lines are added etc in the offer. But, what if the media parameters in the offer do NOT change (the UAC may change an offer e.g simply to do an hold/resume), but the media parameters in the answer change. I would just like to verify whether we think that is already covered in chapter 9.2 and 9.3. Regards, Christer =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 16. lokakuuta 2006 21:57 > To: IETF MMUSIC WG > Subject: [MMUSIC] Remaining ICE open issues >=20 > On the last ICE call, I indicated that I thought we were=20 > mostly done, but that I'd check for straggler open issues.=20 > Here is my list of whats closed and whats left, which we'll=20 > discuss on the call tomorrow. Please let me know if you see=20 > something that is an issue in your mind and not on either list: >=20 > Open > ---- >=20 > MacDonald-1: Determination of controlling endpoint: through=20 > O/A negotiation or heuristic? > Status: actively debating >=20 > MacDonald-2: where should we put text for ICE-for-gateways,=20 > and should we hold up ICE for it? > Status: actively debating >=20 > Issue #5: Removing a peer derived candidate. There is=20 > currently no way to do it. > Status: I suggested no one asked for this feature anyway, may=20 > as well leave it as is. No responses posted. >=20 > Issue #8: The need for connectivity preconditions when you=20 > are running ICE is far from clear. > Status: I put some text in -11 around this; saying they are=20 > only needed if you want the explicit signaling they provide.=20 > Need some feedback on whether this text is OK. >=20 > Issue #9 (never posted AFAICT - just in the slides). Question=20 > is that 3pcc Flow III doesnt work with ICE-10. > Status: Whether it will work depends on the algorithm for=20 > selecting the controlling entity. This has to be something=20 > that survives reordering of m/c lines, which can happen in flow III. >=20 > Issue #10: ICE hammer. STUN checks themselves can cause lots=20 > of traffic on the network, and can be used to launch an=20 > attack. What to do about it? > Status: I posted some ideas on the list, no response. >=20 > Issue #11: ICE pacing. Should we allow ICE checks to go=20 > faster if codecs are at a faster rate? > Status: There was some discussion of this on the calls, no=20 > real conclusion. We did agreed to make the Ta interval=20 > configurable and that some research would ideally be needed=20 > to find a good value. But thats about it. >=20 > Issue #12: (never posted, in slides only). Question is=20 > whether to adjust the retransmit interval for STUN when used=20 > with ICE. Argument is that ICE transactions will often=20 > completely timeout > Status: My suggestion in the slides and in the related=20 > discussion on behave was to leave it alone >=20 > Issue #15: Obfuscation of candidate lines to protect from generic ALG > Status: I propoed we not do this. There was agreement on the=20 > list from Francois and Christer. But it has come up on the calls. >=20 > Holmberg-1: Christer proposed a way to return a STUN Server=20 > in a REGISTER response. The idea is to find one in a local network. > Status: I proposed it be out of scope for ICE. Some=20 > back-and-forth with Christer, not clear where we are. I still=20 > think its out of scope. >=20 > Holmberg-2: Christer raised an issue about handling of new=20 > media streams in a re-offer. You basically need to start a fresh. > Status: I agree; with the ICE-states below, the idea is that=20 > there would be a set of logic that applies in the 'running'=20 > state, anda stream enters the running state when its new. My=20 > plan is to make changes in > ice-12 to accomodate this. But would be good to make sure=20 > we're aligned on the approach. >=20 > Holmberg-3: ICE checks for inactive lines? b=3D0 lines? > Status: we agree ice checks are done if a line is a=3Dinactive.=20 > Christer asks about b=3D0. Not clear. >=20 > Holmberg-6: Reliable provisionals > Status: Christer argues that the stuff in ICE about resending=20 > the 18x until a stun request arrives is a hack, we should be=20 > requiring reliable provisionals. No conclusion in discussions. >=20 > Closed > ------- >=20 > Issue #1: Unified or separate checks across media streams > Conclusion: ICE-11 has separate checks, though still coupled=20 > via the Frozen algorithm >=20 > Issue #2: 32 bit space limit for priorities > Conclusion: New formula in ICE-11 provides more than enough space >=20 > Issue #3: limits on number of media streams > Conclusion: Resolve in ICE-11 by having separate check lists=20 > for each stream. Now there are no limits on the number of=20 > media streams >=20 > Issue #4: when is ICE done? > Conclusion: this is NOT in iCE-11 yet. We have agreed to=20 > signal conclusion via the stun checks, and to have the stun=20 > checks indicate which pairs are selected. ICE is done when=20 > the done flag has been set for each component of each media=20 > stream by the controlling entity. >=20 > Issue #6: what to do if keepalives fail? > Conclusion: a few comments agreed with my suggestion to do=20 > nothing, that this was otuside the scope of ICE to solve >=20 > Issue #7: forking and receipt of media > Conclusion: ICE had this statement that you don't play media=20 > you receive unless you had received a check. This completely=20 > fails with forking. So, the functionality was removed from -11 >=20 > Issue #13: when to send media? > Conclusion: We agreed (though this is not in ICE-11) that=20 > media could be sent once done-ness is signaled via ICE, and=20 > could flow in both directions. I will have that in ICE-12 >=20 > Issue #14: ICE states? DO we need them? > Conclusion: Not in ICE-11, but we agreed I think that this=20 > made sense. I was going to add the three states per media=20 > stream. The need for this goes along with the resolution to #13. >=20 > Holmberg-4; Option tag? > Status: agreed to add an option tag. This will go into ice-12 >=20 > Holmberg-5: port of zero? IP address of 0.0.0.0? > Status: we agreed that no checks are sent for port of zero.=20 > We agree that checks are not sent for IP address of 0.0.0.0,=20 > and text needs to be added to say that ICE endpoints cannot=20 > use that to implement call hold when talking to another=20 > endpoint. That will go into ice-12 >=20 > Matthews-1: spec mentions several times decisions made on=20 > whether you are the offerer or answerer. What if an O/A is in=20 > progress while the decision ahs to be made and this causes=20 > role reversal? Its a race condition. > Status: agreed that, if needed, the role would be based on=20 > the initial role of offerer vs. answerer >=20 > Thanks, > Jonathan R. >=20 >=20 >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 08:48:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoMk-0002LK-9e; Tue, 17 Oct 2006 08:48:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoMi-0002LC-Qh for mmusic@ietf.org; Tue, 17 Oct 2006 08:48:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZoMa-000379-F5 for mmusic@ietf.org; Tue, 17 Oct 2006 08:48:16 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E68FF6AF; Tue, 17 Oct 2006 14:48:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:48:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for openinternet devices Date: Tue, 17 Oct 2006 14:48:06 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59404161973@esealmw113.eemea.ericsson.se> In-Reply-To: <51725.10.238.10.70.1160995369.webmail@10.238.10.70> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for openinternet devices Thread-Index: AcbxEJLkDfwur8ysQuK0HUbW/lTZOgA2EMnQ From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 17 Oct 2006 12:48:07.0239 (UTC) FILETIME=[7E6D9570:01C6F1EA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, You say that the most common use of this would be PSTN gateways. Would it be good to say that terminals that support "full" ICE can also use the lite behavior, in case they detect that they are not located behind a NAT? Regards, Christer =20 > -----Original Message----- > From: derek@counterpath.com [mailto:derek@counterpath.com]=20 > Sent: 16. lokakuuta 2006 13:43 > To: mmusic@ietf.org > Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice=20 > for openinternet devices >=20 > I submitted a small draft which outlines the proposed=20 > mechanism for simplifying ICE for open internet devices and=20 > describes some of the open issues. Hopefully this will allow=20 > those that not been in the calls or closely following the=20 > relevant email threads to get caught up on the debate.=20 >=20 > This document may eventually be subsumed into core ice; there=20 > are arguements for and against this which are outlined in the draft. >=20 > Until it shows up in the repository it can be found at: >=20 > https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdona ld-mmusic-ice-lite-00.txt >=20 > -Derek >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 11:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqwk-0000D0-Jm; Tue, 17 Oct 2006 11:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqwi-0000CG-JK for mmusic@ietf.org; Tue, 17 Oct 2006 11:33:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqwd-0004tM-6b for mmusic@ietf.org; Tue, 17 Oct 2006 11:33:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2006 08:33:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HFXU0V001517; Tue, 17 Oct 2006 08:33:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9HFXUin006822; Tue, 17 Oct 2006 08:33:30 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 08:33:30 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:33:29 -0700 Message-ID: <4534F7C8.8080908@cisco.com> Date: Tue, 17 Oct 2006 11:33:28 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for openinternet devices References: <5EB80D22825EEE42872083AD5BFFB59404161973@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59404161973@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 15:33:29.0905 (UTC) FILETIME=[98CC4210:01C6F201] DKIM-Signature: a=rsa-sha1; q=dns; l=1994; t=1161099210; x=1161963210; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20draft-macdonald-mmusic-ice-lite-00=20--=20ice=20for=0 9openinternet=0A=20devices; X=v=3Dcisco.com=3B=20h=3DIHdvuSYz0X45Dn9yQCZQ/QY4B3I=3D; b=PPrCkFv7LRjelW4lssnwboh3DGMwTt2B7RrHl6DjZPjz5ReN67SgUp+YcQ05RI0dlCOfPsGh LRT/77MH0QySeOgSsnKenFkozO1SSOhMWp7unbBu5xQwOODsind2Azil; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org NO. The difficulty in detecting this in a normal end-user device is the reason we moved away from the old STUN mechanism to ICE. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > You say that the most common use of this would be PSTN gateways. > > Would it be good to say that terminals that support "full" ICE can also > use the lite behavior, in case they detect that they are not located > behind a NAT? > > Regards, > > Christer > > > > >>-----Original Message----- >>From: derek@counterpath.com [mailto:derek@counterpath.com] >>Sent: 16. lokakuuta 2006 13:43 >>To: mmusic@ietf.org >>Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice >>for openinternet devices >> >>I submitted a small draft which outlines the proposed >>mechanism for simplifying ICE for open internet devices and >>describes some of the open issues. Hopefully this will allow >>those that not been in the calls or closely following the >>relevant email threads to get caught up on the debate. >> >>This document may eventually be subsumed into core ice; there >>are arguements for and against this which are outlined in the draft. >> >>Until it shows up in the repository it can be found at: >> >>https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdona > > ld-mmusic-ice-lite-00.txt > >>-Derek >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 11:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr1G-0002dR-TZ; Tue, 17 Oct 2006 11:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr1F-0002ch-QS for mmusic@ietf.org; Tue, 17 Oct 2006 11:38:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZr1D-0005GD-EX for mmusic@ietf.org; Tue, 17 Oct 2006 11:38:17 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2006 08:38:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HFcECE009881; Tue, 17 Oct 2006 08:38:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HFc7W6006597; Tue, 17 Oct 2006 08:38:12 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:38:11 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:38:11 -0700 Message-ID: <4534F8E2.3000100@cisco.com> Date: Tue, 17 Oct 2006 11:38:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] Remaining ICE open issues References: <5EB80D22825EEE42872083AD5BFFB59404161942@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59404161942@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 15:38:11.0408 (UTC) FILETIME=[40963500:01C6F202] DKIM-Signature: a=rsa-sha1; q=dns; l=1993; t=1161099495; x=1161963495; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Remaining=20ICE=20open=20issues; X=v=3Dcisco.com=3B=20h=3DHoVihsRwgY20HZh/6NzbJGqRwjk=3D; b=GQdsNpTmtPM2YISQzsiofL/OLyBuVi5zDls5tjHNqUcbm9J9RFVOUhz+ih4+xxCKVYg4omFd pZJAv1jdXBJQ0LH71PrfRgu/zNmAaDSy2iKdASV6RACDL6WCrq1WsT2W; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Christer Holmberg (JO/LMF) wrote: > Hi, > > A very good collection of the open issues. > > I have a couple of issues: > > FIRST, assume that the UAC supports ICE, but it is NOT located behind a > NAT (or, it has no knowledge of any STUN/TURN servers). Now, the remote > UAS may also support ICE, and it may be located behind a NAT. Now, if > the UAC does not indicate support of ICE, my understanding is that the > remote UAS will not use ICE either. I guess it would be good to describe > (or refer to) "ice-lite" behavior in this case. I don't follow. Support for ICE is different from the controlling/lite role negotiation we've been discussing. If a UAC supports ICE, it will have one or more candidates. If the UAS supports it, it will also have one more more candidates. ICE will then be used, period. Now the question is who is controlling. If the UAC for some reason inserted a single candidate and indicated non-controlling, but the UAS indicates controlling, the UAS is in controlling role. > > SECOND, we have been talking about what happens when new media lines are > added etc in the offer. But, what if the media parameters in the offer > do NOT change (the UAC may change an offer e.g simply to do an > hold/resume), but the media parameters in the answer change. I would > just like to verify whether we think that is already covered in chapter > 9.2 and 9.3. I dont think its covered. I think you'd need a rule that says don't do that. If you want to update media lines which requires an ICE restart, you have to send a new offer without a=remote-candidates to do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 13:16:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsY7-0005wz-3F; Tue, 17 Oct 2006 13:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWW-0005N6-Hk for mmusic@ietf.org; Tue, 17 Oct 2006 13:14:40 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsNQ-0008Bg-Ut for mmusic@ietf.org; Tue, 17 Oct 2006 13:05:34 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HH5CY2002678; Tue, 17 Oct 2006 11:05:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Remaining ICE open issues Date: Tue, 17 Oct 2006 11:05:11 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Remaining ICE open issues Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4g From: "Kevin Johns" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, I will not be able to participate in todays call. I looked over your open issues and have provided my thoughts below. Kevin=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Monday, October 16, 2006 12:57 PM To: IETF MMUSIC WG Subject: [MMUSIC] Remaining ICE open issues On the last ICE call, I indicated that I thought we were mostly done, but that I'd check for straggler open issues. Here is my list of whats closed and whats left, which we'll discuss on the call tomorrow. Please let me know if you see something that is an issue in your mind and not on either list: Open ---- MacDonald-1: Determination of controlling endpoint: through O/A negotiation or heuristic? Status: actively debating no strong opinion at this point. Simple is better at this point. MacDonald-2: where should we put text for ICE-for-gateways, and should we hold up ICE for it? Status: actively debating I think this is a great idea. If we can architect ICE such that documenting ICE-for-Gateways in a separate RFC then I am ok with this. However, given this is often difficult to do, I am not keen on ICE implementators needed to read two RFCs and having separate procedures to implement. Issue #5: Removing a peer derived candidate. There is currently no way to do it. Status: I suggested no one asked for this feature anyway, may as well leave it as is. No responses posted. no opinion Issue #8: The need for connectivity preconditions when you are running ICE is far from clear. Status: I put some text in -11 around this; saying they are only needed if you want the explicit signaling they provide. Need some feedback on whether this text is OK. have not had time to review -11 Issue #9 (never posted AFAICT - just in the slides). Question is that 3pcc Flow III doesnt work with ICE-10. Status: Whether it will work depends on the algorithm for selecting the controlling entity. This has to be something that survives reordering of m/c lines, which can happen in flow III. Given that flow IV can accomplish pretty much the same thing as flow III, I don't have any issues with this. Issue #10: ICE hammer. STUN checks themselves can cause lots of traffic on the network, and can be used to launch an attack. What to do about it? Status: I posted some ideas on the list, no response. have to go find this posting. Must have missed it. Issue #11: ICE pacing. Should we allow ICE checks to go faster if codecs are at a faster rate? Status: There was some discussion of this on the calls, no real conclusion. We did agreed to make the Ta interval configurable and that some research would ideally be needed to find a good value. But thats about it. There might be some policy implications with the pacing. Case in point is IMS and GPRS access networks. In this architecture from what I can tell, there has to be a flow in place to even do connectivity checks. It is unclear is a default flow can be used for such capabilities. Further, they have expressed concern with ICE since the STUN Relay accepts allocation requests on the same IP and port as the actually media for relaying. This forces them to open a default rule to allow for the allocation, but that then opens up to free media. One way to address this is to install a default rule that has such policy restrictions the media would not flow well. If we pace things to quickly, then the rule may start to get in the way... Issue #12: (never posted, in slides only). Question is whether to adjust the retransmit interval for STUN when used with ICE. Argument is that ICE transactions will often completely timeout Status: My suggestion in the slides and in the related discussion on behave was to leave it alone no opinion Issue #15: Obfuscation of candidate lines to protect from generic ALG Status: I propoed we not do this. There was agreement on the list from Francois and Christer. But it has come up on the calls. I agree, we should not do this. Holmberg-1: Christer proposed a way to return a STUN Server in a REGISTER response. The idea is to find one in a local network. Status: I proposed it be out of scope for ICE. Some back-and-forth with Christer, not clear where we are. I still think its out of scope. I agree this is out of scope. Holmberg-2: Christer raised an issue about handling of new media streams in a re-offer. You basically need to start a fresh. Status: I agree; with the ICE-states below, the idea is that there would be a set of logic that applies in the 'running' state, anda stream enters the running state when its new. My plan is to make changes in ice-12 to accomodate this. But would be good to make sure we're aligned on the approach. Sounds reasonable. Holmberg-3: ICE checks for inactive lines? b=3D0 lines? Status: we agree ice checks are done if a line is a=3Dinactive. Christer asks about b=3D0. Not clear. Holmberg-6: Reliable provisionals Status: Christer argues that the stuff in ICE about resending the 18x until a stun request arrives is a hack, we should be requiring reliable provisionals. No conclusion in discussions. I kind of agree with Christer especially since the first set of STUN checks are going to fail given the race condition of setting up the NAT bindings at the remote end. Seems you are guaranteed to always have to re-send the 18x... Closed ------- Issue #1: Unified or separate checks across media streams Conclusion: ICE-11 has separate checks, though still coupled via the Frozen algorithm Issue #2: 32 bit space limit for priorities Conclusion: New formula in ICE-11 provides more than enough space Issue #3: limits on number of media streams Conclusion: Resolve in ICE-11 by having separate check lists for each stream. Now there are no limits on the number of media streams Issue #4: when is ICE done? Conclusion: this is NOT in iCE-11 yet. We have agreed to signal conclusion via the stun checks, and to have the stun checks indicate which pairs are selected. ICE is done when the done flag has been set for each component of each media stream by the controlling entity. Issue #6: what to do if keepalives fail? Conclusion: a few comments agreed wiFrom mmusic-bounces@ietf.org Tue Oct 17 13:16:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsY7-0005wz-3F; Tue, 17 Oct 2006 13:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWW-0005N6-Hk for mmusic@ietf.org; Tue, 17 Oct 2006 13:14:40 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsNQ-0008Bg-Ut for mmusic@ietf.org; Tue, 17 Oct 2006 13:05:34 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HH5CY2002678; Tue, 17 Oct 2006 11:05:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Remaining ICE open issues Date: Tue, 17 Oct 2006 11:05:11 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Remaining ICE open issues Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4g From: "Kevin Johns" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, I will not be able to participate in todays call. I looked over your open issues and have provided my thoughts below. Kevin=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Monday, October 16, 2006 12:57 PM To: IETF MMUSIC WG Subject: [MMUSIC] Remaining ICE open issues On the last ICE call, I indicated that I thought we were mostly done, but that I'd check for straggler open issues. Here is my list of whats closed and whats left, which we'll discuss on the call tomorrow. Please let me know if you see something that is an issue in your mind and not on either list: Open ---- MacDonald-1: Determination of controlling endpoint: through O/A negotiation or heuristic? Status: actively debating no strong opinion at this point. Simple is better at this point. MacDonald-2: where should we put text for ICE-for-gateways, and should we hold up ICE for it? Status: actively debating I think this is a great idea. If we can architect ICE such that documenting ICE-for-Gateways in a separate RFC then I am ok with this. However, given this is often difficult to do, I am not keen on ICE implementators needed to read two RFCs and having separate procedures to implement. Issue #5: Removing a peer derived candidate. There is currently no way to do it. Status: I suggested no one asked for this feature anyway, may as well leave it as is. No responses posted. no opinion Issue #8: The need for connectivity preconditions when you are running ICE is far from clear. Status: I put some text in -11 around this; saying they are only needed if you want the explicit signaling they provide. Need some feedback on whether this text is OK. have not had time to review -11 Issue #9 (never posted AFAICT - just in the slides). Question is that 3pcc Flow III doesnt work with ICE-10. Status: Whether it will work depends on the algorithm for selecting the controlling entity. This has to be something that survives reordering of m/c lines, which can happen in flow III. Given that flow IV can accomplish pretty much the same thing th my suggestion to do nothing, that this was otuside the scope of ICE to solve Issue #7: forking and receipt of media Conclusion: ICE had this statement that you don't play media you receive unless you had received a check. This completely fails with forking. So, the functionality was removed from -11 Issue #13: when to send media? Conclusion: We agreed (though this is not in ICE-11) that media could be sent once done-ness is signaled via ICE, and could flow in both directions. I will have that in ICE-12 Issue #14: ICE states? DO we need them? Conclusion: Not in ICE-11, but we agreed I think that this made sense. I was going to add the three states per media stream. The need for this goes along with the resolution to #13. Holmberg-4; Option tag? Status: agreed to add an option tag. This will go into ice-12 Holmberg-5: port of zero? IP address of 0.0.0.0? Status: we agreed that no checks are sent for port of zero. We agree that checks are not sent for IP address of 0.0.0.0, and text needs to be added to say that ICE endpoints cannot use that to implement call hold when talking to another endpoint. That will go into ice-12 Matthews-1: spec mentions several times decisions made on whether you are the offerer or answerer. What if an O/A is in progress while the decision ahs to be made and this causes role reversal? Its a race condition. Status: agreed that, if needed, the role would be based on the initial role of offerer vs. answerer Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 13:16:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsY8-0005xM-8A; Tue, 17 Oct 2006 13:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWW-0005KS-Sk for mmusic@ietf.org; Tue, 17 Oct 2006 13:14:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsNP-0008Bi-0G for mmusic@ietf.org; Tue, 17 Oct 2006 13:05:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 10:05:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HH5E2Z016249 for ; Tue, 17 Oct 2006 10:05:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HH5ABE000113 for ; Tue, 17 Oct 2006 10:05:14 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 10:05:13 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:05:13 -0700 Message-ID: <45350D48.7050801@cisco.com> Date: Tue, 17 Oct 2006 13:05:12 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE call October 17, 1-2pm EST is ON References: <4533D642.5000004@cisco.com> In-Reply-To: <4533D642.5000004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 17:05:13.0413 (UTC) FILETIME=[6924EF50as flow III, I don't have any issues with this. Issue #10: ICE hammer. STUN checks themselves can cause lots of traffic on the network, and can be used to launch an attack. What to do about it? Status: I posted some ideas on the list, no response. have to go find this posting. Must have missed it. Issue #11: ICE pacing. Should we allow ICE checks to go faster if codecs are at a faster rate? Status: There was some discussion of this on the calls, no real conclusion. We did agreed to make the Ta interval configurable and that some research would ideally be needed to find a good value. But thats about it. There might be some policy implications with the pacing. Case in point is IMS and GPRS access networks. In this architecture from what I can tell, there has to be a flow in place to even do connectivity checks. It is unclear is a default flow can be used for such capabilities. Further, they have expressed concern with ICE since the STUN Relay accepts allocation requests on the same IP and port as the actually media for relaying. This forces them to open a default rule to allow for the allocation, but that then opens up to free media. One way to address this is to install a default rule that has such policy restrictions the media would not flow well. If we pace things to quickly, then the rule may start to get in the way... Issue #12: (never posted, in slides only). Question is whether to adjust the retransmit interval for STUN when used with ICE. Argument is that ICE transactions will often completely timeout Status: My suggestion in the slides and in the related discussion on behave was to leave it alone no opinion Issue #15: Obfuscation of candidate lines to protect from generic ALG Status: I propoed we not do this. There was agreement on the list from Francois and Christer. But it has come up on the calls. I agree, we should not do this. Holmberg-1: Christer proposed a way to return a STUN Server in a REGISTER response. The idea is to find one in a local network. Status: I proposed it be out of scope for ICE. Some back-and-forth with Christer, not clear where we are. I still think its out of scope. I agree this is out of scope. Holmberg-2: Christer raised an issue about handling of new media streams in a re-offer. You basically need to start a fresh. Status: I agree; with the ICE-states below, the idea is that there would be a set of logic that applies in the 'running' state, anda stream enters the running state when its new. My plan is to make changes in ice-12 to accomodate this. But would be good to make sure we're aligned on the approach. Sounds reasonable. Holmberg-3: ICE checks for inactive lines? b=3D0 lines? Status: we agree ice checks are done if a line is a=3Dinactive. Christer asks about b=3D0. Not clear. Holmberg-6: Reliable provisionals Status: Christer argues that the stuff in ICE about resending the 18x until a stun request arrives is a hack, we should be requiring reliable provisionals. No conclusion in discussions. I kind of agree with Christer especially since the first set of STUN checks are going to fail given the race condition of setting up the NAT bindings at the remote end. Seems you are guaranteed to always have to re-send the 18x... Closed ------- Issue #1: Unified or separate checks across media streams Conclusion: ICE-11 has separate checks, though still coupled via the Frozen algorithm Issue #2: 32 bit space limit for priorities Conclusion: New formula in ICE-11 provides more than enough space Issue #3: limits on number of media streams Conclusion: Resolve in ICE-11 by having separate check lists for each stream. Now there are no limits on the number of media streams Issue #4: when is ICE done? Conclusion: this is NOT in iCE-11 yet. We have agreed to signal conclusion via the stun checks, and to have the stun checks indicate which pairs are selected. ICE is done when the done flag has been set for each component of each media stream by the controlling entity. Issue #6: what to do if keepalives fail? Conclusion: a few comments agreed wi:01C6F20E] DKIM-Signature: a=rsa-sha1; q=dns; l=1600; t=1161104714; x=1161968714; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20ICE=20call=20October=2017,=201-2pm=20EST=20is=20ON; X=v=3Dcisco.com=3B=20h=3DKqc+0GM56cYuIpfMNwO78HPwOi0=3D; b=q4OPs89Awm0Z1gl+T8dA4pvedJ2CpuoSV1LvB2IP6qp5j01pT5xYoxPzPOepDCa/qV6F/Om9 2UAqbIXpbwRnNui+xPFmZxQdoyxhe0zIgeUhve0l0GISp6/PWJCqtLwY; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org For folks who are having trouble getting the phone numbers from the website, here are the dialin numbers: Frequently Dialed Phone Numbers: US/Canada: +1.866.432.9903 Japan: +81.3.5763.9394 India: +91.80.4103.3979 Australia: +61.2.8446.5260 United Kingdom: +44.20.8824.0117 And the conference ID is 2203261. -Jonathan R. Jonathan Rosenberg wrote: > Agenda: > > See separate mail with remaining open issues. > > > > Join the Web Conference > 1. Go to: http://meetingplace.cisco.com/join.asp?2203261 > > 2. Fill in the My Name is field then click Attend Meeting > > 3. Accept any security warnings you receive and wait for the Meeting > Room to initialize > > > Join the Voice Conference > 1. From the Meeting Room, click on CONNECT (top left pane) and follow > the instructions on how to have the system call you or simply follow the > Voice only Conference instructions below > > TO ATTEND A VOICE ONLY CONFERENCE > All Users > 1. Dial into Cisco MeetingPlace (see Local & Global Access Numbers link > above) > 2. Press 1 to attend the meeting > 3. Follow the prompts to enter the Meeting ID 2203261 and join the meeting > > > This works best from Internet Explorer. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic th my suggestion to do nothing, that this was otuside the scope of ICE to solve Issue #7: forking and receipt of media Conclusion: ICE had this statement that you don't play media you receive unless you had received a check. This completely fails with forking. So, the functionality was removed from -11 Issue #13: when to send media? Conclusion: We agreed (though this is not in ICE-11) that media could be sent once done-ness is signaled via ICE, and could flow in both directions. I will have that in ICE-12 Issue #14: ICE states? DO we need them? Conclusion: Not in ICE-11, but we agreed I think that this made sense. I was going to add the three states per media stream. The need for this goes along with the resolution to #13. Holmberg-4; Option tag? Status: agreed to add an option tag. This will go into ice-12 Holmberg-5: port of zero? IP address of 0.0.0.0? Status: we agreed that no checks are sent for port of zero. We agree that checks are not sent for IP address of 0.0.0.0, and text needs to be added to say that ICE endpoints cannot use that to implement call hold when talking to another endpoint. That will go into ice-12 Matthews-1: spec mentions several times decisions made on whether you are the offerer or answerer. What if an O/A is in progress while the decision ahs to be made and this causes role reversal? Its a race condition. Status: agreed that, if needed, the role would be based on the initial role of offerer vs. answerer Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 13:16:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsY8-0005xM-8A; Tue, 17 Oct 2006 13:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWW-0005KS-Sk for mmusic@ietf.org; Tue, 17 Oct 2006 13:14:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsNP-0008Bi-0G for mmusic@ietf.org; Tue, 17 Oct 2006 13:05:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 10:05:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HH5E2Z016249 for ; Tue, 17 Oct 2006 10:05:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HH5ABE000113 for ; Tue, 17 Oct 2006 10:05:14 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 10:05:13 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:05:13 -0700 Message-ID: <45350D48.7050801@cisco.com> Date: Tue, 17 Oct 2006 13:05:12 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE call October 17, 1-2pm EST is ON References: <4533D642.5000004@cisco.com> In-Reply-To: <4533D642.5000004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 17:05:13.0413 (UTC) FILETIME=[6924EF50:01C6F20E] DKIM-Signature: a=rsa-sha1; q=dns; l=1600; t=1161104714; x=1161968714; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20ICE=20call=20October=2017,=201-2pm=20EST=20is=20ON; X=v=3Dcisco.com=3B=20h=3DKqc+0GM56cYuIpfMNwO78HPwOi0=3D; b=q4OPs89Awm0Z1gl+T8dA4pvedJ2CpuoSV1LvB2IP6qp5j01pT5xYoxPzPOepDCa/qV6F/Om9 2UAqbIXpbwRnNui+xPFmZxQdoyxhe0zIgeUhve0l0GISp6/PWJCqtLwY; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org For folks who are having trouble getting the phone numbers from the website, here are the dialin numbers: Frequently Dialed Phone Numbers: US/Canada: +1.866.432.9903 Japan: +81.3.5763.9394 India: +91.80.4103.3979 Australia: +61.2.8446.5260 United Kingdom: +44.20.8824.0117 And the conference ID is 2203261. -Jonathan R. Jonathan Rosenberg wrote: > Agenda: > > See separate mail with remaining open issues. > > > > Join the Web Conference > 1. Go to: http://meetingplace.cisco.com/join.asp?2203261 > > 2. Fill in the My Name is field then click Attend Meeting > > 3. Accept any security warnings you receive and wait for the Meeting > Room to initialize > > > Join the Voice Conference > 1. From the Meeting Room, click on CONNECT (top left pane) and follow > the instructions on how to have the system call you or simply follow the > Voice only Conference instructions below > > TO ATTEND A VOICE ONLY CONFERENCE > All Users > 1. Dial into Cisco MeetingPlace (see Local & Global Access Numbers link > above) > 2. Press 1 to attend the meeting > 3. Follow the prompts to enter the Meeting ID 2203261 and join the meeting > > > This works best from Internet Explorer. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 17 14:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZtNX-0002S4-D1; Tue, 17 Oct 2006 14:09:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZtNV-0002Ra-UH for mmusic@ietf.org; Tue, 17 Oct 2006 14:09:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZtNS-0000G3-IQ for mmusic@ietf.org; Tue, 17 Oct 2006 14:09:25 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 11:09:22 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HI9Mrx019210 for ; Tue, 17 Oct 2006 11:09:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HI9MW4006787 for ; Tue, 17 Oct 2006 11:09:22 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 11:09:21 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 11:09:21 -0700 Message-ID: <45351C50.4030505@cisco.com> Date: Tue, 17 Oct 2006 14:09:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 18:09:21.0776 (UTC) FILETIME=[5EF28700:01C6F217] DKIM-Signature: a=rsa-sha1; q=dns; l=2033; t=1161108562; x=1161972562; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Notes=20from=20October=2017,=202006=20ICE=20call; X=v=3Dcisco.com=3B=20h=3DFU/bSbbUr6wl59MolfJXm2gnNU8=3D; b=Ue3AG4JgymknD0Stz3/UlURwqeHrBfBmqPaBZl9nIEWpks/UkYP6VPlzlA4dFMC7UrY/p91n +E7zDlzz/wMCkyG6FPLohK3d7TPUBFxLXgJuOXbcUDBUXtDpyYqKoZQr; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [MMUSIC] Notes from October 17, 2006 ICE call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org ICE Conference Call October 17, 2006 Participants ------------ Jonathan Rosenberg Philip Matthews Cullen Jennings Colin Perkins Eric Rescorla Derek MacDonald Brian Stucker Jean-Francois Mule MacDonald-1: Agree to use an explicit parameter to negotiate who is the controlling endpoint. Parameter will always be present, with two values (controlling-able or not). Agree that if both sides indicate that they are passive, ICE is basically not being utilized, as if one side did not support it. However, each endpoint MUST be prepared to receive a stun check and generate a response. Furthermore, it MAY generate a triggered check, and MAY/SHOULD? delay sending media until a check succeeds in order to prevent voice hammer. MacDonald-2: Agreeing to include ICE-lite profile as part of the main specification. To deal with compliance, define two types of implementatiosn - full and lite, and describe appropriate complaince rules for each. Matthews-X: Raised on the call. Philip wants to split out the keepalive procedure so something else could potentially be used for p2psip. Concerns that you would need a normative reference to a baseline mechanism anyway. Philip also wants to see failure recovery as part of the mechanism, and we have agreed not to do that at this time. Consensus was not to split out the keepalives. Agree to put words in the document that say that the spec says nothing about what to do if connectivity checks fail. Issue #11: Agree to make it inter-check pacing at 20ms, mention it has to be configurable and probably should be slower for wireless. Agree to suspend calls until the IETF meeting, and meet there instead. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 18 04:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Kr-0003YB-0F; Wed, 18 Oct 2006 03:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Kp-0003Y3-IU for mmusic@ietf.org; Wed, 18 Oct 2006 03:59:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6Kf-0002Td-Tm for mmusic@ietf.org; Wed, 18 Oct 2006 03:59:31 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3D6E9EDD; Wed, 18 Oct 2006 09:58:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 09:58:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for openinternet devices Date: Wed, 18 Oct 2006 09:58:30 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594041C39EC@esealmw113.eemea.ericsson.se> In-Reply-To: <4534F7C8.8080908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for openinternet devices Thread-Index: AcbyAZqiPOwgBNfmRdqQ0hMnd91iuQAiXFXA From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 18 Oct 2006 07:58:30.0706 (UTC) FILETIME=[339ED120:01C6F28B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, >The difficulty in detecting this in a normal end-user device is the reason we moved away from the old STUN mechanism to ICE. Ok. What about "mid-network" devices, then, like media servers etc? They may not be located behind a NAT. Regards, Christer >=20 > Christer Holmberg (JO/LMF) wrote: >=20 > > Hi, > >=20 > > You say that the most common use of this would be PSTN gateways. > >=20 > > Would it be good to say that terminals that support "full" ICE can=20 > > also use the lite behavior, in case they detect that they are not=20 > > located behind a NAT? > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: derek@counterpath.com [mailto:derek@counterpath.com] > >>Sent: 16. lokakuuta 2006 13:43 > >>To: mmusic@ietf.org > >>Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for=20 > >>openinternet devices > >> > >>I submitted a small draft which outlines the proposed mechanism for=20 > >>simplifying ICE for open internet devices and describes some of the=20 > >>open issues. Hopefully this will allow those that not been in the=20 > >>calls or closely following the relevant email threads to=20 > get caught up=20 > >>on the debate. > >> > >>This document may eventually be subsumed into core ice; there are=20 > >>arguements for and against this which are outlined in the draft. > >> > >>Until it shows up in the repository it can be found at: > >> > >>https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdona > >=20 > > ld-mmusic-ice-lite-00.txt > >=20 > >>-Derek > >> > >> > >>_______________________________________________ > >>mmusic mailing list > >>mmusic@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mmusic > >> > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 18 20:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLw4-0006xP-R3; Wed, 18 Oct 2006 20:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLw3-0006sc-Nx for mmusic@ietf.org; Wed, 18 Oct 2006 20:38:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLw0-00075N-ET for mmusic@ietf.org; Wed, 18 Oct 2006 20:38:59 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 18 Oct 2006 17:38:56 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9J0ct7Q002266; Wed, 18 Oct 2006 17:38:55 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9J0cqOV002816; Wed, 18 Oct 2006 17:38:53 -0700 (PDT) From: "Dan Wing" To: "'Kevin Johns'" Subject: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Wed, 18 Oct 2006 17:38:53 -0700 Message-ID: <000e01c6f316$f5aa0bf0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4gAEKFqiA= In-Reply-To: DKIM-Signature: a=rsa-sha1; q=dns; l=807; t=1161218335; x=1162082335; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:ICE's=20reliable=2018x=20[was=20RE=3A=20[MMUSIC]=20Remaining=20ICE=20ope n=20issues]; X=v=3Dcisco.com=3B=20h=3DlLebChqSkFm/llaSfrelvgEDXMs=3D; b=QYaoazny+oV63ChIO7DU0ctKaRYiQ0EHeO8+Ip1DEvLIwPWdy/5xvnlxG73pRKLr7/ER9jvk ciPxRD0q6WHbUik8mNJrEQ8Mzjz6YJpoQCWn+qRw2wSGWuQuJRJZUeUb; Authentication-Results: sj-dkim-5.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'IETF MMUSIC WG' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > Holmberg-6: Reliable provisionals > Status: Christer argues that the stuff in ICE about resending the 18x > until a stun request arrives is a hack, we should be > requiring reliable provisionals. No conclusion in discussions. NATs are hacks, too. While two hacks don't make a beautiful architecture, ICE's hack can also be viewed as a different means to the same end -- reliable 18x's when it matters. > I kind of agree with Christer especially since the first > set of STUN checks are going to fail given the race condition of > setting up the NAT bindings at the remote end. Seems you are > guaranteed to always have to re-send the 18x... I don't follow your argument that there's a race condition that will force 18x to be retransmitted. Could you explain that? -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 06:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaVUs-0001i6-K3; Thu, 19 Oct 2006 06:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaVUr-0001hs-Ud for mmusic@ietf.org; Thu, 19 Oct 2006 06:51:33 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaVUq-0008Oj-9n for mmusic@ietf.org; Thu, 19 Oct 2006 06:51:33 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7D0005AQCRKJ@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 19 Oct 2006 18:55:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7D00IROQCRRF@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 19 Oct 2006 18:55:39 +0800 (CST) Received: from w52438 ([10.164.5.40]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7D007RCQFSOF@szxml04-in.huawei.com> for mmusic@ietf.org; Thu, 19 Oct 2006 18:57:33 +0800 (CST) Date: Thu, 19 Oct 2006 18:44:00 +0800 From: Kylin Wei To: mmusic@ietf.org Message-id: <000001c6f36b$7d11b300$2805a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbza3yRuuVkrmTbT+yGWJcSK9+Fag== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [MMUSIC] RTSP: Can I specify multiple host address in RTSP 2.0 dest_addr field? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dear all: Can I specify multiple host addresses in RTSP 2.0 dest_addr field in the unicast mode? For example: C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 CSeq: 302 Transport: RTP/AVP;multicast;mode="PLAY", RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ "192.0.2.5:3457";"192.168.1.2:3456"/ "192.168.1.2:3457";mode="PLAY" Thanks in advance! Kylin Wei _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 08:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWec-0005ho-Gx; Thu, 19 Oct 2006 08:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWeb-0005hY-68 for mmusic@ietf.org; Thu, 19 Oct 2006 08:05:41 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWeQ-0006Sv-90 for mmusic@ietf.org; Thu, 19 Oct 2006 08:05:41 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B0A0B18; Thu, 19 Oct 2006 14:05:29 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:05:29 +0200 Received: from [153.88.13.106] ([153.88.13.106]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:05:29 +0200 Message-ID: <45376A08.3020309@ericsson.com> Date: Thu, 19 Oct 2006 14:05:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kylin Wei Subject: Re: [MMUSIC] RTSP: Can I specify multiple host address in RTSP 2.0dest_addr field? References: <000001c6f36b$7d11b300$2805a40a@china.huawei.com> In-Reply-To: <000001c6f36b$7d11b300$2805a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 12:05:29.0126 (UTC) FILETIME=[DE800460:01C6F376] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Kylin Wei skrev: > Dear all: > Can I specify multiple host addresses in RTSP 2.0 dest_addr field in the > unicast mode? > For example: > C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 > CSeq: 302 > Transport: RTP/AVP;multicast;mode="PLAY", > RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ > "192.0.2.5:3457";"192.168.1.2:3456"/ > "192.168.1.2:3457";mode="PLAY" No, not as you specify it. Currently RTSP allows the following ways and reason to provide multiple address. 1. Within a dest_addr there be one or more addresses. The reason that they may be multiple address is to allow the transport to define two address if need. This is fully scooped by the transport protocol specified. So for RTP/AVP there is allowed to be one or two addresses specifying destination for RTP and RTCP. 2. One may use multiple transport specifications. Each transport specification may specify different destinations and protocols and parameters. However the server will select the first that it can fulfill. Are you considering the above, or do you want to have it for some other purpose? For other purposes is currently not allowed. If you are considering to have one RTSP session that delivers media to multiple destination host that has some issues. The first is about configuring destination ports for a host the session is not running from. The second is about the security issues with such a solution. The denial of service issues with allowing unchecked delivery is very serious. I would like to know a bit more on what you consider to do. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 11:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzS-0003vh-41; Thu, 19 Oct 2006 11:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzR-0003v2-0f for mmusic@ietf.org; Thu, 19 Oct 2006 11:39:25 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZzI-0000th-MM for mmusic@ietf.org; Thu, 19 Oct 2006 11:39:24 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9JFdFlS017952; Thu, 19 Oct 2006 09:39:15 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Thu, 19 Oct 2006 09:39:14 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4gAEKFqiAAH0jnAA== From: "Kevin Johns" To: "Dan Wing" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan, I had the call flow backward in my head, so I don't think this is an issue as I originally thought. Here is what I was thinking: UE A -> INVITE -> UE B; The INVITE contains a set of candidate addresses for UE A Once UE B gathers its candidates, it can being sending connectivity checks in parallel with sending the 18X The First set of STUN Requests will fail since the NAT for UE A will block them as UE A has yet to transmit any STUN requests (it is still waiting for the 18x or has received it and is still building its list) and establish a binding. Depending on how long it takes UE A to build its list and send its checks, UE B may retransmit the 18x having not received any STUN requests. While the first set of STUN checks will fail for UE B, I do not see that this will result in a re-transmission of the 18x. Kevin -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, October 18, 2006 6:39 PM To: Kevin Johns Cc: 'Jonathan Rosenberg'; 'IETF MMUSIC WG' Subject: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] > Holmberg-6: Reliable provisionals > Status: Christer argues that the stuff in ICE about resending the 18x=20 > until a stun request arrives is a hack, we should be requiring=20 > reliable provisionals. No conclusion in discussions. NATs are hacks, too. While two hacks don't make a beautiful architecture, ICE's hack can also be viewed as a different means to the same end -- reliable 18x's when it matters. > I kind of agree with Christer especially since the first set of=20 > STUN checks are going to fail given the race condition of setting up=20 > the NAT bindings at the remote end. Seems you are guaranteed to=20 > always have to re-send the 18x... I don't follow your argument that there's a race condition that will force 18x to be retransmitted. Could you explain that? -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 13:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gabjt-000383-OE; Thu, 19 Oct 2006 13:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gabjr-00037s-Vq for mmusic@ietf.org; Thu, 19 Oct 2006 13:31:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gabjp-00011x-G4 for mmusic@ietf.org; Thu, 19 Oct 2006 13:31:27 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9JHVMJI009237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 Oct 2006 10:31:24 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.na.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9JHUJBg000688 for ; Thu, 19 Oct 2006 10:31:22 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 10:31:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Oct 2006 10:31:19 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B021B91E1@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Usage of a=group:LS Thread-Index: AcbzpGNHs5KBnGWUTHqpbd7XVqTnew== From: "Desineni, Harikishan" To: X-OriginalArrivalTime: 19 Oct 2006 17:31:20.0081 (UTC) FILETIME=[63C70010:01C6F3A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [MMUSIC] Usage of a=group:LS X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dear MMUSIC experts, As per RFC3388 "Grouping of Media Lines in SDP", it seems like LS semantics can be used to signal that audio and video in a session must not be synchronized.=20 Following is an example. v=3D0 o=3DLaura 289083124 289083124 IN IP4 one.example.com t=3D0 0 c=3DIN IP4 129.92.64.56 a=3Dgroup:LS 1=20 a=3Dgroup:LS 2 m=3Daudio 30000 RTP/AVP 0 a=3Dmid:1 m=3Dvideo 30002 RTP/AVP 31 a=3Dmid:2 "a=3Dgroup:LS 1" indicates that audio is grouped with no other media. "a=3Dgroup:LS 2" indicates that video is grouped with no other media. As a result of the above, one can say that the offerer of the above SDP does not want to the receiver to synchronize audio and video streams. RFC3388 does not seem to prevent the above mentioned interpretation. Hence, I believe that such SDP offer should be treated as valid and complaint with RFC3388. I'd like know if I am incorrect in interpreting RFC3388 for the above case?=20 Thanks, - - - - - - - - - - - - - - - - - - Harikishan Desineni Qualcomm Inc., mailto:hd@qualcomm.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 15:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gadd7-0000pO-U1; Thu, 19 Oct 2006 15:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gadd6-0000pD-F3 for mmusic@ietf.org; Thu, 19 Oct 2006 15:32:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gadd5-0005ML-58 for mmusic@ietf.org; Thu, 19 Oct 2006 15:32:36 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 12:32:35 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJWYUX007396 for ; Thu, 19 Oct 2006 15:32:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JJWYYL000524 for ; Thu, 19 Oct 2006 15:32:34 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:32:34 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:32:34 -0400 Message-ID: <4537D2D2.5030800@cisco.com> Date: Thu, 19 Oct 2006 15:32:34 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:32:34.0062 (UTC) FILETIME=[53686AE0:01C6F3B5] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161286355; x=1162150355; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:IETF=20MMUSIC=20WG=20; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=nYJ++oV9R5D73V6oVz9z5CAHbtH9CWJWlyZTXnSRbKN2Xz2oeGHHzHNFlYUZ5cJa7bxe/vp2 HIu6ym8uC26sgC1+76bpUPIRluNOhX9aDmRdVruZwetENHCpRuVSvTju; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [MMUSIC] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 16:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6B-0006sc-T1; Thu, 19 Oct 2006 16:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6A-0006sC-Rb for mmusic@ietf.org; Thu, 19 Oct 2006 16:02:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gae64-0000Gp-BZ for mmusic@ietf.org; Thu, 19 Oct 2006 16:02:38 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1249D47; Thu, 19 Oct 2006 22:02:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 22:02:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Thu, 19 Oct 2006 22:02:17 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940424E81B@esealmw113.eemea.ericsson.se> In-Reply-To: <000e01c6f316$f5aa0bf0$c3f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4gAEKFqiAAKKhZIA== From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Kevin Johns" X-OriginalArrivalTime: 19 Oct 2006 20:02:19.0448 (UTC) FILETIME=[7B94B380:01C6F3B9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >>Holmberg-6: Reliable provisionals >>Status: Christer argues that the stuff in ICE about=20 >>resending the 18x until a stun request arrives is a hack, we should be requiring=20 >>reliable provisionals. No conclusion in discussions. >=20 >NATs are hacks, too. While two hacks don't make a beautiful=20 >architecture, ICE's hack can also be viewed as a different=20 >means to the same end -- reliable 18x's when it matters. So, just because we're dealing with something you regard being a hack, it justifies for us to also start doing hacks?=20 I don't think that is the right direction to take... Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 16:14:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeH4-00048A-C4; Thu, 19 Oct 2006 16:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeH1-000464-P5 for mmusic@ietf.org; Thu, 19 Oct 2006 16:13:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaeGX-0002KA-Pc for mmusic@ietf.org; Thu, 19 Oct 2006 16:13:51 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 13:13:21 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JKDLim027062; Thu, 19 Oct 2006 13:13:21 -0700 Received: from dwingwxp ([10.32.130.69]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JKDLAo006361; Thu, 19 Oct 2006 13:13:21 -0700 (PDT) From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Kevin Johns'" Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Thu, 19 Oct 2006 13:13:21 -0700 Keywords: direct-to-dwing Message-ID: <036a01c6f3bb$05f1bb80$4582200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940424E81B@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4gAEKFqiAAKKhZIAAAbVPg DKIM-Signature: a=rsa-sha1; q=dns; l=1031; t=1161288801; x=1162152801; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20ICE's=20reliable=2018x=20[was=20RE=3A=20[MMUSIC]=20Remaining=20I CE=20open=20issues]; X=v=3Dcisco.com=3B=20h=3DFf5CJ7G9Sluq83eISdnnNpaMspY=3D; b=MjHyRUn0AI7Z4whmOOam83n+o/QPk0VKZicxGSDVuU/STaRD1TC1rYGyjwbDF2Ac7SBNO4Gb hxd+zcJMIozwLB6Pq+sD2k3qoFrVkwN2YpfdqTUHmybVG2MSCiDyMJrF; Authentication-Results: sj-dkim-4.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'IETF MMUSIC WG' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > >>Holmberg-6: Reliable provisionals > >>Status: Christer argues that the stuff in ICE about > >>resending the 18x until a stun request arrives is a hack, > >>we should be requiring reliable provisionals. No conclusion > >>in discussions. > > > >NATs are hacks, too. While two hacks don't make a beautiful > >architecture, ICE's hack can also be viewed as a different > >means to the same end -- reliable 18x's when it matters. > > So, just because we're dealing with something you regard being a hack, > it justifies for us to also start doing hacks? > > I don't think that is the right direction to take... I said ICE's hack can also be viewed as a different means to the same end (reliable 18x responses). That is how I view it. Sending additional SIP signaling is about as significant a 'hack', but all in the SIP signaling plane. As you no doubt recall, there has been significant objection in the past for ICE to require reliable provisional responses. I doubt that has changed. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 16:55:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaev1-0002i0-Si; Thu, 19 Oct 2006 16:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaev0-0002gn-Ur for mmusic@ietf.org; Thu, 19 Oct 2006 16:55:10 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaeuv-0000aG-KG for mmusic@ietf.org; Thu, 19 Oct 2006 16:55:10 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3DE896AB; Thu, 19 Oct 2006 22:27:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 22:27:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Thu, 19 Oct 2006 22:27:32 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940424E83A@esealmw113.eemea.ericsson.se> In-Reply-To: <036a01c6f3bb$05f1bb80$4582200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Thread-Index: AcbxVr6GpCa/eYaLR6Whb+D+eb71egAtXn4gAEKFqiAAKKhZIAAAbVPgAABhV/A= From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Kevin Johns" X-OriginalArrivalTime: 19 Oct 2006 20:27:32.0728 (UTC) FILETIME=[0190E780:01C6F3BD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >>>>Holmberg-6: Reliable provisionals >>>>Status: Christer argues that the stuff in ICE about resending the=20 >>>>18x until a stun request arrives is a hack, we should be=20 >>>>requiring reliable provisionals. No conclusion in discussions. >>>=20 >>>NATs are hacks, too. While two hacks don't make a beautiful=20 >>>architecture, ICE's hack can also be viewed as a different=20 >>>means to the same end -- reliable 18x's when it matters. >>=20 >>So, just because we're dealing with something you regard=20 >>being a hack, it justifies for us to also start doing hacks? >>=20 >>I don't think that is the right direction to take... >=20 >I said ICE's hack can also be viewed as a different means to=20 >the same end (reliable 18x responses). That is how I view=20 >it. Sending additional SIP signaling is about as significant=20 >a 'hack', but all in the SIP signaling plane. >=20 >As you no doubt recall, there has been significant objection=20 >in the past for ICE to require reliable provisional responses. >=20 >I doubt that has changed. Has this been discussed in SIP/SIPPING (yes, I know many of the people there are also following the MMUSIC work)? And, as I asked before, for how long would you keep re-transmitting the 18x, if there is no STUN request coming to "acknowledge" it (you cannot assume there will be a STUN request, e.g. in case there is some NAT/gate/GW in the path which will not pass it)? I don't think we can use words as "send a few re-transmits", or "re-transmit for a while", in a standards specification. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 19 22:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GakTn-0000eu-MV; Thu, 19 Oct 2006 22:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GakTm-0000em-R9 for mmusic@ietf.org; Thu, 19 Oct 2006 22:51:26 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GakTl-0001Ah-21 for mmusic@ietf.org; Thu, 19 Oct 2006 22:51:26 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7E0030SZ3LG7@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 20 Oct 2006 11:02:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7E004QMZ3L3G@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 20 Oct 2006 11:02:09 +0800 (CST) Received: from w52438 ([10.164.5.40]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7E00KODYUJ1S@szxml03-in.huawei.com> for mmusic@ietf.org; Fri, 20 Oct 2006 10:56:47 +0800 (CST) Date: Fri, 20 Oct 2006 10:50:30 +0800 From: Kylin Wei Subject: RE: [MMUSIC] RTSP: Can I specify multiple host address in RTSP 2.0dest_addr field? In-reply-to: <45376A08.3020309@ericsson.com> To: 'Magnus Westerlund' Message-id: <000001c6f3f2$81828e50$2805a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbzduDPg1OyUoM8RV+wjJtgeKAjQgAeJNcg X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hello Westerlund: I'm thinking if one can order a program for others. For example one order a football match video record for some of his friends. So they can watch the same program at the same progress. Perhaps my use case is not perfect. As you had said, there are two issues. But RTSP also allow specify destination host which is not session originator, so I think specifying multiple destination hosts should be allowed. By the way, perhaps the description of dest_addr attribute in rfc2326bits should be made more unambiguous. Kylin Wei > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, October 19, 2006 8:05 PM > To: Kylin Wei > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP: Can I specify multiple host address in RTSP > 2.0dest_addr field? > > Kylin Wei skrev: > > Dear all: > > Can I specify multiple host addresses in RTSP 2.0 dest_addr field in the > > unicast mode? > > For example: > > C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 > > CSeq: 302 > > Transport: RTP/AVP;multicast;mode="PLAY", > > RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ > > "192.0.2.5:3457";"192.168.1.2:3456"/ > > "192.168.1.2:3457";mode="PLAY" > > No, not as you specify it. Currently RTSP allows the following ways and > reason to provide multiple address. > > 1. Within a dest_addr there be one or more addresses. The reason that > they may be multiple address is to allow the transport to define two > address if need. This is fully scooped by the transport protocol > specified. So for RTP/AVP there is allowed to be one or two addresses > specifying destination for RTP and RTCP. > > 2. One may use multiple transport specifications. Each transport > specification may specify different destinations and protocols and > parameters. However the server will select the first that it can fulfill. > > Are you considering the above, or do you want to have it for some other > purpose? For other purposes is currently not allowed. If you are > considering to have one RTSP session that delivers media to multiple > destination host that has some issues. The first is about configuring > destination ports for a host the session is not running from. The second > is about the security issues with such a solution. The denial of service > issues with allowing unchecked delivery is very serious. > > I would like to know a bit more on what you consider to do. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 20 02:59:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoLy-0001BM-V7; Fri, 20 Oct 2006 02:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoLv-00015T-2g for mmusic@ietf.org; Fri, 20 Oct 2006 02:59:35 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaoLX-0007SN-C7 for mmusic@ietf.org; Fri, 20 Oct 2006 02:59:35 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9K6xAWB012908 for ; Fri, 20 Oct 2006 09:59:10 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 09:59:10 +0300 Received: from [172.21.34.112] ([172.21.34.112]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Oct 2006 09:59:10 +0300 Message-ID: <453873BE.5020400@nokia.com> Date: Fri, 20 Oct 2006 09:59:10 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: multipart/mixed; boundary="------------070102030301060708010701" X-OriginalArrivalTime: 20 Oct 2006 06:59:10.0293 (UTC) FILETIME=[3E466850:01C6F415] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Subject: [MMUSIC] [Fwd: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --------------070102030301060708010701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A new version of the file transfer draft is available now. We have captured the comments and discussions we had in the past. Please review it and comment it. Please copy the authors and the list. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland --------------070102030301060708010701 Content-Type: message/rfc822; name*0="I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt" Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebe104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 23:05:39 +0300 Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 23:05:38 +0300 Received: from esdks002.ntc.nokia.com ([172.21.138.121]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 23:05:38 +0300 X-Scanned: Thu, 19 Oct 2006 23:05:25 +0300 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id k9JK5PY2032657; Thu, 19 Oct 2006 23:05:25 +0300 Received: from mgw-ext04.nokia.com (131.228.20.96) by esdks002.ntc.nokia.com 00m5Nd7T; Thu, 19 Oct 2006 23:05:24 EEST Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by mgw-ext04.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JK5MHq011004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Oct 2006 23:05:23 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae7A-0007mr-2f; Thu, 19 Oct 2006 16:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6O-0006yC-Ku for i-d-announce@ietf.org; Thu, 19 Oct 2006 16:02:52 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gadtz-0007g7-BO for i-d-announce@ietf.org; Thu, 19 Oct 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 46E51328BB for ; Thu, 19 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gadtz-0001Dm-43 for i-d-announce@ietf.org; Thu, 19 Oct 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: "ext i-d-announce-bounces@ietf.org" Message-Id: Date: Thu, 19 Oct 2006 15:50:03 -0400 X-Spam-Score: 0.00% X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-pstn-spam: W Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 19 Oct 2006 20:05:38.0740 (UTC) FILETIME=[F25E3F40:01C6F3B9] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Author(s) : M. Garcia-Martin, et al. Filename : draft-garcia-mmusic-file-transfer-mech-01.txt Pages : 31 Date : 2006-10-19 This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file . The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-garcia-mmusic-file-transfer-mech-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-19140014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-mmusic-file-transfer-mech-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19140014.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------070102030301060708010701 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --------------070102030301060708010701-- From mmusic-bounces@ietf.org Fri Oct 20 05:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaqjI-0006ZH-BN; Fri, 20 Oct 2006 05:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaqjG-0006Z9-RG for mmusic@ietf.org; Fri, 20 Oct 2006 05:31:50 -0400 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaqjF-0005Mt-Gn for mmusic@ietf.org; Fri, 20 Oct 2006 05:31:50 -0400 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 102814FEC0; Fri, 20 Oct 2006 12:31:44 +0300 (EET DST) Message-ID: <45389781.1060408@netlab.hut.fi> Date: Fri, 20 Oct 2006 12:31:45 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Desineni, Harikishan" Subject: Re: [MMUSIC] Usage of a=group:LS References: <2CA3E1B6CEC064449CAA7D0FAB46079B021B91E1@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B021B91E1@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > As per RFC3388 "Grouping of Media Lines in SDP", it seems like LS > semantics can be used to signal that audio and video in a session must > not be synchronized. I am curious how that would work. > Following is an example. > > v=0 > o=Laura 289083124 289083124 IN IP4 one.example.com > t=0 0 > c=IN IP4 129.92.64.56 > a=group:LS 1 > a=group:LS 2 > m=audio 30000 RTP/AVP 0 > a=mid:1 > m=video 30002 RTP/AVP 31 > a=mid:2 > > "a=group:LS 1" indicates that audio is grouped with no other media. > "a=group:LS 2" indicates that video is grouped with no other media. > > As a result of the above, one can say that the offerer of the above SDP > does not want to the receiver to synchronize audio and video streams. This appears to be beyond borderline and is not specified anywhere. > RFC3388 does not seem to prevent the above mentioned interpretation. > Hence, I believe that such SDP offer should be treated as valid and > complaint with RFC3388. If you take a closer look at many standards documents, I guess, you will often find cases where more things can be expressed than are well described and/or meaningful. A general rule to achieve interoperability is to stick to what _is_ described. > I'd like know if I am incorrect in interpreting RFC3388 for the above > case? The definition of RFC 3388 is describing in a positive way what you can achieve. Everything else is undefined. Also, the spec is phrased in a way that allows for backwards compatibility if the extension is not understood. Your suggested interpretation would clearly not meet this goal. So, I would like to explicitly discourage any "grey area" interpretation of the spec (which essentially equals second-guessing and will surely be done by different people in different ways). Regards, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 20 08:33:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GatYL-0004HP-GF; Fri, 20 Oct 2006 08:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GatYK-0004DS-E6 for mmusic@ietf.org; Fri, 20 Oct 2006 08:32:44 -0400 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GatYI-00061o-4O for mmusic@ietf.org; Fri, 20 Oct 2006 08:32:44 -0400 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id B8BD84FEC0; Fri, 20 Oct 2006 15:32:38 +0300 (EET DST) Message-ID: <4538C1E7.6080109@netlab.hut.fi> Date: Fri, 20 Oct 2006 15:32:39 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Jean-Francois Mule , Colin Perkins Subject: [MMUSIC] MMUSIC @ IETF 67: Agenda requests X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org MMUSIC is scheduled to meet once at the next IETF in San Diego: THURSDAY, November 9, 2006 0900-1130 Morning Session I Harbor Island III RAI mmusic Multiparty Multimedia Session Control WG We are soliciting input for the agenda. Please send emails to the co-chairs and state -- which Internet Draft you want to discuss -- how much time you will need -- who will be the presenter (if different from you) -- which issues to address Please remember the "Note well" statement and please also remember that meeting time is meant for solving problems rather than for general discussions. Working group draft and drafts tentatively accepted as WG items will get preference over individual submissions. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 20 10:39:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GavWG-0005HL-U4; Fri, 20 Oct 2006 10:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GavWG-0005HG-21 for mmusic@ietf.org; Fri, 20 Oct 2006 10:38:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GavW3-0002Zs-6n for mmusic@ietf.org; Fri, 20 Oct 2006 10:38:44 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2006 07:38:31 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KEcU3W018291; Fri, 20 Oct 2006 07:38:30 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9KEcLOr021706; Fri, 20 Oct 2006 07:38:30 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 10:38:28 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 10:38:28 -0400 Message-ID: <4538DF63.3080408@cisco.com> Date: Fri, 20 Oct 2006 10:38:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [MMUSIC] [Fwd: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt] References: <453873BE.5020400@nokia.com> In-Reply-To: <453873BE.5020400@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2006 14:38:28.0065 (UTC) FILETIME=[67FCB510:01C6F455] DKIM-Signature: a=rsa-sha1; q=dns; l=5994; t=1161355110; x=1162219110; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[MMUSIC]=20[Fwd=3A=20I-D=09ACTION=3Adraft-garcia-mmusic-file-tra nsfer-mech-01.txt]; X=v=3Dcisco.com=3B=20h=3DgtXAXuNR+nFSajovhN0J54AFRik=3D; b=l/5UviUGeXf3paCgbyjK10Md91kFId0gPbM9s4dM1sSpQvit3fOtuFVWUzcH4//Zx8PGgYws OjS/SsQfbhxROEMkaFgV9Vb3FHk71Ag5QJU63Yifr/HlTvfGn6x4LCLn; Authentication-Results: sj-dkim-6.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Miguel and all the authors, This looks good to me. I have a couple of small points and one somewhat more significant one. First the significant one: - When byte-range is used in a file selector, you call for using the msrp byte-range mechanism for file chunking to send only the selected portion of the file. I think this is a violation of the MSRP protocol. It requires that the first chunk sent always start at 1. If all the expected chunks are not received, the msrp implementation is going to think there was some sort of error or premature termination of a transfer. Since I believe this file transfer mechanism is intended to operate over a "standard" msrp, rather than extend it, I don't think you can do this. Instead, I think for purposes of msrp, the requested byte range must be transmitted as a message that always starts with byte 1. The recipient may then interpret the result as replacing the selected portion of a file. Because of this difference in semantics, it might also be less confusing if the selector used a different name. Now the small ones: - You specify the use of email "disposition" values, especially highlighting "inline" and "attachment" as meaningful. When used with email, there is an understood context for interpretting these. In particular, they mostly make sense in the context of a multipart body, where the "outer" or "first" part is "inline" or "message". Other parts are then related to that. So in particular, with "attachment", there is something to attach it to, and for "inline" there is something to inline it with. I don't understand what the analogous context is here. Is there some assumption that there is a relationship to some msrp stream in the same session that is being used for "normal" IM? Some guidance on how to interpret this would be helpful. - Figures 5/6: the file selector specifies a file of size 4096, but only 4092 bytes are transferred. Thanks, Paul Miguel Garcia wrote: > A new version of the file transfer draft is available now. We have > captured the comments and discussions we had in the past. > > Please review it and comment it. Please copy the authors and the list. > > /Miguel > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt > From: > "ext i-d-announce-bounces@ietf.org" > Date: > Thu, 19 Oct 2006 15:50:03 -0400 > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > CC: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer > Author(s) : M. Garcia-Martin, et al. > Filename : draft-garcia-mmusic-file-transfer-mech-01.txt > Pages : 31 > Date : 2006-10-19 > > This document provides a mechanism to negotiate the transfer of one > or more files between two endpoints by using the Session Description > Protocol (SDP) offer/answer model specified in RFC 3264. SDP is > extended to describe the attributes of the files to be transferred. > The offerer can either describe the files it wants to send, or the > files it would like to receive. The answerer can either accept or > reject the offer separately for each individual file . The transfer > of one or more files is initiated after a successful negotiation. > The Message Session Relay Protocol (MSRP) is defined as the default > mechanism to actually carry the files between the endpoints. The > conventions on how to use MSRP for file transfer are also provided in > this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-garcia-mmusic-file-transfer-mech-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 20 15:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0OJ-0006kX-DR; Fri, 20 Oct 2006 15:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0Ni-0005zs-SF; Fri, 20 Oct 2006 15:50:14 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb0NW-00013U-7b; Fri, 20 Oct 2006 15:50:14 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 33AE0328B4; Fri, 20 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gb0NW-0001u7-2S; Fri, 20 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-securityprecondition-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --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 : Security Preconditions for Session Description Protocol (SDP) Media Streams Author(s) : F. Andreasen, D. Wing Filename : draft-ietf-mmusic-securityprecondition-03.txt Pages : 15 Date : 2006-10-20 This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-securityprecondition-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-securityprecondition-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-securityprecondition-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-20134953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-securityprecondition-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-securityprecondition-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-20134953.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Sat Oct 21 10:53:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbID1-00053h-0Q; Sat, 21 Oct 2006 10:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbID0-00053R-37 for mmusic@ietf.org; Sat, 21 Oct 2006 10:52:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbICy-0005Hq-K7 for mmusic@ietf.org; Sat, 21 Oct 2006 10:52:22 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1988C4F0003; Sat, 21 Oct 2006 16:52:20 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Oct 2006 16:52:17 +0200 Received: from [153.88.16.126] ([153.88.16.126]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Oct 2006 16:51:59 +0200 Message-ID: <453A340F.30800@ericsson.com> Date: Sat, 21 Oct 2006 16:51:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kylin Wei Subject: Re: [MMUSIC] RTSP: Can I specify multiple host address in RTSP 2.0dest_addr field? References: <000001c6f3f2$81828e50$2805a40a@china.huawei.com> In-Reply-To: <000001c6f3f2$81828e50$2805a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2006 14:51:59.0557 (UTC) FILETIME=[76164F50:01C6F520] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Kylin Wei skrev: > Hello Westerlund: > > I'm thinking if one can order a program for others. For example one order a > football match video record for some of his friends. So they can watch the > same program at the same progress. Perhaps my use case is not perfect. Well the problem is that it doesn't work as you propose. As the inviting party can't allocate resources, for example ports the the receiving entity what you propose can't work. The reasonable thing to do is to send the URI to the party you like to invite. If actually like to have a session where a single entity controls what is shown, then consider to use a multicast address. I think the easiest way of accomplishing what you propose is a SIP based service where you can invite your friend into the session and then have an application service that forwards the streaming traffic to all participants you invited. Something done completely in RTSP needs massive extensions. Some which I don't think are particular suitable. Like how to resolve the rendezvous with the friend. > As you had said, there are two issues. But RTSP also allow specify > destination host which is not session originator, so I think specifying > multiple destination hosts should be allowed. Well, if you read the security issues with inviting non session originators you see that this should not be allowed unless you actually have a solution to this issue. However the main issue is to know where to transmit. So if you really are interested in resolving this within RTSP then please write an extension draft for this. > By the way, perhaps the description of dest_addr attribute in rfc2326bits > should be made more unambiguous. I have added the following to first paragraph of the dest_addr definition on page 98 of draft-ietf-mmusic-rfc2326bis-13. Note, only a single destination entity per transport spec is intended. The usage of multiple destination to distribute a single media to multiple entities is unspecified. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 23 03:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtsF-0008ME-1T; Mon, 23 Oct 2006 03:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtsB-0008Kf-8N for mmusic@ietf.org; Mon, 23 Oct 2006 03:05:23 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbtj9-0006bP-GU for mmusic@ietf.org; Mon, 23 Oct 2006 02:56:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9N6u0mx008349; Mon, 23 Oct 2006 09:56:00 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 09:55:55 +0300 Received: from [172.21.34.112] ([172.21.34.112]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 23 Oct 2006 09:55:56 +0300 Message-ID: <453C677B.8050600@nokia.com> Date: Mon, 23 Oct 2006 09:55:55 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] [Fwd: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt] References: <453873BE.5020400@nokia.com> <4538DF63.3080408@cisco.com> In-Reply-To: <4538DF63.3080408@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2006 06:55:56.0959 (UTC) FILETIME=[4A473AF0:01C6F670] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "Isomaki Markus \(Nokia-TP/Espoo\)" , mmusic@ietf.org, Gonzalo Camarillo X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Paul: Thanks for your comments. See inline discussion. Paul Kyzivat wrote: > Miguel and all the authors, > > This looks good to me. > > I have a couple of small points and one somewhat more significant one. > First the significant one: > > - When byte-range is used in a file selector, you call for using the > msrp byte-range mechanism for file chunking to send only the selected > portion of the file. I think this is a violation of the MSRP protocol. > It requires that the first chunk sent always start at 1. If all the > expected chunks are not received, the msrp implementation is going to > think there was some sort of error or premature termination of a > transfer. Since I believe this file transfer mechanism is intended to > operate over a "standard" msrp, rather than extend it, I don't think you > can do this. Instead, I think for purposes of msrp, the requested byte > range must be transmitted as a message that always starts with byte 1. > The recipient may then interpret the result as replacing the selected > portion of a file. Because of this difference in semantics, it might > also be less confusing if the selector used a different name. It is certainly not the intention of the draft to violate MSRP. I am not convinced that we are mandating something against MSRP, we are just providing a mechanism to indicate to the "MSRP application client" that it should start and stop the transfer at a certain offset, so MSRP thinks that the offset is his byte 1, but it is not the real byte 1 of the the file. So, it is about telling the MSRP protocol stack that what it considers a file is just a portion of it. I think MSRP should not be impacted. At least, I haven't seen where such violation in the MSRP draft. I believe we need to consult the MSRP authors about this issue. I will be posting a separate e-mail in SIMPLE and try to get an answer. As for the naming issue, if you think "selector" is a bad term, we are open to assign any other term that better reflects the semantics. > > Now the small ones: > > - You specify the use of email "disposition" values, especially > highlighting "inline" and "attachment" as meaningful. When used with > email, there is an understood context for interpretting these. In > particular, they mostly make sense in the context of a multipart body, > where the "outer" or "first" part is "inline" or "message". Other parts > are then related to that. So in particular, with "attachment", there is > something to attach it to, and for "inline" there is something to inline > it with. I don't understand what the analogous context is here. Is there > some assumption that there is a relationship to some msrp stream in the > same session that is being used for "normal" IM? Some guidance on how to > interpret this would be helpful. I think I see your point. Perhaps Gonzalo or Sal can comment on this issue. > > - Figures 5/6: the file selector specifies a file of size 4096, but only > 4092 bytes are transferred. There are a few oversights in the size of these figures, but I think is a bit more complicated. The are 3 sizes to consider: - Figures 4 and 5 contain the file size int he file-selector attribute of the SDP. It currently says 4096 bytes. This refers to the file excluding cpim overhead. - Figure 6 contains a 'size' parameter in the Content-Disposition header of the CPIM overhead. It currently reads 3996. This ought to be the same value as in the SDP in Figures 4 and 5, since it refers to the file size. - Figures 7, 8, 9, and 10 contain an MSRP Byte-Range header with a current value of 4092. This refers to what is transferred in the MSRP SEND request, so this includes the message/cpim overhead. So, in conclusion: Figures 4, 5, and 6 ought to have the same file size. Figures 7, 8, 9, and 10 must have a slightly bigger number (exactly 293 bytes more), since they include the cpim overhead. /Miguel > > Thanks, > Paul > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 23 15:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5An-0004gz-GL; Mon, 23 Oct 2006 15:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5Al-0004dI-3s for mmusic@ietf.org; Mon, 23 Oct 2006 15:09:19 -0400 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc5Ab-0004wI-Do for mmusic@ietf.org; Mon, 23 Oct 2006 15:09:19 -0400 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id EC42A4FECC; Mon, 23 Oct 2006 21:43:19 +0300 (EET DST) Message-ID: <453D0D47.8030904@netlab.hut.fi> Date: Mon, 23 Oct 2006 21:43:19 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org, Colin Perkins , Jean-Francois Mule Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [MMUSIC] Draft MMUSIC agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Folks, please find below the tentative agenda for the MMUSIC meeting in San Diego. If you should be on but aren't, please let us know. Joerg Multiparty Multimedia Session Control (MMUSIC) Working Group ============================================================ CHAIRS: Joerg Ott Colin Perkins Jean-Francois Mule AGENDA Thursday, 9 November 2006 at 09:00-11:30 ----------------------------------------- 09:00 Introduction and progress report (Chairs, 10) 09:10 ICE (Rosenberg, 60) draft-ietf-mmusic-ice-12.txt draft-ietf-mmusic-ice-tcp-01.txt 10:10 SDP Offer/Answer Mechanism to Enable File Transfer (Garcia, 10) draft-garcia-mmusic-file-transfer-mech-01.txt 10:20 SDP for ZRTP (Johnston, 15) draft-zimmermann-avt-zrtp-02.txt 10:35 Signaling of media decoding dependency in SDP (Schierl, 10) draft-schierl-mmusic-layered-codec-00.txt 10:45 An Evaluation of SIP for Streaming Media (Montpetit, 10) draft-whitehead-mmusic-sip-for-streaming-media-02.txt 10:55 SDP for RTSP (Marjou, 10) draft-marjou-mmusic-sdp-rtsp-00.txt 11:05 Best Effort SRTP (Kaplan, 10) draft-kaplan-mmusic-best-effort-srtp-01.txt 11:15 End _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 23 16:26:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6N4-0003Ji-Ls; Mon, 23 Oct 2006 16:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6N2-00036n-VA for mmusic@ietf.org; Mon, 23 Oct 2006 16:26:05 -0400 Received: from mx5-2.spamtrap.magma.ca ([209.217.78.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6Mo-0000Hb-Iq for mmusic@ietf.org; Mon, 23 Oct 2006 16:26:04 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx5-2.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id k9NKPhwR031048; Mon, 23 Oct 2006 16:25:43 -0400 Received: from [10.10.80.117] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id k9NKPgKt030793 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 Oct 2006 16:25:43 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Mon, 23 Oct 2006 16:25:40 -0400 To: Kevin Johns X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF MMUSIC WG , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 19-Oct-06, at 11:39 , Kevin Johns wrote: > Dan, > > I had the call flow backward in my head, so I don't think this is an > issue as I originally thought. Here is what I was thinking: > > UE A -> INVITE -> UE B; The INVITE contains a set of candidate > addresses > for UE A > Once UE B gathers its candidates, it can being sending connectivity > checks in parallel with sending the 18X > > The First set of STUN Requests will fail since the NAT for UE A will > block them as UE A has yet to transmit any STUN requests (it is still > waiting for the 18x or has received it and is still building its list) > and establish a binding. Depending on how long it takes UE A to build > its list and send its checks, UE B may retransmit the 18x having not > received any STUN requests. > > While the first set of STUN checks will fail for UE B, I do not see > that > this will result in a re-transmission of the 18x. > Kevin: If I understand your scenario correctly, then I think the following answers your question. If the NAT in front of UE A has address-dependent mapping, then you are correct in saying that the first set of STUN checks from UE B are likely to be dropped by A's NAT. Once the 18x arrives at UE A, then UE A will start its own set of STUN checks. These checks will install permission entries in A's NAT. Assuming that the NAT in front of UA B is reasonably nice (= not address-dependent mapping), then these STUN packets will make it to UA B, and a reply will come back. In addition, they will "trigger" UA B to resend its checks (see section 7.8 of the ICE-11 draft). These triggered checks are in addition to the normal resending mechanism of STUN. So assuming the 18x gets from UE B to UE A, no resending of this 18x is required. Does this help? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 23 19:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8q5-00046c-2x; Mon, 23 Oct 2006 19:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8q3-00046D-JU for mmusic@ietf.org; Mon, 23 Oct 2006 19:04:11 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc8q0-00041u-Tv for mmusic@ietf.org; Mon, 23 Oct 2006 19:04:11 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9NN458e018553; Mon, 23 Oct 2006 17:04:05 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Mon, 23 Oct 2006 17:04:05 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Thread-Index: Acb24W1gqN/Imt88Rrm1pgMmcoVd/AAFWNCg From: "Kevin Johns" To: "Philip Matthews" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF MMUSIC WG , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Philip, Yep. I had pretty much convinced myself things were ok, but am glad to get affirmation from others! Thanks for taking the time. Kevin=20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Monday, October 23, 2006 2:26 PM To: Kevin Johns Cc: Dan Wing; IETF MMUSIC WG Subject: Re: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] On 19-Oct-06, at 11:39 , Kevin Johns wrote: > Dan, > > I had the call flow backward in my head, so I don't think this is an=20 > issue as I originally thought. Here is what I was thinking: > > UE A -> INVITE -> UE B; The INVITE contains a set of candidate=20 > addresses for UE A Once UE B gathers its candidates, it can being=20 > sending connectivity checks in parallel with sending the 18X > > The First set of STUN Requests will fail since the NAT for UE A will=20 > block them as UE A has yet to transmit any STUN requests (it is still=20 > waiting for the 18x or has received it and is still building its list) > and establish a binding. Depending on how long it takes UE A to build=20 > its list and send its checks, UE B may retransmit the 18x having not=20 > received any STUN requests. > > While the first set of STUN checks will fail for UE B, I do not see=20 > that this will result in a re-transmission of the 18x. > Kevin: If I understand your scenario correctly, then I think the following answers your question. If the NAT in front of UE A has address-dependent mapping, then you are correct in saying that the first set of STUN checks from UE B are likely to be dropped by A's NAT. Once the 18x arrives at UE A, then UE A will start its own set of STUN checks. These checks will install permission entries in A's NAT. Assuming that the NAT in front of UA B is reasonably nice (=3D not address-dependent mapping), then these STUN packets will make it to UA B, and a reply will come back. In addition, they will "trigger" UA B to resend its checks (see section 7.8 of the ICE-11 draft). These triggered checks are in addition to the normal resending mechanism of STUN. So assuming the 18x gets from UE B to UE A, no resending of this 18x is required. Does this help? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 24 02:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcFmc-00048X-Dh; Tue, 24 Oct 2006 02:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcFma-0003xJ-Tc for mmusic@ietf.org; Tue, 24 Oct 2006 02:29:04 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcFmZ-0007s7-Cy for mmusic@ietf.org; Tue, 24 Oct 2006 02:29:04 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9O6SqXV016207; Tue, 24 Oct 2006 09:28:58 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 09:28:52 +0300 Received: from [172.21.34.112] ([172.21.34.112]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Oct 2006 09:28:52 +0300 Message-ID: <453DB2A4.8050804@nokia.com> Date: Tue, 24 Oct 2006 09:28:52 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] [Fwd: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt] References: <453873BE.5020400@nokia.com> <4538DF63.3080408@cisco.com> <453C677B.8050600@nokia.com> In-Reply-To: <453C677B.8050600@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 06:28:52.0135 (UTC) FILETIME=[AC388370:01C6F735] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Gonzalo Camarillo , mmusic@ietf.org, "Isomaki Markus \(Nokia-TP/Espoo\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Miguel Garcia wrote: > Hi Paul: > > Thanks for your comments. See inline discussion. > > Paul Kyzivat wrote: >> Miguel and all the authors, >> >> This looks good to me. >> >> I have a couple of small points and one somewhat more significant one. >> First the significant one: >> >> - When byte-range is used in a file selector, you call for using the >> msrp byte-range mechanism for file chunking to send only the selected >> portion of the file. I think this is a violation of the MSRP protocol. >> It requires that the first chunk sent always start at 1. If all the >> expected chunks are not received, the msrp implementation is going to >> think there was some sort of error or premature termination of a >> transfer. Since I believe this file transfer mechanism is intended to >> operate over a "standard" msrp, rather than extend it, I don't think >> you can do this. Instead, I think for purposes of msrp, the requested >> byte range must be transmitted as a message that always starts with >> byte 1. The recipient may then interpret the result as replacing the >> selected portion of a file. Because of this difference in semantics, >> it might also be less confusing if the selector used a different name. > > > It is certainly not the intention of the draft to violate MSRP. I am not > convinced that we are mandating something against MSRP, we are just > providing a mechanism to indicate to the "MSRP application client" that > it should start and stop the transfer at a certain offset, so MSRP > thinks that the offset is his byte 1, but it is not the real byte 1 of > the the file. So, it is about telling the MSRP protocol stack that what > it considers a file is just a portion of it. I think MSRP should not be > impacted. At least, I haven't seen where such violation in the MSRP draft. > > I believe we need to consult the MSRP authors about this issue. I will > be posting a separate e-mail in SIMPLE and try to get an answer. > We had a discussion with the MSRP authors in the SIMPLE mailining list, and we concluded that: - The terminology of the file transfer draft is misleading. The draft should not use the term "byte-range" for a new SDP attribute, because if the confusion with the MSRP Byte-Range header. Those are different things. It is suggested to use the term file-range instead. - It is possible to use a standard MSRP implementation for file transfer, and still have this suspend/resume feature (in essence, use the file-range attribute). However, the draft has to include some words about this use case clarifying the relation between the SDP attribute file-range and the MSRP header Byte-Range. Example: if I want to send or receive a file whose size is 40,000 bytes, but I just want to send or receive bytes 30,001 to 40,000, the SDP attribute will be a=file-range:30001-40000. Then, from the point of view of MSRP, there is a stream of bytes ranging from byte 1 to 10,000, so the MSRP Byte-Range header of the first chunk will be Byte-Range: 1-1024/10000; the second chunk 1025-2048/10000, etc. (assuming no CPIM and 1K chunks). The next version of the draft will have these changes in. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 24 09:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMMN-0006Kp-HL; Tue, 24 Oct 2006 09:30:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMMM-0006KW-1m for mmusic@ietf.org; Tue, 24 Oct 2006 09:30:26 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMM9-0003Tn-Sl for mmusic@ietf.org; Tue, 24 Oct 2006 09:30:26 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 118D05C8 for ; Tue, 24 Oct 2006 15:30:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 15:30:11 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 15:30:10 +0200 Message-ID: <453E1562.4090600@ericsson.com> Date: Tue, 24 Oct 2006 15:30:10 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: multipart/mixed; boundary="------------000207000907000607090301" X-OriginalArrivalTime: 24 Oct 2006 13:30:10.0657 (UTC) FILETIME=[8764DD10:01C6F770] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Subject: [MMUSIC] [Fwd: I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --------------000207000907000607090301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Me and my co-author has done a bit of review and updates on this document. We think it is ready to published. We intend to request AD sponsored publication for informational status after the IETF meeting. So please review the document, comments are solicited. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com --------------000207000907000607090301 Content-Type: message/rfc822; name="I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 21:53:24 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6F6DC.E614D200" Received: from mailgw5.ericsson.se ([193.180.251.36]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 21:53:23 +0200 Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145]) by mailgw5.ericsson.se (Symantec Mail Security) with ESMTP id 283E4400018; Mon, 23 Oct 2006 21:53:22 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5oa-0000cA-SA; Mon, 23 Oct 2006 15:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5oU-0000bE-28 for i-d-announce@ietf.org; Mon, 23 Oct 2006 15:50:22 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc5o9-0002HO-N2 for i-d-announce@ietf.org; Mon, 23 Oct 2006 15:50:22 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A6CDC3286B for ; Mon, 23 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5o9-0008N2-HZ for i-d-announce@ietf.org; Mon, 23 Oct 2006 15:50:01 -0400 Return-Path: X-OriginalArrivalTime: 23 Oct 2006 19:53:23.0513 (UTC) FILETIME=[E5CA8290:01C6F6DC] Errors-To: i-d-announce-bounces@ietf.org X-Spam-Score: -2.5 (--) List-Post: List-Id: i-d-announce.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 List-Archive: X-Brightmail-Tracker: AAAAAA== Content-class: urn:content-classes:message Subject: I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt Date: Mon, 23 Oct 2006 21:50:01 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt Thread-Index: Acb23Oozwg7dVMGBREqXiMvzBMLSGA== List-Help: List-Subscribe: , List-Unsubscribe: , From: To: Reply-To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F6DC.E614D200 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6F6DC.E614D200" ------_=_NextPart_002_01C6F6DC.E614D200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : SDP and RTSP extensions defined for 3GPP Packet-switched = Streaming Service and Multimedia Broadcast/Multicast Service Author(s) : P. Frojdh, M. Westerlund Filename : draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt Pages : 19 Date : 2006-10-23 =09 The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-mmusic-3gpp-sdp-rtsp= -04.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_002_01C6F6DC.E614D200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt

A New Internet-Draft is available from the on-line = Internet-Drafts
directories.


        Title   =         : SDP and RTSP extensions = defined for 3GPP Packet-switched Streaming Service and Multimedia = Broadcast/Multicast Service
        = Author(s)       : P. Frojdh, M. = Westerlund
        = Filename        : = draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt
        Pages   =         : 19
        Date    =         : 2006-10-23
       
The Packet-switched Streaming Service (PSS) and the Multimedia
   Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP = and RTSP
   with some extensions. This document provides information = about these
   extensions and registers the RTSP and SDP extensions with = IANA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westerlund-mmu= sic-3gpp-sdp-rtsp-04.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body = of
the message.
You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. = After
logging in, type "cd internet-drafts" and then
"get draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html<= /A>
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt".
       
NOTE:   The mail server at ietf.org can return the document = in
        MIME-encoded form by using = the "mpack" utility.  To use this
        feature, insert the command = "ENCODING mime" before the "FILE"
        command.  To decode the = response(s), you will need "munpack" or
        a MIME-compliant mail = reader.  Different MIME-compliant mail readers
        exhibit different behavior, = especially when dealing with
        "multipart" MIME = messages (i.e. documents which have been split
        up into multiple messages), = so check your local documentation on
        how to manipulate these = messages.

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

------_=_NextPart_002_01C6F6DC.E614D200-- ------_=_NextPart_001_01C6F6DC.E614D200 Content-Type: application/octet-stream; name="ATT2617293.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT2617293.TXT Content-Disposition: attachment; filename="ATT2617293.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0yMzEwNDU0OS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13ZXN0ZXJsdW5kLW1tdXNp Yy0zZ3BwLXNkcC1ydHNwLTA0LnR4dA0K ------_=_NextPart_001_01C6F6DC.E614D200 Content-Type: text/plain; charset="us-ascii"; name="draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt Content-Disposition: attachment; filename="draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt" RklMRSBERUxFVEVEDQotLS0tLS0tLS0tLS0NCg0KV2FybmluZyENCg0KVGhlIGF0dGFjaGVkIGZp bGUgZHJhZnQtd2VzdGVybHVuZC1tbXVzaWMtM2dwcC1zZHAtcnRzcC0wNC5VUkwgaGFzIG5vdCBi ZWVuIGRlbGl2ZXJlZC4NClRoZSByZWFzb24gaXMgZHVlIHRvIHRoYXQgdGhlIGZpbHRlciBGSUxF IEZJTFRFUj0gdW5uYW1lZDogKi51cmwgaXMgaW4gZWZmZWN0Lg0KDQoNCkVyaWNzc29uIEdyb3Vw IElU ------_=_NextPart_001_01C6F6DC.E614D200 Content-Type: text/plain; name="ATT2617294.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2617294.txt Content-Disposition: attachment; filename="ATT2617294.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C6F6DC.E614D200-- --------------000207000907000607090301 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --------------000207000907000607090301-- From mmusic-bounces@ietf.org Tue Oct 24 09:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMNd-00086U-PD; Tue, 24 Oct 2006 09:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMNd-000833-2V for mmusic@ietf.org; Tue, 24 Oct 2006 09:31:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMNT-0003q7-8r for mmusic@ietf.org; Tue, 24 Oct 2006 09:31:45 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 24 Oct 2006 06:31:35 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9ODVY8r017802; Tue, 24 Oct 2006 06:31:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9ODVYAo006653; Tue, 24 Oct 2006 06:31:34 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Oct 2006 06:31:34 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 06:31:33 -0700 Message-ID: <453E15B3.3020901@cisco.com> Date: Tue, 24 Oct 2006 09:31:31 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] References: <5EB80D22825EEE42872083AD5BFFB5940424E83A@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940424E83A@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 13:31:33.0137 (UTC) FILETIME=[B88E5010:01C6F770] DKIM-Signature: a=rsa-sha1; q=dns; l=1552; t=1161696694; x=1162560694; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20ICE's=20reliable=2018x=20[was=20RE=3A=20[MMUSIC]=20Remaining=20I CE=20open=20issues]; X=v=3Dcisco.com=3B=20h=3DfqeIHirKZxI5W0dxABXSu/Pi38Y=3D; b=lGf1y9cqxzsCAnETKiVQMxVxti7ZlFqziabejXuuoPbbX1PdMDwYBj0ERDNiP2vuf8WfCPHm f9C+ZRoxyDqXgUMPsjWnWfpswPHX+7ap8xp3/RaqVrBYgtoGwGsiVZcF; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Kevin Johns , IETF MMUSIC WG , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Christer Holmberg (JO/LMF) wrote: >>I said ICE's hack can also be viewed as a different means to >>the same end (reliable 18x responses). That is how I view >>it. Sending additional SIP signaling is about as significant >>a 'hack', but all in the SIP signaling plane. >> >>As you no doubt recall, there has been significant objection >>in the past for ICE to require reliable provisional responses. >> >>I doubt that has changed. > > > Has this been discussed in SIP/SIPPING (yes, I know many of the people > there are also following the MMUSIC work)? > > And, as I asked before, for how long would you keep re-transmitting the > 18x, if there is no STUN request coming to "acknowledge" it (you cannot > assume there will be a STUN request, e.g. in case there is some > NAT/gate/GW in the path which will not pass it)? I don't think we can > use words as "send a few re-transmits", or "re-transmit for a while", in > a standards specification. It doesn't say that. It says to use the retransmit intervals and timers as defined in RFC 3262, but that the retransmissions stop when you receive a STUN request or a PRACK (as opposed to just a PRACK with rfc3262). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 24 19:11:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVPq-0000Jd-2d; Tue, 24 Oct 2006 19:10:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVPo-0000JY-HJ for mmusic@ietf.org; Tue, 24 Oct 2006 19:10:36 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVPn-0004dI-2u for mmusic@ietf.org; Tue, 24 Oct 2006 19:10:36 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9ONAW8h021317; Tue, 24 Oct 2006 17:10:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] [Fwd: I-DACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt] Date: Tue, 24 Oct 2006 17:10:31 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fwd: I-DACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt] Thread-Index: Acb3cPAVgFt6kobQQoub3KYxPNzg9QAQs08g From: "Jean-Francois Mule" To: "Magnus Westerlund" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, Here are a few comments on draft-westerlund-mmusic-3gpp-sdp-rtsp-04.txt.=20 I've read this ID with fresh eyes, so please disregard some of these comments/questions if have been discussed and answered before. --- General comments and questions: 1.1/ Based on a quick read, this I-D seems to be an IETF "doc wrapper" for SDP and RTSP attributes defined in 3GPP. It gives very minimal information on the PSS/MBMS services those attributes are used in, and the reader is forced to fetch the 3gpp specs. =3D> questions: would it be possible to describe the context in which those attributes were defined in a little bit more details?=20 Is it possible to provide more formal grammar definitions (even informative ones) for the attributes? 1.2/ Terminology section It would help the readability of the document to have a terminology section where some of the terms are defined (rather than a bare bone glossary in section 1) 1.3/ Applicability Statement Some of the proposed parameters may be applicable beyond 3gpp's use; this is particularly true attributes like the video frame size (a=3Dframesize:). Given that the normative references and change control process live in 3GPP, should there be some kind of applicability statement for all the attributes declared in this document? Something like: x. Applicability Statement This document describes private extensions to SDP [] and RTSP [] and registers attributes that are normatively defined in 3GPP specifications x, y and z. The use of these extensions is only applicable inside a 3GPP Connectivity Network... The above seems appropriate given: - most of the attributes start with x- or 3GPP (and I understand the fact that these were defined in release 5 and that rfc 4566 discourages those x- uses) - this statement: " In the process of defining these services, there has occasionally been the need to extend both SDP and RTSP functionality. These extensions have mostly been in the form of SDP attributes and RTSP headers. The purpose of this informational document is to register these SDP and RTSP extensions, in order to avoid future conflicts, and also to raise the awareness of their existence within IETF. " 1.4/ attribute definitions: I don't find it useful to have docs that register attributes but don't even provide the syntax of the attribute, or even the unit of the attribute values. I will take one example of this with the media line attribute a=3DX-predecbufsize but this is a general comment: In section 3.1, the Internet-Draft states: "The "a=3DX-predecbufsize" attribute provides the size of the pre- decoder buffer.", and, in section 7.1: SDP Attribute ("att-field"): Attribute name: X-predecbufsize Long form: Pre-decoder buffer size Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: See Section 3.1 Reference: 3GPP TS 26.234, Section 5.3.3.2 Values: See Reference". Yet, 26.224 R5.7.0 states: - "a=3DX-predecbufsize:" This gives the suggested size of the Annex G hypothetical pre-decoder buffer in bytes. And 26.224 R7 states: - "a=3DX-predecbufsize:" If the field is an attribute for an H.263 or MPEG-4 Visual stream and rate adaptation (see clause 10.2) is not in use, this gives the suggested size of the Annex G hypothetical pre-decoder buffer in bytes. =3D=3D> this seems to imply that when the rate adaptation is in use, = this attribute is not well defined or its values should be interpreted differently if present? =3D=3D=3D> it seems to me that the draft should provide details: - explain the attribute's purpose in a more details than just pointing to Annex G and 3GPP spec sections,=20 - provide syntax for the value (even informative, you do that for some like 'a=3Dframesize:') - indicate units for the values - give an example A good example of what "more details" may mean here is RFC 3455: the reader can understand how those private SIP headers are defined and get 24.229 to know more. --- 2. 3gpp-specific or more general RTSP/SDP attributes? 2.1/ naming and declaration of "a=3Dframesize: -" We can't call this an attribute definition, it is a declaration at best. On this one, I wonder the applicability of the attribute: - if it is meant for broader applicability that the 2 3GPP services named in the draft (and I think it should), then this declaration is not enough; - if it is meant for 3gpp only, please name the attribute 3GPP- In either case, I really think you have to provide more information in this draft.=20 2.2./ same comments as above for alt* 3/ section 6.7 - RTSP URI extension I'm not sure what this whole section means or what it is intended for. The first paragraph is purely descriptive and the second is using a normative verb without pointing to any registration. Is the intent of this section to warn implementers that some URIs for 3GP files may contain a track number and that to be valid, it should be the last URI segment?=20 Shouldn't this be about registering the 'trackID' RTSP URI extension for 3GP files? Why not re-use the terminology (track-ID, stream_id_token, stream_id, etc.) as in the referenced 26.234 section 5.3.3.1? An example would help, like=20 a=3Dcontrol:rtsp://mediaserver.com/movie.3gp/trackID=3D1 In short, this seems confusing to me and I'm not sure what to get out of this text. Hope this helps. Note that I have only done a partial review of the document. Jean-Francois. =20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 24, 2006 7:30 AM > To: mmusic (E-mail) > Subject: [MMUSIC] [Fwd: I-DACTION:draft-westerlund-mmusic-3gpp-sdp- > rtsp-04.txt] >=20 > Hi, >=20 > Me and my co-author has done a bit of review and updates on this > document. We think it is ready to published. We intend to request AD > sponsored publication for informational status after the IETF meeting. > So please review the document, comments are solicited. >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 25 05:48:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcfMQ-0004qN-Gd; Wed, 25 Oct 2006 05:47:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcfMP-0004qE-FP for mmusic@ietf.org; Wed, 25 Oct 2006 05:47:45 -0400 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcfMN-00054p-5J for mmusic@ietf.org; Wed, 25 Oct 2006 05:47:45 -0400 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id F0E034FECC; Wed, 25 Oct 2006 12:47:41 +0300 (EET DST) Message-ID: <453F32BD.1060107@netlab.hut.fi> Date: Wed, 25 Oct 2006 12:47:41 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins , Jean-Francois Mule , mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [MMUSIC] MMUSIC agenda posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The revised MMUSIC is now available at: http://www3.ietf.org/proceedings/06nov/agenda/mmusic.txt Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 25 11:30:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcki9-0006kB-3K; Wed, 25 Oct 2006 11:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcki7-0006gK-1z; Wed, 25 Oct 2006 11:30:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcki1-0000hZ-Mh; Wed, 25 Oct 2006 11:30:31 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k9PFUKYJ051871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2006 10:30:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIPPING LIST , simple@ietf.org, mmusic@ietf.org From: Robert Sparks Date: Wed, 25 Oct 2006 10:30:22 -0500 X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [MMUSIC] SIPit 19 summary posted to the SIP list. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org In case you're not subscribed to the SIP list, I've posted a summary of what we saw at SIPit 19 there (a copy is at http://www.sipit.net/report19.txt). Subsequent discussion as related to IETF activities should take place on the SIP list. If you have questions about the sipit itself, please send them to discussion@sipforum.org or directly to me. Thanks, RjS _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 25 12:55:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm2X-0005xO-P0; Wed, 25 Oct 2006 12:55:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm2W-0005xJ-7g for mmusic@ietf.org; Wed, 25 Oct 2006 12:55:40 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcm2U-0000qy-7T for mmusic@ietf.org; Wed, 25 Oct 2006 12:55:40 -0400 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Gcm2T-000Ezc-Gr for mmusic@ietf.org; Wed, 25 Oct 2006 12:55:37 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <453F9708.80006@sipstation.com> Date: Wed, 25 Oct 2006 11:55:36 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [MMUSIC] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org All, The ZRTP I-D has been updated. There are lots of changes in the document including: - Discussion of how ZRTP compares using the criteria in draft-wing-rtpsec-keying-eval-01.txt - Discovery and authentication of ZRTP through the signaling channel and the definitions and ABNF of three SDP attributes a=zrtp, a=zrtp-sas, a=zrtp-sasvalue. - New Multistream key agreement mode allowing SRTP keys for multiple media streams in a session to be derived from a single ZRTP DH exchange. - CRC protection of ZRTP messages against transport errors using a 32 bit CRC algorithm - Use of RTP no-op packets instead of comfort noise packets - Simplified shared secret comparison algorithm - New Stay secure and Disclosure flags - More details on caching of retained shared secrets including expiration intervals - Removal of Error message - Reason field added to GoClear - Discussion of the behavior of intermediary devices that might implement ZRTP We will be discussing the changes in the ZRTP protocol in the AVT working group and the SDP attributes in MMUSIC. As always, comments and feedback are most welcome. Thanks, Alan -------- Original Message -------- Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt Date: Tue, 24 Oct 2006 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP Author(s) : P. Zimmermann, et al. Filename : draft-zimmermann-avt-zrtp-02.txt Pages : 52 Date : 2006-10-24 This document defines ZRTP, RTP (Real-time Transport Protocol) header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a Public Key Infrastructure (PKI) infrastructure. For the media session, ZRTP provides confidentiality, protection against Man in the Middle (MitM) attacks, and, in cases where a secret is available from the signaling protocol, authentication. ZRTP can utilize three Session Description Protocol (SDP) attributes to provide discovery and authentication through the signaling channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zimmermann-avt-zrtp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 25 13:57:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcn0D-00054g-CI; Wed, 25 Oct 2006 13:57:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcmz6-0004qK-VL for mmusic@ietf.org; Wed, 25 Oct 2006 13:56:12 -0400 Received: from adsl-63-193-97-10.dsl.snfc21.pacbell.net ([63.193.97.10] helo=zaphod.philzimmermann.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcmlA-000140-9K for mmusic@ietf.org; Wed, 25 Oct 2006 13:41:48 -0400 Received: from [10.0.1.201] (adsl-63-193-97-10.dsl.snfc21.pacbell.net [63.193.97.10]) (authenticated bits=0) by zaphod.philzimmermann.com (8.13.3/8.13.3) with ESMTP id k9PHfk0t075968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2006 10:41:46 -0700 (PDT) (envelope-from prz@mit.edu) In-Reply-To: <453F9FE4.3060007@sipstation.com> References: <453F9FE4.3060007@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <53F3E7FE-EF18-4BC5-AC65-83D5D3035827@mit.edu> Content-Transfer-Encoding: quoted-printable From: Philip Zimmermann Subject: [Fwd: [MMUSIC] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]] Date: Wed, 25 Oct 2006 10:41:41 -0700 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on zaphod.philzimmermann.com X-Spam-Score: 0.2 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org In the category of full disclosure, I wanted everyone to be aware of =20 an Intellectual Property disclosure I just made to the IETF. The =20 full text can be found at: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D752 While patents are distasteful to me, and I have seen how they have =20 been damaging in the crypto world, this is a purely defensive patent =20 that I have filed. My intention is to provide royalty-free licenses =20 to anyone implementing ZRTP under most circumstances. Provided they =20 are not suing me or my customers for infringing a patent. ;-) The exact text is: "In relation to any IETF standard incorporating the technology in the =20= ZRTP specification ("ZRTP Technology"), Philip Zimmermann (together with his successors and assignees, =93PRZ=94) will grant a royalty-free, non-=20 exclusive license to Qualified Parties to use the ZRTP Technology solely to the =20= extent necessary to implement and practice such IETF standards in strict =20 conformance with the IETF standards. As used herein, Qualified Parties means a =20 party who has not, does not and will not assert, in litigation or otherwise, =20 including in licensing discussions, any patent or other intellectual property =20 right against PRZ or any licensee of the libZRTP SDK. Any such license to a =20 Qualified Party shall terminate at once if such party asserts a patent or other =20 intellectual property right against PRZ or any licensee of the libZRTP SDK. PRZ =20 will grant non-exclusive licenses to Non-Qualified Parties on reasonable, =20 reciprocal non-discriminatory terms and conditions." I also wanted to use this to give some incentive for ZRTP =20 implementors to truthfully implement the ZRTP disclosure flag in =20 Appendix B of the new ZRTP Internet draft. See http://=20 zfoneproject.com/disclosureflag.html I will be in San Diego and would be happy to discuss this further =20 with anyone who wishes. -prz On Oct 25, 2006, at 10:33 AM, Alan Johnston wrote: > > > -------- Original Message -------- > Subject: [MMUSIC] [Fwd: I-D = ACTION:draft-zimmermann-avt-zrtp-02.txt] > Date: Wed, 25 Oct 2006 11:55:36 -0500 > From: Alan Johnston > To: IETF MMUSIC WG > > > > All, > > The ZRTP I-D has been updated. There are lots of changes in the =20 > document including: > > > - Discussion of how ZRTP compares using the criteria in draft-wing-=20 > rtpsec-keying-eval-01.txt > > - Discovery and authentication of ZRTP through the signaling =20 > channel and the definitions and ABNF of three SDP attributes =20 > a=3Dzrtp, a=3Dzrtp-sas, a=3Dzrtp-sasvalue. > > - New Multistream key agreement mode allowing SRTP keys for =20 > multiple media streams in a session to be derived from a single =20 > ZRTP DH exchange. > > - CRC protection of ZRTP messages against transport errors using a =20 > 32 bit CRC algorithm > > - Use of RTP no-op packets instead of comfort noise packets > > - Simplified shared secret comparison algorithm > > - New Stay secure and Disclosure flags > > - More details on caching of retained shared secrets including =20 > expiration intervals > > - Removal of Error message - Reason field added to GoClear > > - Discussion of the behavior of intermediary devices that might =20 > implement ZRTP > > > We will be discussing the changes in the ZRTP protocol in the AVT =20 > working group and the SDP attributes in MMUSIC. > > As always, comments and feedback are most welcome. > > Thanks, > Alan > > -------- Original Message -------- > Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt > Date: Tue, 24 Oct 2006 15:50:02 -0400 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > > > Title : ZRTP: Extensions to RTP for Diffie-Hellman Key = Agreement =20 > for SRTP > Author(s) : P. Zimmermann, et al. > Filename : draft-zimmermann-avt-zrtp-02.txt > Pages : 52 > Date : 2006-10-24 > =09 > This document defines ZRTP, RTP (Real-time Transport Protocol) header > extensions for a Diffie-Hellman exchange to agree on a session key > and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP > protocol is completely self-contained in RTP and does not require > support in the signaling protocol or assume a Public Key > Infrastructure (PKI) infrastructure. For the media session, ZRTP > provides confidentiality, protection against Man in the Middle (MitM) > attacks, and, in cases where a secret is available from the signaling > protocol, authentication. ZRTP can utilize three Session Description > Protocol (SDP) attributes to provide discovery and authentication > through the signaling channel. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt > > To remove yourself from the I-D Announcement list, send a message =20 > to i-d-announce-request@ietf.org with the word unsubscribe in the =20 > body of the message. You can also visit https://www1.ietf.org/=20 > mailman/listinfo/I-D-announce to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username "anonymous" and a password of your e-mail address. After =20 > logging in, type "cd internet-drafts" and then "get draft-=20 > zimmermann-avt-zrtp-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-=20 > sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > ---------------------------------------------- Philip R Zimmermann prz@mit.edu http://philzimmermann.com tel +1 650 322-7223 (spelled with 2 n's) fax +1 650 322-7877 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 25 17:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcq0n-0006Eq-PR; Wed, 25 Oct 2006 17:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcq0m-0006Dm-Bm for mmusic@ietf.org; Wed, 25 Oct 2006 17:10:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcq0i-0004VT-1j for mmusic@ietf.org; Wed, 25 Oct 2006 17:10:08 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2006 14:10:03 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PLA3Ra011872 for ; Wed, 25 Oct 2006 14:10:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9PLA3Aq007213 for ; Wed, 25 Oct 2006 14:10:03 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Oct 2006 14:10:03 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 14:10:02 -0700 Message-ID: <453FD2AA.5070302@cisco.com> Date: Wed, 25 Oct 2006 17:10:02 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 21:10:02.0749 (UTC) FILETIME=[EFF9BAD0:01C6F879] DKIM-Signature: a=rsa-sha1; q=dns; l=826; t=1161810603; x=1162674603; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE-tcp=20now=20available; X=v=3Dcisco.com=3B=20h=3DfnYYkL2P/p64TD/3TQo5NWv0euM=3D; b=cPkLLzI0VL+7vorof8jpbKrq+PP1N0GxKbEsSlEXYHcyh2DEniQuYh5jM5quNdThhU/hCA5g luIA/jOttpfm9NgYpC5QAvL9wptpyUEHNmkzxdI3NdoDOeWOsfGLvRwq; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [MMUSIC] ICE-tcp now available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I've submitted an update to the ICE-tcp draft. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-tcp-02.txt This is pretty much a total rewrite to align with the new ICE. The really good news is that the algorithm in ICE-10 onwards is much more TCP friendly. So much so that very little else needs to be said; mostly it just works for TCP. THe main new feature is support for TLS as well as just TCP. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 25 17:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpvG-0003eC-AY; Wed, 25 Oct 2006 17:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpvE-0003bt-8W for mmusic@ietf.org; Wed, 25 Oct 2006 17:04:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcpub-0003Aw-6E for mmusic@ietf.org; Wed, 25 Oct 2006 17:03:55 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2006 14:03:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PL3iWJ015685 for ; Wed, 25 Oct 2006 14:03:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9PL3iW4021109 for ; Wed, 25 Oct 2006 14:03:44 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 14:03:44 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 14:03:44 -0700 Message-ID: <453FD12F.1010704@cisco.com> Date: Wed, 25 Oct 2006 17:03:43 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 21:03:44.0221 (UTC) FILETIME=[0E5AF0D0:01C6F879] DKIM-Signature: a=rsa-sha1; q=dns; l=6222; t=1161810224; x=1162674224; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE-12=20now=20available; X=v=3Dcisco.com=3B=20h=3DETAKpxRQfTE94YVO1oEKxUPqjlM=3D; b=BHBACigtmInLyYpkcR8xdwjT+/cXXQVjOcbc1SNRKpNnvGrS+TqI8t1HQxrj0sNXy8YoezI4 LsRViGkTNusWIvCiuHo8457lR0z8F4T9voFgQxrDiCMTlryh7U9QkBJT; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [MMUSIC] ICE-12 now available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Folks, ICE-12 is now available. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-12.txt Changes include: * Bad news - the main new features on future-proofing of selection algorithms, allowing restarts, a gateway mode, and media transmission have added 5 more pages compared to -11. ICE is gaining weight again :( * changed Ta default from 50ms to 20ms * added notion of two modes in ICE - full and passive-only. The latter is for things like PSTN gateways. Added an informative annex which summarizes ice processing for passive only devices; normative text is sprinkled throughout the document as needed. THis was actually a really big change, and required touching text nearly everywhere. Not a lot of real normative procedural changes, but it was a lot of work to make it clear what a passive-only agent has to do, vs. full. * introduced notion of passive and controlling roles for a session, and added rules for role determination. The rules are obvious when one side is passive-only. When both are full, the agent which sent the offer that started ICE processing is the controlling agent. This keeps the role fixed while ICE runs, even if offers and answers are exchanged for other reasons. However it allows an ICE restart to retrigger role selection. * when two passive only agents call each other, ICE is aborted completely, as if neither side supported it. This is somewhat different than what was discussed on our conference calls, where we hoped an agent could at least respond to checks. Turned out that required specifying a hybrid mode anyway (which we didn't want to do). This is simpler. If we want to end up with ICE for calls between two gateways to prevent voice hammer, the gateways just need to implement full mode. * added notion of states for connectivity checks, which can either be running or completed. * added the USE-CANDIDATE STUN attribute. This is included by the controlling agent to select the candidate pair that gets used. Added rules for how agents mark candidate pairs in the valid list as "selected" when they were validated by a check containing this attribute, or by a check in the reverse direction of a check containing this attribute. * defined new algorithm for concluding ICE. Passive agents continue checks for a component of a media stream until they see the USE-CANDIDATE flag, and then they stop. This allows the controlling agent to decide how long to let checks run for, and which pair gets used. A basic default algorithm is provided for controlling agents to set the USE-CANDIDATE flag: include it in every check (it works and basically produces the same algorithm as ICE-11 used). * once ICE concludes, an updated offer is sent by the controlling agent ONLY if the selected candidate pairs differ from the ones in the m/c-line. This has the nice side effect of eliminating extra SIP signaling in "good" un-natted networks. Indeed, the extra offer/answer is no longer present in the example in the Examples section. * rules for subsequent offers now explicitly talk about adding media streams and how ICE processing is restarted (using a change in username/password). Handling of 0.0.0.0 is described, as is recommendations for call hold. ICE restarts allow for graceful transition of media; you continue to use the old selected candidates until the ICE checks complete, at which point you switch over to the new. * Media transmission rules: you always send to the selected candidates in the Valid list (based on the STUN signaling). If these conflict with m/c-line, ignore m/c-line. This differs from what we discussed in the calls; separate note pending on that. Keepalives similarly go to wherever media is being sent. This is different from -11 which had a somewhat convoluted algorithm for triggering keepalives like they were a regular ICE check. With ICE states this wasn't necesary and changing that eliminated the need for the extra offer/answer exchange. * did NOT add the mechanism we discussed for "inserted" candidates. COnsequently, if an offer shows up and the m/c-line doesn't match a candidate ICE is aborted, like -11. This inserted mechanism was not going to work once I got into details; separate note pending on that too * removed open issue regarding removal of peer derived candidates; you can't remove any candidates without restarting ICE in fact. With an ICE restart this removes peer derived candidates too, so now there is a way to remove peer derived candidates. * ICE role changes are permitted if ICE restarts for all media streams * point out that ICE makes no recommendations on what to do if a keepalive fails; however, do call out that restarting ICE blindly is a bad idea * clarified that b=0 and a=inactive still count is in-use media streams for which ICE processing is done. * ICE now works with flow III of RFC 3725 (3pcc) and this is noted. I spent a lot of time agonizing over 3pcc flows and making them maximally interoperable with ICE; there are one or two seemingly bizarre rules on ICE restarting based on these use cases (for example, a call starts out with no ICE support, but a reinvite introduces a media stream with candidates - this is called out) * moved some of the formal definitions of the connectivity check usage into a later section in the ICE spec, so that the normative text flows more smoothly * added recommendation that DSCP markings in ICE match the media streams * noted that usage of STUN for reliability of 1xx doesnt change rules on offer/answer exchanges -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 08:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4mJ-0002Vb-CZ; Thu, 26 Oct 2006 08:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4mI-0002Up-H3 for mmusic@ietf.org; Thu, 26 Oct 2006 08:56:10 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4mB-0003FP-OO for mmusic@ietf.org; Thu, 26 Oct 2006 08:56:10 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Q00GAOUKYT3@siemenscomms.co.uk> for mmusic@ietf.org; Thu, 26 Oct 2006 13:55:46 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGYWJK>; Thu, 26 Oct 2006 13:55:35 +0100 Content-return: allowed Date: Thu, 26 Oct 2006 13:55:34 +0100 From: "Elwell, John" To: Hadriel Kaplan , Francois Audet , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A3466F9@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hadriel, Francois, Thanks for working on this update. Just one point. If both SDescriptions and MIKEY are offered (inclusion of a=crypto and a=key-mgmt lines) and a different payload type is also indicated for SRTP, this payload type would apply whether the SDescription-derived key or the MIKEY-derived key is used. So until the SDP answer arrives, it would still not be possible to render SRTP. Of course, in the case of SDescriptions it is not possible anyway, but in the case of certain MIKEY options it ought to be possible. Unfortunately to resolve this we would need somewhat more complex syntax in the a=srtp line. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 25 October 2006 20:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Session Description Protocol (SDP) > Offer/Answer Negotiation For Best-Effort Secure Real-Time > Transport Protocol > Author(s) : F. Audet, H. Kaplan > Filename : draft-kaplan-mmusic-best-effort-srtp-01.txt > Pages : 17 > Date : 2006-10-25 > > This document defines the requirements and a proposed solution for > an SDP Offer/Answer exchange model for negotiating > best-effort SRTP > keys, i.e., in a backward-compatible manner with non-SRTP > devices. > The proposed solution is a trivial interpretation of the usage of > the profile and the usage of SDP indication of [sdesc] and [kmgmt]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > ffort-srtp-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-kaplan-mmusic-best-effort-srtp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 16:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdC5z-0000n8-T7; Thu, 26 Oct 2006 16:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMu-0001ym-J5; Thu, 26 Oct 2006 15:58:24 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBEv-0007Ed-EM; Thu, 26 Oct 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6285326E55; Thu, 26 Oct 2006 19:50:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEv-0005Mg-7D; Thu, 26 Oct 2006 15:50:09 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-tcp-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --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 : TCP Candidates with Interactive Connectivity Establishment (ICE) Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-tcp-02.txt Pages : 15 Date : 2006-10-26 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Simple Traversal of UDP over NAT (STUN). ICE provides a general framework for describing alternates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-ice-tcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-ice-tcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26140248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-tcp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-tcp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26140248.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Oct 26 16:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdC5v-0000b2-U2; Thu, 26 Oct 2006 16:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMu-00021C-Sp; Thu, 26 Oct 2006 15:58:24 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBEu-0007E9-JA; Thu, 26 Oct 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 835EA26E57; Thu, 26 Oct 2006 19:50:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEu-0005L3-Cf; Thu, 26 Oct 2006 15:50:08 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:08 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --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 : Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-12.txt Pages : 75 Date : 2006-10-26 This document describes a protocol for Network Address Translator (NAT) traversal for multimedia session signaling protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Simple Traversal Underneath NAT (STUN) protocol, applying its binding discovery and relay usages, in addition to defining a new usage for checking connectivity between peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-ice-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-ice-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26121907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26121907.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Oct 26 17:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCz2-0005Fl-2l; Thu, 26 Oct 2006 17:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCym-0002fh-Nt for mmusic@ietf.org; Thu, 26 Oct 2006 17:41:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCxF-0002if-Iq for mmusic@ietf.org; Thu, 26 Oct 2006 17:40:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 14:40:01 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QLe12m030556 for ; Thu, 26 Oct 2006 17:40:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9QLe1DM006280 for ; Thu, 26 Oct 2006 17:40:01 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 17:40:01 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 17:40:00 -0400 Message-ID: <45412B2F.9060200@cisco.com> Date: Thu, 26 Oct 2006 17:39:59 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 21:40:00.0922 (UTC) FILETIME=[4A2EE7A0:01C6F947] DKIM-Signature: a=rsa-sha1; q=dns; l=5575; t=1161898801; x=1162762801; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE-12,=20SBCs=20and=20hotel=20ALGs |To:IETF=20MMUSIC=20WG=20; X=v=3Dcisco.com=3B=20h=3D0EX1F8iH3aa+Cdr21kP0eG7Kv7A=3D; b=qGxk+SG8AO/+qXYE3TVeKtOijeVBDZq+qgNHwns6Ja76IyMxIIJ8vB47uG4+KQaTvRu7F9KW fod4QTBhQA2aRJ06dKUHXU4A3XsTwIpJo/yB/CMnSomx2yYbXokz9mnd; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [MMUSIC] ICE-12, SBCs and hotel ALGs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org A big topic of discussion on the list and in our calls has been what ICE should do in the presence of SBCs and hotel-ALG and similar beasts which try and 'help' but get in the way. I had proposed a solution on the list here: http://www1.ietf.org/mail-archive/web/mmusic/current/msg04696.html THe essential idea was that ICE would look for the m/c-line to not match any existing candidates, and if not, treat it as a high priority candidate. If it works, use it, if not, fall back. This sounds great in theory, but when I got down to writing it up, some issues arose. Firstly, the proposal was based on the theory that an SBC would pass STUN packets on the RTP ports. I spoke to several vendors of SBCs and it turns out this is often not the case. Indeed, in their role as "security boxes", many of them will rate limit the RTP, or prevent early media, or check for the right payload types, etc., all of which will cause the STUN checks to fail even though the RTP will work. Furthermore, some SBCs will in fact terminate a call if they see no media traffic, so bypassing them will not help. THus, my proposed approach would make calls fail when they would otherwise work if we didn't try and make ICE work in the presence of SBCs. Secondly, the proposal flat out doesn't work for TCP, since the candidate line for TCP includes some crucial information (active/passive roles or SO), which is missing for the m/c-line. One of the things I accomplished with this set of revisions is a unification of the UDP and TCP mecahnisms. I think its a mistake to break that. Finally, it was going to make it harder to specify this "passive-only" mode, also known as ICE-for-gateways. In the current -12 a gateway doesn't even maintain a candidate list for its peer; with this proposal it would need to do some of it. So, ICE-12 does not contain the proposal in the mail above. Rather, it specifies that if an offer shows up, and the m/c-line doesn't match any candidate, you abort ICE processing (just like -11 and -10 said). It also adds that, when a re-invite comes to confirm the pairs selected by ICE, if the m/c-line doesn't match what is selected by ICE, use the pairs selected by ICE. My main rationale on the first piece of this (if m/c-line doesnt match a candidate, abort) is that we dont know what SBCs will or won't do. Their behaviors are not specified, and they are highly variable. If the purpose of ICE is to make voip *reliable*, then the most reliable thing is to abort ICE processing and go with the relays. In a real sense, the b2bua is a UA on the path; we abort ICE when an ICE-capable UA calls an ICE-unaware UA - thats the only safe thing to do. Same here. This does mean that if you have a non-ICE SBC in a network with ICE endpoints, you get an extra relay hop in the call path. Extra latency - but reliable. If however you make the SBC ice-aware, that problem goes away, and there are many ways to do that which we don't need to specify. I might argue that, within your own network, if you deploy ICE to endpoints and have non-ICE SBC, you should be happy it works at all let alone that it works with just an extra media hop. Consequently, ICE will only proceed in -12 if the m/c-line MATCHES a candidate. There is only one case I found where you still have some kind of non-ICE media intermediary on the path, and ICE would proceed - an ALG which leaves the m/c-line alone with its on the public side of the NAT. In that case, ICE checks can proceed and will most often validate that address anyway. In the case where both endpoints are behind the same NAT/ALG, ICE would find that the direct path works, and re-invite to it. NOW, the helpful ALG might rewrite the SDP to the public value. With ICE-12, media would still flow direct. There is also a case where the m/c-line don't match what ICE selected, even though there isn't an intermediary. That case is when severe packet loss causes each side to disagree on the selected candidates. In that case I think an agent should use what it thinks works, and that is why ICE-12 specifies to ignore the m/c-line in this case. Generally I don't like sending media to somewhere else than the m/c-lines. However, the important point is that in ICE-12, that ISNT going to happen except for these two cases, and the former case you reallly want to fix with TLS. That reduces the mismatch to one of a bad failure case, and if that is our only mismatch use case I am not so worried about it. Backing up one step further, this idea of 'getting around SBCs and ALGs' was never a real requirement for ICE, and I am worried that it is something that is fraught with problems. I don't want to try and dump lots more complexity into ICE to try and guess our way around SBC and ALG implementations. TLS is the surefire way to deal with ALGs. Let us design ICE for how it ought to work without SBCs and ALGs, make sure it has a backwards compatibility mode when they are present, and then declare victory. Right now, I think the market needs a light-as-possible and FINISHED ICE spec more than anything else. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 18:57:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEA1-00044b-Md; Thu, 26 Oct 2006 18:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdE9z-00042z-Es for mmusic@ietf.org; Thu, 26 Oct 2006 18:57:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdE57-0007q0-38 for mmusic@ietf.org; Thu, 26 Oct 2006 18:52:14 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2006 15:52:13 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QMqC8D032074 for ; Thu, 26 Oct 2006 15:52:12 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9QMq6bN015911 for ; Thu, 26 Oct 2006 15:52:12 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 18:51:40 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.224.94]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 18:51:40 -0400 Message-Id: <4.3.2.7.2.20061026173826.03a90de8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Oct 2006 17:51:39 -0500 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Oct 2006 22:51:40.0290 (UTC) FILETIME=[4CCE6620:01C6F951] DKIM-Signature: a=rsa-sha1; q=dns; l=396; t=1161903132; x=1162767132; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:New=20ID=20on=20conveying=20a=20DSCP=20marking/remarking=20in=20an=20Off er; X=v=3Dcisco.com=3B=20h=3DF3NZjaz/RmEJ+Hkd7pt3jVSqbp0=3D; b=GxNj9NBuCQAyPzn6jdFgcQ/Tt8c1ipDc0U8ilY0aoGiCltovYvYERqi8S0Lj6MVdtuY0YcVv vadCpwvKxTxUS1tEaS5RIl22BHwM298MDm1CV63iVudkb0ddhNwPEzhm; Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org MMUSIC WG I've written a new individual ID on how an offer can carry a DSCP marking for a session, to be used upon initial offer or an offer within an established session that needs remarking of the DSCP used for the RTP stream. This link to the ID is here: http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-00.txt I would appreciate comments Thanks James _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 20:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFno-0004xd-Q0; Thu, 26 Oct 2006 20:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFnn-0004va-6F for mmusic@ietf.org; Thu, 26 Oct 2006 20:42:27 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFnl-00044X-N8 for mmusic@ietf.org; Thu, 26 Oct 2006 20:42:27 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9R0ZaJ10285; Thu, 26 Oct 2006 20:35:36 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-12, SBCs and hotel ALGs Date: Thu, 26 Oct 2006 19:42:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCA99@zrc2hxm0.corp.nortel.com> In-Reply-To: <45412B2F.9060200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-12, SBCs and hotel ALGs Thread-Index: Acb5R/qc/0nbImpgTdyp/t1LO+o0awAGJr4A From: "Francois Audet" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree with your conclusion. Your last paragraph is exaclty what I've been saying before. Thanks.=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, October 26, 2006 2:40 PM > To: IETF MMUSIC WG > Subject: [MMUSIC] ICE-12, SBCs and hotel ALGs >=20 > A big topic of discussion on the list and in our calls has=20 > been what ICE should do in the presence of SBCs and hotel-ALG=20 > and similar beasts which try and 'help' but get in the way. >=20 > I had proposed a solution on the list here: > http://www1.ietf.org/mail-archive/web/mmusic/current/msg04696.html >=20 > THe essential idea was that ICE would look for the m/c-line=20 > to not match any existing candidates, and if not, treat it as=20 > a high priority candidate. If it works, use it, if not, fall back. >=20 > This sounds great in theory, but when I got down to writing=20 > it up, some issues arose. >=20 > Firstly, the proposal was based on the theory that an SBC=20 > would pass STUN packets on the RTP ports. I spoke to several=20 > vendors of SBCs and it turns out this is often not the case.=20 > Indeed, in their role as "security boxes", many of them will=20 > rate limit the RTP, or prevent early media, or check for the=20 > right payload types, etc., all of which will cause the STUN=20 > checks to fail even though the RTP will work. Furthermore,=20 > some SBCs will in fact terminate a call if they see no media=20 > traffic, so bypassing them will not help. THus, my proposed=20 > approach would make calls fail when they would otherwise work=20 > if we didn't try and make ICE work in the presence of SBCs. >=20 > Secondly, the proposal flat out doesn't work for TCP, since=20 > the candidate line for TCP includes some crucial information=20 > (active/passive roles or SO), which is missing for the=20 > m/c-line. One of the things I accomplished with this set of=20 > revisions is a unification of the UDP and TCP mecahnisms. I=20 > think its a mistake to break that. >=20 > Finally, it was going to make it harder to specify this=20 > "passive-only"=20 > mode, also known as ICE-for-gateways. In the current -12 a=20 > gateway doesn't even maintain a candidate list for its peer;=20 > with this proposal it would need to do some of it. >=20 > So, ICE-12 does not contain the proposal in the mail above.=20 > Rather, it specifies that if an offer shows up, and the=20 > m/c-line doesn't match any candidate, you abort ICE=20 > processing (just like -11 and -10 said). It also adds that,=20 > when a re-invite comes to confirm the pairs selected by ICE,=20 > if the m/c-line doesn't match what is selected by ICE, use=20 > the pairs selected by ICE. >=20 > My main rationale on the first piece of this (if m/c-line=20 > doesnt match a candidate, abort) is that we dont know what=20 > SBCs will or won't do. Their behaviors are not specified, and=20 > they are highly variable. If the purpose of ICE is to make=20 > voip *reliable*, then the most reliable thing is to abort ICE=20 > processing and go with the relays. In a real sense, the b2bua=20 > is a UA on the path; we abort ICE when an ICE-capable UA=20 > calls an ICE-unaware UA - thats the only safe thing to do. Same here. >=20 > This does mean that if you have a non-ICE SBC in a network=20 > with ICE endpoints, you get an extra relay hop in the call=20 > path. Extra latency - but reliable. If however you make the=20 > SBC ice-aware, that problem goes away, and there are many=20 > ways to do that which we don't need to specify.=20 > I might argue that, within your own network, if you deploy=20 > ICE to endpoints and have non-ICE SBC, you should be happy it=20 > works at all let alone that it works with just an extra media hop. >=20 > Consequently, ICE will only proceed in -12 if the m/c-line=20 > MATCHES a candidate. There is only one case I found where you=20 > still have some kind of non-ICE media intermediary on the=20 > path, and ICE would proceed - an ALG which leaves the=20 > m/c-line alone with its on the public side of the NAT. In=20 > that case, ICE checks can proceed and will most often=20 > validate that address anyway. In the case where both=20 > endpoints are behind the same NAT/ALG, ICE would find that=20 > the direct path works, and re-invite to it. NOW, the helpful=20 > ALG might rewrite the SDP to the public value.=20 > With ICE-12, media would still flow direct. >=20 > There is also a case where the m/c-line don't match what ICE=20 > selected, even though there isn't an intermediary. That case=20 > is when severe packet loss causes each side to disagree on=20 > the selected candidates. In that case I think an agent should=20 > use what it thinks works, and that is why > ICE-12 specifies to ignore the m/c-line in this case. >=20 > Generally I don't like sending media to somewhere else than=20 > the m/c-lines. However, the important point is that in=20 > ICE-12, that ISNT going to happen except for these two cases,=20 > and the former case you reallly want to fix with TLS. That=20 > reduces the mismatch to one of a bad failure case, and if=20 > that is our only mismatch use case I am not so worried about it. >=20 >=20 > Backing up one step further, this idea of 'getting around=20 > SBCs and ALGs'=20 > was never a real requirement for ICE, and I am worried that=20 > it is something that is fraught with problems. I don't want=20 > to try and dump lots more complexity into ICE to try and=20 > guess our way around SBC and ALG implementations. TLS is the=20 > surefire way to deal with ALGs. Let us design ICE for how it=20 > ought to work without SBCs and ALGs, make sure it has a=20 > backwards compatibility mode when they are present, and then=20 > declare victory. Right now, I think the market needs a=20 > light-as-possible and FINISHED ICE spec more than anything else. >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 20:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFhT-0002uS-T2; Thu, 26 Oct 2006 20:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFhM-0002ha-BL for mmusic@ietf.org; Thu, 26 Oct 2006 20:35:48 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFgL-0001lX-8w for mmusic@ietf.org; Thu, 26 Oct 2006 20:34:46 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9R0YWI06613; Thu, 26 Oct 2006 20:34:33 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Thu, 26 Oct 2006 19:34:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCA8D@zrc2hxm0.corp.nortel.com> In-Reply-To: <4.3.2.7.2.20061026173826.03a90de8@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Thread-Index: Acb5UopqibPs6M93Sf2SrVd0XVVvxAAC6+yw From: "Francois Audet" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi James, I'm not sure I see the rationale for negotiating DSCP in SDP. In environments that span networks, different numerical values could be used (and the packets could be re-mapped accordingly at the border of these networks). It seems to me to be more a matter of config-framework. And within a single network, both ends would get the same values from the config-framework.=20 Within different networks, they'd get different values (which is the desired outcome). Also seems to me that this idea has the whole that it may result in the answered being inadvertently tricked into using the wrong DSCP (e.g,=20 a more expensive one, a lesser-quality one, etc.). I'd like to understand why you believe that handling DSCP through configuration (e.g, config-framework) would not be more appropriate. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Thursday, October 26, 2006 3:52 PM > To: mmusic@ietf.org > Subject: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer >=20 > MMUSIC WG >=20 > I've written a new individual ID on how an offer can carry a=20 > DSCP marking for a session, to be used upon initial offer or=20 > an offer within an established session that needs remarking=20 > of the DSCP used for the RTP stream. This link to the ID is here: >=20 > http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-att > ribute-00.txt >=20 > I would appreciate comments >=20 > Thanks > James >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 20:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFpY-0000VZ-6E; Thu, 26 Oct 2006 20:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFi3-00032F-VU for mmusic@ietf.org; Thu, 26 Oct 2006 20:36:31 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFTo-0008BL-MI for mmusic@ietf.org; Thu, 26 Oct 2006 20:21:51 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9R0LjI05367; Thu, 26 Oct 2006 20:21:45 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Thu, 26 Oct 2006 19:21:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCA82@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3466F9@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Thread-Index: Acb4/tEGuB48STR3T+iceuuQZOIrKwAXvq4w From: "Francois Audet" To: "Elwell, John" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Maybe we could use one a=3Dsrtp line for crypto, and another one for kmgmt? (i.e., have a different PT for each?)=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Thursday, October 26, 2006 5:56 AM > To: Hadriel Kaplan; Audet, Francois (SC100:3055); mmusic@ietf.org > Subject: [MMUSIC] RE: I-D=20 > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt >=20 > Hadriel, Francois, >=20 > Thanks for working on this update. Just one point. If both=20 > SDescriptions and MIKEY are offered (inclusion of a=3Dcrypto=20 > and a=3Dkey-mgmt lines) and a different payload type is also=20 > indicated for SRTP, this payload type would apply whether the=20 > SDescription-derived key or the MIKEY-derived key is used. > So until the SDP answer arrives, it would still not be=20 > possible to render SRTP. Of course, in the case of=20 > SDescriptions it is not possible anyway, but in the case of=20 > certain MIKEY options it ought to be possible. Unfortunately=20 > to resolve this we would need somewhat more complex syntax in=20 > the a=3Dsrtp line. >=20 > John >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 25 October 2006 20:50 > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Session Description Protocol (SDP)=20 > > Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport=20 > > Protocol > > Author(s) : F. Audet, H. Kaplan > > Filename : draft-kaplan-mmusic-best-effort-srtp-01.txt > > Pages : 17 > > Date : 2006-10-25 > > =09 > > This document defines the requirements and a proposed solution for=20 > > an SDP Offer/Answer exchange model for negotiating=20 > best-effort SRTP > > keys, i.e., in a backward-compatible manner with=20 > non-SRTP devices. > > The proposed solution is a trivial interpretation of the=20 > usage of=20 > > the profile and the usage of SDP indication of [sdesc]=20 > and [kmgmt]. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > > ffort-srtp-01.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-kaplan-mmusic-best-effort-srtp-01.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 26 20:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdG2Y-0004PN-KH; Thu, 26 Oct 2006 20:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdG2Y-0004PI-6T for mmusic@ietf.org; Thu, 26 Oct 2006 20:57:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdG2W-0006zw-SE for mmusic@ietf.org; Thu, 26 Oct 2006 20:57:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 17:57:40 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9R0veIJ031142; Thu, 26 Oct 2006 17:57:40 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9R0vdin023866; Thu, 26 Oct 2006 17:57:40 -0700 (PDT) From: "Dan Wing" To: "'James M. Polk'" , Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Thu, 26 Oct 2006 17:57:39 -0700 Message-ID: <3e0201c6f962$e69985d0$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4.3.2.7.2.20061026173826.03a90de8@email.cisco.com> Thread-Index: Acb5UoT2HB52cWgXR9eaRo6KWQzhpAAD581g DKIM-Signature: a=rsa-sha1; q=dns; l=2328; t=1161910660; x=1162774660; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20an=20Offer; X=v=3Dcisco.com=3B=20h=3DCAsevRE272Uuu4ItVMtbVXZBiFw=3D; b=De5QtTh64DzAVu3W2n7ZxoefJntpaBgoIPvp2TFb/Q+ZfigWZW1Y27XiilmxfObs1r/eAyOD KLo2LOJ9RyTKPdX2PETbL6s3kBFvb2ZoLjNIB3U/KTFNm/vo156WeNO9; Authentication-Results: sj-dkim-1.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org 3. Offer/Answer Behavior An offer/answer exchange using the 'dscp' attribute allows endpoints provide media packets the desired DSCP through a routed infrastructure. Including the 'dscp' in an offer or answer attribute is not a negotiation. "declarative" would be a good description of what you're doing with the a=dscp attribute. 3.2 Answerer Behavior An answerer MUST adhere to the 'dscp' attribute in the offer if the offer in whole is acceptable to the answerer. The 'dscp' attribute of each media stream MUST be used by the answerer to set the DSCP field of the respective media stream packets from the answerer. An answerer MUST NOT delete or change the 'dscp' attribute from offer to answer (analogous to copying from offer to answer), and SHOULD NOT ignore the 'dscp' attribute of the offer when setting the respective media stream packets towards the offer What if my network wants or needs me to use, say, DSCP 20, and yours wants or needs you to use DSCP 46? Are you assuming that an SBC (or other device that mucks with both SDP and IP packets) will interwork those at our respective network edges so that the SDP and the RTP packets have the appropriate a=dscp values and IP DSCP values, as seen by each of us? I agree with Francois -- I need to understand the justification for this functionality. This seems only germain to each local network and I don't see the value in signaling this in SDP. -d > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, October 26, 2006 3:52 PM > To: mmusic@ietf.org > Subject: [MMUSIC] New ID on conveying a DSCP > marking/remarking in an Offer > > MMUSIC WG > > I've written a new individual ID on how an offer can carry a > DSCP marking > for a session, to be used upon initial offer or an offer within an > established session that needs remarking of the DSCP used for the RTP > stream. This link to the ID is here: > > http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-att > ribute-00.txt > > I would appreciate comments > > Thanks > James > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 02:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLFf-0000Em-BE; Fri, 27 Oct 2006 02:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL7M-0002TQ-2a for mmusic@ietf.org; Fri, 27 Oct 2006 02:23:00 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKsQ-0001Bk-6X for mmusic@ietf.org; Fri, 27 Oct 2006 02:07:37 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7S00AHG6CT2O@siemenscomms.co.uk> for mmusic@ietf.org; Fri, 27 Oct 2006 07:07:41 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZAVB>; Fri, 27 Oct 2006 07:07:28 +0100 Content-return: allowed Date: Fri, 27 Oct 2006 07:07:27 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 01.txt To: Francois Audet , Hadriel Kaplan , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A346A54@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Francois, Yes, that would work. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 27 October 2006 01:22 > To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: I-D > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > Maybe we could use one a=srtp line for crypto, and another one for > kmgmt? > > (i.e., have a different PT for each?) > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Thursday, October 26, 2006 5:56 AM > > To: Hadriel Kaplan; Audet, Francois (SC100:3055); mmusic@ietf.org > > Subject: [MMUSIC] RE: I-D > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > Hadriel, Francois, > > > > Thanks for working on this update. Just one point. If both > > SDescriptions and MIKEY are offered (inclusion of a=crypto > > and a=key-mgmt lines) and a different payload type is also > > indicated for SRTP, this payload type would apply whether the > > SDescription-derived key or the MIKEY-derived key is used. > > So until the SDP answer arrives, it would still not be > > possible to render SRTP. Of course, in the case of > > SDescriptions it is not possible anyway, but in the case of > > certain MIKEY options it ought to be possible. Unfortunately > > to resolve this we would need somewhat more complex syntax in > > the a=srtp line. > > > > John > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: 25 October 2006 20:50 > > > To: i-d-announce@ietf.org > > > Subject: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > > > > > > > Title : Session Description Protocol (SDP) > > > Offer/Answer Negotiation For Best-Effort Secure Real-Time > Transport > > > Protocol > > > Author(s) : F. Audet, H. Kaplan > > > Filename : draft-kaplan-mmusic-best-effort-srtp-01.txt > > > Pages : 17 > > > Date : 2006-10-25 > > > > > > This document defines the requirements and a proposed > solution for > > > an SDP Offer/Answer exchange model for negotiating > > best-effort SRTP > > > keys, i.e., in a backward-compatible manner with > > non-SRTP devices. > > > The proposed solution is a trivial interpretation of the > > usage of > > > the profile and the usage of SDP indication of [sdesc] > > and [kmgmt]. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > > > ffort-srtp-01.txt > > > > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > > the message. > > > You can also visit > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. > Login with the > > > username "anonymous" and a password of your e-mail address. After > > > logging in, type "cd internet-drafts" and then "get > > > draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 12:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUlG-00009C-P5; Fri, 27 Oct 2006 12:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUlF-00006i-Rs for mmusic@ietf.org; Fri, 27 Oct 2006 12:40:49 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUlE-0001q7-Bj for mmusic@ietf.org; Fri, 27 Oct 2006 12:40:49 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9RGek0S021491; Fri, 27 Oct 2006 10:40:46 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-12, SBCs and hotel ALGs Date: Fri, 27 Oct 2006 10:40:45 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-12, SBCs and hotel ALGs Thread-Index: Acb5R/qc/0nbImpgTdyp/t1LO+o0awAGJr4AACFs/zA= From: "Kevin Johns" To: "Francois Audet" , "Jonathan Rosenberg" , "IETF MMUSIC WG" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree as well. This is not something I would like to see solved by ICE. Thanks Kevin -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, October 26, 2006 6:42 PM To: Jonathan Rosenberg; IETF MMUSIC WG Subject: RE: [MMUSIC] ICE-12, SBCs and hotel ALGs I agree with your conclusion. Your last paragraph is exaclty what I've been saying before. Thanks.=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Thursday, October 26, 2006 2:40 PM > To: IETF MMUSIC WG > Subject: [MMUSIC] ICE-12, SBCs and hotel ALGs >=20 > A big topic of discussion on the list and in our calls has been what=20 > ICE should do in the presence of SBCs and hotel-ALG and similar beasts > which try and 'help' but get in the way. >=20 > I had proposed a solution on the list here: > http://www1.ietf.org/mail-archive/web/mmusic/current/msg04696.html >=20 > THe essential idea was that ICE would look for the m/c-line to not=20 > match any existing candidates, and if not, treat it as a high priority > candidate. If it works, use it, if not, fall back. >=20 > This sounds great in theory, but when I got down to writing it up,=20 > some issues arose. >=20 > Firstly, the proposal was based on the theory that an SBC would pass=20 > STUN packets on the RTP ports. I spoke to several vendors of SBCs and=20 > it turns out this is often not the case. > Indeed, in their role as "security boxes", many of them will rate=20 > limit the RTP, or prevent early media, or check for the right payload=20 > types, etc., all of which will cause the STUN checks to fail even=20 > though the RTP will work. Furthermore, some SBCs will in fact=20 > terminate a call if they see no media traffic, so bypassing them will=20 > not help. THus, my proposed approach would make calls fail when they=20 > would otherwise work if we didn't try and make ICE work in the=20 > presence of SBCs. >=20 > Secondly, the proposal flat out doesn't work for TCP, since the=20 > candidate line for TCP includes some crucial information=20 > (active/passive roles or SO), which is missing for the m/c-line. One=20 > of the things I accomplished with this set of revisions is a=20 > unification of the UDP and TCP mecahnisms. I think its a mistake to=20 > break that. >=20 > Finally, it was going to make it harder to specify this "passive-only" > mode, also known as ICE-for-gateways. In the current -12 a gateway=20 > doesn't even maintain a candidate list for its peer; with this=20 > proposal it would need to do some of it. >=20 > So, ICE-12 does not contain the proposal in the mail above.=20 > Rather, it specifies that if an offer shows up, and the m/c-line=20 > doesn't match any candidate, you abort ICE processing (just like -11=20 > and -10 said). It also adds that, when a re-invite comes to confirm=20 > the pairs selected by ICE, if the m/c-line doesn't match what is=20 > selected by ICE, use the pairs selected by ICE. >=20 > My main rationale on the first piece of this (if m/c-line doesnt match > a candidate, abort) is that we dont know what SBCs will or won't do.=20 > Their behaviors are not specified, and they are highly variable. If=20 > the purpose of ICE is to make voip *reliable*, then the most reliable=20 > thing is to abort ICE processing and go with the relays. In a real=20 > sense, the b2bua is a UA on the path; we abort ICE when an ICE-capable > UA calls an ICE-unaware UA - thats the only safe thing to do. Same=20 > here. >=20 > This does mean that if you have a non-ICE SBC in a network with ICE=20 > endpoints, you get an extra relay hop in the call path. Extra latency=20 > - but reliable. If however you make the SBC ice-aware, that problem=20 > goes away, and there are many ways to do that which we don't need to=20 > specify. > I might argue that, within your own network, if you deploy ICE to=20 > endpoints and have non-ICE SBC, you should be happy it works at all=20 > let alone that it works with just an extra media hop. >=20 > Consequently, ICE will only proceed in -12 if the m/c-line MATCHES a=20 > candidate. There is only one case I found where you still have some=20 > kind of non-ICE media intermediary on the path, and ICE would proceed=20 > - an ALG which leaves the m/c-line alone with its on the public side=20 > of the NAT. In that case, ICE checks can proceed and will most often=20 > validate that address anyway. In the case where both endpoints are=20 > behind the same NAT/ALG, ICE would find that the direct path works,=20 > and re-invite to it. NOW, the helpful ALG might rewrite the SDP to the > public value. > With ICE-12, media would still flow direct. >=20 > There is also a case where the m/c-line don't match what ICE selected, > even though there isn't an intermediary. That case is when severe=20 > packet loss causes each side to disagree on the selected candidates.=20 > In that case I think an agent should use what it thinks works, and=20 > that is why > ICE-12 specifies to ignore the m/c-line in this case. >=20 > Generally I don't like sending media to somewhere else than the=20 > m/c-lines. However, the important point is that in ICE-12, that ISNT=20 > going to happen except for these two cases, and the former case you=20 > reallly want to fix with TLS. That reduces the mismatch to one of a=20 > bad failure case, and if that is our only mismatch use case I am not=20 > so worried about it. >=20 >=20 > Backing up one step further, this idea of 'getting around SBCs and=20 > ALGs' > was never a real requirement for ICE, and I am worried that it is=20 > something that is fraught with problems. I don't want to try and dump=20 > lots more complexity into ICE to try and guess our way around SBC and=20 > ALG implementations. TLS is the surefire way to deal with ALGs. Let us > design ICE for how it ought to work without SBCs and ALGs, make sure=20 > it has a backwards compatibility mode when they are present, and then=20 > declare victory. Right now, I think the market needs a=20 > light-as-possible and FINISHED ICE spec more than anything else. >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 13:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVmk-0002b8-Al; Fri, 27 Oct 2006 13:46:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVmi-0002aU-VR for mmusic@ietf.org; Fri, 27 Oct 2006 13:46:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdVmf-0003iX-Jz for mmusic@ietf.org; Fri, 27 Oct 2006 13:46:24 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2006 10:46:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RHkLhw023028; Fri, 27 Oct 2006 10:46:21 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9RHkJin013474; Fri, 27 Oct 2006 10:46:20 -0700 (PDT) From: "Dan Wing" To: "'Elwell, John'" , "'Francois Audet'" , "'Hadriel Kaplan'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Fri, 27 Oct 2006 10:46:19 -0700 Message-ID: <426401c6f9ef$cfe8d380$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A346A54@ntht201e.siemenscomms.co.uk> Thread-Index: Acb5ke7hi9adp0odSaSOufCIIyQGPwAXXj6w DKIM-Signature: a=rsa-sha1; q=dns; l=5998; t=1161971181; x=1162835181; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20RE=3A=20I-D=20ACTION=3Adraft-kaplan-mmusic-best-effor t-srtp-01.txt; X=v=3Dcisco.com=3B=20h=3DxBX4iA4VQuhdkcexVU8I2tdVYaA=3D; b=KYKOoGIiClo1MOFzPZKe8A3v2qWCO5nhF+Fhkw7N7ZHh9H7LpR6jxHP1FjUX3D6JkxCLsq+6 6AMCMyu53v9mZKJD7mP1Zm77wM3Wk8kjYQv8hEUsI30pA82IZoOU2jFH; Authentication-Results: sj-dkim-4.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org And another for srtp-dtls and another for zrtp? Maybe there is a more efficient way to combine these. Perhaps only including a=srtp for those key exchange mechanisms which can allow decrypting SRTP media that arrives prior to the SDP answer? Or perhaps specifying the payload types in such a way that they're assigned to each of the a= key management mechanisms understood by the answerer. As a possible strawman for this last idea: m=blahblah a=key-mgmt blahblah a=crypto blahblah a=fingerprint blahblah (used by srtp-dtls) a=zrtp a=srtp key-mgmt 40 crypto 41 fingerprint 42 zrtp 43 -d > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, October 26, 2006 11:07 PM > To: Francois Audet; Hadriel Kaplan; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: I-D > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > Francois, > > Yes, that would work. > > John > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 27 October 2006 01:22 > > To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org > > Subject: RE: [MMUSIC] RE: I-D > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > Maybe we could use one a=srtp line for crypto, and another one for > > kmgmt? > > > > (i.e., have a different PT for each?) > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Thursday, October 26, 2006 5:56 AM > > > To: Hadriel Kaplan; Audet, Francois (SC100:3055); mmusic@ietf.org > > > Subject: [MMUSIC] RE: I-D > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > Hadriel, Francois, > > > > > > Thanks for working on this update. Just one point. If both > > > SDescriptions and MIKEY are offered (inclusion of a=crypto > > > and a=key-mgmt lines) and a different payload type is also > > > indicated for SRTP, this payload type would apply whether the > > > SDescription-derived key or the MIKEY-derived key is used. > > > So until the SDP answer arrives, it would still not be > > > possible to render SRTP. Of course, in the case of > > > SDescriptions it is not possible anyway, but in the case of > > > certain MIKEY options it ought to be possible. Unfortunately > > > to resolve this we would need somewhat more complex syntax in > > > the a=srtp line. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: 25 October 2006 20:50 > > > > To: i-d-announce@ietf.org > > > > Subject: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : Session Description Protocol (SDP) > > > > Offer/Answer Negotiation For Best-Effort Secure Real-Time > > Transport > > > > Protocol > > > > Author(s) : F. Audet, H. Kaplan > > > > Filename : > draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > Pages : 17 > > > > Date : 2006-10-25 > > > > > > > > This document defines the requirements and a proposed > > solution for > > > > an SDP Offer/Answer exchange model for negotiating > > > best-effort SRTP > > > > keys, i.e., in a backward-compatible manner with > > > non-SRTP devices. > > > > The proposed solution is a trivial interpretation of the > > > usage of > > > > the profile and the usage of SDP indication of [sdesc] > > > and [kmgmt]. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > > > > ffort-srtp-01.txt > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > message to > > > > i-d-announce-request@ietf.org with the word unsubscribe in > > > the body of > > > > the message. > > > > You can also visit > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > to change your subscription settings. > > > > > > > > Internet-Drafts are also available by anonymous FTP. > > Login with the > > > > username "anonymous" and a password of your e-mail > address. After > > > > logging in, type "cd internet-drafts" and then "get > > > > draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > Send a message to: > > > > mailserv@ietf.org. > > > > In the body type: > > > > "FILE > > > > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility. > To use this > > > > feature, insert the command "ENCODING mime" > before the "FILE" > > > > command. To decode the response(s), you will > need "munpack" or > > > > a MIME-compliant mail reader. Different MIME-compliant > > > mail readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which > have been split > > > > up into multiple messages), so check your local > documentation on > > > > how to manipulate these messages. > > > > > > > > Below is the data which will enable a MIME compliant > mail reader > > > > implementation to automatically retrieve the ASCII > version of the > > > > Internet-Draft. > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 14:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWlr-0000LZ-Kr; Fri, 27 Oct 2006 14:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWlp-0000LE-TE for mmusic@ietf.org; Fri, 27 Oct 2006 14:49:33 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWli-0007x1-CV for mmusic@ietf.org; Fri, 27 Oct 2006 14:49:33 -0400 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k9RImBsp010475 for ; Fri, 27 Oct 2006 14:49:04 -0400 Received: from [135.9.42.81] ([135.9.42.81]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Oct 2006 12:48:32 -0600 Message-ID: <4542547D.9000703@avaya.com> Date: Fri, 27 Oct 2006 12:48:29 -0600 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt References: <426401c6f9ef$cfe8d380$5b82200a@amer.cisco.com> In-Reply-To: <426401c6f9ef$cfe8d380$5b82200a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 18:48:32.0178 (UTC) FILETIME=[8006E920:01C6F9F8] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: 'Francois Audet' , "'Elwell, John'" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Would the payload type entries be comma-separated lists for multiple-payload channels? We would also want to distinguish between different cryptosuites (even if they used the same master key/salt), perhaps via multiple ordered "crypto" entries? -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Dan Wing wrote: > And another for srtp-dtls and another for zrtp? > > Maybe there is a more efficient way to combine these. Perhaps only > including a=srtp for those key exchange mechanisms which can allow > decrypting SRTP media that arrives prior to the SDP answer? Or perhaps > specifying the payload types in such a way that they're assigned to each of > the a= key management mechanisms understood by the answerer. As a possible > strawman for this last idea: > > m=blahblah > a=key-mgmt blahblah > a=crypto blahblah > a=fingerprint blahblah (used by srtp-dtls) > a=zrtp > a=srtp key-mgmt 40 crypto 41 fingerprint 42 zrtp 43 > > -d > > > >>-----Original Message----- >>From: Elwell, John [mailto:john.elwell@siemens.com] >>Sent: Thursday, October 26, 2006 11:07 PM >>To: Francois Audet; Hadriel Kaplan; mmusic@ietf.org >>Subject: RE: [MMUSIC] RE: I-D >>ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt >> >>Francois, >> >>Yes, that would work. >> >>John >> >> >>>-----Original Message----- >>>From: Francois Audet [mailto:audet@nortel.com] >>>Sent: 27 October 2006 01:22 >>>To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org >>>Subject: RE: [MMUSIC] RE: I-D >>>ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt >>> >>>Maybe we could use one a=srtp line for crypto, and another one for >>>kmgmt? >>> >>>(i.e., have a different PT for each?) >>> >>> >>>>-----Original Message----- >>>>From: Elwell, John [mailto:john.elwell@siemens.com] >>>>Sent: Thursday, October 26, 2006 5:56 AM >>>>To: Hadriel Kaplan; Audet, Francois (SC100:3055); mmusic@ietf.org >>>>Subject: [MMUSIC] RE: I-D >>>>ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt >>>> >>>>Hadriel, Francois, >>>> >>>>Thanks for working on this update. Just one point. If both >>>>SDescriptions and MIKEY are offered (inclusion of a=crypto >>>>and a=key-mgmt lines) and a different payload type is also >>>>indicated for SRTP, this payload type would apply whether the >>>>SDescription-derived key or the MIKEY-derived key is used. >>>>So until the SDP answer arrives, it would still not be >>>>possible to render SRTP. Of course, in the case of >>>>SDescriptions it is not possible anyway, but in the case of >>>>certain MIKEY options it ought to be possible. Unfortunately >>>>to resolve this we would need somewhat more complex syntax in >>>>the a=srtp line. >>>> >>>>John >>>> >>>> >>>>>-----Original Message----- >>>>>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>>>Sent: 25 October 2006 20:50 >>>>>To: i-d-announce@ietf.org >>>>>Subject: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt >>>>> >>>>>A New Internet-Draft is available from the on-line >>> >>>Internet-Drafts >>> >>>>>directories. >>>>> >>>>> >>>>> Title : Session Description Protocol (SDP) >>>>>Offer/Answer Negotiation For Best-Effort Secure Real-Time >>> >>>Transport >>> >>>>>Protocol >>>>> Author(s) : F. Audet, H. Kaplan >>>>> Filename : >> >>draft-kaplan-mmusic-best-effort-srtp-01.txt >> >>>>> Pages : 17 >>>>> Date : 2006-10-25 >>>>> >>>>>This document defines the requirements and a proposed >>> >>>solution for >>> >>>>> an SDP Offer/Answer exchange model for negotiating >>>> >>>>best-effort SRTP >>>> >>>>> keys, i.e., in a backward-compatible manner with >>>> >>>>non-SRTP devices. >>>> >>>>> The proposed solution is a trivial interpretation of the >>>> >>>>usage of >>>> >>>>> the profile and the usage of SDP indication of [sdesc] >>>> >>>>and [kmgmt]. >>>> >>>>>A URL for this Internet-Draft is: >>>>>http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e >>>>>ffort-srtp-01.txt >>>>> >>>>>To remove yourself from the I-D Announcement list, send a >>>> >>>>message to >>>> >>>>>i-d-announce-request@ietf.org with the word unsubscribe in >>>> >>>>the body of >>>> >>>>>the message. >>>>>You can also visit >>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>to change your subscription settings. >>>>> >>>>>Internet-Drafts are also available by anonymous FTP. >>> >>>Login with the >>> >>>>>username "anonymous" and a password of your e-mail >> >>address. After >> >>>>>logging in, type "cd internet-drafts" and then "get >>>>>draft-kaplan-mmusic-best-effort-srtp-01.txt". >>>>> >>>>>A list of Internet-Drafts directories can be found in >>>>>http://www.ietf.org/shadow.html or >>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>>Internet-Drafts can also be obtained by e-mail. >>>>> >>>>>Send a message to: >>>>> mailserv@ietf.org. >>>>>In the body type: >>>>> "FILE >>>>>/internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". >>>>> >>>>>NOTE: The mail server at ietf.org can return the document in >>>>> MIME-encoded form by using the "mpack" utility. >> >> To use this >> >>>>> feature, insert the command "ENCODING mime" >> >>before the "FILE" >> >>>>> command. To decode the response(s), you will >> >>need "munpack" or >> >>>>> a MIME-compliant mail reader. Different MIME-compliant >>>> >>>>mail readers >>>> >>>>> exhibit different behavior, especially when dealing with >>>>> "multipart" MIME messages (i.e. documents which >> >>have been split >> >>>>> up into multiple messages), so check your local >> >>documentation on >> >>>>> how to manipulate these messages. >>>>> >>>>>Below is the data which will enable a MIME compliant >> >>mail reader >> >>>>>implementation to automatically retrieve the ASCII >> >>version of the >> >>>>>Internet-Draft. >>>>> >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 15:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLJ-0006eR-Pb; Fri, 27 Oct 2006 15:26:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLI-0006be-1P for mmusic@ietf.org; Fri, 27 Oct 2006 15:26:12 -0400 Received: from smtp112.iad.emailsrvr.com ([207.97.245.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdX9u-0007JJ-Lc for mmusic@ietf.org; Fri, 27 Oct 2006 15:14:30 -0400 Received: from counterpath.com (webmail8.r4.iad.mlsrvr.com [192.168.1.83]) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 51AED44C11D; Fri, 27 Oct 2006 15:14:26 -0400 (EDT) Received: from ([10.238.10.71]) (proxying for 24.85.147.44) (Webmail authenticated user derek@counterpath.com, derek@counterpath.com); by webmail.counterpath.com with HTTP; Fri, 27 Oct 2006 15:14:26 -0400 (EDT) Message-ID: <44590.10.238.10.71.1161976466.webmail@10.238.10.71> Date: Fri, 27 Oct 2006 15:14:26 -0400 (EDT) Subject: RE: [MMUSIC] ICE-12, SBCs and hotel ALGs From: derek@counterpath.com To: "Jonathan Rosenberg" , mmusic@ietf.org X-Mailer: Webmail.us v5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: OK Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: derek@counterpath.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The consensus that we reached on the ICE calls was that a user agent coul= d ignore the m/c line if it couldn't validated by ICE. This is needed to = deal with misbehaving ALG devices, which are an existing deployment issue= . These devices are often not controlled by the network operator, and can= be seen as morally equivalent to a misbehaving NAT from the ice requirem= ents standpoint. A large part of this debate was around whether SBC type devices needed to= be ICE aware, or if ICE should be designed so that it deosn't "work arou= nd" existing SBCs. I don't know if we settled that debate; consensus seem= d to be that it is easy for an SBC vendor to disable ice. Changing ice so= that the m/c line MUST match a candidate assumes that the requirement is= that ice not bypass existing SBC devices. This includes the motivation = that existing SBC devices do not allow ice checks to proceed. We need to = resolve this SBC/ICE requirments debate if we are ever going to reach con= sensus on ICE. It seems to me that a way forward is to have two operating modes for ice;= one which is designed to honour existing middle boxes in a deployment, a= nd one which just tries to establish connectivity. I propose we have another ice breakout session this IETF to try to reach = consensus on this long running issue. Given past performance, we should s= chedule several hours. -Derek Jonathan Rosenberg said: > A big topic of discussion on the list and in our calls has been what IC= E > should do in the presence of SBCs and hotel-ALG and similar beasts whic= h > try and 'help' but get in the way. >=20 > I had proposed a solution on the list here: > http://www1.ietf.org/mail-archive/web/mmusic/current/msg04696.html >=20 > THe essential idea was that ICE would look for the m/c-line to not matc= h > any existing candidates, and if not, treat it as a high priority > candidate. If it works, use it, if not, fall back. >=20 > This sounds great in theory, but when I got down to writing it up, some > issues arose. >=20 > Firstly, the proposal was based on the theory that an SBC would pass > STUN packets on the RTP ports. I spoke to several vendors of SBCs and i= t > turns out this is often not the case. Indeed, in their role as "securit= y > boxes", many of them will rate limit the RTP, or prevent early media, o= r > check for the right payload types, etc., all of which will cause the > STUN checks to fail even though the RTP will work. Furthermore, some > SBCs will in fact terminate a call if they see no media traffic, so > bypassing them will not help. THus, my proposed approach would make > calls fail when they would otherwise work if we didn't try and make ICE > work in the presence of SBCs. >=20 > Secondly, the proposal flat out doesn't work for TCP, since the > candidate line for TCP includes some crucial information (active/passiv= e > roles or SO), which is missing for the m/c-line. One of the things I > accomplished with this set of revisions is a unification of the UDP and > TCP mecahnisms. I think its a mistake to break that. >=20 > Finally, it was going to make it harder to specify this "passive-only" > mode, also known as ICE-for-gateways. In the current -12 a gateway > doesn't even maintain a candidate list for its peer; with this proposal > it would need to do some of it. >=20 > So, ICE-12 does not contain the proposal in the mail above. Rather, it > specifies that if an offer shows up, and the m/c-line doesn't match any > candidate, you abort ICE processing (just like -11 and -10 said). It > also adds that, when a re-invite comes to confirm the pairs selected by > ICE, if the m/c-line doesn't match what is selected by ICE, use the > pairs selected by ICE. >=20 > My main rationale on the first piece of this (if m/c-line doesnt match = a > candidate, abort) is that we dont know what SBCs will or won't do. Thei= r > behaviors are not specified, and they are highly variable. If the > purpose of ICE is to make voip *reliable*, then the most reliable thing > is to abort ICE processing and go with the relays. In a real sense, the > b2bua is a UA on the path; we abort ICE when an ICE-capable UA calls an > ICE-unaware UA - thats the only safe thing to do. Same here. >=20 > This does mean that if you have a non-ICE SBC in a network with ICE > endpoints, you get an extra relay hop in the call path. Extra latency - > but reliable. If however you make the SBC ice-aware, that problem goes > away, and there are many ways to do that which we don't need to specify= . > I might argue that, within your own network, if you deploy ICE to > endpoints and have non-ICE SBC, you should be happy it works at all let > alone that it works with just an extra media hop. >=20 > Consequently, ICE will only proceed in -12 if the m/c-line MATCHES a > candidate. There is only one case I found where you still have some kin= d > of non-ICE media intermediary on the path, and ICE would proceed - an > ALG which leaves the m/c-line alone with its on the public side of the > NAT. In that case, ICE checks can proceed and will most often validate > that address anyway. In the case where both endpoints are behind the > same NAT/ALG, ICE would find that the direct path works, and re-invite > to it. NOW, the helpful ALG might rewrite the SDP to the public value. > With ICE-12, media would still flow direct. >=20 > There is also a case where the m/c-line don't match what ICE selected, > even though there isn't an intermediary. That case is when severe packe= t > loss causes each side to disagree on the selected candidates. In that > case I think an agent should use what it thinks works, and that is why > ICE-12 specifies to ignore the m/c-line in this case. >=20 > Generally I don't like sending media to somewhere else than the > m/c-lines. However, the important point is that in ICE-12, that ISNT > going to happen except for these two cases, and the former case you > reallly want to fix with TLS. That reduces the mismatch to one of a bad > failure case, and if that is our only mismatch use case I am not so > worried about it. >=20 >=20 > Backing up one step further, this idea of 'getting around SBCs and ALGs= ' > was never a real requirement for ICE, and I am worried that it is > something that is fraught with problems. I don't want to try and dump > lots more complexity into ICE to try and guess our way around SBC and > ALG implementations. TLS is the surefire way to deal with ALGs. Let us > design ICE for how it ought to work without SBCs and ALGs, make sure it > has a backwards compatibility mode when they are present, and then > declare victory. Right now, I think the market needs a light-as-possibl= e > and FINISHED ICE spec more than anything else. >=20 > Thanks, > Jonathan R. >=20 >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-271= 1 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 19:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaiU-000379-3i; Fri, 27 Oct 2006 19:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaiR-000373-T7 for mmusic@ietf.org; Fri, 27 Oct 2006 19:02:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdaiQ-0000Bl-JG for mmusic@ietf.org; Fri, 27 Oct 2006 19:02:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2006 16:02:18 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RN2HYg004394; Fri, 27 Oct 2006 16:02:17 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9RN2GW4008043; Fri, 27 Oct 2006 16:02:16 -0700 (PDT) From: "Dan Wing" To: , "'Joerg Ott'" , Date: Fri, 27 Oct 2006 16:02:17 -0700 Message-ID: <47cf01c6fa1b$f3d4fa40$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb4dYHZVSYt5fyqTiWvNTZdgAeZKgBpKMyg DKIM-Signature: a=rsa-sha1; q=dns; l=1660; t=1161990137; x=1162854137; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:alternate=20RTP=20profiles=20in=20SDP=20offer/answer; X=v=3Dcisco.com=3B=20h=3DDVdDnPXE+OHndl5Gz1RY5d9ua80=3D; b=1LHadKa74DuN39xMjlXTH3p3IjvQPVy4FX/uflFhiYsOKiBtAv4sxJa8f//ITKrVaiQTgw6u pAQbbtfXZaZ2+4eJJeOKGcFnAOMTwnzr+9xzy6sPLZMU0Y8ds1W6stna; Authentication-Results: sj-dkim-2.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Flemming Andreasen' , 'Francois Audet' , ietf-rtpsec@imc.org Subject: [MMUSIC] alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org draft-ietf-avt-profile-savpf-09 mentions, in several places, how ports can be overloaded and grouping can be used to specify RTP/SAVP and RTP/SAVPF in the same offer. The suggestions in draft-ietf-avt-profile-savpf-09 appear to have the drawbacks that Flemming describes in section 3.1 and 3.5 of draft-andreasen-mmusic-sdp-capability-negotiation-01. It seems ill-advised for AVT to publish a document encouraging use of mechanisms with these drawbacks, unless MMUSIC agrees with this decision. Considering that the upcoming IETF has two individual contributions in MMUSIC on this topic, draft-andreasen-mmusic-sdp-capability-negotiation-01 and draft-kaplan-mmusic-best-effort-srtp-01, I don't believe there is consensus within MMUSIC of which approach to take. Can Joerggand Elisabetta discuss the technique proposed in draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC meeting? Or can we perhaps have a joint presentation by all five authors so that MMUSIC can make an informed decision on this important topic? -d > Title : Extended Secure RTP Profile for > RTCP-based Feedback (RTP/SAVPF) > Author(s) : J. Ott, E. Carrara > Filename : draft-ietf-avt-profile-savpf-09.txt > Pages : 17 > Date : 2006-10-25 > > An RTP profile (SAVP) is defined for secure real-time > communications, and another profile (AVPF) is specified to provide > timely feedback from the receivers to a sender. This memo defines > the combination of both profiles to enable secure RTP > communications with feedback. > > http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-09.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 27 20:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdbpm-00081a-Mh; Fri, 27 Oct 2006 20:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdbpl-00081V-TK for mmusic@ietf.org; Fri, 27 Oct 2006 20:13:57 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdbpk-0006JC-JR for mmusic@ietf.org; Fri, 27 Oct 2006 20:13:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9S0Dg607411; Fri, 27 Oct 2006 20:13:42 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Oct 2006 19:13:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2968F@zrc2hxm0.corp.nortel.com> In-Reply-To: <47cf01c6fa1b$f3d4fa40$5b82200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: alternate RTP profiles in SDP offer/answer Thread-Index: Acb4dYHZVSYt5fyqTiWvNTZdgAeZKgBpKMygAALQaGA= From: "Francois Audet" To: "Dan Wing" , , "Joerg Ott" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Flemming Andreasen , ietf-rtpsec@imc.org Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I fully support Dan's suggestion. It seems to me that a significant fraction of draft-ietf-avt-profile-savpf-09 is really MMUSIC material, and does overlap with the two drafts that=20 Dan listed. I also support the suggestion that all the parties try to collaborate on a joint presentation of the issues. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Friday, October 27, 2006 4:02 PM > To: mmusic@ietf.org; 'Joerg Ott'; carrara@kth.se > Cc: 'Flemming Andreasen'; 'Hadriel Kaplan'; Audet, Francois=20 > (SC100:3055); ietf-rtpsec@imc.org > Subject: alternate RTP profiles in SDP offer/answer >=20 > draft-ietf-avt-profile-savpf-09 mentions, in several places,=20 > how ports can be overloaded and grouping can be used to=20 > specify RTP/SAVP and RTP/SAVPF in the same offer. The=20 > suggestions in draft-ietf-avt-profile-savpf-09 appear to have=20 > the drawbacks that Flemming describes in section 3.1 and 3.5=20 > of draft-andreasen-mmusic-sdp-capability-negotiation-01. It=20 > seems ill-advised for AVT to publish a document encouraging=20 > use of mechanisms with these drawbacks, unless MMUSIC agrees=20 > with this decision. >=20 > Considering that the upcoming IETF has two individual=20 > contributions in MMUSIC on this topic,=20 > draft-andreasen-mmusic-sdp-capability-negotiation-01 > and draft-kaplan-mmusic-best-effort-srtp-01, I don't believe=20 > there is consensus within MMUSIC of which approach to take. >=20 > Can Joerggand Elisabetta discuss the technique proposed in > draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC=20 > meeting? Or can we perhaps have a joint presentation by all=20 > five authors so that MMUSIC can make an informed decision on=20 > this important topic? >=20 > -d >=20 >=20 > > Title : Extended Secure RTP Profile for=20 > > RTCP-based Feedback (RTP/SAVPF) > > Author(s) : J. Ott, E. Carrara > > Filename : draft-ietf-avt-profile-savpf-09.txt > > Pages : 17 > > Date : 2006-10-25 > > =09 > > An RTP profile (SAVP) is defined for secure real-time > > communications, and another profile (AVPF) is specified=20 > to provide > > timely feedback from the receivers to a sender. This=20 > memo defines > > the combination of both profiles to enable secure RTP > > communications with feedback. > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-09.tx > > t >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Oct 28 04:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdjPm-0002AN-PJ; Sat, 28 Oct 2006 04:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdjPl-0002A7-Do for mmusic@ietf.org; Sat, 28 Oct 2006 04:19:37 -0400 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdjPk-0007Vo-2O for mmusic@ietf.org; Sat, 28 Oct 2006 04:19:37 -0400 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 111014FED8; Sat, 28 Oct 2006 11:19:32 +0300 (EET DST) Message-ID: <45431294.8060507@netlab.hut.fi> Date: Sat, 28 Oct 2006 11:19:32 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing References: <47cf01c6fa1b$f3d4fa40$5b82200a@amer.cisco.com> In-Reply-To: <47cf01c6fa1b$f3d4fa40$5b82200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, 'Francois Audet' , 'Flemming Andreasen' , 'Joerg Ott' Subject: [MMUSIC] Re: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan, what you claim to be a problem here has been removed from the SAVPF spec for this very reason. -08 had -- by accident -- some remnants in that were taken out in -09. Should there be an oversight left in, then please be precise of what you mean and we will be happy to fix this. To quote from present -09: If alternative RTP profiles are to be specified for a single RTP session, each alternative needs to be included on a separate media line in SDP. However, with only basic SDP, it is not possible to communicate that the two m= lines are meant as alternatives (as opposed to specifying different media sessions of the same type). A mechanism to indicate semantic equivalence between the individual sessions and ensure that any receiver only joins one of them, such as the grouping framework [9], is being defined in the MMUSIC WG. From the mere authorship of the spec, it should become clear that there is a close interaction with what MMUSIC does. I must admit that I am somehwat surprised and not particularly amused about your seocnd-guessing below. Joerg > draft-ietf-avt-profile-savpf-09 mentions, in several places, how ports can > be overloaded and grouping can be used to specify RTP/SAVP and RTP/SAVPF in > the same offer. The suggestions in draft-ietf-avt-profile-savpf-09 appear > to have the drawbacks that Flemming describes in section 3.1 and 3.5 of > draft-andreasen-mmusic-sdp-capability-negotiation-01. It seems ill-advised > for AVT to publish a document encouraging use of mechanisms with these > drawbacks, unless MMUSIC agrees with this decision. > > Considering that the upcoming IETF has two individual contributions in > MMUSIC on this topic, draft-andreasen-mmusic-sdp-capability-negotiation-01 > and draft-kaplan-mmusic-best-effort-srtp-01, I don't believe there is > consensus within MMUSIC of which approach to take. > > Can Joerggand Elisabetta discuss the technique proposed in > draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC meeting? Or can we > perhaps have a joint presentation by all five authors so that MMUSIC can > make an informed decision on this important topic? > > -d > > > >> Title : Extended Secure RTP Profile for >> RTCP-based Feedback (RTP/SAVPF) >> Author(s) : J. Ott, E. Carrara >> Filename : draft-ietf-avt-profile-savpf-09.txt >> Pages : 17 >> Date : 2006-10-25 >> >> An RTP profile (SAVP) is defined for secure real-time >> communications, and another profile (AVPF) is specified to provide >> timely feedback from the receivers to a sender. This memo defines >> the combination of both profiles to enable secure RTP >> communications with feedback. >> >>http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-09.txt > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 29 04:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge6q3-0005jR-Og; Sun, 29 Oct 2006 04:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge6q2-0005jC-8l for mmusic@ietf.org; Sun, 29 Oct 2006 04:20:18 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge6py-0003WZ-NM for mmusic@ietf.org; Sun, 29 Oct 2006 04:20:18 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7W00L674LKD7@siemenscomms.co.uk> for mmusic@ietf.org; Sun, 29 Oct 2006 09:20:09 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZ4MM>; Sun, 29 Oct 2006 09:19:57 +0000 Content-return: allowed Date: Sun, 29 Oct 2006 09:19:56 +0000 From: "Elwell, John" Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 01.txt To: Dan Wing , 'Francois Audet' , 'Hadriel Kaplan' , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A38D722@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan, It would probably need to be something like: a=srtp key-mgmt:0=96,18=97 crypto:0=98,18=99 fingerprint:0=100,18=101 zrtp:0=102,18=103 John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 27 October 2006 18:46 > To: Elwell, John; 'Francois Audet'; 'Hadriel Kaplan'; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: I-D > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > And another for srtp-dtls and another for zrtp? > > Maybe there is a more efficient way to combine these. Perhaps only > including a=srtp for those key exchange mechanisms which can allow > decrypting SRTP media that arrives prior to the SDP answer? > Or perhaps > specifying the payload types in such a way that they're > assigned to each of > the a= key management mechanisms understood by the answerer. > As a possible > strawman for this last idea: > > m=blahblah > a=key-mgmt blahblah > a=crypto blahblah > a=fingerprint blahblah (used by srtp-dtls) > a=zrtp > a=srtp key-mgmt 40 crypto 41 fingerprint 42 zrtp 43 > > -d > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Thursday, October 26, 2006 11:07 PM > > To: Francois Audet; Hadriel Kaplan; mmusic@ietf.org > > Subject: RE: [MMUSIC] RE: I-D > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > Francois, > > > > Yes, that would work. > > > > John > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 27 October 2006 01:22 > > > To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org > > > Subject: RE: [MMUSIC] RE: I-D > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > Maybe we could use one a=srtp line for crypto, and another one for > > > kmgmt? > > > > > > (i.e., have a different PT for each?) > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Thursday, October 26, 2006 5:56 AM > > > > To: Hadriel Kaplan; Audet, Francois (SC100:3055); > mmusic@ietf.org > > > > Subject: [MMUSIC] RE: I-D > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > Hadriel, Francois, > > > > > > > > Thanks for working on this update. Just one point. If both > > > > SDescriptions and MIKEY are offered (inclusion of a=crypto > > > > and a=key-mgmt lines) and a different payload type is also > > > > indicated for SRTP, this payload type would apply whether the > > > > SDescription-derived key or the MIKEY-derived key is used. > > > > So until the SDP answer arrives, it would still not be > > > > possible to render SRTP. Of course, in the case of > > > > SDescriptions it is not possible anyway, but in the case of > > > > certain MIKEY options it ought to be possible. Unfortunately > > > > to resolve this we would need somewhat more complex syntax in > > > > the a=srtp line. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > > > > > Sent: 25 October 2006 20:50 > > > > > To: i-d-announce@ietf.org > > > > > Subject: I-D > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > directories. > > > > > > > > > > > > > > > Title : Session Description Protocol (SDP) > > > > > Offer/Answer Negotiation For Best-Effort Secure Real-Time > > > Transport > > > > > Protocol > > > > > Author(s) : F. Audet, H. Kaplan > > > > > Filename : > > draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > Pages : 17 > > > > > Date : 2006-10-25 > > > > > > > > > > This document defines the requirements and a proposed > > > solution for > > > > > an SDP Offer/Answer exchange model for negotiating > > > > best-effort SRTP > > > > > keys, i.e., in a backward-compatible manner with > > > > non-SRTP devices. > > > > > The proposed solution is a trivial interpretation of the > > > > usage of > > > > > the profile and the usage of SDP indication of [sdesc] > > > > and [kmgmt]. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > > > > > ffort-srtp-01.txt > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > message to > > > > > i-d-announce-request@ietf.org with the word unsubscribe in > > > > the body of > > > > > the message. > > > > > You can also visit > > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > > to change your subscription settings. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. > > > Login with the > > > > > username "anonymous" and a password of your e-mail > > address. After > > > > > logging in, type "cd internet-drafts" and then "get > > > > > draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > http://www.ietf.org/shadow.html or > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > Send a message to: > > > > > mailserv@ietf.org. > > > > > In the body type: > > > > > "FILE > > > > > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > MIME-encoded form by using the "mpack" utility. > > To use this > > > > > feature, insert the command "ENCODING mime" > > before the "FILE" > > > > > command. To decode the response(s), you will > > need "munpack" or > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > mail readers > > > > > exhibit different behavior, especially when dealing with > > > > > "multipart" MIME messages (i.e. documents which > > have been split > > > > > up into multiple messages), so check your local > > documentation on > > > > > how to manipulate these messages. > > > > > > > > > > Below is the data which will enable a MIME compliant > > mail reader > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > Internet-Draft. > > > > > > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 29 06:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8uI-0001h8-FD; Sun, 29 Oct 2006 06:32:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8uG-0001fL-Iv; Sun, 29 Oct 2006 06:32:48 -0500 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge8uF-0007Kt-8j; Sun, 29 Oct 2006 06:32:48 -0500 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 4E1DE1D88F50; Sun, 29 Oct 2006 12:32:44 +0100 (CET) Received: from localhost (mailgw1.hhi.de [192.168.20.43]) by mail.hhi.fraunhofer.de (Postfix) with SMTP id A40A51D88F44; Sun, 29 Oct 2006 12:32:43 +0100 (CET) Received: from mail.hhi.fraunhofer.de (mail.hhi.fraunhofer.de [192.168.20.45]) by mailgw1.hhi.de (Postfix) with ESMTP id 67EED10A40E1; Sun, 29 Oct 2006 12:32:34 +0100 (CET) Received: from ipam040189 (p54BC87D8.dip0.t-ipconnect.de [84.188.135.216]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id A470F1D88F44; Sun, 29 Oct 2006 12:32:31 +0100 (CET) From: "Thomas Schierl" To: , Date: Sun, 29 Oct 2006 12:32:32 +0100 Organization: HHI/FhG Message-ID: <006301c6fb4d$f15c00f0$179fa8c0@ipam040189> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb7TewzWFXVI5ieSIKBu726OMfZQA== X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.7 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Ye-Kui.Wang@nokia.com, 'Jonathan Lennox' Subject: [MMUSIC] New I-D version of draft-schierl-mmusic-layered-codec X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi all, A new version of draft-schierl-mmusic-layered-codec on "Signaling of layered and multi description media in Session Description Protocol (SDP)" is available. Please review it. Unfortunately, we ran out of time, thus it is somewhat inconsistent and less matured than we would have wished. Anyway, there are open questions within the draft, which may require at least a quick review. ftp://ftp.ietf.org/internet-drafts/draft-schierl-mmusic-layered-codec-01.txt The draft will be presented in mmusic as well as in avt, because of its relation to the RTP Payload Format for SVC Video. ftp://ftp.ietf.org/internet-drafts/draft-wenger-avt-rtp-svc-03.txt Thanks and see you in San Diego, Thomas _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 29 14:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeGIm-0002AL-LC; Sun, 29 Oct 2006 14:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeGIR-00029O-0s for mmusic@ietf.org; Sun, 29 Oct 2006 14:26:15 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeGIM-0002MD-JV for mmusic@ietf.org; Sun, 29 Oct 2006 14:26:14 -0500 Received: from [84.209.226.151] (helo=[192.168.1.130]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1GeGIH-0005Wf-GA for mmusic@ietf.org; Sun, 29 Oct 2006 19:26:05 +0000 Message-ID: <4545007D.2080109@db.org> Date: Sun, 29 Oct 2006 20:26:53 +0100 From: "Alfred E. Heggestad" User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org hi here are some comment on some minor things in draft-ietf-mmusic-ice-11: > Section 4.1. Gathering Candidates > > Agents which serve end users directly, such softphones, hardphones, > ^^^^^^^^^^^^^^^ typo -> should be "such as" > Section 5.6. Forming the Check Lists > > pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P:1?0) > > Where O-P>A-P:1?0 is an expression whose value is 1 if O-P is greater > it would be better to write "O-P>A-P:1?0" as "O-P>A-P?1:0", i.e. where the question mark and the colon are swapped. this is standard C syntax, and will evalate to 1 if O-P>A-P and 0 if not. > Section 7.7.2. Processing the Response > > the agent knows about, the mapped address representes a new peer > ^^^^^^^^^^^ typo -> should be "represents" > Section 8. Completing the ICE Checks > > When a pair is aded to the valid list, and the agent was the answerer > ^^^^ typo -> should be "added" > Section 8. Completing the ICE Checks > > assymetric. It is possible to fix both of these problems by > ^^^^^^^^^^ typo. should be "asymmetric" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 29 21:14:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMeY-0006AO-Sn; Sun, 29 Oct 2006 21:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMTw-0003gi-Me for mmusic@ietf.org; Sun, 29 Oct 2006 21:02:32 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeML8-00024Y-T1 for mmusic@ietf.org; Sun, 29 Oct 2006 20:53:29 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1B5D41E8C28; Sun, 29 Oct 2006 17:53:22 -0800 (PST) To: derek@counterpath.com Subject: Re: [MMUSIC] ICE-12, SBCs and hotel ALGs References: <44590.10.238.10.71.1161976466.webmail@10.238.10.71> From: Eric Rescorla Date: Sun, 29 Oct 2006 17:53:22 -0800 In-Reply-To: <44590.10.238.10.71.1161976466.webmail@10.238.10.71> (derek@counterpath.com's message of "Fri, 27 Oct 2006 15:14:26 -0400 (EDT)") Message-ID: <86ac3eefhp.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mmusic@ietf.org, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org derek@counterpath.com writes: > The consensus that we reached on the ICE calls was that a user agent > could ignore the m/c line if it couldn't validated by ICE. This is > needed to deal with misbehaving ALG devices, which are an existing > deployment issue. These devices are often not controlled by the > network operator, and can be seen as morally equivalent to a > misbehaving NAT from the ice requirements standpoint. I too am uncomfortable with aborting in this case. > I propose we have another ice breakout session this IETF to try to > reach consensus on this long running issue. Given past performance, > we should schedule several hours. Yeah, this sounds right. Let's schedule it soon, too, cause my schedule is filling up already. -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 29 21:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMvG-0000SG-EV; Sun, 29 Oct 2006 21:30:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMgj-0006iw-SB for mmusic@ietf.org; Sun, 29 Oct 2006 21:15:45 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeMgh-0006MJ-D3 for mmusic@ietf.org; Sun, 29 Oct 2006 21:15:45 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id A0170614; Sun, 29 Oct 2006 21:14:47 -0500 From: "Hadriel Kaplan" To: "'Elwell, John'" , "'Dan Wing'" , "'Francois Audet'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Sun, 29 Oct 2006 21:14:34 -0500 Message-ID: <006001c6fbc9$2530a0e0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb7O2c3PZUDoigIQoirauJsm96rFQAjOO/g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A38D722@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.1 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I wouldn't think zrtp would need port-mapping. They're supposed to handshake in clear RTP (or maybe rtcp depending on how the argument in AVT ends up). So they should be able to use the m= line ones. I would expect that any media-plane key exchange mechanism would be designed such that it gracefully fails if either side doesn't support it, no? They may need/want an attribute so the offerer can tell the answerer to try it, or other info like a fingerprint, but port-mapping wouldn't be one of them, would it? -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Sunday, October 29, 2006 4:20 AM > To: Dan Wing; 'Francois Audet'; 'Hadriel Kaplan'; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- > 01.txt > > Dan, > > It would probably need to be something like: > a=srtp key-mgmt:0=96,18=97 crypto:0=98,18=99 fingerprint:0=100,18=101 > zrtp:0=102,18=103 > > John > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 27 October 2006 18:46 > > To: Elwell, John; 'Francois Audet'; 'Hadriel Kaplan'; mmusic@ietf.org > > Subject: RE: [MMUSIC] RE: I-D > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > And another for srtp-dtls and another for zrtp? > > > > Maybe there is a more efficient way to combine these. Perhaps only > > including a=srtp for those key exchange mechanisms which can allow > > decrypting SRTP media that arrives prior to the SDP answer? > > Or perhaps > > specifying the payload types in such a way that they're > > assigned to each of > > the a= key management mechanisms understood by the answerer. > > As a possible > > strawman for this last idea: > > > > m=blahblah > > a=key-mgmt blahblah > > a=crypto blahblah > > a=fingerprint blahblah (used by srtp-dtls) > > a=zrtp > > a=srtp key-mgmt 40 crypto 41 fingerprint 42 zrtp 43 > > > > -d > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Thursday, October 26, 2006 11:07 PM > > > To: Francois Audet; Hadriel Kaplan; mmusic@ietf.org > > > Subject: RE: [MMUSIC] RE: I-D > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > Francois, > > > > > > Yes, that would work. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 27 October 2006 01:22 > > > > To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org > > > > Subject: RE: [MMUSIC] RE: I-D > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > Maybe we could use one a=srtp line for crypto, and another one for > > > > kmgmt? > > > > > > > > (i.e., have a different PT for each?) > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: Thursday, October 26, 2006 5:56 AM > > > > > To: Hadriel Kaplan; Audet, Francois (SC100:3055); > > mmusic@ietf.org > > > > > Subject: [MMUSIC] RE: I-D > > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > > > Hadriel, Francois, > > > > > > > > > > Thanks for working on this update. Just one point. If both > > > > > SDescriptions and MIKEY are offered (inclusion of a=crypto > > > > > and a=key-mgmt lines) and a different payload type is also > > > > > indicated for SRTP, this payload type would apply whether the > > > > > SDescription-derived key or the MIKEY-derived key is used. > > > > > So until the SDP answer arrives, it would still not be > > > > > possible to render SRTP. Of course, in the case of > > > > > SDescriptions it is not possible anyway, but in the case of > > > > > certain MIKEY options it ought to be possible. Unfortunately > > > > > to resolve this we would need somewhat more complex syntax in > > > > > the a=srtp line. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Internet-Drafts@ietf.org > > [mailto:Internet-Drafts@ietf.org] > > > > > > Sent: 25 October 2006 20:50 > > > > > > To: i-d-announce@ietf.org > > > > > > Subject: I-D > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > directories. > > > > > > > > > > > > > > > > > > Title : Session Description Protocol (SDP) > > > > > > Offer/Answer Negotiation For Best-Effort Secure Real-Time > > > > Transport > > > > > > Protocol > > > > > > Author(s) : F. Audet, H. Kaplan > > > > > > Filename : > > > draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > Pages : 17 > > > > > > Date : 2006-10-25 > > > > > > > > > > > > This document defines the requirements and a proposed > > > > solution for > > > > > > an SDP Offer/Answer exchange model for negotiating > > > > > best-effort SRTP > > > > > > keys, i.e., in a backward-compatible manner with > > > > > non-SRTP devices. > > > > > > The proposed solution is a trivial interpretation of the > > > > > usage of > > > > > > the profile and the usage of SDP indication of [sdesc] > > > > > and [kmgmt]. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > > > > > > ffort-srtp-01.txt > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > message to > > > > > > i-d-announce-request@ietf.org with the word unsubscribe in > > > > > the body of > > > > > > the message. > > > > > > You can also visit > > > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > > > to change your subscription settings. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. > > > > Login with the > > > > > > username "anonymous" and a password of your e-mail > > > address. After > > > > > > logging in, type "cd internet-drafts" and then "get > > > > > > draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > http://www.ietf.org/shadow.html or > > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > Send a message to: > > > > > > mailserv@ietf.org. > > > > > > In the body type: > > > > > > "FILE > > > > > > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > > MIME-encoded form by using the "mpack" utility. > > > To use this > > > > > > feature, insert the command "ENCODING mime" > > > before the "FILE" > > > > > > command. To decode the response(s), you will > > > need "munpack" or > > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > mail readers > > > > > > exhibit different behavior, especially when dealing with > > > > > > "multipart" MIME messages (i.e. documents which > > > have been split > > > > > > up into multiple messages), so check your local > > > documentation on > > > > > > how to manipulate these messages. > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > > mail reader > > > > > > implementation to automatically retrieve the ASCII > > > version of the > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Oct 29 21:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeN7C-0007Du-Rk; Sun, 29 Oct 2006 21:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMt1-00089n-44 for mmusic@ietf.org; Sun, 29 Oct 2006 21:28:27 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeMsz-0008L4-4K for mmusic@ietf.org; Sun, 29 Oct 2006 21:28:26 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 0101B1CC22 for ; Sun, 29 Oct 2006 18:28:18 -0800 (PST) To: mmusic@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 29 Oct 2006 18:28:17 -0800 From: EKR Message-Id: <20061030022818.0101B1CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org $Id: draft-ietf-mmusic-ice-12-rev.txt,v 1.1 2006/10/30 02:31:02 ekr Exp $ A few notes on ICE-12. As I understand the USE-CANDIDATE flag, there are two ways things can happen. 1. The controlling agent (henceforth CoA) can include the USE-CANDIDATE flag in one (or more) of his initial periodic checks and when that check concludes the component is automatically done. 2. The CoA can complete (or give up on) all of his periodic checks and then do a *new* check on one of the components that succeeded. Do I have this correct? If so, I think that you should be a little clearer earlier on that one may receive duplicate checks. I would advise doing this by adding the following to the end of S 9, para 2. "Note, an implementation may choose to complete all possible checks and then choose the best one (given some metric). In this case, it will send initial checks without the USE-CANDIDATE flag and then a second check on a single candidate using the USE-CANDIDATE flag." As I understand it, candidates should only be "selected" once checks have succeeded in the direction you want to send. I.e., if you're not the CoA and the first request you see contains a USE-CANDIDATE flag, you do a triggered check and only select the candidate upon receipt of the response. Is this right? That's what Figure 10 seems to show. If it is, Figure 4 is kind of misleading. I guess it's supposed to show approach (1) above, but... Figure 10 should indicate that msg 10 has the USE-CANDIDATE flag set. -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 04:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTN8-0004FZ-RX; Mon, 30 Oct 2006 04:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTLj-0003qU-0L for mmusic@ietf.org; Mon, 30 Oct 2006 04:22:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeQpP-0007ML-LN for mmusic@ietf.org; Mon, 30 Oct 2006 01:41:10 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D3CEEA61; Mon, 30 Oct 2006 07:40:29 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 07:40:29 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 07:40:29 +0100 Received: from [131.160.36.36] (EH3I2003TGFCPET-131160036036.lmf.ericsson.se [131.160.36.36]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CCF9D23F6; Mon, 30 Oct 2006 08:40:28 +0200 (EET) Message-ID: <45459E5C.1040406@ericsson.com> Date: Mon, 30 Oct 2006 08:40:28 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: j.koshiko@east.ntt.co.jp Subject: Re: [MMUSIC] Question about bundling SDP m=lines References: <20061003192708.3D31.J.KOSHIKO@east.ntt.co.jp> In-Reply-To: <20061003192708.3D31.J.KOSHIKO@east.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 06:40:29.0274 (UTC) FILETIME=[4A39FBA0:01C6FBEE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, yes, you could use the grouping framework to group a few streams together so that they should be accepted or rejected as a group. As you point out, none of the current 'semantics' does this. Therefore, you would need to define new 'semantics' for the framework. Cheers, Gonzalo j.koshiko@east.ntt.co.jp wrote: > Folks, > > I hope I would like to ask an question on SDP offer/answer model. > > Imagine the case where the offerer initiates a video call. > Is there any parameter which indicates offerer doesn't want > answerer to answer an SDP with video medium only, > without an audio medium? > > An SDP offer for video call includes two m=lines, m=audio and m=video. > According to RFC4566/3264, the answerer may read > each m=line independently, and may return a SDP answer > with port 0 in either of the two m=lines. > Session may be established with video only, without audio, > which is not the caller's intention. > > offerer answerer > | | > | INVITE (m=video & m=audio) | > |--------------------------------->| > | 200 OK (m=video & m=audio port 0)| > |<---------------------------------| > | RTP session (video only) | > |<================================>| > | | > > To avoid this, offerer have to tell the answerer that > m=audio and m=video are bundled and that it doesn't > want to establish with either of the media. > > I hope I would like to ask you how to express the offerer's intention. > > I guess this should be achived by m=line group attribute > defined by RFC3388, because it says in Chapter 1 that "expression of > how different media streams within a session description relate to > each other." I guess that this would make it possible to express > that m=audio and m=video are bundled. > > What the "semantics" field should be set, > if I use a group attribute in this way? > Four values, "LS", "FID", "SRF" and "ANAT" are registered on IANA, > but none of them seems to be intended to influence UA's offer/answer. > Is a new semantics parameter needed to meed the requirement? > > Please let me know your advice. > > Does this topic match to another mailing list more? > I apologize if this subject is off-topic for this mailing list. > > Thank you, > Jun Koshiko > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 09:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYM3-00049h-8T; Mon, 30 Oct 2006 09:43:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYM1-00049c-Mz for mmusic@ietf.org; Mon, 30 Oct 2006 09:43:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeYLx-0008R8-5m for mmusic@ietf.org; Mon, 30 Oct 2006 09:43:09 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2006 09:43:05 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UEh4Pe020445; Mon, 30 Oct 2006 09:43:04 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9UEh4DM018443; Mon, 30 Oct 2006 09:43:04 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 09:43:04 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 09:43:04 -0500 Message-ID: <45460F77.5050906@cisco.com> Date: Mon, 30 Oct 2006 09:43:03 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [MMUSIC] Question about bundling SDP m=lines References: <20061003192708.3D31.J.KOSHIKO@east.ntt.co.jp> <45459E5C.1040406@ericsson.com> In-Reply-To: <45459E5C.1040406@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 14:43:04.0152 (UTC) FILETIME=[B4ADBD80:01C6FC31] DKIM-Signature: a=rsa-sha1; q=dns; l=4245; t=1162219384; x=1163083384; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[MMUSIC]=20Question=20about=20bundling=20SDP=20m=3Dlines |To:Gonzalo=20Camarillo=20; X=v=3Dcisco.com=3B=20h=3Dw9eOR5pZ3S4tiA+ipOAS90wcAPw=3D; b=DX3lFbtN/K+saIbpNS8R65u/UGd3vyZwzbWuUViSGX+Qbp7veqq2uEg9BxHW1oPtm5y7W3KE tkH5oTtg+xCMTyw7EZgSyqYPT/4CmgqfMhwPUf79h+5V4Em7xPMmQoQn; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This seems to be one more example of a whole family of cases where SDP and offer/answer aren't sufficient to state the criteria desired for a call. Other examples are: - several codecs can be supported but only one at a time, so any answer listing more than one codec is unacceptable. (Unless of course there are two and one of them is telephone-events.) - I'd like an audio call or a fax call, but not both One solution to this is to come up with a new notation to express each new kind of constraint, and add it to SDP. Another possible solution might be to use an attribute to characterize media streams as "required" or "optional", with the expectation that a call should not be completed unless the "required" streams can be established. Yet another possible solution is to use preconditions. I haven't thought out the details, but it seems it would be possible to define a precondition type related to media sufficiency. This would delay alerting while the offerer gets to see the initial answer. At that point the offerer can call things off if the answer isn't sufficient. This would avoid the need to express all possible types of constraints, reducing it to a case of "I'll know if its good when I see it". Unfortunately, it seems that use of preconditions has not caught on. So this kind of solution isn't likely to be very popular. Paul Gonzalo Camarillo wrote: > Hi, > > yes, you could use the grouping framework to group a few streams > together so that they should be accepted or rejected as a group. As you > point out, none of the current 'semantics' does this. Therefore, you > would need to define new 'semantics' for the framework. > > Cheers, > > Gonzalo > > j.koshiko@east.ntt.co.jp wrote: >> Folks, >> >> I hope I would like to ask an question on SDP offer/answer model. >> >> Imagine the case where the offerer initiates a video call. >> Is there any parameter which indicates offerer doesn't want >> answerer to answer an SDP with video medium only, >> without an audio medium? >> >> An SDP offer for video call includes two m=lines, m=audio and m=video. >> According to RFC4566/3264, the answerer may read >> each m=line independently, and may return a SDP answer >> with port 0 in either of the two m=lines. >> Session may be established with video only, without audio, >> which is not the caller's intention. >> >> offerer answerer >> | | >> | INVITE (m=video & m=audio) | >> |--------------------------------->| >> | 200 OK (m=video & m=audio port 0)| >> |<---------------------------------| >> | RTP session (video only) | >> |<================================>| >> | | >> >> To avoid this, offerer have to tell the answerer that >> m=audio and m=video are bundled and that it doesn't >> want to establish with either of the media. >> >> I hope I would like to ask you how to express the offerer's intention. >> >> I guess this should be achived by m=line group attribute >> defined by RFC3388, because it says in Chapter 1 that "expression of >> how different media streams within a session description relate to >> each other." I guess that this would make it possible to express >> that m=audio and m=video are bundled. >> >> What the "semantics" field should be set, if I use a group attribute >> in this way? Four values, "LS", "FID", "SRF" and "ANAT" are registered >> on IANA, >> but none of them seems to be intended to influence UA's offer/answer. >> Is a new semantics parameter needed to meed the requirement? >> >> Please let me know your advice. >> >> Does this topic match to another mailing list more? >> I apologize if this subject is off-topic for this mailing list. >> >> Thank you, >> Jun Koshiko >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 11:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gea6R-0003jw-4c; Mon, 30 Oct 2006 11:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gea6P-0003jq-Qb for mmusic@ietf.org; Mon, 30 Oct 2006 11:35:09 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gea6M-0005TX-GU for mmusic@ietf.org; Mon, 30 Oct 2006 11:35:09 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9UGZ5Bi008340; Mon, 30 Oct 2006 09:35:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Oct 2006 09:35:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mmusic-ice-12: questions on ICE's local preference and rfc 3484's source address selection algorithm Thread-Index: Acb8QWBb2DCrv/RWQ1azohiMxQZa0Q== From: "Jean-Francois Mule" To: "Jonathan Rosenberg" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [MMUSIC] draft-ietf-mmusic-ice-12: questions on ICE's local preference and rfc 3484's source address selection algorithm X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, In section 5.2 of ice-12, the second paragraph on page 19 has some considerations on the selection of (local) preferences based on the IP address family (Ipv6, IPv4). While ice defines an application level mechanisms for choosing between candidates for valid connectivity, RFC 3484 defines a default source/destination address selection algorithm for IPv6 nodes (in cases where there is no guidance provided by the application layer).=20 --- Questions: 1. Would it be appropriate to somehow link the precedence of the policy table in 3484 with the local preference of ICE when both IPv4 and IPv6 candidates are present, and a policy table does exist? What got me to go back to 3484 is the second sentence of that second paragraph on page 19 of ice-12 on how connectivity checks over IPv6 might be preferred over IPv4 ones; see section 10.3 of 3484 - there seems to be some parallels at a first sight. 2. Would it be useful to mention RFC 3484 in ICE and discuss how it may/should be used in dual-stack hosts to derive the local preference of particular candidate? Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 12:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebPT-0000wV-H7; Mon, 30 Oct 2006 12:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebP9-0000mF-8x for mmusic@ietf.org; Mon, 30 Oct 2006 12:58:35 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebAA-0004YJ-6y for mmusic@ietf.org; Mon, 30 Oct 2006 12:43:16 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id k9UHg4MW025401; Mon, 30 Oct 2006 11:42:05 -0600 (CST) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.234.25]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k9UHg4I19053; Mon, 30 Oct 2006 11:42:04 -0600 (CST) Message-Id: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Oct 2006 11:42:02 -0600 To: mmusic@ietf.org From: John Rosenberg Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <4.3.2.7.2.20060927201415.032e6848@email.cisco.com> References: <200609270215.k8R2FI5J006271@workhorse.brookfield.occnc.com > <200609270215.k8R2FI5J006271@workhorse.brookfield.occnc.com> <4.3.2.7.2.20060927201415.032e6848@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan Wing wrote: >I agree with Francois -- I need to understand the justification for this >functionality. This seems only germain to each local network and I don't >see the value in signaling this in SDP. I think the justification here is to allow a call controller/session manager to exert influence over the endpoints' behavior in choosing the DSCP value to use for a bearer stream. For example in the US, DISA has some requirements for their Defense Information System Network that specify that a call controller must instruct served CPE regarding what DSCP value to use in the bearer based on the precedence level that the user requests - this involves an authentication and authorization to use that level in the call controller (a B2BUA). While it's interesting, and potentially useful, for one EP to tell another "Hey, I'm going to use DSCP 41" I think that view of this draft misses its point, and that the real power is allowing a call controller/session manager to drive the endpoint's behavior. This allows for all kinds of good things - like authorization - to come into play w.r.t. use of particular DSCP values and the PHBs they imply. In cases when the bearer streams cross network boundaries, I would expect Session Boarder Controllers to rewrite the SDP and modify the DSCP attribute as appropriate per policy - similar to how STPs that interconnect ISUP networks modify IAMs transmitted between networks. John Rosenberg Lucent Technologies _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 13:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebUu-00036L-6F; Mon, 30 Oct 2006 13:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebUs-00035w-94 for mmusic@ietf.org; Mon, 30 Oct 2006 13:04:30 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebUj-0001aj-3Z for mmusic@ietf.org; Mon, 30 Oct 2006 13:04:30 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9UHvJB10101; Mon, 30 Oct 2006 12:57:19 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Mon, 30 Oct 2006 12:04:06 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nortel.com> In-Reply-To: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Thread-Index: Acb8TXSpt5X2OZGFTlCdCeoUb8rBQQAADuQQ From: "Francois Audet" To: "John Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Even a better reason then to use the config-framework instead of mandating a B2BUA in the middle pretending to be the other end.=20 > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com]=20 > Sent: Monday, October 30, 2006 9:42 AM > To: mmusic@ietf.org > Cc: jmpolk@email.cisco.com > Subject: RE: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer >=20 > Dan Wing wrote: >=20 >=20 > >I agree with Francois -- I need to understand the justification for=20 > >this functionality. This seems only germain to each local=20 > network and=20 > >I don't see the value in signaling this in SDP. >=20 > I think the justification here is to allow a call=20 > controller/session manager to exert influence over the=20 > endpoints' behavior in choosing the DSCP value to use for a=20 > bearer stream. For example in the US, DISA has some=20 > requirements for their Defense Information System Network=20 > that specify that a call controller must instruct served CPE=20 > regarding what DSCP value to use in the bearer based on the=20 > precedence level that the user requests - this involves an=20 > authentication and authorization to use that level in the=20 > call controller (a B2BUA). >=20 > While it's interesting, and potentially useful, for one EP to=20 > tell another "Hey, I'm going to use DSCP 41" I think that=20 > view of this draft misses its point, and that the real power=20 > is allowing a call controller/session manager to drive the=20 > endpoint's behavior. This allows for all kinds of good things=20 > - like authorization - to come into play w.r.t. use of=20 > particular DSCP values and the PHBs they imply. >=20 > In cases when the bearer streams cross network boundaries, I=20 > would expect Session Boarder Controllers to rewrite the SDP=20 > and modify the DSCP attribute as appropriate per policy -=20 > similar to how STPs that interconnect ISUP networks modify=20 > IAMs transmitted between networks. >=20 > John Rosenberg > Lucent Technologies >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 13:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebbh-0000xz-45; Mon, 30 Oct 2006 13:11:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebbf-0000xn-Jd for mmusic@ietf.org; Mon, 30 Oct 2006 13:11:31 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gebbb-00031M-5z for mmusic@ietf.org; Mon, 30 Oct 2006 13:11:31 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id k9UIAQYa019763; Mon, 30 Oct 2006 12:10:26 -0600 (CST) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.234.25]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k9UIAPI09611; Mon, 30 Oct 2006 12:10:25 -0600 (CST) Message-Id: <200610301810.k9UIAPI09611@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Oct 2006 12:10:21 -0600 To: "Francois Audet" , From: John Rosenberg Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nor tel.com> References: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I don't think anything is mandating a B2BUA in the middle. In the DISA case there *is* a B2BUA in the middle and the requirement is that it have a way to tell the endpoint what DSCP value to use. The mechanism James is proposing fits the bill in that situation, and would also be useful in an IMS network to allow a CSCF or App Server to exert control over the DSCP values and thus the Per Hop behaviors that they imply. John At 12:04 PM 10/30/2006, Francois Audet wrote: >Even a better reason then to use the config-framework instead of >mandating >a B2BUA in the middle pretending to be the other end. > >> -----Original Message----- >> From: John Rosenberg [mailto:jrrosenberg@lucent.com] >> Sent: Monday, October 30, 2006 9:42 AM >> To: mmusic@ietf.org >> Cc: jmpolk@email.cisco.com >> Subject: RE: [MMUSIC] New ID on conveying a DSCP >> marking/remarking in an Offer >> >> Dan Wing wrote: >> >> >> >I agree with Francois -- I need to understand the justification for >> >this functionality. This seems only germain to each local >> network and >> >I don't see the value in signaling this in SDP. >> >> I think the justification here is to allow a call >> controller/session manager to exert influence over the >> endpoints' behavior in choosing the DSCP value to use for a >> bearer stream. For example in the US, DISA has some >> requirements for their Defense Information System Network >> that specify that a call controller must instruct served CPE >> regarding what DSCP value to use in the bearer based on the >> precedence level that the user requests - this involves an >> authentication and authorization to use that level in the >> call controller (a B2BUA). >> >> While it's interesting, and potentially useful, for one EP to >> tell another "Hey, I'm going to use DSCP 41" I think that >> view of this draft misses its point, and that the real power >> is allowing a call controller/session manager to drive the >> endpoint's behavior. This allows for all kinds of good things >> - like authorization - to come into play w.r.t. use of >> particular DSCP values and the PHBs they imply. >> >> In cases when the bearer streams cross network boundaries, I >> would expect Session Boarder Controllers to rewrite the SDP >> and modify the DSCP attribute as appropriate per policy - >> similar to how STPs that interconnect ISUP networks modify >> IAMs transmitted between networks. >> >> John Rosenberg >> Lucent Technologies >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 13:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec7o-0007Kz-AL; Mon, 30 Oct 2006 13:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec7m-0007Hg-RF for mmusic@ietf.org; Mon, 30 Oct 2006 13:44:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gec48-0001DC-Ra for mmusic@ietf.org; Mon, 30 Oct 2006 13:40:59 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2006 10:40:57 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UIeue4012077; Mon, 30 Oct 2006 13:40:56 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9UIeuDO005736; Mon, 30 Oct 2006 13:40:56 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:40:56 -0500 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:40:55 -0500 Message-ID: <45464737.5040403@cisco.com> Date: Mon, 30 Oct 2006 13:40:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: derek@counterpath.com Subject: Re: [MMUSIC] ICE-12, SBCs and hotel ALGs References: <44590.10.238.10.71.1161976466.webmail@10.238.10.71> In-Reply-To: <44590.10.238.10.71.1161976466.webmail@10.238.10.71> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 18:40:55.0830 (UTC) FILETIME=[EF42FB60:01C6FC52] DKIM-Signature: a=rsa-sha1; q=dns; l=3556; t=1162233656; x=1163097656; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20ICE-12,=20SBCs=20and=20hotel=20ALGs |To:derek@counterpath.com; X=v=3Dcisco.com=3B=20h=3DyNTj2a3gvL+TLEjbgguRtrh61Zo=3D; b=ew3HYTthU7g7zTFeiZ/p0YjdrIbbo5rJUzC2J0d6xxqMtsUp5G2G70B764QgG3CcZc4GRk49 S2BrL21ZgsufKhWlPEIq45rG/OgdnTm2ImjSTgnwg/Pumz7J3hMcxQ08; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic@ietf.org, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org derek@counterpath.com wrote: > The consensus that we reached on the ICE calls was that a user agent > could ignore the m/c line if it couldn't validated by ICE. This is > needed to deal with misbehaving ALG devices, which are an existing > deployment issue. These devices are often not controlled by the > network operator, and can be seen as morally equivalent to a > misbehaving NAT from the ice requirements standpoint. The problem I ran into is that this is the "right" thing to do for those nasty ALGs, but is exactly the wrong thing to do for an SBC thats on the path. THe UA cannot tell which is which. So, when an offer shows up with an m/c-line which doesn't match a candidate, and it doesn't validate, is the situation that: 1. there is an SBC on the path that is ice-unaware, and it blocks non-RTP packets from flowing 2. there is an ALG on the path that is broken and the m/c-line it provided doesnt work You cannot differentiate these two cases with ICE. If you ignore the m/c-line assuming its case (2), and in reality its case (1), the call will fail. So, the mechanism that can in fact make things more reliable here is to deal with the ALG problem with SIP over TLS, leaving only case 1. Then, in case 1, you do what I described in ICE-12 - use the m/c-line and abort ICE processing. > > A large part of this debate was around whether SBC type devices > needed to be ICE aware, or if ICE should be designed so that it > deosn't "work around" existing SBCs. I don't know if we settled that > debate; consensus seemd to be that it is easy for an SBC vendor to > disable ice. Changing ice so that the m/c line MUST match a candidate > assumes that the requirement is that ice not bypass existing SBC > devices. This includes the motivation that existing SBC devices do > not allow ice checks to proceed. We need to resolve this SBC/ICE > requirments debate if we are ever going to reach consensus on ICE. THere are two cases to worry about - ICE aware and ICE-unaware SBCs. For ICE-aware, there are lots of things an SBC can do once it knows ICE is running. THis was really not the case we were worried about. Its an ICE-unaware SBC. I believe the requirement is that calls do not fail in the presence of an ICE-unaware SBC. That is the only requirement I think we should strive to meet. Some folks wanted the requirement to get around the ICE-unaware SBC if a better path was available. I disagree with that and I think it is a path fraught with peril. You simply don't know how the SBC is configured or working and you should not guess your way around it. An SBC is a UA, and when one is in the way, its like talking to an ICE-unaware UA. We should abort ICE. > > It seems to me that a way forward is to have two operating modes for > ice; one which is designed to honour existing middle boxes in a > deployment, and one which just tries to establish connectivity. I really noodled on this for a while. Given the unpredictability of SBC and ALG behavior, I do not think you can write an algorithm which will work. The problem is that you just don't know what the SBC behavior is going to be. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 13:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec8g-0007tF-0s; Mon, 30 Oct 2006 13:45:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec83-0007Q8-UP for mmusic@ietf.org; Mon, 30 Oct 2006 13:44:59 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gebzh-0000Hz-62 for mmusic@ietf.org; Mon, 30 Oct 2006 13:36:23 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9UITIB22762; Mon, 30 Oct 2006 13:29:18 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Oct 2006 12:36:06 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2A029@zrc2hxm0.corp.nortel.com> In-Reply-To: <45431294.8060507@netlab.hut.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: alternate RTP profiles in SDP offer/answer Thread-Index: Acb6adD2pCb1ylzmTzqBOBAJndchqQB4Z5qg From: "Francois Audet" To: "Joerg Ott" , "Dan Wing" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, Flemming Andreasen , Joerg Ott Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Joerg, It looks like we may have misinterpreted the concept of "alternatives" in the draft. The drafts left us with the impression that it was indeed endorsing the idea=20 of port overloading. We had assumed that "alternatives" were meant to denote backward compatibility with UAs that did not support SAVPF. I guess the paragraph that you quoted below clarifies it, but it may not be=20 totally obvious to the reader that the mechanism in this draft suffers from the exact same problem described in the 2 drafts than Dan listed. Perhaps a simple statement upfront to clarify it would help. For example, the first paragraph of Page 7 currently state: Different RTP profiles MAY be used in different media sessions. For negotiation of a media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that SAVP and SAVPF entities MAY be mixed in a single RTP session (see section 4). Also, the offer/answer mechanism MAY be used to offer alternatives for the same media session (e.g. using the same transport parameters) and allow the answered to choose one of the profiles. It could be emphasised that what you are really saying is that the alternatives are using multiple media descriptions (i.e., multiple m lines) in a single media session. Something like: Different RTP profiles MAY be used in different media sessions. For negotiation of a media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that SAVP and SAVPF entities MAY be mixed in a single RTP session (see section 4). Also, the offer/answer mechanism MAY be used to offer alternatives for the same media session (e.g. using the same transport parameters and multiple media descriptions) and allow=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the answered to choose one of the profiles. Also, in section 1.1, the description of (SDP) media description could be clarified with something like: (SDP) media description: This term refers to the specification given in a single m=3D line in an SDP message. An SDP media description may define only one RTP session. Grouping of m=3D lines in SDP (each with=20 ^^^^^^^^^^ their own distinct transport address as described in [9]) may cause ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ several SDP session level descriptions to define (alternatives of) the same RTP session for the same media type. =20 Or something along those lines. Thanks, and sorry for the confusion. > -----Original Message----- > From: Joerg Ott [mailto:jo@netlab.tkk.fi]=20 > Sent: Saturday, October 28, 2006 1:20 AM > To: Dan Wing > Cc: mmusic@ietf.org; 'Joerg Ott'; carrara@kth.se; 'Flemming=20 > Andreasen'; 'Hadriel Kaplan'; Audet, Francois (SC100:3055);=20 > ietf-rtpsec@imc.org > Subject: Re: alternate RTP profiles in SDP offer/answer >=20 > Dan, >=20 > what you claim to be a problem here has been removed from the=20 > SAVPF spec for this very reason. -08 had -- by accident --=20 > some remnants in that were taken out in -09. Should there be=20 > an oversight left in, then please be precise of what you mean=20 > and we will be happy to fix this. >=20 > To quote from present -09: >=20 > If alternative RTP profiles are to be specified for a single RTP > session, each alternative needs to be included on a separate media > line in SDP. However, with only basic SDP, it is not possible to > communicate that the two m=3D lines are meant as alternatives (as > opposed to specifying different media sessions of the same type). > A mechanism to indicate semantic equivalence between the=20 > individual > sessions and ensure that any receiver only joins one of them, such > as the grouping framework [9], is being defined in the MMUSIC WG. >=20 > From the mere authorship of the spec, it should become clear=20 > that there is a close interaction with what MMUSIC does. >=20 > I must admit that I am somehwat surprised and not=20 > particularly amused about your seocnd-guessing below. >=20 > Joerg >=20 > > draft-ietf-avt-profile-savpf-09 mentions, in several=20 > places, how ports=20 > > can be overloaded and grouping can be used to specify RTP/SAVP and=20 > > RTP/SAVPF in the same offer. The suggestions in=20 > > draft-ietf-avt-profile-savpf-09 appear to have the drawbacks that=20 > > Flemming describes in section 3.1 and 3.5 of=20 > > draft-andreasen-mmusic-sdp-capability-negotiation-01. It seems=20 > > ill-advised for AVT to publish a document encouraging use=20 > of mechanisms with these drawbacks, unless MMUSIC agrees with=20 > this decision. > >=20 > > Considering that the upcoming IETF has two individual=20 > contributions in=20 > > MMUSIC on this topic,=20 > > draft-andreasen-mmusic-sdp-capability-negotiation-01 > > and draft-kaplan-mmusic-best-effort-srtp-01, I don't=20 > believe there is=20 > > consensus within MMUSIC of which approach to take. > >=20 > > Can Joerggand Elisabetta discuss the technique proposed in > > draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC meeting? Or=20 > > can we perhaps have a joint presentation by all five=20 > authors so that=20 > > MMUSIC can make an informed decision on this important topic? > >=20 > > -d > >=20 > >=20 > >=20 > >> Title : Extended Secure RTP Profile for=20 > >> RTCP-based Feedback (RTP/SAVPF) > >> Author(s) : J. Ott, E. Carrara > >> Filename : draft-ietf-avt-profile-savpf-09.txt > >> Pages : 17 > >> Date : 2006-10-25 > >>=09 > >> An RTP profile (SAVP) is defined for secure real-time > >> communications, and another profile (AVPF) is specified=20 > to provide > >> timely feedback from the receivers to a sender. This=20 > memo defines > >> the combination of both profiles to enable secure RTP > >> communications with feedback. > >> > >>http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-s > avpf-09.tx > >>t > >=20 > >=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 13:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecEG-0004t0-RA; Mon, 30 Oct 2006 13:51:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecEF-0004sa-8s for mmusic@ietf.org; Mon, 30 Oct 2006 13:51:23 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GecEC-0003pL-Uz for mmusic@ietf.org; Mon, 30 Oct 2006 13:51:23 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2006 13:51:21 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UIpKrm006361; Mon, 30 Oct 2006 13:51:20 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9UIpKDM009876; Mon, 30 Oct 2006 13:51:20 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:51:20 -0500 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:51:19 -0500 Message-ID: <454649A8.9090804@cisco.com> Date: Mon, 30 Oct 2006 13:51:20 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Mule References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 18:51:19.0865 (UTC) FILETIME=[63372A90:01C6FC54] DKIM-Signature: a=rsa-sha1; q=dns; l=2246; t=1162234280; x=1163098280; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20draft-ietf-mmusic-ice-12=3A=20questions=20on=20ICE's=20local=20p reference=0A=20and=20rfc=203484's=20source=20address=20selection=20algorith m |To:Jean-Francois=20Mule=20; X=v=3Dcisco.com=3B=20h=3DUrDE5Y8x8AAgF8gkLq2jRLIq/Wk=3D; b=gtxBy3uVXDgy3fDXtvfQDBi28zptGf+NgDs3AYQl78hA3sAomBF6Wbk725fpr2GE3Oc4yZQd /SPOlE3NbBUyFFqTBJTRGgkVn7qsf4RpDV/XdPPaflL1SAmcNVIL82f6; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: draft-ietf-mmusic-ice-12: questions on ICE's local preference and rfc 3484's source address selection algorithm X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org These are some good questions. To be frank I was not familiar with RFC3484 until you pointed it out. It is very much solving the same kind of problem, but it makes a much different assumption. It assumes that the source selection algorithm has the destination address as an input. In ICE, we don't know the destination until after we've signaled the priority for the source addresses. Consequently, it was non-obvious to me how to just reference RFC 3484 or use any of its algorithms without some major tweaking. Indeed I would go so far as to say that RFC 3484 is almost inapplicable because of this difference. Perhaps you can suggest some words that do make sense? Thanks, Jonathan R. Jean-Francois Mule wrote: > Jonathan, > > In section 5.2 of ice-12, the second paragraph on page 19 has some > considerations on the selection of (local) preferences based on the IP > address family (Ipv6, IPv4). > While ice defines an application level mechanisms for choosing > between candidates for valid connectivity, RFC 3484 defines a default > source/destination address selection algorithm for IPv6 nodes (in cases > where there is no guidance provided by the application layer). > > --- Questions: > 1. Would it be appropriate to somehow link the precedence of the policy > table in 3484 with the local preference of ICE when both IPv4 and IPv6 > candidates are present, and a policy table does exist? > What got me to go back to 3484 is the second sentence of that second > paragraph on page 19 of ice-12 on how connectivity checks over IPv6 > might be preferred over IPv4 ones; see section 10.3 of 3484 - there > seems to be some parallels at a first sight. > > 2. Would it be useful to mention RFC 3484 in ICE and discuss how it > may/should be used in dual-stack hosts to derive the local preference of > particular candidate? > > Jean-Francois. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 14:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedGI-00012z-D6; Mon, 30 Oct 2006 14:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedGH-00012m-Bi for mmusic@ietf.org; Mon, 30 Oct 2006 14:57:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GedGB-0001mr-S8 for mmusic@ietf.org; Mon, 30 Oct 2006 14:57:33 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 11:57:27 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UJvRhL019657; Mon, 30 Oct 2006 11:57:27 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9UJv5P1017219; Mon, 30 Oct 2006 11:57:26 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:57:22 -0500 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:57:22 -0500 Message-ID: <45465922.2040001@cisco.com> Date: Mon, 30 Oct 2006 14:57:22 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-ice-12 References: <20061030022818.0101B1CC22@delta.rtfm.com> In-Reply-To: <20061030022818.0101B1CC22@delta.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 19:57:22.0608 (UTC) FILETIME=[9D31C300:01C6FC5D] DKIM-Signature: a=rsa-sha1; q=dns; l=2192; t=1162238247; x=1163102247; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Comments=20on=20draft-ietf-mmusic-ice-12; X=v=3Dcisco.com=3B=20h=3DgnZ6RAdkNulPSiHLvbTwnn/9Z4Y=3D; b=XUbGR4XSwHgO0Lo8hsBYbGj5idT8Ysc8oWRu9/JcQ6XGU8pDJkY4PHnxwxTJXofV3HPhGr4L oJshdehQKXyiNLtURLXk7sDC9OcIvCmHMY4+PBEC2WfYZ8Rkxmi0JjjS; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for the read and your comments. Responses below. EKR wrote: > $Id: draft-ietf-mmusic-ice-12-rev.txt,v 1.1 2006/10/30 02:31:02 ekr Exp $ > > A few notes on ICE-12. > > As I understand the USE-CANDIDATE flag, there are two ways things > can happen. > > 1. The controlling agent (henceforth CoA) can include the > USE-CANDIDATE flag in one (or more) of his initial periodic checks > and when that check concludes the component is automatically > done. Right. > > 2. The CoA can complete (or give up on) all of his periodic checks > and then do a *new* check on one of the components that succeeded. Right. > > Do I have this correct? If so, I think that you should be a little > clearer earlier on that one may receive duplicate checks. I would > advise doing this by adding the following to the end of S 9, para 2. > "Note, an implementation may choose to complete all possible checks > and then choose the best one (given some metric). In this case, > it will send initial checks without the USE-CANDIDATE flag and > then a second check on a single candidate using the USE-CANDIDATE > flag." Added. I think its more than a note; that first may is a MAY. > > > As I understand it, candidates should only be "selected" once checks > have succeeded in the direction you want to send. I.e., if you're not > the CoA and the first request you see contains a USE-CANDIDATE flag, > you do a triggered check and only select the candidate upon receipt of > the response. Is this right? Right. > That's what Figure 10 seems to show. If > it is, Figure 4 is kind of misleading. I guess it's supposed to show > approach (1) above, but... Right. I clarified that in the text. > > Figure 10 should indicate that msg 10 has the USE-CANDIDATE flag set. done. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 15:34:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedqE-0003l8-Pb; Mon, 30 Oct 2006 15:34:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedqD-0003kI-GY for mmusic@ietf.org; Mon, 30 Oct 2006 15:34:41 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gedq7-0005JY-Ll for mmusic@ietf.org; Mon, 30 Oct 2006 15:34:41 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E793D36F; Mon, 30 Oct 2006 21:34:32 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 21:34:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Mon, 30 Oct 2006 21:34:31 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940454924E@esealmw113.eemea.ericsson.se> In-Reply-To: <453E15B3.3020901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Thread-Index: Acb3cLrOWMfPks5VSrOLb0CoLeKiewE70JLA From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 30 Oct 2006 20:34:33.0076 (UTC) FILETIME=[CEA82B40:01C6FC62] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Kevin Johns , IETF MMUSIC WG , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >>And, as I asked before, for how long would you keep re-transmitting=20 >>the 18x, if there is no STUN request coming to=20 >>"acknowledge" it (you cannot assume there will be a STUN request, e.g. in case=20 >>there is some NAT/gate/GW in the path which will not pass it)? I don't >>think we can use words as "send a few re-transmits", or "re-transmit for=20 >>a while", in a standards specification. >=20 >It doesn't say that. It says to use the retransmit intervals=20 >and timers as defined in RFC 3262, but that the=20 >retransmissions stop when you receive a STUN request or a=20 >PRACK (as opposed to just a PRACK with rfc3262). I think that also the following 3262 deviations should be clarified (eventhough one may consider them obvious), in addition to the text saying that this 18x can not be used for offer/answer purpose: 1. If the UAC supports 100rel, the UAS MUST use it, and not use the STUN request as acknowledgement. Ie the re-transmisson will not cease if a STUN request is received before the PRACK. 2. If 100rel is not used, and there is no STUN request before the re-transmission timeout (64*T1), the UAS shall not reject the INVITE just because the 18x "failed". 3. The RFC3262 rule, saying that the first reliable 18x must be acknowledged before futher reliable 18xs are sent, does not apply. 4. When 200 OK is sent, the re-transmission of 18x (if still ongoing) is ceased. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 15:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gee1M-0004TO-7H; Mon, 30 Oct 2006 15:46:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gee1L-0004TF-1R for mmusic@ietf.org; Mon, 30 Oct 2006 15:46:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gee1G-0006HJ-RK for mmusic@ietf.org; Mon, 30 Oct 2006 15:46:11 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2006 15:46:07 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UKk6Yi029777; Mon, 30 Oct 2006 15:46:06 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9UKk6YL019429; Mon, 30 Oct 2006 15:46:06 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 15:46:06 -0500 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 15:46:05 -0500 Message-ID: <4546648D.7000808@cisco.com> Date: Mon, 30 Oct 2006 15:46:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Rosenberg Subject: Re: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer References: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nortel.com> <200610301810.k9UIAPI09611@ihmail.ih.lucent.com> In-Reply-To: <200610301810.k9UIAPI09611@ihmail.ih.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 20:46:05.0640 (UTC) FILETIME=[6B750C80:01C6FC64] DKIM-Signature: a=rsa-sha1; q=dns; l=4004; t=1162241166; x=1163105166; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20an=20Offer |To:John=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DHlu7vdT84QhazwBfLUUwwAIunXo=3D; b=aH5vPLHFYsGXNIYqUbsfNdjc4sQrfASGTGVnsYuNneD9LMkM4gSl1mNjhBsTmo0fWBCbqKZa b27u9PcuzwNVF9Dpju5vedkoLu9YDLz+jgsrZR51jp4+963u08SNjiGJ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Francois Audet , mmusic@ietf.org, jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org It most certainly is mandating a b2bua in the middle. As folks have pointed out, and I concur, it makes more sense for a local network to tell its UA what DSCP to use. SIP negotiation is wrong for that, since it's between endpoints. Thus, for the mechanism to be useful, it requires that: 1. the SIP provider is the same as the access provider, 2. the SIP provider runs a b2bua to modify SIP/SDP signaling I also see no reason why the DSCP value would be dynamic (i.e., it won't change on a call-by-call basis). It thus seems much more appropraite to me to use whatever the configuration mechanism is for the phone. Thanks, Jonathan R. John Rosenberg wrote: > I don't think anything is mandating a B2BUA in the middle. In the DISA > case there *is* a B2BUA in the middle and the requirement is that it > have a way to tell the endpoint what DSCP value to use. The mechanism > James is proposing fits the bill in that situation, and would also be > useful in an IMS network to allow a CSCF or App Server to exert control > over the DSCP values and thus the Per Hop behaviors that they imply. > > John > > At 12:04 PM 10/30/2006, Francois Audet wrote: > >Even a better reason then to use the config-framework instead of > >mandating > >a B2BUA in the middle pretending to be the other end. > > > >> -----Original Message----- > >> From: John Rosenberg [mailto:jrrosenberg@lucent.com] > >> Sent: Monday, October 30, 2006 9:42 AM > >> To: mmusic@ietf.org > >> Cc: jmpolk@email.cisco.com > >> Subject: RE: [MMUSIC] New ID on conveying a DSCP > >> marking/remarking in an Offer > >> > >> Dan Wing wrote: > >> > >> > >> >I agree with Francois -- I need to understand the justification for > >> >this functionality. This seems only germain to each local > >> network and > >> >I don't see the value in signaling this in SDP. > >> > >> I think the justification here is to allow a call > >> controller/session manager to exert influence over the > >> endpoints' behavior in choosing the DSCP value to use for a > >> bearer stream. For example in the US, DISA has some > >> requirements for their Defense Information System Network > >> that specify that a call controller must instruct served CPE > >> regarding what DSCP value to use in the bearer based on the > >> precedence level that the user requests - this involves an > >> authentication and authorization to use that level in the > >> call controller (a B2BUA). > >> > >> While it's interesting, and potentially useful, for one EP to > >> tell another "Hey, I'm going to use DSCP 41" I think that > >> view of this draft misses its point, and that the real power > >> is allowing a call controller/session manager to drive the > >> endpoint's behavior. This allows for all kinds of good things > >> - like authorization - to come into play w.r.t. use of > >> particular DSCP values and the PHBs they imply. > >> > >> In cases when the bearer streams cross network boundaries, I > >> would expect Session Boarder Controllers to rewrite the SDP > >> and modify the DSCP attribute as appropriate per policy - > >> similar to how STPs that interconnect ISUP networks modify > >> IAMs transmitted between networks. > >> > >> John Rosenberg > >> Lucent Technologies > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 16:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeGB-0005T6-B1; Mon, 30 Oct 2006 16:01:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeGA-0005T1-5Q for mmusic@ietf.org; Mon, 30 Oct 2006 16:01:30 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeG6-0007kA-T0 for mmusic@ietf.org; Mon, 30 Oct 2006 16:01:30 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id k9UL0MO0003187; Mon, 30 Oct 2006 15:00:23 -0600 (CST) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.234.25]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k9UL0KI00871; Mon, 30 Oct 2006 15:00:20 -0600 (CST) Message-Id: <200610302100.k9UL0KI00871@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Oct 2006 15:00:18 -0600 To: Jonathan Rosenberg From: John Rosenberg Subject: Re: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <4546648D.7000808@cisco.com> References: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nortel.com> <200610301810.k9UIAPI09611@ihmail.ih.lucent.com> <4546648D.7000808@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Francois Audet , mmusic@ietf.org, jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan - At 02:46 PM 10/30/2006, Jonathan Rosenberg wrote: >I also see no reason why the DSCP value would be dynamic (i.e., it won't >change on a call-by-call basis). It thus seems much more appropraite to >me to use whatever the configuration mechanism is for the phone. In the DISA scenario, it absolutely can change on a call by call basis. In DISA's requirements, the bearer DSCP to use is determined based on the precedence level requested for the call, which can change for each call a user makes. The Local Call Controller serving the user's endpoint authenticates and determines whether the requested precedence level is authorized for that user. It then must instruct the endpoint what DSCP value to use for the bearer stream(s) associated with that call. James' draft allows for exactly the necessary behavior described above. I also believe that it does not mandate a B2BUA in the middle. If one is not there then it's an endpoint to endpoint discussion (not negotiation) regarding the bearer DSCP that they intend to use. John _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 16:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeSd-0004yc-BN; Mon, 30 Oct 2006 16:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeSc-0004xb-6t for mmusic@ietf.org; Mon, 30 Oct 2006 16:14:22 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeSY-0000Tj-RY for mmusic@ietf.org; Mon, 30 Oct 2006 16:14:22 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9ULEDj13263; Mon, 30 Oct 2006 16:14:13 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Mon, 30 Oct 2006 15:14:07 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC98B82@zrc2hxm0.corp.nortel.com> In-Reply-To: <200610302100.k9UL0KI00871@ihmail.ih.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Thread-Index: Acb8ZpdKCysrRGS6Q3+h0pkfDLZbmAAAZoQA From: "Francois Audet" To: "John Rosenberg" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mmusic@ietf.org, jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Well, sure, it can be dynamic based on precedence level. You could have a static rule that assigns a DSCP codepoint to different precedence level. > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com]=20 > Sent: Monday, October 30, 2006 1:00 PM > To: Jonathan Rosenberg > Cc: Audet, Francois (SC100:3055); mmusic@ietf.org;=20 > jmpolk@email.cisco.com > Subject: Re: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer >=20 > Jonathan - >=20 > At 02:46 PM 10/30/2006, Jonathan Rosenberg wrote: >=20 > >I also see no reason why the DSCP value would be dynamic=20 > (i.e., it won't >change on a call-by-call basis). It thus=20 > seems much more appropraite to >me to use whatever the=20 > configuration mechanism is for the phone. >=20 > In the DISA scenario, it absolutely can change on a call by=20 > call basis. In DISA's requirements, the bearer DSCP to use is=20 > determined based on the precedence level requested for the=20 > call, which can change for each call a user makes. The Local=20 > Call Controller serving the user's endpoint authenticates and=20 > determines whether the requested precedence level is=20 > authorized for that user. It then must instruct the endpoint=20 > what DSCP value to use for the bearer stream(s) associated=20 > with that call. >=20 > James' draft allows for exactly the necessary behavior=20 > described above. >=20 > I also believe that it does not mandate a B2BUA in the=20 > middle. If one is not there then it's an endpoint to endpoint=20 > discussion (not > negotiation) regarding the bearer DSCP that they intend to use. >=20 > John >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 16:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7y-0002Hc-UC; Mon, 30 Oct 2006 16:57:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7w-0002FP-Pv for mmusic@ietf.org; Mon, 30 Oct 2006 16:57:04 -0500 Received: from smtp152.iad.emailsrvr.com ([207.97.245.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geewn-00045K-4w for mmusic@ietf.org; Mon, 30 Oct 2006 16:45:42 -0500 Received: from counterpath.com (webmail8.r4.iad.mlsrvr.com [192.168.1.83]) by relay5.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id D56F017459; Mon, 30 Oct 2006 16:45:32 -0500 (EST) Received: from ([10.238.10.71]) (proxying for 24.207.97.255) (Webmail authenticated user derek@counterpath.com, derek@counterpath.com); by webmail.counterpath.com with HTTP; Mon, 30 Oct 2006 16:45:32 -0500 (EST) Message-ID: <43209.10.238.10.71.1162244732.webmail@10.238.10.71> Date: Mon, 30 Oct 2006 16:45:32 -0500 (EST) Subject: Re: [MMUSIC] ICE-12, SBCs and hotel ALGs From: derek@counterpath.com To: "Jonathan Rosenberg" X-Mailer: Webmail.us v5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: OK Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: mmusic@ietf.org, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: derek@counterpath.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org See inline. Jonathan Rosenberg said: >=20 >=20 > derek@counterpath.com wrote: >=20 >> The consensus that we reached on the ICE calls was that a user agent >> could ignore the m/c line if it couldn't validated by ICE. This is >> needed to deal with misbehaving ALG devices, which are an existing >> deployment issue. These devices are often not controlled by the >> network operator, and can be seen as morally equivalent to a >> misbehaving NAT from the ice requirements standpoint. >=20 > The problem I ran into is that this is the "right" thing to do for thos= e > nasty ALGs, but is exactly the wrong thing to do for an SBC thats on th= e > path. THe UA cannot tell which is which. So, when an offer shows up wit= h > an m/c-line which doesn't match a candidate, and it doesn't validate, i= s > the situation that: >=20 > 1. there is an SBC on the path that is ice-unaware, and it blocks > non-RTP packets from flowing >=20 > 2. there is an ALG on the path that is broken and the m/c-line it > provided doesnt work >=20 > You cannot differentiate these two cases with ICE. If you ignore the > m/c-line assuming its case (2), and in reality its case (1), the call > will fail. >=20 > So, the mechanism that can in fact make things more reliable here is to > deal with the ALG problem with SIP over TLS, leaving only case 1. Then, > in case 1, you do what I described in ICE-12 - use the m/c-line and > abort ICE processing. Consider a network where the SBC is not important for anything except NAT= traversal. It is desirable to get rid of the SBC in this network(esp. w= hen building a new network) and use a pure TURN/ICE approach. The TURN/IC= E approach should result in less realed traffic and will also allow easy = deployment of SIP-identity and other technololgies that require that the = message body remain intact.=20 If ICE doesn't deal with problem ALG devices TLS is required. If TLS isn'= t used an SBC will be required to deal with the hotel ALG scenario, and t= his SBC will have to be ICE aware for TURN to be used at the same time. I= f this network requires TLS or SBCs it will have a higher cost(initial an= d recurring) than the TURN/ICE approach. Also, an ICE-aware SBC will be r= equired for TURN to deployed.=20 Another consideration is the work in P2P-SIP. P2P-SIP will most likely us= e ICE with some nodes acting as relay devices. So, to get around misbeha= ving ALG devices P2P-sip would also require an encrypted channel or SBC l= ike functionality at the relay node. >=20 >> >> A large part of this debate was around whether SBC type devices >> needed to be ICE aware, or if ICE should be designed so that it >> deosn't "work around" existing SBCs. I don't know if we settled that >> debate; consensus seemd to be that it is easy for an SBC vendor to >> disable ice. Changing ice so that the m/c line MUST match a candidate >> assumes that the requirement is that ice not bypass existing SBC >> devices. This includes the motivation that existing SBC devices do >> not allow ice checks to proceed. We need to resolve this SBC/ICE >> requirments debate if we are ever going to reach consensus on ICE. >=20 > THere are two cases to worry about - ICE aware and ICE-unaware SBCs. Fo= r > ICE-aware, there are lots of things an SBC can do once it knows ICE is > running. THis was really not the case we were worried about. Its an > ICE-unaware SBC. >=20 > I believe the requirement is that calls do not fail in the presence of > an ICE-unaware SBC. That is the only requirement I think we should > strive to meet. Some folks wanted the requirement to get around the > ICE-unaware SBC if a better path was available. I disagree with that an= d > I think it is a path fraught with peril. You simply don't know how the > SBC is configured or working and you should not guess your way around > it. An SBC is a UA, and when one is in the way, its like talking to an > ICE-unaware UA. We should abort ICE. Consider an existing network where the SBC is providing NAT traversal whe= n necessary. This is usually inefficient and a lot of traffic is relayed = unecessarily. If this network is a blood-simple SIP network built on the = internet it will probably: 1. Signal SIP over UDP 2. Use SBCs for NAT traversal, which are not ICE-aware. 3. Have PSTN-SIP gateways that are not ICE-aware. 4. Does not have control over all network elements, so will suffer from h= otel ALGs. To optimize traffic, the network has be upgraded to: 1. Have PSTN-SIP gateways that are ICE-aware. 2. Have SBCs that are ICE-aware. 3. Deploy endpoints that are ICE-aware. I agree that deploying ICE in the network before the upgrade could be har= mful if the network will tear down calls that do not support the media pa= th. However, a network that does not have this property will benefit fro= m 3. There are no issues with ice when a network has 2 and 3. I still think the core issue is whether: 1) ICE should not 'work around' devices that change the m/c line so it ca= n be deployed in noetworks that rely on traffic following a certain path = without a device being ICE-aware. 2) Networks should disable ICE if it can cause problems. I'm strongly in favour of 2. ICE seems useless in type 1 networks, as IC= E processing will not occur unless the network has detected that two ICE-= aware endpoints have reach to each other before the offer reaches the ICE= -unaware SBC, or if the devices are not NATd. Of course, ICE is accompli= shing little if the devices were not behind a NAT. I think another reason for 2 is that it is likely that even if ICE contin= ues to require that the m/c line match a candidate, some ice implementati= ons will *not* follow this mandate as they may have been tweaked for the = TURN/ICE deployment described above. Deploying an ICE endpoint which always attempts ICE in a network which is= not prepared for ICE will at worst result in dropped calls for that endp= oint. This should be a self-correcting problem, as the user will either = disable ICE, or change the ICE behaviour if we go with the dual operating= mode approach. >=20 >=20 >> >> It seems to me that a way forward is to have two operating modes for >> ice; one which is designed to honour existing middle boxes in a >> deployment, and one which just tries to establish connectivity. >=20 > I really noodled on this for a while. Given the unpredictability of SBC > and ALG behavior, I do not think you can write an algorithm which will > work. The problem is that you just don't know what the SBC behavior is > going to be. I don't think we should write an algorithm, and as you say it would be ex= tremely difficult if not impossible. This would have to be a configuratio= n parameter on the endpoint. =20 >=20 > -Jonathan R. >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-271= 1 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 17:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg5N-0003cm-Fr; Mon, 30 Oct 2006 17:58:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg5M-0003ch-JQ for mmusic@ietf.org; Mon, 30 Oct 2006 17:58:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geg57-0008Qf-OC for mmusic@ietf.org; Mon, 30 Oct 2006 17:58:28 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 14:58:12 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UMw9HW022180; Mon, 30 Oct 2006 14:58:09 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9UMw8W4016431; Mon, 30 Oct 2006 14:58:08 -0800 (PST) From: "Dan Wing" To: "'Joerg Ott'" Date: Mon, 30 Oct 2006 14:58:08 -0800 Keywords: direct-to-dwing Message-ID: <564501c6fc76$de9c8d20$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45431294.8060507@netlab.hut.fi> Thread-Index: Acb6ac+20tzo+Eq7SjOMGB6Vbm4jqgAPyFuw DKIM-Signature: a=rsa-sha1; q=dns; l=5051; t=1162249092; x=1163113092; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20alternate=20RTP=20profiles=20in=20SDP=20offer/answer; X=v=3Dcisco.com=3B=20h=3DZD7nVjcVFat1K54Z7ztdU6OfYko=3D; b=fE4OSsEPdF9GvVMjeZMDAPo36An3wX2GM/ypUtuDUOMGHNOCTtkSnO1DzOa7XLxafSrgeTd+ J2ZyFMV8B+idpgNUp3RqjfDFBMRFXq4lrWg0vlec/wNIKZsqUA3MZCJ7; Authentication-Results: sj-dkim-3.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, 'Francois Audet' , 'Flemming Andreasen' , 'Joerg Ott' Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > what you claim to be a problem here has been removed from the SAVPF > spec for this very reason. -08 had -- by accident -- some remnants > in that were taken out in -09. Should there be an oversight left in, > then please be precise of what you mean and we will be happy to > fix this. Thanks. I'm sorry for not noticing, until now, this AVT document was normatively specifying SDP behavior for SAVPF. Here are my comments about the MUSTs in the document that may interfere with the I-Ds on best-effort SRTP: ----- 1. Section 3.3.1 says: If supported, the answerer SHOULD prefer a secure profile over non-secure ones. and later says: If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. Based on -savpf-09's defintion of "media session", this means the entire RFC3388 group has to be rejected. This means an RFC3388-grouped offer with SAVPF and SAVP, sent to an answerer that understands RFC3388 and SAVP (but the answerer doesn't implement SAVPF), would have to be rejected by the answerer. I don't believe this is your intent. I suggest deleting: If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. otherwise, we'll not be able to use SDP grouping. ----- 2. Section 3.3.2: To offer two or more alternative RTP profiles for a particular media stream, the SDP description MUST contain exactly one m= line for this media stream for each profile and all the same transport address (IP address and port number). This requirement makes sense if you're using grouping (RFC3388), so prefixing this with "If using RFC3388, ..." seems suitable. However, note that section 7.5.3 RFC3388 explitictly prohibits using the same transport address. ----- 3. Section 3.3.4, titled "Describing Alternative Session Profiles", which I assume is talking about SDP (which describes sessions): SAVP and SAVPF entities MAY be mixed in the same RTP session (see also section 4) and so MAY AVP and AVPF entities. Other combinations -- i.e. between secure and insecure profiles -- in the same RTP session are incompatible and MUST NOT be used together. The MUST NOT in that last sentence prohibits using RFC3388 grouping to mix AVPF and SAVPF. That MUST NOT should be removed from -savpf, as it is a stronger requirement than SAVP's own registration (RFC3711), which is counter to a sentence in draft-ietf-avt-profile-savpf's security considerations section which says that draft-ietf-avt-profile-savpf doesn't increase or decrease security compared to SAVP itself. 4. Also, in that paragraph, I believe the first sentence should read: SAVP and SAVPF entities MAY be mixed in the same media session ^^^^^ (see also section 4) and so MAY AVP and AVPF entities. ----- 5. Example 4: A client inquires a media description from a server using DESCRIBE and obtains a static SDP description without any keying parameters but the media description shows that both secure and non-secure media sessions using (S)AVPF are available. However, the SDP is: v=0 o=alice 3203093520 3203093520 IN IP4 movies.example.com s=Media with feedback t=0 0 c=IN IP4 0.0.0.0 m=video 49170 RTP/SAVPF 96 a=rtpmap:96 H263-2000/90000 a=rtcp-fb:96 nack m=video 49172 RTP/AVPF 96 a=rtpmap:96 H263-2000/90000 a=rtcp-fb:96 nack which isn't for one video stream but rather is for two separate video streams -- one encrypted, the other unencrypted. I see that the port numbers were modified between -07 and -09 (likely a result of my complaints about -07), but the text introducing the example wasn't changed. Is it useful to just show SAVPF in the SDP, and not show alternative grouping? ----- Editorial nits: Section 3.3.1, OLD: setting the port number in the respect m= line to 0. NEW: setting the port number in the respective m= line to 0. ^^^ Section 5: OLD: The SAVP profile does not add, nor take away, any security services compared to SAVP. NEW: The SAVPF profile does not add, nor take away, ^^^^^ any security services compared to SAVP. > From the mere authorship of the spec, it should become clear that > there is a close interaction with what MMUSIC does. > > I must admit that I am somehwat surprised and not particularly > amused about your seocnd-guessing below. Please accept my apologies for not reviewing this document until now. I hope my suggested changes improve the document and assist with its forward progress. I do hope there is time on the MMUSIC agenda to discuss grouping and its merits for negotiating RTP profiles along with the other two approaches that are on the MMUSIC agenda. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 18:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GegKQ-000731-4o; Mon, 30 Oct 2006 18:14:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GegKO-00072s-Oh for mmusic@ietf.org; Mon, 30 Oct 2006 18:14:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GegKN-0002Pv-FG for mmusic@ietf.org; Mon, 30 Oct 2006 18:14:00 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2006 15:13:59 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UNDwnQ019784; Mon, 30 Oct 2006 15:13:59 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9UNDwW4029080; Mon, 30 Oct 2006 15:13:58 -0800 (PST) From: "Dan Wing" To: "'John Rosenberg'" , "'Jonathan Rosenberg'" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Mon, 30 Oct 2006 15:13:58 -0800 Message-ID: <564b01c6fc79$146cb9f0$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <200610302100.k9UL0KI00871@ihmail.ih.lucent.com> Thread-Index: Acb8bS1nKNo9xAllT+OJlhQ0wMoTxwACe6nQ DKIM-Signature: a=rsa-sha1; q=dns; l=1741; t=1162250039; x=1163114039; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20an=20Offer; X=v=3Dcisco.com=3B=20h=3DCAsevRE272Uuu4ItVMtbVXZBiFw=3D; b=pdDqPTfro0n2BK3NQUsLmyy0oLdder8K+oWbQD10rgRoBsrzNOEC6B88GA7ki4hxGdnZgc1g 2scozWRstvDXj3qb8VG6r4jeB/TewZ6si5FhyODN+1RXyoGWgC9AdfyU; Authentication-Results: sj-dkim-4.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Francois Audet' , mmusic@ietf.org, jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > >I also see no reason why the DSCP value would be dynamic > >(i.e., it won't > >change on a call-by-call basis). It thus seems much more > >appropraite to > >me to use whatever the configuration mechanism is for the phone. > > In the DISA scenario, it absolutely can change on a call by call > basis. In DISA's requirements, the bearer DSCP to use is determined > based on the precedence level requested for the call, which can > change for each call a user makes. The Local Call Controller serving > the user's endpoint authenticates and determines whether the > requested precedence level is authorized for that user. It then must > instruct the endpoint what DSCP value to use for the bearer stream(s) > associated with that call. If you really want to enable such communication without a B2BUA, tacking on a new SIP header seems better than messing with the SDP. > James' draft allows for exactly the necessary behavior > described above. > > I also believe that it does not mandate a B2BUA in the middle. If one > is not there then it's an endpoint to endpoint discussion (not > negotiation) regarding the bearer DSCP that they intend to use. If my network authorized me to use 0110, and your network authorized you to use 1001, and there isn't an SBC(*) between us, it seems Things Will Break. I'll send you an invitation and indicate I am using 0110, and you'll either reject the session entirely (which is nasty) or you'll ignore the DSCP attribute and use the authorized DSCP value. When your media packet gets into my network, 1001 might be my scavanger class. (*) It has to be an SBC, not just a B2BUA; the media packets need to have their DSCP bits changed. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 20:14:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiCG-0004tI-Dk; Mon, 30 Oct 2006 20:13:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiCF-0004sy-65 for mmusic@ietf.org; Mon, 30 Oct 2006 20:13:43 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiCC-0005xl-G5 for mmusic@ietf.org; Mon, 30 Oct 2006 20:13:43 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2006 17:13:40 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9V1DdId013084; Mon, 30 Oct 2006 17:13:39 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9V1DdW4018609; Mon, 30 Oct 2006 17:13:39 -0800 (PST) From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Elwell, John'" , "'Francois Audet'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Mon, 30 Oct 2006 17:13:39 -0800 Keywords: direct-to-dwing Message-ID: <57bc01c6fc89$cc8f99c0$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <006001c6fbc9$2530a0e0$0500a8c0@acmepacket.com> Thread-Index: Acb7O2c3PZUDoigIQoirauJsm96rFQAjOO/gADAghZA= DKIM-Signature: a=rsa-sha1; q=dns; l=8933; t=1162257219; x=1163121219; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20RE=3A=20I-D=20ACTION=3Adraft-kaplan-mmusic-best-effor t-srtp-01.txt; X=v=3Dcisco.com=3B=20h=3DxBX4iA4VQuhdkcexVU8I2tdVYaA=3D; b=agcWkpPe8yncFYm10AIV+1LnplPfVRHPFITpUAHBpJuRiz7u8tdM7ZKvJ+RAeEUqXYQYW5dF t60eA06UkcXm6ELH6Lu/OUIp7Z6aExV0cY6UGE+ORASzsqyBN4Ee0/Nn; Authentication-Results: sj-dkim-2.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > I wouldn't think zrtp would need port-mapping. Security Descriptions probably doesn't need it, either -- it can't do early media unless we resurrect draft-wing-mmusic-sdes-early-media-00.txt or some idea like it. > They're supposed to handshake in clear RTP (or maybe rtcp > depending on how the argument in AVT ends up). So they should > be able to use the m= line ones. I would expect > that any media-plane key exchange mechanism would be designed > such that it gracefully fails if either side doesn't support > it, no? You only want to fail gracefully if your security policy allows RTP, and your signaling indicates the remote party only supports RTP. Otherwise, an attacker could interfere with your media-plane key exchange so that you can only run RTP. > They may need/want an attribute so the offerer can tell the > answerer to try it, or other info like a fingerprint, but > port-mapping wouldn't be one of them, would it? Currently zrtp defines its own a=zrtp attribute; it might make sense to use the portmapping attribute to mean the same thing ("I can do ZRTP; can you?"). -d > -hadriel > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Sunday, October 29, 2006 4:20 AM > > To: Dan Wing; 'Francois Audet'; 'Hadriel Kaplan'; mmusic@ietf.org > > Subject: RE: [MMUSIC] RE: I-D > ACTION:draft-kaplan-mmusic-best-effort-srtp- > > 01.txt > > > > Dan, > > > > It would probably need to be something like: > > a=srtp key-mgmt:0=96,18=97 crypto:0=98,18=99 > fingerprint:0=100,18=101 > > zrtp:0=102,18=103 > > > > John > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: 27 October 2006 18:46 > > > To: Elwell, John; 'Francois Audet'; 'Hadriel Kaplan'; > mmusic@ietf.org > > > Subject: RE: [MMUSIC] RE: I-D > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > And another for srtp-dtls and another for zrtp? > > > > > > Maybe there is a more efficient way to combine these. > Perhaps only > > > including a=srtp for those key exchange mechanisms which can allow > > > decrypting SRTP media that arrives prior to the SDP answer? > > > Or perhaps > > > specifying the payload types in such a way that they're > > > assigned to each of > > > the a= key management mechanisms understood by the answerer. > > > As a possible > > > strawman for this last idea: > > > > > > m=blahblah > > > a=key-mgmt blahblah > > > a=crypto blahblah > > > a=fingerprint blahblah (used by srtp-dtls) > > > a=zrtp > > > a=srtp key-mgmt 40 crypto 41 fingerprint 42 zrtp 43 > > > > > > -d > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Thursday, October 26, 2006 11:07 PM > > > > To: Francois Audet; Hadriel Kaplan; mmusic@ietf.org > > > > Subject: RE: [MMUSIC] RE: I-D > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > Francois, > > > > > > > > Yes, that would work. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > Sent: 27 October 2006 01:22 > > > > > To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org > > > > > Subject: RE: [MMUSIC] RE: I-D > > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > > > Maybe we could use one a=srtp line for crypto, and > another one for > > > > > kmgmt? > > > > > > > > > > (i.e., have a different PT for each?) > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > > Sent: Thursday, October 26, 2006 5:56 AM > > > > > > To: Hadriel Kaplan; Audet, Francois (SC100:3055); > > > mmusic@ietf.org > > > > > > Subject: [MMUSIC] RE: I-D > > > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > > > > > Hadriel, Francois, > > > > > > > > > > > > Thanks for working on this update. Just one point. If both > > > > > > SDescriptions and MIKEY are offered (inclusion of a=crypto > > > > > > and a=key-mgmt lines) and a different payload type is also > > > > > > indicated for SRTP, this payload type would apply > whether the > > > > > > SDescription-derived key or the MIKEY-derived key is used. > > > > > > So until the SDP answer arrives, it would still not be > > > > > > possible to render SRTP. Of course, in the case of > > > > > > SDescriptions it is not possible anyway, but in the case of > > > > > > certain MIKEY options it ought to be possible. Unfortunately > > > > > > to resolve this we would need somewhat more complex > syntax in > > > > > > the a=srtp line. > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Internet-Drafts@ietf.org > > > [mailto:Internet-Drafts@ietf.org] > > > > > > > Sent: 25 October 2006 20:50 > > > > > > > To: i-d-announce@ietf.org > > > > > > > Subject: I-D > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts > > > > > > > directories. > > > > > > > > > > > > > > > > > > > > > Title : Session Description Protocol (SDP) > > > > > > > Offer/Answer Negotiation For Best-Effort Secure Real-Time > > > > > Transport > > > > > > > Protocol > > > > > > > Author(s) : F. Audet, H. Kaplan > > > > > > > Filename : > > > > draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > > > > Pages : 17 > > > > > > > Date : 2006-10-25 > > > > > > > > > > > > > > This document defines the requirements and a proposed > > > > > solution for > > > > > > > an SDP Offer/Answer exchange model for negotiating > > > > > > best-effort SRTP > > > > > > > keys, i.e., in a backward-compatible manner with > > > > > > non-SRTP devices. > > > > > > > The proposed solution is a trivial > interpretation of the > > > > > > usage of > > > > > > > the profile and the usage of SDP indication of [sdesc] > > > > > > and [kmgmt]. > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e > > > > > > > ffort-srtp-01.txt > > > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > > message to > > > > > > > i-d-announce-request@ietf.org with the word unsubscribe in > > > > > > the body of > > > > > > > the message. > > > > > > > You can also visit > > > > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > > > > to change your subscription settings. > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. > > > > > Login with the > > > > > > > username "anonymous" and a password of your e-mail > > > > address. After > > > > > > > logging in, type "cd internet-drafts" and then "get > > > > > > > draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > > http://www.ietf.org/shadow.html or > > > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > > > Send a message to: > > > > > > > mailserv@ietf.org. > > > > > > > In the body type: > > > > > > > "FILE > > > > > > > > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-01.txt". > > > > > > > > > > > > > > NOTE: The mail server at ietf.org can return > the document > in > > > > > > > MIME-encoded form by using the "mpack" utility. > > > > To use this > > > > > > > feature, insert the command "ENCODING mime" > > > > before the "FILE" > > > > > > > command. To decode the response(s), you will > > > > need "munpack" or > > > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > > mail readers > > > > > > > exhibit different behavior, especially when dealing with > > > > > > > "multipart" MIME messages (i.e. documents which > > > > have been split > > > > > > > up into multiple messages), so check your local > > > > documentation on > > > > > > > how to manipulate these messages. > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > > > mail reader > > > > > > > implementation to automatically retrieve the ASCII > > > > version of the > > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mmusic mailing list > > > > > > mmusic@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 20:34:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiWJ-0000Jy-0E; Mon, 30 Oct 2006 20:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiWH-0000E0-2b for mmusic@ietf.org; Mon, 30 Oct 2006 20:34:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiWF-0001bn-ON for mmusic@ietf.org; Mon, 30 Oct 2006 20:34:25 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2006 17:34:23 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9V1YNOh003344; Mon, 30 Oct 2006 17:34:23 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9V1YNAo006105; Mon, 30 Oct 2006 17:34:23 -0800 (PST) From: "Dan Wing" To: "'John Rosenberg'" , Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Mon, 30 Oct 2006 17:34:23 -0800 Message-ID: <581201c6fc8c$b1a57730$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> Thread-Index: Acb8TXOsYqP204VgSkiNv5jx3b4IUQAPZm1A DKIM-Signature: a=rsa-sha1; q=dns; l=3311; t=1162258463; x=1163122463; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20an=20Offer; X=v=3Dcisco.com=3B=20h=3DCAsevRE272Uuu4ItVMtbVXZBiFw=3D; b=EIAI6NelEnYy1u16NviOjgtfL8szzXZT/pEz2s+OcopBQc1N2B6ozB2WMfWtu8RgVW40+MOM OjjqBwdlqakuwolYGOhgEGS6v7EvpCOmWFo8msD1+3nFEf/yt38GcDhd; Authentication-Results: sj-dkim-2.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > >I agree with Francois -- I need to understand the justification for > >this functionality. This seems only germain to each local network > >and I don't see the value in signaling this in SDP. > > I think the justification here is to allow a call controller/session > manager to exert influence over the endpoints' behavior in choosing > the DSCP value to use for a bearer stream. But this draft doesn't describe how a call controller or session manager does that. Rather, from the SIP perspective, the endpoint dreams up a DSCP value and, following this specification, declares that value in its SDP and requires its peer to use the same DSCP value. > For example in the US, > DISA has some requirements for their Defense Information System > Network that specify that a call controller must instruct served CPE > regarding what DSCP value to use in the bearer based on the > precedence level that the user requests - this involves an > authentication and authorization to use that level in the call > controller (a B2BUA). The flow I'm imagining is this: Call Alice Controller B2BUA | | | 1. offhook-------->| | | 2. dialed digits-->| | | 3. |--555-1212--->| | 4. |<--DSCP=0100--| | 5. |--INVITE, a=dscp:0100------>| Where draft-polk-mmusic-dscp-attribute-00.txt is only describing message 5. Is that about right? > While it's interesting, and potentially useful, for one EP to tell > another "Hey, I'm going to use DSCP 41" I think that view of this > draft misses its point, and that the real power is allowing a call > controller/session manager to drive the endpoint's behavior. This > allows for all kinds of good things - like authorization - to come > into play w.r.t. use of particular DSCP values and the PHBs > they imply. As written, the draft only describes the offerer having that privilege to decide the DSCP value it'll use in its call setup. The draft doesn't describe steps (3) and (4) in the above flow. Now, if we imagine an *incoming* call (that is, a call going towards Alice), I could see where the B2BUA, in conjunction with the Call Controller, could decide the DSCP value for the incoming call. Something like this: Call Alice Controller B2BUA | | | 1. | | |<--INVITE To: Alice 2. | |<-DSCP?------| 3. | |--DSCP=0101->| 4. |<-INVITE, a=dscp:0101-------| In which case the draft, as written, makes sense. > In cases when the bearer streams cross network boundaries, I would > expect Session Boarder Controllers to rewrite the SDP and modify the > DSCP attribute as appropriate per policy - similar to how STPs that > interconnect ISUP networks modify IAMs transmitted between networks. Yes, something needs to modify the DSCPs as they cross the network boundary. SBCs are a heavy way to do that, but we don't have a better mechanism to do such remarking on a per-flow basis. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 20:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geita-0006sr-2H; Mon, 30 Oct 2006 20:58:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeitY-0006sL-DE for mmusic@ietf.org; Mon, 30 Oct 2006 20:58:28 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeirA-0004iD-11 for mmusic@ietf.org; Mon, 30 Oct 2006 20:56:02 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id AD23067C; Mon, 30 Oct 2006 20:55:47 -0500 From: "Hadriel Kaplan" To: "'Dan Wing'" , "'Elwell, John'" , "'Francois Audet'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Mon, 30 Oct 2006 20:55:30 -0500 Keywords: direct-to-dwing Message-ID: <016e01c6fc8f$a54b3490$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb7O2c3PZUDoigIQoirauJsm96rFQAjOO/gADAghZAAAZ2UoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <57bc01c6fc89$cc8f99c0$5b82200a@amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, October 30, 2006 8:14 PM > To: 'Hadriel Kaplan'; 'Elwell, John'; 'Francois Audet'; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- > 01.txt > > > I wouldn't think zrtp would need port-mapping. > > Security Descriptions probably doesn't need it, either -- it can't do > early > media unless we resurrect draft-wing-mmusic-sdes-early-media-00.txt or > some > idea like it. Sure, but you may need to know that you can't do it. I.e., when you make a best-effort offer, you may need to know that the answerer has chosen srtp instead of rtp before the SDP answer comes back, so payload-mapping is the way. (sorry, I said port-mapping originally but meant payload-mapping) -hadriel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 30 21:03:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geiy1-0000g6-SQ; Mon, 30 Oct 2006 21:03:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geixz-0000fY-VP for mmusic@ietf.org; Mon, 30 Oct 2006 21:03:03 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geixy-0006pb-MK for mmusic@ietf.org; Mon, 30 Oct 2006 21:03:03 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2006 18:03:02 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9V231E9029558; Mon, 30 Oct 2006 18:03:01 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9V231W4000296; Mon, 30 Oct 2006 18:03:01 -0800 (PST) From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Elwell, John'" , "'Francois Audet'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Mon, 30 Oct 2006 18:03:01 -0800 Keywords: direct-to-dwing Message-ID: <582c01c6fc90$b21a5c40$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <016e01c6fc8f$a54b3490$0500a8c0@acmepacket.com> Thread-Index: Acb7O2c3PZUDoigIQoirauJsm96rFQAjOO/gADAghZAAAZ2UoAAAOIUA DKIM-Signature: a=rsa-sha1; q=dns; l=780; t=1162260182; x=1163124182; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20RE=3A=20I-D=20ACTION=3Adraft-kaplan-mmusic-best-effor t-srtp-01.txt; X=v=3Dcisco.com=3B=20h=3DxBX4iA4VQuhdkcexVU8I2tdVYaA=3D; b=Yx1rjRVr9wPruMePlTpi26YNqSObXOcRnVKvTwA67CwYE3Tc+0Cis9ViD5E/7rWmAjv3PAur QQPKCGl4XKsqSGJyHUe9pelUtah6U+Lcg1XZ7Vklw8R6hFkL46d8iZJk; Authentication-Results: sj-dkim-3.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > > Security Descriptions probably doesn't need it, either -- it can't > > do early media unless we resurrect > > draft-wing-mmusic-sdes-early-media-00.txt or some idea like it. > > Sure, but you may need to know that you can't do it. I.e., when you > make a best-effort offer, you may need to know that the answerer has > chosen srtp instead of rtp before the SDP answer comes back, so > payload-mapping is the way. (Sorry, I said port-mapping originally > but meant payload-mapping) Ok, but what can you do with that new knowledge? Maybe there is something useful you can do with the various early media things described in draft-stucker-sipping-early-media-coping (stop playing the RTP that's being streamed to you), but I'm not sure I know what it is. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 03:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeokU-0001V0-0n; Tue, 31 Oct 2006 03:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeokS-0001Uo-Ui for mmusic@ietf.org; Tue, 31 Oct 2006 03:13:28 -0500 Received: from eastmail3.ntt-east.co.jp ([202.229.5.46] helo=evx3.enoc.east.ntt.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeokR-0003eT-8V for mmusic@ietf.org; Tue, 31 Oct 2006 03:13:28 -0500 Received: from emix1.enoc.east.ntt.co.jp by evx3.enoc.east.ntt.co.jp with ESMTP id k9V8DLm12459; Tue, 31 Oct 2006 17:13:21 +0900 (JST) Received: from cip4.noc.east.ntt.co.jp by emix1.enoc.east.ntt.co.jp with ESMTP id k9V8DKx04714; Tue, 31 Oct 2006 17:13:21 +0900 (JST) Received: from [10.8.52.35] ([10.8.52.35]) by cip4.noc.east.ntt.co.jp (MOS 3.4.6-GR) with ESMTP id CTG29615; Tue, 31 Oct 2006 17:13:19 +0900 (JST) Date: Tue, 31 Oct 2006 17:03:57 +0900 From: Jun KOSHIKO To: Paul Kyzivat , Gonzalo Camarillo Subject: Re: [MMUSIC] Question about bundling SDP m=lines In-Reply-To: <45460F77.5050906@cisco.com> References: <45459E5C.1040406@ericsson.com> <45460F77.5050906@cisco.com> Message-Id: <20061031170242.9037.J.KOSHIKO@east.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.27 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, Thank you for the valuable comments. I understand that your comments are the followings. - Protocol Extension is needed to match the requirement - There are three possible solutions as followings 1. Grouping m=lines of SDP (+ new "semantics") 2. New attributes (required/optional) in media description 3. Use precondition (+ new "precondition-type") Is my understanding correct? I hope I would like to compare and consider the advantages and disadvantages of the three solutions. Thank you, Jun Koshiko > This seems to be one more example of a whole family of cases where SDP > and offer/answer aren't sufficient to state the criteria desired for a > call. Other examples are: > - several codecs can be supported but only one at a time, so any > answer listing more than one codec is unacceptable. (Unless of > course there are two and one of them is telephone-events.) > > - I'd like an audio call or a fax call, but not both > > One solution to this is to come up with a new notation to express each > new kind of constraint, and add it to SDP. > > Another possible solution might be to use an attribute to characterize > media streams as "required" or "optional", with the expectation that a > call should not be completed unless the "required" streams can be > established. > > Yet another possible solution is to use preconditions. I haven't thought > out the details, but it seems it would be possible to define a > precondition type related to media sufficiency. This would delay > alerting while the offerer gets to see the initial answer. At that point > the offerer can call things off if the answer isn't sufficient. This > would avoid the need to express all possible types of constraints, > reducing it to a case of "I'll know if its good when I see it". > > Unfortunately, it seems that use of preconditions has not caught on. So > this kind of solution isn't likely to be very popular. > > Paul > > Gonzalo Camarillo wrote: > > Hi, > > > > yes, you could use the grouping framework to group a few streams > > together so that they should be accepted or rejected as a group. As you > > point out, none of the current 'semantics' does this. Therefore, you > > would need to define new 'semantics' for the framework. > > > > Cheers, > > > > Gonzalo > > > > j.koshiko@east.ntt.co.jp wrote: > >> Folks, > >> > >> I hope I would like to ask an question on SDP offer/answer model. > >> > >> Imagine the case where the offerer initiates a video call. > >> Is there any parameter which indicates offerer doesn't want > >> answerer to answer an SDP with video medium only, > >> without an audio medium? > >> > >> An SDP offer for video call includes two m=lines, m=audio and m=video. > >> According to RFC4566/3264, the answerer may read > >> each m=line independently, and may return a SDP answer > >> with port 0 in either of the two m=lines. > >> Session may be established with video only, without audio, > >> which is not the caller's intention. > >> > >> offerer answerer > >> | | > >> | INVITE (m=video & m=audio) | > >> |--------------------------------->| > >> | 200 OK (m=video & m=audio port 0)| > >> |<---------------------------------| > >> | RTP session (video only) | > >> |<================================>| > >> | | > >> > >> To avoid this, offerer have to tell the answerer that > >> m=audio and m=video are bundled and that it doesn't > >> want to establish with either of the media. > >> > >> I hope I would like to ask you how to express the offerer's intention. > >> > >> I guess this should be achived by m=line group attribute > >> defined by RFC3388, because it says in Chapter 1 that "expression of > >> how different media streams within a session description relate to > >> each other." I guess that this would make it possible to express > >> that m=audio and m=video are bundled. > >> > >> What the "semantics" field should be set, if I use a group attribute > >> in this way? Four values, "LS", "FID", "SRF" and "ANAT" are registered > >> on IANA, > >> but none of them seems to be intended to influence UA's offer/answer. > >> Is a new semantics parameter needed to meed the requirement? > >> > >> Please let me know your advice. > >> > >> Does this topic match to another mailing list more? > >> I apologize if this subject is off-topic for this mailing list. > >> > >> Thank you, > >> Jun Koshiko > >> > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > --------------------------------------------------------- Jun KOSHIKO Next Generation Strategy Research and Development Center NTT-east Corporation Telephone +81 3 5359 5104 Facsimile +81 3 5359 1236 E-mail: j.koshiko@east.ntt.co.jp 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan --------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 03:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geore-00067R-9T; Tue, 31 Oct 2006 03:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Georc-00067K-G2 for mmusic@ietf.org; Tue, 31 Oct 2006 03:20:52 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeorZ-0005U9-6g for mmusic@ietf.org; Tue, 31 Oct 2006 03:20:52 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Z00E7WR6Q92@siemenscomms.co.uk> for mmusic@ietf.org; Tue, 31 Oct 2006 08:20:51 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG5NB8>; Tue, 31 Oct 2006 08:20:39 +0000 Content-return: allowed Date: Tue, 31 Oct 2006 08:20:36 +0000 From: "Elwell, John" Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 01.txt To: Dan Wing , 'Hadriel Kaplan' , 'Francois Audet' , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A3D7852@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 31 October 2006 02:03 > To: 'Hadriel Kaplan'; Elwell, John; 'Francois Audet'; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: I-D > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt > > > > Security Descriptions probably doesn't need it, either -- it can't > > > do early media unless we resurrect > > > draft-wing-mmusic-sdes-early-media-00.txt or some idea like it. > > > > Sure, but you may need to know that you can't do it. I.e., when you > > make a best-effort offer, you may need to know that the answerer has > > chosen srtp instead of rtp before the SDP answer comes back, so > > payload-mapping is the way. (Sorry, I said port-mapping originally > > but meant payload-mapping) > > Ok, but what can you do with that new knowledge? Maybe there > is something > useful you can do with the various early media things described in > draft-stucker-sipping-early-media-coping (stop playing the > RTP that's being > streamed to you), but I'm not sure I know what it is. [JRE] If SDescriptions has a different payload type, then you know that if you receive this payload type before the SDP answer you cannot render it, whereas if you receive a payload type for RTP or for SRTP using certain MIKEY options you can indeed render the payload. > > -d > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 03:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gep6d-0003n5-Kh; Tue, 31 Oct 2006 03:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gep6c-0003mx-3X for mmusic@ietf.org; Tue, 31 Oct 2006 03:36:22 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gep6a-0006wn-Sl for mmusic@ietf.org; Tue, 31 Oct 2006 03:36:22 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id k9V8a4DQ011183; Tue, 31 Oct 2006 09:36:04 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k9V8a3Bm000584; Tue, 31 Oct 2006 09:36:03 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 09:36:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6FCC7.99A1AAE3" Subject: AW: [MMUSIC] Question about bundling SDP m=lines Date: Tue, 31 Oct 2006 09:36:02 +0100 Message-ID: <72963DDDF17D7949ABD18DC5DA58E77001781323@MCHP7R5A.ww002.siemens.net> In-Reply-To: <45460F77.5050906@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question about bundling SDP m=lines thread-index: Acb8MlKyke5onGp9S9WDy+sUqzsP1wAj0Myw From: "Schmidt, Christian" To: "Paul Kyzivat" , "Gonzalo Camarillo" , X-OriginalArrivalTime: 31 Oct 2006 08:36:03.0610 (UTC) FILETIME=[99D36FA0:01C6FCC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FCC7.99A1AAE3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are working on a new draft about dependencies between media streams = (see attachment). We propose to use an additional SDP attribute, called dependency. With this new attribute, you could define mandatory and optional = dependencies between media streams. The draft could be extended to cover other types of dependencies between = media streams as well. Could this new dependency attribute solve your problem? Comments are = welcome. Christian Schmidt -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Montag, 30. Oktober 2006 15:43 An: Gonzalo Camarillo Cc: mmusic@ietf.org Betreff: Re: [MMUSIC] Question about bundling SDP m=3Dlines This seems to be one more example of a whole family of cases where SDP=20 and offer/answer aren't sufficient to state the criteria desired for a=20 call. Other examples are: - several codecs can be supported but only one at a time, so any answer listing more than one codec is unacceptable. (Unless of course there are two and one of them is telephone-events.) - I'd like an audio call or a fax call, but not both One solution to this is to come up with a new notation to express each=20 new kind of constraint, and add it to SDP. Another possible solution might be to use an attribute to characterize=20 media streams as "required" or "optional", with the expectation that a=20 call should not be completed unless the "required" streams can be=20 established. Yet another possible solution is to use preconditions. I haven't thought = out the details, but it seems it would be possible to define a=20 precondition type related to media sufficiency. This would delay=20 alerting while the offerer gets to see the initial answer. At that point = the offerer can call things off if the answer isn't sufficient. This=20 would avoid the need to express all possible types of constraints,=20 reducing it to a case of "I'll know if its good when I see it". Unfortunately, it seems that use of preconditions has not caught on. So=20 this kind of solution isn't likely to be very popular. Paul Gonzalo Camarillo wrote: > Hi, >=20 > yes, you could use the grouping framework to group a few streams=20 > together so that they should be accepted or rejected as a group. As = you=20 > point out, none of the current 'semantics' does this. Therefore, you=20 > would need to define new 'semantics' for the framework. >=20 > Cheers, >=20 > Gonzalo >=20 > j.koshiko@east.ntt.co.jp wrote: >> Folks, >> >> I hope I would like to ask an question on SDP offer/answer model. >> >> Imagine the case where the offerer initiates a video call. >> Is there any parameter which indicates offerer doesn't want >> answerer to answer an SDP with video medium only, >> without an audio medium? >> >> An SDP offer for video call includes two m=3Dlines, m=3Daudio and = m=3Dvideo.=20 >> According to RFC4566/3264, the answerer may read >> each m=3Dline independently, and may return a SDP answer >> with port 0 in either of the two m=3Dlines. >> Session may be established with video only, without audio, >> which is not the caller's intention. >> >> offerer answerer >> | | >> | INVITE (m=3Dvideo & m=3Daudio) | >> |--------------------------------->| >> | 200 OK (m=3Dvideo & m=3Daudio port 0)| >> |<---------------------------------| >> | RTP session (video only) | >> = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| >> | | >> >> To avoid this, offerer have to tell the answerer that >> m=3Daudio and m=3Dvideo are bundled and that it doesn't >> want to establish with either of the media. >> >> I hope I would like to ask you how to express the offerer's = intention. >> >> I guess this should be achived by m=3Dline group attribute >> defined by RFC3388, because it says in Chapter 1 that "expression of=20 >> how different media streams within a session description relate to=20 >> each other." I guess that this would make it possible to express >> that m=3Daudio and m=3Dvideo are bundled. >> >> What the "semantics" field should be set, if I use a group attribute=20 >> in this way? Four values, "LS", "FID", "SRF" and "ANAT" are = registered=20 >> on IANA, >> but none of them seems to be intended to influence UA's offer/answer. >> Is a new semantics parameter needed to meed the requirement? >> >> Please let me know your advice. >> >> Does this topic match to another mailing list more? >> I apologize if this subject is off-topic for this mailing list. >> >> Thank you, >> Jun Koshiko >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C6FCC7.99A1AAE3 Content-Type: text/plain; name="draft-schmidt-sdp-dependency-attr-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-schmidt-sdp-dependency-attr-00.txt Content-Disposition: attachment; filename="draft-schmidt-sdp-dependency-attr-00.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENoLiBTY2htaWR0DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNpZW1lbnMNCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAzMCwgMjAwNg0K RXhwaXJlczogTWF5IDMsIDIwMDcNCg0KDQogICAgICBUaGUgU0RQIChTZXNzaW9uIERlc2NyaXB0 aW9uIFByb3RvY29sKSBEZXBlbmRlbmN5IEF0dHJpYnV0ZQ0KICAgICAgICAgICAgICAgICAgZHJh ZnQtc2NobWlkdC1zZHAtZGVwZW5kZW5jeS1hdHRyLTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8N Cg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXBy ZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1z IG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlz Y2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3aWxs IGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuDQoN CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBz aXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUg dG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNp dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8v d3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg d2lsbCBleHBpcmUgb24gTWF5IDMsIDIwMDcuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29w eXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KU2NobWlkdCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMywgMjAw NyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBT RFAgRGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAgICAgICBPY3RvYmVyIDIwMDYNCg0KDQpBYnN0 cmFjdA0KDQogICBUaGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSB3YXMgaW50 ZW5kZWQgZm9yIGRlc2NyaWJpbmcNCiAgIG11bHRpbWVkaWEgc2Vzc2lvbnMgZm9yIHRoZSBwdXJw b3NlcyBvZiBzZXNzaW9uIGFubm91bmNlbWVudCwgc2Vzc2lvbg0KICAgaW52aXRhdGlvbiwgYW5k IG90aGVyIGZvcm1zIG9mIG11bHRpbWVkaWEgc2Vzc2lvbiBpbml0aWF0aW9uLg0KICAgVG9nZXRo ZXIgd2l0aCBPZmZlci9BbnN3ZXIgbW9kZWwgaXQgZGVmaW5lcyBhIG1lY2hhbmlzbSwgaG93IHR3 bw0KICAgZW50aXRpZXMgY2FuIHJlYWNoIGEgY29tbW9uIHZpZXcgb2YgYSBtdWx0aW1lZGlhIHNl c3Npb24gYmV0d2Vlbg0KICAgdGhlbS4NCg0KICAgVGhlIHRpZ2h0bHkgY291cGxlZCBTSVAgY29u ZmVyZW5jaW5nIGZyYW1ld29yayBkb2VzIG5vdCBnaXZlIHRoZQ0KICAgb2ZmZXJlciB0aGUgcG9z c2liaWxpdHkgdG8gZGVmaW5lIGRlcGVuZGVuY2llcyBiZXR3ZWVuIG1lZGlhIHR5cGVzDQogICBh bmQgdGh1cyBhIG11bHRpbWVkaWEgb2ZmZXIgbWF5IHBvdGVudGlhbGx5IGxlYWQgdG8gbXVsdGkt cGFydHkNCiAgIG11bHRpbWVkaWEgY29uZmVyZW5jZSB3aGVyZSwgYWZ0ZXIgdGhlIGNvbmZlcmVu Y2UgaXMgc2V0IHVwLA0KICAgZGlmZmVyZW50IGNvbmZlcmVuY2UgcGFydGljaXBhbnRzIHVzZSBk aWZmZXJlbnQsIG5vbiBvdmVybGFwcGluZywNCiAgIG1lZGlhIHR5cGUgc2V0cyBpbiBvbmUgY29u ZmVyZW5jZSBzbyBubyBjb250ZW50IGNhbiBiZSBkZWxpdmVyZWQgdG8NCiAgIGFsbCB0aGUgY29u ZmVyZW5jZSBwYXJ0aWNpcGFudHMuDQoNCiAgIEluIGNlcnRhaW4gY2FzZXMsIHRoZXJlIGFyZSBk ZXBlbmRlbmNpZXMgYmV0d2VlbiBtZWRpYSBzdHJlYW1zLCBmb3INCiAgIGV4YW1wbGUgYSB0ZXh0 IHN0cmVhbSBmb3Igc3VidGl0bGluZyBtYWtlIHNlbnNlIG9ubHkgdG9nZXRoZXIgd2l0aCBhDQog ICB2aWRlbyBzdHJlYW0uDQoNCiAgIFRvIGFjaGlldmUgdGhpcywgdGhlIFNEUCBtZWNoYW5pc20g Y2FuIGJlIGV4dGVuZGVkIHdpdGggYSBuZXcgU2Vzc2lvbg0KICAgRGVzY3JpcHRpb24gUHJvdG9j b2wgKFNEUCkgbWVkaWEtbGV2ZWwgYXR0cmlidXRlOiAiZGVwZW5kZW5jeSIuICBUaGUNCiAgICJk ZXBlbmRlbmN5IiBhdHRyaWJ1dGUgYWxsb3dzIHRoZSBvZmZlcmVyIHRvIGRlZmluZSBkZXBlbmRl bmNpZXMgb2YNCiAgIG1lZGlhIHN0cmVhbXMuICBUaGUgdXBkYXRlZCBvZmZlci9hbnN3ZXIgbWVj aGFuaXNtIHVzZWQgd2l0aCBuZXcNCiAgICJkZXBlbmRlbmN5IiBhdHRyaWJ1dGUgYXNzdXJlcyBm dXJ0aGVybW9yZSB0aGF0IGluIGEgbXVsdGktcGFydHkgU0lQDQogICBzZXNzaW9uIGFsbCBwYXJ0 aWNpcGFudHMgc2hhcmUgYXQgbGVhc3Qgb25lIGNvbW1vbiBtZWRpYSB0eXBlLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2NobWlkdCAgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBNYXkgMywgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAgRGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAg ICAgICBPY3RvYmVyIDIwMDYNCg0KDQoxICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIG92ZXJhbGwg ZnJhbWV3b3JrIGZvciB0aWdodGx5IGNvdXBsZWQgU0lQIGNvbmZlcmVuY2luZyBpcyBkZWZpbmVk DQogICBpbiBSRkMgNDM1MyBbNV0uICBUaGUgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZSBkZWZp bmVzIHRoZSBjZW50cmFsDQogICBjb21wb25lbnQgY2FsbGVkICdmb2N1cycuICBUaGUgZm9jdXMg bWFpbnRhaW5zIGEgU0lQIHNpZ25hbGluZw0KICAgcmVsYXRpb25zaGlwIHdpdGggZWFjaCBwYXJ0 aWNpcGFudCBpbiB0aGUgY29uZmVyZW5jZS4gIEVhY2gNCiAgIGNvbmZlcmVuY2UgaXMgY29tcG9z ZWQgb2YgYSBwYXJ0aWN1bGFyIHNldCBvZiBtZWRpYSB0eXBlcyB0aGF0IHRoZQ0KICAgZm9jdXMg aXMgbWFuYWdpbmcuICBUaGUgc3RhbmRhcmQgb2ZmZXIvYW5zd2VyIHRlY2huaXF1ZXMgZGVmaW5l ZCBpbg0KICAgUkZDIDMyNjQgWzRdIGFyZSB1c2VkIGZvciBhZGRpbmcgYW5kIHJlbW92aW5nIG1l ZGlhIHR5cGVzIGluIHRoZQ0KICAgY29uZmVyZW5jZS4gIFdoZW4gdGhlIHNldCBvZiBtZWRpYSB0 eXBlcyBpbiB0aGUgY29uZmVyZW5jZSBjaGFuZ2VzLA0KICAgdGhlIGZvY3VzIHdpbGwgbmVlZCB0 byBnZW5lcmF0ZSBhIHJlLUlOVklURSB0byBlYWNoIHBhcnRpY2lwYW50IGluDQogICBvcmRlciB0 byBhZGQgb3IgcmVtb3ZlIHRoZSBtZWRpYSBzdHJlYW1zLiAgV2hlbiBhIG1lZGlhIHN0cmVhbSBp cw0KICAgYmVpbmcgYWRkZWQsIGEgcGFydGljaXBhbnQgY2FuIHJlamVjdCB0aGUgb2ZmZXJlZCBt ZWRpYSBzdHJlYW0sIGluDQogICB3aGljaCBjYXNlIGhlIHdpbGwgbm90IHJlY2VpdmUgb3IgY29u dHJpYnV0ZSB0byB0aGF0IHN0cmVhbS4NCiAgIFJlamVjdGlvbiBvZiBhIHN0cmVhbSBieSBhIHBh cnRpY2lwYW50IGRvZXMgbm90IGltcGx5IHRoYXQgdGhlIHN0cmVhbQ0KICAgaXMgbm8gbG9uZ2Vy IHBhcnQgb2YgdGhlIGNvbmZlcmVuY2UsIG9ubHkgdGhhdCB0aGlzIHBhcnRpY2lwYW50IGlzDQog ICBub3QgaW52b2x2ZWQgaW4gaXQuDQoNCiAgIFRoaXMgaGFuZGxpbmcgbWF5IHBvdGVudGlhbGx5 IGxlYWQgdG8gbXVsdGktcGFydHkgbXVsdGltZWRpYQ0KICAgY29uZmVyZW5jZXMgd2hlcmUsIGFm dGVyIHRoZSBjb25mZXJlbmNlIGlzIHNldCB1cCwgZGlmZmVyZW50DQogICBjb25mZXJlbmNlIHBh cnRpY2lwYW50cyB1c2UgZGlmZmVyZW50LCBub24gb3ZlcmxhcHBpbmcsIG1lZGlhIHR5cGUNCiAg IHNldHMgaW4gb25lIGNvbmZlcmVuY2Ugc28gbm8gY29udGVudCBjYW4gYmUgZGVsaXZlcmVkIHRv IGFsbCB0aGUNCiAgIGNvbmZlcmVuY2UgcGFydGljaXBhbnRzLiAgQXMgYW4gZXhhbXBsZSwgaWYg b25lIGNvbmZlcmVuY2UgdXNlciBBDQogICB1c2VzIGF1ZGlvIHRvZ2V0aGVyIHdpdGggdGV4dCBt ZXNzYWdpbmcsIHVzZXIgQiB1c2VzIGF1ZGlvIG9ubHkgYW5kDQogICB1c2VyIEMgdXNlcyB0ZXh0 IG1lc3NhZ2luZyBvbmx5LiAgSW4gc3VjaCBhIGNvbmZpZ3VyYXRpb24sIHRoZSB1c2VyIEINCiAg IGNhbm5vdCBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIHVzZXIgQywgdGhlIGluZm9ybWF0aW9u IGV4Y2hhbmdlIGNhbg0KICAgYmUgZG9uZSBvbmx5IHZpYSB1c2VyIEEuIFRoaXMgY29uZmlndXJh dGlvbiBjYW4gYmUgaW4gc29tZSBjYXNlcw0KICAgdW5kZXNpcmVkLg0KDQogICBJbiBhZGRpdGlv biwgc2ltaWxhciBwcm9ibGVtIGNhbiBvY2N1ciBhbHNvIGluIHR3by1wYXJ0eSBzZXNzaW9uDQog ICBiZXR3ZWVuIHRoZSBTSVAgdXNlciBhZ2VudHMgUkZDIDMyNjEgWzZdLiAgSW4gc29tZSBjYXNl cywNCiAgIGRlcGVuZGVuY2llcyBtYXkgYmUgcmVxdWlyZWQuICBGb3IgZXhhbXBsZSwgYSB0ZXh0 LXN0cmVhbSBmb3INCiAgIHN1YnRpdGxpbmcgbWF5IG9ubHkgbWFrZSBzZW5zZSB0b2dldGhlciB3 aXRoIGEgdmlkZW8gc3RyZWFtLiAgQWxzbyBpbg0KICAgdGhpcyBjYXNlLCB0aGVyZSBpcyBhIG5l ZWQgZm9yIGVuaGFuY2VtZW50cyBvZiBvZmZlci9hbnN3ZXIgbW9kZWwNCiAgIHRoYXQgYWxsb3dz IHRvIHRoZSBvZmZlcmVyIHRvIGluZGljYXRlIGluIHRoZSBvZmZlciwgdGhhdCBvbmUgbWVkaWEN CiAgIHN0cmVhbSBjYW4gYmUgYWNjZXB0ZWQgb25seSBpZiBhbm90aGVyIGRlcGVuZGFudCBtZWRp YSBzdHJlYW1zIGFyZQ0KICAgYWxzbyBhY2NlcHRlZC4NCg0KICAgVGhlIE9mZmVyL2Fuc3dlciBt b2RlbCBhcyBkZWZpbmVkIG5vdyBkb2VzIG5vdCBhbGxvdyB0byBkZWZpbmUNCiAgIGRlcGVuZGVu Y2llcyBiZXR3ZWVuIG1lZGlhIHN0cmVhbXMuICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBh DQogICBzb2x1dGlvbiBob3cgdGhlIFNEUCAoZGVmaW5lZCBpbiBSRkMgNDU2NiBbM10pIGNhbiBi ZSBlbmhhbmNlZCB3aXRoIGENCiAgIG5ldyBhdHRyaWJ1dGUgdGhhdCBhbGxvd3MgdGhlIGRlZmlu aXRpb24gb2YgbWVkaWEgZGVwZW5kZW5jaWVzIGFuZA0KICAgdGhlIG1hcmtpbmcgb2YgbWVkaWEg c3RyZWFtcyBhcyBtYW5kYXRvcnkgb3Igb3B0aW9uYWwuDQoNCg0KDQoNCg0KDQoNCg0KU2NobWlk dCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMywgMjAwNyAgICAgICAgICAgICAgICAg IFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAgRGVwZW5kZW5jeSBhdHRy aWJ1dGUgICAgICAgICAgICBPY3RvYmVyIDIwMDYNCg0KDQoyICBUZXJtaW5vbG9neQ0KDQogICBJ biB0aGlzIGRvY3VtZW50LCB0aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwNCiAgICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTk9UDQogICBSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMNCiAgIGRlc2NyaWJlZCBpbiBCQ1AgMTQsIFJGQyAy MTE5IFsxXSBhbmQgaW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzIGZvcg0KICAgY29tcGxpYW50 IGltcGxlbWVudGF0aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTY2htaWR0 ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAzLCAyMDA3ICAgICAgICAgICAgICAgICAg W1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5IGF0dHJp YnV0ZSAgICAgICAgICAgIE9jdG9iZXIgMjAwNg0KDQoNCjMgIE1vdGl2YXRpb24gZm9yIHRoZSBO ZXcgRGVwZW5kZW5jeSBBdHRyaWJ1dGUNCg0KICAgRXZlbiB0aG91Z2ggdGhlIG9yZGVyIG9mICdt JyBsaW5lcyBpbiBvZmZlciBjYW4gYmUgY29uc2lkZXJlZCBhcw0KICAgcHJlZmVyZW5jZSBvZiB0 aGUgb2ZmZXJlciwgdGhlIGhhbmRsaW5nIGRlZmluZWQgaW4gT2ZmZXIvQW5zd2VyIG1vZGVsDQog ICBbNF0gbGltaXRzIHRoZSB1c2FnZSBvZiBzdWNoIGFuIG9yZGVyZWQgbGlzdC4gIEFzIHRoZSBv cmRlciBvZiB0aGUNCiAgIG1lZGlhLWxpbmVzIGluIGFuIG9mZmVyIGNhbm5vdCBiZSBjaGFuZ2Vk IGluIHRoZSBzdWJzZXF1ZW50IG9mZmVyIG9mDQogICB0aGUgc2FtZSBTSVAgc2Vzc2lvbiwgdGhl IG5ld2x5IG9mZmVyZWQgbWVkaWEgc3RyZWFtIGNhbm5vdCBiZSBwbGFjZWQNCiAgIHRvIHRoZSBw b3NpdGlvbiBpbiB0aGUgb3JkZXJlZCBsaXN0IHdpc2hlZCBieSB0aGUgb2ZmZXJlci4NCg0KICAg VGhlIFNEUCBbM10gYW5kIGl0cyBleHRlbnNpb25zIGFscmVhZHkgZGVmaW5lIHNldmVyYWwgYXR0 cmlidXRlcyB0bw0KICAgYmUgdXNlZCBvbiB0aGUgbWVkaWEtbGV2ZWwsIGJ1dCBub25lIG9mIHRo ZW0gaXMgYXBwcm9wcmlhdGUgdG8gYmUNCiAgIHVzZWQgaW4gdGhlIGNvbnRleHQgb2Ygb3JkZXJp bmcgbWVkaWEgc3RyZWFtcyBiYXNlZCBvbiB0aGUNCiAgIHByZWZlcmVuY2VzIG9mIHRoZSBvZmZl cmVyLg0KDQogICBUaGUgbW9zdCBkZXNpcmFibGUgc2VlbXMgdG8gYmUgdGhlICdpJyBTRFAgYXR0 cmlidXRlLCBkZWZpbmVkIGluIFJGQw0KICAgNDU2NiBbM10sIHRoYXQgY2FuIGJlIHVzZWQgdG8g bGFiZWwgbWVkaWEgc3RyZWFtcyB3aXRoIGFueSB0ZXh0DQogICB2YWx1ZSwgaW5jbHVkaW5nIHRo ZSBudW1iZXIuICBOZXZlcnRoZWxlc3MsIHZhbHVlcyBvZiB0aGUgJ2knDQogICBhdHRyaWJ1dGUg YXJlIGludGVuZGVkIGZvciBodW1hbiB1c2VycyBhbmQgbm90IGZvciBhdXRvbWF0YS4NCiAgIE1v cmVvdmVyLCB0aGUgdXNhZ2Ugb2YgJ2knIGF0dHJpYnV0ZSBmb3Igb3RoZXIgcHVycG9zZSB0aGFu IGRlZmluaW5nDQogICBvZiBtZWRpYSBzdHJlYW0gZGVwZW5kZW5jaWVzIChmb3IgZXhhbXBsZSBi eSBjbGllbnRzIG5vdCBzdXBwb3J0aW5nDQogICBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGlzIGRv Y3VtZW50KSBtYXkgbGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5DQogICBwcm9ibGVtcy4NCg0KICAg QWxzbyB1c2FnZSBvZiBzb21lIG90aGVyIHBvc3NpYmxlIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiBS RkMgNDU2NiBbM10NCiAgIGFuZCBpdHMgZXh0ZW5zaW9ucyBjYW4gYmUgY29uc2lkZXJlZCBhcyB0 aGVpciBtaXN1c2UgYW5kIGlzIG5vdA0KICAgcmVjb21tZW5kZWQuDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNjaG1pZHQgICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDMsIDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgU0RQIERlcGVuZGVuY3kgYXR0cmlidXRlICAgICAgICAgICAg T2N0b2JlciAyMDA2DQoNCg0KNCAgVGhlIERlcGVuZGVuY3kgQXR0cmlidXRlDQoNCiAgIFRoaXMg c3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgbmV3IG1lZGlhLWxldmVsIHZhbHVlIGF0dHJpYnV0ZToN CiAgICJkZXBlbmRlbmN5Ii4gIEl0cyBmb3JtYXR0aW5nIGluIFNEUCBpcyBkZXNjcmliZWQgYnkg dGhlIGZvbGxvd2luZw0KICAgQk5GIFsyXToNCg0KICAgICAgZGVwZW5kZW5jeS1hdHRyaWJ1dGUg PSAiYT1kZXBlbmRlbmN5Om1hbmRhdG9yeT0iIHBvaW50ZXJzDQogICAgICAiO29wdGlvbmFsPSIg cG9pbnRlcnMgLyAiYT1kZXBlbmRlbmN5Om1hbmRhdG9yeT0iIHBvaW50ZXJzIC8NCiAgICAgICJh PWRlcGVuZGVuY3k6b3B0aW9uYWw9IiBwb2ludGVycw0KDQogICAgICBwb2ludGVycyA9IHBvaW50 ZXIgKiggIiwiIHBvaW50ZXIpDQoNCiAgICAgIHBvaW50ZXIgPSB0b2tlbg0KDQogICAgICB0b2tl biA9IDEqKHRva2VuLWNoYXIpDQoNCiAgICAgIHRva2VuLWNoYXIgPSAleDIxIC8gJXgyMy0yNyAv ICV4MkEtMkIgLyAleDJELTJFIC8gJXgzMC0zOQ0KDQogICAgICAvICV4NDEtNUEgLyAleDVFLTdF DQoNCiAgICAgIFRoZSBwb2ludGVyIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiB0aGUgU0RQIExhYmVs IEF0dHJpYnV0ZSBbN10gYnV0DQogICAgICBpbmNsdWRlZCBoZXJlIHRvIHByb3ZpZGUgc3VwcG9y dCBmb3IgdGhlIGltcGxlbWVudG9yIG9mIHRoaXMgU0RQDQogICAgICBmZWF0dXJlLg0KDQogICAg ICBUaGlzIG5ldyAiZGVwZW5kZW5jeSIgYXR0cmlidXRlIFNIQUxMIGNvbnRhaW4gb25lIG9yIHR3 byBsaXN0cyBvZg0KICAgICAgU0RQIExhYmVscyAtIG1hbmRhdG9yeSBhbmQgb3B0aW9uYWwuICBF YWNoIGxpc3QgU0hBTEwgY29udGFpbiBhDQogICAgICBsaXN0IG9mIHRva2VucyBkZWZpbmVkIGJ5 IGFuIG9mZmVyZXIgKG9yIGhlciBhcHBsaWNhdGlvbikgdGhhdCBhcmUNCiAgICAgIGNvbm5lY3Rl ZCB0byBtZWRpYSBzdHJlYW0gaW4gdGhlIFNEUCBtZXNzYWdlLg0KDQogICAgICBUaGUgbWFuZGF0 b3J5IGxpc3QgY29udGFpbnMgZGVwZW5kZW5jaWVzIHRoYXQgbXVzdCBiZSBmdWxmaWxsZWQgaW4N CiAgICAgIG9yZGVyIHRvIGVuc3VyZSB0aGUgY29ycmVjdCBzZXNzaW9uIHNldHVwLCB3aGlsZSB0 aGUgb3B0aW9uYWwgbGlzdA0KICAgICAgY29udGFpbnMgdGhlIGRlcGVuZGVuY2llcyB0aGF0IGFy ZSByZWNvbW1lZGVkIHRvIHRoZSBhbnN3ZXJlci4NCiAgICAgIEUuZy4gc3VidGl0bGluZyBkb2Vz IG5vdCBtYWtlIHNlbnNlIHdpdGhvdXQgdmlkZW8gKG1hbmRhdG9yeQ0KICAgICAgZGVwZW5kZW5j eSksIHdoaWxlIHN1YnRpdGxpbmcgd2l0aCB2aWRlbyBpcyB1c2VmdWwgYnV0IG5vdA0KICAgICAg bmVjZXNzYXJ5IChvcHRpb25hbCBkZXBlbmRlbmN5KS4NCg0KICAgRXhhbXBsZToNCg0KICAgICAg YT1kZXBlbmRlbmN5Om1hbmRhdG9yeT0xLDM7b3B0aW9uYWw9Mg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KU2NobWlkdCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMywgMjAwNyAgICAg ICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAgRGVw ZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAgICAgICBPY3RvYmVyIDIwMDYNCg0KDQo1ICBUaGUgRGVw ZW5kZW5jeSBBdHRyaWJ1dGUgaW4gT2ZmZXIvQW5zd2VyIE1vZGVsDQoNCiAgIEluIHRoaXMgc2Vj dGlvbiwgd2UgZGVmaW5lIGV4dGVuc2lvbnMgdG8gdGhlIG9mZmVyL2Fuc3dlciBtb2RlbA0KICAg ZGVmaW5lZCBpbiBSRkMzMjY0IFs0XSB0byBhbGxvdyBlc3RhYmxpc2htZW50IG9mIHRoZSBtdWx0 aW1lZGlhDQogICBzZXNzaW9uIHdpdGggbWVkaWEgc3RyZWFtIGRlcGVuZGVuY2llcy4NCg0KICAg QW4gb2ZmZXJlciB0aGF0IHdhbnRzIHRvIHVzZSBkZXBlbmRlbmN5IGV4dGVuc2lvbiBkZWZpbmVk IGluIHRoaXMNCiAgIGRvY3VtZW50IE1BWSBpbmNsdWRlIHRoZSAiZGVwZW5kZW5jeSIgYXR0cmli dXRlIGluIGVhY2ggbWVkaWEtbGV2ZWwNCiAgIHNlY3Rpb24gaW4gdGhlIFNEUCBvZmZlci4gIElu IGFkZGl0aW9uLCBlYWNoIG1lZGlhIHN0cmVhbSBpbiB0aGUgU0RQDQogICBtZXNzYWdlIGdlbmVy YXRlZCBieSB0aGUgb2ZmZXJlciwgd2hpY2ggaXMgcmVmZXJlbmNlZCBpbiBhbg0KICAgImRlcGVu ZGVuY3kiIGF0dHJpYnV0ZSBvZiBhbm90aGVyIG1lZGlhIHN0cmVhbSwgTVVTVCBpbmNsdWRlIHRo ZQ0KICAgbGFiZWwgYXR0cmlidXRlIGRlZmluZWQgaW4gUkZDNDU3NCBbN10uDQoNCiAgIFdoZW4g dGhlIGFuc3dlcmVyIHJlY2VpdmVzIGFuIG9mZmVyIHdpdGggImRlcGVuZGVuY3kiIGF0dHJpYnV0 ZXMgYW5kDQogICBzdXBwb3J0cyBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LCB0 aGUgYW5zd2VyZXIgU0hBTEwgdXNlDQogICB0aGUgZm9sbG93aW5nIHJ1bGVzIHdoZW4gZ2VuZXJh dGluZyB0aGUgYW5zd2VyOg0KDQogICAgICAoMSkgV2hlbiBhbnkgbWVkaWEgc3RyZWFtIGZyb20g dGhlIG9mZmVyIGlzIGFjY2VwdGVkLCBhbGwgbWVkaWENCiAgICAgIHN0cmVhbXMgd2l0aCBsYWJl bCBsaXN0ZWQgYXMgbWFuZGF0b3J5IGluIHRoZSAiZGVwZW5kZW5jeSINCiAgICAgIGF0dHJpYnV0 ZSBNVVNUIGJlIGFjY2VwdGVkIHRvby4NCg0KICAgICAgKDIpIFdoZW4gYW55IG1lZGlhIGxhYmVs IGluY2x1ZGVkIGluIHRoZSBtYW5kYXRvcnkgbGlzdCBpcyBub3QNCiAgICAgIHJlY29nbml6ZWQg YXMgdmFsaWQgbGFiZWwgb2YgYW55IG1lZGlhIGluY2x1ZGVkIGluIHRoZSBTRFANCiAgICAgIG1l c3NhZ2UsIHRoZSBhbnN3ZXJlciBTSEFMTCByZWplY3QgdGhlIGVudGlyZSBvZmZlcmVkIHNlc3Np b24uDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIGFueSBoYW5kbGlu ZyBmb3IgdGhlIG1lZGlhIHR5cGVzDQogICB3aXRoIGxhYmVscyBsaXN0ZWQgYXMgb3B0aW9uYWwg aW4gdGhlICJkZXBlbmRlbmN5IiBhdHRyaWJ1dGUsIGJ1dCBpdA0KICAgaXMgUkVDT01NRU5ERUQg dGhhdCB3aGVuIGFueSBtZWRpYSBzdHJlYW0gZnJvbSB0aGUgb2ZmZXIgaXMgYWNjZXB0ZWQsDQog ICBhbGwgbWVkaWEgc3RyZWFtcyB3aXRoIGxhYmVsIGxpc3RlZCBhcyBvcHRpb25hbCBpbiB0aGUg ImRlcGVuZGVuY3kiDQogICBhdHRyaWJ1dGUgYXJlIGFjY2VwdGVkIGJ5IHRoZSBhcHBsaWNhdGlv biB0b28uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTY2htaWR0 ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAzLCAyMDA3ICAgICAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5IGF0dHJp YnV0ZSAgICAgICAgICAgIE9jdG9iZXIgMjAwNg0KDQoNCjYgIEV4YW1wbGUNCg0KICAgVGhlIGZv bGxvd2luZyBpcyBhbiBleGFtcGxlIG9mIGFuIFNEUCBzZXNzaW9uIGRlc2NyaXB0aW9uIHRoYXQg dXNlcw0KICAgdGhlICJkZXBlbmRlbmN5IiBhdHRyaWJ1dGU6DQoNCiAgICAgIHY9MA0KDQogICAg ICBjPUlOIElQNCAxLjIuMy40DQoNCiAgICAgIG09YXVkaW8gMTIzNCBSVFAvQVZQIC4uLg0KDQog ICAgICBhPWxhYmVsOjENCg0KICAgICAgbT12aWRlbyAyMzQ2IFJUUC9BVlAgLi4uDQoNCiAgICAg IGE9bGFiZWw6Mg0KDQogICAgICBhPWRlcGVuZGVuY3k6bWFuZGF0b3J5PTE7b3B0aW9uYWw9Mw0K DQogICAgICBtPW1lc3NhZ2UgMzQ1NiBUQ1AvTVNSUCAuLi4NCg0KICAgICAgaT1zdWJ0aXRsZXMg Zm9yIGF1ZGlvDQoNCiAgICAgIGE9bGFiZWw6Mw0KDQogICAgICBhPWRlcGVuZGVuY3k6bWFuZGF0 b3J5PTINCg0KICAgVGhlIGV4YW1wbGUgYWJvdmUsIHdoZW4gdXNlZCBpbiB0aGUgb2ZmZXIsIHJl cHJlc2VudHMgdGhlIHNlc3Npb24NCiAgIHdoZXJlIGF0IGxlYXN0IGF1ZGlvIHNoYWxsIGJlIHVz ZWQgYnkgYWxsIG11bHRpLXBhcnR5IG11bHRpbWVkaWENCiAgIHNlc3Npb24gcGFydGljaXBhbnRz LiAgVmlkZW8gY2FuIGJlIHVzZWQgb25seSB0b2dldGhlciB3aXRoIGF1ZGlvLg0KICAgU3VidGl0 bGVzIGNhbiBiZSB1c2VkIG9ubHkgdG9nZXRoZXIgd2l0aCBhdWRpbyBhbmQgdmlkZW8uICBWaWRl byBpcw0KICAgcmVjb21tZW5kZWQgdG8gYmUgdXNlZCB0b2dldGhlciB3aXRoIHN1YnRpdGxlcy4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2NobWlkdCAgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBNYXkgMywgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAgRGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAg ICAgICBPY3RvYmVyIDIwMDYNCg0KDQo3ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBB biBhdHRhY2tlciBtYXkgYXR0ZW1wdCB0byBhZGQsIG1vZGlmeSwgb3IgcmVtb3ZlICJkZXBlbmRl bmN5Ig0KICAgYXR0cmlidXRlcyBmcm9tIGEgc2Vzc2lvbiBkZXNjcmlwdGlvbi4gIFRoaXMgY291 bGQgcmVzdWx0IGluIGFuDQogICBhcHBsaWNhdGlvbiBiZWhhdmluZyBpbiBhIG5vbi1kZXNpcmFi bGUgd2F5LiAgU28sIGl0IGlzIHN0cm9uZ2x5DQogICBSRUNPTU1FTkRFRCB0aGF0IGludGVncml0 eSBwcm90ZWN0aW9uIGJlIGFwcGxpZWQgdG8gdGhlIFNEUCBzZXNzaW9uDQogICBkZXNjcmlwdGlv bnMuICBGb3Igc2Vzc2lvbiBkZXNjcmlwdGlvbnMgY2FycmllZCBpbiBTSVAgUkZDMzI2MSBbNl0s DQogICBTL01JTUUgaXMgdGhlIG5hdHVyYWwgY2hvaWNlIHRvIHByb3ZpZGUgc3VjaCBlbmQtdG8t ZW5kIGludGVncml0eQ0KICAgcHJvdGVjdGlvbiwgYXMgZGVzY3JpYmVkIGluIFs2XSBPdGhlciBh cHBsaWNhdGlvbnMgTUFZIHVzZSBhDQogICBkaWZmZXJlbnQgZm9ybSBvZiBpbnRlZ3JpdHkgcHJv dGVjdGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTY2htaWR0ICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIE1heSAzLCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5IGF0dHJpYnV0ZSAgICAgICAgICAg IE9jdG9iZXIgMjAwNg0KDQoNCjggIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgICAgQ29udGFj dCBuYW1lOiBDaHJpc3RpYW4gU2NobWlkdCBjaHJpc3RpYW4tc2NobWlkdEBzaWVtZW5zLmNvbQ0K DQogICAgICBBdHRyaWJ1dGUgbmFtZTogImRlcGVuZGVuY3kiLg0KDQogICAgICBUeXBlIG9mIGF0 dHJpYnV0ZTogTWVkaWEgbGV2ZWwuDQoNCiAgICAgIFN1YmplY3QgdG8gY2hhcnNldDogTm90Lg0K DQogICAgICBQdXJwb3NlIG9mIGF0dHJpYnV0ZTogVGhlICdkZXBlbmRlbmN5JyBhdHRyaWJ1dGUg YWxsb3dzIGRlZmluaXRpb24NCiAgICAgIG9mIG1lZGlhIHN0cmVhbSBkZXBlbmRlbmNpZXMgaW4g dGhlIG9mZmVyLiAgVGhlIG1lZGlhIHN0cmVhbQ0KICAgICAgZGVwZW5kZW5jaWVzIGFsbG93IGVz dGFibGlzaG1lbnQgb2YgbXVsdGktcGFydHkgbXVsdGltZWRpYSBzZXNzaW9uDQogICAgICB3aGVy ZSBhbGwgcGFydGljaXBhbnRzIHNoYXJlIGF0IGxlYXN0IG9uZSBjb21tb24gbWVkaWEgdHlwZS4N Cg0KICAgICAgQWxsb3dlZCBhdHRyaWJ1dGUgdmFsdWVzOiBNYW5kYXRvcnkgYW5kIG9wdGlvbmFs IGxpc3RzIG9mIHRva2Vucw0KICAgICAgd2l0aCBtZWRpYSBzdHJlYW0gbGFiZWxzDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClNjaG1pZHQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDMsIDIwMDcgICAgICAg ICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU0RQIERlcGVu ZGVuY3kgYXR0cmlidXRlICAgICAgICAgICAgT2N0b2JlciAyMDA2DQoNCg0KOSAgQWNrbm93bGVk Z2VtZW50cw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNjaG1p ZHQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDMsIDIwMDcgICAgICAgICAgICAgICAg IFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU0RQIERlcGVuZGVuY3kgYXR0 cmlidXRlICAgICAgICAgICAgT2N0b2JlciAyMDA2DQoNCg0KMTAuICBSZWZlcmVuY2VzDQoNCiAg IFsxXSAgQnJhZG5lciwgUy4sICJLZXkgV29yZHMgZm9yIFVzZSBpbiBSRkNzIHRvIEluZGljYXRl IFJlcXVpcmVtZW50DQogICAgICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5 OTcuDQoNCiAgIFsyXSAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5G IGZvciBTeW50YXgNCiAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwgTm92 ZW1iZXIgMTk5Ny4NCg0KICAgWzNdICBIYW5kbGV5LCBNLiwgSmFjb2Jzb24sIFYuLCBhbmQgQy4g UGVya2lucywgIlNEUDogU2Vzc2lvbg0KICAgICAgICBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIFJG QyA0NTY2LCBKdWx5IDIwMDYuDQoNCiAgIFs0XSAgUm9zZW5iZXJnLCBKLiBhbmQgSC4gU2NodWx6 cmlubmUsICJBbiBPZmZlci9BbnN3ZXIgTW9kZWwgd2l0aA0KICAgICAgICB0aGUgU2Vzc2lvbiBE ZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSIsIFJGQyAzMjY0LCBKdW5lIDIwMDIuDQoNCiAgIFs1 XSAgUm9zZW5iZXJnLCBKLiwgIkEgRnJhbWV3b3JrIGZvciBDb25mZXJlbmNpbmcgd2l0aCB0aGUg U2Vzc2lvbg0KICAgICAgICBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIiwgUkZDIDQzNTMsIEZl YnJ1YXJ5IDIwMDYuDQoNCiAgIFs2XSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBD YW1hcmlsbG8sIEcuLCBKb2huc3RvbiwgQS4sDQogICAgICAgIFBldGVyc29uLCBKLiwgU3Bhcmtz LCBSLiwgSGFuZGxleSwgTS4sIGFuZCBFLiBTY2hvb2xlciwgIlNJUDoNCiAgICAgICAgU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sIiwgUkZDIDMyNjEsIEp1bmUgMjAwMi4NCg0KICAgWzddICBM ZXZpbiwgTy4gYW5kIEcuIENhbWFyaWxsbywgIlRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3Rv Y29sDQogICAgICAgIChTRFApIExhYmVsIEF0dHJpYnV0ZSIsIEF1Z3VzdCAyMDA2Lg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTY2htaWR0 ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAzLCAyMDA3ICAgICAgICAgICAgICAgICBb UGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5IGF0dHJp YnV0ZSAgICAgICAgICAgIE9jdG9iZXIgMjAwNg0KDQoNCkF1dGhvcidzIEFkZHJlc3MNCg0KICAg Q2hyaXN0aWFuIFNjaG1pZHQNCiAgIFNpZW1lbnMNCiAgIFN0Li1NYXJ0aW4tU3RyLiA3Ng0KICAg TXVlbmNoZW4gIDgxNTQxDQogICBHZXJtYW55DQoNCiAgIFBob25lOiArNDkgKDg5KSA2MzYtNzUx OTINCiAgIEVtYWlsOiBjaHJpc3RpYW4tc2NobWlkdEBzaWVtZW5zLmNvbQ0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClNjaG1pZHQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDMsIDIw MDcgICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg U0RQIERlcGVuZGVuY3kgYXR0cmlidXRlICAgICAgICAgICAgT2N0b2JlciAyMDA2DQoNCg0KRnVs bCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDYpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0 cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5k IGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAgIHJldGFpbiBhbGwg dGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRI RSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1Ig SVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElO VEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVT LCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFO WSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lM TCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoN Cg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9u IHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwg UHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8N CiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9n eSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBh bnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2 YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBp bmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRp b24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRv Y3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3Bp ZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFu eQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhl IHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5z ZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0 cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4g YmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBo dHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJl c3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywg cGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAg cmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8g aW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0 aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpBY2tub3dsZWRn bWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRl ZCBieSB0aGUgSUVURg0KICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSku DQoNCg0KDQoNCg0KU2NobWlkdCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMywgMjAw NyAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQoNCg== ------_=_NextPart_001_01C6FCC7.99A1AAE3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C6FCC7.99A1AAE3-- From mmusic-bounces@ietf.org Tue Oct 31 11:55:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewtJ-0007nh-Bw; Tue, 31 Oct 2006 11:55:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewtH-0007nD-EB for mmusic@ietf.org; Tue, 31 Oct 2006 11:55:07 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewtF-0005Wa-V8 for mmusic@ietf.org; Tue, 31 Oct 2006 11:55:07 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9VGt0703926; Tue, 31 Oct 2006 11:55:00 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Tue, 31 Oct 2006 10:54:56 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC9956E@zrc2hxm0.corp.nortel.com> In-Reply-To: <581201c6fc8c$b1a57730$5b82200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Thread-Index: Acb8TXOsYqP204VgSkiNv5jx3b4IUQAPZm1AACB0vZA= From: "Francois Audet" To: "Dan Wing" , "John Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I think it would make sense to have the precedence level being conveyed in SIP, and the DSCP associated with it locally at each end. Id Alice calls Bob with precendence level X indicated in SIP, then=20 both Alice and Bob can use the DSCP coding associated by their respective network to the proper precedence level. That way, you preserve the dynamic feature of the functionality you need, but you don't need to negotiate the DSCP value dynamically. Only the precedence. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Monday, October 30, 2006 5:34 PM > To: 'John Rosenberg'; mmusic@ietf.org > Cc: jmpolk@email.cisco.com > Subject: RE: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer >=20 > > >I agree with Francois -- I need to understand the=20 > justification for=20 > > >this functionality. This seems only germain to each local network=20 > > >and I don't see the value in signaling this in SDP. > >=20 > > I think the justification here is to allow a call=20 > controller/session=20 > > manager to exert influence over the endpoints' behavior in choosing=20 > > the DSCP value to use for a bearer stream. >=20 > But this draft doesn't describe how a call controller or=20 > session manager does that. Rather, from the SIP perspective,=20 > the endpoint dreams up a DSCP value and, following this=20 > specification, declares that value in its SDP and requires=20 > its peer to use the same DSCP value. =20 >=20 > > For example in the US, > > DISA has some requirements for their Defense Information System=20 > > Network that specify that a call controller must instruct=20 > served CPE=20 > > regarding what DSCP value to use in the bearer based on the=20 > precedence=20 > > level that the user requests - this involves an authentication and=20 > > authorization to use that level in the call controller (a B2BUA). >=20 > The flow I'm imagining is this: >=20 > Call > Alice Controller B2BUA > | | | > 1. offhook-------->| | | > 2. dialed digits-->| | | > 3. |--555-1212--->| | > 4. |<--DSCP=3D0100--| | > 5. |--INVITE, a=3Ddscp:0100------>| >=20 > Where draft-polk-mmusic-dscp-attribute-00.txt is only=20 > describing message 5. > Is that about right? >=20 > > While it's interesting, and potentially useful, for one EP to tell=20 > > another "Hey, I'm going to use DSCP 41" I think that view of this=20 > > draft misses its point, and that the real power is allowing a call=20 > > controller/session manager to drive the endpoint's behavior. This=20 > > allows for all kinds of good things - like authorization - to come=20 > > into play w.r.t. use of particular DSCP values and the PHBs they=20 > > imply. >=20 > As written, the draft only describes the offerer having that=20 > privilege to decide the DSCP value it'll use in its call=20 > setup. The draft doesn't describe steps (3) and (4) in the=20 > above flow. >=20 >=20 > Now, if we imagine an *incoming* call (that is, a call going=20 > towards Alice), I could see where the B2BUA, in conjunction=20 > with the Call Controller, could decide the DSCP value for the=20 > incoming call. Something like this: >=20 > Call > Alice Controller B2BUA > | | | > 1. | | |<--INVITE To: Alice > 2. | |<-DSCP?------| > 3. | |--DSCP=3D0101->| > 4. |<-INVITE, a=3Ddscp:0101-------| >=20 > In which case the draft, as written, makes sense. >=20 >=20 > > In cases when the bearer streams cross network boundaries, I would=20 > > expect Session Boarder Controllers to rewrite the SDP and=20 > modify the=20 > > DSCP attribute as appropriate per policy - similar to how STPs that=20 > > interconnect ISUP networks modify IAMs transmitted between networks. >=20 > Yes, something needs to modify the DSCPs as they cross the=20 > network boundary. > SBCs are a heavy way to do that, but we don't have a better=20 > mechanism to do such remarking on a per-flow basis. >=20 > -d >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 12:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex0a-0006PL-Et; Tue, 31 Oct 2006 12:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex0Y-0006Kd-8n for mmusic@ietf.org; Tue, 31 Oct 2006 12:02:38 -0500 Received: from clyde.ncr.disa.mil ([164.117.144.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gex0P-0006cy-8i for mmusic@ietf.org; Tue, 31 Oct 2006 12:02:38 -0500 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by clyde.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 12:02:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer (UNCLASSIFIED) Date: Tue, 31 Oct 2006 12:02:43 -0500 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A97378@vanualevu.disanet.disa-u.mil> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC98B82@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer (UNCLASSIFIED) Thread-Index: Acb8ZpdKCysrRGS6Q3+h0pkfDLZbmAAAZoQAAClWFSA= From: "Nguyen, An P CIV NCS NC2" To: "Francois Audet" , "John Rosenberg" , "Jonathan Rosenberg" X-OriginalArrivalTime: 31 Oct 2006 17:02:44.0074 (UTC) FILETIME=[61EA1CA0:01C6FD0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Nguyen, An P CIV NCS NC2" , mmusic@ietf.org, jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE Just a clarification: Are we talking about a private network in which we can assign different DSCP codepoints for different precedence level? An -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Monday, October 30, 2006 4:14 PM To: John Rosenberg; Jonathan Rosenberg Cc: mmusic@ietf.org; jmpolk@email.cisco.com Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Well, sure, it can be dynamic based on precedence level. You could have a static rule that assigns a DSCP codepoint to different precedence level. > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com]=20 > Sent: Monday, October 30, 2006 1:00 PM > To: Jonathan Rosenberg > Cc: Audet, Francois (SC100:3055); mmusic@ietf.org;=20 > jmpolk@email.cisco.com > Subject: Re: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer >=20 > Jonathan - >=20 > At 02:46 PM 10/30/2006, Jonathan Rosenberg wrote: >=20 > >I also see no reason why the DSCP value would be dynamic=20 > (i.e., it won't >change on a call-by-call basis). It thus=20 > seems much more appropraite to >me to use whatever the=20 > configuration mechanism is for the phone. >=20 > In the DISA scenario, it absolutely can change on a call by=20 > call basis. In DISA's requirements, the bearer DSCP to use is=20 > determined based on the precedence level requested for the=20 > call, which can change for each call a user makes. The Local=20 > Call Controller serving the user's endpoint authenticates and=20 > determines whether the requested precedence level is=20 > authorized for that user. It then must instruct the endpoint=20 > what DSCP value to use for the bearer stream(s) associated=20 > with that call. >=20 > James' draft allows for exactly the necessary behavior=20 > described above. >=20 > I also believe that it does not mandate a B2BUA in the=20 > middle. If one is not there then it's an endpoint to endpoint=20 > discussion (not > negotiation) regarding the bearer DSCP that they intend to use. >=20 > John >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexuq-0005tr-OJ; Tue, 31 Oct 2006 13:00:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexuo-0005ma-3X for mmusic@ietf.org; Tue, 31 Oct 2006 13:00:46 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GexmQ-0006WU-Ve for mmusic@ietf.org; Tue, 31 Oct 2006 12:52:10 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 09:52:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VHq6LP019450; Tue, 31 Oct 2006 09:52:06 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VHq5ip029664; Tue, 31 Oct 2006 09:52:06 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Oct 2006 09:52:06 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 09:52:05 -0800 Message-ID: <45478D44.6080807@cisco.com> Date: Tue, 31 Oct 2006 12:52:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer References: <1ECE0EB50388174790F9694F77522CCF0DC9956E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC9956E@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 17:52:05.0588 (UTC) FILETIME=[471D4940:01C6FD15] DKIM-Signature: a=rsa-sha1; q=dns; l=5237; t=1162317126; x=1163181126; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20an=20Offer; X=v=3Dcisco.com=3B=20h=3DHlu7vdT84QhazwBfLUUwwAIunXo=3D; b=iO83wL4OuIiBvFhx5/1R2onw5BtYvM+VsrFNkOiq8l1So0nkjZ16oAosesusl9GIcajGHHJY UUBGrETe/V0NRHCcB6mmmAERpttEL9+zJGqI05RYfNa8wJT+3kJGdL/9; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: mmusic@ietf.org, Dan Wing , jmpolk@email.cisco.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This sounds like session policies. Session-specific ones in particular were developed to address this issue of how ones own SIP provider, if they also own the access network, can tell you want kind of media things they want you to do. -Jonathan R. Francois Audet wrote: > I think it would make sense to have the precedence level being conveyed > in SIP, and the DSCP associated with it locally at each end. > > Id Alice calls Bob with precendence level X indicated in SIP, then > both Alice and Bob can use the DSCP coding associated by their > respective > network to the proper precedence level. > > That way, you preserve the dynamic feature of the functionality you > need, but > you don't need to negotiate the DSCP value dynamically. Only the > precedence. > > >>-----Original Message----- >>From: Dan Wing [mailto:dwing@cisco.com] >>Sent: Monday, October 30, 2006 5:34 PM >>To: 'John Rosenberg'; mmusic@ietf.org >>Cc: jmpolk@email.cisco.com >>Subject: RE: [MMUSIC] New ID on conveying a DSCP >>marking/remarking in an Offer >> >> >>>>I agree with Francois -- I need to understand the >> >>justification for >> >>>>this functionality. This seems only germain to each local network >>>>and I don't see the value in signaling this in SDP. >>> >>>I think the justification here is to allow a call >> >>controller/session >> >>>manager to exert influence over the endpoints' behavior in choosing >>>the DSCP value to use for a bearer stream. >> >>But this draft doesn't describe how a call controller or >>session manager does that. Rather, from the SIP perspective, >>the endpoint dreams up a DSCP value and, following this >>specification, declares that value in its SDP and requires >>its peer to use the same DSCP value. >> >> >>>For example in the US, >>>DISA has some requirements for their Defense Information System >>>Network that specify that a call controller must instruct >> >>served CPE >> >>>regarding what DSCP value to use in the bearer based on the >> >>precedence >> >>>level that the user requests - this involves an authentication and >>>authorization to use that level in the call controller (a B2BUA). >> >>The flow I'm imagining is this: >> >> Call >> Alice Controller B2BUA >> | | | >> 1. offhook-------->| | | >> 2. dialed digits-->| | | >> 3. |--555-1212--->| | >> 4. |<--DSCP=0100--| | >> 5. |--INVITE, a=dscp:0100------>| >> >>Where draft-polk-mmusic-dscp-attribute-00.txt is only >>describing message 5. >>Is that about right? >> >> >>>While it's interesting, and potentially useful, for one EP to tell >>>another "Hey, I'm going to use DSCP 41" I think that view of this >>>draft misses its point, and that the real power is allowing a call >>>controller/session manager to drive the endpoint's behavior. This >>>allows for all kinds of good things - like authorization - to come >>>into play w.r.t. use of particular DSCP values and the PHBs they >>>imply. >> >>As written, the draft only describes the offerer having that >>privilege to decide the DSCP value it'll use in its call >>setup. The draft doesn't describe steps (3) and (4) in the >>above flow. >> >> >>Now, if we imagine an *incoming* call (that is, a call going >>towards Alice), I could see where the B2BUA, in conjunction >>with the Call Controller, could decide the DSCP value for the >>incoming call. Something like this: >> >> Call >> Alice Controller B2BUA >> | | | >> 1. | | |<--INVITE To: Alice >> 2. | |<-DSCP?------| >> 3. | |--DSCP=0101->| >> 4. |<-INVITE, a=dscp:0101-------| >> >>In which case the draft, as written, makes sense. >> >> >> >>>In cases when the bearer streams cross network boundaries, I would >>>expect Session Boarder Controllers to rewrite the SDP and >> >>modify the >> >>>DSCP attribute as appropriate per policy - similar to how STPs that >>>interconnect ISUP networks modify IAMs transmitted between networks. >> >>Yes, something needs to modify the DSCPs as they cross the >>network boundary. >>SBCs are a heavy way to do that, but we don't have a better >>mechanism to do such remarking on a per-flow basis. >> >>-d >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexvw-00071o-I8; Tue, 31 Oct 2006 13:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexvu-00070b-Fe for mmusic@ietf.org; Tue, 31 Oct 2006 13:01:54 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gexvr-0001y4-Be for mmusic@ietf.org; Tue, 31 Oct 2006 13:01:54 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2006 10:01:51 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VI1oZE004819; Tue, 31 Oct 2006 10:01:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VI1oAo026165; Tue, 31 Oct 2006 10:01:50 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Oct 2006 10:01:50 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:01:49 -0800 Message-ID: <45478F8D.40503@cisco.com> Date: Tue, 31 Oct 2006 13:01:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: derek@counterpath.com Subject: Re: [MMUSIC] ICE-12, SBCs and hotel ALGs References: <43209.10.238.10.71.1162244732.webmail@10.238.10.71> In-Reply-To: <43209.10.238.10.71.1162244732.webmail@10.238.10.71> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 18:01:50.0095 (UTC) FILETIME=[A381F9F0:01C6FD16] DKIM-Signature: a=rsa-sha1; q=dns; l=8711; t=1162317710; x=1163181710; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20ICE-12,=20SBCs=20and=20hotel=20ALGs; X=v=3Dcisco.com=3B=20h=3DyNTj2a3gvL+TLEjbgguRtrh61Zo=3D; b=TKO/Tv8wRZC8PeQM69NV/bs8P7cR8cQdtHLZ+F2SoDk67ZLZr5COTvB8dQmCNoSG1LzPQuQ0 xg+Z2x/WleH7gpFMdb+RWEsBJV8iXZ7FU2PPYDBeKTgJdoiokjqt4Hl8; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: mmusic@ietf.org, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. derek@counterpath.com wrote: > See inline. > > Jonathan Rosenberg said: > >> >> derek@counterpath.com wrote: >> >> >>> The consensus that we reached on the ICE calls was that a user >>> agent could ignore the m/c line if it couldn't validated by ICE. >>> This is needed to deal with misbehaving ALG devices, which are an >>> existing deployment issue. These devices are often not controlled >>> by the network operator, and can be seen as morally equivalent to >>> a misbehaving NAT from the ice requirements standpoint. >> >> The problem I ran into is that this is the "right" thing to do for >> those nasty ALGs, but is exactly the wrong thing to do for an SBC >> thats on the path. THe UA cannot tell which is which. So, when an >> offer shows up with an m/c-line which doesn't match a candidate, >> and it doesn't validate, is the situation that: >> >> 1. there is an SBC on the path that is ice-unaware, and it blocks >> non-RTP packets from flowing >> >> 2. there is an ALG on the path that is broken and the m/c-line it >> provided doesnt work >> >> You cannot differentiate these two cases with ICE. If you ignore >> the m/c-line assuming its case (2), and in reality its case (1), >> the call will fail. >> >> So, the mechanism that can in fact make things more reliable here >> is to deal with the ALG problem with SIP over TLS, leaving only >> case 1. Then, in case 1, you do what I described in ICE-12 - use >> the m/c-line and abort ICE processing. > > > Consider a network where the SBC is not important for anything except > NAT traversal. It is desirable to get rid of the SBC in this > network(esp. when building a new network) and use a pure TURN/ICE > approach. The TURN/ICE approach should result in less realed traffic > and will also allow easy deployment of SIP-identity and other > technololgies that require that the message body remain intact. Sure. In this use case, don't deploy an SBC. Or if you have a mix of ICE and non-ICE endpoints, have the SBC simply back off for ICE calls. It sounds like you want to support a case where the operator wants to keep their existing SBC, and by adding ICE endpoints, reduce load on the SBC by having traffic cease flowing through it when a direct path is detected by ICE. I can see why you would want to do that. However my point remains that and endpoint CANNOT TELL whether disregarding the m/c-line will result in media working or failing. > > If ICE doesn't deal with problem ALG devices TLS is required. If TLS > isn't used an SBC will be required to deal with the hotel ALG > scenario, and this SBC will have to be ICE aware for TURN to be used > at the same time. If this network requires TLS or SBCs it will have a > higher cost(initial and recurring) than the TURN/ICE approach. Also, > an ICE-aware SBC will be required for TURN to deployed. I realize that TLS is higher cost than no TLS. But its the reliability bit that gets me. Any other solution is simply not going to work reliably. > > Another consideration is the work in P2P-SIP. P2P-SIP will most > likely use ICE with some nodes acting as relay devices. So, to get > around misbehaving ALG devices P2P-sip would also require an > encrypted channel or SBC like functionality at the relay node. TLS works fine here too. > >>> A large part of this debate was around whether SBC type devices >>> needed to be ICE aware, or if ICE should be designed so that it >>> deosn't "work around" existing SBCs. I don't know if we settled >>> that debate; consensus seemd to be that it is easy for an SBC >>> vendor to disable ice. Changing ice so that the m/c line MUST >>> match a candidate assumes that the requirement is that ice not >>> bypass existing SBC devices. This includes the motivation that >>> existing SBC devices do not allow ice checks to proceed. We need >>> to resolve this SBC/ICE requirments debate if we are ever going >>> to reach consensus on ICE. >> >> THere are two cases to worry about - ICE aware and ICE-unaware >> SBCs. For ICE-aware, there are lots of things an SBC can do once it >> knows ICE is running. THis was really not the case we were worried >> about. Its an ICE-unaware SBC. >> >> I believe the requirement is that calls do not fail in the presence >> of an ICE-unaware SBC. That is the only requirement I think we >> should strive to meet. Some folks wanted the requirement to get >> around the ICE-unaware SBC if a better path was available. I >> disagree with that and I think it is a path fraught with peril. You >> simply don't know how the SBC is configured or working and you >> should not guess your way around it. An SBC is a UA, and when one >> is in the way, its like talking to an ICE-unaware UA. We should >> abort ICE. > > > Consider an existing network where the SBC is providing NAT traversal > when necessary. This is usually inefficient and a lot of traffic is > relayed unecessarily. If this network is a blood-simple SIP network > built on the internet it will probably: > > 1. Signal SIP over UDP 2. Use SBCs for NAT traversal, which are not > ICE-aware. 3. Have PSTN-SIP gateways that are not ICE-aware. 4. Does > not have control over all network elements, so will suffer from hotel > ALGs. > > To optimize traffic, the network has be upgraded to: > > 1. Have PSTN-SIP gateways that are ICE-aware. 2. Have SBCs that are > ICE-aware. 3. Deploy endpoints that are ICE-aware. > > I agree that deploying ICE in the network before the upgrade could be > harmful if the network will tear down calls that do not support the > media path. However, a network that does not have this property will > benefit from 3. There are no issues with ice when a network has 2 and > 3. But how does the endpoint know??? > > I still think the core issue is whether: 1) ICE should not 'work > around' devices that change the m/c line so it can be deployed in > noetworks that rely on traffic following a certain path without a > device being ICE-aware. 2) Networks should disable ICE if it can > cause problems. > > I'm strongly in favour of 2. ICE seems useless in type 1 networks, > as ICE processing will not occur unless the network has detected that > two ICE-aware endpoints have reach to each other before the offer > reaches the ICE-unaware SBC, or if the devices are not NATd. Of > course, ICE is accomplishing little if the devices were not behind a > NAT. I'm lost here on what a 'type 1 network' is. > > I think another reason for 2 is that it is likely that even if ICE > continues to require that the m/c line match a candidate, some ice > implementations will *not* follow this mandate as they may have been > tweaked for the TURN/ICE deployment described above. I cannot stop people from breaking the spec. We are trying to figure out what is right and codify it. > > Deploying an ICE endpoint which always attempts ICE in a network > which is not prepared for ICE will at worst result in dropped calls > for that endpoint. This should be a self-correcting problem, as the > user will either disable ICE, or change the ICE behaviour if we go > with the dual operating mode approach. ICE will be invisible. Users will not know what it is or know how to disable it. The whole idea with ICE is that it makes voip work more reliably without configuration or assumptions. You are proposing to make a bunch of assumptions and add configuration to the endpoint for voip to work. > >> >>> It seems to me that a way forward is to have two operating modes >>> for ice; one which is designed to honour existing middle boxes in >>> a deployment, and one which just tries to establish connectivity. >>> >> >> I really noodled on this for a while. Given the unpredictability of >> SBC and ALG behavior, I do not think you can write an algorithm >> which will work. The problem is that you just don't know what the >> SBC behavior is going to be. > > > I don't think we should write an algorithm, and as you say it would > be extremely difficult if not impossible. This would have to be a > configuration parameter on the endpoint. See above. I think there is no hope of user configuration for this parameter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexxE-0007ft-DP; Tue, 31 Oct 2006 13:03:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexxB-0007fl-Bm for mmusic@ietf.org; Tue, 31 Oct 2006 13:03:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gexx7-0002Mt-VN for mmusic@ietf.org; Tue, 31 Oct 2006 13:03:13 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 10:03:09 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VI395r011023; Tue, 31 Oct 2006 10:03:09 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9VI39W4015014; Tue, 31 Oct 2006 10:03:09 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:03:09 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:03:08 -0800 Message-ID: <45478FDC.4060406@cisco.com> Date: Tue, 31 Oct 2006 13:03:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] References: <5EB80D22825EEE42872083AD5BFFB5940454924E@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940454924E@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 18:03:08.0925 (UTC) FILETIME=[D27E7AD0:01C6FD16] DKIM-Signature: a=rsa-sha1; q=dns; l=1984; t=1162317789; x=1163181789; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20ICE's=20reliable=2018x=20[was=20RE=3A=20[MMUSIC]=20Remaining=20I CE=20open=20issues]; X=v=3Dcisco.com=3B=20h=3DfqeIHirKZxI5W0dxABXSu/Pi38Y=3D; b=OHtPFHhTd20IuDCwrZumZ8avyPAO1iKujOt0y2rht7fzicCD9e88BL6P5whrUBu//IwKF4sz 59l4V34HKrSDJb0JwhkGIOUEtE8Bf0Kryi21zAy/V113I3Y+yq8tH9DW; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Kevin Johns , IETF MMUSIC WG , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I'm OK with #2-#4 but I dont see the point of #1. Why? -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > >>>And, as I asked before, for how long would you keep re-transmitting >>>the 18x, if there is no STUN request coming to >>>"acknowledge" it (you cannot assume there will be a STUN request, e.g. > > in case > >>>there is some NAT/gate/GW in the path which will not pass it)? I don't > > >>>think we can use words as "send a few re-transmits", or "re-transmit > > for > >>>a while", in a standards specification. >> >>It doesn't say that. It says to use the retransmit intervals >>and timers as defined in RFC 3262, but that the >>retransmissions stop when you receive a STUN request or a >>PRACK (as opposed to just a PRACK with rfc3262). > > > I think that also the following 3262 deviations should be clarified > (eventhough one may consider them obvious), in addition to the text > saying that this 18x can not be used for offer/answer purpose: > > 1. If the UAC supports 100rel, the UAS MUST use it, and not use the STUN > request as acknowledgement. Ie the re-transmisson will not cease if a > STUN request is received before the PRACK. > > 2. If 100rel is not used, and there is no STUN request before the > re-transmission timeout (64*T1), the UAS shall not reject the INVITE > just because the 18x "failed". > > 3. The RFC3262 rule, saying that the first reliable 18x must be > acknowledged before futher reliable 18xs are sent, does not apply. > > 4. When 200 OK is sent, the re-transmission of 18x (if still ongoing) is > ceased. > > Regards, > > Christer > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexzq-0001Yn-2F; Tue, 31 Oct 2006 13:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexzo-0001YY-DX for mmusic@ietf.org; Tue, 31 Oct 2006 13:05:56 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gexzm-0003NK-1T for mmusic@ietf.org; Tue, 31 Oct 2006 13:05:56 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2006 10:05:53 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VI5oI4003962; Tue, 31 Oct 2006 10:05:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VI5oin010780; Tue, 31 Oct 2006 10:05:50 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Oct 2006 10:05:50 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:05:49 -0800 Message-ID: <4547907D.1060406@cisco.com> Date: Tue, 31 Oct 2006 13:05:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-ice-11 References: <4545007D.2080109@db.org> In-Reply-To: <4545007D.2080109@db.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 18:05:49.0864 (UTC) FILETIME=[326BD280:01C6FD17] DKIM-Signature: a=rsa-sha1; q=dns; l=2014; t=1162317950; x=1163181950; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[MMUSIC]=20Comments=20on=20draft-ietf-mmusic-ice-11; X=v=3Dcisco.com=3B=20h=3D7s//PGyXLgPCRZT8JuxtBZWVoZc=3D; b=aSe+z9CoAyJZ9woh1+hG1d6D2NXkeuvkXKfqUTEiT+1YUEBbrCaUtl+X8FYnoQGGgWL7mSIT AK8/9PixocmHFnutf9C+6XFZdp4vh0lR09hHzd6Lb+3wJ6oiTN1n3DGb; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks. I've incorporated these into my working version of -13. -Jonathan R. Alfred E. Heggestad wrote: > hi > > here are some comment on some minor things in draft-ietf-mmusic-ice-11: > > > > > > Section 4.1. Gathering Candidates > > > > Agents which serve end users directly, such softphones, hardphones, > > ^^^^^^^^^^^^^^^ > > > typo -> should be "such as" > > > > > > Section 5.6. Forming the Check Lists > > > > pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P:1?0) > > > > Where O-P>A-P:1?0 is an expression whose value is 1 if O-P is greater > > > > > it would be better to write "O-P>A-P:1?0" as "O-P>A-P?1:0", i.e. where the > question mark and the colon are swapped. this is standard C syntax, and > will evalate to 1 if O-P>A-P and 0 if not. > > > > > > Section 7.7.2. Processing the Response > > > > the agent knows about, the mapped address representes a new peer > > ^^^^^^^^^^^ > > > typo -> should be "represents" > > > > > > Section 8. Completing the ICE Checks > > > > When a pair is aded to the valid list, and the agent was the answerer > > ^^^^ > > typo -> should be "added" > > > > > > Section 8. Completing the ICE Checks > > > > assymetric. It is possible to fix both of these problems by > > ^^^^^^^^^^ > > typo. should be "asymmetric" > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey2p-0002o4-Uc; Tue, 31 Oct 2006 13:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey2h-0002md-VB for mmusic@ietf.org; Tue, 31 Oct 2006 13:09:00 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gey2Z-0004Oz-8c for mmusic@ietf.org; Tue, 31 Oct 2006 13:08:55 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A10E0538; Tue, 31 Oct 2006 13:08:14 -0500 From: "Hadriel Kaplan" To: "'Elwell, John'" , "'Dan Wing'" , "'Francois Audet'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Tue, 31 Oct 2006 13:08:14 -0500 Message-ID: <00c001c6fd17$887daa90$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb8xXNPrdNyK/VbQJqGuEEwTE09iwAUB0ew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D7852@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, October 31, 2006 3:21 AM > > [JRE] If SDescriptions has a different payload type, then you know that if > you receive this payload type before the SDP answer you cannot render it, > whereas if you receive a payload type for RTP or for SRTP using certain > MIKEY options you can indeed render the payload. Exactly. And if you make a new offer later, or your original offer got forked, you can decide when/what can be rendered or not. So it also helps if you get both RTP and SRTP at the same time during a transition period. (ie, the item for further study in your draft-wing-media-security-requirements-00.txt, labeled "A solution SHOULD allow to start with RTP and then upgrade to SRTP") -hadriel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey8h-0007F0-7s; Tue, 31 Oct 2006 13:15:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey8R-00073T-LD for mmusic@ietf.org; Tue, 31 Oct 2006 13:14:51 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gey8O-0005i3-Av for mmusic@ietf.org; Tue, 31 Oct 2006 13:14:51 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9VIEkca007903; Tue, 31 Oct 2006 11:14:47 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] ICE-12: conditions for verifying ICE support Date: Tue, 31 Oct 2006 11:14:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-12: conditions for verifying ICE support Thread-Index: Acb8bs2VIjigA/NCRRC1ePJv3VvLgwAnBjLQ From: "Jean-Francois Mule" To: "Jonathan Rosenberg" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is mostly a question for clarification on what conditions define ICE is supported on the receiving side. I understand this text may be affected by the pending consensus on the scope of ICE and resolution w.r.t. the SBCs and hotel ALGs. In section 6.1, page 22 of ice-12, it says: |6.1. Verifying ICE Support | | The answerer will proceed with the ICE procedures defined in this | specification if the following are true: | # condition 1 | o There is at least one a=3Dcandidate attribute for each media stream | in the offer it just received. | # condition 2 | o For each media stream, at least one of the candidates is a match | for its respective in-use component in the m/c-line. Doesn't the second condition suffice?=20 In other words, is there a case where condition#2 is met but #1 is not? Are these conditions equivalent to: "For each media description, at least one candidate must be an in-use candidate as defined in section 5.3." I'm not sure your usage of "component" here means media stream component (RTP component ID 1, etc.) or whether it points to an element of a candidate (IP add, port, ...). Also, it may help to clarify the use of "m/c-line" and may be expand it as you may have multiple c lines, one for the session level, one for each media description. This applies at several places in the document. It may help to clarify the definition of "in-use" in section 5.3 to say something like: A candidate is defined as an "in-use" candidate in a media description if its IP address appears in the associated c line and its port in the related m line...=20 Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geye4-0005cS-9H; Tue, 31 Oct 2006 13:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geye2-0005bS-DF for mmusic@ietf.org; Tue, 31 Oct 2006 13:47:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geydz-0007nu-2X for mmusic@ietf.org; Tue, 31 Oct 2006 13:47:30 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 10:47:27 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VIlQWF011131; Tue, 31 Oct 2006 10:47:26 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VIlQOV028385; Tue, 31 Oct 2006 10:47:26 -0800 (PST) From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Elwell, John'" , "'Francois Audet'" , Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt Date: Tue, 31 Oct 2006 10:47:26 -0800 Keywords: direct-to-dwing Message-ID: <05ba01c6fd1d$02a933c0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb8xXNPrdNyK/VbQJqGuEEwTE09iwAUB0ewAAG+WYA= In-Reply-To: <00c001c6fd17$887daa90$0500a8c0@acmepacket.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1196; t=1162320446; x=1163184446; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20RE=3A=20I-D=20ACTION=3Adraft-kaplan-mmusic-best-effor t-srtp-01.txt; X=v=3Dcisco.com=3B=20h=3D6EKcEWaPdoq7FL3/T62WYxpNN8Q=3D; b=A9uK2vwDju2xy1G2B2yFXt/M64et8KqiwZTAAB3xHAtYN4S3H57IRjDgfbG5TZd0vDjl8iSO mCBHKRrvZtB4GKbQGtMQ3xtClRAvMx/hq/FvT2OhFHIIW3lV50HhraxA; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, October 31, 2006 3:21 AM > > > > [JRE] If SDescriptions has a different payload type, then > > you know that if > > you receive this payload type before the SDP answer you > > cannot render it, > > whereas if you receive a payload type for RTP or for SRTP > > using certain MIKEY options you can indeed render the > > payload. > > Exactly. Ok, thanks. Makes sense to me now. > And if you make a new offer later, or your original offer got > forked, you can decide when/what can be rendered or not. So > it also helps if you get both RTP and SRTP at the same > time during a transition period. (ie, the item for further > study in your draft-wing-media-security-requirements-00.txt, > labeled "A solution SHOULD allow to start with RTP and then > upgrade to SRTP") Yeah, there are two cases hidden there, I believe: one is what ZRTP does today ('upgrading' a connection), and another is handling RTP early media as described by draft-stucker-sipping-early-media-coping-03.txt, where the RTP is coming from RTP endpoints that aren't the final endpoint. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 13:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyoq-0002b5-M7; Tue, 31 Oct 2006 13:58:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyoo-0002b0-NB for mmusic@ietf.org; Tue, 31 Oct 2006 13:58:38 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geyoi-0002XM-SS for mmusic@ietf.org; Tue, 31 Oct 2006 13:58:38 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id k9VIwSSw029486; Tue, 31 Oct 2006 12:58:29 -0600 (CST) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.234.25]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k9VIwSP27021; Tue, 31 Oct 2006 12:58:28 -0600 (CST) Message-Id: <200610311858.k9VIwSP27021@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Oct 2006 12:58:23 -0600 To: "Nguyen, An P CIV NCS NC2" , "Francois Audet" , "Jonathan Rosenberg" From: John Rosenberg Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer (UNCLASSIFIED) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A97378@vanualevu.disanet.d isa-u.mil> References: <1ECE0EB50388174790F9694F77522CCF0DC98B82@zrc2hxm0.corp.nortel.com> <9B4320CC9BC1D847AFFA97F25A422A59A97378@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: "James M. Polk" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The DISA example is, in fact, a private network. But there are similar applications in the public network (e.g. 911, GETS/ETS) that could benefit from having a call controller or app server instruct endpoints what DSCP values they should use on a call by call basis. At 11:02 AM 10/31/2006, Nguyen, An P CIV NCS NC2 wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Just a clarification: Are we talking about a private network in which we >can assign different DSCP codepoints for different precedence level? > >An > >-----Original Message----- >From: Francois Audet [mailto:audet@nortel.com] >Sent: Monday, October 30, 2006 4:14 PM >To: John Rosenberg; Jonathan Rosenberg >Cc: mmusic@ietf.org; jmpolk@email.cisco.com >Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an >Offer > >Well, sure, it can be dynamic based on precedence level. > >You could have a static rule that assigns a DSCP codepoint >to different precedence level. > >> -----Original Message----- >> From: John Rosenberg [mailto:jrrosenberg@lucent.com] >> Sent: Monday, October 30, 2006 1:00 PM >> To: Jonathan Rosenberg >> Cc: Audet, Francois (SC100:3055); mmusic@ietf.org; >> jmpolk@email.cisco.com >> Subject: Re: [MMUSIC] New ID on conveying a DSCP >> marking/remarking in an Offer >> >> Jonathan - >> >> At 02:46 PM 10/30/2006, Jonathan Rosenberg wrote: >> >> >I also see no reason why the DSCP value would be dynamic >> (i.e., it won't >change on a call-by-call basis). It thus >> seems much more appropraite to >me to use whatever the >> configuration mechanism is for the phone. >> >> In the DISA scenario, it absolutely can change on a call by >> call basis. In DISA's requirements, the bearer DSCP to use is >> determined based on the precedence level requested for the >> call, which can change for each call a user makes. The Local >> Call Controller serving the user's endpoint authenticates and >> determines whether the requested precedence level is >> authorized for that user. It then must instruct the endpoint >> what DSCP value to use for the bearer stream(s) associated >> with that call. >> >> James' draft allows for exactly the necessary behavior >> described above. >> >> I also believe that it does not mandate a B2BUA in the >> middle. If one is not there then it's an endpoint to endpoint >> discussion (not >> negotiation) regarding the bearer DSCP that they intend to use. >> >> John >> >> > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic >Classification: UNCLASSIFIED >Caveats: NONE _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 14:26:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezEv-00052j-Jh; Tue, 31 Oct 2006 14:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezEs-00051W-3k for mmusic@ietf.org; Tue, 31 Oct 2006 14:25:36 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezEo-0000cY-Oj for mmusic@ietf.org; Tue, 31 Oct 2006 14:25:34 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9VJIdj19986; Tue, 31 Oct 2006 14:18:39 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer (UNCLASSIFIED) Date: Tue, 31 Oct 2006 13:25:14 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC99965@zrc2hxm0.corp.nortel.com> In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A97378@vanualevu.disanet.disa-u.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer (UNCLASSIFIED) Thread-Index: Acb8ZpdKCysrRGS6Q3+h0pkfDLZbmAAAZoQAAClWFSAABR8zMA== From: "Francois Audet" To: "Nguyen, An P CIV NCS NC2" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Different networks (private or public: doesn't matter) may use different DSCP values for the same type of traffic (e.g., voice with precedence x). > -----Original Message----- > From: Nguyen, An P CIV NCS NC2 [mailto:an.p.nguyen@dhs.gov]=20 > Sent: Tuesday, October 31, 2006 9:03 AM > To: Audet, Francois (SC100:3055); John Rosenberg; Jonathan Rosenberg > Cc: mmusic@ietf.org; jmpolk@email.cisco.com; Nguyen, An P CIV NCS NC2 > Subject: RE: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer (UNCLASSIFIED) >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Just a clarification: Are we talking about a private network=20 > in which we can assign different DSCP codepoints for=20 > different precedence level? >=20 > An >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, October 30, 2006 4:14 PM > To: John Rosenberg; Jonathan Rosenberg > Cc: mmusic@ietf.org; jmpolk@email.cisco.com > Subject: RE: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in an Offer >=20 > Well, sure, it can be dynamic based on precedence level. >=20 > You could have a static rule that assigns a DSCP codepoint to=20 > different precedence level. >=20 > > -----Original Message----- > > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > > Sent: Monday, October 30, 2006 1:00 PM > > To: Jonathan Rosenberg > > Cc: Audet, Francois (SC100:3055); mmusic@ietf.org;=20 > > jmpolk@email.cisco.com > > Subject: Re: [MMUSIC] New ID on conveying a DSCP=20 > marking/remarking in=20 > > an Offer > >=20 > > Jonathan - > >=20 > > At 02:46 PM 10/30/2006, Jonathan Rosenberg wrote: > >=20 > > >I also see no reason why the DSCP value would be dynamic=20 > (i.e., it=20 > > won't >change on a call-by-call basis). It thus seems much more=20 > > appropraite to >me to use whatever the configuration=20 > mechanism is for=20 > > the phone. > >=20 > > In the DISA scenario, it absolutely can change on a call by call=20 > > basis. In DISA's requirements, the bearer DSCP to use is determined=20 > > based on the precedence level requested for the call, which=20 > can change=20 > > for each call a user makes. The Local Call Controller serving the=20 > > user's endpoint authenticates and determines whether the requested=20 > > precedence level is authorized for that user. It then must instruct=20 > > the endpoint what DSCP value to use for the bearer stream(s)=20 > > associated with that call. > >=20 > > James' draft allows for exactly the necessary behavior described=20 > > above. > >=20 > > I also believe that it does not mandate a B2BUA in the=20 > middle. If one=20 > > is not there then it's an endpoint to endpoint discussion (not > > negotiation) regarding the bearer DSCP that they intend to use. > >=20 > > John > >=20 > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > Classification: UNCLASSIFIED > Caveats: NONE >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 14:30:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezJY-0001Qg-1u; Tue, 31 Oct 2006 14:30:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezJW-0001P1-4C for mmusic@ietf.org; Tue, 31 Oct 2006 14:30:22 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezJP-0001wd-Jv for mmusic@ietf.org; Tue, 31 Oct 2006 14:30:22 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0DA14787; Tue, 31 Oct 2006 20:30:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 20:30:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Date: Tue, 31 Oct 2006 20:29:55 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB594045A33C4@esealmw113.eemea.ericsson.se> In-Reply-To: <45478FDC.4060406@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues] Thread-Index: Acb9FtRNzaLJTFC8RnSUIIAss/6cgQAC3hDg From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 31 Oct 2006 19:30:14.0833 (UTC) FILETIME=[FD60C210:01C6FD22] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Kevin Johns , IETF MMUSIC WG , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >I'm OK with #2-#4 but I dont see the point of #1. Why? I was maybe a little unclear. What I meant was that if both the UAC AND the UAS support 100rel, they should use it, because if reliable transport of 18x is needed I think that the standardized 100rel mechanism should be used.=20 I think that the STUN-acknowledgement mechanism should only be used if 100rel is not supported. Isn't that the reason the STUN-acknowledgement was defined in the first place - to allow UASs that do not support 100rel to still use ICE? Regards, Christer > Christer Holmberg (JO/LMF) wrote: >=20 > > Hi, > >=20 > >=20 > >>>And, as I asked before, for how long would you keep=20 > re-transmitting=20 > >>>the 18x, if there is no STUN request coming to=20 > "acknowledge" it (you=20 > >>>cannot assume there will be a STUN request, e.g. > >=20 > > in case > >=20 > >>>there is some NAT/gate/GW in the path which will not pass it)? I=20 > >>>don't > >=20 > >=20 > >>>think we can use words as "send a few re-transmits", or=20 > "re-transmit > >=20 > > for > >=20 > >>>a while", in a standards specification. > >> > >>It doesn't say that. It says to use the retransmit intervals and=20 > >>timers as defined in RFC 3262, but that the retransmissions=20 > stop when=20 > >>you receive a STUN request or a PRACK (as opposed to just a=20 > PRACK with=20 > >>rfc3262). > >=20 > >=20 > > I think that also the following 3262 deviations should be clarified=20 > > (eventhough one may consider them obvious), in addition to the text=20 > > saying that this 18x can not be used for offer/answer purpose: > >=20 > > 1. If the UAC supports 100rel, the UAS MUST use it, and not use the=20 > > STUN request as acknowledgement. Ie the re-transmisson will=20 > not cease=20 > > if a STUN request is received before the PRACK. > >=20 > > 2. If 100rel is not used, and there is no STUN request before the=20 > > re-transmission timeout (64*T1), the UAS shall not reject=20 > the INVITE=20 > > just because the 18x "failed". > >=20 > > 3. The RFC3262 rule, saying that the first reliable 18x must be=20 > > acknowledged before futher reliable 18xs are sent, does not apply. > >=20 > > 4. When 200 OK is sent, the re-transmission of 18x (if=20 > still ongoing)=20 > > is ceased. > >=20 > > Regards, > >=20 > > Christer > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 16:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0xj-0002KL-81; Tue, 31 Oct 2006 16:15:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0oq-00049T-2Z for mmusic@ietf.org; Tue, 31 Oct 2006 16:06:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0om-0000Y2-Na for mmusic@ietf.org; Tue, 31 Oct 2006 16:06:48 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 13:06:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VL6dRl028022; Tue, 31 Oct 2006 13:06:39 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VL6cOV026816; Tue, 31 Oct 2006 13:06:38 -0800 (PST) From: "Dan Wing" To: "'Desineni, Harikishan'" , "'Joerg Ott'" , "'Francois Audet'" Date: Tue, 31 Oct 2006 13:06:37 -0800 Keywords: direct-to-dwing Message-ID: <072201c6fd30$750b9a30$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb6ac+20tzo+Eq7SjOMGB6Vbm4jqgAPyFuwAJ6EedAAA0j28A== In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B0227B3D8@NAEX01.na.qualcomm.com> DKIM-Signature: a=rsa-sha1; q=dns; l=2576; t=1162328799; x=1163192799; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20alternate=20RTP=20profiles=20in=20SDP=20offer/answer; X=v=3Dcisco.com=3B=20h=3D2RoD1c0r/wUQSJGoxCviAgiR1+k=3D; b=EMi8sMPpMxXVpEe1GNZ1fT7IpA574aqeI2freNwbItiW/SyHUVPm9hUZ4U981dJEiTQdw/1b P6Wzvje5F66L1XcpnaiRw+U5AWa73mddjhQsannRo86GS0Rn0MBJ1W1j; Authentication-Results: sj-dkim-5.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Tue, 31 Oct 2006 16:15:55 -0500 Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, "'Srinivasamurthy, Naveen'" , "'Jayaram, Ranjith'" , 'Flemming Andreasen' , 'Joerg Ott' , "'Ludwin, Albert'" , "'Leung, Nikolai'" Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > RFC4585, Section 4.4, Example 3 allows grouping of media > lines with the same transport address and port. I copied > it below FYI. Even though RFC 3388 prohibits such > transport overloading, RFC 4585 allows such signaling for > profile negotiation (between RTP/AVP and RTP/AVPF). Are we going to declare RFC4585's example normative? > Indeed, RFC4585 is referring to RFC 3388 for such grouping. > Per RFC4585, > overloading two "m=" lines isn't a violation of the standard when > negotiating RTP/AVP and RTP/AVPF profiles. Unfortunately, though, SDP parsers that don't implement RFC4585 aren't aware of RFC4585's permission to do this. > It is an already established > concept in RFC4585. Probably there are existing implementations which > already support such signaling. Any new signaling solution can only be > an alternative to the solution used in the following example. Is there consensus in MMUSIC with that position? -d > ---> > m=video 51372 RTP/AVP 98 99 > c=IN IP4 224.2.1.184 > a=rtpmap:98 H263-1998/90000 > a=rtpmap:99 H261/90000 > m=video 51372 RTP/AVPF 98 99 > c=IN IP4 224.2.1.184 > a=rtpmap:98 H263-1998/90000 > a=rtpmap:99 H261/90000 > a=rtcp-fb:* nack > a=rtcp-fb:98 nack rpsi > Note that these two m= lines SHOULD be grouped by some appropriate > mechanism to indicate that both are alternatives actually conveying > the same contents. A sample framework by which this can be > achieved is defined in [10]. > > > > -----Original Message----- > > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > > rtpsec@mail.imc.org] On Behalf Of Dan Wing > > Sent: Monday, October 30, 2006 2:58 PM > > To: 'Joerg Ott' > > Cc: mmusic@ietf.org; 'Joerg Ott'; carrara@kth.se; 'Flemming > Andreasen'; > > 'Hadriel Kaplan'; 'Francois Audet'; ietf-rtpsec@imc.org > > Subject: RE: alternate RTP profiles in SDP offer/answer > > > > > . > > > > ----- > > > > 2. Section 3.3.2: > > > > To offer two or more alternative RTP > > profiles for a particular media stream, the SDP description MUST > > contain exactly one m= line for this media stream for > each profile > > and all the same transport address (IP address and port number). > > > > This requirement makes sense if you're using grouping (RFC3388), so > > prefixing this with "If using RFC3388, ..." seems suitable. > > > > However, note that section 7.5.3 RFC3388 explitictly prohibits using > the > > same transport address. > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 16:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0xi-0002Hq-Lm; Tue, 31 Oct 2006 16:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezdQ-0003uQ-Pg for mmusic@ietf.org; Tue, 31 Oct 2006 14:50:56 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezdJ-0005Yr-HM for mmusic@ietf.org; Tue, 31 Oct 2006 14:50:56 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9VJogDx028667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 31 Oct 2006 11:50:43 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9VJoVtH014086; Tue, 31 Oct 2006 11:50:39 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:50:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2006 11:50:37 -0800 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B0227B3D8@NAEX01.na.qualcomm.com> In-Reply-To: <564501c6fc76$de9c8d20$5b82200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: alternate RTP profiles in SDP offer/answer Thread-Index: Acb6ac+20tzo+Eq7SjOMGB6Vbm4jqgAPyFuwAJ6EedA= From: "Desineni, Harikishan" To: "Dan Wing" , "Joerg Ott" , "Francois Audet" X-OriginalArrivalTime: 31 Oct 2006 19:50:38.0862 (UTC) FILETIME=[D6F4C2E0:01C6FD25] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Tue, 31 Oct 2006 16:15:56 -0500 Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, "Srinivasamurthy, Naveen" , "Jayaram, Ranjith" , Flemming Andreasen , Joerg Ott , "Ludwin, Albert" , "Leung, Nikolai" Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org RFC4585, Section 4.4, Example 3 allows grouping of media lines with the same transport address and port. I copied it below FYI. Even though RFC 3388 prohibits such transport overloading, RFC 4585 allows such signaling for profile negotiation (between RTP/AVP and RTP/AVPF). Indeed, RFC4585 is referring to RFC 3388 for such grouping. Per RFC4585, overloading two "m=3D" lines isn't a violation of the standard when negotiating RTP/AVP and RTP/AVPF profiles. It is an already established concept in RFC4585. Probably there are existing implementations which already support such signaling. Any new signaling solution can only be an alternative to the solution used in the following example. ---> m=3Dvideo 51372 RTP/AVP 98 99 c=3DIN IP4 224.2.1.184 a=3Drtpmap:98 H263-1998/90000 a=3Drtpmap:99 H261/90000 m=3Dvideo 51372 RTP/AVPF 98 99 c=3DIN IP4 224.2.1.184 a=3Drtpmap:98 H263-1998/90000 a=3Drtpmap:99 H261/90000 a=3Drtcp-fb:* nack a=3Drtcp-fb:98 nack rpsi Note that these two m=3D lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying the same contents. A sample framework by which this can be achieved is defined in [10]. > -----Original Message----- > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > rtpsec@mail.imc.org] On Behalf Of Dan Wing > Sent: Monday, October 30, 2006 2:58 PM > To: 'Joerg Ott' > Cc: mmusic@ietf.org; 'Joerg Ott'; carrara@kth.se; 'Flemming Andreasen'; > 'Hadriel Kaplan'; 'Francois Audet'; ietf-rtpsec@imc.org > Subject: RE: alternate RTP profiles in SDP offer/answer >=20 >=20 . >=20 > ----- >=20 > 2. Section 3.3.2: >=20 > To offer two or more alternative RTP > profiles for a particular media stream, the SDP description MUST > contain exactly one m=3D line for this media stream for each = profile > and all the same transport address (IP address and port number). >=20 > This requirement makes sense if you're using grouping (RFC3388), so > prefixing this with "If using RFC3388, ..." seems suitable. >=20 > However, note that section 7.5.3 RFC3388 explitictly prohibits using the > same transport address. >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 16:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0xj-0002KL-81; Tue, 31 Oct 2006 16:15:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0oq-00049T-2Z for mmusic@ietf.org; Tue, 31 Oct 2006 16:06:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0om-0000Y2-Na for mmusic@ietf.org; Tue, 31 Oct 2006 16:06:48 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 13:06:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VL6dRl028022; Tue, 31 Oct 2006 13:06:39 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VL6cOV026816; Tue, 31 Oct 2006 13:06:38 -0800 (PST) From: "Dan Wing" To: "'Desineni, Harikishan'" , "'Joerg Ott'" , "'Francois Audet'" Date: Tue, 31 Oct 2006 13:06:37 -0800 Keywords: direct-to-dwing Message-ID: <072201c6fd30$750b9a30$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb6ac+20tzo+Eq7SjOMGB6Vbm4jqgAPyFuwAJ6EedAAA0j28A== In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B0227B3D8@NAEX01.na.qualcomm.com> DKIM-Signature: a=rsa-sha1; q=dns; l=2576; t=1162328799; x=1163192799; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20alternate=20RTP=20profiles=20in=20SDP=20offer/answer; X=v=3Dcisco.com=3B=20h=3D2RoD1c0r/wUQSJGoxCviAgiR1+k=3D; b=EMi8sMPpMxXVpEe1GNZ1fT7IpA574aqeI2freNwbItiW/SyHUVPm9hUZ4U981dJEiTQdw/1b P6Wzvje5F66L1XcpnaiRw+U5AWa73mddjhQsannRo86GS0Rn0MBJ1W1j; Authentication-Results: sj-dkim-5.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Tue, 31 Oct 2006 16:15:55 -0500 Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, "'Srinivasamurthy, Naveen'" , "'Jayaram, Ranjith'" , 'Flemming Andreasen' , 'Joerg Ott' , "'Ludwin, Albert'" , "'Leung, Nikolai'" Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > RFC4585, Section 4.4, Example 3 allows grouping of media > lines with the same transport address and port. I copied > it below FYI. Even though RFC 3388 prohibits such > transport overloading, RFC 4585 allows such signaling for > profile negotiation (between RTP/AVP and RTP/AVPF). Are we going to declare RFC4585's example normative? > Indeed, RFC4585 is referring to RFC 3388 for such grouping. > Per RFC4585, > overloading two "m=" lines isn't a violation of the standard when > negotiating RTP/AVP and RTP/AVPF profiles. Unfortunately, though, SDP parsers that don't implement RFC4585 aren't aware of RFC4585's permission to do this. > It is an already established > concept in RFC4585. Probably there are existing implementations which > already support such signaling. Any new signaling solution can only be > an alternative to the solution used in the following example. Is there consensus in MMUSIC with that position? -d > ---> > m=video 51372 RTP/AVP 98 99 > c=IN IP4 224.2.1.184 > a=rtpmap:98 H263-1998/90000 > a=rtpmap:99 H261/90000 > m=video 51372 RTP/AVPF 98 99 > c=IN IP4 224.2.1.184 > a=rtpmap:98 H263-1998/90000 > a=rtpmap:99 H261/90000 > a=rtcp-fb:* nack > a=rtcp-fb:98 nack rpsi > Note that these two m= lines SHOULD be grouped by some appropriate > mechanism to indicate that both are alternatives actually conveying > the same contents. A sample framework by which this can be > achieved is defined in [10]. > > > > -----Original Message----- > > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > > rtpsec@mail.imc.org] On Behalf Of Dan Wing > > Sent: Monday, October 30, 2006 2:58 PM > > To: 'Joerg Ott' > > Cc: mmusic@ietf.org; 'Joerg Ott'; carrara@kth.se; 'Flemming > Andreasen'; > > 'Hadriel Kaplan'; 'Francois Audet'; ietf-rtpsec@imc.org > > Subject: RE: alternate RTP profiles in SDP offer/answer > > > > > . > > > > ----- > > > > 2. Section 3.3.2: > > > > To offer two or more alternative RTP > > profiles for a particular media stream, the SDP description MUST > > contain exactly one m= line for this media stream for > each profile > > and all the same transport address (IP address and port number). > > > > This requirement makes sense if you're using grouping (RFC3388), so > > prefixing this with "If using RFC3388, ..." seems suitable. > > > > However, note that section 7.5.3 RFC3388 explitictly prohibits using > the > > same transport address. > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 16:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0xi-0002Hq-Lm; Tue, 31 Oct 2006 16:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezdQ-0003uQ-Pg for mmusic@ietf.org; Tue, 31 Oct 2006 14:50:56 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezdJ-0005Yr-HM for mmusic@ietf.org; Tue, 31 Oct 2006 14:50:56 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9VJogDx028667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 31 Oct 2006 11:50:43 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9VJoVtH014086; Tue, 31 Oct 2006 11:50:39 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:50:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2006 11:50:37 -0800 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B0227B3D8@NAEX01.na.qualcomm.com> In-Reply-To: <564501c6fc76$de9c8d20$5b82200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: alternate RTP profiles in SDP offer/answer Thread-Index: Acb6ac+20tzo+Eq7SjOMGB6Vbm4jqgAPyFuwAJ6EedA= From: "Desineni, Harikishan" To: "Dan Wing" , "Joerg Ott" , "Francois Audet" X-OriginalArrivalTime: 31 Oct 2006 19:50:38.0862 (UTC) FILETIME=[D6F4C2E0:01C6FD25] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Tue, 31 Oct 2006 16:15:56 -0500 Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, "Srinivasamurthy, Naveen" , "Jayaram, Ranjith" , Flemming Andreasen , Joerg Ott , "Ludwin, Albert" , "Leung, Nikolai" Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org RFC4585, Section 4.4, Example 3 allows grouping of media lines with the same transport address and port. I copied it below FYI. Even though RFC 3388 prohibits such transport overloading, RFC 4585 allows such signaling for profile negotiation (between RTP/AVP and RTP/AVPF). Indeed, RFC4585 is referring to RFC 3388 for such grouping. Per RFC4585, overloading two "m=3D" lines isn't a violation of the standard when negotiating RTP/AVP and RTP/AVPF profiles. It is an already established concept in RFC4585. Probably there are existing implementations which already support such signaling. Any new signaling solution can only be an alternative to the solution used in the following example. ---> m=3Dvideo 51372 RTP/AVP 98 99 c=3DIN IP4 224.2.1.184 a=3Drtpmap:98 H263-1998/90000 a=3Drtpmap:99 H261/90000 m=3Dvideo 51372 RTP/AVPF 98 99 c=3DIN IP4 224.2.1.184 a=3Drtpmap:98 H263-1998/90000 a=3Drtpmap:99 H261/90000 a=3Drtcp-fb:* nack a=3Drtcp-fb:98 nack rpsi Note that these two m=3D lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying the same contents. A sample framework by which this can be achieved is defined in [10]. > -----Original Message----- > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > rtpsec@mail.imc.org] On Behalf Of Dan Wing > Sent: Monday, October 30, 2006 2:58 PM > To: 'Joerg Ott' > Cc: mmusic@ietf.org; 'Joerg Ott'; carrara@kth.se; 'Flemming Andreasen'; > 'Hadriel Kaplan'; 'Francois Audet'; ietf-rtpsec@imc.org > Subject: RE: alternate RTP profiles in SDP offer/answer >=20 >=20 . >=20 > ----- >=20 > 2. Section 3.3.2: >=20 > To offer two or more alternative RTP > profiles for a particular media stream, the SDP description MUST > contain exactly one m=3D line for this media stream for each = profile > and all the same transport address (IP address and port number). >=20 > This requirement makes sense if you're using grouping (RFC3388), so > prefixing this with "If using RFC3388, ..." seems suitable. >=20 > However, note that section 7.5.3 RFC3388 explitictly prohibits using the > same transport address. >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1xv-000162-Uh; Tue, 31 Oct 2006 17:20:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1xs-00015w-VY for mmusic@ietf.org; Tue, 31 Oct 2006 17:20:12 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1xq-0008DC-00 for mmusic@ietf.org; Tue, 31 Oct 2006 17:20:12 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 14:20:10 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMK94S022503; Tue, 31 Oct 2006 17:20:09 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMK9YJ028101; Tue, 31 Oct 2006 17:20:09 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:20:09 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:20:08 -0500 Message-Id: <4.3.2.7.2.20061031155231.0349b160@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:03:59 -0600 To: "Francois Audet" , From: "James M. Polk" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCA8D@zrc2hxm0.corp.nor tel.com> References: <4.3.2.7.2.20061026173826.03a90de8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:20:09.0115 (UTC) FILETIME=[B9A4BEB0:01C6FD3A] DKIM-Signature: a=rsa-sha1; q=dns; l=3167; t=1162333209; x=1163197209; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=0A=20=20an=20Offer |To:=22Francois=20Audet=22=20,=20; X=v=3Dcisco.com=3B=20h=3D7EWGNVsPmFcg19NDB5SiWst/rtM=3D; b=RlXW3vRD1GNLAYiW9q9rOIKQm9hYJF4w5Wjv+WGrcMNRv85U0dBxk5NDJovRnqAFtX9cJz5b 6rM8Mexuj+rzF2LV9MCx6dZag50roKdcsk432AOp3VaAtDoYlhjHfDzT; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org First of all, sorry for not responding earlier comments in-line At 07:34 PM 10/26/2006 -0500, Francois Audet wrote: >Hi James, > >I'm not sure I see the rationale for negotiating DSCP in SDP. > >In environments that span networks, different numerical values could be >used >(and the packets could be re-mapped accordingly at the border of these >networks). and that leaves all the control at the border, and zero in the middle of the network (i.e. no server can change a value). This proposal allows for a server that can change the SDP of an offer/answer to inform the offerer or answerer what DSCP to use per media session (different for each media too) >It seems to me to be more a matter of config-framework. > >And within a single network, both ends would get the same values >from the config-framework. Will all UAs understand to use a specific DSCP for their RTP, or is this more hopeful? This mechanism provides a way for domains that have controlling intermediaries to include what DSCP to use for voice, and what to use for video. If network conditions change (for whatever reason) during a (voice or video) call, each media can be changed to a new DSCP. >Within different networks, they'd get different values (which is the >desired outcome). And when conditions change, say when a resrevation is lost, but local policy is to not terminate the call - but the DSCP has to change, this mechanism does that >Also seems to me that this idea has the whole that it may result in the >answered being inadvertently tricked into using the wrong DSCP (e.g, >a more expensive one, a lesser-quality one, etc.). OK, but the only entities that should be mucking with the DSCP are intermediary SIP servers, which have to be inplicitly trusted anyway, I'm not sure how this has less trust than other aspects of a offer/answer exchange >I'd like to understand why you believe that handling DSCP through >configuration (e.g, config-framework) would not be more appropriate. One mechanism for setting and changing DSCPs per media stream. An important requirement we have is on the changing of the DSCP of a specific media flow of an established session/call. How to isolate down to a specific flow needs this granularity IMO. > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, October 26, 2006 3:52 PM > > To: mmusic@ietf.org > > Subject: [MMUSIC] New ID on conveying a DSCP > > marking/remarking in an Offer > > > > MMUSIC WG > > > > I've written a new individual ID on how an offer can carry a > > DSCP marking for a session, to be used upon initial offer or > > an offer within an established session that needs remarking > > of the DSCP used for the RTP stream. This link to the ID is here: > > > > http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-att > > ribute-00.txt > > > > I would appreciate comments > > > > Thanks > > James > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1zF-0001NW-Hu; Tue, 31 Oct 2006 17:21:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1zB-0001N6-4i for mmusic@ietf.org; Tue, 31 Oct 2006 17:21:35 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1z9-0008Mg-QG for mmusic@ietf.org; Tue, 31 Oct 2006 17:21:33 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 31 Oct 2006 14:21:32 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMLVN5011088 for ; Tue, 31 Oct 2006 14:21:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMLVW4028093 for ; Tue, 31 Oct 2006 14:21:31 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:21:31 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:21:30 -0800 Message-Id: <4.3.2.7.2.20061031160542.02eb9388@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:21:27 -0600 To: "Dan Wing" , From: "James M. Polk" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <3e0201c6f962$e69985d0$5b82200a@amer.cisco.com> References: <4.3.2.7.2.20061026173826.03a90de8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:21:30.0929 (UTC) FILETIME=[EA689210:01C6FD3A] DKIM-Signature: a=rsa-sha1; q=dns; l=1372; t=1162333291; x=1163197291; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=0A=20=20an=20Offer; X=v=3Dcisco.com=3B=20h=3D7EWGNVsPmFcg19NDB5SiWst/rtM=3D; b=PJsD+xr+kBn6Y1QBmjvRA8lCuGH69dY2zGoM3S6lJlVzBvywFVeIVIkYh1BZYC6KcdynugUB TNurfbCmHnqcGracK6nLUlbIPUZGP4c+sHG7PJt5MHSjvKvNdM95U9Fu; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 05:57 PM 10/26/2006 -0700, Dan Wing wrote: >I agree with Francois -- I need to understand the justification for this >functionality. This seems only germain to each local network and I don't >see the value in signaling this in SDP. Signaling this in SIP cannot get to the media level. In other words, lets say only the video stream of a multi-stream flow between two endpoints needs adjusting mid-stream. SIP cannot pick out the video only, and not affect the audio stream, I do not believe. >-d > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, October 26, 2006 3:52 PM > > To: mmusic@ietf.org > > Subject: [MMUSIC] New ID on conveying a DSCP > > marking/remarking in an Offer > > > > MMUSIC WG > > > > I've written a new individual ID on how an offer can carry a > > DSCP marking > > for a session, to be used upon initial offer or an offer within an > > established session that needs remarking of the DSCP used for the RTP > > stream. This link to the ID is here: > > > > http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-att > > ribute-00.txt > > > > I would appreciate comments > > > > Thanks > > James > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf20b-0001lc-64; Tue, 31 Oct 2006 17:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf20Z-0001lX-Kg for mmusic@ietf.org; Tue, 31 Oct 2006 17:22:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf20Y-0008VW-8v for mmusic@ietf.org; Tue, 31 Oct 2006 17:22:59 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 14:22:58 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMMuNQ012470; Tue, 31 Oct 2006 14:22:56 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMMlOj007861; Tue, 31 Oct 2006 14:22:56 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Oct 2006 14:22:55 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:22:54 -0800 Message-Id: <4.3.2.7.2.20061031160758.02f51f70@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:22:51 -0600 To: "Francois Audet" , "John Rosenberg" , From: "James M. Polk" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nor tel.com> References: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:22:54.0915 (UTC) FILETIME=[1C77D130:01C6FD3B] DKIM-Signature: a=rsa-sha1; q=dns; l=2651; t=1162333376; x=1163197376; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=0A=20=20an=20Offer; X=v=3Dcisco.com=3B=20h=3D7EWGNVsPmFcg19NDB5SiWst/rtM=3D; b=EmNq/90kWSsvHyH6QedkWihBcidNHW5AlyJbzUjdUPed8Wj+4wek7Ncxp9p8tWPfOB8s3FPU RFk2P5MMICiLs0ZFY4X/UYV8J3d71Hh+pgvrJ2TynUPhW6XPn5Rx5rTR; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 12:04 PM 10/30/2006 -0600, Francois Audet wrote: >Even a better reason then to use the config-framework instead of >mandating >a B2BUA in the middle pretending to be the other end. Francois, don't take this wrong, but I read your comment as me stating there has to be a B2BUA in every network. I'm only saying there needs to be a intermediary that can modify SDP in those nertworks that may want this feature. > > -----Original Message----- > > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > > Sent: Monday, October 30, 2006 9:42 AM > > To: mmusic@ietf.org > > Cc: jmpolk@email.cisco.com > > Subject: RE: [MMUSIC] New ID on conveying a DSCP > > marking/remarking in an Offer > > > > Dan Wing wrote: > > > > > > >I agree with Francois -- I need to understand the justification for > > >this functionality. This seems only germain to each local > > network and > > >I don't see the value in signaling this in SDP. > > > > I think the justification here is to allow a call > > controller/session manager to exert influence over the > > endpoints' behavior in choosing the DSCP value to use for a > > bearer stream. For example in the US, DISA has some > > requirements for their Defense Information System Network > > that specify that a call controller must instruct served CPE > > regarding what DSCP value to use in the bearer based on the > > precedence level that the user requests - this involves an > > authentication and authorization to use that level in the > > call controller (a B2BUA). > > > > While it's interesting, and potentially useful, for one EP to > > tell another "Hey, I'm going to use DSCP 41" I think that > > view of this draft misses its point, and that the real power > > is allowing a call controller/session manager to drive the > > endpoint's behavior. This allows for all kinds of good things > > - like authorization - to come into play w.r.t. use of > > particular DSCP values and the PHBs they imply. > > > > In cases when the bearer streams cross network boundaries, I > > would expect Session Boarder Controllers to rewrite the SDP > > and modify the DSCP attribute as appropriate per policy - > > similar to how STPs that interconnect ISUP networks modify > > IAMs transmitted between networks. > > > > John Rosenberg > > Lucent Technologies > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:24:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf22A-0002Az-Iw; Tue, 31 Oct 2006 17:24:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf226-00028x-H5 for mmusic@ietf.org; Tue, 31 Oct 2006 17:24:37 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf225-0000EK-7O for mmusic@ietf.org; Tue, 31 Oct 2006 17:24:34 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2006 14:24:33 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMOWt3008592; Tue, 31 Oct 2006 14:24:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMOWin005414; Tue, 31 Oct 2006 14:24:32 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:24:32 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:24:31 -0800 Message-Id: <4.3.2.7.2.20061031162310.02544c00@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:24:30 -0600 To: "Dan Wing" , "'John Rosenberg'" , "'Jonathan Rosenberg'" From: "James M. Polk" In-Reply-To: <564b01c6fc79$146cb9f0$5b82200a@amer.cisco.com> References: <200610302100.k9UL0KI00871@ihmail.ih.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:24:32.0025 (UTC) FILETIME=[5659A090:01C6FD3B] DKIM-Signature: a=rsa-sha1; q=dns; l=1394; t=1162333472; x=1163197472; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:DSCP=20setting/resetting=20in=20SIP=20vs.=20SDP; X=v=3Dcisco.com=3B=20h=3DD3BN+3b9b5wEzS6xoVUoQV839Pk=3D; b=q3sViGjvIh4SVoXKZQYlA6BIQHNDQzslnJkaGQoBDqj0kyIovDTYfMtPcNtbyBstiGCidUNG y6ybTCohoc2CRFSwCeOEi64GQlJgpKyO0KPjBOemxdlBJ/txNLjqI5Tr; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Francois Audet' , mmusic@ietf.org Subject: [MMUSIC] DSCP setting/resetting in SIP vs. SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 03:13 PM 10/30/2006 -0800, Dan Wing wrote: > > >I also see no reason why the DSCP value would be dynamic > > >(i.e., it won't > > >change on a call-by-call basis). It thus seems much more > > >appropraite to > > >me to use whatever the configuration mechanism is for the phone. > > > > In the DISA scenario, it absolutely can change on a call by call > > basis. In DISA's requirements, the bearer DSCP to use is determined > > based on the precedence level requested for the call, which can > > change for each call a user makes. The Local Call Controller serving > > the user's endpoint authenticates and determines whether the > > requested precedence level is authorized for that user. It then must > > instruct the endpoint what DSCP value to use for the bearer stream(s) > > associated with that call. > >If you really want to enable such communication without a B2BUA, >tacking on a new SIP header seems better than messing with the SDP. How will SIP change the DSCP of a Video stream and not change the DSCP of the audio stream within the same Call-ID? > > James' draft allows for exactly the necessary behavior > > described above. > > > > I also believe that it does not mandate a B2BUA in the middle. If one > > is not there then it's an endpoint to endpoint discussion (not > > negotiation) regarding the bearer DSCP that they intend to use. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf287-0007vY-6x; Tue, 31 Oct 2006 17:30:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf284-0007uA-Bw for mmusic@ietf.org; Tue, 31 Oct 2006 17:30:44 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf283-0000p4-18 for mmusic@ietf.org; Tue, 31 Oct 2006 17:30:44 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 14:30:43 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMUg2j026327; Tue, 31 Oct 2006 17:30:42 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMUgDM010195; Tue, 31 Oct 2006 17:30:42 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:30:42 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:30:42 -0500 Message-Id: <4.3.2.7.2.20061031162453.025346b8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:30:40 -0600 To: "Dan Wing" , "'John Rosenberg'" , From: "James M. Polk" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <581201c6fc8c$b1a57730$5b82200a@amer.cisco.com> References: <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:30:42.0252 (UTC) FILETIME=[3305C8C0:01C6FD3C] DKIM-Signature: a=rsa-sha1; q=dns; l=3903; t=1162333842; x=1163197842; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=0A=20=20an=20Offer |To:=22Dan=20Wing=22=20, =20=22'John=20Rosenberg'=22=20,=0A=20=20=20=20=20=20=20=20; X=v=3Dcisco.com=3B=20h=3D7EWGNVsPmFcg19NDB5SiWst/rtM=3D; b=A9DR8v9fMnw+zRx4pI5v27lximEPunSzJbPw+C76AylyrkIKB5mATWqkGJgOWJzQwyXASFX0 wLpp4GDnedmC1Ym8WFutHYXiOxiz+avdcWrbWkBkmFtrrIW8/vt2Ob1+; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 05:34 PM 10/30/2006 -0800, Dan Wing wrote: > > >I agree with Francois -- I need to understand the justification for > > >this functionality. This seems only germain to each local network > > >and I don't see the value in signaling this in SDP. > > > > I think the justification here is to allow a call controller/session > > manager to exert influence over the endpoints' behavior in choosing > > the DSCP value to use for a bearer stream. > >But this draft doesn't describe how a call controller or session >manager does that. Rather, from the SIP perspective, the endpoint >dreams up a DSCP value and, following this specification, declares >that value in its SDP and requires its peer to use the same DSCP >value. Shown clearly in Figure 1 (page 4), Alice's UA, making the initial offer doesn't have this "a=dscp" attribute in her Offer. The intermediary added it. Thus, the endpoint didn't "dream up" this DSCP value. As for the rest of your message below - I'm open to you sending text to "fix this"... ;-) > > For example in the US, > > DISA has some requirements for their Defense Information System > > Network that specify that a call controller must instruct served CPE > > regarding what DSCP value to use in the bearer based on the > > precedence level that the user requests - this involves an > > authentication and authorization to use that level in the call > > controller (a B2BUA). > >The flow I'm imagining is this: > > Call > Alice Controller B2BUA > | | | > 1. offhook-------->| | | > 2. dialed digits-->| | | > 3. |--555-1212--->| | > 4. |<--DSCP=0100--| | > 5. |--INVITE, a=dscp:0100------>| > >Where draft-polk-mmusic-dscp-attribute-00.txt is only describing message 5. >Is that about right? > > > While it's interesting, and potentially useful, for one EP to tell > > another "Hey, I'm going to use DSCP 41" I think that view of this > > draft misses its point, and that the real power is allowing a call > > controller/session manager to drive the endpoint's behavior. This > > allows for all kinds of good things - like authorization - to come > > into play w.r.t. use of particular DSCP values and the PHBs > > they imply. > >As written, the draft only describes the offerer having that privilege to >decide the DSCP value it'll use in its call setup. The draft doesn't >describe steps (3) and (4) in the above flow. > > >Now, if we imagine an *incoming* call (that is, a call going towards Alice), >I could see where the B2BUA, in conjunction with the Call Controller, could >decide the DSCP value for the incoming call. Something like this: > > Call > Alice Controller B2BUA > | | | > 1. | | |<--INVITE To: Alice > 2. | |<-DSCP?------| > 3. | |--DSCP=0101->| > 4. |<-INVITE, a=dscp:0101-------| > >In which case the draft, as written, makes sense. > > > > In cases when the bearer streams cross network boundaries, I would > > expect Session Boarder Controllers to rewrite the SDP and modify the > > DSCP attribute as appropriate per policy - similar to how STPs that > > interconnect ISUP networks modify IAMs transmitted between networks. > >Yes, something needs to modify the DSCPs as they cross the network boundary. >SBCs are a heavy way to do that, but we don't have a better mechanism to do >such remarking on a per-flow basis. > >-d > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:31:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf29F-00007u-La; Tue, 31 Oct 2006 17:31:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf29D-00007R-6h for mmusic@ietf.org; Tue, 31 Oct 2006 17:31:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf29B-0000sw-OJ for mmusic@ietf.org; Tue, 31 Oct 2006 17:31:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 14:31:54 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMVrFD015306; Tue, 31 Oct 2006 17:31:53 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMVrDM010557; Tue, 31 Oct 2006 17:31:53 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:31:53 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:31:52 -0500 Message-Id: <4.3.2.7.2.20061031161057.02760278@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:19:55 -0600 To: Jonathan Rosenberg , John Rosenberg From: "James M. Polk" In-Reply-To: <4546648D.7000808@cisco.com> References: <200610301810.k9UIAPI09611@ihmail.ih.lucent.com> <200610301742.k9UHg4I19053@ihmail.ih.lucent.com> <1ECE0EB50388174790F9694F77522CCF0DC29F8F@zrc2hxm0.corp.nortel.com> <200610301810.k9UIAPI09611@ihmail.ih.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:31:52.0732 (UTC) FILETIME=[5D082DC0:01C6FD3C] DKIM-Signature: a=rsa-sha1; q=dns; l=5104; t=1162333913; x=1163197913; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Remarking=20DSCPs=20midcall |To:Jonathan=20Rosenberg=20, =0A=20=20=20=20=20=20=20=20Jo hn=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DOvY9jxBa0UswM4aWdE+9RzN8+kc=3D; b=r2TVZGroKTDRtMPJ0ovjWPofqhq3clUNyklq3DzcQPAee8iDExw5ubg5xNp6VqjXP7qFDOc0 RoBVhTE76qTm6jeS4FgbpfJeQxgakfQZGNc+NqFFvOj4ULQ1KATgFknE; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Francois Audet , mmusic@ietf.org Subject: [MMUSIC] Remarking DSCPs midcall X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 03:46 PM 10/30/2006 -0500, Jonathan Rosenberg wrote: >It most certainly is mandating a b2bua in the middle. As folks have >pointed out, and I concur, it makes more sense for a local network to tell >its UA what DSCP to use. SIP negotiation is wrong for that, since it's >between endpoints. Thus, for the mechanism to be useful, it requires that: > >1. the SIP provider is the same as the access provider, >2. the SIP provider runs a b2bua to modify SIP/SDP signaling > >I also see no reason why the DSCP value would be dynamic (i.e., it won't >change on a call-by-call basis). Say there is a local policy of establishing a reservation between edge routers for every call in a network. The phones know nothing of this reservation, or even which reservation protocol is used. Local policy has all calls using a certain DSCP for audio calls (say 46). But the local network also has a policy that if the reservation goes away (for whatever reason) the call can stay up, but without the reservation. These calls now need to have a less than Expedited Forwarding class treatment through the network. The mid-call DSCP value has to change from 46 to something else. This mechanism does this on a per call basis. >It thus seems much more appropraite to me to use whatever the >configuration mechanism is for the phone. If only set at call set-up, I tend to agree. However, of the DSCP needs to be changed, doing this in a consistent way (i.e. using the same mechanism) seems to make sense to me. >Thanks, >Jonathan R. > >John Rosenberg wrote: > >>I don't think anything is mandating a B2BUA in the middle. In the DISA >>case there *is* a B2BUA in the middle and the requirement is that it have >>a way to tell the endpoint what DSCP value to use. The mechanism James is >>proposing fits the bill in that situation, and would also be useful in an >>IMS network to allow a CSCF or App Server to exert control over the DSCP >>values and thus the Per Hop behaviors that they imply. >>John >>At 12:04 PM 10/30/2006, Francois Audet wrote: >> >Even a better reason then to use the config-framework instead of >> >mandating >> >a B2BUA in the middle pretending to be the other end. >> > >> >> -----Original Message----- >> >> From: John Rosenberg [mailto:jrrosenberg@lucent.com] >> >> Sent: Monday, October 30, 2006 9:42 AM >> >> To: mmusic@ietf.org >> >> Cc: jmpolk@email.cisco.com >> >> Subject: RE: [MMUSIC] New ID on conveying a DSCP >> >> marking/remarking in an Offer >> >> >> >> Dan Wing wrote: >> >> >> >> >> >> >I agree with Francois -- I need to understand the justification for >> >> >this functionality. This seems only germain to each local >> >> network and >> >> >I don't see the value in signaling this in SDP. >> >> >> >> I think the justification here is to allow a call >> >> controller/session manager to exert influence over the >> >> endpoints' behavior in choosing the DSCP value to use for a >> >> bearer stream. For example in the US, DISA has some >> >> requirements for their Defense Information System Network >> >> that specify that a call controller must instruct served CPE >> >> regarding what DSCP value to use in the bearer based on the >> >> precedence level that the user requests - this involves an >> >> authentication and authorization to use that level in the >> >> call controller (a B2BUA). >> >> >> >> While it's interesting, and potentially useful, for one EP to >> >> tell another "Hey, I'm going to use DSCP 41" I think that >> >> view of this draft misses its point, and that the real power >> >> is allowing a call controller/session manager to drive the >> >> endpoint's behavior. This allows for all kinds of good things >> >> - like authorization - to come into play w.r.t. use of >> >> particular DSCP values and the PHBs they imply. >> >> >> >> In cases when the bearer streams cross network boundaries, I >> >> would expect Session Boarder Controllers to rewrite the SDP >> >> and modify the DSCP attribute as appropriate per policy - >> >> similar to how STPs that interconnect ISUP networks modify >> >> IAMs transmitted between networks. >> >> >> >> John Rosenberg >> >> Lucent Technologies >> >> >> >> >> >> _______________________________________________ >> >> mmusic mailing list >> >> mmusic@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ 07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 17:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2In-0005hP-Eq; Tue, 31 Oct 2006 17:41:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2Ik-0005hI-6X for mmusic@ietf.org; Tue, 31 Oct 2006 17:41:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf2Ii-0001sX-Pw for mmusic@ietf.org; Tue, 31 Oct 2006 17:41:46 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 14:41:44 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VMfhBx024603; Tue, 31 Oct 2006 14:41:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VMfUbZ014032; Tue, 31 Oct 2006 14:41:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:41:43 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:41:42 -0800 Message-Id: <4.3.2.7.2.20061031164131.02f744d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 16:41:40 -0600 To: "Francois Audet" , "Nguyen, An P CIV NCS NC2" From: "James M. Polk" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer (UNCLASSIFIED) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC99965@zrc2hxm0.corp.nor tel.com> References: <9B4320CC9BC1D847AFFA97F25A422A59A97378@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2006 22:41:43.0080 (UTC) FILETIME=[BCE82280:01C6FD3D] DKIM-Signature: a=rsa-sha1; q=dns; l=3318; t=1162334503; x=1163198503; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=0A=20=20an=20Offer=20(UNCLASSIFIED); X=v=3Dcisco.com=3B=20h=3DHPH+m+q01Ti5DbAK5/oZGtoH/F8=3D; b=Xk5v4ylHAvY+wysJggBCHlqPJleQGDKsQMHUya2wGFVXNeRs7IZvRA/P/83kwws6R0gAl4K1 leGPVs9HdX31Pek9tspSQbcMCBEwDvX7zHrqvenfsZMTBFgNFFjH/wZj; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 01:25 PM 10/31/2006 -0600, Francois Audet wrote: >Different networks (private or public: doesn't matter) may use different >DSCP values for the same type of traffic (e.g., voice with precedence >x). yes > > -----Original Message----- > > From: Nguyen, An P CIV NCS NC2 [mailto:an.p.nguyen@dhs.gov] > > Sent: Tuesday, October 31, 2006 9:03 AM > > To: Audet, Francois (SC100:3055); John Rosenberg; Jonathan Rosenberg > > Cc: mmusic@ietf.org; jmpolk@email.cisco.com; Nguyen, An P CIV NCS NC2 > > Subject: RE: [MMUSIC] New ID on conveying a DSCP > > marking/remarking in an Offer (UNCLASSIFIED) > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > Just a clarification: Are we talking about a private network > > in which we can assign different DSCP codepoints for > > different precedence level? > > > > An > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, October 30, 2006 4:14 PM > > To: John Rosenberg; Jonathan Rosenberg > > Cc: mmusic@ietf.org; jmpolk@email.cisco.com > > Subject: RE: [MMUSIC] New ID on conveying a DSCP > > marking/remarking in an Offer > > > > Well, sure, it can be dynamic based on precedence level. > > > > You could have a static rule that assigns a DSCP codepoint to > > different precedence level. > > > > > -----Original Message----- > > > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > > > Sent: Monday, October 30, 2006 1:00 PM > > > To: Jonathan Rosenberg > > > Cc: Audet, Francois (SC100:3055); mmusic@ietf.org; > > > jmpolk@email.cisco.com > > > Subject: Re: [MMUSIC] New ID on conveying a DSCP > > marking/remarking in > > > an Offer > > > > > > Jonathan - > > > > > > At 02:46 PM 10/30/2006, Jonathan Rosenberg wrote: > > > > > > >I also see no reason why the DSCP value would be dynamic > > (i.e., it > > > won't >change on a call-by-call basis). It thus seems much more > > > appropraite to >me to use whatever the configuration > > mechanism is for > > > the phone. > > > > > > In the DISA scenario, it absolutely can change on a call by call > > > basis. In DISA's requirements, the bearer DSCP to use is determined > > > based on the precedence level requested for the call, which > > can change > > > for each call a user makes. The Local Call Controller serving the > > > user's endpoint authenticates and determines whether the requested > > > precedence level is authorized for that user. It then must instruct > > > the endpoint what DSCP value to use for the bearer stream(s) > > > associated with that call. > > > > > > James' draft allows for exactly the necessary behavior described > > > above. > > > > > > I also believe that it does not mandate a B2BUA in the > > middle. If one > > > is not there then it's an endpoint to endpoint discussion (not > > > negotiation) regarding the bearer DSCP that they intend to use. > > > > > > John > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 18:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3BL-0003dd-GM; Tue, 31 Oct 2006 18:38:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3BG-0003dX-31 for mmusic@ietf.org; Tue, 31 Oct 2006 18:38:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3BE-00006s-Qj for mmusic@ietf.org; Tue, 31 Oct 2006 18:38:06 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 15:38:04 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VNc4oG014531; Tue, 31 Oct 2006 15:38:04 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VNbsbF008300; Tue, 31 Oct 2006 15:37:59 -0800 (PST) From: "Dan Wing" To: "'James M. Polk'" , "'John Rosenberg'" , "'Jonathan Rosenberg'" Date: Tue, 31 Oct 2006 15:37:54 -0800 Keywords: direct-to-dwing Message-ID: <084201c6fd45$9c274d70$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9O1ZVYcWDd2Y0Tu6c2hbWOTOEJAACdW9Q In-Reply-To: <4.3.2.7.2.20061031162310.02544c00@email.cisco.com> DKIM-Signature: a=rsa-sha1; q=dns; l=530; t=1162337884; x=1163201884; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20DSCP=20setting/resetting=20in=20SIP=20vs.=20SDP; X=v=3Dcisco.com=3B=20h=3DDjHpCZLch31twIzb7CzVceZ5X7s=3D; b=taKdLYaepVVVRflSWkqLmC6zUo7CBvk9+ruUpzVJ9q3CTXIXYR7NPjNfFl3+v/xDTY/ZPIRb +GgyCPXtpySJiS8OMwxNOr0UpgoHVioI6lEN5SF7lW0v7h0C4QNiRqP/; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'Francois Audet' , mmusic@ietf.org Subject: [MMUSIC] RE: DSCP setting/resetting in SIP vs. SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > >If you really want to enable such communication without a B2BUA, > >tacking on a new SIP header seems better than messing with the SDP. > > How will SIP change the DSCP of a Video stream and not change > the DSCP of the audio stream within the same Call-ID? Here is a crazy straw-man idea: Media-priority: audio=high; video=low And each endpoint is provisioned to know which DSCP value its supposed to use for 'high' or 'low'. Gross? Yes. Worse than mandating diddling with SDP in a B2BUA? Maybe so. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 19:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3bC-0005nF-JE; Tue, 31 Oct 2006 19:04:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3b6-0005n2-8L for mmusic@ietf.org; Tue, 31 Oct 2006 19:04:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3b4-000453-6A for mmusic@ietf.org; Tue, 31 Oct 2006 19:04:48 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2006 16:04:45 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA104jNC020321; Tue, 31 Oct 2006 16:04:45 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA104iOV028616; Tue, 31 Oct 2006 16:04:45 -0800 (PST) From: "Dan Wing" To: "'James M. Polk'" , "'John Rosenberg'" , Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer Date: Tue, 31 Oct 2006 16:04:44 -0800 Keywords: direct-to-dwing Message-ID: <085401c6fd49$56b63720$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9PDN3KkWtrq6LTw2eGyHjwhdd5wACo6jg In-Reply-To: <4.3.2.7.2.20061031162453.025346b8@email.cisco.com> DKIM-Signature: a=rsa-sha1; q=dns; l=5577; t=1162339485; x=1163203485; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20=20an=20Offer; X=v=3Dcisco.com=3B=20h=3DDgHfiL1Cfmdu8nPr6+Wxdp4xpps=3D; b=uNDlNFCyjK8UNp962R+YQr5eQx2oW9UwpyhgxBHatP5OvEWJ1EXiXN1hJXweW5+ucvOnsT8s lw+KQJvnCZQwp9O1Soxiwro2z7WhJjeJmdm49MxKIZm8H5knu30tG0OS; Authentication-Results: sj-dkim-5.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > At 05:34 PM 10/30/2006 -0800, Dan Wing wrote: > > > >I agree with Francois -- I need to understand the > > > >justification for > > > >this functionality. This seems only germain to each > > > >local network > > > >and I don't see the value in signaling this in SDP. > > > > > > I think the justification here is to allow a call > > > controller/session > > > manager to exert influence over the endpoints' behavior > > > in choosing > > > the DSCP value to use for a bearer stream. > > > >But this draft doesn't describe how a call controller or session > >manager does that. Rather, from the SIP perspective, the endpoint > >dreams up a DSCP value and, following this specification, declares > >that value in its SDP and requires its peer to use the same DSCP > >value. > > Shown clearly in Figure 1 (page 4), Alice's UA, making the > initial offer doesn't have this "a=dscp" attribute in her > Offer. The intermediary added it. Thanks. Sorry I had missed that. > Thus, the endpoint didn't "dream up" this DSCP value. > > As for the rest of your message below - I'm open to you > sending text to "fix this"... ;-) Call the intermediary what it is -- an SBC. Figure 1 shows a network with only one SBC. However, Alice's network would have its own SBC and Bob's network would also have its own SBC. In such a situation an SBC would be necessary to modify the DSCP values of the RTP packets as they cross into Alice's and Bob's networks. Alice Alice-SBC Bob-SBC Bob | | | | | Offer | | | |------------->| Offer | | | | a=dscp 46 | Offer | | |----------->| a=dscp 47 | | | |------------>| | | | | | | | Answer | | | Answer | a=dscp 47 | | Answer | a=dscp 47 |<------------| | a=dscp 46 |<-----------| | |<-------------| | | | | | | |=RTP,dscp 46=>|==========RTP,dscp47=====>| |<====RTP,dscp46============|<=RTP,dscp47=| | | | | This will all work with your I-D as written, without changes. Sorry that I missed the lack of Alice's UA indicating DSCP in Figure 1. -d > > > > For example in the US, > > > DISA has some requirements for their Defense Information System > > > Network that specify that a call controller must instruct > served CPE > > > regarding what DSCP value to use in the bearer based on the > > > precedence level that the user requests - this involves an > > > authentication and authorization to use that level in the call > > > controller (a B2BUA). > > > >The flow I'm imagining is this: > > > > Call > > Alice Controller B2BUA > > | | | > > 1. offhook-------->| | | > > 2. dialed digits-->| | | > > 3. |--555-1212--->| | > > 4. |<--DSCP=0100--| | > > 5. |--INVITE, a=dscp:0100------>| > > > >Where draft-polk-mmusic-dscp-attribute-00.txt is only > describing message 5. > >Is that about right? > > > > > While it's interesting, and potentially useful, for one EP to tell > > > another "Hey, I'm going to use DSCP 41" I think that view of this > > > draft misses its point, and that the real power is allowing a call > > > controller/session manager to drive the endpoint's behavior. This > > > allows for all kinds of good things - like authorization - to come > > > into play w.r.t. use of particular DSCP values and the PHBs > > > they imply. > > > >As written, the draft only describes the offerer having that > privilege to > >decide the DSCP value it'll use in its call setup. The draft doesn't > >describe steps (3) and (4) in the above flow. > > > > > >Now, if we imagine an *incoming* call (that is, a call going > towards Alice), > >I could see where the B2BUA, in conjunction with the Call > Controller, could > >decide the DSCP value for the incoming call. Something like this: > > > > Call > > Alice Controller B2BUA > > | | | > > 1. | | |<--INVITE To: Alice > > 2. | |<-DSCP?------| > > 3. | |--DSCP=0101->| > > 4. |<-INVITE, a=dscp:0101-------| > > > >In which case the draft, as written, makes sense. > > > > > > > In cases when the bearer streams cross network boundaries, I would > > > expect Session Boarder Controllers to rewrite the SDP and > modify the > > > DSCP attribute as appropriate per policy - similar to how > STPs that > > > interconnect ISUP networks modify IAMs transmitted > between networks. > > > >Yes, something needs to modify the DSCPs as they cross the > network boundary. > >SBCs are a heavy way to do that, but we don't have a better > mechanism to do > >such remarking on a per-flow basis. > > > >-d > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 31 19:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf4CO-0001CP-Ag; Tue, 31 Oct 2006 19:43:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf4At-0000kp-P7 for mmusic@ietf.org; Tue, 31 Oct 2006 19:41:48 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3vi-0007U9-0G for mmusic@ietf.org; Tue, 31 Oct 2006 19:26:08 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 16:26:06 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA10Q5h3014016; Tue, 31 Oct 2006 19:26:05 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA10Q5YJ028420; Tue, 31 Oct 2006 19:26:05 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 19:26:05 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 19:26:04 -0500 Message-Id: <4.3.2.7.2.20061031181617.027875e8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2006 18:26:03 -0600 To: "Dan Wing" , "'John Rosenberg'" , From: "James M. Polk" Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer In-Reply-To: <085401c6fd49$56b63720$c5f0200a@amer.cisco.com> References: <4.3.2.7.2.20061031162453.025346b8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Nov 2006 00:26:04.0965 (UTC) FILETIME=[5147F550:01C6FD4C] DKIM-Signature: a=rsa-sha1; q=dns; l=6096; t=1162340765; x=1163204765; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[MMUSIC]=20New=20ID=20on=20conveying=20a=20DSCP=20marking/remark ing=20in=20=0A=20=20an=20Offer |To:=22Dan=20Wing=22=20, =20=22'John=20Rosenberg'=22=20,=0A=20=20=20=20=20=20=20=20; X=v=3Dcisco.com=3B=20h=3D7EWGNVsPmFcg19NDB5SiWst/rtM=3D; b=rrodxt9BpYaWAVGMX02Z1HwjCguuswXU9tPNzEtaGXetsc2qEfrvgMYlzx5CJeBwuF7H7REU J2fI7V0pZ3ssstsOMuKQjBs5CTcPG0odCZwn6kqxCoCk0YZBxUXFJurh; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At 04:04 PM 10/31/2006 -0800, Dan Wing wrote: > > At 05:34 PM 10/30/2006 -0800, Dan Wing wrote: > > > Shown clearly in Figure 1 (page 4), Alice's UA, making the > > initial offer doesn't have this "a=dscp" attribute in her > > Offer. The intermediary added it. > >Thanks. Sorry I had missed that. np It is more subtle than it should be in the ID I should show something like Alice --- INVITE (no DSCP attribute) ---> intermediary ... > > Thus, the endpoint didn't "dream up" this DSCP value. > > > > As for the rest of your message below - I'm open to you > > sending text to "fix this"... ;-) > >Call the intermediary what it is -- an SBC. actually I never thought of the intermediary as an SBC, but I guess it could be >Figure 1 shows a network with only one SBC. However, Alice's network would >have its own SBC and Bob's network would also have its own SBC. where there is an SBC, there are likely to be 2, yes >In such a >situation an SBC would be necessary to modify the DSCP values of the RTP >packets as they cross into Alice's and Bob's networks. The SBC can simply modify the DSCP value of each RTP packet it transmits, but not what it receives. The SBC would need to signal or negotiate this with the other side. I am proposing this be done in SDP, and not SIP, because SDP gets to the specific media level, whereas SIP doesn't. In other words, Alice and Bob may have more than one stream within a Call-ID, but something less than all of the streams need to be modified. I don't believe SIP can do this. SIP would only be equivalent to session level in SDP (affecting all streams with a session) here between Alice and Bob. > Alice Alice-SBC Bob-SBC Bob > | | | | > | Offer | | | > |------------->| Offer | | > | | a=dscp 46 | Offer | > | |----------->| a=dscp 47 | > | | |------------>| > | | | | > | | | Answer | > | | Answer | a=dscp 47 | > | Answer | a=dscp 47 |<------------| > | a=dscp 46 |<-----------| | > |<-------------| | | > | | | | > |=RTP,dscp 46=>|==========RTP,dscp47=====>| > |<====RTP,dscp46============|<=RTP,dscp47=| > | | | | > >This will all work with your I-D as written, without changes. Sorry that I >missed the lack of Alice's UA indicating DSCP in Figure 1. If the intermediaries were SBCs, this is a more complete diagram than Figure 1 in the ID. Should I include such a detailed diagram in the ID? >-d > > > > > > > > For example in the US, > > > > DISA has some requirements for their Defense Information System > > > > Network that specify that a call controller must instruct > > served CPE > > > > regarding what DSCP value to use in the bearer based on the > > > > precedence level that the user requests - this involves an > > > > authentication and authorization to use that level in the call > > > > controller (a B2BUA). > > > > > >The flow I'm imagining is this: > > > > > > Call > > > Alice Controller B2BUA > > > | | | > > > 1. offhook-------->| | | > > > 2. dialed digits-->| | | > > > 3. |--555-1212--->| | > > > 4. |<--DSCP=0100--| | > > > 5. |--INVITE, a=dscp:0100------>| > > > > > >Where draft-polk-mmusic-dscp-attribute-00.txt is only > > describing message 5. > > >Is that about right? > > > > > > > While it's interesting, and potentially useful, for one EP to tell > > > > another "Hey, I'm going to use DSCP 41" I think that view of this > > > > draft misses its point, and that the real power is allowing a call > > > > controller/session manager to drive the endpoint's behavior. This > > > > allows for all kinds of good things - like authorization - to come > > > > into play w.r.t. use of particular DSCP values and the PHBs > > > > they imply. > > > > > >As written, the draft only describes the offerer having that > > privilege to > > >decide the DSCP value it'll use in its call setup. The draft doesn't > > >describe steps (3) and (4) in the above flow. > > > > > > > > >Now, if we imagine an *incoming* call (that is, a call going > > towards Alice), > > >I could see where the B2BUA, in conjunction with the Call > > Controller, could > > >decide the DSCP value for the incoming call. Something like this: > > > > > > Call > > > Alice Controller B2BUA > > > | | | > > > 1. | | |<--INVITE To: Alice > > > 2. | |<-DSCP?------| > > > 3. | |--DSCP=0101->| > > > 4. |<-INVITE, a=dscp:0101-------| > > > > > >In which case the draft, as written, makes sense. > > > > > > > > > > In cases when the bearer streams cross network boundaries, I would > > > > expect Session Boarder Controllers to rewrite the SDP and > > modify the > > > > DSCP attribute as appropriate per policy - similar to how > > STPs that > > > > interconnect ISUP networks modify IAMs transmitted > > between networks. > > > > > >Yes, something needs to modify the DSCPs as they cross the > > network boundary. > > >SBCs are a heavy way to do that, but we don't have a better > > mechanism to do > > >such remarking on a per-flow basis. > > > > > >-d > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic