30 Jan
2003
30 Jan
'03
11:57 a.m.
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