[Users] nathelper and flag 2

[Andreas Granig]

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


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.