[OpenSIPS-Users] OpenSIPS searches for wrong SRV record

[Nabeel]

I added '$rp = 5061' and it now registers successfully.  Just a suggestion,
if I set the listening port and transport to TLS and 5061, it makes sense
for the routing and register port to default to 5061, not remain at 5060.

On 7 July 2015 at 19:24, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:

>  Hi,
>
> add a port:
>  $rp = 5070
>
> add a transport param:
>   add_uri_param("transport=tls");
> or set a outgoing/send socket with TLS
>   force_send_socket("tls:ip:port");
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 06.07.2015 21:09, Nabeel wrote:
>
> Hi,
>
> How can I include the proto/port indications in the URI?
> On 6 Jul 2015 18:14, "Bogdan-Andrei Iancu" <bogdan at opensips.org> wrote:
>
>>  Hi Nabeel,
>>
>> According to RFC3263 (Locating SIP Servers), if no proto/port
>> indications are found in the URI, a NAPTR lookup should be tried (to
>> determine the protocol). If no luck, UDP is assumed. And it proceeds with
>> port discovery - doing an SRV lookup .
>>
>> In your case, there is no proto, proto. No NATPR either, so UDP is
>> assumed as default.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 06.07.2015 15:49, Nabeel wrote:
>>
>> The URI it seems to be resolving is "sip:mydomain.com" (from the log):
>>
>> Jul  6 10:27:20 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:parse_msg:  uri:     <sip:mydomain.com>
>>
>> Jul  6 10:27:20 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:parse_to: display={}, ruri={sip:+447479189410 at mydomain.com}
>> Jul  6 10:27:20 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:get_hdr_field: <To> [38]; uri=[sip:+447479189410 at mydomain.com]
>>
>>
>> I think the routing URI should be "sip:mydomain.com;transport=tls".
>> Please let me know how I can specify the URI for TLS in OpenSIPS.
>>
>> I have an SRV record at my domain for TLS, but not a NAPTR record.   In
>> the log below,  OpenSIPS first looks for NAPTR record, doesn't find it,
>> then looks for SRV record, but it is for UDP so it fails:
>>
>> Jul  6 07:42:14 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:mk_proxy: doing DNS lookup...
>> Jul  6 07:42:14 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
>> Jul  6 07:42:14 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:get_record: lookup(mydomain.com, 35) failed
>> Jul  6 07:42:14 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:sip_resolvehost: no valid NAPTR record found for mydomain.com,
>> trying direct SRV lookup...
>> Jul  6 07:42:14 server0 /usr/local/sbin/opensips[1731]:
>> DBG:core:get_record: lookup(_sip._udp.mydomain.com, 33)
>> failed                                                    Jul  6 07:42:14
>> server0 /usr/local/sbin/opensips[1731]: DBG:core:sip_resolvehost: no valid
>> SRV record found for _sip._udp.mydomain.com, trying A record lookup...
>> Jul  6 07:42:14 server0 /usr/local/sbin/opensips[1731]:
>> ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 1  (no corresponding
>> listening socket)
>> On 6 Jul 2015 09:34, "Bogdan-Andrei Iancu" <bogdan at opensips.org> wrote:
>>
>>>  Hi,
>>>
>>> What is the complete SIP URI that OpenSIPS tries to resolve ? What kind
>>> of query (NATPR , SRV, AAA) and the query string depends on the RURI you
>>> have.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 05.07.2015 09:36, Nabeel wrote:
>>>
>>>  I'm running OpenSIPS with TLS support compiled and enabled.   The
>>> first SRV record OpenSIPS searches for when connecting is  _sip._udp. (as
>>> shown below).
>>>
>>>  It should be _sips._tcp.  How can this be fixed?
>>>
>>>
>>>  DBG:core:get_record: lookup(_sip._udp.domain.com, 33) failed
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150709/0d0ffa93/attachment-0001.htm>