Howdy,

So you’ve got the reserved ports range 0-1023. Then there’s a few other brackets.

In Linux there are kernel parameters to adjust these ranges, but it has been a few years.

If we’re really at the stage where we are looking at increasing the size of the range, then looking into these parameters is also worth looking into on these rtp boxes.

Typically a box wouldn’t be processing anywhere near the limits to be genuinely worth considering.

But now that RTPEngine has Cuda offloading…

On 12 Dec 2023, at 2:46 am, Alex Balashov via sr-users sr-users@lists.kamailio.org wrote:

Hello,

Ports are allocated dynamically. Even ports are for RTP, odd ports are for RTCP. There is no standard that I am aware of, but common practice is for the lower bound to be UDP 8000. The upper bound varies, but can be as high as the logical maximum of 65535.

-- Alex

...

On 8 Dec 2023, at 05:16, ZZ Wave via sr-users sr-users@lists.kamailio.org wrote:

Hello.

I have some rant with network security dept. Is there some standard, RFC, what port range should be used for RTP traffic, how RTP ports are selected during SIP call negotiation?

Thanks. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Hi,

@Richard Edmands, what do you mean by "RTPengine has Cuda offloading..."? Can you share more references to that?

Thank you, Stefan

________________________________ From: Richard Edmands via sr-users sr-users@lists.kamailio.org Sent: Wednesday, December 13, 2023 11:06:08 AM To: Kamailio (SER) - Users Mailing List Cc: Richard Edmands Subject: [SR-Users] Re: Standard on RTP ports

Howdy,

So you’ve got the reserved ports range 0-1023. Then there’s a few other brackets.

In Linux there are kernel parameters to adjust these ranges, but it has been a few years.

If we’re really at the stage where we are looking at increasing the size of the range, then looking into these parameters is also worth looking into on these rtp boxes.

Typically a box wouldn’t be processing anywhere near the limits to be genuinely worth considering.

But now that RTPEngine has Cuda offloading…

On 12 Dec 2023, at 2:46 am, Alex Balashov via sr-users sr-users@lists.kamailio.org wrote:

Hello,

Ports are allocated dynamically. Even ports are for RTP, odd ports are for RTCP. There is no standard that I am aware of, but common practice is for the lower bound to be UDP 8000. The upper bound varies, but can be as high as the logical maximum of 65535.

-- Alex

...

On 8 Dec 2023, at 05:16, ZZ Wave via sr-users sr-users@lists.kamailio.org wrote:

Hello.

I have some rant with network security dept. Is there some standard, RFC, what port range should be used for RTP traffic, how RTP ports are selected during SIP call negotiation?

Thanks. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Thank you.

--- Stefan

________________________________ From: Richard Edmands thesirdmz@gmail.com Sent: Friday, December 15, 2023 12:04:24 AM To: Kamailio (SER) - Users Mailing List Cc: Stefan-Cristian Mititelu Subject: Re: [SR-Users] Re: Standard on RTP ports

Sure, since it’s really fresh. The github commit will have to be it.

https://github.com/sipwise/rtpengine/commit/2fa121c0d90745fcbd714c20f0cbf9ae2f1e574a [2fa121c0d90745fcbd714c20f0cbf9ae2f1e574a.png] MT#54294 add GPU support · sipwise/rtpengine@2fa121chttps://github.com/sipwise/rtpengine/commit/2fa121c0d90745fcbd714c20f0cbf9ae2f1e574a github.comhttps://github.com/sipwise/rtpengine/commit/2fa121c0d90745fcbd714c20f0cbf9ae2f1e574a

Looks like my memory was mildy off, not cuda specific, just gpu offloading for transcoding.

On 14 Dec 2023, at 7:08 pm, Stefan-Cristian Mititelu via sr-users sr-users@lists.kamailio.org wrote:



Hi,

@Richard Edmands, what do you mean by "RTPengine has Cuda offloading..."? Can you share more references to that?

Thank you, Stefan

________________________________ From: Richard Edmands via sr-users sr-users@lists.kamailio.org Sent: Wednesday, December 13, 2023 11:06:08 AM To: Kamailio (SER) - Users Mailing List Cc: Richard Edmands Subject: [SR-Users] Re: Standard on RTP ports

Howdy,

So you’ve got the reserved ports range 0-1023. Then there’s a few other brackets.

In Linux there are kernel parameters to adjust these ranges, but it has been a few years.

