[Nice] Starting with libnice
Youness Alaoui
youness.alaoui at collabora.co.uk
Mon Nov 28 04:46:24 PST 2011
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>
>
-------------- 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/20111128/f10e65c9/attachment.pgp>
More information about the nice
mailing list