[OpenSIPS-Users] fix_nated_sdp() not taking effect
Mark Farmer
farmorg at gmail.com
Tue Nov 19 08:53:15 EST 2019
I have been using bridged mode all along.
I've flipped over to RTPproxy for now, this is my interface configuration,
10.147 being the NATed subnet & 10.150 being the internal subnet:
-l 10.150.50.51/10.147.52.52 -A 10.150.50.51/XXX.XXX.XXX.XXX <-- PUBLIC IP
I think I understand offer/answer params but calling rtpproxy_offer() in
both the initial routing and again in the failure route breaks the SDP
which I believe is expected.
If I don't call rtpproxy_offer for the initial INVITE then the SDP is
broken for that leg.
Clearly I'm missing something somewhere...
On Tue, 19 Nov 2019 at 13:28, Callum Guy <callum.guy at x-on.co.uk> wrote:
> You might want to read up on bridge mode, it allows you to meet the finely
> control which interface is presented during the SDP rewrites.
>
> All of the information on the various use cases is available in the module
> docs, I've used both successfully including some pretty complex request
> routing.
>
> The move to offer/answer with interface specifications works great, you'll
> just have to fire off the offer with different params when in the failure
> route so it will override your initial public/public selection from the
> initial invite processing
>
> On Tue, 19 Nov 2019, 12:27 Mark Farmer, <farmorg at gmail.com> wrote:
>
>> Hi Răzvan
>>
>> My OpenSIPS/RTPProxy box has 2 interfaces, public(NAT) - for phones &
>> internal - for Asterisk.
>> The issue is that if a call from one registered user to another is
>> rejected & goes to failure_route() then I send the call to an Asterisk box
>> for voicemail which is connected via the internal interface.
>>
>> When the call is routed to Asterisk, I need the RTP to flow between
>> RTPproxy & Asterisk on the internal interfaces so I need to have the SDP
>> correct before it hits Asterisk. RTP to & from the phone needs to use the
>> public interface.
>>
>> Initial media flow:
>> phone<-->OpenSIPS/RTPproxy<-->phone
>>
>> Voicemail media flow:
>> phone<-->OpenSIPS/RTPproxy<-->Asterisk
>>
>> What is the best way to achieve this?
>>
>> Many thanks!
>> Mark.
>>
>>
>> On Mon, 18 Nov 2019 at 12:50, Răzvan Crainea <razvan at opensips.org> wrote:
>>
>>> Yes, the problem is definitely the fact that you are calling
>>> `rtpproxy_offer()` for the initial invite. Hence, when you run
>>> `fix_nated_sdp()`, you're trying to change the same IP once again - this
>>> is not possile in OpenSIPS.
>>> But I wonder why you need the `fix_nated_sdp()` if you are using
>>> RTPProxy. Can't you just use the `ip_address`[1] field to advertise the
>>> proper IP int he c= line.
>>>
>>> [1]
>>>
>>> https://opensips.org/html/docs/modules/3.0.x/rtpproxy.html#func_rtpproxy_offer
>>>
>>> Best regards,
>>> Răzvan
>>>
>>> On 11/13/19 1:51 PM, Mark Farmer wrote:
>>> > Hi everyone
>>> >
>>> > In my failure_route I'm routing to an Asterisk box for voicemail & I
>>> > need to change the SDP c/o parameters to use the correct internal IP
>>> > address but using fix_nated_sdp() is not taking effect.
>>> >
>>> > if (t_check_status("486|408|603")) {
>>> > xlog("CUSTOM_LOG: User replied $T_reply_code -
>>> Routing
>>> > to Asterisk Voicemail service.");
>>> > prefix("VMR_");
>>> > rewritehostport("10.150.50.53:2404
>>> > <http://10.150.50.53:2404>");
>>> > force_send_socket(udp:10.150.50.51);
>>> > fix_nated_sdp(10,"10.150.50.51");
>>> >
>>> > if (!t_relay()) {
>>> > send_reply(500,"Internal Error");
>>> > }
>>> > exit;
>>> > }
>>> >
>>> > I get the CUSTOM_LOG entry so I know that the route is executing.
>>> >
>>> > Maybe I'm doing something wrong with the flags, I've tried:
>>> > fix_nated_sdp(2,"10.150.50.51");
>>> > fix_nated_sdp(8,"10.150.50.51");
>>> > fix_nated_sdp(10,"10.150.50.51");
>>> >
>>> > But when I examine the SDP in the resulting invite, the c/o parameters
>>> > are never changed.
>>> > I'm using rtpengine_offer/answer in the initial routing, could it be
>>> > related to that?
>>> >
>>> > I'm using OpenSIPS 3.0.1
>>> >
>>> > Best regards
>>> > Mark.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users at lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >
>>>
>>> --
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>> Mark Farmer
>> farmorg at gmail.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | **
> <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel>
> <https://twitter.com/xonuk> *
>
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient, please notify
> X-on immediately on +44(0)333 332 0000 and delete the
> message from your computer. If you are not a named addressee you must not
> use, disclose, disseminate, distribute, copy, print or reply to this email. Views
> or opinions expressed by an individual
> within this email may not necessarily reflect the views of X-on or its
> associated companies. Although X-on routinely screens for viruses,
> addressees should scan this email and any attachments
> for viruses. X-on makes no representation or warranty as to the absence of
> viruses in this email or any attachments.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Mark Farmer
farmorg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20191119/83b67f90/attachment.html>
More information about the Users
mailing list