Re: [reSIProcate-users] Canceling invite after failover

[Byron Campen <bcampen@xxxxxxxxxxxx>]

That should not be happening. The transport sequence number is ignored by the stack when performing transaction-matching. If cancel is not working, then you have some other problem. It is _possible_ that the CANCEL isn't working because a new provisional response hasn't come in yet for the failover transaction; I'll have to look into this possibility.

You may want to update to 1.4; it provides a SipStack::cancelClientInviteTransaction(const resip::Data& tid) function that causes the stack to handle sending a CANCEL. It also it appropriate to call before a provisional comes in; the stack will automatically wait for a provisional, and then send a CANCEL for you. You no longer have to keep track of whether you have received a provisional or not at the TU.

Best regards,

Byron Campen

Hi!

 

I have a problem with the following scenario.

 

My application sends an invite to a destination that can be resolved to two different destinations.

The first tried destination is down so reciprocate tries the other and succeeds. I’m then trying to cancel the invite by using makeCancel giving it the pointer to the invite.

 

The problem is that this invite has a branch parameter different from the invite actually sent out. The branch of the invite sent out has been incremented in restoreOriginalContactAndVia. So when I’m calling makeCancel the cancel is constructed with the incorrect branch-parameter and I’m not able to cancel the request.

 

Incrementing the branch parameter when failing over seems fine but shouldn’t this affect my original sip message? Is the sip message copied somewhere in the stack?

 

What am I missing here?

 

/kj

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/