Kalle
-
Posts
20 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Kalle
-
-
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!
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
BTW, the person who transfers the call can just hangup before the call is answered. In that case it will still behave like before.
We got a prompt that said something like "This is not possible at the moment" before it hanged up. Doesn't remember more and we downgraded to 1030. Will try next version and get back to you then.
// Kalle
-
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
- Set 0311234567 600 on the Account number(s): field for 600 (instead of 600 0311234567).
-
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
-
Let's consider this case. For this to work as you expected, you can make use of the "Trunk->Customer specific header (Example: X-snom: my header")".
- Set the "Extension->ANI" to 0319999605.
- Set the "trunk->accept redirect" to "No"
- Set the "Trunk->Customer specific header (Example: X-snom: my header")" to "Diversion:<{ext-ani}@{domain}>;reason=unconditional;screen=no;privacy=off". Note: if you want the trunk's domain to go out in the INVITE, then you can use {trunk-host} instead of {domain}
Thanks for your suggestion.
But I have already tried that as you can see in a previous post. It does make it ok with calls redirected by extension. 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. And to make that work the trunk needs to accept redirect. With the extra "Customer specific header" the invite will then have two Diversion tags.. The "Customer specific header" also adds Diversion tag to every outbound call.
I am not sure that my suggestion will be the best or even work but I think that a possibility to edit the DIversion tag that "Accept Redirect" makes would solve it.
// Kalle
- Set the "Extension->ANI" to 0319999605.
-
I would like to provide some background information about some changes we did in the transfer area. Attended transfer is all fine and we did not touch it; however for the blind transfer we felt that the blind transfer had to be improved.
The overall problem with the blind transfer is that it might fail. That is very unsatisfactory for the one who called into the system. The one who initiates the transfer must know if the transfer failed, and if that is the case the call should not be just disconnected (callers thrown out of the system), but the call should get back somehow. If you want, the PBX is overlooking the blind transfer and if something goes wrong make sure that the call does not get lost. The answer is to use a temporary conference where the transferer is part of that conference until the call is successfully transferred, especially the transferer can hear if there is a ringback tone after the transfer and then get out of the conference. I believe that is a huge improvement compared to the situation when you never know if the transfer worked or not.
Maybe we should involve the marketing department. They might propose to rename the blind transfer to automatic transfer, because there is a machine (the PBX) taking care about the details.
Hi, Great feature!
But we have noticed when doing a "automatic"transfer to a agent group the one who transfers get "stuck" until someone answers.. We had to downgrade to 4.5.0.1030 to fix that.
Maybe there should be a setting for this or if possible some rule that it handles a blind transfer the "old" way if a agent group is the destination.
// Kalle
-
Could you please post an INVITE that you want the PBX to send out? We can take a look at it and try to setup the trunk.
Of course, here are some examples, (Incoming number: 0701123456, 0319999600 is PBX main number)
This is how it should be (Redirected extension 605 to 03190510) :
INVITE sip:03190510@sip-corporate.tele2.se;user=phone SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK-581023b173c2c5c06625917d317d58d8;rport
From: "0701123456" <sip:0701123456@pbxdomain;user=phone>;tag=1875464570
To: "Kalle" <sip:0319999605@pbxdomain;user=phone>
Call-ID: 538c560f@pbx
CSeq: 30914 INVITE
Max-Forwards: 70
Contact: <sip:T2username@x.x.x.x:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: snomONE/4.5.0.1075 Delta Aurigids
In-Reply-To: 121c9d0b-30877060-5b153ef4-966d@212.151.144.8
P-Charging-Vector: icid-value=;icid-generated-at=x.x.x.x;orig-ioi=pbxdomain
Diversion: <0319999605@sip-corporate.tele2.se>;reason=unconditional;screen=no;privacy=off
Content-Type: application/sdp
Content-Length: 384
This is how it looks like now (Redirected extension 605 to 031901510) :
INVITE sip:03190510@sip-corporate.tele2.se;user=phone SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK-5230ea360fea69aa482013409b20702f;rport
From: "0701123456" <sip:0701123456@pbxdomain;user=phone>;tag=1665200458
To: "Kalle" <sip:0319999605@pbxdomain;user=phone>
Call-ID: 29b484c9@pbx
CSeq: 24105 INVITE
Max-Forwards: 70
Contact: <sip:T2username@x.x.x.x:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: snomONE/4.5.0.1075 Delta Aurigids
Diversion: <tel:605>;reason=unconditional;screen=no;privacy=off
In-Reply-To: 21b0e110-473abd9c-1c04c0-9210@212.151.144.8
P-Charging-Vector: icid-value=;icid-generated-at=x.x.x.x;orig-ioi=pbxdomain
Content-Type: application/sdp
Content-Length: 388
Redirected on trunk (MEX, 600 is put as "Assume that call comes from user:", 600 has 0319999600 as ANI, X92A in To is a prefix that Tele2 adds because of MEX service.) :
[5] 20120503082027: SIP Tx udp:130.244.190.42:5060:
INVITE sip:03190510@sip-corporate.tele2.se;user=phone SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK-60d3f42be369987eb80c3ab60c68e748;rport
From: "0701123456" <sip:0701123456@212.151.144.8;user=phone>;tag=1033792167
To: "X92A03190510" <sip:X92A03190510@pbxdomain;user=phone>
Call-ID: e7bbc063@pbx
CSeq: 29992 INVITE
Max-Forwards: 70
Contact: <sip:T2username@x.x.x.x:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: snomONE/2011-4.5.0.1050 Coma Berenicids
Diversion: <tel:600>;reason=unconditional;screen=no;privacy=off
In-Reply-To: 5c1c7fa9-12e21f60-459e15ee-982d@212.151.144.8
P-Charging-Vector: icid-value=;icid-generated-at=x.x.x.x;orig-ioi=pbxdomain
Proxy-Authorization: Digest realm="sip-corporate.tele2.se",nonce="4fa223e6000010847adfab1f8ba6ec7ed797eb8881d4f73f",response="92f40ba7fa5d749cd3abbc6fa796e4da",username="T2username",uri="sip:03190510@sip-corporate.tele2.se;user=phone",algorithm=MD5
Content-Type: application/sdp
Content-Length: 388
// Kalle
-
I thought that the new header feature is able to take care about this?
Yes, It does almost. Before we wasn't able to redirect calls at all. But it does not take care of the Diversion tag.
// Kalle
-
Did you try setting 0311234567 as the ANI on the extension 600? Your case may be different from Jim's, not sure.
What Jim wanted earlier was sort of a 2 stage dialing in 1 step, if I remember correctly. Ex: the access number and the destination number will be passed in the same INVITE and PBX "somehow" accepts the call and dials out the destination number.
Yes, I do have 0311234567 as ANI on extension600.
// Kalle
-
OK, I have "played" some with at Tele2 MEX cell phone. I get the same result as Jim but this is because Tele2 doesn't accept redirects or other calls with somebody elses from: header. So the diversion tag is important.
We have since earlier used a "Customer specific header (Example: X-snom: my header)" on trunk with : "Diversion: <{trunk-ani}@{trunk-host}>;reason=unknown" because if not we get "SIP/2.0 403 Call did not pass A-number check" after invite (If we want to send incoming calls a-number when we want to redirect a call to cell - and that we want!)
I think it is the same with Jim's example AND our own problem that when a MEX connected cellphone calls it makes a invite to PBX and then the PBX handles it as a redirect.
To make that get accepted by Tele 2 we need to "Accept Redirect:" in trunk and set our A-number connected to Tele2 account in "Assume that call comes from user:".
BUT then PBX sends extension number 600 instead (because the account is 600 0311234567). And the formatting of the Diversion tag that "Accept Redirect:" uses seems to not be accepted by Tele2. PBX sends: "Diversion: <tel:600>;reason=unconditional;screen=no;privacy=off" Should be: "<0311234567@sip-corporate.tele2.se>;reason=unknown"
So it would be nice to in section Routing/Redirection if it was possible to set our own Diversion tag? Then the call should be routed correctly and SnomOne is working with Tele2 MEX. And maybe it also signals on BLF? ;-)
Please - if you need any testpilot to make this work: I'm in!
Regards // Kalle
Some more comments of this or am I way off in my mind?
// Kalle
-
We realized that it is not as 'easy' as we thought. So, it is not added to the software yet
OK, I have "played" some with at Tele2 MEX cell phone. I get the same result as Jim but this is because Tele2 doesn't accept redirects or other calls with somebody elses from: header. So the diversion tag is important.
We have since earlier used a "Customer specific header (Example: X-snom: my header)" on trunk with : "Diversion: <{trunk-ani}@{trunk-host}>;reason=unknown" because if not we get "SIP/2.0 403 Call did not pass A-number check" after invite (If we want to send incoming calls a-number when we want to redirect a call to cell - and that we want!)
I think it is the same with Jim's example AND our own problem that when a MEX connected cellphone calls it makes a invite to PBX and then the PBX handles it as a redirect.
To make that get accepted by Tele 2 we need to "Accept Redirect:" in trunk and set our A-number connected to Tele2 account in "Assume that call comes from user:".
BUT then PBX sends extension number 600 instead (because the account is 600 0311234567). And the formatting of the Diversion tag that "Accept Redirect:" uses seems to not be accepted by Tele2. PBX sends: "Diversion: <tel:600>;reason=unconditional;screen=no;privacy=off" Should be: "<0311234567@sip-corporate.tele2.se>;reason=unknown"
So it would be nice to in section Routing/Redirection if it was possible to set our own Diversion tag? Then the call should be routed correctly and SnomOne is working with Tele2 MEX. And maybe it also signals on BLF? ;-)
Please - if you need any testpilot to make this work: I'm in!
Regards // Kalle
-
Hi again,
I thought I would give this a new shot now after the summer holidays. Our hosted competitors in Sweden has this functionality and it is highly requested by customers.
Using version 2011-4.3.0.5002 (Win64).
In this example I am calling 90400 from my mobile phone. The VoIP provider routes the call to our SIP trunk and puts a "C945" prefix in the To section but we want to use Request URI so this does not matter. What I am trying to achieve is that:
- The call should be routed back to the VoIP provider and my extension should show as busy on my colleagues phones busy lamp fields (since 0709355940 is the mobile phone number set on my extension).
- My extension ANI should be showed to the person I am calling (SIP From field I suppose), not my mobile phone number.
Here is what happens:
[8] 2011/07/27 23:55:15: Incoming call: Request URI sip:90400@46.59.77.70;user=phone, To is "C94590400" <sip:C94590400@sip-corporate.tele2.se:5060;user=phone>
[8] 2011/07/27 23:55:15: Call from a trunk 1
[8] 2011/07/27 23:55:15: Trunk Tele2 SIP Trunk@sip.itstod.se has country code 46, area code 501
[9] 2011/07/27 23:55:15: Incoming: formatted From is = "0709355940" <sip:+46709355940@212.151.144.8:5060;user=phone>
[9] 2011/07/27 23:55:15: Incoming: formatted To is = "C94590400" <sip:C94590400@sip-corporate.tele2.se:5060;user=phone>
[9] 2011/07/27 23:55:15: Incoming: formatted URI is = sip:90400@sip.itstod.se;user=phone
[8] 2011/07/27 23:55:15: To is "C94590400" <sip:C94590400@sip-corporate.tele2.se:5060;user=phone>, user 0, domain 1
[8] 2011/07/27 23:55:15: Send call to extension is not set. Route the call based on global number 90400
[4] 2011/07/27 23:55:15: Domain trunk Tele2 SIP Trunk@sip.itstod.se could not identify user for 90400
The PBX is not routing the call out to the VoIP provider, why?
Regards,
Hi!
Is this possible (fixed) today with snomONE?
LED status on cell calls
in Using Cell Phones
Posted
Is there any new build with this implemented today?
// Kalle