[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Chaigneau, Nicolas via sr-users]

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: 
\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: ;tag=1
To: 
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: ;tag=1
To: 
;tag=c274965b2956228c98c55e1090b81acd.025f7fb7
Call-ID: test_sip.20240112-151142.268284.1///1-268285@10.118.21.108
Cseq: 1 INVITE
Contact: 
Server: kamailio (5.7.3 (x86_64/linux))
Content-Length: 0





-Message d'origine-
De : Alex Balashov  
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 
>  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: \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/dset.c:690]: print_dset(): no r-uri or 
> branches
> 
> 
> 
> Regards,
> Nicolas.
> 
> -Message d'origine-
> De : Alex Balashov via sr-users  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: \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.
>

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Alex Balashov via sr-users]

Yes, but one wonders why this would be necessary, given that there is no relay 
operation to consume the R-URI?

> On 12 Jan 2024, at 09:43, Ben Kaufman via sr-users 
>  wrote:
> 
> I think you can remove the warning simply by "touching" the ruri:
> 
> $ru = $ru;
> 
> 
> 
> -Original Message-
> From: Chaigneau, Nicolas via sr-users 
> Sent: Friday, January 12, 2024 8:26 AM
> To: Kamailio (SER) - Users Mailing List 
> Cc: Chaigneau, Nicolas 
> 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: 
> \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/dset.c:690]: print_dset(): no r-uri or branches
> 
> 
> 
> Regards,
> Nicolas.
> 
> -Message d'origine-
> De : Alex Balashov via sr-users  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: \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 
>>  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%7C63840649573742%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_

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Chaigneau, Nicolas via sr-users]

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  
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 
Sent: Friday, January 12, 2024 8:26 AM
To: Kamailio (SER) - Users Mailing List 
Cc: Chaigneau, Nicolas 
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: 
\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/dset.c:690]: print_dset(): no r-uri or branches



Regards,
Nicolas.

-Message d'origine-
De : Alex Balashov via sr-users  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: \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 
>  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%7C63840649573742%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 appen

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Chaigneau, Nicolas via sr-users]

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: 
\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/dset.c:690]: print_dset(): no r-uri or branches



Regards,
Nicolas.

-Message d'origine-
De : Alex Balashov via sr-users  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: \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 
>  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/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 

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Ben Kaufman via sr-users]

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

$ru = $ru;



-Original Message-
From: Chaigneau, Nicolas via sr-users 
Sent: Friday, January 12, 2024 8:26 AM
To: Kamailio (SER) - Users Mailing List 
Cc: Chaigneau, Nicolas 
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: 
\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/dset.c:690]: print_dset(): no r-uri or branches



Regards,
Nicolas.

-Message d'origine-
De : Alex Balashov via sr-users  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: \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 
>  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%7C63840649573742%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/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

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Alex Balashov via sr-users]

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 
>  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: \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/dset.c:690]: print_dset(): no r-uri or branches
> 
> 
> 
> Regards,
> Nicolas.
> 
> -Message d'origine-
> De : Alex Balashov via sr-users 
> 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: \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 
>>  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/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  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 appendin

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Chaigneau, Nicolas via sr-users]

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: 
\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/dset.c:690]: print_dset(): no r-uri or branches



Regards,
Nicolas.

-Message d'origine-
De : Alex Balashov via sr-users  
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: \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 
>  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/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  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 
>>  wrote:
>> 
>> Hello,
>>  So far I was using Kamailio in "stateless" mo

[SR-Users] Re: Internal DNS resolver

[Igor Potjevlesch via sr-users]

You're right, sorry:

kamcmd dns.add_srv _sip._udp.example.com 3600 0 50 5060 srv1.com 2

kamcmd dns.add_srv _sip._udp.example.com 3600 0 50 5060 srv2.com 2

kamcmd dns.add_a srv1.com 3600 192.168.1.1 2

kamcmd dns.add_a srv2.com 3600 192.168.1.2 2



Finally, it looks to work fine by adding:

dns_srv_lb=yes

use_dns_failover=yes





De : Sergiu Pojoga 
Envoyé : vendredi 12 janvier 2024 14:50
À : Kamailio (SER) - Users Mailing List 
Cc : mico...@gmail.com; Igor Potjevlesch 
Objet : Re: [SR-Users] Re: Internal DNS resolver



