[OpenSIPS-Users] 408 Request Timeout with UDP

Fri Aug 7 18:39:25 CEST 2015

SamyGo,

I was referring to this test you suggested:

"Can you do a small test ? Re register your callee phone and within same
second make a call to callee."

Line 294 was already there when I generated the config file using
'menu_config'; I did not add that myself.

I think Bogdan's suggestion is working, but in my initial tests I got more
consistent results when I included the additional parameters in my last
Email.

Bogdan,

Regarding UDP, I realised that the UDP port could not be in LISTEN state
and this was probably preventing my server from fully opening that port.
Running nmap on that port showed result "open|filtered", unlike with TCP
which showed fully open.  I am not running any firewalls on my server, so
this seems to be the default behaviour of my network.

I would like to clarify one thing.  You mentioned adding
setbflag(SIP_PING_FLAG) before doing save(), but in my config file I don't
see save() anywhere, there is only this line: "if (!save("location"))".
Where exactly do I add this line?

On 7 August 2015 at 16:13, SamyGo <govoiper at gmail.com> wrote:

> 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/9aa7da68/attachment-0001.htm>