4 May
2020
4 May
'20
7:44 p.m.
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
works<https://www.semafone.com/our-solution/how-it-works/demo/>
[b] Read our insightful blog<https://semafone.com/media-centre/blog/>
[p] Switchboard: 0845 543 0822 / Mobile:
[e] Chris.Martineau@semafone.com<mailto:Chris.Martineau@semafone.com>
[w] Web: semafone.com<https://semafone.com> / Twitter:
@semafone<https://twitter.com/semafone> / LinkedIn:
Semafone<https://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.c…) .
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/)
4 May
4 May
8:22 p.m.
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/
8:49 p.m.
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(a)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
8:51 p.m.
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:
--
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/
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
9:09 p.m.
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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
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:
--
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/ 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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5 May
5 May
10:55 a.m.
Thanks Daniel,
Will test and advise.
Chris
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Daniel-Constantin
Mierla
Sent: 04 May 2020 19:09
To: Kamailio (SER) - Users Mailing List <sr-users(a)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:
--
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://lis…
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.c…)
.
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 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:
--
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/>m/>,
http://www.csrpswitch.com/<http://www.csrpswitch.com/>
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>om>,
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://lis…
--
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://lis…
6 May
6 May
12:53 p.m.
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(a)lists.kamailio.org> *On Behalf Of
*Daniel-Constantin Mierla
*Sent:* 04 May 2020 19:09
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
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(a)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(a)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(a)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.c…)
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.
1:57 p.m.
Todays task, I had to port it into an earlier version for a legacy version test.
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: 06 May 2020 10:53
To: Chris Martineau <Chris.Martineau(a)semafone.com>om>; Kamailio (SER) - Users Mailing
List <sr-users(a)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:
--
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://lis…
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%2fprodu…)
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.c…)
.
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 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:
--
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/>m/>,
http://www.csrpswitch.com/<http://www.csrpswitch.com/>
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>om>,
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://lis…
--
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://lis…
21 May
21 May
12:10 p.m.
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(a)gmail.com; Kamailio (SER) - Users Mailing List
<sr-users(a)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:
--
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://lis…
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%2fprodu…)
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.c…)
.
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 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:
--
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/>m/>,
http://www.csrpswitch.com/<http://www.csrpswitch.com/>
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>om>,
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://lis…
--
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://lis…
22 May
22 May
2:34 p.m.
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(a)gmail.com; Kamailio (SER) - Users Mailing List
<sr-users(a)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(a)gmail.com
<mailto:miconda@gmail.com>>
*Sent:* 06 May 2020 10:53
*To:* Chris Martineau <Chris.Martineau(a)semafone.com
<mailto:Chris.Martineau@semafone.com>>; Kamailio (SER) - Users Mailing
List <sr-users(a)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(a)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(a)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:
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(a)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.c…
<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.c…)
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
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
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(a)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(a)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/>,
1648
days inactive
1666
days old
9 comments
3 participants
participants (3)
-
Alex Balashov -
Chris Martineau -
Daniel-Constantin Mierla