Just so ppl you're asking don't lose their minds either trying to be 
clairvoyants of your particular setup, can you post what records exactly were 
added and what makes you think they are not followed by Kam when selecting a 
destination?



So you add records with dns.add and then lookup them up with dns.lookup



Cheers,



On Fri, Jan 12, 2024 at 8:42 AM Igor Potjevlesch via sr-users 
mailto:sr-users@lists.kamailio.org> > wrote:

Hello,



Just to be sure that I'm not losing my time: is there any chance to do a 
load-balancing using add_srv? I just tried with two equal entries but it's 
always the same which is returned.



Regards,



Igor.



De : Daniel-Constantin Mierla mailto:mico...@gmail.com> >
Envoyé : vendredi 12 janvier 2024 11:17
À : Igor Potjevlesch mailto:igor.potjevle...@gmail.com> >; 'Kamailio (SER) - Users Mailing List' 
mailto:sr-users@lists.kamailio.org> >
Objet : Re: [SR-Users] Internal DNS resolver



Hello,

the core rpc lack proper documentation, not like the case of modules. In this 
case, the code should be suggestive of what parameters have to be provided:

  - https://github.com/kamailio/kamailio/blob/master/src/core/dns_cache.c#L4744

For each of those values, the corex docs for dns_cache parameter should give 
details.

Cheers,
Daniel



On 12.01.24 11:05, Igor Potjevlesch wrote:

Hello Daniel,



Thanks! I wll try. I didn't find out how to use dns.add_a. Is someone has the 
exact params lists? Thank you.



Regards,



Igor.



De : Daniel-Constantin Mierla   
Envoyé : jeudi 11 janvier 2024 19:36
À : Kamailio (SER) - Users Mailing List   

Cc : Igor Potjevlesch   

Objet : Re: [SR-Users] Internal DNS resolver



Hello,



On 11.01.24 19:07, Igor Potjevlesch via sr-users wrote:

Hello!



I have a quick question about the internal DNS resolver and cache embedded in 
Kamailio.

Is the ability to add an entry with dns.add_a bypass the "real" DNS lookup? So, 
let's say that sip.example.com   is publicly resolve 
alternatively with 1.2.3.4 & 5.6.7.8.9, if I do a dns.add_a to add my own 
sip.example.com   with, alternatively, 127.0.0.1 and 
127.0.0.2, will it work?





yes, it should work, the internal cache is checked first and if entry found, 
then it is used.

You can also add entries in the dns cache at startup via dns_cache modparam 
from corex.

Cheers,
Daniel

--
Daniel-Constantin Mierla (@ asipto.com  )
twitter.com/miconda   -- linkedin.com/in/miconda 

Kamailio Consultancy, Training and Development Services -- asipto.com 

Kamailio Advanced Training, February 20-22, 2024 -- asipto.com 

Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com 





 


Sans virus. 

 www.avast.com

--
Daniel-Constantin Mierla (@ asipto.com  )
twitter.com/miconda   -- linkedin.com/in/miconda 

Kamailio Consultancy, Training and Development Services -- asipto.com 

Kamailio Advanced Training, February 20-22, 2024 -- asipto.com 

Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com 


__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org 

Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:



--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Internal DNS resolver

[Sergiu Pojoga via sr-users]

Just so ppl you're asking don't lose their minds either trying to be
clairvoyants of your particular setup, can you post what records exactly
were added and what makes you think they are not followed by Kam when
selecting a destination?

So you add records with *dns.add* and then lookup them up with *dns.lookup*

Cheers,

