3300 and Office 365 not using NuPoint

[doctora]

We have voicemail with Office 365 using a mediant 1000 gateway.  Everything works well except when we set the auto attendant to transfer a call instead of leave a message.  The call gets transferred as expected and if the person receiving the call does not answer it the call goes to their voicemail as expected but if the person does answer the call they hear static. 

We are unsure what the 3300 needs to see in order to transfer the call.  We are able to log the packets as they pass through the mediant 1000.  If someone knows something about the transfer process and could just shed some light on that we might be able to trouble shoot this on our own.

Thanks in advance.

[acejavelin]

I assume these are SIP extensions to the Mitel? Did you program a second multicall key on each of the SIP devices in the Mitel?

[doctora]

Thank you for your response.

All of our extensions are on DNI(4015 or 4025) phones.  No sip phones. 

I added the multi call to my phone and tested and I still get the static if I answer a transferred call from voicemail. 

[acejavelin]

No, I mean your office365 voicemail extensions... they are SIP extensions, correct? In the key programming of those SIP extensions, key 2 should be a multicall of the prime DN.

[bluewhite4]

Ace,
I'm going to assume that using Office365 is similar to using Exchange UM a few years ago, and that the voicemail ports are actually SIP trunk ports. So a call routed to or from the Office365 UM voicemail is trans-versing those SIP trunk Groups.

My guess for the static would be that Office365 is using the wrong codec type for the audio. Not sure. You'd probably be best served by getting a wireshark trace of the traffic.

[doctora]

Thanks for both replies.

acejavelin. 

I am not sure what you mean.  we associate a phone extension with a mailbox but we don't do any configuration of the number in office 365.  The configuration of the extensions is in the 3300.  I apologize if I am missing something.  Please try and explain again if I am.

bluewhite4

We changed the audio codec in the dial plan under settings to mp3 and WMA with no positive results.  We left it set to mp3.   I am working with someone on this and we were wondering if you meant in the Office 365 or in the Audio codes box. Please clarify.

Thanks again
Mark.

[bluewhite4]

Well the MP3/WMA would be the audio type of the voicemail message itself I would think.

I was referring to the codec on the Audio codes box I guess. It's the proxy between Office365's server/s and the Mitel?

Do you have a How To guide or anything that you've followed for this? I wasn't aware that Office365 UM was available or supported at all.

[bluewhite4]

Or is this the guide you're using: http://www.audiocodes.com/filehandler.ashx?fileid=3076885
So then the AudioCodes box is connected to the Mitel via QSig PRI?


Also found this: http://www.audiocodes.com/filehandler.ashx?fileid=35718
It's older, but it should get the Mitel side configured correctly.

[doctora]

We are connecting through IP not PRI.  I have provided a link below to our documentation. 

http://www.audiocodes.com/filehandler.ashx?fileid=2199440

We did find a setting for a codec in the codes section on the AudioCodes box but there was only one and it is set to T38  which is some sort of fax thing.  Not sure we are even in the right place.

We have done the change something.  Oops broke the whole thing.  Quick change it back.  Routine enough to start asking around and being a bit more careful.  It seems like it is more in the 3300 because the call is transferring properly and if the other person picks it up the connection stays connected until one of the parties hangs up.  Other than the static instead of audio it is working fine.

It is my belief( and I am often wrong) that once the transfer starts it should be back in the 3300 and nothing should be going to Office until voicemail is chosen again. Since the connection is made.  Both parties can answer the phone and the call stays connected until one of the parties hangs up.  The only thing wrong with the call is the static.

[acejavelin]

To be honest, I don't think you understand how any of this integration works to Office365... the Mediant gateway you are referring to is a SIP Gateway, but "IP connection" you are using a SIP connection.

You have a codec or RTP streaming issue... Or a SIP Peer options set incorrectly in the 3300. Without digging into both I don't know how I can troubleshoot this further if you don't understand the basic concepts involved.

[doctora]

acejavelin
      That was kind of mean.  If you don't want to help then don't reply.  You are correct in stating that I don't understand what is going on(You pointed it out not once but twice! ouch).

    Thanks for the tip on checking the Peer options.  I will look into it.

To anyone else reading this.

I want to understand the transfer better. I have been watching a syslog trace out of the median gateway.  When the call goes to voicemail I see it pass up to the Office365 server and then when the transfer back to an extension is made we see it go back through the Mediant 1000 to the 3300.  It is my belief that the call is then handed off to the 3300 until voicemail is requested again.  Does anyone know if this is true or if Office365 continues to track the call even if it is just a transferred call that is answered by the called party? 

Understanding this would help as I trace the call further.  I have wireshark set to collect packets on the connection between the Mediant Server and Office365.  I am currently setting up a switch on the connection between the Mediant 1000 and the 3300 so I can watch that also on Wireshark.  All I see on the mediant to Office365 look like good handshake and data packets but they stop after the call is transferred.

Thanks for the help.
Mark

[acejavelin]

I meant no disrespect or other ill intentions, and certainly did not mean to come across as mean, I apologize if I offended you... and it is not a problem to ask for help if you don't understand something. My point was that if you don't have a grasp of how this is supposed to work, and how SIP works in general, you may want to involve your vendor for more assistance since troubleshooting through the forums would be very difficult. If a user here had been in this situation before they probably would have responded already, but since this is day 5 of the same problem and nothing has changed, it might be beneficial to work with your vendor.

If you could give some more information, like how your SIP Peer is configured in the Mitel and how your gateway is configured, it might throw a red flag to someone.

[doctora]

I was beginning to get the same feeling after a few days people will usually comment or not.  The sad part is our vendor is pretty much useless.  We are required to use them for in house political reasons that are above my pay grade to know.  If it is not a vanilla install they will not help. 

Thanks for your time on this I will stop this thread.  If we get it going I will update with what we find.  We are pretty resourceful.  We were told not to use our local MS exchange for voicemail 5 years ago and we have had it running well for years. 

Thanks for the help.
Mark