Kalle

Is there any new build with this implemented today? // Kalle

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!

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

Thanks, it worked great with "ordinary" calls. Will test with mex extensions next week off-worktime. // Kalle

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

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

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

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

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

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

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

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

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

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