[OpenSIPS-Users] 408 Request Timeout with UDP

Fri Aug 7 17:13:02 CEST 2015

Hi Nabeel,

Which test are you referring to ?
Have you tried adding the following by Bogdan in your .cfg file ?

An issue may be the fact the default script does non-SIP pinging (which is
unidirectional), so the NAT may close. Add the followings:
1) modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG")
   modparam("nathelper", "sipping_from", "sip:pinger at xx.xx.xx.xx"
<sip:pinger at xx.xx.xx.xx>)

2) setbflag(SIP_PING_FLAG); before doing save()

The above worked or you haven't tried them ?

Why do you've this at line 294 in your script:  if (   0 )
setflag(TCP_PERSISTENT);?? Just above or after this you can write this:
setbflag(SIP_PING_FLAG); as mentioned by Bogdan.

BR,
Sammy

On Fri, Aug 7, 2015 at 6:21 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Nabeel,
>
> Using TCP gives an advantage over UDP as being connection oriented, it
> force the NAT pinhole to stay open. Nevertheless, using the SIP pinging
> with UDP should also have fixed the problem.
>
> I will update the default cfg to use SIP pinging rather than simple UDP
> pinging.
>
> Thanks and Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 07.08.2015 12:32, Nabeel wrote:
>
> SamyGo,
>
> I tried the test you suggested but it did not work.
>
> Bogdan,
>
> After switching to TCP and adding your suggestions along with the
> following parameters, the timeout errors seem to be resolved:
>
> *tcp_async=1*
> *tcp_connect_timeout=99999*
> *tcp_send_timeout=99999*
>
> * modparam("nathelper", "nortpproxy_str", "a=nortpproxy:yes\r\n") *
> I'm not sure in exactly what combination works best, but perhaps these
> should be included in the default residential script?
>
> Thanks for the help... I'll be back with more questions.
>
>
> On 6 August 2015 at 15:41, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi Nabeel,
>>
>> This time the SIP trace looks ok - the message is sent to a public IP and
>> not a private one (as shown in the prev capture). Also the usrloc data
>> looks ok, telling that the NAT traversal works ok.
>> As you have Mobile Data, some operators do filter SIP, so not sure what
>> say.
>>
>> Do you see the sip messages going back and forward during the registration
>> process ?
>>
>> An issue may be the fact the default script does non-SIP pinging (which
>> is unidirectional), so the NAT may close. Add the followings:
>> 1) modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG")
>>    modparam("nathelper", "sipping_from", "sip:pinger at xx.xx.xx.xx"
>> <sip:pinger at xx.xx.xx.xx>)
>>
>> 2) setbflag(SIP_PING_FLAG); before doing save()
>>
>> You should see OpenSIPS doing keep alive with OPTIONS requests.
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 06.08.2015 14:59, Nabeel wrote:
>>
>> My OpenSIPS runs on a public IP.  The callee was connected to Wi-Fi in my
>> first test earlier, but in the second test the callee was connected to a
>> public IP  (public mobile network).  In both cases, the same '404 timeout'
>> error occurred on call attempt.  The SIP trace for the second case is at
>> this link:
>>
>> http://pastebin.com/jGxRQ34q
>>
>> Regarding private IP, you said it's impossible to route from public IP to
>> private IP.  Although at the IP level this may be true, even if the user is
>> on Wi-Fi, the whole point of NAT traversal is that the user's public IP is
>> discovered and the call can get connected, is that not right?  I'm fact,
>> using a TURN server and a different SIP proxy, I was able to connect these
>> same devices under the same networks, so I know this should be possible.  I
>> feel something is not configured correctly in OpenSIPS / rtpproxy.
>>
>> I did "opensipsctl ul show" and the results seem normal; please check it:
>>
>> http://pastebin.com/n1BbTuMK
>>
>> Perhaps the NAT processing just needs a bit more time; in thar case what
>> are the config options to increase the request timeout for UDP?  I have
>> seen the 'tcp_send_timeout' and 'tcp_connect_timeout' options for TCP, but
>> please let me know if there are similar options for UDP.
>> On 6 Aug 2015 12:08, "Bogdan-Andrei Iancu" <bogdan at opensips.org> wrote:
>>
>>> Nabeel,
>>>
>>> I suppose you OpenSIPS seats on a public IP, right ? The callee looks to
>>> have a private IP. And, at IP level, it is impossible to route from a
>>> public IP to a private one.
>>>
>>> I see your script has NAT traversal support. My question is - did the
>>> callee properly registered via this script ? can you do an "opensipsctl ul
>>> show" to see the callee's registration ?
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 06.08.2015 07:14, Nabeel wrote:
>>>
>>> Hi,
>>>
>>> Yes, the destination IP is  192.168.0.19:60912 and both phones are
>>> registered to OpenSIPS.  In this case, the callee is connected to Wi-Fi
>>> (hence 192.xx IP address) and the caller is connected to a mobile network.
>>>
>>> The opensips.cfg I am using was generated from 'make menuconfig', except
>>> with the addition of "alias=domain.com". I have attached my config file
>>> at this link:
>>>
>>> http://pastebin.com/0QRyC938
>>>
>>>
>>>
>>> On 6 August 2015 at 05:00, SamyGo <govoiper at gmail.com> wrote:
>>>
>>>> Hi Nabeel,
>>>> Quick question; what is this destination ip? 192.168.0.19:60912 ? - Destination
>>>> User Agent Registered on OpenSIPS?
>>>> Can you share the opensips.cfg code snippet for this call ?
>>>>
>>>> On Wed, Aug 5, 2015 at 11:55 PM, Nabeel <nabeelshikder at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am using the residential script generated by 'make menuconfig', with
>>>>> UDP and NAT support enabled.  I added "alias=domain.com" to the
>>>>> config because otherwise the UA did not register with my domain (
>>>>> username at domain.com). When I attempt to make a call, I see '408
>>>>> Request Timeout' in the sip trace and the call does not connect.  Please
>>>>> check the log/trace below and advise how to fix this.
>>>>>
>>>>> SIP trace:
>>>>>
>>>>> http://pastebin.com/u5h9qGNr
>>>>>
>>>>> OpenSIPS log:
>>>>>
>>>>> http://pastebin.com/B8PUCKh0
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150807/f248c317/attachment-0001.htm>