[pjsip] Invalid Content-Lenght header value on iOS
Tom van der Geer
tom at vdgeer.com
Sun Dec 29 16:49:24 EST 2013
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
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?
>Date: Sun, 29 Dec 2013 12:56:57 -0800
>From: David Sanders <dsanders at pinger.com>
>To: <pjsip at lists.pjsip.org>
>Subject: Re: [pjsip] Invalid Content-Lenght header value on iOS
>Message-ID: <52C08C99.70308 at pinger.com>
>Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>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
>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
>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.
>On 12/29/13 6:53 AM, Tom van der Geer wrote:
>> 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
>> Some of the calls in our traces (all happen to be from PJSIP based
>> on iOS) have a malformed value in the Content-Length header. See
>> HEX: 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 36 20 20 33 33
>> 0d 0a
>> Decoded: C o n t e n t - L e n g t h : 6 3 3
>> \r \n
>> As you see it will print a 6 as first character of the length value.
>> 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
>> I?ve found this error on different instances of the PJSIP client for
>> 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,
>> Visit our blog: http://blog.pjsip.org
>> pjsip mailing list
>> pjsip at lists.pjsip.org
More information about the pjsip