Thanks Bogdan-Andrei. If I don't intend to chain multiple RTPProxy, is there 
any reason to keep the nortpproxy_str attribute, or is it safe to disable it by 
setting it to empty string?

________________________________
From: Bogdan-Andrei Iancu <[email protected]>
Sent: Monday, January 15, 2018 11:08:41 AM
To: OpenSIPS users mailling list; William Simon
Subject: Re: [OpenSIPS-Users] nortpproxy_str usage

Hi William,

IF you end up chaining multiple RTPproxy'es, you need to be sure you avoid the 
"learning" deadlock between them - as rtpproxy is normally waiting to receive 
RTP in order to learn the end-points IP+port (as the IP coordinates from SDP 
are private, so not usable). So, if the IP in the received SDP in public, use 
the "r" flag when triggering rtpproxy (not to wait, but to trust the IP+port in 
SDP) - see 
http://www.opensips.org/html/docs/modules/2.3.x/rtpproxy.html#idp5556688

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam


On 01/12/2018 08:48 PM, William Simon wrote:
I have a provider that is reflecting the a=nortpproxy:yes attribute back to me 
in the SDP of its reply. I know it's being reflected back because when I 
customize that header using the nortpproxy_str setting, I get my own value back 
in the provider's replies.

The result is that the answer side of rtpproxy isn't engaged and there's no 
audio.

>From an old thread 
>(http://lists.opensips.org/pipermail/users/2012-November/023444.html) it seems 
>like the best option for me is to simply disable this a=nortpproxy:yes 
>attribute and let the opensips logic engage rtpproxy all the time.

What kind of negative side effects would I face by disabling this and letting 
rtpproxy engage every time? Is this flag only really useful when you are 
working with a hierarchy of SIP proxies in your own environment? My topology 
has two equal-priority equal-weight opensips proxies that serve as clustered 
load balancer as well as outbound-proxy for internal freeswitch servers.

Thanks
W Simon


“The information transmitted is intended only for the person or entity to which 
it is addressed and may contain proprietary, business-confidential and/or 
privileged material. If you are not the intended recipient of this message you 
are hereby notified that any use, review, retransmission, dissemination, 
distribution, reproduction or any action taken in reliance upon this message is 
prohibited. If you received this in error, please contact the sender and delete 
the material from any computer.”


_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




“The information transmitted is intended only for the person or entity to which 
it is addressed and may contain proprietary, business-confidential and/or 
privileged material. If you are not the intended recipient of this message you 
are hereby notified that any use, review, retransmission, dissemination, 
distribution, reproduction or any action taken in reliance upon this message is 
prohibited. If you received this in error, please contact the sender and delete 
the material from any computer.”
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to