11 Sep
2021
11 Sep
'21
6:29 a.m.
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(a)gmail.com>gt;:
Wouldn’t dispatching based on user hash solve all
these problems?
On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков <sitdikovt(a)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(a)palner.com>om>:
--
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(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:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(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:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(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:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users