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