If we’re really at the stage where we are looking at increasing the size of the range, then looking into these parameters is also worth looking into on these rtp boxes.

Typically a box wouldn’t be processing anywhere near the limits to be genuinely worth considering.

But now that RTPEngine has Cuda offloading…

On 12 Dec 2023, at 2:46 am, Alex Balashov via sr-users sr-users@lists.kamailio.org wrote:

Hello,

Ports are allocated dynamically. Even ports are for RTP, odd ports are for RTCP. There is no standard that I am aware of, but common practice is for the lower bound to be UDP 8000. The upper bound varies, but can be as high as the logical maximum of 65535.

-- Alex

...

On 8 Dec 2023, at 05:16, ZZ Wave via sr-users sr-users@lists.kamailio.org wrote:

Hello.

I have some rant with network security dept. Is there some standard, RFC, what port range should be used for RTP traffic, how RTP ports are selected during SIP call negotiation?

Thanks. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Hello,

the enum module seems to execute its queries synchronously indeed.

Asynchronous execution could be added to the module or as another module. Maybe also adding some configurable timeout values to not block the server in case of errors would be also sufficient. You can also look at the async module to see if maybe this is an easier solution: https://www.kamailio.org/docs/modules/devel/modules/async.html

Cheers,

Henning

From: Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org Sent: Freitag, 15. Dezember 2023 10:37 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Chaigneau, Nicolas nicolas.chaigneau@capgemini.com Subject: [SR-Users] enum queries using Kamailio in asynchronous mode ?

Hello,

I will need to perform enum queries from Kamailio.

I see that there is a module for that: https://www.kamailio.org/docs/modules/devel/modules/enum.html

However, I’m worried that if the enum server is unresponsive, this could block all workers… I don’t think the module can handle an asynchronous mode ? I see that we have a specific module for HTTP async: https://www.kamailio.org/docs/modules/devel/modules/http_async_client.html

Has anyone had to implement this kind of need with enum in Kamailio ?

Thanks.

Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

I’m not sure how to do that though… If I do something like this:

