In order to use SRV records I think you need to add code to what nameserver to use.
This is from our code:
533 if ((_res.options & RES_INIT) == 0) res_init();
534
535 int i;
536 for (i = 0; i<_res.nscount; i++)
537 {
538 pj_strdup2_with_null(app_config->pool,
539 &(app_config->cfg.nameserver[app_config->cfg.nameserver_count++]),
540 inet_ntoa(_res.nsaddr_list[i].sin_addr));
541 }
542
543 // TODO: If no dns servers are detected, system will crash
544
545 // Set up DNS SRV support (is this needed? does pjsua set this up automatically?)
546 pj_dns_resolver *resv;
547 status = pjsip_endpt_create_resolver(pjsua_get_pjsip_endpt(), &resv);
548
549 if (status == PJ_SUCCESS && app_config->cfg.nameserver_count > 0)
550 {
551 status = pj_dns_resolver_set_ns(resv, app_config->cfg.nameserver_count, app_config->cfg.nameserver, NULL);
552
553 if (status == PJ_SUCCESS)
554 {
555 status = pjsip_endpt_set_resolver(pjsua_get_pjsip_endpt(), resv);
556 }
557 }
558
559 if (status != PJ_SUCCESS || app_config->cfg.nameserver_count == 0)
560 {
561 PJ_LOG(1,(THIS_FILE, "Error: could not configure DNS SRV support"));
562 }
Best regards,
Even Andr?
On 13. okt. 2010, at 23.59, R?gis Montoya wrote:
> On 13/10/2010 16:04, Benny Prijono wrote:
>> 2010/10/9 R?gis Montoya<r3gis.3r at gmail.com>:
>>> Hi,
>>>
>>> I've a question about STUN& ICE& DNS resolvers.
>>>
>>> I'm trying to configure pjsua with stun, ice& dns srv activated.
>>>
>>> * First it resolve my stun server, that's fine, it works as expected.
>>> It seems to fill pjsua_var.stun_srv with resolved IP. (I think that's
>>> important for the next steps)
>> That is not supposed to happen. Rather, it will just use the
>> exact/original STUN server string as is, which means it won't be an IP
>> address. I suspect you may have modified PJSUA-LIB to do something
>> differently.
> You're probably right, I guess there were something wrong with the library : I don't modify pjsua, but when I do builds sometimes, when things are not cleaned between each build, I get strange results - since I build with the NDK from android, I suspect the toolkit to do strange things.
>
> Just retested it after a clean rebuild and it works now...
> However, I've just noticed something, that is more a feature request that an bug : pjsip doesn't seems to resolve Alias DNS entries (at least for stun). Maybe this problem was mixed in the first error I get on my first tests. But for example stun.ekiga.net is an alias to stun.counterpath.com ... When I put stun.ekiga.net and activate namserver, it fails since there is no _stun._udp nor A record. (This one I tried with a clean pjsip-app on my ubuntu and on my build on android ;) )
>
> Sorry for the annoyance and thanks for your answer.
>
>
>> -Benny
>>
>>> * Then, it's ICE turn. It tries to create its transports using :
>>> create_ice_media_transports . It get back stun_srv from ice_cfg.stun.server
>>> (which is at this point an ip and not a domain name).
>>> It continues and try to create the transport... but here it tries to resolve
>>> again the stun server (using dns srv fields....) ... but the stun server is
>>> now an ip address... So it send some dns request that make no sense (I
>>> think)... then fall back to the A srv record... but fail again since it ask
>>> to resolve an IP address...
>>> Finally ICE can't create transport !!!
>>>
>>> I've attached the relevant part of the log.
>>> If I disable DNS SRV (I mean if I don't provide any nameserver to pjsua),
>>> there is no problem. But it is supposed to work with dns srv resolution too,
>>> or I'm wrong somewhere in my configuration?
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20101014/334ef5cd/attachment-0001.html>
