headers
Adam Roach | 1 Apr 2007 01:24
Favicon

Re: ICE-tcp: TLS then STUN or STUN then TLS

Given EKR and Rémi's analysis of the situation, it sounds to me like we 
get to choose between making implementors work harder and making CPUs 
work harder.

I would argue that the key to a successful protocol is a low 
implementation complexity. Even for low-end mobile devices, CPUs are 
relatively fast (133 MHz is the low-low-low end nowadays) and getting 
faster all the time -- so the extra TLS handshakes, while a waste of CPU 
time, are going to be rather insignificant in the grand scheme of 
things. (As to battery life: consider that these wasted cycles will 
typically occur only at the start of a session, so there should be 
negligible impact on total power used).

Finally, given that ICE-TCP is being considered for applications other 
than TCP (cf. Aki's ICE-MSRP draft), I'd want to stay away from any 
solution that assumes the use of RTP TCP framing.

/a

Rémi Denis-Courmont wrote:
> On Thursday 29 March 2007 17:25:41 ext EKR wrote:
>   
>>> Well, one idea on the demux is if we are using the contrans framing,
>>> the TLS runs ONTOP of the framing so the demux is trivial.
>>>       
>
> My memory might be failing, but I thought RTP/TCP framing only adds a bytes 
> length word. That is sufficient to differenciate RTP from STUN, sure... but 
> does it work for TLS vs STUN at all?
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Colin Perkins | 1 Apr 2007 15:00

Re: WGLC: draft-ietf-mmusic-ice-15.txt

[Not as chair]

On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote:
> This is to announce a Working Group Last Call on ICE
> draft-ietf-mmusic-ice-15.txt.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
>
> This WGLC will end on Friday April 20.
>
> Please mail all your final comments to the author and the mmusic  
> mailing
> list.

I notice that there are a number of IPR claims against ICE:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=799  
(Cisco)
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=727  
(Tandberg)
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=728  
(Tandberg)
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=729  
(Tandberg)

The license terms offered for the Cisco IPR are reasonable, and not  
problematic.

The license terms offered by Tandberg are more of a concern. While
(Continue reading)

Permalink | Reply | 3 comments |
headers
Elwell, John | 2 Apr 2007 16:53
Picon

ICE micro-lite for support of IPv6 transition

There was strong consensus at IETF68 to deprecate ANAT and use ICE as the
sole way of negotiating between IPv4 and IPv6 for media. However, there was
some concern about this raising the bar too high for those who require to
support IPv6 ahead of full ICE. While many markets may require ICE for NAT
traversal before they require IPv6, there are certain customers demanding
IPv6 transition capabilities at an early stage, and needing to do a full ICE
implementation to satisfy these customers can be undesirable.

To satisfy this market, the requirement is for an offer to include two
candidates, one IPv4 and the other IPv6. For backwards compatibility with
IPv4 non-ICE implementations, the IPv4 candidate would be the default. The
answerer should be able to select one of these and the call should be able
to continue without a connectivity check. Removal of connectivity checks
would considerably simplify the implementation of ICE for IPv4/IPV6
negotiation in these environments. Compatibility with full or lite ICE
implementations would have to be provided, of course.

Thus we would really only use the SDP enhancements of ICE, and not the rest.
Compared with ANAT it has the advantages of better backward compatibility
with existing IPv4 devices and being a step on the path towards full ICE.

ICE lite goes some way to lowering the bar for implementing ICE, but it does
not solve the present problem for two reasons:
1) An ICE lite implementation cannot propose two candidates.
2) An ICE lite implementation is still required to support connectivity
checks as a server.

It seems that the requirements above could be supported by a fairly small
change to ICE, along the following lines. I will call this an ICE
"micro-lite" implementation.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jean-Francois Mule | 2 Apr 2007 18:22
Favicon

Review team formed for RTSP/2.0

Folks,

   Based on our open calls during the mmusic wg meetings at IETF 67 &
68, we have formed a review team for RTSP with the main goal of
resolving open issues and getting new revisions out.

   The following people have signed up to be on the review team:
      - Martin Stiemerling (new editor)
      - Chris Steck
      - Dave Singer
      - Henning Schulzrinne
      - Jamie Gordon
      - Magnus Westerlund 
      - Reinaldo Penno
      - Sean Sheedy
      - Magnus Westerlund
      - Jean-Francois Mule

   We plan to have regular calls and will post meeting notes/updates on
spec issues, etc.

Jean-Francois.
Permalink | Reply | 4 comments |
headers
Stephan Wenger | 2 Apr 2007 23:25

Re: Review team formed for RTSP/2.0

It's good to see Magnus Westerlund twice on this list -- that should  
ensure quality.  But I wonder: when did the cloning happen?  :-)
Stephan

