pbx support Posted May 25, 2012 Report Share Posted May 25, 2012 I think what we will do/verify if we are compliant to the RFC on this. Otherwise, it becomes very difficult to maintain. BTW, can you please explain this setup a bit? ...But it doesn't solve the problem with a mex extension. A mex extension is an outside extension that makes an invite to pbx so trunk needs to redirect. Quote Link to comment Share on other sites More sharing options...
pbx support Posted May 25, 2012 Report Share Posted May 25, 2012 We did a quick test here before knowing what exactly you are doing. Maybe there is something you can try before waiting for the new version. Set 0311234567 600 on the Account number(s): field for 600 (instead of 600 0311234567). Set "Assume that call comes from user:" as 600 The default "diversion_style" is set to tel under pbx.xml file. Change it to sip. You can change this Global setting using http://PBX IP address/reg_index.htm?save=save&diversion_style=sip Make a test call With this you should see the INVITE going out with Diversion: "display name of 600" <sip:0311234567@pbx.company.com>;reason=unconditional;screen=no;privacy=off Let us know how it goes while we are making sure that we are RFC compliant. Quote Link to comment Share on other sites More sharing options...
Kalle Posted May 25, 2012 Report Share Posted May 25, 2012 BTW, can you please explain this setup a bit? Of course, I have a PDF document that explains the MEX signaling. But I need a mailadress where I can send it, don't want to publish it on the forum.... Please PM where to mail it .. // Kalle Quote Link to comment Share on other sites More sharing options...
Kalle Posted May 25, 2012 Report Share Posted May 25, 2012 We did a quick test here before knowing what exactly you are doing. Maybe there is something you can try before waiting for the new version. Set 0311234567 600 on the Account number(s): field for 600 (instead of 600 0311234567). Set "Assume that call comes from user:" as 600 The default "diversion_style" is set to tel under pbx.xml file. Change it to sip. You can change this Global setting using http://PBX IP address/reg_index.htm?save=save&diversion_style=sip Make a test call With this you should see the INVITE going out with Diversion: "display name of 600" <sip:0311234567@pbx.company.com>;reason=unconditional;screen=no;privacy=off Let us know how it goes while we are making sure that we are RFC compliant. Tried from home tonight. Worked great when redirected an extension. Did not need the Trunk->Customer specific header and the Diversion tag looks like it should. However, I can't try with a MEX extension until monday. Need to contact Tele2 customer service so they can activate a cellular phone as MEX. Will get back to you.. // Kalle Quote Link to comment Share on other sites More sharing options...
Kalle Posted May 28, 2012 Report Share Posted May 28, 2012 OK, Tried now with following scenarios: * Trunk set to "Accept Redirect" : Redirection works from extension = OK, Mex extension calls extension = Not OK, Mex extension calls external number = Not OK * Trunk set to "Accept Redirect" and "Assume that call comes from user: 600" : Redirection works from extension = OK (But wrong caller ID), Mex extension calls extension = OK (But wrong caller ID) Mex extension calls external number = Almost OK, You don't get any sound from external phone to Mex extension (Except from DTMF ...? Something strange with rtp One more downside: Every incoming call to PBX gets the callerid of 600. // Kalle Quote Link to comment Share on other sites More sharing options...
pbx support Posted May 29, 2012 Report Share Posted May 29, 2012 Did not need the Trunk->Customer specific header and the Diversion tag looks like it should. // Kalle The "Trunk->Customer specific header" was set to empty in our tests (note that this header is used if the call is outbound on that trunk. In this case, we are doing the inbound). "Trunk->Accept Redirect" was to "No". The invite to the destination (either to an extension or to an external number) had "From" header as original "from" header and "Diversion" as the DID of the 600 (in this case 0311234567). Quote Link to comment Share on other sites More sharing options...
Kalle Posted May 29, 2012 Report Share Posted May 29, 2012 The "Trunk->Customer specific header" was set to empty in our tests Yes, "Trunk->Customer specific header" was empty in my test also. But without "Trunk->Accept Redirect = Yes" it doesn't add a diversion tag at all. // Kalle Quote Link to comment Share on other sites More sharing options...
Kalle Posted June 12, 2012 Report Share Posted June 12, 2012 OK, Tried now with following scenarios: * Trunk set to "Accept Redirect" : Redirection works from extension = OK, Mex extension calls extension = Not OK, Mex extension calls external number = Not OK * Trunk set to "Accept Redirect" and "Assume that call comes from user: 600" : Redirection works from extension = OK (But wrong caller ID), Mex extension calls extension = OK (But wrong caller ID) Mex extension calls external number = Almost OK, You don't get any sound from external phone to Mex extension (Except from DTMF ...? Something strange with rtp One more downside: Every incoming call to PBX gets the callerid of 600. // Kalle Had some time to look at this again. Really want it to work. Seems like tag mex>external number = No sound was that From tag had mex ip as sender.. Should have been snomPBX ip. Will try that and see.. However I also noticed that when Trunk set to "Accept Redirect" and "Assume that call comes from user: 600" also every incoming call gets the Diversion tag on it - that's why the incoming callerid is screwed up i guess. Maybe it would be a alternative to have a "incoming route" function in snomONE that lets you do the same thing as the new header feature but on incoming and route the call like the outgoing dial plan. // Kalle Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 12, 2012 Report Share Posted June 12, 2012 It is very hard to match every possible combinations of providers. Many times "more settings = more confusion". The "assume call coming from user" is used for the incoming calls to overwrite the "From" user. This definitely has impact on the caller id. Quote Link to comment Share on other sites More sharing options...
Kalle Posted June 13, 2012 Report Share Posted June 13, 2012 It is very hard to match every possible combinations of providers. Many times "more settings = more confusion". Yes, I understand that and respect it. However, MEX and this scenario is a common way in Sweden to integrate cell phones as extension. I am a reseller of Snom products and usually we integrate Asterisk solutions in this kind of setup. But I rather use snomOne because of the greate pnp functionality and the ease of install. For that I need some kind of MEX support. I will do a new test in a few days and play around with custom header settings and see if I can get the sound to work. I also need to now if snomOne team is interested in make it work and if so I will do everything I can to help and of course a happy beta user ;-) // Kalle Quote Link to comment Share on other sites More sharing options...
jim@itstod.se Posted June 13, 2012 Report Share Posted June 13, 2012 Yes, I understand that and respect it. However, MEX and this scenario is a common way in Sweden to integrate cell phones as extension. I am a reseller of Snom products and usually we integrate Asterisk solutions in this kind of setup. But I rather use snomOne because of the greate pnp functionality and the ease of install. For that I need some kind of MEX support. I will do a new test in a few days and play around with custom header settings and see if I can get the sound to work. I also need to now if snomOne team is interested in make it work and if so I will do everything I can to help and of course a happy beta user ;-) Couldn't agree more. As Kalle says, to sell big in Sweden we need to be able to offer MEX functionality. Our competitors (LG/Ericsson, Avaya, Telepo etc.) has it and all major telecom operators offer it via ISDN and SIP trunks combined with GSM/3G for the mobile phones. I understand that the Scandinavian market may not be very big, but other vendors like Avaya have found it worth to build in support for it in their software . Best regards, Jim Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 14, 2012 Report Share Posted June 14, 2012 Yes, I understand that and respect it. I also need to now if snomOne team is interested in make it work and if so I will do everything I can to help and of course a happy beta user ;-) // Kalle Ok, We will take another swing at it. We will try to make the diversion header flexible and editable like the other headers so that you have more control on it. Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 15, 2012 Report Share Posted June 15, 2012 What OS version PBX are you running? We can provide you with a test version and see it works for you folks @Sweden and not have any other issues. Quote Link to comment Share on other sites More sharing options...
Kalle Posted June 15, 2012 Report Share Posted June 15, 2012 What OS version PBX are you running? We can provide you with a test version and see it works for you folks @Sweden and not have any other issues. CentOS64 I'm working on that PDF document for you. I noticed that it was in Swedish so I will put in some english words in it... // Kalle Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 18, 2012 Report Share Posted June 18, 2012 Sent(PM) you the new version. In case if someone else wanted to try the centos64 bit version please go ahead - http://downloads.snom.net/snomONE/centos64/v4.5/pbxctrl-centos5-4.5.0.1086_beta There is a new "Diversion header" that you can use. You still need to use "Accept Redirect" (for the backward compatibility). In the next major version (may be in 3-6 months), we may clean up some of the settings to make it simpler to use. Quote Link to comment Share on other sites More sharing options...
Kalle Posted June 29, 2012 Report Share Posted June 29, 2012 Sent(PM) you the new version. In case if someone else wanted to try the centos64 bit version please go ahead - http://downloads.snom.net/snomONE/centos64/v4.5/pbxctrl-centos5-4.5.0.1086_beta There is a new "Diversion header" that you can use. You still need to use "Accept Redirect" (for the backward compatibility). In the next major version (may be in 3-6 months), we may clean up some of the settings to make it simpler to use. Thanks, it worked great with "ordinary" calls. Will test with mex extensions next week off-worktime. // Kalle Quote Link to comment Share on other sites More sharing options...
Kalle Posted July 4, 2012 Report Share Posted July 4, 2012 Will test with mex extensions next week off-worktime. // Kalle Yes, MEX worked ok also. The previous problem with no sound was that PBX used PCMU for incoming and PCMA for outgoing and couldn't transcode. But when after force PCMU everything went fine. Now I only have one request and in my world it would be a all ok MEX solution: When calling from MEX the trunk should choose "Assume that call comes from user:" the MEX user. Then BLF should signal that the extension is busy. So my mind says: IF [from] = Extension Cell phone number then [Assume that call comes from user:] = Extension ELSE [Assume that call comes from user:] = 0319999600 Easy heh? // Kalle Quote Link to comment Share on other sites More sharing options...
Kalle Posted July 4, 2012 Report Share Posted July 4, 2012 So my mind says: IF [from] = Extension Cell phone number then [Assume that call comes from user:] = Extension ELSE [Assume that call comes from user:] = 0319999600 If I hardcode a Extension on [Assume that call comes from user:] it is also possible to Retrieve/Move current call to/from cellphone to/from that extension. So this is can be really great! Quote Link to comment Share on other sites More sharing options...
Kalle Posted August 14, 2012 Report Share Posted August 14, 2012 So my mind says: IF [from] = Extension Cell phone number then [Assume that call comes from user:] = Extension ELSE [Assume that call comes from user:] = 0319999600 Is there any new build with this implemented today? // Kalle Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.