Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - danje

Pages: [1]
1
Mitel Software Applications / MiContact Centre, Ignite and GDPR
« on: February 11, 2020, 06:30:16 AM »
Hi all,

How are people addressing GDPR requirements with MiContact Center and Ignite? Unless I'm missing something, there isn't any (official) way to purge emails, contacts, telephone records, etc from contact center and data is all over the place - ElasticSearch, SQL Server databases and archived SMDR, ACD and log files.

Mitel have a KB article about scrubbing a contact from MiContact Center and Ignite which deals with the "Right to Erasure" requirement of GDPR: https://mitel.custhelp.com/app/answers/answer_view/a_id/1010075/loc/en_US

The official GDPR guidance is to basically turn off logging which doesn't seem like a viable solution to me.
https://mitel.custhelp.com/app/answers/answer_view/a_id/1010053/loc/en_US

The big thing that's missing however, is the ability to manage log retention. As things stand the system will keep everything for ever which in short means that anyone using Mitel products cannot be GDPR compliant.

Anyone got any solutions?! (other than turn logging off ;-)

Thanks for your help,
Dan.

2
Thanks for your replies.  The serial interface is unresponsive too.  :(  I've managed to schedule a reboot but out of curiosity is there a way to perform a manual reboot from the SX-2000 interface?

3
Hello all,

Here's an interesting one.  The management interfaces for our 3300 MXeIII seem to have locked up.  The web interface is inaccessible (just says "This page cannot be displayed") and the RTC shell seems to be unresponsive - telnet'ing to port 2002 gives me a username and password prompt but after entering those details nothing else happens.  The SX-2000 interface still seems to be responding.  The phones themselves all seem to be working OK, we just can't administer anything!

Does anyone have any idea how I can rescue things without resorting to cycling the power or pressing the reset button?  I'm trying to avoid the likelyhood of any database corruption!

Thanks for your help,
Dan.

4
Hello all,

I have an odd problem with calls apparently randomly jumping between ACD queues.  We have a top level "options" queue with an interflow dial list which feeds into 4 other ACD queues.  Each queue has its own skill group.  We handle around 400 calls a day but every now and again (maybe 10 calls a day), a call will jump from one queue to another.  When I look at the SMDR logs I can see the call come into the options queue and then flow into another queue based on the option the caller has chosen.  Very shortly afterwards (around 10 to 20 seconds) the call will jump to another queue.  The only queue that has an interflow dial list is the first "options" queue.

Has anybody got any ideas what could be causing it?  I'm assuming it's a configuration problem but I can't for the life of me work out what it is.

We're running MCD 6.0 SP2 on a Mitel 3300 MXe-III.

Thanks for your help,
Dan.

5
Hi all,

We created a new agent ID for the user and that appeared to fix the problem - for a couple of days. :(  We set her up from scratch with a new ID, with the same COS and device settings as all the other agents and everything was working, then all of a sudden the problem started again.  I'm starting to think that it might be down to a bug - I'll look into doing a software upgrade.

Thanks for your help,
Dan.

6
Mitel MiVoice Business/MCD/3300 / Re: Record a internal Call
« on: March 08, 2016, 06:14:56 AM »
Hi Anders,

Unfortunately the built-in Record A Call feature can only be used if one of the parties in the call is on a trunk.  Internal calls can be recorded but it requires a 3rd party system which essentially captures SIP/RTP traffic as it traverses the network.

Regards,
Dan.

7
Hi all,

Thanks for your responses.  The COS and COR are the same as the other phones.  The phones are all on the same subnet as the PBX and no firewalls are involved - just a single voice VLAN.  The problem follows the user - if she logs onto a another Agent's phone (which works fine for that agent), she still has the same problem.  I think it's a configuration issue and I suspect it's some weird corruption behind the scenes.  I'll recreate the agent ID see if the problem goes away.  :)

For info we're running version 6.0 SP2 on a 3300 MXe-III.

Thanks for your help,
Dan.

8
Hello all,

I have a really odd problem with one of our call centre agents and one-way audio on transferred calls.  We're using ISDN for inbound and outbound calls.  We have 5 ACD agents all of which are set up identically (or at least appear to be).  They're all using 5320IP phones, all use headsets and have a "Headset" key configured.   For one of the agents however, if she presses the transfer button to put the caller on hold and speak to a 3rd party, the 3rd party cannot hear her until she has pressed the Headset key to turn the headset off, and then on again.  This only happens with external callers that come through the ACD queues - we have been unable to recreate it with internal calls.  It only happens to this agent, regardless of the phone she's logged into (we've even changed the headset!).  I've gone through ACD settings, device settings, station attributes and compared them side by side with the other ACD users and I can't for the life of me work out what's wrong?