On Fri, Jan 12, 2024 at 8:42 AM Igor Potjevlesch via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hello,
>
>
>
> Just to be sure that I'm not losing my time: is there any chance to do a
> load-balancing using add_srv? I just tried with two equal entries but it's
> always the same which is returned.
>
>
>
> Regards,
>
>
>
> Igor.
>
>
>
> *De :* Daniel-Constantin Mierla 
> *Envoyé :* vendredi 12 janvier 2024 11:17
> *À :* Igor Potjevlesch ; 'Kamailio (SER) -
> Users Mailing List' 
> *Objet :* Re: [SR-Users] Internal DNS resolver
>
>
>
> Hello,
>
> the core rpc lack proper documentation, not like the case of modules. In
> this case, the code should be suggestive of what parameters have to be
> provided:
>
>   -
> https://github.com/kamailio/kamailio/blob/master/src/core/dns_cache.c#L4744
>
> For each of those values, the corex docs for dns_cache parameter should
> give details.
>
> Cheers,
> Daniel
>
>
>
> On 12.01.24 11:05, Igor Potjevlesch wrote:
>
> Hello Daniel,
>
>
>
> Thanks! I wll try. I didn't find out how to use dns.add_a. Is someone has
> the exact params lists? Thank you.
>
>
>
> Regards,
>
>
>
> Igor.
>
>
>
> *De :* Daniel-Constantin Mierla  
> *Envoyé :* jeudi 11 janvier 2024 19:36
> *À :* Kamailio (SER) - Users Mailing List 
> 
> *Cc :* Igor Potjevlesch 
> 
> *Objet :* Re: [SR-Users] Internal DNS resolver
>
>
>
> Hello,
>
>
>
> On 11.01.24 19:07, Igor Potjevlesch via sr-users wrote:
>
> Hello!
>
>
>
> I have a quick question about the internal DNS resolver and cache embedded
> in Kamailio.
>
> Is the ability to add an entry with dns.add_a bypass the "real" DNS
> lookup? So, let's say that sip.example.com is publicly resolve
> alternatively with 1.2.3.4 & 5.6.7.8.9, if I do a dns.add_a to add my own
> sip.example.com with, alternatively, 127.0.0.1 and 127.0.0.2, will it
> work?
>
>
>
>
> yes, it should work, the internal cache is checked first and if entry
> found, then it is used.
>
> You can also add entries in the dns cache at startup via dns_cache
> modparam from corex.
>
> Cheers,
> Daniel
>
> --
>
> Daniel-Constantin Mierla (@ asipto.com)
>
> twitter.com/miconda -- linkedin.com/in/miconda
>
> Kamailio Consultancy, Training and Development Services -- asipto.com
>
> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
>
> Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
>
>
>
>
> 
>
> Sans virus.www.avast.com
> 
>
> --
>
> Daniel-Constantin Mierla (@ asipto.com)
>
> twitter.com/miconda -- linkedin.com/in/miconda
>
> Kamailio Consultancy, Training and Development Services -- asipto.com
>
> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
>
> Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: xavp_params_explode broken comma in value?

[Daniel-Constantin Mierla via sr-users]

Hello,

On 12.01.24 11:56, Benoît Panizzon wrote:
> Hi Daniel
>  
>> comma is not allowed in an unquoted value for SIP parameters because
>> it is separator for header bodies that are set on the same header
>> name. Practically the comma is the end of parameters list.
> Thank you for your confirmation I was on the right track.
>
>> It should work with:
>>
>> xavp_params_explode("a=foo;c=\"hello,world\";e=baar", "x");
> Any recipe on how to solve if the value is the 'authentication'
> password taken from the database? As far as I understood the SIP RFC a
> comma is permitted in the SIP password itself, as it is never present
> cleartext in a sip header.
>
> Quick example of what I do when receiving a REGISTER with credentials to pull 
> the password:
>
> $var(query) = "select user,password,language from sometable where auth_user = 
> '" + $var(auth_user) + "' limit 1";
> $var(qresult) = sql_xquery("database", "$var(query)", "userdata");
> xavp_params_implode("userdata","$var(xuserdata)");
>
> $var(xuserdata) is "user=JohnDoe;password=secret,password;language=de_CH"
>
> This is the stored in an $sht to be cached and available for a while and 
> reducde SQL queries.
>
> I guess there is no way to have sql_xquery automatically quote result fields 
> that need quoting.
>
> I could probably do select user,concat('"',password,'"'),language from 
> sometable?
>
> This could also be a potential issue with variable injections via SQL. 
> Immagine some use sets a password ";var=value" this would lead to this var 
> being overwritten I guess.
>
> We are moving towards storing ha1 hashed passwords, so that would solve my 
> issue I guess.

the devel version has a new function to implode with values between quotes:

  -
https://www.kamailio.org/docs/modules/devel/modules/pv.html#pv.f.xavp_params_implode_qval

If you expect any kind of characters, maybe hexa/base32/base64
encoding/decoding is a variant to explore.

Cheers, Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Internal DNS resolver

[Igor Potjevlesch via sr-users]

Hello,



Just to be sure that I'm not losing my time: is there any chance to do a 
load-balancing using add_srv? I just tried with two equal entries but it's 
always the same which is returned.



