9 Jul
2024
9 Jul
'24
7:07 p.m.
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!
9 Jul
9 Jul
9:51 p.m.
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
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: sadik.oualla.mohamed--- via sr-users <sr-users(a)lists.kamailio.org>
Sent: Dienstag, 9. Juli 2024 18:07
To: sr-users(a)lists.kamailio.org
Cc: sadik.oualla.mohamed(a)gmail.com
Subject: [SR-Users] Change the To Header in the failure_route
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!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
10 Jul
10 Jul
2:05 a.m.
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
2:33 a.m.
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(a)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(a)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
4:32 p.m.
Yes Alex, this is what I understood as well.
To have something like:
"Caller" <-> "B2BUA" <-> "Kamailio" <->
"Callee"
right?
4:58 p.m.
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(a)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(a)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
11 Jul
11 Jul
6:57 p.m.
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.
12 Jul
12 Jul
12:24 p.m.
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.
3 p.m.
$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().
5:04 p.m.
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(a)lists.kamailio.org>
Sent: Friday, July 12, 2024 11:24 AM
To: sr-users(a)lists.kamailio.org
Cc: Maria Jonas <mariajonas345(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
7:53 p.m.
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(a)lists.kamailio.org>
Sent: Friday, July 12, 2024 9:04 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Maria Jonas <mariajonas345(a)outlook.com>om>; Henning Westerholt
<hw(a)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(a)lists.kamailio.org>
Sent: Friday, July 12, 2024 11:24 AM
To: sr-users(a)lists.kamailio.org
Cc: Maria Jonas <mariajonas345(a)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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
8:21 p.m.
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(a)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(a)lists.kamailio.org>
Sent: Friday, July 12, 2024 9:04 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Maria Jonas <mariajonas345(a)outlook.com>om>; Henning Westerholt
<hw(a)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(a)lists.kamailio.org>
Sent: Friday, July 12, 2024 11:24 AM
To: sr-users(a)lists.kamailio.org
Cc: Maria Jonas <mariajonas345(a)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(a)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(a)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(a)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
133
days inactive
136
days old
11 comments
5 participants
participants (5)
-
Alex Balashov -
Ben Kaufman -
Henning Westerholt -
Maria Jonas -
sadik.oualla.mohamed＠gmail.com