Hi,
We are migrating from our openser 1.4 to kamailio 4.0.3 and have run into a couple of issues. One of them is described below and we need to know if it is a known bug or not.
Kamailio receives an INVITE from a gateway and finally responds with 200 OK. Then an ACK is generated by the gateway towards the Kamailio that some how does not get relayed to the next hop.
The only special aspect here is that the ACK does not contain a Contact header. Is that something that could confuse kamailio and make it unable to relay?
According to SIP RFC, a contact header in ACK is not a must have. Our case is the one where ACK is sent by the UAC after receiving a 200 OK final response. Everything else about the ACK looks OK e.g. ACK has a branch different from the the branch value in the UAC INVITE.
Is it a a known bug in 4.0.3?
In the configuration, we handle ACK as below:
if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; }
Br Adnan
The only way to diagnose this is to get a full packet capture. In all likelihood, there is a problem with the ACK. 4.0 does not, in principle, mishandle ACKs, no, but loose-routing and NAT problems related to their handling are not uncommon.
Adnan 112linuxstockholm@gmail.com wrote:
Hi,
We are migrating from our openser 1.4 to kamailio 4.0.3 and have run into a couple of issues. One of them is described below and we need to know if it is a known bug or not.
Kamailio receives an INVITE from a gateway and finally responds with 200 OK. Then an ACK is generated by the gateway towards the Kamailio that some how does not get relayed to the next hop.
The only special aspect here is that the ACK does not contain a Contact header. Is that something that could confuse kamailio and make it unable to relay?
According to SIP RFC, a contact header in ACK is not a must have. Our case is the one where ACK is sent by the UAC after receiving a 200 OK final response. Everything else about the ACK looks OK e.g. ACK has a branch different from the the branch value in the UAC INVITE.
Is it a a known bug in 4.0.3?
In the configuration, we handle ACK as below:
if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; }
Br Adnan
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
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
For further clarification, the Contact header is not relevant at all (so not used) for routing current request (no matter is ACK or something else). No Contact never results in misrouting. As Alex pointed, only a full sip trace can reveal the problem.
Cheers, Daniel
On 11/27/13 8:31 PM, Alex Balashov wrote:
The only way to diagnose this is to get a full packet capture. In all likelihood, there is a problem with the ACK. 4.0 does not, in principle, mishandle ACKs, no, but loose-routing and NAT problems related to their handling are not uncommon.
Adnan 112linuxstockholm@gmail.com wrote:
Hi, We are migrating from our openser 1.4 to kamailio 4.0.3 and have run into a couple of issues. One of them is described below and we need to know if it is a known bug or not. Kamailio receives an INVITE from a gateway and finally responds with 200 OK. Then an ACK is generated by the gateway towards the Kamailio that some how does not get relayed to the next hop. The only special aspect here is that the ACK does not contain a Contact header. Is that something that could confuse kamailio and make it unable to relay? According to SIP RFC, a contact header in ACK is not a must have. Our case is the one where ACK is sent by the UAC after receiving a 200 OK final response. Everything else about the ACK looks OK e.g. ACK has a branch different from the the branch value in the UAC INVITE. Is it a a known bug in 4.0.3? In the configuration, we handle ACK as below: if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; } Br Adnan ------------------------------------------------------------------------ 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-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
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,
1. After adding t_newtran() as shown below, some how this got fixed i.e. ACK got routed.
However, we are disputed in considering t_newtran() to have caused the fix.
if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { * t_newtran(); #<<<<NEW ADD>>>>* exit; }
2. Is there a frequently used tool remove the private info. from the snoop traces before sending in as debug info.
One way to remove the info, is to convert snoop to text and then replace all IPs and passwords using sed but I need something less time consuming.
Br Adnan
On Wed, Nov 27, 2013 at 11:30 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
For further clarification, the Contact header is not relevant at all (so not used) for routing current request (no matter is ACK or something else). No Contact never results in misrouting. As Alex pointed, only a full sip trace can reveal the problem.
Cheers, Daniel
On 11/27/13 8:31 PM, Alex Balashov wrote:
The only way to diagnose this is to get a full packet capture. In all likelihood, there is a problem with the ACK. 4.0 does not, in principle, mishandle ACKs, no, but loose-routing and NAT problems related to their handling are not uncommon.
Adnan 112linuxstockholm@gmail.com 112linuxstockholm@gmail.com wrote:
Hi,
We are migrating from our openser 1.4 to kamailio 4.0.3 and have run into a couple of issues. One of them is described below and we need to know if it is a known bug or not.
Kamailio receives an INVITE from a gateway and finally responds with 200 OK. Then an ACK is generated by the gateway towards the Kamailio that some how does not get relayed to the next hop.
The only special aspect here is that the ACK does not contain a Contact header. Is that something that could confuse kamailio and make it unable to relay?
According to SIP RFC, a contact header in ACK is not a must have. Our case is the one where ACK is sent by the UAC after receiving a 200 OK final response. Everything else about the ACK looks OK e.g. ACK has a branch different from the the branch value in the UAC INVITE.
Is it a a known bug in 4.0.3?
In the configuration, we handle ACK as below:
if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; }
Br Adnan
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
Hello,
On 11/28/13 5:58 PM, Adnan wrote:
Hi,
- After adding t_newtran() as shown below, some how this got fixed
i.e. ACK got routed.
However, we are disputed in considering t_newtran() to have caused the fix.
if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else {
- t_newtran(); #<<<<NEW ADD>>>>* exit; }
I find that strange, end to end ACK does create any transaction anyhow. Still the sip trace is what can reveal where is the issue.
- Is there a frequently used tool remove the private info. from the
snoop traces before sending in as debug info.
One way to remove the info, is to convert snoop to text and then replace all IPs and passwords using sed but I need something less time consuming.
Converting to text and find/replace is the way typically just works, sed should do it quickly, another tool perhaps will end up in being another sed.
Daniel
Br Adnan
On Wed, Nov 27, 2013 at 11:30 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
For further clarification, the Contact header is not relevant at all (so not used) for routing current request (no matter is ACK or something else). No Contact never results in misrouting. As Alex pointed, only a full sip trace can reveal the problem. Cheers, Daniel On 11/27/13 8:31 PM, Alex Balashov wrote:The only way to diagnose this is to get a full packet capture. In all likelihood, there is a problem with the ACK. 4.0 does not, in principle, mishandle ACKs, no, but loose-routing and NAT problems related to their handling are not uncommon. Adnan <112linuxstockholm@gmail.com> <mailto:112linuxstockholm@gmail.com> wrote: Hi, We are migrating from our openser 1.4 to kamailio 4.0.3 and have run into a couple of issues. One of them is described below and we need to know if it is a known bug or not. Kamailio receives an INVITE from a gateway and finally responds with 200 OK. Then an ACK is generated by the gateway towards the Kamailio that some how does not get relayed to the next hop. The only special aspect here is that the ACK does not contain a Contact header. Is that something that could confuse kamailio and make it unable to relay? According to SIP RFC, a contact header in ACK is not a must have. Our case is the one where ACK is sent by the UAC after receiving a 200 OK final response. Everything else about the ACK looks OK e.g. ACK has a branch different from the the branch value in the UAC INVITE. Is it a a known bug in 4.0.3? In the configuration, we handle ACK as below: if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; } Br Adnan ------------------------------------------------------------------------ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 <tel:%2B1-678-954-0671> Web: http://www.evaristesys.com/, http://www.alexbalashov.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto: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
-
Adnan -
Alex Balashov -
Daniel-Constantin Mierla