Hello,
I need help with modifying the "To" header in the "failure_route[ID]{...}". Specifically, I want to add the "to tag" parameter from the previous SIP messages of the current dialog(e.g., 180 Ringing, PRACK or final responses).
Here's the scenario:
1. Kamailio receives and relays the SIP messages: INVITE, 180 Ringing, PRACK, 200 OK, 486 Busy Here. 2. In my case, the 180 Ringing includes the "to tag" parameter. 3. When Kamailio receives the 486 response, it triggers "failure_route[ID]" using "t_on_failure(ID)" method. 4. I extract the SIP response code and reason from the final response of the INVITE transcation in this failure_route. 5. After processing and applying some instructions, I send a reply using "t_send_reply" with the code and reason extracted.
The problem:
- The failure_route[ID] holds the initial INVITE, which has no "to tag" parameter. - When I send a reply using "t_send_reply()", Kamailio generates a random "to tag" different from the previous SIP messages, which confuses my UAC. I think adding the "to tag" parameter manually might be a solution, but I'm not sure if I'm doing it correctly or if there is a better approach. I also tried using uac_replace_to() method, but it doesn't work in the failure_route[ID].
How can I make sure the reply in failure_route[ID] uses the correct "to tag" from the previous SIP messages? Are there any other possibilities to achieve this?
Any assistance would be appreciated.
Thank you!
Hello,
you probably want to look into adding a B2BUA component or fix your UAC. Kamailio will generate a random To tag by default, as required by the RFC 3261, section 19.3. This way the UAC can differentiate between the response from the UAS part before and the Kamailio proxy server.
Cheers,
Henning
Thank you for taking the time to reply Henning, and for the insight.
This is exactly what we are doing; we use FreeSWITCH as a B2BUA. In the scenario I described earlier, the UAC is the second leg of FreeSWITCH.
When FreeSWITCH receives the final response "negative reply sent from kamailio", it gets confused and doesn't know where to relay it. It takes 32 seconds before generating a negative SIP message to the UAC in leg A, indicating a timeout.
FreeSWITCH expects to receive a SIP message with the same To and From tags as the previous SIP messages. In this case, I think it considers it as a different dialog with new To and From tags.
Cheers,
Mohamed
I think what Henning meant was to use a B2BUA intermediately inside the call path.
On Jul 9, 2024, at 7:05 PM, sadik.oualla.mohamed--- via sr-users sr-users@lists.kamailio.org wrote:
Thank you for taking the time to reply Henning, and for the insight.
This is exactly what we are doing; we use FreeSWITCH as a B2BUA. In the scenario I described earlier, the UAC is the second leg of FreeSWITCH.
When FreeSWITCH receives the final response "negative reply sent from kamailio", it gets confused and doesn't know where to relay it. It takes 32 seconds before generating a negative SIP message to the UAC in leg A, indicating a timeout.
FreeSWITCH expects to receive a SIP message with the same To and From tags as the previous SIP messages. In this case, I think it considers it as a different dialog with new To and From tags.
Cheers,
Mohamed __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Yes Alex, this is what I understood as well.
To have something like: "Caller" <-> "B2BUA" <-> "Kamailio" <-> "Callee" right?
Yes, exactly, but with the caveat that the B2BUA in the middle must aggregate responses with differing To tags in a satisfactory way.
Proxy forking is messy. Proxies aren't UAs, and their call attempts aren't call legs, but "branches". Proxies essentially fork calls with one hand tied behind their back, in that they cannot interfere with most messaging (much), because most message attributes, including To-tags, must be constructed by the UAs. The rules that govern them are rather strict, and, depending on your point of view, a little arbitrary.
-- Alex
On Jul 10, 2024, at 9:32 AM, sadik.oualla.mohamed--- via sr-users sr-users@lists.kamailio.org wrote:
Yes Alex, this is what I understood as well.
To have something like: "Caller" <-> "B2BUA" <-> "Kamailio" <-> "Callee" right? __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
I appreciate the knowledge you have shared with me Alex, thank you, but I think there might be a misunderstanding of our setup. Our deployment with Kamailio involves a direct call flow with a single callee "UAS" and no forking. Here's a clearer explanation of the issue we're facing: "Caller" <-> "B2BUA" <-> "Kamailio" <-> "Only one single callee"
1. Current Behavior with Kamailio:
- After our UAS sends a final negative SIP Response "greater than 4XX", Kamailio's failure_route[ID]{...} is trigered via the t_on_failure(ID) method and processes this rejected SIP request (in our case the INVITE). - In the failure_route[ID]{...}, I extract the response code and reason phrase from the last SIP reply of this rejected Request "in this case, the 486 Busy here", then we construct some headers and do some processing and we use t_send_reply(code, "reason phrase") to respond. However, Kamailio sends this reply with a different "To tag" parameter, because it holds the rejected request INVITE which has no To tag.
2. Expected Behavior:
Ideally, these messages should belong to the same SIP transaction and dialog, meaning there should be no need to change the To tag parameter when sending the response. This is the same behavior when we used onreply_route[ID]{...} as well.
3. Impact of PRACK Integration:
Previously, our tests without PRACK (e.g., "INVITE, 100, 180, 200 OK, ACK" or "INVITE, 100, 180, 486, ACK") did not highlight this issue "The To tag is changed in the case of receipts of negative SIP Response because we use always the failure_route[ID]{...}" the B2BUA relay it directly to the other leg to UAC. However, integrating PRACK has exposed problems. When our B2BUA receives a negative SIP Response after the "180, PRACK, 200 to this PRACK" with a different To tag from these previous messages, it becomes confused.
Thank you for your understanding and assistance.
To ensure the reply in failure_route[ID] uses the correct "to tag" from previous SIP messages, you need to manually add the "to tag" parameter from the 180 Ringing or other related responses. Since uac_replace_to() doesn't work in failure_route, you can use the $ct variable to access and modify the "To" header. Here's an example:
failure_route[ID] { # Extract the to-tag from the previous response (e.g., 180 Ringing) $avp(to_tag) = $(ct{uri.param,tag});
# Process and send a reply with the extracted to-tag append_to_reply("To: $ct{uri.param.tag}\r\n"); t_send_reply(486, "Busy Here"); }
Make sure you adjust the script according to your specific requirements and the context of your SIP message handling.
$ct is a pseudo variable that holds the Call-ID header value. Using append_to_reply() method adds an other To header and does not change the To header used by the t_send_reply().
Hello,
the $ct pseudo-variable is for accessing the Contact header, I don't understand how this is related to retrieving a To tag.
Cheers,
Henning
-----Original Message----- From: Maria Jonas via sr-users sr-users@lists.kamailio.org Sent: Friday, July 12, 2024 11:24 AM To: sr-users@lists.kamailio.org Cc: Maria Jonas mariajonas345@outlook.com Subject: [SR-Users] Re: Change the To Header in the failure_route
To ensure the reply in failure_route[ID] uses the correct "to tag" from previous SIP messages, you need to manually add the "to tag" parameter from the 180 Ringing or other related responses. Since uac_replace_to() doesn't work in failure_route, you can use the $ct variable to access and modify the "To" header. Here's an example:
failure_route[ID] { # Extract the to-tag from the previous response (e.g., 180 Ringing) $avp(to_tag) = $(ct{uri.param,tag});
# Process and send a reply with the extracted to-tag append_to_reply("To: $ct{uri.param.tag}\r\n"); t_send_reply(486, "Busy Here"); }
Make sure you adjust the script according to your specific requirements and the context of your SIP message handling. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
The manner in which this reply is "confidently wrong" makes it looks like it may have been pulled directly from AI?
-----Original Message----- From: Henning Westerholt via sr-users sr-users@lists.kamailio.org Sent: Friday, July 12, 2024 9:04 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Maria Jonas mariajonas345@outlook.com; Henning Westerholt hw@gilawa.com Subject: [SR-Users] Re: Change the To Header in the failure_route
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.
Hello,
the $ct pseudo-variable is for accessing the Contact header, I don't understand how this is related to retrieving a To tag.
Cheers,
Henning
-----Original Message----- From: Maria Jonas via sr-users sr-users@lists.kamailio.org Sent: Friday, July 12, 2024 11:24 AM To: sr-users@lists.kamailio.org Cc: Maria Jonas mariajonas345@outlook.com Subject: [SR-Users] Re: Change the To Header in the failure_route
To ensure the reply in failure_route[ID] uses the correct "to tag" from previous SIP messages, you need to manually add the "to tag" parameter from the 180 Ringing or other related responses. Since uac_replace_to() doesn't work in failure_route, you can use the $ct variable to access and modify the "To" header. Here's an example:
failure_route[ID] { # Extract the to-tag from the previous response (e.g., 180 Ringing) $avp(to_tag) = $(ct{uri.param,tag});
# Process and send a reply with the extracted to-tag append_to_reply("To: $ct{uri.param.tag}\r\n"); t_send_reply(486, "Busy Here"); }
Make sure you adjust the script according to your specific requirements and the context of your SIP message handling. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
The manner in which Maria Jonas writes makes me think it might be a fictive personality.
On Jul 12, 2024, at 12:53 PM, Ben Kaufman via sr-users sr-users@lists.kamailio.org wrote:
The manner in which this reply is "confidently wrong" makes it looks like it may have been pulled directly from AI?
-----Original Message----- From: Henning Westerholt via sr-users sr-users@lists.kamailio.org Sent: Friday, July 12, 2024 9:04 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Maria Jonas mariajonas345@outlook.com; Henning Westerholt hw@gilawa.com Subject: [SR-Users] Re: Change the To Header in the failure_route
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.
Hello,
the $ct pseudo-variable is for accessing the Contact header, I don't understand how this is related to retrieving a To tag.
Cheers,
Henning
-----Original Message----- From: Maria Jonas via sr-users sr-users@lists.kamailio.org Sent: Friday, July 12, 2024 11:24 AM To: sr-users@lists.kamailio.org Cc: Maria Jonas mariajonas345@outlook.com Subject: [SR-Users] Re: Change the To Header in the failure_route
To ensure the reply in failure_route[ID] uses the correct "to tag" from previous SIP messages, you need to manually add the "to tag" parameter from the 180 Ringing or other related responses. Since uac_replace_to() doesn't work in failure_route, you can use the $ct variable to access and modify the "To" header. Here's an example:
failure_route[ID] { # Extract the to-tag from the previous response (e.g., 180 Ringing) $avp(to_tag) = $(ct{uri.param,tag});
# Process and send a reply with the extracted to-tag append_to_reply("To: $ct{uri.param.tag}\r\n"); t_send_reply(486, "Busy Here"); }
Make sure you adjust the script according to your specific requirements and the context of your SIP message handling. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Alex Balashov -
Ben Kaufman -
Henning Westerholt -
Maria Jonas -
sadik.oualla.mohamed＠gmail.com