Regards,



Igor.



De : Daniel-Constantin Mierla 
Envoyé : vendredi 12 janvier 2024 11:17
À : Igor Potjevlesch ; 'Kamailio (SER) - Users 
Mailing List' 
Objet : Re: [SR-Users] Internal DNS resolver



Hello,

the core rpc lack proper documentation, not like the case of modules. In this 
case, the code should be suggestive of what parameters have to be provided:

  - https://github.com/kamailio/kamailio/blob/master/src/core/dns_cache.c#L4744

For each of those values, the corex docs for dns_cache parameter should give 
details.

Cheers,
Daniel



On 12.01.24 11:05, Igor Potjevlesch wrote:

Hello Daniel,



Thanks! I wll try. I didn't find out how to use dns.add_a. Is someone has the 
exact params lists? Thank you.



Regards,



Igor.



De : Daniel-Constantin Mierla   
Envoyé : jeudi 11 janvier 2024 19:36
À : Kamailio (SER) - Users Mailing List   

Cc : Igor Potjevlesch   

Objet : Re: [SR-Users] Internal DNS resolver



Hello,



On 11.01.24 19:07, Igor Potjevlesch via sr-users wrote:

Hello!



I have a quick question about the internal DNS resolver and cache embedded in 
Kamailio.

Is the ability to add an entry with dns.add_a bypass the "real" DNS lookup? So, 
let's say that sip.example.com is publicly resolve alternatively with 1.2.3.4 & 
5.6.7.8.9, if I do a dns.add_a to add my own sip.example.com with, 
alternatively, 127.0.0.1 and 127.0.0.2, will it work?






yes, it should work, the internal cache is checked first and if entry found, 
then it is used.

You can also add entries in the dns cache at startup via dns_cache modparam 
from corex.

Cheers,
Daniel

--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com




 


Sans virus. 

 www.avast.com

--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com


--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Alex Balashov via sr-users]

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: \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 
>  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_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/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  
> 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 
>>  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/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 trans

[SR-Users] Re: xavp_params_explode broken comma in value?

[Alex Balashov via sr-users]

I used base64 encoding transformations to deal with these kinds of problems.

—
Sent from mobile, apologies for brevity and errors.

> On Jan 12, 2024, at 6:11 AM, Benoît Panizzon via sr-users 
>  wrote:
> 
> Hi Daniel
> 
>> comma is not allowed in an unquoted value for SIP parameters because
>> it is separator for header bodies that are set on the same header
>> name. Practically the comma is the end of parameters list.
> 
> Thank you for your confirmation I was on the right track.
> 
>> It should work with:
>> 
>> xavp_params_explode("a=foo;c=\"hello,world\";e=baar", "x");
> 
> Any recipe on how to solve if the value is the 'authentication'
> password taken from the database? As far as I understood the SIP RFC a
> comma is permitted in the SIP password itself, as it is never present
> cleartext in a sip header.
> 
> Quick example of what I do when receiving a REGISTER with credentials to pull 
> the password:
> 
> $var(query) = "select user,password,language from sometable where auth_user = 
> '" + $var(auth_user) + "' limit 1";
> $var(qresult) = sql_xquery("database", "$var(query)", "userdata");
> xavp_params_implode("userdata","$var(xuserdata)");
> 
> $var(xuserdata) is "user=JohnDoe;password=secret,password;language=de_CH"
> 
> This is the stored in an $sht to be cached and available for a while and 
> reducde SQL queries.
> 
> I guess there is no way to have sql_xquery automatically quote result fields 
> that need quoting.
> 
> I could probably do select user,concat('"',password,'"'),language from 
> sometable?
> 
> This could also be a potential issue with variable injections via SQL. 
> Immagine some use sets a password ";var=value" this would lead to this var 
> being overwritten I guess.
> 
> We are moving towards storing ha1 hashed passwords, so that would solve my 
> issue I guess.
> 
> --
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
> 
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: xavp_params_explode broken comma in value?

[Benoît Panizzon via sr-users]

Hi Daniel
 
> comma is not allowed in an unquoted value for SIP parameters because
> it is separator for header bodies that are set on the same header
> name. Practically the comma is the end of parameters list.

Thank you for your confirmation I was on the right track.

> It should work with:
> 
> xavp_params_explode("a=foo;c=\"hello,world\";e=baar", "x");

