Audiocodes Syslog:
34758635) !! [ERROR] ServicesMngr: Cannot allocate more Media channel. current active: 0 and max is: 0 [Time:17-09@10:37:35]10:40:22.005  192.168.91.11   local0.warn    [S=36517144] [SID=b9f1b9:10:703405]  (      lgr_flow)(  34758636) !! [ERROR] (#22)RTPStreamResource::AllocateResource Allocate Resource – cannot allocate DSP. probably lack of resources

[Time:17-09@10:37:35] 10:40:22.006  192.168.91.11   local0.notice  [S=36517145] [SID=b9f1b9:10:703405]  ( media_service)(  34758637)  (#8) StreamsConnector Deallocated. [Time:17-09@10:37:35]

Reason for failure:

Option 1: no SDP ports configured or Option 2:  ShoreTel does not send a telephone-event in the SDP

Option 1:
enable music on hold on the phone system, so that the re-invite does not have:  a=inactive

OR

If you don’t want music on hold, then do the following below to allow the Audiocodes to use SDP channel.

So we need to fix the DSP capability on your virtual SBC – at the moment, you have none. This can be resolved by doing the following:

* changing the parameter SBCPerformanceProfile set to 2 (optimised for transcoding) (will require a reset afterwards, complete reset after all tasks have been confirmed)

* making sure your virtual SBC has more than 1x vCPU, it will need at least 2x CPU to do transcoding.

* CPU cores will need to be avx capable (say avx support) – jump onto your virtual SBC CLI and run the command ‘show system hardware’ it will output the CPU details, for example:  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, total 2 cores avx support(avx) 

What we want is the ini file to say “;Num of DSP Cores: 0  Num DSP Channels: 0” — but have the number be something other than 0.

Option 2:

___ShoreTel inbound manipulation___
Message Type: ACK
Action Subject: body.sdp
Condition: body.sdp regex (v=0)(\r\n)(.*)(RTP/AVP 8 0)(.*)(a=inactive)(.*)

AVP 8 0 has to match the order of the codec in the ShoreTel Invite SDP. If the ShoreTel codec list ever changes, then this will also have to change.

Modify
Action Value:$1+$2+$3+$4+’ 101’+$5+’a=rtpmap:101 telephone-event/8000\\a=fmtp:101 0-15’+$2+$6+$7

Make sure you have Manipulation 3 set:

If this rule is working, but you are still getting the same result, then try looking at the syslog to make sure we are matching on the rule.

o=ShoreGear 0 4 IN IP4 192.168.100.25 
s=- 
c=IN IP4 192.168.100.25 
t=0 0 
m=audio 64283 RTP/AVP 18 8 0 
a=rtpmap:18 G729/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:0 PCMU/8000 
a=inactive 
                                                                             
1: v=0 

2:  
                                                                             
3: o=ShoreGear 0 4 IN IP4 192.168.100.25 
s=- 
c=IN IP4 192.168.100.25 
t=0 0 
m=audio 64283  

4: RTP/AVP 8 0 

5:  
a=rtpmap:18 G729/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:0 PCMU/8000 
                                                                             
6: a=inactive 

7:  

Syslog:

22:00:11.994  192.168.100.241 local0.notice  [S=73726] [SID=bf639b:36:300]  (     lgr_stack)(     70325)  [ManSet: 3, Rule: 4] – Executed on msgId:1601 (Condition was True)[Time:25-09@22:00:12]

Matching on AVP 8 0

I check the logs, the MM rule is working and the ACK with Telephone event is forwarded to ITSP. After there’s few more re-Invite from both endpoints that seems causing timing issue. I suggest you configure the parameter:

‘SBCRemoteReInviteSupport’ = Not Supported’ on ITSP IP Profile.