Branch value in ACK messages

1. Brekeke Product Name and version:
2.4.7.3
2. Java version:
1.6.0_22-b04
3. OS type and the version:
openSuSE 11.3
4. UA (phone), gateway or other hardware/software involved:
x-lite
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :
Pattern 5
6. Your problem:

It seems that the Brekeke is changing the branch value in the Via Header in ACK messages. The upper server is not able to correlate this messages anymore, so ghosts sessions are created.

The problem appears if using upper registration and a new call has to be authenticated. On the first INVITE with Cseq 1 the switch responds with a 401, the client ACK's this Cseq 1 and creates a new INVITE with Cseq 2, containing the authencation data. Due to the fact that the Brekeke uses a different branch value in the ACK for the Cseq 1 than originally used in the INVITE, the switch is not able to correlate this and claims that the intial INVITE cannot be found. The Brekeke maintains this first INVITE in the Active Connections and claims it is "closing" until a timeout occurs.

Do I miss something here ? Is there a workaround ?

we identified the root cause, the problem only appears if the Cseq: field contains more than one space between the Cseq number and the method name. I would expect the parser to be more flexible here.

I want to make it clear...

Does the problem happen when you use X-Lite as the caller?
What is the upper server?
Does the same problem happen if you make a call between X-Lite?


> It seems that the Brekeke is changing the branch value in the
> Via Header in ACK messages.

Is it same branch value which X-Lite generated??


> Due to the fact that the Brekeke uses a different branch value in
> the ACK for the Cseq 1 than originally used in the INVITE,

Can you paste these packets here?

the backend is a Cisco BTS10200. I have a case open with them to find out why the CSeq header has such a strange format and contains 8 spaces between the number and the method name.

X-Lite works fine directly on the switch, just the Brekeke does something strange upon receiving this line.

The branch value from x-lite (client) and Brekeke is different. I can send you the trace, please just tell me to which address.

tested again today and played around with the CSeq header. The Brekeke has definitely an issue here - as soon as there is more than one space between the number and the method name, the server starts to regenerate the branch values, which causes a lot of confusion.

hi

Can you post a packet trace at http://pcapr.net ?
Which packet does such a strange CSeq have?
Can you make a call between X-lite without problem?

Hi,

I have uploaded the trace:

http://www.pcapr.net/view/adminstuff/20 ... .pcap.html

It contains two calls, one which has the error and one error free. The initial problem can be found in Packet #4, the 401 response. This one contains the strange formatted CSeq: header which causes the Brekeke to "regenerate" the branch id in the via header of the ACK.

Due to that, the switch is not able to find the initial INVITE.

I performed some tests today and had another proxy between the Brekeke and the switch. This proxy parsed the CSeq header and I started to remove the additional whitespaces, with this setup, I could verify that the strange CSeq header causes the issue.

Many thanks for looking at this.

Hi
I've downloaded it.
so you can remove the file if you want.

I've reproduced and verified it.
I will report it to the Brekeke's developer team.