Subject: [MMUSIC] Notes from ICE call on 9/26

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2006 14:18:16 -0400

ICE call
September 26, 2006

Tim Moore
Kevin Johns
Philip Matthews
Derek MacDonald
Vicky Chan
Rohan Mahy
Jonathan Rosenberg

General agreement on symmetric RTP. Make a clear statement that
symmetric behavior is what ICE produces. Question though: what is the
problem with non-symmetric operation? Various network middlebox cases
(not just SBCs), like qos-installers, monitors, diagnostic tools, were
raised.

Need to clarify behavior of ICE for unidirectional media -
sendonly/recvonly.

Agreement for the most part on the call that it is more desirable to
have one side of the call pick a pair and communicate that to the far
end rather than having each side independently pick its own
candidate. This is choice 2a in my note on 9/26 entitled "ICE
Finishing: Design choices". Jonathan still on the fence.

Long debate once again on the question of what to do when m/c-line
doesn't match what is selected, and in particular the case where there
is an SBC that has mucked with the m/c-line and left the candidate
attributes in. ICE-10, per agreement at the last meeting, says to
abort ICE. This is re-raised and folks want to allow ICE to
proceed. Derek makes a proposal that if the m/c-line doesn't match, do
a check on the m/c-line if you havent and if it works use it, else
not. Some interest in this; questions on whether it would work with
SBCs that pass RTP and not STUN.

No real conclusion. Jonathan strongly encourages folks to please post
on the list during the week so we can have some forward progress prior
to the next call.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Philip Matthews <[email-masked]>
Date: Tue, 26 Sep 2006 15:39:52 -0400

> SBCs that pass RTP and not STUN.

Regarding the possibilities of SBCs that might pass RTP and not STUN:
Such behavior would mean that the STUN keep-alives as currently  
defined in the
ICE  spec would fail.  It also seem likely that such SBCs would also  
block the multiplexing
of STUN packets with other protocols (like SIP, as in the sip- 
outbound proposal).
So I now suggest that we ignore this case and explore further Derek's  
suggestion
to run a STUN check on the (modified) m/c-line.

- Philip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 22:03:25 +0200

Hi,

It is true that an SBC may, or may not, pass STUN messages. 

But, I think you could have situations where STUN messages are dropped
somewhere in the network (e.g. due to some filters) even if do not have
an SBC in the path, and the m/c-lines do match one of the alternatives.

Regards,

Christer

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]] 
> Sent: 26. syyskuuta 2006 22:40
> To: Jonathan Rosenberg
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] Notes from ICE call on 9/26
> 
> 
> proceed. 
> > Derek makes a proposal that if the m/c-line doesn't match, 
> do a check 
> > on the m/c-line if you havent and if it works use it, else 
> not. Some 
> > interest in this; questions on whether it would work with SBCs that 
> > pass RTP and not STUN.
> 
> Such behavior would mean that the STUN keep-alives as 
> currently defined in the ICE  spec would fail.  It also seem 
> likely that such SBCs would also block the multiplexing of 
> STUN packets with other protocols (like SIP, as in the sip- 
> outbound proposal).
> So I now suggest that we ignore this case and explore further 
> Derek's suggestion to run a STUN check on the (modified) m/c-line.
> 
> - Philip
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Sep 2006 11:59:40 -0400

Christer:

I agree. Successful passage (or not) of STUN packets is not a guarantee
of successful package (or not) of RTP packets.

I think you are implying that we should ignore these cases, and again  
I agree.

- Philip