Summary: | ASTERISK-09258: [patch] Incoming SIP Contact header truncated at 250 chars | ||
Reporter: | Jeff Gehlbach (jeffg) | Labels: | |
Date Opened: | 2007-04-13 08:29:42 | Date Closed: | 2007-07-09 21:20:48 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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! |