29 Jun
2010
29 Jun
'10
12:37 p.m.
Hello,
See transmission below. For some reason the ACK package is lost/dropped and the remote
server retransmits the 200 OK status. But Kamailio does not retransmit the ACK on
receiving the retransmitted OK's. Eventually the remote server gives up and pulls the
plug after ~20 seconds. Is this a bug or should I look closer at my routing script? The
script is for the ACK handling pretty much the same at the vanilla script delivered with
the source. I'm still on version 3.0.0.
/Ole
-> Request: INVITE sip:phonenum@destination, with session description
<- Status: 100 Trying
<- Status: 180 Ringing
<- Status: 183 Session Progress, with session description
<- Status: 200 OK, with session description
-> Request: ACK sip:phonenum@destination
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
-> Request: BYE sip:phonenum@destination
-> Request: BYE sip:phonenum@destination
<- Status: 481 Call leg/transaction does not exist
29 Jun
29 Jun
1:15 p.m.
The log does not tell us anything.
If you want to know from us if your config is wrong or your
clients/server is buggy, then we need an ngrep dump recorded at the SIP
proxy:
ngrep -Wbyline -t -q port 5060
regards
Klaus
Am 29.06.2010 12:37, schrieb Ole Kaas:
Hello,
See transmission below. For some reason the ACK package is lost/dropped and the remote
server retransmits the 200 OK status. But Kamailio does not retransmit the ACK on
receiving the retransmitted OK's. Eventually the remote server gives up and pulls the
plug after ~20 seconds. Is this a bug or should I look closer at my routing script? The
script is for the ACK handling pretty much the same at the vanilla script delivered with
the source. I'm still on version 3.0.0.
/Ole
-> Request: INVITE sip:phonenum@destination, with session description
<- Status: 100 Trying
<- Status: 180 Ringing
<- Status: 183 Session Progress, with session description
<- Status: 200 OK, with session description
-> Request: ACK sip:phonenum@destination
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
-> Request: BYE sip:phonenum@destination
-> Request: BYE sip:phonenum@destination
<- Status: 481 Call leg/transaction does not exist
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:47 p.m.
I have also seen this with Kamailio 1.5 I have not confirmed whether
Kamailio is sending the 200 OK back down to my asterisk server or not.
On Tue, Jun 29, 2010 at 7:15 AM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
The log does not tell us anything.
If you want to know from us if your config is wrong or your clients/server
is buggy, then we need an ngrep dump recorded at the SIP proxy:
ngrep -Wbyline -t -q port 5060
regards
Klaus
Am 29.06.2010 12:37, schrieb Ole Kaas:
Hello,
See transmission below. For some reason the ACK package is lost/dropped
and the remote server retransmits the 200 OK status. But Kamailio does not
retransmit the ACK on receiving the retransmitted OK's. Eventually the
remote server gives up and pulls the plug after ~20 seconds. Is this a bug
or should I look closer at my routing script? The script is for the ACK
handling pretty much the same at the vanilla script delivered with the
source. I'm still on version 3.0.0.
/Ole
-> Request: INVITE sip:phonenum@destination, with session description
<- Status: 100 Trying
<- Status: 180 Ringing
<- Status: 183 Session Progress, with session description
<- Status: 200 OK, with session description
-> Request: ACK sip:phonenum@destination
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
<- Status: 200 OK, with session description
-> Request: BYE sip:phonenum@destination
-> Request: BYE sip:phonenum@destination
<- Status: 481 Call leg/transaction does not exist
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:50 p.m.
Hi Klaus,
I've mailed pcap dump to you directly for further inspection.
/Ole
Den 29/06/2010 kl. 13.15 skrev Klaus Darilion:
The log does not tell us anything.
If you want to know from us if your config is wrong or your clients/server is buggy, then
we need an ngrep dump recorded at the SIP proxy:
ngrep -Wbyline -t -q port 5060
regards
Klaus
Am 29.06.2010 12:37, schrieb Ole Kaas:
> Hello,
>
> See transmission below. For some reason the ACK package is lost/dropped and the
remote server retransmits the 200 OK status. But Kamailio does not retransmit the ACK on
receiving the retransmitted OK's. Eventually the remote server gives up and pulls the
plug after ~20 seconds. Is this a bug or should I look closer at my routing script? The
script is for the ACK handling pretty much the same at the vanilla script delivered with
the source. I'm still on version 3.0.0.
>
> /Ole
>
> -> Request: INVITE sip:phonenum@destination, with session description
> <- Status: 100 Trying
> <- Status: 180 Ringing
> <- Status: 183 Session Progress, with session description
> <- Status: 200 OK, with session description
> -> Request: ACK sip:phonenum@destination
> <- Status: 200 OK, with session description
> <- Status: 200 OK, with session description
> <- Status: 200 OK, with session description
> <- Status: 200 OK, with session description
> <- Status: 200 OK, with session description
> <- Status: 200 OK, with session description
> -> Request: BYE sip:phonenum@destination
> -> Request: BYE sip:phonenum@destination
> <- Status: 481 Call leg/transaction does not exist
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
30 Jun
30 Jun
1:23 a.m.
2010/6/29 Ole Kaas <obk(a)tet.dk>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.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:33 p.m.
Den 30/06/2010 kl. 01.23 skrev Iñaki Baz Castillo:
2010/6/29 Ole Kaas <obk(a)tet.dk>dk>:
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
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.
1 Jul
1 Jul
9:12 a.m.
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<obk(a)tet.dk>dk>:
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
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.
2:38 p.m.
Hi, I have a similar issue, my proxy sip doesn't relay the ACK coming from a
Cisco GW (caller), to a PSTN-GW (callee), then the OK and ACK are retransmitted
for a while till the pstn-gw send a BYE.
Attach a text graph, where:
10.10.10.128 is a Cisco GW.
10.15.15.122 is my Proxy SIP (and oldie SER one)
10.20.20.153 is the PSTN-GW.
It only happens with this cisco gw, works great with asterisk and others ata.
I think there is something wrong with the ACK, i don't understand why the the
proxy sip ignores it and never relays it.
I'd appreciate any comment. I also can help to solve the original issue of Ole
K.
Regards,
Caio
On Thu, 1 Jul 2010, Klaus Darilion wrote:
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:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/6/29 Ole Kaas<obk(a)tet.dk>dk>:
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
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.
2 Jul
2 Jul
3:11 p.m.
Am 01.07.2010 17:40, schrieb Claudio Furrer:
>
> Am 01.07.2010 14:38, schrieb Claudio Furrer:
>> Hi, I have a similar issue,
>
> It is not possible to debug this issue without full SIP trace!
>
> ngrep -Wbyline -t -d any port 5060
I find it unpleasant to read such a trace. Please really use ngrep to
get a nice formated SIP trace, or supply the pcap file.
thanks
Klaus
3:54 p.m.
> > Hi,
I have a similar issue,
>
> It is not possible to debug this issue without full SIP trace!
>
> ngrep -Wbyline -t -d any port 5060
I find it unpleasant to read such a trace. Please really use ngrep to get a
nice formated SIP trace, or supply the pcap file.
5:16 p.m.
Am 02.07.2010 15:54, schrieb Claudio Furrer:
Ok, here it goes again.
Pay attention to the "200: OK" response from the PSTN-GW. I think its Contact
header should be read by the Cisco GW (calling party), and then send its
ACK-request with R-URI based on that Contact. But it doesn't happen. Then here i
think this is the failure. (rfc3261, section 12.1.1 and 12.2.1.2). May i am
wrong..
What do you think?
I'd appreciate your comments.
You are right. Caller behaves wrong, it should send ACK with
RURI=ContactOf200Ok.
Maybe this is a buggy NAT traversal feature of Caller (Cisco?) which can
be turned off.
If you can't fix it at Caller-side, you can make some workarounds at the
proxy (if it is a fixed routing to the other gateway)
regards
Klaus
>> Hi, I have a similar issue,
>
> It is not possible to debug this issue without full SIP trace!
>
> ngrep -Wbyline -t -d any port 5060
I find it unpleasant to read such a trace. Please really use ngrep to get a
nice formated SIP trace, or supply the pcap file.
5:28 p.m.
> > Hi,
I have a similar issue,
>
> It is not possible to debug this issue without full SIP trace!
>
> ngrep -Wbyline -t -d any port 5060
I find it unpleasant to read such a trace. Please really use ngrep to get
a
nice formated SIP trace, or supply the pcap file.
6:37 p.m.
If you allways route the requests from the broken caller to the other
gateway, you can use something like that:
...
if (loose_route() {
if (src__ip=10.10.10.128) {
$rd=10.20.20.153;
$du="sip:10.20.20.153:5060";
}
... normal loose-route processing
t_relay();
exit;
}
...
regards
Klaus
Am 02.07.2010 17:28, schrieb Claudio Furrer:
You are right. Caller behaves wrong, it should send ACK with
RURI=ContactOf200Ok.
Maybe this is a buggy NAT traversal feature of Caller (Cisco?) which can be
turned off.
If you can't fix it at Caller-side, you can make some workarounds at the proxy
(if it is a fixed routing to the other gateway)
I think being a cisco device, there isn't too much to touch/modify. Just to
start thinking about a workaround. Which kind of modification, source code or
ser.cfg config? Maybe accepting and relaying all ACKs sent by this gw; simple,
but insecure, not sure.
Thank you Klaus,
Caio
>>>
Hi, I have a similar issue,
>>
>> It is not possible to debug this issue without full SIP trace!
>>
>> ngrep -Wbyline -t -d any port 5060
I find it unpleasant to read such a trace. Please really use ngrep to get
a
nice formated SIP trace, or supply the pcap file.
Ok, here it goes again.
Pay attention to the "200: OK" response from the PSTN-GW. I think its
Contact
header should be read by the Cisco GW (calling party), and then send its
ACK-request with R-URI based on that Contact. But it doesn't happen. Then
here i
think this is the failure. (rfc3261, section 12.1.1 and 12.2.1.2). May i am
wrong..
What do you think?
I'd appreciate your comments. 
3 Jul
3 Jul
11:40 a.m.
On Jul 2, 2010, at 9:54 AM, Claudio Furrer <elcaio(a)gmail.com> wrote:
Ok, here it goes again.
Pay attention to the "200: OK" response from the PSTN-GW. I think
its Contact
header should be read by the Cisco GW (calling party), and then send
its
ACK-request with R-URI based on that Contact. But it doesn't happen.
Then here i
think this is the failure. (rfc3261, section 12.1.1 and 12.2.1.2).
May i am wrong..
What do you think?
I'd appreciate your comments
I agree with your assessment. The target request URI of the ACK
generates by the Cisco UAC should be the Contact URI received in the
200 OK.
I work with Cisco ISDN-VoIP gear all the time and have never seen a
device do that, though. It is either a very unusual bug in a very old
IOS release or a misconfiguration.
Can you tell me what device and IOS version is involved? Also,
applicable elements of the running-config could help.
Cheers,
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
>
>
1 Jul
1 Jul
10:33 p.m.
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
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<obk(a)tet.dk>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
>
2 Jul
2 Jul
3:08 p.m.
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<obk(a)tet.dk>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
>
5049
days inactive
5053
days old
17 comments
6 participants
participants (6)
-
Alex Balashov -
Claudio Furrer -
Geoffrey Mina -
Iñaki Baz Castillo -
Klaus Darilion -
Ole Kaas