- Joined
- Feb 18, 2008
- Messages
- 8
- Reaction score
- 0
Here's my ongoing saga.
I'm testing 3CX to see if we want to buy it. We're using a SIP trunk from BroadVox. Most things are working now. However, frequently callers (most of them) calling into our PBX from BroadVox are getting misrouted. They receive an IVR when connecting. The IVR lets them dial an extension, which our case is a 3 digit number. In most cases, the PBX drops or doesn't get the initial 1, so they either get an invalid extension, or for some strange reason, the PBX forwards them to extension 111.
I turned logging up to debug. This is a typical call into the PBX that is sent to extension 111, even though extension 115 was keyed in.
From what I've read on this forum and Voxilla, it appears this is a DTMF issue. I've asked BroadVox which says they comply with RFC 2833 for DTMF so it is 3CX' problem. I assume that 3CX is going to tell me the same thing based upon previous posts.
All of the internal extension phones (GrandStream GXP 2000) are using RFC 2833 (via RTP (RFC2833) ).
I would appreciate any help. If 3CX and/or BroadVox cannot handle this kind of scenario, can someone point me to a PBX/provider that can?
Rob Hicks
I'm testing 3CX to see if we want to buy it. We're using a SIP trunk from BroadVox. Most things are working now. However, frequently callers (most of them) calling into our PBX from BroadVox are getting misrouted. They receive an IVR when connecting. The IVR lets them dial an extension, which our case is a 3 digit number. In most cases, the PBX drops or doesn't get the initial 1, so they either get an invalid extension, or for some strange reason, the PBX forwards them to extension 111.
I turned logging up to debug. This is a typical call into the PBX that is sent to extension 111, even though extension 115 was keyed in.
08:54:25.579 LineCfg::getInboundTarget :[CM503011]: Inbound office hours' rule for LN:10001 forwards to DN:801
08:54:25.579 LineCfg::getInboundTarget :[CM503011]: Inbound office hours' rule for LN:10001 forwards to DN:801
08:54:16.642 CallCtrl:nLegConnected :[CM503007]: Call(59): Device joined: sip:[email protected]:5060
08:54:07.376 CallCtrl:nSelectRouteReq :[CM503004]: Call(59): Calling: Ext:111@[Dev:sip:[email protected]:5060]
08:54:03.626 MediaServerReporting:TMFhandler :[MS211000] C:59.1: 64.158.162.71:19624 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
08:53:48.517 LineCfg::getInboundTarget :[CM503011]: Inbound office hours' rule for LN:10001 forwards to DN:801
08:53:48.501 CallCtrl:nLegConnected :[CM503007]: Call(59): Device joined: sip:801???????@???.???.???.???:5060
08:53:47.548 CallCtrl:nLegConnected :[CM503007]: Call(59): Device joined: sip:
08:53:47.548 CallCtrl:nSelectRouteReq :[CM503004]: Call(59): Calling: IVR:801@[Dev]
08:53:47.532 Line:rintEndpointInfo :[CM505003]: Provider:[Broadvox1] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] Transport: [sip:???.???.???.???:5060]
08:53:47.532 LineCfg::getInboundTarget :[CM503011]: Inbound office hours' rule for LN:10001 forwards to DN:801
08:53:47.517 CallCtrl:nIncomingCall :[CM503001]: Call(59): Incoming call from 801???????@(Ln.10001@Broadvox1) to [sip:[email protected]:5060]
08:53:46.345 LineCfg::getInboundTarget :[CM503011]: Inbound office hours' rule for LN:10001 forwards to DN:801
From what I've read on this forum and Voxilla, it appears this is a DTMF issue. I've asked BroadVox which says they comply with RFC 2833 for DTMF so it is 3CX' problem. I assume that 3CX is going to tell me the same thing based upon previous posts.
All of the internal extension phones (GrandStream GXP 2000) are using RFC 2833 (via RTP (RFC2833) ).
I would appreciate any help. If 3CX and/or BroadVox cannot handle this kind of scenario, can someone point me to a PBX/provider that can?
Rob Hicks