[OpenSIPS-Users] nortpproxy_str usage

[Bogdan-Andrei Iancu]

IF you do not want to chain, yes, just ignore that attribute.

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/15/2018 06:42 PM, William Simon wrote:
>
> 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 <bogdan at opensips.org>
> *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
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180116/4da56c7e/attachment.html>