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 > <sr-users@lists.kamailio.org> wrote: > > 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.chaign...@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.chaign...@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-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: -- 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 mailing list options or unsubscribe: