Sorry that is what I was trying to let you know. Is that I had thought
the same thing that the Fragment was not even sent, but it was just
because of the tcpdump filter I had not that it actually wasn't being
sent. If you have not try capturing all IP traffic to a host IP and see
if you see it.
20.05.2020 11:11 に Olle Frimanson さんは書きました:
Hi the issue on my side is that it’s not the network that is the
problem the second fragment is not even sent. I also kind on lean to
TCP at the moment but it would be good to get a comment from Opensips
team on this if and how they setup the sockets and if there is a
difference on different routes
Br Olle
Skickat från min iPhone
20 maj 2020 kl. 17:14 skrev junkmail <[email protected]>:
Hello, I had run into the same issue. One thing I was a bit mistaken
because I was using tcpdump and doing a capture filter of port 5060 or
the such. So I was missing the Fragment in my sniff as it does not
include the UDP header. Just something to be aware of. But I was
having problems specifically traffic inside of GCP < google cloud. As
well as traffic traversing the VPN to GCP. I am not certain about
what changed for internal to GCP but that started working and now the
only thing using TCP is over VPNs. Sorry not a lot of information
here. but my best guess is either the firewall/router on my side or
Googles is dropping the UDP fragment. I didn't dig into it much
further as TCP fixed the issue and this was just a transit between
opensisps systems.
19.05.2020 01:21 に [email protected] さんは書きました:
Hi, this happens one single opensips instance server it receives the
inbound packet fine, then when its send out on the same interface
it’s fragmented, so I don’t think it’s network or router switch
related. Have seen such problems in the past in virtual environments
but this is not the case now.
My prime suspect is Centos since it send out the first part of the
fragmented packet but not the following part that would complete the
packet.
But indeed it is a strange bug, since it does not always happen.
BR/Olle
FRÅN: Users <[email protected]> FÖR Giovanni
Maruzzelli
SKICKAT: den 19 maj 2020 09:13
TILL: OpenSIPS users mailling list <[email protected]>
ÄMNE: Re: [OpenSIPS-Users] UDP fragmentation in reply routes
Can be a problem of the virtual env, and/or the router/switch...
Try substitute real hardware to virtual, and different models of
router/switch
In a LAN, UDP fragmentation is not supposed to be a problem at all...
answered from mobile, please pardon terseness and typos,
-giovanni
On Tue, May 19, 2020, 08:05 <[email protected]> wrote:
Thanks for the reply Max,
we are doing all we can to make the packets smaller, but before we
move over to TCP, which is most likely our next step, I wanted to
explore what could be happening.
AFAIK the application have some control of this since these are
parameters that partly can be set when you open a socket, that’s
why I wonders if Opensips might use those parameters or not,
especially since we have so very different behaviour in different
directions.
BR/Olle
FRÅN: Users <[email protected]> FÖR Maxim Sobolev
SKICKAT: den 18 maj 2020 22:03
TILL: OpenSIPS users mailling list <[email protected]>
ÄMNE: Re: [OpenSIPS-Users] UDP fragmentation in reply routes
Smells like a OS/kernel bug to me. There is little application can
do in that regard, UDP fragmentation/reassembly happens at much
lower layers of the OSI stack.
However, as a workaround as long as SIP goes you can try to reduce
your SIP signalling packet size by using compact version of SIP
headers, as well as dropping headers that are not used. That would
save you 100-150 bytes per SIP message perhaps. I don't know if
OpenSIP can do that in the proxy mode out of the box though, so you
might want to add b2b into the flow.
-Max
On Mon., May 18, 2020, 12:34 p.m. Olle Frimanson, <[email protected]>
wrote:
Hi,
We have an issue on our home proxy (opensips 2.4.6), when it
receives 200 OK (over UDP) from our Freeswitch and the package
size is higher than the MTU size , we sometimes get fragmentation
of the UDP packets, but only the first part of the fragmented
package is sent to our edge proxy. Is this a known issue or is it
a OS bug?
We have not yet spotted any pattern on this and in most cases
bigger packets with MTU around 1600 bytes gets through without an
issue.
I can add that in the other direction in the normal request routes
we don’t have any issue at all can have packets > 2000 bytes
without any issues.
Does Opensips use IP_MTU_DISCOVER or how is fragmentation
controlled and is it expected to have different behavior in reply
routes vs other routes?
We use Centos 7 in a virtual server environment.
I was hoping someone can share some light on this strange issue.
BR/Olle
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
