[Nice] Starting with libnice

Tiago Sá tiagosa at di.uminho.pt
Thu Jan 26 03:56:06 PST 2012


Hi Youness,

I have a simple question for you:
Is there any way to close the "connection" to the other agent? Let him know
that you have terminated sending data?

Just unrefing the agent doesn't work.

Thanks,
Tiago

On Fri, Dec 16, 2011 at 10:42 PM, Youness Alaoui <
youness.alaoui at collabora.co.uk> wrote:

> On 12/16/2011 06:41 AM, Tiago Sá wrote:
> > Hi Youness,
> >
> > Sure! I will share the application when I succeed.
> cool :)
>
> > Before trying to pipe from a local socket I am simply testing reading
> from a
> > file and sending that data to the other agent.
> > I am using nice_agent_new_reliable and pseudo_tcp is opened:
> > "(process:11881): libnice-DEBUG: Agent 0xb97de0: s1:1 pseudo Tcp socket
> Opened"
> > Can I assume that Nice will manage the acknowledgments, sequencing and
> all that
> > TCP stuff?
> Yes, libnice will handle all of that, you still use the libnice API the
> same
> way, *but* there is a small difference between a normal agent and a
> reliable
> agent. I will explain it below.
>
> >
> > This is the function I use to slice and send the file:
> >
> > int send_file(char *filename){
> >         FILE *file = fopen(filename, "rb");
> >         char *file_chunk = malloc(CHUNK_SIZE);
> >
> >         size_t nbytes = 0;
> >         int sent=0;
> >         while ( (nbytes = fread(file_chunk, sizeof(char),
> CHUNK_SIZE,file)) > 0)
> >         {
> >                 int offset = 0;
> >                 while (((sent =
> > nice_agent_send(agent,stream_id,NICE_COMPONENT_TYPE_RTP,nbytes,fi
> > le_chunk+offset)) > 0) || (sent == -1 && errno == EINTR) ) {
> >                         if (sent > 0) {
> >                                 printf("SENT FILE: chunk size: %zu send
> result:
> > %d \n",nbytes,sent);
> >                                 offset += sent;
> >                                 nbytes -= sent;
> >                         }
> >                 }
> >         }
> >         return 0;
> > }
> >
> > And the callback to receive:
> >
> > void
> > cb_nice_recv (NiceAgent * agent, guint stream_id, guint component_id,
> >               guint len, gchar * buf, gpointer user_data)
> > {
> >   FILE *file_received=fopen("testFile-received.txt", "ab");
> >
> >   if(file_received){
> >       int writen = fwrite(buf,sizeof(char),len,file_received);
> >      printf("RECEIVED FILE: buf size: %d , writen size:
> %d\n\n",len,writen);
> >   }
> >   else{ perror("ERROR OPENING FILE\n"); }
> > }
> >
> > It sends some chunks and then starts to fail on send.
> >
> > Problably I should use the "reliable-transport-writable" signal, to wait
> before
> > trying to send a new chunk, but then, the signal must be handled by a
> different
> > callback, am I write? Or can I "wait" for the signal on the same
> send_file function?
>
> The read callback is fine, although you should remember to fclose the
> file...
> As for the sending, you're not waiting for it to be writable. I don't
> think that
> 'errno' has any meaning either in the world of libnice...
>
> The way you should do it is to send data using a callback function that
> you hook
> into the reliable-transport-writable signal. That signal will be sent when
> you
> first connect (so you don't need to listen for state changes actually),
> and then
> it will only be sent if the nice_agent_send returns less bytes than you
> tried to
> send or if it returns -1.
> Don't forget that if you call nice_agent_send, and it returns the right
> number
> of bytes sent, then the writable signal will not be emitted.. the emission
> of
> the signal is only enabled IF the last operation of the nice_agent_send
> was that
> it couldn't send the full buffer you gave it..
>
> So here's a quick pseudocode to illustrate how you should do it :
> void
> writable_cb (NiceAgent *agent, guint sid, guint cid, gpointer data)
> {
>  FILE *file = data;
>   char *file_chunk = malloc(CHUNK_SIZE);
>  size_t nbytes = 0;
>  int sent=0;
>
>   while ( (nbytes = fread(file_chunk, sizeof(char), CHUNK_SIZE, file)) > 0)
>  {
>      int offset = 0;
>      sent = nice_agent_send(agent,stream_id, NICE_COMPONENT_TYPE_RTP,
>              nbytes,file_chunk);
>      if (sent < nbytes) {
>           /* If return value is -1 it means nothing was sent */
>           if (sent == -1)
>              sent = 0;
>           /* seek back to the last byte that was actually sent, so it gets
>              read on the next pass */
>           fseek (file, nbytes - seek, SEEK_CURRENT);
>
>           /* break and exit the function, wait for the next signal callback
>              to continue sending the rest of the data */
>           break;
>      }
>  }
> }
>
> main() {
>
>  FILE* fd = fopen("some_file.txt", "rb");
>
>  agent = nice_agent_reliable_new();
>  g_signal_connect(agent, "reliable-transport-writable", writable_cb, fd);
>
> }
>
>
> This should be enough to give you an idea on what needs to be done.
> Hope it helps!
>
> Youness.
>
> >
> > Thank you for the helpful information you are sharing.
> >
> > Cheers,
> > Tiago Sá
> >
> >
> > On Mon, Dec 12, 2011 at 11:39 PM, Youness Alaoui <
> youness.alaoui at collabora.co.uk
> > <mailto:youness.alaoui at collabora.co.uk>> wrote:
> >
> >     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 <http://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>
> >     > <mailto: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>
> >     >     <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>
> >     <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>>
> >     >     > <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:
> >     >     >
> >     >     >     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>>>
> >     >     >     > <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 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>>>>
> >     >     >     >     > <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
> >     <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>>>>
> >     >     >     >     <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 <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>>>>
> >     >     >     >     <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 <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>
> >     >     >     <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>
> >     >     <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>
> >
>
>
>


-- 
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/20120126/a9156bb3/attachment-0001.htm>


More information about the nice mailing list