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

Alex Balashov abalashov at evaristesys.com
Sat Aug 2 23:21:45 CEST 2008


Alex Balashov wrote:

> Both far-endpoints send a 200 OK w/SDP and I hear both media streams 
> simultaneously when I call, interleaved by clicks.  After a while, the 
> second (most recent) contact's media stream drops off because the UAC 
> decides that the call has timed out because it has not received ACK 
> replies to its 200 OKs;  at the same time, OpenSER appears to generate a 
> CANCEL for that second call leg.  The CANCEL is replied to with a 200 OK 
> (not a 487 Request Terminated?) although this seems a little bizarre 
> since the dialog's state is already established -- but since the 200 OKs 
> are never replied to, I suppose it is not necessary to receive a BYE in 
> order to terminate that request.  Meanwhile, 200 OKs in response to 
> INVITE keep coming from the contact that was slower to pick up and was 
> CANCEL'd (why? this is Asterisk 1.4), but the ACKs from them keep being 
> routed to the first contact (the one that remains), which must be 
> understandably confused as to why they're there although processed as 
> retransmissions.

OK, that was rather incoherent.  Let me take a step back and summarise 
from what I see in my Kamailio debugging output:

1. SBC sends call to Kamailio proxy.

2. Proxy does registrar dip and resolves two contacts - A and B.

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.

- The proxy elects to CANCEL the other branch to B between #6 and #7.

- After sending the CANCEL, the proxy decides to pass back the original 
200 OK for the INVITE (with SDP) for B back to the SBC as well.

- After that, B replies with a 200 OK for the CANCEL issued by the 
proxy.  Why does it reply with a 200 OK?  Simply because it is after the 
INVITE was already OK'd?  Is that per the RFC?  I thought a call leg 
could not be CANCEL'd at this stage at all and requires a BYE?

- SBC ACKs the 200 OK (for INVITE) from A, and proxy relays to A.

- Meanwhile, B keeps sending 200 OKs for the INVITE (AFTER a CANCEL on 
that branch!) and the proxy keeps relaying them back to the SBC, which 
replies with ACKs.  But these ACKs keep getting forwarded back to A, not 
B, presumably because from the proxy's POV the B leg is now CANCEL'd and 
OK'd (in the penultimate step).

So, I am not really sure what to make of this... I would appreciate any 
help!

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




More information about the sr-users mailing list