[Home]

Summary:ASTERISK-09258: [patch] Incoming SIP Contact header truncated at 250 chars
Reporter:Jeff Gehlbach (jeffg)Labels:
Date Opened:2007-04-13 08:29:42Date Closed:2007-07-09 21:20:48
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip-contact-header-truncation_trunk-61638.patch
Description:Incoming SIP calls from my employer's Nortel MCS5200 trigger the following message in the console with verbose=3:

WARNING[PID]: chan_sip.c:2417 get_in_brackets: No closing bracket found in '<sip:jgehlbach@[SNIP]'

Comparing the full headers of the INVITE shows that the string above is just a truncation to 250 characters of the Contact header's value.  For example:

<--- SIP read from 64.xxx.xxx.x:5060 --->
INVITE sip:jeffg!ganesha.jeffg.org:5060;maddr=72.xxx.xx.x SIP/2.0
From: "Jeff Gehlbach"<sip:jgehlbach!myemployer.net>;tag=1764584509
To: "jeffg"<sip:jeffg!ganesha.jeffg.org>
Call-ID: 16dc8bae11311f1813de1be764fa729e2c951478@64.xxx.xxx.x
CSeq: 39680 INVITE
Via: SIP/2.0/UDP 64.xxx.xxx.x:5060;branch=z9hG4bK-1abd97-687496e4-8688d31
content-type: application/sdp
contact: <sip:jgehlbach@64.xxx.xxx.x:5060;nt_end_pt=YM0+~Kj!etq-.8g~QmepM9_HcimvnQc~PMQiEt~EJaddr~W6e.5Liq1qN.12~Xn7y*oN1M~PC-.19qa1W7CO8~Kmq25f~Rn7XKG~NKTaiN4mX0~Xn2rdk71cpice~Hgor74uw6Cre1Njf0qtS305Qdk0~EbtYMig~W031Pfctc_m1pa.N.QVI8~G4.atla56m-GmM-ivcJj;nt_server_host=64.xxx.xxx.x>
user-agent:  Nortel IPCM9.1.7.02007-03-01-2100
max-forwards: 19
supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,com.nortelnetworks.im.encryption
x-nt-party-id: /jgehlbach
subject: null
call-info: <http://atl-56m-mcs-ipcm.myemployer.net:80/pa/direct/pictureServlet?user=jgehlbach@myemployer.net>;Purpose=icon
allow: REFER
x-nt-corr-id: e5dc8bae11c4f1d3de1be744da98d34712850a@64.xxx.xxx.x
x-nt-location: 1656
accept-language: en-us
Content-Length: 262

...

[Apr 13 07:32:22] WARNING[14174]: chan_sip.c:2417 get_in_brackets: No closing bracket found in '<sip:jgehlbach@64.xxx.xxx.x:5060;nt_end_pt=YM0+~Kj!etq-.8g~QmepM9_HcimvnQc~PMQiEt~EJaddr~W6e.5Liq1qN.12~Xn7y*oN1M~PC-.19qa1W7CO8~Kmq25f~Rn7XKG~NKTaiN4mX0~Xn2rdk71cpice~Hgor74uw6Cre1Njf0qtS305Qdk0~EbtYMig~W031Pfctc_m1pa.N.QVI8~G4.atla56m-GmM-ivcJj;nt'

(Note that my sanitizing above includes SPIT-armor by UUCP-ifying SIP URIs, i.e. s/@/!/g)

This looks like a straightforward case of a heap-allocated string truncating an unexpectedly long value.  At trunk revision 61638, chan_sip.c:

static int parse_ok_contact(struct sip_pvt *pvt, struct sip_request *req)
{
       char contact[250];
       char *c;

       /* Look for brackets */
       ast_copy_string(contact, get_header(req, "Contact"), sizeof(contact));
       c = get_in_brackets(contact);


Now I'm  no SIP wizard, but I've checked RFC3261 and found no mention of a length limit on any header's value.  There are also heap-allocated [256] strings in a couple of other places through which the Contact header passes.  The attached patch changes the allocation from 256 to 384 in the following functions in chan_sip.c:

respprep
extract_uri
parse_moved_contact

In parse_ok_contact, I maintained the 6-byte difference in length just because I do not fully understand why it was there.

These changes resolve the issue for me.  Impact should be limited to an additional 128 bytes of heap per SIP call.
Comments:By: Joshua C. Colp (jcolp) 2007-04-13 12:21:51

Fixed in 1.4 as of revision 61648 and trunk as of revision 61649. Thanks!