Thanks for your quick reply.
I’m not quite sure that I understand fully what you mean.
This is my scenario:
INVITE --->
branch=z9hG4bK-d8754z-08c75b1641774534-2---d8754z-
100 <---
branch=z9hG4bK-d8754z-08c75b1641774534-2---d8754z-
180 <---
branch=z9hG4bK-d8754z-08c75b1641774534-2---d8754z-
CANCEL --->
branch=z9hG4bK-d8754z-08c75b1641774534-1---d8754z-
481 <---
branch=z9hG4bK-d8754z-08c75b1641774534-1---d8754z-
As you can see the branch is not the same for the cancel message. The cancel is not accepted by the remote side which returns 481.
What do you mean by "transport sequence number is ignored by the stack when performing transaction-matching"? Doesn't 3261 state that the branch parameter of the cancel must be equal to the branch parameter of the invite being cancelled?
I've looked into the send-function of SipStack.cxx and found that the message is copied before being processed. This means that the original sip message that I'm holding on to to be able to cancel is not the same as the one actually sent out. So when mTransportSeq is incremented after failover there is no way for me of knowing that. The only solution I see to this is to use the incoming provisional response to update my invite.
Best regards
Krister
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.
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?