Hey all,
I have a Kamailio implementation (version: kamailio 4.4.1 (x86_64/solaris) 12b048) as part of the Kazoo platform. I’m having an odd problem with an e2e ACK (after a 200OK after a T38 re-invite), which I’m pretty sure has to do with a Contact header rewrite due to the following (can review attached PCAP for specifics):
if (nat_uac_test("3")) { force_rport(); fix_nated_contact(); }
I have a couple of questions about this:
A flag of 3, I don’t understand. I read the documentation http://kamailio.org/docs/modules/4.4.x/modules/nathelper.html#nathelper.f.nat_uac_test, and there is a 1,2,4,8,etc… So, I’m guessing that a flag of 3, means 1+2? If #1 is true, then "the "received" test is used: address in the “Via” header is compared against source IP address of signaling” I don’t understand this test, as I’m pretty sure that the 200OK that’s getting re-written is properly constructed. I guess I’m trying to understand when one would want to use this test?
Thanks!
~Noah
I discussed this with Alex Balashov off-line, and he answered my questions:
A flag of 3, I don’t understand. I read the documentation http://kamailio.org/docs/modules/4.4.x/modules/nathelper.html#nathelper.f.nat_uac_test, and there is a 1,2,4,8,etc… So, I’m guessing that a flag of 3, means 1+2?
Yes, apparently this is a bit array: https://en.wikipedia.org/wiki/Bit_array https://en.wikipedia.org/wiki/Bit_array and a value of 3 = 1+2.
If #1 is true, then "the "received" test is used: address in the “Via” header is compared against source IP address of signaling” I don’t understand this test, as I’m pretty sure that the 200OK that’s getting re-written is properly constructed. I guess I’m trying to understand when one would want to use this test?
Although we weren’t able to come up with an example for this test, it does not seem to apply to my environment. Updating the flag to 1 solves my issue.
Thanks!
~Noah
On 17/08/16 20:26, Noah Mehl wrote:
I discussed this with Alex Balashov off-line, and he answered my questions:
- A flag of 3, I don’t understand. I read the documentation http://kamailio.org/docs/modules/4.4.x/modules/nathelper.html#nathelper.f.nat_uac_test, and there is a 1,2,4,8,etc… So, I’m guessing that a flag of 3, means 1+2?
Yes, apparently this is a bit array: https://en.wikipedia.org/wiki/Bit_array and a value of 3 = 1+2.
- If #1 is true, then "the "received" test is used: address in the “Via” header is compared against source IP address of signaling”
- I don’t understand this test, as I’m pretty sure that the 200OK that’s getting re-written is properly constructed. I guess I’m trying to understand when one would want to use this test?
Although we weren’t able to come up with an example for this test, it does not seem to apply to my environment. Updating the flag to 1 solves my issue.
This is when the sip message was sent from a.b.c.d and the Via header has x.y.z.w. if you get a pcap with the request, we can check and see if the test is true for it.
On the other hand, you should use set_contact_alias()/handle_ruri_alias() instead of fix_nated_contact() (see how default kamailio.cfg does it) -- it is safer for such cases and avoids getting in troubles with devices that are strict in checking if the r-uri is the contact they set previously.
Cheers, Daniel
On 08/18/2016 03:02 AM, Daniel-Constantin Mierla wrote:
This is when the sip message was sent from a.b.c.d and the Via header has x.y.z.w. if you get a pcap with the request, we can check and see if the test is true for it.
In Noah's case, this posed an issue because the request was being received from a proxy. The proxy strips off its Via, and the topmost exposed Via has the network & transport-layer reachability information of the UAS that received the reinvite (originated on Noah's end). Both proxy and UAS are public, but different entities.
On the other hand, you should use set_contact_alias()/handle_ruri_alias() instead of fix_nated_contact() (see how default kamailio.cfg does it) -- it is safer for such cases and avoids getting in troubles with devices that are strict in checking if the r-uri is the contact they set previously.
Agree. I have moved to this nowadays for all cases that were handled with fix_nated_contact() in the past for just this reason.
-- Alex
-
Alex Balashov -
Daniel-Constantin Mierla -
Noah Mehl