Hi,
Haven't follow if it is or not a fragmentation issue, but if it is,
instead of switching to TCP, you can use the compression module to
reduce the size of the SIP packet. See the mc_compact() function:
http://www.opensips.org/html/docs/modules/2.1.x/compression.html#id293508
If running an older version (than 2.1), you may simply consider removing
(via remove_hf()) some optional headers (like User-Agent, Date, Time, etc)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05.05.2016 23:28, Patrick Wakano wrote:
It seems you are facing packet fragmentation, and the second part of
the fragment isn't reaching opensips...
maybe your wifi router (if it is the only element between your
endpoint and opensips) is not correct handling this situation....
I would sugest a change to TCP as your next step for debugging this
problem!
On Thu, May 5, 2016 at 5:23 PM, Nabeel <[email protected]
<mailto:[email protected]>> wrote:
Yes, it is definitely listening on the non-standard port:
# netstat -lnp | grep opensips
udp 0 0 162.xxx.x.110:12341 0.0.0.0:* 1750/opensips
In fact, it even seems to register correctly, but the INVITE does
not get through.
I have OpenSIPS set on debug level 4 but did not see anything in
the log.
On 5 May 2016 at 21:14, Tito Cumpen <[email protected]
<mailto:[email protected]>> wrote:
Nabeel,
Did you verify that your opensips server is listening on this
non Standard port ?
run
netstat -lnp | grep opensips
On Thu, May 5, 2016 at 4:12 PM, Nabeel
<[email protected] <mailto:[email protected]>> wrote:
Tito Campen, I took the trace on my OpenSIPS server, which
is the receiving proxy. However, OpenSIPS did not add
anything to the server's log itself.
On 5 May 2016 at 21:08, Tito Cumpen <[email protected]
<mailto:[email protected]>> wrote:
Nabel, You should should take a trace at the receiving
proxy to verify the traffic is even getting there. If
there is no sdp received from the UAS you would not
see rtp traversing at all. Using non Standard points
doesn't assure you that messaging traffic will traverse.
On Thu, May 5, 2016 at 3:54 PM, Tito Cumpen
<[email protected] <mailto:[email protected]>> wrote:
Adding to Bogdan's point I am successfully using
sip tls on port 443 without any issues as of yet.
It's bypassing some isp enforced algs as well as
those enforced by local routers. :-).
On Thu, May 5, 2016 at 3:35 PM, Nabeel
<[email protected]
<mailto:[email protected]>> wrote:
Please check the following SIP trace taken
within a WiFi network. The call fails to
connect despite the INVITE request and using a
non-standard port. Could this be caused by SIP
ALG, or some unopened RTP port on the router?
http://pastebin.com/raw/C4iymTbh
_______________________________________________
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] <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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
