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

[Alex Balashov]

Alex Balashov wrote:
> 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?
> 
> 

I should add that this sequence appears to play out in the exact same 
order every single time.

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