Jump to content
KAZOOcon: hackathon signup and details here! ×

Sip URI?


Rick Guyton

Recommended Posts

Is there a way to connect from an external system using a SIP URI instead of a DID? For example if I have a device setup as user_2484 on a realm RingMe.mydomain.com, can I route calls to user_2484@RingMe.mydomain.com? Is there another way to do something similar? I know there's a SIP URI "device" but it seems silly to have to setup a whole new device for this.
Link to comment
Share on other sites

  • Administrators
If you're trying to have an external system call into Kazoo without authentication and via SIP URI, that is not currently possible.

If you're trying to have an extension number that is dialed by a customer map to an external system via a SIP URI, then yes, create a device for each one, that's the way to go. And yes you have to do it for each extension.
Link to comment
Share on other sites

  • Administrators
Correct, not at this time.

The main issue is that we'd have to open up inbound calling to every IP on the internet, which makes it super easy to DOS the system.

We may address this shortly with a new product offering where attacks can be isolated to a single reseller. Stay tuned. But for now, no on inbound, only outbound.
Link to comment
Share on other sites

A use case for us is management companies that own multiple businesses.  So for example, we have one company with 4 separate car lots and a corporate office.

We are also in talks with a medical company that has 3-4 business entities and will will be opening up "nerve centers" across the country.

It would be nice if we could always create separate accounts for billing, limits, and tracking yet still create and manage call flows with multiple accounts and perform extension to extension dialing when necessary.
Link to comment
Share on other sites

Yes, for us it's for extension to extension dialing between accounts. For us there's a two fold need. First, one of our clients keeps buying out other smaller businesses. If we could set them up on their own account we could retain their existing extension numbers, mailbox numbers, ect. All while allowing them to dial out to other accounts. This also prevents them from for example intercomming the CEO. (Yea, that happened) Second, it allows location managers to manage their own systems via SmartPBX without messing with other locations. This is a really big need for us.
Link to comment
Share on other sites

  • Administrators
Would it be agreeable if we built a module to simply allow calling between two accounts by extension-dialing?

This means:
* No BLF between the accounts
* No shared parking lots
* No shared call centers
* No shared intercom/paging
* Conference bridges could be used by both parties though
* No detection of overlapping feature codes / extensions (will prefer the local configuration first, then failback to other accounts)

Might be other caveats.
Link to comment
Share on other sites

Well, in a best case senario, it'd be nice to be able to have conflicting EXTs call eachother somehow. For example if ext 100 in accountA called 100@accountb.domain.com or *FETCODEFORACCOUNTB100.

But, all the other "caveats" you've listed would actually be very beneficial to us. I mean it'd be nice if they could see BLF. But, I can code around that workign directly with the phones.
Link to comment
Share on other sites

  • 2 weeks later...
So, I've been thinking about this a lot. Ya know, if there are conflicting extension numbers, there's a really easy work around for this. You could just add the star coded extension in the parent account. For example, If you have ext 100 in ClientAccount1, and another ext 100 in ClientAccount2 you could just add *60100 to the ext 100 callflow in ClientAccount1, then *61100 in ClientAccount2. If a user inside either account dialed 100, it'd goto THEIR ext 100. But, ClientAccount2 could dial *60100, it wouldn't be valid in their account, so it'd go searching in ClientAccount1, find it then route it.

So, nevermind my last post, I think all you caveats would be fine. How do we get this ball rolling?
Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...
  • 1 month later...
We've just received a request from a customer requesting their PBX user's SIP URI information as they are setting up Salesforce call logging.  

I know there are connectors that can be used for Salesforce auto call logging.  We have used gUnify in the past and Tenfold(Callinize) is doing some of this but have not used them yet.  
Link to comment
Share on other sites

Using schema callflows.resources.json, would it be possible to add something like to_sip_url ? This way we can configure:

From account to account
{"module":"resources"  ,"data":{    "to_sip_url":"xxx@realm.com"    ,"use_local_resources":true  } }<br id="null"><br id="null">// external (global)<br id="null">{"module":"resources"  ,"data":{    "to_did":"xxx@domain.com"    ,"use_local_resources":false  } }
Link to comment
Share on other sites

  • 2 years later...
  • 4 years later...

Bump. I'd like to see this feature in some form or another, as I think it would be of benefit. Could someone from 2600Hz give a status update on it, or let us know if it has been canned/superseded/implemented some other way possibly?

Link to comment
Share on other sites

×
×
  • Create New...