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?