[SR-Users] Kamailio dispatcher -> FreeSWITCH transfers handling.

David Villasmil david.villasmil.work at gmail.com
Fri Sep 10 23:14:51 CEST 2021


Wouldn’t dispatching based on user hash solve all these problems?

On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков <sitdikovt at 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 at 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 at 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 at 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 at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210910/e4f98065/attachment.htm>


More information about the sr-users mailing list