Hi Zeus!
Zeus Ng schrieb:
First, the ACK should follow section 12.2 (indeed 12.2.1.1), Requests within a Dialog, not section 12.1.2 according to section 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
I disagee: the SER is an UAS not an UAC. IMHO, the concernig chapters are 16.6 subpoint 8 ("16.6 Request Forwarding"; "8. Add a Via header field value") and 8.1.1.7 ("8.1.1.7 Via"). Both chapters state the UAS (SER) MUST add a Via with a branch parameter starting with the magic cookie "z9hG4bK".
The ACK generated by the UAC looks good to me, anyway.
Second, do you happened to have a line like this in your SER config.
aliase=your_proxy_name:5080 or aliase=your_proxy_ip:5080?
Are you sure about the trailing 'e' in "aliase"? I've two alias-definitions (one for the IP, one for the realm) in my ser.cfg. But they don't have the port added. I've already added the ports in the listen statements.
Alex Mack
When I mention section 12.2, I was referring your UA, not SER. I do have a typo on alias as well.
To better troubleshoot your problem, ser.cfg and debug would help. By looking at your ngrep, I believe there is something wrong with your ser.cfg. The ACK from SER to Asterisk should not have a Record-Route header added.
-----Original Message----- From: serdev-bounces@lists.iptel.org [mailto:serdev-bounces@lists.iptel.org] On Behalf Of Alex Mack Sent: Wednesday, 4 May 2005 8:29 PM To: Zeus Ng Cc: serdev@lists.iptel.org; serusers@lists.iptel.org Subject: Re: [Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's
Hi Zeus!
Zeus Ng schrieb:
First, the ACK should follow section 12.2 (indeed 12.2.1.1),
Requests
within a Dialog, not section 12.1.2 according to section
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
I disagee: the SER is an UAS not an UAC. IMHO, the concernig chapters are 16.6 subpoint 8 ("16.6 Request Forwarding"; "8. Add a Via header field value") and 8.1.1.7 ("8.1.1.7 Via"). Both chapters state the UAS (SER) MUST add a Via with a branch parameter starting with the magic cookie "z9hG4bK".
The ACK generated by the UAC looks good to me, anyway.
Second, do you happened to have a line like this in your SER config.
aliase=your_proxy_name:5080 or aliase=your_proxy_ip:5080?
Are you sure about the trailing 'e' in "aliase"? I've two alias-definitions (one for the IP, one for the realm) in my ser.cfg. But they don't have the port added. I've already added the ports in the listen statements.
Alex Mack
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi Zeus!
Maybe there's a misunderstandiung: I for myself have no problem with looping packets but I've problems with ACKs and Via-HF with branch=0 - and that's the UAS (SER) to be blamed for. The UA sends a normal - and in my eyes correct - ACK after an 200 OK, and this ACK is forwarded by SER with a Via-HF containing "branch=0".
So far I didn't get a clue how I could take influence on SER writing bad branch parameters - even if I wanted SER to do that. IMHO branch=0 isn't legal according to the metioned sections of RFC3261.
I've attached a ethereal plaintext export of a call. Packet #13 is the ACK from the initiating UA to SER, packet #14 is the bad ACK with branch=0. Sorry for the crumbled view, but I have almost no influence on ethereal's export format.
Alex Mack
Zeus Ng schrieb:
When I mention section 12.2, I was referring your UA, not SER. I do have a typo on alias as well.
To better troubleshoot your problem, ser.cfg and debug would help. By looking at your ngrep, I believe there is something wrong with your ser.cfg. The ACK from SER to Asterisk should not have a Record-Route header added.
-----Original Message----- From: serdev-bounces@lists.iptel.org [mailto:serdev-bounces@lists.iptel.org] On Behalf Of Alex Mack Sent: Wednesday, 4 May 2005 8:29 PM To: Zeus Ng Cc: serdev@lists.iptel.org; serusers@lists.iptel.org Subject: Re: [Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's
Hi Zeus!
Zeus Ng schrieb:
First, the ACK should follow section 12.2 (indeed 12.2.1.1),
Requests
within a Dialog, not section 12.1.2 according to section
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
I disagee: the SER is an UAS not an UAC. IMHO, the concernig chapters are 16.6 subpoint 8 ("16.6 Request Forwarding"; "8. Add a Via header field value") and 8.1.1.7 ("8.1.1.7 Via"). Both chapters state the UAS (SER) MUST add a Via with a branch parameter starting with the magic cookie "z9hG4bK".
The ACK generated by the UAC looks good to me, anyway.
Second, do you happened to have a line like this in your SER config.
aliase=your_proxy_name:5080 or aliase=your_proxy_ip:5080?
Are you sure about the trailing 'e' in "aliase"? I've two alias-definitions (one for the IP, one for the realm) in my ser.cfg. But they don't have the port added. I've already added the ports in the listen statements.
Alex Mack
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Alex,
I agree with you that "branch=0" is a bad implementation. A similar discussion was raised last year in the sip-implementors mailing list.
http://lists.cs.columbia.edu/pipermail/sip-implementors/2004-September/00724 3.html
It illustrated the problem with examples. Maybe someone should look into this issue.
Zeus
-----Original Message----- From: Alex Mack [mailto:amack@fhm.edu] Sent: Wednesday, 4 May 2005 10:32 PM To: Zeus Ng Cc: serdev@lists.iptel.org; serusers@lists.iptel.org Subject: Re: [Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's
Hi Zeus!
Maybe there's a misunderstandiung: I for myself have no problem with looping packets but I've problems with ACKs and Via-HF with branch=0 - and that's the UAS (SER) to be blamed for. The UA sends a normal - and in my eyes correct - ACK after an 200 OK, and this ACK is forwarded by SER with a Via-HF containing "branch=0".
So far I didn't get a clue how I could take influence on SER writing bad branch parameters - even if I wanted SER to do that. IMHO branch=0 isn't legal according to the metioned sections of RFC3261.
I've attached a ethereal plaintext export of a call. Packet #13 is the ACK from the initiating UA to SER, packet #14 is the bad ACK with branch=0. Sorry for the crumbled view, but I have almost no influence on ethereal's export format.
Alex Mack
Zeus Ng schrieb:
When I mention section 12.2, I was referring your UA, not SER. I do have a typo on alias as well.
To better troubleshoot your problem, ser.cfg and debug would
help. By
looking at your ngrep, I believe there is something wrong with your ser.cfg. The ACK from SER to Asterisk should not have a Record-Route header added.
-----Original Message----- From: serdev-bounces@lists.iptel.org [mailto:serdev-bounces@lists.iptel.org] On Behalf Of Alex Mack Sent: Wednesday, 4 May 2005 8:29 PM To: Zeus Ng Cc: serdev@lists.iptel.org; serusers@lists.iptel.org Subject: Re: [Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's
Hi Zeus!
Zeus Ng schrieb:
First, the ACK should follow section 12.2 (indeed 12.2.1.1),
Requests
within a Dialog, not section 12.1.2 according to section
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
I disagee: the SER is an UAS not an UAC. IMHO, the concernig chapters are 16.6 subpoint 8 ("16.6 Request Forwarding"; "8. Add a Via header field value") and 8.1.1.7
("8.1.1.7
Via"). Both chapters state the UAS (SER) MUST add a Via
with a branch
parameter starting with the magic cookie "z9hG4bK".
The ACK generated by the UAC looks good to me, anyway.
Second, do you happened to have a line like this in your
SER config.
aliase=your_proxy_name:5080 or aliase=your_proxy_ip:5080?
Are you sure about the trailing 'e' in "aliase"? I've two alias-definitions (one for the IP, one for the realm) in my ser.cfg. But they don't have the port added. I've already added the ports in the listen statements.
Alex Mack
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
-
Alex Mack -
Zeus Ng