[SR-Users] Wrong To tag in t_reply

[Ivan Ribakov]

> you can use send_reply() to avoid any test in the config.
> 
Thanks for the tip Daniel, will give it a go!

> So think that kamailio itself is the branch of the incoming request, and can create many outgoing branches. If it generates a final reply, it does it to the incoming branch. It is not forwarding (sending back) a reply from an outgoing branch.
> 

Ok, when you put it that way it actually makes more sense - thanks for a great example! 

I still have one question left about my current scenario - why does Kamailio retransmit final non-2xx response after receiving an ACK if the response is valid and, as far as I can tell, so is the ACK?

Just to provide more context:
1) Ingress INVITE vs 504 response from Kamailio


2) 504 response from Kamailio vs Caller ACK


Regards,
Ivan

> On 11 Dec 2020, at 14:06, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> actually you are wrong that you think it is a wrong to tag. The entity that generates the final reply sets the to-tag (e.g.,to be able to match ack). Even here where you talk about the serial forking, you are going to face the case of different to-tag values for each branch sent out and replied. But also think about parallel forking, that timed out with many active branches, which to-tag to use?!?
> 
> So think that kamailio itself is the branch of the incoming request, and can create many outgoing branches. If it generates a final reply, it does it to the incoming branch. It is not forwarding (sending back) a reply from an outgoing branch.
> 
> Obviously, being open source, one can code a specific behaviour for some specific needs, but is not SIP specs compliant. If the upstream cannot deal with different to-tags, it won't really work with serial/parallel forking anyhow.
> 
> As a side remark, seeing the comments, if route(ROUTE_ELEMENT_FINAL_FAILURE) is used only in failure_route, then transaction is always defined there, because failure_route is executed only in the transaction context. Anyhow, if you are using in many places, not knowing if transaction was created, you can use send_reply() to avoid any test in the config.
> 
> Cheers,
> Daniel
> 
> On 11.12.20 11:04, Ivan Ribakov wrote:
>> Hi all,
>> 
>> I’m trying to implement following routing behaviour:
>> 
>> - ingress INVITE is sequentially forked to 1 or more endpoints
>> - under certain conditions sequential forking may be stopped and pre-defined error returned to the caller
>> 
>> Here’s is part of the config responsible for handling errors:
>> 
>> failure_route[ROUTE_ELEMENT_FINAL_FAILURE_HELPER] {
>>     route(ROUTE_ELEMENT_FINAL_FAILURE);
>> }
>> 
>> route[ROUTE_ELEMENT_FINAL_FAILURE] {
>>     # We need to check if the error happens before the first egress, because T-state is not defined yet so we can not use t_reply
>>     if ($var(before_first_egress) == 0) {
>>         t_reply("$var(sipCode)", "$var(sipMessage)");
>>     } else {
>>         sl_send_reply("$var(sipCode)", "$var(sipMessage)");
>>     }
>> }
>> 
>> 
>> 
>> Here is a simple scenario where delivering call to first endpoint times out after receiving 180 Ringing (using custom fr_inv_timer value) where:
>> - .33 is caller
>> - .208 is Kamailio
>> - .138 is callee
>> 
>> 
>> 
>> Notice that 504 is retransmitted by Kamailio. Here is a comparison of 180 and 504 returned by Kamailio:
>> 
>> 
>> 
>> As can be seen, 180 was proxied from the callee and has callee’s to-tag (tag=CALLEE1), however 504 that was generated by Kamailio using t_reply() has a different to-tag (presumably generated by Kamailio).
>> 
>> How can I tell Kamailio not to generate new to-tag but to use the last one that proxied back to the caller?
>> 
>> Thanks in advance for any help!
>> 
>> Regards,
>> Ivan
>> 
>> 
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/72af2fd6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-5.png
Type: image/png
Size: 121610 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/72af2fd6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-6.png
Type: image/png
Size: 98097 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/72af2fd6/attachment-0001.png>