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.chaign...@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.chaign...@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.
__________________________________________________________
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:
