On Thu, Aug 28, 2008 at 10:22 AM, Stephen D. Strowes < stephen.strowes at nokia.com> wrote: > Hi, > > I'm looking at the pjsua test client included in the pjproject source, > and I'd appreciate a little clarification: the client seems to be > generating RFC3489-style request, not RFC3489bis requests. Is this > intentional? > > Yeah, something like that. There are few STUN usages that we use in pjsua, I'm not sure which STUN request are you referring to, but some of the usage(s) do intentionally produce RFC3489-style requests indeed. The NAT type detection usage is one of them, it intentionally produces old style requests so that the server responds with old style responses, since there are few old/deprecated attributes (such as CHANGED-ADDRESS) that we need in order to make the detection work. > I've noticed the issue because I'm running turnserver > (http://www.turnserver.org/), which rejects STUN packets generated by > the pjsua test client because they're lacking the correct magic cookie > in the STUN header. > > Looking at the code, the pj_ice_strans_* functions seem to create good > STUN packets, but pjstun_create_bind_req (in stun_simple.c, pjlib-util, > which the pjsua test client ultimately uses) creates old-style STUN > packets... > > Is this accurate? It'd be really useful for me to be able to use some of > the pjsua test client code as-is. I can either modify the client, or > modify turnserver; not sure which is the path of least resistance... > > Why not just use different server for STUN and TURN? No modification is needed. :) Cheers Benny > Cheers, > -S. > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080828/6e1c4960/attachment.html
