OK, I think I just found the main bug...
When a SipMessage (HttpMessage) with a multipart/mixed content-type is
received by Sipxtapi, the HttpMessage class parses the Body and creates a
multipart HttpBody.
The multipart HttpBody contains an array of pointers (mpBodyParts) to
MimeBodyPart objects.
The MimeBodyPart constructor keeps a pointer (mpParentBody) to the HttpBody
data.
Then there are bugs in the HttpBody copy constructor and the HttpBody
assignment operator, as the MimeBodyParts are copied to the new HttpBody
without updating the mpParentBody pointer. If the copied object is deleted,
the mpParentBody pointers in MimeBodyPart objects point to bad memory... and
sipxtapi *crashes*
Quick solutions are the following In HttpBody.cpp
1) In HttpBody::HttpBody(const HttpBody& rHttpBody)
Replace the line
new MimeBodyPart(*(rHttpBody.mpBodyParts[partIndex])) :
With the line:
new MimeBodyPart(this, rHttpBody.mpBodyParts[partIndex]->getRawStart(),
rHttpBody.mpBodyParts[partIndex]->getRawLength() ) :
2) In HttpBody& HttpBody::operator=(const HttpBody& rhs)
Replace the line
mpBodyParts[partIndex] = new MimeBodyPart(*(rhs.mpBodyParts[partIndex]));
With the line
mpBodyParts[partIndex] = new MimeBodyPart(this,
rhs.mpBodyParts[partIndex]->getRawStart(),
rhs.mpBodyParts[partIndex]->getRawLength() );
There are a few other smaller bugs to fix for multipart content-type to be
fully OK.
3) In the HttpBody constructor, the boundary data cannot have quotes:
Content-Type: multipart/mixed;boundary="unique-boundary-1" --> doesn't work
as the double-quotes are also searched in the body. I checked the RFC, and
double-quotes are allowed around the boundary.
I added those few lines to the constructor to remove first and last \":
whiteSpaceIndex = mMultipartBoundary.first('\"');
if(whiteSpaceIndex == 0) mMultipartBoundary.remove(whiteSpaceIndex,1);
whiteSpaceIndex = mMultipartBoundary.last('\"');
if(whiteSpaceIndex > 0) mMultipartBoundary.remove(whiteSpaceIndex);
4) Again in the HttpBody constructor, there is a problem in the MimeBodyPart
startIndex calculation: partBytes - parentBodyBytes is not the start index !
mpBodyParts[partIndex] = new MimeBodyPart(this, partBytes - parentBodyBytes,
partLength);
This line is replaced by the line:
mpBodyParts[partIndex] = new MimeBodyPart(this, partStart, partLength);
And I got partStart by changing getMultipartBytes() to return this value as
an additional output parameter.
I'll try to publish a clean patch ASAP... but now it's working, and sipxtapi
doesn't crash anymore when receiving multipart/mixed bodies in INVITES.
stipus
----- Original Message -----
From: "Alexander Chemeris" <[EMAIL PROTECTED]>
To: "stipus" <[EMAIL PROTECTED]>
Cc: "Daniel Sigurgeirsson" <[EMAIL PROTECTED]>; "Jaroslav Libak"
<[EMAIL PROTECTED]>; "AlexeyTrizno" <[EMAIL PROTECTED]>;
<[email protected]>
Sent: Monday, July 02, 2007 3:35 PM
Subject: Re: [sipxtapi-dev] OsMsgPool::FindFreeMsg
'MediaSignals'queuesize(33) exceeds soft limit (32)
> Hello,
>
> On 6/30/07, stipus <[EMAIL PROTECTED]> wrote:
> > Yes, this is in inside SipConnection::getInitialSdpCodecs( )
> >
> > However, there are tests that check for null in the function. At the end
of
> > the function you can also find a return value based on the body being
null:
>
> Hum, I found that SipConnection::getInitialSdpCodecs( ) return value
> is not checked in four places:
> SipConnection::answer()
> SipConnection::accept()
> SipConnection::processInviteResponseRinging()
> SipConnection::processInviteResponseNormal()
>
> So, I guess it crash in one of this functions. Could you check this?
>
> Patch, adding checks of SipConnection::getInitialSdpCodecs( ) return value
> is welcome.
>
> --
> Regards,
> Alexander Chemeris.
>
> SIPez LLC.
> SIP VoIP, IM and Presence Consulting
> http://www.SIPez.com
> tel: +1 (617) 273-4000
>
>
>
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
