[Kamailio-Users] INVITE branch handling for multiple contacts.

[Alex Balashov]

Juha Heinanen wrote:
> Alex Balashov writes:
> 
>  > 3. Proxy bifurcates the call into two branches 'branch A' (to A) and 
>  > 'branch B' (to B).  Rewrites RURI, relays INVITE.
>  > 
>  > 4. A answers with 200 OK.
>  > 
>  > 5. B answers with 200 OK.
>  > 
>  > 6. Proxy passes back 200 OK to SBC for A.  Then for B.
>  > 
>  > 7. SBC issues in-dialog end-to-end ACK for that 200 OK;  proxy decides 
>  > to forward it only to A as per the ONREPLY-ROUTE.  No replies are 
>  > forwarded to B.  It is here that I think things go wrong.
>  > 
>  > 8. B keeps sending 200 OKs and getting no ACKs for them, and eventually 
>  > gives up and kills the session.
>  > 
>  > So, it looks like not all replies are being statefully relayed to both 
>  > branches.
>  > 
>  > Additionally, it looks like the following is happening:
>  > 
>  > - At step #6 above, the 200 OK passed to the SBC is for A only.
> 
> canceling of b branch should happen already after step 4, but perhaps 4 and
> 5 take place almost simultaneously and there is some race condition
> related bug in tm module.

I think it's just the order of events.  According to my packet capture:

- Packet 9, time index 7.953711: 200 OK arrives from A.
- Packet 10, time index 7.954636: 200 OK arrives from B.
- Packet 11, time index 7.969227: Proxy passes 200 OK from A back to SBC.
- Packet 12, time index 7.969268: Proxy originates CANCEL for branch B.
- Packet 13, time index 7.970279: Proxy passes 200 OK from B back to SBC.
- Packet 14, time index 7.971508: 200 OK for CANCEL request arrives from 
B.  [1]
- Packet 15, time index 8.018730: SBC originates ACK for branch to A.
- Packet 16, time index 8.018895: Proxy passes ACK for branch A to A.
- Packet 17, time index 8.153957: B retransmits 200 OK for INVITE.
- Packet 18, time index 8.155309: Proxy forwards 200 OK from B to SBC.
- Packet 19, time index 8.155853: SBC sends ACK again to A's contact. 
This is really strange because the Contact address in Packet 18 is for B.

Then, the sequence 17-19 repeats itself.  B keeps sending 200 OKs, SBC 
keeps ACKing them back to A, and nothing is actually CANCEL'd.

I'm stumped.  Is this the SBC choosing to handle branching that way, or 
Kamailio?

-- Alex

[1]  Again, I would ask, why would a CANCEL be replied to with a 200 OK 
(by bleeding-edge 1.4 release of Asterisk) rather than a 487 Request 
Terminated?  Is this what the RFC prescribes if the session is already 
set up (i.e. after the INVITE has been 200 OK'd in packet 10)?  Wouldn't 
a CANCEL just be invalid at that point - in favour of a BYE?


-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599