The following code sets up some SIP message headers and sends a subscribe message. The problem lies with the CSIPMessageElements object. When it is passed to the CSIPSubscribeDialogAssoc::SendSubscribeL() method, ownership of the CSIPMessageElements object is transferred meaning the responsibility to free the memeory held by this object becomes that of the SIP stack.
It appears that ownership is transferred as attempting to destroy the object causes an access violation. However, Alloc panic (memory leak) is reported when the application is closed within the emulator. If I comment out the SendSubscribeL() call and change the Pop(iSubscribeMsgElems) to PopAndestroy(iSubscribeMsgElems) the leak is gone!
Is this a known problem with the SIP stack?
if( iProfile->Status() == CSIPProfile::ERegistered )
// Check for a connection
if( !iConnection )
iConnection = iProfileRegistry->ConnectionL(*iProfile);
// Create the 2nd Accept Header (to insure we are identical with header in SAL Subscribe)
CSIPAcceptHeader *acceptHdr2 = CSIPAcceptHeader::NewLC( aMediaType2, aMediaSubtype2 );
// Send Subscribe
if ( iSIPSubscribeDialogAssoc )
if ( iSUBSCRIBEClientTransaction )
I have discovered that the SIP stack leak is actually a red herring and that the leak occurs in the incoming Notifications which result from the Subscribe request. The ownership of the incoming Transaction objects is transferred from the stack to the application and so it is the responsibility of the app to free the memory of these objects.
We have not registered with public SIP server per say although with the 6620, the registration messages are sent using our carriers network and are routed back to our internal network and SIP server. In this context we could be considered to be registering with a public server.
Thanks, I'll see if this fixes it. I thought I tried deleting the transaction object, but I'll try again.
When we attempt to register with a public server from behind a firewall(WINS emulator, or 6620), the SIP stack rejects the servers registration acknowledgement with 'ERegistrarRespondedWithDifferentSipAddressInContact'.
You may want to look into this. There are several public servers you can attempt to register with.
I'm not surprised to hear that the emulator does not receive the ACK. The stack on your PC (emulator) is most likely storing private network address in the SIP messages. The public SIP server is reponding using that IP which is not a public IP address...