[Nice] minimal example

[Youness Alaoui]

You're welcome.
I don't think it's necessary to have an API for it because it's so simple, also,
everyone will print it differently.. if you use XMPP, it will be different (in
xml), if you use SIP/SDP it will be different (needs to follow the
specifications for that), if you have your own custom thing, you may want it in
binary form, etc...
and in the end, it's so simple that you can write it in 5 minutes inside your
mail client, so there's no need for it in my opinion. There will be an example
though once we can get a proper tutorial for libnice (I'm still waiting for
someone to contribute that... )



On 01/13/2012 04:47 PM, Eduardo Bezerra wrote:
> Perfect, this is exactly what I was looking for. Maybe in the future there could
> be two more functions in the nice api for this? Anyway, now I'm going to
> implement a small rendezvous server to make this candidate exchange...
> 
> Thanks again, Youness
> 
> 
> On Fri, Jan 13, 2012 at 10:09 PM, Youness Alaoui <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>> wrote:
> 
>     Should be fairly easy to serialize, it's not such a big structure. All you need
>     is the type, component id, address and priority.
>     Here it explains how to encode it into a string for the SDP protocol :
>     http://tools.ietf.org/html/rfc5245#section-15
>     You can do simpler with something like :
> 
>     nice_address_to_string(cand->addr, addr_string);
>     sprintf(out, "CANDIDATE: %s %d %d %s %s\n",
>           cand->foundation, cand->component_id, cand->priority,
>           cand->transport == NICE_CANDIDATE_TRANSPORT_UDP ? "UDP" : "UNK",
>           addr_string, nice_address_get_port(cand->addr),
>           cand->type == NICE_CANDIDATE_TYPE_HOST ? "host" :
>           cand->type == NICE_CANDIDATE_TYPE_SERVER_REFLEXIVE ? "srv" : "relay")
> 
>     and read it with :
> 
>     sscanf (in, "CANDIDATE: %s %d %d %s %s\n",
>           foundation, component_id, priority,
>           transport_str, addr_string, addr_port, type_str);
>     cand = nice_candidate_new(memcmp(type_str, "host") == 0 ?
>                              NICE_CANDIDATE_TYPE_HOST :
>                              memcmp(type_str, "srv") == 0 ?
>                              NICE_CANDIDATE_TYPE_SERVER_REFLEXIVE :
>                              NICE_CANDIDATE_TYPE_RELAY_REFLEXIVE);
>     memcpy(cand->foundation, foundation, NICE_CANDIDATE_MAX_FOUNDATION);
>     cand->component_id = component_id;
>     cand->priority = priority;
>     cand->transport = NICE_CANDIDATE_TRANSPORT_UDP;
>     nice_address_set_from_string(cand->addr, addr_string);
>     nice_address_set_port(cand->addr, addr_port);
> 
>     This should do it.. don't forget to also send out your credentials separately.
> 
>     Hope this helps,
>     Youness.
> 
>     On 01/13/2012 03:36 PM, Eduardo Bezerra wrote:
>     > Yes, I guess I'll need some 3rd guy in the middle to allow the two peers to
>     > connect to each other (and then, hopefully, communicate directly). But how to
>     > you go from a NiceCandidate struct of a peer (which contains several other
>     > structs and unions) to, say, a string? Such string could be sent to the
>     > 3rd-party and forwarded to the other peer, which would parse it and
>     recreate the
>     > NiceCandidate struct, for each received remote candidate... The thing is
>     that I
>     > want different platforms to communicate, so there should be some "protocol" to
>     > send the candidates info...
>     >
>     >
>     > On Fri, Jan 13, 2012 at 8:49 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,
>     >
>     >     Thanks Tiago for taking over while I was asleep! Nice to see all this
>     activity
>     >     and to have Eduardo's tests successful! :)
>     >     Having a nat friendly retwork as one of the peers guarantees success,
>     if you
>     >     have two nat-hostile networks, then it depends on the type of NATs
>     involved, if
>     >     both are symmetric NATs, then it will fail, if at least one of them is
>     not a
>     >     symmetric NAT, then it should succeed (c.f.
>     >    
>     http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_Port_translation
>     >     )
>     >
>     >     libnice does not provide any serialization method, you will still
>     always need a
>     >     third party server to do the candidate exchange and that will depend
>     on the
>     >     protocol used by this server, could be XMPP, could be SIP, could be
>     custom, it
>     >     really all depends on what your needs are and what the server
>     supports/accepts.
>     >
>     >     Youness.
>     >
>     >
>     >
>     > _______________________________________________
>     > Nice mailing list
>     > 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>
>     http://lists.freedesktop.org/mailman/listinfo/nice
> 
> 
> 
> 
> _______________________________________________
> Nice mailing list
> Nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice


-------------- 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/20120113/0a3a4aa4/attachment.pgp>