[Nice] Starting with libnice
Tiago Sá
tiagosa at di.uminho.pt
Wed Nov 23 10:15:49 PST 2011
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 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! :)
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?
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."
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?
Thank you for your help.
Regards,
Tiago Sá
On Thu, Nov 17, 2011 at 9:42 PM, Youness Alaoui <
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>> 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>>> 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>>
> > > > 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>>
> > > 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>
> > >
> >
> >
> >
> >
> >
> > --
> > 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/20111123/ba8c07df/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.c
Type: text/x-csrc
Size: 9628 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/nice/attachments/20111123/ba8c07df/attachment-0001.c>
More information about the nice
mailing list