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 Developer
http://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 <[email protected]
<mailto:[email protected]>> 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:[email protected]"
<mailto:sip:[email protected]>)
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 Developer
http://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" <[email protected]
<mailto:[email protected]>> 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 Developer
http://www.opensips-solutions.com
On 06.08.2015 07:14, Nabeel wrote:
Hi,
Yes, the destination IP is 192.168.0.19:60912
<http://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
<http://domain.com>". I have attached my config file at this
link:
http://pastebin.com/0QRyC938
On 6 August 2015 at 05:00, SamyGo <[email protected]
<mailto:[email protected]>> wrote:
Hi Nabeel,
Quick question; what is this destination ip?
192.168.0.19:60912 <http://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
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
I am using the residential script generated by 'make
menuconfig', with UDP and NAT support enabled. I
added "alias=domain.com <http://domain.com>" to the
config because otherwise the UA did not register
with my domain ([email protected]
<mailto:[email protected]>). 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
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