On Apr 2, 2007, at 9:22 AM, Jean-Francois Mule wrote:

> Folks,
>
>    Based on our open calls during the mmusic wg meetings at IETF 67 &
> 68, we have formed a review team for RTSP with the main goal of
> resolving open issues and getting new revisions out.
>
>    The following people have signed up to be on the review team:
>       - Martin Stiemerling (new editor)
>       - Chris Steck
>       - Dave Singer
>       - Henning Schulzrinne
>       - Jamie Gordon
>       - Magnus Westerlund
>       - Reinaldo Penno
>       - Sean Sheedy
>       - Magnus Westerlund
>       - Jean-Francois Mule
>
>    We plan to have regular calls and will post meeting notes/ 
> updates on
> spec issues, etc.
>
> Jean-Francois.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geir Arne Sandbakken | 3 Apr 2007 11:05

RE: WGLC: draft-ietf-mmusic-ice-15.txt

Colin,

The part of the IPR concerning negotiation of a license is adopted from
the standard ITU patent policy statement.  We understand you concern,
and it is now under revision.

Cheers,
Geir Arne

> -----Original Message-----
> From: Colin Perkins [mailto:csp <at> csperkins.org]
> Sent: 01 April 2007 15:00
> To: Jean-Francois Mule
> Cc: mmusic <at> ietf.org; Joerg Ott
> Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt
> 
> [Not as chair]
> 
> On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote:
> > This is to announce a Working Group Last Call on ICE
> > draft-ietf-mmusic-ice-15.txt.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
> >
> > This WGLC will end on Friday April 20.
> >
> > Please mail all your final comments to the author and the mmusic
> > mailing
> > list.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Magnus Westerlund | 3 Apr 2007 11:05
Picon
Favicon

Re: Review team formed for RTSP/2.0

Stephan Wenger skrev:
> It's good to see Magnus Westerlund twice on this list -- that should 
> ensure quality.  But I wonder: when did the cloning happen?  :-)

Who has talked about cloning? Dual cores, isn't the latest trends. But I 
don't think I ever committed the second instance to this task ;-).

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Benny Prijono | 3 Apr 2007 19:44
Favicon

ICE 15: Triggered check clarification

Hi,

I'd like to propose clarification for triggered check. Please see
Section 7.2.1.4.  Triggered Checks for reference.

Background 1)

"
  Next, the agent constructs a pair whose local candidate is equal to
  the transport address on which the STUN request was received, and
  ..
"

A typical application doesn't normally have access on the
destination address of an incoming packet (it only has access to
source address), so in the situation where a base address is 
associated with more than one candidates (for example, host and 
server reflexive), it wouldn't be possible to find which local 
candidate to choose.

Background 2)

"
  This pair is then looked up in the check list.  There can be one of
  several outcomes:
  o  If the pair is not already on the check list:

     *  The pair is inserted into the check list based on its
        priority
"
(Continue reading)

Permalink | Reply | 4 comments |
headers
Desineni, Harikishan | 3 Apr 2007 20:22

RE: Review team formed for RTSP/2.0

I was under the (wrong?) impression that 2.0 is close to becoming an
RFC. Can somebody please post the list of open issues on this thread?

-Hari

> -----Original Message-----
> From: Jean-Francois Mule [mailto:jf.mule <at> cablelabs.com]
> Sent: Monday, April 02, 2007 9:22 AM
> To: mmusic <at> ietf.org
> Cc: Colin Perkins; Joerg Ott
> Subject: [MMUSIC] Review team formed for RTSP/2.0
> 
> Folks,
> 
>    Based on our open calls during the mmusic wg meetings at IETF 67 &
> 68, we have formed a review team for RTSP with the main goal of
> resolving open issues and getting new revisions out.
> 
>    The following people have signed up to be on the review team:
>       - Martin Stiemerling (new editor)
>       - Chris Steck
>       - Dave Singer
>       - Henning Schulzrinne
>       - Jamie Gordon
>       - Magnus Westerlund
>       - Reinaldo Penno
>       - Sean Sheedy
>       - Magnus Westerlund
>       - Jean-Francois Mule
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 4 Apr 2007 10:16
Picon
Favicon

Re: Review team formed for RTSP/2.0

Desineni, Harikishan skrev:
> I was under the (wrong?) impression that 2.0 is close to becoming an
> RFC. Can somebody please post the list of open issues on this thread?
> 

This review team is an effort to finish it up. This effort has been 
lingering due to lack of editor and reviewer work. But I have great hope 
that we will be able to make reasonable progress. But I am not willing 
to even make a public guess when we actually will have finished.

The official but not completely up to date list of open issues are 
available at: https://sourceforge.net/projects/rtspspec/

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------
Permalink | Reply | 0 comments |

Gmane