Any recipe on how to solve if the value is the 'authentication'
password taken from the database? As far as I understood the SIP RFC a
comma is permitted in the SIP password itself, as it is never present
cleartext in a sip header.

Quick example of what I do when receiving a REGISTER with credentials to pull 
the password:

$var(query) = "select user,password,language from sometable where auth_user = 
'" + $var(auth_user) + "' limit 1";
$var(qresult) = sql_xquery("database", "$var(query)", "userdata");
xavp_params_implode("userdata","$var(xuserdata)");

$var(xuserdata) is "user=JohnDoe;password=secret,password;language=de_CH"

This is the stored in an $sht to be cached and available for a while and 
reducde SQL queries.

I guess there is no way to have sql_xquery automatically quote result fields 
that need quoting.

I could probably do select user,concat('"',password,'"'),language from 
sometable?

This could also be a potential issue with variable injections via SQL. Immagine 
some use sets a password ";var=value" this would lead to this var being 
overwritten I guess.

We are moving towards storing ha1 hashed passwords, so that would solve my 
issue I guess.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Internal DNS resolver

[Igor Potjevlesch via sr-users]

Hello,



Wonderful! Thank you Daniel.



Regards,



Igor.



De : Daniel-Constantin Mierla 
Envoyé : vendredi 12 janvier 2024 11:17
À : Igor Potjevlesch ; 'Kamailio (SER) - Users 
Mailing List' 
Objet : Re: [SR-Users] Internal DNS resolver



Hello,

the core rpc lack proper documentation, not like the case of modules. In this 
case, the code should be suggestive of what parameters have to be provided:

  - https://github.com/kamailio/kamailio/blob/master/src/core/dns_cache.c#L4744

For each of those values, the corex docs for dns_cache parameter should give 
details.

Cheers,
Daniel



On 12.01.24 11:05, Igor Potjevlesch wrote:

Hello Daniel,



Thanks! I wll try. I didn't find out how to use dns.add_a. Is someone has the 
exact params lists? Thank you.



Regards,



Igor.



De : Daniel-Constantin Mierla   
Envoyé : jeudi 11 janvier 2024 19:36
À : Kamailio (SER) - Users Mailing List   

Cc : Igor Potjevlesch   

Objet : Re: [SR-Users] Internal DNS resolver



Hello,



On 11.01.24 19:07, Igor Potjevlesch via sr-users wrote:

Hello!



I have a quick question about the internal DNS resolver and cache embedded in 
Kamailio.

Is the ability to add an entry with dns.add_a bypass the "real" DNS lookup? So, 
let's say that sip.example.com is publicly resolve alternatively with 1.2.3.4 & 
5.6.7.8.9, if I do a dns.add_a to add my own sip.example.com with, 
alternatively, 127.0.0.1 and 127.0.0.2, will it work?






yes, it should work, the internal cache is checked first and if entry found, 
then it is used.

You can also add entries in the dns cache at startup via dns_cache modparam 
from corex.

Cheers,
Daniel

--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com




 


Sans virus. 

 www.avast.com

--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com


--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: xavp_params_explode broken comma in value?

[Daniel-Constantin Mierla via sr-users]

Hello,

On 12.01.24 11:01, Benoît Panizzon via sr-users wrote:
> Hey!
>
> I'm hunting down an issue with xavp_params_explode, maybe somebody has
> already come adross it and could confirm it exists and maybe know a
> solution?
>
> xavp_params_explode("a=foo;c=hello,world;e=baar", "x");
>
> $xavp(x=>a) is 'foo'
>
> but x=>c and x=>e are null
>
> Am I right to assume the issue being caused by the comma? Is there a
> way to allow a comma?
comma is not allowed in an unquoted value for SIP parameters because it
is separator for header bodies that are set on the same header name.
Practically the comma is the end of parameters list.

It should work with:

xavp_params_explode("a=foo;c=\"hello,world\";e=baar", "x");

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Internal DNS resolver

[Daniel-Constantin Mierla via sr-users]

Hello,

the core rpc lack proper documentation, not like the case of modules. In
this case, the code should be suggestive of what parameters have to be
provided:

  -
https://github.com/kamailio/kamailio/blob/master/src/core/dns_cache.c#L4744

For each of those values, the corex docs for dns_cache parameter should
give details.

Cheers,
Daniel


