Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mitel 3300 -- No RADs or MOH on SIP trunks, Just silence

Status
Not open for further replies.
phonebits

phonebits

Technical User
Feb 8, 2012
113
US
Hi Everyone-

I have a 3300 for a pretty big client that switched to SIP from the local ILEC about a year back.

We're now noticing after adding MOH and setting up some new ACD paths that when an incoming call hits a multi-level
auto attendant the calling party hears the AA greeting and when they make a selection that takes them to an ACD path
they just hear silence. If you make the same call internally, you hear a half ring then a RAD followed by music until
the RAD repeats.

On the SIP Peer SDP page we had "Avoid Signaling Hold to the Peer" set to yes since the SIP cutover, so that isn't the fix
as I've seen in a lot of threads on this issue.

I did a TCPDUMP and looked through it in wireshark and nothing is sticking out to me.

Code: 
|Time     | 192.168.99.253                        |
|         |                   | 192.168.99.10     |                   
|8.380000 |         INVITE SDP (g711U g7          |SIP INVITE From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 Call-ID:58e2e28-7f000001-13c4-1567cd-ce6d745e-1567cd@192.168.99.10 CSeq:1
|         |(5060)   ------------------>  (5060)   |
|8.380000 |         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   <------------------  (5060)   |
|8.550000 |         180 Ringing                   |SIP Status 180 Ringing
|         |(5060)   <------------------  (5060)   |
|9.700000 |         200 OK SDP (g711U te          |SIP Status 200 OK
|         |(5060)   <------------------  (5060)   |
|9.760000 |         ACK       |                   |SIP Request INVITE ACK 200 CSeq:1
|         |(5060)   ------------------>  (5060)   |
|18.290000|         INVITE    |                   |SIP INVITE From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:2
|         |(5060)   <------------------  (5060)   |
|18.310000|         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   ------------------>  (5060)   |
|18.350000|         200 OK SDP (g711U g7          |SIP Status 200 OK
|         |(5060)   ------------------>  (5060)   |
|18.370000|         ACK SDP (g711U telep          |SIP ACK From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:2
|         |(5060)   <------------------  (5060)   |
|18.750000|         INVITE    |                   |SIP INVITE From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:3
|         |(5060)   <------------------  (5060)   |
|18.770000|         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   ------------------>  (5060)   |
|18.810000|         200 OK SDP (g711U g7          |SIP Status 200 OK
|         |(5060)   ------------------>  (5060)   |
|18.820000|         ACK SDP (g711U telep          |SIP ACK From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:3
|         |(5060)   <------------------  (5060)   |
|22.310000|         INVITE    |                   |SIP INVITE From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:4
|         |(5060)   <------------------  (5060)   |
|22.340000|         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   ------------------>  (5060)   |
|22.400000|         200 OK SDP (g711U g7          |SIP Status 200 OK
|         |(5060)   ------------------>  (5060)   |
|22.420000|         ACK SDP (g711U telep          |SIP ACK From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:4
|         |(5060)   <------------------  (5060)   |
|30.320000|         INVITE    |                   |SIP INVITE From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:5
|         |(5060)   <------------------  (5060)   |
|30.340000|         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   ------------------>  (5060)   |
|30.400000|         200 OK SDP (g711U g7          |SIP Status 200 OK
|         |(5060)   ------------------>  (5060)   |
|30.410000|         ACK SDP (g711U telep          |SIP ACK From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:5
|         |(5060)   <------------------  (5060)   |
|49.540000|         INVITE    |                   |SIP INVITE From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:6
|         |(5060)   <------------------  (5060)   |
|49.560000|         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   ------------------>  (5060)   |
|49.600000|         200 OK SDP (g711U g7          |SIP Status 200 OK
|         |(5060)   ------------------>  (5060)   |
|49.610000|         ACK SDP (g711U telep          |SIP ACK From: "WIRELESS CALLER" <sip:8024304019@192.168.99.10:5060;transport=UDP To:<sip:4322@192.168.99.10:5060 CSeq:6
|         |(5060)   <------------------  (5060)   |

Anyone have any ideas? I'm trying with Mitel and the carrier but don't have high hopes for anything but finger pointing from either of them.
 
Sort by date Sort by votes
Phonebits,

Have you checked your Class of Service for your sip trunks? There are settings in there under Call Hold that will impact the MoH. Also double check RAD section as well.


I am running SIP trunks and have MoH enabled for callers (although I don't use RADS). I can confirm that Avoid Signaling Hold to the Peer in the SIP Peer SDP options is not the problem (mine is also set to yes).

The issue is most likely in the SIP Trunk CoS.



JCarmichael
 
Upvote 0 Downvote
JCarmichael,

I checked the COS form that applies to the SIP trunks, the relevant flags to allow MOH are on, however the ones pertaining to RADS I believe are to govern ports actually assigned as RADS, as I have a RAD COS that seems to be applied just to the ports that actually generate RAD messages.

I would expect if it were a COS issue that there would be ringback or something, not dead silence. In fact it even stays silent once the path overflows to an external PSTN with the silence only being broken when the forwarded party answers.
 
Upvote 0 Downvote
Phonebits,


Of course after I posted above, I reread your post.

How does a internal users dial out to the AA to get the MoH and RADS? Are they dialing the full phone number or an extension?



I posted under the assumption the internal users were dialing an extension to get to the AA.


I double checked my SIP Peer profile and nothing sticks out that screams Music on Hold. Although, my experience is extremely limited with SIP. I just switched from PRIs to SIP just about 2 months ago.


JCarmichael
 
Upvote 0 Downvote
JCarmichael,

I was just dialing the DN of the MLAA while testing, and selecting the option that lead to the ACD path. Testing internally that way everything works great.

But when I pointed a DID at the MLAA and did the same.... silence once I selected the option pointed at the ACD. I also tested making a call to a cell phone and putting it on hold, silence as well.
 
Upvote 0 Downvote
phonesbits,

Take a look at this thread (if you havent already)


Do you know for a fact your SIP provider allows MoH? Apparently, MoH is not always supported and/or enabled.

In your SIP Peer Profile - SDP Options do you have Prevent the Use of IP Address 0.0.0.0 in SDP Messages set to yes?



JCarmichael
 
Upvote 0 Downvote
Trying to wrangle someone from the carrier who can assist (very difficult, they're an ILEC and have outsourced all aspects of their SIP offering to contract employees from Adtran (CPE) and the softswitch vendor.).

I don't have Prevent Use of IP Address 0.0.0.0 set to yes, it's currently set to no.

Here's my SDP Options Form:

Code: 
Allow Peer To Use Multiple Active M-Lines   No    
  Allow Using UPDATE For Early Media Renegotiation   No    
  Avoid Signaling Hold to the Peer   Yes    
  Enable Mitel Proprietary SDP   No    
  Force sending SDP in initial Invite message   Yes    
  Force sending SDP in initial Invite - Early Answer   Yes    
  Limit to one Offer/Answer per INVITE   No    
  NAT Keepalive   No    
  Prevent the Use of IP Address 0.0.0.0 in SDP Messages   No    
  Renegotiate SDP To Enforce Symmetric Codec   No    
  Repeat SDP Answer If Duplicate Offer Is Received   Yes    
  RTP Packetization Rate Override   No    
  RTP Packetization Rate   20ms    
  Special handling of Offers in 2XX responses (INVITE)   Yes    
  Suppress Use of SDP Inactive Media Streams   No
 
Upvote 0 Downvote
phonesbits,

System Administration Tool Help said:
Prevent the Use of IP Address 0.0.0.0 in SDP Messages

If enabled, a SENDONLY or INACTIVE SDP that is sent by MiVoice Business will not contain the IP Address 0.0.0.0 as its connection address. If available, it will use the endpoint's IP address; otherwise, it will send the MiVoice Business system's IP address + port 9000. It is recommended that this option be set to 'Yes' for most customers. When set to 'No', in some cases it can prevent audio from being available when prompts or music-on-hold is being played to specific devices.
Click to expand...

The default value for it is Yes.

You could try to enable it, although I would only try it after hours/maintenance window just in case it screws up all the trunks.

Other than enabling the option above, I am running out of ideas on the PBX side.


JCarmichael
 
Upvote 0 Downvote
I tried setting it to yes with no effect. I think it was set to no during the initial turnup with the ILEC back in the day as part of our process of getting the trunks to work at all.

I've got a ticket open with the ILEC and am waiting on a ticket with Mitel. Here's to hoping one side or both manage to come up with some ideas.
 
Upvote 0 Downvote
phonebits,

Is it possible that this is a codec mismatch issue? I see in your SIP trace that g711u is offered and another g7 but the rest is cut off. Can you confirm if it is g711a?

My thinking is this:
SIP provider has set only g711u. The session is negotiated as g711u but the MoH was recorded as g711a. Since g711a is not offered as a codec by the provider there would be no audio.

I will admit, I am not sure if a codec mix match would affect the RADs as well.

Another shot in the dark, you could ask Mitel about setting up a MBG as a SIP proxy. Using a MBG as a sip proxy does alleviate some issues. To be honest, I don't think it would solve this problem but since you have a ticket open it might be worth it to ask.


Hopefully both sides dont point the finger at each other for to long.

JCarmichael
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Joe King
  • Locked
  • Question
MoH in between RADS on IVR
Replies
2
Views
228
Joe King
Joe King
Jose Moreno
  • Locked
  • Question
Mitel 3300 mOH 1
Replies
2
Views
176
Jose Moreno
Jose Moreno
W
  • Locked
  • Question
Mitel 3300 MXe III-L LAN Ports Dead
Replies
3
Views
445
jpruder
jpruder
LuanCarli
  • Locked
  • Question
Mitel SIP-Dect with Cloud-ID 8.0 - Gigaset registration
Replies
0
Views
236
LuanCarli
LuanCarli
Jose Moreno
  • Locked
  • Question
MITEL 3300 - Auto Attendant Greeting
Replies
4
Views
218
jpruder
jpruder

Part and Inventory Search

Sponsor

Back
Top