[OpenSIPS-Users] dns srv lookups happening during relay
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Aug 17 15:25:00 CEST 2015
Try:
append_branch("sip:dst_ip:port;transport=tcp");
Also take a look at $branch variable & co:
http://www.opensips.org/Documentation/Script-CoreVar-1-11#toc21
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.08.2015 14:36, Tito Cumpen wrote:
>
> Bogdan,
>
> I will acquire the capture later today and post. Can you tell me how I
> can append the port and protocol when creating the branch ? Or at
> least what the string needs to look like ?
>
> Thanks,
> Tito
>
> On Aug 17, 2015 5:38 AM, "Bogdan-Andrei Iancu" <bogdan at opensips.org
> <mailto:bogdan at opensips.org>> wrote:
>
> Hi Tito,
>
> Yes, your SIP URI does not have any protocol or port indication,
> so NAPTR lookup is perform.
>
> Now, of the call flow you describe : DNS based discovery is to be
> done for initial request only - the sequential requests (in
> dialog) should simply follow the path discovered by the initial
> request. So, better post somewhere the pcap or so.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 15.08.2015 00:41, Tito Cumpen wrote:
>> I enabled debug level 6 and I am noticing this
>> : DBG:core:mk_proxy: doing DNS lookup...
>> Aug 14 20:42:09 cloud-server-06 /sbin/opensips[22814]:
>> DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
>>
>> Here it claims that this request is lacking a port and and a
>> proto on this branch I am appending the branch like so
>>
>> avp_pushto("$du","sip:sisterproxyIP");
>>
>> append_branch();
>>
>>
>> the sister proxy is where the user resides. This is actually
>> confusing the remote opensips proxy(same version) because now it
>> sends all in dialog request via a tcp socket all thought the 200
>> was sent via udp leg. 2 requests came into the sister proxy. I'm
>> not sure why the one gets a 404 and the proceeds the only
>> difference is the udp request has two rr headers. It appears that
>> the remote proxy might not have cancelled the dialog even thought
>> it sent a negative reply. I have a trace of this if needs to be
>> supplied.
>>
>>
>> Thanks,
>>
>> Tito
>>
>>
>>
>> On Fri, Aug 14, 2015 at 3:52 PM, Tito Cumpen <tito at xsvoce.com
>> <mailto:tito at xsvoce.com>> wrote:
>>
>> Group,
>>
>>
>> I am using :
>>
>> version: opensips 2.2-dev (x86_64/linux)
>>
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP,
>> PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144,
>> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
>>
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>
>> git revision: b7db080
>>
>> main.c compiled on 22:43:41 Jun 25 2015 with gcc 4.8.3
>>
>>
>>
>> I have a strange issue in which dns SRV lookups and routing
>> is happening although I have set the RURI domain as an alias
>> in my config. On some calls this will eventually screw up
>> the dialog termination once a bye is sent because it makes an
>> attempt to transmit the bye to this SRV entry.
>>
>> I see this error in the logs.
>>
>> Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
>> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 47
>> Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
>> ERROR:core:tcpconn_async_connect: poll error: flags 1c
>> Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
>> ERROR:core:tcpconn_async_connect: failed to retrieve SO_ERROR
>> [server=192.XX.XX.XX:38798] (111) Connection refused
>> Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
>> ERROR:core:proto_tcp_send: async TCP connect failed
>> Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
>> ERROR:tm:msg_send: send() for proto 2 failed
>>
>> Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
>> ERROR:tm:t_forward_nonack: sending request failed
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150817/b6cd4221/attachment-0001.htm>
More information about the Users
mailing list