On 12.01.24 11:05, Igor Potjevlesch wrote:
>
> Hello Daniel,
>
>  
>
> Thanks! I wll try. I didn't find out how to use dns.add_a. Is someone
> has the exact params lists? Thank you.
>
>  
>
> Regards,
>
>  
>
> Igor.
>
>  
>
> *De :*Daniel-Constantin Mierla 
> *Envoyé :* jeudi 11 janvier 2024 19:36
> *À :* Kamailio (SER) - Users Mailing List 
> *Cc :* Igor Potjevlesch 
> *Objet :* Re: [SR-Users] Internal DNS resolver
>
>  
>
> Hello,
>
>  
>
> On 11.01.24 19:07, Igor Potjevlesch via sr-users wrote:
>
> Hello!
>
>  
>
> I have a quick question about the internal DNS resolver and cache
> embedded in Kamailio.
>
> Is the ability to add an entry with dns.add_a bypass the "real"
> DNS lookup? So, let's say that sip.example.com is publicly resolve
> alternatively with 1.2.3.4 & 5.6.7.8.9, if I do a dns.add_a to add
> my own sip.example.com with, alternatively, 127.0.0.1 and
> 127.0.0.2, will it work?
>
>
>
> yes, it should work, the internal cache is checked first and if entry
> found, then it is used.
>
> You can also add entries in the dns cache at startup via dns_cache
> modparam from corex.
>
> Cheers,
> Daniel
>
> -- 
> Daniel-Constantin Mierla (@ asipto.com)
> twitter.com/miconda -- linkedin.com/in/miconda
> Kamailio Consultancy, Training and Development Services -- asipto.com
> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
> Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
>
> 
>   Sans virus.www.avast.com
> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Internal DNS resolver

[Igor Potjevlesch via sr-users]

Hello Daniel,



Thanks! I wll try. I didn't find out how to use dns.add_a. Is someone has the 
exact params lists? Thank you.



Regards,



Igor.



De : Daniel-Constantin Mierla 
Envoyé : jeudi 11 janvier 2024 19:36
À : Kamailio (SER) - Users Mailing List 
Cc : Igor Potjevlesch 
Objet : Re: [SR-Users] Internal DNS resolver



Hello,



On 11.01.24 19:07, Igor Potjevlesch via sr-users wrote:

Hello!



I have a quick question about the internal DNS resolver and cache embedded in 
Kamailio.

Is the ability to add an entry with dns.add_a bypass the "real" DNS lookup? So, 
let's say that sip.example.com is publicly resolve alternatively with 1.2.3.4 & 
5.6.7.8.9, if I do a dns.add_a to add my own sip.example.com with, 
alternatively, 127.0.0.1 and 127.0.0.2, will it work?





yes, it should work, the internal cache is checked first and if entry found, 
then it is used.

You can also add entries in the dns cache at startup via dns_cache modparam 
from corex.

Cheers,
Daniel

--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com


--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] xavp_params_explode broken comma in value?

[Benoît Panizzon via sr-users]

Hey!

I'm hunting down an issue with xavp_params_explode, maybe somebody has
already come adross it and could confirm it exists and maybe know a
solution?

xavp_params_explode("a=foo;c=hello,world;e=baar", "x");

$xavp(x=>a) is 'foo'

but x=>c and x=>e are null

Am I right to assume the issue being caused by the comma? Is there a
way to allow a comma?

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: registrar questions

[mm e via sr-users]

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

[SR-Users] Re: registrar questions

[mm e via sr-users]

After using sqlops to modify the "subscriber" table, how to refresh the 
configuration to take effect?
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: registrar questions

[Daniel-Constantin Mierla via sr-users]

On 12.01.24 09:48, mm e via sr-users wrote:
> In addition to the RPC command "kamctl add username password", is there a 
> module with a method to operate the "subscriber" database table?

You can "operate" any sql database table with sqlops module.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

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

[SR-Users] Re: registrar questions

[mm e via sr-users]

Sorry, this is a shell script. Is it possible to add username in the module 
method?
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] registrar questions

[mm e via sr-users]

In addition to the RPC command "kamctl add username password", is there a 
module with a method to operate the "subscriber" database table?
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Using http_async_query - transaction seems "reused" for subsequent SIP INVITE requests received ? (Kamailio 5.7.3)

[Chaigneau, Nicolas via sr-users]

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/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  
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 
>  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/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-le...@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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit