Jump to content

DECT and other extensions - M9?


UKenGB
 Share

Recommended Posts

I am configuring snomONE with a Snom M9 and several softphones and I'm after some ideas about how best to integrate a DECT system into the whole setup. In particular Intercom between extensions.

 

Any DECT system will have some method of calling other extensions and snomONE has its Intercom feature, but the latter only works between handsets NOT registered to the same extension. So in theory, I could have ALL the M9 handsets on one extension and they could use snomONE Intercom to call any of the softphones, but NOT any of the other M9 handsets. But the M9 handsets could use their own internal calling to other handsets.

 

However, although that maybe covers all requirements, it needs 2 different methods to make the Intercom call (I assume) so you need to know where the recipient is before calling, which may well defeat the object of calling in the first place.

 

So has anyone gone down this route? What would be the best way to integrate the 2 requirements so that Intercom is possible between any 'clients' (i.e. M9 handset, or softphone), but using the same method of calling so users only need to know ONE way to call another client? What about trying to call ALL the other clients if you don't know where the intended recipient is.

 

How have others achieved this?

Link to comment
Share on other sites

The word "intercom" is used in different ways. In the snom ONE PBX world it means "call an extension and have it pick up immediately in handsfree mode". In the snom m9 world, it means "call another handset on DECT without bothering the SIP world (but have the handset ring)".

 

The m9 model is that every handset is a different extension. The users don't have to know that it all runs on the same base station. I would keep it this way, if you register everyone on the same extension this is pretty chaotic (also the PBX limits the number of registrations per extension by default to 5), and you cannot call from one handset to another except using the "m9 intercom" feature.

Link to comment
Share on other sites

The word "intercom" is used in different ways. In the snom ONE PBX world it means "call an extension and have it pick up immediately in handsfree mode".
So it's just 'Paging' really? How can you use the PBX to just ring another extension (ignore multiple registrations) in the same way as in the DECT world?

 

The m9 model is that every handset is a different extension. The users don't have to know that it all runs on the same base station. I would keep it this way, if you register everyone on the same extension this is pretty chaotic (also the PBX limits the number of registrations per extension by default to 5), and you cannot call from one handset to another except using the "m9 intercom" feature.
Overall, the problem I am trying to get my head around is how best to integrate an M9 into the snomONE setup alongside other NON M9 SIP clients (be that softphones or even other Snom SIP hardware). Mainly this involves figuring out how to perform tasks like Intercom and Call Transfer. While both the PBX and the M9 have ways to do this, they require different methods of operation which is not ideal. I see that the M9 setup includes an option to specify it is being used with snomONE, but how does that modify the M9's behaviour?

 

Whilst I can see some advantages of every handset (M9 and other) having its own extension, there are obvious disadvantages to that, not least of which is the licensing limitation on the total number of extensions. Also, the M9 itself provides most of the functionality that would be gained by using separate extensions. In fact the DECT handsets provide simple Menu operation of Intercom and transfer instead of additional numeric dialling to achieve the same result using the PBX. I was not thinking of putting everything onto one extension, but maybe assign the M9 in that way and use separate extensions for the other SIP clients.

 

Truth is, I'm still not 100% sure of the best way to achieve integration between the PBX and the M9 - hence my request for others' suggestions and ideas.

Link to comment
Share on other sites

So it's just 'Paging' really? How can you use the PBX to just ring another extension (ignore multiple registrations) in the same way as in the DECT world?

 

Just call the extension with the extension number. For example, if you want to ring extension 40, dial "40". For a PBX "intercom" you would have to dial *9040 and have the permission to do that.

 

Overall, the problem I am trying to get my head around is how best to integrate an M9 into the snomONE setup alongside other NON M9 SIP clients (be that softphones or even other Snom SIP hardware). Mainly this involves figuring out how to perform tasks like Intercom and Call Transfer. While both the PBX and the M9 have ways to do this, they require different methods of operation which is not ideal. I see that the M9 setup includes an option to specify it is being used with snomONE, but how does that modify the M9's behaviour?

 

Many people believe that they have a 1:1 relationship between base station and handset. This is not true. The base station can be more seen like a switch that converts DECT to Ethernet. The base can maintain a registration for each handset.

 

