[Serdev] Bug with ACKs out of transactions, ACK/Via:branch=0

[Jiri Kuthan]

As a matter of fact, if the load generator is not able to deal with branch=0
it breaks the standard. SIP UAs must receive ACKs with any branches. 

Even though RFC3261 doesn't special-case for ACK, there is no reason for
unique branch in e2e ACKS. The unique branch is used to correlate replies
(you might have noticed there are no replies for ACKs) and 
statefuly processed retransmissions (e2e ACKs are not processed statefuly).

Don't get me wrong -- it would be nice to have it if no for our reason
to save times on replying on serusers. However we are having code which has 
been tested against a variety of devices in sipits, our labs, by third parties 
then touching the interoperable code to make your load generator happy does
not appear very high priority.

-jiri

At 01:30 PM 5/31/2005, Alex Mack wrote:
>Hi!
>
>This is a *push* for the "ACK/Via branch=0" problem. Is there something in progress?
>
>RFC3261 states that ACKs on negative responses are in transaction whereas ACKs on "200 OK" replies are out of transaction.
>
>Section 13.1:
>
>  The procedure for sending this ACK
>  depends on the type of response.  For final responses between 300 and
>  699, the ACK processing is done in the transaction layer and follows
>  one set of rules (See Section 17).  For 2xx responses, the ACK is
>  generated by the UAC core.
>
>Maybe that's the reason for SER relaying ACKs with faulty Via-parameter "branch=0"?
>
>I still have the problem that a load generator refuses to work, because he clings to RFC and drops the (erroneous) ACK. I could provide traces off-list.
>
>Alex Mack
>
>_______________________________________________
>Serdev mailing list
>serdev at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev

--
Jiri Kuthan            http://iptel.org/~jiri/