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

Thu Jan 15 13:00:53 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:                     feedback
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 167727 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-12 12:02 CST
Last Modified:              2009-01-15 13:00 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
====================================================================== 

---------------------------------------------------------------------- 
 (0097952) svnbot (reporter) - 2009-01-15 13:00
 http://bugs.digium.com/view.php?id=14220#c97952 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 168726

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

------------------------------------------------------------------------
r168726 | mmichelson | 2009-01-15 13:00:53 -0600 (Thu, 15 Jan 2009) | 25
lines

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

........
r168725 | mmichelson | 2009-01-15 13:00:06 -0600 (Thu, 15 Jan 2009) | 17
lines

Remove an unneeded condition for line addition to a SIP request/response

In Asterisk 1.4 and 1.6.0, the sip_request structure had a statically
allocated buffer to hold the text of the request. There was a check in the
add_line function to not attempt to write the line into the buffer if we
did not have room for it.

In trunk and Asterisk versions starting with 1.6.1, an expandable ast_str
structure is used to hold the text. Since it may grow to fit an
arbitrarily
sized string, this check in add_line is no longer valid.

I found this oddity while attempting to fix issue
http://bugs.digium.com/view.php?id=14220; however, I do
not
believe that this is the fix for that issue since the output supplied by
the
reporter did not contain the warning message that would be printed had
this
condition been satisfied.

........

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-15 13:00 svnbot         Checkin                                      
2009-01-15 13:00 svnbot         Note Added: 0097952                          
======================================================================