Anybody got any ideas?

Thanks in advice for your help,
Dan.

9
Quote from: acejavelin
Oh, and Sonicwall routers... Bad combination with anything SIP, we have had nothing but issues trying to run SIP through a Sonicwall router, even endpoints. Phones would come up and work, but after about 5 minutes into the call the audio would drop. Trunking we always got one-way audio, even for a system that is NAT aware.

Initial testing suggests everything is working OK.  Audio both ways, incomng and outgoing calls, hold, call trading, etc.  I made a call to my mobile for about 20 minutes and didn't seem to have any problems.  Mitel MCD is listed in the SIP combatibility matrix for the PRO3060 and in general we've never had a problem with SonicWALLs (been using them for about 10 years) - I used it mainly because I happened to have a spare one. :)  We'll see how things go - we can always splash out on something with a better reputation if we run into problems. ;)

10
Just thought people might want to know how I actually solved this in the end.  It turns out that you do actually need a gateway that is capable of doing SIP transformations and that it doesn't "just work" as I was constantly being told.  A dropped a spare SonicWALL PRO3060 into the mix and enabled SIP Tranformations and Consistent NAT and everything is magically working.  It's a little bit horrible at the moment as we're double NAT'ing on the CPE router and the firewall, but it proves it works.  My plan is to simplify things by reconfiguring the Cisco router as a bridge using PPPoE on the firewall's WAN interface.  Got there in the end. :-)

11
Thank you everyone for your responses. :)

Quote from: ralph
I think you may be correct here.   Is the SBC on your premises?   I'm thinking your 3300 needs to be pointing the internal interface of the SBC.

We have a router onsite (managed by our SIP provider), but I'm not sure whether that's performing the SBC function as well.  I do know that it is doing 1:1 NAT for the PBX but it isn't doing port forwarding i.e. packets to/from the PBX that traverse the CPE router have their source/destination addresses rewritten but all other traffic is passed through untouched.  Traffic that is sent directly to the LAN interface of the CPE router (e.g. SIP on port 5060) results in an ICMP 70 "destination unreachable" response suggesting to me that port forwarding isn't enabled.  Our SIP trunk provider says that the router only does pass through 1:1 NAT for traffic to/from the PBX.  The router's WAN interface has a public address which is presented as the public PBX address.

Quote from: ralph
Has your VAR verified that the carrier has been verified by Mitel's COE?

I'm not sure but I know they have plenty of other Mitel customers that are using their service and they don't seem to be having any problems. :(

Quote from: bobcheese
media will always be from the endpoint not from the ICP unless you use MBG as a SIP proxy

I've seen a lot of people say something along these lines and in the back of my mind I keep thinking "how can this work without some kind of ALG/proxy?", but our SIP trunk provider assures us that it does, and I know other Mitel customers are using their service without the need for any extra kit.

Quote from: collisionsystm
I recently did an install with Level3 as the SIP Provider. We had a problem where the phones were out-pulsing the Private IP instead of the Public address needed to properly send back. The fix was easy. You use the URI/Number Translation form.

I tried this and it didn't seem to make any difference. :(  Did a packet trace and the contents of the SDP packet remained unchanged - not sure if I'm missing something.

12
Mitel MiVoice Business/MCD/3300 / SIP trunks, SDP and private IP addresses
« on: September 12, 2012, 08:04:08 AM »
Hi all,

I've been struggling with this one for quote a while - our SIP trunk provider says we need to change something on our VMCD, our telephone engineer says there's something wrong with the networking side, and I'm stuck in the middle trying to work out what the problem *actually* is.

This is the scenario...

  • We have a Virtual Mitel Communications Director (Release level 5.0, Active software load 11.0.0.102)
  • We're using 5320IP handsets.
  • I can make calls on the SIP trunk but only the called party can hear audio.
  • I can receive calls on the SIP trunk (using a DID) but only the calling party can hear audio.
  • In a packet trace I can see the RTP packets going out, but nothing ever comes in.
  • In a packet trace I can see the IP address of the SIP provider's media server and the *private* IP address of my 5320 handset.
  • Our SIP provider is using an SBC to manipulate the VoIP traffic.
  • Our VMCD is NAT'd via a router provided by our SIP provider (I'm not sure if this bit of kit does the SBC side of things too).

Our SIP provider says that if we can get the public IP address of the VMCD to be used in the SDP packets instead of the private IP address of the handset, then their SBC should take care of the rest.

So, is this possible?  I can't for the life of me work out how to do it and all the evidence I've found so far suggests that Mitel PBX's will *always* stream the RTP directly between the endpoints and that this behaviour cannot be changed without some kind of ALG.

Anyone got any suggestions? :)

Thanks for your help.

Pages: [1]