You can check it in the pcap - if an UDP packet is fragmented into multiple IP packets, you have some fragmentation flag set into the IP header (see https://www.cs.nyu.edu/courses/fall98/G22.2262-001/class11.txt, look for "fragmentation" ).

Also, at SIP level, you may check if the advertised Content-Length matches the actual length of the body - if the body is shorter than advertised in Content-Len, it means the UDP packet is fragmented .

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2016 20:11, Nabeel wrote:

Can packet fragmentation be verified (to be sure that it is packet fragmentation)?

On 6 May 2016 5:28 pm, "Nabeel" <nabeelshik...@gmail.com <mailto:nabeelshik...@gmail.com>> wrote:

    The trace I posted earlier is what I see with tcpdump when
    attempting a call. There is no other INVITE shown in the trace:
    http://pastebin.com/raw/C4iymTbh

    The trace seems to end abruptly in the middle of the SDP, so I
    think it could be due to packet fragmentation.

    On 6 May 2016 4:18 pm, "Bogdan-Andrei Iancu" <bog...@opensips.org
    <mailto:bog...@opensips.org>> wrote:

        So that meas the INVITE never gets to the callee ?? maybe it
        is not properly routed .

        Do you see (with ngrep or tcpdump) the INVITE being sent out
        by opensips towards callee ?

        Regards,

        Bogdan-Andrei Iancu
        OpenSIPS Founder and Developer
        http://www.opensips-solutions.com

        On 06.05.2016 12:56, Nabeel wrote:

        Hi,

        Thanks for the idea about packet compression. By 'call fails
        to connect', I meant the call does not connect to the callee,
        ie. the callee's phone does not ring after the INVITE
        (despite using TURN server).

        This was a public WiFi network and that was all I could get
        at the time. I am using OpenSIPS version 2.1.

        Nabeel

        On 6 May 2016 9:16 am, "Bogdan-Andrei Iancu"
        <bog...@opensips.org <mailto:bog...@opensips.org>> wrote:

            Hi,

            Hard to analyze a call based on the INVITE packet only
            :). Still the SIP signaling does not show any ALG
            interference (also not sure if the capture was done
            before or after the ALG). Also, what you mean by "call
            fails" ?no reply, negative reply , no audio ?

            Regards,

            Bogdan-Andrei Iancu
            OpenSIPS Founder and Developer
            http://www.opensips-solutions.com

            On 05.05.2016 22:35, Nabeel 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
            Users@lists.opensips.org <mailto:Users@lists.opensips.org>
            http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to