[asterisk-bugs] [Asterisk 0014220]: SIP INVITE packets are incorrectly truncated with 1.6.1 svn after approx 1020 characters

Tue Jan 20 14:15:35 CST 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14220 
====================================================================== 
Reported By:                riksta
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   14220
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 167727 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-01-12 12:02 CST
Last Modified:              2009-01-20 14:15 CST
====================================================================== 
Summary:                    SIP INVITE packets are incorrectly truncated with
1.6.1 svn after approx 1020 characters
Description: 
Since updating from 1.6.1b4 to SVN-branch-1.6.1-r167727 i can no longer
make calls to my SIP trunk provider if my call has a long CALLERID(name)
string.

The sip trunk provider's techie says that my SIP INVITE packets are being
truncated... eg if i set the callerid name as a short string and the INVITE
packet was 1017 characters, the call goes through perfectly.

If i set the callerid name as a longer string and the INVITE packet was
1020 chars the call fails to be sent.

In #asterisk-dev Corydon76 explains that it is probably to do with the
fact that SIP INVITES are no longer are built in a static buffer (That was
part of the ast_str work) 

I will attach a sip debug log file of a successful and unsuccessful call
====================================================================== 

---------------------------------------------------------------------- 
 (0098233) svnbot (reporter) - 2009-01-20 14:15
 http://bugs.digium.com/view.php?id=14220#c98233 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 169559

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r169559 | mmichelson | 2009-01-20 14:15:34 -0600 (Tue, 20 Jan 2009) | 27
lines

Merged revisions 169557 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

........
r169557 | mmichelson | 2009-01-20 14:10:31 -0600 (Tue, 20 Jan 2009) | 19
lines

Convert the character pointers in a sip_request to be pointer offsets

When an ast_str expands to hold more data, any pointers that were pointing
to the data prior to the expansion will be pointing at invalid memory.
This
change makes such pointers used in chan_sip.c instead be offsets from the
beginning of the string so that the same math may be applied no matter
where
in memory the string resides.

To help ease this transition, a macro called REQ_OFFSET_TO_STR has been
added
to chan_sip.c so that given a sip_request and an offset, the string at
that
offset is returned.

(closes issue http://bugs.digium.com/view.php?id=14220)
Reported by: riksta
Tested by: putnopvut

Review http://reviewboard.digium.com/r/126/

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=169559 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-20 14:15 svnbot         Checkin                                      
2009-01-20 14:15 svnbot         Note Added: 0098233                          
======================================================================