Mitel 3300 MCD 4.2 with SIP Trunk Asterisk - Automatic Outbound call signaling

[steve75]

Hello everyone,
I need help on a problem on outgoing calls via SIP Trunk.
I created a sip trunk with 15 contemporary connecting Mitel 3300 MCD 4.2 with Asterisk system.
Everything works fine. But making an outgoing call the Mitel 3300 provides immediately CONNECT. This may be fine on outgoing calls manuals. On outbound calls made ​​automatically by the system asterisk, if I have the CONNECT instant the system is not able to understand if the called number has answered the call or not.
Do you have any help that I can give? Need to change some parameter in the SIP Peer Profile for this type of problem?
Any help is appreciated!
Thank you

This is my SIP Peer Profile:
Calling Line ID Options
  Default CPN       
  CPN Restriction   No   
  Public Calling Party Number Passthrough   No   
  Use Diverting Party Number as Calling Party Number   No   
 
 
Authentication Options
  User Name       
  Password   *******     
  Confirm Password   *******     
  Authentication Option for Incoming Calls   No Authentication   
  Subscription User Name       
  Subscription Password   *******     
  Subscription Confirm Password   *******     
 
 
SDP Options
  Allow Peer To Use Multiple Active M-Lines   No   
  Allow Using UPDATE For Early Media Renegotiation   No   
  Avoid Signaling Hold to the Peer   No   
  Enable Mitel Proprietary SDP   Yes   
  Force sending SDP in initial Invite message   No   
  Force sending SDP in initial Invite - Early Answer   No   
  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   No   
  RTP Packetization Rate Override   No   
  RTP Packetization Rate   20ms   
  Special handling of Offers in 2XX responses (INVITE)   No   
  Suppress Use of SDP Inactive Media Streams   No   
 
 
Signaling and Header Manipulation Options
  Allow Display Update   No   
  Build Contact Using Request URI Address   No   
  De-register Using Contact Address not *   No   
  Disable Reliable Provisional Responses   Yes   
  Disable Use of User-Agent and Server Headers   No   
  Enable sending '+' for E.164 numbers   No   
  Force Max-Forward: 70 on Outgoing Calls   No   
  Ignore Incoming Loose Routing Indication   No   
  Use P-Asserted Identity Header   No   
  Use P-Preferred Identity Header   No   
  Use Restricted Character Set For Authentication   No   
  Use To Address in From Header on Outgoing Calls   No   
  Use user=phone   No   
 
 
Timers
  Registration Period   3600   
  Registration Period Refresh (%)   50   
  Session Timer   90   
  Subscription Period   3600   
  Subscription Period Minimum   300   
  Subscription Period Refresh (%)   80   
 
 
Key Press Event Options
  Allow Inc Subscriptions for Local Digit Monitoring   No   
  Allow Out Subscriptions for Remote Digit Monitoring   No   
  Force Out Subscriptions for Remote Digit Monitoring   No   
  Request Outbound Proxy to Handle Out Subscriptions   No   
  KPML Transport   default   
  KPML Port   0

[jrg0852]

My guess is a timer change would tweak this, but not sure which one. See what "Help" gives you, or hover the mouse pointer at the timers and look at the info. If someone else knows more, please chime in. Thanks.

[matthew]

Huh, what are the chances.. I was going to post about the same problem in a different scenario. 

I have a MCD 6.0 SP2 system sip trunked to a 3rd party IVR app. The IVR wants to make outbound calls to customers and give them information they requested. Obviously, it needs to know when the B party answers. I'm seeing the same thing as steve75 - for some unknown reason the Mitel is responding with 200 OK at about the time it receives a ring signal from the external telephone network. Basically, the IVR sends an INVITE, the Mitel replies with 100 Trying, then a few seconds later it sends 183 Session Progress, quickly followed by 200 OK. If we test to an extension, it works perfectly. The outbound trunks are E1 ISDN.

I've been all over my config, and have read a bunch of the sample configs for different providers on MOL, but I'm still in the dark. The only thing that looks like what I want is in Digital CO Trunk Circuit Descriptors there is a setting for Fake Answer Supervision After Outpulsing, but it doesn't apply to my trunk types as far as I can tell. It's like that setting is Yes on E1 trunks.

jrg0852 - I don't think this is timer related as I see it at random times roughly 3 to 6 seconds after INVITE.

[ralph]

Is there a way to tell from CCS traces if the answer supervision is coming from the E1?

Ralph

[matthew]

I've been in touch with the amazing guys at L2 Support. They have suggested I enable "Suppress Simulated CCM after ISDN Progress" in CoS for anything in the path. The online help for that feature is instructive, but has a couple of warnings that are giving me pause. I'm just going through change management with the customer and will update the thread with how things turn out - probably sometime next week.

[matthew]

Earlier update than expected - this new SIP trunk is not in production so we gave it its own COS and gave it a try there only. The IVR dev says "Works a treat". 

[sarond]

Good to know,
Thanks for the update

[ralph]

They have suggested I enable "Suppress Simulated CCM after ISDN Progress" in CoS for anything in the path. The online help for that feature is instructive, but has a couple of warnings that are giving me pause.

Ah!  I remember this now.  The issues I've experienced with this enabled were that there were some auto attendants i couldn't dial through.  It wouldn't hear the touch tones.   You'd call an airline, it would answer with an auto attendant but you couldn't do anything.
With this enabled you won't be able to use touch tones until you get answer supervision from the far end.  In some cases it never comes through.

Ralph

[matthew]

Thanks, ralph. That puts some meat onto the warnings in help. I'll pass it on to the devs to be sure to use a broad range of test numbers during rollout.

Hopefully steve75 will let us know if it's helped his issue, too.