[Nice] New API and refactor

[Rémi Denis-Courmont]

Le Tuesday 24 June 2008 00:09:39 ext Youness Alaoui, vous avez écrit :
> > The STUN-ICE usage is a corner case. It is of course ICE-specific. We put
> > it to the STUN part because it had a lot of common code with the binding
> > discovery, and because we did not want to expose (as far as possible) the
> > ICE agent to the STUN messages.
>
> yeah, it's ICE specific and should be in libnice, at least, that's what
> I think.
> To summarize what I just said :
> - the usages are just "how to use libstun" and should not be part of
> libstun itself.

No. Binding discovery is part of STUN. So are the timers. You could run ICE 
with any other binding discovery scheme (TURN, Teredo server, UPnP IGD, 
NAT-PMP, SOCKS...). This is part of STUN. Both in the spec, and in the 
architecture. The timers are part of STUN. They simply are.

ICE has its own timers, for connectivity probing. They are _different_ from 
the STUN ones.

I'm totally fine splitting the low-layer (message format) and mid-layer 
(usages) of STUN into different libraries. But I really think the mid-layer 
does not belong in ICE. Besides, the ICE agent code is already complicated 
enough. And if we implement another STUN usage, for instance TURN, we would 
end up having to copy all this STUN transaction code. Bad idea.

> - whoever wants to do binding requests, would only need a few lines of
> code, so no need for the bind usage

That's not true. You would need to reimplement the timers (tens of lines of 
code..), the legacy STUN rollover, the error cases, etc. All in all, you end 
up with a few hundreds of lines.

Compare the amount of STUN code in the command line STUN client, with the 
amount of STUN code in what you want to put out of libstun...

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D