4 May
2005
4 May
'05
1:28 p.m.
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
4 May
4 May
2:38 p.m.
New subject: [Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's
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(a)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(a)lists.iptel.org; serusers(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
3:32 p.m.
New subject: [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(a)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(a)lists.iptel.org; serusers(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
6:27 p.m.
New subject: [Serusers] Re: [Serdev] Problem with Via Branch/Strange Looping Problem with ACK's
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(a)lists.iptel.org; serusers(a)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(a)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(a)lists.iptel.org; serusers(a)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(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
7145
days inactive
7145
days old
3 comments
2 participants
participants (2)
-
Alex Mack -
Zeus Ng