[Spce-user] SIP UDP packet fragmentation breaking calls

[Marco Teixeira]

Nice !
Thankx




On Tue, Sep 22, 2015 at 3:08 PM, Daniel Grotti <dgrotti at sipwise.com> wrote:

> Hi,
> we already have it on our roadmap (internal ticket MT#0009327)
> I already noticed that not-fully-compliant point to rfc.
> We will provide a solution for that in the future, cannot say why though.
>
>
> --
> Daniel Grotti
> VoIP Engineer
>
>
> Sipwise GmbH
> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
>
> On 09/22/2015 04:04 PM, Marco Teixeira wrote:
> > Hi Daniel,
> >
> > Thank you for your reply.
> > Please consider getting it onto your roadmap to keep your amazing
> > product RFC compliant.
> >
> > For clarity here is the link i forgot to past (i guess)
> > https://support.software.dell.com/kb/sw10958
> >
> > ---
> > Best regards
> > Marco
> >
> >
> > On Tue, Sep 22, 2015 at 2:57 PM, Daniel Grotti <dgrotti at sipwise.com
> > <mailto:dgrotti at sipwise.com>> wrote:
> >
> >     Hi Marco,
> >     SPCE does not fallback in TCP unfortunately.
> >     you should reduce the MTU by removing headers or you should be able
> to
> >     rebuild your fragmented packets at the final destination.
> >
> >     --
> >     Daniel Grotti
> >     VoIP Engineer
> >
> >
> >     Sipwise GmbH
> >     Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
> >     <http://www.sipwise.com>
> >
> >     On 09/21/2015 11:27 PM, Marco Teixeira wrote:
> >     > Hi there,
> >     >
> >     > I might have stumbled upon the issue described here (but without
> >     any ALG
> >     > in the middle, just for example, as i can't pass any sensitive
> >     info here)
> >     >
> >     > I'm seeing fragmented SIP packets when the final gateway sends
> OPTION
> >     > back over 2 NGCP CE and over to a final farm of SIP servers...
> >     >
> >     > The call is established correctly and only when the OPTIONs don't
> get
> >     > ACK, the call drops within 10 seconds (always).
> >     >
> >     > So, according to the test on that link, trancript below:
> >     > (..) If a request is within 200 bytes of the path MTU, or if it is
> >     larger
> >     >    than 1300 bytes and the path MTU is unknown, the request MUST
> >     be sent
> >     >    using an RFC 2914 [43] congestion controlled transport
> >     protocol, such
> >     >    as TCP. (...)
> >     >
> >     > Shouldn't SIPWISE activate TCP or whatever to avoid this ?
> >     > How did you guys solve this ?
> >     > (no, TCP on all calls is really asking for trouble on the call
> volume
> >     > i'm aimming for)
> >     >
> >     >
> >     > Best regards
> >     > Marco
> >     >
> >     >
> >     > _______________________________________________
> >     > Spce-user mailing list
> >     > Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
> >     > https://lists.sipwise.com/listinfo/spce-user
> >     >
> >     _______________________________________________
> >     Spce-user mailing list
> >     Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
> >     https://lists.sipwise.com/listinfo/spce-user
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20150922/76520b55/attachment-0001.html>