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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/6/29 Ole Kaas obk@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.
Regards.
Den 30/06/2010 kl. 01.23 skrev Iñaki Baz Castillo:
2010/6/29 Ole Kaas obk@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
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 Kaasobk@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
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:
- Asterisk Gateway does not receive/accept the ACK
- 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 Kaasobk@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
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
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.
Caio
Am 02.07.2010 15:54, 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.
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.
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)
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
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:
> 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.
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
On Jul 2, 2010, at 9:54 AM, Claudio Furrer elcaio@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/
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:
- Asterisk Gateway does not receive/accept the ACK
- 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 Kaasobk@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
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:
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:
- 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 Kaasobk@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
-
Alex Balashov -
Claudio Furrer -
Geoffrey Mina -
Iñaki Baz Castillo -
Klaus Darilion -
Ole Kaas