[Serusers] The tm module generates non-compliant branch id for final 200 OK ACKs

[Jiri Kuthan]

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