3 Jan
2014
3 Jan
'14
3:59 p.m.
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(a)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(a)192.xx.xxx.xxxkamailio.log
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)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(a)192.xx.xxx.xxx|log|source
96.xxx.xxx.xxx:33745
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|from
sip:xxxyyyzzzz@test1.test.com
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|to
sip:xxxyyyzzzz@test1.test.com
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|originated from
external sources
Dec 30 03:33:45 sip-01 kamailio[20489]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)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(a)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(a)192.xx.xxx.xxx|log|source
96.xxx.xxx.xxx:33745
Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|from
sip:xxxyyyzzzz@test1.test.com
Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|to
sip:xxxyyyzzzz@test1.test.com
Dec 30 03:33:45 sip-01 kamailio[20495]: INFO: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|originated from
external sources
Dec 30 03:33:45 sip-01 kamailio[20495]: DEBUG: <script>:
3b0400ca43e28f78f3e6dc945a084b88(a)192.xx.xxx.xxx|log|authenticated
xxxyyyzzzz(a)test1.test.com via cached SIP creds
7 Jan
7 Jan
10:01 a.m.
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(a)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
3:54 p.m.
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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8 Jan
8 Jan
10:53 a.m.
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(a)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(a)192.xx.xxx.xxx
<mailto: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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4029
days inactive
4034
days old
3 comments
2 participants
participants (2)
-
Brian Davis -
Klaus Darilion