[OpenSIPS-Users] OpenSIPS/RTpProxy BridgeMode after failure route

Thu Oct 9 07:36:51 CEST 2014

Hi Ali,

As per your logs connection and owner SDP strings are written twice, which
shows rtpproxy was called twice in result it concatenated multiple IP
addresses in SDP.

I would look in to the following:

1) try unforce in the main route just before new rtpproxy_offer("rocie")
function call (instead of failure route). Can be easily done logically.
2) Check version of RTPproxy, if it complies with the rtpproxy devel module
documentation.
3) The similar scenario can also be achieved by handling rtpproxy per
branch, but it is slightly off the topic.
4) Assuming you are handling Offer/Answer approach correctly for media.

Best Regards

Salman
VoIP Professional

On Thu, Oct 9, 2014 at 2:06 AM, Ali Pey <alipey at gmail.com> wrote:

> Hello Salman,
>
> Can you please elaborate on how you got this working? I have the same
> problem and can't get it to work.
>
> In failure route, I do:
> unforce_rtp_proxy()
> Then when I have a new destination, I do:
> rtpproxy_offer("rocie");
>
> However, I end up with messed up SDP, in my second invite. It doesn't
> remove the old IP addresses and only adds the IP addresses again:
> o=Sonus_UAC 9216 20203 IN IP4 10.160.11.16210.160.11.162a Capabilities
> c=IN IP4 10.160.11.16210.160.11.162udio 2311822970AVP 0 8 100
>
>
> Please let me know how I can fix this.
>
> Thanks.
>
>
> On Mon, Jan 6, 2014 at 10:26 AM, Salman Zafar <msalman212 at gmail.com>
> wrote:
>
>> Hi Razvan,
>>         I got it working without branching, after banging head a lot I
>> got to learn unforcing drops the media ports for previous rtpproxy
>> offer/answer and after that directing the new flow though rtpproxy flags,IP
>> media works. I am able to traverse from eternal to internal play media and
>> then on failure do external to external with media flowing between public
>> interfaces. Just wondering if you know this method or certify.
>>
>>
>>
>> On Mon, Jan 6, 2014 at 4:35 PM, Răzvan Crainea <razvan at opensips.org>
>> wrote:
>>
>>> Hi, Salman!
>>>
>>> The sockets used by RTPProxy are created when the session is started
>>> (the first offer) and cannot be updated afterwards. Therefore the only
>>> solution I can see is to configure a per branch scenario, as you mentioned.
>>>
>>> Best regards,
>>>
>>> Razvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>> <https://contactmonkey.com/api/v1/tracker?cm_session=66f49ebf-f052-47c3-adee-bf8dd17afa5d&cm_type=link&cm_link=c1574c01-908b-4910-aaff-83f9f8f63efd&cm_destination=http://www.opensips-solutions.com>
>>>
>>>
>>> On 12/30/2013 01:11 PM, Salman Zafar wrote:
>>>
>>>> Hi,
>>>>     I have a scenario of playing media at a private-ip media server and
>>>> send BUSY, next in failure route bridge call to a public IP. (SIP to
>>>> SIP).
>>>>
>>>> So the scenario is as follows:
>>>>
>>>> UA(Phone1) -> OpenSIPS/RTpProxy(ei) -> Media-Server (Private IP) -> BUSY
>>>> -> OpenSIPS(failure route) -> RTpProxy(ee) -> lookup -> (UA Phone2)
>>>>
>>>> Now the problem is RtpProxy is being offered (EI flags) in first case
>>>> where routing to Media sever at private IP, after failure it is again
>>>> used with (EE flags), also in corresponding replies.
>>>>
>>>> The second time RTpProxy does not effect SDP c= and ports in a way to
>>>> build media communication. SDP fix directly does not effect rtp ports.
>>>>
>>>> Is there any way of using RtpProxy differently in fail-over, or I have
>>>> to go for rtpproxy per branch?.
>>>>
>>>>
>>>> Thanks in advance.
>>>>
>>>> --
>>>> Regards
>>>>
>>>> Salman
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>>
>>>> <https://contactmonkey.com/api/v1/tracker?cm_session=66f49ebf-f052-47c3-adee-bf8dd17afa5d&cm_type=link&cm_link=93f81bb0-9371-45ae-8414-6b50270f9815&cm_destination=http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>> http://lists.opensips.org/cgi-
>>>> <https://contactmonkey.com/api/v1/tracker?cm_session=66f49ebf-f052-47c3-adee-bf8dd17afa5d&cm_type=link&cm_link=0138242a-38a8-4160-8e04-9e778d8a3ff2&cm_destination=http://lists.opensips.org/cgi->
>>>> bin/mailman/listinfo/users
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>>
>>> <https://contactmonkey.com/api/v1/tracker?cm_session=66f49ebf-f052-47c3-adee-bf8dd17afa5d&cm_type=link&cm_link=c6cc3f04-ad93-4c1d-a2e3-36d16616e13d&cm_destination=http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>> http://lists.opensips.org/cgi-
>>> <https://contactmonkey.com/api/v1/tracker?cm_session=66f49ebf-f052-47c3-adee-bf8dd17afa5d&cm_type=link&cm_link=39ab01b6-8245-48af-9ab5-ed7494a6765b&cm_destination=http://lists.opensips.org/cgi->
>>> bin/mailman/listinfo/users
>>>
>>
>>
>>
>> --
>> Regards
>>
>> M. Salman Zafar
>>
>> VoIP Professional
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <https://contactmonkey.com/api/v1/tracker?cm_session=66f49ebf-f052-47c3-adee-bf8dd17afa5d&cm_type=link&cm_link=8efee758-5809-4052-89d5-9190de57c58c&cm_destination=http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>

-- 
Regards

M. Salman Zafar
VoIP Professional
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20141009/941217ed/attachment.htm>