Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: danje 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.
-
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
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.
But....
If the SBC isn't on prem I'm still thinking this should work. Has your VAR verified that the carrier has been verified by Mitel's COE?
Ralph
-
media will always be from the endpoint not from the ICP unless you use MBG as a SIP proxy
-
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.
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 used * (wild card) so that all phones would outpulse the same IP.
URI = *@PUBLICIP
User = *
I.E. URI = *@8.8.8.8
User = *
That should correct the SDP Header information that your provider is seeing as incorrect.
-
Thank you everyone for your responses. :)
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.
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. :(
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.
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.
-
Can you do a tcpdump and attach it to a post so that we can see what is actually being included in the SIP header?
-
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. :-)
-
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. :-)
It usually "just works" if you are throwing SIP endpoints in (like Polycom/Aastra phones), but for trunking it is different, you are correct that you need a SIP-aware router.
We use the Edgemarc routers from Edgewater Networks, just point the phone system to the router and let it register to that and a little setup in the router and it does all teh translation and stuff needed to connect tot he SIP providor. Helps that we are usually the SIP provider as well! :)
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.
-
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. ;)
-
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. ;)
Cool! Glad they are working for you.