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
On 09/21/2010 11:12 AM, 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.
My objection is rooted in the fact that last time I had tried to use these functions (about 3 months ago), they still simply did not work. I had to use force_rtp_proxy() to achieve the desired effect.
I don't remember at the moment, offhand, exactly the respects in which they didn't work. But I've complained about it on the sr-users and Kamailio-users list a number of times, most notably in October or November 2009.
On 09/21/2010 11:23 AM, Alex Balashov wrote:
On 09/21/2010 11:12 AM, 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.
My objection is rooted in the fact that last time I had tried to use these functions (about 3 months ago), they still simply did not work. I had to use force_rtp_proxy() to achieve the desired effect.
I don't remember at the moment, offhand, exactly the respects in which they didn't work. But I've complained about it on the sr-users and Kamailio-users list a number of times, most notably in October or November 2009.
See this thread:
http://lists.sip-router.org/pipermail/sr-users/2009-October/024925.html
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
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.
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@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/
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@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/
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@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@kamailio.org CC: sr-users@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.
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@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@kamailio.org CC: sr-users@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.
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@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@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@kamailio.org CC: sr-users@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.
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@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@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@kamailio.org CC: sr-users@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.
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@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@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@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@kamailio.org CC: sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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@kamailio.org CC: sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/9/21 Ovidiu Sas osas@voipembedded.com:
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.
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@aliax.net wrote:
2010/9/21 Ovidiu Sas osas@voipembedded.com:
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@aliax.net
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
On Wed, Sep 22, 2010 at 3:42 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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)
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
-
Alex Balashov -
César Pinto Magán -
Daniel-Constantin Mierla -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Ovidiu Sas