Hi list! :-) I'm a total newbie in Kamailio. Trying to study) Sorry for lots of text, I'm simply don't know how to explain my questions shorter :-D
I want to configure Kamailio as dispatcher, registrar and NAT traversal in front of FS farm. I've managed to set up Kamailio and Fswitches. Now I need to handle "special cases" with confs, REFER transfers etc
Giovanni Maruzzelli once presented solution for this, with following logic: ------------------------------------------------------------------------------------------------------- 1) Kamailio by default distribute calls to various FSs - dispatch or load_balance 2) Each time Kamailio sends a call to a FS, it writes down which destination "number" is going to which FS server and from which UserID 3) if another call comes for the same (or related) destination, or is originated from the same UserID then Kamailio sends the call to that same FS server, bypassing default distribution algorithm ------------------------------------------------------------------------------------------------------- Sounds good and helpful, but I'm stuck :-(
*Can someone please share an example or point me how and in what form should I write down call info,and how can I control it (delete on BYE or CANCEL)?*
Actually there are 2 questions It seems to me that recordings can be made using HTABLEs but here's a problem: ===================================================================================== ============================================================================================= 1) PROBLEM WITH WRITING TO HTABLE ON ATT TRANSFER
After the dispatcher sets $du - I write an htable entry $sht(fsdest=>$fU:$rU) = $du; Existing entries are removed on catching 'BYE' for normal clearing, and with failure_route for all failures. BYE logic is: IN WITHINNDLG route
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { if (sht_match_name("fsdest", "eq", "$fU:$rU")) { $sht(fsdest=>$fU:$rU) = $null; //BYE A->B } else { $sht(fsdest=>$rU:$fU) = $null; //BYE A<-B } } handle_ruri_alias(); route(RELAY); } }
Another entry is setting up if blind transfer is made. If INVITE is coming from one of FSs, and have 'Referred-By' field. IN DIALOG route: if (is_present_hf("Referred-By")) { $sht(fsdest=>$fU:$rU) = $si; } For now it's working. Entries are written and deleted properly.
*Problem with Attended transfer.* 1) A --> B = htable entry A:B=xxxx 2) A --> C = htable entry A:C=xxxx(checked and set same FS addr because $fU is present (If only it's worked as it should)) 3) Att transfer (Refer $rU B, referred-by - A. Refer-To - C) B --> C = all related entries deleted from table over BYE logic. 4) No entry B --> C (no INVITE was sent, bridged by REFER) So, logic for check active calls in htable is broken now, because we don't have entry B-->C
*How can I handle writing to htable in Attended transfer case?* If another Invite will come FROM or TO B or C = there will be no htable entry. I'm not sure this is even a correct way. Surely missing something. ============================================================================================= =============================================================================================
2) PROBLEM WITH IDENTIFYING TABLE ENTRIES
Anyway, the main problem is with identifying those htables to set proper $du. If INVITE is coming TO FSs I need to check if caller ID ($fU) or dest ($rU) is present in htables.
Form I need to write to hash must be like $fU:$rU Entry must be unique or it will be: 1) rewrited anytime a new invite is going to the same dest. 2) deleted anytime BYE or failure will come
eg: If $sht(fsdest=>$rU) = $dd 1) 1000 --> 3200 = htable entry 3200 = xxxx 2) 1005 --> 3200 = htable entry rewriten to the same 3200 = xxxx When 1000 or 1005 leaving conf, it sends BYE and removes entry. So, next call to 3200 may be sent to the wrong FS.
Ok, we have a unique entry ($fU:$rU). Checking for active destination: if (sht_match_name("fsdest", "re", ":$rU")) {} If there's an htable with $rU in key - we got a match. Now we need to assign a value from htable to $du. But, I don't know how to get the name of this entry. There's always different $fU: (or $rU if we check for the same caller ID ($fU)).
eg: 1000 --> 3200 = htbale 1000 --> 3200 New call 1005 --> 3200 Check sht_match name ":3200" - got match We need to set: $du = $sht(fsdest=>$fU:$rU) But it will be $sht(fsdest=>1005:3200) and we don't have this entry. We need (fsdest=>1003:3200) But i don't see any way to get needed $fU.
*Is there any way to search or identify these tables?* ============================================================================================= =============================================================================================
Can someone help me with this, please? :-) Or maybe there is a better way to do this?
*My kamailio.cfg routing block in pastebin, if neededhttps://pastebin.com/1PZ0QSDW https://pastebin.com/1PZ0QSDW*
Thank you! Regards, Tim
There's a lot to go through on this example... and many ways to handle such scenarios.
Personally, I very much like the HTABLE approach for "remembering" destinations. Instead of using a BYE to remove the entries, you might see if using DIALOG for this use case to be beneficial (removing the HTABLE entry when all calls are ended).
Depending on how the endpoints are linking attended transfers, you may need to consider adding SIP headers (like X-ORIG-CI) to add a call-id, from tag, or other info to identify original calls.
Again, many different ways that you could approach this, but sounds like you're on the right track for sure.
Fred Posner | palner.com Matrix: @fred:matrix.lod.com o: +1 (212) 937-7844
Thanks Fred! The dialog module is really helpful. Got rid of that ugly "BYE" construction. Also no need to write a special ht entry for blind transfer.
For now I'm saving to htable on event_route(dialog:start), and removing on 'end' or 'failure' event. Much cleaner :-D Thanks a lot for the tip.
For "Htable key identify" problem: I've managed to find corresponding keys with 'sht_iterator' in while loop. Matches found with ($(shtitkey(i1){s.select,-1,:} == $rU || $fU). Key values = $shtitval(i1). Not the most elegant solution, imo, but best I can do for now :-D
Haven't got hands on the problem with attended transfer yet. But it's already clear that I've got a huge lack of SIP knowledge. Can't get how custom headers with original call-id and from/to tags can help me with this. Would be very grateful for clarify, if it's possible :-D For now my best idea is to catch indialog 'REFER' with 'Replaces' in 'Refer-to' and write to htable according to its contents (eg, set $fU from RURI and $rU from 'Refer-to').
Anyway, Thanks a lot for your help!
Regards, Tim
чт, 9 сент. 2021 г. в 20:05, Fred Posner fred@palner.com:
There's a lot to go through on this example... and many ways to handle such scenarios.
Personally, I very much like the HTABLE approach for "remembering" destinations. Instead of using a BYE to remove the entries, you might see if using DIALOG for this use case to be beneficial (removing the HTABLE entry when all calls are ended).
Depending on how the endpoints are linking attended transfers, you may need to consider adding SIP headers (like X-ORIG-CI) to add a call-id, from tag, or other info to identify original calls.
Again, many different ways that you could approach this, but sounds like you're on the right track for sure.
Fred Posner | palner.com Matrix: @fred:matrix.lod.com o: +1 (212) 937-7844
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Wouldn’t dispatching based on user hash solve all these problems?
On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков sitdikovt@gmail.com wrote:
Thanks Fred! The dialog module is really helpful. Got rid of that ugly "BYE" construction. Also no need to write a special ht entry for blind transfer.
For now I'm saving to htable on event_route(dialog:start), and removing on 'end' or 'failure' event. Much cleaner :-D Thanks a lot for the tip.
For "Htable key identify" problem: I've managed to find corresponding keys with 'sht_iterator' in while loop. Matches found with ($(shtitkey(i1){s.select,-1,:} == $rU || $fU). Key values = $shtitval(i1). Not the most elegant solution, imo, but best I can do for now :-D
Haven't got hands on the problem with attended transfer yet. But it's already clear that I've got a huge lack of SIP knowledge. Can't get how custom headers with original call-id and from/to tags can help me with this. Would be very grateful for clarify, if it's possible :-D For now my best idea is to catch indialog 'REFER' with 'Replaces' in 'Refer-to' and write to htable according to its contents (eg, set $fU from RURI and $rU from 'Refer-to').
Anyway, Thanks a lot for your help!
Regards, Tim
чт, 9 сент. 2021 г. в 20:05, Fred Posner fred@palner.com:
There's a lot to go through on this example... and many ways to handle such scenarios.
Personally, I very much like the HTABLE approach for "remembering" destinations. Instead of using a BYE to remove the entries, you might see if using DIALOG for this use case to be beneficial (removing the HTABLE entry when all calls are ended).
Depending on how the endpoints are linking attended transfers, you may need to consider adding SIP headers (like X-ORIG-CI) to add a call-id, from tag, or other info to identify original calls.
Again, many different ways that you could approach this, but sounds like you're on the right track for sure.
Fred Posner | palner.com Matrix: @fred:matrix.lod.com o: +1 (212) 937-7844
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@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
- sr-users@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'm using round-robin for now. Will try hash on URIs and come back. Thanks, David! One question - algorithms can be bitwise combined (like in nat_uac_test)? Or need to do separate ds test for from-URI and R-URI?
Thank you! Regards, Tim
сб, 11 сент. 2021 г. в 03:16, David Villasmil < david.villasmil.work@gmail.com>:
Wouldn’t dispatching based on user hash solve all these problems?
On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков sitdikovt@gmail.com wrote:
Thanks Fred! The dialog module is really helpful. Got rid of that ugly "BYE" construction. Also no need to write a special ht entry for blind transfer.
For now I'm saving to htable on event_route(dialog:start), and removing on 'end' or 'failure' event. Much cleaner :-D Thanks a lot for the tip.
For "Htable key identify" problem: I've managed to find corresponding keys with 'sht_iterator' in while loop. Matches found with ($(shtitkey(i1){s.select,-1,:} == $rU || $fU). Key values = $shtitval(i1). Not the most elegant solution, imo, but best I can do for now :-D
Haven't got hands on the problem with attended transfer yet. But it's already clear that I've got a huge lack of SIP knowledge. Can't get how custom headers with original call-id and from/to tags can help me with this. Would be very grateful for clarify, if it's possible :-D For now my best idea is to catch indialog 'REFER' with 'Replaces' in 'Refer-to' and write to htable according to its contents (eg, set $fU from RURI and $rU from 'Refer-to').
Anyway, Thanks a lot for your help!
Regards, Tim
чт, 9 сент. 2021 г. в 20:05, Fred Posner fred@palner.com:
There's a lot to go through on this example... and many ways to handle such scenarios.
Personally, I very much like the HTABLE approach for "remembering" destinations. Instead of using a BYE to remove the entries, you might see if using DIALOG for this use case to be beneficial (removing the HTABLE entry when all calls are ended).
Depending on how the endpoints are linking attended transfers, you may need to consider adding SIP headers (like X-ORIG-CI) to add a call-id, from tag, or other info to identify original calls.
Again, many different ways that you could approach this, but sounds like you're on the right track for sure.
Fred Posner | palner.com Matrix: @fred:matrix.lod.com o: +1 (212) 937-7844
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@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
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
dispatcher algorithms can’t be combined like this, you need to pick one in the command.
Cheers,
Henning
-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of ????? ???????? Sent: Saturday, September 11, 2021 6:29 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Kamailio dispatcher -> FreeSWITCH transfers handling.
I'm using round-robin for now. Will try hash on URIs and come back. Thanks, David! One question - algorithms can be bitwise combined (like in nat_uac_test)? Or need to do separate ds test for from-URI and R-URI?
Thank you! Regards, Tim
сб, 11 сент. 2021 г. в 03:16, David Villasmil <david.villasmil.work@gmail.commailto:david.villasmil.work@gmail.com>: Wouldn’t dispatching based on user hash solve all these problems?
On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков <sitdikovt@gmail.commailto:sitdikovt@gmail.com> wrote: Thanks Fred! The dialog module is really helpful. Got rid of that ugly "BYE" construction. Also no need to write a special ht entry for blind transfer.
For now I'm saving to htable on event_route(dialog:start), and removing on 'end' or 'failure' event. Much cleaner :-D Thanks a lot for the tip.
For "Htable key identify" problem: I've managed to find corresponding keys with 'sht_iterator' in while loop. Matches found with ($(shtitkey(i1){s.select,-1,:} == $rU || $fU). Key values = $shtitval(i1). Not the most elegant solution, imo, but best I can do for now :-D
Haven't got hands on the problem with attended transfer yet. But it's already clear that I've got a huge lack of SIP knowledge. Can't get how custom headers with original call-id and from/to tags can help me with this. Would be very grateful for clarify, if it's possible :-D For now my best idea is to catch indialog 'REFER' with 'Replaces' in 'Refer-to' and write to htable according to its contents (eg, set $fU from RURI and $rU from 'Refer-to').
Anyway, Thanks a lot for your help!
Regards, Tim
чт, 9 сент. 2021 г. в 20:05, Fred Posner <fred@palner.commailto:fred@palner.com>: There's a lot to go through on this example... and many ways to handle such scenarios.
Personally, I very much like the HTABLE approach for "remembering" destinations. Instead of using a BYE to remove the entries, you might see if using DIALOG for this use case to be beneficial (removing the HTABLE entry when all calls are ended).
Depending on how the endpoints are linking attended transfers, you may need to consider adding SIP headers (like X-ORIG-CI) to add a call-id, from tag, or other info to identify original calls.
Again, many different ways that you could approach this, but sounds like you're on the right track for sure.
Fred Posner | palner.comhttp://palner.com Matrix: @fred:matrix.lod.comhttp://matrix.lod.com o: +1 (212) 937-7844
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Regards,
David Villasmil email: david.villasmil.work@gmail.commailto:david.villasmil.work@gmail.com phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users