Invalid Content-Lenght header value on iOS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

Thanks for your response. I?m glad to hear that someone else recognises
this issue as well!

To answer your question: This setup allows users to call over Mobile
Networks (3G/4G) as well as over WiFi. I can?t tell from the traces which
one is used for these particular calls. I should however be able to find
out if these users are from a specific country and maybe even a specific
ISP/Telecom operator. Will this help you? What did you find out in this
respect?

Yes, I?m aware of ALG?s that interfere with the SIP signalling. We?ve had
our share of problems with that already...
It crossed my mind that it?s an ALG that causes these issues. However one
would then expect that the problem is introduced on the first INVITE
(without AUTH) as well, but these look good.

I?m very curious what your findings were. Please share your patch. Any
chance that this will be merged into the official sources?
Best regards,

Tom



>Date: Sun, 29 Dec 2013 12:56:57 -0800
>From: David Sanders <dsanders@xxxxxxxxxx>
>To: <pjsip at lists.pjsip.org>
>Subject: Re: Invalid Content-Lenght header value on iOS
>Message-ID: <52C08C99.70308 at pinger.com>
>Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
>Hey Tom,
>
>What kind of network environment are you using the client with? WiFi,
>3G, 4G? Local network or over the internet?
>
>We've seen the same issue and dug into the code which produces the value
>for the header, and everything seems to be OK with the code.
>
>PJSIP normally creates Content-Length header values with several blank
>spaces before the number. This is because it writes (6?) spaces for the
>value, then fills it back in later once it knows how long the message
>body is.
>
>The best theory I've come up with for the strange mangled Content-Length
>values is that some router in the network is running ALG and is mangling
>the SIP (Google around for SIP and ALG). I think the extra spaces at the
>start of the value (while legal SIP) confuse these routers and cause
>them to botch the header value.
>
>I've even seen the issue on a REGISTER, where the value comes out as "0
>0".
>
>We're currently testing a patch for PJSIP which removes the leading
>spaces to see if that fixes the issue. I'll let you know if that works
>and can forward the patch along to you if you'd like.
>
>- David
>
>
>On 12/29/13 6:53 AM, Tom van der Geer wrote:
>> Hi,
>>
>> I subscribed to this mailinglist to report something I?ve seen happening
>> in my traces of several calls made with an iOS version of a PJSIP based
>> client.
>>
>> Some of the calls in our traces (all happen to be from PJSIP based
>>client
>> on iOS) have a malformed value in the Content-Length header. See
>>example:
>>
>> HEX:     43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 36 20 20 33 33
>>39
>> 0d 0a
>> Decoded: C  o  n  t  e  n  t  -  L  e  n  g  t  h  :     6        3  3
>>9
>> \r \n
>>
>>
>> As you see it will print a 6 as first character of the length value.
>>Most
>> SIP header parsers will fail on this header. Even wireshark will not be
>> able to decode this properly and malforms the presentation of the SDP.
>>
>> Things I?ve noticed/observed:
>> In the occasions I?ve found in my traces, te value differs from 1 to 10,
>> but the most common value is 6.
>> I?ve noticed this error in the INVITE messages (contains an SDP, so
>> Content-Length > 0). It?s almost always in an INVITE (+AUTH +SDP) which
>> responds to a 401 Unauthorised. I did see it happen on the first INVITE
>> too.
>> I?ve found this error on different instances of the PJSIP client for
>>iOS.
>> It?s not just one instance/device that?s off.
>>
>> My guess is that it?s caused by using an incorrectly initialised memory
>> space for storing the value but my C-knowledge is not sufficient to
>> properly assess the code. It could be an ARM/iOS SDK specific issue too.
>>
>> Does anybody have an idea what might be going on?
>> Best regards,
>>
>> Tom
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org





[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux