[sr-dev] [SR-Users] rtpproxy (k): removal of force_rtpproxy
César Pinto Magán
Cesar.Pinto at a-e.es
Wed Sep 22 11:54:57 CEST 2010
Ok. Thanks for the link. It also comments other helpful switch "-f" that can help me also to make tests. :)
César Pinto (2439)
+34 91 787 23 00 alhambra-eidos.es
-----Mensaje original-----
De: sip.nslu at gmail.com [mailto:sip.nslu at gmail.com] En nombre de Ovidiu Sas
Enviado el: martes, 21 de septiembre de 2010 20:01
Para: Daniel-Constantin Mierla
CC: César Pinto Magán; sr-users at lists.sip-router.org; sr-dev
Asunto: Re: [SR-Users] [sr-dev] rtpproxy (k): removal of force_rtpproxy
Long time ago I did a brief description on how bridging can be
achieved. It was for openser but it is still valid:
http://www.mail-archive.com/users@openser.org/msg04806.html
Probably we should add this to the rtpproxy module documentation.
Regards,
Ovidiu Sas
On Tue, Sep 21, 2010 at 12:32 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
>
>
> On 9/21/10 6:23 PM, César Pinto Magán wrote:
>>
>> I mean for a more detailed functionality and capabilities.
>
> ok, understand. Probably we should open a wiki page for it. There are one or
> two configs (perhaps pretty old now) in nathelper module to show bridging
> mode.
>
> Cheers,
> Daniel
>
>> The bridge mode appears in
>> http://www.voip-info.org/wiki/view/SER+example+outboundproxy and it is
>> talked about in this list (I had to search deep int the list records to find
>> some about). It is supposed to be used in a multihomed site, but it doesn't
>> work very fine for me (I had to put explicitly the IPs to be used)
>>
>>
>>
>> César Pinto (2439)
>> +34 91 787 23 00 alhambra-eidos.es
>>
>>
>>
>> -----Mensaje original-----
>> De: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
>> Enviado el: martes, 21 de septiembre de 2010 18:03
>> Para: César Pinto Magán
>> CC: Alex Balashov; sr-users at lists.sip-router.org; sr-dev
>> Asunto: Re: [SR-Users] [sr-dev] rtpproxy (k): removal of force_rtpproxy
>>
>>
>> Hi Cesar,
>>
>> are you looking for rtpproxy protocol format or for a more detailed
>> functionality of rtpproxy capabilities (e.g., what means bridge mode)?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 9/21/10 5:52 PM, César Pinto Magán wrote:
>>>
>>> Hello,
>>> I'm actually using rtpproxy_offer/answer(), and it works fine for us. I
>>> had to move from force_rtp_rpoxy() because it had several rare behaviors and
>>> the use of the offer/answer model solved them. It is very simple to
>>> implement.
>>>
>>> By the way, is there any type of documentation about rtpproxy and their
>>> commands (i.e. how works the bridge/switch mode of the rtp). The rtpproxy
>>> wiki says nothing about it.
>>>
>>>
>>> César Pinto (2439)
>>> +34 91 787 23 00 alhambra-eidos.es
>>>
>>>
>>>
>>> -----Mensaje original-----
>>> De: sr-users-bounces at lists.sip-router.org
>>> [mailto:sr-users-bounces at lists.sip-router.org] En nombre de Alex Balashov
>>> Enviado el: martes, 21 de septiembre de 2010 17:32
>>> Para: daniel at kamailio.org
>>> CC: sr-users at lists.sip-router.org; sr-dev
>>> Asunto: Re: [SR-Users] [sr-dev] rtpproxy (k): removal of force_rtpproxy
>>>
>>> On 09/21/2010 11:27 AM, Daniel-Constantin Mierla wrote:
>>>
>>>> personally I haven't tested much those functions. Maybe is better for
>>>> now to mark it obsolete and add a warning message at startup (via
>>>> fixup), then remove it with next release, allowing some maturity tests
>>>> for new ones. I am saying that also because most of existing configs
>>>> out there are using this function and new people will look for it.
>>>
>>> I agree.
>>>
>>> All of our configs use force_rtp_proxy(), but I would be happy to
>>> migrate them; however, I need some reasonable assurance that
>>> rtpproxy_offer/answer() will actually work.
>>>
>>> As can be seen from a number of previous threads on the list, I had to
>>> call force_rtp_proxy() to get several common scenarios to work, even
>>> though supposedly rtpproxy_offer/answer() are just wrappers (the code
>>> would suggest that), and even though the 'nathelper' documentation
>>> says that supposedly they will accept and use the same flags as those
>>> listed for force_rtp_proxy() the same way. It has not been true in my
>>> experience.
>>>
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
More information about the sr-dev
mailing list