[Spce-user] SIP UDP packet fragmentation breaking calls

Daniel Grotti dgrotti at sipwise.com
Tue Sep 22 10:08:17 EDT 2015


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
> 
> 



More information about the Spce-user mailing list