[Freeswitch-users] Multiple Registrations or unique SIP credentials for each user device?

Michael Avers michael at mailworks.org
Sun Aug 13 19:25:35 UTC 2017


I'm thinking also I can basically set presence_id=3005 at domain for
inbound/outbound calls to/from any of the 3005_XXX extensions, right? I
tried it and it works for the most part, but the issue is that the
presence for 3005 at domain gets cleared right away but the one for the
actual extension, ie. 3005_APP at domain hangs for a while even after
channel is destroyed. Not sure if it's a bug or not
Mike


On Sun, Aug 13, 2017, at 05:08 AM, Yuriy Gorlichenko wrote:
> I worked with the same logic you described. Regarding presence control
> i used Kamailio server as presence and as registrar server, but in my
> case  wrote my custom logic on SIP layer handling precence (means i
> rewrote presence logic in kamailio and integrated it in .cfg
> kamailio's file). I used kamailio because this is implosible to
> implement on a Dialplan (read as application) layer.> 
> alo you can write your own module for integrate same logic in
> FreeSWTICH but it will be SIP layrer handling anyway.>  
> 
> 2017-08-13 2:16 GMT+03:00 Michael Avers <michael at mailworks.org>:
>> Hello,
>> 
>>  We have customers that currently register their single extension on
>>  their desk phone, mobile softphone, as well as desktop softphone -
>>  and usually they want them all to ring at the same time, which is
>>  easy, we just let them have multiple registrations and it gets the
>>  job done.>> 
>>  However, some customers are asking to have more fine grained control
>>  over which of their devices receive the incoming calls and in what
>>  order. For example they may want the desk phone to ring or 10
>>  seconds and only then start ringing the mobile app, and the desktop
>>  softphone to never ring (they just use it for outbound dialing).>> 
>>  What is the best way to achieve this? I thought about assigning
>>  unique credentials to each device they register on. This would be
>>  fine if I were to direct inbound calls coming on a DID or via an IVR
>>  extension, because I can just ring them as if it was a ring group
>>  and control all the needed requirements with the bridge string.>> 
>>  However, how do I get this to work for local extension to extension
>>  calling? Say their extension should be 3005, but they no longer
>>  register it directly and instead are issued credentials for
>>  3005_DESK at domain, 3005_XYZ at domain and so forth. I can have 3005 be a
>>  dialplan extension that bridges to them, sure.>> 
>>  But then you have presence to deal with, basically when 3005_DESK is
>>  on the phone 3005 at domain presence should indicate that.>> 
>>  Is what I'm asking for possible at all, and if so are there any best
>>  practices to get this working properly? Hope I was clear enough :)>> 
>>  Thanks
>>  Mike
>> 
>>  ___________________________________________________________________-
>>  ______>>  Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>> 
>>  Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>> 
>>  FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>  UNSUBSCRIBE:
>>  http://lists.freeswitch.org/mailman/options/freeswitch-users>> http://www.freeswitch.org
> ___________________________________________________________________-
> ________> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>  
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>  
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170813/6b656e06/attachment.html>


More information about the FreeSWITCH-users mailing list