Folks, I discovered that the tm module generates non RFC3261 compliant branch id when forwarding ACK to the final 200 OK response. The RFC, to which ser claims to complain by prefixing generated branch id with magic "z9hG4bK", mandates that ACK to the final 200 OK response should carry on the same branch id as that response and the initial INVITE. On contrary, ser currently adds RFC3261-compliant branch ids for everything, but that final ACK, which in default configuration is being sent with branch id of `0'. This creates a compatibility problem when the next hop uses that branch id for matching 200 OKs to subsequent ACKs, example of such UA is Vovida's b2bua software. I do not have a fix right now, as I am away from my lab, but it should be pretty trivial to fix by pre-loading msg->add_to_branch_s with a correct value in tm module before calling forward() and non-overriding it in the forward() if it is already non-NULL. -Maxim