[OpenSIPS-Users] fix_nated_sdp() not taking effect
Mark Farmer
farmorg at gmail.com
Wed Nov 20 09:20:49 EST 2019
As I suspected and as indicated by Răzvan, calling rtpproxy_offer() a
second time in the failure route breaks the SDP (XXX.XXX.XXX.XXX is the
public IP)
o=- 1574259046 1574259046 IN IP4 XXX.XXX.XXX.XXX10.150.50.51
s=Polycom IP Phone
c=IN IP4 XXX.XXX.XXX.XXX10.150.50.51
I am making progress, my rtpproxy_offer/answer now seems to be working as
expected but now I have an issue in that because rtpproxy was never engaged
in the initial INVITE, RTPproxy is now trying to send audio to the private
ip of the original phone.
Is there something in particular that I need to do with a 603 reply to
handle the audio path establishment?
Many thanks for all input on this!
Mark.
On Wed, 20 Nov 2019 at 09:58, Callum Guy <callum.guy at x-on.co.uk> wrote:
> 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.
>
> _______________________________________________
> 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/20191120/73f94635/attachment-0001.html>
More information about the Users
mailing list