... async_workers_group="name=enum;workers=4;nonblock=0;usleep=0" ... request_route { ... async_task_route("ENUM", "enum"); ... } route[ENUM] { # query enum servers here # then proceed with the remaining of the routing logic ... } ...

This can still block all async workers… and then my Kamailio would also become blocked ? Am I missing something ?

Regards, Nicolas.

De : Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org Envoyé : mardi 19 décembre 2023 09:19 À : Henning Westerholt; Kamailio (SER) - Users Mailing List Cc : Chaigneau, Nicolas Objet : [SR-Users] Re: enum queries using Kamailio in asynchronous mode ?

Thanks Henning! The async module seems a good solution indeed, I’ll look into this.

Regards, Nicolas.

De : Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Envoyé : mardi 19 décembre 2023 09:10 À : Kamailio (SER) - Users Mailing List Cc : Chaigneau, Nicolas Objet : RE: enum queries using Kamailio in asynchronous mode ?

Hello,

the enum module seems to execute its queries synchronously indeed.

Asynchronous execution could be added to the module or as another module. Maybe also adding some configurable timeout values to not block the server in case of errors would be also sufficient. You can also look at the async module to see if maybe this is an easier solution: https://www.kamailio.org/docs/modules/devel/modules/async.html

Cheers,

Henning

From: Chaigneau, Nicolas via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Freitag, 15. Dezember 2023 10:37 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Chaigneau, Nicolas <nicolas.chaigneau@capgemini.commailto:nicolas.chaigneau@capgemini.com> Subject: [SR-Users] enum queries using Kamailio in asynchronous mode ?

Hello,

I will need to perform enum queries from Kamailio.

I see that there is a module for that: https://www.kamailio.org/docs/modules/devel/modules/enum.html

However, I’m worried that if the enum server is unresponsive, this could block all workers… I don’t think the module can handle an asynchronous mode ? I see that we have a specific module for HTTP async: https://www.kamailio.org/docs/modules/devel/modules/http_async_client.html

Has anyone had to implement this kind of need with enum in Kamailio ?

Thanks.

Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Hello,

So far I was using Kamailio in "stateless" mode to handle SIP INVITE requests and reply with 302.

I am now trying to use module http_async_client module, but I'm experiencing unexpected behavior with "branches". I'm using function http_async_query as described in the example:

https://www.kamailio.org/docs/modules/devel/modules/http_async_client.html#h...

When the transaction is resumed, I'm building and sending the reply, using "append_branch" and "sl_send_reply": https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_reply

For example:

append_branch("..."); sl_send_reply("302", "Moved Temporarily");

This works, however when I'm sending new client SIP INVITE requests to Kamailio, it seems it will always reuse the previous transaction. The new branches are appended to the branches of the first transaction. I end up with errors "ERROR: <core> [core/dset.c:424]: append_branch(): max nr of branches exceeded" when the limit (12) is exceeded.

I do not understand why this happens. This is a new SIP INVITE message, it should not be linked to the previous transaction ?

I tried a few things: - remove the transaction using "t_release();" - configure: modparam("tm", "wt_timer", 0)

This did not help...

How can I solve this ?

Thanks for your help.

Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Hello Alex,

The confusion is probably on my part.

Reading this: https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_reply

3.1. sl_send_reply(code, reason) For the current request, a reply is sent back having the given code and text reason. The reply is sent stateless, totally independent of the Transaction module and with no retransmission for the INVITE's replies.

If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers. The destination set contains the request URI (R-URI), if it is modified compared to the received one, plus the branches added to the request (e.g., after an append_branch() or lookup("location")). If the R-URI was changed but it is not desired to be part of the destination set, it can be reverted using the function revert_uri().

Custom headers to the reply can be added using append_to_reply() function from textops module.

I thought that I needed to use append_branch before calling sl_send_reply to control the Contact headers in the reply.

I tried to use "append_to_reply" instead to add the Contact headers, like this: append_to_reply("Contact: <...>\r\n");

This works, but then I get WARNING messages in the logs: WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Which is also why I was confused... You're telling me I should not create branches... but if I don't, I get these messages.

Could you please clarify ?

Thanks a lot.

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : jeudi 11 janvier 2024 18:57 À : Kamailio (SER) - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi,

First off, a bit confused as to why you are appending a branch and then sending a final reply? Adding a branch only makes sense if you plan to fork the request to an additional destination, instead of responding to the sender with a final dispositive (>= 3xx) reply.

-- Alex

On 11 Jan 2024, at 12:16, Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org wrote:

Hello, So far I was using Kamailio in "stateless" mode to handle SIP INVITE requests and reply with 302. I am now trying to use module http_async_client module, but I'm experiencing unexpected behavior with "branches". I'm using function http_async_query as described in the example:

https://www.kamailio.org/docs/modules/devel/modules/http_async_client. html#http_async_client.f.http_async_query When the transaction is resumed, I'm building and sending the reply, using "append_branch" and "sl_send_reply": https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_r eply For example: append_branch("..."); sl_send_reply("302", "Moved Temporarily"); This works, however when I'm sending new client SIP INVITE requests to Kamailio, it seems it will always reuse the previous transaction. The new branches are appended to the branches of the first transaction. I end up with errors "ERROR: <core> [core/dset.c:424]: append_branch(): max nr of branches exceeded" when the limit (12) is exceeded. I do not understand why this happens. This is a new SIP INVITE message, it should not be linked to the previous transaction ? I tried a few things:

• remove the transaction using "t_release();"
• configure: modparam("tm", "wt_timer", 0) This did not help... How can I solve this ?

Thanks for your help. Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Thanks for the clarification. So "branches" is not what I need.

So I should do something like that:

append_to_reply("Contact: <...>\r\n"); sl_send_reply("302", "Moved Temporarily"); exit;

(I do have an "exit" immediately after all calls to "sl_send_reply")

I tried with a minimalist request_route, as follows:

request_route { if (is_method("INVITE")) { append_to_reply("Contact: sip:+1234;myparam=test@$si:$sp\r\n"); xlog("L_INFO", "Calling sl_send_reply then exit\n"); sl_send_reply("302", "Moved Temporarily"); exit; } }

But I still have this WARNING message logged by Kamailio when handling a SIP INVITE:

WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : vendredi 12 janvier 2024 13:44 À : Kamailio - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi Nicolas,

Yes, I think that unfortunately this is the outcome of some confusion. Apart from the word "append", there is nothing in common between the concepts of append_branch() and append_to_reply().

I'm not sure why you are getting the messages you are just sending redirects, but the prime suspicion is that the execution of your configuration contains additional steps beyond just sending stateless replies, e.g. that you call sl_send_reply(), but do not call 'exit' afterward, and so the config execution progresses to a step where some kind of relay is attempted.

Conceptually, sending redirects is as simple as:

request_route { ...

# Maybe some sanity-checking or request boilerplate here.

if(method == "INVITE") { # some DB ops or whatever, yielding $var(val).

append_to_reply("Contact: sip:$var(val)\r\n"); sl_send_reply("302", "Moved Temporarily"); exit; }

# Anything else that might occur in this config should not # occur if an INVITE was received--note the 'exit' step above. }

It may not be quite as simple as that, but hopefully this gives the right idea.

-- Alex

On 12 Jan 2024, at 03:16, Chaigneau, Nicolas nicolas.chaigneau@capgemini.com wrote:

Hello Alex,

The confusion is probably on my part.

Reading this: https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_r eply

3.1. sl_send_reply(code, reason) For the current request, a reply is sent back having the given code and text reason. The reply is sent stateless, totally independent of the Transaction module and with no retransmission for the INVITE's replies.

If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers. The destination set contains the request URI (R-URI), if it is modified compared to the received one, plus the branches added to the request (e.g., after an append_branch() or lookup("location")). If the R-URI was changed but it is not desired to be part of the destination set, it can be reverted using the function revert_uri().

Custom headers to the reply can be added using append_to_reply() function from textops module.

I thought that I needed to use append_branch before calling sl_send_reply to control the Contact headers in the reply.

I tried to use "append_to_reply" instead to add the Contact headers, like this: append_to_reply("Contact: <...>\r\n");

This works, but then I get WARNING messages in the logs: WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Which is also why I was confused... You're telling me I should not create branches... but if I don't, I get these messages.

Could you please clarify ?

Thanks a lot.

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : jeudi 11 janvier 2024 18:57 À : Kamailio (SER) - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi,

First off, a bit confused as to why you are appending a branch and then sending a final reply? Adding a branch only makes sense if you plan to fork the request to an additional destination, instead of responding to the sender with a final dispositive (>= 3xx) reply.

-- Alex

...

On 11 Jan 2024, at 12:16, Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org wrote:

Hello, So far I was using Kamailio in "stateless" mode to handle SIP INVITE requests and reply with 302. I am now trying to use module http_async_client module, but I'm experiencing unexpected behavior with "branches". I'm using function http_async_query as described in the example:

https://www.kamailio.org/docs/modules/devel/modules/http_async_client. html#http_async_client.f.http_async_query When the transaction is resumed, I'm building and sending the reply, using "append_branch" and "sl_send_reply": https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_ r eply For example: append_branch("..."); sl_send_reply("302", "Moved Temporarily"); This works, however when I'm sending new client SIP INVITE requests to Kamailio, it seems it will always reuse the previous transaction. The new branches are appended to the branches of the first transaction. I end up with errors "ERROR: <core> [core/dset.c:424]: append_branch(): max nr of branches exceeded" when the limit (12) is exceeded. I do not understand why this happens. This is a new SIP INVITE message, it should not be linked to the previous transaction ? I tried a few things:

• remove the transaction using "t_release();"
• configure: modparam("tm", "wt_timer", 0) This did not help...

How can I solve this ? Thanks for your help. Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

The entire configuration (reduced to this minimalist state, just to reproduce the issue):

loadmodule "corex.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "textops.so" loadmodule "xlog.so"

request_route { if (is_method("INVITE")) { append_to_reply("Contact: sip:+1234;myparam=test@$si:$sp\r\n"); sl_send_reply("302", "Moved Temporarily"); exit; } }

An example of SIP INVITE, with the 302 response from Kamailio. (this is sent using sipp)

----------------------------------------------- 2024-01-12 15:11:42.763400 UDP message sent (314 bytes):

INVITE sip:+18080678901@10.118.21.108:5061 SIP/2.0 Via: SIP/2.0/UDP 10.118.21.108:5060;branch=z9hG4bK-268285-1-0 From: sip:+13030678901@10.118.21.108:5060;tag=1 To: sip:+18080678901@10.118.21.108:5061 Call-ID: test_sip.20240112-151142.268284.1///1-268285@10.118.21.108 Cseq: 1 INVITE Max-Forwards: 70

----------------------------------------------- 2024-01-12 15:11:42.763913 UDP message received [435] bytes :

SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP 10.118.21.108:5060;branch=z9hG4bK-268285-1-0 From: sip:+13030678901@10.118.21.108:5060;tag=1 To: sip:+18080678901@10.118.21.108:5061;tag=c274965b2956228c98c55e1090b81acd.025f7fb7 Call-ID: test_sip.20240112-151142.268284.1///1-268285@10.118.21.108 Cseq: 1 INVITE Contact: sip:+1234;myparam=test@10.118.21.108:5060 Server: kamailio (5.7.3 (x86_64/linux)) Content-Length: 0

-----Message d'origine----- De : Alex Balashov abalashov@evaristesys.com Envoyé : vendredi 12 janvier 2024 15:37 À : Chaigneau, Nicolas Cc : Kamailio (SER) - Users Mailing List Objet : Re: [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

That's a little puzzling. Could you post the incoming invite, and perhaps the entire configuration?

— Sent from mobile, apologies for brevity and errors.

On Jan 12, 2024, at 9:26 AM, Chaigneau, Nicolas nicolas.chaigneau@capgemini.com wrote:

Thanks for the clarification. So "branches" is not what I need.

So I should do something like that:

append_to_reply("Contact: <...>\r\n"); sl_send_reply("302", "Moved Temporarily"); exit;

(I do have an "exit" immediately after all calls to "sl_send_reply")

I tried with a minimalist request_route, as follows:

request_route { if (is_method("INVITE")) { append_to_reply("Contact: sip:+1234;myparam=test@$si:$sp\r\n"); xlog("L_INFO", "Calling sl_send_reply then exit\n"); sl_send_reply("302", "Moved Temporarily"); exit; } }

But I still have this WARNING message logged by Kamailio when handling a SIP INVITE:

WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : vendredi 12 janvier 2024 13:44 À : Kamailio - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi Nicolas,

Yes, I think that unfortunately this is the outcome of some confusion. Apart from the word "append", there is nothing in common between the concepts of append_branch() and append_to_reply().

I'm not sure why you are getting the messages you are just sending redirects, but the prime suspicion is that the execution of your configuration contains additional steps beyond just sending stateless replies, e.g. that you call sl_send_reply(), but do not call 'exit' afterward, and so the config execution progresses to a step where some kind of relay is attempted.

Conceptually, sending redirects is as simple as:

request_route { ...

   # Maybe some sanity-checking or request boilerplate here.

   if(method == "INVITE") {
      # some DB ops or whatever, yielding $var(val).

      append_to_reply("Contact: <sip:$var(val)>\r\n");
      sl_send_reply("302", "Moved Temporarily");
      exit;
   }

   # Anything else that might occur in this config should not
   # occur if an INVITE was received--note the 'exit' step above.

}

It may not be quite as simple as that, but hopefully this gives the right idea.

-- Alex

...

On 12 Jan 2024, at 03:16, Chaigneau, Nicolas nicolas.chaigneau@capgemini.com wrote:

Hello Alex,

The confusion is probably on my part.

Reading this: https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_ r eply

3.1. sl_send_reply(code, reason) For the current request, a reply is sent back having the given code and text reason. The reply is sent stateless, totally independent of the Transaction module and with no retransmission for the INVITE's replies.

If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers. The destination set contains the request URI (R-URI), if it is modified compared to the received one, plus the branches added to the request (e.g., after an append_branch() or lookup("location")). If the R-URI was changed but it is not desired to be part of the destination set, it can be reverted using the function revert_uri().

Custom headers to the reply can be added using append_to_reply() function from textops module.

I thought that I needed to use append_branch before calling sl_send_reply to control the Contact headers in the reply.

I tried to use "append_to_reply" instead to add the Contact headers, like this: append_to_reply("Contact: <...>\r\n");

This works, but then I get WARNING messages in the logs: WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Which is also why I was confused... You're telling me I should not create branches... but if I don't, I get these messages.

Could you please clarify ?

Thanks a lot.

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : jeudi 11 janvier 2024 18:57 À : Kamailio (SER) - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi,

First off, a bit confused as to why you are appending a branch and then sending a final reply? Adding a branch only makes sense if you plan to fork the request to an additional destination, instead of responding to the sender with a final dispositive (>= 3xx) reply.

-- Alex

...

...

On 11 Jan 2024, at 12:16, Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org wrote:

Hello, So far I was using Kamailio in "stateless" mode to handle SIP INVITE requests and reply with 302. I am now trying to use module http_async_client module, but I'm experiencing unexpected behavior with "branches". I'm using function http_async_query as described in the example:

https://www.kamailio.org/docs/modules/devel/modules/http_async_client. html#http_async_client.f.http_async_query When the transaction is resumed, I'm building and sending the reply, using "append_branch" and "sl_send_reply": https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send _ r eply For example: append_branch("..."); sl_send_reply("302", "Moved Temporarily"); This works, however when I'm sending new client SIP INVITE requests to Kamailio, it seems it will always reuse the previous transaction. The new branches are appended to the branches of the first transaction. I end up with errors "ERROR: <core> [core/dset.c:424]: append_branch(): max nr of branches exceeded" when the limit (12) is exceeded. I do not understand why this happens. This is a new SIP INVITE message, it should not be linked to the previous transaction ? I tried a few things:

• remove the transaction using "t_release();"
• configure: modparam("tm", "wt_timer", 0) This did not help...

How can I solve this ? Thanks for your help. Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Hello Ben,

Thanks for the idea !

I tried that, the WARNING message is no longer logged. However, the SIP 302 response is changed. Kamailio will build an additional Contact header, using the Request-URI.

That's not good :/

-----Message d'origine----- De : Ben Kaufman bkaufman@bcmone.com Envoyé : vendredi 12 janvier 2024 15:44 À : Kamailio (SER) - Users Mailing List Cc : Chaigneau, Nicolas Objet : RE: [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

I think you can remove the warning simply by "touching" the ruri:

$ru = $ru;

-----Original Message----- From: Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org Sent: Friday, January 12, 2024 8:26 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Chaigneau, Nicolas nicolas.chaigneau@capgemini.com Subject: [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Thanks for the clarification. So "branches" is not what I need.

So I should do something like that:

append_to_reply("Contact: <...>\r\n"); sl_send_reply("302", "Moved Temporarily"); exit;

(I do have an "exit" immediately after all calls to "sl_send_reply")

I tried with a minimalist request_route, as follows:

request_route { if (is_method("INVITE")) { append_to_reply("Contact: sip:+1234;myparam=test@$si:$sp\r\n"); xlog("L_INFO", "Calling sl_send_reply then exit\n"); sl_send_reply("302", "Moved Temporarily"); exit; } }

But I still have this WARNING message logged by Kamailio when handling a SIP INVITE:

WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : vendredi 12 janvier 2024 13:44 À : Kamailio - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi Nicolas,

Yes, I think that unfortunately this is the outcome of some confusion. Apart from the word "append", there is nothing in common between the concepts of append_branch() and append_to_reply().

I'm not sure why you are getting the messages you are just sending redirects, but the prime suspicion is that the execution of your configuration contains additional steps beyond just sending stateless replies, e.g. that you call sl_send_reply(), but do not call 'exit' afterward, and so the config execution progresses to a step where some kind of relay is attempted.

Conceptually, sending redirects is as simple as:

request_route { ...

# Maybe some sanity-checking or request boilerplate here.

if(method == "INVITE") { # some DB ops or whatever, yielding $var(val).

append_to_reply("Contact: sip:$var(val)\r\n"); sl_send_reply("302", "Moved Temporarily"); exit; }

# Anything else that might occur in this config should not # occur if an INVITE was received--note the 'exit' step above. }

It may not be quite as simple as that, but hopefully this gives the right idea.

-- Alex

On 12 Jan 2024, at 03:16, Chaigneau, Nicolas nicolas.chaigneau@capgemini.com wrote:

Hello Alex,

The confusion is probably on my part.

Reading this: https://kama/ ilio.org%2Fdocs%2Fmodules%2Fdevel%2Fmodules%2Fsl.html%23sl.f.sl_send_r &data=05%7C02%7Cbkaufman%40bcmone.com%7Ccf2236879144419e18de08dc137b17 19%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638406666649573742%7CU nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha WwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yAITfh%2F8iqcRf0XWbhyNW2fLi9JI u7vwWA%2FADkdpQHs%3D&reserved=0 eply

3.1. sl_send_reply(code, reason) For the current request, a reply is sent back having the given code and text reason. The reply is sent stateless, totally independent of the Transaction module and with no retransmission for the INVITE's replies.

If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers. The destination set contains the request URI (R-URI), if it is modified compared to the received one, plus the branches added to the request (e.g., after an append_branch() or lookup("location")). If the R-URI was changed but it is not desired to be part of the destination set, it can be reverted using the function revert_uri().

Custom headers to the reply can be added using append_to_reply() function from textops module.

I thought that I needed to use append_branch before calling sl_send_reply to control the Contact headers in the reply.

I tried to use "append_to_reply" instead to add the Contact headers, like this: append_to_reply("Contact: <...>\r\n");

This works, but then I get WARNING messages in the logs: WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Which is also why I was confused... You're telling me I should not create branches... but if I don't, I get these messages.

Could you please clarify ?

Thanks a lot.

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : jeudi 11 janvier 2024 18:57 À : Kamailio (SER) - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi,

First off, a bit confused as to why you are appending a branch and then sending a final reply? Adding a branch only makes sense if you plan to fork the request to an additional destination, instead of responding to the sender with a final dispositive (>= 3xx) reply.

-- Alex

...

On 11 Jan 2024, at 12:16, Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org wrote:

Hello, So far I was using Kamailio in "stateless" mode to handle SIP INVITE requests and reply with 302. I am now trying to use module http_async_client module, but I'm experiencing unexpected behavior with "branches". I'm using function http_async_query as described in the example:

https://www.kamailio.org/docs/modules/devel/modules/http_async_client. html#http_async_client.f.http_async_query When the transaction is resumed, I'm building and sending the reply, using "append_branch" and "sl_send_reply": https://kam/ ailio.org%2Fdocs%2Fmodules%2Fdevel%2Fmodules%2Fsl.html%23sl.f.sl_send _&data=05%7C02%7Cbkaufman%40bcmone.com%7Ccf2236879144419e18de08dc137b 1719%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638406666649586361% 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GBlP8y4m0TjCeFOW%2FRsNlEr ZVAOe2S4LyFK6MrDW37A%3D&reserved=0 r eply For example: append_branch("..."); sl_send_reply("302", "Moved Temporarily"); This works, however when I'm sending new client SIP INVITE requests to Kamailio, it seems it will always reuse the previous transaction. The new branches are appended to the branches of the first transaction. I end up with errors "ERROR: <core> [core/dset.c:424]: append_branch(): max nr of branches exceeded" when the limit (12) is exceeded. I do not understand why this happens. This is a new SIP INVITE message, it should not be linked to the previous transaction ? I tried a few things:

• remove the transaction using "t_release();"
• configure: modparam("tm", "wt_timer", 0) This did not help...

How can I solve this ? Thanks for your help. Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

From the code:

In function sl_reply_helper (sl_funcs.c):

/* if that is a redirection message, dump current message set to it */ if(code >= 300 && code < 400) { dset.s = print_dset(msg, &dset.len, sl_rich_redirect); if(dset.s) { add_lump_rpl(msg, dset.s, dset.len, LUMP_RPL_HDR); } }

Function print_dset (dset.c) will log this WARNING:

LM_WARN("no r-uri or branches\n");

I don't have a "destination set" (no branches - anymore, and no new Request-URI), I just want to send a stateless 302 reply. The call is hard-coded, I can't disable this through configuration...

-----Message d'origine----- De : Chaigneau, Nicolas Envoyé : vendredi 12 janvier 2024 15:26 À : Kamailio (SER) - Users Mailing List Cc : Alex Balashov Objet : RE: [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

Thanks for the clarification. So "branches" is not what I need.

So I should do something like that:

append_to_reply("Contact: <...>\r\n"); sl_send_reply("302", "Moved Temporarily"); exit;

(I do have an "exit" immediately after all calls to "sl_send_reply")

I tried with a minimalist request_route, as follows:

request_route { if (is_method("INVITE")) { append_to_reply("Contact: sip:+1234;myparam=test@$si:$sp\r\n"); xlog("L_INFO", "Calling sl_send_reply then exit\n"); sl_send_reply("302", "Moved Temporarily"); exit; } }

But I still have this WARNING message logged by Kamailio when handling a SIP INVITE:

WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : vendredi 12 janvier 2024 13:44 À : Kamailio - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi Nicolas,

Yes, I think that unfortunately this is the outcome of some confusion. Apart from the word "append", there is nothing in common between the concepts of append_branch() and append_to_reply().

I'm not sure why you are getting the messages you are just sending redirects, but the prime suspicion is that the execution of your configuration contains additional steps beyond just sending stateless replies, e.g. that you call sl_send_reply(), but do not call 'exit' afterward, and so the config execution progresses to a step where some kind of relay is attempted.

Conceptually, sending redirects is as simple as:

request_route { ...

# Maybe some sanity-checking or request boilerplate here.

if(method == "INVITE") { # some DB ops or whatever, yielding $var(val).

append_to_reply("Contact: sip:$var(val)\r\n"); sl_send_reply("302", "Moved Temporarily"); exit; }

# Anything else that might occur in this config should not # occur if an INVITE was received--note the 'exit' step above. }

It may not be quite as simple as that, but hopefully this gives the right idea.

-- Alex

On 12 Jan 2024, at 03:16, Chaigneau, Nicolas nicolas.chaigneau@capgemini.com wrote:

Hello Alex,

The confusion is probably on my part.

Reading this: https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_r eply

3.1. sl_send_reply(code, reason) For the current request, a reply is sent back having the given code and text reason. The reply is sent stateless, totally independent of the Transaction module and with no retransmission for the INVITE's replies.

If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers. The destination set contains the request URI (R-URI), if it is modified compared to the received one, plus the branches added to the request (e.g., after an append_branch() or lookup("location")). If the R-URI was changed but it is not desired to be part of the destination set, it can be reverted using the function revert_uri().

Custom headers to the reply can be added using append_to_reply() function from textops module.

I thought that I needed to use append_branch before calling sl_send_reply to control the Contact headers in the reply.

I tried to use "append_to_reply" instead to add the Contact headers, like this: append_to_reply("Contact: <...>\r\n");

This works, but then I get WARNING messages in the logs: WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches

Which is also why I was confused... You're telling me I should not create branches... but if I don't, I get these messages.

Could you please clarify ?

Thanks a lot.

Regards, Nicolas.

-----Message d'origine----- De : Alex Balashov via sr-users sr-users@lists.kamailio.org Envoyé : jeudi 11 janvier 2024 18:57 À : Kamailio (SER) - Users Mailing List Cc : Alex Balashov Objet : [SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.******

Hi,

First off, a bit confused as to why you are appending a branch and then sending a final reply? Adding a branch only makes sense if you plan to fork the request to an additional destination, instead of responding to the sender with a final dispositive (>= 3xx) reply.

-- Alex

...

On 11 Jan 2024, at 12:16, Chaigneau, Nicolas via sr-users sr-users@lists.kamailio.org wrote:

Hello, So far I was using Kamailio in "stateless" mode to handle SIP INVITE requests and reply with 302. I am now trying to use module http_async_client module, but I'm experiencing unexpected behavior with "branches". I'm using function http_async_query as described in the example:

https://www.kamailio.org/docs/modules/devel/modules/http_async_client. html#http_async_client.f.http_async_query When the transaction is resumed, I'm building and sending the reply, using "append_branch" and "sl_send_reply": https://kamailio.org/docs/modules/devel/modules/sl.html#sl.f.sl_send_ r eply For example: append_branch("..."); sl_send_reply("302", "Moved Temporarily"); This works, however when I'm sending new client SIP INVITE requests to Kamailio, it seems it will always reuse the previous transaction. The new branches are appended to the branches of the first transaction. I end up with errors "ERROR: <core> [core/dset.c:424]: append_branch(): max nr of branches exceeded" when the limit (12) is exceeded. I do not understand why this happens. This is a new SIP INVITE message, it should not be linked to the previous transaction ? I tried a few things:

• remove the transaction using "t_release();"
• configure: modparam("tm", "wt_timer", 0) This did not help...

How can I solve this ? Thanks for your help. Regards, Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

On 15/12/2023 14.04, [EXT] Calvin E. via sr-users wrote:

Probably this:

https://github.com/sipwise/rtpengine/blob/master/debian/changelog

ngcp-rtpengine (12.1.0.0+0~mr12.1.0.0) unstable; urgency=medium   * [2fa121c] MT#54294 add GPU support   * [b3544be] MT#54294 packaging for rtpengine-gpu   * [079bfac] MT#55283 fix up pkg generator for -gpu packages

I'm guessing this uses underlying FFmpeg CUDA support.

It's a bit more complicated than this as ffmpeg doesn't have GPU support for audio processing.

So we took the Opus codec, ported it to CUDA, heavily modified it for parallel execution, and combined it with some other codecs (G.711 for now) to be able to do transcoding on a GPU.

This isn't relevant for the regular media proxy (RTP passthrough) use case though.

Cheers