When using nat_uac_test("3"), there is a particular REGISTER message that my kamailio server receives where the source and via addresses are different, but this function seems to return false (and then no nat correction is applied). I have included the register message below. Is there an obvious reason this is not triggering the nat_uac_test? Or can anyone share how they would usually debug a situation like this? Any help/advice would be appreciated.
Thank you!
Example captured Register message:
REGISTER sip:test1.test.com:5060 SIP/2.0 Call-ID: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx CSeq: 1418 REGISTER From: "Joe" sip:xxxyyyzzzz@test1.test.com;tag=2163936191 To: "Joe" sip:xxxyyyzzzz@test1.test.com Via: SIP/2.0/UDP 96.xxx.xxx.xxx:33745;rport;branch=z9hG4bKf5s1p`n3TRv5TZx5RXy.RVv+JPz8Nat*UX!8KRx4SRx Via: SIP/2.0/UDP 192.xx.xxx.xxx:33745;branch=z9hG4bKeb263246c44095f072d8167dd0c7987a343134;rport Max-Forwards: 70 User-Agent: SIPAUA/0.1.001 Contact: "Joe" sip:xxxyyyzzzz@192.xx.xxx.xxx:33745;transport=udp Expires: 3600 Authorization: Digest username="xxxyyyzzzz",realm="test1.test.com ",nonce="UsDqxVLA6ZlvIrO3TsqCtm9X3vqY8405",uri="sip:test1.test.com:5060 ",response="769d1e6f2fd36cf040503f9f079279a0" Content-Length: 0
Associated lines from kamailio log:
[kamailio]# grep 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxxkamailio.log Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|start|recieved UDP request REGISTER sip:test1.test.com Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|source 96.xxx.xxx.xxx:33745 Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|from sip:xxxyyyzzzz@test1.test.com Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|to sip:xxxyyyzzzz@test1.test.com Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|originated from external sources Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|end|issued new auth challenge to new registration attempt Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|start|recieved UDP request REGISTER sip:test1.test.com:5060 Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|source 96.xxx.xxx.xxx:33745 Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|from sip:xxxyyyzzzz@test1.test.com Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|to sip:xxxyyyzzzz@test1.test.com Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|originated from external sources Dec 30 03:33:45 sip-01 kamailio[20495]: DEBUG: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|authenticated xxxyyyzzzz@test1.test.com via cached SIP creds
On 03.01.2014 16:59, Brian Davis wrote:
REGISTER sip:test1.test.com:5060 http://test1.test.com:5060 SIP/2.0 Via: SIP/2.0/UDP 96.xxx.xxx.xxx:33745;rport;branch=z9hG4bKf5s1p`n3TRv5TZx5RXy.RVv+JPz8Nat*UX!8KRx4SRx
Via: SIP/2.0/UDP 192.xx.xxx.xxx:33745;branch=z9hG4bKeb263246c44095f072d8167dd0c7987a343134;rport
Contact: "Joe" sip:xxxyyyzzzz@192.xx.xxx.xxx:33745;transport=udp
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|source 96.xxx.xxx.xxx:33745
Actually the source IP seem to be identical to the topmost Via address.
But it should detect the private IP address in the contact header.
Maybe you have an exception, that NAT traversal is not triggered, if there is more than 1 Via header.
Klaus
The other interesting issue in this case is that the 192.xx.xxx.xxx address is not an RFC1918 address, but it is also not reachable from kamailio. That is why I hoped kamailio would trigger NAT traversal logic solely on the fact that the source and contact address are different.
On Tue, Jan 7, 2014 at 5:01 AM, Klaus Darilion <klaus.mailinglists@pernau.at
wrote:
On 03.01.2014 16:59, Brian Davis wrote:
REGISTER sip:test1.test.com:5060 SIP/2.0 Via: SIP/2.0/UDP 96.xxx.xxx.xxx:33745;rport;branch=z9hG4bKf5s1p`n3TRv5TZx5RXy.RVv+JPz8Nat*UX!8KRx4SRx
Via: SIP/2.0/UDP 192.xx.xxx.xxx:33745;branch=z9hG4bKeb263246c44095f072d8167dd0c7987a343134;rport Contact: "Joe" sip:xxxyyyzzzz@192.xx.xxx.xxx:33745;transport=udp
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx|log|source 96.xxx.xxx.xxx:33745
Actually the source IP seem to be identical to the topmost Via address.
But it should detect the private IP address in the contact header.
Maybe you have an exception, that NAT traversal is not triggered, if there is more than 1 Via header.
Klaus
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
On 07.01.2014 16:54, Brian Davis wrote:
The other interesting issue in this case is that the 192.xx.xxx.xxx address is not an RFC1918 address, but it is also not reachable from
I should have known that if it is an RFC1918 address, you would not have to mask it.
kamailio. That is why I hoped kamailio would trigger NAT traversal logic solely on the fact that the source and contact address are different.
Here is my very pragmatic approach for NAT traversal: Forget about nat_uac_test(). Just always force NAT traversal [1], as it does not harm if the users are not behind NAT. It may increase traffic on your media relay but reduces support calls from customers.
Probaly the elegant solutions would be to apply NAT traversal only for SIP and use SIP client with ICE support (and provide a turn relay).
regards Klaus
[1] use add_contact_alias(), handle_ruri_alias() and fix_nated_register(). Do not use fix_nated_contact(). Further, apply NAT traversal only if the clients are directly "connected" to your proxy (not if there are other devices inbetween).
On Tue, Jan 7, 2014 at 5:01 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
On 03.01.2014 16:59, Brian Davis wrote:REGISTER sip:test1.test.com:5060 <http://test1.test.com:5060> SIP/2.0 Via: SIP/2.0/UDP 96.xxx.xxx.xxx:33745;rport;branch=z9hG4bKf5s1p`n3TRv5TZx5RXy.RVv+JPz8Nat*UX!8KRx4SRx Via: SIP/2.0/UDP 192.xx.xxx.xxx:33745;branch=z9hG4bKeb263246c44095f072d8167dd0c7987a343134;rport Contact: "Joe" <sip:xxxyyyzzzz@192.xx.xxx.xxx:33745;transport=udp>Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>: 3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx <mailto:3b0400ca43e28f78f3e6dc945a084b88@192.xx.xxx.xxx>|log|source 96.xxx.xxx.xxx:33745Actually the source IP seem to be identical to the topmost Via address. But it should detect the private IP address in the contact header. Maybe you have an exception, that NAT traversal is not triggered, if there is more than 1 Via header. Klaus _______________________________________________ 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
-
Brian Davis -
Klaus Darilion