[Nice] New API and refactor
remi.denis-courmont at nokia.com
Thu Jul 3 00:43:00 PDT 2008
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...
Maemo Software, Nokia Devices R&D
More information about the Nice