Subject: [MMUSIC] ICE-TCP and SO

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Nov 2008 12:28:42 -0500

As folks noticed, I posted a revision of ice-tcp. However, the document 
itself has not changed as I wasn't able to invest any time in it since 
last IETF.

Since Dublin we did get confirmation that SO does not work on XP, thus 
making ICE-tcp really ineffective. I think this is the impetus for 
Bruce's framework draft.

The main questions then for the ICE-tcp draft, beyond the framework 
stuff proposed by Bruce and Adam, is:

* should we REMOVE S-O from ICE-tcp, given the problems supporting it on XP

* should we instead try to use one of the other mechanisms from Saikat's 
paper

Comments welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 17 Nov 2008 16:45:28 +0100

> * should we REMOVE S-O from ICE-tcp, given the problems supporting it on XP

does it make sense to remove S-O because it does not work on 1 given
platform? I think this approach is very Softphone oriented..
There are plenty of embedded SIP devices with their own OS/IP-stack
that might be able to support S-O.

if you want to make ICE-TCP more modular, we can also consider moving
the TCP S-O function to a separare ICE-TCP extension document.

/alfred

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Nov 2008 17:41:12 -0500

Indeed, this very comment was made at the mike during the mmusic 
session. I think we agreed to keep it.

-Jonathan R.

Alfred E. Heggestad wrote:
>> As folks noticed, I posted a revision of ice-tcp. However, the 
>> document itself has not changed as I wasn't able to invest any time in 
>> it since last IETF.
>>
>> * should we instead try to use one of the other mechanisms from 
>> Saikat's paper
>>
>> Comments welcome.
>>
>> Thanks,
>> Jonathan R.
> 
>