< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] Canceling invite after failover


I have committed a fix to main, and I just want to check if the fix works. Is this something you already have a test for?

Best regards,
Byron Campen

Ohhh, the other side is complaining, not the stack. That does make sense. We probably need to set the transport sequence when the CANCEL comes down from the TU. Good catch! I'll try to fix this tomorrow.

Best regards,
Byron Campen

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
 

Från: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] 
Skickat: den 6 november 2008 20:14
Till: Krister Jarl
Kopia: resiprocate-users@xxxxxxxxxxxxxxx
Ämne: Re: [reSIProcate-users] Canceling invite after failover
 
                    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/
 

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