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