[SR-Users] Kamailio - DMQ dns srv Question

[Charles Chance]

Hey,

On 22 September 2016 at 12:18, José Seabra <joseseabra4 at gmail.com> wrote:

> Hello Daniel and Charles,
> Thank you for your feedback.
> Another doubt is when we use a FQDN that only resolves as A record, would
> be better DMQ send only a A query or is there any reason for always try SRV?
>
>
As far as I recall (it's been a while since I did anything with this), the
default behaviour is to query A record only. There is a mod_param to enable
multi-record/SRV lookup:

modparam("dmq", "multi_notify", 1)

But the default is off.

Is this not the behaviour you are seeing?

Cheers,
Charles




> Thank you for your great job.
>
> BR
> José Seabra
>
> 2016-09-22 8:33 GMT+01:00 Charles Chance <charles.chance at sipcentric.com>:
>
>> Hello,
>>
>> I can take a look today.
>>
>> Cheers,
>> Charles
>>
>> On 22 Sep 2016 06:20, "Daniel-Constantin Mierla" <miconda at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I guess that the one who did the implementation of the srv query for dmq
>>> hasn't "allocated" any service name. I haven't looked at the sources, but I
>>> guess it should be a small patch to compose the srv dns string to be
>>> queried -- maybe that part can be made a mod param so each can choose its
>>> preferred service.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 21/09/16 19:28, José Seabra wrote:
>>>
>>> Hello,
>>> I have a doubt related with DMQ dns behavior, I noticed that when
>>> kamailio starts, it tries to resolve DMQ name configured on parameter
>>> notification_address as the following sequence:
>>>
>>>    1. SRV
>>>    2. A
>>>    3. AAAA
>>>
>>>
>>> Isn't supposed kamailio  try first resolve the  NAPTR DMQ name, and then
>>> SRV?
>>> I'm asking this because kamailio is trying resolve the SRV record
>>> without any transport protocol specified on query, as my dns server only
>>> accepts queries on the format "_Service._Proto.Name" the SRV will never be
>>> resolved.
>>>
>>> Thank you.
>>> BR
>>> --
>>> José Seabra
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Cumprimentos
> José Seabra
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, 
Birmingham Science Park, Birmingham B7 4BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160922/36587727/attachment.html>