Hi,
Trying to use early media with prack support and rtpengine without success. INVITE(no SDP)--> 183(SDP)<-- PRACK(SDP)--> 200ok(no SDP)<-- ACK(no SDP)-->
Looking at the code it does not seem to allow for PRACK in the methods it supports.
In the rtpengine_manage code...
if (!(method==METHOD_INVITE || method==METHOD_ACK || method==METHOD_CANCEL || method==METHOD_BYE || method==METHOD_UPDATE)) return -1;
In the rtpengine_answer code...
rtpengine_answer1_f(struct sip_msg *msg, char *str1, char *str2) {
if (msg->first_line.type == SIP_REQUEST) if (msg->first_line.u.request.method_value != METHOD_ACK) return -1;
return rtpengine_rtpp_set_wrap_fparam(msg, rtpengine_answer_wrap, str1, 2, OP_ANSWER); }
Returns -1 no matter what function you use.
I have checked code all the way up to 5.3 and on the master.
I may be looking at this wrong and it is supported, but it doesn't look like it.
Could you please advise if this is a oversight or if there is a specific reason it is not included.
Thanks
Chris
Chris Martineau | Senior Telephony Engineer [vid] See how Semafone workshttps://www.semafone.com/our-solution/how-it-works/demo/ [b] Read our insightful bloghttps://semafone.com/media-centre/blog/ [p] Switchboard: 0845 543 0822 / Mobile: [e] Chris.Martineau@semafone.commailto:Chris.Martineau@semafone.com [w] Web: semafone.comhttps://semafone.com / Twitter: @semafonehttps://twitter.com/semafone / LinkedIn: Semafonehttps://uk.linkedin.com/company/semafone [a] SEMAFONE, Pannell House, Park Street, Guildford, Surrey GU1 4HN
[Semafone]https://www.semafone.com
Disclaimer
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom.
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cu...) .
Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
For information about how we process data and monitor communications please see our Privacy Policy (https://semafone.com/gb/privacy/)
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in both cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was part of a cascade of fixup functions that goes back to rtpengine_manage(), but not to _answer(). You're right of course.
On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla wrote:
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in both cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
I pushed a patch to rtpengine module to handle PRACK in both manage() and answer() functions.
Chris: can you test and see if works as expected? If yes, it will be backported.
Cheers, Daniel
On 04.05.20 19:51, Alex Balashov wrote:
Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was part of a cascade of fixup functions that goes back to rtpengine_manage(), but not to _answer(). You're right of course.
On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla wrote:
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in both cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Thanks Daniel,
Will test and advise.
Chris
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: 04 May 2020 19:09 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] PRACK support in RTPENGINE module?
I pushed a patch to rtpengine module to handle PRACK in both manage() and answer() functions.
Chris: can you test and see if works as expected? If yes, it will be backported.
Cheers, Daniel
On 04.05.20 19:51, Alex Balashov wrote:
Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was part of a cascade of fixup functions that goes back to rtpengine_manage(), but not to _answer(). You're right of course.
On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla wrote:
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in both cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/http://www.evaristesys.com, http://www.csrpswitch.com/http://www.csrpswitch.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/http://www.evaristesys.com/, http://www.csrpswitch.com/http://www.csrpswitch.com/
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Disclaimer
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom.
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cu...) .
Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
For information about how we process data and monitor communications please see our Privacy Policy (https://semafone.com/gb/privacy/)
Have you had the chance to do any testing? It will help deciding to push the commit to branch 5.3 for the release of 5.3.4.
Cheers, Daniel
On 05.05.20 09:55, Chris Martineau wrote:
Thanks Daniel,
Will test and advise.
Chris
*From:*sr-users sr-users-bounces@lists.kamailio.org *On Behalf Of *Daniel-Constantin Mierla *Sent:* 04 May 2020 19:09 *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] PRACK support in RTPENGINE module?
I pushed a patch to rtpengine module to handle PRACK in both manage() and answer() functions.
Chris: can you test and see if works as expected? If yes, it will be backported.
Cheers, Daniel
On 04.05.20 19:51, Alex Balashov wrote:
Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was part of a cascade of fixup functions that goes back to rtpengine_manage(), but not to _answer(). You're right of course.
On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla
wrote:
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in
both
cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should
support
PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since
RTPEngine
does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/ http://www.evaristesys.com,
http://www.csrpswitch.com/ http://www.csrpswitch.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com www.twitter.com/miconda http://www.twitter.com/miconda --
www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/ http://www.evaristesys.com/,
http://www.csrpswitch.com/ http://www.csrpswitch.com/
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
*Disclaimer*
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom. The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cu...) Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
Todays task, I had to port it into an earlier version for a legacy version test.
From: Daniel-Constantin Mierla miconda@gmail.com Sent: 06 May 2020 10:53 To: Chris Martineau Chris.Martineau@semafone.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] PRACK support in RTPENGINE module?
Have you had the chance to do any testing? It will help deciding to push the commit to branch 5.3 for the release of 5.3.4.
Cheers, Daniel On 05.05.20 09:55, Chris Martineau wrote: Thanks Daniel,
Will test and advise.
Chris
From: sr-users sr-users-bounces@lists.kamailio.orgmailto:sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: 04 May 2020 19:09 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Subject: Re: [SR-Users] PRACK support in RTPENGINE module?
I pushed a patch to rtpengine module to handle PRACK in both manage() and answer() functions.
Chris: can you test and see if works as expected? If yes, it will be backported.
Cheers, Daniel
On 04.05.20 19:51, Alex Balashov wrote:
Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was part of a cascade of fixup functions that goes back to rtpengine_manage(), but not to _answer(). You're right of course.
On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla wrote:
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in both cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/http://www.evaristesys.com, http://www.csrpswitch.com/http://www.csrpswitch.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/http://www.evaristesys.com/, http://www.csrpswitch.com/http://www.csrpswitch.com/
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Disclaimer
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom. The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.mimecast.com%2fproduc...https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.mimecast.com%2fproducts%2f&c=E,1,6-EEFrJJBxQuWdKCU8nDShSCY8ftP3YG5HunAYbdqAhHg54p0k9SuXsxW6A7W32wpQKE1kZjwLwDwP1TF3_r3j4JAl62AkawRf-TI3zTOblg9g,,&typo=1) Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Disclaimer
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom.
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cu...) .
Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
For information about how we process data and monitor communications please see our Privacy Policy (https://semafone.com/gb/privacy/)
Sorry Daniel, don’t think I followed up on this.
It works a treat, thanks for your help.
Chris
From: Chris Martineau Sent: 06 May 2020 11:57 To: miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: RE: [SR-Users] PRACK support in RTPENGINE module?
Todays task, I had to port it into an earlier version for a legacy version test.
From: Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com> Sent: 06 May 2020 10:53 To: Chris Martineau <Chris.Martineau@semafone.commailto:Chris.Martineau@semafone.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Subject: Re: [SR-Users] PRACK support in RTPENGINE module?
Have you had the chance to do any testing? It will help deciding to push the commit to branch 5.3 for the release of 5.3.4.
Cheers, Daniel On 05.05.20 09:55, Chris Martineau wrote: Thanks Daniel,
Will test and advise.
Chris
From: sr-users sr-users-bounces@lists.kamailio.orgmailto:sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: 04 May 2020 19:09 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Subject: Re: [SR-Users] PRACK support in RTPENGINE module?
I pushed a patch to rtpengine module to handle PRACK in both manage() and answer() functions.
Chris: can you test and see if works as expected? If yes, it will be backported.
Cheers, Daniel
On 04.05.20 19:51, Alex Balashov wrote:
Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was part of a cascade of fixup functions that goes back to rtpengine_manage(), but not to _answer(). You're right of course.
On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla wrote:
Hello,
Chris mentioned that rtpengine_answer() is also not supporting (or is ruling out all request types but ACK), so the C code is limiting in both cases, no matter using rtpengine_manage() or rtpengine_answer().
The rtpengine manage() was built as a wrapper around offer()/answer() and it makes the decision of which one is executed in various cases (request/reply/failure route), but not what offer()/answer() functions do internally.
So in this case the code has to allow execution for PRACK, it was an omission, likely not a scenario that popped up so far.
Cheers, Daniel
On 04.05.20 19:22, Alex Balashov wrote:
Hello Chris,
rtpengine_manage() is just a wrapper that makes context-sensitive invocations of rtpengine_offer() and rtpengine_answer(), so that you don't have to choose which of them to call manually. But it's not perfect.
There are nevertheless situations where this manual use of the offer/answer functions is necessary, and it sounds like this is one of them.
There is a larger question of whether rtpengine_manage() should support PRACK; it seems like the answer is yes. But this lacking cannot be framed as "RTPEngine doesn't support PRACK" or anything like that. RTPEngine can support any SDP-bearing request and reply, since RTPEngine does not care about SIP semantics per se.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/http://www.evaristesys.com, http://www.csrpswitch.com/http://www.csrpswitch.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/http://www.evaristesys.com/, http://www.csrpswitch.com/http://www.csrpswitch.com/
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-usershttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Disclaimer
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom. The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.mimecast.com%2fproduc...https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.mimecast.com%2fproducts%2f&c=E,1,6-EEFrJJBxQuWdKCU8nDShSCY8ftP3YG5HunAYbdqAhHg54p0k9SuXsxW6A7W32wpQKE1kZjwLwDwP1TF3_r3j4JAl62AkawRf-TI3zTOblg9g,,&typo=1) Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Disclaimer
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom.
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cu...) .
Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
For information about how we process data and monitor communications please see our Privacy Policy (https://semafone.com/gb/privacy/)
OK, thanks for reporting back. I backported the commit to branch 5.3.
Cheers, Daniel
On 21.05.20 11:10, Chris Martineau wrote:
Sorry Daniel, don’t think I followed up on this.
It works a treat, thanks for your help.
Chris
*From:*Chris Martineau *Sent:* 06 May 2020 11:57 *To:* miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* RE: [SR-Users] PRACK support in RTPENGINE module?
Todays task, I had to port it into an earlier version for a legacy version test.
*From:*Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> *Sent:* 06 May 2020 10:53 *To:* Chris Martineau <Chris.Martineau@semafone.com mailto:Chris.Martineau@semafone.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> *Subject:* Re: [SR-Users] PRACK support in RTPENGINE module?
Have you had the chance to do any testing? It will help deciding to push the commit to branch 5.3 for the release of 5.3.4.
Cheers, Daniel
On 05.05.20 09:55, Chris Martineau wrote:
Thanks Daniel, Will test and advise. Chris *From:*sr-users <sr-users-bounces@lists.kamailio.org> <mailto:sr-users-bounces@lists.kamailio.org> *On Behalf Of *Daniel-Constantin Mierla *Sent:* 04 May 2020 19:09 *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org> *Subject:* Re: [SR-Users] PRACK support in RTPENGINE module? I pushed a patch to rtpengine module to handle PRACK in both manage() and answer() functions. Chris: can you test and see if works as expected? If yes, it will be backported. Cheers, Daniel On 04.05.20 19:51, Alex Balashov wrote: > Oh, sorry. I misread; it seemed to me that rtpengine_answer1_f() was > part of a cascade of fixup functions that goes back to > rtpengine_manage(), but not to _answer(). You're right of course. > > On Mon, May 04, 2020 at 07:49:19PM +0200, Daniel-Constantin Mierla wrote: > >> Hello, >> >> Chris mentioned that rtpengine_answer() is also not supporting (or is >> ruling out all request types but ACK), so the C code is limiting in both >> cases, no matter using rtpengine_manage() or rtpengine_answer(). >> >> The rtpengine manage() was built as a wrapper around offer()/answer() >> and it makes the decision of which one is executed in various cases >> (request/reply/failure route), but not what offer()/answer() functions >> do internally. >> >> So in this case the code has to allow execution for PRACK, it was an >> omission, likely not a scenario that popped up so far. >> >> Cheers, >> Daniel >> >> On 04.05.20 19:22, Alex Balashov wrote: >>> Hello Chris, >>> >>> rtpengine_manage() is just a wrapper that makes context-sensitive >>> invocations of rtpengine_offer() and rtpengine_answer(), so that you >>> don't have to choose which of them to call manually. But it's not >>> perfect. >>> >>> There are nevertheless situations where this manual use of the >>> offer/answer functions is necessary, and it sounds like this is one of >>> them. >>> >>> There is a larger question of whether rtpengine_manage() should support >>> PRACK; it seems like the answer is yes. But this lacking cannot be >>> framed as "RTPEngine doesn't support PRACK" or anything like that. >>> RTPEngine can support any SDP-bearing request and reply, since RTPEngine >>> does not care about SIP semantics per se. >>> >>> -- Alex >>> >>> -- >>> Alex Balashov | Principal | Evariste Systems LLC >>> >>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) >>> Web: http://www.evaristesys.com/ <http://www.evaristesys.com>, http://www.csrpswitch.com/ <http://www.csrpswitch.com> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> -- >> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> >> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users *Disclaimer* Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom. The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cudasvc.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.mimecast.com%2fproducts%2f&c=E,1,6-EEFrJJBxQuWdKCU8nDShSCY8ftP3YG5HunAYbdqAhHg54p0k9SuXsxW6A7W32wpQKE1kZjwLwDwP1TF3_r3j4JAl62AkawRf-TI3zTOblg9g,,&typo=1>) Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda
*Disclaimer*
Semafone is a limited company, registered in England, with registered number 06963868. Our registered office is at Pannell House, Park Street, Guildford, Surrey, GU1 4HN, United Kingdom. The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please send it back to us, and immediately and permanently delete it.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here (https://protect-eu.mimecast.com/s/6sS0CE8WmI1xZECyHvaY?domain=linkprotect.cu...) Although Semafone has taken reasonable precautions to ensure no viruses are present in this email, Semafone cannot accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and any attachments) are virus free.
-
Alex Balashov -
Chris Martineau -
Daniel-Constantin Mierla