[Spce-user] Udp to Tcp sig generates big mtu making the messages to fail

[Cosmin Nistor]

Hi, thanks for your suggestions > indeed there is somewhere a device that
limits the mtu.
After a litlle more troubleshooting - thanks Lorenzo i concluded it seems
to be an issue with packet reassembly on the uac side > all the tests i
used Android 4.2.2( different phones, different softphones but always
Android 4.2.2); when using a softphone on my laptop the messages got to the
laptop interface the same way, fragmented, but the call ended ok. So..my
conclusion is the problem was on the phone's OS; i'll do some more tests on
different Android devices.

Regards,

Cosmin



On Mon, Apr 28, 2014 at 11:41 AM, Daniel Grotti <dgrotti at sipwise.com> wrote:

> Hi,
> looks like you have a device in the middle with a small limit of mtu
> that cause that fragmentation.
>
> Daniel
>
>
>
>
> On 04/28/2014 10:25 AM, Daniel Grotti wrote:
> > Hi,
> > A pcap trace would help, anyway, it looks like an Asterisk behavior:
> >
> > http://www.spinics.net/lists/asterisk/msg123908.html
> >
> > Do you have a pcap to analyze the re-invite's MTU ?
> > And don't see such a lot of headers, just a couples od Record-Route and
> > Via, SDP also doesn't contain any additional lines.
> >
> >
> > Daniel
> >
> >
> >
> >
> > On 04/27/2014 10:19 AM, Cosmin Nistor wrote:
> >> Hello list,
> >>
> >> New to the list - maybe i could get an opinion on an issue i am facing
> >> using a setup with Sipwise CE.
> >> Using 2.8, 3.0 versions, tested on the 3.2.1 on a test machine, the
> same.
> >>
> >> Setup and problem description( see attached file):
> >>
> >> - running Sipwise in the front doing sig( tcp) to uac and sig udp to
> >> asterisk + rtp and an Asterisk in the back doing sig udp.
> >> - uac1 calls uac 2, the calls gets answered, uac2 sends bye;
> >> - when bye is received by asterisk it sends an invite back( strange
> >> behaviour to me, but since asterisk is a b2bua may be legit to try to
> >> get the media back if there are any further steps to pass in the
> >> dialplan before sending the final bye);
> >> - Sipwise receives the invite from asterisk (udp) and passed the invite
> >> to uac( tcp) < here the trouble occours, the invite is a large packet
> >> that gets fragmented; the result is that down the line the uac does not
> >> ack the re-invite, so the call gets stuck.
> >> - using the same scenario but for the call leg Sipwise-uac using udp or
> >> tls i see the same call flow but the mtu of frames is less than 1500 =>
> >> packets are not fragmented => calls end ok.
> >>
> >> I attach a ngrep trace to show the issue, a pcap contains sensitive
> >> information( ip, usernames).
> >>
> >> The approach could be to stripe down the size of the packets, been
> >> trying to toggle parameters in sems white/blacklist but could not find a
> >> working solution > if i could find some suggestions would be
> appreciated.
> >>
> >> Thanks and regards,
> >>
> >> Cosmin
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Spce-user mailing list
> >> Spce-user at lists.sipwise.com
> >> http://lists.sipwise.com/listinfo/spce-user
> >>
> >
> > _______________________________________________
> > Spce-user mailing list
> > Spce-user at lists.sipwise.com
> > http://lists.sipwise.com/listinfo/spce-user
> >
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20140502/0665b6d1/attachment.html>