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
At 12:51 AM 1/30/2003, Maxim Sobolev wrote:
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.
No. ACK/200 is a "transaction" separate from the original INVITE, however ugly it may sound. It may take a different path and have different transaction id (i.e., branch). It is actually forwarded statelessly per specification. SER generates branch "0" for statelessly forwarded messages. Equal branch id only applies for non-200 ACKs.
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.
That is then Vovida's bug. 200-ACK may take a completely different path and have completely different via-stack, topomost via and its branch.
-Jiri
-
Jiri Kuthan -
Maxim Sobolev