[Nice] Serializing NiceCandidate...

[Youness Alaoui]

On 08/24/2010 11:40 AM, Tony Di Croce wrote:
> Great! Thanks for your help... I'm now successfully talking to my stun
> server...
> 
> Regarding NiceCandidate.username and NiceCandidate.password... Is it
> safe to assume that those strings are subject to the same size limit as
> the strings passed to nice_agent_set_remote_credentials() (I.E. the
> username and password have a max size of 256 bytes)? It's convenient if
> that is true because it means that a NiceCandidate can be serialized
> into a completely fixed length structure...
Take the time to look at the code before asking your questions!

  gchar *username;        /* pointer to a NULL-terminated username string */
  gchar *password;        /* pointer to a NULL-terminated password string */

You don't know, you never know, and you can't assume that the size is fixed
(even if it is, it's better not to assume it, otherwise if you ever need to
change something in the future, you're screwed).


> 
> BTW, what is best practice for generating the username and password
> pair? Should I just generate random strings for those? Perhaps a UUID?

There is no best practice, libnice will generate it for you.. your local
candidates will have their username/password generated by libnice, and the
remote candidates's username/password will be received from the other side.
if using the MSN or GOOGLE compatibility modes, then the username/password will
be present in the NiceCandidate, otherwise (using the WLM2009/RFC5245
compatibility mode), the username/password fields will be NULL, and the
credentials will be available through nice_agent_get_local_credentials() and you
must set the remote credentials with nice_agent_set_remote_credentials().
This is because the old ICE drafts (MSN/GOOGLE compatiblity) used a user/pass
per candidate while the RFC uses a single username/password for the whole stream!

Hope this helps,
Youness.

> 
>     td
> 
> On Mon, Aug 23, 2010 at 5:34 PM, Youness Alaoui
> <youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>>
> wrote:
> 
>     FYI, You don't need everything from the structure, the 'turn'
>     attribute is also
>     internal and useless for you, same for priority.
>     Have a look at the RFC on how to encode the SDP, it might help you
>     understand
>     how to 'serialize' the candidate :
>     http://tools.ietf.org/html/rfc5245#section-4.3
> 
>     On 08/23/2010 08:06 PM, Youness Alaoui wrote:
>     > No, that's used only internally, you don't need to read it or
>     write it or
>     > anything like that!
>     > The documentation says "the underlying socket", I thought it would
>     be pretty
>     > clear...
>     >
>     > On 08/23/2010 08:04 PM, Tony Di Croce wrote:
>     >>
>     >> I have to serialize and transmit NiceCandidate objects from one
>     peer to
>     >> another... The only field i'm unsure about how to proceed with is
>     >> "sockptr"... This is defined as a gpointer... When I reconstruct
>     these
>     >> CandidateObjects on the other side of a network connection this
>     member
>     >> will be NULL... Is that OK, or should i initialize it in some way?
>     >>
>     >>    td
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> 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 <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/20100824/bfc956af/attachment.pgp>