Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Probably not solving your problem but this is my newest pragmatic aproach:
A client should support symmetric SIP. Thus, I use force_rport for all local clients. As usually also all SIP proxies are symmetric I also do force_port for requests from external nodes.
For REGISTER I do not trust the information in the Contact header at all - I always use fix_nated_register. Further, I always use fix_nated_contact for local SIP users - thus for SIP NAT traversal I do not need any tests.
Regarding RTP NAT traversal - if you want to save bandwidth on your RTP proxy - of course you still need a nat-test.
regards klaus
On Tue, February 13, 2007 17:36, Andreas Granig said:
Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
I have nearly the same approach. Problem is, that I have to do fix_nated_sdp if the client is nated to pass the right media IP to mediaproxy-dispatcher. In this special case, SIP came from 1.2.3.4 and RTP from 1.2.3.5 (announced in SDP), but since NAT was detected, it was "fixed" to 1.2.3.4 by fix_nated_sdp, so my RTP-Proxy silently dropped packets from 1.2.3.5.
If RTP and SIP both always come from the same IP, this problem may remain undetected, but here it popped up due to the different IP addresses.
Andreas
Klaus Darilion wrote:
Probably not solving your problem but this is my newest pragmatic aproach:
A client should support symmetric SIP. Thus, I use force_rport for all local clients. As usually also all SIP proxies are symmetric I also do force_port for requests from external nodes.
For REGISTER I do not trust the information in the Contact header at all - I always use fix_nated_register. Further, I always use fix_nated_contact for local SIP users - thus for SIP NAT traversal I do not need any tests.
Regarding RTP NAT traversal - if you want to save bandwidth on your RTP proxy - of course you still need a nat-test.
regards klaus
On Tue, February 13, 2007 17:36, Andreas Granig said:
Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
You could also change the rtp proxy to allow signing in also from other IP addresses but of course this weakens security.
regards klaus
On Tue, February 13, 2007 17:58, Andreas Granig said:
Hi Klaus,
I have nearly the same approach. Problem is, that I have to do fix_nated_sdp if the client is nated to pass the right media IP to mediaproxy-dispatcher. In this special case, SIP came from 1.2.3.4 and RTP from 1.2.3.5 (announced in SDP), but since NAT was detected, it was "fixed" to 1.2.3.4 by fix_nated_sdp, so my RTP-Proxy silently dropped packets from 1.2.3.5.
If RTP and SIP both always come from the same IP, this problem may remain undetected, but here it popped up due to the different IP addresses.
Andreas
Klaus Darilion wrote:
Probably not solving your problem but this is my newest pragmatic aproach:
A client should support symmetric SIP. Thus, I use force_rport for all local clients. As usually also all SIP proxies are symmetric I also do force_port for requests from external nodes.
For REGISTER I do not trust the information in the Contact header at all
I always use fix_nated_register. Further, I always use fix_nated_contact for local SIP users - thus for SIP NAT traversal I do not need any tests.
Regarding RTP NAT traversal - if you want to save bandwidth on your RTP proxy - of course you still need a nat-test.
regards klaus
On Tue, February 13, 2007 17:36, Andreas Granig said:
Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Klaus Darilion wrote:
You could also change the rtp proxy to allow signing in also from other IP addresses but of course this weakens security.
That's not exactly what I want :o)
So, would it make sense to extend the received_test() in msg_translator.c to also take into account an maddr parameter?
Andreas
Hi Andreas,
I guess this will be the most reasonable solution.
Regards, bogdan
Andreas Granig wrote:
Klaus Darilion wrote:
You could also change the rtp proxy to allow signing in also from other IP addresses but of course this weakens security.
That's not exactly what I want :o)
So, would it make sense to extend the received_test() in msg_translator.c to also take into account an maddr parameter?
Andreas
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Klaus,
Another, not directly related question:
If you have a nated UAC, RTP-Proxies usually wait for packets arriving on each call leg before bridging them together. Now if you have a peering with another provider which has the same setup using i-enum and peering policies, you are stuck because both RTP-Proxies wait for packets to arrive from the peering-leg. How would you handle that? Is there an option in the peering policies, which negotiates which provider's RTP-proxy is going to be used?
Andreas
Klaus Darilion wrote:
Probably not solving your problem but this is my newest pragmatic aproach:
A client should support symmetric SIP. Thus, I use force_rport for all local clients. As usually also all SIP proxies are symmetric I also do force_port for requests from external nodes.
For REGISTER I do not trust the information in the Contact header at all - I always use fix_nated_register. Further, I always use fix_nated_contact for local SIP users - thus for SIP NAT traversal I do not need any tests.
Regarding RTP NAT traversal - if you want to save bandwidth on your RTP proxy - of course you still need a nat-test.
regards klaus
On Tue, February 13, 2007 17:36, Andreas Granig said:
Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Andreas Granig wrote:
Klaus,
Another, not directly related question:
If you have a nated UAC, RTP-Proxies usually wait for packets arriving on each call leg before bridging them together. Now if you have a peering with another provider which has the same setup using i-enum and peering policies, you are stuck because both RTP-Proxies wait for packets to arrive from the peering-leg. How would you handle that? Is there an option in the peering policies, which negotiates which provider's RTP-proxy is going to be used?
The RTP proxy should wait for packets from both destinations. It should forward immediately to the socket announced in the SDP and fall back to the socket from which it received the packet. If the both RTP proxies have a public IP then the socket in the SDP can be reached directly.
I think rtpproxy will forward to the IP:port in the SDP and then fall back to the IP:port a packet is received from if this is different.
I do not know how mediaproxy handles this.
In a "strict" peering environment you do not want your rtp proxy to change the destination if someone sends you an RTP packet from any destiantion. Thus you will tell the rtp proxy to by symmetric on one side and to use the SDP on the other side. (like the "r" flag http://www.openser.org/docs/modules/1.1.x/nathelper#AEN275)
regards klaus
Andreas
Klaus Darilion wrote:
Probably not solving your problem but this is my newest pragmatic aproach:
A client should support symmetric SIP. Thus, I use force_rport for all local clients. As usually also all SIP proxies are symmetric I also do force_port for requests from external nodes.
For REGISTER I do not trust the information in the Contact header at all - I always use fix_nated_register. Further, I always use fix_nated_contact for local SIP users - thus for SIP NAT traversal I do not need any tests.
Regarding RTP NAT traversal - if you want to save bandwidth on your RTP proxy - of course you still need a nat-test.
regards klaus
On Tue, February 13, 2007 17:36, Andreas Granig said:
Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Oh, ok, my RTP-Proxies do just this, so it would work anyways (and that's also the behaviour which is necessary for some T.38 implementations).
I was just thinking about this situation and thought that there could be an issue. False alarm :o)
Andreas
Klaus Darilion wrote:
Andreas Granig wrote:
Klaus,
Another, not directly related question:
If you have a nated UAC, RTP-Proxies usually wait for packets arriving on each call leg before bridging them together. Now if you have a peering with another provider which has the same setup using i-enum and peering policies, you are stuck because both RTP-Proxies wait for packets to arrive from the peering-leg. How would you handle that? Is there an option in the peering policies, which negotiates which provider's RTP-proxy is going to be used?
The RTP proxy should wait for packets from both destinations. It should forward immediately to the socket announced in the SDP and fall back to the socket from which it received the packet. If the both RTP proxies have a public IP then the socket in the SDP can be reached directly.
I think rtpproxy will forward to the IP:port in the SDP and then fall back to the IP:port a packet is received from if this is different.
I do not know how mediaproxy handles this.
In a "strict" peering environment you do not want your rtp proxy to change the destination if someone sends you an RTP packet from any destiantion. Thus you will tell the rtp proxy to by symmetric on one side and to use the SDP on the other side. (like the "r" flag http://www.openser.org/docs/modules/1.1.x/nathelper#AEN275)
regards klaus
Andreas
Klaus Darilion wrote:
Probably not solving your problem but this is my newest pragmatic aproach:
A client should support symmetric SIP. Thus, I use force_rport for all local clients. As usually also all SIP proxies are symmetric I also do force_port for requests from external nodes.
For REGISTER I do not trust the information in the Contact header at all - I always use fix_nated_register. Further, I always use fix_nated_contact for local SIP users - thus for SIP NAT traversal I do not need any tests.
Regarding RTP NAT traversal - if you want to save bandwidth on your RTP proxy - of course you still need a nat-test.
regards klaus
On Tue, February 13, 2007 17:36, Andreas Granig said:
Hi,
Today I found a UAC which is *not* located behind NAT (public IP 1.2.3.4) and sends this Via-Header, which seems perfectly valid according to RFC3261:
SIP/2.0/UDP VINNASUP06C:5060;maddr=1.2.3.4;branch=z9hG4bK-2198d2
I used to check for nated clients using nat_uac_test("3"), which detects NAT in this case, because the host-part doesn't match the received-address. So is the test-flag "2" useless, since the host-part can be "hostname / IPv4address / IPv6reference", or should this particular test be extended to also check for the maddr-parameter?
In the meanwhile, I've changed my nat-test to "17" for only testing Contact and Via-Port instead of Contact and Via-Address, but it's still not optimal.
Any opinions on this?
Andreas
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation.
-
Andreas Granig -
Bogdan-Andrei Iancu -
Klaus Darilion