[Nice] Starting with libnice
Youness Alaoui
youness.alaoui at collabora.co.uk
Mon Dec 12 15:39:53 PST 2011
On 12/12/2011 06:20 AM, Tiago Sá wrote:
> Hi again Youness,
Hi again Tiago,
>
> my application is progressing in small steps.
> We chose to use XMPP for the communication. We are using libstrophe, it lacks
> some documentation, but was enough for our needs.
> We implemented a naif handshake, life the one you mentioned above, by exchanging
> some xmpp message stanzas.
Cool, you may want to look at the jingle XEP to see how candidates are being
transferred in a VoIP call.
>
> This application will be part of a research project involving the grid, where we
> need private hosts (called agents) to be able to communicate someway. We will
> implement that (inter-agent) communication protocol later, right now we are
> concerned with the NAT traversal thing, and it seems to be working fine :)
>
> Now, I would like to ask you a final question:
> Right now we are able to send strings using "nice_agent_send". We would like to
> establish a socket between the hosts and use other common primitives to code our
> application.
> Maybe the best possibility would be to create some kind of pipe from an
> "external" application using local ports (something
> like http://code.google.com/p/gnat/)
> Or, in a simpler way, just pipe stdin/stdout from another app, slice that data
> and send it using libnice send primitive?
>
> Have you ever tried something like this?
I have not tried something like that, but it shouldn't be too hard in my
opinion. You could just create a local daemon that connects to the XMPP server,
and when it gets a new local connection, it sends candidates and acts as a proxy
between the 127.0.0.1:12345 socket and the remote socket with the
nice_agent_send and the recv callback.
Would be nice if that code gets shared if you ever get to do it. But I don't see
anything that would prevent it from working.
Good luck!
>
> Thank you very much for your help.
>
> Cheers,
> Tiago
>
>
>
>
> On Mon, Nov 28, 2011 at 12:46 PM, Youness Alaoui <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>> wrote:
>
> On 11/23/2011 01:14 PM, Tiago Sá wrote:
> > Hi Youness,
> >
> > thank you for your suggestions.
> > You'r right, the STUN/TURN server I was using had a connection limit. I
> > installed the turnserver.org <http://turnserver.org>
> <http://turnserver.org> one in a public addressed
> > machine.
> > I also changed the way how I was writing the candidates, setting those
> pointers
> > to NULL.
> > ICE seems to be working properly now! :)
> Glad it worked :)
>
> >
> > I have a question:
> > According to the example in http://nice.freedesktop.org/libnice/NiceAgent.html
> > we should be able to start sending messages after the signal new-selected-pair
> > is fired. However, I tried it but no success:
> > void
> > cb_new_selected_pair (void)
> > {
> > printf ("cb_new_selected_pair\n");
> > nice_agent_send(agent, stream_id, NICE_COMPONENT_TYPE_RTP,
> strlen("Ola"),"Ola");
> > }
> >
> > That first message is never received. However, after "a while" I try to send
> > again and it works. Do I have to wait for the other agent to be ready to
> receive?
> Humm.. that might not have been entirely true.. technically if there is a
> selected pair, then it should work, unless you are ready locally, but the remote
> isn't ready to receive yet. technically you should wait for the state to go to
> READY... and not care about the selected pair.. the docs might be wrong there,
> but it's been a while and I'm not entirely sure of the use case that would make
> it fail (but in every other project, we use the READY state as an indication
> that we're ready to send).
>
> >
> > Well, this is a checkpoint for me, but I must ask for another suggestion now.
> > I need to improve the way how the communication between agents is made
> > (exchanging candidates/credentials, initiating p2p connections, etc...)
> > As I read in this
> > thread http://lists.freedesktop.org/archives/nice/2010-August/000330.html
> , you
> > wrote:
> > "well, the serialization, if I understand what you mean, is how you send the
> > candidates to the other side, right ? In that case, that's not part of the ICE
> > methodology.. you can 'serialize' the candidates/user/pass any way you want..
> > one method is to put it in the SDP of a SIP invite. You can also send it as an
> > XML using Jingle's XEP over an XMPP connection.. it really all depends on what
> > protocol is being used to connect to the server (SIP, XMPP, custom, other...).
> > I'll let you decide on the best way to do that."
> Thanks for searching in the archives :)
>
> >
> > After doing some research, I feel a bit scared. That is a completely new world
> > for me. Could you please point the "simplest and most feasible" solution for
> > this problem? Should I choose SIP or XMPP?
> > libjingle, for example, presents a huge API...
> > Do you know any simple client, possibly allowing me to connect to an existing
> > infrastructure (such as Google Talk), I could use for this trivial information
> > exchange?
>
> Humm.. yes, libjingle is a big pile of **** :) my suggestion is to never use it!
> The real question here is what do you need libnice for? what will the clients be
> ? if it's for a game or some custom application and that you can control the
> server and the client, then you can setup something custom. If you want to have
> a list of contacts in your application and the user can just select one and it
> will know what to do, then using XMPP might be the best solution. It really all
> depends on your needs and capabilities.. you can decide all about it, but here's
> a simple example if you want :
> client sending to server is : --->
> client receiving from server is : <-----
> Comments are preceded with #
> ----> HELLO
> <---- HELLO 12345 # Where 12345 would be a random id that gets assigned to you
> ----> 54321 BEGIN ICE # first number being the 'random id' of the destination
> ----> 54321 ICE-CREDENTIALS <the_username> <the_password>
> ----> 54321 CANDIDATE 1 UDP 192.168.1.100 43132 host
> ----> 54321 CANDIDATE 2 UDP 1.2.3.4 52133 srv-reflx
> ----> 54321 ICE DONE # To say you're done, you can send it to the peer
> <---- 54321 ICE REPLY
> <---- 54321 ICE-CREDENTIALS foo bar # the remote's credentials
> <---- 54321 CANDIDATE 1 UDP 192.168.1.200 54521 host
> <---- 54321 CANDIDATE 2 UDP 1.2.4.1 9614 srv-reflx
> <---- 54321 CANDIDATE 3 UDP 4.3.2.1 32957 <tel:4.3.2.1%2032957> relay-reflx
> <---- 54321 ICE DONE
> [...]
> ----> 54321 ICE DESTROY
>
> And your server just maps sockets with those random ids, and relays the data
> from one socket to another. And you parse the received input and build your
> candidates...
> So this is a very simple, but of course inefficient, you get a random id
> everytime, it's hard to improve the protocol, etc... so using XMPP would be
> better, but if you really don't need that much, then this might be the solution
> you want.. like I said, it really depends on what you need it for.
> As for XMPP, you can look at the 'wocky' library
> (http://cgit.freedesktop.org/wocky/)
>
>
> >
> > Thank you for your help.
> You're welcome :)
>
> >
> > Regards,
> > Tiago Sá
> >
> >
> >
> > On Thu, Nov 17, 2011 at 9:42 PM, Youness Alaoui
> <youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>> wrote:
> >
> > On 11/16/2011 08:30 PM, Tiago Sá wrote:
> > > Hi again Youness,
> > > thanks a lot for your help.
> > > I believe I solved the problems you pointed before.
> > > I am using a dumb method to exchange candidates. I write them to
> file and
> > > exchange them using a ftp server (I will improve it later).
> > >
> > > So, the way I run it is:
> > > (HostA) ./client l
> > > (HostB) ./client r
> > > //local candidates are gathered and written to file
> > > (HostA) put leftCands.bin on FTP and get rightCands.bin
> > > (HostB) put rightCands.bin on FTP and get leftCands.bin
> > > //read local credentials and write them on the remote host
> > >
> > > I am using a relay server, that should work as a last resort. But
> during the
> > > local candidate gathering, sometimes it gets a relayed candidate,
> but most of
> > > the times it doesn't. Can it be related with timeouts?
> > It's possible the timeouts are affecting it, but I doubt it, usually
> the RTT
> > would be 200ms, but if you don't get a response from the relay or the stun
> > server, it will retry 4 times until it times out after about 3 seconds.
> > It's possible though that the server has a limit on the number of
> allocations
> > you can create (probably 5) and if you are testing your app and it
> creates 2
> > allocations each time (one for each side), then it's possible the
> server starts
> > rejecting your allocation requests (each time you want to use TURN, it
> will ask
> > the server to allocate a port for you for that specific connection, so
> you have
> > the same settings but one port for each stream/component).
> > If that's the case, maybe that's why it sometimes works (when the
> allocation
> > times out from the server). libnice should technically deallocate when the
> > stream is destroyed, so maybe catch your Ctrl-C and do an unref on the
> agent
> > before returning from the main.
> >
> > >
> > > Either way, it can never get a pair a establish a connection. :(
> > > I don't have a clue why this happens..
> >
> > A log + wireshark dump might be helpful in this case. You can enable
> logging
> > with :
> > export NICE_DEBUG=all
> >
> >
> > >
> > > Can you please have a look?
> > The code looks sane enough.. apart from the obvious method of exchanging
> > candidates which isn't "optimal". One thing I noticed though, you just
> fwrite
> > the whole structure, but note that there are pointers in the structure
> that will
> > be written as is to the file, and not their content. I'm thinking of
> > username+password (but those should be NULL if you use the RFC5245
> compatibility
> > mode) but mostly the turn structure (which is just for local
> candidates and
> > wouldn't be used anyways for remote ones, but it's best to set it to
> NULL to
> > avoid possible crashes).
> >
> > >
> > > Cheers,
> > > Tiago
> > >
> > >
> > > On Fri, Nov 4, 2011 at 2:03 PM, Youness Alaoui
> > <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> <mailto:youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>> wrote:
> > >
> > > Hi again Tiago,
> > >
> > > For the remote candidates, you will need a third party server to
> > exchange that
> > > information, usually the candidates would be sent over SIP or
> XMPP for
> > example.
> > > ICE cannot work if you don't have a third party server with
> which you can
> > > reliably exchange candidates. For testing purposes you could have it
> > print the
> > > candidates to stdout, and you could copy/paste that into stdin
> of the
> > other
> > > instance and have it parse the input.. or you could hardcode a
> port to
> > connect
> > > to and do the candidate exchange.. there's no easy way of doing that
> > though.
> > > You cannot hardcode the candidates because the port used will be
> random
> > > everytime, also, you will need to exchange the randomly generated
> > > username/password (nice_agent_get_local_credentials +
> > > nice_agent_set_remote_credentials) to make the connectivity
> checks work.
> > >
> > > As for your example, here are a few comments :
> > > 1 - you call the nice_agent_set_relay_info with stream_id being
> > uninitialized,
> > > you must call it *after* you do the nice_agent_add_stream...
> > > 2 - you don't need those GValues, you can just do
> > > g_object_set (G_OBJECT(agent),
> > > "stun-server", "66.228.45.110",
> > > "stun-server-port", 3478,
> > > NULL);
> > > 3 - You shouldn't set the remote credentials as the same as the
> local ones
> > > 4 - In your print_candidate_info, you may also want to print the
> port
> > used.
> > >
> > > I hope this helps, let me know if you have further questions.
> > >
> > > Youness.
> > >
> > >
> > > On 11/03/2011 12:57 PM, Tiago Sá wrote:
> > > > Hi Youness,
> > > >
> > > > I have been trying to create a simple application based on the
> first
> > link you
> > > > pointed before.
> > > > Thanks for the tips you gave me. I have a couple of questions
> though, if
> > > you can
> > > > help me.
> > > >
> > > > I need to find a way to get the remote candidates passed from
> a peer to
> > > another.
> > > > Can you point an easy way to do that?
> > > > Could I hardcode the remote candidates list, for testing purposes?
> > > >
> > > > Right now, I only get two local candidates (HOST and
> SERVER_REFLEXIVE).
> > > > I am trying to use the numb TURN server, shouldn't I get a RELAYED
> > > candidate too?
> > > >
> > > > I am attaching the code. Can you please have a look at the
> code and
> > check
> > > where
> > > > the error could be?
> > > >
> > > > Thanks for helping!
> > > >
> > > > Regards,
> > > > Tiago Sá
> > > >
> > > >
> > > > On Wed, Oct 19, 2011 at 10:53 PM, Youness Alaoui
> > > <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> <mailto:youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>>>
> > > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>>> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Welcome to the world of libnice :)
> > > > Yes, doing NAT traversal is far from being easy, the only
> > solution is
> > > pretty
> > > > much to use the ICE specification and that's not easy to
> > implement, so
> > > that's
> > > > why you'd need to use libnice.
> > > >
> > > > For an example, you can have a look at the unit tests, like
> > > > tests/test-fullmode.c for example, although that does a lot of
> > stuff.
> > > You can
> > > > see a quick example in the documentation for NiceAgent :
> > > > http://nice.freedesktop.org/libnice/NiceAgent.html
> > > >
> > > > For smaller examples, you can look at the libnice mailing list
> > > archives, some
> > > > people posted their example code where they were having
> > problems. For
> > > example, a
> > > > very simple example can be seen here :
> > > >
> http://lists.freedesktop.org/archives/nice/2011-January/000404.html
> > > > But make sure to click on the "Next message" to read the whole
> > thread
> > > because
> > > > that example had a bug that I explained how to fix in the
> following
> > > emails.
> > > > Same for this thread :
> > > >
> http://lists.freedesktop.org/archives/nice/2011-October/000434.html
> > > >
> > > > I hope that helps,
> > > > Youness.
> > > >
> > > > On 10/19/2011 09:58 AM, Tiago Sá wrote:
> > > > > Hi all,
> > > > >
> > > > > my name is Tiago Sá, I am a junior researcher from Portugal
> > and this
> > > is my
> > > > first
> > > > > mail to this list.
> > > > > I have a NAT traversal problem to solve and I have been
> > looking for
> > > a solution
> > > > > during the last weeks, which, as I found out, is not so
> > trivial as I
> > > > thought before.
> > > > > As stated on the libnice homepage, libnice seems to be
> what I am
> > > looking for:
> > > > >
> > > > > "ICE is useful for applications that want to establish
> > peer-to-peer
> > > > UDP data
> > > > > streams. It automates the process of traversing NATs and
> > > provides security
> > > > > against some attacks. It also allows applications to
> > create reliable
> > > > streams
> > > > > using a TCP over UDP layer."
> > > > >
> > > > >
> > > > > I have been looking for the provided documentation and I am
> > feeling kind
> > > > of lost.
> > > > > Is there any example application or tutorial to get started?
> > > > > Could you please share a basic application of this kind or
> > point me a
> > > > direction?
> > > > >
> > > > >
> > > > > Thanks in advance for your help.
> > > > >
> > > > > Regards,
> > > > > Tiago Sá
> > > > >
> > > > > --
> > > > > Tiago Sá
> > > > > Universidade do Minho, Braga - Portugal
> > > > >
> > > > > http://about.me/tiagosa/
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Nice mailing list
> > > > > Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>
> > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>>
> > > > > http://lists.freedesktop.org/mailman/listinfo/nice
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Nice mailing list
> > > > Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>
> > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>>
> > > > http://lists.freedesktop.org/mailman/listinfo/nice
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Tiago Sá
> > > > Universidade do Minho, Braga - Portugal
> > > > www.tiagosa.com <http://www.tiagosa.com>
> <http://www.tiagosa.com> <http://www.tiagosa.com>
> > <http://www.tiagosa.com>
> > > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Tiago Sá
> > > Universidade do Minho, Braga - Portugal
> > > www.tiagosa.com <http://www.tiagosa.com> <http://www.tiagosa.com>
> <http://www.tiagosa.com>
> > >
> >
> >
> >
> >
> >
> > --
> > Tiago Sá
> > Universidade do Minho, Braga - Portugal
> > www.tiagosa.com <http://www.tiagosa.com> <http://www.tiagosa.com>
> >
>
>
>
>
>
> --
> Tiago Sá
> Universidade do Minho, Braga - Portugal
> www.tiagosa.com <http://www.tiagosa.com>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20111212/7b643093/attachment.pgp>
More information about the nice
mailing list