Re: [Users] Bug in branch handling?

Hi Federico, I tried to go through the RFC to find something backing up their statement. But lucky for us, I didn't find. Here is the part describing how a 2xx ACK must be build: 13.2.2.4 2xx Responses The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately. looking to: 12.2 Requests within a Dialog 12.2.1 UAC Behavior 12.2.1.1 Generating the Request there are no special requirements for VIA branch. Also in 8.1.1.7 Via The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. there is no limitation about the 2xx ACK branch - it says that it must be the same for non-2xx ACK and CANCEL but this does not imply that for 2xx ACK it *must* be different. Maybe they can point out more precisely the RFC section that supports their statement. regards, bogdan Federico Giannici wrote: