[OpenSIPS-Users] fix_nated_sdp() not taking effect
Callum Guy
callum.guy at x-on.co.uk
Wed Nov 20 04:55:23 EST 2019
It should be acceptable to repeat rtpproxy_offer in the failure route -
perhaps there is an argument that you'd need to disengage the first session
before starting a new one but I don't recall doing that myself. Just to
clarify you are using the direction options to manage the bridge interfaces
used for each scenario?
i.e. rtpproxy_offer("rfie"), rtpproxy_offer("rfei"), rtpproxy_offer("rfee")
etc?
On Tue, 19 Nov 2019 at 13:54, Mark Farmer <farmorg at gmail.com> wrote:
> 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
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20191120/7eab3a26/attachment.html>
More information about the Users
mailing list