[Users] nathelper and flag 2

[Andreas Granig]

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 at 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.