The beauty of this is that handsets are relatively cheap and if budget is really low (and features like address book integration don't count) you can take other dirt cheap DECT handsets and register them with the base as well.

 

Truth is, I'm still not 100% sure of the best way to achieve integration between the PBX and the M9 - hence my request for others' suggestions and ideas.

 

No problem. Different scenarios require different solutions. For example, at home you would register two or more handsets with the same SIP account and they will ring on incoming calls at the same time; this is the typical DECT deployment in many many installations. But in a business where you want to be able to control which exact handset is ringing, you probably better give each of them its own SIP identity.

Link to comment
Share on other sites

Different scenarios require different solutions. For example, at home you would register two or more handsets with the same SIP account and they will ring on incoming calls at the same time; this is the typical DECT deployment in many many installations. But in a business where you want to be able to control which exact handset is ringing, you probably better give each of them its own SIP identity.

Oh yes I agree, in a business environment, each with its own extension is best, but then it's reasonable to assume they will be paying for the Blue or Yellow versions to get sufficient extensions - unlike the home user. But I want to be conversant with both scenarios and understand the optimum configuration in each instance.

 

However, there is still an issue with lack of integration between the DECT and the SIP domains. Even with a PBX extension for each handset, once you add in additional SIP (non DECT) clients, the connectivity between them all is not uniform - unless you completely eschew any DECT functionality and rely entirely on SIP/PBX intercom and transfer, which would be a shame because the DECT version is easier to use as you don't have to remember esoteric numbering to do it.

 

This is how I would 'want' to see it done:-

 

When the M9 is configured with snomONE, the PBX tells the M9 about the additional (non DECT, i.e. softphones or other SIP clients) extensions it has and the M9 then adds these to its list of known 'handsets'. So when an internal call or transfer needs to be made, the M9 handset user simply uses the standard M9 methods of doing this, but the list of 'handsets' that is presented also includes those other SIP clients which can be selected and used as if they were other M9 DECT handsets. In this way, the integration between the 2 systems would be TRANSPARENT, which is how it should be.

 

The problem is of course that we are dealing with 2 entirely different systems, but this should be hidden from the user as illustrated above.

 

In any case, what about Address Books?

 

Should the M9 be configured with VCARDs or should a SCSV file (SemiColon Separated Variables) be prepared and imported into snomONE? Or both? The lack of consistency here is clear, but it is not even obvious in which location is it best to put such data.

 

Maybe that's a different topic (unless you want to cover it here :-)

Link to comment
Share on other sites

However, there is still an issue with lack of integration between the DECT and the SIP domains. Even with a PBX extension for each handset, once you add in additional SIP (non DECT) clients, the connectivity between them all is not uniform - unless you completely eschew any DECT functionality and rely entirely on SIP/PBX intercom and transfer, which would be a shame because the DECT version is easier to use as you don't have to remember esoteric numbering to do it.

 

When registered to the PBX, I would forget about the ability in DECT to talk directly. "So what"! Especially when in the LAN, bandwidth cannot be the issue.

 

When the M9 is configured with snomONE, the PBX tells the M9 about the additional (non DECT, i.e. softphones or other SIP clients) extensions it has and the M9 then adds these to its list of known 'handsets'. So when an internal call or transfer needs to be made, the M9 handset user simply uses the standard M9 methods of doing this, but the list of 'handsets' that is presented also includes those other SIP clients which can be selected and used as if they were other M9 DECT handsets. In this way, the integration between the 2 systems would be TRANSPARENT, which is how it should be.

 

Ehh. So you mean the m9 should have an internal dial plan that says if you can this and that extension, go there directly? What about CDR then? And what if call recording was enabled or the call gets put on hold and you should hear the music on hold? Barge in? I would say it is easier to run all the stuff through the PBX...

 

Should the M9 be configured with VCARDs or should a SCSV file (SemiColon Separated Variables) be prepared and imported into snomONE? Or both? The lack of consistency here is clear, but it is not even obvious in which location is it best to put such data.

 

The idea was to use LDAP for this. The address book sounds like a simple topic, but the lack of the "one" standard in the real life makes things complicated. LDAP is good if you don't want to replicate the data all the time; just keep everything in a central place; the PBX is just the fallback in this case and you'll have the same address book on your DECT device that you might also have on your desktop device (useful when you have them both registered to the same extension).

 

One of the interesting points about the address book is that it can store images. The m9 supports the photo caller ID ("poor mans video telephony"), and when extensions have their pictures uploaded you can see who is calling you.

 

But thanks to the smart phone, that model of the centralized address book is becoming obsolete these days. Seems that in the future we have to think about synchronizing address books between the devices :rolleyes: . Anyway, thats work in progress.

 

Maybe that's a different topic (unless you want to cover it here :-)

 

Why not!

Link to comment
Share on other sites

The idea was to use LDAP for this. The address book sounds like a simple topic, but the lack of the "one" standard in the real life makes things complicated. LDAP is good if you don't want to replicate the data all the time; just keep everything in a central place; the PBX is just the fallback in this case and you'll have the same address book on your DECT device that you might also have on your desktop device (useful when you have them both registered to the same extension).

 

One of the interesting points about the address book is that it can store images. The m9 supports the photo caller ID ("poor mans video telephony"), and when extensions have their pictures uploaded you can see who is calling you.

 

But thanks to the smart phone, that model of the centralized address book is becoming obsolete these days. Seems that in the future we have to think about synchronizing address books between the devices :blink: . Anyway, thats work in progress.

 

Why not!

So it would be reasonable to ignore address books on the PBX and set up LDAP access on the M9 and let the soft phones use whatever they have?

 

This would be good since the soft phones would all have access to appropriately shared address books which could also sync to the LDAP server. IOW, you could set up a system that required no manual updating. Yes?

 

What about CardDAV?

Link to comment
Share on other sites

So it would be reasonable to ignore address books on the PBX and set up LDAP access on the M9 and let the soft phones use whatever they have?

 

This would be good since the soft phones would all have access to appropriately shared address books which could also sync to the LDAP server. IOW, you could set up a system that required no manual updating. Yes?

 

What about CardDAV?

 

We have seen CardDAV. Nice standard, but who supports it?

 

The topic remains messy. The "addressbook" as such does not exist, it is a scattered database with a lot of local copies in all kinds of formats. Therefore, there is no simple answer for this. The only common dominator that I spotted to far is vCard, so whatever we do in the future will probably try to use this format as much as possible.

Link to comment
Share on other sites

We have seen CardDAV. Nice standard, but who supports it?
Well, Apple for a start, but I'm sure there are others now and more in the future.

 

The topic remains messy. The "addressbook" as such does not exist, it is a scattered database with a lot of local copies in all kinds of formats. Therefore, there is no simple answer for this. The only common dominator that I spotted to far is vCard, so whatever we do in the future will probably try to use this format as much as possible.
I agree that it is a messy subject and hard to resolve for all parties concerned.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...