rtpproxy (k): removal of force_rtpproxy
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. -- 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 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 -- 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, 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. -- 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/
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/
-- Daniel-Constantin Mierla http://www.asipto.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. -- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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.
-- Daniel-Constantin Mierla http://www.asipto.com
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
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. -- Iñaki Baz Castillo <ibc@aliax.net>
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
participants (7)
-
Alex Balashov -
César Pinto Magán -
Daniel-Constantin Mierla -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Ovidiu Sas