21 Sep
2010
21 Sep
'10
6:12 p.m.
Hello all,
I would like to propose the removal of force_rtp_proxy function from
the rtpproxy (k) module.
Instead, the rtpproxy_offer/rtpproxy_answer should be used.
Why?
- force_rtp_proxy no longer support 200ok/ACK SDP negotiation ('s'
flag was deprecated);
- all functionality of force_rtp_proxy is provided by
rtpproxy_offer/rtpproxy_answer;
- rtpproxy_offer/rtpproxy_answer is easier to use in the config.
Objections?
Regards,
Ovidiu Sas
21 Sep
21 Sep
6:27 p.m.
Hello,
On 9/21/10 5:12 PM, Ovidiu Sas wrote:
Hello all,
I would like to propose the removal of force_rtp_proxy function from
the rtpproxy (k) module.
Instead, the rtpproxy_offer/rtpproxy_answer should be used.
Why?
- force_rtp_proxy no longer support 200ok/ACK SDP negotiation ('s'
flag was deprecated);
- all functionality of force_rtp_proxy is provided by
rtpproxy_offer/rtpproxy_answer;
- rtpproxy_offer/rtpproxy_answer is easier to use in the config.
Objections?
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.
Cheers,
Daniel
6:32 p.m.
New subject: [SR-Users] 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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
6:42 p.m.
New subject: [SR-Users] rtpproxy (k): removal of force_rtpproxy
force_rtp_proxy does not handle properly 200ok/ACK renegotiation (the
s flag is obsolete).
I am using offer/answer (the new rtpproxy module) in bridging mode
without any issues.
Migrating from force_rtp_proxy to offer/answer model is quite straight forward.
Maintaing both force rtp and ofer/answer is just extra work load
(given the fact that both are just wrappers around a single function).
I would go for a clean layout ... but ... Vox Populi, Vox Dei :)
Regards,
Ovidiu Sas
On Tue, Sep 21, 2010 at 11:32 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
6:53 p.m.
New subject: [SR-Users] rtpproxy (k): removal of force_rtpproxy
On 9/21/10 5:42 PM, Ovidiu Sas wrote:
force_rtp_proxy does not handle properly 200ok/ACK
renegotiation (the
s flag is obsolete).
I am using offer/answer (the new rtpproxy module) in bridging mode
without any issues.
Migrating from force_rtp_proxy to offer/answer model is quite straight forward.
Maintaing both force rtp and ofer/answer is just extra work load
(given the fact that both are just wrappers around a single function).
I would go for a clean layout ... but ... Vox Populi, Vox Dei :)
Good to know that
you tested and you are probably right regarding the code.
There won't be more load if we remove with next version -- as now we are
in testing phase, once 3.1 is released, we can drop it from master branch.
I will look over it and push it with default config in 3.1 -- somehow I
missed the fact that 's' was deprecated, because I never used it :-)
Cheers,
Daniel
Regards,
Ovidiu Sas
On Tue, Sep 21, 2010 at 11:32 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
> 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.
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 1170 Peachtree Street
> 12th Floor, Suite 1200
> Atlanta, GA 30309
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> Web: http://www.evaristesys.com/
>
--
Daniel-Constantin Mierla
http://www.asipto.com
6:52 p.m.
New subject: [SR-Users] rtpproxy (k): removal of force_rtpproxy
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(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
En nombre de Alex Balashov
Enviado el: martes, 21 de septiembre de 2010 17:32
Para: daniel(a)kamailio.org
CC: sr-users(a)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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:02 p.m.
New subject: [SR-Users] 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(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
En nombre de Alex Balashov
Enviado el: martes, 21 de septiembre de 2010 17:32
Para: daniel(a)kamailio.org
CC: sr-users(a)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:
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
7:23 p.m.
New subject: [SR-Users] rtpproxy (k): removal of force_rtpproxy
I mean for a more detailed functionality and capabilities. 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@gmail.com]
Enviado el: martes, 21 de septiembre de 2010 18:03
Para: César Pinto Magán
CC: Alex Balashov; sr-users(a)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(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
En nombre de Alex Balashov
Enviado el: martes, 21 de septiembre de 2010 17:32
Para: daniel(a)kamailio.org
CC: sr-users(a)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:
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
7:32 p.m.
New subject: [SR-Users] rtpproxy (k): removal of force_rtpproxy
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@gmail.com]
Enviado el: martes, 21 de septiembre de 2010 18:03
Para: César Pinto Magán
CC: Alex Balashov; sr-users(a)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(a)lists.sip-router.org
[mailto:sr-users-bounces@lists.sip-router.org] En nombre de Alex Balashov
> Enviado el: martes, 21 de septiembre de 2010 17:32
> Para: daniel(a)kamailio.org
> CC: sr-users(a)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
9:01 p.m.
New subject: [SR-Users] 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(a)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@gmail.com]
Enviado el: martes, 21 de septiembre de 2010 18:03
Para: César Pinto Magán
CC: Alex Balashov; sr-users(a)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(a)lists.sip-router.org
> [mailto:sr-users-bounces@lists.sip-router.org] En nombre de Alex Balashov
> Enviado el: martes, 21 de septiembre de 2010 17:32
> Para: daniel(a)kamailio.org
> CC: sr-users(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
22 Sep
22 Sep
12:54 p.m.
New subject: [SR-Users] rtpproxy (k): removal of force_rtpproxy
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(a)gmail.com [mailto:sip.nslu@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(a)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(a)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@gmail.com]
Enviado el: martes, 21 de septiembre de 2010 18:03
Para: César Pinto Magán
CC: Alex Balashov; sr-users(a)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(a)lists.sip-router.org
> [mailto:sr-users-bounces@lists.sip-router.org] En nombre de Alex Balashov
> Enviado el: martes, 21 de septiembre de 2010 17:32
> Para: daniel(a)kamailio.org
> CC: sr-users(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:16 a.m.
2010/9/21 Ovidiu Sas <osas(a)voipembedded.com>om>:
Why?
- force_rtp_proxy no longer support 200ok/ACK SDP negotiation ('s'
flag was deprecated);
Hi, in case of "200/ACK SDP" rtpproxy_offer should be called in the
183/200 and rtpproxy_answer in the ACK, and for that the existance of
a SDP body should be inspected in the initial INVITE, am I right? or
is there a more user-friendly way to achieve this case?
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:09 a.m.
There is no other more user friendly procedure for the 200ok/ACK SDP
negotiation.
The existence of SDP in the initial INVITE must be checked.
Regards,
Ovidiu Sas
On Tue, Sep 21, 2010 at 8:16 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/9/21 Ovidiu Sas <osas(a)voipembedded.com>om>:
Why?
- force_rtp_proxy no longer support 200ok/ACK SDP negotiation ('s'
flag was deprecated);
Hi, in case of "200/ACK SDP" rtpproxy_offer should be called in the
183/200 and rtpproxy_answer in the ACK, and for that the existance of
a SDP body should be inspected in the initial INVITE, am I right? or
is there a more user-friendly way to achieve this case?
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:42 a.m.
Am 21.09.2010 17:12, schrieb Ovidiu Sas:
Hello all,
I would like to propose the removal of force_rtp_proxy function from
the rtpproxy (k) module.
Instead, the rtpproxy_offer/rtpproxy_answer should be used.
Why?
- force_rtp_proxy no longer support 200ok/ACK SDP negotiation ('s'
flag was deprecated);
- all functionality of force_rtp_proxy is provided by
rtpproxy_offer/rtpproxy_answer;
- rtpproxy_offer/rtpproxy_answer is easier to use in the config.
Objections?
I would prefer to keep force_rtp_proxy and make it detect
late-offer-answer automatically. So just calling force_rtp_proxy() on
INVITE, 200 and ACK and it should work in all cases. (just like mediaproxy)
regards
klaus
7:05 p.m.
On Wed, Sep 22, 2010 at 3:42 AM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
Am 21.09.2010 17:12, schrieb Ovidiu Sas:
What you propose is a new functionality. I would prefer a new name
(engage_rtp_proxy) for this function and still drop the old
force_rtp_proxy.
Regards,
Ovidiu Sas
Hello all,
I would like to propose the removal of force_rtp_proxy function from
the rtpproxy (k) module.
Instead, the rtpproxy_offer/rtpproxy_answer should be used.
Why?
- force_rtp_proxy no longer support 200ok/ACK SDP negotiation ('s'
flag was deprecated);
- all functionality of force_rtp_proxy is provided by
rtpproxy_offer/rtpproxy_answer;
- rtpproxy_offer/rtpproxy_answer is easier to use in the config.
Objections?
I would prefer to keep force_rtp_proxy and make it detect late-offer-answer
automatically. So just calling force_rtp_proxy() on INVITE, 200 and ACK and
it should work in all cases. (just like mediaproxy)
5175
days inactive
5176
days old
14 comments
7 participants
participants (7)
-
Alex Balashov -
César Pinto Magán -
Daniel-Constantin Mierla -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Ovidiu Sas