headers
Colin Perkins | 1 Aug 2005 09:16

Working group last call: draft-ietf-mmusic-sdp-bfcp-02.txt

This is to announce a working group last call on SDP Format for  
Binary Floor Control Protocol <draft-ietf-mmusic-sdp-bfcp-02.txt>.  
Please send any final comments on this draft to the <mmusic <at> ietf.org>  
mailing list by 22nd August 2005. If no substantive issues are raised  
by that time, we will request the IETF publish this draft as a  
Proposed Standard RFC.

Colin
Permalink | Reply | 1 comment |
headers
Colin Perkins | 1 Aug 2005 09:12

Working group last call: draft-ietf-mmusic-comedia-tls-04.txt

This is to announce a working group last call on Connection-Oriented  
Media Transport over TLS in SDP <draft-ietf-mmusic-comedia- 
tls-04.txt>. Please send any final comments on this draft to the  
<mmusic <at> ietf.org> mailing list by 22nd August 2005. If no substantive  
issues are raised by that time, we will request the IETF publish this  
draft as a Proposed Standard RFC.

Colin
Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 1 Aug 2005 12:17
Picon
Favicon

Re: ICE issue 1: avoiding the STUN flood

Hi Jonathan,

I think the proposal looks good. I think it is a very reasonable 
approach. As you are going to perform checks in semi parallel way there 
will definitely be a need for a timer allowing for certain randomness in 
behavior. Also due to the occasional packet loss the retransmission of 
binding requests needs to be given a reasonable time to be sent and 
returned for the higher prioritized items.

Cheers

Magnus

Jonathan Rosenberg wrote:
> The algorithm in the ICE spec, as currently specified, has each endpoint 
> doing a connectivity check from each of its candidates, to each of its 
> peer candidates, completely in parallel. If you have a multi-homed host 
> with two interfaces, and you have a STUN, TURN server, and you are 
> dual-stack, you end up with 12 candidates and 144 parallel connectivity 
> checks to a similarly equipped peer.
> 
> This presents several problems:
> 
> 1. Magnus had raised this concern some time back, about the congestion 
> load on the network with the checks. This is becoming significant.
> 
> 2. There have been reports of NATs that, if the packet rates are too 
> high, revert to symmetric behaviors. They also limit the number of ports 
> that they'll allocate in some cases.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Magnus Westerlund | 1 Aug 2005 12:20
Picon
Favicon

Re: ICE issue 2: TCP or not TCP?

Hi,

Jonathan Rosenberg wrote:
> So, we have a few options:
> 
> 1. abandon TCP entirely, stick with UDP only
> 2. keep TCP, but put it in a separate draft that progresses independently
> 3. keep TCP in the current draft
> 
> 

I would support option 3. The checks and handling of TCP in ICE doesn't 
seem overly complex and can clearly be tided up quickly in the same way 
that the rest of the draft needs some tidying up.

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 <at> ericsson.com
Permalink | Reply | 0 comments |
headers
Joerg Ott | 1 Aug 2005 11:24
Picon
Picon
Favicon

Slides now on the web page

Hi,

the MMUSIC slides for today's session are now online at

http://www.dmn.tzi.org/ietf/mmusic/63/63-mmusic-agenda.html

Cheers,
Joerg
Permalink | Reply | 0 comments |
headers
Colin Perkins | 1 Aug 2005 18:02

Working group last call: draft-ietf-mmusic-connectivity-precon-00.txt

This is to announce a working group last call on the Connectivity  
Preconditions for SDP <draft-ietf-mmusic-connectivity- 
precon-00.txt>.  Please send any final comments on this draft to the  
<mmusic <at> ietf.org> mailing list by 29th August 2005.

If no substantive issues are raised by that time, we will request the  
IETF publish this draft as a Proposed Standard RFC.

Colin
Permalink | Reply | 1 comment |
headers
Colin Perkins | 1 Aug 2005 18:04

Working group last call: draft-ietf-mmusic-securityprecondition-00.txt

This is to announce a working group last call on the Security  
Preconditions for SDP <draft-ietf-mmusic- 
securityprecondition-00.txt>.  Please send any final comments on this  
draft to the <mmusic <at> ietf.org> mailing list by 29th August 2005.

If no substantive issues are raised by that time, we will request the  
IETF publish this draft as a Proposed Standard RFC.

Colin
Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 2 Aug 2005 14:38

Summary of IMG discussion

About 9 interested individuals, including the WG chairs, had a lunch 
meeting to discuss IMG future. Some of the results:

- The current envelope draft contains extraneous architecture material 
that obscures the mechanical aspects of the envelope. The draft should 
be slimmed down to focus on sections 5 through end, including offering 
an example.

- Alignment of the draft with the related 3GPP effort may be desirable; 
if possible, the IMG draft could be a superset of the 3GPP effort. 
Apparently, the 3GPP effort contains an XML envelope, with references to 
objects in MIME parts. Action item: those with detailed knowledge please 
provide background.

Rod Walsh, as current editor, will provide a date by which a revised 
version will be available.

- Additional drafts needed include:
   - a SIP event package for notifications of IMG object changes;
   - a URN definition for IMG objects
   - a DDDS (NAPTR) definition for resolving these URNs to an 
"actionable" URL such as http (for retrieval) or sip (for events)
   - an architecture document describing how these 4 efforts (three 
above  + envelope) work together, using some of the text cut from the 
envelope draft;

Parties interested in contributing to these drafts are invited to make 
themselves known.

- These drafts will start as individual contributions, but there is some
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 2 Aug 2005 15:14
Picon
Favicon

draft-ietf-mmusic-ice-05: TCP keep-alive of bindings

Hi,

How is keep-alive really done in the TCP case for the active session. It 
is clear that the demultiplexing that can be used for RTP over UDP 
doesn't work. With the TCP framing of RTP there will be for all RTP 
packets of shorter length 256 will have a 0 octet initially for each 
packet. Thus STUN and RTP framing can't be disambiguied.

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 <at> ericsson.com
Permalink | Reply | 2 comments |
headers
Magnus Westerlund | 1 Aug 2005 20:12
Picon
Favicon

The indication of candidates belonging to a transport adress

Hi,

I think we should consider if not explicitly indicating which of the 
transport address (RTP or RTCP) a candidate belongs to actually is a 
important optimization as it can reduce the number of checks need from 
N*M to N/2*M/2.

The current way of simple specifying two candidates of the same priority 
level do work. However it does cause you to check RTCP against RTP 
candidates instead of only checking RTP against RTP candidates.

This is a significant gain reducing the number of possible checks with a 
factor of 4. Thus I think it can be worth specifying support in the 
candidate attribute. One proposal would be to have a 
Group:NR_WITHIN_GROUP construct to id the candidates belonging.

I would also like to point out that the current SDP attribute syntax is 
broken. It ends with a SP and does not specify group.

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 <at> ericsson.com
Permalink | Reply | 0 comments |

Gmane