3 Aug
2008
3 Aug
'08
4:45 a.m.
Juha Heinanen wrote:
Alex Balashov writes:
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
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.