[Nice] Starting with libnice
Tiago Sá
tiagosa at di.uminho.pt
Mon Dec 12 03:21:25 PST 2011
Hi again Youness,
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.
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?
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> 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> 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 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>> 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>>> 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>>>> 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>>>
> > > > > 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>>>
> > > > 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>
> > > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > 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>
> >
>
>
>
--
Tiago Sá
Universidade do Minho, Braga - Portugal
www.tiagosa.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20111212/3da77169/attachment-0001.htm>
More information about the nice
mailing list