21 Feb
2012
21 Feb
'12
6:38 a.m.
Hello,
we have a Kamailio proxy which gets the call from PSTN gw and does some
call forwarding (serial forking) to several destinations through our sbc
The call flow I am looking at is:
- Kamailio sends INVITE to branch_1.
- branch_1 sends 180 with to-tag*, proxy relays it to the gw
* 180 meets the requirements for dialog creating 18x responses in
sections 12.1, 12.1.1 because it contains to-tag, contact and mirrored
record-route.
- After some seconds Kamailio sends a CANCEL to branch_1.
- And sends the INVITE to branch_2.
- branch_1 replies 200 for the CANCEL and 487 for the INVITE.
- branch_2 replies 180 and 200 for the INVITE.
- When PSTN gw receives that it sees it still needs to cancel other
early dialog established by 180 from branch_1.
- The PSTN gw sends a BYE with to-tag of branch_1 to cancel this
specific early dialog.
SIP allows early dialogs to individually released while other dialogs
continue, as written in RFC, section 15:
"The BYE request is used to terminate a specific session or attempted
session. In this case, the specific session is the one with the peer UA
on the other side of the dialog. (...). The caller’s UA MAY send a BYE
for either confirmed or early dialogs, and the callee’s UA MAY send a
BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs."
The BYE follows the loose routing path, proxy gets 481 from the sbc and
forwards that response back to PSTN gw, which somehow breaks it. AFAICS
it's not specified in RFC what should the behavior look like when
getting both a 200 and error-class response for the INVITE (quotes are
most welcome!).
IMO it would be more correct to absorb BYE in proxy but I see a big
problem here: branch_2 can even ring for 5 minutes and it's not feasible
for proxy to have a wt-timer that long. Also it's not possible to inform
the gw that early dialog has cleared as soon as we receive 200/487 from
branch_1.
So I'm not sure which party is at fault and if we can workaround that
somehow in the Kamailio. Any thoughts?