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(a)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.