Am 01.07.2010 22:33, schrieb Ole Kaas:
Hello,
The guy operating the Asterisk at the far end have been inspecting
the traces I've sent him. Hen notes that the ACK relayed doesn't
entirely comply to the standard. The values of "branch" in the VIA
header of the relayed ACK response incorrectly have the value "0"
(also rport in the VIA header added by their Asterisk is modified).
He suggest setting the syn_branch parameter to get the "branch"
right. I've found this thread about it:
http://blog.gmane.org/gmane.comp.voip.ser/month=20090701
This some question pops up again and again. The RFC is not 100% clear in
this aspect. It states that any RFC3261 compatible UA/proxy must add a
unique branch parameter, starting with the magic cookie. (Thus, Kamailio
should use a unique branch in ACK).
Further RFC3261 states, that if a user agent receives a SIP request
where the topmost Via header contains a branch parameter which does not
start with the magic cookie, the UA has to accept the request and uses
RFC2543-based transaction matching.
Thus, Kamailio - when used as RFC3261 complient proxy - should use a
unique branch parameter. On the other hand, RFC3261 compatible clients
should accept branch=0 too.
I just wonder why this Asterisk-based Gateway does not accept branch=0.
I have several Asterisk versions in use and never experienced any issue
with branch=0.
regards
Klaus
I have put syn_branch=0 in the config and "branch" now have a valid
value. I don't quite buy it - that the incorrect value of "branch"
should be the culprit. But I'll activate tcpdump again and wait to
see if the dropped calls has vanished.
/Ole
Den 01/07/2010 kl. 09.12 skrev Klaus Darilion:
Hi!
Kamailio behaves correct in this trace and I couldn't spot an
abvious error in the trace.
Nevertheless there are 2 problems:
1. Asterisk Gateway does not receive/accept the ACK 2. Asterisk PBX
does not retransmit ACK
reg. 1: ask the gateway operator if he sees the ACK in the Asterisk
log, and if yes the error message of Asterisk why this ACK is not
accepted. If the ACK is not seen in the Asterisk console then maybe
it gets dropped by a buggy firewall.
reg 2: login to your Asterisk PBX and verify if Asterisk receives
the 200 OK, and maybe spot some log message why it does not trigger
ACK retransmissions.
regards Klaus
Am 30.06.2010 23:33, schrieb Ole Kaas:
Den 30/06/2010 kl. 01.23 skrev Iñaki Baz Castillo:
2010/6/29 Ole Kaas<o...@tet.dk>:
Hi Klaus,
I've mailed pcap dump to you directly for further
inspection.
Hi, it's much better if you capture a trace with "ngrep
-Wbyline -t -q port 5060" and paste it in a new mail by
replacing your public IP's with other values. Then all the
people here could help you rather than asking for private help
to a specific member of the maillist.
You are right. But maybe it was something (obvious) that could be
resolved quickly and I could post an update here on the list. The
original log was inadequate - Klaus was a great help, with
suggestions to obtain new log. So here it is attached and
anonymized with all ip addresses (and stuff) converted to private
adresses. The Kamailio server is multi homed and the two networks
are non-routable (I use rtpproxy to bridge media). Our Asterisk
PBX is version 1.4.26.1 and the Asterisk Gateway is 1.6.1 (or
1.6.0 - cant remember and not under my control). Kamailio is
version 3.0.0.
Looking at the trace, it seems the problem starts with the ACK
not being received by the Asterisk Gateway which then resends the
OK. The OK is relayed back to the originating Asterisk PBX which
seems to ignore the retransmission. In fact it seems that
Kamailio is routing and relaying the sip packets correctly.
However, it seems that the problem only exists between Asterisk
and Kamailio. I have other pbx'es (3CX) connecting to Kamailio
and I have no evidence that the problem happens with those. I
have another trace where the call comes from one of the Asterisk
Gateways and is routed back to one of the other Asterisk
Gateways. The result is the same - the OK's are ignored by
Asterisk.
/Ole
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
